Edge service configuration

Abstract

The invention provides methods designed to enable external AF / AS to provide information about edge data network configuration to 5GC. Further, methods for edge service enabled UE provisioning are provided. Mechanisms are disclosed for enabling a UE that does not host an EEC to request EDN information provisioning in order to enable a non-edge aware application client to utilize edge services; enabling an EEC hosted by a UE to acquire edge configuration information by using URSP rules to establish an IP connection with a configuration server; and enabling an EEC hosted by a UE to acquire edge data network configuration information during registration. Further, methods are provided including mechanisms for enabling an AF to subscribe to event monitoring exposure via a NEF and request a preference for optimized reporting or reporting distribution via the UE; enabling subscription and policies from centralized NFs to be distributed to edge or locally deployed along the UE's path via the UE; and enabling exposure of event monitoring from centralized NFs to edge servers with low latency via the UE.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. Patent Application Serial No. 62 / 955,506 entitled “Edge Services Configuration”, filed December 31, 2019, and U.S. Patent Application Serial No. 63 / 018,582 entitled “Edge Services Configuration”, filed May 1, 2020, the contents of which are incorporated herein by reference in their entirety. Background Technology

[0003] The 3rd Generation Partnership Project (3GPP) has developed technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities, including studies on codecs, security, and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE Advanced, and New Radio (NR) (also referred to as "5G"). It is hoped that the 3GPP NR standard will continue to evolve and include definitions for next-generation radio access technologies (new RATs), which are expected to provide new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. This flexible radio access is expected to include new non-backward-compatible radio access in the new spectrum below 7 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with different needs. Ultra-mobile broadband is expected to include centimeter-wave and millimeter-wave spectrum, which will provide opportunities for ultra-mobile broadband access for applications such as indoor spaces and hotspots. Specifically, it is expected that ultra-mobile broadband and flexible radio access below 7 GHz will share a common design framework, while having specific design optimizations for centimeter waves and millimeter waves.

[0004] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low-latency Communication (URLLC), massive machine type communication (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy savings), and enhanced vehicle-to-everything (eV2X) communications, which can include any of vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and vehicle communications with other entities. Particular services and applications in these categories include, for example, monitoring and sensor networks, device remote control, bi-directional remote control, personal cloud computing, video streaming, cloud-based wireless offices, first responder connectivity, automotive eCall, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and drones, among others. All of these use cases and others are contemplated herein. SUMMARY

[0005] Aspects disclosed herein describe methods that enable an external AF / AS to provide information to the 5GC about edge data network configuration. Other aspects disclosed herein describe mechanisms to address UE provisioning for edge service enablement, such as: 1) mechanisms to enable a UE that does not host an EEC to request EDN information provisioning in order to enable non-edge-aware application clients to leverage edge services, such mechanisms can be based on UE registration procedures and based on URSP rule provisioning and usage; 2) mechanisms to enable an EEC hosted by a UE to obtain edge configuration information by using URSP rules to establish IP connectivity with a configuration server; and 3) mechanisms to enable an EEC hosted by a UE to obtain edge data network configuration information during registration.

[0006] Additional aspects disclosed herein describe methods that enable network information exposure at the edge with low latency, such as: 1) mechanisms to enable an AF to subscribe to event monitoring exposure via a NEF and request a preference for reporting (e.g., with low latency) or reporting distribution optimization via a UE; 2) mechanisms to enable subscription and policies from centralized NFs to be distributed to the edge or locally deployed along a UE’s path via a UE; and 3) mechanisms to enable exposure of event monitoring from centralized NFs to edge servers with low latency via a UE. BRIEF DESCRIPTION OF DRAWINGS

[0007] A more detailed understanding can be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0008] In the drawings:

[0009] Figure 1A An example communication system is illustrated.

[0010] Figure 1B Figure 1C Figure 1D is a system diagram of an example RAN and core network.

[0011] Figure 1E Another example communication system is illustrated.

[0012] Figure 1F is a block diagram of an example apparatus or device, such as a WTRU.

[0013] Figure 1G is a block diagram of an example computing system.

[0014] Figure 2 Usage of edge and cloud V2X application servers by V2X AC on the UE is illustrated.

[0015] Figure 3 3GPP-defined architecture for enabling edge applications is illustrated. (See 3GPP TR 23.758, Study on Application Framework for Enabling Edge Applications, V1.0.0 (2019-09)).

[0016] Figure 4A Figure 4B Figure 4C Call flow for example enhanced registration procedure (no EEC case) is illustrated.

[0017] Figure 5A Figure 5B Call flow for example enhanced UE requested PDU session establishment is illustrated.

[0018] Figure 6A Figure 6B Call flow for example enhanced registration procedure (EEC based case) is illustrated.

[0019] Figure 7 is a system diagram of an example core network architecture with network functions.

[0020] Figure 8 is an example of an example unoptimized network exposure reporting path for edge deployments.

[0021] Figure 9 is an example of an example optimized reporting path from centralized network functions.

[0022] Figure 10 is a call flow of an example of forwarding edge reporting subscriptions from a centralized network exposure function.

[0023] ​​​​​​Figure 11 is an example call flow for exemplary routing / distribution of edge monitoring policies via a UE.

[0024] Figure 12 is an example call flow for exemplary reporting routing from a centralized NF via a UE.

[0025] Figures 13A-13E shows an example enhanced registration procedure that enables a UE to convey its support for routing monitoring reports.

[0026] Figure 14 shows an example of an optimized reporting path from a locally deployed NF. DETAILED DESCRIPTION

[0027] Figure 1A An example communications system 100 in which the systems, methods, and apparatuses described and claimed herein can be used is shown. The communications system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, which generally or collectively can be referred to as WTRU 102 or WTRUs 102. The communications system 100 can include a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and Network Services 113, which can include, for example, V2X servers, V2X functions, ProSe servers, ProSe functions, IoT services, video streaming, and / or edge computing, etc.

[0028] It should be appreciated that the concepts disclosed herein can be used with any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102 can be any type of apparatus or device configured to operate and / or communicate in a wireless environment. In Figure 1A In an example, in Figures 1A-1EEach WTRU 102 is depicted as a handheld wireless communication device. It is to be appreciated that each WTRU can alternatively be a device of any type that is configured to transmit and / or receive wireless signals including, by way of example only, user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane.

[0029] The communication system 100 can also include base stations 114a and 114b. In Figure 1A In the example depicted, each base station 114a and 114b is depicted as a single element. In practice, base stations 114a and 114b can include any number of interconnected base stations and / or network elements. Base station 114a can be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the network

[0030] The TRPs 119a, 119b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, Network Services 113, and / or other networks 112. The RSUs 120a and 120b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or Network Services 113. By way of example, the base stations 114a, 114b can be a Base Transceiver Station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a Next Generation Node-B (gNode B), a satellite, a site controller, an access point (AP), a wireless router, and the like.

[0031] The base station 114a can be part of the RAN 103 / 104 / 105, which can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. Similarly, the base station 114b can be part of the RAN 103b / 104b / 105b, which can also include other base stations and / or network elements (not shown), such as a BSC, a RNC, relay nodes, etc. The base station 114a can be configured to transmit and / or receive wireless signals within a particular geographic area known as a cell (not shown). Similarly, the base station 114b can be configured to transmit and / or receive wired and / or wireless signals within a particular geographic area known as a cell (not shown). The cell can further be divided into cell sectors. For example, the cell associated with the base station 114a can be divided into three sectors. Thus, for example, the base station 114a can include three transceivers, one for each sector of the cell. The base station 114a can employ multiple-input multiple-output (MIMO) technology and, thus, can utilize multiple transceivers for each sector of the cell.

[0032] The base station 114a can communicate with one or more of the WTRUs 102a, 102b, 102c, and 102g over the air interface 115 / 116 / 117, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115 / 116 / 117 can be established using any suitable radio access technology (RAT).

[0033] The base stations 114b can communicate with one or more of the RRHs 118a and 118b, TRPs 119a and 119b, and / or RSUs 120a and 120b through a wired or wireless interface 115b / 116b / 117b, which can be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, cmWave, mmWave, etc.). The air interface 115b / 116b / 117b can be established using any suitable RAT.

[0034] The RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b can communicate with one or more of the WTRUs 102c, 102d, 102e, 102f through an air interface 115c / 116c / 117c, which can be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.). The air interface 115c / 116c / 117c can be established using any suitable RAT.

[0035] The WTRUs 102 can communicate with one another using a direct air interface 115d / 116d / 117d, such as sidelink communication, which can be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.). The air interface 115d / 116d / 117d can be established using any suitable RAT.

[0036] The communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103 / 104 / 105 and WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b in the RAN 103b / 104b / 105b and WTRUs 102c, 102d, 102e, 102f can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 115 / 116 / 117 and / or 115c / 116c / 117c respectively using Wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

[0037] The base stations 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, and 102g or RRHs 118a and 118b, TRPs 119a and 119b, and / or RSUs 120a and 120b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, and 102f can implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA) that can establish the air interface 115 / 116 / 117 or 115c / 116c / 117c respectively using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) that can utilize frequency division duplexing (FDD), time division duplexing (TDD), or a combination of both. The air interface 115 / 116 / 117 or 115c / 116c / 117c can implement 3GPP NR technology. The LTE and LTE-A technology can include LTE D2D and / or V2X technology and interfaces such as sidelink communication, etc. Similarly, 3GPP NR technology can include NR V2X technology and interfaces such as sidelink communication, etc.

[0038] The base stations 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, and 102g or RRHs 118a and 118b, TRPs 119a and 119b, and / or RSUs 120a and 120b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, and 102f can implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0039] Figure 1ABase station 114c can be, for example, a wireless router, a home node B, a home evolution node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, trains, antennas, satellites, factories, and campuses. Base station 114c and WTRU 102 (e.g., WTRU 102e) can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). Similarly, base station 114c and WTRU 102 (e.g., WTRU 102d) can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). Base station 114c and WTRU 102 (e.g., WTRU 102e) can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114c can have a direct connection to Internet 110. Therefore, base station 114c can access Internet 110 without going through core network 106 / 107 / 109.

[0040] RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b can communicate with core networks 106 / 107 / 109, which can be any type of network configured to provide voice, data, messaging, authorization and authentication, application and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRU 102. For example, core networks 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, and / or perform advanced security functions such as user authentication.

[0041] Although not in Figure 1A As shown, but to be understood, RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or core network 106 / 107 / 109 can communicate directly or indirectly with other RANs employing the same RAT as or a different RAT than RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b. For example, in addition to being connected to RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, which may be utilizing E-UTRA radio technology, core network 106 / 107 / 109 can also communicate with another RAN (not shown) employing GSM or NR radio technology.

[0042] Core networks 106 / 107 / 109 may also act as gateways for WTRU 102 to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Other networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include any type of packet data network (e.g., IEEE 802.3 Ethernet) or another core network connected to one or more RANs, which may use the same RAT as or a different RAT than RAN 103 / 104 / 105 or RAN 103b / 104b / 105b.

[0043] Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communication system 100 may include multi-mode capability. For example, WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks via different wireless links. Figure 1A The WTRU 102g shown can be configured to communicate with a base station 114a that can employ cellular-based radio technology and with a base station 114c that can employ IEEE 802 radio technology.

[0044] Despite Figure 1A Although not shown, it should be understood that user equipment can be wired to a gateway. The gateway can be a residential gateway (RG). The RG can provide connectivity to the core network 106 / 107 / 109. It should be understood that many of the ideas contained herein are equivalent to those of UEs acting as WTRUs and UEs connecting to the network using wired connections. For example, ideas applicable to radio interfaces 115, 116, 117, and 115c / 116c / 117c are equivalent to those for wired connections.

[0045] Figure 1B This is a system diagram of an exemplary RAN 103 and core network 106. As described above, RAN 103 can communicate with WTRUs 102a, 102b, and 102c via air interface 115 using UTRA radio technology. RAN 103 can also communicate with core network 106. Figure 1BAs shown, the RAN 103 can include Node-Bs 140a, 140b, and 140c, which can each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node-Bs 140a, 140b, and 140c can each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 can also include RNCs 142a, 142b. It will be appreciated that the RAN 103 can include any number of Node-Bs and RNCs.

[0046] As shown, Figure 1B The Node-Bs 140a, 140b can be in communication with the RNC 142a. Additionally, the Node-B 140c can be in communication with the RNC 142b. The Node-Bs 140a, 140b, and 140c can communicate with the respective RNCs 142a and 142b via an Iub interface. The RNCs 142a and 142b can be in communication with one another via an Iur interface. Each of the RNCs 142a and 142b can be configured to control the respective Node-Bs 140a, 140b, and 140c to which it is connected. In addition, each of the RNCs 142a and 142b can be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0047] Figure 1B The core network 106 shown includes a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are each depicted as part of the core network 106, it will be appreciated that any one of these elements can be owned and / or operated by an entity other than the core network operator.

[0048] The RNC 142a in the RAN 103 can be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 can be connected to the MGW 144. The MSC 146 and the MGW 144 can provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c, and traditional land-line communications devices.

[0049] The RNC 142a in the RAN 103 can also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 can be connected to the GGSN 150. The SGSN 148 and the GGSN 150 can provide the WTRUs 102a, 102b, and 102c with access to the packet- switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0050] The core network 106 can also be connected to the other networks 112, which can include other wired or wireless networks that are owned and / or operated by other service providers.

[0051] Figure 1C is a system diagram of an example RAN 104 and a core network 107. As

[0052] The RAN 104 can include eNode-Bs 160a, 160b, and 160c, though it will be appreciated that the RAN 104 can include any number of eNode-Bs. The eNode-Bs 160a, 160b, and 160c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. For example, the eNode-Bs 160a, 160b, and 160c can implement MIMO technology. Thus, the eNode-B 160a, for example, can use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0053] Each of the eNode-Bs 160a, 160b, and 160c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, and the like. As shown, the eNode-Bs 160a, 160b, and 160c can communicate with one another over an X2 interface. Figure 1C

[0054] Figure 1C The core network 107 as shown can include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements can be owned and / or operated by an entity other than the operator of the core network

[0055] ​The MME 162 can be connected to each of the eNode Bs 160a, 160b, and 160c in the RAN 104 via an SI interface and can serve as a control node. For example, the MME 162 can be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and 102c, and the like. The MME 162 can also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0056] The serving gateway 164 can be connected to each of the eNode Bs 160a, 160b, and 160c in the RAN 104 via the SI interface. The serving gateway 164 can generally route and forward user data packets to / from the WTRUs 102a, 102b, and 102c. The serving gateway 164 can also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, managing and storing contexts of the WTRUs 102a, 102b, and 102c, and the like.

[0057] The serving gateway 164 can also be connected to the PDN gateway 166, which can provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0058] The core network 107 can facilitate communications with other networks. For example, the core network 107 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. Further, the core network 107 can provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which can include other wired or wireless networks that are owned and / or operated by other service providers.

[0059] Figure 1Dis a system diagram of an example RAN 105 and core network 109. The RAN 105 can be in communication with the WTRUs 102a and 102b through the air interface 117. The RAN 105 can also be in communication with the core network 109. The non-3GPP interworking function (N3IWF) 199 can be in communication with the WTRU 102c through the air interface 198 using non-3GPP radio technology. The N3IWF 199 can also be in communication with the core network 109.

[0060] The RAN 105 can include next-generation NodeBs 180a and 180b. It will be appreciated that the RAN 105 can include any number of next-generation NodeBs. The next-generation NodeBs 180a and 180b can each include one or more transceivers for communicating with the WTRUs 102a and 102b over the air interface 117. When using integrated access and backhaul connections, the same air interface can be used between the WTRUs and the next-generation NodeBs, which can be the core network 109 via one or more gNBs. The next-generation NodeBs 180a and 180b can implement MIMO, MU-MIMO, and / or digital beamforming techniques. Thus, the next-generation NodeB 180a, for example, can use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. It will be appreciated that the RAN 105 can employ other types of base stations such as an eNodeB. It will also be appreciated that the RAN 105 can include more than one type of base station. For example, the RAN can include eNodeBs and next-generation NodeBs.

[0061] The N3IWF 199 can include a non-3GPP access point 180c. It will be appreciated that the N3IWF 199 can include any number of non-3GPP access points. The non-3GPP access point 180c can include one or more transceivers for communicating with the WTRU 102c over the air interface 198. The non-3GPP access point 180c can communicate with the WTRU 102c over the air interface 198 using 802.11 protocols.

[0062] Each of the next-generation NodeBs 180a and 180b can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, and the like. As shown, the next-generation NodeBs 180a and 180b can communicate with one another, e.g., over an Xn interface. Figure 1D As shown, the next-generation NodeBs 180a and 180b can communicate with one another, e.g., over an Xn interface.

[0063] Figure 1DThe illustrated core network 109 can be a 5G core network (5GC). The core network 109 can provide a variety of communication services to customers interconnected by radio access networks. The core network 109 includes a plurality of entities performing functionality of the core network. As used herein, the term “core network entity” or “network function” refers to any entity performing one or more functions of the core network. It will be appreciated that such core network entities can be logical entities that are implemented in the form of computer executable instructions (software) stored in the memory of, and

[0064] In Figure 1D In examples, the 5G core network 109 can include an Access and Mobility Management Function (AMF) 172, a Session Management Function (SMF) 174, User Plane Functions (UPFs) 176a and 176b, a User Data Management Function (UDM) 197, an Authentication Server Function (AUSF) 190, a Network Exposure Function (NEF) 196, a Policy Control Function (PCF) 184, a Non-3GPP Interworking Function (N3IWF) 199, a User Data Repository (UDR) 178. While each of the foregoing elements are depicted as part of the 5G core network 109, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the core network operator. It will also be appreciated that the 5G core network can not include all of these elements, can include additional elements, and can include multiple instances of each of the elements. Figure 1D The network functions are shown directly connected to each other, however, it will be appreciated that they can communicate via a routing agent such as a Diameter routing agent or message bus.

[0065] In Figure 1D In examples, the connections between the network functions are implemented via a set of interfaces or reference points. It will be appreciated that the network functions can be modeled, described, or implemented as a set of services that are invoked or called by other network functions or services. The invocation of network function services can be implemented via direct connections between network functions, exchange of messages on a message bus, invocation of software functions, etc.

[0066] The AMF 172 can be connected to the RAN 105 via an N2 interface and can serve as a control node. For example, the AMF 172 can be responsible for registration management, connection management, access authorization, access authentication, and the like. The AMF can forward user plane tunnel configuration information to the RAN 105 via an N2 interface. The AMF 172 can receive user plane tunnel configuration information from the SMF via an N11 interface. The AMF 172 can generally route and forward NAS packets to / from the WTRUs 102a, 102b, and 102c via an N1 interface. The N1 interface is not shown in FIG. 1. Figure 1D

[0067] The SMF 174 can be connected to the AMF 172 via an N11 interface. Similarly, the SMF can be connected to the PCF 184 via an N7 interface, and to the UPFs 176a and 176b via an N4 interface. The SMF 174 can serve as a control node. For example, the SMF 174 can be responsible for session management, IP address allocation of the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPF 176a and UPF 176b, and generation of downlink data notifications to the AMF 172.

[0068] The UPF 176a and UPF 176b can provide the WTRUs 102a, 102b, and 102c with access to a packet data network (PDN), such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and other devices. The UPF 176a and UPF 176b can also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, the other network 112 can be an Ethernet network or any type of network that exchanges data packets. The UPF 176a and UPF 176b can receive traffic steering rules from the SMF 174 via an N4 interface. The UPF 176a and UPF 176b can provide access to packet data networks by connecting to the packet data networks via an N6 interface or by connecting to each other and to other UPFs via an N9 interface. In addition to providing access to packet data networks, the UPF 176 can be responsible for packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, downlink packet buffering.

[0069] The AMF 172 can also be connected to the N3IWF 199, for example, via an N2 interface. The N3IWF facilitates connectivity between the WTRU 102c and the 5G core network 170, for example, via a radio interface technology not defined by 3GPP. The AMF can interact with the N3IWF 199 in the same or a similar manner as it interacts with the RAN 105.

[0070] ​The PCF 184 can be connected to the SMF 174 via an N7 interface, to the AMF 172 via an N15 interface, and to an Application Function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not shown in FIG. 10. The PCF 184 can provide policy rules to control plane nodes such as the AMF 172 and the SMF 174, allowing the control plane nodes to enforce the rules. The PCF 184 can send policies for the WTRUs 102a, 102b, and 102c to the AMF 172, so that the AMF can deliver the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies can then be enforced or applied at the WTRUs 102a, 102b, and 102c. Figure 1D The PCF 184 can be connected to the SMF 174 via an N7 interface, to the AMF 172 via an N15 interface, and to an Application Function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not shown in FIG. 10. The PCF 184 can provide policy rules to control plane nodes such as the AMF 172 and the SMF 174, allowing the control plane nodes to enforce the rules. The PCF 184 can send policies for the WTRUs 102a, 102b, and 102c to the AMF 172, so that the AMF can deliver the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies can then be enforced or applied at the WTRUs 102a, 102b, and 102c.

[0071] The UDR 178 can act as a repository for authentication credentials and subscription information. The UDR can connect to network functions so that the network functions can add to, read from, and modify the data in the repository. For example, the UDR 178 can connect to the PCF 184 via an N36 interface. Similarly, the UDR 178 can connect to the NEF 196 via an N37 interface, and the UDR 178 can connect to the UDM 197 via an N35 interface.

[0072] The UDM 197 can act as an interface between the UDR 178 and other network functions. The UDM 197 can authorize network functions to access the UDR 178. For example, the UDM 197 can connect to the AMF 172 via an N8 interface, and the UDM 197 can connect to the SMF 174 via an N10 interface. Similarly, the UDM 197 can connect to the AUSF 190 via an N13 interface. The UDR 178 and the UDM 197 can be tightly integrated.

[0073] The AUSF 190 performs authentication-related operations and connects to the UDM 178 via an N13 interface and to the AMF 172 via an N12 interface.

[0074] The NEF 196 exposes capabilities and services in the 5G core network 109 to Application Functions (AFs) 188. The exposure can occur over an N33 API interface. The NEF can connect to the AF 188 via an N33 interface, and the NEF can connect to other network functions in order to expose the capabilities and services of the 5G core network 109.

[0075] Application Functions 188 can interact with network functions in the 5G Core Network 109. Interactions between the Application Functions 188 and the network functions can be via direct interfaces or can occur via the NEF 196. The Application Functions 188 can be considered part of the 5G Core Network 109 or can be external to the 5G Core Network 109 and deployed by enterprises that have a business relationship with the mobile network operator.

[0076] Network slicing is a mechanism that can be used by mobile network operators to support one or more “virtual” core networks behind the operator’s air interface. This involves “slicing” the core network into one or more virtual networks to support different RANs running across a single RAN or different service types. Network slicing enables operators to create customized networks to provide optimized solutions for different market scenarios that require a wide variety of requirements in terms of functionality, performance, and isolation, for example.

[0077] 3GPP has designed the 5G Core Network to support network slicing. Network slicing is a good tool that network operators can use to support a wide variety of 5G use cases (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband) that require very diverse and sometimes extreme requirements. Without the use of network slicing technology, the flexibility and scalability of the network architecture can not be sufficient to efficiently support the wider range of use case requirements when each use case has its own specific set of performance, scalability, and availability requirements. In addition, new network services should be introduced more efficiently.

[0078] Referring again to Figure 1D In the network slicing scenario, the WTRU 102a, 102b, or 102c can connect to the AMF 172 via the N1 interface. The AMF can be a logical part of one or more slices. The AMF can coordinate the connection or communication of the WTRU 102a, 102b, or 102c with one or more of the UPF 176a and 176b, the SMF 174, and other network functions. Each of the UPF 176a and 176b, the SMF 174, and the other network functions can be part of the same slice or different slices. When they are part of different slices, they can be isolated from each other in the sense that they can utilize different computing resources, security credentials, etc.

[0079] The core network 109 can facilitate communications with other networks. For example, the core network 109 can include, or can communicate with, an IP gateway for facilitating communications between the 5G core network 109 and the PSTN 108, an IP multimedia subsystem (IMS) server for facilitating

[0080] The core network entities described herein and shown in Figure 1A , Figure 1C , Figure 1D and Figure 1E are identified by the names given to these entities in certain existing 3GPP specifications, but it will be appreciated that these entities and functions can be identified by other names in the future and that certain entities or functions can be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Accordingly, the specific network entities and functions described and shown in Figure 1A , Figure 1B , Figure 1C , Figure 1D and Figure 1E are provided by way of example only and it is understood that the subject matter disclosed and claimed herein can be embodied in any similar communication system, whether presently defined or defined in the future.

[0081] Figure 1E An example communication system 111 in which the systems, methods, and apparatuses described herein can be used is shown. The communication system 111 can include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and road side units (RSUs) 123a and 123b. In practice, the concepts presented herein can be applied to any number of WTRUs, base stations gNB, V2X networks, and / or other network elements. One or several or all of the WTRUs A, B, C, D, E, and F can be outside the range of access network coverage 131. The WTRUs A, B, and C form a V2X group, with WTRU A being the group leader and WTRUs B and C being group members.

[0082] If WTRUs A, B, C, D, E, and F are within the coverage area 131 of the access network, they can communicate with each other via gNB 121 through Uu interface 129. Figure 1E In the example, WTRUs B and F are shown as being within access network coverage 131. WTRUs A, B, C, D, E, and F can communicate directly with each other via sidelink interfaces (e.g., PC5 or NR PC5) (such as interfaces 125a, 125b, or 128), regardless of whether they are within or outside access network coverage 131. For example, in Figure 1E In the example, WRTU D outside the access network coverage 131 communicates with WTRU F inside the coverage 131.

[0083] WTRUs A, B, C, D, E, and F can communicate with RSUs 123a or 123b via Vehicle-to-Network (V2N) 133 or sidelink interface 125b. WTRUs A, B, C, D, E, and F can communicate with V2X server 124 via Vehicle-to-Infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F can communicate with another UE via Vehicle-to-Pedestrian (V2P) interface 128.

[0084] Figure 1F The exemplary apparatus or device WTRU 102 (such as the systems, methods, and devices described herein) that can be configured for wireless communication and operation is an example of such an apparatus or device. Figure 1A , Figure 1B , Figure 1C , Figure 1D or Figure 1E A block diagram of WTRU 102. (See attached diagram.) Figure 1F As shown, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138. It should be understood that the WTRU 102 may include any sub-combination of the foregoing elements. Additionally, the nodes that base stations 114a and 114b and / or base stations 114a and 114b may represent (such as, but not limited to, transceiver stations (BTS), Node B, site controllers, access points (APs), home nodes (BTS), evolved home nodes (eNodeB), home evolved node B (HeNB), home evolved node B gateways, next-generation nodes (gNode-B), and proxy nodes, etc.) may include... Figure 1F Some or all of the elements described herein and the elements in the text.

[0085] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 1F While the processor 118 and transceiver 120 are depicted as separate components, it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0086] The UE's transmit / receive element 122 can be configured to transmit data to a base station (e.g., via air interface 115 / 116 / 117). Figure 1A The base station 114a) transmits or receives signals from the base station, or transmits or receives signals to or from another UE via air interface 115d / 116d / 117d. For example, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. The transmit / receive element 122 may be a transmitter / detector configured to transmit and / or receive, for example, IR signals, UV signals, or visible light signals. The transmit / receive element 122 may be configured to transmit and receive both RF signals and optical signals. It should be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals or wired signals.

[0087] Furthermore, although the transmitting / receiving element 122 is in Figure 1F While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interfaces 115 / 116 / 117.

[0088] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. Therefore, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11 or NR and E-UTRA), or via multiple beams to the same RAT at different RRHs, TRPs, RSUs, or nodes.

[0089] The processor 118 of the WTRU 102 can be coupled to, and can receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicators 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicators 128. In addition, the processor 118 can access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. The processor 118 can access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server on the cloud or in the edge computing platform, or on a home computer (not shown).

[0090] The processor 118 can receive power from the power source 134, and can be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 can be any suitable device for powering the WTRU 102. For example, the power source 134 can include one or more dry cell batteries, solar cells, fuel cells, and the like.

[0091] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, the information from the GPS chipset 136, the WTRU 102 can receive location information over the air interface 115 / 116 / 117 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 can acquire location information by way of any suitable location-determination method.

[0092] The processor 118 can also be coupled to other peripherals 138 that can include one or more software modules and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 can include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect an FM radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0093] The WTRU 102 can be included in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device (such as a smart watch or smart clothing), a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The WTRU 102 can be connected to other components, modules, or systems of such apparatuses or devices via one or more interconnects, such as an interconnect that can include one of the peripherals 138.

[0094] Figure 1G is a block diagram of an example computing system 90 in which Figure 1A Figure 1C Figure 1D and Figure 1E ​​One or more devices of the communication network illustrated in FIG. 1, such as certain nodes or functional entities in the RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, other networks 112, or network services 113. The computing system 90 can comprise a computer or server and can be controlled primarily by computer readable instructions, which can be in the form of software, wherever and by whatever means such software is stored or accessed. Such computer readable instructions can be executed within a processor 91 to operate the computing system 90. The processor 91 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate array (FPGA) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 91 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the computing system 90 to operate in a communication network. The coprocessor 81 is an optional processor that can perform additional functions or assist the processor 91. The processor 91 and / or coprocessor 81 can receive, generate, and process data relating to the methods and apparatus disclosed herein.

[0095] In operation, the processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computing system's main data-transfer path, system bus 80. Such a system bus connects the various components in the computing system 90 and defines the medium for data exchange. The system bus 80 typically includes a data bus for sending data, an address bus for sending addresses, and a control bus for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component

[0096] Memory that is coupled to system bus 80 includes random access memory (RAM) 82 and read only memory (ROM) 93. Such memory stores instructions and data that are needed by the processor 91 to implement the desired functions. ROM 93 typically contains stored data that cannot be readily modified, such as instructions for basic system functions associated with the generic processing of data by the processor 91. RAM 82 can be used to store temporary variables or other intermediate storage when implementing the functions of the present disclosure. Access to both ROM 93 and RAM 82 is typically controlled by a memory controller 92. The memory controller 92 can provide an address translation function that allows processes running on the processor 91 to access a virtual address space that is mapped to physical addresses of memory. The memory controller 92 can also provide a memory protection function that isolates processes from one another and from the system processes. Thus, a program running in a first mode can only access memory that is mapped through its own process virtual address space; it cannot access the virtual address space of another process unless memory sharing between processes has been set up.

[0097] In addition, computing system 90 can contain peripherals controller ( 83) responsible for communicating instructions from processor 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.

[0098] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output can include text, graphics, animated graphics, and video. The visual output can be provided in the form of a graphical user interface (GUI). Display 86 can be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.

[0099] Further, computing system 90 can contain communication circuitry, such as for example a wireless or wired network adapter 97, that can be used to connect computing system 90 to an external communications network or device, such as Figure 1A 、 Figure 1B 、 Figure 1C 、 Figure 1D and Figure 1E RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, WTRUs 102, or other networks 112, to enable the computing system 90 to communicate with other nodes or functional entities of these networks. The communication circuitry, alone or in combination with the processor 91, can be used to perform the transmitting and receiving steps of certain apparatuses, nodes, or functional entities described herein.

[0100] It should be appreciated that any or all of the apparatuses, systems, methods, and processes described herein can be embodied in the form of computer executable instructions embodied in a computer readable storage medium, such as a computer storage medium (e.g., RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVD), or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium used to store desired information in the form of computer-executable instructions). Specifically, any of the steps, operations, or functions described herein can be implemented in the form of such computer executable instructions. Computer readable storage media includes volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer readable storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to store the desired information in the form of computer-executable instructions.

[0101] The following is a list of acronyms that can appear in the description below. Acronyms used herein refer to the corresponding term listed below, unless otherwise stated:

[0102] 5GC 5G core network

[0103] AF application function

[0104] AMF access management function

[0105] API application programming interface

[0106] AS application server

[0107] AC application client

[0108] BS binding function

[0109] CN core network

[0110] DNN data network name

[0111] DNS domain name server

[0112] EAS edge application server

[0113] EDN edge data network

[0114] ECSP edge computing service provider

[0115] EDNCS edge data network configuration server

[0116] EES edge enablement server

[0117] EEC edge enablement client

[0118] EHE edge hosting environment

[0119] EMRP edge monitoring routing policy

[0120] FQDN fully qualified domain name

[0121] GMLC gateway mobile location center

[0122] GUI graphical user interface

[0123] LADN local area data network

[0124] NEF network exposure function

[0125] NF network function

[0126] PDU protocol data unit

[0127] SMF session management function

[0128] UDM unified data management

[0129] UE user equipment

[0130] UP user plane

[0131] Application server - an entity deployed on a network node that provides services for application clients.

[0132] Application client - an entity that accesses the services of an application server.

[0133] Edge application server - a server that provides application services, hosted on an edge node or edge hosting environment.

[0134] Edge node - a virtual or physical entity that is deployed within an edge network and hosts edge-based applications and services.

[0135] Edge data network - a local data network that supports the distributed deployment of edge hosting environments. In this disclosure, the term edge data network can be used interchangeably with the term edge hosting environment. For example, a server described herein as being in an edge data network is running in a corresponding edge hosting environment.

[0136] Edge Enabler Server - an entity deployed within the edge network that provides edge network centric services to edge enabler clients and edge application servers. In some 3GPP specifications, edge enabler servers are not functionally distinguished from edge application servers, and the term "edge application server" can apply to both.

[0137] Edge Enabler Client - an entity deployed on a device that provides edge network centric services to application clients hosted on the device.

[0138] Edge Data Network Configuration Server - an entity in the network that configures edge enabler clients and edge enabler servers to enable services provided by the edge data network. An edge data network configuration server can also be referred to as an edge configuration server.

[0139] Edge Hosting Environment - an environment that provides the support required for edge application servers to execute.

[0140] Edge Application Deployment.

[0141] The benefits of deploying application servers (ASs) at the edge of a 3GPP system, rather than in the cloud, can include reduced access latency, and increased reliability of application clients (ACs) that access services provided by these ASs. In addition, network operators can also benefit from deploying ASs at the edge of their networks, as this deployment model can allow network operators to distribute load and reduce congestion levels in their networks (e.g., by enabling localized communication between ACs and ASs).

[0142] For example, Figure 2 An autonomous vehicle use case is shown. The vehicle hosts a UE, and hosted on the UE is a V2X AC used by the vehicle's autonomous driving control system. The V2X AC communicates with V2X services (e.g., platooning services, cooperative driving services, or collision avoidance services) deployed in the 3GPP system. The V2X services can be deployed in a distributed manner across the system, as a combination of V2X ASs deployed on edge nodes (e.g., roadside units or cell towers) as well as in the cloud.

[0143] To enhance performance (e.g., reduce access latency and improve reliability), the preferred method for a V2X AC to access a V2X service can be via a V2X AS deployed in an edge network that is generally closer to the vehicle in the system, rather than via a cloud access to a V2X AS. When accessing a V2X AS at the edge, a V2X AC hosted on a UE within the vehicle can utilize more timely and more reliable information about other vehicles as well as road and traffic conditions. As a result, vehicles can travel at higher speeds and at closer distances to other vehicles. Vehicles can also change lanes more frequently and more efficiently without sacrificing safety. In contrast, when accessing a V2X AS in the cloud, due to the reduced availability of timely information, vehicles can have to fall back to more conservative modes of operation. This can generally result in lower vehicle speeds, increased distances between vehicles and / or suboptimal lane changes.

[0144] As vehicles travel along a road, V2X AC handover between V2X ASs hosted on different edge nodes closest to the vehicles can have to be coordinated. Likewise, for cases where edge network coverage fades in and out during vehicle travel, V2X AC handover between V2X ASs hosted on edge nodes and V2X ASs hosted in the cloud can also have to be coordinated. For such scenarios, seamless (i.e., low latency and reliable) V2X AC handover between ASs hosted on two edge nodes and in the cloud can be critical for successful deployment of such V2X use cases as well as other types of use cases with similar requirements as V2X.

[0145] 3GPP architecture for enabling edge applications .

[0146] “Error! Reference source not found.” shows a 3GPP defined architecture for enabling edge applications. The framework for enabling edge applications can include edge-enabled clients and application clients hosted on UEs, and edge-enabled servers and edge application servers hosted in edge data networks. An edge data network configuration server can be used to configure the edge-enabled clients and edge-enabled servers. The edge-enabled clients and servers can provide edge-centric capabilities to the application clients and servers, respectively. The edge-enabled servers and edge data network configuration server can also interact with a 3GPP network.

[0147] 3GPP architecture for network exposure .

[0148] Figure 7is a system diagram of a network-enabled core network architecture as described below. Current network exposure mechanisms in the 5GS can be designed based on the NEF and other control plane NFs (e.g. AMF, SMF or PCF). The NEF (as described in 3GPP TS 23.501, System Architecture for the 5G System; Stage 2, V16.3.0 (2019-12)) can include the following functionalities.

[0149] • Secure exposure of capabilities and events to third parties, application functions, etc.

[0150] • The NEF stores / retrieves information as structured data using a standardized interface (Nudr) of a unified data repository (UDR).

[0151] • Secure on-boarding of information from external applications to the 3GPP network. This provides a means for application functions to securely provide information (e.g. expected UE behavior, 5GLAN group information or service specific information) to the 3GPP network. In this case, the NEF can authenticate, authorize and help limit the application function.

[0152] • Conversion of internal-external information. This conversion is between information exchanged with the AF and information exchanged with internal network functions. For example, the conversion can be between an AF service identifier and internal 5G core information such as a DNN or S-NSSAI.

[0153] • Specifically, the NEF handles the masking of network and user sensitive information to external AFs according to network policies.

[0154] • The network exposure function receives information from other network functions (based on the exposure capabilities of other network functions). The NEF stores the received information as structured data using a standardized interface of a unified data repository (UDR). The NEF can access the stored information and "re-expose" it to other network functions and application functions, and for other purposes such as analytics.

[0155] • The NEF can support the packet flow description function by storing and retrieving PFDs in the UDR and providing PFDs to the SMF upon request by the SMF (pull mode) or NEF PFD management request (push mode).

[0156] • The NEF can also support the 5GLAN group management function.

[0157] • Exposure of analytics. The NEF can securely expose NWDAF analytics to external parties according to the provisions of TS 23.288.

[0158] • The NWDAF retrieves data from external parties. The NWDAF can collect data provided by external parties via the NEF for analytics generation purposes. The NEF handles and forwards requests and notifications between the NWDAF and the AF as specified in TS 23.288.

[0159] A specific NEF instance can support one or more of the above functions, and thus separate NEFs can support a subset of APIs specified for capability exposure. The NEF has access to the UDR, which can be located in the same PLMN as the NEF. For external exposure of services related to a specific UE, the NEF can reside in the HPLMN. The NEF in the HPLMN can have an interface with NFs in the VPLMN, according to operator agreements.

[0160] Problem statement .

[0161] SA6 has designed an edge computing application layer architecture. In this architecture, an application client on the UE can access services of an edge enabler client on the UE. The application client on the UE can also communicate with an edge application server. The edge application server can reside in an edge data network. The server at the edge can interact with the 5GS to access functions and information exposed by the network. Currently, the exposure can be provided via control plane NFs (e.g., NEF or PCF) that can be centrally deployed to avoid relocation. If the application client on the UE uses procedures and APIs defined by SA6 to access the edge enabler client, this is referred to as “edge aware”.

[0162] In the SA6 architecture, the edge enabler client can communicate with an EDN configuration server hosted in the N6-LAN (i.e., the EDN configuration server can not be deployed in the edge). The edge enabler client can communicate with the EDN configuration server in order to obtain information such as which edge data networks are available at a given location, or which edge application servers are available. Thus, the edge enabler client can have to establish communication with the EDN configuration server and obtain configuration information before it can provide services to the application client. 3GPP has not yet defined the means by which the edge enabler client discovers the EDN configuration server.

[0163] In other scenarios, the application client on the UE can not be “edge aware”. Thus, for example, they do not communicate with the edge enabler client and do not follow the 3GPP application layer protocols.

[0164] In scenarios where applications on the UE can use edge services, although the application client is not "edge-aware", 3GPP has not defined how the UE protocol stack can know where to send application data when edge computing is enabled. In other words, the UE cannot independently (without application help) determine when to route data to the edge. For example, consider the case of a smartphone hosting a non-edge-aware application. The smartphone can display a GUI that allows the user to indicate which applications the user wants to enable edge computing on. If the indicated applications are not "edge-aware", the UE protocol stack cannot enable edge computing on those applications.

[0165] When edge services rely on network exposure information (e.g., reports) from the NEF, long latency of reports being transmitted from the network to the edge server can cause the information to be outdated by the time it reaches the edge server. This in turn can cause application behavior changes (e.g., adjusting video stream resolution or switching driving automation levels) based on outdated network information. Thus, one problem to be solved is how to deliver network exposure information (e.g., reports) to the edge server in a more timely or optimized manner. If new, more efficient exposure mechanisms are defined, these exposure mechanisms should also include a method for the 5G system to determine which exposure mechanism to use so that multiple mechanisms can coexist in the system. This problem is further discussed below and illustrated in Figure 8 .

[0166] Edge service enablement orchestration

[0167] The following assumptions or conventions can be used when describing edge service enablement.

[0168] A UE can be edge service-aware or unaware.

[0169] An edge-aware UE is capable of triggering explicit requests for services provided at the edge. There are two methods that can be used to implement an edge-aware UE. The first way to implement an edge-aware UE is to provide an edge-enabled client to be hosted at the UE that enables edge services with network entities such as an edge-enabled server and an edge-enabled configuration server as described in the SA6 architecture. Note that this disclosure uses the SA6 nomenclature for these entities, but non-SA6 based implementations with equivalent entities can also be envisioned. For example, the edge-enabled server can be referred to as a service layer or a common service entity. The second way to implement an edge-aware UE is to not host an edge-enabled client at the UE, but to have a specialized protocol stack and configuration edge functionality. For example, the UE can provide a GUI that allows the user to indicate that certain applications should be allowed to access edge services. In this case, the UE needs to enable the UE protocol stack to understand how to send application data when edge computing is enabled.

[0170] Edge-unaware UEs do not have the capability to trigger explicit requests for services to be provided at the edge. Edge-unaware UEs can have traffic routed by the network to edge services, but the UE typically does not have awareness of this.

[0171] Application clients on edge-aware UEs (with or without EEC) can be edge service aware or unaware.

[0172] Edge-aware application clients are pre-provisioned with configuration information, which can be explicitly provided to the UE or an EEC hosted by the UE, containing information about their edge-related capabilities and requirements. Edge-aware application clients can also be able to trigger explicit requests for services to be provided at the edge. These requests are handled by the UE or an EEC hosted on the UE prior to requesting from the network.

[0173] Edge-unaware application clients do not have the capability to trigger explicit requests for edge services, but they can be pre-provisioned with information about their capabilities and requirements, which can be used by the UE or an EEC hosted on the UE to configure or trigger such services. For example, the UE can provide a GUI that allows the user to indicate on which applications to enable edge computing. The functionality enabled by the GUI can use application client pre-provisioned configuration information, but the application client itself can be edge-unaware.

[0174] Edge data networks are local data networks that support distributed deployment of edge hosting environments.

[0175] Services at edge data networks are provided by an edge computing service provider (ECSP), which can or can not be the same as the mobile network operator (MNO).

[0176] Edge data networks can be configured as LADNs (e.g., when the MNO is also the ECSP), in which case the service area of the edge data network can be discovered as a LADN service area based on existing 5GC procedures. However, in the more general case where the EDN is not configured as a LADN, these procedures cannot discover the edge data network service area. The following description is for the more general case, and specific reference is made to the LADN case.

[0177] Edge data network configuration servers are deployed / managed by the ECSP or MNO, and can provide configuration services to one or more edge data networks. Configuration servers typically do not reside in the edge, but are part of the MNO’s N6-LAN.

[0178] EDN information in 5GC. The 5GS specifies network capabilities for interworking with external application servers. This includes exposure capabilities via the NEF, e.g., exposure of provisioning capabilities to external functions. It also includes capabilities of application servers belonging to third parties with which the PLMN has agreements to influence routing decisions. These enhanced capabilities can be used to provide ECSPs with a method to provide EDN information to the EDN that is externally managed.

[0179] The application server can provide configuration of the edge data network (which can not be managed by the PLMN serving the UE) to: 1) the AMF, where information about the EDN service area is used to assist in EDN and EDNCS discovery; 2) the SMF, where traffic information is used to influence routing, which can be used to access the EDNCS or provide connectivity for edge services.

[0180] Note that the PCF can provide corresponding policies for both the AMF and the SMF. The AMF and SMF configurations are detailed below separately. However, the AF can also provide a single set of provisioning information to the PCF, which then provides the information to both the AMF and the SMF via corresponding policies.

[0181] The AMF can be configured with any EDN related information for all EDNs available in any tracking area of the AMF service area, as well as information about additional EDNs in the PLMN.

[0182] There can be different approaches to how the edge data network information can be configured at the AMF, e.g., as a set of tracking areas. In one example, the information is configured on a per-DNN basis, i.e., the configured edge service area is the same for different UEs accessing edge services using the same DNN, independent of the UE subscription information. In a second example, the information is configured on a per-EDNCS basis, i.e., the configured edge service area is the same for different UEs accessing the same type of edge service or from the same ECSP, independent of the UE registration area. The UE subscription information is used to derive the type of edge service subscribed to, which in turn is used to derive the corresponding EDN-CS. Different DNNs provided by the UE can map to the same EDN-CS.

[0183] In both of the above examples, the EDN information configured at the AMF can depend on factors that determine the UE registration area (e.g., mobility patterns and allowed / disallowed areas). For example, UEs located in the same EDN service area and subscribed to the same service (or using the same DNN) but with different mobility patterns can be mapped to different EDN CSs (or EDNs). For each EDN, this information can include: EDN identifier, service area (e.g., list of corresponding TAIs), one or more DNNs, an indicator specifying whether the EDN is configured as a LADN and can be discovered as a LADN, an ID associated with the ECSP, FQDN of the EDN-CS associated with each or more DNNs, and condition parameters (e.g., per service type) to determine the EDN CS association with the DNN. The way the AMF can use this information is described in procedures explained later.

[0184] The SMF receives information of traffic routing impact from the AF via the PCF. For example, when edge configuration information is provisioned in the 5GC, the application server’s request can target a set of UEs. For such a request, the information can be stored in the UDR, and the PCF receives the corresponding notification of the application server request. The traffic routing impact information provided to the SMF can include: 1) traffic descriptor (IP filter or application ID); 2) DNAI; 3) N6 routing information (which can include IP address, port); and 4) EDN CS FQDN. The way the SMF can use this information is described in procedures explained later.

[0185] Handling of non-edge-aware UE applications without EEC. Aspects disclosed herein include procedures that can be well suited for cases where edge services need to be provided to non-edge-aware UE applications by a UE that does not host an EEC. For example, the UE can provide a GUI that allows the user to indicate that certain applications should be allowed to access edge services. The UE protocol stack can use this indication to determine that traffic from the indicated applications should be routed to an edge data network.

[0186] Handling of non-edge-aware UE applications without EEC - registration-based provisioning. A UE can have to register with the network to get authorized to receive services, enable mobility tracking, and enable reachability. It is proposed that when a UE registers with the network, it indicates to the network that it wants to access the network’s edge compute resources. This mechanism can be used in scenarios where the UE does not host an EEC, but hosts non-edge-aware applications, and provides a GUI that allows the user to indicate on which applications to enable edge computing.

[0187] Figures 4A-4C An enhanced registration procedure (no EEC case) is shown in accordance with one aspect of the disclosure. Figures 4A-4CThe procedure shown in Figure 23.502 is an enhanced version of the General Registration procedure described in section 4.2.2.2.2.2 of 3GPP TS 23.502 (see 3GPP TS 23.502, “5G system procedures; Stage 2,” V16.1.1 (2019-09)). The improvements to the General Registration procedure are as follows. In Figure 4A Step 1 of Figure 23.502, the UE can initiate the registration procedure using the registration type “initial registration” or “mobility registration update” and can request retrieval of edge data network information by providing an EDN information indication, which is a flag and additional information that can indicate that the UE wants to access edge computing resources of the network. The EDN information indication can also include an application descriptor (OSId and / or OSAppId) to indicate to the network which specific applications on the UE should have access to edge computing services. The EDN information indication can be provided in Figure 4A Step 3 of Figure 23.502 is forwarded to the AMF and in Figure 4B Step 16 of Figure 23.502 is forwarded to the PCF. The PCF can use this information to determine which URSP rules to forward to the UE. The PCF can respond to the AMF by indicating whether the UE can be configured with URSP rules that will enable edge computing. This indication can be provided by the PCF based on the application descriptor. In Figure 4C Step 21 of Figure 23.502, the indication from the PCF can be provided to the UE by the AMF. The PCF can also subscribe to the AMF to receive notifications when the location of the UE changes so that the URSP rules related to edge computing for the UE can be updated.

[0188] Handling of non-edge-aware UE applications without EEC - use of URSP rules. URSP is a policy provided by the PCF to the UE. The UE can use them to determine how to route outgoing traffic from the UE. The traffic can be routed to an established PDU session, can be offloaded to non-3GPP access outside of a PDU session, or can trigger establishment of a new PDU session.

[0189] Using the registration procedure enhancements described above, the UE can provide an indication to the PCF that the traffic of its hosted applications can benefit from being routed to edge services. The PCF can use this information (e.g., application descriptor) to determine that URSP rules for accessing edge services can be needed. Thus, EDN-specific URSP rules can be returned to the UE in the registration accept response. The URSP rules can also be provided to the UE in a configuration update procedure. To support this feature, the routing component of the URSP rules can be modified to include a new edge enablement indication. Only routes with this indication can be considered valid if the UE is configured (e.g., via a GUI) such that the associated application descriptor enables edge services. The RSD can also indicate the locations where the route can be considered valid (e.g., locations where edge computing services are available).

[0190] A URSP policy with a routing descriptor including an edge enablement indication can be used only if edge computing is enabled on the UE. The routing selection verification criteria can provide a location (and time) context associated with a specific edge service required. The edge enablement indication can be used in a URSP rule that would result in a PDU session establishment for edge configuration purposes being routed to an edge service. Other URSP rules with an edge enablement indication can result in a PDU session establishment for edge configuration purposes being sent to a configuration server.

[0191] Edge configuration server EEC discovery (URSP based approach). In some handover from EPS or between 3GPP and non-3GPP cases or after a network triggered PDU session establishment procedure, a new PDU session is established by the UE in the 5GS using a PDU session establishment procedure. This procedure can assume that the UE is registered and the AMF has retrieved the user subscription data from the UDM.

[0192] In some scenarios, an edge-enabled client can attempt to establish an IP connection with an edge configuration server after pre-provisioning a FQDN for the edge configuration server or after obtaining a FQDN at registration. For example, a UE has discovered an EDN service area and one of the application clients has been pre-provisioned with a well-known FQDN in order to access a configuration server. When first accessing the FQDN, a URSP rule in the UE can cause the UE to attempt to establish a new PDU session. The URSP rule can indicate to the UE that the PDU session is for obtaining edge configuration data or, in general, operator configuration data. This mechanism can also be used for purposes other than obtaining operator or edge configuration data, e.g., for obtaining the edge service itself. This mechanism can also be used by edge-aware UEs or applications when the FQDN has been pre-configured rather than provided via a URSP rule.

[0193] The PDU session establishment procedure in 23.502 section 4.3.2.2.1 (see 3GPP TS 23.502, "5G system procedures; Stage 2", V16.1.1 (2019-09)) can be enhanced as shown in Figure 5A and Figure 5B It is noted that only the changes to the procedure introduced by this disclosure are detailed, all other steps are performed according to the specification.

[0194] Figure 5A and Figure 5B A call flow example is shown for an enhanced UE requested PDU session establishment. Therein, in Figure 5AIn step 1 of the procedure, the UE can send a NAS message (S-NSSAI, DNN, PDU Session ID, Request Type, old PDU Session ID, N1 SM container (PDU Session Establishment Request)) to the AMF including an edge configuration request indication. The inclusion of the edge configuration request indication can indicate the purpose of the PDU session to retrieve configuration information from an edge configuration server.

[0195] In step 2, the AMF can perform SMF selection and, if the edge configuration request indicator is included, determine the EDNCS. If the message includes a DNN corresponding to a known EDNCS, the AMF can forward this information to the SMF so that the SMF can determine which DNS server addresses to provide to the UE so that the FQDN will resolve to the IP address of the operator ECS. The DNS server addresses can be provided in a variety of ways: as a simple list, as a list mapping each DNS address to a certain location (e.g., cell ID), etc. If the message does not include a DNN corresponding to a known EDNCS, for the provided S-NSSAI, the AMF can select / determine: 1) an EDNCS corresponding to an available LADN; 2) an EDNCS based on priorities established from UE subscription information about the relative priority of subscribed edge services or a default DNN to use; or 3) an EDNCS based on local OAM configuration. The AMF can create an implicit subscription to the “presence of the UE in an EDN area” in order to send presence notifications to the SMF.

[0196] In step 3, the AMF can send an Nsmf_PDUSession_CreateSMContext request to the selected SMF and send an edge configuration selection mode flag to the SMF, and the SMF can use this indication to determine which DNS server addresses should be sent to the UE in the PDU Session Establishment Response. The DNS server addresses can be provided in a variety of ways: as a simple list, as a list mapping each DNS address to a certain location (e.g., cell ID), etc. The PDU Session Establishment Response can also be used to send an indication to the UE that the PDU session can be used to reach an edge configuration server.

[0197] In step 5, the SMF may send an Nsmf_PDUSession_CreateSMContext response to the AMF. This response may include the FQDN of the EDNCS, or may provide the DNS server address for the EDNCS to be updated at the UE (i.e., during the PDU session, as described in 3GPP TS 23.501 "System Architecture for 5G Systems"; Phase 2, V16.3.0 (2019-12)). In step 8, the SMF may use the FQDN of the EDNCS to select an appropriate UPF. In step 10a, the SMF may send an N4 session establishment request to the selected UPF, and may include appropriate CN tunneling information. Then, starting from step 6, various procedures (such as optional secondary authentication / authorization) may consider using the PDU session for configuration purposes. Figure 5B Steps 12 and 13 are used to transmit response information to the UE.

[0198] Edge configuration server EEC discovery (registration-based method). During registration, edge configuration server information can be provided to the UE. Figure 6A and Figure 6B An enhancement to the general registration procedure is shown and described below. Figure 6A In step 1, the UE can initiate the registration process using the registration type "Initial Registration" or "Mobility Registration Update," and can request the discovery of the Edge Configuration Server by providing an EDNCS Discovery Request Indication. This EDNCS Discovery Request Indication is a flag and additional information indicating that the UE wants to access the network's edge computing resources. The EDNCS Discovery Request Indication may also include application descriptors (OSId and OSAppId) to indicate to the network which specific applications on the UE should have access to edge computing services. The EDNCS Discovery Request Indication can be forwarded to the AMF in step 3. The AMF can use this information to determine which EDNCS discovery information to forward to the UE.

[0199] When a UE requests EDN discovery information via an EDN discovery request, the AMF can identify the EDN discovery information to be provided in response to the registration process. The AMF can use subscription information (existing or provided via...) Figure 6B Step 14 (obtained) determines the services the UE has edge service subscriptions for. AMF can create a list of EDNs and EDNCSs available to the UE in the registration area to be provided to the UE during registration acceptance. Figure 6Binformation provided to the UE can include: 1) EDN identifier; 2) UE's authorized scope on the EDN (e.g., on a service or storage device); 3) corresponding EDN service area (e.g., list of corresponding TAIs); 4) one or more DNNs for acquiring edge services; 5) optional indicator that specifies whether the EDN is configured as a LADN and can be discovered as a LADN; 6) FQDN of the EDNCS associated with each or more DNNs, which is determined based on a condition parameter (e.g., each service type or mobility mode); or 7) EDNCS discovery information. The EDNCS discovery information can include the following information: 1) FQDN or IP address of the EDNCS; 2) list of services (e.g., application descriptors) for which edge services can be provided; or 3) one or more DNNs associated with the ECD for the UE to access. Note that, Figure 6B The "EDN information" in step 21 of the above includes the "EDNCS discovery information" described above.

[0200] Note that not all information in the above list can be available at the AMF. For example, the EDN service area can be configured, but the EDNCS information can not be available. If the UE also includes a LADN DNN or an indicator that requests LADN information, the AMF can only provide information for EDNs that are configured as LADNs and can be discovered as LADNs. Alternatively, the UE can use an optional indicator that specifies whether the EDN is configured as a LADN and can be discovered as a LADN to extract this information.

[0201] Based on the EDN service area available at the UE, the UE can later determine whether it can request a PDU session for edge services. Alternatively, this information can be requested and provided in the UE service request or configuration update procedure. If the AMF determines that multiple applicable EDNCSs are available, based on the above procedures, for the provided S-NSSAI, the AMF can select / determine: 1) the EDNCS that corresponds to an available LADN; 2) the EDNCS based on the priority established according to the UE's subscription information about the relative priority of the subscribed edge services or the default DNN to be used; 3) the EDNCS based on local OAM configuration. The AMF can create an implicit subscription to the "UE's presence in the EDN area" in order to send the presence notification to the SMF. The AMF can determine the SMF that corresponds to the selected EDNCS, or if the EDNCS cannot be determined, it can reject the session establishment request.

[0202] Efficient network exposure via UE and alternative paths .

[0203] Monitoring events can be exposed to Application Functions (AFs) (as described in 3GPP TS 23.502, 4.15.3, 5G System Procedures; Stage 2, V16.1.1 (2019-09)). When monitoring events are exposed to AFs via the NEF, reports can be sent from the NF that detected the event (AMF, GMLC, UDM, or SMF) to the NEF and to the AF. Before detecting the event and sending the report, the NF that detected the event can be configured for monitoring, e.g., one of the procedures in TS 23.502, section 4.15.3.2, for the AMF. The configuration typically includes invoking a subscription operation.

[0204] Figure 8 is an example of an unoptimized network exposure reporting path for edge deployments. “Local deployment” as described herein denotes core network functions (e.g., UPF or SMF) that can be dedicated to enabling functionality in LADNs and / or edge deployments, as local deployment functions are typically deployed geographically closer to UEs. Local deployment functions can be depicted independently of “centralized” core network functions, which are deployed independently of the location of the served UEs.

[0205] An edge hosting environment can be geographically close to the local deployment and to the UE, but it is not functionally part of the CN deployment. Thus, in one aspect of the disclosure, the local deployment can be considered separate from the edge hosting environment, e.g., the local deployment can serve multiple EHEs and can be managed by different providers. However, this is merely a logical structure, and the local deployment can alternatively be considered part of the 5GC, or include EHEs, etc. Note also that in some 3GPP specifications (e.g., from 3GPP SA2), this concept of local deployment can be referred to as “edge” or “edge deployment.”

[0206] Figure 8 Two possibilities for AF deployment are depicted: in an edge hosting environment (EHE) (with an edge application server), or in a centralized cloud. The dashed lines illustrate the reporting path to the AF, for reports that can be generated by the AMF or the local SMF.

[0207] Figure 8 The reasons why the current exposure architecture can cause problems in certain edge deployments are shown. The fact that monitoring reports need to traverse a centralized NEF can cause unacceptable delays between the occurrence of an event and the reception of the event report at the AF, especially in edge AFs. Note that although the AMF and the NEF can be located in a “centralized” core network, i.e., not in an “edge,” they can not be close to each other. For example, the AMF, SMF, and NEF can each be located in different / independent cities.

[0208] Aspects of the present disclosure propose new reporting methods that can be used to send event reports when a UE is connected to an edge hosting environment (EHE) via a local deployment. In one aspect, a new CN function, the “Local Enabling Function” (LEF), is proposed. The LEF can be a NEF that can be used to route monitoring reports to an AF. The AF’s monitoring report configuration request, which is not sensitive to latency, can still be sent to a NEF that resides in a centralized core network.

[0209] Figure 9 is an example of an optimized reporting path from a centralized network function. Figure 9 LEF in a local deployment is depicted for exposure to an AF in an EHE connected to the local deployment. The dashed lines illustrate the reporting path from the AMF or local SMF to the edge AF. The depicted reporting path corresponds to the methods introduced herein. Optimization is achieved by minimizing (or eliminating) the number of times a message crosses a geographical boundary between a centralized NF and an entity that is close in geography to the edge.

[0210] Method for edge reporting subscription via centralized NEF - method using subscription redirection. Below is described how an AF can subscribe to monitoring events via a centralized NEF. As the UE moves and connects to different local deployments and EHEs, the subscription can be forwarded to the LEF serving the corresponding deployment.

[0211] Figure 10 is a call flow example showing forwarding of edge reporting subscriptions from a centralized network exposure function. Figure 10 The flow in depicts a subscription to events forwarded by a centralized NEF to a PCF, e.g., downlink delivery data status. In the flow, for other types of events (e.g., availability after DDN failure), the PCF can be replaced by a UDM. Therefore, the forwarding functions and flow messages described for the PCF can be applied to other NFs such as the UDM.

[0212] To enable AFs to subscribe to event monitoring via a centralized NEF, reporting exposure is provided by the most suitable NEF or LEF to meet reporting requirements (e.g., latency), it is proposed to enhance the reporting subscription procedure to include new proposed reporting parameters, including reporting requirements, AF availability information, and UE routing preference indicator. Reporting requirements (e.g., latency tolerance) can be per subscription, and can also include a list of qualifiers so that the provided reporting requirements can be applied differently based on some conditions (e.g., UE location, UE reachability status, time of day, etc.). AF availability information can be, for example, AF location parameters or availability time. The UE routing preference indicator can be used as a mandatory or optional requirement to include (or preferably include) the UE in the reporting path. This feature can be used when the UE can also be handled using the report (e.g., QoS change) instead of waiting for the AF handling based on the report. The reporting parameters can be used to determine which entity (e.g., NEF or LEF) is the most suitable for reporting exposure in order to meet the reporting requirements.

[0213] In Figure 10 Step 1, the AF can send a Nnef_EventExposure_Subscribe request to the centralized NEF requesting edge hosting environment detection reporting, e.g., data delivery status. The request can include IP traffic filters and monitoring events. In step 2, the NEF can send a Npcf_EventExposure_Subscribe request to the PCF. The IP filter information, monitoring events received from step 1, and the endpoint of the requesting AF can be included in the message. The NEF can determine the address of the selected PCF for the PDU session by, for example, querying the BSF.

[0214] Using the proposed subscription reporting parameters above, the NEF can determine the most suitable entity to support the subscription reporting exposure. To support this function at the BSF, it is proposed to enhance the registration Nbsf_Management_Register operation (as described in 3GPP TS 23.502, Procedures for the 5G System; 5.2.13.2.2; Stage 2, V16.1.1 (2019-09)) to include information about available NEFs and LEFs. This means that when the PCF invokes Nbsf_Management_Register, in addition to the tuple of PDU session and PCF id (UE address, SUPI, GPSI, DNN, DN information (e.g., S-NSSAI), PCF id), it can also provide suitable NEF / LEF information based on, for example, reporting requirements or endpoint (AF) information.

[0215] When the subscribed NEF meets these requirements, the existing subscription / notification procedures can be applicable. The following description is mainly for the case where the LEF in the local deployment provides the most efficient reporting exposure.

[0216] In step 3, the PCF can send an Nsmf_EventExposure_Subscribe request message to a local SMF, which can serve the PDU session related to the IP filter information, and can include the notification endpoint of the LEF and the notification endpoint of the requesting AF. Next, in step 4, the local SMF can send an Nnef_EventExposure_Subscribe request to the corresponding LEF, requesting exposure of the report. The request can include the endpoint of the requesting AF. Then, in step 5, the LEF can send an Nsmf_EventExposure_Subscribe response to the local SMF, and in step 6, the local SMF can send an Npcf_EventExposure_Subscribe response message to the PCF, including the LEF information. Next is step 7, in which the PCF can send an Npcf_EventExposure_Subscribe response message to the NEF, including the LEF information. In step 8, the NEF can send an Nsmf_EventExposure_Subscribe response to the AF, which can include the LEF information. In step 9, the local SMF can detect an event, e.g., a change in downlink delivery status. And, in step 10, the SMF can send an Nsmf_EventExposure_Notify with a downlink delivery status event message to the LEF.

[0217] For communication with the LEF, the local SMF can use the N4 interface to the local UPF and from the local UPF use the Nx interface that has been offered to the LEF. Alternatively, a new interface or API can be defined between the local SMF and the LEF. Alternatively, a new service-based interface can be defined between the local SMF and the LEF, and the report can be sent to the LEF using the API of the service-based interface. In step 11, the LEF can send an Nnef_EventExposure_Notify with a downlink delivery status event message to the AF.

[0218] Note that assuming the LEF interface is implemented as an extension of the NEF operations currently defined by 3GPP, the messages in steps 4, 5, 10, 11 above can use Nnef operations. However, the LEF messaging can be similarly implemented but independent of the Nnef operations currently described by 3GPP.

[0219] It is noted that this method relies on the PCF determining the corresponding local SMF in addition to the proposed BSF function enhancements in this document. This means that as the UE moves and changes its connection from local deployment A to local deployment B, the PCF needs to track the subscription sent to the local SMF and LEF serving local deployment A and forward them to local deployment B and delete the old subscription. The PCF can also send an update of the subscription response to the NEF using the new LEF (corresponding to step 7). The subscription response update is forwarded by the NEF to the AF (corresponding to step 8).

[0220] Method for edge reporting subscription via centralized NEF - using policy forwarding via UE. Figure 11 is a call flow example showing the routing / distribution of edge monitoring policies via UE. Figure 11 The flow in illustrates how an AF can subscribe to monitoring events generated by NFs in local deployments via a centralized NEF. To support this method, the AF subscription procedure can be enhanced using the previously proposed reporting parameters. The reporting parameters can include reporting requirements, AF availability information, and UE routing preference indicator. The reporting parameters can be used to determine whether the subscription is related to edge event monitoring that needs to be delivered in an optimized way (e.g., via LEF in local deployments). To enable the method using policy forwarding via UE, one or more event subscriptions by the AF can be used to create an edge monitoring policy (EMP).

[0221] The AMF can encapsulate the EMP in a NAS message and can send it to the UE. As the UE changes its connection from one local deployment to another, the UE can provide the EMP to each local SMF via user plane messaging using a pre-configured FQDN (or provided in the policy itself). Alternatively, the UE can provide the EMP to each local SMF via NAS-SM messaging (e.g., PDU session establishment or PDU session modification messages). When the UPF receives a message addressed to the pre-configured FQDN, the UPF can deliver the message to the local SMF associated with the PDU session. To enable this functionality, it is proposed that the UE indicates its support for policy forwarding. The indication of support can be provided during various procedures, e.g., when registering to the core network. The network (i.e., AMF) can use this indicator to determine whether to allow the EMP to be sent to the UE.

[0222] The SMF can be configured using the policy information (EMP) that can be sent from the UE to the local SMF. This method of delivering policies to the SMF via the UE can also be used in other cases (such as cases where the SMF cannot directly communicate with the PCF or cannot receive policy information from the AMF), or for delivering other policies or configuration messages from centralized NFs to NFs in local deployments.

[0223] In Figure 11In step 1, the AF can send an Nnef_EventExposure_Subscribe request to the centralized NEF requesting edge hosting environment detection reports, e.g. data delivery status. The request can include IP traffic filters and monitoring events. Then, in step 2, the NEF can send the request to the corresponding NF, e.g. an Npcf_EventExposure_Subscribe request to the PCF. For some types of events (e.g. availability after DDN failure), the PCF can be replaced by the UDM. The IP filter information, monitoring events received from step 1 and the endpoint of the requesting AF can be included in the message. The NEF can determine the address of the selected PCF for the PDU session by querying the BSF.

[0224] In step 3, the PCF or UDM can create a corresponding EMP or can modify an existing EMP to include the new subscription. For example, the EMP can be created by the PCF and stored in the UDM. The EMP can also be forwarded to the AMF, where the EMP is encapsulated in a NAS message related to the monitoring of the UE. The EMP can contain information about one or more monitoring events and one or more receiving AFs. The EMP that can be distributed using this method can include the following:

[0225] • a policy identifier that provides a unique ID for the policy;

[0226] • a UE identification filter that provides a method to identify the UE to which the monitoring policy applies. The filter can be expressed as, for example, an IP filter or a subscription related ID;

[0227] • a notification endpoint that is associated with the endpoint information of the receiving AF. The receiving AF can include more than one receiving AF;

[0228] • a measurement or message type identifier (e.g. downlink delivery data status event ID) that determines which measurements or message types should be generated in the local deployment and sent to the AF to which the policy applies;

[0229] • a notification parameter that can include, for example, a time window in which the event notification should be forwarded to the AF. The notification parameter can include LEF information or the LEF information can be pre-configured at the local SMF;

[0230] • a policy applicability criterion that specifies to which local deployments it should apply, e.g. by indicating a geographical area, specific LADN information, etc. The local SMF can use the policy applicability criterion to verify the policy or configure the monitoring; and

[0231] • Policy delivery criteria, which specify other criteria defining how the UE should deliver the EMP to the locally deployed. For example, the policy delivery criteria can indicate to the UE that an AMF trigger is needed in order to trigger delivery. In another example, the criteria can indicate that the UE should trigger EMP delivery for any new LADN detected, among other ways. These criteria can also indicate whether the UE should use a preconfigured FQDN for EMP delivery or can configure another specific FQDN.

[0232] In step 4, the AMF can send the EMP to the UE using a NAS message. The NAS message can contain the EMP and instructions on how to send the report to the local SMF when connected to the local deployment. For example, the policy delivery criteria described above can be included in the NAS message instead of being included in the policy itself.

[0233] The subsequent steps of Figure 11 are repeated for each new local deployment when the UE connects with a new local deployment. In step 5, the UE can detect a new local deployment, for example, by detecting a new LADN. Alternatively, the UE can be triggered by the AMF after connecting to the local deployment. Then in step 6, the UE can send the EMP, encapsulated in a UP message, to the local UPF, which can then forward the message to the local SMF using the EMP or the policy delivery criteria specified in the NAS message received from the AMF. The UE can be configured with a DNN and / or S-NSSAI that can be used to send the EMP to the SMF. The UE can be configured with a URSP rule that indicates that traffic carrying the EMP should be routed to a specific DNN and / or S-NSSAI. In step 7, the local SMF can configure monitoring in the local deployment. The local SMF can configure other NFs implemented in the local deployment, for example, a NWDAF, to provide monitoring reports. In step 8, the local SMF can detect an event. The event can alternatively be detected by other NFs implemented in the local deployment. In step 9, the local SMF can send Nsmf_EventExposure_Notify with the monitoring event to the LEF, and in step 10, the LEF can send Nnef_EventExposure_Notify with the monitoring event message to the AF.

[0234] The method described above for distributing subscription information provided by the AF via a centralized NF (i.e., NEF) can be used to distribute any policy or configuration information provided via a centralized NF to NFs in a local deployment along the UE’s path. The method can also be used to distribute policy or configuration information provided via a centralized NF to servers in an edge hosting environment connected to the local deployment.

[0235] Method to report to edge server - method for centralized NF event reporting via UE. When an event is detected in the central core network (e.g., by Figure 8 the AMF) and the AF is in the edge, sending the report via NEF to the edge can be inefficient. As shown in Figure 8 sending the report via NEF can cause significant delay. In one aspect, it is proposed that if the UE is connected to a local / edge deployment and the AF that should receive the report is in the edge, the AMF can send the report via the UE using a NAS message. The NAS message can contain the event report and instructions (i.e., address) on how to send the report to the AF. For example, the following information can be sent to the UE:

[0236] • Event report, which describes an event such as a change in location, a change in SUPI / PEI association, a change in MICO mode setting, a UE reachability report, a QoS target can no longer (or can again) be achieved, or a QoS monitoring parameter;

[0237] • IP address or FQDN of the LEF that should receive the report;

[0238] • DNN or S-NSSAI that should be used in association with the PDU session used to send the report to the UE;

[0239] • AF identifier that identifies the AF to which the LEF should forward the report; and

[0240] • Transaction reference ID that can be used by the AF to associate the report with an earlier received request for a report by the AF.

[0241] This method can also be used to forward monitoring reports from the AMF or other NF in the centralized core network when the UE is reachable. This method can also support a subscription that precisely introduces reporting parameters, where a UE routing preference indicator forces or indicates a preference for UE routing. This is particularly useful for cases such as QoS monitoring, where it is beneficial for the UE to act directly on the report without waiting for AF action or commands. At the same time, the AF can also be made aware of the report via an optimized path.

[0242] Figure 12 is a call flow example showing reporting routing from centralized NFs via the UE. Figure 12 depicts a high level flow method for monitoring reporting from centralized NFs (e.g., AMF) to an AF located in an EHE via the UE.

[0243] The UE is in Figure 12Upon receiving the monitoring report from the AMF in step 2, the UE can send the monitoring report to the LEF in step 3 via a local UPF. When the UE sends the monitoring report to the LEF, the UE can choose to use an existing PDU session that has been associated with the DNN and S-NSSAI that were provided by the AMF when sending the monitoring report to the UE. Alternatively, the UE can use the DNN and S-NSSAI provided by the AMF to establish a new PDU session and use the new PDU session to send the report. The UE can also forward information such as the AF identifier to the LEF so that the LEF can determine to which AF to forward the report. The UE can also include other information such as a timestamp indicating when the report was received from the AMF, a transaction reference ID received from the AMF, etc.

[0244] In step 4, the UPF can send the report to the LEF using an interface or API. For example, Figure 9 The Nx interface in can be an N6-based interface and can use IP-based routing to send the report to the NEF. Alternatively, a new service-based interface can be defined between the UPF and the LEF and the report can be sent to the LEF using an API of the service-based interface.

[0245] Then, in step 5, the LEF can expose the information to edge AFs using the same API used at the centralized NEF Figure 9 The Ny interface supports the edge AF to LEF interface and can be implemented as the N33 / Nnef interface defined in TS 29.122. Since the UE is connected to the AF via an edge environment, this API can be enhanced to indicate to the edge AF that the report came via the UE.

[0246] To enable this functionality, it is proposed that the UE indicate its support for routing monitoring reports to the edge. The indication of support can be provided as part of the PDU session establishment procedure, during various procedures, e.g., when registering to the core network. The network (i.e., the AMF) can use this indicator to determine whether to allow the sending of monitoring reports to the UE.

[0247] To enable this functionality, it is also proposed that the core network provide the UE with an edge monitoring routing policy (EMRP). The UE can use the EMRP to receive monitoring reports and can route them to the LEF, which in turn can expose the information to the edge AF that requested it.

[0248] Figures 13A-13E A call flow example is shown that illustrates an enhanced registration procedure that enables the UE to communicate its support for routing monitoring reports. Figures 13A-13EA general registration procedure (as described in 3GPP TS 23.502, 5G System Procedures; Stage 2, V16.1.1 (2019-09)) is depicted, which is enhanced to allow the UE to convey its support for routing of monitoring reports to the LEF.

[0249] In Figures 13A-13E The following enhancements are proposed in the procedure shown below to enable the UE to support routing of monitoring reports to the LEF.

[0250] In Figure 13A Step 1 of the procedure in

[0251] In Figure 13C Step 16 of the procedure in

[0252] a) a policy identifier, which provides a unique ID for the policy;

[0253] b) a DNN, which identifies the data network the UE is connected to when routing the monitoring reports to a given LEF;

[0254] c) an IP address or FQDN of the LEF to which the policy applies;

[0255] d) a notification endpoint, which is associated with the endpoint information of the receiving AF;

[0256] e) a measurement or message type identifier (e.g., event ID), which determines which measurements or message types should be forwarded to the LEF to which the policy applies; and

[0257] f) An indicator of application level exposure of LEF information. This is a binary indicator that allows the UE to send LEF information to the AF using application layer signaling. This helps support the AF at the edge to discover the LEF they should connect to. Generally, the AF can be pre-provisioned with information about the centralized NEF. However, with the proliferation of edge deployments, it can not be feasible to pre-provision the information about all LEFs when the ECSP is different from the MNO. Instead, the UE can send this information to the AF at the application level based on the received EMRP.

[0258] In Figure 13E Step 21 of the method 20, the EMRP is returned to the UE in the registration accept message. If the UE did not include the LEF reporting capability indicator in step 1, the AMF can prompt the UE if it wants to provide the LEF report in the registration accept message.

[0259] In step 22, if the AMF prompts the UE to provide its LEF reporting capability, the UE returns the indicator to the AMF in the registration complete message. Upon receiving the LEF reporting capability indicator, the AMF can trigger the execution of a UE configuration update procedure for transparent UE policy delivery, generating and sending the EMRP. Upon receiving the EMRP, the UE routes the monitoring reports specified by the policy and sends them to the LEF.

[0260] Alternatively, the UE can send the LEF reporting capability indicator as part of the PDU session establishment procedure. In this scenario, the UE includes the indicator in the PDU session establishment request or when modifying the PDU session. The SMF receives the indicator and forwards it to the PCF. The EMRP is generated by the PCF and returned to the UE in the PDU session establishment accept response. Examples of existing types of AMF monitoring reports that use this method are: UE reachability, location reporting, availability after downlink data notification failure, etc.

[0261] Examples of existing types of PCF monitoring reports that use this method are: change of access type, signaling path status, possible inability to achieve (or ability to achieve again) QoS targets, QoS monitoring parameters.

[0262] In Figure 8 Another event detected in the central core network of the method 30 is a change in QoS of an ongoing PDU session (TS 23.503 section 6.1.3.22). This report can be sent via SMF and NAS signaling.

[0263] Method for reporting to edge servers - edge deployment NF event routing method. Figure 14 is an example of an optimized reporting path from a locally deployed NF. When an event is detected in the edge (e.g., Figure 14The sending of the report to the AF via a path that does not leave the edge is valid when the AF is in the edge and the SMF of the UE is in the edge (i.e. the SMF of the UE is in the edge and the SMF of the SMF of the UE is in the edge).

[0264] For reports generated by other NFs in the local deployment (e.g. NWDAF), the PCF can generate an edge monitoring policy (EMP) that is applicable to all (or a group) of UEs connected to the local deployment and provided to the local SMF. The EMP can be generated or stored by other NFs (e.g. UDM) to ensure availability after a DDN failure event. The edge monitoring policy provided to the local SMF can include:

[0265] • a policy identifier that provides a unique ID for the policy;

[0266] • a UE identity filter that provides a way to identify the UEs to which the monitoring policy applies, the filter can be represented as, for example, an IP filter or a subscription related ID;

[0267] • a notification endpoint that is associated with the endpoint information of the receiving AF, the receiving AF can include multiple receiving AFs;

[0268] • a measurement or message type identifier (e.g. downlink delivery data status event ID) that determines which measurements or message types should be forwarded to the LEF to which the policy applies;

[0269] • a notification parameter that includes the address (e.g. IP address) of the LEF to which the policy applies, the notification parameter can include other criteria (e.g. time window) for forwarding event notifications to the AF, such notification criteria can be used by the local SMF to configure event monitoring and notification routing; and

[0270] • a policy applicability criterion that specifies to which local deployments it should apply, for example by indicating a geographical area, specific LADN information, etc. The policy applicability criterion can be used by the local SMF to verify the policy or configure the monitoring.

[0271] The local SMF can use the edge monitoring policy to determine how to configure the monitoring and can send the monitoring reports. The local SMF can configure other NFs (e.g. NWDAF) implemented in the local deployment to provide the monitoring reports. Based on this configuration, the reports identified by filtering based on the UE identity filter and the measurement or message type identifier are generated and sent to the LEF indicated by the policy. The message sent by the local SMF to the LEF also contains the notification endpoint provided by the policy, which is used by the LEF to determine where to forward the reports.

[0272] In many cases, to report events generated by the local NF, existing interfaces can be reused. For example, the local SMF can use the N4 interface to the local UPF. From the local UPF, the reporting can use the proposed interfaces, i.e., the Nx interface between the local UPF and the LEF, and the Ny interface between the LEF and the (E)AF. Alternatively, a new interface or API can be defined between the local SMF and the LEF. In another alternative, a new service-based interface can be defined between the local SMF and the LEF, and the reporting can be sent to the LEF using the API of the service-based interface. A new interface / API or service-based interface can also be defined between other locally deployed NFs (e.g., the NWDAF) and the LEF.

Claims

1. A wireless transmit / receive unit (WTRU) hosting an edge enabler client (EEC), the WTRU comprising a processor, a communication circuit connected to a network, and a memory, the memory comprising computer executable instructions that, when executed by the processor, cause the WTRU to: send a non-access stratum (NAS) request to the network, the NAS request comprising an edge data network configuration server (EDNCS) discovery request indication indicating that the WTRU wishes to access edge computing resources of the network; and receive a NAS response from the network comprising EDNCS discovery information.

2. The WTRU of claim 1, wherein the EDNCS discovery information comprises at least one identifier of an EDNCS.

3. The WTRU of claim 2, wherein the identifier of the EDNCS is a fully qualified domain name.

4. The WTRU of claim 2, wherein the identifier of the EDNCS is an internet protocol (IP) address.

5. The WTRU of claim 1, wherein the instructions further cause the WTRU to determine to establish a PDU session based at least in part on the EDNCS discovery information.

6. The WTRU of claim 1, wherein the instructions further cause the WTRU to determine to obtain an edge service based at least in part on the EDNCS discovery information.

7. The WTRU of claim 2, wherein the instructions further cause the WTRU to determine to establish a PDU session based at least in part on the EDNCS discovery information.

8. The WTRU of claim 3, wherein the instructions further cause the WTRU to determine to establish a PDU session based at least in part on the EDNCS discovery information.

9. A server hosting a network function (NF), the server comprising a processor, a communication circuit connected to a network, and a memory, the memory comprising computer executable instructions that, when executed by the processor, cause the server to: receive a NAS request from a wireless transmit / receive unit (WTRU), the NAS request comprising an edge data network configuration server (EDNCS) discovery request indication indicating to the NF that the WTRU wishes to access edge computing resources of the network; and send a NAS response to the WTRU comprising EDNCS discovery information.

10. The server of claim 9, wherein the EDNCS discovery information comprises at least one identifier of an EDNCS.

11. The server of claim 10, wherein the identifier is a fully qualified domain name (FQDN).

12. The server of claim 10, the identifier is an internet protocol (IP) address.

13. The server of claim 9, wherein the instructions further cause the NF to derive the EDNCS discovery information from subscription information of the WTRU. ​ ​ ​ ​ 14. The server of claim 9, wherein, The WTRU determines to establish a PDU session based at least in part on the EDNCS discovery information.

Images