Patent Description:
Cellular communication networks provide communication content such as voice, video, packet data, messaging, and broadcast for subscriber devices, such as mobile devices and data terminals. The cellular communication network may include a number of base stations that can support communication for a number of subscriber devices across dispersed geographic regions. Generally, when a user device, such as a mobile phone, initiates a communication session, the network selects service instances for the communication session. Yet unfortunately, the instances selected for the communication session may impact the communication session itself or the user's experience with the communication session if the selection process does not properly account for factors such as circumstances of the user and/or circumstances of the network when the communication session is established.

<CIT> discloses methods and systems for Open Network Automation Platform (ONAP) Fifth Generation Core (SGC) interaction for analytics.

<CIT> discloses a selection module associated with a control plane node implementing CUPS functionality that can identify a user plane element for assigning user plane functionalities based on static and/or dynamic selection criteria.

<CIT> discloses an Access and Mobility Management Function (AMF) that may assign a temporary ID containing particularized identification information to a UE in a manner that allows for selection by a RAN of an AMF and that enables an AMF to process an N1/N2 transaction, such as may occur when a UE enters an idle mode and/or transitions from an idle mode to a connected mode.

<CIT> discloses a first network device that determines a first pointer value associated with a first management instance that includes at least one of network access or mobility management functions for user equipment (UE) interaction with a wireless network.

The claimed subject matter is defined by the independent claims. Dependent claims describe embodiments thereof.

As mobility and connectivity for devices increase, mobile networks and their resources are increasing in their demand. Unlike resource demands for mobile networks in the past, this demand is more complex due to an evolution of mobile devices. For instance, mobile networks that once predominantly supported mobile communication for mobile phones, now support almost any computing device that has been configured with connectivity for a mobile network. Mobile devices have expanded from mobile phones, tablets, laptops, and personal display devices to an array of smart devices, such as smart wearables (e.g., watches, heart monitors, etc.), smart peripherals (e.g., speakers, headphones, etc.), smart appliances, and smart sensors. Furthermore, the very nature of traditional mobile phones has changed with advanced computing and micro processing from a device that relies on a mobile network for telephony services to a device more akin to a personal computer with functionality such as media streaming, mobile applications, electronic mail, and internet connectivity. Such functionality has even shifted the common mode of communication between people from a telephone call to a text message.

With constant changes to the mobile phone itself, and the increased usage of different types of mobile devices, mobile networks are having to address different types of connectivity needs. In other words, whereas mobile networks historically had relatively predictable resource demands, mobile networks today are now subject to increased variation in resource demand. For instance, network loads today support an increased use of mobile video and real-time communication applications. When resource demands on a mobile network were relatively predictable, the signaling functions of the network performed by a control plane and the data packet forwarding of a user plane were also relatively predictable. Due to such predictability, the control plane and the data plane were generally coupled together in a mobile network structure. Yet as resource demands have begun to vary, this variation has altered resource demands with respect to control plane and user plane resource requirements. Some devices demand a large amount of control plane resources (e.g., signaling resources), while other devices demand a small amount of signaling resources. The same may be true for the user plane where some devices may have large demands for data resources while others have relatively small demands for data resources.

Based on the disparity of resource demands, mobile networks transmitting data packets using a core network centralized around general packet radio service (GPRS) transitioned to a packet core network (e.g., an evolved packet core (EPC) for <NUM> or a fifth generation core (SGC) for <NUM>). With the network architecture of packet core network, the structure of the packet core network separated the user plane that manages user (e.g., subscriber) data and the control plane that manages signaling of user data through the network. This approach has generally been referred to as Control and User Plane Separation (CUPS). CUPS sought to provide flexible network deployment were the control plane and the user plane may be independently scaled while not affecting the functionality of other nodes of the packet core network. By independently scaling the user plane and the control plane, a CUPS configuration allows a mobile network to address user traffic on an as-needed basis in real-time. Therefore, the packet core network is capable of addressing increased user data traffic from a proliferation of video and other mobile applications that mobile networks currently experience.

In addition to independent scaling, a decoupling of the user plane and control plane may enable these planes to reside in an edge network. An edge network generally refers to a portion of a packet core network that is located close to where devices and their users use a mobile network (e.g., consume data). In other words, the "edge" refers to locations near endpoints of a mobile network (e.g., user equipment) and an edge network is where a part of a distributed computing topology of the mobile network resides. Accordingly, an edge network brings computing and/or data storage closer to endpoints.

Although user planes and control planes are separate and/or able to reside in edge networks, the selection of which user plane instance and/or control plane instance to use in a communication session with user equipment (UE) may impact network performance and/or a user's experience with the network. For example, if the assignment of a user plane instance and/or a control plane instance contributes to negative factors, such as latency or packet loss, the assignment may detrimentally impact a user's experience with the network. Thus, depending on the communication functions that a UE wants to perform, selection of a user plane instance and/or a control plane instance may be crucial to the performance of network services for the user. Furthermore, the selection of a user plane instance and/or control plane instance may not depend solely on the functions that a specific user wants to perform, but also other factors, such as where a user is located, a time of day for the selection, the current load on the mobile network at the time of selection, the current access patterns of users of the mobile network, etc. In other words, a decision to select a service instance (i.e., a control plane instance or a user plane instance) becomes increasingly complicated, especially when an increased number of mobile devices cause a mobile network to experience a large number of service instance requests at any one time. Accordingly, the user plane selector and/or the control plane selector disclosed herein attempt to address deficiencies with service instance selection.

With the ongoing improvements to mobile networks, network infrastructure is being built closer to the user (e.g., endpoints) and/or the user's radio access network (RAN). In these improved mobile networks, an air interface latency corresponding to the time it takes a UE, such as a mobile device, to communicate with a base station (e.g., RAN antenna) has been reduced. For example, in a fifth generation (<NUM>) network infrastructure, the air interface latency has been reduced to under five milliseconds. As a comparison, previous generations of mobile networks, for example, a third generation (<NUM>) mobile network, had an air interface latency of <NUM>-<NUM> milliseconds or more. With a low amount of air interface latency (e.g., less than five milliseconds), various mobile applications are possible, but without the function of these applications being latency-sensitive, latency issues may shift to being the fault of the packet core network portion of a mobile network. Stated differently, when the air interface latency was eighty or more milliseconds, the communication between UEs and the RAN infrastructure (e.g., base station(s)) was the network bottleneck; thus, functions of the mobile network in the EPC could occur within this air interface latency window without contributing to further latency issues. For instance, if the network takes <NUM>-<NUM> milliseconds to send and to retrieve a data packet from an packet core network data center in a <NUM> network (e.g., with eighty milliseconds of air interface latency), such function would not contribute to additional latency, but in a <NUM> network (e.g., with five milliseconds of air interface latency), these packet core network functions have introduced five or more seconds of latency to the task. Now with such a low degree of air interface latency, how the packet core network functions may impact the user's (e.g., the mobile network subscriber's) experience. To be sensitive to the potential of latency issues in mobile networks, the control plane selector and/or the user plane selector aims to select a service instance that fits a user's function. From this perspective, when possible, each plane selector (e.g., the user plane selector and/or the control plane selector) attempts to best support the instance of the user.

<FIG> illustrates a communication network <NUM> (also referred to as a cellular network), which may be a Long-Term Evolution (LTE) network, a <NUM> network, and/or a multiple access network supporting numerous access technologies specified by the <NUM>rd Generation Partnership Project (3GPP), such as the General Packet Radio Service (GPRS), the Global System for Mobile Communications/Enhanced Data Rates for GSM Evolution (GSM/EDGE), the Universal Mobile Telecommunication System/High Speed Packet Access (UMTS/HSPA), LTE and LTE advanced network technologies. The cellular network <NUM> (e.g., LTE network or <NUM> network) enables wireless communication of high-speed data packets between subscriber devices <NUM>, 102a-b, such as mobile devices and data terminals, and a base station <NUM>. The subscriber devices <NUM> may be interchangeably referred to as user equipment (UE) devices and/or mobile devices <NUM>. For instance, LTE is a wireless communication standard that is based on the GSM/EDGE and UMTS/HSPA network technologies and configured to increase the capacity and speed of the telecommunication by using different radio interfaces in addition to core network improvements. Different types of cellular networks <NUM> may support different bands/frequencies at various bandwidths to allow UE devices <NUM> to communicate data (e.g., data packets). To illustrate, LTE supports scalable carrier bandwidths, from <NUM> to <NUM> and supports both frequency division duplexing (FDD) and time-division duplexing (TDD) while <NUM> supports bandwidths ranging from <NUM> to <NUM> where some bandwidths overlap with LTE.

UE devices <NUM> may be any telecommunication device that is capable of transmitting and/or receiving voice/data over the network <NUM>. UE devices <NUM> may include, but are not limited to, mobile computing devices, such as laptops, tablets, smart phones, and wearable computing devices (e.g., headsets and/or watches). UE devices <NUM> may also include other computing devices having other form factors, such as computing devices included in desktop computers, smart speakers/displays, vehicles, gaming devices, televisions, or other appliances (e.g., networked home automation devices and home appliances). UE devices <NUM> subscribe to network services provided by a network operator of the communication network <NUM>. The network operator may also be referred to as a mobile network operator (MNO), a wireless service provider, wireless carrier, cellular company, or mobile network carrier.

The UE devices <NUM> may communicate with an external network <NUM>, such as a packet data network (PDN), through the communication network <NUM> (or <NUM>/<NUM> network). Referring to <FIG>, the communication network <NUM> represents a distributed architecture for a mobile network. The communication network <NUM> includes a first portion, an Evolved Universal Terrestrial Radio Access Network (e-UTRAN) portion <NUM>, and a second portion, a packet core network portion <NUM>. The packet core network portion <NUM> may generally refer to either an Evolved Packet Core (EPC) for fourth generation (<NUM>) core infrastructure or a fifth generation (<NUM>) core infrastructure (i.e., 5GC). The first portion <NUM> includes an air interface <NUM> (e.g., Evolved Universal Terrestrial Radio Access (e-UTRA) of 3GPP's LTE upgrade path) that interfaces between endpoints, such as UEs <NUM> and a radio access network (RAN) of one or more base stations <NUM>. In LTE, the air interface <NUM> uses orthogonal frequency-division multiple access (OFDMA) radio-access for the downlink and Single-carrier FDMA (SC-FDMA) for the uplink. Accordingly, the first portion <NUM> supports radio communication of data packets and/or other surfaces from the external network <NUM> to the UE devices <NUM> over the air interface <NUM> via one or more base station <NUM>.

Each base station <NUM> may include an evolved Node B (also referred as eNode B or eNB in <NUM> systems) or, with respect to a <NUM> system, a next generation Node B (also referred to as a gNB). An eNB/gNB <NUM> includes hardware that connects to the air interface <NUM> (e.g., a mobile phone network) for communicating directly with the UE devices <NUM>. For instance, the eNB/gNB <NUM> may transmit downlink LTE/<NUM> signals (e.g., communications) to the UE devices <NUM> and receive uplink LTE/<NUM> signals from the UE devices <NUM> over the air interface <NUM>. A base station <NUM> may have an associated coverage area <NUM>area that corresponds to an area where one or more UE devices <NUM> communicate with the network <NUM> by way of the base station <NUM>. For <NUM> network, when the base station <NUM> is an eNB, the base station <NUM> uses an S1 interface for communicating with the packet core network <NUM> (e.g., with the core network portion <NUM> of the packet core network <NUM>). The S1 interface may include an S1-MME interface for communicating with a Mobility Management Entity (MME) <NUM> of the core network <NUM> and an S1-U interface for interfacing with a Serving Gateway (SGW, e.g., shown in <FIG> as a combination of a Serving Gateway and a Packet Data Node Gateway (SPGW)). Accordingly, the S1 interface is associated with a backhaul link for communicating with the packet core network <NUM>. For a <NUM> network, when the base station <NUM> is a gNB, the gNB uses a N2 and a N3 interface to connect to <NUM> core network control plane and user plane functions. For example, the N2 interface is an interface for communication between the gNB <NUM> and an Access and Mobility Management Function (AMF) while the N3 interface is an interface for communication between the gNB and a backend user plane <NUM> of an edge network <NUM>.

Generally speaking, the packet core network <NUM> (e.g., an EPC or a 5GC) communicates with the UE devices <NUM> and the external network <NUM> to route data packets therebetween. As such means of communication, the packet core network <NUM> provides a framework configured to converge voice and data on the LTE/<NUM> network <NUM>. The packet core network <NUM> unifies voice and data on an Internet Protocol (IP) service architecture and voice is treated as just another IP application. The packet core network <NUM> includes, without limitation, a core network <NUM> and an edge network <NUM>. In a <NUM> network, the core network <NUM> may include several network elements, such as, for example, the MME <NUM>, a Policy and Charging Rules Function (PCRF) <NUM>, a Home Subscriber Server (HSS) (not shown), and a Serving GPRS Support Node (SGSN) (not shown). Whereas for a <NUM> network, the core network <NUM> includes an Access and Mobility Management Function (AMF) <NUM> instead of the MME <NUM> and a Policy, Charging Function (PCF) <NUM> as the <NUM> equivalent to the PCRF <NUM>. In both <NUM> and <NUM> networks, the edge network <NUM> may include the separation of the user plane and the control plane. In other words, each of the Serving Gateway (SGW) and the Packet Data Node Gateway (PGW) have a control plane portion <NUM> (e.g., shown with a designated "-C") and a user plane portion <NUM> (e.g., shown with a designated "-U").

In some examples, such as <FIG>, the edge network <NUM> is divided into different front end (FE) network elements (e.g., facing the core network <NUM> and the external network <NUM>) and backend network elements (BE) (e.g., facing the e-UTRAN portion <NUM> of the network <NUM>). With this division, <FIG> illustrates that the control plane portion <NUM> may be split further into a back end control plane <NUM> and a front end control plane <NUM>. In <NUM> networks, in addition to the SGW and PGW elements, the control plane portion <NUM> also includes a Session Management Function (SMF). Here, the SMF includes functions on both the front end (FE) and the backend (BE) of the control plane portion <NUM>. Although <FIG> depicts that the PGW and the SGW may be integrated (e.g., by the SPGW element), other network elements, such as the MME/AMF <NUM>, the PCRF/PCF <NUM>, SGSN, and the HSS, may be standalone components, or at least two of the components may be integrated together.

The network <NUM> includes interfaces that allow the UE devices <NUM>, the base stations <NUM>, and various network elements (e.g., the MME <NUM>, the PCRF/PCF <NUM>, the SPGW, the SGSN, the HSS, the SMF) to cooperate with each other during use of the network <NUM>. Information flows along these interfaces throughout the network <NUM> and generally these interfaces may be divided by user plane function and control plane function. The user plane function routes user plane traffic and includes a user plane protocol stack between the UE devices <NUM> and the base station <NUM> with sublayers, such as packet data convergence protocol (PDCP), radio link control (RLC), and medium access control (MAC). The user plane function may be shared by multiple control plane functions. A user plane data packet may traverse multiple user plane functions. Some interfaces specific to the user plane portion <NUM> are as follows: a S1-U interface between the base station <NUM> and the SPGW-U of the control plane portion <NUM> for per bearer user plane tunneling and inter base station path switching during handover; an N3 interface (e.g., in <NUM>) between a base station <NUM> and the user plane portion <NUM> where the N3 interface may use a GPRS Tunneling Protocol (GTP) or an Information Centric Networking (ICN) protocol; an N6 interface between the user control plane portion <NUM> and the external network <NUM> (e.g., a packet data network); an N9 interface between user plane instances (e.g., an intermediate user plane and a session anchor user plane) and where the interface may use a GPRS Tunneling Protocol (GTP) or an Information Centric Networking (ICN) protocol; a S4 interface (not shown) between a UE device <NUM> with <NUM> access or <NUM> access and the PGW for control and mobility support and, in some cases, user plane tunneling; and a S12 interface (not shown) between the E-UTRAN portion <NUM> (e.g., UE device <NUM>) and the SGW for user plane tunneling as an operator configuration option. Other types of communication networks (e.g., <NUM>, <NUM>, etc.) may include other user plane interfaces besides the ones depicted in <FIG> for the network <NUM>.

Referring to <FIG>, in some examples, the user plane portion <NUM> includes one or more user plane instances <NUM>, 152a-n. Each user plane instance <NUM> may refer to an infrastructure site (e.g., shown as sites <NUM>-n) where computing resources may reside (e.g., hardware such as data processing hardware or memory hardware). By having different sites, the edge network <NUM> of the packet core network <NUM> may capitalize on locations near endpoints such as UEs <NUM> that may support user plane functions and/or control plane functions. With service instances closer to the location of an endpoint, data functions (e.g., by the user plane portion <NUM>) and data control functions (e.g., by the control plane portion <NUM>) may occur at a rate to minimize latency and meet endpoint demand/access patterns. Although the network <NUM> of <FIG> depicts a single site (e.g., site <NUM>) for the control plane portion <NUM>, the control plane portion <NUM> may have multiple control plane instances <NUM> occurring at one or more sites. Since, generally speaking, a UE <NUM> is served by a single control plane instance <NUM>, the network <NUM> of <FIG> depicts a single control plane site for simplicity, but the packet core network <NUM> may include other sites hosting control plane instances <NUM> (not shown) that were not selected in this particular example to support the UE <NUM>. In some configurations, the user plane portion <NUM> and the control plane portion <NUM> share one or more sites that support their respective functionalities.

The control plane portion <NUM> is responsible for controlling and supporting user plane functions with control plane protocols (e.g., GTP-C, Gx, Gy, Gz). Particularly, the control plane portion <NUM> controls E-UTRAN access connections (e.g., attaching and detaching from the E-UTRAN portion <NUM> of the network <NUM>), controls attributes of an established network access connection (e.g., an activation of an IP address), controls routing paths of an established network connection (e.g., to support user mobility), controls the processing of packets by various rules (e.g., packet detections rules, packet forwarding rules, quality of service enforcement rules, and/or usage reporting rules), and/or controls an assignment of network resources based on demands to the network <NUM> (e.g., by a user of a UE device <NUM>). The control plane portion <NUM> may interface with multiple user plane instances (e.g., user plane instances 152a-n). Generally, a UE <NUM> is served by a single control plane portion <NUM> although multiple user plane instances <NUM> may be selected for different types of connections or functions. Some interfaces specific to the control plane portion <NUM> (e.g., shown in dotted lines between network elements), are as follows: a S1-MME interface between the base station <NUM> and the MME <NUM> that guarantees delivery of signaling messages; a S3 interface (not shown) between the SGSN and the MME <NUM> that enables user/bearer information exchange for inter 3GPP access network mobility in idle and/or active states; a S5/S8 interface (not shown) between the SGW-C/U and the PGW-C/U where the S5 interface is used in a non-roaming scenario to serve relocation based on UE device <NUM> mobility and to connect to a non-collocated gateway of a PDN while the S8 interface connects to public land mobile networks (PLMN); a Sxa/Sxb interface between the user plane portion <NUM> and the control plane portion <NUM> that uses a Packet Forwarding Control Plane (PFCP) protocol; an S10 interface (not shown) that coordinates handovers between MMEs <NUM>; a S11 interface between the MME <NUM> and the control plane portion <NUM> for transferring signal messages; a S6a interface (not shown) between the MME <NUM> and the HSS that enables transfer of subscription and authentication data related to user access; a S6d interface (not shown) between the HSS and the SGSN that also enables transfer of subscription and authentication data related to user access; and a S13 interface (not shown) that supports a UE device <NUM> identity check. Other types of communication networks (e.g., <NUM>, <NUM>, etc.) may include other control plane interfaces besides the ones depicted in <FIG> for the network <NUM>.

When a particular UE device <NUM> connects to the network <NUM>, one or more control messages are sent among the various network elements (e.g., between the network elements of the evolved packet core <NUM> and the E-UTRAN portion <NUM>). For instance, the base station <NUM> sends a control message to the MME <NUM> indicating that a new UE device <NUM> is attempting to connect to the network <NUM>. As another example, the SPGW sends a control message to the MME <NUM> indicating that data from the external network <NUM> has arrived for a particular UE device <NUM> and that the UE device <NUM> needs to establish tunnels in order to accept the waiting data. The control plane interfaces may transmit such control messages using control plane protocols, such as a general packet radio service tunneling control (GTP-C) protocol or a Diameter protocol. The type of protocol used to transmit a control message <NUM> may depend on the interface. For instance, the S3, S5/S8, and S10 interfaces use GTP-C protocol while the S11, S6a, S6d, and S13 interfaces use Diameter protocol.

The MME/AMF <NUM> is a key control-node for the network <NUM>. The MME/AMF <NUM> manages sessions and states and authenticates and tracks a UE device <NUM> across the network <NUM>. For instance, the MME/AMF <NUM> may perform various functions such as, but not limited to, control of signaling and security for a Non Access Stratum (NAS), authentication and mobility management of UE devices <NUM>, selection of gateways for UE devices <NUM>, and bearer management functions.

The PCRF/PCF <NUM> is a node responsible for real-time policy rules and charging in the packet core network <NUM>. In some examples, the PCRF/PCF <NUM> is configured to access subscriber databases (i.e., UE device users) to make policy decisions. Quality of service management may be controlled by dynamic policy interactions between the PCRF/PCF <NUM> and a network gateway device (e.g., a PGW, SGW or SPGW). Signaling by the PCRF/PCF <NUM> may establish or modify attributes of an EPS bearer (i.e., a virtual connection between the UE device <NUM> and the network gateway device). In some configurations, such as voice over LTE (VoLTE), the PCRF <NUM> allocates network resources for establishing calls and distributing requested bandwidth to a call bearer with configured attributes.

The SGW (e.g., shown as a separate network element with respect to the control plane portion <NUM>, but integrated with the PGW in the user plane portion <NUM>) performs various functions related to IP data transfer for user devices <NUM>, such as data routing and forwarding, as well as mobility anchoring. The SGW may perform functions such as buffering, routing, and forwarding of data packets for mobile devices <NUM>. Similarly, the PGW (i.e., network gateway device) performs various functions such as, but not limited to, internet protocol (IP) address allocation, maintenance of data connectivity for UE devices <NUM>, packet filtering for UE devices <NUM>, service level gating control and rate enforcement, dynamic host configuration protocol (DHCP) functions for clients and servers, and gateway general packet radio service (GGSN) functionality.

The SMF of the control plane portion <NUM> performs functionality related to session management (SM) and IP address management. For instance, the SMF performs session establishment, session modification, and/or session release between user plane functions and RAN node (e.g., base station <NUM>). The SMF also is configured to select and to control user plane functions (e.g., traffic steering to route traffic to its proper destination), to terminate interfaces towards the PCF, to collect charging data and to support charging interfaces, to initiate RAN node specific session management information, and to support roaming functionality. With regard to IP address management, the SMF is configured to allocate a UE IP address and thereafter manage that UE IP address. This may include authorization functions for the IP address.

The HSS (not shown) refers to a database of all UE devices <NUM> that includes all UE device user data. Generally, the HSS is responsible for authentication for call and session setup. In other words, the HSS is configured to transfer subscription and authentication data for user access and UE context authentication. The HSS interacts with the MME <NUM> to authenticate the UE device <NUM> and/or UE device user. The MME communicates with the HSS on the PLMN using Diameter protocol (e.g., via the S6a interface).

In some implementations, the packet core network <NUM> includes a user plane selector <NUM> and/or a control plane selector <NUM>. Each selector <NUM>, <NUM> is configured to select a service instance for a communication session between a UE <NUM> and the packet core network <NUM>. Here, the user plane selector <NUM> is configured to select a user plane instance <NUM> from one or more user plane instance candidates <NUM> (e.g., shown in <FIG>) available to the packet core network <NUM> to perform the user plane functions (e.g., data packet processing) during the communication session between a UE <NUM> and the packet core network <NUM>. Similarly, the control plane selector <NUM> is configured to select a control plane instance <NUM> from one or more control plane instance candidates <NUM> (e.g., shown in <FIG>) available to the packet core network <NUM> to perform control plane functions (e.g., data packet routing) during the communication session between a UE <NUM> and the packet core network <NUM>.

When the UE <NUM> decides to use the data packets services of the network <NUM> (e.g., for cellular communication or to support the use of various computing-based applications), the UE <NUM> initiates a session set-up request (e.g., also referred to as a request R). The UE <NUM> sends this session set-up request to a base station <NUM> (e.g., an eNB/gNB) within the geographical region of the UE <NUM> (e.g., the coverage area <NUM>area). The base station <NUM> then selects a MME/AMF <NUM> of the packet core network <NUM> as a network control node to manage the communication session for the UE <NUM>. Generally, the base station <NUM> selects a MME/AMF <NUM> of a network <NUM> based on its own load balancing techniques. Once the base station <NUM> selects the MME/AMF <NUM> in response to the set-up request, the MME/AMF <NUM> is configured to consult a Domain name Service (DNS) to select a SPGW/SMF virtual IP (VIP) address for the UE <NUM>. The VIP is communicated to a network operator (e.g., by advertising from a Top Of Rack (TOR) switch) and a control plane portion <NUM> (e.g., a front end control plane portion <NUM>) is selected for the communication session (e.g., by the TOR with a hashing function). With a selected front end control plane portion <NUM> (e.g., shown as the front end control plane portion <NUM> of site <NUM>), the front end control plane portion <NUM> works with the control plane selector <NUM> to discover a backend control plane portion <NUM> for the communication session (e.g., a control plane instance <NUM>). The backend plane portion <NUM> for a particular control plane instance <NUM> is configured to process the initial session set-up message of the session setup request R. Once the control plane portion <NUM> performs protocol processing to setup the UE session, the control plane portion <NUM> selects a user plane instance <NUM> to perform the user plane functions of the user plane portion <NUM>. Here, in order for the control plane portion <NUM> to select the user plane instance <NUM>, the control plane portion <NUM> consults with the user plane selector <NUM>. The user plane selector <NUM> either passes a selection recommendation or may be used to actually select one of the available user plane instances 152a-n. With the service instances <NUM>, <NUM> established for the session of the UE <NUM>, the control plane portion <NUM> programs tunnel parameters and provides the UE <NUM> with UE IP addresses (e.g., IPv4/IPv6 addresses). The control plane portion <NUM> is also responsible for maintaining the established association between an external network <NUM> (e.g., packet data network) and the selected user plane instance <NUM>. At this point, the control plane portion <NUM> may also respond to the mobility manager (e.g., the MME/AMF <NUM>) to relay that the session has been established with service instances <NUM>, <NUM> and also to establish a RAN-side data path (e.g., a S1-U interface tunnel). After establishment of the session with the user plane instance <NUM>, the control plane portion <NUM> routes data (e.g., messages or other packets of information) through the selected user plane instance <NUM> for the established connection between the UE <NUM> and the external network <NUM>.

In some implementations, the selectors <NUM>, <NUM> include hardware (e.g., data processing hardware <NUM>, <NUM> and memory hardware <NUM>, <NUM>) as computing resources to perform the functions of the selectors <NUM>, <NUM>. In some examples, this hardware may be specific to the selector(s) <NUM>, <NUM> or refer to processing resources of the packet core network <NUM> (e.g., the edge network <NUM>) shared with the selector(s) <NUM>, <NUM>. In some configurations, the selector(s) <NUM>, <NUM> are co-located with service instances <NUM>, <NUM> (e.g., reside at one or more sites with the user plane portion <NUM> and/or the control plane portion <NUM>) or in a centralized location capable of communicating the recommendations and/or selections of the selector(s) <NUM>, <NUM> to the appropriate network elements in order to establish the service instances <NUM>, <NUM>.

Referring to <FIG>, the user plane selector <NUM> is configured to recommend or to select a user plane instance <NUM> based on a request R to establish a communication session (e.g., between a UE <NUM> and an external network <NUM>). The user plane selector <NUM> generally includes an identifier <NUM> and an analyzer <NUM>. The identifier <NUM> is configured to identify a plurality of user plane instance candidates <NUM>. A user plane instance candidate <NUM> refers to a user plane instance <NUM> that is capable of communicating with a control plane instance <NUM> established for a communication session. In other words, the user plane instance candidate <NUM> has to be reachable by the control plane portion <NUM> such that the control plane portion <NUM> can route data packets accordingly through the user plane instance candidate <NUM>, if selected.

In <FIG>, the identifier <NUM> identifies each site (e.g., sites <NUM>-n) of the user plane portion <NUM> as a user plane instance candidate 212a-n. For each user plane instance candidate <NUM>, the identifier <NUM> determines one or more selection parameters <NUM>, 114i-i. Here, i corresponds to a number of types of selection parameters <NUM> that may be determined or obtained by the identifier <NUM>. The selection parameters <NUM> generally refer to network performance metrics. In some configurations, each RAN node (e.g., base station <NUM>) maintains a number of key performance indicators (KPIs) <NUM> that correspond to communication-based metrics that are collected, or generally quantified and stored, to monitor network performance. When a base station <NUM> receives the request R from the UE <NUM>, the base station <NUM> is also configured to communicate its KPIs <NUM> to the packet core network <NUM> (e.g., to the selector <NUM>). In some implementations, the selector <NUM> may periodically stream or obtain KPIs <NUM> from one or more base nodes <NUM> of the network <NUM> and determine the parameters <NUM> at the time of receipt or at the time of identification. In some examples, the base station <NUM> communicates only a subset of the KPIs <NUM> (e.g., the selection parameter(s) <NUM>) to the packet core network <NUM>. Although the selection parameters <NUM> may refer to any network performance metric that may be used by the selector <NUM> to optimize user plane instance selection, some examples of selection parameters <NUM> include a base station node IP address (eNB/gNB-IP), an identifier or number of external network(s) <NUM>, a GTP-U latency, transport control protocol (TCP) retransmissions, and/or a time of day (ToD).

In some examples, the identifier <NUM> determines the one or more selection parameters <NUM> for each candidate <NUM> at the selector <NUM>. In other words, the base station <NUM> has previously gathered or is gathering KPIs that correspond to a particular user plane instance <NUM>. When the identifier <NUM> receives or determines the selection parameters <NUM> based on the KPIs <NUM>, the identifier <NUM> associates the selection parameters <NUM> with its specific user plane instance <NUM>. In some configurations, the identifier <NUM> associates the selection parameters <NUM> with the user plane instance <NUM> prior to identifying the user plane instance <NUM> as a user plane instance candidate <NUM>. In this configuration, the identifier <NUM> may be configured to perform an initial filtering of user plane instances <NUM> by identifying only user plane instances <NUM> as user plane instance candidates <NUM> when the user plane instances <NUM> satisfy one or more selection parameter thresholds.

The analyzer <NUM> is configured to select one of the plurality of user plane instance candidates 212a-n to fulfill the request R for the user plane instance <NUM> from the control plane portion <NUM>. Here, the analyzer <NUM> receives the candidates <NUM> from the identifier <NUM> and generates a selection <NUM> (e.g., shown as a dotted box around a particular candidate <NUM>) that selects or recommends a user plane instance candidate <NUM> as the user plane instance <NUM> to fulfill the request R. As shown in <FIG>, the analyzer <NUM> may perform the selection <NUM> (or recommendation) using a few different selection approaches. In either approach, the analyzer <NUM> generally bases the selection <NUM> on the selection parameter(s) 114a-n associated with the candidates <NUM>.

Referring to <FIG> and <FIG>, the analyzer <NUM> may place the candidates <NUM> in a particular order (e.g., shown as a list <NUM>) and select the candidate <NUM> as the selection <NUM> based on this order. In one approach, as shown in <FIG>, the analyzer <NUM> generates a list <NUM> of candidates <NUM> and is configured to select the candidate <NUM> based on a round robin approach. In other words, similar to round robin scheduling of computing resources, the analyzer <NUM> performs the selection <NUM> by cycling through each candidate <NUM> on the list <NUM> in order. For instance, the analyzer <NUM> selects the first candidate 212a on the list <NUM> as a first selection <NUM>, 202a when it receives a first request R. The analyzer <NUM> then sequentially selects the second candidate 212b on the list <NUM> as a second selection <NUM>, 202b when it receives a subsequent request R since the candidate <NUM> on the list <NUM> before it (e.g., the first candidate 212a) has already been previously selected in a prior session. In this manner, the analyzer <NUM> equally distributes instances <NUM> based on the previous selection <NUM>. This approach may help balance the load (e.g., at particular network sites) by rotating the selection <NUM> such that the same candidate <NUM> or set of candidates <NUM> is not routinely selected causing underutilization of other feasible candidates <NUM>. In other words, although a user plane instance <NUM> or site with the ability to host multiple user planes instances <NUM> may appear as though it is the best candidate <NUM> based on, for example, the location of the UE <NUM>, if multiple UEs <NUM> near that site are requesting service instances, the computing resources at a site may become taxed due to poor distribution of instances <NUM> behalf of the selector <NUM> (e.g., even though other sub-optimal, but acceptable instances are available to these UEs <NUM>).

Referring to <FIG>, when the analyzer <NUM> orders the candidates <NUM> (e.g., in the list <NUM>), the analyzer <NUM> may associate a weight w with a candidate <NUM>. In some examples, the weight w refers to a classification of the one or more selection parameters <NUM> associated with the candidate <NUM>. In other words, the identifier <NUM> or the analyzer <NUM> may assign a weight w to the candidate based on a single selection parameter <NUM> of the candidate <NUM> or more than one selection parameter <NUM> of the candidate <NUM>. In some examples, the weight w may refer to a score assigned to each candidate <NUM> as a function of its selection parameter(s) <NUM>. With the weights w, wa-n assigned to each candidate <NUM>, the analyzer <NUM> may generate the list <NUM> in an order that ranks the candidates <NUM> by weight w. When the list <NUM> includes weights w for the candidates <NUM>, the analyzer <NUM> generate the selection <NUM> of a candidate <NUM> based on a candidate with the greatest or lowest weight (e.g., depending on the weight function). Accordingly, when the analyzer <NUM> orders the list <NUM> by weight w, the analyzer <NUM> may be configured to select the top candidate <NUM> on the list <NUM>.

Additionally or alternatively to the weight w applied to each candidate <NUM>, <FIG> illustrates that the analyzer <NUM> may use an approach where the selection <NUM> is based on selection criteria <NUM>. The selection criteria <NUM> generally refers to a rule-based approach where the analyzer <NUM> uses one or more rules to select a candidate <NUM>. In some examples, the selection criteria <NUM> refers to a rule to select a minima or maxima of one or more of the selection parameters <NUM>. In other examples, the selection criteria <NUM> includes multiple rules (e.g., compounding rules) such that the analyzer <NUM> uses its processing to determine a candidate <NUM> that represents the intersection of each rule or the next best alternative. For instance, with several selection parameters <NUM>, the rules may specify that the candidate <NUM> should have at least a particular latency measurement (i.e., a latency threshold) at a particular time of day. In this instance, the analyzer <NUM> determines a candidate <NUM> that satisfies each of these rules (or the next best alternative), and selects such candidate <NUM> as the selection <NUM>. In some configurations, with compound rules as the selection criteria <NUM>, each rule may be assigned priority. For example, the analyzer <NUM> may prioritize a candidate's average latency characteristics rather than confine itself to latency measurements at a particular time of day. In order to load balance resources of the network <NUM> and/or be latency-sensitive, the selection criteria <NUM> may often include rules that specify thresholds or values that latency measurements (e.g., GTP-U latency) and/or load measurement should satisfy in order to be selected by the analyzer <NUM>.

<FIG> depicts the selector <NUM> using a machine learning approach to user plane instance selection. In this approach, the selector <NUM> forms the selection <NUM> of the user plane instance <NUM> based on a prediction P from a predictive model <NUM> at a predictor <NUM>. In some examples, the predictor <NUM> replaces the analyzer <NUM>. Yet in other examples, the analyzer <NUM> (although not shown) may still be implemented by the selector <NUM> to determine that the prediction P actually satisfies selection criteria <NUM>. The predictor <NUM> generally includes two stages, a first stage (e.g., a training stage) and a second stage (e.g., inference stage). In the first stage, the predictor <NUM> trains the model <NUM> to be able to predict a user plane instance <NUM> that satisfies the selection criteria <NUM>. In order to train the predictor <NUM>, the predictor <NUM> generates training groups <NUM>. Each training group <NUM> includes a set of training user plane instances <NUM> and corresponding selection parameter(s) <NUM> to simulate a set of user plane instance candidates <NUM> that the selector <NUM> would select from during operation. Here, each training user plane instance <NUM> in a training group <NUM> includes a selection criteria label <NUM>. The selection criteria label <NUM> indicates whether or not a training user plane instance <NUM> with its parameters <NUM> satisfies the selection criteria <NUM>. By including the selection criteria label <NUM>, the selection criterial label <NUM> functions as a ground truth while training the model <NUM> with the training groups <NUM>. With ground truths, the predictor <NUM> learns which candidates <NUM> associated with particular selection parameter(s) <NUM> correspond to which label <NUM>. In some examples, to determine whether the model <NUM> has been sufficiently trained, a validation training group <NUM>, 234v is passed to the model <NUM> to identify whether the model <NUM> accurately identifies the correct labels <NUM> for the validation training group 234v. In a second stage (e.g., inference), after the predictor <NUM> is trained, the predictor <NUM> no longer uses training user plane instances <NUM> with both parameters <NUM> and a label <NUM>. Instead, the identifier <NUM> communicates one or more candidates <NUM>, their parameter(s) <NUM>, and the selection criteria <NUM> to the trained model <NUM> for the trained model <NUM> to generate a prediction P of the label <NUM> for each candidate <NUM>. Here, the predictor <NUM> forms the selection <NUM> by using a label <NUM> to predicts that a candidate <NUM> from among the candidates <NUM> satisfies the selection criteria <NUM>.

In some examples, once training is complete (e.g., after validation), the predictor <NUM> tests the model <NUM> on small percentage of new incoming requests R to predict the user plane instance candidate <NUM> for different selection criteria <NUM>. Some selection criteria <NUM> may try to identify the best user plane instance candidate <NUM> to use with a particular network configuration (e.g., a particular UE <NUM>, base station <NUM>, or some combination of network elements that connect to an external network <NUM>). For instance, the selection criteria <NUM> includes an identifier of the particular type of network configuration, such as a base station node internet protocol address (eNB/gNB-IP), an evolved Universal Mobile Telecommunications Service Terrestrial Radio Access Network cell global identifier (ECGI), an International Mobile Equipment Identity (IMEI), or an International Mobile Subscriber Identity (IMSI). The model <NUM> may use one or more of these identifiers with other selection criteria <NUM> such as, a latency measurement (e.g., the lowest latency) or a rate of TCP retransmissions (e.g., the lowest rate). In other words, the selection criteria <NUM> may compound different types of criteria. A first type of criteria may be network performance-based criteria (e.g., the lowest latency). A second type of criteria may be network device-based criteria (e.g., use the identifiers for particular type of network elements or network configurations). A third type of criteria may be based on current conditions during a request R (e.g., time of day or a location of network equipment). To give an example of such compound selection criteria <NUM>, the request R along with the selection criteria <NUM> may request the best user instance candidate <NUM> for a given packet core identifier (e.g., ECGI/eNB-IP or gNB-IP) at a particular time of day. Additionally, the selector <NUM> may want to fulfill this request R for any UE <NUM> based on the given packet core identifier and ToD or for a particular UE <NUM>. With these types of compounding layers, the selection <NUM> of a user plane instance candidate <NUM> may be capable of varying degrees of granularity. In some configuration, when the predictor <NUM> tests the model <NUM> on a small percentage of new incoming requests R, the predictor <NUM> uses selection criteria <NUM> in an increasing order of granularity. For instance, the increasing order of granularity is (i) eNB/gNB-Ip, ToD, (ii) ECGI, ToD, (iii) IMEI, ECGI/eNB-IP or gNB-IP, ToD, (iv) IMSI, ECGI/eNB-IP or gNB-IP, ToD (e.g., when IMSI or hashed IMSI is available for use).

Referring to <FIG>, the control plane selector <NUM> is configured to recommend or to select a control plane instance <NUM> based on a request R to establish a communication session (e.g., between a UE <NUM> and an external network <NUM>). The control plane selector <NUM> generally includes an identifier <NUM> and an analyzer <NUM>. The identifier <NUM> is configured to identify a plurality of control plane instance candidates <NUM>. A control plane instance candidate <NUM> refers to a control plane instance <NUM> that is configured to route packets for a UE <NUM> during a communication session. In other words, the control plane instance candidate <NUM> is configured to serve an entirety of a MME/AMF IP space, if selected.

In <FIG>, each site (e.g., sites <NUM>-n) of the control plane portion <NUM> is shown to be identified as a control plane instance candidate 312a-n by the identifier <NUM>. For each control plane instance candidate <NUM>, the identifier <NUM> determines one or more selection parameters <NUM>, 138i-i (e.g., for the control plane functions these are also referred to as routing selection parameters <NUM>). Here, i corresponds to a number of types of routing selection parameters <NUM> that may be determined or obtained by the identifier <NUM>. The routing selection parameters <NUM> generally refer to network performance metrics. In some configurations, each mobilty manager (e.g., MME/AMF <NUM>) maintains a number of key performance indicators (KPIs) <NUM> (also referred to as routing KPIs <NUM>) that correspond to communication-based metrics that are collected, or generally quantified and stored, to monitor network performance (e.g., session routing performance). When a MME/AMF <NUM> receives the request R from the UE <NUM>, the MME/AMF <NUM> is also configured to communicate its routing KPIs <NUM> to the packet core network <NUM> (e.g., to the selector <NUM>). In some implementations, the selector <NUM> may periodically stream or obtain routing KPIs <NUM> from one or more mobility managers <NUM> of the network <NUM> and determine the routing parameters <NUM> at the time of receipt or at the time of identification. In some examples, the mobility manager <NUM> communicates only a subset of the routing KPIs <NUM> (e.g., the routing selection parameter(s) <NUM>) to the packet core network <NUM>. Although the routing selection parameters <NUM> may refer to any network performance metric that may be used by the selector <NUM> to optimize control plane instance selection, some examples of routing selection parameters <NUM> include a MME/AMF IP address, an identifier or number of external network(s) <NUM>, a GTP-C latency, GTP-C retransmission count, and/or a time of day (ToD).

In some examples, the identifier <NUM> determines the one or more routing selection parameters <NUM> for each candidate <NUM> at the selector <NUM>. In other words, the mobility manager <NUM> has previously gathered or is gathering routing KPIs <NUM> that correspond to particular control plane instance <NUM>. When the identifier <NUM> receives or determines the routing selection parameters <NUM> based on the routing KPIs <NUM>, the identifier <NUM> associates the routing selection parameters <NUM> with its specific control plane instance <NUM>. In some configurations, the identifier <NUM> associates the routing selection parameters <NUM> with the control plane instance <NUM> prior to identifying the control plane instance <NUM> as a control plane instance candidate <NUM>. In this configuration, the identifier <NUM> may be configured to perform an initial filtering of control plane instances <NUM> by identifying only control plane instances <NUM> that satisfy one or more routing selection parameter thresholds as control plane instance candidates <NUM>.

The analyzer <NUM> is configured to select one of the plurality of control plane instance candidates 312a-n to fulfill the request R for the control plane instance <NUM> from the session manager (e.g., the SMF from the front end control plane portion <NUM>). Here, the analyzer <NUM> receives the candidates <NUM> from the identifier <NUM> and generates a selection <NUM> (e.g., shown as a dotted box around a particular candidate <NUM>) that selects or recommends a control plane instance candidate <NUM> as the control plane instance <NUM> to fulfill the request R. As shown in <FIG>, the analyzer <NUM> may perform the selection <NUM> (or recommendation) using a few different selection approaches. In either approach, the analyzer <NUM> generally bases the selection <NUM> on the routing selection parameter(s) 138a-n associated with the candidates <NUM>.

Referring to <FIG> and <FIG>, the analyzer <NUM> may place the candidates <NUM> in a particular order (e.g., shown as a list <NUM>) and select the candidate <NUM> as the selection <NUM> based on this order. In one approach, as shown in <FIG>, the analyzer <NUM> generates a list <NUM> of candidates <NUM> and is configured to select the candidate <NUM> based on a round robin approach. In other words, similar to round robin scheduling of computing resources, the analyzer <NUM> performs the selection <NUM> by cycling through each candidate <NUM> on the list <NUM> in order. For instance, when the analyzer <NUM> selects the first candidate 312a on the list <NUM> as a first selection <NUM>, 302a when it receives a first request R, it then sequentially selects the second candidate 312b on the list <NUM> as a second selection <NUM>, 302b when it receives a subsequent request R since the candidate <NUM> on the list <NUM> before it (e.g., the first candidate 312a) has already been previously selected in a prior session. In this manner, the analyzer <NUM> equally distributes instances <NUM> based on previous selection <NUM>. This approach may help balance the load (e.g., at particular network sites) by rotating the selection <NUM> such that the same candidate <NUM> or set of candidates <NUM> is not routinely selected causing underutilization of other feasible candidates <NUM>.

Referring to <FIG>, when the analyzer <NUM> orders the candidates <NUM> (e.g., in the list <NUM>), the analyzer <NUM> may associate a weight w to a candidate <NUM>. In some examples, the weight w refers to a classification of the one or more routing selection parameters <NUM> associated with the candidate <NUM>. In other words, the identifier <NUM> or the analyzer <NUM> may assign a weight w to the candidate <NUM> based on a single routing selection parameter <NUM> of the candidate <NUM> or more than one routing selection parameter <NUM> of the candidate <NUM>. In some examples, the weight w may refer to a score assigned to each candidate <NUM> as a function of its routing selection parameter(s) <NUM>. With the weights w, wa-n assigned to each candidate <NUM>, the analyzer <NUM> may generate the list <NUM> in an order that ranks the candidates <NUM> by weight w. When the list <NUM> includes weights w for the candidates <NUM>, the analyzer <NUM> generate the selection <NUM> of a candidate <NUM> based on a candidate <NUM> with the greatest or lowest weight w (e.g., depending on the weight function). Accordingly, when the analyzer <NUM> orders the list <NUM> by weight w, the analyzer <NUM> may be configured to select the top candidate <NUM> on the list <NUM>.

Additionally or alternatively to the weight w applied to each candidate <NUM>, <FIG> illustrates that the analyzer <NUM> may use an approach where the selection <NUM> is based on selection criteria <NUM>. The selection criteria <NUM>, much like the selection criteria <NUM> of the user plane selector <NUM>, generally refers to a rule-based approach where the analyzer <NUM> uses one or more rules to select a candidate <NUM>. In some examples, the selection criteria <NUM> refers to a rule to select a minima or maxima of one or more of the routing selection parameters <NUM>. In other examples, the selection criteria <NUM> includes multiple rules (e.g., compounding rules) such that the analyzer <NUM> uses its processing to determine a candidate <NUM> that represents the intersection of each rule or the next best alternative. For instance, with several routing selection parameters <NUM>, the rules may specify that the candidate <NUM> should have at least a particular latency measurement (i.e., a latency threshold) at a particular time of day. In this instance, the analyzer <NUM> determines a candidate <NUM> that satisfies each of these rules (or the next best alternative), and selects such candidate <NUM> as the selection <NUM>. In some configurations, with compound rules as the selection criteria <NUM>, each rule may be assigned priority. For example, the analyzer <NUM> may prioritize a candidate's average latency characteristics rather than confine itself to latency measurements at a particular time of day. In order to load balance resources of the network <NUM> and/or be latency-sensitive, the selection criteria <NUM> may often include rules that specify thresholds or values that latency measurements and/or load measurement should satisfy in order to be selected by the analyzer <NUM>.

<FIG> depicts the selector <NUM> using a machine learning approach to control plane instance selection. In this approach, the selector <NUM> forms the selection <NUM> of the control plane instance <NUM> based on a prediction P from a predictive model <NUM> at a predictor <NUM>. In some examples, the predictor <NUM> replaces the analyzer <NUM>. Yet in other examples, the analyzer <NUM> (although not shown) may still be implemented by the selector <NUM> to determine that the prediction P actually satisfies selection criteria <NUM>. The predictor <NUM> generally includes two stages, a first stage (e.g., a training stage) and a second stage (e.g., inference stage). In the first stage, the predictor <NUM> trains to be able to predict a control plane instance <NUM> that satisfies the selection criteria <NUM>. In order to train the predictor <NUM>, the predictor <NUM> generates training groups <NUM>. Each training group <NUM> includes a set of training control plane instances <NUM> and corresponding routing selection parameter(s) <NUM> to simulate a set of control plane instance candidates <NUM> that the selector <NUM> would select from during operation. Here, each training control plane instance <NUM> in a training group <NUM> includes a selection criteria label <NUM>. The selection criteria label <NUM> indicates whether or not a training control plane instance <NUM> with its routing parameters <NUM> satisfies the selection criteria <NUM>. By including the selection criteria label <NUM>, the selection criterial label <NUM> functions as a ground truth while training the model <NUM> with the training groups <NUM>. With ground truths, the predictor <NUM> learns which candidates <NUM> associated with particular routing selection parameter(s) <NUM> correspond to which label <NUM>. In some examples, to determine whether the model <NUM> has been sufficiently trained, the a validation training group <NUM>, 334v is passed to the model <NUM> to identify whether the model <NUM> accurately identifies the correct labels <NUM> for the validation training group 334v. In a second stage (e.g., inference), after the predictor <NUM> is trained, the predictor <NUM> no longer uses training user plane instances <NUM> with both routing parameters <NUM> and a label <NUM>. Instead, the identifier <NUM> communicates one or more candidates <NUM>, their routing parameter(s) <NUM>, and the selection criteria <NUM> to the trained model <NUM> for the trained model <NUM> to generate a prediction P of the label <NUM> for each candidate <NUM>. Here, the predictor <NUM> forms the selection <NUM> by using a label <NUM> that predicts that a candidate <NUM> from among the candidates <NUM> satisfies the selection criteria <NUM>.

In some examples, once training is complete (e.g., after validation), the predictor <NUM> tests the model <NUM> on small percentage of new incoming requests R to predict the control plane instance candidate <NUM> for different selection criteria <NUM>. Some selection criteria <NUM> that may be used try to identify the best control plane instance candidate <NUM> to use with a particular network configuration (e.g., a particular UE <NUM>, session manager (e.g., SMF of the front end control plane portion <NUM>), or some combination of network elements that connect to an external network <NUM>). For instance, the selection criteria <NUM> includes an identifier of the particular type of network configuration, such as an identifier of the MME, an identifier of the AMF, an International Mobile Equipment Identity (IMEI), or an International Mobile Subscriber Identity (IMSI). The model <NUM> may use one or more of these identifiers with other selection criteria <NUM> such as, a latency measurement (e.g., the lowest latency) or a rate of GTP-C retransmissions (e.g., the lowest rate). In other words, the selection criteria <NUM> may compound different types of criteria. A first type of criteria may be network performance-based criteria (e.g., the lowest latency). A second type of criteria may be network device-based criteria (e.g., use the identifiers for particular type of network elements or network configurations). A third type of criteria may be based on current conditions during a request R (e.g., time of day or a location of network equipment). To give an example of such compound selection criteria <NUM>, the request R along with the selection criteria <NUM> may request the best control instance candidate <NUM> for a given mobility manager identifier (e.g., MME/AMF identifier) at a particular time of day. Additionally, the selector <NUM> may want to fulfill this request R for any UE <NUM> based on the given mobility manager identifier and ToD or for a particular UE <NUM>. With these types of compounding layers, the selection <NUM> of a user plane instance candidate <NUM> may be capable of varying degrees of granularity. In some configuration, when the predictor <NUM> tests the model <NUM> on a small percentage of new incoming requests R, the predictor <NUM> uses selection criteria <NUM> in an increasing order of granularity. For instance, the increasing order of granularity is (i) MME/AMF, ToD, (ii) IMEI, MME/AMF, ToD, (iii) IMSI, MME/AMF, ToD (e.g., when IMSI or hashed IMSI is available for use).

<FIG> is a flowchart of an example arrangement of operations for a method <NUM> of selecting a user plane instance <NUM>. At operation <NUM>, the method <NUM> receives, at data processing hardware <NUM>, from a control plane <NUM>, a request R for a user plane instance <NUM> in a packet core network <NUM>. The user plane instance <NUM> is configured to perform packet processing for a user equipment <NUM> during a communication session. At operation <NUM>, the method <NUM> identifies a plurality of user plane instance candidates <NUM> associated with a base station <NUM> in communication with the user equipment <NUM>. The plurality of user plane instance candidates <NUM> is configurable by the control plane <NUM>. For each user plane instance candidate, at operation <NUM>, the method <NUM> determiners one or more selection parameters <NUM> corresponding to a subset of key performance indicators <NUM> for the base station <NUM> in communication with the user equipment <NUM>. At operation <NUM>, the method <NUM> selects one of the plurality of user plane instance candidates <NUM> to fulfill the request R for the user plane instance <NUM> from the control plane <NUM> based on the one or more selection parameters <NUM> determined for each of the plurality of user plane instance candidates <NUM>.

<FIG> is a flowchart of an example arrangement of operations for a method <NUM> of selecting a control plane instance <NUM>. At operation <NUM>, the method <NUM> receives, at data processing hardware <NUM>, from a session manager <NUM> of a packet core network <NUM>, a request R for a control plane instance <NUM> in the packet core network <NUM>. The control plane instance <NUM> is configured to route packets for a user equipment <NUM> during a communication session. At operation <NUM>, the method <NUM> identifies a plurality of control plane instance candidates <NUM> associated with a mobility manager <NUM> of the packet core network <NUM>. The plurality of control plane instance candidates <NUM> is configured to serve a geographic region of the mobility manager <NUM>. For each control plane instance candidate <NUM>, at operation <NUM>, the method <NUM> determines one or more selection parameters <NUM> corresponding to a subset of key performance indicators <NUM> for the mobility manager <NUM> in communication with the user equipment <NUM>. At operation <NUM>, the method <NUM> selects a respective control plane instance candidate <NUM> to fulfill the request R for the control plane instance <NUM> from the session manager <NUM> based on the determined one or more selection parameters <NUM>.

<FIG> is schematic view of an example computing device <NUM> that may be used to implement the systems (e.g., the selectors <NUM>, <NUM>) and methods (e.g., method <NUM> and method <NUM>) described in this document.

The processor <NUM> (e.g., data processing hardware <NUM>, <NUM>) can process instructions for execution within the computing device <NUM>, including instructions stored in the memory <NUM> or on the storage device <NUM> to display graphical information for a graphical user interface (GUI) on an external input/output device, such as display <NUM> coupled to high speed interface <NUM>.

The memory <NUM> (e.g., memory hardware <NUM>, <NUM>) stores information non-transitorily within the computing device <NUM>.

Claim 1:
A method (<NUM>) comprising:
receiving, at data processing hardware (<NUM>), from a control plane (<NUM>), a request for a user plane instance (<NUM>) in a packet core network (<NUM>), the user plane instance (<NUM>) configured to perform packet processing for a user equipment (<NUM>) during a communication session;
identifying, by the data processing hardware (<NUM>), a plurality of user plane instance candidates (<NUM>) associated with a base station (<NUM>) in communication with the user equipment (<NUM>), the plurality of user plane instance candidates (<NUM>) configurable by the control plane (<NUM>);
for each user plane instance candidate (<NUM>), determining, by the data processing hardware (<NUM>), one or more selection parameters (<NUM>) corresponding to a subset of key performance indicators (<NUM>) for the base station (<NUM>) in communication with the user equipment (<NUM>); and
selecting, by the data processing hardware (<NUM>), using a machine learning selection model (<NUM>), one of the plurality of user plane instance candidates (<NUM>) to fulfil the request for the user plane instance (<NUM>) from the control plane (<NUM>) based on the one or more selection parameters (<NUM>) determined for each of the plurality of user plane instance candidates (<NUM>), wherein the machine learning selection model (<NUM>) is
configured to receive the one or more selection parameters determined for each of the plurality of user plane instance candidates and selection criteria; and
characterized in that the machine learning selection model is trained on a plurality of training groups, each training group comprising a plurality of training user plane instances, each training user plane instance in the corresponding training group associated with one or more corresponding selection parameters and a selection criteria label, the selection criteria label indicating whether or not the corresponding training user plane instances satisfy the selection criteria,
wherein the selection criteria include compound selection criteria (<NUM>) comprising network performance-based criteria, network device-based criteria, and criteria based on conditions of network devices during the request, and wherein the machine learning model uses the compound selection criteria (<NUM>) in an increasing order of granularity.