DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The Amendment to the claims filed on 03/06/2026 complies with the requirements of 37 CFR 1.121(c) and has been entered. Claims 1, 14, 18 and 20 are amended and Claim 22 is cancelled.
Response to Arguments
Applicant's Arguments/Remarks filed 03/06/2026 (hereinafter Resp.) have been fully considered hereinafter.
Applicant’s argument and amendment is for a “per network slice and per interface selection of the congestion control processes” – See Resp., p.8:¶1 allegedly supported by [¶¶0057-60] of the Specification. Examiner respectfully disagrees with this interpretation of the present disclosure because of the following reasons.
The disclosure supports the assertion that a network slice involves many network interfaces albeit they are known and standardized (“A network slice involves the access network (RAN), the transport network, the core network (CN) and possibly a cloud network that is part of the communication service provider. Since many links in a network slice are IP flow-based, congestion control mechanisms can have a direct influence in the quality of the network slice, or how well the service level specifications of the network slice will be fulfilled” – See Spec. [¶0026]).
However, when it comes to congestion control processes, these interfaces are considered by the present disclosure in two “aggregates”: user plane interfaces and control plane interfaces, i.e., not individually and for sure in the alternative between the two interface aggregates as shown in Fig. 8 wherein “[a]t operation 809, congestion control selection module 605 requests from UDM 601 the user plane interfaces used in the network slice” – See [¶0067] and, in the alternative, “[i]n operation 813, congestion control selection module 605, requests control plane interfaces used in the network slice” – See [¶0068].
Finally, the “congestion control selection module 605 applies the selected congestion control process in NSMF/NSSMF 603” – See [¶0070] and Fig. 8, i.e., at slice level, over all the interfaces included in the slice not on a per interface basis, hence a claim to a congestion control process for each of a plurality of interfaces of a network slice does not have support in the present Specification. In addition, a person of ordinary skills in eth art would appreciate that one congestion control process for each possible interface of a network slice would require an excessive amount of computing resources and may result in a suboptimal or even impossible solution to reducing the congestion occurring in a network slice – See, e.g., Fig. 1C of Ravichandran et al., U.S. Patent Application No. 2020/0186411 showing end-to-services supported by network slices managed by a cognitive orchestrator.
In sum, Applicant’s argument is unpersuasive and the §103 rejection is maintained.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Amended Claims 1, 14, 18 and 20 and their dependent claims are rejected under 35 U.S.C. §112(a) as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, at the time the application was filed, had possession of the claimed invention.
The Amended Claims recite the requirement “a congestion control process for each of a plurality of interfaces of a network slice.” However, the present disclosure specifically describes the process of selecting a congestion control process for an aggregate of user plane interfaces or, in the alternative, for an aggregate of control plane interfaces – See [¶¶0067-68] and Figure 8 whereby the selected congestion control process is applied at the slice level, specifically the Network Slice Management Function/Network Slice Subnet Management Function (NSMF/NSSMF) – See [¶0070] and Figure 8. Specifically, the further limitation “specific to each of the plurality of interfaces of the network slice” is not supported by the disclosure because the disclosure specifically states that “congestion control selection module 605 applies the selected congestion control process in NSMF/NSSMF 603” – See [¶0070] and Fig. 8, i.e., at slice level. Therefore, the amended claim requires features that do not have support in the present disclosure.
In sum, Amended Claims 1, 14, 18 and 20 and their dependent claims are rejected under 35 U.S.C. §112(a) as introducing new matter. For examination purposes the claimed limitation “each of a plurality of interfaces of a network slice” will be interpreted as “user plane interfaces” and “control plane interfaces” as supported by the present disclosure. Applicant could amend to specify whether the plurality of interfaces are of type “user plane” or “control plane.”
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-2, 4, 7-10, 12, 14-15, 18-20, as amended, are rejected under 35 U.S.C. 103 as being unpatentable over Chiba et al., U.S. Patent Application Publication No. 2020/0382990 (hereinafter Chiba) and further in view of Ravichandran et al., "Mechanism of dynamic, impact-aware and context aware orchestration of cognitive functions in 5G networks," 2018 IEEE International Conference on Advanced Networks and Telecommunications Systems (ANTS), and references included therein (hereinafter Ravichandran1).
Regarding Amended Claim 1, Chiba teaches a computer-implemented method for dynamic congestion control for network slices (“mechanism and a communication control method for implementing management processing such as congestion control for each network slice” – See [¶0009], whereby “a Network Slice is a logical network that provides a specific network capability and a network characteristic” – See [¶0130] and a “Network Slice Instance (NSI) . . . is an entity of each of one or a plurality of Network Slices configured in the core network” and “may include a virtual Network Function (NF) generated using a Network Slice Template (NST)” and “associated with a resource request for providing a required communication service or capability, and is a logical expression of one or a plurality of Network Functions (NFs)” – See [¶0131]), the method comprising:
obtaining a recommendation from a network node for a congestion control process for each of a plurality of interfaces of a network slice (“congestion control initiated by the terminal apparatus and by a network for each network slice and/or a DNN or an APN” – See [¶0012] whereby “the APN may be identification information for identifying the core network and an external network such as the DN” or “may be a Data Network Name (DNN)” or “can also be used as information for selecting a gateway such as the PGW A 30/UPGW _A 130/UPF A 235 for connecting the core network A_90,” i.e., inherently providing control plane interfaces and user plane interfaces as a gateway to the core network for each network slice – See [¶0111] and Fig. 4; furthermore, “an apparatus (network apparatus) within a network performs transmission and/or reception of a message and/or performs a procedure” based on sessions – See [¶0126], and “a Session Management (SM) message (also referred to as a Non-Access-Stratum (NAS) SM message or a SM message) may be a NAS message [i.e., over user plane interfaces] used in a procedure for the SM (also referred to as a session management procedure or an SM procedure), or may be a control message [i.e., over control plane interfaces] transmitted and/or received between the UE_A 10 and the SMF A 230 via the AMF A 240” – See [¶0127] (emphasis added); see also 3GPP TS 23.501 V16.6.0 (2020-09), “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16)” specifying, at page 194-195, that “A Network Slice instance is defined within a PLMN and shall include: the Core Network Control Plane and User Plane Network Functions, as described in clause 4.2, and, in the serving PLMN, at least one of the following: the NG-RAN described in TS 38.300 [27]; . . .” whereby the general 5G System architecture in Figure 4.2.3-1 at page 31 shows the same NFs as in Fig. 4 of Chiba and § 4.3, 3GPP TS 38.300 V16.3.0 (2020-09)” Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Release 16)” further specifies at page 18-19 that “The NG user plane interface (NG-U) is defined between the NG-RAN node and the UPF . . . to carry the user plane PDUs between the NG-RAN node and the UPF” in a “non-guaranteed delivery” while “The NG control plane interface (NG-C) is defined between the NG-RAN node and the AMF” providing, among other functions “NG interface management”, “PDU Session Management”, “Configuration Transfer”, and “Transport of NAS messages”; de Foy et al., “Network Slicing - 3GPP Use Case: draft-defoy-netslices-3gpp-network-slicing-02,” Internet-Draft, October 17, 2017, showing the control pane and the user pane interfaces of a network slice reproduced hereinafter;
PNG
media_image1.png
734
501
media_image1.png
Greyscale
PNG
media_image2.png
417
549
media_image2.png
Greyscale
; furthermore, the congestion control process may apply specifically to the plurality of control plane or user plane interfaces of a network slice, e.g., “in a case that control signal congestion with respect to S-NSSAI #A is detected on an NW and the NW recognizes it as a UE initiated session management request directed only to the parameters of the S-NSSAI #A, the NW may apply the second congestion control” to “prevent the UE-initiated session management request directed only to the S-NSSAI #A,” i.e., the congestion control is applied to user plane interfaces of S-NSSAI #A – See [¶0151], while “the fourth congestion control in the present embodiment is control signal congestion control directed to the parameters of the DNN and the S-NSSAI” e.g., “may be congestion control to restrict all connections based on the S-NSSAI #A and congestion control to restrict a connection to the DNN #A in all types of connectivity,” i.e., the congestion control is applied to control/connectivity plane interfaces of S-NSSAI #A – See [¶0156]; furthermore, a network slice interfaces are standardized, e.g., as shown in Fig. 4 of Chiba, because a network slice is a collection of network functions (NFs) as known in the art and “the NF may be a function apparatus such as an MME, an SGW, a PGW, a CPF, an AMF, an SMF or a UPF, or may be a function such as Mobility Management (MM) or Session Management (SM), or capability information”– See [¶0054], whereby one NF “may have connectivity with another NF and may be connected to each apparatus via another NF” – See [¶0071] i.e., are interconnected through standardized interfaces in user plane or control plane; thus, each NW slice instance (NSI) “may be an aggregation including a plurality of NFs” – See [¶0131] the NSI includes the plurality of interfaces between the included NFs “generated using a Network Slice Template (NST)” – See [¶0131] grouped by User Plane functions and Control Plane functions as shown above)
based on at least one condition related to the network slice (“the NW may transmit different values to the UE as cause values depending on whether the congestion control is the second congestion control or the third congestion control, or the first congestion control or the fourth congestion control” – See [¶0243], e.g., “the fourth congestion control” is directed to “the parameters of the DNN and the S-NSSAI and may be congestion control caused by connectivity to the DNN via a network slice selected based on the S-NSSAI in a congested state” – See [¶0156] or the UE’s “first PDU session is rejected because of a temporary cause,” e.g., one of the 5GMM PDU session rejection causes due to DNN or N-SSAI1)
wherein application of the congestion control process addresses the at least one condition related to the network slice (e.g., when “the NW may transmit different values to the UE as cause values depending on whether the congestion control is second congestion control or the fourth congestion control” – See [¶0244], “the fourth congestion control . . . may be congestion control to restrict all connections to the DNN via a network slice selected based on the S-NSSAI #A and may be congestion control to restrict a connection to the DNN #A in all types of connectivity” in case of UE requesting “connectivity to the DNN via a network slice selected based on the S-NSSAI in a congested state” – See [¶0156]; similarly, the “second congestion control . . . indicates control signal congestion control directed to parameters of S-NSSI . . . and the NW recognizes it as a UE initiated session management request directed only to the parameters of the S-NSSAI” and in “case that the second congestion control is applied . . . [it] may prevent the UE-initiated session management request directed only to the S-NSSAI” – See [¶0151]; i.e., “congestion control to restrict all connections to the DNN via a network slice selected based on the S-NSSAI” – See [¶0152] to relieve the congested condition of the NW slice); and
applying the congestion control process in a protocol stack for each of the plurality of interfaces of the network slice (the UE initiated “SM message may be an NAS message used in a procedure for session management and may be a control message transmitted and/or received between the UE_A 10 and the SMF A 230 via the AMF A 240” and “the SM message may include . . . a PDU session reject message” – See [¶00141]; i.e., the congestion control process applies to the protocol stack of NAS, across the Nx interfaces which are Control Plane interfaces between NFs, i.e., “it may be congestion control to restrict all connections to the DNN via a network slice selected based on the S-NSSAI #A” – See [¶0152] wherein the “[t]he SMF A 230 transmits a PDU session establishment reject message to the UE_A 10 via the AMF A 240 using the N11 interface, and the AMF A 240 that has received the PDU session establishment request message transmits the PDU session establishment reject message to the UE_A 10 using the N1 interface” – See [¶0314] whereby the SMF, AMF and NR access NFs may be part of the same NW slice/NSI, as explained supra; i.e., the congestion control is applied to the NG-C control interfaces of the NAS protocol stack as specified in 3GPP TS 38.300 and explained supra; furthermore while the UE applies the congestion control through “first identification process to identify which type of congestion control to apply among the congestion controls from the first congestion control to the fourth congestion control and second identification process to identify the DNN and/or the S-NSSA associated with the congestion control to be applied” – See [¶0173], there can be “Third identification information in the present embodiment may be a PDU session ID and information used to identify a PDU Session” – See [¶0230], “Fourth identification information in the present embodiment is a Procedure transaction identity (PTI), which may be information for identifying transmission and/or reception of a series of messages of a specific session management procedure as a single group” – See [¶0231], “13th identification information in the present embodiment may be a PDU Session ID and/or PTI that is a PDU session ID and/or PTI not allowed by the network, or may be information indicating that a PDU session ID and/or PTI identified with the third identification information is not allowed” – See [¶0235] and “the 21st identification information may be information indicating that the congestion control applied at the time of reception of the 21st identification information is changed to another congestion control among the congestion controls from the first to the fourth congestion control” – See [¶0257] e.g., after the UE successfully establishes a PDU session with the core network as explained in § 1.3.2 and Fig. 11, procedure (A) whereby “each apparatus may transition to a state in which the PDU session is established based on the completion of the procedure (A) in the present procedure” and “may transition to the first state”– See [¶0349] and Fig. 12 wherein “each apparatus in the UE_A 10 and core network_B 190 that has transitioned to the first state (S1200)” – See [¶0359] and “that the UE_A 10 may perform the congestion control identification processing applied by the UE_A 10 based on the received 21st identification information in the fifth process” – See [¶0365] wherein “the fifth process may be a process of recognizing, by the UE_A 10, the matter indicated by the core network_B 190” – See [¶0363] i.e., the UE changes from congestion control applied to PDU session establishment over control plane interfaces Nx to congestion control applied to user plane interfaces during an ongoing PDU session due to the matter indicated by the core network because “the UE_A 10 can stop or modify the congestion control applied by the UE_A 10 based on the network-initiated session management request message” – See [¶0369] and a “NW slice according to the present embodiment is an NW slice to which the established PDU session belongs at a time when the UE connects to a particular DN” – See [¶0136])
wherein obtaining the recommendation comprises consulting a cognitive layer of the network to determine a best or improved congestion control process specific to each of the plurality of interfaces of the network slice (“the PCRF performs QoS management for a communication path between the UE_A 10, the DN_A 5” and “generate and/or manage a Policy and Charging Control (PCC) rule and/or a routing rule used by each apparatus to transmit and/or receive user data” – See [¶0058] based on context data from “a UDM FE (application front end) and a User Data Repository (UDR)” – See [¶0078]; then, in preparation for responding to each congestion control signal with a recommended congestion process, a “first timer may be configured to be associated with at least one of a congestion control unit which an NW applies,” wherein “the identification information indicating one or more NW slices” – See [¶0140], “to a back-off timer received from the NW . . . for a plurality of relevant NW slices based on information for identifying one NW slice . . . in units of back-off timers for preventing reconnection or a combination of an APN/DNN and one NW slice” – See [¶¶0141-42], and “rules configured in the UE_A 10 to collectively manage a plurality of back-off timers that have occurred in a plurality of PDU sessions . . . [e.g.,] in a case that conflicting or overlapping congestion control is applied” – See [¶0146], and “rules for associating information identifying a plurality of network slices. Note that the network slice association rules may be received [dynamically] in the PDU session reject message” – See [¶0145]; furthermore, the NW may change dynamically the parameters and type of congestion control process to be applied to a specific PDU session message by exchanging 21 types of indication information applicable to 15 described UE behaviors in case of congestion detected for UE initiated sessions – See [¶¶0158-73]).
Chiba does not explicitly teach a cognitive layer of the network that is configured to determine the best or improved congestion control process specific to the network slice. Ravichandran1 teaches that “[t]he resources and the services running on each slice need to be orchestrated, while all slices have to be orchestrated at the network level” – See I, ¶1:col2, at page 1, presenting “a case for effective orchestration of the CFs in a dynamic and context aware manner taking into consideration service/slice SLAs, and KPIs, user mobility, service characteristics and dynamic network conditions, while complying with policy constraints” – See id., ¶1:col1, at page 2; i.e., using a cognitive layer to execute the logic in Fig. 3 for “[i]mpact-aware and context-aware determination of actions to resolve (predicted) fault or performance issues in a service or slice, considering impacts on other services and slices, and the affected common resources” – See II., ¶3:col2, at page 2, Fig. 1 showing a E2E Cognitive Function (CF) Orchestrator layer based on CFs distributed at slice level, and Fig. 3.
Thus, Ravichandran1 and Chiba each teaches slice level performance management. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the recommendations for the type of congestion control process and the indication information exchanged between the network and the UE when a congestion cause occurs at slice level, after the UE is in communication with the core network during an established PDU session as taught in Chiba, could have been obtained from a cognitive layer orchestrating cognitive functions (CFs) distributed at slice level to determine a best or improved congestion control process specific to the network slice, as taught in Ravichandran1, because a congestion control process is a type of slice level performance management as taught in both Chiba and Ravichandran1. Furthermore, a person of ordinary skill in the art would have been able to carry out the combination through techniques known in the art because Chiba teaches control plane interfaces and user plane interfaces according to 3GPP standards – See [¶0075]. Finally, the combination has the predictable result of dynamically assessing the impact of congestion control actions on a service/slice on other services and slices and perform self-adaptation for improvement, as taught by Ravichandran1.
Therefore, Amended Claim 1 is obvious over Chiba in view of Ravichandran1.
Regarding Claim 2, dependent from Amended Claim 1, Chiba does not teach the method of Claim 1, wherein the network node comprises a machine learning model, and wherein the machine learning model comprises an unsupervised machine learning model. However, Ravichandran1 teaches the network node comprises a machine learning model (“Cognitive functions and analytics engines are now seen as an integral part of management and orchestration . . . employing one or more of artificial intelligence, machine learning or deep learning techniques to address an issue – its output could be prediction, recommendation, root cause determination, resolution or a combination of these” – See I., ¶2:col1, at page 1, and “the CFs are activated at the appropriate place in the network in a context-aware manner, taking into consideration aspects such as user mobility, session type, Key Performance Indicators (KPIs), SLAs, dynamic network conditions, location of the users involved in the session” – See id., ¶3:col2, at page 1 and Fig. 1 showing CF deployed in NFs at slice level, wherein, e.g., “a CF performing log analysis to determine the root cause may comprise of NLP to examine the event logs, employ machine learning (ML) techniques on the performance metrics and decoded event logs” – See III., ¶8:col2, at page 2, whereby machine learning (ML) techniques include using ML models.
Although Ravichandran1 does not explicitly teach wherein the machine learning model comprises an unsupervised machine learning model, Ravichandran1 references “Ayoubi et al [2]” as related work – See II., ¶1:col.1, at page 2, whereby Ayoubi et al, “Machine Learning for Cognitive Network Management”, IEEE Communications Magazine, Jan. 2018, pp 150-165, (hereinafter Ayoubi) teaches that an unsupervised ML technique “uses unlabeled training datasets to create models that find dominating structure or patterns in the data . . . appropriate for clustering, outliers detection, and density estimation problems,” specifically, “k-nearest neighbors (k-NN), decision trees (DTs), and neural networks (NNs) have been used in both supervised and unsupervised learning. k-means operates only in unsupervised learning” – See Ayoubi, ¶1,¶3 :col2, at page 159 and Table 1 (showing unsupervised ML techniques used for fault management, and a person of ordinary skills in the art would recognize that using the cause value related to the N-SSAI congestion in a congestion control process, as taught in Chiba, may be an example of ML unsupervised model driven fault management).
Therefore, Claim 2 is obvious over Chiba in view of Ravichandran1.
Regarding Claim 4, dependent from Claim 1, Chiba further teaches wherein the at least one condition related to the network slice comprises at least one of a specification of the network slice, a status of the network, a traffic flow in other network slices, and a topology of the network (“the UE_A 10, an apparatus in the access network, and/or an apparatus in the core network, and an apparatus in a data network may associate one or more pieces of identification information with the PDU session for management,” such as a SM reject message, wherein “these pieces of identification information may include . . . a Traffic Flow Template (TFT) . . . identification information of the DN_A 5 [e.g., associated with topology], Network Slice Instance (NSI) identification information [e.g., associated with slice specification], Dedicated Core Network (DCN) identification information, or access network identification information [e.g., associated with topology] – See [¶0031]; in addition, “a cause value may be information for identifying a congestion control among the congestion controls from the first congestion control to the fourth congestion control the congestion control that the NW notifies the UE indicates based on the rejection of the PDU session establishment” – See [¶0238], wherein the cause value is associated with a congested condition of the DNN and/or the S-NSSAI, e.g., “the first congestion control in the present embodiment is control signal congestion control directed to the DNN, and congestion control caused by connectivity to the DNN in a congested state” – See [¶0150] or “may be congestion control caused by a network slice selected based on the S-NSSAI in a congested state” – See [¶0152] “or in a case that a first PDU session is rejected because of a temporary cause” with the APN/DNN– See [¶0159] and in general “The 15th identification information in the present embodiment is information indicating one or more Cause Values indicating a cause for which the present procedure has been rejected” – See [¶0238]; see also 3GPP 24.501 at pages 208-209 for cause values).
Therefore, Claim 4 is obvious over Chiba in view of Ravichandran1.
Regarding Claim 7, dependent from Amended Claim 1, Chiba further teaches extracting the at least one condition related to the network slice, wherein the extracting comprises obtaining the at least one condition from at least one of a network slice request and a network knowledge database (“for each congestion control from the first congestion control to the fourth congestion control, the NW may transmit a different value to the UE as a cause value” and “[t]he UE may interpret each value transmitted as a cause value in advance” – See [¶0239], e.g., the network “UDR stores data necessary for the UDM FE for provision and policy profiles necessary for the PCF” – See [¶0078], and cause values associated with DNN and S-NSSAI congestion are, e.g., cause #22, 67, or 69 as defined in 3GPP TS 24.501 at page 209)
Therefore, Claim 7 is obvious over Chiba in view of Ravichandran1.
Regarding Claim 8, dependent from Claim 7, Chiba further teaches obtaining a network topology of a network slice instance for the network slice request2 (“Network Slice Instance (NSI) . . . is an entity of each of one or a plurality of Network Slices configured in the core network_B 190” which “may include a virtual Network Function (NF) generated using a Network Slice Template (NST) . . . associated with a resource request for providing a required communication service or capability, and is a logical expression of one or a plurality of Network Functions (NFs),” i.e., “an aggregation including a plurality of NFs in the core network_B 190” and “[t]he UE_A 10 . . . can be allocated to one or a plurality of network slices, based on NSSAI and/or S-NSSAI” – See [¶0131], i.e., based on “information indicating an operation of network slices expected in terms of function and service” – See [¶0132] such as connectivity to DN_A as shown in Fig. 4),
wherein the network topology comprises a plurality of network functions and a plurality of links between the plurality of network functions (“core network_B may include at least one of an Authentication Server Function (AUSF), an Access and Mobility Management Function (AMF)_A 240, an Unstructured Data Storage Network Function (UDSF), a Network Exposure Function (NEF), an Network Repository Function (NRF), a Policy Control Function (PCF), a Session Management Function (SMF)_A 230, a Unified Data Management (UDM), a User Plane Function (UPF)_A 235, an Application Function (AF), or a Non-3GPP InterWorking Function (N3IWF)” which “may also be configured as Network Functions (NFs)” – See [¶0063] in a topology containing a plurality of links between the plurality of network functions because the Network Slice Template (NST) “is associated with a resource request for providing a required communication service or capability, and is a logical expression of one or a plurality of Network Functions (NFs)” – See [¶0131] and as shown, e.g., in Fig. 4)
Therefore, Claim 8 is obvious over Chiba in view of Ravichandran1.
Regarding Claim 9, dependent from Claim 7, Chiba further teaches determining the plurality of interfaces included in the network slice instance, e.g., based on the access/core NFs3 included in the NSI used by “the UE_A 10 [to] transmit and/or receive the user data to and/or from an apparatus, such as an application server that is deployed in the DN_A 5 by using a PDU session” – See [¶0031], Fig. 1 and Figs. 3 and 4, distinguishing NFs and interfaces for UTRAN/E-UTRAN access to network B (Fig. 3) and for NR access to network A (Fig. 4 and [¶0064]).
Therefore, Claim 9 is obvious over Chiba in view of Ravichandran1.
Regarding Claim 10, dependent from Claim 9, Chiba further teaches wherein the plurality of interfaces comprises interfaces in a user plane or in a control plane of the network (Fig. 4 shows a plurality of interfaces to NFs such as a “User Plane Function (UPF)_A 235” and an “AMF A 240 which may also be a Common Control Plane Network Function (Common CPNF, or CCNF)” – See [¶0067], also noting that “a User Plane (U-Plane or UP) may be a communication path for transmitting and/or receiving user data” and “a Control Plane (C-Plane or CP) may be a communication path for transmitting and/or receiving a control message” – See [¶0046]).
Therefore, Claim 10 is obvious over Chiba in view of Ravichandran1.
Regarding Claim 12, dependent from Claim 8, Chiba further teaches the method of Claim 8, wherein the applying the congestion control process for a plurality of interfaces of a network slice comprises applying the congestion control process in the plurality of network functions (e.g., “[t]he second congestion control . . . indicates control signal congestion control directed to parameters of S-NSSI. For example, in a case that control signal congestion with respect to S-NSSAI #A is detected on an NW and the NW recognizes it as a UE initiated session management request directed only to the parameters of the S-NSSAI #A, the NW may apply the second congestion control” – See [¶0151] and “the second congestion control may be congestion control to restrict all connections based on the S-NSSAI #A” – See [¶0152]; then, when “the UE_A 10 may include . . . identification information . . . in the PDU session establishment request message and transmit them to request establishment of a PDU session belonging to a network slice, to indicate a network slice to which the PDU session belongs requested by the UE_A 10, or to indicate a network slice to which the PDU session is to belong” – See [¶0291] “[t]he SMF A 230 within the core network_B 190 receives the PDU session establishment request message and performs the third condition determination . . . to determine whether the SMF A 230 accepts a request of the UE_A 10” – See [¶0295] and “the SMF A 230 transmits the PDU session establishment reject message to the AMF A 240 using the N11 interface, and the AMF A 240 that has received the PDU session establishment request message transmits the PDU session establishment reject message to the UE_A 10 using the N1 interface” – See [¶0314] indicating that “a request to establish a PDU session belonging to a network slice has been rejected or indicate a network slice that is not allowed to belong to the PDU session” – See [¶0317]; i.e., the second congestion control process is applied in the plurality of network functions, e.g. SMF and AMF).
Therefore, Claim 12 is obvious over Chiba in view of Ravichandran1.
Regarding Claims 14 and 15, as amended, Chiba teaches a network node for dynamic congestion control for network slices,
wherein the network node may comprise: at least one processor; at least one memory connected to the at least one processor and storing program code that is executed by the at least one processor to perform operations (e.g., Figs. 7 and 8 show an AMF and a SMF comprising network connection unit and the storage unit which are connected to a controller via a bus whereby, for an AMF, the storage unit stores a context and stores programs, data, and the like necessary for each operation of the node – See [¶¶0091,0094,0095])
further comprising execution of the steps of Claims 1 and 2, respectively, as amended, recited with the same language, only from the perspective of the network node. Because the network node determines what type of congestion control process is applied, as explained in Regarding Amended Claim 1, supra, Claims 14 and 15, as amended, are obvious over Chiba in view of Ravichandran1.
Regarding Amended Claim 18, Chiba also teaches a computer program comprising program code to be executed by processing circuitry of a network node (“A program running on an apparatus according to the present invention may serve as a program that controls a Central Processing Unit (CPU) and the like to cause a computer to operate in such a manner as to implement the functions of the above-described embodiment according to the present invention. Programs or information handled by the programs are temporarily stored in a volatile memory such as a Random Access Memory (RAM), a non-volatile memory such as a flash memory, a Hard Disk Drive (HDD), or another storage device system” – See [¶0370]), whereby execution of the program code causes the network node to perform operations comprising the steps of Amended Claim 1, which is obvious over Chiba in view of Ravichandran1.
Therefore, Amended Claim 18 is obvious over Chiba in view of Ravichandran1.
Regarding Claim 19, dependent from Amended Claim 18, it merely recites the steps of Amended Claim 18 wherein the network node is limited by the same features as recited in Claim 2. Because Claims 2 and 18, as amended, are obvious over Chiba in view of Ravichandran1, Claim 19 is also obvious over Chiba in view of Ravichandran1.
Regarding Amended Claim 20, Chiba teaches a computer program product comprising a non-transitory storage medium including program code to be executed by processing circuitry of a network node (“a program for implementing such functions of the embodiment according to the present invention may be recorded on a computer-readable recording medium,” i.e., a product – See [¶0371]) whereby execution of the program code causes the network node to perform operations comprising the steps of Amended Claim 1. Because Amended Claim 1 is obvious over Chiba in view of Ravichandran1, Amended Claim 20 is also obvious over Chiba in view of Ravichandran1.
In sum, Claims 1-2, 4, 7-10, 12, 14-15, 18-20, as amended, are rejected under 35 U.S.C. §103 as obvious over Chiba in view of Ravichandran1.
Claims 3, 5-6, and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Chiba in view of Ravichandran1 as applied to claims 1, 2, and 7 above, as amended, and further in view of Ravichandran et al., U.S. Patent Application No. 2020/0186411 (hereinafter Ravichandran2).
Regarding Claim 3, dependent from Claim 2, Chiba in view of Ravichandran1 further teaches wherein the cognitive layer comprises declarative and statistical knowledge encapsulated in the cognitive layer describing a plurality of congestion control processes (the “Performance monitoring module (PERF-MON)” of the Cognitive Function Orchestrator “collects relevant inputs about the status and performance of the NEs hosting the CFs” including statistical knowledge such as “analysis latency, latency to obtain the results, resource occupancy levels, etc.” – See Ravichandran1, III., ¶2:col2, at page 3, as well as declarative knowledge, e.g., the triggers for preventive/corrective actions include “[c]ongestion in network segment(s) hosting the CF; Change in a service or slice characteristics; Change in policy” – See id., IV.A., ¶1:col2, at page 4, and this knowledge can improve on Chiba’s slice level congestion control processes through techniques known in the art).
Ravichandran1 further teaches that “[t]he CF-O may obtain relevant performance metrics either directly from the NEs hosting the CFs, through the SO, I-SLO and/or from nodes delegated by them, depending on network topology and policy constraints” – See III.A.,¶2:col1, at page 3, and by reference information extracted from a plurality of metrics of an operating process (e.g., the Ayoubi reference discloses in Figs. 2-4, an improved MAPE model with a cognitive control loop in each of the FCAPS network management functions can retrieve data from and/or log created knowledge to the knowledge source). However, Chiba in view of Ravichandran1 does not explicitly teach wherein the statistical knowledge comprises information extracted from a plurality of metrics of an operating congestion control process from the plurality of congestion control processes.
Ravichandran2 teaches a communication network wherein “[e]ach of the E2E network slices 107 may be composed of one or more network slice subnets 106 across network segments 101 that may be 'stitched' together (i.e., communicatively interconnected to each other)” and “interconnections among network slice subnets 106 may be based on one or more standard protocols (e.g., transmission control protocol/Internet protocol (TCP/IP), general packet radio service tunneling protocol (GTP), etc.) and/or other proprietary protocols” – See [¶0028], and wherein a network node comprises at least one of a cognitive layer and a machine learning model (“cognitive functions (CFs) 108 in the communication network 100” – See [¶0021] and Fig. 1C; wherein “[o]ne or more CFs 108 may be employed at some of the nodes ( e.g., network elements 105, domain orchestration device 102, etc.) of the communication network 100 . . . the CFs 108 may be part of an existing node, or may be a plug-in on top of an existing node . . . may be custom built for a particular network slice subnet, or may be common across network slice subnets (i.e., may be slice agnostic)” and “the scope or coverage (for data collection and analysis) of the CFs 108 in the network subnets may be at node level” – See [¶0029]) and the communication network includes an end-to-end cognitive orchestration (E2ECO) device that “may perform orchestration of cognitive functions (CFs) 108 in the communication network 100” – See [¶0021] and Fig. 1C.
Ravichandran2 further teaches wherein the declarative knowledge comprises knowledge encapsulated in the cognitive layer describing a plurality of congestion control processes (“The FPPM 209 may . . . predict/detect fault or performance issue in one or more service(s)/slice(s) using pre-provisioned inputs (PPP-RULES) that may be adapted by the EAAM 205 (ADAPT-PPP-RULES)” – See [¶¶0088-89]; and “FPIRM 210 may . . . determine possible resolutions for the determined root cause using ADAPTED-RES-RULES” – See [¶¶0094-95] whereby the rules are declarative knowledge encapsulated in the cognitive layer associated with a plurality of congestion control processes as described in Figs. 4, 5A and 5B) and
wherein the statistical knowledge comprises information extracted from a plurality of metrics of an operating congestion control process from the plurality of congestion control processes (“The MONIM 207 may be responsible for collecting the fault, performance, and event data from various NEs, as well as actual SLA/KPI trends, resource occupancy trends, etc.” and “may store the collected information in the CDB 211” and “in conjunction with FIGS. 5A and 5B, the MONIM 207 may perform pre-processing of the data using preprovisioned rules, and then may passes the information to the FPPM 209” – See [¶0086], Fig. 2, and Figs. 5A/B describing fault/performance management processes which may be congestion control processes following NW slice activation).
Thus, Ravichandran2 and Chiba in view of Ravichandran1 each teaches end-to-end slice level performance management processes including congestion control using statistical and declarative knowledge collected by CFs at node/slice level. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the functions of extracting a plurality of metrics of an operating process and applying knowledge encapsulated in the cognitive layer describing a plurality of rules applicable to an operating process, such as Fault and Performance management at slice level, further managed in the E2ECO device/cognitive layer described by Ravichandran2, could have been substituted in for the recommendation from the network for one of a congestion control process and associated indication information, as taught by Chiba in view of Ravichandran1, because in both cases the objective of the managed functions is to provide for detecting and solving congestion/performance degradation at network slice level. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution through techniques known in the art. Finally, the substitution achieves the predictable result of maintaining SLAs through dynamic detection, analysis, and appropriate resolution of a performance degradation using rules and metrics at NF level collected by CFs as taught by Ravichandran2, while maintaining compliance with 3GPP TS 24.501 DNN/NSSAI related cause values, as taught by Chiba.
Therefore, Claim 3 is obvious over Chiba in view of Ravichandran1 and further in view of Ravichandran2.
Regarding Claim 5, depending from Claim 2, Chiba in view of Ravichandran1 discloses by reference to Ayouba that ML models obtained by unsupervised training are used in fault localization and prediction as traffic load and metrics prediction – See Table 1, Ayouba, at page 160.
Ravichandran2 further teaches wherein the obtaining comprises processing inputs to the cognitive layer to obtain an output from the cognitive layer comprising the recommendation for the congestion control process (“the control logic 400 may include the step of determining a fault or a performance, issue and one or more associated causes, related to a set of network slices in the communication network 100” and “determining one or more possible resolutions for the fault or the performance issue based on the one or more associated causes” – See [¶0104] by “aggregating a set of events or a set of performance trends over a pre-defined period of time, and determining the fault or the performance issue and the one or more associated causes by evaluating the set of events or the set of performance trends” i.e., by processing inputs – See [¶0108] and “identifying a possible resolution with a high suitability and at least one of a low impact on or a low conflict with the set of services, the set of other services, the set of network slices, or the set of other network slices,” i.e., obtaining an output recommendation – See [¶0109])
wherein the inputs comprise at least one key performance indicator, KPI, associated with the at least one condition related to the network slice (“upon activating the service or the network slice, determining a set of parameters to be monitored to compute the set of KPI's” – See [¶0105] and further “comparing a set of actual KPI's with a set of corresponding target KPI's for the set of services or the set of network slices” – See [¶0107], specifically ”collect data on the ACTUAL-SLA-KPIs (and associated trends) of various services and slices” to “detect fault/performance issue(s) in one or more services/ slices, using pre-provisioned inputs which were then adapted . . . based on learning” – See [¶¶0174-75], i.e., at least one KPI is associated with at least one condition/issue in a network slice)
Therefore, Claim 5 is obvious over Chiba in view of Ravichandran1 and further in view of Ravichandran2.
Regarding Claim 6, dependent from Amended Claim 1, Chiba in view of Ravichandran1 teaches wherein the applying the congestion control process in a protocol stack for the plurality of interfaces of the network slice, as explained in Regarding Amended Claim 1, supra. Chiba further teaches application of the congestion control process to a traffic flow (“an apparatus in the. . . network . . . may associate one or more pieces of identification information with the PDU session for management” which “may include . . . Traffic Flow Template (TFT)” and the “Network Slice Instance (NSI) identification information” – See [¶0031] and a “first timer may be configured to be associated with at least one of a congestion control unit which an NW applies” on “a per identification information basis,” i.e., may be based on the indicated traffic flow in the identification information).
Ravichandran2 further teaches application of the congestion control process to a traffic flow through the plurality of interfaces using a transport protocol (on the one hand, as shown in Fig. 1C, “[t]he interconnections among network slice subnets 106 may be based on one or more standard protocols (e.g., transmission control protocol/Internet protocol (TCP/IP), general packet radio service tunneling protocol (GTP), etc.) and/or other proprietary protocols” – See [¶0028], and, on the other hand, EXT interfaces are used for the orchestration of CFs to perform service/slice level performance at the cognitive layer, as shown in Fig. 1A, wherein “interface EXT1 may employ any standard protocol (e.g., http, REST, SNMP, etc.) . . . EXT2 interface (or each of the interfaces EXT21, EXT22 ... EXT2m) may employ any standard protocol (e.g., http, REST, SNMP, netconf/yang, etc.) . . . interface EXT3 (or each of the interfaces EXT31, EXT32 ... EXT3m) may employ any standard protocol (e.g., REST/RESTCONF, netconf/yang, etc.) . . . interfaces EXT41, EXT42 ... EXT4m may employ any standard protocol (e.g., SNMP, netconf/yang, openflow, REST etc.) or any other proprietary protocol,” i.e., using application level transport protocols – See [¶0025]).
Therefore, Claim 6 is obvious over Chiba in view of Ravichandran1 and further in view of Ravichandran2.
Regarding Claim 11, dependent from Claim 7, the method in Chiba in view of Ravichandran1 teaches normalizing and transforming the at least one condition into the at least one KPI (e.g., Chiba teaches a cause value representing the network congestion condition, as explained in Regarding Amended Claim 7, supra, and Ravichandran1 teaches that “root cause identification can be split into event log analysis, relevant KPI(s) trend analysis, resource occupancy trend analysis, reasoning (e.g., using decision tree or deep learning techniques)”– See III.B., ¶3:col.1, at page 3).
However, Chiba in view of Ravichandran1 does not teach the mapping between the KPI trend analysis and the condition.
Ravichandran2 further teaches monitoring the at least one condition related to the network slice (“high-level intent (HLI)” may drive “operating the network at high reliability (say, five 9's) while adhering to service level agreement (SLA) or key performance indicator (KPI) values of the service or the slice” – See [¶0035] and requires “parameters and events to monitor for a slice along with conditions (active slices, geo location, class of users, etc.)” which “may be provisioned at the time of slice creation[/instantiation]” – See [¶¶0047-48] and further “extract[ing] relevant information from the information reported by the CFs and various NEs in the network (including alarms, events, service/slice SLA/KPI trends, etc.)” – See [¶0174]),
wherein the extracting comprises normalizing and transforming the at least one condition into the at least one KPI (“the PPM 201 may be responsible for determining the parameters to be monitored (MO-PAR) so as to determine the performance levels of the nodes, services and slices, and to determine conformance to the HLI” – See [¶0062] and Fig. 2, including “mapping of events/parameters to be monitored and analyzed to the corresponding cognitive analysis type required” e.g., “latency KPI may require regression along with deep learning, congestion monitoring may require decision tree analysis” – See [¶0051], and “may process the current value of HLI . . . for triggering preventive actions” based on, e.g., “KPI thresholds (target vs actual)” – See [¶0114], therefore normalizing and transforming the current condition into at least one KPI).
Therefore, Claim 11 is obvious over Chiba in view of Ravichandran1 and further in view of Ravichandran2.
In sum, Claims 3, 5-6, and 11 are rejected under 35 U.S.C. §103 as obvious over Chiba in view of Ravichandran1 and further in view of Ravichandran2.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Cheng et al., U.S. Patent Application No. 2016/0044530 discloses a congestion management method with congestion mitigation process;
Seetharaman et al., U.S. Patent Application No. 2022/0021590 discloses method and apparatus for determining a network slice template hierarchy based on the updated service requirement set;
Sciancalepore et al., U.S. Patent Application No. 2020/0059521 discloses slice management in 5G IoT;
Rath et al., U.S. Patent Application No. 2020/0084279 discloses enabling network aware applications and applications aware networks by a sense analyze decide respond (SADR) framework using machine learning techniques to analyze network state;
Dao et al., U.S. Patent Application No. 2021/0235288 discloses policy optimization in a communication network using network data analytics (NWDA) function on network traffic to obtain network performance measurement data, receive the measurement data from the network elements, and transmit a policy input based on the received measurement data;
Lau et al., U.S. Patent Application No. 2019/0168696 discloses dynamic wireless configuration of a vehicle via a network slice to facilitate improved subscriber experiences;
Sudarsan et al., U.S. Patent Application No. 2020/0267596 disclosing congestion control in wireless network and performing one or more action to mitigate or remove the cause of the congestion or degradation;
Kucera et al., U.S. Patent Application No. 2021/0084523 disclosing controlling transmission of a data flow in a communication network, comprising defining a quality of service setting for at least one data flow and associating at least one network slice to the at least one data flow to be transmitted;
3GPP TS 23.502 V16.6.0 (2020-09),”Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 16)”;
3GPP TS 28.531 V16.7.0 (2020-09), “Technical Specification Group Services and System Aspects; Management and orchestration; Provisioning; (Release 16)”;
3GPP TS 24.501 V16.6.0 (2020-09), “Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3; (Release 16)”;
3GPP TS 23.501 V16.6.0 (2020-09), “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16)”;
3GPP TS 38.300 V16.3.0 (2020-09)” Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Release 16);
Vasilakos et al., “Integrated Methodology to Cognitive Network & Slice Management in Virtualized 5G Networks,” May 2020, available at https://arxiv.org/abs/2005.04830;
Bin et al., “Machine Learning for Network Slicing Resource Management: A Comprehensive Survey,” arXiv, January 20, 2020, to appear in ZTE Communications, 2020, available at https://arxiv.org/pdf/2001.07974;
de Foy et al., “Network Slicing - 3GPP Use Case: draft-defoy-netslices-3gpp-network-slicing-02,” Internet-Draft, October 17, 2017.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LUCIA GHEORGHE GRADINARIU whose telephone number is (571)272-1377. The examiner can normally be reached Monday-Friday 9:00am - 5:00pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Joseph AVELLINO can be reached at (571)272-3905. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/L.G.G./Examiner, Art Unit 2478
/JOSEPH E AVELLINO/Supervisory Patent Examiner, Art Unit 2478
1 See 3GPP TS 24.501 V16.6.0 (2020-09), “Technical Specification Group Core Network and Terminals;
Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3; (Release 16)” (hereinafter 3GPP TS 24.501) teaching in § 5.4.5.2.4 that “if the Request type IE is set to ‘initial request’ or ‘existing PDU session’” and “ S-NSSAI only based congestion control is activated for the S-NSSAI” then “the AMF shall send back to the UE the 5GSM message which was not forwarded, a back-off timer value and 5GMM cause #69 ‘insufficient resources for specific slice’” – See 3GPP TS 24.501:208-209
2 A person of ordinary skills in the art would look at 3GPP TS 28.530 V16.3.0 (2020-09), “Technical Specification Group Services and System Aspects; Management and orchestration; Concepts, use cases and requirements (Release 16)” (hereinafter 3GPP TS 28.530) for details of using network slicing in response to request for a service – See, e.g., Figure 4.1.3.1, Figure 4.1.6.1 and Figure 4.4.1.1.
3 A person of ordinary skills in the art would also consult 3GPP TS 23.501 V16.6.0 (2020-09), “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16)” (hereinafter 3GPP TS 23.501), referenced by Chiba, e.g., Figure 4.2.3-1.
