Apparatus for use in a user equipment

Abstract

The present application relates to an apparatus for use in a user equipment (UE), the apparatus comprising logic and circuitry configured to cause the UE to: generate, based on a remote memory access (RAM) protocol stack, a first protocol packet from data to be transmitted; generate, based on a wireless communication protocol stack, a second protocol packet from the first protocol packet; and transmit the second protocol packet on a radio bearer.

Description

[0001] Priority requirements This application is based on and claims priority to U.S. Patent Application No. 63 / 062,328, filed August 6, 2020, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0002] Embodiments of this disclosure generally relate to the field of wireless communication, and more particularly to apparatus used in user equipment (UE). Background Technology

[0003] Cloud computing has become very popular, providing customers with computing / storage capabilities that allow them to focus more on software development and data management without worrying too much about the performance limitations of their underlying infrastructure. Edge computing is thought to extend computing / storage capabilities closer to the customer, thereby optimizing performance metrics such as latency. In the 5G New Radio (NR) system architecture, the Uplink Classifier (ULCL) framework is used to offload computing tasks from user equipment (UE) to different data networks (DNs) that may be located at the network edge. For UEs with limited computing power, applications can be presented in cloud computing centers or network edge devices, with computing offloaded based on application-level logic built on top of the UE's operating system (OS). Traffic routing can be an application's inference of traffic transmitted over the cellular network to meet the application's Quality of Service (QoS) requirements. Attached Figure Description

[0004] Embodiments of this disclosure will be illustrated in the accompanying drawings by way of example rather than limitation, wherein similar reference numerals refer to similar elements.

[0005] Figure 1 An architectural reference model of a 5G NR system architecture is shown.

[0006] Figure 2 This demonstrates the evolution of 5G NR system architecture toward supporting enhanced computing and dynamic workload migration.

[0007] Figure 3 A method for use in a UE according to an embodiment of this disclosure is shown.

[0008] Figure 4 The runtime execution flow of the host program in the OpenCL framework is shown.

[0009] Figure 5 This diagram illustrates the high-level layering of the PCIe protocol stack.

[0010] Figure 6 The conceptual flow of a PCIe transaction is shown.

[0011] Figure 7 An end-to-end NR user plane protocol stack supporting the PCIe protocol stack is shown.

[0012] Figure 8a The OpenCL message flow is shown when the PCIe protocol stack is stacked on the NR protocol stack.

[0013] Figure 8b This shows the encoding format of the PDU session type information element.

[0014] Figure 9 The delays for sending and acknowledging TLPs are shown.

[0015] Figure 10 A schematic diagram of a network according to various embodiments of the present disclosure is shown.

[0016] Figure 11 A schematic diagram of a wireless network according to various embodiments of the present disclosure is shown.

[0017] Figure 12 A block diagram is shown of components according to some example embodiments of the present disclosure that are capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein.

[0018] Figure 13 A schematic diagram of a 5G edge computing network according to various embodiments of the present disclosure is shown.

[0019] Figure 14 A schematic diagram of an architecture capable of deploying edge applications according to various embodiments of the present disclosure is shown.

[0020] Figure 15 A schematic diagram of an application architecture for enabling edge applications according to various embodiments of the present disclosure is shown.

[0021] Figure 16 and Figure 17 A schematic diagram illustrating the relationship between edge-enabled servers within different EDNs and within the same EDN, according to various embodiments of this disclosure, is shown.

[0022] Figure 18 A schematic diagram illustrating the roles and relationships of service providers involved in the deployment of edge computing services according to various embodiments of this disclosure is shown.

[0023] Figure 19 The illustration shows a 5G service-based architecture and MEC architecture that can be deployed in an example edge computing system according to various embodiments of the present disclosure, as well as an integrated MEC deployment that can be used in a 5G network of the example edge computing system.

[0024] Figure 20A schematic diagram of a MEC system reference architecture according to various embodiments of the present disclosure is shown.

[0025] Figure 21 A schematic diagram of the MEC reference architecture in a Network Functions Virtualization (NFV) environment is shown.

[0026] Figure 22 A schematic diagram of the architecture, including the ETSI ISG MEC architecture and the EDGE APP architecture, is shown. Detailed Implementation

[0027] The illustrative embodiments will be described using terminology commonly used by those skilled in the art to convey the essence of this disclosure to them. However, it will be apparent to those skilled in the art that many alternative embodiments can be implemented using portions of the described aspects. Specific figures, materials, and configurations are given for purposes of explanation to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to those skilled in the art that alternative embodiments can be implemented without these specific details. In other instances, well-known features may be omitted or simplified to avoid obscuring the illustrative embodiments.

[0028] Furthermore, the various operations are described sequentially as a plurality of discrete operations in a manner most conducive to understanding the illustrative embodiments; however, the order of description should not be construed as implying that these operations are necessarily sequentially related. In particular, these operations do not need to be performed in the order presented.

[0029] The phrases “in an embodiment,” “in one embodiment,” and “in some embodiments” are used repeatedly throughout this document. These phrases do not typically refer to the same embodiment; however, they may refer to the same embodiment. Unless the context otherwise requires, the terms “comprising,” “having,” and “including” are synonyms. The phrases “A or B” and “A / B” mean “(A), (B), or (A and B).”

[0030] With the trend of cloudification in telecommunications networks, it is expected that cellular networks can be built flexibly and scalably through Virtualized Network Functions (VNFs) or Containerized Network Functions (CNFs) running on general-purpose hardware. Heterogeneous computing capabilities provided by hardware and software will naturally accompany this trend, enabling enhanced computing to be delivered to end devices across devices and networks. In different scenarios, computing tasks typically have different requirements in terms of resources and dependencies. Computing tasks can be standalone applications or applications serving one or more UEs, or they can be general-purpose functions such as artificial intelligence (AI) training or inference, or microservice functions using specific accelerators. Furthermore, computing tasks can be semi-static or dynamically initiated.

[0031] To enable these scenarios, this disclosure proposes that user equipment (UE) in a cellular network use the Peripheral Component Interconnect Fast (PCIe) protocol to access network-provided hardware (HW) accelerators. PCIe is a high-speed serial computer expansion bus standard. The PCIe interface is a common motherboard interface used for hardware connections to graphics cards, hard disk drives, solid-state drives (SSDs), Wi-Fi, Ethernet, field-programmable gate arrays (FPGAs), and M.2 cellular modems in personal computers. PCIe interfaces are also commonly used for cellular modem hardware connections in smartphones. Currently, the PCIe protocol is only supported on wired connections, and it is limited to wired connections where the hardware accelerator and motherboard must be in the same location.

[0032] To support enhanced computing and dynamic workload migration on 5G NR networks, this disclosure proposes accessing network-provided HW accelerators via the PCIe protocol through radio bearers in cellular networks. Moving HW accelerators to cellular networks offers several advantages. Applications have diverse accelerator requirements, such as graphics processing units (GPUs), field-programmable gate arrays (FPGAs), and high-speed storage devices. Building ultra-mobile devices that support all such accelerators would make them more expensive, larger, and heavier due to their large battery size. These devices would also require more complex cooling systems.

[0033] Figure 1 An architectural reference model of a 5G NR system architecture is shown. Figure 2 This demonstrates the evolution of 5G NR system architecture towards supporting enhanced computing and dynamic workload migration. From Figures 1 to 2 As can be seen, the user plane used for enhanced computing and dynamic workload migration is located between the UE and the compute scheduling function (SF) in the radio access network (RAN) (i.e., interfaces 3, 16, and 13).

[0034] This disclosure primarily relates to how to use the PCIe protocol to access network-provided HW accelerators via radio bearers in a cellular network and / or how to offload workloads from a UE to network-provided HW accelerators to enable enhanced computing and / or dynamic workload migration.

[0035] Figure 3 A method used in a UE according to an embodiment of this disclosure is shown. For example... Figure 3 As shown, method 300 includes: S302, generating a first protocol packet from data to be transmitted based on a remote memory access (RMA) protocol stack; S304, generating a second protocol packet from the first protocol packet based on a wireless communication protocol stack; and S306, transmitting the second protocol packet on a radio bearer.

[0036] In some embodiments, the RMA protocol stack is a Peripheral Component Interconnect Fast (PCIe) protocol stack, a Remote Direct Memory Access over Converged Ethernet (RDMA) v2 (RoCEv2) protocol stack, or a RapidIO protocol stack.

[0037] In some embodiments, the wireless communication protocol stack is a novel radio (NR) protocol stack.

[0038] In some embodiments, when the RMA protocol stack is a PCIe protocol stack, generating the first protocol packet includes: generating a transaction layer packet from the data to be sent based on the transaction layer protocol in the PCIe protocol stack; and generating a data link layer packet from the transaction layer packet as the first protocol packet based on the data link layer protocol in the PCIe protocol stack.

[0039] In some embodiments, generating a second protocol packet includes: generating a PDCP packet from a first protocol packet as a second protocol packet based on the Packet Data Convergence Protocol (PDCP) in the NR protocol stack.

[0040] In some embodiments, the first protocol packet is included in the Service Data Unit (SDU) of the PDCP packet, and a PDCP SDU type different from that used for Internet Protocol (IP) data and non-IP data is used for the first protocol packet.

[0041] In some embodiments, the first protocol packet is included in the Service Data Unit (SDU) of the PDCP packet, and the PDCP SDU type for non-Internet Protocol (non-IP) data is used for the first protocol packet.

[0042] In some embodiments, method 300 further includes: requesting the establishment of a radio access network (RAN) computing session by using a radio resource control (RRC) message, a non-access stratum (NAS) request message, or a request message of the RMA protocol stack.

[0043] In some embodiments, when the request message of the RMA protocol stack is used to request the establishment of a RAN computing session and the RMA protocol stack is a PCIe protocol stack, the RAN computing session type information element in the request message of the RMA protocol stack indicates that the RAN computing session type for PCIe will be used in the RAN computing session.

[0044] In some embodiments, when a NAS request message is used to request the establishment of a RAN computing session and the RMA protocol stack is a PCIe protocol stack, the PDU session type information element in the NAS request message indicates that an unstructured PDU session type will be used in the PDU session.

[0045] In some embodiments, transaction layer grouping includes TC information indicating the traffic category (TC) associated with a PCIe transaction, wherein the PCIe transaction is classified into eight TCs.

[0046] In some embodiments, method 300 further includes: sending UE dwell time for different payload sizes in a Protocol Data Unit (PDU) session establishment request message; and receiving REPLAY_TIMER limits for different payload sizes in a PDU session establishment response message, wherein the REPLAY_TIMER limit for the payload size of the transaction layer packet is used to determine whether to retransmit the transaction layer packet.

[0047] In some embodiments, the REPLAY_TIMER limit is determined based on the following: UE dwell time of the transaction layer packet, base station dwell time of the transaction layer packet, computational scheduling function (SF) dwell time of the transaction layer packet, data link layer processing time, computational SF dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet, base station dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet, and UE dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet.

[0048] In some embodiments, method 300 further includes: offloading workload from the UE to a network-provided hardware accelerator based on a software framework for writing programs that execute across heterogeneous platforms, wherein workload-related data is sent to the network-provided hardware accelerator by generating a first protocol packet from the workload-related data and generating a second protocol packet from the first protocol packet.

[0049] In some embodiments, the software framework is the Open Computing Language (OpenCL) framework, the Computing Unified Device Architecture (CUDA) framework, the Open Graphics Library (OpenGL) framework, or the Vulkan framework.

[0050] To illustrate how the OpenCL framework and PCIe protocol stack are used to enhance computing and enable dynamic workload migration, the following details are provided.

[0051] Overview of the OpenCL Framework The OpenCL framework is a software (SW) framework for writing programs that execute across heterogeneous platforms, including one or more central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), FPGAs, and other processors or hardware accelerators. The OpenCL framework consists of a host program that executes on an OpenCL host and a kernel that executes on one or more OpenCL devices. Together, the host program and the kernel are used to efficiently implement algorithms across heterogeneous platforms. The OpenCL host and one or more OpenCL devices are typically connected via a PCIe interface.

[0052] Figure 4 This illustrates the runtime execution flow of the host program. For example... Figure 4 As shown, the runtime execution flow of the host program includes: 1. Initialization • Query one or more OpenCL devices from the OpenCL host, and • Create a context to associate an OpenCL host with one or more OpenCL devices.

[0053] 2. Configure the kernel • Create programs for execution on one or more OpenCL devices (e.g., extract the kernel from a pre-compiled program file).

[0054] 3. Create data and kernel parameters • Create memory objects and kernel parameters.

[0055] 4. Submit for execution • Submit the kernel to the command queue for execution, and • Copy the results of kernel execution from one or more OpenCL devices to the OpenCL host.

[0056] PCIe Protocol Stack Overview The PCIe protocol stack consists of three discrete logical layers: the transaction layer, the data link layer, and the physical layer. Each of these layers is divided into two parts: one part handles outbound (to be sent) information, and the other part handles inbound (received) information. Figure 5 This diagram illustrates the high-level layering of the PCIe protocol stack.

[0057] The PCIe protocol stack uses packets to transmit information between sending and receiving components. Packets are formed at the transaction and data link layers to carry information from the sending component to the receiving component. As sent packets flow through other layers, they are expanded with additional information needed for processing at those layers. The receiving component performs the reverse process, transforming packets from a physical layer representation to a data link layer representation, and finally to a transaction layer representation that can be processed by the receiving component's transaction layer. Figure 6 The conceptual flow of a PCIe transaction is shown.

[0058] Transaction layer Above the PCIe protocol stack is the transaction layer. The primary responsibility of the transaction layer is to assemble and disassemble Transaction Layer Packets (TLPs). TLPs are used to transmit PCIe transactions (e.g., reads and writes) and certain types of events. The transaction layer is also responsible for managing credit-based flow control over TLPs.

[0059] Each request packet requiring a response packet is implemented as a split transaction. Each request packet has a unique identifier that allows the response packet to be directed to the correct initiator. Depending on the type of PCIe transaction (memory, I / O, configuration, and message), the packet format supports different forms of addressing.

[0060] Data Link Layer The middle layer of the PCIe protocol stack is the data link layer, which serves as an intermediate stage between the transaction layer and the physical layer. The primary responsibilities of the data link layer include link management and data integrity checks (including error detection and correction). The sending portion of the data link layer receives the transaction protection layer (TLP) assembled by the transaction layer, calculates the data protection code and TLP sequence number, applies them to the TLP, and then submits the TLP with the applied data protection code and TLP sequence number to the physical layer for transmission.

[0061] The receiving part of the data link layer is responsible for checking the integrity of the received TLP and submitting it to the transaction layer for further processing. When a TLP error is detected, the data link layer is responsible for requesting a retransmission of the TLP until the information is correctly received or a link failure is determined between the sending and receiving components.

[0062] The data link layer also generates and uses packets for link management functions. To distinguish these packets from those used by the transaction layer, the term "data link layer packet (DLLP)" can be used when referring to packets generated and used at the data link layer.

[0063] Physical layer The physical layer includes all the circuitry for interface operation, including drivers and input buffers, parallel-to-serial and serial-to-parallel converters, phase-locked loops (PLLs), and impedance matching circuitry. The physical layer also includes logic functions related to interface initialization and maintenance. The physical layer exchanges information with the data link layer in an implementation-specific format. The physical layer is responsible for converting information received from the data link layer into an appropriate serialization format and transmitting it via the PCI Fast Link at a frequency and bandwidth compatible with the receiving components connected to the other side of the link.

[0064] Integration of PCIe protocol stack and NR protocol stack This disclosure proposes replacing the physical layer of the PCIe protocol stack with the NR protocol stack. The transaction layer and data link layer of the PCIe protocol stack are located above the PDCP layer of the NR protocol stack. Hereinafter, for clarity and simplicity, the transaction layer and data link layer of the PCIe protocol stack will be referred to as the PCIe transaction layer and the PCIe data link layer.

[0065] In some embodiments, the General Packet Radio Service (GPRS) Tunneling User Plane (GPT-U) protocol is used as an example of the interface protocol between the 5G Access Network (5G-AN) and the RAN computed SF, such as... Figure 7 As shown, it illustrates an end-to-end NR user plane protocol stack supporting the PCIe protocol stack. This disclosure is not limited to the GTP-U protocol interface. Alternatively, the RAN computed SF can be part of the 5G-AN (e.g., located in the same location as the gNB central unit user plane (CU-UP)) or an instance of the gNB central CU-UP (in which case the PDCP layer terminates at the RAN computed SF).

[0066] On the transmitting side (i.e., in the UE uplink direction or the RAN calculating the SF downlink direction), the PCIe data link layer accepts the TLP assembled by the PCIe transaction layer, calculates the data protection code and TLP sequence number and applies them to the TLP, and then submits the TLP with the data protection code and TLP sequence number applied to it to the PDCP layer for transmission.

[0067] On the receiving side (i.e., in the UE downlink direction or the RAN-calculated SF uplink direction), the PCIe data link layer receives data from the PDCP layer (via GTP-U in the uplink) to check the integrity of the received TLP and submit it to the PCIe transaction layer for further processing. When a TLP error is detected, the PCIe data link layer is responsible for requesting a retransmission of the TLP until the information is correctly received or a link failure is determined between the sending and receiving sides.

[0068] Figure 8aThe OpenCL message flow is illustrated when a PCIe protocol stack is stacked on top of an NR protocol stack. Note that the message flow uses a modified PDU session / RAN compute session establishment procedure as an example. The message flow can also be used as an example using an RRC procedure or a new NAS procedure with relevant information. Furthermore, the software framework used to write programs that execute across heterogeneous platforms is not limited to the OpenCL framework. Any cross-platform application programming framework, such as Vulkan, CUDA, and OpenGL frameworks, can be used. Moreover, this disclosure is not limited to a PCIe protocol stack for providing remote memory access (RMA). Any protocol that supports RMA, such as RoCEv2 or RapidIO, can be used.

[0069] Although shown separately in the message flow, the RAN computed SF can be located in the same place as the gNB CU-UP, or as an instance of the gNB CU-UP (in which case the PDCP layer will terminate at the RAN computed SF).

[0070] like Figure 8a As shown, the message flow includes: In S800, the UE registers with the 5G NR network. During registration, supported compute offloading functions are discovered to ensure that the 5G NR network supports the PCIe protocol stack and the requested OpenCL devices.

[0071] In step S802, the UE requests the establishment of a RAN computation session using an RRC message, a modified PDU session / RAN computation session establishment request message, or a new NAS request message. In the case of a modified PDU session / RAN computation session establishment request message, a new PDU session type for PCIe is used. In this step, a RAN computation SF supporting the OpenCL framework and the PCIe protocol stack of the requested HW accelerator is allocated. The user plane is established using a dedicated radio bearer (DRB) and a quality of service (QoS) flow.

[0072] S804, the UE performs PCIe enumeration. The relevant PCIe TLP is embedded in the PDCP SDU (e.g., using a new SDU type for PCIe) and transmitted on the DRB.

[0073] S806, based on one or more discovered PCIe devices, the UE sets up the OpenCL kernel and creates memory objects and kernel parameters.

[0074] In S808, the UE submits one or more OpenCL kernels to the OpenCL command queue for execution. The associated PCIe TLP is embedded in the PDCP SDU (e.g., using a new SDU type for PCIe) and sent on the DRB.

[0075] S810, RAN compute SF loads OpenCL kernels from the OpenCL command queue and schedules the OpenCL kernels to execute on specific HW accelerators.

[0076] In S812, the RAN compute SF writes the results of executing the OpenCL kernel to the OpenCL results queue. The associated PCIe TLP is embedded in the PDCP SDU (e.g., using a new SDU type for PCIe) and sent on the DRB.

[0077] S814, the UE obtains the results of executing the OpenCL kernel from the OpenCL result queue.

[0078] New PDU types for PCIe The purpose of the PDU session type information element is to indicate the type of PDU session. The PDU session type information element is represented as follows: Figure 8b The encoding is shown in Table 1.

[0079] Table 1: PDU Session Type Information Elements New PDCP SDU type for PCIe Currently, the 5G NR system architecture only supports PDCP SDU types for IP data and non-IP data. To support PCIe data link layer packets, a new PDCP SDU type is proposed, as shown in Table 2.

[0080] Table 2: SDU Types The PDCP entity can process SDUs differently depending on the SDU type. For example, Robust Header Compression (ROHC) is applicable to IP SDUs but not to non-IP SDUs.

[0081] Enhanced 5GS QoS Model for PCIe Traffic Categories (TCs) are defined to allow PCIe transactions to be classified into eight TCs. The TC mechanism, along with PCIe Virtual Channel support, is a fundamental element for implementing differentiated traffic services. Each PCIe transaction layer packet uses TC information as a fixed tag, carried end-to-end within the PCIe architecture. As packets traverse the PCIe architecture, the TC information is used within each link and each switch element to make decisions about the correct service traffic.

[0082] Therefore, it is necessary to enhance the QoS model of the 5G NR system architecture to support end-to-end differentiation of PCIe transactions based on TC information.

[0083] Table 3: QoS Rule Information Elements PCIe REPLAY_TIMER Limitation for NR According to the PCIe protocol, the REPLAY_TIMER counts the time needed to determine when a previously transmitted TLP needs to be replayed. If the transmit retry buffer contains a TLP for which it has not received a positive or negative acknowledgment, and (as indicated by REPLAY_TIMER) no positive or negative acknowledgment is received within the time period limited by REPLAY_TIMER, the transmit component initiates replay. REPLAY_TIMER is started when the last symbol of the first TLP to be retransmitted is transmitted.

[0084] • The simplified REPLAY_TIMER constraint is: o When the extended synchronization bit is cleared, the value is between 24,000 and 31,000 symbol times.

[0085] o When the extended synchronization bit is set, the value is 80,000 to 100,000 symbol times.

[0086] If the extended sync bit changes state before an unacknowledged TLP is completed, the implementation is allowed to adjust their REPLAY_TIMER limits when the extended sync bit changes state or when the REPLAY_TIMER is reset next time.

[0087] • Implementations supporting data rates of 16.0 GT / s or higher must use a simplified REPLAY_TIMER limit for operations at all data rates.

[0088] • It is strongly recommended that implementations supporting only data rates below 16.0 GT / s use a simplified REPLAY_TIMER limit for operations at all data rates, but other REPLAY_TIMER limits are permitted.

[0089] When the PCIe protocol stack is integrated with the NR protocol stack, several issues need to be addressed when determining the REPLAY_TIMER limit. The PCIe data link layer does not know when the TLP is accurately transmitted on the radio bearer. Furthermore, the dwell time of the TLP within the UE's modem, gNB, and RAN calculations must be considered.

[0090] Figure 9 The delays for sending and acknowledging TLPs are shown. Based on Figure 9 This disclosure proposes to determine the REPLAY_TIMER limit based on different TLP payload sizes, as follows: REPLAY_TIMER limit (per payload size) = UE modem dwell time (TLP payload size) + gNB dwell time (TLP payload size) + SF dwell time calculation (TLP payload size) + Data link layer processing time + SF dwell time calculation (DLLP size for positive / negative acknowledgment) + gNB dwell time (DLLP size for positive / negative acknowledgment) + UE modem dwell time (DLLP size for positive / negative acknowledgment) Figure 10-12 Various systems, devices, and components are shown that can implement multiple aspects of the disclosed embodiments.

[0091] Figure 10 A schematic diagram of a network 1000 according to various embodiments of the present disclosure is shown. The network 1000 can operate in a manner consistent with the 3GPP technical specifications of Long Term Evolution (LTE) or 5G / NR systems. However, exemplary embodiments are not limited in this respect, and the described embodiments can be applied to other networks that benefit from the principles described herein, such as future 3GPP systems, etc.

[0092] Network 1000 may include UE 1002, which may include any mobile or non-mobile computing device designed to communicate with Radio Access Network (RAN) 1004 via an over-the-air connection. UE 1002 may be, but is not limited to, smartphones, tablet computers, wearable computing devices, desktop computers, laptop computers, in-vehicle infotainment devices, in-vehicle entertainment devices, dashboards, head-up displays, in-vehicle diagnostic devices, dashboard mobile devices, mobile data terminals, electronic engine management systems, electronic / engine control units, electronic / engine control modules, embedded systems, sensors, microcontrollers, control modules, engine management systems, network devices, machine-to-machine (M2M) or device-to-device (D2D) devices, Internet of Things (IoT) devices, etc.

[0093] In some embodiments, network 1000 may include multiple UEs that are directly coupled to each other through a secondary link interface. The UE may be an M2M / D2D device that communicates using physical secondary link channels (e.g., but not limited to, physical secondary link broadcast channel (PSBCH), physical secondary link discovery channel (PSDCH), physical secondary link shared channel (PSSCH), physical secondary link control channel (PSCCH), physical secondary link basic channel (PSFCH), etc.).

[0094] In some embodiments, UE 1002 can also communicate with access point (AP) 1006 via an over-the-air connection. AP 1006 can manage wireless local area network (WLAN) connections and can be used to offload some / all network traffic from RAN 1004. The connection between UE 1002 and AP 1006 can be consistent with any IEEE 802.11 protocol, where AP 1006 can be a Wi-Fi® router. In some embodiments, UE 1002, RAN 1004, and AP 1006 can utilize cellular WLAN aggregation (e.g., LTE-WLAN aggregation (LWA) / Lightweight IP (LWIP)). Cellular WLAN aggregation may involve RAN 1004 configuring UE 1002 to utilize both cellular radio resources and WLAN resources.

[0095] RAN 1004 may include one or more access nodes, such as Access Node (AN) 1008. AN 1008 can terminate the air interface protocol of UE 1002 by providing access layer protocols including Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Media Access Control (MAC), and L1 protocol. In this way, AN 1008 enables data / voice connectivity between Core Network (CN) 1020 and UE 1002. In some embodiments, AN 1008 may be implemented in discrete devices or as one or more software entities running on a server computer (as part of, for example, a virtual network, which may be referred to as a Distributed RAN (CRAN) or a virtual baseband unit pool). AN 1008 may be referred to as a Base Station (BS), Next Generation Base Station (gNB), RAN Node, Evolved Node B (eNB), Next Generation eNB (ng eNB), Node B (NodeB), Roadside Unit (RSU), TRxP, Transmit Receive Point (TRP), etc. AN 1008 can be a macro cell base station or a low-power base station, used to provide micro cells, pico cells, or other similar cells with smaller coverage areas, smaller user capacity, or higher bandwidth compared to macro cells.

[0096] In embodiments where RAN 1004 includes multiple ANs, these ANs can be coupled to each other via an X2 interface (if RAN 1004 is an LTE RAN) or an Xn interface (if RAN 1004 is a 5G RAN). In some embodiments, the X2 / Xn interfaces, which can be separated into control / user plane interfaces, can allow ANs to transmit and handover, data / context transfer, mobility, load management, interference coordination, and other related information.

[0097] The AN of RAN 1004 can manage one or more cells, cell groups, component carriers, etc., to provide an air interface for network access to UE 1002. UE 1002 can simultaneously connect to multiple cells provided by the same or different ANs of RAN 1004. For example, UE 1002 and RAN 1004 can use carrier aggregation to allow UE 1002 to connect to multiple component carriers, each component carrier corresponding to a primary cell (Pcell) or a secondary cell (Scell). In a dual-connectivity scenario, the first AN can be the primary node providing the primary cell group (MCG), and the second AN can be the secondary node providing the secondary cell group (SCG). The first / second AN can be any combination of eNB, gNB, ng eNB, etc.

[0098] RAN 1004 can provide an air interface on either licensed or unlicensed spectrum. To operate in unlicensed spectrum, nodes can use Licensed Assisted Access (LAA), enhanced LAA (eLAA), and / or further enhanced LAA (feLAA) mechanisms based on PCell / Scell ​​carrier aggregation (CA) technology. Before accessing unlicensed spectrum, nodes can perform medium / carrier sensing operations based on, for example, a Listen-Before-Speak (LBT) protocol.

[0099] In a vehicle-to-everything (V2X) scenario, UE 1002 or AN 1008 can be or act as a roadside unit (RSU), which can refer to any transportation infrastructure entity used for V2X communication. The RSU can be implemented in or by a suitable AN or a stationary (or relatively stationary) UE. An RSU implemented in or by a UE can be referred to as a "UE-type RSU"; an RSU implemented in or by an eNB can be referred to as an "eNB-type RSU"; an RSU implemented in or by a next-generation NodeB (gNB) can be referred to as a "gNB-type RSU," and so on. In one example, the RSU is a computing device coupled to radio frequency circuitry located on the roadside, providing connectivity support to passing vehicle UEs. The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU can provide very low-latency communication required for high-speed events such as collision avoidance, traffic warnings, etc. Alternatively or additionally, the RSU can provide other cellular / WLAN communication services. RSU components can be enclosed in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide wired connections (e.g., Ethernet) to traffic signal controllers or backhaul networks.

[0100] In some embodiments, RAN 1004 may be LTE RAN 1010, which includes an evolved Node B (eNB), such as eNB 1012. LTE RAN 1010 can provide an LTE air interface with the following characteristics: a 15 kHz subcarrier spacing (SCS); a single-carrier frequency division multiple access (SC-FDMA) waveform for uplink (UL) and a cyclic prefix orthogonal frequency division multiplexing (CP-OFDM) waveform for downlink (DL); turbo codes for data and TBCC for control, etc. The LTE air interface may rely on Channel State Information Reference Signal (CSI-RS) for CSI acquisition and beam management; rely on Physical Downlink Shared Channel (PDSCH) / Physical Downlink Control Channel (PDCCH) Demodulation Reference Signal (DMRS) for PDSCH / PDCCH demodulation; and rely on Cell Reference Signal (CRS) for cell search and initial acquisition, channel quality measurement, and channel estimation, and rely on channel estimation for coherent demodulation / detection at the UE. The LTE air interface can operate on a sub-6 GHz band.

[0101] In some embodiments, RAN 1004 may be a next-generation (NG) RAN 1014 with a gNB (e.g., gNB 1016) or a gn-eNB (e.g., ng-eNB 1018). gNB 1016 can connect to a 5G-enabled UE using a 5G NR interface. gNB 1016 can connect to the 5G core via an NG interface, which may include an N2 interface or an N3 interface. ng-eNB 1018 can also connect to the 5G core via an NG interface, but can connect to the UE via an LTE air interface. gNB 1016 and ng-eNB 1018 can connect to each other via an Xn interface.

[0102] In some embodiments, the NG interface can be divided into two parts: the NG user plane (NG-U) interface and the NG control plane (NG-C) interface. The former carries traffic data between the nodes of UPF 1048 and NG-RAN 1014 (e.g., the N3 interface), while the latter is the signaling interface between the nodes of Access and Mobility Management Function (AMF) 1044 and NG-RAN 1014 (e.g., the N2 interface).

[0103] NG-RAN 1014 can provide a 5G-NR air interface with the following features: Variable Subcarrier Spacing (SCS); Cyclic Prefix-Orthogonal Frequency Division Multiplexing (CP-OFDM) for downlink (DL), CP-OFDM and DFT-s-OFDM for UL; Polarity, Repetition, Simplex, and Reed-Muller codes for control, and Low-Density Parity-Check (LDPC) codes for data. The 5G-NR air interface can be similar to the LTE air interface, relying on Channel State Reference Signals (CSI-RS) and PDSCH / PDCCH Demodulation Reference Signals (DMRS). The 5G-NR air interface may not use Cell Reference Signals (CRS), but can use Physical Broadcast Channel (PBCH) Demodulation Reference Signals (DMRS) for PBCH demodulation; Phase Tracking Reference Signals (PTRS) for PDSCH phase tracking; and Tracking Reference Signals for time tracking. The 5G-NR air interface can operate on the FR1 band, which includes the sub-6 GHz band, or the FR2 band, which includes the 24.25 GHz to 52.6 GHz band. The 5G-NR air interface can include synchronization signals and PBCH blocks (SSBs), where an SSB is an area of ​​the downlink resource grid that includes the primary synchronization signal (PSS), secondary synchronization signal (SSS), and PBCH.

[0104] In some embodiments, the 5G-NR air interface can use the bandwidth portion (BWP) for various purposes. For example, the BWP can be used for dynamic adaptation of the SCS. For instance, UE 1002 can be configured with multiple BWPs, each configured with a different SCS. When a BWP is indicated to UE 1002 for a change, the transmitted SCS also changes. Another use case for BWPs relates to power saving. Specifically, multiple BWPs with different numbers of frequency resources (e.g., PRBs) can be configured for UE 1002 to support data transmission under different traffic load scenarios. A BWP containing fewer PRBs can be used for data transmission with lower traffic loads, while allowing power saving at UE 1002 and, in some cases, at gNB 1016. A BWP containing more PRBs can be used for scenarios with higher traffic loads.

[0105] RAN 1004 is communicatively coupled to CN 1020, which includes network elements, to provide various functions supporting data and telecommunications services to customers / subscribers (e.g., users of UE 1002). Components of CN 1020 can be implemented in a single physical node or in different physical nodes. In some embodiments, Network Function Virtualization (NFV) can be used to virtualize any or all of the functions provided by the network elements of CN1020 onto physical computing / storage resources such as servers, switches, etc. A logical instance of CN 1020 can be referred to as a network slice, and a logical instance of a portion of CN 1020 can be referred to as a network subslice.

[0106] In some embodiments, CN 1020 may be LTE CN 1022, or may be referred to as EPC. LTE CN 1022 may include a Mobility Management Entity (MME) 1024, a Serving Gateway (SGW) 1026, a Serving General Packet Radio Service (GPRS) Support Node (SGSN) 1028, a Home Subscriber Server (HSS) 1030, a Proxy Gateway (PGW) 1032, and a Policy Control and Charging Rules Function (PCRF) 1034, as shown in the figure. These components are coupled to each other through interfaces (or "reference points"). The functions of the elements of LTE CN 1022 can be briefly described below.

[0107] MME 1024 enables mobility management functions to track the current location of UE 1002, thereby facilitating paging, bearer activation / deactivation, handover, gateway selection, authentication, and other functions.

[0108] The SGW 1026 can terminate the S1 interface toward the RAN and route data packets between the RAN and the LTE CN 1022. The SGW 1026 can serve as a local mobility anchor for handover between RAN nodes and can also provide anchoring for inter-3GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

[0109] SGSN 1028 can track the location of UE 1002 and perform security functions and access control. Additionally, SGSN 1028 can perform EPC inter-node signaling for mobility between different RAT networks; PDN and S-GW selection specified by MME 1024; MME selection for handover, etc. The S3 reference point between MME 1024 and SGSN 1028 enables the exchange of user and bearer information for 3GPP indirect network access mobility in idle / active states.

[0110] The HSS 1030 may include a database for network users, containing subscription-related information that supports network entities in handling communication sessions. The HSS 1030 can provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc. An S6a reference point between the HSS 1030 and the MME 1024 enables the transmission of subscription and authentication data for authenticating / authorizing user access to the LTE CN 1020.

[0111] PGW 1032 can terminate the SGi interface toward a data network (DN) 1036, which may include an application / content server 1038. PGW 1032 can route data packets between the LTE CN 1022 and the data network 1036. PGW 1032 can be coupled to SGW 1026 via an S5 reference point to facilitate user plane tunneling and tunnel management. PGW 1032 may also include nodes for policy enforcement and charging data collection (e.g., PCEF). Additionally, the SGi reference point between PGW 1032 and the data network 1036 can be, for example, an external public or private PDN or an internal packet data network for providing IP Multimedia Subsystem (IMS) services. PGW 1032 can be coupled to PCRF 1034 via a Gx reference point.

[0112] PCRF 1034 is the policy and charging control element of LTE CN 1022. PCRF 1034 can be communicatively coupled to application / content server 1038 to determine appropriate Quality of Service (QoS) and charging parameters for service flows. PCRF 1032 can provide relevant rules to PCEF (via Gx reference point) with appropriate Service Flow Template (TFT) and QoS Class Identifier (QCI).

[0113] In some embodiments, CN 1020 may be a 5G core network (5GC) 1040. 5GC 1040 may include Authentication Server Function (AUSF) 1042, Access and Mobility Management Function (AMF) 1044, Session Management Function (SMF) 1046, User Plane Function (UPF) 1048, Network Slice Selection Function (NSSF) 1050, Network Open Function (NEF) 1052, NF Storage Function (NRF) 1054, Policy Control Function (PCF) 1056, Unified Data Management (UDM) 1058, and Application Function (AF) 1060, as shown in the figure. These functions are coupled to each other through interfaces (or "reference points"). The functions of the components of 5GC 1040 can be briefly described below.

[0114] The AUSF 1042 can store data for UE 1002 authentication and handle authentication-related functions. The AUSF 1042 facilitates a common authentication framework for various access types. In addition to communicating with other components of the 5GC 1040 via a reference point, as shown in the figure, the AUSF 1042 can also demonstrate an interface based on Nausf services.

[0115] AMF 1044 allows other functions of 5GC 1040 to communicate with UE 1002 and RAN 1004 and subscribe to notifications about mobility events for UE 1002. AMF 1044 can handle registration management (e.g., registering UE 1002), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. AMF 1044 can provide the transmission of Session Management (SM) messages between UE 1002 and SMF 1046 and acts as a transparent broker for routing SM messages. AMF 1044 can also provide the transmission of SMS messages between UE 1002 and the SMSF. AMF 1044 can interact with AUSF 1042 and UE 1002 to perform various security anchoring and context management functions. Furthermore, AMF 1044 can be the termination point of the RANCP interface, which may include or be the N2 reference point between RAN 1004 and AMF 1044; AMF 1044 can serve as the termination point for NAS (N1) signaling and perform NAS encryption and integrity protection. AMF 1044 can also support NAS signaling with UE 1002 via the N3 IWF interface.

[0116] SMF 1046 can be responsible for SM (e.g., tunnel management and session establishment between UPF 1048 and AN 1008); UE IP address allocation and management (including optional authorization); selection and control of UP functions; configuring flow control at UPF 1048 to route traffic to appropriate destinations; termination of interfaces to policy control functions; control of policy enforcement, charging, and QoS as a part; lawful interception (for SM events and interfaces to the LI system); termination of the SM portion of NAS messages; downlink data notification; initiating AN-specific SM information (sent to AN 1008 on N2 via AMF 1044); and determining the SSC mode of the session. SM can refer to the management of PDU sessions, and a PDU session or "session" can refer to the PDU connectivity service that provides or enables PDU exchange between UE 1002 and data network 1036.

[0117] The UPF 1048 can be used as an anchor point for mobility within and between RATs, an external PDU session point interconnecting with the data network 1036, and a branch point supporting multi-homed PDU sessions. The UPF 1048 can also perform packet routing and forwarding, packet inspection, user plane portion of policy rules, lawful packet interception (IP collection), traffic usage reporting, QoS processing for the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), uplink traffic authentication (e.g., SDF-to-QoS flow mapping), transport-level packet marking in uplink and downlink, and downlink packet buffering and downlink data notification triggering. The UPF 1048 may include an uplink classifier to support traffic flow routing to the data network.

[0118] The NSSF 1050 can select a set of network slice instances to serve UE 1002. If needed, the NSSF 1050 can also determine the allowed Network Slice Selection Assistance Information (NSSAI) and its mapping to a single subscribed NSSAI (S-NSSAI). The NSSF 1050 can also determine the set of AMFs to be used to serve UE 1002 based on appropriate configuration and possibly by querying the NRF 1054, or determine a list of candidate AMFs. The selection of a set of network slice instances for UE 1002 can be triggered by the AMF 1044 (which UE 1002 registers with through interaction with the NSSF 1050), resulting in a change of AMF. The NSSF 1050 can interact with the AMF 1044 via reference point N22; and can communicate with another NSSF in the access network via reference point N31 (not shown). Furthermore, the NSSF 1050 can expose an interface based on NNSSF services.

[0119] The NEF 1052 can securely expose services and capabilities provided by 3GPP network functions to third parties, internal exposure / re-exposure, AFs (e.g., AF 1060), edge computing, or fog computing systems. In these embodiments, the NEF 1052 can authenticate, authorize, or restrict AFs. The NEF 1052 can also translate information exchanged with the AF 1060 and information exchanged with internal network functions. For example, the NEF 1052 can translate between AF service identifiers and internal 5GC information. The NEF 1052 can also receive information from other NFs based on their exposed capabilities. This information can be stored as structured data at the NEF 1052 or stored at a data storage NF using a standardized interface. The NEF 1052 can then re-expose the stored information to other NFs and AFs, or use it for other purposes such as analytics. Additionally, the NEF 1052 can expose interfaces based on Nnef services.

[0120] NRF 1054 supports service discovery, receiving NF discovery requests from NF instances and providing information about discovered NF instances to them. NRF 1054 also maintains information about available NF instances and the services they support. As used herein, the terms "instantiation," "instance," etc., can refer to the creation of an instance, and an "instance" can refer to the concrete occurrence of an object, such as during program code execution. Furthermore, NRF 1054 can demonstrate interfaces based on NRF services.

[0121] The PCF 1056 can provide policy rules to control plane functions to execute them, and can also support a unified policy framework to manage network behavior. The PCF 1056 can also implement a front-end to access subscription information related to policy decisions in the UDR of the UDM 1058. In addition to communicating with functions via reference points as shown in the figure, the PCF 1056 also demonstrates an interface based on Npcf services.

[0122] UDM 1058 can process subscription-related information to support network entities in handling communication sessions and can store subscription data for UE 1002. For example, subscription data can be transmitted via the N8 reference point between UDM 1058 and AMF 1044. UDM 1058 can include two parts: an application front-end and a user data record (UDR). The UDR can store policy data and subscription data for UDM 1058 and PCF 1056, and / or structured data and application data for exposure (including PFD for application detection and application request information for multiple UEs 1002) for NEF 1052. UDR 221 can expose a Nudr service-based interface to allow UDM 1058, PCF 1056, and NEF 1052 to access specific sets of stored data, as well as to read, update (e.g., add, modify), delete, and receive notifications of relevant data changes in the subscription UDR. UDM may include UDM-FE (UDM front-end), which is responsible for handling credentials, location management, subscription management, etc. Several different front-ends can provide services to the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification processing, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs via reference points as shown in the figure, the UDM 1058 can also demonstrate interfaces based on Nudm services.

[0123] The AF 1060 can provide application impact on service routing, provide access to NEF, and interact with the policy framework for policy control.

[0124] In some embodiments, 5GC 1040 can enable edge computing by selecting an operator / third-party service that is geographically close to the point where UE 1002 connects to the network. This can reduce latency and load on the network. To provide edge computing implementation, 5GC 1040 can select a UPF 1048 close to UE 1002 and perform traffic routing from UPF 1048 to data network 1036 via the N6 interface. This can be based on UE subscription data, UE location, and information provided by AF 1060. In this way, AF 1060 can influence UPF (re)selection and service routing. Based on operator deployment, when AF 1060 is considered a trusted entity, the network operator can allow AF 1060 to interact directly with the relevant NF. In addition, AF 1060 can expose an interface based on Naf services.

[0125] Data network 1036 can represent various network operator services, Internet access, or third-party services that can be provided by one or more servers (including, for example, application / content server 1038).

[0126] Figure 11 A wireless network 1100 according to various embodiments is schematically illustrated. The wireless network 1100 may include a UE 1102 that communicates wirelessly with an AN 1104. The UE 1102 and the AN 1104 may be similar to and substantially interchangeable with components of the same name described elsewhere herein.

[0127] UE 1102 can be communicatively coupled to AN 1104 via connection 1106. Connection 1106 is shown as an air interface to enable communication coupling and can operate at millimeter wave or sub-6 GHz frequencies according to cellular communication protocols such as LTE or 5G NR.

[0128] UE 1102 may include a host platform 1108 coupled to a modem platform 1110. Host platform 1108 may include application processing circuitry 1112, which may be coupled to protocol processing circuitry 1114 of modem platform 1110. Application processing circuitry 1112 may run various applications for UE 1102 to process source / receive application data. Application processing circuitry 1112 may also implement one or more layer operations to send / receive application data to / from a data network. These layer operations may include transport (e.g., UDP) and Internet (e.g., IP) operations.

[0129] Protocol processing circuitry 1114 can implement one or more layer operations to facilitate the transmission or reception of data via connection 1106. Layer operations implemented by protocol processing circuitry 1114 may include, for example, Media Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), RRC, and Non-Access Stratum (NAS) operations.

[0130] The modem platform 1110 may further include digital baseband circuitry 1116, which can implement one or more layer operations "below" the layer operations performed by protocol processing circuitry 1114 in the network protocol stack. These operations may include, for example, one or more of the following PHY operations: HARQ-ACK function, scrambling / descrambling, encoding / decoding, layer mapping / demapping, modulation symbol mapping, received symbol / bit metric determination, multi-antenna port precoding / decoding. These functions may include one or more of the following: space-time, space-frequency, or spatial coding, reference signal generation / detection, preamble sequence generation and / or decoding, synchronization sequence generation / detection, blind decoding of control channel signals, and other related functions.

[0131] The modem platform 1110 may further include transmitting circuitry 1118, receiving circuitry 1120, RF circuitry 1122, and RF front-end (RFFE) circuitry 1124, which may include or be connected to one or more antenna panels 1126. In short, transmitting circuitry 1118 may include a digital-to-analog converter, a mixer, an intermediate frequency (IF) component, etc.; receiving circuitry 1120 may include an analog-to-digital converter, a mixer, an IF component, etc.; RF circuitry 1122 may include a low-noise amplifier, a power amplifier, a power tracking component, etc.; and RFFE circuitry 1124 may include filters (e.g., surface acoustic wave filters), switches, antenna tuners, beamforming components (e.g., phased array antenna components), etc. The selection and arrangement of components such as the transmitting circuit 1118, receiving circuit 1120, RF circuit 1122, RFFE circuit 1124, and antenna panel 1126 (collectively referred to as the "transmit / receive assembly") can be specific to implementation details, such as whether the communication is time division multiplexing (TDM) or frequency division multiplexing (FDM), at mmWave or frequencies below 6 GHz, etc. In some embodiments, the transmit / receive assembly can be arranged in multiple parallel transmit / receive chains and can be arranged in the same or different chips / modules, etc.

[0132] In some embodiments, the protocol processing circuit 1114 may include one or more instances of control circuitry (not shown) to provide control functions for the transmitting / receiving components.

[0133] UE reception can be established via and through antenna panel 1126, RFFE circuit 1124, RF circuit 1122, receiving circuit 1120, digital baseband circuit 1116, and protocol processing circuit 1114. In some embodiments, antenna panel 1126 can receive transmissions from AN 1104 by receiving beamforming signals received by a plurality of antennas / antenna elements of one or more antenna panels 1126.

[0134] UE transmission can be established via and through protocol processing circuitry 1114, digital baseband circuitry 1116, transmission circuitry 1118, RF circuitry 1122, RFFE circuitry 1124, and antenna panel 1126. In some embodiments, the transmission component of UE 1102 can apply spatial filtering to the data to be transmitted to form a transmission beam transmitted by the antenna elements of antenna panel 1126.

[0135] Similar to UE 1102, AN 1104 may include a host platform 1128 coupled to a modem platform 1130. Host platform 1128 may include application processing circuitry 1132 coupled to protocol processing circuitry 1134 of modem platform 1130. The modem platform may also include digital baseband circuitry 1136, transmit circuitry 1138, receive circuitry 1140, RF circuitry 1142, RFFE circuitry 1144, and antenna panel 1146. Components of AN 1104 may be similar to and substantially interchangeable with their counterparts in UE 1102. In addition to performing data transmission / reception as described above, components of AN 1104 may perform various logical functions, including, for example, Radio Network Controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management, and packet scheduling.

[0136] Figure 12 This is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any or more methods discussed herein, according to some example embodiments. Specifically, Figure 12 A schematic diagram of hardware resource 1200 is shown, which includes one or more processors (or processor cores) 1210, one or more memory / storage devices 1220, and one or more communication resources 1230, wherein each of these processors, memory / storage devices, and communication resources can be communicatively coupled via bus 1240 or other interface circuitry. For embodiments utilizing node virtualization (e.g., Network Functions Virtualization (NFV)), a hypervisor 1202 can be executed to provide an execution environment for one or more network slices / subslices to utilize hardware resource 1200.

[0137] Processor 1210 may include, for example, processor 1212 and processor 1214. Processor 1210 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) such as a baseband processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a radio frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

[0138] The memory / storage device 1220 may include main memory, disk storage devices, or any suitable combination thereof. The memory / storage device 1220 may include, but is not limited to, any type of volatile, non-volatile, or semi-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, etc.

[0139] Communication resource 1230 may include interconnect or network interface controllers, components, or other suitable devices for communicating with one or more peripheral devices 1204 or one or more databases 1206 or other network elements via network 1208. For example, communication resource 1230 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, near field communication (NFC) components, Bluetooth® (or Bluetooth® Low Energy) components, Wi-Fi® components, and other communication components.

[0140] Instructions 1250 may include software, programs, application programs, applets, or other executable code for causing at least any one of processors 1210 to perform any one or more of the methods discussed herein. Instructions 1250 may reside wholly or partially within processor 1210 (e.g., in the processor's cache), memory / storage device 1220, or any suitable combination thereof. Furthermore, any portion of instructions 1250 may be transferred from any combination of peripheral device 1204 or database 1206 to hardware resource 1200. Therefore, the memory of processor 1210, memory / storage device 1220, peripheral device 1204, and database 1206 are examples of computer-readable and machine-readable media.

[0141] Edge computing refers to the implementation, coordination, and use of computing and resources at locations closer to the “edge” or a collection of “edges” of the network. Deploying computing resources at the edge of the network can reduce application and network latency, reduce network backhaul traffic and associated energy consumption, improve service capabilities, enhance compliance with security or data privacy requirements (especially compared to traditional cloud computing), and improve total cost of ownership.

[0142] A separate computing platform or other component capable of performing edge computing operations (referred to as an "edge computing node," "edge node," etc.) can reside anywhere required by the system architecture or self-organizing service. In many edge computing architectures, edge nodes are deployed at gateways, network routers, and / or other devices closer to the endpoint devices that generate and use data (e.g., UEs, Internet of Things (IoT) devices, etc.). For example, edge nodes can be implemented in high-performance computing data centers or cloud installations; in designated edge node servers, enterprise servers, roadside servers, or telecommunications central offices; or on local or peer-to-peer edge devices that are using edge services.

[0143] Edge computing nodes can partition resources (e.g., memory, CPU, GPU, interrupt controllers, I / O controllers, memory controllers, bus controllers, network connections, or sessions), where each partition can include security and / or integrity protection capabilities. Edge nodes can also provide orchestration for multiple applications through isolated user-space instances such as containers, partitions, virtual environments (VEs), virtual machines (VMs), Function as a Service (FaaS) engines, servlets, servers, and / or other similar compute abstractions. Containers are contained, deployable software units that provide code and the necessary dependencies. Various edge system deployments / architectures treat VMs, containers, and functions equally in terms of application composition. Edge nodes coordinate based on edge provisioning capabilities, while the operation of various applications is coordinated with orchestration capabilities (e.g., VMs or container engines). Orchestration capabilities can be used to deploy isolated user-space instances, identify and schedule the use of specific hardware, security-related functions (e.g., key management, trust anchor management, etc.), and other tasks related to the provisioning and lifecycle of isolated user spaces.

[0144] Applications suitable for edge computing include, but are not limited to, the virtualization of traditional network functions, such as, for example, Software-Defined Networking (SDN), Network Functions Virtualization (NFV), Distributed RAN Units, and / or RAN Clouds. Other example use cases for edge computing include compute offloading, Content Data Network (CDN) services (e.g., video-on-demand, content streaming, security monitoring, alarm system monitoring, building access, data / content caching, etc.), gaming services (e.g., AR / VR, etc.), accelerated browsing, IoT and industry applications (e.g., factory automation), media analytics, real-time streaming / transcoding, and V2X applications (e.g., driver assistance and / or autonomous driving applications).

[0145] 5G networks go beyond traditional mobile broadband services to provide a variety of new services such as IoT, industrial control, autonomous driving, and mission-critical communications (which may have ultra-low latency, ultra-high reliability, and high data capacity requirements due to security and performance concerns). Edge computing capabilities are added to the core 5G system architecture to support these services by hosting applications closer to the local data network, thereby reducing end-to-end latency and load on the transport network. Figure 13 An example 5G edge computing network is shown.

[0146] Figure 14 An architecture capable of deploying edge applications is illustrated, wherein the application client is an application residing in the UE (User Equipment) performing client functions, and the edge application server (EAS) is an application server residing in an edge data network that serves as a local data network and performs server functions. The application client connects to the edge application server to utilize (or obtain) the services of applications with the advantages of edge computing.

[0147] Deploying edge computing in 3GPP networks requires collaboration with other Service Data Objects (SDOs) because Application Functions (AFs) and Access Layers (ASs) are not 3GPP-defined nodes. Deploying network functions to support edge computing in both 3GPP and non-3GPP networks requires communication between the 3GPP management system and the non-3GPP management system.

[0148] Figure 14 An example peer-to-peer (P2P) edge computing management deployment scenario is shown, in which deploying edge computing in a 3GPP network requires communication between the 3GPP management system and non-3GPP management systems (including the edge computing management system and the European Telecommunications Standards Institute (ETSI) NFV Management and Orchestration (MANO)).

[0149] exist Figure 14In the example, the 3GPP management system can initiate edge computing deployment by requesting the edge computing management system to deploy a local data network and requesting the NFV orchestrator (NFVO) to connect the UPF and the local data network, where the local data network has QoS requirements for the connection (e.g., a virtual link) between the UPF and the local data network. The edge computing management system can also initiate edge computing deployment by requesting the 3GPP management system to deploy a UPF and requesting the NFVO to connect the UPF and the local data network, where the local data network has QoS requirements for the connection between the UPF and the local data network.

[0150] Figure 15 An application architecture for enabling edge applications is shown. The edge data network is a local data network (e.g., Figure 10 (DN 1036). Edge application servers and edge enable servers are included in the EDN. The edge configuration server provides configuration related to the edge enable server (EES), including details of the edge data network hosting the EES. The UE contains one or more application clients and edge enable clients. The edge application server, edge enable server, and edge configuration server can interact with the 3GPP core network.

[0151] The Edge-1 (EDGE-1) reference point supports interactions between the edge-enabled server and the edge-enabled client related to enabling edge computing. The EDGE-1 reference point supports: registration and deregistration of edge-enabled clients to the edge-enabled server; retrieval and provision of configuration information for the UE; and discovery of available edge application servers in the edge data network.

[0152] The Edge-2 (EDGE-2) reference point supports interactions between the Edge Enablement Server (EES) and the 3GPP network related to the Edge Enablement Layer. The EES supports access to 3GPP network functions and APIs to retrieve network capability information (e.g., via the Service Capability Open Function (SCEF) and NEF API), where the EES acts as a trusted AF in the 5GC. The EES reuses 3GPP reference points defined in SA2, N33, or EPS or 5GS interfaces considering different deployment models.

[0153] Edge-3 (EDGE-3) reference points support interactions between edge enable servers and edge application servers related to the edge enable layer. EDGE-3 reference points support: registering edge application servers using availability information (e.g., time constraints, location constraints); deregistering edge application servers from edge enable servers; and providing access to network capability information (e.g., location information). The following cardinality rules apply to EDGE-3 (between EA and EES): a) an EAS can communicate with only one EES; b) an EES can communicate with one or more EAS simultaneously.

[0154] The EDGE-4 reference point supports edge data network configuration information between the edge data network configuration server and the edge-enabled client, related to the edge enable layer. The EDGE-4 reference point supports providing edge data network configuration information to the edge-enabled client in the UE.

[0155] The Edge-5 (EDGE-5) reference point supports interaction between one or more application clients and edge-enabled clients in the UE. The EDGE-5 reference point supports: obtaining information about the edge application servers that the application client needs to connect to; notification of events related to the connection between the application client and its corresponding edge application server, such as when the application client needs to reconnect to a different edge application server; providing application client information (e.g., its profile) for various tasks, such as identifying the appropriate edge application server instance to connect to; and providing the edge-enabled client with the desired edge application server identity, enabling it to use that identity as a filter when requesting information about the edge application server.

[0156] Edge-6 (EDGE-6) reference points support edge-enabled layer-related interactions between the edge data network configuration server and the edge enable server. EDGE-6 reference points support the registration of edge enable server information to the edge enable network configuration server.

[0157] Edge-2 (EDGE-2) (or EDGE-7) reference points support edge-enabled layer-related interactions between the edge-enabled server and the 3GPP network. EDGE-7 reference points support access to 3GPP network functions and APIs to retrieve network capability information (e.g., via the SCEF and NEF APIs), where the EAS acts as a trusted AF in the 5GC. EDGE-7 reference points reuse 3GPP reference points defined in SA2, N6, or EPS or 5GS interfaces considering different deployment models.

[0158] The EDGE-8 reference point supports interaction between the edge data network configuration server and the 3GPP network. The EDGE-8 reference point supports providing edge data network configuration to the 3GPP network using Network Open Services.

[0159] EDGE-9 reference points support interaction between two edge-enabled servers. EDGE-9 reference points can provide communication between EES servers in different EDNs and within the same EDN.

[0160] EES provides the necessary support functions for edge application servers and edge-enabled clients. The functions of the edge-enabled server include: a) providing configuration information to edge-enabled clients to enable the exchange of application data traffic with the edge application server; b) supporting application programming interface (API) callers and API open functions; c) interacting with the 3GPP core network to access network functions directly (e.g., via PCF) or indirectly (e.g., via SCEF / NEF / SCEF+NEF); and d) supporting application context transfer.

[0161] The following cardinality rules apply to edge-enabled servers: a) One or more EES can reside in an EDN; b) One or more EES can reside in the EDN of each Edge Computing Service Provider (ECSP).

[0162] EAS is an application server residing in an edge data network, performing server functions. Application clients connect to the edge application server to leverage the advantages of edge computing and access application services. The application's server functions may only be available as an edge application server. However, if the application's server functions can be used simultaneously as an edge application server and an application server residing in the cloud, then the functions of the edge application server and the application server may differ. Furthermore, if the edge application server and the application server have different functions, the application data traffic may also differ.

[0163] Edge application servers can use 3GPP core network functions in different ways, such as: a) if it is a 3GPP core network trusted entity, it can directly call the 3GPP core network function API; b) it can call 3GPP core network functions through the edge enabled server; and c) it can call 3GPP core network functions through capability exposure functions (e.g., SCEF or NEF).

[0164] The following cardinality rules apply to edge application servers: a) One or more EASs can reside in an EDN. One or more EASs belonging to the same EAS ID can be provided by multiple ECSPs in the EDN.

[0165] The Edge Enabled Server ID (EESID) is the FQDN of the Edge Enabled Server, and each Edge Enabled Server ID is unique within the PLMN domain.

[0166] The Edge Application Server ID (EASID) identifies a specific application, such as SA6Video, SA6Game, etc. For example, all edge SA6Video servers will share the same Edge Application Server ID. The format of the EAS ID is beyond the scope of this specification. Table E28.2.4-1 shows the Edge Application Server profile.

[0167] Table E28.2.4-1: Edge Application Server Profile Edge application server service KPIs provide information about the service characteristics offered by the edge application server (see, for example, Table E28.2.5-1). Table E28.2.5-1: Edge Application Server Service KPIs The Edge Enabled Server profile includes information about EES and the services it provides (for example, see Table E28.2.6-1).

[0168] E28.2.6-1: Edge Enabler Server Profile The network capability exposure for one or more edge application servers depends on the deployment scenario and the business relationship between the ASP / ECSP and the PLMN operator. The following mechanisms are supported: direct network capability exposure and / or network capability exposure via edge-enabled servers.

[0169] In some implementations, the network capability exposure for one or more EASs depends on the deployment scenario and the business relationship between the ASP / ECSP and the PLMN operator. Mechanisms supported include direct network capability exposure and / or network capability exposure via an edge-enabled server. In some implementations, billing features with different deployment options depending on the business relationship between the edge application service provider, the edge computing service provider, and the SFC service provider are outside the scope of this disclosure.

[0170] Edge-9 reference points support interaction between two edge-enabled servers. Figure 16 The different EDNs shown Figure 17 EDGE-9 reference points are provided between EES within the same EDN.

[0171] Figure 18This diagram illustrates the roles and relationships of service providers involved in the deployment of edge computing services. Application Service Providers (ASPs) are responsible for creating Edge Application Servers (EAS) and Application Clients (ACs). Edge Computing Service Providers (ECSPs) are responsible for deploying the Edge Data Network (EDN) containing the EAS and the Edge Enabled Server (EES) that provides configuration information to Edge Enabled Clients (EECs), enabling the ACs to exchange application data traffic with the EAS. Public Land Mobile Network (PLMN) operators are responsible for deploying 5G network functions such as 5GC and 5G NR.

[0172] End users are consumers of applications / services provided by ASPs and can enter into ASP service agreements with one or more application service providers. End users have PLMN subscription agreements with PLMN operators. UEs used by end users are allowed to register on the PLMN operator's network. ASPs use edge services (e.g., infrastructure, platforms, etc.) provided by edge computing service providers (ECSPs) and can enter into ECSP service agreements with one or more ECSPs. ECSPs can be mobile network operators or third-party service providers offering edge computing services. A single PLMN operator can enter into PLMN operator service agreements with one or more edge computing service providers. A single ECSP can enter into PLMN operator service agreements with one or more PLMN operators providing edge computing support. ECSPs and PLMN operators can be part of the same organization or different organizations.

[0173] The following discussion provides specific examples related to edge computing configurations provided in multi-access edge computing (MEC) and 5G network implementations. However, many other standards and network implementations are applicable to the edge and service management concepts discussed herein. For example, the embodiments discussed herein can be applied to many other edge computing / networking technologies in various combinations and layouts of devices located at the network edge. Examples of such other edge computing / networking technologies that can implement the embodiments of this document include content delivery networks (CDNs) (also known as “content distribution networks”, etc.); mobile service provider (MSP) edge computing and / or mobile-as-a-service (MaaS) provider systems (e.g., for AECC architectures); nebula edge cloud systems; fog computing systems; cloudlet edge cloud systems; mobile cloud computing (MCC) systems; central offices redesigned as data center (CORD), mobile CORD (M-CORD), and / or aggregated multi-access core (COMAC) systems, etc. Furthermore, the technologies disclosed herein can relate to other IoT edge network systems and configurations, and other intermediate processing entities and architectures can also be used to implement the embodiments of this document.

[0174] Figure 19The diagram illustrates a 5G service-based architecture and MEC architecture that can be deployed in an example edge computing system, as well as an integrated MEC deployment that can be used in a 5G network for the example edge computing system.

[0175] Figure 19 The diagram illustrates a non-integrated MEC deployment 19A including a 5G service-based architecture 1900 and an MEC architecture 1990, and an integrated MEC deployment 19B including an MEC system 1991 within a 5G network 1901, wherein some functional entities of the MEC system 1991 interact with the NF of the 5G network. Referring to deployment 19A, the 5G system architecture 1900 is shown in a service-based representation and includes... Figure 10 Various elements are identical or similar. For example, 5G system architecture 1900 includes the following entities that also appear in system architecture 1900: NSSF 1916, PCF 1922, UDM 1924, AF 1926, AUSF 1910, AMF 1912, SMF 1914, UE 1902, RAN 1904, UPF 1906, and DN 1908. In addition to these network entities, 5G system architecture 2800 also includes Network Open Function (NEF) 1918 and Network Repository Function (NRF) 1920. 5G system architecture can be service-based, and interactions between NFs can be represented by corresponding point-to-point reference points Ni or SBIs (e.g., ...). Figure 19 (As shown).

[0176] Figure 19 The 5G System 1900 is a service-based representation used to represent NFs in a CP that enable other authorized NFs to access its services. The 5G System 1900 includes the following service-based interfaces (SBIs): Namf (SBI shown in AMF1912), Nsmf (SBI shown in SMF 1914), Nnef (SBI shown in NEF1918), Npcf (SBI shown in PCF1922), Nudm (SBI shown in UDM1924), Naf (SBI shown in AF1926), Nnrf (SBI shown in NRF 1920), Nnssf (SBI shown in NSSF1916), and Nausf (SBI shown in AUSF 1910). It can also use... Figure 19 Other SBIs not shown in the table (e.g., Nudr, N5g eir, and Nudsf).

[0177] The NEF 1918 provides a means for securely exposing the services and functions offered by 3GPP NFs to third parties, internal open / reopen AF 1964, edge computing, or fog computing systems. The NEF 1918 can authenticate, authorize, and / or restrict AF 1964. The NEF 1918 can also translate information exchanged with AF 1964 and information exchanged with internal NFs. The NEF 1918 can also receive information from other NFs based on their open capabilities. This information can be stored as structured data at the NEF 1918 or stored at a data storage device NF using a standardized interface. The stored information can then be reopened by the NEF 1918 to other NFs and AFs, and / or used for other purposes such as analysis. In this example, the NEF 1918 provides an interface to the MEC host in MEC systems 1990 and 1991, which can be used to handle radio connections with RAN 1904.

[0178] The NRF 1920 supports service discovery, receiving NF discovery requests from NF instances or SCP 1928 and providing information on discovered (or to be discovered) NF instances to the NF instances or SCP 1928. The NRF 1920 maintains NF profiles of available NF instances and their supported services (e.g., NF instance ID, NF type, PLMN ID, NF's FQDN or IP address, NF capacity information, NF priority information, etc.). SCP 1928 (or individual instances of SCP 1928) supports indirect communication between two or more NFs; delegated discovery; message forwarding and routing to destination NF / NF services; communication security (e.g., authorizing NF service users to access NF service producer APIs); load balancing; monitoring; overload control; and discovery and selection functions for UDM, AUSF, UDR, and PCF (based on UE SUPI, SUCI, or GPSI access to subscription data stored in the UDR). The load balancing, monitoring, and overload control functions provided by SCP 1928 may be implementation-specific. SCP 1928 can be deployed in a distributed manner. There can be more than one SCP 1928 in the communication paths between various NF services. Although SCP 1928 is not an NF instance, it can be deployed in a distributed, redundant, and scalable manner.

[0179] The MEC system 1990 may include an MEC orchestrator 1970 (operating at the system level) and the following MEC entities operating at the distributed host level: one or more applications 1972, one or more services 1974, virtualization infrastructure 1976, MEC platform 1978, and MEC platform manager 1980. The components of the MEC system 1990 will be discussed in detail below.

[0180] Integrated MEC deployment 19B includes the same MEC and 5GC NF as the non-integrated deployment 19A discussed earlier. In this embodiment, integrated MEC deployment 19B is at least partially located within 5G network 1901. 5G network 1901 is the same as or similar to 5G system 1900; however, not all NFs in 5G network 1901 are shown. Integrated MEC deployment 19B can be configured using one or more of the following techniques: (1) local routing and traffic routing; (2) the ability of AF 1926 to influence UPF 1906 (re)select and route traffic directly via PCF 1922 or indirectly via NEF 1918, depending on the operator's policy; (3) Session and Service Continuity (SSC) modes for UE 1902 and application mobility scenarios; (4) support for Local Area Data Network (LADN) 1908 in 5G network 1901 by supporting connections to LADN 1908 in specific areas where application 1972 is deployed. Access to LADN 1908 can be available in a specific LADN service area, defined as a set of tracking areas within the UE's serving PLMN. LADN 1908 can be configured to be served by the UE's serving PLMN. For local routing and traffic steering, the 5G network 1901 can be configured to select traffic for application 1972 to be routed to LADN 1908, which can be part of the MEC system 1991. A PDU session can have multiple N6 interfaces pointing to the data network 1908. The UPF 1906, terminating these interfaces, can be configured to support PDU session anchoring functionality. Traffic steering of the UPF 1906 is supported by a UL classifier that operates on a set of traffic filters matching the steering traffic, or by IPv6 multihoming, where multiple IPv6 prefixes are already associated with the PDU session in question.

[0181] In 5G networks 1901, NFs and their generated services are registered in NRF 1920, while in MEC systems 1991, services generated by MEC applications 1972 are registered in the service registry of MEC platform 1978. Service registration can be part of application-enabled functionality. To use a service (if authorized), an NF can interact directly with the NF that generated the service. A list of available MEC services can be found in NRF 1920. Some services can be accessed through NEF 1918, which can also be used for untrusted entities outside the domain to access services. In other words, NEF 1918 can serve as a service openness central point and plays a crucial role in authorizing all access requests from outside the system. Authentication-related processes can be provided by AUSF 1910.

[0182] The 5G network 1901 can utilize network slicing, which allows the allocation of required functions and resources from available network slices (NFs) to different services or tenants using those services. The Network Slice Selection Function (NSSF) 1916 can be configured to assist in selecting appropriate network slice instances for users and to assist in allocating the necessary Active Cloud Components (AMFs) 1912. MEC applications 1972 (e.g., applications hosted in a distributed cloud within the MEC system 1990) can belong to one or more network slices already configured in the 5G network 1901.

[0183] PCF 1922 is also the function of AF 1926 (e.g., MEC Platform 1978) requesting its services to influence traffic steering rules. PCF 1922 can be accessed directly or via NEF 1918, depending on whether AF 1926 is considered trusted, and in the case of traffic steering, depending on whether the corresponding PDU session is known at the time of the request. UDM 1924 is responsible for services related to users and subscriptions. For example, UDM 1924 can be configured to generate 3GPP Authentication and Key Protocol (AKA) authentication credentials, process user identification information, manage access authorization (e.g., roaming restrictions), register users serving NF (serving AMF 1912, SMF 1914), support service continuity by recording SMF / DNN assignments, support interception processes during outbound roaming by acting as a contact point, and perform subscription management processes.

[0184] UPF 1906 can be configured to assist in integrated MEC deployment in a 5G network 1901. From the perspective of MEC system 1991, UPF 1906 can be viewed as a distributed, configurable data plane. The control of this data plane (e.g., in traffic rule configuration) can follow NEF-PCF-SMF communication routes. Therefore, as shown in deployment 19B, a local UPF 1906 can be part of an MEC implementation.

[0185] The MEC orchestrator 1970 in Deployment 19B is a system-level functional entity for the MEC, acting as an AF (Automatic Front-End) that can interact with the NEF 1918 or, in some cases, directly with the target 5G NF (Network Provider). At the Distributed Host Level (or “MEC Host Level”), the MEC Platform 1978 can be configured to interact with the 5G NF, also in the role of AF 1926. MEC hosts (e.g., Figure 20 MEC host 2002 and / or other host-level functional entities can be deployed in the data network of a 5G system (e.g., 1908). Although NEF 1918, as a 5GC NF, is a system-level entity centrally deployed with similar NFs, instances of NEF 1918 can also be deployed at the edge to allow low-latency, high-throughput service access from MEC hosts.

[0186] In Deployment 19B, MEC System 1991 is deployed on the N6 reference point of UPF 1906, which can be located in the data network 1908 outside of 5G System 1901. This functionality can be achieved through flexible positioning of UPF 1906. In addition to MEC Application 1972, the distributed MEC host can accommodate a message broker as MEC Platform Service 1974, as well as another MEC Platform Service that directs traffic to a local accelerator. The choice of running a service as an MEC Application or Platform Service can be implementation-specific, taking into account the level of sharing and authentication required to access the service. MEC services such as message brokers can initially be deployed as MEC Application 1972 and then provided as MEC Platform Service 1974.

[0187] The MEC host of MEC system 1991 is deployed in the edge or central data network. UPF 1906 can be configured to manage the routing of UP traffic to the target MEC application 1972 in DN 1908. The location of DN 1908 and UPF 1906 is a choice made by the network operator based on technical and business parameters such as available site facilities, supported applications and their requirements, measured or estimated user load, etc. The MEC management system (orchestrates the operation of MEC hosts and applications) can dynamically determine where to deploy MEC applications 1972. Regarding the physical deployment of MEC hosts, the following options can be used in different aspects: (1) the MEC host and the local UPF 1906 are in the same location as the base station at the base station edge layer; (2) the MEC host is in the same location as the transmission node that may include the local UPF 1906; (3) the MEC host and the local UPF 1906 are in the same location as the network aggregation point; and (4) the MEC host is in the same location as the 5G core NF (e.g., in the same data center).

[0188] Figure 20 An example MEC system reference architecture is shown. Figure 20The diagram illustrates a functional MEC system reference architecture (or MEC architecture) 2000. MEC provides cloud computing capabilities and an IT service environment for application developers and content providers at the network edge. This environment is characterized by ultra-low latency and high bandwidth, as well as real-time access to radio network information that applications can utilize. MEC technology allows for the flexible and rapid deployment of innovative applications and services to mobile users, enterprises, and vertical market segments. Specifically, regarding the automotive industry, applications such as V2X (e.g., protocols based on IEEE 802.11p, such as DSRC / ITS-G5 or protocols based on 3GPP C-V2X) require exchanging data, providing data to aggregation points, and accessing data in databases that provide an overview of local conditions derived from multiple sensors (by various vehicles, roadside units, etc.).

[0189] The MEC architecture 2000 includes an MEC host 2002, a Virtualization Infrastructure Manager (VIM) 2008, an MEC Platform Manager 2006, an MEC Orchestrator 2010, an Operation Support System (OSS) 2012, a User Application Agent 2014, a UE application 2018 running on the UE 2020, and a CFS ingress 2016. The MEC host 2002 may include an MEC platform 2032 with a filtering rule control component 2040, a Domain Name System (DNS) processing component 2042, a service registry 2038, and MEC services 2036. MEC services 2036 may include at least one scheduler that can be used to select resources for instantiating MEC applications (or NFV) 2026 on the Virtualization Infrastructure (VI) 2022. MEC applications 2026 may be configured to provide services 2030, which may include handling different types of network communication traffic associated with one or more radio connections (e.g., connections to one or more RAN or core network functions) and / or some other services discussed herein. Another MEC host 2002 may have the same or similar configuration / implementation as MEC host 2002, and another MEC application 2026 instantiated within another MEC host 2002 may be similar to MEC application 2026 instantiated within MEC host 2002. VI 2022 includes a data plane 2024 coupled to MEC platform 2022 via the MP2 interface. Other interfaces between various network entities of MEC architecture 2000 include... Figure 20 As shown.

[0190] The MEC system 2000 includes three sets of reference points: an "Mp" reference point concerning MEC platform functionality, an "Mm" reference point serving as a management reference point, and an "Mx" reference point connecting MEC entities to external entities. Interfaces / reference points in the MEC system 2000 may include IP-based connections and can be used to provide representative state transmission (REST or RESTful) services. Messages transmitted using reference points / interfaces may be in XML, HTML, JSON, or, for example, some other desired formats discussed herein. In other embodiments, appropriate authentication, authorization, and accounting (AAA) protocols, such as RADIUS or DIAMETER protocols, may also be used for communication via reference points / interfaces.

[0191] The logical connections between various entities in the MEC architecture 2000 may be access-independent and may not depend on a specific deployment. MEC supports implementing MEC Application 2026 as a pure software entity running on VI 2022, which is located at or near the network edge. MEC Application 2026 is an application that can be instantiated on MEC Host 2002 within the MEC system 2000 and can potentially provide or use MEC Service 2036.

[0192] Figure 20 The MEC entities shown can be categorized into MEC system-level entities, MEC host-level entities, and network-level entities (not shown). Network-level entities (not shown) include various external network-level entities, such as 3GPP networks, local area networks (e.g., LAN, WLAN, PAN, DN, LADN, etc.), and external networks. MEC system-level entities include MEC system-level management entities and UE 2020, and are described in more detail below. MEC host-level entities include one or more MEC hosts 2002, 2004, and MEC management entities, which provide the functionality to run MEC application 2026 on or within a subset of the operator network. The MEC management entity includes various components that manage the MEC-specific functions of a specific MEC platform 2032, MEC host 2002, and the MEC application 2026 to be run.

[0193] MEC Platform Manager 2006 is the MEC management entity, including MEC platform component management component 2044, MEC application rules and requirements management component 2046, and MEC application lifecycle management component 2048. Remote application 2050 is configured to communicate with MEC host 2002 (e.g., with MEC application 2026) via MEC orchestrator 2010 and MEC Platform Manager 2006.

[0194] MEC host 2002 is an entity that includes MEC platform 2032 and VI 2022. VI 2022 provides compute, storage, and network resources for running MEC application 2026. VI 2022 includes a data plane (DP) 2024 that enforces traffic rules 2040 received by MEC platform 2032 and routes traffic between MEC application 2026, MEC service 2036, DNS server / agent (e.g., via DNS processing entity 2042), 3GPP network, local network, and external network. MEC DP 2024 can connect to (R)AN nodes and 3GPP core networks, and / or can connect to access points via wider networks (e.g., the Internet, enterprise networks, etc.).

[0195] MEC Platform 2032 is a set of essential functionalities required to run MEC applications 2026 on a specific VI 2022 and enable them to provide and use MEC services 2036, providing itself with a large number of MEC services 937a. MEC Platform 2032 may also provide various services and / or functions, such as providing an environment where MEC applications 2026 can discover, advertise, use, and provide MEC services 2036 (including MEC services 2036 provided via other platforms when supported). MEC Platform 2032 may allow authorized MEC applications 2026 to communicate with third-party servers located on an external network. MEC Platform 2032 may receive traffic rules from MEC Platform Manager 2006, applications, or services and accordingly instruct the data plane (e.g., see Traffic Rule Control 2040). MEC Platform 2032 may send instructions to DP 2024 within VI 2022 via an MP2 reference point. The MP2 reference point between DP 2024 of MEC Platform 2032 and VI 2022 can be used to instruct DP 2034 how to route traffic between applications, networks, services, etc. MEC Platform 2032 can translate individual flows within a session, representing UE 2020, UE applications, tokens for individual sessions, and / or traffic rules, into specific IP addresses. MEC Platform 2032 also receives DNS records from MEC Platform Manager 2006 and configures DNS proxies / servers accordingly. MEC Platform 2032 hosts MEC services 2036 (including the multi-access edge services discussed below) and provides access to persistent storage and time information. Furthermore, MEC Platform 2032 can communicate with other MEC Platforms 2032 of other MEC Servers 2002 via the MP3 reference point. When an update, activation, or deactivation of a traffic rule is received from MEC Platform Manager 2006, an application, or a service, MEC Platform 2032 instructs Data Plane 2024 accordingly. The MEC platform 2032 also receives DNS records from the MEC platform manager 2006 and uses them to configure the DNS proxy / server 2042. Traffic rule control 2040 allows the MEC platform 2032 to perform traffic routing (including traffic rule updates, activation, and deactivation). In some embodiments, traffic rule control 2040 allows the MEC platform 2032 to perform traffic control, for example, by routing data packets over one or more access network connections in a multi-access environment comprising multiple access networks, wherein each access network may have multiple access network connections and / or may implement different access technologies.

[0196] VI 2022 represents the sum of all hardware and / or software components that constitute the deployment, management, and execution of MEC Application 2026 and / or MEC Platform 2032. VI 2022 can span multiple locations, and the network providing connectivity between these locations is considered part of VI 2022. The physical hardware resources of VI 2022 include compute, storage, and network resources that provide processing, storage, and connectivity to MEC Application 2026 and / or MEC Platform 2032 through virtualization layers (e.g., hypervisors, VM monitors (VMMs), etc.). The virtualization layer can abstract and / or logically partition the physical hardware resources of MEC Server 2002 into a hardware abstraction layer. The virtualization layer also enables the software implementing MEC Application 2026 and / or MEC Platform 2032 to use the underlying VI 2022 and can provide virtualized resources to MEC Application 2026 and / or MEC Platform 2032 for execution.

[0197] MEC Application 2026 is an application that can be instantiated on MEC Host / Server 2002 within MEC System 2000 and may provide or use MEC Service 2036. The term "MEC Service" refers to a service provided by MEC Platform 2032 itself or by MEC Application 2026 through MEC Platform 2032. MEC Application 2026 can run as a VM on VI 2022 provided by MEC Server 2002 and can interact with MEC Platform 2032 to use and provide MEC Service 2036. The Mp1 reference point between MEC Platform 2032 and MEC Application 2026 is used to use and provide service-specific functionality. Mp1 provides service registration 2038, service discovery, and communication support for various services, such as MEC Service 2036 provided by MEC Host 2002. Mp1 may also provide application availability, session state relocation support, traffic and DNS rule activation, access to persistent storage, and time information, etc. Alternatively, MEC Application 2026 can use the MEC API to communicate with MEC Platform 2032.

[0198] MEC Application 2026 is instantiated on VI 2022 of MEC Server 2002 based on configurations or requests validated by MEC management (e.g., MEC Platform Manager 2006). MEC Application 2026 can also interact with MEC Platform 2032 to perform certain support procedures related to the lifecycle of MEC Application 2026, such as indicating availability, preparing for user state relocation, etc. MEC Application 2026 may have a number of associated rules and requirements, such as required resources, maximum latency, required or useful services, etc. MEC management can validate these requirements and specify default values ​​if they are missing. MEC Service 2036 is a service provided and / or used by MEC Platform 2032 and / or MEC Application 2026. Service consumers (e.g., MEC Application 2026 and / or MEC Platform 2032) can communicate with specific MEC Service 2036 through separate APIs, including the MEC V2X API and other MEC APIs discussed herein. When provided by an application, MEC service 2036 can be registered in the service registry 2038 on the MEC platform 2032 via the Mp1 reference point. Furthermore, MEC application 2026 can subscribe to one or more services 2030 / 2036, which are authorized via the Mp1 reference point.

[0199] Examples of MEC services 2036 include V2X Information Service (VIS), RNIS, Location Service, UE Identity Service, WLAN Access Information (WAI) Service, Fixed Access Information (FAI) Service, and / or other MEC services. RNIS (when available) provides radio network-related information to authorized MEC applications 2026 and exposes appropriate, up-to-date radio network information to MEC applications 2026. RNI may include radio network status, measurements, and statistics related to UP, information related to UE 2020 served by one or more radio nodes associated with MEC host 2002 (e.g., UE context and radio access bearer), changes in information related to UE 2020 served by radio nodes associated with MEC host, etc. RNI can be provided at a relevant granularity (e.g., per UE 2020, per cell, per time period).

[0200] Service users (e.g., MEC Application 2026, MEC Platform 2032, etc.) can communicate with RNIS via the RNI API to obtain context information from the corresponding RAN. The RNI can be provided to service users via NANs (e.g., (R)AN nodes, RRHs, APs, etc.). The RNI API supports query-based and subscription-based (e.g., publish / subscribe) mechanisms, which can be used through a representative state transfer (RESTful) API or a message relay on the MEC Platform 2032 (not shown). MEC Application 2026 can query information on the message relay via a transfer information query process, where the transfer information can be pre-provisioned to MEC Application 2026 via an appropriate configuration mechanism. Messages transmitted via the RNI API can be in XML, JSON, Protobuf, or some other suitable format.

[0201] VIS supports various V2X applications, including trip-aware QoS prediction. MEC Application 2026 and MEC Platform 2032 can use RNI to optimize existing services and provide new services based on up-to-date information about radio conditions. For example, MEC Application 2026 can use RNI to optimize current services (e.g., video throughput guidance). In throughput guidance, the radio analytics MEC Application 2026 can use MEC services to provide the backend video server with a near real-time indication of the estimated throughput available at the radio DL interface at the next moment. The throughput guidance radio analytics application calculates the throughput guidance based on the required radio network information obtained from the multi-access edge service running on MEC Server 2002. MEC Platform 2032 can also use RNI to optimize mobility procedures required to support service continuity, for example, when one MEC Application 2026 requests a single piece of information using a simple request-response model (e.g., using a RESTful mechanism), while other MEC Applications 2026 subscribe to multiple different notifications about changes to that information (e.g., using publish / subscribe mechanisms and / or message relay mechanisms).

[0202] When available, LS can provide location-related information to authorized MEC applications 2026 and expose such information to MEC applications 2026. MEC platform 2032 or one or more MEC applications 2026 can use the location-related information to perform effective device location tracking, location-based service recommendations, and / or other similar services. LS supports location retrieval mechanisms, such as reporting the location only once for each location information request. LS supports location subscription mechanisms, such as reporting the location multiple times periodically or based on specific events (e.g., location changes) for each location request. Location information may include the location of a specific UE 2020 currently served by radio nodes associated with MEC server 2002, information about the locations of all UE 2020s currently served by radio nodes associated with MEC server 2036, information about the locations of a specific category of UE 2020s currently served by radio nodes associated with MEC server 2036, a list of UE 2020s in a specific location, information about the locations of all radio nodes currently associated with MEC host 2002, etc. Location information can take the form of geographic location, Global Navigation Satellite Service (GNSS) coordinates, cell identifier (ID), etc. The LS can be accessed via the API defined in the Open Mobile Alliance (OMA) specification "Zonal Presence RESTful Network API" OMA-TS-REST-NetAPI-ZonalPresence-V1-0-20160308-C. The Zonal Presence service utilizes the concept of a "zone," where a zone is suitable for grouping all radio nodes or subsets thereof associated with the MEC host 2002 according to the desired deployment. In this regard, the OMA Zonal Presence API provides MEC application 2026 with a means to retrieve information about zones, access points associated with zones, and users connected to access points. Furthermore, the OMA Zonal Presence API allows authorized applications to subscribe to notification mechanisms that report user activity within a zone. The MEC server 2002 can use the OMA Zonal Presence API to access the location information or zonal presence information of individual UEs 2020 to identify the relative location or orientation of the UEs 2020.

[0203] BWMS allocates bandwidth for specific traffic routed to and from MEC application 2026, and specifies static / dynamic bandwidth resources (including bandwidth size and priority). MEC application 2026 can use BWMS to update / receive bandwidth information from MEC platform 2032. Different MEC applications 2026 running in parallel on the same MEC server 2002 can be allocated specific static and dynamic bandwidth resources (including bandwidth size and priority). BWMS includes a Bandwidth Management (BWM) API to allow registered applications to statically and / or dynamically register specific bandwidth allocations for each session / application. The BWM API includes an HTTP protocol binding for BWM functionality using a RESTful service or some other suitable API mechanism. The BWM service is used to allocate / adjust BW resources for MEC applications and allows MEC applications to provide their BW requirements.

[0204] Different MEC applications running in parallel on the same MEC host may require specific static / dynamic up / down bandwidth (BW) resources (including BW size and BW priority). In some cases, different sessions running in parallel on the same application may each have specific BW requirements. Furthermore, sessions driven by applications closer to the end user (e.g., shorter RTT) may have an unfair advantage over sessions driven by applications running at more distant locations (e.g., outside the RAN). To address such potential resource conflicts between competing applications, BWM and / or Multi-Access Flow Control (MTS) services can be used.

[0205] The MTS service can be provided as part of the BWMS or separately. The MTS service is used for seamless control / splitting / replication of application data traffic across multiple access network connections. The MTS service allows applications / MEC applications to understand various MTS functions and MX network connection information. The MTS also allows MEC applications to provide requirements that affect traffic management operations (e.g., latency, throughput, loss, etc.). A specific session or application / MEC application can be identified using a set of filters and / or identifiers (IDs) within the resource request.

[0206] The purpose of UE identity features is to enable UE-specific traffic rules in the MEC system 2000. When the MEC system 2000 supports UE identity features, the MEC platform 2032 provides this functionality (e.g., the UE identity API) for MEC applications 2026 to register tags representing UE 2020 or lists of tags representing each UE 2020. Each tag is mapped to a specific UE 2020 in the MNO system, and the MEC platform 2032 provides this mapping information. UE identity tag registration triggers the MEC platform 2032 to activate the corresponding traffic rule 2040 linked to the tag. The MEC platform 2032 also provides this functionality (e.g., the UE identity API) for MEC applications 2026 to invoke a deregistration procedure to disable or otherwise stop using the user's traffic rules.

[0207] WAIS is a service that provides WLAN access information to service users within an MEC system 2000. WAIS can be used with licensed MEC applications 2026 and is discoverable via an MP1 reference point. The granularity of WLAN access information can be adjusted based on parameters such as per station, per NAN / AP, or per multiple APs (multi-AP). Service users can use WLAN access information to optimize existing services and provide new types of services based on the latest information from WLAN APs (which may be combined with information such as RNI or fixed access network information). WAIS defines protocols, data models, and interfaces in the form of a RESTful API. Information about APs and client stations can be requested by querying or subscribing to notifications, each notification including attribute-based filtering and attribute selectors.

[0208] FAIS is a service that provides fixed access network information (or FAI) to service users within the MEC system 2000. FAIS can be used by authorized MEC applications 2026 and can be discovered via the MP1 reference point. FAI can be used by MEC applications 2026 and MEC platform 2032 to optimize existing services and provide new services based on up-to-date information from fixed access (e.g., NAN), which may be combined with other information from other access technologies (e.g., RNI or WLAN information). Service users interact with FAI via the FAI API to obtain context information from the fixed access network. Both MEC applications 2026 and MEC platform 2032 can use FAIS; both MEC platform 2032 and MEC applications 2026 can be FAI providers. The FAI API supports querying and subscription (publish / subscribe mechanism) via RESTful API or other transport methods (e.g., message bus). Alternative transport tools can also be used.

[0209] MEC management includes MEC system-level management and MEC host-level management. MEC management includes MEC Platform Manager 2006 and VI Manager (VIM) 2008, and handles the management of MEC-specific functions for a particular MEC server 2002 and the applications running on it. In some implementations, some or all of the multi-access edge management components may be implemented by one or more servers located in one or more data centers, and may use virtualization infrastructure connected to the NFV infrastructure used for virtualization, or use the same hardware as the NFV infrastructure.

[0210] The MEC Platform Manager 2006 manages the application lifecycle, including notifying the MEC Orchestrator (MEC-O) 2010 of relevant application events. The MEC Platform Manager 2006 also provides MEC platform element management functionality 2044 to the MEC Platform 2032, manages MEC application rules and requirements 2046 (including service authorization, traffic rules, DNS configuration, and conflict resolution), and manages MEC application lifecycle management 2048. The MEC Platform Manager 2006 can also receive virtualization resources, fault reports, and performance measurement results from VIM 2008 for further processing. The Mm5 reference point between the MEC Platform Manager 2006 and the MEC Platform 2032 is used for platform configuration, configuration of the MEC platform element management functionality 2044, MEC application rules and requirements 2046, MEC application lifecycle management 2048, and application relocation management.

[0211] VIM 2008 can be an entity that allocates, manages, and publishes virtualized (compute, storage, and networking) resources for VI 2022 and prepares the VI 2022 runtime software image. To this end, VIM 2008 can communicate with VI 2022 via the Mm7 reference point between VIM 2008 and VI 2022. Preparing VI 2022 may include configuring VI 2022 and receiving / storing the software image. Where supported, VIM 2008 can provide rapid application configuration, as described in "Openstack++ for Cloudlet Deployments". VIM 2008 can also collect and report performance and failure information about virtualized resources and perform application relocation when supported. For application relocation from / to external cloud environments, VIM 2008 can interact with an external cloud manager to perform application relocation (e.g., using the mechanisms described in "Adaptive VM Handoff Across Cloudlets" and / or via an agent). Furthermore, VIM 2008 can communicate with MEC Platform Manager 2006 via the Mm6 reference point, which can be used to manage virtualization resources, such as for application lifecycle management. Additionally, VIM 2008 can communicate with MEC-O 2010 via the Mm4 reference point, which can be used to manage the virtualization resources of MEC Server 2002 and manage application images. Managing virtualization resources may include tracking available resource capacity, etc.

[0212] MEC system-level management includes MEC-O 2010, which provides an overview of the complete MEC system 2000. MEC-O 2010 maintains an overall view of the MEC system 2000 based on deployed MEC hosts 2002, available resources, available MEC services 2036, and topology. The Mm3 reference point between MEC-O 2010 and the MEC Platform Manager 2006 can be used for application lifecycle, application rules, and requirements management, and to track available MEC services 2036. MEC-O 2010 can communicate with the User Application Lifecycle Management Agent (UALMP) 2014 via the Mm9 reference point to manage MEC applications 2026 requested by UE applications 2018.

[0213] MEC-O 2010 can also handle application package installation, including checking the integrity and authenticity of application packages, verifying application rules and requirements, adjusting them as necessary to comply with operator policies, maintaining records of application package installation, and preparing VIM 2008 for application processing. MEC-O 2010 can select the appropriate MEC host 901 for application instantiation based on constraints such as latency, available resources, and available services. MEC-O 2010 can also trigger application instantiation and termination, and trigger application relocation when needed and supported.

[0214] The Operations Support System (OSS) 2012 is the operator's OSS, which receives requests from UE applications 2018 via the Customer-Facing Service (CFS) entry point 2016 through the Mx1 reference point to instantiate or terminate MEC applications 2026. OSS 2012 determines the approval of these requests. Third parties can use the CFS entry point 2016 (and the Mx1 interface) to request MEC system 2000 to run application 2018 within MEC system 2000. Approved requests can be forwarded to MEC-O 2010 for further processing. Where supported, OSS 2012 also receives requests from UE applications 2018 to relocate applications between an external cloud and MEC system 2000. The Mm2 reference point between OSS 2012 and MEC Platform Manager 2006 is used for MEC Platform Manager 2006 configuration, fault, and performance management. The Mm1 reference point between MEC-O 2010 and OSS 2012 is used to trigger the instantiation and termination of MEC application 2026 in MEC system 2000.

[0215] UE Application 2018 (also referred to as "Device Application," etc.) is one or more applications running on Device 2020, which has the ability to interact with MEC System 2000 through User Application Lifecycle Management Agent 2014. UE Application 2018 may be or include one or more client applications, or may interact with one or more client applications. In the context of MEC, these UE applications are applications running on Device 2018 that utilize the functionality provided by one or more specific MEC Application 2026. User Application Lifecycle Management (LCM) Agent 2014 can authorize requests from UE Application 2018 in UE 2020 and interact with OSS 2012 and MEC-O 2010 to further process these requests. In the MEC context, the term "lifecycle management" refers to the set of functions required to manage the instantiation, maintenance, and termination of MEC Application 2026 instances. User application LCM agent 2014 interacts with OSS 2012 via the Mm8 reference point and is used to process UE 2018 requests for applications running in MEC system 2000. The user application can be MEC application 2026 instantiated in MEC system 2000 in response to user requests from applications running in UE 2020 (e.g., UE application 2018). User application LCM agent 2014 allows UE application 2018 to request login, instantiation, and termination of the user application, and, where supported, relocates the user application within and outside MEC system 2000. It also allows notification of the user application's status to the user application. User application LCM agent 2014 can only be accessed from within the mobile network and is only available if supported by MEC system 2000. UE Application 2018 can use the Mx2 reference point between User Application LCM Agent 2014 and UE Application 2018 to request MEC System 2000 to run the application in MEC System 2000 or to move the application in or out of MEC System 2000. The Mx2 reference point can only be accessed in the mobile network and is only available if supported by MEC System 2000.

[0216] To run MEC application 2026 in MEC system 2000, MEC-O 2010 receives requests triggered by OSS 2012, third parties, or UE application 2018. In response to these requests, MEC-O 2010 selects MEC server / host 2002 to host MEC application 2026 for compute offloading, etc. These requests may include information about the application to be run, as well as other possible information (e.g., the location where the application needs to be activated, other application rules and requirements, and the location of the application image (if it is not already installed in MEC system 2000)).

[0217] MEC-O 2010 can select one or more MEC servers 2002 for compute-intensive tasks. The selected one or more MEC servers can offload the compute tasks of UE application 2018 based on various operating parameters (e.g., network capabilities and conditions, compute capabilities and conditions, application requirements, and / or other similar operating parameters). Application requirements can be rules and requirements associated with one or more MEC Application 2026s, such as: application deployment model (e.g., whether it is one instance per user, one instance per host, one instance on each host, etc.); required virtualization resources (e.g., compute, storage, network resources, including specific hardware support); latency requirements (e.g., maximum latency, the strictness of latency limits, latency fairness among users); location requirements; multi-access edge services required and / or useful for MEC Application 2026 operation; multi-access edge services that MEC Application 2026 can utilize (if available); connectivity or mobility support / requirements (e.g., application state relocation, application instance relocation); required multi-access edge functions, such as VM relocation support or UE identification; required network connectivity (e.g., connecting to applications within the MEC System 2000, connecting to a local network or the Internet); information about the operator's MEC System 2000 deployment or mobile network deployment (e.g., topology, cost); requirements for accessing user traffic; requirements for persistent storage; traffic rule 2040; DNS rule 2042, etc.

[0218] MEC-O 2010 takes into account the above requirements and information, as well as information on currently available resources in the MEC system 2000, to select one or more MEC servers 2002 to host MEC application 2026 and / or for compute offloading. After selecting one or more MEC servers 2002, MEC-O 2010 requests the selected MEC host 2002 to instantiate one or more applications or application tasks. The actual algorithm used to select the MEC server 2002 depends on the implementation, configuration, and / or operator deployment. The selection algorithm may be based on task offloading criteria / parameters, such as considering the network, compute, and energy consumption requirements for performing the application task, as well as network functions, processing, and offloading encoding / coding or distinguishing traffic between different RATs. In some cases (e.g., UE mobility events that cause increased latency, load balancing decisions, etc.), and if supported, MEC-O 2010 may decide to select one or more new MEC host 2002s as master nodes and initiate the transfer of application instances or application-related status information from one or more source MEC host 2002s to one or more target MEC host 2002s.

[0219] In the first implementation, the 5GS UPF is mapped to the MEC architecture 2000 as the MEC data plane 2024. In these implementations, UPF 2006 handles the UP path for PDU sessions. Furthermore, the UPF provides an interface to the data network (e.g., DN 1036) and supports PDU session anchoring functionality.

[0220] In the second implementation, the AF of the 5GS is mapped to the MEC architecture 2000, which serves as the MEC platform 2032. In these implementations, the AF can be configured or operated to exert application effects on traffic routing, access network capabilities, and interact with the policy framework for policy control. The second implementation can be combined with the first implementation or can be a standalone implementation. In the first and / or second implementations, since user traffic is routed to the local DN 1036, MEC applications 2026, 2027, and / or 2028 can be mapped to the DN 1036 of the 5GS.

[0221] In the third implementation, the 5GS RAN can be a VNF-based virtual RAN, and UPF 2006 can be configured or operated as the MEC data plane 2024 within the NF Virtualization Infrastructure (NFVI) (e.g., VI 2022). In these implementations, the AF can be configured as a MEC platform VNF (e.g., see [link to relevant documentation]). Figure 21 The discussion includes MEC API, MEC application enabling functionality, and API principles. Furthermore, the native DN 1036 can include MEC applications 2026, 2027, and / or 2028 instantiated as VNFs. A third implementation can be combined with the first and / or second implementations, or it can be a standalone implementation.

[0222] Alternatively or additionally, the access-level edge (e.g., the RAN nodes and / or other access network nodes discussed herein) can communicate with the local / regional edge network using one or more APIs. The local / regional edge network may include network nodes that communicate with the national edge network using appropriate applications. The national edge may include various NANs that use applications to access one or more remote clouds within the global edge. NANs may also be configured or operated for vertical segmentation management and SLA compliance. Alternatively or additionally, MEC deployment can be based on the definition of "edge" to provide flexibility to the MNO, particularly when deploying MECs in NFV environments (e.g., MEC entities can be instantiated as virtualized NFs (VNFs), thus offering high flexibility for operator deployment).

[0223] In some embodiments, the MEC system 2000 can be flexibly deployed based on the use case / vertical segmentation / information to be processed. Some components of the MEC system 2000 may reside in the same location as other elements of the system. For example, in some use cases (e.g., enterprise), the MEC application 2026 may need to use MEC services locally, and deploying a MEC host equipped with the required API set locally may be efficient. In another example, deploying the MEC server 2002 in a data center (away from the access network) may not require hosting APIs such as the RNI API (which can be used to collect wireless network information from wireless base stations). On the other hand, RNI information can be detailed and provided in the cloud RAN (CRAN) environment at the aggregation point, enabling the execution of appropriate radio-aware traffic management algorithms. In some other aspects, bandwidth management APIs may exist at the access-level edge and more remote edge locations to establish transport networks (e.g., for CDN-based services).

[0224] Figure 21 A reference architecture for MEC in a Network Functions Virtualization (NFV) environment, which can be deployed from an example edge computing system, is shown. Figure 21 A MEC reference architecture 2100 in an NFV environment is illustrated. The MEC architecture 2100 can be configured to provide functionality. The MEC architecture 2100 includes an MEC platform 2102, an MEC platform manager – NFV (MEPM-V) 2114, a data plane 2108, an NFV infrastructure (NFVI) 2110, VNF managers (VNFM) 2120 and 2122, an NFV orchestrator (NFVO) 2124, an MEC application orchestrator (MEAO) 2126, an OSS 2128, a user application LCM agent 2130, a UE application 2134, and a CFS ingress 2132. The MEC platform manager 2114 may include MEC platform component management 2116 and MEC application rules and requirements management 2118. The MEC platform 2102 can be coupled to another MEC platform 2106 via an MP3 interface.

[0225] In this embodiment, the MEC platform 2102 is deployed as a VNF. For the ETSI NFV Management and Orchestration (MANO) components, the MEC application 2104 can appear as a VNF. This allows for the reuse of ETSI NFV MANO functionality. The full suite of MANO functionality may not be used, and some additional functionality may be required. Such a specific MEC application is referred to by the name "MEC Application VNF" or "MEA-VNF". The virtualization infrastructure is deployed as NFVI 2110, and its virtualization resources are managed by the Virtualization Infrastructure Manager (VIM) 2112. For this purpose, one or more procedures defined in the ETSI NFV Infrastructure Specification can be used. The MEA-VNFM 304 is managed like a single VNF, allowing MEC deployments in NFV to delegate certain orchestration and LCM tasks to NFVO 2124 and VNFMs 2120 and 2122, as defined in the ETSI NFV MANO.

[0226] When the MEC platform is implemented as a VNF (e.g., MEC platform VNF 2102), the MEPM-V 2114 can be configured as an Element Manager (EM). The MEAO 2126 uses the NFVO 2124 for resource orchestration and orchestrates a collection of MEA VNFs 2104 as one or more NFV Network Services (NS). The MEPM-V 2114 delegates LCM components to one or more VNFMs 2120 and 2122. Specific or generic VNFMs 2120 and 2122 are used to perform LCM. According to the set concept in 3GPP TR 32.842 v13.1.0 (2015-12-21), the MEPM-V 2114 and VNFM (ME platform LCM) 2120 can be deployed as a single package, or the VNFM can be a generic VNFM, with the MEC platform VNF 2102 and MEPM-V 2114 provided by a single vendor.

[0227] The Mp1 reference point between MEC application 2104 and MEC platform 2114 is optional for MEC application 2104 unless it is an application that provides and / or uses MEC services. The Mm3* reference point between MEAO 2126 and MEPM-V 2114 is based on the Mm3 reference point. This reference point can be changed to accommodate the separation between MEPM-V 2114 and VNFM (ME application LCM) 2122. The following new reference points (Mv1, Mv2, and Mv3) are introduced between components of the ETSI MEC architecture and ETSI NFV architecture to support the management of ME application VNF 2104.

[0228] The following reference points relate to existing NFV reference points, but only a subset of their functionality is available for ETSI MEC and may require expansion. Mv1 is the reference point connecting MEAO 2126 and NFVO 2124, and is associated with the Os-Ma-nfvo reference point defined in ETSI NFV. Mv2 is the reference point connecting VNFM 2122, which performs the LCM of MEC application VNF 2104, to MEPM-V 2114 to allow the exchange of LCM-related notifications between these entities. Mv2 is associated with the Ve-Vnfm-em reference point defined in ETSI NFV, but may include additional features and may not use all the functionality provided by Ve-Vnfm-em. Mv3 is the reference point connecting VNFM 2122 to the ME application VNF 2104 instance to allow message exchange (e.g., related to MEC application LCM or initial deployment-specific configurations). Mv3 is related to the Ve-Vnfm-vnf reference point defined in ETSI NFV, but may include additional items and may not use all the features provided by Ve-Vnfm-vnf.

[0229] The following reference points are used as defined by ETSI NFV: The Nf-Vn reference point connects each ME application VNF 2104 and NFVI 2110. The Nf-Vi reference point connects NFVI 2110 and VIM 2112. The Os-Ma-nfvo reference point connects OSS 2128 and NFVO 2124 and is primarily used to manage NS (e.g., connecting and orchestrating multiple VNFs to provide services). The Or-Vnfm reference point connects NFVO 2124 and VNFM (MEC Platform LCM) 2120 and is primarily used by NFVO 2124 to invoke VNF LCM operations. The Vi-Vnfm reference point connects VIM 2112 and VNFM (MEC Platform LCM) 2120 and is primarily used by VNFM 2120 to invoke resource management operations to manage the cloud resources required by the VNFs (in an NFV-based MEC deployment, it is assumed that this reference point is in a 1:1 ratio with Mm6). The Or-Vi reference point connects NFVO 2124 and VIM 2112, and is primarily used by NFVO 2124 to manage cloud resource capacity. The Ve-Vnfm-em reference point connects VNFM (MEC platform LCM) 2120 and MEPM-V 2114. The Ve-Vnfm-vnf reference point connects VNFM (MEC platform LCM) 2120 and MEC platform VNF 2102.

[0230] Figure 22 Example architectures, including the ETSI ISG MEC architecture and the EDGE APP architecture, are shown. Figure 22In ETSI-MEC, the Application Lifecycle Management Agent (ACLMP) is coupled to OSS 2012 via the Mm8 reference point and to the MEC Orchestrator 2010 via the Mm-9 reference point. Additionally, the Application Lifecycle Management Client (ALCMC) is coupled to ACLMP via the Mx2 reference point. In ETSI-MEC, MEC applications and the MEC platform can expose services, including network services, depending on their availability at the core or access network level. Detailed information about MEC entities has been discussed previously.

[0231] The following paragraphs describe examples of various embodiments.

[0232] Example 1 includes an apparatus for use in a user equipment (UE), comprising logic and circuitry that causes the UE to perform the following processes: generating a first protocol packet from data to be transmitted based on a remote memory access (RMA) protocol stack; generating a second protocol packet from the first protocol packet based on a wireless communication protocol stack; and transmitting the second protocol packet on a radio bearer.

[0233] Example 2 includes the apparatus described in Example 1, wherein the RMA protocol stack is a Peripheral Component Interconnect Fast (PCIe) protocol stack, a Remote Direct Memory Access over Converged Ethernet v2 (RoCEv2) protocol stack, or a High-Speed ​​Input / Output (RapidIO) protocol stack.

[0234] Example 3 includes the apparatus described in Example 1 or 2, wherein the wireless communication protocol stack is a novel radio (NR) protocol stack.

[0235] Example 4 includes the apparatus described in Example 2, wherein, when the RMA protocol stack is the PCIe protocol stack, the logic and circuitry are further configured to cause the UE to: generate a transaction layer packet from the data to be transmitted based on the transaction layer protocol in the PCIe protocol stack; and generate a data link layer packet from the transaction layer packet as the first protocol packet based on the data link layer protocol in the PCIe protocol stack.

[0236] Example 5 includes the apparatus described in Example 3, wherein the logic and circuitry are further configured to cause the UE to: generate a PDCP packet from the first protocol packet as the second protocol packet based on the Packet Data Convergence Protocol (PDCP) in the NR protocol stack.

[0237] Example 6 includes the apparatus described in Example 5, wherein the first protocol packet is included in the Service Data Unit (SDU) of the PDCP packet, and a PDCP SDU type different from that used for Internet Protocol (IP) data and non-IP data is used for the first protocol packet.

[0238] Example 7 includes the apparatus described in Example 5, wherein the first protocol packet is included in the Service Data Unit (SDU) of the PDCP packet, and the PDCP SDU type for non-Internet Protocol (non-IP) data is used for the first protocol packet.

[0239] Example 8 includes the apparatus described in Example 2, wherein the logic and circuitry are further configured to cause the UE to request the establishment of a Radio Access Network (RAN) computing session by using a Radio Resource Control (RRC) message, a Non-Access Stratum (NAS) request message, or a request message of the RMA protocol stack.

[0240] Example 9 includes the apparatus described in Example 8, wherein when a request message from the RMA protocol stack is used to request the establishment of a RAN computing session and the RMA protocol stack is the PCIe protocol stack, the RAN computing session type information element in the request message from the RMA protocol stack indicates that a PCIe-based RAN computing session type will be used in the RAN computing session.

[0241] Example 10 includes the apparatus described in Example 8, wherein when the NAS request message is used to request the establishment of a RAN computing session and the RMA protocol stack is the PCIe protocol stack, the PDU session type information element in the NAS request message indicates that an unstructured PDU session type will be used in the PDU session.

[0242] Example 11 includes the apparatus described in Example 4, wherein the transaction layer grouping includes TC information indicating the traffic category (TC) associated with the PCIe transaction, and wherein the PCIe transaction is classified into eight TCs.

[0243] Example 12 includes the apparatus described in Example 4, wherein the logic and circuitry are further configured to cause the UE to: send a UE dwell time for different payload sizes in a Protocol Data Unit (PDU) session establishment request message; and receive a REPLAY_TIMER limit for different payload sizes in a PDU session establishment response message, wherein the REPLAY_TIMER limit for the payload size of the transaction layer packet is used to determine whether to retransmit the transaction layer packet.

[0244] Example 13 includes the apparatus described in Example 4, wherein the REPLAY_TIMER limit is determined based on the following: the UE dwell time of the transaction layer packet, the base station dwell time of the transaction layer packet, the computational scheduling function (SF) dwell time of the transaction layer packet, the data link layer processing time, the computational SF dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet, the base station dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet, and the UE dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet.

[0245] Example 14 includes the apparatus described in Example 1, wherein the logic and circuitry are further configured to cause the UE to: offload workloads from the UE to a network-provided hardware accelerator based on a software framework for writing programs that execute across heterogeneous platforms, wherein the workload-related data is sent to the network-provided hardware accelerator by generating the first protocol packet from the data related to the workload and generating the second protocol packet from the first protocol packet.

[0246] Example 15 includes the apparatus described in Example 14, wherein the software framework is the Open Computing Language (OpenCL) framework, the Computing Unified Device Architecture (CUDA) framework, the Open Graphics Library (OpenGL) framework, or the Vulkan framework.

[0247] Example 16 includes a computer-readable storage medium storing instructions that, when executed by one or more processors, cause the one or more processors to: generate a first protocol packet from data to be transmitted based on a remote memory access (RMA) protocol stack; generate a second protocol packet from the first protocol packet based on a wireless communication protocol stack; and provide the second protocol packet to a wireless interface for transmission over a radio bearer.

[0248] Example 17 includes the computer-readable storage medium described in Example 16, wherein the RMA protocol stack is a Peripheral Component Interconnect Fast (PCIe) protocol stack, a Remote Direct Memory Access over Converged Ethernet v2 (RoCEv2) protocol stack, or a High-Speed ​​Input / Output (RapidIO) protocol stack.

[0249] Example 18 includes the computer-readable storage medium described in Example 16 or 17, wherein the wireless communication protocol stack is a novel radio (NR) protocol stack.

[0250] Example 19 includes the computer-readable storage medium of Example 17, wherein, when the RMA protocol stack is the PCIe protocol stack, the instructions, when executed by the one or more processors, further cause the one or more processors to: generate a transaction layer packet from the data to be sent based on a transaction layer protocol in the PCIe protocol stack; and generate a data link layer packet from the transaction layer packet as the first protocol packet based on a data link layer protocol in the PCIe protocol stack.

[0251] Example 20 includes the computer-readable storage medium of Example 18, wherein the instructions, when executed by the one or more processors, further cause the one or more processors to: generate a PDCP packet from the first protocol packet as the second protocol packet based on the Packet Data Convergence Protocol (PDCP) in the NR protocol stack.

[0252] Example 21 includes the computer-readable storage medium of Example 20, wherein the first protocol packet is contained in a Service Data Unit (SDU) of the PDCP packet, and a PDCP SDU type different from that used for Internet Protocol (IP) data and non-IP data is used for the first protocol packet.

[0253] Example 22 includes the computer-readable storage medium of Example 20, wherein the first protocol packet is included in a Service Data Unit (SDU) of the PDCP packet, and the PDCP SDU type for non-Internet Protocol (non-IP) data is used for the first protocol packet.

[0254] Example 23 includes the computer-readable storage medium described in Example 16 or 17, wherein the instructions, when executed by the one or more processors, further cause the one or more processors to request the establishment of a Radio Access Network (RAN) computing session by using a Radio Resource Control (RRC) message, a Non-Access Stratum (NAS) request message, or a request message of the RMA protocol stack.

[0255] Example 24 includes the computer-readable storage medium of Example 23, wherein when a request message of the RMA protocol stack is used to request the establishment of a RAN computing session and the RMA protocol stack is the PCIe protocol stack, the RAN computing session type information element in the request message of the RMA protocol stack indicates that a PCIe-based RAN computing session type will be used in the RAN computing session.

[0256] Example 25 includes the computer-readable storage medium of Example 23, wherein when the NAS request message is used to request the establishment of a RAN computing session and the RMA protocol stack is the PCIe protocol stack, the PDU session type information element in the NAS request message indicates that an unstructured PDU session type will be used in the PDU session.

[0257] Example 26 includes the computer-readable storage medium of Example 19, wherein the transaction layer grouping includes TC information indicating the traffic category (TC) associated with a PCIe transaction, and wherein the PCIe transaction is classified into eight TCs.

[0258] Example 27 includes the computer-readable storage medium of Example 19, wherein, when executed by the one or more processors, the instructions further cause the one or more processors to: include UE dwell time for different payload sizes in a Protocol Data Unit (PDU) session establishment request message; and obtain REPLAY_TIMER limits for different payload sizes in a PDU session establishment response message, wherein the REPLAY_TIMER limit for the payload size of the transaction layer packet is used to determine whether to retransmit the transaction layer packet.

[0259] Example 28 includes the computer-readable storage medium of Example 19, wherein the REPLAY_TIMER limit is determined based on the following: the UE dwell time of the transaction layer packet, the base station dwell time of the transaction layer packet, the computational scheduling function (SF) dwell time of the transaction layer packet, the data link layer processing time, the computational SF dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet, the base station dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet, and the UE dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet.

[0260] Example 29 includes the computer-readable storage medium of Example 16, wherein the instructions, when executed by the one or more processors, further cause the one or more processors to: offload workloads from the UE to a network-provided hardware accelerator based on a software framework for writing programs that execute across heterogeneous platforms, wherein the workload-related data is transmitted to the network-provided hardware accelerator by generating the first protocol packet from the workload-related data and generating the second protocol packet from the first protocol packet.

[0261] Example 30 includes the computer-readable storage medium described in Example 29, wherein the software framework is the Open Computing Language (OpenCL) framework, the Computing Unified Device Architecture (CUDA) framework, the Open Graphics Library (OpenGL) framework, or the Vulkan framework.

[0262] Example 31 includes a method for use in a user equipment (UE), comprising: generating a first protocol packet from data to be transmitted based on a remote memory access (RMA) protocol stack; generating a second protocol packet from the first protocol packet based on a wireless communication protocol stack; and transmitting the second protocol packet over a radio bearer.

[0263] Example 32 includes the method described in Example 31, wherein the RMA protocol stack is a Peripheral Component Interconnect Fast (PCIe) protocol stack, a Remote Direct Memory Access over Converged Ethernet v2 (RoCEv2) protocol stack, or a High-Speed ​​Input / Output (RapidIO) protocol stack.

[0264] Example 33 includes the method described in Example 31 or 32, wherein the wireless communication protocol stack is a novel radio (NR) protocol stack.

[0265] Example 34 includes the method described in Example 32, wherein, when the RMA protocol stack is the PCIe protocol stack, generating the first protocol packet includes: generating a transaction layer packet from the data to be sent based on the transaction layer protocol in the PCIe protocol stack; and generating a data link layer packet from the transaction layer packet as the first protocol packet based on the data link layer protocol in the PCIe protocol stack.

[0266] Example 35 includes the method described in Example 33, wherein generating the second protocol packet includes: generating a PDCP packet from the first protocol packet as the second protocol packet based on the Packet Data Convergence Protocol (PDCP) in the NR protocol stack.

[0267] Example 36 includes the method of Example 35, wherein the first protocol packet is included in a Service Data Unit (SDU) of the PDCP packet, and a PDCP SDU type different from that used for Internet Protocol (IP) data and non-IP data is used for the first protocol packet.

[0268] Example 37 includes the method of Example 35, wherein the first protocol packet is included in the Service Data Unit (SDU) of the PDCP packet, and the PDCP SDU type for non-Internet Protocol (non-IP) data is used for the first protocol packet.

[0269] Example 38 includes the method described in Example 31 or 32, further comprising: requesting the establishment of a Radio Access Network (RAN) computing session by using a Radio Resource Control (RRC) message, a Non-Access Stratum (NAS) request message, or a request message of the RMA protocol stack.

[0270] Example 39 includes the method described in Example 38, wherein when the request message of the RMA protocol stack is used to request the establishment of a RAN computing session and the RMA protocol stack is the PCIe protocol stack, the RAN computing session type information element in the request message of the RMA protocol stack indicates that the RAN computing session type for PCIe will be used in the RAN computing session.

[0271] Example 40 includes the method described in Example 38, wherein when the NAS request message is used to request the establishment of a RAN computing session and the RMA protocol stack is the PCIe protocol stack, the PDU session type information element in the NAS request message indicates that an unstructured PDU session type will be used in the PDU session.

[0272] Example 41 includes the method of Example 34, wherein the transaction layer grouping includes TC information indicating the traffic category (TC) associated with the PCIe transaction, and wherein the PCIe transaction is classified into eight TCs.

[0273] Example 42 includes the method of Example 34, further comprising: sending a UE dwell time for different payload sizes in a Protocol Data Unit (PDU) session establishment request message; and receiving a REPLAY_TIMER limit for different payload sizes in a PDU session establishment response message, wherein the REPLAY_TIMER limit for the payload size of the transaction layer packet is used to determine whether to retransmit the transaction layer packet.

[0274] Example 43 includes the method described in Example 34, wherein the REPLAY_TIMER limit is determined based on the following: the UE dwell time of the transaction layer packet, the base station dwell time of the transaction layer packet, the computational scheduling function (SF) dwell time of the transaction layer packet, the data link layer processing time, the computational SF dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet, the base station dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet, and the UE dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet.

[0275] Example 44 includes the method of Example 31, further comprising: offloading the workload from the UE to a network-provided hardware accelerator based on a software framework for writing programs that execute across heterogeneous platforms, wherein the workload-related data is sent to the network-provided hardware accelerator by generating the first protocol packet from the data related to the workload and generating the second protocol packet from the first protocol packet.

[0276] Example 45 includes the method described in Example 44, wherein the software framework is the Open Computing Language (OpenCL) framework, the Computing Unified Device Architecture (CUDA) framework, the Open Graphics Library (OpenGL) framework, or the Vulkan framework.

[0277] Example 46 includes a user equipment (UE) comprising: a wireless interface; and processor circuitry coupled to the wireless interface, the processor circuitry being configured to: generate a first protocol packet from data to be transmitted based on a remote memory access (RMA) protocol stack; generate a second protocol packet from the first protocol packet based on a wireless communication protocol stack; and transmit the second protocol packet over a radio bearer.

[0278] Example 47 includes the UE described in Example 46, wherein the RMA protocol stack is a Peripheral Component Interconnect Fast (PCIe) protocol stack, a Remote Direct Memory Access over Converged Ethernet v2 (RoCEv2) protocol stack, or a High-Speed ​​Input / Output (RapidIO) protocol stack.

[0279] Example 48 includes the UE described in Example 46 or 47, wherein the wireless communication protocol stack is a novel radio (NR) protocol stack.

[0280] Example 49 includes the UE described in Example 47, wherein, when the RMA protocol stack is the PCIe protocol stack, the processor circuitry is further configured to: generate a transaction layer packet from the data to be sent based on the transaction layer protocol in the PCIe protocol stack; and generate a data link layer packet from the transaction layer packet as the first protocol packet based on the data link layer protocol in the PCIe protocol stack.

[0281] Example 50 includes the UE described in Example 48, wherein the processor circuitry is further configured to generate a PDCP packet from the first protocol packet as the second protocol packet based on the Packet Data Convergence Protocol (PDCP) in the NR protocol stack.

[0282] Example 51 includes the UE described in Example 50, wherein the first protocol packet is included in the Service Data Unit (SDU) of the PDCP packet, and a PDCP SDU type different from that used for Internet Protocol (IP) data and non-IP data is used for the first protocol packet.

[0283] Example 52 includes the UE described in Example 50, wherein the first protocol packet is included in the Service Data Unit (SDU) of the PDCP packet, and the PDCP SDU type for non-Internet Protocol (non-IP) data is used for the first protocol packet.

[0284] Example 53 includes the UE described in Example 46 or 47, wherein the processor circuitry is further configured to request the establishment of a Radio Access Network (RAN) computing session by using a Radio Resource Control (RRC) message, a Non-Access Stratum (NAS) request message, or a request message of the RMA protocol stack.

[0285] Example 54 includes the UE described in Example 53, wherein when the request message of the RMA protocol stack is used to request the establishment of a RAN computing session and the RMA protocol stack is the PCIe protocol stack, the RAN computing session type information element in the request message of the RMA protocol stack indicates that the RAN computing session type for PCIe will be used in the RAN computing session.

[0286] Example 55 includes the UE described in Example 53, wherein when the NAS request message is used to request the establishment of a RAN computing session and the RMA protocol stack is the PCIe protocol stack, the PDU session type information element in the NAS request message indicates that an unstructured PDU session type will be used in the PDU session.

[0287] Example 56 includes the UE described in Example 49, wherein the transaction layer grouping includes TC information indicating the traffic category (TC) associated with the PCIe transaction, and wherein the PCIe transaction is divided into eight TCs.

[0288] Example 57 includes the UE described in Example 49, wherein the processor circuitry is further configured to: send UE dwell time for different payload sizes in a Protocol Data Unit (PDU) session establishment request message; and receive REPLAY_TIMER limits for different payload sizes in a PDU session establishment response message, wherein the REPLAY_TIMER limit for the payload size of the transaction layer packet is used to determine whether to retransmit the transaction layer packet.

[0289] Example 58 includes the UE described in Example 49, wherein the REPLAY_TIMER limit is determined based on the following: the UE dwell time of the transaction layer packet, the base station dwell time of the transaction layer packet, the computational scheduling function (SF) dwell time of the transaction layer packet, the data link layer processing time, the computational SF dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet, the base station dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet, and the UE dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet.

[0290] Example 59 includes the UE described in Example 46, wherein the processor circuitry is further configured to: offload workloads from the UE to a network-provided hardware accelerator based on a software framework for writing programs that execute across heterogeneous platforms, wherein the workload-related data is sent to the network-provided hardware accelerator by generating the first protocol packet from the data related to the workload and generating the second protocol packet from the first protocol packet.

[0291] Example 60 includes the UE described in Example 59, wherein the software framework is the Open Computing Language (OpenCL) framework, the Computing Unified Device Architecture (CUDA) framework, the Open Graphics Library (OpenGL) framework, or the Vulkan framework.

[0292] While certain embodiments have been illustrated and described herein for purposes of description, various alternative and / or equivalent embodiments or implementations that achieve the same purpose may be substituted for the illustrated and described embodiments without departing from the scope of the invention. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, the embodiments described herein are clearly limited only by the appended claims and their equivalents.

Claims

1. An apparatus for use in a user equipment (UE), comprising logic and circuitry that causes the UE to perform the following processes: Based on the Remote Memory Access (RMA) protocol stack, a first protocol packet is generated from the data to be sent, wherein... The RMA protocol stack is a Peripheral Component Interconnect Fast (PCIe) protocol stack, a Remote Direct Memory Access over Converged Ethernet (RDMA) v2 (RoCEv2) protocol stack, or a RapidIO protocol stack; Based on the wireless communication protocol stack, a second protocol packet is generated from the first protocol packet; and The second protocol packet is transmitted over the radio bearer, wherein The wireless communication protocol stack is a novel radio (NR) protocol stack, and the logic and circuitry are further configured to cause the UE to: generate a PDCP packet from the first protocol packet as the second protocol packet based on the Packet Data Convergence Protocol (PDCP) in the NR protocol stack, wherein the first protocol packet is contained in the Service Data Unit (SDU) of the PDCP packet, and a PDCP SDU type different from that used for Internet Protocol (IP) data and non-IP data is used for the first protocol packet, or a PDCP SDU type used for non-IP data is used for the first protocol packet.

2. The apparatus of claim 1, wherein, When the RMA protocol stack is the PCIe protocol stack, the logic and circuitry are further configured to cause the UE to: Based on the transaction layer protocol in the PCIe protocol stack, a transaction layer packet is generated from the data to be sent. as well as Based on the data link layer protocol in the PCIe protocol stack, a data link layer packet is generated from the transaction layer packet as the first protocol packet.

3. The apparatus of claim 1, wherein, The logic and circuitry are further configured to cause the UE to: A radio access network (RAN) computing session is requested by using a radio resource control (RRC) message, a non-access stratum (NAS) request message, or a request message of the RMA protocol stack.

4. The apparatus of claim 3, wherein, When the request message of the RMA protocol stack is used to request the establishment of a RAN computing session and the RMA protocol stack is the PCIe protocol stack, the RAN computing session type information element in the request message of the RMA protocol stack indicates that the RAN computing session type for PCIe will be used in the RAN computing session.

5. The apparatus of claim 3, wherein, When the NAS request message is used to request the establishment of a RAN computing session and the RMA protocol stack is the PCIe protocol stack, the PDU session type information element in the NAS request message indicates that an unstructured PDU session type will be used in the PDU session.

6. The apparatus of claim 2, wherein, The transaction layer grouping includes TC information indicating the traffic category (TC) associated with the PCIe transaction, wherein the PCIe transaction is divided into eight TCs.

7. The apparatus of claim 2, wherein, The logic and circuitry are further configured to cause the UE to: Send the UE dwell time for different payload sizes in the Protocol Data Unit (PDU) session establishment request message; as well as The PDU session establishment response message receives REPLAY_TIMER limits for different payload sizes, wherein the REPLAY_TIMER limit for the payload size of the transaction layer packet is used to determine whether to resend the transaction layer packet.

8. The apparatus of claim 7, wherein, The REPLAY_TIMER limit is determined based on the following: the UE dwell time of the transaction layer packet, the base station dwell time of the transaction layer packet, the computational scheduling function (SF) dwell time of the transaction layer packet, the data link layer processing time, the computational SF dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet, the base station dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet, and the UE dwell time of the data link layer packet that provides positive or negative acknowledgment for the transaction layer packet.

9. The apparatus of claim 1, wherein, The logic and circuitry are further configured to cause the UE to: Based on a software framework for writing programs that execute across heterogeneous platforms, the workload is offloaded from the UE to a network-provided hardware accelerator, wherein the workload-related data is sent to the network-provided hardware accelerator by generating the first protocol packet from the data related to the workload and generating the second protocol packet from the first protocol packet.

10. The apparatus of claim 9, wherein, The software framework is the Open Computing Language (OpenCL) framework, the Computing Unified Device Architecture (CUDA) framework, the Open Graphics Library (OpenGL) framework, or the Vulkan framework.

11. A computer-readable storage medium storing instructions that, when executed by one or more processors of a user equipment (UE), cause the UE to: Based on the Remote Memory Access (RMA) protocol stack, a first protocol packet is generated from the data to be sent, wherein... The RMA protocol stack is a Peripheral Component Interconnect Fast (PCIe) protocol stack, a Remote Direct Memory Access over Converged Ethernet (RDMA) v2 (RoCEv2) protocol stack, or a RapidIO protocol stack; Based on the wireless communication protocol stack, a second protocol packet is generated from the first protocol packet; and The second protocol packet is provided to the wireless interface for transmission over the radio bearer, wherein The wireless communication protocol stack is a novel radio (NR) protocol stack. When the instructions are executed by the one or more processors, the UE is further prompted to: generate a PDCP packet from the first protocol packet as the second protocol packet based on the Packet Data Convergence Protocol (PDCP) in the NR protocol stack, wherein the first protocol packet is contained in the Service Data Unit (SDU) of the PDCP packet, and a PDCP SDU type different from that used for Internet Protocol (IP) data and non-IP data is used for the first protocol packet, or a PDCP SDU type used for non-IP data is used for the first protocol packet.

12. The computer-readable storage medium of claim 11, wherein, When the RMA protocol stack is the PCIe protocol stack, the instructions, when executed by the one or more processors, further prompt the UE to: Based on the transaction layer protocol in the PCIe protocol stack, a transaction layer packet is generated from the data to be sent; and Based on the data link layer protocol in the PCIe protocol stack, a data link layer packet is generated from the transaction layer packet as the first protocol packet.

Images