Apparatus and method for edge-aware distributed network

Abstract

Systems and methods are disclosed that improve the use of network functions on edge data networks. A mechanism is described herein that supports edge-assisted UE context and trigger collection, where a UE can proactively send its context information and / or any triggers (e.g., a request for a network function / service to be deployed in an edge data network, etc.) to an edge enablement server that processes the context and triggers received from its UEs. The edge enablement server can also forward the UE context and triggers to the 5G core network (5GC) upon receiving a solicitation request from the 5GC, or if the 5GC has subscribed to be notified about UE context and triggers. A network repository function is provided as a new network function that collects, stores, and manages edge data network information.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 955,706, filed December 31, 2019, which is incorporated herein by reference. Background Art

[0003] The 5G System (5GS) architecture comprises a set of network functions (NFs) and network entities. The 5G Core (5GC) network utilizes a service-based principle, where each NF can be either a service provider or a service consumer. As a service provider, NFx includes a set of services (or functions) and provides a service-based interface (SBI) through which other NFs, acting as service consumers, can access these services. For transport layer security, 3GPP NFs support Transport Layer Security (TLS) and, if network security is not provided by other means, use TLS within the Public Land Mobile Network (PLMN).

[0004] To consume services provided by an NF service provider, an NF service consumer must first discover the NF service provider and its services. To be discovered by an NF service consumer, the NF service provider must first register itself with the repository. For example, the Network Data Analytics Function (NWDAF) provides two services for the Nnwdaf interface: Nnwdaf_AnalyticsSubscription and Nnwdaf_AnalyticsInfo. Nnwdaf_AnalyticsSubscription enables NF service consumers to subscribe to and unsubscribe from different types of analytics with the NWDAF. Summary of the Invention

[0005] This summary is provided to introduce some concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages mentioned in any part of this disclosure.

[0006] Disclosed are systems and methods for improving the use of network functions on edge data networks. A mechanism for supporting edge-assisted UE context and trigger collection is described herein, wherein a UE can proactively send its context information and / or any triggers (e.g., requests for network functions / services to be deployed in the edge data network, etc.) to an edge enabling server, which will process the context and triggers received from all its UEs. Upon receiving a solicitation request from the 5GC, or if the 5GC has subscribed to receive notifications about UE context and triggers, the edge enabling server can also forward the UE context and triggers to the 5GC. A network repository function is provided as a new network function for collecting, storing, and managing edge data network information. NF consumers can discover edge data networks and edge servers from the edge network repository function (ENRF). The edge-assisted distributed network function solution is configured to distribute network functions from the 5GC to the edge data network, thereby facilitating UEs and edge applications to access network functions more efficiently, such as with reduced latency. The edge-assisted messaging service on the 5G system enables MSGin5G to fully utilize the edge data network to improve message delivery efficiency, especially for point-to-point messages. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The above summary of the invention and the following detailed description can be better understood when read in conjunction with the accompanying drawings. Various aspects of the present disclosure are shown for the purpose of illustrating the present disclosure. However, the present disclosure is not limited to the specific aspects discussed. In the accompanying drawings:

[0008] Figure 1A An example communication system is illustrated in which the methods and apparatus described and claimed herein may be implemented.

[0009] Figure 1B is a block diagram of an example device or apparatus configured for wireless communication;

[0010] Figure 1C is a system diagram of an example radio access network (RAN) and core network;

[0011] Figure 1D Here is another example system diagram of the RAN and core network;

[0012] Figure 1E Here is another example system diagram of the RAN and core network;

[0013] Figure 1F is a block diagram of an example computing system;

[0014] Figure 1G is a block diagram of another example communication system;

[0015] Figure 2Illustrate the non-roaming 5G system architecture;

[0016] Figure 3 Illustrate the service-based interface (SBI) protocol stack;

[0017] Figure 4 Illustrate the application architecture used to enable edge applications;

[0018] Figure 5 Illustration of messaging services via 5G systems;

[0019] Figure 6 Illustrates concurrent attachments from large-scale IoT devices;

[0020] Figure 7 Illustration of the architectural framework for implementing the proposed edge-assisted network function distribution

[0021] Figure 8 Illustration of edge-assisted UE context and trigger collection;

[0022] Figure 9 Illustration of edge-assisted MSGin5G services;

[0023] Figure 10 Diagram illustrating the activation of MSGin5G edge server;

[0024] Figure 11 Diagram illustrating edge-assisted messaging;

[0025] Figure 12 Illustrated illustration of edge-assisted messaging;

[0026] Figure 13 Diagram illustrating edge network / server registration using NFD instructions;

[0027] Figure 14 Diagram illustrating edge network / server discovery;

[0028] Figure 15 Diagram illustrating NFD policy configuration;

[0029] Figure 16 Illustrate the process for generating NFD triggers;

[0030] Figure 17 Illustrate a process for distributing selected NFs to selected edge networks;

[0031] Figure 18 Illustrate the processing used to fully exploit distributed network capabilities;

[0032] Figure 19 illustrates a process for deactivating a distributed network function;

[0033] Figure 20 Diagram illustrating the interaction between DNF and CNF;

[0034] Figure 21 Illustration of enhanced edge-enabled client registration for indicating MSGin5G;

[0035] Figure 22 Illustration of enhanced edge application registration for reporting EAS to 5GC;

[0036] Figure 23 Diagram illustrating edge-enabling server instantiation;

[0037] Figure 24 Illustration of a UE user interface for UE context / trigger collection;

[0038] Figure 25 Illustration of a UE user interface for MSGin5G messaging;

[0039] Figure 26 Illustration of UE user interface for MSGin5G server indication. DETAILED DESCRIPTION

[0040] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities—including work 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), and LTE-Advanced standards. 3GPP has begun work on the standardization of the next generation cellular technology known as New Radio (NR) (also referred to as "5G"). 3GPP NR standard development is expected to include the definition of next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 6 GHz and new ultra-mobile broadband radio access above 6 GHz. Flexible radio access is expected to consist of new, non-backwards compatible radio access in new spectrum below 6 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 requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra-mobile broadband access, for example, for indoor applications and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with sub-6 GHz flexible radio access, with cmWave and mmWave-specific design optimizations.

[0041] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide range of user experience requirements for data rates, latency, and mobility. These use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, ultra-high broadband access indoors, broadband access in crowds, 50+ Mbps ubiquitous, ultra-low-cost broadband access, and mobile broadband in vehicles), emergency communications, massive machine-type communications, network operations (e.g., network slicing, routing, migration and interworking, energy conservation), and enhanced vehicle-to-everything (eV2X) communications, which can include vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), vehicle-to-pedestrian (V2P), and vehicle-to-other-entities communications. Specific services and applications within these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud office, first responder connectivity, car emergency calling, disaster alerts, real-time gaming, multi-person video calling, autonomous driving, augmented reality, the tactile internet, and virtual reality, to name a few. All of these and other use cases are envisioned in this article.

[0042] Figure 1A An embodiment of an example communication system 100 is illustrated in which the methods and apparatus described and claimed herein may be implemented. As shown, the example communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (which may be generally or collectively referred to as WTRUs 102), 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 a V2X server (or ProSe function and server) 113, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Figure 1A-1E, but it should be understood that for the various use cases envisioned for 5G wireless communications, each WTRU may include or be implemented in any type of device or apparatus configured to send and / or receive wireless signals, including, by way of example only, a 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, a consumer electronic product, a wearable device such as a smart watch or smart clothing, a medical or e-health device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train or airplane, and the like.

[0043] The communication system 100 may also include a base station 114a and a base station 114b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. The base station 114b may be any type of device configured to wiredly and / or wirelessly interface with at least one of the RRHs (remote radio heads) 118a, 118b, the TRPs (transmit and receive points) 119a, 119b, and / or the RSUs (roadside units) 120a, 120b to facilitate access to one or more communication networks, such as the core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRPs 119a, 119b may 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 networks 106 / 107 / 109, the Internet 110, and / or other networks 112. The RSUs 120a and 120b may 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 networks 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. For example, the base stations 114 a and 114 b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114 a and 114 b are depicted as a single element, it will be appreciated that the base stations 114 a and 114 b may include any number of interconnected base stations and / or network elements.

[0044] Base station 114a may be part of the RAN 103 / 104 / 105, which may 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. Base station 114b may be part of the RAN 103b / 104b / 105b, which may 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. Base station 114a may be configured to transmit and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Cells may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, eg, one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, thus, may utilize multiple transceivers for each sector of the cell.

[0045] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c over an air interface 115 / 116 / 117, which may 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 may be established using any suitable radio access technology (RAT).

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

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

[0048] The WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g may communicate with one another via an air interface 115d / 116d / 117d (not shown), which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115d / 116d / 117d may be established using any suitable radio access technology (RAT).

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

[0050] In an embodiment, the base stations 114a and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d in the RAN 103b / 104b / 105b 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 between the mobile devices 102a, 102b, 102c and the base stations 114a or the RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, 102f. The air interface 115 / 116 / 117 can implement Long Term Evolution (LTE) or LTE-Advanced (LTE-A) that can utilize frequency spectrum allocated above 20 kilohertz (kHz) to establish the air interface 115 / 116 / 117 or 115c / 116c / 117c respectively. In the future, the air interface 115 / 116 / 117 can implement 3GPP NR technology. The LTE and LTE-A technology includes LTE D2D and V2X technology and interfaces (such as sidelink communication, etc.). The 3GPP NR technology includes NR V2X technology and interfaces (such as sidelink communication, etc.).

[0051] In an embodiment, the base stations 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, 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.

[0052] Figure 1AThe base station 114c in the example may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, etc. In an embodiment, the base station 114c and the WTRU 102e may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114c and the WTRU 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114c and the WTRU 102e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or a femtocell. Figure 1A As shown in FIG, base station 114b may have a direct connection to the Internet 110. Thus, base station 114c may not be required to access the Internet 110 via core network 106 / 107 / 109.

[0053] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with the core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, and / or perform high-level security functions, such as user authentication.

[0054] Although not in Figure 1A Although not shown in the figure, it will be appreciated that the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, which may utilize an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that employs a GSM radio technology.

[0055] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) from the TCP / IP internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT.

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

[0057] Figure 1B is a block diagram of an example device or apparatus, such as WTRU 102, configured for wireless communication according to the embodiments illustrated herein. Figure 1B As shown in the example WTRU 102, it 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 other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the above elements while still being consistent with the embodiment. In addition, the embodiment contemplates that the base stations 114a and 114b, and / or the nodes that the base stations 114a and 114b may represent, such as but not limited to transceiver stations (BTS), Node-Bs, site controllers, access points (APs), home node-Bs, evolved home node-Bs (eNodeBs), home evolved node-Bs (HeNBs), home evolved node-B gateways, and proxy nodes, etc., may be included in the Figure 1BSome or all of the elements depicted in and described herein.

[0058] The processor 118 may 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 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. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, although it is appreciated that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0059] The transmit / receive element 122 may be configured to transmit or receive signals to and from a base station (e.g., base station 114a) via air interface 115 / 116 / 117. For example, in an embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In another embodiment, the transmit / receive element 122 may be configured to transmit and receive both RF signals and optical signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0060] In addition, although the transmit / receive element 122 is Figure 1B Although depicted as a single element in the figures, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interfaces 115 / 116 / 117.

[0061] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, for example, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

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

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

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

[0065] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as an accelerometer, a biometric (e.g., fingerprint) sensor, an electronic compass, a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port or other interconnect interface, a vibration device, a television transceiver, a hands-free headset, modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, etc.

[0066] The WTRU 102 may be implemented in other devices or apparatuses, such as sensors, consumer electronics, wearable devices such as smart watches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, and vehicles such as cars, trucks, trains, or airplanes. The WTRU 102 may be connected to other components, modules, or systems of such devices or apparatuses via one or more interconnect interfaces, such as one of the peripheral devices 138.

[0067] Figure 1C 1 is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As described above, the RAN 103 may employ UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. Figure 1C As shown in FIG, the RAN 103 may include Node-Bs 140a, 140b, 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. Each Node-B 140a, 140b, 140c may be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0068] like Figure 1CAs shown in FIG, Node-Bs 140a and 140b can communicate with RNC 142a. Additionally, Node-B 140c can communicate with RNC 142b. Node-Bs 140a, 140b, and 140c can communicate with respective RNCs 142a and 142b via an Iub interface. RNCs 142a and 142b can communicate with each other via the Iub interface. Each RNC 142a and 142b can be configured to control the respective Node-B 140a, 140b, and 140c to which it is connected. Additionally, each RNC 142a and 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handoff control, macrodiversity, security functions, data encryption, and the like.

[0069] Figure 1C The core network 106 shown in FIG may include 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. Although each of the above elements is depicted as part of the core network 106, it is appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

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

[0071] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 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.

[0072] As described above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0073] Figure 1D1 is a system diagram of the RAN 104 and the core network 107 in accordance with an embodiment. As noted above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

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

[0075] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in uplink and / or downlink, etc. Figure 1D As shown in FIG, eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0076] Figure 1D The core network 107 shown in FIG may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the above elements is depicted as part of the core network 107, it is appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0077] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation and deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and 102c, and the like. The MME 162 may 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.

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

[0079] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 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.

[0080] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may 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. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0081] Figure 1E 1 is a system diagram of the RAN 105 and the core network 109 in accordance with an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As described further below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0082] like Figure 1EAs shown in FIG, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In an embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, for example, the base station 180a may use multiple antennas to transmit and receive wireless signals to and from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handover triggering, tunnel establishment, radio resource management, traffic classification, and Quality of Service (QoS) policy enforcement. The ASN gateway 182 may act as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0083] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. Additionally, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, and 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0084] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point, which includes protocols that facilitate WTRU handover and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols that facilitate mobility management based on mobility events associated with each of the WTRUs 102a, 102b, and 102c.

[0085] like Figure 1EAs shown in FIG, the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, which includes protocols that facilitate data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, and accounting (AAA) server 186, and a gateway 188. While each of the above elements is depicted as part of the core network 109, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0086] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may 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, and 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and supporting user services. The gateway 188 may facilitate intercommunication with other networks. For example, the gateway 188 may 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 landline communication devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0087] Although not in Figure 1E , however, it will be appreciated that the RAN 105 may be connected to other ASNs, and the core network 109 may be connected to other core networks. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference point, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0088] Described in this article and Figure 1A 、 Figure 1C 、 Figure 1D and Figure 1EThe core network entities shown in the diagram are identified using the names given to these entities in certain existing 3GPP specifications, but it should be understood that in the future, these entities and functions may be identified by other names, and in future specifications released by 3GPP, including future 3GPP NR specifications, some entities or functions may be merged. Figure 1A 、 Figure 1B 、 Figure 1C 、 Figure 1D and Figure 1E The specific network entities and functions described and illustrated in the present disclosure are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or defined in the future.

[0089] Figure 1F is a block diagram of an example computing system 90 in which Figure 1A 、 Figure 1C 、 Figure 1D and Figure 1E 109, such as certain nodes or functional entities in RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, or other network 112. Computing system 90 may comprise a computer or server and may be primarily controlled by computer-readable instructions, which may be in the form of software, regardless of where or how such software is stored or accessed. Such computer-readable instructions may be executed in processor 91 to cause computing system 90 to operate. Processor 91 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, or the like. Processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0090] In operation, processor 91 retrieves, decodes, and executes instructions, and transfers information to and from other resources via the computer system's primary data transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for transmitting data, address lines for transmitting addresses, and control lines for transmitting interrupts and for operating the bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0091] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. Such memory includes circuitry that allows information to be stored and retrieved. ROM 93 typically contains stored data that is not easily modified. Data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts virtual addresses into physical addresses when instructions are executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes is set up, it cannot access memory within the virtual address space of other processes.

[0092] In addition, the computing system 90 may include a peripheral device controller 83 , which is responsible for transmitting instructions from the processor 91 to peripheral devices, such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

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

[0094] In addition, the computing system 90 may include a communication network that can be used to connect the computing system 90 to an external communication network, such as Figure 1A 、 Figure 1B 、 Figure 1C 、 Figure 1D and Figure 1EThe RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112 of the computing system 90 are connected to the computing system 90 so as to enable the computing system 90 to communicate with other nodes or functional entities of these networks. Communication circuitry, such as network adapter 97, can be used to perform the sending and receiving steps of certain devices, nodes or functional entities described herein, either alone or in combination with processor 91.

[0095] Figure 1G The diagram illustrates one embodiment of an example communication system 111 in which the methods and apparatus described and claimed herein may be implemented. As shown, the example communication system 111 may include wireless transmit / receiver units (WTRUs) A, B, C, D, E, F, a base station, a V2X server, and RSUs A and B, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. One, some, or all of the WTRUs A, B, C, D, E may be outside the range of the network (e.g., outside the cell coverage boundary shown as a dashed line in the diagram). WTRUs A, B, C form a V2X group, with WTRU A being the group leader and WTRUs B and C being group members. WTRUs A, B, C, D, E, F may communicate via a Uu interface or a sidelink (PC5) interface.

[0096] It should be understood that any or all of the devices, systems, methods, and processes described herein may be implemented in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor, such as processor 118 or 91, causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions executed on a processor of a device or computing system configured for wireless and / or wired network communications. Computer-readable storage media include volatile and non-volatile, removable, and non-removable media implemented in any non-temporary (e.g., tangible or physical) method or technology for storage of information, although such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage devices, cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other tangible or physical medium that can be used to store the desired information and can be accessed by a computing system.

[0097] Figure 2 An example 5G system (5GS) architecture 200 is shown. Figure 2Examples include a set of network functions (NFs) and a number of network entities. Specifically, the 5G Core (5GC) network utilizes a service-based principle, where each NF can be either a service provider or a service consumer. As a service provider, NFx includes a set of services (or functions) and provides a service-based interface (SBI) through which other NFs, acting as service consumers, can access these services.

[0098] As in Figure 2 As shown in the example of FIG, , UE 201 can access Access and Mobility Management Function (AMF) 203 via Radio Access Network ((R)AN) 202 via the N1 interface. (R)AN 202 can access AMF 203 via the N2 interface. (R)AN 202 can access User Plane Function (UPF) 204 via the N3 interface. UPF 204 can access Session Management Function (SMF) 205 via the N4 interface. UPF 204 can access Data Network (DN) 206 via the N6 interface. Policy Control Function (PCF) 207 can access AMF 208 via the N15 interface. AMF 203 can access SMF 205 via the N11 interface. SMF 205 can access Unified Data Management (UDM) 209 via the N10 interface. AMF 203 can access Network Slice Selection Function (NSSF) 210 via the N22 interface. The AMF 203 may access the Authentication Server Function (AUSF) 211 via the N12 interface. The AMF 203 may access the UDM 209 via the N8 interface. The UDM 209 may be connected to the AUSF 211 via the N13 interface. The Network Exposure Function (NEF) 212 exposes capabilities and services in the 5G core network to the Application Function (AF) 213 via the N33 interface.

[0099] Figure 3 300. Figure 3 In the example, HTTP / 2 protocol 302 with JavaScript Object Notation (JSON) is used as the application layer serialization protocol. For transport layer security protection, all 3GPP NFs support Transport Layer Security (TLS) 303, which can be used within the Public Land Mobile Network (PLMN) if network security is not provided by other means. Figure 3 The example also shows an application layer 301 , a transmission control protocol (TCP) layer 304 , an Internet protocol (IP) layer 305 , and an L2 layer 306 .

[0100] To consume services provided by an NF service provider, an NF service consumer must first discover the NF service provider and its services. To be discovered by an NF service consumer, the NF service provider must first register itself with the repository. For example, the Network Data Analytics Function (NWDAF) provides two services for the Nnwdaf interface: Nnwdaf_AnalyticsSubscription and Nnwdaf_AnalyticsInfo. Nnwdaf_AnalyticsSubscription enables NF service consumers to subscribe to and unsubscribe from different types of analytics from NWDAF.

[0101] The Network Repository Function (NRF) is a NF that has the services listed in Table 1 and provides the following functions through these services:

[0102] Support service discovery function;

[0103] It can receive an NF discovery request from an NF instance or a Service Communication Agent (SCP), and provide information of the discovered (to-be-discovered) NF instance to the NF instance or the SCP;

[0104] Maintaining NF profiles of available NF instances and the services they support; and

[0105] Notify subscribed NF service consumers or SCPs of newly registered / updated / deregistered NF instances along with their NF services.

[0106]

[0107] Table 1. NF services provided by NRF

[0108] The Policy Control Function (PCF) of the NF provides the following services as listed in Table 2 to support the following functions:

[0109] Supports a unified policy framework to manage network behavior.

[0110] Provide policy rules to the control plane functions to enforce them.

[0111] Access subscription information relevant to policy decisions in the Unified Data Repository (UDR).

[0112]

[0113]

[0114] Table 2. NF services provided by PCF

[0115] The Network Data Analysis Function (NWDAF) is a network entity that provides the following functions:

[0116] Event subscription based data collection provided by AMF, SMF, PCF, UDM, AF (directly or via NEF) and OAM;

[0117] Retrieving information from data repositories (e.g. from UDR via UDM for information related to subscribers);

[0118] Retrieving information about NFs (e.g. NRF for NF related information and NSSF for slice related information); and

[0119] Providing analytics on-demand to consumers based on “request-response” and / or “subscription-notification” mechanisms.

[0120] The Unified Data Repository (UDR), as a NF, supports the following functions:

[0121] Storing and retrieving subscription data through the Unified Data Management (UDM);

[0122] Storing and retrieving policy data through the PCF;

[0123] Storing and retrieving structured data for exposure;

[0124] Application data (including Packet Flow Descriptions (PFD) for application detection, AF request information for multiple UEs, 5GLAN group information for 5GLAN management); and

[0125] Storing and retrieving NF set IDs corresponding to subscriber identifiers (e.g. IMPI, IMPU).

[0126] The UDR is located in the same PLMN where NF service consumers use Nudr to store and retrieve data from. Nudr is an intra-PLMN interface.

[0127] The Service Communication Proxy (SCP) is a network entity that provides the following functions as specified in 3GPP TS 23.288:

[0128] Indirect communication between two NFs;

[0129] Delegated discovery for assisting an NF to discover other NFs and their services from the NRF;

[0130] Message forwarding and routing to destination NF / NF service;

[0131] Communication security (e.g. authorization of NF service consumers to access NF service producer APIs), load balancing, monitoring, overload control, etc.; and

[0132] Optionally interact with other entities (e.g., UDR) to resolve UDM group ID / UDR group ID / AUSF group ID / PCF group ID based on UE identity (e.g., SUPI).

[0133] TS23.501 also defines some edge computing enablers, such as:

[0134] User plane (re)selection: The 5G core network (re)selects the UPF to route user traffic to the local data network;

[0135] Session and service continuity to enable UE and application mobility;

[0136] Application functions can influence UPF (re)selection and traffic routing via PCF or NEF;

[0137] QoS and charging: PCF provides QoS control and charging rules for traffic routed to the local data network; and

[0138] Local Area Data Network (LADN) support: The 5G core network provides support for connecting to LADN in an area where the application is deployed.

[0139] In addition, TR 23.748 is studying and evaluating potential architectural enhancements to support edge computing (EC) in 5GC. For example, it may study the following enhancements:

[0140] Discovery of the IP addresses of application servers deployed in the EC environment;

[0141] 5GC enhancements to support seamless changes of application servers serving UEs;

[0142] How to efficiently (and with low latency) provide information about, for example, the QoS status of the data path to the local application server;

[0143] Support for traffic steering in N6-LANs deployed in edge computing environments, including support for end-user traffic to be sent to the central N6 interface of the data network after being processed by local application servers;

[0144] Support PDU session anchor change when the application server does not support notification of UE IP address change; and

[0145] Supports I-SMF insertion or reselection based on AF requests to route traffic to application servers deployed in edge computing environments.

[0146] 3GPP TR 28.803 specifies the use cases, requirements, and scenarios for the 3GPP management system to support the deployment of edge computing. Some of the identified requirements include:

[0147] The Network Function Virtualization Orchestrator (NFVO) should have the capability to allow the 3GPP management system to instantiate VNFs with conditions (e.g., location constraints);

[0148] The 3GPP management system should have the ability to configure the SMF or NRF (e.g., to add or remove UPF); and

[0149] The 3GPP management system should have the capability to collect performance measurements (eg, latency, data volume) of the connection from the UE to the 3GPP UPF.

[0150] Figure 4 An application architecture 400 for enabling edge applications in a 3GPP network is shown. Figure 4 The example of FIG4 shows that an edge data network (EDN) 401 includes a functional entity referred to herein as an edge enabling server (EES) 411. EES 411 can provide support functions required for edge application servers 412 to operate in EDN 401. For example, EES 411 can provide information related to edge application servers 412, such as availability, to edge enabling clients (EECs) 420.

[0151] EEC 420 may provide support functions required for application client 421. For example, it may discover edge application servers 412 available in EDN 401. EEC 420 may also retrieve and provide configuration information to enable application data traffic 404 to be exchanged with edge application servers 412 (e.g., via 3GPP network 405).

[0152] The edge data network configuration server 403 may provide the support functions required for the UE 402 to connect with the EES 411 .

[0153] like Figure 4 As shown in , many edge applications can be deployed in the edge data network and make full use of the edge enabling servers deployed in the edge data network. In addition, once the edge applications are deployed in the edge data network, they should be discoverable and provide more efficient services to the UE and other edge applications. In addition, edge applications can interact with cloud applications. In addition, due to the emergence of edge data networks, it is expected that UEs can benefit by directly accessing more nearby edge applications instead of accessing remote cloud applications. In this way, for connectivity, UE context becomes more critical because it may affect how applications and services in the edge data network are effectively managed and fully utilized.

[0154] Figure 5The use case of the message service (MSGin5G) 500 in the 5G system described in TS22.262 and TR 23.700-24 is shown. MSGin5G 500 supports point-to-point messaging (e.g., from UE A to UE B), application-to-point messaging (e.g., from App1 server 511 to UE B), multicast messaging (e.g., from App1 server 511 to UE B and UE C), and broadcast messaging (e.g., from App2 server 512 to all UEs in a certain location). MSGin5G as service 501 can reside in 5GC 502. Note that even for point-to-point messaging between two UEs (e.g., UE A and UE B) under the same 5G RAN, the message needs to be first sent from the source UE (e.g., UE A) to the MSGin5G server 510, which can further forward the message to the destination UE (e.g., UE B).

[0155] Figure 6 Another example use case is shown. Figure 6 In the example shown in Figure 6, massive Internet of Things (IoT) devices 601 connect to the 5GS to report sensory data to IoT applications. This example can be deployed in the cloud system 602 and / or the edge data network 603. Although these IoT devices are deployed in different locations and may only need to communicate with edge applications in different edge data networks 603, these IoT devices may try to attach to the 5GS at the same time, which may suddenly cause high overhead for the backhaul link and network functions 604 such as AMF and SMF. This use case shows that the centralized network function 604 in the mobile core network may become overloaded by simultaneous connections from massive IoT devices and may not work properly in the worst case.

[0156] The previous three use cases highlight the following four issues:

[0157] 5GS lacks the ability to collect, store, and manage edge data network information;

[0158] 5GS, including the edge data network, lacks the functionality to collect, store, and manage UE context information and triggers generated by UEs;

[0159] The MSGin5G service lacks mechanisms to fully utilize edge data networks; and

[0160] Although it has been mentioned that functions such as UPF can be deployed at the edge, 5GS lacks a mechanism to determine designated NF instances and services and distribute them to the edge data network.

[0161] The embodiments described herein address the above-mentioned issues.

[0162] In one embodiment, a mechanism is described that supports edge-assisted UE context and trigger collection, where a UE can proactively send its context information and / or any triggers (e.g., a request for network functions / services to be deployed in an edge data network, etc.) to an edge enabler server, which can handle the context and triggers received from all of its UEs. The edge enabler server can also forward the UE context and triggers to the 5GC upon receiving a solicitation request from the 5GC, or if the 5GC has subscribed to be notified about UE context and triggers.

[0163] For example, a UE can perform operations including:

[0164] The UE can receive a first context / trigger subscription from a first network entity;

[0165] The UE can generate a first context / trigger based on a user input and / or a configured context / trigger generation policy;

[0166] The UE can send the first context / trigger to a second network entity; and

[0167] The UE can receive a first response from a third network entity.

[0168] The first network entity can be a network function in the 5GC, an edge enabler server, or an edge enabler client. The second network entity can include an edge enabler client. The second network entity, upon receiving the first context / trigger, can generate a second context / trigger based on the first context / trigger. The second network entity can send the second context / trigger to an edge enabler server, where the edge enabler server can combine the context / triggers received from multiple edge enabler clients; the edge enabler server can generate an aggregated context / trigger and send it to a network function in the 5GC.

[0169] In another example, an edge enabler server can perform operations including:

[0170] The edge enabler server can receive a second context / trigger from a second network entity;

[0171] The edge enabler server can generate an aggregated context / trigger based on the first context / trigger and the second context / trigger;

[0172] The edge enabler server can send the aggregated context / trigger to a third network entity;

[0173] The edge enabler server can receive a first response from the third network entity;

[0174] The edge enabling server may generate a second response based on the first response and may send the second response to the first network entity;

[0175] The edge-enabling server may generate a third response based on the first response, and may send the third response to the second network entity;

[0176] The edge enabling server may determine a first set of new network functions and services based on the first context / trigger and / or the second context / trigger;

[0177] The edge enabling server may request a first set of new network functions and services from the fourth network entity; and

[0178] The edge enabling server may receive a fourth response from the fourth network entity.

[0179] The first network entity may include an edge-enabled client. The second network entity may include an edge-enabled client. The third network entity may include a network function in a 5GC. The fourth network entity may include a network function in a 5GC.

[0180] In a second embodiment, an edge-assisted messaging service on a 5G system is described herein to enable MSGin5G to fully utilize edge data networks to improve message delivery efficiency, especially for point-to-point messages.

[0181] For example, the UE may perform the following operations:

[0182] The UE may send a first registration request indicating a message service requirement and preference to the first network entity; and

[0183] The UE may receive a first response from the first network entity.

[0184] The first response may include the address of one or more MSGin5G servers. Each MSGin5G server may be deployed in an edge data network or in the cloud.

[0185] In another example, the UE may perform the following operations:

[0186] The UE may send a first discovery request to the first network entity to discover the MSGin5G server;

[0187] The UE may receive a first response from the first network entity;

[0188] The UE may send a first message service request to the second network entity;

[0189] The UE may receive a second response from the second network entity;

[0190] The UE may send a first message to the second network entity; and

[0191] The UE may receive a third response from the second network entity.

[0192] The first discovery request may indicate a target UE identifier. The first network entity may be an edge-enabled client or an edge-enabled server. The first response may include multiple identifiers of discovered MSGin5G servers. The first message service request may indicate a source UE identifier and multiple target UE identifiers. The second response may include a list of approved target UE identifiers. The first message may include a message delivery priority for each target UE and a list of target UE identifiers.

[0193] In another example, the MSGin5G edge server located in the first edge data network can perform the following operations:

[0194] The MSGin5G edge server can register itself with the NRF or MSGin5G server in the 5GC;

[0195] MSGin5G edge servers can discover other MSGin5G edge servers from NRF or MSGin5G servers;

[0196] The MSGin5G edge server can establish multiple UE subgroups;

[0197] The MSGin5G edge server may send the established subgroup to the MSGin5G server;

[0198] The MSGin5G edge server may send periodic status reports to the MSGin5G server indicating message forwarding statistics at the MSGin5G edge server;

[0199] The MSGin5G edge server may receive the first message from the MSGin5G server, another MSGin5G edge server, an application, or a UE;

[0200] The MSGin5G edge server may determine a recipient of the first message;

[0201] The MSGin5G edge server can forward messages to the recipient via different paths and:

[0202] If the recipient is an application in the cloud, the first message is forwarded to the MSGin5G server;

[0203] If the recipient is close to another nearby MSGin5G edge server, forward the first message to the other MSGin5G edge server;

[0204] If the recipient is an application deployed in the first edge data network, forward the first message directly to the recipient (or via a local UPF / SEF);

[0205] If the recipient is a UE that fully utilizes the first edge data network, forwarding the first message to the recipient via a local UPF / SEF deployed in the first edge data network; and

[0206] Otherwise, the first message is forwarded to the MSGin5G server.

[0207] In the third embodiment, the edge network repository function (ENRF) as a NF is described, which can collect, store and manage edge data network information. NF consumers can discover edge data networks and edge servers from ENRF.

[0208] For example, ENRF can do the following:

[0209] The ENRF may receive an edge network and server (de)registration request from the first network entity;

[0210] The ENRF may send an edge network and server (de)registration response to the first network entity;

[0211] The ENRF may receive an edge network and server discovery request from a second network entity; and

[0212] The ENRF may send an edge network and server discovery response to the second network entity.

[0213] The ENRF may maintain a list of registered edge data networks and a list of registered edge servers deployed in different locations. An edge network and server registration request may include the location of one or more edge data networks, the names of one or more edge data networks, the identifiers of one or more edge servers deployed in one or more edge data networks, a list of (not)allowed UEs for the edge data network and / or edge server, a list of UEs currently using the edge server, etc. The first network entity may be an edge enabling server, an edge network controller, an edge network gateway, an ETSIMEC coordinator, a mobile cellular network OAM system, etc. An edge data network and server registration response may include the assigned name of the edge data network or edge server, a list of (not)allowed edge applications for the edge data network, a list of (not)allowed UEs for the edge data network and / or edge server, etc. An edge network and server discovery request may include a discovery filter for discovering edge data networks in a given location, a discovery filter for discovering edge data networks where a given edge application is located, a discovery filter for discovering edge servers in a given location, a discovery filter for discovering edge servers where a given edge application is located, a discovery filter for discovering UEs currently using one or more edge data networks, a discovery filter for discovering UEs currently using one or more edge servers, etc. The second network entity may be a network function consumer (e.g., AMF, SMF, etc.), a network function distribution manager, an edge network controller, an edge server, an ETSIMEC coordinator, a mobile cellular network OAM system, etc.

[0214] In a fourth embodiment, this document describes an edge-assisted distributed network function solution to distribute network functions from 5GC to edge data networks, thereby facilitating more efficient (e.g., reduced latency) access to network functions by UEs and edge applications. For example, the following process may be performed:

[0215] Configure strategies for distributing network functions;

[0216] Generate triggers for network function distribution;

[0217] Distribute selected network functions from the core network to selected edge data networks;

[0218] Leverage network capabilities deployed at the edge of the data network; and

[0219] Coordinate network functions at the edge data network with network functions at the core network.

[0220] In another embodiment, the UE may perform the following operations:

[0221] The UE may receive a network function distribution policy configuration request from the first network entity that may include one or more network function distribution policies;

[0222] UE can verify the network function distribution strategy;

[0223] UE can store network function distribution strategy;

[0224] The UE may generate a network function distribution policy configuration response;

[0225] The UE may send a network function distribution policy configuration response to the first network entity;

[0226] The UE may generate a network function distribution trigger for distributing a first network function in the core network to the first edge node;

[0227] The UE may send a network function distribution triggering request to the third network entity;

[0228] The UE may receive a network function distribution trigger response from the third network entity;

[0229] The UE may receive a network function distribution notification request from the fourth network entity, the request indicating an address of a second network function that is a peer network function of the first network function and is successfully deployed at the first edge node;

[0230] The UE may send a network function access request to the second network function to access the second network function;

[0231] The UE may receive a network function access response from the second network function;

[0232] The UE may receive a network function adjustment notification request from the fifth network entity to switch from using the second network function at the first edge node to the first network function at the core network or to another network function at another edge node;

[0233] The UE may send a network function adjustment notification response to the fifth network entity; and

[0234] The UE may send a network function access request to a first network function at the core network or to another network function at another edge node.

[0235] The first network entity may include a policy control function, a network function distribution manager, an edge server, etc. A network function distribution policy may specify conditions for triggering the distribution of one or more network functions from a core network to one or more edge servers in one or more edge data networks. The network function distribution trigger request may indicate an identifier for the first network function, the location of a first edge node to which the first network function is to be distributed, contextual information about the first edge node (such as an identifier of the edge server and / or an identifier of the edge data network), a triggering reason, a time to distribute the first network function to the first edge node, a priority for distributing the first network function to the first edge node, a coordination mode between the first network function of the core network and its peer network function to be established at the first edge node, etc. The third network entity may include a network function distribution manager, a first network function, an edge server, etc. The network function distribution notification request may include an identifier for the second network function, an identifier for a user plane function for accessing the second network function, a lifetime for the second network function, an identifier for the edge server where the second network function resides, a set of user equipment devices authorized to access the second network function, a set of edge applications authorized to access the second network function, etc. The fourth network entity may include a network function distribution manager, a first network function, an edge server at the first edge node, etc. The network function access request may indicate a need to switch back to the first network function after a duration. The network function access response may include a trigger for switching back to the first network function. The network function adjustment notification request may include an identifier of the first network function, a mode for synchronizing content and context information between the second network function and the first network function, etc. The fifth network entity may be a network function distribution manager.

[0236] In another example, the UE may perform the following operations:

[0237] The UE can receive the network function distribution policy from the PCF;

[0238] The UE may send a network function distribution policy configuration response to the PCF;

[0239] The UE may generate a network function distribution trigger for distributing a first network function in the core network to the first edge node;

[0240] The UE may send a network function distribution trigger request to the network function distribution manager;

[0241] The UE may receive a network function distribution trigger response from the network function distribution manager;

[0242] The UE may receive a network function distribution notification from the network function distribution manager, the network function distribution notification indicating an address of a second network function that is a peer network function of the first network function and is successfully deployed at the first edge node;

[0243] The UE may send a network function access request to the second network function to access the second network function;

[0244] The UE may receive a network function access response from the second network function;

[0245] The UE may receive a network function adjustment notification request from the network function distribution manager to switch from using the second network function at the first edge node to the first network function at the core network or another network function at another edge node; and

[0246] The UE may send a network function adjustment notification response to the network function distribution manager.

[0247] In another example, an edge server can do the following:

[0248] The edge server may receive, from the first network entity, a network function distribution policy configuration request that may include one or more network function distribution policies;

[0249] Edge servers can verify network function distribution policies;

[0250] Edge servers can store network function distribution policies;

[0251] The edge server may generate a network function distribution policy configuration response;

[0252] The edge server may send a network function distribution policy configuration response to the first network entity;

[0253] The edge server may send a network function distribution policy discovery request to the first network entity for discovering and retrieving one or more network function distribution policies;

[0254] The edge server may receive a network function distribution policy discovery response including one or more network function distribution policies from the first network entity;

[0255] Edge servers can store network function distribution policies;

[0256] The edge server may send a network function distribution trigger request to the third network entity, the network function distribution trigger request including a first trigger for distributing the first network function to the first edge node;

[0257] The edge server may receive a network function distribution trigger response from the third network entity;

[0258] The edge server may receive a network function distribution request from the fourth network entity for distributing the first network function to the edge server, i.e., creating and activating a second network function at the edge server, the second network function being referred to as a peer network function of the first network function;

[0259] The edge server can generate and activate the second network function;

[0260] The edge server may send a network function distribution response to the fourth network entity;

[0261] The edge server may send a network function distribution notification to the fifth network entity;

[0262] The edge server may receive a network function access request for accessing the second network function from the sixth network entity;

[0263] The edge server may execute the network function access request and generate a network function access response;

[0264] The edge server may send a network function access response to the sixth network entity;

[0265] The edge server may send a network function status report request to the seventh network entity to report the current status of the second network function;

[0266] The edge server may receive a network function status response from the seventh network entity;

[0267] The edge server may receive a network function adjustment request to adjust a second network function;

[0268] The edge server may send a network function adjustment response to the eighth network entity; and

[0269] The edge server may send a network function adjustment notification to a ninth network entity. The first network entity may be a policy control function, a network function distribution manager, an unstructured data storage function, a unified data repository function, a unified data management function, etc. The network function distribution policy may specify conditions for triggering the distribution of one or more network functions from the core network to one or more edge servers in one or more edge data networks. The network function distribution policy configuration response may include an identifier of the edge server, the location of the edge server, the traffic load at the edge server, capabilities of the edge server such as storage and computing, a list of current network functions at the edge server, a list of current edge applications served by the edge server, a list of network functions that the edge server can host, a list of network functions that the edge server cannot host, a time window during which the edge server is willing and / or unwilling to host the network function, etc.

[0270] The first trigger may be received from the first edge application or generated by the edge server. The first trigger may indicate an identifier of the first network function, a location of a first edge node to which the first network function is to be distributed, context information about the first edge node (such as an identifier of the edge server and / or an identifier of the edge data network), a trigger reason, a time to distribute the first network function to the first edge node, a priority for distributing the first network function to the first edge node, a mode of coordination between the first network function of the core network and its peer network function to be created at the first edge node, etc.

[0271] The third network entity may be a network function distribution manager or a first network function. The network function distribution trigger response may include an identifier of a first edge server at the first edge node, an identifier of a first edge data network at the first edge node, etc. The network function distribution request may include an identifier of the first network function in the core network, a software image of the first network function, an identifier of a user plane path, an identifier of an edge enabling server, a set of network function distribution requirements, a set of network function access rules, etc. The set of network function distribution requirements may include a coordination mode between the first network function in the core network and a second network function to be created at the first edge node, a lifespan of the second network function, etc.

[0272] The set of network function access rules may include a list of edge applications that can access the second network function to be created at the edge server, a list of edge applications that cannot access the second network function, a list of user equipment that can access the second network function, and a list of user equipment that cannot access the second network function. The network function distribution response may include an identifier of the second peer network function, an identifier of the edge server, an identifier of a user plane function for accessing the edge server, the capabilities of the edge server, context information of the edge data network where the edge server resides, etc. The fourth network entity may be a network function distribution manager, a first network function in a core network, etc. The network function distribution notification may include an identifier of the second network function created and hosted by the edge server, and an identifier of a user plane function for accessing the second network function.

[0273] The fifth network entity may be an edge application, user equipment, a user plane function, a control plane function, or the like. The network function access request may include an identifier of the second network function, a need to switch back to the first network function after a duration, or the like. The network function access response may indicate a trigger for switching back to the first network function after a duration, or the like. The sixth network entity may be an edge application, user equipment, another edge server, or the like. The network function status report request may include a list of network functions hosted by the edge server, the current status of each listed network function, and a need to switch the listed network functions to their peer network functions in the core network after a duration. The network function status response may indicate a trigger for switching the network functions from the edge server to the core network. The seventh network entity may be a network function distribution manager, a first network function in the core network, or the like. The network function adjustment request may be generated by the edge server itself, issued by a network function manager, or issued by another network function in the core network.

[0274] The network function adjustment request may include an identifier of a network function that is currently hosted by an edge server but is to be adjusted, an adjustment action, an adjustment condition, an identifier of a network function that is hosted in a core network but is associated with the network function to be adjusted, etc. The adjustment action may be deactivation, removal, relocation, etc. The adjustment condition may include the time to start the adjustment, the number of edge applications and / or user equipment using these network functions to be adjusted being less than a threshold, a new location (if the adjustment action is "relocation"), etc. The eighth network entity may be a network function distribution manager. The network function adjustment notification request may include an identifier of an edge server, an identifier of the network function being adjusted, an identifier of a peer network function of the network function being adjusted, etc. The ninth network entity may be an edge application, a user equipment, and / or an edge data network controller.

[0275] In another example, the network function distribution manager may perform the following operations:

[0276] The network function distribution manager may send a network function distribution policy configuration request, which may include one or more network function distribution policies, to the first network entity;

[0277] The network function distribution manager may receive a network function distribution policy configuration response from the first network entity;

[0278] The network function distribution manager may receive a network function distribution policy discovery request for discovering and retrieving one or more network function distribution policies from the first network entity;

[0279] The network function distribution manager may send a network function distribution policy discovery response including one or more network function distribution policies to the first network entity;

[0280] The network function distribution manager may receive, from the third network entity, a network function distribution trigger request for distributing the network function of the core network to the first edge node;

[0281] The network function distribution manager may send a network function distribution trigger response to the third network entity;

[0282] The network function distribution manager may select an appropriate first network function to be distributed to the first edge node based on context information from other network entities;

[0283] The network function distribution manager may select an appropriate first edge server to which the selected first network function may be distributed;

[0284] The network function distribution manager may select an appropriate first user location function to access the first edge server;

[0285] The network function distribution manager may send a network function distribution request to the selected first edge server;

[0286] The network function distribution manager may receive a network function distribution response from the first edge server;

[0287] The network function distribution manager may send a network function distribution notification to the fourth network entity;

[0288] The network function distribution manager may receive a network function status report request from the fifth network entity;

[0289] The network function distribution manager may send a network function adjustment request to the first edge server;

[0290] The network function distribution manager may receive a network function adjustment response from the first edge server; and

[0291] The network function distribution manager may send a network function adjustment notification to the sixth network entity.

[0292] The network function distribution manager may reside in an edge data network and / or a core network. A network function distribution policy may specify conditions for triggering the distribution of one or more network functions from the core network to one or more edge-enabling servers in one or more edge data networks. The first network entity may be a user equipment, an edge-enabling server, a policy control function, a network repository function, another network function, or the like. The network function distribution trigger request may indicate an identifier of the network function to be distributed, a location of a first edge node to which the network function is to be distributed, context information about the first edge node (such as an identifier of an edge server and / or an identifier of an edge data network), a triggering reason, a time to distribute the network function to the first edge node, a priority for distributing the network function to the first edge node, a mode of coordination between the network function of the core network and its peer network function to be created at the first edge node, and the like. The network function distribution trigger request may be generated locally by the network function distribution manager, and therefore a network function distribution trigger response may not be sent to a third network entity.

[0293] The third network entity may be an edge server, user equipment, a policy control function, an edge application, other network functions, etc. The first network function may be an AMF, an SMF, an UPF, an NWDAF, an MSGin5G service, etc. Other network entities may be user equipment, an edge application, a core application, a network function and / or an edge server. The selected first user plane function allows the user equipment, the edge application and / or other edge servers to directly and more efficiently access the first edge server, thereby accessing any network function distributed to the first edge server. The network function distribution request may include an identifier of the selected first network function in the core network, a software image of the first network function, an identifier of the selected first user plane path, an identifier of the selected first edge server, a set of network function distribution requirements, a set of network function access rules, etc. The set of network function distribution requirements includes a mode of coordination between the first network function of the core network and a peer network function (referred to as a second network function) to be created at the first edge node, the lifespan of the second network function, etc. The set of network function access rules includes a list of edge applications that can access the second network function to be created on the first edge server, a list of edge applications that cannot access the second network function, a list of user equipment that can access the second network function, a list of user equipment that cannot access the second network function, etc.

[0294] The network function distribution response may include an identifier of the second network function created at the first edge server, an identifier of the first edge server, an identifier of a first user plane function for accessing the first edge server, edge capabilities of the first edge server, context information of an edge data network where the first edge server resides, etc. The network function distribution notification may include an identifier of the second network function created and hosted by the first edge server, and an identifier of the first user plane function for accessing the second network function.

[0295] The fourth network entity may be a user equipment, an edge application, a selected second network function, a policy control function, a network repository function, etc. The network function status report request may include identifiers of the network functions hosted by the edge server, current status of these network functions, current edge capabilities of the edge server, etc. The network function status report request may be a one-time request triggered by a previous network function status solicitation request sent from the network function distribution manager to the fifth network entity, or a recurring and periodic request as a result of a previous subscription made by the network function distribution manager to the fifth network entity.

[0296] The fifth network entity may be an edge server, a network repository function, another network function, or the like. The network function adjustment request may include an identifier of a network function currently hosted by the first edge server but to be adjusted, an adjustment action, an adjustment condition, an identifier of a network function hosted in the core network but associated with the network function to be adjusted, or the like. The adjustment action may be deactivation, removal, relocation, or the like. The adjustment condition may include the time to start the adjustment, the number of edge applications and / or user equipment using the network functions to be adjusted being less than a threshold, a new location (if the adjustment action is "relocation"), or the like. The network function adjustment response may be followed by a network function adjustment confirmation, which may be sent from the first edge server to the network function distribution manager only after the specified adjustment action has been performed. The sixth network entity may be a user equipment device, an edge application, a network repository function, a network function in the core network associated with the network function to be adjusted, or the like.

[0297] The Network Function Distribution Manager can perform the following operations:

[0298] The network function can receive the network function distribution policy from the PCF;

[0299] The network function may generate a network function distribution trigger for distributing the first network function to the edge data network based on the policy received from the PCF;

[0300] The network function may select an appropriate first edge data network and first edge server based on context information received from the edge network repository function;

[0301] The network function may send a network function distribution request to the selected first edge server;

[0302] The network function may receive a network function distribution response from the first edge server, the network function distribution response indicating that the second network function is deployed at the first edge server;

[0303] The network function may send configuration information to the second network function;

[0304] The network function may send a network function distribution notification to the NRF, thereby registering the second network function with the NRF;

[0305] The network function may receive a periodic report from the second network function indicating an updated status of the second network function;

[0306] The network function may decide to adjust the second network function based on the policy received from the PCF and the latest status of the second network function;

[0307] The network function may send a network function adjustment request to the second network function;

[0308] The network function may receive a network function adaptation response from the second network function; and

[0309] The network function may send a network function adjustment notification to the NRF. The configuration information may include the address of the NRF, the address of the network function distribution manager, the address of the first network function, the frequency of sending periodic reports to the network function distribution manager, etc. The network function distribution manager may reside in the core network and / or the edge data network.

[0310] With respect to the embodiments described herein, the following concepts are explained herein.

[0311] Edge Network and Server Context (ENSC): context and characteristic information about the edge data network and edge servers deployed in the edge data network (e.g., location, capabilities, constraints, etc.).

[0312] ENRF: A network function or logical entity that maintains records of edge network and server contexts. For example, ENRF can receive edge data network / server registrations from other logical entities, create edge data network / server context records, receive queries for edge data networks / servers from NF consumers, and return matching edge data networks / servers to NF consumers.

[0313] Edge Network Controller (ENC): A logical entity that knows about one or more edge data networks / servers and registers their context with the ENRF. The ENC can also discover other edge data networks / servers from the ENRF. The ENC can be deployed within the edge data network, or it can be a third-party entity (e.g., another ENRF owned by a different operator, an MEC coordinator, a 5G OAM system, etc.). The ENC can be an edge data network configuration server as defined in 3GPP TR 23.758.

[0314] Distributed NF (DNF): NF distributed to and deployed in the edge data network.

[0315] Centralized NF (CNF): A NF deployed in a mobile core network such as 5GC. A CNF can have multiple DNF instances. For example, a centralized NWDAF in a 5GC can have multiple distributed NWDAF instances deployed in edge data networks.

[0316] NF Distribution (NFD): The process of distributing one or more NFs to one or more edge data networks. In other words, when NFD is completed, one or more DNFs can be created and deployed in one or more edge data networks.

[0317] NFD policy: A policy that describes the conditions and rules regarding whether, when, and how to conduct NFD.

[0318] NF Distribution Manager (NFDM): A network function or logical entity that initiates, monitors, manages, and controls NFD processes. For example, NFDM can select the appropriate NF and the appropriate edge data network; it then triggers the creation and deployment of the selected NF to the selected edge data network. NFDM can be implemented as part of an existing NF (e.g., NRF) or as a standalone NF. NFDM can be in client mode (i.e., deployed in the edge data network) or in server mode (i.e., deployed in the 5GC).

[0319] Figure 7 A framework of an edge application enabling architecture 700 is shown. Figure 7The example shows that EDN 701 includes EES 711. EES 711 can provide support functions required for edge application server 712 to operate in EDN 701. For example, EES 711 can provide information related to edge application server 712, such as availability, to EEC 720. EEC 720 can provide support functions required by application client 721. For example, it can discover available edge application servers 712 in EDN 701. EEC 720 can also retrieve and provide configuration information to enable application data traffic 704 to be exchanged with edge application server 712 (e.g., via 3GPP network 705). Edge data network configuration server 703 can provide support functions required for UE 702 to connect with EES 711.

[0320] Edge-assisted network function distribution can be achieved within the framework of the edge application enabling architecture 700 through the following extensions:

[0321] ENRF 750 may include logical functions and may be part of 3GPP network 705 or application server functions. ENC 715 may include logical functions and may be part of edge data network 701. EDGE-X1 751 is an interface between ENRF 750 and ENC 715 to support functions such as for ENC 715 to register edge data network context information with ENRF 750 or for ENC 715 to discover edge data network context information from ENRF.

[0322] EDGE-X2 752 is an interface between ENC 715 and edge application servers 712 to support functions such as for edge application servers 712 to register their context information with ENC 715 or for ENC 715 to retrieve their context information from edge application servers 712 .

[0323] Edge-X3 753 is an interface between ENC 715 and EES 711 to support functions such as for EES 711 to register its context information with ENC 715 or for ENC 715 to directly retrieve EES 711 context information.

[0324] EDGE-X4 754 is an interface between ENC 715 and edge data network configuration server 703 to support functions such as configuring ENC 715 using access information (e.g., address, name and / or identifier, etc.) of ENRF 750 for edge data network configuration server 703.

[0325] Figure 8An example process 800 for edge-assisted UE context and trigger collection is shown. In step 0(c), the 5GC (e.g., UDM, AF, UDR, or new NF) subscribes to an edge enabling server (EES) to receive automatic notifications about UE context and triggers (e.g., via step 8 below). In steps 0(b) and 0(a), the EES can subscribe to an edge enabling client (EEC) (e.g., the EEC in UE1 and / or the EEC in UE2) and a context service (e.g., in UE1 and / or UE2) for UE context and triggers. In step 1, the context service in a UE (e.g., UE1 or UE2) can detect that there is a new context or one or more triggers to be sent to the EES. The new context or trigger can come from one or more applications on the UE. In step 2, the context service in the UE can send the new context and trigger to the EEC in the same UE. In step 3, the new context and trigger can come from different applications and may have some duplication. Therefore, the EEC can merge the received context and trigger by eliminating duplication. In step 4, the EEC can send the merged context and trigger to the EES. In step 5, the EES may receive merged contexts and triggers from multiple EECs. The EES may aggregate these contexts and triggers to generate an aggregated context and trigger. The EES may store the received contexts and triggers. In step 6, the EES may send a response to the EEC. The EEC may send a response to the context service in the UE. In step 8, the EES may send the aggregated context and trigger, along with its edge context information, to the 5GC (existing 5GC network functions such as UDM, AF, and UDR, or a new context service network function in the 5GC). The edge context information may indicate only the EES itself or also indicate the edge applications and edge-enabled clients it supports. In step 9, the 5GC may send a response to the EES. In step 10, the EES may request certain new capabilities from the 5GC. For example, multiple UEs may send triggers for a local AMF; therefore, the EES may request the 5GC to locally instantiate the AMF in the edge data network where the EES resides. To this end, the EES may provide the 5GC with the following information: Network Slice Selection Assistance Information (N-SSAI), UE ID (5G-GUTI, SUPI), and Application ID. If the EES requests the 5GC to instantiate a new SMF or UPF in the edge data network, the 5GC may be provided with context information related to the session. In step 11, the 5GC may send a response to the EES. The response may include one or more network parameters. For example, if step 10 includes a request to instantiate an AMF or AMF instance, the response may include the AMF name, AMF ID (GUAMI), S-NSSAI supported by the AMF, AMF instance ID, AMF service area, etc.

[0326] Figure 9 An example edge-aware MSGin5G service 900 is shown. The edge-aware MSGin5G service 900 may support the following functionality.

[0327] Each edge data network can have one or more MSGin5G servers, such as MSGin5G edge server 1 911 in edge data network 1 901 and MSGin5G edge server 2 912 in edge data network 2 902 .

[0328] The MSGin5G server 903 in the 5GC 904 can coordinate, manage, and control the MSGin5G edge servers in the edge data network. For example, the MSGin5G server 903 can request the NFDM to create the MSGin5G edge server 1 911 and the MSGin5G edge server 2 912. The MSGin5G server 903 can configure the MSGin5G edge server 1 911 to periodically report its status to the MSGin5G server 903. The MSGin5G server 903 can configure the MSGin5G edge server 1 911 to only serve a list of allowed UEs and applications.

[0329] The MSGin5G edge server can be fully utilized to reduce message delivery latency and overhead, especially for point-to-point messages between two or more UEs in the same location (e.g., a future connected factory). Figure 9 In the example, when UE A needs to send a message to UE B for App1, UE A may first send the message to MSGin5G Edge Server 1 911, which may then forward the message to UE B. In another example, when UE A needs to send a message to UE D, the message may pass through the following entities in sequence: UE A, MSGin5G Edge Server 1 911, MSGin5G Edge Server 2 912, and UE D. Note that in order to route messages between MSGin5G Edge Server 1 911 and MSGin5G Edge Server 2 912, one or both of them may contact the core network to determine a serving edge server based on location. For example, MSGin5G Edge Server 1 911 may learn the address and other access information about MSGin5G Edge Server 2 912 from the core network by providing the location where MSGin5G Edge Server 2 912 resides.

[0330] Each MSGin5G edge server can register itself with the MSGin5G server 903 or NRF. In the latter case, the MSGin5G server 903 can find the MSGin5G edge server in the edge data network from the NRF. Any NF consumer and application can also find the MSGin5G edge server in a specific location from the NRF or MSGin5G server 903. When the UE attaches to the 5G network (or when the UE establishes a PDU session), the UE can request and / or be assigned to the MSGin5G edge server 903.

[0331] If App1 needs to send a multicast / broadcast message to all four UEs, App1 can first send the message to MSGin5G Server 903. MSGin5G Server 903 can forward the message to MSGin5G Edge Server 1 901 and MSGin5G Edge Server 2 902, respectively. MSGin5G Edge Server 1 901 can then multicast / broadcast the message to UE A and UE B using any available local multicast / broadcast mechanism.

[0332] If the UE needs to send a message to both UE B and UE C, UE A first unicasts the message to MSGin5G edge server 1 911, and MSGin5G edge server 1 911 then multicasts the message to both UE B and UE C.

[0333] When the MSGin5G edge server 903 needs to establish a group, it may first contact the MSGin5G edge servers (e.g., MSGin5G edge server 1 911 and MSGin5G edge server 2 912) to establish some subgroups. The subgroups established by the MSGin5G edge servers may be reported to the MSGin5G server and merged by the MSGin5G server to create various groups.

[0334] If App1 is deployed in edge data network 1 and it needs to send a message to UE A (or UE B, or UE C), App1 can first send the message to MSGin5G edge server 1 911, and MSGin5G edge server 1 911 can forward the message to UE A (or UE B, or UE C).

[0335] Figure 10 An example process 1000 of MSGin5G Edge Server (MES) activation is shown, where a new MES is instantiated and registered with the EES. In step 1, the MSGin5G Cloud Server (MCS) and 5GC (e.g., Figure 15-17A new distributed network function manager (in the ) can facilitate the deployment of a new MES in the edge data network. During this process, the MES can register itself as a network function with the Network Repository Function (NRF), and the MES can be provided with the address of the edge data network configuration server. In step 2, the MES can discover the EES from the edge data network configuration server. In step 3, the MES can register with the EES by indicating its capabilities (e.g., maximum number of messages processed per second, maximum number of UEs or applications supported, etc.). The MES can also indicate the address of the MCS to the EES. Alternatively, the MCS can register the MES with the EES. As a result, the EES can proactively contact the MES for confirmation and notification after receiving the MCS's request in step 3(b). In step 4: the EES can send a response to the MES (or MCS). In step 5, the EES can generate a list of registered MESs, including their addresses, their capabilities, and the addresses of the corresponding MCSs. In step 6, the MES registration comes from the MES itself, and the EES can send a notification to the MCS to indicate the successful registration of the MES. Note that the EES may also send the same notification to the 5GC so that the 5GC can maintain a list of successfully registered MESs. In step 7, the MCS may send a response to the EES. In step 8, the MCS may generate a list of MESs that have successfully registered with the EES and are ready to be fully utilized as edge services. In step 9, whenever a UE registers and / or attaches to the 5GC, it may indicate its willingness and preference to be aware of any MES close to its location. Alternatively, the 5GC may proactively send a configuration update message indicating the same information as included in step 11. In step 10, the 5GC may select an MES / MCS based on the UE's willingness and preference as indicated in step 9 and may assign it to the UE. In step 11: the 5GC may send the address of the assigned MES / MCS to the UE.

[0336] Figure 11 An example of edge-assisted messaging 1100 is shown. Figure 11 In the example, EES facilitates UE to discover MES, and MES can help the source UE send messages to the destination UE without the need for MCS in the cloud to relay. Figure 11 It is also shown that two UEs are served by the same MES. Figure 11the MSGin5G service in UE1 can send a discovery request to the EEC in UE1, which in turn forwards the request to the EES for discovery of MESs. The UE1 as the source UE can include its identifier and the target / destination UE identifier (e.g. UE2) in the discovery request. The EES can look up its local MES list, find one or more appropriate MESs for the source UE (i.e. UE1), and can send a response to the EEC in UE1, which forwards the response to the MSGin5G service in UE1; the response includes the identifiers of the discovered MESs. In step 2, the EES can send an indication to the MESs that it has been discovered by UE1 for sending messages to UE2. In step 3, the MSGin5G service in UE1 can send a message service request to the MESs indicating the source UE identifier and the target UE identifier. Multiple target UE identifiers can be included in the request. In step 4, the MESs can approve (or reject) the message service request. The MESs can approve the request for some target UE identifiers while rejecting others. The MESs can send a message service confirmation to the MSGin5G service in UE1 indicating the approval or rejection results. If the MESs reject all target UE identifiers, steps 5-9 can be skipped. In step 5, the MSGin5G service in UE1 starts sending a message to the MESs. The message is targeted to one or more target UEs and their identifiers can be included in the message. If the message is for multiple target UEs, UE1 can indicate different message delivery priorities for each target UE, based on which the MESs can first forward the message to the target UE(s) with higher priority. The message can include multiple segments and each segment is for a different target UE. In step 6, the MESs can forward the message to all target UEs as included in step 5. The MESs can forward the same message to each UE one by one. If the message in step 5 includes multiple segments, the MESs can forward each segment to the corresponding target UE one by one and / or based on any message delivery priority as included in step 5. The MESs can also take advantage of the underlying network’s multicast capability to send the message to all target UEs in the MESs’ coverage range at once.In step 7, each target UE may receive the forwarded message from the MES and may send a response to the MES. Each target UE may indicate to the MES whether the message arrival rate to the target UE should be increased, decreased, or indifferent. In step 8, the MES may send a response to the source UE (i.e., UE1). The MES may instruct UE1 to increase or decrease the message generation rate via the response message. The MES may also instruct UE1 to start using a different MES / MCS via the response message. In step 9, in order for the MCS to have a global view of all locally transferred messages between the source UE and the target UE, the MES may send a notification to the MCS. The MES may send a separate notification to the MCS for each transferred message, or one notification may cover multiple transferred messages.

[0337] Figure 12 Another example 1200 of edge-assisted messaging is shown, in which the MCS may first receive a message from a source UE and then decide to use an MES. In step 1, UE1, the source UE, may send a message to the MCS. The message may include information indicating one or more target UE identifiers and information indicating the locations of the one or more target UE identifiers. In step 2, the MCS may obtain location information about the source UE and target UEs from the 5GC, or alternatively from the message in step 1. In step 3, the MCS may identify a suitable EES from the 5GC based on the location information of the source UE and target UEs. In step 4, the MCS may discover a suitable MES from the EES given the source UE identifier and target UE identifier. In step 5, the EES may send the discovered MES address or identifier to the MCS. In step 6, the MCS may forward the message received in step 1 to the MES. The MCS may instruct the MES on how to forward the message to each target UE (e.g., priority, number of retransmissions per target UE, whether to store the message locally, and under what conditions). In step 7, the MES may forward the message to the target UE according to the instructions received from the MCS in step 6. In step 8, the target UE may send a response to the MES. In step 9, the MES may send a response to the MCS. The MES may indicate: 1) the identifier of the target UE that has (and / or has not) received the message; 2) whether the MES can assist in forwarding messages for the source UE in the future; and / or 3) whether the MES is willing to receive future messages directly from the source UE. In step 10, the MCS may send a response to the source UE (i.e., UE1). In this response message, the MCS may include the identifier or address of the MES, indicating that the source UE may send future messages directly to the MES.

[0338] ENRF can receive edge network / server registration requests from ENCs and can generate ENSC records. ENRF can then send automatic notifications about new ENSC records to any NF consumers that have subscribed to ENRF. When ENRF can receive a request to discover ENSC records from an NF consumer (e.g., ENC, NFDM, other NFs, SCS, AF, etc.), it first searches its local ENSC records to answer the request; if necessary, ENRF can contact the ENC to check for any missing and / or up-to-date ENSCs that do not exist locally at ENRF, attempting to answer the request with a more complete and accurate answer.

[0339] Figure 13 An example process 1300 for edge network / server registration using NFD indications is shown. In this process, the ENC registers one or more edge networks (ENs) and their edge servers (ESs) with the ENRF. The ENC may also indicate whether and how each edge network / server supports NFD. In step 1, the ENC may register the EN / ES with the ENRF using the NFD indication. The ENC may send an EN / ES registration request to the ENRF. If the ENRF resides within the core network as part of an NF or NRF, the ENC may first send the EN / ES registration request to the NEF, which then forwards the request to the ENRF. The EN / ES registration request may include EN / ES information and an NFD indication. The ENRF may receive the EN / ES registration request and process it by decoding the EN / ES information and the NFD indication.

[0340] The EN / ES information may include a list of edge networks (e.g., their names and / or identifiers), the capabilities of each edge network, a list of edge servers deployed in each edge network (e.g., their names, identifiers, and / or addresses), the capabilities of each edge server (e.g., a list of supported edge applications, a list of supported UEs), the service area of ​​each edge network, the applications available in each edge network, the service scheduling of each edge network, etc.

[0341] The NFD indication may indicate whether the edge network supports NFD, whether the edge server supports NFD, what types of NFs the edge network can host, what types of NFs the edge server can host, when the edge network can host NFD and for how long, when the edge server can host NFD and for how long, whether the edge network can store NFD policies and generate NFD triggers based on the NFD policies, whether the edge server can store NFD policies and generate NFD triggers based on the NFD policies, etc.

[0342] In step 2, the ENRF may send a request to the PCF to verify the existence of any EN / ES-related policies (e.g., via interfaces Npcf or Rx, or via NEF). For example, some edge networks or edge servers may not be allowed to register with the ENRF and / or may only be allowed to register for a limited time. This request may include all or part of the EN / ES information and NFD indication received in step 1. The PCF may need to check with the UDM / UDR for authentication and authorization. In step 3, the PCF may receive the request from the ENRF. The PCF may process the request, compare the EN / ES information with any configured EN / ES-related policies, and generate a list of allowed EN / ES according to the policies. In step 4, the PCF may generate a new NFD policy based on the NFD indication received in step 2. In step 5, the PCF may send a response to the ENRF. This response may include the list of allowed EN / ES and the created NFD policy. In step 6, the ENRF may receive the response from the PCF and, in particular, decode the list of allowed EN / ES. Based on the list of allowed EN / ES, the ENRF may determine which EN / ES may be registered. The ENRF may generate an EN / ES record for each allowed and registered edge network and / or edge server. In step 7, the ENRF may send a response to the ENC, which includes the registration results, such as a list of EN / ES allowed for registration, a list of EN / ES denied for registration, etc. In step 8, if any NF consumer (e.g., NWDAF) has subscribed to the ENRF to receive notifications about any newly registered EN / ES, the ENRF may send a notification to the NF consumer. The notification may include the list of registered EN / ES to which the NF consumer has subscribed.

[0343] Figure 14An example process 1400 for discovering edge networks and / or edge servers is shown. In step 1, the NF consumer may send an EN / ES discovery request to the ENRF to discover one or more edge networks and / or edge servers. The discovery request may include a discovery filter, which may indicate some conditions, such as the location of the edge network and / or edge server, the type of edge application hosted by the edge network and / or edge server, and the services provided by the edge network and / or edge server. In step 2, the ENRF may search its EN / ES records against the discovery filter received in step 1. In step 3, the ENRF may select and contact the ENC to discover more EN / ENs, assuming that the ENC has information about some of the EN / ESs it manages. In step 4, the ENRF may send an EN / ES discovery request to the ENC. The request may contain the same discovery filter as received in step 1. The ENC may search its local EN / ES database to find any suitable EN / ES that match the discovery filter. In step 5, the ENC may send a response to the ENRF indicating any edge networks and / or edge servers newly discovered in step 4 and their capabilities. Similar to Figure 13 In step 1 of the NF Consumer, this step may also register these new edge networks and / or edge servers. In step 6, if the ENRF receives new edge networks and / or edge servers, the ENRF may generate new EN / ES records for them. In step 7, the ENRF may send a response to the NF Consumer, which may include the list of discovered edge networks and / or edge servers found in step 2 and received from step 5.

[0344] The proposed edge-aware network function distribution is policy-based and NFDM-coordinated, which includes several techniques described here:

[0345] Configuration of NFD policy ( Figure 16 (as shown in ): The Application Function (AF) (or 3GPP OAM system) can generate / configure some NFD policies to the PCF. The PCF can pass the NFD policies to the NFDM. The PCF or NFDM can then store the new NFD policies to the UDR, notify the NRF of the new NFD policies, notify the NFx of the NFx-specific NFD policies, configure the new NFD policies to the ENC and / or related edge servers, and push the NFD policies to the UE. Logical entities that act as NF consumers (e.g., UE, ENC, NFx, NRF, etc.) can also discover NFD policies from the PCF or NFDM.

[0346] NFD triggers the generation of Figure 17(as shown in the figure): The UE, a specific NFx, ENC, and / or NFDM can generate NFD triggers based on their locally maintained NFD policies. Additionally, the NFDM can receive automatic notifications from the NWDAF or ENRF regarding context changes to the edge data network / server; as a result, the NFDM can generate NFD triggers. If NFD triggers are generated by entities other than the NFDM, they may first be sent to the NFDM; the NFDM can then verify these NFD triggers with the PCF. Only after verifying the new NFD triggers can the NFDM begin the NFD process.

[0347] Distribute the selected NFs to the selected edge networks ( Figure 18 ): After verifying the locally generated or received NFD trigger, NFDM can start the NFD process to create the requested NF in the appropriate edge data network. NFDM can first check with NRF to select the appropriate NF to be distributed to the edge network / server; it can contact ENRF to discover and select the appropriate edge network / server. NFDM can then install the selected NFx to the selected edge network / server directly or through other entities such as NFVO. After successfully creating the requested DNFx, NFDM can send a notification to NRF to register DNFx and / or can send another notification to the corresponding centralized NFx. NFDM can also provide additional configuration information to DNFx (e.g., the address of NRF, the address of the corresponding centralized NFx, the address of NFDM, etc.).

[0348] Leverage DNF in edge networks ( Figure 19 (as shown in ): After successfully creating DNFx at the edge data network, the UE can discover the DNFx from the notification from the NFDM or from the ENC that the DNFx can be periodically announced. For example, the UE can start using DNFx directly or via the local NEF to enable direct communication with edge applications in the same edge network to improve performance. At the same time, DNFx can send periodic reports to the NFDM (or NWDAF) to indicate the communication records and statistics between DNFx and the UE and / or between DNFx and other entities. The NFDM can forward these reports to the NWDAF for data analysis, to the NRF for updating the context information of the DNFx, and / or to the corresponding centralized NFx. Alternatively, the DNFx can send periodic reports directly to the corresponding centralized NFx.

[0349] Deactivation of distributed network functions ( Figure 20(as shown in ): NFDM can decide to remove or deactivate an existing DNFx based on NFD policy. It can then contact DNFx directly or via other entities such as NFVO to deactivate DNFx. DNFx (or NFDM) can send a deactivation notification to the UE corresponding to CNFx and / or NRF. Alternatively, CNFx can initiate the removal or deactivation of its DNFx. After receiving the deactivation notification from DNFx (NFDM or ENC), the UE can resume using centralized NFx, or alternatively use another new DNFx if the UE is notified of another new DNFx by the ENC, NFDM and / or the current DNFx.

[0350] The interaction between DNF and the corresponding CNF ( Figure 21 ): A CNF may have multiple corresponding DNFs (e.g., DNF1 and DNF2) created in the edge data network. The CNF may subscribe to each DNF in order to receive automatic notifications of selected information about each DNF; such selected subscriptions and notifications may be triggered by the CNF itself or another NF consumer (e.g., NWDAF). When a CNF receives a service request from an NF consumer, the CNF may first attempt to answer the service request using its local information. If the CNF needs to collect additional information in order to service the original service request from the NF consumer, the CNF may first adapt the service request and may select one or more DNFs from its set of DNFs. The CNF may then send the adapted service request to each selected DNF. The CNF may combine the responses received from the DNFs with its local responses to generate a final response to the NF consumer.

[0351] Figure 15 An example process 1500 for configuring an NFD policy is shown. In step 1, the AF (or 3GPP OAM system) may send a request to the PCF to create / configure a new NFD policy. The PCF may receive the request and may generate a number of new NFD policies as requested; the PCF may generate a policy identifier for each created NFD policy. The PCF may then send a response to the AF indicating whether the new NFD policy has been successfully created at the PCF. Each NFD policy may contain four elements as described in Table 3 below: NFD policy ID, target NF, NFD condition, and NFD action. For each NFD policy, the PCF may include one or more NFDM addresses in the NFD action. Note that the PCF may discover the NFDM from the NRF.

[0352] Examples of NFD strategies could be:

[0353] NFD Policy #1: NFD Policy ID = "NFDPolicy01", Target NF = "AMF", NFD Condition = "The frequency of concurrent messages (e.g., Registration Requests and Service Requests) that the AMF may receive from UEs within the location exceeds a threshold", and NFD Action = "Generate NFD trigger for distributing the AMF to the selected edge network within the location, and send the NFD trigger to NFDM".

[0354] NFD Policy #2: NFD Policy ID = "NFDPolicy02", Target NF = "AMF", NFD Condition = "Number of UEs registered with RM within the location exceeds the threshold", and NFD Action = "Generate NFD trigger for distributing AMF to selected edge networks within the location and send NFD trigger to NFDM".

[0355] NFD Policy #3: NFD Policy ID = "NFDPolicy03", Target NF = "NWDAF", NFD Condition = "UE requests a local area data network and as part of session management, a local UPF has been assigned to the UE", and NFD Action = "Generate an NFD trigger for distributing the NWDAF to the local area data network to collect data from the local UPF and provide UPF data analysis, and send the NFD trigger to the NFDM."

[0356] NFD Policy #4: NFD Policy ID = "NFDPolicy04", Target NF = "AMF, SMF, UPF", NFD Condition = "CIoT devices communicate with edge applications using the control plane", and NFD Action = "Generate an NFD trigger for distributing all NFs on the control plane to the edge network where the edge applications reside, and send the NFD trigger to NFDM".

[0357] In step 2, the PCF may send the newly created NFD policies (including their identifiers) to the NFDM. The NFDM may send a response to the PCF as confirmation of receipt of these NFD policies. In step 3, the PCF (or NFDM) may store the newly created NFD policies in the UDR, from which any NF consumer can search and retrieve the NFD policies. In step 4, the PCF (or NFDM) may notify the NRF of the new NFD policies, but may only send the NFD policy ID and target NF to the NRF. As a result, the NRF can proactively generate NFD triggers after receiving data analysis results for a specific NF from the NWDAF by comparing the received data analysis results with NFD conditions. In step 5, if the target NFD of the newly created NFD policy is "NFx," the PCF (or NFDM) may send the NFD policy to the NFx. The NFx can then evaluate the NFD conditions based on its local information and generate NFD triggers on its own. Alternatively, the NFx can subscribe to the NWDAF to receive notifications about data analysis results that can be used to compare with the NFD conditions. In step 6, the PCF (or NFDM) can configure certain NFD policies with the ENC, which can be an edge network controller, software-defined network controller, edge enabler server, base station, access network gateway / router, etc. In step 7, similar to step 6, the PCF (or NFDM) can configure certain NFD policies for the UE, so that the UE can automatically trigger the creation of distributed network functions in the edge data network based on the configured policies. The policies can be sent from the PCF to the UE via the AMF using a NAS connection. Alternatively, this step can occur when the UE registers with the AMF (initial registration, periodic registration, and / or registration update), when the UE establishes an N1 connection with the AMF (i.e., service request), when the AMF performs a UE configuration update procedure, when the UE establishes a PDU session with the SMF, and so on. As a result, the UE can proactively generate NFD triggers and send them to the NFDM.

[0358] The following table shows the key elements of the NFD strategy.

[0359]

[0360] Table 3. Key information elements of NFD policy

[0361] Figure 16This diagram illustrates a process 1600 for generating an NFD trigger. Generally, logical entities such as the NFDM, NFx, ECN, and / or UE can automatically generate an NFD trigger based on configured NFD policies and / or local analysis results or analysis results received from the NWDAF. In step 0, it is assumed that the NFDM has subscribed to the NWDAF. The NFDM can receive analysis results regarding the NFx from the NWDAF. For example, the NFDM may have subscribed to the NWDAF to obtain predictive analysis results regarding locations where the number of UEs that can be served by an AMF (i.e., in this case, NFx = AMF) is maximized. In step 1, the NFDM can check with the NRF to obtain a list of existing NFxs that may be distributed to the edge network. The NRF can send the list of existing NFxs (including their status) to the NFDM. For example, the NFDM can discover the list of existing AMFs (or UPFs) (including their status) from the NRF. In step 2, the NFDM, NFx, ECN, and / or UE can check their locally stored NFD policies to generate an NFD trigger in step 3. For example, the NFDM may check its NFD policy against the predictive analysis result received from step 0. In step 3, the NFDM may contact the ENRF to discover candidate edge networks and / or edge servers for hosting the DNF to be created. For example, if the predictive analysis result from step 0 is UE-related location information, the NFDM may provide this location information to the ENRF; as a result, the ENRF may return a list of candidate edge networks and / or edge servers to the NFDM. The NFDM may select one or more edge networks and / or edge servers from this list to include in the NFD trigger to be generated in step 4.

[0362] In step 4, after checking the NFD policy in step 2, the NFMD / NFx / ENC / UE may generate an NFD trigger, which may be to create a DNF instance as a new NF at a certain location, or to create a DNF instance for an existing NFx at a certain location. If the trigger is to create a DNF instance as a new NF (i.e., there is no such peer NF instance in the 5GC), step 6 may not be required. For example, the NFDM may generate a DNF trigger to create a new AMF instance for an existing AMF in the 5GC at a selected edge network or edge server where many UEs suddenly appear and attempt to connect to the mobile core network. In step 5, the NFx, ENC, and / or UE may send the generated NFD trigger to the NFDM. It is assumed that the address of the NFDM is included in the NFD policy and is known to the NFx / ENC / UE; otherwise, the NFx / ENC / UE may be provided with the address of the NFDM or discover it from the NRF. In step 6, if the NFD trigger is to create a DNF instance for an existing NFx at a certain location (e.g., AMF in 5GC), NFDM can check with NFx whether it really needs to create a DNF instance in the edge network or edge server. In step 7, NFDM can verify the NFD trigger generated in step 4(a) or received from step 5 with PCF. To this end, NFDM can send a request indicating the NFD trigger to be verified to PCF. In step 8, PCF can receive the NFD trigger from step 7 and check its NFD policy to verify whether the NFD trigger should be generated. In step 9, PCF can send a response indicating the verification result to NFDM (i.e., whether the NFD trigger is valid). In step 10, if the NFD trigger is received from step 5, NFDM can forward the verification result received from step 9 to the sender of step 5 (i.e., NFx, ENC, or UE).

[0363] Figure 17An example process 1700 for creating a DNF instance at a selected edge network and / or edge server is shown. In step 1, assume that a new DNF trigger has been generated or received by the NFDM and verified by the PCF. It is also assumed that the DNF trigger specifies that a new DNF instance (i.e., DNFx) needs to be created at location Loc#1 for an existing centralized NF CNFx or a new NF of the same type CNFx. In step 2, the NFDM can discover candidate edge networks and / or edge servers deployed at location Loc#1 from the ENRF. In step 3, the NFDM can select an edge network and / or edge server. For example, the edge network / server with the greatest capabilities (e.g., compute and storage) and the least load can be selected. In step 4, the NFDM can send a request to the NFVO to create a new DNFx. This request can include the type of DNF to be created and the identifier / address of the selected edge network and / or edge server. The NFDM can also indicate its address to the NFVO and request that the NFVO instruct the DNFx to contact the NFDM once the DNFx is created. In step 5, NFVO may instruct the generation of a virtual network function on the selected edge network / server at location Loc#1 using network function virtualization technology. NFVO may send a response to NFDM indicating the access method (e.g., IP address and port number) of the created DNFx. It is assumed that NFVO notifies the ENC of the creation of DNFx, including their access method. Note that NFVO is a logical function and it may be part of the OAM system. In step 6, DNFx may contact NFDM to pull and receive some configuration information from NFDM (e.g., the identity / address of NRF, the identity / address of CNFx (if NDFx is created for CNFx), etc.). Alternatively, NFDM may send a request to DNFx to push such configuration information to DNFx. In step 7, NFDM or DNFx may send a request to NRF to register DNFx and its access method with the NRF. In step 8, if DNFx is created for CNFx, NFDM or DNFx may send a notification to CNFx to inform CNFx of the successful creation of DNFx, including the access method of DNFx. If step 7 does not occur, CNFx may register DNFx with NRF, including its access method.

[0364] Figure 18An example procedure 1800 is shown for a UE accessing and fully utilizing a DNF instance (i.e., DNFx) after the DNF instance is created at the edge network / server. At step 1, the NFDM (or CNFx if the UE is accessing the CNFx and the DNFx is created for the CNFx) can send a request to the UE indicating an access method of the DNFx and instructing the UE to fully utilize the DNFx. At step 2, the UE can send a discovery request to the ENC. As a result, the ENC can send to the UE a list of DNFx created at specified locations; for each discovered DNFx, the ENC can also send to the UE an access method of the DNFx. At step 3, the UE can start accessing the DNFx directly or indirectly via a local NEF. At step 4, the DNFx can send a periodic report to the NFDM, which indicates a list of UEs and / or applications accessing the DNFx, a rate of request messages received at the DNFx, etc. Such a report can also be sent to the CNFx, the NRF, and / or the NWDAF. At step 5, the NFDM can forward the periodic report or summary information from the periodic report to the CNFx. At step 6, the NFDM can send a notification to the NRF.

[0365] Figure 19 An example procedure 1900 is shown for deactivation or removal of a DNF instance (i.e., DNFx). At step 1, the NFDM can decide to deactivate the DNFx, e.g., based on some policies. At step 2, the NFDM can send a request directly to the DNFx to deactivate the DNFx. Alternatively, the NFDM can send a request to the NFVO to deactivate the DNFx using network virtualization techniques. The request can include an access method of another new DNFx. At step 3, the NFDM or the DNFx can notify the NRF (and the CNFx if the DNFx is created for the CNFx) of the deactivation of the DNFx. As a result, the NRF and the CNFx can remove any records or information about the DNFx. The NFDM, the DNFx, or the NRF can also notify the ENRF of the deactivation of the DNFx. At step 4, the DNFx can notify relevant UEs or edge applications of the deactivation of the DNFx and can notify them of other nearby DNFx. At step 5, the UE can select a new DNFx. At step 6, if a new DNFx is selected at step 5, the UE starts accessing the new DNFx; otherwise, the UE can resume accessing the CNFx in the 5GC. At step 7, the UE can resume accessing the CNFx in the 5GC.

[0366] Figure 20An example process 2000 illustrates the interaction between a CNF and all of its DNFs. In step 0, the CNF may have subscribed to each DNF in order to receive automatic notifications about their status. In step 1, the NF consumer may send a service request to the CNF. In step 2, the CNF may process the service request to authorize it. In step 3, the CNF may adapt the service request, for example, decomposing the service request into several adapted service requests. Each adapted service request may be serviced by a DNF. In step 4, the CNF may select an appropriate DNF for each adapted service request. In step 5, the CNF may send the adapted service request to the selected DNF. In step 6, the CNF may receive responses from the DNFs. In step 7, the CNF may generate a new response based on all responses from the DNFs. In step 8, the CNF may send the new response to the NF consumer.

[0367] Figure 21 An example process 2100 for enhancing EEC registration is shown. In step 1, the EEC may send a registration or registration update to the EES, via the parameter MSGin5G-Indication, indicating the UE's willingness and preference to use MSGin5G services. In step 2, the EES may search its local data to select an appropriate MES for the EEC based on the MSGin5G-Indication received in step 1. In step 3, the EES may contact each selected MES to confirm its availability. In step 4, the EES may select and assign one or more available MESs to the UE. Accordingly, the EES includes the addresses or identifiers of the assigned MESs and / or their corresponding MCSs in a response message sent to the EEC.

[0368] Figure 22 An example process 2200 for enhanced edge application registration is shown. In step 1, EAS may send a registration request or registration update to EES. If EAS wishes to be open to 5GC, EAS may indicate itself to EES. In step 2, EES may authorize the registration request. If the request is authorized, EES may register EAS. EES may then send a message to 5GC to report the newly registered EAS. Thus, 5GC may maintain a list of EAS registered at each EES, thereby enabling any network function consumer or application to discover EAS (and EES) from 5GC. In step 3, 5GC may send a response to EES. In step 4, EES may send a response to EAS and may indicate whether EAS has been reported to 5GC.

[0369] Figure 23 An example process 2300 for instantiating an edge-enabled server is shown. In step 1, the UE may, for example, Figure 6The process in reports its context and trigger to the 5GC. In step 2, the 5GC or the existing old EES can send a trigger to the distributed network function manager (DNFM) to request the instantiation of a new EES. For example, after the 5GC may receive context information from multiple UEs, it may determine that many UEs suddenly appear in one location and the new EES may benefit these UEs. Note that the DNFM can be part of the 5GC. In step 3, the DNFM can generate a new EES instance for the selected edge data network, for example based on the mechanism proposed for edge-assisted distributed network functions. As a result of this step, a new EES can be instantiated and created at the edge data network. In step 4, the DNFM can send a response to the 5GC (or the old EES). In step 5, if the old EES initiates the creation of a new EES, the old EES can transfer its EES context (e.g., a list of registered edge application servers, a list of registered edge-enabled clients) to the new EES. After the new EES receives the complete context from the old EES, it can contact each EEC and / or each EAS registered with the old EES to notify them of future contact with the new EES. Alternatively, the old EES can notify each of its EECs and / or EASs of the address of the new EES and instruct them to contact the new EES for future communications. In step 6, the DNFM can notify the edge data network configuration server of the newly instantiated EES. Alternatively, the DNFM may have already provided the new EES with the address of the edge data network configuration server; therefore, the new EES can proactively contact the edge data network configuration server to report its presence.

[0370] ENRF is proposed as a new NF. Each edge network registers its capabilities with ENRF, particularly its ability to host distributed NFs. NF consumers discover edge networks and their capabilities from ENRF or from the UDR (if ENRF stores edge network capabilities in the UDR). NWDAF can access edge data capabilities from ENRF and provide analysis results about edge data networks to NF consumers.

[0371] NFDM is proposed as a new NF to control and manage NF distribution. NFM can be deployed as part of NRF or can be co-located with NRF.

[0372] To support distributed NFs, each NFx can add new services (called "NF distribution") that allow NF service consumers to trigger NFx to create one or more NFx instances at the edge data network. For example, the following table lists two new services of NWDAF.

[0373]

[0374] Table 4: New services provided by NWDAF

[0375] The network slice instance is extended to include DNF, edge server, and edge data network. The UE can indicate its network slice requirement for edge entities (i.e., edge data network, edge server, and DNF). When the AMF selects a network slice instance for the UE, it not only considers the UE’s location, but also the UE’s network slice requirement for edge entities.

[0376] Figure 24 An example 2400 of UE user interface for UE context / trigger collection is shown. In (a), the user can manually select the context and trigger to send to the EES, which can also be specified by the user. After the user selects the context, trigger, and EES, the user simply clicks the “Send” button, and the selected context and trigger can be sent to the selected EES. In (b), the UE automatically generates pop-up messages. Each message requires the user to send the selected context and trigger to the selected EES by clicking the “Send” button. In this case, the user does not need to manually pick the context, trigger, and / or EES.

[0377] Figure 25 An example 2500 of UE user interface for MSGin5G sender and receiver is shown. As shown in (a), the MSGin5G sender can first indicate the message content, MSGin5G service address, and message receiver identifier and priority; then, the user clicks the “Send” button to send the message to the MSGin5G service, where the message can be delivered to the message receiver. As shown in (b), when the message is delivered to the MSGin5G receiver, the message can pop up on the UE’s screen, showing the received message content and message sender identifier; then, the receiver can click the “Confirm” button to confirm the received message and trigger sending a response message to the message sender.

[0378] Figure 26 An example user interface 2600 is shown. In addition, when the UE registers, performs registration update, performs configuration update, or establishes a PDU session with the 5GC, the 5GC can push some assigned MSGin5G servers to the UE. In this case, these assigned MSGin5G servers can pop up on the UE’s screen to allow the user to select one.

[0379] The following is a list of acronyms that can appear in the above description. Unless otherwise indicated, acronyms used herein refer to the corresponding term listed below.

[0380] 5G Fifth Generation

[0381] 5GC 5G core network

[0382] 5GS 5G system

[0383] AF application function

[0384] AMF Access Management Function

[0385] AN Access Network

[0386] CNF Centralized Network Function

[0387] DNF Distributed Network Function

[0388] EAC Edge Application Client

[0389] EAS Edge Enablement Server

[0390] EEC Edge Enabled Client

[0391] EES Edge Enabling Server

[0392] ENC Edge Network Controller

[0393] ENRF Edge Network Repository Functionality

[0394] GUAMI Globally Unique AMF ID

[0395] GUTI Globally Unique Temporary Identifier

[0396] MEC Multi-access Edge Computing

[0397] MSGin5G Message service within the 5G system

[0398] NEF Network Exposure Function

[0399] NF Network Function

[0400] NFD Network Function Distribution

[0401] NFDM Network Function Distribution Manager

[0402] NFV Network Function Virtualization

[0403] NFVO NFV Orchestrator

[0404] NRF Network Repository Features

[0405] NSSAI Network Slice Selection Assistance Information

[0406] NWDAF network data analysis function

[0407] OAM Operations, Administration and Maintenance

[0408] SBA Service-Based Architecture

[0409] SBI Service-Based Interface

[0410] SCP Service Communication Agent

[0411] SCS Service Capability Server

[0412] SMF session management functions

[0413] S-NSSAI Single Network Slice Selection Assistance Information

[0414] SUPI Subscription Persistent Identifier

[0415] UDM Unified Data Management

[0416] UE User Equipment

[0417] UPF User Plane Function

[0418] VNF Virtual Network Function

Claims

1. A device implementing a server function, the device comprising one or more processors and a memory, the device further comprising computer-executable instructions stored in the memory of the device, the computer-executable instructions, when executed by the one or more processors of the device, causing the server function on the device to: Receiving first context information or a first trigger from a first client function on a first network entity, wherein receiving the first context information or the first trigger is based on a first subscription from the device for storing and managing: first context information associated with a first client function on a first network entity, and a trigger from a first client function on a first network entity; receiving second context information or a second trigger from a second client function of a second network entity, wherein receiving the second context information or the second trigger is based on a second subscription from the device for storing and managing: second context information associated with a second client function of the second network entity, and a triggering of a second client function from a second network entity; Generate aggregated context information or aggregated triggers based on the following: First context information or first trigger, and second contextual information or a second trigger; and sending the aggregated context information or the aggregated trigger to a third network entity, The device includes at least one of the following: a network function or an edge enabling server in a 5G core network 5GC.

2. The apparatus of claim 1, wherein the first network entity comprises an edge-enabled client.

3. The apparatus of claim 1, wherein the second network entity comprises an edge-enabled client.

4. The apparatus according to claim 1, wherein the third network entity comprises a network function in a 5G core network 5GC.

5. The apparatus of claim 1 , wherein the computer-executable instructions, when executed by the one or more processors, further cause the apparatus to: A response is received from the third network entity.

6. The apparatus of claim 5, wherein the computer-executable instructions, when executed by the one or more processors, further cause the apparatus to: generating a second response based on the response; and A second response is sent to the first network entity.

7. The apparatus of claim 5, wherein the computer-executable instructions, when executed by the one or more processors, further cause the apparatus to: generating a second response based on the response; and A second response is sent to the second network entity.

8. The apparatus of claim 1 , wherein the computer-executable instructions, when executed by the one or more processors, further cause the apparatus to: Identify one or more network functions and services based on the following: First context information or first trigger, or Second context information or second trigger.

9. The apparatus of claim 1 , wherein the computer-executable instructions, when executed by the one or more processors, further cause the apparatus to: sending a request for one or more network functions and services to a fourth network entity; and A response is received from the fourth network entity.

10. The apparatus of claim 1, wherein the context information or trigger is at least one of: the location of the first network entity or the second network entity, or Willingness or preference to use services in the network.

Images