Patent Description:
Fifth-generation (<NUM>) mobile and wireless networks will provide enhanced mobile broadband communications and are intended to deliver a wider range of services and applications as compared to all prior generation mobile and wireless networks. Compared to prior generations of mobile and wireless networks, the <NUM> architecture is service based, meaning that wherever suitable, architecture elements are defined as network functions that offer their services to other network functions via common framework interfaces. In order to support this wide range of services and network functions across an ever-growing base of user equipment (UE), <NUM> networks incorporate the network slicing concept utilized in previous generation architectures.

Within the scope of the <NUM> mobile and wireless network architecture, a network slice comprises a set of defined features and functionalities that together form a complete Public Land Mobile Network (PLMN) for providing services to UEs. This network slicing permits the controlled composition of a PLMN with the specific network functions and provided services that are required for a specific usage scenario. In other words, network slicing enables a <NUM> network operator to deploy multiple, independent PLMNs where each is customized by instantiating only those features, capabilities, and services required to satisfy a given subset of the UEs or a related business customer needs.

In particular, network slicing is expected to play a critical role in <NUM> networks because of the multitude of use cases and new services <NUM> is capable of supporting. Network service provisioning through network slices is typically initiated when an enterprise requests network slices when registering with an Access and Mobility Management Function (AMF)/Mobility Management Entity (MME) for a <NUM> network. At the time of registration, the enterprise will typically ask the AMF/MME for characteristics of network slices, such as slice bandwidth, slice latency, processing power, and slice resiliency associated with the network slices. These network slice characteristics can be used in ensuring that assigned network slices are capable of actually provisioning specific services, e.g. based on requirements of the services, to the enterprise.

<CIT> is directed to a method for resolving an identifier of a path between a first user plan entity (UPE) and a second UPE. The method includes receiving a translation request comprising a network slice selection assistance information (S-NSSAI), a first transport interface address, a second transport interface address, and one or more quality of service (QoS) parameters associated with the transport path between the first UPE and the second UPE; selecting the identifier of the transport path from a translation table in accordance with the S- NSSAI, the first transport interface address and the second transport interface address; and sending a translation response comprising an indicator of the identifier. The invention is directed to a method per claim <NUM>, corresponding non-transitory computer-readable storage medium per claim <NUM> as well as corresponding one or more network nodes claim <NUM>. Dependent claims provide further embodiments of the invention.

In order to describe the manner in which the above-recited and other advantages and features of the disclosure can be obtained, a more particular description of the principles briefly described above will be rendered by reference to specific aspects thereof which are illustrated in the appended drawings. Understanding that these drawings depict only exemplary aspects of the disclosure and are not therefore to be considered to be limiting of its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which:.

Various aspects of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. Thus, the following description and drawings are illustrative and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding of the disclosure. However, in certain instances, well-known or conventional details are not described in order to avoid obscuring the description. References to one or an aspect in the present disclosure can be references to the same aspect or any aspect; and, such references mean at least one of the aspects.

Reference to "one aspect" or "an aspect" means that a particular feature, structure, or characteristic described in connection with the aspect is included in at least one aspect of the disclosure. The appearances of the phrase "in one aspect" in various places in the specification are not necessarily all referring to the same aspect, nor are separate or alternative aspects mutually exclusive of other aspects. Moreover, various features are described which may be exhibited by some aspects and not by others.

Likewise, the disclosure is not limited to various aspects given in this specification.

Without intent to limit the scope of the disclosure, examples of instruments, apparatus, methods and their related results according to the aspects of the present disclosure are given below.

A method can include receiving an attach request message from a subscribing gNodeB network node. Further, the method can include receiving traffic engineering data associated with one or more User Plane (UP) entities for selecting a least congested network path. The subscribing gNodeB network node can be anchoring to a first UP entity of the one or more UP entities based on the traffic engineering data. Specifically, the traffic engineering data comprises a list of UPs along an optimal path with congestion below a determined threshold, and wherein the anchoring the first UP entity is based on the list of UPs.

A system can include one or more processors and at least one computer-readable storage medium storing instructions which, when executed by the one or more processors, cause the one or more processors to receive an attach request message from a subscribing gNodeB network node. The instructions can cause the one or more processors to receive traffic engineering data associated with one or more User Plane (UP) entities for selecting a least congested network path. The instructions can also cause the one or more processors to anchor the subscribing gNodeB network node to a first UP entity of the one or more UP entities based on the traffic engineering data. Specifically, the traffic engineering data comprises a list of UPs along an optimal path with congestion below a determined threshold and wherein the anchoring of the first UP entity is based on the list of UPs.

A non-transitory computer-readable storage medium having stored therein instructions which, when executed by a processor, causes the processor to receive an attach request message from a subscribing gNodeB network node. The instructions can cause the one or more processors to receive traffic engineering data associated with one or more User Plane (UP) entities for selecting a least congested network path. The instructions can also cause the one or more processors to anchor the subscribing gNodeB network node to a first UP entity of the one or more UP entities based on the traffic engineering data. Specifically, the traffic engineering data comprises a list of UPs along an optimal path with congestion below a determined threshold and wherein the anchoring the first UP entity is based on the list of UPs. The instructions can also cause the processor to subscribe to receive the traffic engineering data to receive updates regarding a first set of interfaces between a radio access network (RAN) and the one or more UP entities, a second set of interfaces between the one or more UP entities and a Data Network (DN) and/or a third set of interfaces between the one or more UP entities and one or more respective branching User Plane Functions (UPF).

With increased <NUM> UE cases of eMBB (enhanced mobile broadband), VR/AR, <NUM>/HD video, and other high bandwidth cases getting deployed, the backhaul network, specifically links associated with the User Plane Function (UPF), will likely succumb to congestion. Given the small cells of <NUM> for high bandwidth use cases, this may result in a complex distributed congestion problem in the network, which may pose threat to SLAs (service level agreements) around low latency as well as for high speed UEs. 3GPP (3rd Gen Partnership Project) has so far not considered the traffic engineering aspects as part of the <NUM> architecture.

There therefore exist needs for systems and methods for solving complex distributed congestion in a <NUM>, or LTE Control Plane and User Plane Separation (CUPS), network by using traffic engineering data to redirect sessions and for policy planning.

The disclosed technology addresses the need in the art for solving complex distributed congestion in an IP network, such as a <NUM> or LTE CUPS network, by using traffic engineering data to redirect sessions. Additionally, the disclosed technology addresses the need in the art for monitoring and collecting data associated with a traffic engineering state of the IP network, specifically a IP network backhaul, and using the data to correct and provide alternate, non-congested paths, and thus elevating the UE quality of experience. The present technology involves systems, methods, and computer-readable media anchoring a network node to a User Plane (UP) entity based on traffic engineering data. Additionally, the present technology involves systems, methods, and computer-readable media for subscribing to traffic engineering data associated with requested parameters to push particular policies and/or select alternate application functions to correct congestion.

A description of network environments and architectures for network data access and services, as illustrated in <FIG>, <FIG>, and <FIG> are first disclosed herein. A discussion of systems, methods, and computer-readable medium for federating enterprises and SaaS providers using network slices, as shown in <FIG>, will then follow. The discussion then concludes with a brief description of example devices, as illustrated in <FIG>. These variations shall be described herein as the various aspects are set forth. The disclosure now turns to <FIG>.

<FIG> illustrates a diagram of an example cloud computing architecture <NUM>. The architecture can include a cloud <NUM>. The cloud <NUM> can be used to form part of a TCP connection or otherwise be accessed through the TCP connection. Specifically, the cloud <NUM> can include an initiator or a receiver of a TCP connection and be utilized by the initiator or the receiver to transmit and/or receive data through the TCP connection. The cloud <NUM> can include one or more private clouds, public clouds, and/or hybrid clouds. Moreover, the cloud <NUM> can include cloud elements <NUM>-<NUM>. The cloud elements <NUM>-<NUM> can include, for example, servers <NUM>, virtual machines (VMs) <NUM>, one or more software platforms <NUM>, applications or services <NUM>, software containers <NUM>, and infrastructure nodes <NUM>. The infrastructure nodes <NUM> can include various types of nodes, such as compute nodes, storage nodes, network nodes, management systems, etc..

The cloud <NUM> can be used to provide various cloud computing services via the cloud elements <NUM>-<NUM>, such as SaaSs (e.g., collaboration services, email services, enterprise resource planning services, content services, communication services, etc.), infrastructure as a service (IaaS) (e.g., security services, networking services, systems management services, etc.), platform as a service (PaaS) (e.g., web services, streaming services, application development services, etc.), and other types of services such as desktop as a service (DaaS), information technology management as a service (ITaaS), managed software as a service (MSaaS), mobile backend as a service (MBaaS), etc..

The client endpoints <NUM> can connect with the cloud <NUM> to obtain one or more specific services from the cloud <NUM>. The client endpoints <NUM> can communicate with elements <NUM>-<NUM> via one or more public networks (e.g., Internet), private networks, and/or hybrid networks (e.g., virtual private network). The client endpoints <NUM> can include any device with networking capabilities, such as a laptop computer, a tablet computer, a server, a desktop computer, a smartphone, a network device (e.g., an access point, a router, a switch, etc.), a smart television, a smart car, a sensor, a GPS device, a game system, a smart wearable object (e.g., smartwatch, etc.), a consumer object (e.g., Internet refrigerator, smart lighting system, etc.), a city or transportation system (e.g., traffic control, toll collection system, etc.), an internet of things (IoT) device, a camera, a network printer, a transportation system (e.g., airplane, train, motorcycle, boat, etc.), or any smart or connected object (e.g., smart home, smart building, smart retail, smart glasses, etc.), and so forth.

<FIG> illustrates a diagram of an example fog computing architecture <NUM>. The fog computing architecture can be used to form part of a TCP connection or otherwise be accessed through the TCP connection. Specifically, the fog computing architecture can include an initiator or a receiver of a TCP connection and be utilized by the initiator or the receiver to transmit and/or receive data through the TCP connection. The fog computing architecture <NUM> can include the cloud layer <NUM>, which includes the cloud <NUM> and any other cloud system or environment, and the fog layer <NUM>, which includes fog nodes <NUM>. The client endpoints <NUM> can communicate with the cloud layer <NUM> and/or the fog layer <NUM>. The architecture <NUM> can include one or more communication links <NUM> between the cloud layer <NUM>, the fog layer <NUM>, and the client endpoints <NUM>. Communications can flow up to the cloud layer <NUM> and/or down to the client endpoints <NUM>.

The fog layer <NUM> or "the fog" provides the computation, storage and networking capabilities of traditional cloud networks, but closer to the endpoints. The fog can thus extend the cloud <NUM> to be closer to the client endpoints <NUM>. The fog nodes <NUM> can be the physical implementation of fog networks. Moreover, the fog nodes <NUM> can provide local or regional services and/or connectivity to the client endpoints <NUM>. As a result, traffic and/or data can be offloaded from the cloud <NUM> to the fog layer <NUM> (e.g., via fog nodes <NUM>). The fog layer <NUM> can thus provide faster services and/or connectivity to the client endpoints <NUM>, with lower latency, as well as other advantages such as security benefits from keeping the data inside the local or regional network(s).

The fog nodes <NUM> can include any networked computing devices, such as servers, switches, routers, controllers, cameras, access points, gateways, etc. Moreover, the fog nodes <NUM> can be deployed anywhere with a network connection, such as a factory floor, a power pole, alongside a railway track, in a vehicle, on an oil rig, in an airport, on an aircraft, in a shopping center, in a hospital, in a park, in a parking garage, in a library, etc..

In some configurations, one or more fog nodes <NUM> can be deployed within fog instances <NUM>, <NUM>. The fog instances <NUM>, <NUM> can be local or regional clouds or networks. For example, the fog instances <NUM>, <NUM> can be a regional cloud or data center, a local area network, a network of fog nodes <NUM>, etc. In some configurations, one or more fog nodes <NUM> can be deployed within a network, or as standalone or individual nodes, for example. Moreover, one or more of the fog nodes <NUM> can be interconnected with each other via links <NUM> in various topologies, including star, ring, mesh or hierarchical arrangements, for example.

In some cases, one or more fog nodes <NUM> can be mobile fog nodes. The mobile fog nodes can move to different geographic locations, logical locations or networks, and/or fog instances while maintaining connectivity with the cloud layer <NUM> and/or the endpoints <NUM>. For example, a particular fog node can be placed in a vehicle, such as an aircraft or train, which can travel from one geographic location and/or logical location to a different geographic location and/or logical location. In this example, the particular fog node may connect to a particular physical and/or logical connection point with the cloud <NUM> while located at the starting location and switch to a different physical and/or logical connection point with the cloud <NUM> while located at the destination location. The particular fog node can thus move within particular clouds and/or fog instances and, therefore, serve endpoints from different locations at different times.

<FIG> depicts an exemplary schematic representation of a network environment <NUM> in which network slicing has been implemented, and in which one or more aspects of the present disclosure may operate. As illustrated, network environment <NUM> is divided into four domains, each of which will be explained in greater depth below; a User Equipment (UE) domain <NUM>, e.g. of one or more enterprise, in which a plurality of user cellphones or other connected devices <NUM> reside; a Radio Access Network (RAN) domain <NUM>, in which a plurality of radio cells, base stations, towers, or other radio infrastructure <NUM> resides; a Core Network <NUM>, in which a plurality of Network Functions (NFs) <NUM>, <NUM>,. , n reside; and a Data Network <NUM>, in which one or more data communication networks such as the Internet <NUM> reside. Additionally, the Data Network <NUM> can support SaaS providers configured to provide SaaSs to enterprises, e.g. to users in the UE domain <NUM>.

Core Network <NUM> contains a plurality of Network Functions (NFs), shown here as NF <NUM>, NF <NUM>. In some aspects, core network <NUM> is a <NUM> core network (5GC) in accordance with one or more accepted 5GC architectures or designs. In some aspects, core network <NUM> is an Evolved Packet Core (EPC) network, which combines aspects of the 5GC with existing <NUM> networks. Regardless of the particular design of core network <NUM>, the plurality of NFs typically execute in a control plane of core network <NUM>, providing a service based architecture in which a given NF allows any other authorized NFs to access its services. For example, a Session Management Function (SMF) controls session establishment, modification, release, etc., and in the course of doing so, provides other NFs with access to these constituent SMF services.

In some aspects, the plurality of NFs of core network <NUM> can include one or more Access and Mobility Management Functions (AMF; typically used when core network <NUM> is a 5GC network) and Mobility Management Entities (MME; typically used when core network <NUM> is an EPC network), collectively referred to herein as an AMF/MME for purposes of simplicity and clarity. In some aspects, an AMF/MME can be common to or otherwise shared by multiple slices of the plurality of network slices <NUM>, and in some aspects an AMF/MME can be unique to a single one of the plurality of network slices <NUM>.

The same is true of the remaining NFs of core network <NUM>, which can be shared amongst one or more network slices or provided as a unique instance specific to a single one of the plurality of network slices <NUM>. In addition to NFs comprising an AMF/MME as discussed above, the plurality of NFs of the core network <NUM> can additionally include one or more of the following: User Plane Functions (UPFs); Policy Control Functions (PCFs); Authentication Server Functions (AUSFs); Unified Data Management functions (UDMs); Application Functions (AFs); Network Exposure Functions (NEFs); NF Repository Functions (NRFs); and Network Slice Selection Functions (NSSFs). Various other NFs can be provided without departing from the scope of the present disclosure, as would be appreciated by one of ordinary skill in the art.

Across these four domains of the network environment <NUM>, an overall operator network domain <NUM> is defined. The operator network domain <NUM> is in some aspects a Public Land Mobile Network (PLMN), and can be thought of as the carrier or business entity that provides cellular service to the end users in UE domain <NUM>. Within the operator network domain <NUM>, a plurality of network slices <NUM> are created, defined, or otherwise provisioned in order to deliver a desired set of defined features and functionalities, e.g. SaaSs, for a certain use case or corresponding to other requirements or specifications. Note that network slicing for the plurality of network slices <NUM> is implemented in end-to-end fashion, spanning multiple disparate technical and administrative domains, including management and orchestration planes (not shown). In other words, network slicing is performed from at least the enterprise or subscriber edge at UE domain <NUM>, through the Radio Access Network (RAN) <NUM>, through the <NUM> access edge and the <NUM> core network <NUM>, and to the data network <NUM>. Moreover, note that this network slicing may span multiple different <NUM> providers.

For example, as shown here, the plurality of network slices <NUM> include Slice <NUM>, which corresponds to smartphone subscribers of the <NUM> provider who also operates network domain, and Slice <NUM>, which corresponds to smartphone subscribers of a virtual <NUM> provider leasing capacity from the actual operator of network domain <NUM>. Also shown is Slice <NUM>, which can be provided for a fleet of connected vehicles, and Slice <NUM>, which can be provided for an IoT goods or container tracking system across a factory network or supply chain. Note that these network slices <NUM> are provided for purposes of illustration, and in accordance with the present disclosure, and the operator network domain <NUM> can implement any number of network slices as needed, and can implement these network slices for purposes, use cases, or subsets of users and user equipment in addition to those listed above. Specifically, the operator network domain <NUM> can implement any number of network slices for provisioning SaaSs from SaaS providers to one or more enterprises.

<NUM> mobile and wireless networks will provide enhanced mobile broadband communications and are intended to deliver a wider range of services and applications as compared to all prior generation mobile and wireless networks. Compared to prior generations of mobile and wireless networks, the <NUM> architecture is service based, meaning that wherever suitable, architecture elements are defined as network functions that offer their services to other network functions via common framework interfaces. In order to support this wide range of services and network functions across an ever-growing base of user equipment (UE), <NUM> networks incorporate the network slicing concept utilized in previous generation architectures.

Within the scope of the <NUM> mobile and wireless network architecture, providing new functionalities of core functions at the core network <NUM> and maintaining uncongested data rates at the <NUM> UE from a User Plane Function (UPF) are important for successfully deploying <NUM> SA (Stand-Alone) with network operators. When more network operators move to the <NUM> SA architecture, the backhaul network may succumb to congestion. This is especially the case given the small cells of <NUM> for high bandwidth cases, and that more and more <NUM> UE use cases of eMBB (enhanced mobile broadband), VR/AR, <NUM>/HD video, and other high bandwidth cases are getting deployed.

In addition, in LTE Control Plane and User Plane Separation (CUPS), similar issues of congestion may occur. For example, in both <NUM> and LTE CUPS deployment, communication between SMF (session management function)/CP(control plane) and UPF (user plane function) happens using N4/Sx protocol. However, in selecting a UPF/UP for a subscriber's session to be anchored to, the SMF does not consider the network KPIs of the path from gNB/eNB to UPF/UP and UPF/UP out to Internet. Packet core backhaul network between gNB/eNB and UPF is likely to get congested given the multiplication effect in backhaul traffic brought in by <NUM> data rates.

As such, it is desirable for traffic engineering data to be monitored and collected and provide a function for auto-correction of back-haul network congestion, specifically interfaces associated with the UPF, which are likely to get congested given the multiplication effect in backhaul traffic brought in by <NUM> data rates.

<FIG> depicts a schematic representation of an example network environment <NUM> having a selected User Plane Function (UPF) link that is congested. A subscriber, such as a UE <NUM>, may request Session Management Function/Control Plane (SMF/CP), through a base station, such as a gNodeB (gNB) <NUM>, to anchor to a User Plane Function (UPF) for a session. SMF/CP has an option to select a UPF in a UPF group, such as between UPF1 <NUM> and UPF2 <NUM>, using a UPF selection algorithm that is based on a UPF selection algorithm <NUM> that may consider session load of each UPF, DNS queries, and other parameters.

However, in order to take into consideration congestion in a packet core backhaul network, such as between gNB/eNB and UPF, network KPIs can be monitored and can be provided to the SMF/CP <NUM> in the form of lists of UPFs that are along an optimal path with low congestion. The SMF/CP <NUM> can then anchor the session to one of the UPFs from the provided list. As shown in <FIG>, SMF/CP <NUM> may learn about the congestion at UPF1 <NUM> and then re-anchor the session on UPF2 <NUM>. The optimal path may change in real-time for a next subscriber session based on where the subscriber is located. As such, each subscriber will be anchored on a path where it can receive the best quality of experience.

<FIG> depicts a schematic representation of a first example network environment 400A having RAN-UPF link that is congested. The link between the RAN domain <NUM> and a UPF, such as the UPF1 <NUM> as shown in <FIG>, may be referred to as an N3 link <NUM>. <FIG> depicts a schematic representation of a second example network environment 400B having a UPF-Internet link that is congested. The link between a UPF, such as the UPF <NUM><NUM> as shown in <FIG>, and the data network <NUM> may be referred to as an N6 link <NUM>. <FIG> depicts a schematic representation of a third example network environment 400C having a Branching UPF-UPF link that is congested. The link between a UPF, such as the UPF1 <NUM> as shown in <FIG>, and a branching UPF <NUM> may be referred to as an N9 link.

Selecting a UPF based on UE-location or 3GPP mechanism and load balance between UPFs in a UP group does not take into consideration congestion on any given UPF. Therefore, by receiving traffic engineering data, the SMF <NUM> or Network Repository Function <NUM> (see <FIG>) (SMF/NRF <NUM>) is able to take congestion into consideration as a factor for UPF selection.

<FIG> illustrates an example flow diagram <NUM> of a UE session establishment with a UPF based on traffic engineering information. When there is congestion, such as N3 link congestion <NUM> or N6 link congestion <NUM>, associated with a UPF, such as either with UPF1 <NUM> or UPF2 <NUM>, such traffic engineering data is monitored <NUM>, <NUM> by a Traffic Engineering Awareness Function (TEAF) <NUM>. The SMF/NRF <NUM>, may receive and/or store (<NUM>) the traffic engineering information for each UPF. For example, the traffic engineering data may include network KPIs, congestion states for each link, and/or a list of UPFs that are along an optimal path with low congestion.

The UE <NUM> may send a request (<NUM>) to the AMF <NUM> for Protocol Data Unit (PDU) session establishment. The AMF <NUM> may receive the request and forward (<NUM>) a request to create a session, along with UE location information, to the SMF/NRF <NUM>. The SMF/NRF <NUM> may retrieve (<NUM>) subscription updates and send a response (<NUM>) back to AMF <NUM>. The SMF/NRF <NUM> may select (<NUM>) a Policy Control Function (PCF) <NUM> and based on the selection, establish (<NUM>) a policy association with the PCF <NUM>. The PCF <NUM> is a control plane network function (NF) that may provide policy rules for control plane functions and may further provide real-time management of subscribers, applications, and network resources. The SMF/NRF <NUM> may select (<NUM>) a UPF, for example, the SMF/NRF <NUM> select UPF2 <NUM> because UPF1 <NUM> is congested. The SMF/NRF <NUM> may establish (<NUM>) a N4 link with UPF2 <NUM> and relay (<NUM>) information to AMF <NUM> which then sends (<NUM>) establish and modification procedures to the UE <NUM>.

<FIG> illustrates a schematic representation of an example network environment 600A having a TEAF <NUM> that monitors and collects traffic engineering information at the N3, N6, and N9 links. The N3 link <NUM> may comprise different routes and associated routers, such as Router <NUM>402A (on N3 route-<NUM>) and Router <NUM>402B (on N3 route-<NUM>). The TEAF <NUM> may monitor and collect traffic engineering data from the Router <NUM>402A and Router <NUM>402B and detect that Router <NUM>402B has succumbed to congestion. TEAF <NUM> may further program the network to re-route the traffic via Router <NUM>402A to ease congestion at Router <NUM>402B.

TEAF <NUM> may monitor and collect traffic engineering information pertaining to links including the N3, N6, and N9 links, while other Network Functions (NF) may subscribe to particular Traffic Engineering Awareness Data (TEAD) associated with the links. <FIG> illustrates a schematic representation of an example network environment 600B having various NFs subscribe for traffic engineering data from TEAF <NUM>. For example, a Policy Control Function (PCF) <NUM> may use traffic engineering data to known to impact certain subscribers or UPF nodes, via its Service Based Interface (SBI). The SBI interface serves as an interface that allows for two programs to communicate. The PCF <NUM> may push policy in terms of lowering APNMBR bit rate of a subscriber to ease congestion. The PCF <NUM> may also request the TEAF <NUM> to auto-correct the network for certain APN locations to relieve congestion at the N3 link <NUM>, the N6 link <NUM>, or the N9 link <NUM> (see <FIG>).

Access and Mobility Management Function (AMF) <NUM> may subscribe to traffic engineering data at certain locations from TEAF <NUM> and may select an alternate Session Management Function (SMF) <NUM> based on a traffic engineering state of the network.

The UPF <NUM> may interface with TEAF <NUM> or Network Repository Function (NRF) <NUM> over its SBI interface to receive its traffic engineering data and may perform self-overload control, such as by rejecting new sessions or dropping lower priority sessions. The NRF <NUM> may use traffic engineering data from all UPFs <NUM> and sort the UPFs based on load/overload in the network. The NRF <NUM> may interface with TEAF <NUM> to receive traffic engineering data for the UPFs, which can be used to help the SMF <NUM> in UPF selection.

The SMF <NUM> may use traffic engineering data based on Access Point Name (APN) and location. The APN may identify the part of the network where a user session is established. The SMF <NUM> may receive traffic engineering data regarding the UPF <NUM> and use such data for selecting an alternative group of UPs when the NRF <NUM> is not in use. The SMF <NUM> can also program traffic shaping algorithms, such as Cisco Ultra Traffic Optimization (CUTO) or Control Plane and User Plane Separation (CUPS), on the UPF <NUM> based on traffic engineering data so that the UPF <NUM> shapes traffic at lower rates and hence lowering congestion.

Network Exposure Function (NEF) <NUM> may orchestrate network slicing based on the traffic engineering data. Orchestration services such as enterprise onboarding, may use the traffic engineering data in algorithms for determining which routers have reachability to which enterprise and hence choose the appropriate router for onboarding the new enterprise, such as by configuring virtual routing and forwarding for the enterprise on these routers. As such, the NEF <NUM> and associated orchestration system may bring up more virtual routers and paths in the network for additional capacity.

<FIG> illustrates an example flow diagram <NUM> of a TEAF Service Consumer <NUM> subscribing for traffic engineering data, requesting an auto-correction, and requesting specific traffic engineering data. The TEAF Service Consumer <NUM> may be any AF that can receive traffic engineering data and interface with the TEAF <NUM>. For example, the TEAF Service Consumer <NUM> may subscribe (<NUM>) or unsubscribe (with receipt <NUM>) for traffic engineering data that the TEAF <NUM> will notify (<NUM>) back to the consumers when applicable. The SBI interface procedures for the TEAF <NUM> may allow the TEAF Service Consumer <NUM> to request (<NUM>) for traffic engineering data that the TEAF <NUM> will respond (<NUM>) to the consumers based on the parameters set in the subscription. The SBI interface may also provide functionality for <NUM> System's Network Functions (NFs) to program and request (<NUM>) the TEAF <NUM> to perform (<NUM>) auto-correction on the network. The above procedures may be invoked via the NEF <NUM>. In other words, the TEAF <NUM> may extend its services to the other NFs in <NUM> via SBI interfaces that were defined to subscribe to traffic engineering data for certain locations or certain APN or UPF-list or combinations of the same. Locations may be TAC/PRA/RAC/eNB etc..

<FIG> illustrates an example method for anchoring a subscribing network node to a User Plane (UP) entity based on traffic engineering data. Although the example method <NUM> depicts a particular sequence of operations, the sequence may be altered without departing from the scope of the present disclosure. For example, some of the operations depicted may be performed in parallel or in a different sequence that does not materially affect the function of the method <NUM>. In other examples, different components of an example device or system that implements the method <NUM> may perform functions at substantially the same time or in a specific sequence.

According to some aspects, the method includes receiving an attach request message from a subscribing gNodeB network node at step <NUM>. For example, the Session Management Function (SMF) or a Control Plane (CP) (SMF/CP <NUM>) of a <NUM>-compatible IP network illustrated in <FIG> may receive an attach request message from a subscribing gNodeB network node.

According to some aspects, the method includes receiving traffic engineering data associated with one or more User Plane entities for selecting a least congested network path at step <NUM>. For example, the SMF/CP <NUM> of a <NUM>-compatible IP network illustrated in <FIG> can receive traffic engineering data associated with one or more User Plane entities to select a least congested network path. In some aspects, the traffic engineering data comprises a list of UPs along an optimal path with congestion below a determined threshold. In some aspects, the traffic engineering data comprises a congestion state in integer form for each of the one or more interfaces. For example, the congestion state may contain the following information:.

According to some aspects, the method includes anchoring the subscribing gNodeB network node to a first User Plane entity of the one or more UP entities based on the traffic engineering data at step <NUM>. For example, the SMF/CP <NUM> of a <NUM>-compatible IP network illustrated in <FIG> may anchor the subscribing gNodeB to a first User Plane entity of the one or more UP entities based on the traffic engineering data. In some aspects, anchoring the first UP entity is based on the list of UPs.

According to some aspects, the method includes receiving, from a network element, a subscription request for traffic engineering data, wherein the subscription request comprises parameters for responding and re-routing receive the traffic engineering data at step <NUM>. For example, the TEAF <NUM>, illustrated in <FIG> and <FIG> may receive, from a network element, a subscription request for traffic engineering data, wherein the subscription request comprises parameters for responding and re-routing the traffic engineering data. The TEAF Service Consumer <NUM> may receive updates regarding at least one of a first set of interfaces between a radio access network and the one or more UP entities, a second set of interfaces between the one or more UP entities and a Data Network, and/or a third set of interfaces between the one or more UP entities and one or more respective branching User Plane Functions. According to some aspects, the network element is the SMF/CP <NUM> of a <NUM>-compatible IP network illustrated in <FIG>.

According to some aspects, the method includes monitoring and collecting traffic engineering data of a plurality of interfaces of the <NUM>-compatible IP network at step <NUM>. For example, the TEAF illustrated in <FIG> may monitor and collect traffic engineering data of a plurality of interfaces of the <NUM>-compatible IP network.

According to some aspects, the method includes sending, to the network element, a response comprising some of the collected traffic engineering data associated with the requested parameters at step <NUM>. For example, the TEAF illustrated in <FIG> may send, to the network element, a response comprising some of the collected traffic engineering data associated with the requested parameters.

According to some aspects, the method includes re-routing traffic in the <NUM> compatible IP network based on the parameters via Software-Defined Networking (SDN) at step <NUM>. For example, the TEAF <NUM> illustrated in <FIG> may re-route traffic in the <NUM> compatible IP network based on the parameters set via Software-Defined Networking (SDN).

According to some aspects, the method includes selecting a set of UP groups based on an Access Point Name (APN) and a location of a respective User Equipment (UE). For example, the SMF/NRF <NUM> illustrated in <FIG> may select a set of UP groups based on an Access Point Name (APN) and a location of a respective User Equipment (UE).

According to some aspects, the method includes selecting a UP group of the set of UP groups based on a lowest aggregate level of congestion when adding up congestion of all the UPs in each group. For example, the SMF/NRF <NUM> illustrated in <FIG> may select a UP group of the set of UP groups based on a lowest aggregate level of congestion when adding up congestion of all the UPs in each group. The congestion may be determined from the subscribed traffic engineering data received from the TEAF <NUM>.

According to some aspects, the method includes choosing a UP of the selected UP group having a least congestion level for a respective interface between the UP and a Radio Access Network and a respective interface between the UP and a Data Network. For example, the SMF/NRF <NUM> illustrated in <FIG> may choose a UP of the selected UP group having a least congestion level for a respective interface between the UP and a Radio Access Network and a respective interface between the UP and a Data Network.

According to some aspects, the method includes receiving the traffic engineering data from the Traffic Engineering Awareness Function (TEAF) <NUM>. For example, the PCF <NUM>, the AMF <NUM>, the UPF <NUM>, the SMF <NUM>, and/or the NEF <NUM> illustrated in <FIG> may receive the traffic engineering data from the TEAF <NUM>. In some aspects, the TEAF monitors and collects traffic engineering data of a plurality of interfaces of the <NUM>-compatible IP network. In some aspects, the TEAF <NUM> comprises an SBI through which network elements are provided a means to subscribe to TEAF data and/or request performance of auto-correction on the <NUM>-compatible IP network. In some aspects, the PCF <NUM> uses the collected traffic engineering data to push particular policies for lowering APN-MBR bit rate of subscribers to ease congestion and/or requests the TEAF <NUM> to auto-correct the <NUM>-compatible IP network for certain Access Point Name locations to ease congestion. In some aspects, the AMF <NUM> uses the collected traffic engineering data to select an alternate SMF.

In some aspects, the UPF <NUM> uses the collected traffic engineering data to perform self-overload control including at least one of rejection new sessions, dropping lower priority sessions, and regulating traffic. In some aspects, the NRF <NUM> uses the collected traffic engineering data to select an alternate UPF. In some aspects, the SMF <NUM> uses the collected traffic engineering data to select an alternate UP group and/or program a traffic shaping algorithm on a UPF, providing the UPF with a traffic controlling capability. In some aspects, an orchestration system uses the collected traffic engineering data to bring up one or more virtual routers and paths in the <NUM>-compatible IP network based on a determined need and/or use an algorithm to determine reachability between routers and a new enterprises for onboarding the new enterprise.

<FIG> illustrates a computing system architecture <NUM> including various components in electrical communication with each other using a connection <NUM>, such as a bus. Example system architecture <NUM> includes a processing unit (CPU or processor) <NUM> and a system connection <NUM> that couples various system components including the system memory <NUM>, such as read only memory (ROM) <NUM> and random access memory (RAM) <NUM>, to the processor <NUM>. The system architecture <NUM> can include a cache <NUM> of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor <NUM>. The system architecture <NUM> can copy data from the memory <NUM> and/or the storage device <NUM> to the cache <NUM> for quick access by the processor <NUM>. In this way, the cache can provide a performance boost that avoids processor <NUM> delays while waiting for data. These and other modules can control or be configured to control the processor <NUM> to perform various actions.

Other system memory <NUM> may be available for use as well. The memory <NUM> can include multiple different types of memory with different performance characteristics. The processor <NUM> can include any general purpose processor and a hardware or software service, such as service <NUM><NUM>, service <NUM><NUM>, and service <NUM><NUM> stored in storage device <NUM>, configured to control the processor <NUM> as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor <NUM> may be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

To enable user interaction with the computing system architecture <NUM>, an input device <NUM> can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device <NUM> can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input to communicate with the computing system architecture <NUM>. The communications interface <NUM> can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

The storage device <NUM> can include services <NUM>, <NUM>, <NUM> for controlling the processor <NUM>. Other hardware or software modules are contemplated. The storage device <NUM> can be connected to the system connection <NUM>. In one aspect, a hardware module that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as the processor <NUM>, connection <NUM>, output device <NUM>, and so forth, to carry out the function.

In some aspects the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like.

Claim 1:
A method comprising:
receiving (<NUM>) an attach request message from a subscribing gNodeB network node (<NUM>);
receiving (<NUM>) traffic engineering data associated with one or more User Plane, UP, entities (<NUM>, <NUM>) for selecting a least congested network path; and
anchoring (<NUM>) the subscribing gNodeB network node (<NUM>) to a first UP entity of the one or more UP entities based on the traffic engineering data,
the method further comprising:
selecting a set of UP groups based on an Access Point Name, APN, and a location of a respective User Equipment, UE;
selecting (<NUM>) a UP group of the set of UP groups based on a lowest aggregate level of congestion when adding up congestion of UPs in each group; and
choosing (<NUM>) a UP of the selected UP group having a least congestion level for a respective interface (N3) between the UP and a Radio Access Network, RAN, and a respective interface (N6) between the UP and a Data Network, DN.