EDGE-ANCHORED INDICATIONS FOR USER EQUIPMENT (UE) COMMUNICATIONS

The present application relates to controlling the use of edge-anchored indications for a UE. In an example, a UE can communicate with an edge entity via a network. The network can determine based on one or a combination of UE authorization or AF authorization whether the related traffic is to be edge-anchored or not. Edge anchoring the traffic can help avoid the UE switching the traffic to an alternate network that may be available to the UE. The network can send an edge-anchored indication to the UE accordingly.

BACKGROUND

Cellular communications can be defined in various standards to enable communications between a user equipment and a cellular network. For example, Fifth generation mobile network (5G) is a wireless standard that aims to improve upon data transmission speed, reliability, availability, and more.

DETAILED DESCRIPTION

Generally, a first network (e.g., a Third Generation Partnership Project (3GPP) New Radio (NR) cellular network) can facilitate communications of a user equipment (UE) with an edge entity. As used herein, an edge entity refers to an edge application server (EAS), an edge application function (EAF), or any other node or service for edge computing. A second network (e.g., a WiFi network, a non-3GPP cellular network, etc.) may also be available to the UE and capable of facilitating the communications with the edge entity. In certain situations, it may be desired to avoid a UE switch of traffic between the UE and the edge entity (e.g., traffic of a protocol data unit (PDU) session) from being sent via the first network to being sent via the second network. In such situations, an edge-anchored indication can be used, whereby the first network can send this indication to the UE, and whereby the UE can use this indication to possibly avoid the UE switch.

In some examples, edge-anchored indications are sent to the UE based on any or a combination of a UE authorization, a policy, network connectivity conditions, or an application function (AF) authorization. For example, subscription data of the UE can explicitly or implicitly indicate an authorization for edge-anchored indications. Policy and charging control (PCC) rule information can include policy indicating that edge-anchored indications apply to some or all traffic with the UE. Based on changes to a network connectivity condition, a request of the edge entity can be received and processed to update the policy and/or send, to the UE an edge-anchored indication related to the corresponding traffic or, conversely, to indicate that the edge-anchored indication is no longer usable. Such and other requests can be received from an AF. An authorization of the AF to request setting of traffic switching indications can be verified. These and other functionalities are further described herein below.

Embodiments of the present disclosure are described in connection with 5G networks. However, the embodiments are not limited as such and similarly apply to other types of communication networks including other types of cellular networks.

The term “user equipment” or “UE” as used herein refers to a device with radio communication capabilities and may describe a remote user of network resources in a communications network. The term “user equipment” or “UE” may be considered synonymous to, and may be referred to as, client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Examples include a cellular phone, a tablet, a laptop, a desktop computer, a wearable device, a smart appliance, an internet of things (IoT) device, sensor devices, and the like. Furthermore, the term “user equipment” or “UE” may include any type of wireless/wired device or any computing device including a wireless communications interface.

The term “base station” as used herein refers to a device with radio communication capabilities, that is a network component of a communications network (or, more briefly, a network), and that may be configured as an access node in the communications network. A UE's access to the communications network may be managed at least in part by the base station, whereby the UE connects with the base station to access the communications network. Depending on the radio access technology (RAT), the base station can be referred to as a gNodeB (gNB), eNodeB (eNB), access point, etc.

The term “network” as used herein reference to a communications network that includes a set of network nodes configured to provide communications functions to a plurality of user equipment via one or more base stations. For instance, the network can be a public land mobile network (PLMN) that implements one or more communication technologies including, for instance, 5G communications.

The terms “instantiate,” “instantiation,” and the like as used herein refer to the creation of an instance. An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during execution of program code.

The term “3GPP Access” refers to accesses (e.g., radio access technologies) that are specified by 3GPP standards. These accesses include, but are not limited to, GSM/GPRS, LTE, LTE-A, and/or 5G NR. In general, 3GPP access refers to various types of cellular access technologies.

The term “Non-3GPP Access” refers any accesses (e.g., radio access technologies) that are not specified by 3GPP standards. These accesses include, but are not limited to, WiMAX, CDMA2000, Wi-Fi, WLAN, and/or fixed networks. Non-3GPP accesses may be split into two categories, “trusted” and “untrusted”: Trusted non-3GPP accesses can interact directly with an evolved packet core (EPC) and/or a 5G core (5GC), whereas untrusted non-3GPP accesses interwork with the EPC/5GC via a network entity, such as an Evolved Packet Data Gateway and/or a 5G NR gateway. In general, non-3GPP access refers to various types on non-cellular access technologies.

FIG.1illustrates an example of a 5G network architecture that incorporates both 3GPP (e.g., cellular) and non-3GPP (e.g., non-cellular) access to a 5G core network (CN), in accordance with some embodiments. As shown, a UE106may access the 5G CN through both a radio access network (RAN, e.g., a base station104that can be a gNB) and an access point (AP)112. The AP112may include a connection to the Internet100as well as a connection to a non-3GPP inter-working function (N3IWF)103network entity. The N3IWF may include a connection to a core access and mobility management function (AMF)105of the 5G CN. The AMF105may include an instance of a 5G mobility management (5G MM) function associated with the UE106. In addition, the RAN (e.g., the base station104) may also have a connection to the AMF105. Thus, the 5G CN may support unified authentication over both connections as well as allow simultaneous registration for UE106access via both gNB104and AP112. As shown, the AMF105may include one or more functional entities associated with the 5G CN (e.g., network slice selection function (NSSF)120, short message service function (SMSF)122, application function (AF)124, unified data management (UDM)126, policy control function (PCF)128, and/or authentication server function (AUSF)130). Note that these functional entities may also be supported by a session management function (SMF)106aand an SMF106bof the 5G CN. The AMF105may be connected to (or in communication with) the SMF106a. Further, the base station104may be in communication with (or connected to) a user plane function (UPF)108athat may also be in communication with the SMF106a. Similarly, the N3IWF103may be communicating with a UPF108bthat may also be communicating with the SMF106b. Both UPFs may be communicating with the data network (e.g., DN110aand110b) and/or the Internet100and Internet Protocol (IP) Multimedia Subsystem/IP Multimedia Core Network Subsystem (IMS) core network110.

Generally, base station104communicates over a transmission medium with one or more UEs (e.g., including the UE106). Each of the user devices may be referred to herein as a “user equipment” (UE). The base station (BS)104may be a base transceiver station (BTS) or cell site (a “cellular base station”) and may include hardware that enables wireless communication with the UE106.

The communication area (or coverage area) of the base station104may be referred to as a “cell.” The base station104and the UE106may be configured to communicate over the transmission medium using any of various radio access technologies (RATs), also referred to as wireless communication technologies, or telecommunication standards, such as GSM, UMTS (associated with, for example, WCDMA or TD-SCDMA air interfaces), LTE, LTE-Advanced (LTE-A), 5G new radio (5G NR), HSPA, 3GPP2 CDMA2000 (e.g., 1×RTT, 1×EV-DO, HRPD, eHRPD), etc. If the base station104is implemented in the context of LTE, it may alternately be referred to as an ‘eNodeB’ or ‘eNB’. If base station104is implemented in the context of 5G NR, it may alternately be referred to as ‘gNodeB’ or ‘gNB’.

The base station104may also be equipped to communicate with a network (e.g., a core network of a cellular service provider, such as the 5G CN, a telecommunication network, such as a public switched telephone network (PSTN), and/or the Internet, among various possibilities). Thus, the base station104may facilitate communication between the user devices and/or between the UE106and the network. In particular, the cellular base station104may provide UEs106with various telecommunication capabilities, such as voice, SMS, and/or data services.

The base station104and other similar base stations operating according to the same or a different cellular communication standard may thus be provided as a network of cells, which may provide continuous or nearly continuous overlapping service to UE106and similar devices over a geographic area via one or more cellular communication standards.

Thus, while base station104may act as a “serving cell” for UE106as illustrated inFIG.1, the UE106may also be capable of receiving signals from (and possibly within communication range of) one or more other cells, which may be referred to as “neighboring cells.” Such cells may also be capable of facilitating communication between user devices and/or between user devices and the network100. Such cells may include “macro” cells, “micro” cells, “pico” cells, and/or cells which provide any of various other granularities of service area size.

In some embodiments, the base station104may be a next generation base station, e.g., a 5G New Radio (5G NR) base station, or “gNB”. In some embodiments, a gNB may also be connected to a legacy evolved packet core (EPC) network and/or to a NR core (NRC) network. In addition, a gNB cell may include one or more transition and reception points (TRPs). In addition, a UE capable of operating according to 5G NR may be connected to one or more TRPs within one or more gNBs.

FIG.2illustrates an example of a 5G network architecture that incorporates both dual 3GPP (e.g., LTE and 5G NR) access and non-3GPP access to the 5G CN, in accordance with some embodiments. As shown, a UE206may access the 5G CN through both a RAN (e.g., a base station204, such as gNB) and an AP212. The AP212may include a connection to the Internet200as well as a connection to a N3IWF203network entity. The N3IWF203may include a connection to an AMF205of the 5G CN. The AMF205may include an instance of a 5G MM function associated with the UE206. In addition, the RAN (e.g., the base station204) may also have a connection to the AMF205. Thus, the 5G CN may support unified authentication over both connections as well as allow simultaneous registration for UE206access via both the base station204and the AP212. In addition, the 5G CN may support dual-registration of the UE106on both a legacy network (e.g., LTE via a base station202, such as an eNB) and a 5G network (e.g., via the base station204). As shown, the base station202may have connections to a mobility management entity (MME)242and a serving gateway (SGW)244. The MME242may have connections to both the SGW244and the AMF205. In addition, the SGW244may have connections to both an SMF206aand an UPF208a. As shown, the AMF205may include one or more functional entities associated with the 5G CN (e.g., NSSF220, SMSF222, AF224, UDM226, PCF228, and/or AUSF230). The UDM226may also include a home subscriber server (HSS) function and the PCF228may also include a policy and charging rules function (PCRF). These functional entities may also be supported by an SMF606aand an SMF206bof the 5G CN. The AMF205may be connected to (or in communication with) the SMF206a. Further, the base station204may be in communication with (or connected to) the UPF208athat may also be in communication with the SMF206a. Similarly, the N3IWF203may be communicating with a UPF208bthat may also be communicating with an SMF206b. Both UPFs may be communicating with the data network (e.g., DN210aand210b) and/or the Internet200and an IMS core network210.

FIG.3illustrates an example of a CN300, in accordance with some embodiments, in accordance with some embodiments. The CN300can include a 5G CN, such as any of the 5G CN described inFIGS.1and2. It should be appreciated that the CN300can be a different generation CN, such as a sixth generation (6G) CN.

The CN300includes a network splice selection function (NSSF)306. The NSSF306can be a control plane function that can verify that a UE is subscribed to each of the single network slice selection information (S-NSSAI) belonging to a requested S-NSSAI, select one or more network slices to serve the UE and generate an Allowed NSSAI, and identify a set of candidate access and mobility function (AMF) to serve the UE. The NSSF306can communicate with the CN300via an Nnssf308, a control plane interface exhibited by the NSSF306. The CN300can further include a network exposure function (NEF)310. The NEF310can be a control plane function that can provide information about NFs within the CN300to external NFs. The NEF310can communicate with the CN300via an Nnef312, a control plane interface exhibited by the NEF310. The CN300can further include a network repository function (NRF)314. The NRF314can be a control plane function that allows NFs to register their services and allows other NFs to discover those services. The NRF314can communicate with the CN300via an Nnrf316, a control plane interface exhibited by the NRF314. The CN300can further include a policy control function (PCF)318. The PCF318can be a control plane function responsible for providing policies associated with mobility management and policies associated with session management. The PCF318can communicate with the CN300via an Npcf320, an interface exhibited by the PCF318. The CN300can further include a unified data management (UDM)322. The UDM322can be a control plane function that manages subscriber data and store subscriber data. The UDM322can communicate with the CN300via an Nudm324, a control plane interface exhibited by the UDM322. The CN300further includes an application function (AF)326. The AF326can be a control plane function that acts as a server for providing support for specific services. The AF326can communicate with the CN300via an Naf328, a control plane interface exhibited by the AF326. In addition, the CN300can include a unified data repository (UDR)302. The UDR302can be configured as a centralized data repository for subscription data, subscriber policy data, sessions, contexts, and application states and can provide notifications to other network function about updates to, for example, subscription data. The UDR322can communicate with the CN300via an Nudr304, a control plane interface exhibited by the UDR302.

The CN300can further include a network slice specific authentication and authorization function (NSSAAF)330. The NSSAAF330can be a control plane function that can support network splice-specific authentication and authorization. The NSSAAF330can communicate with the CN300via an Nnssaaf332, an interface exhibited by the NSSAAF330. The CN300can further include an authentication server function (AUSF)334. The AUSF334is a control plane function that can support both subscriber and network authentication. The AUSF334can communicate with the CN300via an Nausf336, an interface exhibited by the AUSF334. The CN300can further include an AMF338. The AMF338can be a control plane function whose responsibilities include registration management, connection management, reachability management, and mobility management. The AMF338can communicate with the CN300via an Namf340, an interface exhibited by the AMF338. The Namf340is configured to receive messages from the base station358via the AMF338.

The CN300can further include a session management function (SMF)342. The SMF342can be a control plane function whose responsibilities include packet data unit (PDU) session management, internet protocol (IP) address allocation, and general packet radio service (GPRS) protocol (GTP-U) tunnel management. The SMF342can communicate with the CN300via an Nsmf344, an interface exhibited by the SMF342. The CN300can further include a service communication proxy (SCP)346. The SCP346can be a control plane function that can provide routing control and observability for the CN300. The SCP346can communicate with the CN300via an Nscp348, an interface exhibited by the SCP346. The CN300can further include a network slice administration control function (NSACF)350. The NSACF350can be a control plane function that monitors and controls the number of registers UEs per network slice. The NSACF350can communicate with the CN300via a Nnsacf352, an interface exhibited by the NSACF350.

The CN300can be in operable communication with a UE354. The UE354can communicate with the CN300via an N1 interface (N1)356. The UE354can be in communication with a base station358. The UE354can also communicate with the CN300via the base station358. The base station358can communicate with the CN300via an NG (also known as “N2”)360.

The base station358can communicate with a user plane function (UPF)362via an N3 interface (N3)364. The UPF362can include an intermediate UPF (I-UPF) and a UPF session anchor. The I-UPF can communicate with the UPF session anchor via an N9 interface (N9)366. The UPF362can be responsible for routing and forward to user plane packets to an external data network368via an N6 interface (N6)370.

FIG.4illustrates an example of edge anchoring of UE communications, in accordance with some embodiments. A UE410can communicate with an edge entity430(shown as an edge application function and/or an edge application server) via a 5G system (5GS)420that includes a 5G access network (5G-AN)522and a 5G core network (5GC)424and that represents a 3GPP cellular network of a mobile network operator (MNO). For example, a PDU session can be established, whereby the 5GCS420can facilitate the traffic between the UE410and the edge entity430. The 5G-AN522can include, among other things, a base station (e.g., a gNB). The 5GC424can be an example of the CN300ofFIG.3. An alternate network440may also be available to the UE410, where the traffic between the UE410and the edge entity430can be sent via the alternate network440instead of the 5GS420(e.g., by using another data session). The alternate network can be a WiFi network, a WiMax network, a non-3GPP network, or any other type of networks.

It may be desired to avoid a UE switch of the traffic from being sent via the 5GS420to being sent via the alternate network420. For example, depending on agreements between the MNO and an operator, provider, or owner of the edge component430, connectivity requirements (e.g.., latency, throughput, etc.), or other parameters, the traffic may need to be served by the 5GS420only when this 3GPP cellular network is available. In such situations, an edge-anchored indication426can be used, whereby the 5GS420sends this indication426to the UE410(e.g., an SMF of the 5GC424sends it via a base station of the 5G-AN422), and whereby the UE410can use this indication426to possibly avoid the UE switch. Avoiding the switch is illustrated inFIG.4by using dotted lines between the UE410and the alternate network440and between the alternate network440and the edge entity430.

Generally, the edge-anchored indication426includes information indicating to the UE410that the traffic, or more broadly, the PDU session is edge-anchored. An edge-anchored PDU session represents a PDU session that provides connectivity to an edge entity (e.g., the edge entity430inFIG.4), where this connectivity cannot be relocated. In an example, the edge-anchored indication426include any or a combination of UE route selection policy (URSP) rule selection descriptor (RSD) fields to indicate whether the PDU session is edge-anchored. In another example, during a PDU session establishment or modification, the edge-anchored indication426can be provided using extended protocol configuration options (ePCO) information elements (IEs). In this example, the edge-anchored indication426can merely indicate that the PDU session (or the traffic) is edged-anchored or can provide additional information, such as the PDU session (or the traffic) being edged-anchored and 5GC preferred (e.g., preference is to use the 5GS420), or such as the PDU session (or the traffic) being edged-anchored and 3GPP access preferred (e.g., preference is to use a 3GPP cellular network).

In certain situations, the edge-anchored indication426can be provided based on any or a combination of a UE authorization, a policy, network connectivity conditions, or an AF authorization. For example, the edge-anchored indication426may be provided only to a subset of UEs connected to the 5GS420(e.g., to UEs that are authorized to use the edge deployment or require edge-anchored indications). In another example, the edge-anchored indication426may apply only to a subset of applications. In particular, not all application traffic may require edge-anchoring. Edge-anchored indications may only be provisioned if specific applications have been detected and a policy is in place to anchor traffic of that application to edge hosting environment of the MNO. In yet another example, UE connectivity conditions may dynamically change. The UE410may be able to reach the same edge entity430via the alternate network440so that there is no break in connectivity. Or, the UE410may have alternate access that may be providing better connectivity that the 5GS420may not be aware of. In these cases, an AF of the 5GC424needs to be able to control the edge-anchored indications of the 5GS420that may prevent the UE410from getting a better user experience for the application traffic. In a further example, if the UE410has been given an indication that application traffic should consider cellular connectivity as edge anchored (or any of its variants), the UE410may not switch traffic over non-3GPP connections that the UE410may find. This can be misused by unauthorized AFs or due to misconfigurations in the networks. In such cases, edge-anchored indications can be provided to the UE410about an authorization of an AF. These and other controls over the use of edge-anchored indications are further described in connection with the next figures.

FIG.5illustrates an example of UE authorization-based edge anchoring, in accordance with some embodiments. Generally, a UE authorization for an edge-anchored indication is determined first to then provide the edge-anchored indication to the relevant UE.

In the illustration ofFIG.5, a UE510can communicate with an edge entity530(shown as an edge application function and/or an edge application server) via a 5GS520that includes a 5G-AN522and a 5GC524and that represents a 3GPP cellular network of an MNO. A PDU session can be established, whereby the 5GCS520can facilitate the traffic between the UE510and the edge entity530. An alternate network540may also be available to the UE510, where the traffic between the UE510and the edge entity530can be sent via the alternate network540instead of the 5GS520(e.g., by using another data session). The UE510, the 5GS520, the 5G-AN522, the 5GC524, the edge entity530, and the alternate network540can be similar to the UE410, the 5GS420, the 5G-AN422, the 5GC424, the edge entity430, and the alternate network440, respectively, ofFIG.4. Similarities are not repeated herein.

In an example, the 5GC524can store a UE authorization528for sending edge-anchored indications to the UE510. As such, during a PDU session establishment or modification and/or based on a request of the edge entity530or an AF, the 5GC524can determine the UE authorization528and send an edge-anchored indication526(similar to the edge-anchored indication416ofFIG.4) to the UE510.

For example, a UDR of the 5GC524(e.g., the UDR302ofFIG.3) stores subscription data, such as session management (SM) subscription data, associated with the UE510. This data can include an SM field that stores the UE authorization528. As such, this data can explicitly indicate whether the UE510is authorized to receive edge-anchored indications from the 5GS520based on a subscription with the MNO. In the illustration ofFIG.5, the UE510is authorized and information in the SM field can indicate this authorization. Otherwise, information in the SM field (or a blank SM field) can indicate a lack of authorization. Additionally, or alternatively, the subscription data (e.g., the SM field) stores a UE authorization for discovery of edge application server (EAS) via an edge application server discovery function (EASDF). In this case, the UE authorization can serve as a dual purpose authorization: a first authorization edge-anchored indications and a second authorization for the discover of the EAS via the EASDF. In other words, the first authorization can be derived implicitly from the SM subscription data for the EAS via the EASDF.

An SMF of the 5GC524(e.g., the SMF342ofFIG.3) may retrieve or derive the UE authorization528for the edge-anchored indication526from the UDR at the time of the PDU session establishment or medication. In addition, the SMF can subscribe to notifications of the UDR about updates to the subscription data and can receive from the UDR an update indicating that this UE authorization528is now included in the subscription data or, conversely, is no longer included. Based on the UE authorization528and, possibly or optionally other information (e.g., policy information as described in the next figures), the SMF (or more generally the 5GS520) can determine that the edge-anchored indication526is to be sent to the UE510and can do so.

FIG.6illustrates an example of a sequence diagram600for UE authorization-based edge anchoring, in accordance with some embodiments. The sequence diagram600represents steps that different components can perform to send an edge-anchored indication to a UE610based on a UE authorization (which may be explicit or implicit). As illustrated inFIG.6, in addition to the UE610, these components include an SMF620, a UPF630, a PCF640, a UDM650, and a UDR660of a 5GC (e.g., of the 5GC524ofFIG.5).

Initially, the UE610initiates a PDU session establishment, where the SMF620and the UPF630can facilitate this establishing. At that time, the SMF620can bring retrieving subscription data for a subscriber permanent identifier (SUPI), a data network name (DNN), and a single network slice selection assistance information (S-NSSAI). For example, the SMF620makes a request to the UDM650using a Nudm interface (shown as a Nudm_SDM_GetRequest (SUPI, DNN, S-NSSAI)). In turn, the UDM650makes a call to the UDR660over an Nudr interface to request the subscription data (shown as Nudr_DM_Query (SUPI, DNN, S-NSSAI, SM subscription data)). The UDM650looks up the subscription data based on the SUPI, DNN, and/or S-NSSAI and determines a corresponding UE authorization (explicit or implicit). This UE authorization is sent back as part of the SM subscription data (shown as being sent in a response to the UDM650: Nudr_DM_Query Response (SM subscription data)). The UDM650responds to the SMF620with the UE authorization and other subscription data (e.g., shown as Nudm_SDM_Get Response (SM subscription data)). The SMF620determines an explicit UE authorization for sending an edge-anchored indication to the UE610or derives an implicit UE authorization for sending the edge-anchored indication to the UE610based on an explicit UE authorization for EAS discovery via EASDF. The SMF620then sends the edge-anchored indication to the UE610.

In an example, the UE authorization can be a new element “UE authorization for Edge-anchored indication” in the SM subscription data as defined in a technical specification, such as being added to table 5.2.3.3.1-1 of 3GPP TS 23.502, V17.5.0 (2022-07). Optionally, the UE authorization may also be implicitly indicated by the setting of “UE authorization for EAS discovery via EASDF,” where this existing element is defined in a technical specification, such as being added to table 5.2.3.3.1-1 of 3GPP TS 23.502, V17.5.0 (2022-07), and its interpretation can be modified in light of the present disclosure to derive an implicit “UE authorization for Edge-anchored indication.”

Although not illustrated in the sequence diagram600, the UE authorization (implicit or explicit) can be updated over time, whereby the UE authorization can be added to the SM subscription data, if not already added, or whereby the UE authorization can be removed from the SM subscription data, if previously added. An update to the SM subscription data (addition or removal of the UE authorization) can be sent to the SMF620, whereby the SMF620may subscribe to changes in SM subscription data and may be notified through a Nudm-SDM_Notification service primitive. Upon such a notification, the SMF620may send an update to the UE610(e.g., may send the edge-anchored indication if the UE authorization is added, or an indication to that the edge-anchored indication is to be used if the UE authorization is removed).

FIG.7illustrates an example of policy-based edge anchoring, in accordance with some embodiments. Generally, a policy can be stored and used to determine whether traffic to an edge entity is to be anchored or not. Because not all application traffic may require edge-anchoring, edge-anchored indications may only be provisioned if specific applications have been detected and the relevant policy or policies are in place to anchor traffic of an application to an edge hosting environment of the MNO.

In the illustration ofFIG.7, a UE710can communicate with an edge entity730(shown as an edge application function and/or an edge application server) via a 5GS720that includes a 5G-AN722and a 5GC724and that represents a 3GPP cellular network of an MNO. A PDU session can be established, whereby the 5GCS720can facilitate the traffic between the UE710and the edge entity730. An alternate network740may also be available to the UE710, where the traffic between the UE710and the edge entity730can be sent via the alternate network740instead of the 5GS720(e.g., by using another data session). The UE710, the 5GS720, the 5G-AN722, the 5GC724, the edge entity730, and the alternate network740can be similar to the UE410, the 5GS420, the 5G-AN422, the 5GC424, the edge entity430, and the alternate network440, respectively, ofFIG.4. Similarities are not repeated herein.

In an example, the 5GC724can store a policy728for sending edge-anchored indications to the UE710. The policy728can be associated with the edge entity730, with an application or application type of the edge entity730, and/or particular traffic or traffic type of the application. An association indicates that the policy728is to be applied to the traffic. As such, when the traffic in the PDU session begins or is being exchanged between the UE710and the edge component730, the 5GC724(e.g., an SMF thereof) can determine whether the policy728applies to the traffic. In the illustration ofFIG.7, the determination is positive (e.g., the policy728applies) and, accordingly, the 5GC724sends an edge-anchored indication726to the UE710.

In an example, the policy728can include policy information that can inform the SMF that the edge-anchored indication726is to be sent only if specific application traffic is detected. The policy information can be received as policy and charging control (PCC) rules from a PCF of the 5GC724. For example, the policy728(e.g., the particular policy information) can be included in a new field of PCC rule information in the 5GC524, as defined in a technical specification, such as 3GPP TS 23.503, V17.5.0 (2022-07). The new field can be an “Indication of Edge enabler usage,” which can indicate that the edge-anchored indication726is to be sent if any of the edge enablers like local PSA user plane function (UPF) or uplink (UL) classifier (CL) is used for the PDU session to access a local edge hosting environment (e.g., the edge entity730). Such policy information can be included in a policy control section or an AF) influenced traffic steering enforcement control section of the PCC rule information. In another example, the policy728can be a local policy configured in the SMF (e.g., stored locally to the SMF).

Detecting whether the policy728applies to traffic can involve determining a match between the traffic and the policy information. For example, the policy information can include a service data flow (SDF) filter. The match can be between the traffic and the SDF filter. This type of match can be determined by a UPF of the 5GS720.

Upon the SMF determining that the policy728applies, other checks can be performed before the SMF sends the edge-anchored indication726to the UE710. For example, the SMF can determine whether a UE authorization exists, similarly to what is described herein above in connection withFIGS.5and6. If the UE authorization also exists, then the edge-anchored indication726is sent.

As such, using the policy728can involve the following. Application traffic begins. The UPF detects that this traffic corresponds to the SDF associated with the policy728. Next, the UPF informs the SMF of the traffic matching the SDF filter. In turn, the SMF checks UE authorization and the policy728(either dynamic PCC rules or local configuration) to decide if the UE710is to be provided with the edge-anchored indication726.

FIG.8illustrates an example of dynamic connection conditions-based edge anchoring, in accordance with some embodiments. Generally, one or more parameters of a UE connection with an edge entity via a network can dynamically change over time. For example, a UE connection with the edge entity via an alternate network can provide better performance (e.g., throughput, latency, quality of service (QoS), etc.). Conversely, the alternate UE connection's performance can deteriorate. In such situations, an AF can indicate to the network whether the traffic is to be edge-anchored or not. As such, depending on the connection conditions, the edge anchoring can be dynamically adjusted, whereby the network can send an edge-anchored indication to the UE indicating that the traffic (or the PDU session) is edge-anchored, as needed, or can send another indication to the UE that the traffic (or the PDU session) is no longer edge-anchored.

In the illustration ofFIG.8, a UE810can communicate with an edge entity830(shown as an edge application function and/or an edge application server) via a 5GS820that includes a 5G-AN822and a 5GC824and that represents a 3GPP cellular network of an MNO. A PDU session can be established, whereby the 5GCS820can facilitate the traffic between the UE810and the edge entity830. An alternate network840may also be available to the UE810, where the traffic between the UE810and the edge entity830can be sent via the alternate network840instead of the 5GS820(e.g., by using another data session). The UE810, the 5GS820, the 5G-AN822, the 5GC824, the edge entity830, and the alternate network840can be similar to the UE410, the 5GS420, the 5G-AN422, the 5GC424, the edge entity430, and the alternate network440, respectively, ofFIG.4. Similarities are not repeated herein.

In an example, the 5GC824can store a policy828for sending edge-anchored indications to the UE810. The policy828can be updated depending on traffic, application, network, and/or connections conditions, wherein the policy828can set switching restrictions or lifting such restrictions according to changes observed for the traffic and/or connectivity. The 5GC824(e.g., a NEF thereof) can update the policy828and the 5GC824(e.g., an SMF thereof) can look up policy information of the policy828to determine whether the edge-anchored indication826is to be sent to the UE810indicating that the traffic (or PDU session) is edge-anchored, or whether another indication is to be sent to the UE810to indicate that the traffic (or PDU session) is to no longer be edge-anchored. Of course, the 5GC824can performs other checks before sending any of such indications, such as also checking for a UE authorization and/or an application authorization as described in connection withFIGS.5-7.

In an example, the policy828can provide different controls to an AF. For instance, an application service level does not require guaranteed QoS from the 5GS820and, hence, does not require traffic to be bound to the 5GS820, and/or if the UE810has a better connection to another edge entity which is not visible to the 5GS820. In such situations, the AF can indicate to the 5GS820to stop provisioning edge-anchored or 5GC preferred or 3GPP access preferred or any indication that causes application traffic to flow through the 5GS820. The NEF service or “AFSessionWithQoS” can be enhanced (e.g., augmented) with additional fields that enable the AF to configure setting of traffic switching restrictions and lifting them according to the changes observed for the UE application traffic and connectivity.

The AF can provide the required setting in the Nnef_AFSessionWithQoS service API. In turn, the NEF authorizes the AF for this service action. If the AF is authorized for this service, the NEF forwards the setting to a PCF of the 5GC824. The PCF determines whether an SM policy update is required and informs the SMF. The SMF initiates a PDU session modification and delivers the required setting as part of ePCO. The setting can take different values. One example value indicates whether the UE810should consider the PDU session connectivity as offering edge-enablers to access the edge component830. Another example value indicates whether the UE810should prefer the 5GC connectivity for the application traffic (access can be 3GPP or non-3GPP). Yet another example value indicates whether the UE810should prefer 3GPP access connectivity for the application traffic. These and other functionalities are described in connection with the next figures.

FIG.9illustrates an example of a sequence diagram900for dynamic connection conditions-based edge anchoring, in accordance with some embodiments. The sequence diagram900is applicable to sending an edge-anchored indication to a UE910. The sequence diagram900represents steps that different components can perform to send the edge-anchored indication based on different conditions that may dynamically change over time. As illustrated inFIG.9, in addition to the UE910, these components include an SMF920, a UPF930, a PCF940, a NEF950, and an edge entity960(shown as an EAS and/or EAF).

Initially, the UE910has a PDU session that is already established. Based on this PDU session, application traffic can be communicated (e.g., sent and/or received) with the edge component960via a 5GS that includes the SMF920, the UPF930, the PCF940, and the NEF950. The edge component960determines that the application traffic needs to be considered edge-anchored over cellular. Accordingly, the edge component960(or an AF associated therewith) sends a request for edge-anchoring the application traffic. This request can be a “Nnef_AFSessionWithQoS (edge-anchored)” API call to the NEF950, where the “edge-anchored” value in the call provides the indication. Optionally, the NEF950may request and receive information from the PCF940to determine if a policy is already existent and specifies the edge-anchoring. If so, no additional steps may be needed. Otherwise, the NEF950can proceed to update the policy as described in the next steps. Alternatively, and as illustrated inFIG.9, the NEF950does not process the policy. Instead, the NEF950passes the request to the PCF940that then performs the processing. As illustrated in the next figures, before passing this request, the NEF950can determine whether the edge component960(or the AF) is authorized to request the edge anchoring. If authorized, the request is passed. Otherwise, the request is not passed, and no additional steps may be needed. Passing the request can include an API call to the PCF940, such as a “Npcf_APolicyAuthorizationCreate/Update (edge-anchored)” call indicating the edge anchoring (e.g., “edge-anchored” is added as a value in this call).

Next, the PCF940updates the policy as needed. For example, the policy is updated only when no current indication for the edge anchoring is specified therein. In an example, the policy is stored as policy information in PCC rule information. In this case, an “indication of edge enabler usage” can be added to indicate that the application traffic is to be edge-anchored.

Upon the update, the PCF940can inform the SMF920about the edge anchoring of the application traffic. For example, an API call to the SMF920is made, such as a “Nsmf_SMPolicyControl_UpdateNotify (edge-anchored)” call indicating the edge anchoring (e.g., “edge-anchored” is added as a value in this call).

Upon receiving an indication that the application traffic is to be edge-anchored, the SMF920can send an edge-anchored indication to the UE910. In this case, a PDU session modification message can be sent, illustrated as a “PDU Session Modification (ePCO {SDF identifier=edge-anchored})”, wherein the ePCO information indicates the edge anchoring. The SMF920can then modify the PDU session to designate an SDF of the application traffic as being “edge-anchored.”

FIG.10illustrates another example of a sequence diagram100for dynamic connection conditions-based edge anchoring, in accordance with some embodiments. The sequence diagram1000is applicable to informing a UE1010that an edge-anchored indication is no longer usable or applicable. As illustrated with the bubbles labeled with the letter “A,” the sequence diagram1000can be performed following the sequence diagram900ofFIG.9. Nonetheless, the sequence diagram1000can be independently performed of the sequence diagram900whenever the edge-anchored indication is no longer usable or applicable. Additionally or alternatively, the sequence diagram900can be performed after the sequence diagram1000when the edge-anchored indication becomes usable or applicable.

As illustrated inFIG.10, the sequence diagram1000represents steps that different components can perform to send the edge-anchored indication based on different conditions that may dynamically change over time. As illustrated inFIG.10, in addition to the UE1010, these components include an SMF1020, a UPF1030, a PCF1040, a NEF1050, and an edge entity1060(shown as an EAS and/or EAF).

Initially, the UE1010established a connection to the same edge entity described in the sequence diagram900(e.g., the edge entity1060is the same as the edge entity960) using an alternate network (e.g., a non-3GPP network, where the connection would be a non-3GPP connection). The AF associated with the edge entity1050determines that the UE1010has connectivity with no loss of service levels over this connection. The AF can then send a request to the NEF1050to indicate that the application traffic no longer requires to be edge-anchored. This request can be a “Nnef_AFSessionWithQoS (no longer requires edge-anchored)” API call to the NEF1050, where the “no longer requires edge-anchored” value in the call provides the indication. Optionally, the NEF1050may request and receive information from the PCF1040to determine if a policy is already existent and specifies that the edge-anchoring is not needed. If so, no additional steps may be needed. Otherwise, the NEF1050can proceed to update the policy as described in the next steps. Alternatively, and as illustrated inFIG.10, the NEF1050does not process the policy. Instead, the NEF1050passes the request to the PCF1040that then performs the processing. As further illustrated herein below, before passing this request, the NEF1050can determine whether the AF is authorized to request the lifting of the edge anchoring. If authorized, the request is passed. Otherwise, the request is not passed, and no additional steps may be needed. Passing the request can include an API call to the PCF1040, such as a “Npcf_APolicyAuthorizationCreate/Update (no longer requires edge-anchored)” call indicating that edge anchoring is no longer needed (e.g., “no longer requires edge-anchored” is added as a value in this call).

Next, the PCF1040updates the policy as needed. For example, the policy is updated only when no current indication for no edge anchoring is specified therein. In an example, the policy is stored as policy information in PCC rule information. In this case, an “indication of edge enabler usage” can be removed to indicate that the application traffic is to no longer be edge-anchored. Upon the update, the PCF1040can inform the SMF1020about the lifting of the edge anchoring for the application traffic. For example, an API call to the SMF1020is made, such as a “Nsmf_SMPolicyControl_UpdateNotify (no longer requires edge-anchored)” call indicating that the edge anchoring is no longer needed (e.g., “no longer requires edge-anchored” is added as a value in this call).

Upon receiving an indication that the application traffic is to no longer be edge-anchored, the SMF1020can send an indication to the UE1010that the application traffic need no longer be edge anchored. In this case, a PDU session modification message can be sent, illustrated as a “PDU Session Modification (ePCO {SDF identifier=no longer edge-anchored})”, wherein the ePCO information indicates that the edge anchoring is no longer needed. The SMF1020can then modify the PDU session to designate an SDF of the application traffic as being “not edge-anchored.”

FIG.11illustrates an example of AF authorization-based edge anchoring, in accordance with some embodiments. As described herein above, AFs can request the change to the edge anchoring of traffic. To prevent misuse of edge-anchored indications, an AF that requests setting of traffic switching indications can be authorized by a 5GS (e.g., a NEF thereof). If authorized, a request to edge-anchor the traffic or to longer edge-anchor the traffic can be processed. Otherwise, the request can be denied. For example, when the NEF receives the request from the AF, the NEF checks whether the AF is authorized for the operation setting requested by the AF (e.g., set “edge-anchored” or as “no longer requires edge-anchored”). The NEF can store and maintain information that identifies AFs and the authorization of each of such AFs vis-à-vis the edge anchoring. This information can be looked up to determine the authorization.

In the illustration ofFIG.11, a UE1110can communicate with an edge entity1130(shown as an edge application function and/or an edge application server) via a 5GS1120that includes a 5G-AN1122and a 5GC1124and that represents a 3GPP cellular network of an MNO. A PDU session can be established, whereby the 5GCS1120can facilitate the traffic between the UE1110and the edge entity1130. An alternate network1140may also be available to the UE1110, where the traffic between the UE1110and the edge entity1130can be sent via the alternate network1140instead of the 5GS1120(e.g., by using another data session). The UE1110, the 5GS1120, the 5G-AN1122, the 5GC1124, the edge entity1130, and the alternate network1140can be similar to the UE410, the 5GS420, the 5G-AN422, the 5GC424, the edge entity430, and the alternate network440, respectively, ofFIG.4. Similarities are not repeated herein.

In an example, the 5GC1124(e.g., a NEF thereof) can store an AF authorization1128for requesting changes to edge-anchored indications for all UEs, for a particular set of UEs, or for the specific UE1110. The AF authorization1128can be associated with an AF identifier and can indicate (e.g., using a Boolean value or any other types of value) whether the AF having the AF identifier is authorized to set traffic to be edge-anchored, to no longer be edge-anchored, and/or to request both types of settings. In addition to possibly be granular to the UE level, the AF authorization1128can be global to all traffic of the AF or granular to particular type of traffic of the AF.

As such, the 5GC1124(e.g., the NEF) can receive a request of the AF associated with the edge entity1130requesting a change to the edge anchoring of application traffic (e.g., to edge-anchor it or to no longer edge-anchor it). The 5GC1124(e.g., the NEF) can look up the AF authorization1128to determine whether the AF is authorized to make this change. If the determination is positive (as illustrated inFIG.11), the 5GC1124can further process the request (e.g., as illustrated inFIGS.10and11) to then generate and send an edge-anchored indication1126to the UE1110. Otherwise, no such edge-anchored indication1126is sent.

FIG.12illustrates an example of an operational flow/algorithmic structure1200for edge anchoring of UE communications, in accordance with some embodiments. The operational flow/algorithmic structure1200can be implemented by a network, such as one including any of the 5GS's described herein above. In particular, the operational flow/algorithmic structure1200can be implemented as instructions stored in one or more memory of a system (e.g., a 5GS) that, upon execution by one or more processors of the system, configure the system to perform the operations of the operational flow/algorithmic structure1200.

In an example, the operational flow/algorithmic structure1200includes, at1202, receiving, from a UE, a request to establish a PDU session with the network. This request can be received by a 5GC of the network (e.g., via a base station of a 5G-AN of the network) and processed by the 5GC (e.g., by an SMF and UPF) to establish the PDU session, such that traffic between the UE and an edge entity can be facilitated via the network based on the PDU session.

In an example, the operational flow/algorithmic structure1200includes, at1204, determining, based on subscription data associated with the UE, an authorization for the UE to receive an edge-anchored indication from the network, wherein the edge-anchored indication facilitates avoiding a UE switch of traffic from being sent via the network to being sent via a different network, the traffic associated with an edge application or an edge application server. For instance, the edge entity includes the edge application or the edge application server. The subscription data can explicitly or implicitly indicate the authorization. The subscription data can be stored by a UDR of the 5GC and the authorization can be requested and retrieved therefrom by the SMF.

In an example, the operational flow/algorithmic structure1200includes, at1206, sending, based on the authorization, the edge-anchored indication to the UE. For instance, the edge-anchored indication is sent using URSP RSD fields or using ePCO IEs. As described herein above, in addition to checking the UE authorization based on subscription data, a policy applicable to the traffic and/or AF associated with the edge entity can also be checked to determine whether the edge-anchored indication is to be sent to the UE.

FIG.13illustrates an example of an operational flow/algorithmic structure for edge anchoring of UE communications, in accordance with some embodiments. The operational flow/algorithmic structure1300can be implemented by a network, such as one including any of the 5GS's described herein above. In particular, the operational flow/algorithmic structure1300can be implemented as instructions stored in one or more memory of a system (e.g., a 5GS) that, upon execution by one or more processors of the system, configure the system to perform the operations of the operational flow/algorithmic structure1300.

In an example, the operational flow/algorithmic structure1300includes, at1302, determining that traffic between a UE and an edge application or an edge application server is associated with a policy. The traffic can be facilitated based on a PDU session established via the network (e.g., a 5GC of the network). A UPF of the 5GC can detect that the traffic corresponds to an SDF and can inform an SMF of the 5GC of this detection.

In an example, the operational flow/algorithmic structure1300includes, at1304, determining that the policy indicates that an edge-anchored indication is associated with the traffic, wherein the edge-anchored indication facilitates avoiding a UE switch of the traffic from being sent via the network to being sent via a different network. For instance, the SMF can determine that the policy applies to the SDF and can determine the AF authorization to from policy information of the policy.

In an example, the operational flow/algorithmic structure1300includes, at1306, sending the edge-anchored indication to the UE. For instance, the edge-anchored indication is sent using URSP RSD fields or using ePCO IEs. As described herein above, in addition to checking the AF authorization based on policy information, a UE authorization can also be checked to determine whether the edge-anchored indication is to be sent to the UE.

FIG.14illustrates receive components1400of the UE106, in accordance with some embodiments. The receive components1400may include an antenna panel1404that includes a number of antenna elements. The panel1404is shown with four antenna elements, but other embodiments may include other numbers.

The antenna panel1404may be coupled to analog beamforming (BF) components that include a number of phase shifters1408(1)-1408(4). The phase shifters1408(1)-1408(4) may be coupled with a radio-frequency (RF) chain1412. The RF chain1412may amplify a receive analog RF signal, downconvert the RF signal to baseband, and convert the analog baseband signal to a digital baseband signal that may be provided to a baseband processor for further processing.

In various embodiments, control circuitry, which may reside in a baseband processor, may provide BF weights (for example W1-W4), which may represent phase shift values, to the phase shifters1408(1)-1408(4) to provide a receive beam at the antenna panel1404. These BF weights may be determined based on the channel-based beamforming.

FIG.15illustrates a ULE1500, in accordance with some embodiments. The UE1500may be similar to and substantially interchangeable with UE106ofFIG.1.

Similar to that described above with respect to UE154, the UE1500may be any mobile or non-mobile computing device, such as mobile phones, computers, tablets, industrial wireless sensors (for example, microphones, carbon dioxide sensors, pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, laser scanners, fluid level sensors, inventory sensors, electric voltage/current meters, actuators, etc.), video surveillance/monitoring devices (for example, cameras, video cameras, etc.), wearable devices, or relaxed-IoT devices. In some embodiments, the UE may be a reduced capacity UE or NR-Light UE.

The UE1500may include processors1504, RF interface circuitry1508, memory/storage1512, user interface1516, sensors1520, driver circuitry1522, power management integrated circuit (PMIC)1524, and battery1528. The components of the UE1500may be implemented as integrated circuits (ICs), portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram ofFIG.15is intended to show a high-level view of some of the components of the UE1500. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other implementations.

The components of the UE1500may be coupled with various other components over one or more interconnects1532, which may represent any type of interface, input/output, bus (local, system, or expansion), transmission line, trace, optical connection, etc. that allows various circuit components (on common or different chips or chipsets) to interact with one another.

The processors1504may include processor circuitry such as baseband processor circuitry (BB)1504A, central processor unit circuitry (CPU)1504B, and graphics processor unit circuitry (GPU)1504C. The processors1504may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory/storage1512to cause the UE1500to perform operations as described herein.

In some embodiments, the baseband processor circuitry1504A may access a communication protocol stack1536in the memory/storage1512to communicate over a 3GPP compatible network. In general, the baseband processor circuitry1504A may access the communication protocol stack to: perform user plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer, and PDU layer; and perform control plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and a non-access stratum “NAS” layer. In some embodiments, the PHY layer operations may additionally/alternatively be performed by the components of the RF interface circuitry1508.

The baseband processor circuitry1504A may generate or process baseband signals or waveforms that carry information in 3GPP-compatible networks. In some embodiments, the waveforms for NR may be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and discrete Fourier transform spread OFDM (DFT-S-OFDM) in the uplink.

The baseband processor circuitry1504A may also access group information1524from memory/storage1512to determine search space groups in which a number of repetitions of a PDCCH may be transmitted.

The memory/storage1512may include any type of volatile or non-volatile memory that may be distributed throughout the UE1500. In some embodiments, some of the memory/storage1512may be located on the processors1504themselves (for example, L1 and L2 cache), while other memory/storage1512is external to the processors1504but accessible thereto via a memory interface. The memory/storage1512may include any suitable volatile or non-volatile memory, such as, but not limited to, dynamic random-access memory (DRAM), static random-access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state memory, or any other type of memory device technology.

The RF interface circuitry1508may include transceiver circuitry and a radio frequency front module (RFEM) that allows the UE1500to communicate with other devices over a radio access network. The RF interface circuitry1508may include various elements arranged in transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

In various embodiments, the RF interface circuitry1508may be configured to transmit/receive signals in a manner compatible with NR access technologies.

The driver circuitry1522may include software and hardware elements that operate to control particular devices that are embedded in the UE1500, attached to the UE1500, or otherwise communicatively coupled with the UE1500. The driver circuitry1522may include individual drivers allowing other components to interact with or control various input/output (I/O) devices that may be present within, or connected to, the UE1500. For example, driver circuitry1522may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, sensor drivers to obtain sensor readings of sensor circuitry1520and control and allow access to sensor circuitry1520, drivers to obtain actuator positions of electro-mechanic components or control and allow access to the electro-mechanic components, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

The PMIC1524may manage power provided to various components of the UE1500. In particular, with respect to the processors1504, the PMIC1524may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

A battery1528may power the UE1500, although in some examples the UE1500may be mounted deployed in a fixed location, and may have a power supply coupled to an electrical grid. The battery1528may be a lithium ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in vehicle-based applications, the battery1528may be a typical lead-acid automotive battery.

FIG.16illustrates a gNB1600, in accordance with some embodiments. The gNB node1600may be similar to and substantially interchangeable with the base station104ofFIG.1.

The gNB1600may include processors1604, RF interface circuitry1608, core network (CN) interface circuitry1612, and memory/storage circuitry1616.

The components of the gNB1600may be coupled with various other components over one or more interconnects1628.

The processors1604, RF interface circuitry1608, memory/storage circuitry1616(including communication protocol stack1610), antenna1624, and interconnects1628may be similar to like-named elements shown and described with respect toFIG.13.

The CN interface circuitry1612may provide connectivity to a core network, for example, a 5thGeneration Core network (5GC) using a 5GC-compatible network interface protocol, such as carrier Ethernet protocols, or some other suitable protocol. Network connectivity may be provided to/from the gNB1600via a fiber optic or wireless backhaul. The CN interface circuitry1612may include one or more dedicated processors or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry1612may include multiple controllers to provide connectivity to other networks using the same or different protocols.

EXAMPLES

Example 1 includes a method implemented by a network, the method comprising: receiving, from a user equipment (UE), a request to establish a protocol data unit (PDU) session with the network; determining, based on subscription data associated with the UE, an authorization for the UE to receive an edge-anchored indication from the network, wherein the edge-anchored indication facilitates avoiding a UE switch of traffic from being sent via the network to being sent via a different network, the traffic associated with an edge application or an edge application server; and sending, based on the authorization, the edge-anchored indication to the UE.

Example 2 includes the method of example 1, wherein the authorization is determined from a session management (SM) field of the subscription data, wherein the SM field stores the authorization.

Example 3 includes the method of example 1, wherein the authorization is a first authorization that is determined from a session management (SM) field of the subscription data, wherein the SM field stores a UE authorization for discovery of edge application server (EAS) via an edge application server discovery function (EASDF), wherein the UE authorization indicates the first authorization and further indicates a second authorization for the discover of the EAS via the EASDF.

Example 4 includes the method of any example 1 through 3, wherein the authorization is determined as part of establishing the PDU session.

Example 5 includes the method of any example 1 through 4, further comprising: receiving a notification about an update to the subscription data, the update indicating that the authorization is included in the subscription data.

Example 6 includes the method of any example 1 through 5, further comprising: determining that the traffic is associated with a policy; and determining that the policy indicates that the edge-anchored indication is associated with the traffic, wherein sending the edge-anchored indication to the UE is further based on the policy.

Example 7 includes the method of example 6, wherein the policy is determined from policy and charging control (PCC) rule information.

Example 8 includes the method of example 7, wherein the PCC rule information includes an indication of using an edge enabler for the PDU session, wherein the determining that the policy indicates that the edge-anchored indication is associated with the traffic is based on the indication.

Example 9 includes the of example 8, wherein the indication is included in a policy control section or an application function (AF) influenced traffic steering enforcement control section of the PCC rule information.

Example 10 includes the method of example 6, wherein the policy is stored locally to a session management function (SMF) of the network.

Example 11 includes the method of example 6, wherein the policy associates the edge-anchored indication with the traffic by at least using a service data flow (SDF) filter.

Example 12 includes the method of example 11, further comprising: determining a match between the traffic and the SDF filter; and determining that the policy is applicable based on the match, wherein the authorization is determined based on the policy being applicable.

Example 13 includes the method of example 6, wherein the policy is determined from policy and charging control (PCC) rule information, and wherein the method further comprises: receiving a first request of the edge application or the edge application server indicating that the traffic is to be edge-anchored; and updating, based on the first request, the PCC rule information by at least updating the policy to indicate that the edge-anchored indication is associated with the traffic.

Example 14 includes the method of example 13, further comprising: receiving a second request of the edge application or the edge application server indicating that the traffic is to no longer be edge-anchored; and updating, based on the second request, the PCC rule information by at least updating the policy to indicate that the traffic is no longer edge-anchored.

Example 15 includes the method of example 13, further comprising: verifying that the first request is received from an application function (AF) authorized to indicate that the traffic is to be edge-anchored.

Example 16 includes a method implemented by a network, the method comprising: determining that traffic between a user equipment (UE) and an edge application or an edge application server is associated with a policy; determining that the policy indicates that an edge-anchored indication is associated with the traffic, wherein the edge-anchored indication facilitates avoiding a UE switch of the traffic from being sent via the network to being sent via a different network; and sending the edge-anchored indication to the UE.

Example 17 includes the method of example 16, further comprising: determining, based on subscription data associated with the UE, an authorization for the edge-anchored indication, wherein sending the edge-anchored indication to the UE is further based on the authorization.

Example 18 includes the method of example 17, wherein the authorization is determined from a session management (SM) field of the subscription data, wherein the SM field stores the authorization.

Example 19 includes the method of example 17, wherein the authorization is a first authorization that is determined from a session management (SM) field of the subscription data, wherein the SM field stores a UE authorization for discovery of edge application server (EAS) via an edge application server discovery function (EASDF), wherein the UE authorization indicates the first authorization and further indicates a second authorization for the discovery of the EAS via the EASDF.

Example 20 includes the method of example 17, wherein the authorization is determined as part of establishing a protocol data unit (PDU) session between the UE and the network.

Example 21 includes the method of any example 16 through 20, wherein the policy is determined from policy and charging control (PCC) rule information that includes an indication of using an edge enabler for a protocol data unit (PDU) session, wherein the determining that the policy indicates that the edge-anchored indication is associated with the traffic is based on the indication.

Example 22 includes the method of claim21, wherein the indication is included in a policy control section or an application function (AF) influenced traffic steering enforcement control section of the PCC rule information.

Example 23 includes the method of any example 16 through 22, wherein the policy is stored locally to a session management function (SMF) of the network.

Example 24 includes the method of any example 16 through 23, wherein the policy associates the edge-anchored indication with the traffic by at least using a service data flow (SDF) filter.

Example 25 includes the method of claim24, further comprising: determining a match between the traffic and the SDF filter; determining that the policy is applicable based on the match; and determining, from subscription data associated with the UE and based on the policy being applicable, an authorization for the edge-anchored indication, wherein sending the edge-anchored indication to the UE is further based on the authorization.

Example 26 includes the method of any example 16 through 25, wherein the policy is determined from policy and charging control (PCC) rule information, and wherein the method further comprises: receiving a first request of the edge application or the edge application server indicating that the traffic is to be edge-anchored; and updating, based on the first request, the PCC rule information by at least updating the policy to indicate that the edge-anchored indication is associated with the traffic.

Example 27 includes the method of claim26, further comprising: receiving a second request of the edge application or the edge application server indicating that the traffic is to no longer be edge-anchored; and updating, based on the second request, the PCC rule information by at least updating the policy to indicate that the traffic is no longer edge-anchored.

Example 28 includes the method of claim26, further comprising: verifying that the first request is received from an application function (AF) authorized to indicate that the traffic is to be edge-anchored.

Example 29 includes a network comprising means to perform one or more elements of a method described in or related to any of the examples 1-28.

Example 30 includes one or more non-transitory computer-readable media comprising instructions to cause a network, upon execution of the instructions by one or more processors of the network, to perform one or more elements of a method described in or related to any of the examples 1-28.

Example 31 includes a network comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of the examples 1-28.

Example 32 includes a network comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of a method described in or related to any of the examples 1-28.

Example 33 includes a system comprising means to perform one or more elements of a method described in or related to any of the examples 1-28.