SYSTEMS AND METHODS FOR USER EQUIPMENT POLICY UPDATES BASED ON RADIO FREQUENCY CONNECTION CHARACTERISTICS

A system described herein may receive, from a policy element of a core of a wireless network, a set of triggers associated with a plurality of radio frequency (“RF”) bands implemented by a radio access network (“RAN”). The system may identify that a User Equipment (“UE”) is connected to the RAN via a first RF band, and may identify a subsequent connection of the UE to the RAN via a second RF band. The system may identify that a particular trigger, of the set of triggers, is satisfied based on the subsequent connection of the UE to the RAN via the second RF band, and may indicate, to the policy element, that the particular trigger has been satisfied. The policy element may output a second set of UE policies for communications between the UE and the core of the wireless network based on the satisfaction of the particular trigger.

BACKGROUND

Wireless networks provide wireless connectivity to User Equipment (“UEs”), such as mobile telephones, tablets, Internet of Things (“IoT”) devices, Machine-to-Machine (“M2M”) devices, or the like. Such wireless networks may enforce policies related to the UEs, such as Quality of Service (“QoS”) parameters for services that the UEs are authorized to receive, Data Network Names (“DNNs”) that the UEs are authorized to use, network slices of the wireless network with which the UEs are authorized to communicate, and/or other types of policies.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Embodiments described herein provide for different UE policies based on different characteristics of a wireless connection between UEs and a RAN of a wireless network. Such UE policies may include sets of UE Route Selection Policy (“URSP”) rules or other suitable UE-based or UE-implemented rules, conditions, etc. For the sake of simplicity, such UE policies are described herein in the context of URSP rules. However, similar concepts may apply to embodiments in which other types of UE policies are implemented.

A particular URSP rule may include information corresponding particular traffic attributes, traffic types, traffic descriptors, application or service types, or other conditions to network parameters, QoS parameters, routing parameters, or other parameters, such as particular network slices, DNNs, or other types of parameters. For example, one URSP rule may indicate that communication sessions associated with voice call traffic are associated with a first network slice (e.g., a network slice that provides low latency services), while another URSP rule may indicate that communication sessions associated with content streaming traffic are associated with a second network slice (e.g., a network slice that provides high throughput services).

As provided for herein, different sets of URSP rules may be provided for different attributes or characteristics of a radio frequency (“RF”) connection (e.g., a wireless connection) between a UE and a RAN. Such attributes or characteristics may include, for example, a radio access technology (“RAT”) such as Fifth Generation (“5G”) or Long-Term Evolution (“LTE”), an RF band (e.g., a Sub-6 GHz band, a mid-band, a millimeter-wave (“mmWave”) band, etc.), or other suitable attributes or characteristics. Further, in some embodiments, the network may monitor changes in such characteristics, such as when the UE connects to a RAN via a second RAT or band after being connected to the RAN via a first RAT or RF band (e.g., is handed over to the second RAT or band, re-selects the second RAT or band, etc.), and may automatically determine and provide updated UE policies to the UE based on monitoring and detecting such changes. For the sake of brevity, RF bands are sometimes referred to herein simply as “bands.”

By automatically identifying such changes and providing updated UE policies, the network may be able to enforce different sets of UE policies based on an access type of the UE (e.g., a particular RAT or band). Different UE policies may be used, for example, to provide a particular level of end-to-end QoS commensurate with a particular service type, in a manner that accounts for wireless access parameters. For example, a first UE policy may be associated with a relatively lower latency network slice in situations where a UE is connected to a RAT or band that provides relatively higher latency service, while a second UE policy may be associated with a relatively higher latency network slice in situations where the UE is connected to a RAT or band that provides relatively lower latency service. In other words, a UE policy may be selected to compensate for or otherwise account for QoS characteristics or other characteristics of a RAN to which the UE is connected, in order to preserve or otherwise delivery end-to-end QoS parameters associated with a given service or traffic type.

As shown inFIG.1, for example, a particular UE101may connect (at102) to a particular RAN103via a first band, represented as “Band_1.” For example, RAN103may include one or more base stations that operate according to multiple bands. For example, the one or more base stations may include discrete antennas, radios, and/or other suitable wireless hardware that provides wireless service according to the multiple bands. Such hardware may be co-located or may be geographically distributed. For example, coverage areas associated with multiple bands may partially or fully overlap in some scenarios, or may be non-overlapping in other scenarios.

As further shown, core network105may provide services to UE101and/or other suitable devices or systems that are connected to RAN103, such as routing traffic between UE101and one or more networks such as the Internet, application servers, other UEs, etc. Based on the connection of UE101to RAN103via Band_1, core network105may provide (at104) a first set of UE policies (e.g., a first set of URSP rules or other suitable policies) to UE101. For example, as discussed below, core network105may select the first set of UE policies based on characteristics of the connection between UE101and RAN103, including the particular band (i.e., Band_1, in this example) via which UE101is connected to RAN103. UE101and core network105may communicate based on the first set of UE policies, which may include UE101requesting particular network slices, DNNs, etc. for particular traffic or service types.

Further, as discussed below, one or more elements of RAN103and/or core network105may maintain trigger information, indicating triggers or conditions under which UE101should receive new or updated UE policies. Such triggers or conditions may include, for example, a connection of UE101to RAN103via a different band or RAT (e.g., a band or RAT change, a handover to a different band or RAT, etc.) than Band_1.

At some point, UE101may connect (at106) to RAN103via a different band, such as Band_2. While examples herein are discussed in the context of UE101connecting to RAN103via different bands (e.g., from Band_1to Band_2), similar concepts may apply when UE101connects to RAN103via different RATs or access types (e.g., licensed access types such as LTE or 5G or unlicensed access types such as WiFi). The band change (e.g., the connection at106to Band_2) may be the result of UE101moving to a different location served by RAN103, load balancing performed by RAN103(e.g., RAN103may instruct UE101to connect to Band_2instead of Band_1in situations where Band_1is congested), a re-selection procedure performed by UE101(e.g., UE101may identify that signal strength or other performance metrics associated with Band_2are stronger or otherwise more favorable than signal strength or other performance metrics associated with Band_1), and/or other scenarios.

Based on the connection of UE101to RAN103via Band_2(e.g., the change from Band_1to Band_2), core network105may receive (at108) an indication of the band change (e.g., from RAN103). For example, RAN103and/or some other suitable device or system may have identified the band change associated with UE101, and may further identify that such band change is associated with the previously discussed triggers, conditions, etc. provided by core network105. Based on the band change (e.g., from Band_1to Band_2), core network105may identify and provide (at110) a second set of UE policies, which may be different from the first set of UE policies initially provided (at104) based on the connection of UE101to RAN103via Band_1. For example, core network105may identify that the second set of UE policies are associated with the connection between UE101and RAN103via Band_2. Additionally, or alternatively, core network105may identify that the sequence of connections (e.g., the connection (at102) of UE101to RAN103via Band_1and then the subsequent connection (at106) of UE101to RAN103via Band_2) is associated with the second set of UE policies. That is, in some scenarios, the sequence of connections via particular bands may indicate or may be associated with some sort of error condition, based on which providing the second set of UE policies may be part of a remedial measure performed in order to remediate or otherwise account for the error condition. UE101and core network105may accordingly communicate (at110) according to the second set of UE policies, which may include particular network slices or other types of parameters that are associated with particular traffic types, applications, services, etc.

FIG.2illustrates an example signal flow associated with automatically determining and providing UE policies based on a band change associated with UE101. As shown, UE101may connect (at202) to RAN103via Band_1. The connection (at202) may include a registration or other suitable procedure with an access control function associated with RAN103, such as Access and Mobility Management Function (“AMF”)201. As part of the registration procedure, AMF201may authenticate UE101, verify that UE101is authorized to access RAN103(e.g., via Band_1), and/or may perform other suitable operations.

Further, as shown and based on the connection of UE101to RAN103, AMF201may request (at204) UE policies and/or other suitable information from a policy element of core network105, such as Policy Control Function (“PCF”)203. For example, AMF201may output an Npcf_UEPolicyControl_Create message to PCF203. In some embodiments, AMF201may request (at204) a set of triggers or conditions in conjunction with the request for UE policies, and/or may request such triggers or conditions in a separate message (or set of messages) from the request for UE policies. In some embodiments, the Npcf_UEPolicyControl_Create message may include a parameter, field, flag, etc. indicating that AMF201is requesting the set of triggers or conditions. Additionally, or alternatively, PCF203may automatically identify the set of triggers or conditions based on receiving the request for UE policies (e.g., the request may, in some embodiments, not include an explicit request for such triggers or conditions). As discussed above, the triggers or conditions may be triggers or conditions relating to UE access of RAN103, such as a change from the current band (i.e., Band_1) to another band, or may otherwise include the connection of UE to RAN103via some other band. As noted above, similar concepts may apply in scenarios where UE101access RAN103via a different RAT or access type.

In some embodiments, the request (at204), which may include a Npcf_UEPolicyControl_Create message or other suitable message, may indicate the particular access parameters associated with UE101and RAN103(i.e., the connection of UE101to RAN103via Band_1, in this example). In some embodiments, the request (at204) may include other suitable information, such as an identifier of UE101(e.g., a Subscription Permanent Identifier (“SUPI”), a Globally Unique Temporary Identifier (“GUTI”), an International Mobile Station Equipment Identity (“IMEI”), a Mobile Directory Number (“MDN”), etc.), location information of UE101, a cell identifier indicating a particular cell or base station of RAN103to which UE101is connected, or other suitable information.

PCF203may identify (at206) a set of UE policies based on the request. For example, PCF203may obtain the policy information, or may derive the policy information based on information received from a Unified Data Repository (“UDR”), a Charging Function (“CHF”), a Network Data Analytics Function (“NWDAF”), or other suitable device or system. In some embodiments, a UE-PCF, which may be a subsystem of PCF203and/or may otherwise be communicatively coupled to PCF203or AMF201, may identify (at206) or obtain the UE policy information. For example, PCF203may identify UE policies (e.g., URSP rules or other suitable policies) that are applicable to UE101when UE101is connected to RAN103via Band_1. PCF203may further identify triggers or conditions based on the indicated connection of UE101to RAN103via Band_1. For example, the triggers or conditions may include a band change from Band_1to any other band, a band change from Band_1to one or more specific bands (e.g., Band_2or some other particular band), a band change from any band (e.g., Band_1, in this instance) to any other band, a band change from any band to a specific band, etc. As noted above, the triggers or conditions may include a sequence of band changes, such as a band change from Band_1to Band_2, a sequence of band changes from Band_1to Band_2and then to another band, etc.

PCF203may provide (at208) the identified UE policies (e.g., URSP rules or other suitable UE policies) to AMF201. PCF203may also provide (at208) the identified triggers or conditions to AMF201, which may maintain (at210) the triggers or conditions. In some embodiments, PCF203may provide the UE policies and/or the triggers or conditions via a response to the Npcf_UEPolicyControl_Create message, such as a “201 Created” Hypertext Transfer Protocol (“HTTP”) message or other suitable message confirming or acknowledging the request for UE information and/or for triggers or conditions. In some embodiments, PCF203may provide the triggers or conditions in a separate message, or set of messages, from the requested UE policies. For example, in some embodiments, PCF203may provide the triggers with, or in conjunction with, the confirmation or acknowledgement of the request (at204) for UE policy information, while PCF203may provide the actual UE policies via some other type of message. In some embodiments, for example, PCF203may provide the requested UE policies via a N1N2 Message to AMF201, based on which AMF201may forward (at212) the UE policies to UE101.

FIGS.3and4illustrate example data structures301and401, respectively, that may be maintained by AMF201in accordance with some embodiments, in order to maintain (e.g., at210) triggers and/or conditions under which new or updated UE policy information should be requested. In some embodiments, AMF201may maintain additional or different data structures or other types of information associated with such triggers and/or conditions. In some embodiments, AMF201may store data structures301and401(e.g., the usage of data structure301may not be mutually exclusive with data structure401and/or other data structures).

As shown inFIG.3, data structure301may include different triggers or conditions for different UEs101or groups of UEs101(e.g., where a “group” may refer to multiple specified UEs101, UEs101that are associated with a particular group or label such as “first responder” or “enterprise,” UEs101that are associated with a particular device type such as mobile telephone or IoT device, etc.). For example, different UEs101may be associated with different triggers based on which updated UE policy information should be requested. On the other hand, in some embodiments, some or all such triggers may be “universal,” inasmuch as some or all of the triggers may apply to all UEs101. The example triggers shown in data structure301may indicate the connection via a particular specified band (or any band) after being connected to another specified band (or any band).

In this example, a first UE101(represented as “UE_A”) may be associated with a first set of triggers, such as the connection to RAN103via any band (denoted as “<Any>”) after being connected to RAN103via a specified band (i.e., Band_1, in this example). That is, if UE_A is connected to RAN103via Band_1and then connects to any other band, this trigger may be satisfied.

As another example, data structure301may indicate a trigger that is satisfied if any UE101connects to RAN103via Band_2after being connected via any other band. As further shown, data structure301may indicate a trigger that is satisfied if any UE101of a specified group (shown as “{UE_Group_A}”) connects to RAN103via Band_3after being connected via any other band. As yet another example, data structure301may indicate a trigger that is satisfied if any UE101connects to RAN103via Band_1after being connected via Band_2. As another example, data structure301may indicate a trigger that is satisfied UE_B connects to RAN103via any band after being connected via another other band (e.g., any band change associated with UE_B).

In some embodiments, data structure301may include additional or different information than is discussed above. For example, in some embodiments, data structure301may include an identifier for each trigger. As discussed below, such identifier may be used to identify a set of updated UE policies when particular respective triggers are satisfied.

FIG.4illustrates example data structure401, which may indicate triggers that include sequences of band changes. As similarly noted above, data structure401may be maintained on a per-UE or a per-UE group basis. For the sake of simplicity, data structure401is discussed without regard to whether the triggers indicated in data structure401are specific to any particular UE101or UE group. As shown, data structure401indicates that a trigger may be satisfied based on a sequence of a given UE101connecting to RAN103via Band_1, then any other band, and then Band_1again. Further, data structure401may indicate that the trigger is satisfied if such sequence occurs within 10 seconds. Such a sequence may indicate a “ping pong” scenario, in which UE101is handed back and forth to and from the same band. For example, particular sets of updated UE policies may be used to remediate factors that would lead to the occurrence of such scenarios.

As another example, data structure401may indicate that a trigger is satisfied if a particular UE101connects to RAN103via Band_2, then Band_1, then Band_3, then Band_4within a 30-minute timeframe. In practice, data structure401may indicate other sequences, timeframes, or other suitable information based on which triggers may be satisfied. As similarly noted above, data structure401may include identifiers for each trigger, which may be used to identify particular UE policies in response to the occurrence of such triggers.

Returning toFIG.2, based on receiving (at212) the UE policies, UE101may communicate with core network105in accordance with the UE policies. For example, UE101may request the establishment of one or more communication sessions, such as protocol data unit (“PDU”) sessions, between UE101and one or more elements of core network105(e.g., a User Plane Function (“UPF”), a Packet Data Network (“PDN”) Gateway (“PGW”), or other suitable network element) based on the UE policies. Such establishment may include, for example, UE101identifying particular network slices, DNNs, or other suitable parameters associated with particular types or services of traffic to be communicated via the communication sessions, and requesting that the communication sessions be associated with such network slices, DNNs, etc. UE101may additionally, or alternatively, route particular traffic (e.g., matching particular attributes, descriptors, etc.) via respective communication sessions that are associated with particular network slices, DNNs, etc. based on the UE policies.

As further shown, at some point after the connection (at202) of UE101to RAN103, UE101may connect (at214) to RAN103via a different band (i.e., Band_2, in this example). For example, as discussed above, UE101may perform a re-selection procedure to identify that UE101should connect via Band_2, may move to a location at which Band_2is available and Band_1is not available, may be handed off by a base station of RAN103from Band_1to Band_2, etc. In some embodiments, UE101may register (at214) with AMF201, and/or AMF201may otherwise determine that UE101has connected to RAN103via Band_2(e.g., UE101and/or a base station of RAN103may notify AMF201of the connection via Band_2).

Further, AMF201may determine (at216) that a particular trigger (e.g., as discussed above with respect to data structures301and401, and/or some other suitable trigger maintained at210) has been satisfied based on the connection of UE101to RAN103via Band_2after being connected via Band_1. For example, AMF201may determine that the sequence of connection via Band_1and then Band_2satisfies a particular trigger, that the band change from Band_1satisfies a particular trigger, that the band to Band_2satisfies a particular trigger, etc.

Based on determining (at216) that the trigger has been satisfied, AMF201may request (at218) UE policies associated with UE101. In some embodiments, AMF201may indicate, to PCF203, that one or more triggers have been satisfied. For example, in some embodiments, AMF201may indicate a particular identifier of a particular trigger that has been satisfied. In some embodiments, AMF201may indicate a particular sequence of bands via which UE101has been connected (e.g., the last two bands, the last three bands, all bands via which UE101has been connected over the last 30 minutes, etc.). Such sequence may be, in this example, Band_1and then Band_2. In some embodiments, the request (at218) may include a Npcf_UEPolicyControl_Update message. In some embodiments, the Npcf_UEPolicyControl_Update message may include some or all of the above-mentioned information (e.g., an identifier of a particular trigger that has been met, a sequence of bands via which UE101has been connected, etc.). Additionally, or alternatively, the Npcf_UEPolicyControl_Update message may be provided in addition to one or more other messages that include some or all of the above-mentioned information.

In some embodiments, AMF201may forgo indicating, to PCF203, that any triggers have been satisfied. In such embodiments, from the standpoint of PCF203, the request (at218) may be irrespective of the satisfaction of any triggers, and may instead be considered as a request for policy information based on the connection of UE101to RAN103via Band_2. In some embodiments, AMF201may again request (at218) a set of triggers (e.g., as similarly discussed above at204). Additionally, or alternatively, AMF201may forgo requesting (at218) trigger information, as the previously received (at204) triggers may remain applicable.

PCF203may identify (at220) updated UE policies based on the connection of UE101via Band_2. For example, PCF203may identify updated UE policies that are associated with the connection of UE101via Band_2, may identify updated UE policies based on the sequence of bands via which UE101has been connected to RAN103, may identify updated UE policies based on a particular trigger identifier that has been provided by AMF201, and/or may otherwise identify updated UE policies based on receiving the indication (at218) that one or more triggers have been satisfied. As discussed above, the identified (at220) UE policies may be determined in order to remediate one or more abnormal or performance-degrading conditions that are associated with particular triggers.

PCF203may accordingly provide (at222) the updated UE policies to UE101. As discussed above, the updated UE policies may be provided via AMF201, such as via an N1N2 message (including the UE policies) provided to AMF201, which may forward the UE policies to UE101via RAN103. UE101and core network105may communicate in accordance with the updated UE policies. For example, UE101may request and/or otherwise participate in communication sessions that are associated with QoS parameters, network slices, DNNs, etc. indicated by the updated UE policies.

In the event that PCF203identifies (at220) updated trigger information, PCF203may also provide such updated trigger information to AMF201, which may maintain the updated trigger information and continue to monitor band changes or other information associated with UE101in order to determine whether any triggers (e.g., in the updated trigger information or the original trigger information, as applicable) have been met.

As shown inFIG.5, PCF203may receive updates to triggers based on which AMF201should request new UE policy information, and may provide such updated triggers to AMF201. For example, assume PCF203provides (at502) a set of policy change triggers to AMF201(e.g., as similarly described above at208), and AMF201maintains (at504) the received policy change triggers (e.g., as similarly described above at210). At some point, PCF203may update and/or modify (at506) some or all of the policy change triggers. For example, a network operator associated with core network105may provide updated policy change triggers, another network element of core network105may provide the updated policy change triggers, PCF203may automatically modify the policy change triggers (e.g., using artificial intelligence/machine learning (“AI/ML”) techniques or other suitable techniques), and/or the policy change triggers may be updated or modified in some other manner.

PCF203may provide (at508) the updated policy change triggers to AMF201. For example, PCF203may “push” the updated policy change triggers to AMF201(e.g., without an explicit request for the updated policy change triggers), or PCF203may provide the updated policy change triggers in response to a request from AMF201for policy change triggers. AMF201may accordingly maintain (at510) the updated policy change triggers, and may monitor connections associated with one or more UEs101to determine whether any of such updated policy change triggers are satisfied. As the policy change triggers are maintained by AMF201(e.g., as maintained at504and/or510), particular UEs101may not need to receive updated policy change triggers, thereby reducing network traffic and load as compared to implementations in which UEs101maintain such trigger information.

FIG.6illustrates an example process600for obtaining updated UE policy information based on band-related triggers (e.g., band changes) associated with a particular UE101. In some embodiments, some or all of process600may be performed by AMF201.

As shown, process600may include receiving (at602), from a policy element of a core of a wireless network (e.g., PCF203of core network105), triggers associated with RF bands implemented by a RAN of the wireless network (e.g., RAN103). For example, AMF201may request the triggers from PCF203based on identifying (at604) that a particular UE101has connected to RAN103. Additionally, or alternatively, PCF203may push the triggers to AMF201, or AMF201may receive such triggers in some other manner. As discussed above, AMF201may request the triggers via an Npcf_UEPolicyControl_Create message, an Npcf_UEPolicyControl_Update message, or other suitable message. In some embodiments, as discussed above, PCF203may identify particular triggers that are associated with particular UEs101, and may provide such particular triggers to AMF201based on an indication by AMF201of a connection associated with a particular UE101(e.g., via the first RF band).

Process600may additionally include identifying (at606) a subsequent connection of UE101to RAN103via a second RF band. For example, AMF201may identify that UE101has been handed over to the second RF band, that UE101has requested a connection via the second RF band, etc.

Process600may also include determining (at608) that a particular trigger, of the received band-related triggers, has been satisfied based on the connection of UE101via the second RF band. For example, as discussed above, AMF201may identify that a sequence of bands, via which UE101has connected to RAN103, matches a sequence specified in the band-related triggers. Additionally, or alternatively, AMF201may otherwise identify that the particular trigger has been satisfied.

Process600may further include notifying (at610) the policy element (e.g., PCF203) that the particular trigger has been satisfied. The notification may include a request to provide updated UE policies (e.g., updated URSP rules) to UE101. As discussed above, the updated UE policies may be selected by PCF203based on the connection of UE101to RAN103via the second band, based on a sequence of bands via which UE101has connected to RAN103, and/or other suitable factors. UE101may update locally stored URSP rules based on the received updated UE policies, based on which UE101may communicate with core network105(e.g., a UPF, a PGW, etc.) in accordance with the updated URSP rules.

FIG.7illustrates an example environment700, in which one or more embodiments may be implemented. In some embodiments, environment700may correspond to a 5G network, and/or may include elements of a 5G network. In some embodiments, environment700may correspond to a 5G Non-Standalone (“NSA”) architecture, in which a 5G RAT may be used in conjunction with one or more other RATs (e.g., an LTE RAT), and/or in which elements of a 5G core network may be implemented by, may be communicatively coupled with, and/or may include elements of another type of core network (e.g., an evolved packet core (“EPC”)). In some embodiments, portions of environment700may represent or may include a 5G core (“5GC”). As shown, environment700may include UE101, RAN710(which may include one or more Next Generation Node Bs (“gNBs”)711), RAN712(which may include one or more evolved Node Bs (“eNBs”)713), and various network functions such AMF201, Mobility Management Entity (“MME”)716, Serving Gateway (“SGW”)717, Session Management Function (“SMF”)/PGW-Control plane function (“PGW-C”)720, PCF/Policy Charging and Rules Function (“PCRF”)725, Application Function (“AF”)730, UPF/PGW-User plane function (“PGW-U”)735, Unified Data Management (“UDM”)/Home Subscriber Server (“HSS”)740, and Authentication Server Function (“AUSF”)745. Environment700may also include one or more networks, such as Data Network (“DN”)750. Environment700may include one or more additional devices or systems communicatively coupled to one or more networks (e.g., DN750).

The example shown inFIG.7illustrates one instance of each network component or function (e.g., one instance of SMF/PGW-C720, PCF/PCRF725, UPF/PGW-U735, UDM/HSS740, and/or AUSF745). In practice, environment700may include multiple instances of such components or functions. For example, in some embodiments, environment700may include multiple “slices” of a core network, where each slice includes a discrete and/or logical set of network functions (e.g., one slice may include a first instance of AMF201, SMF/PGW-C720, PCF/PCRF725, and/or UPF/PGW-U735, while another slice may include a second instance of AMF201, SMF/PGW-C720, PCF/PCRF725, and/or UPF/PGW-U735). The different slices may provide differentiated levels of service, such as service in accordance with different Quality of Service (“QoS”) parameters.

The quantity of devices and/or networks, illustrated inFIG.7, is provided for explanatory purposes only. In practice, environment700may include additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than illustrated inFIG.7. For example, while not shown, environment700may include devices that facilitate or enable communication between various components shown in environment700, such as routers, modems, gateways, switches, hubs, etc. In some implementations, one or more devices of environment700may be physically integrated in, and/or may be physically attached to, one or more other devices of environment700. Alternatively, or additionally, one or more of the devices of environment700may perform one or more network functions described as being performed by another one or more of the devices of environment700.

Elements of environment700may interconnect with each other and/or other devices via wired connections, wireless connections, or a combination of wired and wireless connections. Examples of interfaces or communication pathways between the elements of environment700, as shown inFIG.7, may include an N1 interface, an N2 interface, an N3 interface, an N4 interface, an N5 interface, an N6 interface, an N7 interface, an N8 interface, an N9 interface, an N10 interface, an N11 interface, an N12 interface, an N13 interface, an N14 interface, an N15 interface, an N26 interface, an S1-C interface, an S1-U interface, an S5-C interface, an S5-U interface, an S6a interface, an S11 interface, and/or one or more other interfaces. Such interfaces may include interfaces not explicitly shown inFIG.7, such as Service-Based Interfaces (“SBIs”), including an Namf interface, an Nudm interface, an Npcf interface, an Nupf interface, an Nnef interface, an Nsmf interface, and/or one or more other SBIs. In some embodiments, environment700may be, may include, may be implemented by, and/or may be communicatively coupled to RAN103and/or core network105.

UE101may include a computation and communication device, such as a wireless mobile communication device that is capable of communicating with RAN710, RAN712, and/or DN750. UE101may be, or may include, a radiotelephone, a personal communications system (“PCS”) terminal (e.g., a device that combines a cellular radiotelephone with data processing and data communications capabilities), a personal digital assistant (“PDA”) (e.g., a device that may include a radiotelephone, a pager, Internet/intranet access, etc.), a smart phone, a laptop computer, a tablet computer, a camera, a personal gaming system, an Internet of Things (“IoT”) device (e.g., a sensor, a smart home appliance, a wearable device, a Machine-to-Machine (“M2M”) device, or the like), or another type of mobile computation and communication device. UE101may send traffic to and/or receive traffic (e.g., user plane traffic) from DN750via RAN710, RAN712, and/or UPF/PGW-U735.

RAN710may be, or may include, a 5G RAN that includes one or more base stations (e.g., one or more gNBs711), via which UE101may communicate with one or more other elements of environment700. UE101may communicate with RAN710via an air interface (e.g., as provided by gNB711). For instance, RAN710may receive traffic (e.g., user plane traffic such as voice call traffic, data traffic, messaging traffic, etc.) from UE101via the air interface, and may communicate the traffic to UPF/PGW-U735and/or one or more other devices or networks. Further, RAN710may receive signaling traffic, control plane traffic, etc. from UE101via the air interface, and may communicate such signaling traffic, control plane traffic, etc. to AMF201and/or one or more other devices or networks. Additionally, RAN710may receive traffic intended for UE101(e.g., from UPF/PGW-U735, AMF201, and/or one or more other devices or networks) and may communicate the traffic to UE101via the air interface. In some embodiments, RAN103may be, may include, and/or may be implemented by RAN710.

RAN712may be, or may include, a LTE RAN that includes one or more base stations (e.g., one or more eNBs713), via which UE101may communicate with one or more other elements of environment700. UE101may communicate with RAN712via an air interface (e.g., as provided by eNB713). For instance, RAN712may receive traffic (e.g., user plane traffic such as voice call traffic, data traffic, messaging traffic, signaling traffic, etc.) from UE101via the air interface, and may communicate the traffic to UPF/PGW-U735(e.g., via SGW717) and/or one or more other devices or networks. Further, RAN712may receive signaling traffic, control plane traffic, etc. from UE101via the air interface, and may communicate such signaling traffic, control plane traffic, etc. to MME716and/or one or more other devices or networks. Additionally, RAN712may receive traffic intended for UE101(e.g., from UPF/PGW-U735, MME716, SGW717, and/or one or more other devices or networks) and may communicate the traffic to UE101via the air interface. In some embodiments, RAN103may be, may include, and/or may be implemented by RAN712.

AMF201may include one or more devices, systems, Virtualized Network Functions (“VNFs”), Cloud-Native Network Functions (“CNFs”), etc., that perform operations to register UE101with the 5G network, to establish bearer channels associated with a session with UE101, to hand off UE101from the 5G network to another network, to hand off UE101from the other network to the 5G network, manage mobility of UE101between RANs710and/or gNBs711, and/or to perform other operations. In some embodiments, the 5G network may include multiple AMFs201, which communicate with each other via the N14 interface (denoted inFIG.7by the line marked “N14” originating and terminating at AMF201).

MME716may include one or more devices, systems, VNFs, CNFs, etc., that perform operations to register UE101with the EPC, to establish bearer channels associated with a session with UE101, to hand off UE101from the EPC to another network, to hand off UE101from another network to the EPC, manage mobility of UE101between RANs712and/or eNBs713, and/or to perform other operations.

SGW717may include one or more devices, systems, VNFs, CNFs, etc., that aggregate traffic received from one or more eNBs713and send the aggregated traffic to an external network or device via UPF/PGW-U735. Additionally, SGW717may aggregate traffic received from one or more UPF/PGW-Us735and may send the aggregated traffic to one or more eNBs713. SGW717may operate as an anchor for the user plane during inter-eNB handovers and as an anchor for mobility between different telecommunication networks or RANs (e.g., RANs710and712).

SMF/PGW-C720may include one or more devices, systems, VNFs, CNFs, etc., that gather, process, store, and/or provide information in a manner described herein. SMF/PGW-C720may, for example, facilitate the establishment of communication sessions on behalf of UE101. In some embodiments, the establishment of communications sessions may be performed in accordance with one or more policies provided by PCF/PCRF725.

PCF/PCRF725may include one or more devices, systems, VNFs, CNFs, etc., that aggregate information to and from the 5G network and/or other sources. PCF/PCRF725may receive information regarding policies and/or subscriptions from one or more sources, such as subscriber databases and/or from one or more users (such as, for example, an administrator associated with PCF/PCRF725). In some embodiments, PCF203may implement, may be implemented by, may be communicatively coupled to, and/or may otherwise be associated with PCF/PCRF725.

AF730may include one or more devices, systems, VNFs, CNFs, etc., that receive, store, and/or provide information that may be used in determining parameters (e.g., quality of service parameters, charging parameters, or the like) for certain applications.

UPF/PGW-U735may include one or more devices, systems, VNFs, CNFs, etc., that receive, store, and/or provide data (e.g., user plane data). For example, UPF/PGW-U735may receive user plane data (e.g., voice call traffic, data traffic, etc.), destined for UE101, from DN750, and may forward the user plane data toward UE101(e.g., via RAN710, SMF/PGW-C720, and/or one or more other devices). In some embodiments, multiple UPFs735may be deployed (e.g., in different geographical locations), and the delivery of content to UE101may be coordinated via the N9 interface (e.g., as denoted inFIG.7by the line marked “N9” originating and terminating at UPF/PGW-U735). Similarly, UPF/PGW-U735may receive traffic from UE101(e.g., via RAN710, RAN712, SMF/PGW-C720, and/or one or more other devices), and may forward the traffic toward DN750. In some embodiments, UPF/PGW-U735may communicate (e.g., via the N4 interface) with SMF/PGW-C720, regarding user plane data processed by UPF/PGW-U735.

UDM/HSS740and AUSF745may include one or more devices, systems, VNFs, CNFs, etc., that manage, update, and/or store, in one or more memory devices associated with AUSF745and/or UDM/HSS740, profile information associated with a subscriber. AUSF745and/or UDM/HSS740may perform authentication, authorization, and/or accounting operations associated with the subscriber and/or a communication session with UE101.

DN750may include one or more wired and/or wireless networks. For example, DN750may include an Internet Protocol (“IP”)-based PDN, a wide area network (“WAN”) such as the Internet, a private enterprise network, and/or one or more other networks. UE101may communicate, through DN750, with data servers, other UEs101, and/or to other servers or applications that are coupled to DN750. DN750may be connected to one or more other networks, such as a public switched telephone network (“PSTN”), a public land mobile network (“PLMN”), and/or another network. DN750may be connected to one or more devices, such as content providers, applications, web servers, and/or other devices, with which UE101may communicate.

FIG.8illustrates another example environment800, in which one or more embodiments may be implemented. In some embodiments, environment800may correspond to a 5G network, and/or may include elements of a 5G network. In some embodiments, environment800may correspond to a 5G SA architecture, or may correspond to a 5G NSA architecture. In some embodiments, environment800may include a 5GC, in which 5GC network elements perform one or more operations described herein.

As shown, environment800may include UE101, RAN103(which may include one or more gNBs711) and various network functions, which may be implemented as VNFs, CNFs, etc. Such network functions may include AMF201, SMF801, UPF803, PCF203, UDM805, AUSF807, Network Repository Function (“NRF”)809, AF730, Network Exposure Function (“NEF”)811, and UDR813. Environment800may also include or may be communicatively coupled to one or more networks, such as DN750.

The example shown inFIG.8illustrates one instance of each network component or function (e.g., one instance of SMF801, UPF803, PCF203, UDM805, AUSF807, etc.). In practice, environment800may include multiple instances of such components or functions. For example, in some embodiments, environment800may include multiple “slices” of a core network, where each slice includes a discrete and/or logical set of network functions (e.g., one slice may include a first instance of SMF801, PCF203, UPF803, etc., while another slice may include a second instance of SMF801, PCF203, UPF803, etc.). Additionally, or alternatively, one or more of the network functions of environment800may implement multiple network slices. The different slices may provide differentiated levels of service, such as service in accordance with different QoS parameters.

The quantity of devices and/or networks, illustrated inFIG.8, is provided for explanatory purposes only. In practice, environment800may include additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than illustrated inFIG.8. For example, while not shown, environment800may include devices that facilitate or enable communication between various components shown in environment800, such as routers, modems, gateways, switches, hubs, etc. In some implementations, one or more devices of environment800may be physically integrated in, and/or may be physically attached to, one or more other devices of environment800. Alternatively, or additionally, one or more of the devices of environment800may perform one or more network functions described as being performed by another one or more of the devices of environment800.

Elements of environment800may interconnect with each other and/or other devices via wired connections, wireless connections, or a combination of wired and wireless connections. Examples of interfaces or communication pathways between the elements of environment800, as shown inFIG.8, may include interfaces shown inFIG.8and/or one or more interfaces not explicitly shown inFIG.8. These interfaces may include interfaces between specific network functions, such as an N1 interface, an N2 interface, an N3 interface, an N4 interface, an N5 interface, an N6 interface, an N7 interface, an N8 interface, an N9 interface, an N10 interface, an N11 interface, an N12 interface, an N13 interface, an N14 interface, an N15 interface, an N16 interface, an N26 interface, and/or one or more other interfaces. In some embodiments, one or more elements of environment800may communicate via a service-based architecture (“SBA”), in which a routing mesh or other suitable routing mechanism may route communications to particular network functions based on interfaces or identifiers associated with such network functions. Such interfaces may include or may be referred to as Service-Based Interfaces (“SBIs”), including an Namf interface (e.g., indicating communications to be routed to AMF201), an Nudm interface (e.g., indicating communications to be routed to UDM805), an Npcf interface, an Nupf interface, an Nnef interface, an Nsmf interface, an Nnrf interface, an Naf interface, and/or one or more other SBIs.

UPF803may include one or more devices, systems, VNFs, CNFs, etc., that receive, route, process, and/or forward traffic (e.g., user plane traffic). As discussed above, UPF803may communicate with UE101via one or more communication sessions, such as PDU sessions. Such PDU sessions may be associated with a particular network slice or other suitable QoS parameters, as noted above. UPF803may receive downlink user plane traffic (e.g., voice call traffic, data traffic, etc. destined for UE101) from DN750, and may forward the downlink user plane traffic toward UE101(e.g., via RAN103). In some embodiments, multiple UPFs803may be deployed (e.g., in different geographical locations), and the delivery of content to UE101may be coordinated via the N9 interface. Similarly, UPF803may receive uplink traffic from UE101(e.g., via RAN103), and may forward the traffic toward DN750. In some embodiments, UPF803may communicate (e.g., via the N4 interface) with SMF801, regarding user plane data processed by UPF803(e.g., to provide analytics or reporting information, to receive policy and/or authorization information, etc.).

PCF203may include one or more devices, systems, VNFs, CNFs, etc., that aggregate, derive, generate, etc. policy information associated with the 5GC and/or UEs101that communicate via the 5GC and/or RAN103. PCF203may receive information regarding policies and/or subscriptions from one or more sources, such as subscriber databases (e.g., UDM805, UDR813, etc.), and/or from one or more users such as, for example, an administrator associated with PCF203. In some embodiments, the functionality of PCF203may be split into multiple network functions, such as access and mobility PCF (“AM-PCF”)815, session management PCF (“SM-PCF”)817, UE PCF (“UE-PCF”)819, and so on. Such different “split” PCFs may be associated with respective SBIs (e.g., the AM-PCF may be associated with an Nampcf SBI, the SM-PCF may be associated with an Nsmpcf SBI, the UE-PCF may be associated with an Nuepcf SBI, and so on) via which other network functions may communicate with the split PCFs. The split PCFs may maintain information regarding policies associated with different devices, systems, and/or network functions.

NRF809may include one or more devices, systems, VNFs, CNFs, etc. that maintain routing and/or network topology information associated with the 5GC. For example, NRF809may maintain and/or provide Internet Protocol (“IP”) addresses of one or more network functions, routes associated with one or more network functions, discovery and/or mapping information associated with particular network functions or network function instances (e.g., whereby such discovery and/or mapping information may facilitate the SBA), and/or other suitable information.

NEF811include one or more devices, systems, VNFs, CNFs, etc. that provide access to information, application programming interfaces (“APIs”), and/or other operations or mechanisms of the 5GC to devices or systems that are external to the 5GC. NEF811may maintain authorization and/or authentication information associated with such external devices or systems, such that NEF811is able to provide information, that is authorized to be provided, to the external devices or systems. Such information may be received from other network functions of the 5GC (e.g., as authorized by an administrator or other suitable entity associated with the 5GC), such as SMF801, UPF803, a CHF of the 5GC, and/or other suitable network function. NEF811may communicate with external devices or systems via DN750and/or other suitable communication pathways.

FIG.9illustrates an example RAN environment900, which may be included in and/or implemented by one or more RANs (e.g., RAN103or some other RAN). In some embodiments, a particular RAN103may include one RAN environment900. In some embodiments, a particular RAN103may include multiple RAN environments900. In some embodiments, RAN environment900may correspond to a particular gNB711of RAN103. In some embodiments, RAN environment900may correspond to multiple gNBs711. In some embodiments, RAN environment900may correspond to one or more other types of base stations of one or more other types of RANs. As shown, RAN environment900may include Central Unit (“CU”)905, one or more Distributed Units (“DUs”)903-1through903-N (referred to individually as “DU903,” or collectively as “DUs903”), and one or more Radio Units (“RUs”)901-1through901-M (referred to individually as “RU901,” or collectively as “RUs901”).

CU905may communicate with a core of a wireless network (e.g., may communicate with one or more of the devices or systems described above with respect toFIG.8, such as AMF805and/or UPF803). In the uplink direction (e.g., for traffic from UEs101to a core network), CU905may aggregate traffic from DUs903, and forward the aggregated traffic to the core network. In some embodiments, CU905may receive traffic according to a given protocol (e.g., Radio Link Control (“RLC”)) from DUs903, and may perform higher-layer processing (e.g., may aggregate/process RLC packets and generate Packet Data Convergence Protocol (“PDCP”) packets based on the RLC packets) on the traffic received from DUs903.

In accordance with some embodiments, CU905may receive downlink traffic (e.g., traffic from the core network) for a particular UE101, and may determine which DU(s)903should receive the downlink traffic. DU903may include one or more devices that transmit traffic between a core network (e.g., via CU905) and UE101(e.g., via a respective RU901). DU903may, for example, receive traffic from RU901at a first layer (e.g., physical (“PHY”) layer traffic, or lower PHY layer traffic), and may process/aggregate the traffic to a second layer (e.g., upper PHY and/or RLC). DU903may receive traffic from CU905at the second layer, may process the traffic to the first layer, and provide the processed traffic to a respective RU901for transmission to UE101.

RU901may include hardware circuitry (e.g., one or more RF transceivers, antennas, radios, and/or other suitable hardware) to communicate wirelessly (e.g., via an RF interface) with one or more UEs101, one or more other DUs903(e.g., via RUs901associated with DUs903), and/or any other suitable type of device. In the uplink direction, RU901may receive traffic from UE101and/or another DU903via the RF interface and may provide the traffic to DU903. In the downlink direction, RU901may receive traffic from DU903, and may provide the traffic to UE101and/or another DU903.

As noted above, one or more elements of RAN environment900may, in some embodiments, be communicatively coupled to one or more MECs827. For example, DU903-1may be communicatively coupled to MEC827-1, DU903-N may be communicatively coupled to MEC827-N, CU905may be communicatively coupled to MEC827-2, and so on. MECs827may include hardware resources (e.g., configurable or provisionable hardware resources) that may be configured to provide services and/or otherwise process traffic to and/or from UE101, via a respective RU901.

For example, DU903-1may route some traffic, from UE101, to MEC827-1instead of to a core network via CU905. MEC827-1may process the traffic, perform one or more computations based on the received traffic, and may provide traffic to UE101via RU901-1. In some embodiments, MEC827may include, and/or may implement, some or all of the functionality described above with respect to UPF803, AF730, and/or one or more other devices, systems, VNFs, CNFs, etc. In this manner, ultra-low latency services may be provided to UE101, as traffic does not need to traverse DU903, CU905, links between DU903and CU905, and an intervening backhaul network between RAN environment900and the core network.

FIG.10illustrates example components of device1000. One or more of the devices described above may include one or more devices1000. Device1000may include bus1010, processor1020, memory1030, input component1040, output component1050, and communication interface1060. In another implementation, device1000may include additional, fewer, different, or differently arranged components.

Bus1010may include one or more communication paths that permit communication among the components of device1000. Processor1020may include a processor, microprocessor, or processing logic that may interpret and execute instructions (e.g., processor-executable instructions). In some embodiments, processor1020may be or may include one or more hardware processors. Memory1030may include any type of dynamic storage device that may store information and instructions for execution by processor1020, and/or any type of non-volatile storage device that may store information for use by processor1020.

Input component1040may include a mechanism that permits an operator to input information to device1000and/or other receives or detects input from a source external to input component1040, such as a touchpad, a touchscreen, a keyboard, a keypad, a button, a switch, a microphone or other audio input component, etc. In some embodiments, input component1040may include, or may be communicatively coupled to, one or more sensors, such as a motion sensor (e.g., which may be or may include a gyroscope, accelerometer, or the like), a location sensor (e.g., a Global Positioning System (“GPS”)-based location sensor or some other suitable type of location sensor or location determination component), a thermometer, a barometer, and/or some other type of sensor. Output component1050may include a mechanism that outputs information to the operator, such as a display, a speaker, one or more light emitting diodes (“LEDs”), etc.

Communication interface1060may include any transceiver-like mechanism that enables device1000to communicate with other devices and/or systems. For example, communication interface1060may include an Ethernet interface, an optical interface, a coaxial interface, or the like. Communication interface1060may include a wireless communication device, such as an infrared (“IR”) receiver, a Bluetooth® radio, or the like. The wireless communication device may be coupled to an external device, such as a remote control, a wireless keyboard, a mobile telephone, etc. In some embodiments, device1000may include more than one communication interface1060. For instance, device1000may include an optical interface and an Ethernet interface.