CN114449465A

CN114449465A - Apparatus and method for charging of 5GS capability to support edge computing

Info

Publication number: CN114449465A
Application number: CN202111287595.XA
Authority: CN
Inventors: 姚羿志; 乔伊·周
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2020-11-03
Filing date: 2021-11-02
Publication date: 2022-05-06

Abstract

The present disclosure provides an apparatus and method for charging of 5GS capabilities to support edge computing. An apparatus comprising: an interface circuit; and a processor circuit coupled with the interface circuit, wherein the processor circuit is configured to: encoding a charging data request for charging of a fifth generation (5G) system (5GS) capability supporting edge calculation for transmission via the interface circuit to a charging function (CHF); decoding a charging data response received from the CHF via the interface circuit in response to the charging data request, the charging data response confirming the charging data request; and perform charging with CHF for 5GS capability to support edge computation. Other embodiments are also disclosed and claimed.

Description

Apparatus and method for charging of 5GS capability to support edge computing

Priority declaration

This application is based on and claims priority from united states provisional application serial No. 63/109,258 filed on 3/11/2020. The entire contents of this application are incorporated herein by reference in their entirety.

Technical Field

Embodiments of the present disclosure relate generally to the field of wireless communications, and in particular, to an apparatus and method for charging for fifth generation (5G) system (5GS) capabilities that support edge computing.

Background

The third generation partnership project (3GPP) has started from Rel-15, 5GS already supports edge computing (edge computing), and edge application enabling architecture and solutions and 5GC enhancements are being studied and defined in Rel-17. Edge computing enables operator and 3 rd party services to be hosted close to the UE's attachment access point, enabling efficient service delivery by reducing end-to-end delay and load on the transport network.

Disclosure of Invention

An aspect of the present disclosure provides an apparatus, comprising: an interface circuit; and a processor circuit coupled with the interface circuit, wherein the processor circuit is configured to: encoding a charging data request for charging of a fifth generation (5G) system (5GS) capability supporting edge computing for transmission via the interface circuit to a charging function (CHF); decoding a charging data response received from the CHF via the interface circuit in response to the charging data request, the charging data response confirming the charging data request; and performing a charge with the CHF for the 5GS capability that supports edge computing.

An aspect of the present disclosure provides an apparatus, comprising: an interface circuit; and a processor circuit coupled with the interface circuit, wherein the processor circuit is configured to: encoding a charging data request for charging of an edge enabled resource or service for transmission via the interface circuit to a charging function (CHF); decoding a charging data response received from the CHF via the interface circuit in response to the charging data request, the charging data response confirming the charging data request; and performing charging of the edge-enabled resources or services with the CHF.

One aspect of the present disclosure provides a method, comprising: encoding a charging data request for charging of a fifth generation (5G) system (5GS) capability supporting edge computing for transmission to a charging function (CHF); decoding a charging data response received from the CHF in response to the charging data request, the charging data response confirming the charging data request; and performing a charge with the CHF for the 5GS capability that supports edge computing.

One aspect of the present disclosure provides a method, comprising: encoding a charging data request for charging of an edge enabled resource or service for transmission to a charging function (CHF); decoding a charging data response received from the CHF in response to the charging data request, the charging data response confirming the charging data request; and performing charging of the edge-enabled resources or services with the CHF.

An aspect of the disclosure provides a computer-readable medium having instructions stored thereon, wherein the instructions, when executed by a processor circuit, cause the processor circuit to perform the method of the disclosure.

Drawings

Embodiments of the present disclosure will be described by way of example, and not limitation, in the figures of the accompanying drawings in which like references indicate similar elements.

Fig. 1 illustrates an example architecture of a system according to some embodiments of the present disclosure.

Fig. 2 illustrates an example architecture of a system including a 5G core (5GC) according to some embodiments of the present disclosure.

Fig. 3 illustrates an example of a 5GS architecture in a non-roaming scenario, in accordance with some embodiments of the present disclosure.

Fig. 4 illustrates an example architecture for enabling edge applications according to some embodiments of the present disclosure.

Fig. 5 illustrates a flow diagram of a method for charging for 5GS capability to support edge computing, according to some embodiments of the present disclosure.

Fig. 6 illustrates an example architecture for 5G data connectivity converged charging, according to some embodiments of the present disclosure.

Fig. 7 illustrates an example architecture of 5G converged inter-provider charging supported by management service (MnS) producers of Public Land Mobile Networks (PLMNs) in accordance with some embodiments of the present disclosure.

Fig. 8 illustrates an example architecture of 5G converged inter-provider charging supported by a Charging Enabling Function (CEF) in accordance with some embodiments of the present disclosure.

Fig. 9 illustrates a flow diagram of a method for edge-enabled charging of resources and services, according to some embodiments of the present disclosure.

Fig. 10 illustrates an example architecture of 5G fused inter-provider charging supported by MnS producers of Edge Computing Service Providers (ECSPs) according to some embodiments of the disclosure.

Fig. 11 illustrates an example architecture for 5G converged inter-provider charging supported by CEF in accordance with some embodiments of the disclosure.

Fig. 12 illustrates an example architecture for 5G converged inter-provider charging supported by an Edge Enabler Server (EES) according to some embodiments of the present disclosure.

Fig. 13 illustrates an example of an infrastructure device in accordance with various embodiments.

Fig. 14 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium and performing any one or more of the methodologies discussed herein, according to some example embodiments.

Fig. 15 illustrates a network according to various embodiments of the present disclosure.

Detailed Description

Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of the disclosure to others skilled in the art. However, it will be readily appreciated by those skilled in the art that many alternative embodiments may be practiced using portions of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth in order to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to one skilled in the art that alternative embodiments may be practiced without the specific details. In other instances, well-known features may be omitted or simplified in order not to obscure the illustrative embodiments.

Further, various operations will be described as multiple discrete operations, in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

The phrases "in an embodiment," "in one embodiment," and "in some embodiments" are used repeatedly herein. The phrase generally does not refer to the same embodiment; however, it may refer to the same embodiment. The terms "comprising," "having," and "including" are synonymous, unless the context dictates otherwise. The phrases "A or B" and "A/B" mean "(A), (B) or (A and B)".

Fig. 1 illustrates an example architecture of a system 100 according to some embodiments of the present disclosure. The following description is provided for an example system 100 operating in conjunction with the Long Term Evolution (LTE) system standard and the 5G or New Radio (NR) system standard provided by the 3GPP Technical Specification (TS). However, the example embodiments are not limited in this respect and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., sixth generation (6G)) systems, Institute of Electrical and Electronics Engineers (IEEE)802.16 protocols (e.g., wireless Metropolitan Area Network (MAN), Worldwide Interoperability for Microwave Access (WiMAX), etc.), and so forth.

As shown in FIG. 1, the system 100 can include a UE 101a and a UE 101b (collectively referred to as "UE(s) 101"). As used herein, the term "user equipment" or "UE" may refer to devices having radio communication capabilities and may describe remote users of network resources in a communication network. The terms "user equipment" or "UE" may be considered synonyms and may be referred to as a client, a mobile phone, a mobile device, a mobile terminal, a user terminal, a mobile unit, a mobile station, a mobile user, a subscriber, a user, a remote station, an access agent, a user agent, a receiver, a radio, a reconfigurable mobile, and the like. Furthermore, the terms "user equipment" or "UE" may include any type of wireless/wired device or any computing device that includes a wireless communication interface. In this example, the UE 101 is shown as a smartphone (e.g., a handheld touchscreen mobile computing device connectable to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a consumer electronic device, a cellular phone, a smartphone, a feature phone, a tablet, a wearable computer device, a Personal Digital Assistant (PDA), a pager, a wireless handheld device, a desktop computer, a laptop computer, an in-vehicle infotainment system (IVI), an in-vehicle entertainment (ICE) device, an Instrument panel (Instrument Cluster, IC), a head-up display (HUD) device, an in-vehicle diagnostics (OBD) device, a dashboard mobile Device (DME), a Mobile Data Terminal (MDT), an Electronic Engine Management System (EEMS), an electronic/Engine Control Unit (ECU), an electronic/Engine Control Module (ECM), a mobile computing device(s), a mobile computing device, a mobile device, Embedded systems, microcontrollers, control modules, Engine Management Systems (EMS), networked or "smart" devices, Machine Type Communication (MTC) devices, machine-to-machine (M2M), internet of things (IoT) devices, and/or the like.

In some embodiments, any of the UEs 101 may include an IoT UE, which may include a network access layer designed for low power IoT applications that utilize short-term UE connections. IoT UEs may utilize technologies such as M2M or MTC to exchange data with MTC servers or devices via PLMNs, proximity-based services (ProSe) or device-to-device (D2D) communications, sensor networks, or IoT networks. The data exchange of M2M or MTC may be a machine initiated data exchange. An IoT network describes interconnected IoT UEs that may include uniquely identifiable embedded computing devices (within the internet infrastructure) with short-term connections. The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connection of the IoT network.

UE 101 may be configured to connect with (e.g., communicatively couple with) RAN 110. In an embodiment, RAN110 may be a Next Generation (NG) RAN or a 5G RAN, an evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access network (E-UTRAN), or a legacy RAN, such as a UTRAN (UMTS terrestrial radio access network) or a GERAN (GSM (global system for Mobile communications or group Sp specific Mobile) EDGE (GSM evolution) radio access network). As used herein, the term "NG RAN" or the like may refer to RAN110 operating in an NR or 5G system 100, and the term "E-UTRAN" or the like may refer to RAN110 operating in an LTE or 4G system 100. The UE 101 utilizes connections (or channels) 103 and 104, respectively, each of which includes a physical communication interface or layer (discussed in further detail below). As used herein, the term "channel" may refer to any tangible or intangible transmission medium that communicates data or a stream of data. The term "channel" may be synonymous and/or equivalent to "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," and/or any other similar term denoting a path or medium through which data is communicated. In addition, the term "link" may refer to a connection between two devices for the purpose of transmitting and receiving information over a Radio Access Technology (RAT).

In this example,

connections

103 and 104 are shown as air interfaces to enable communicative coupling, and may be consistent with a cellular communication protocol, such as a global system for mobile communications (GSM) protocol, a Code Division Multiple Access (CDMA) network protocol, a push-to-talk (PTT) protocol, a cellular PTT (poc) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (5G) protocol, a New Radio (NR) protocol, and/or any other communication protocol discussed herein. In an embodiment, the UE 101 may exchange communication data directly via the ProSe interface 105. The ProSe interface 105 may alternatively be referred to as a Sidelink (SL) interface 105 and may include one or more logical channels including, but not limited to, a Physical Sidelink Control Channel (PSCCH), a physical sidelink shared channel (PSCCH), a Physical Sidelink Discovery Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

UE 101b is shown configured to access an Access Point (AP)106 (also referred to as "WLAN node 106", "WLAN terminal 106", or "WT 106", etc.) via a connection 107. The connection 107 may comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, where the AP 106 would comprise a wireless fidelity (WiFi) router. In this example, the AP 106 is shown connected to the internet without being connected to the core network of the wireless system (described in further detail below). In various embodiments, UE 101b, RAN110, and AP 106 may be configured to utilize LTE-WLAN aggregation (LWA) operations and/or WLAN LTE/WLAN radio level integration (LWIP) operations with IPsec tunneling. LWA operation may involve UE 101b in RRC _ CONNECTED being configured by RAN node 111 to utilize radio resources of LTE and WLAN. The LWIP operation may involve the UE 101b using WLAN radio resources (e.g., connection 107) via an internet protocol security (IPsec) protocol tunnel to authenticate and encrypt packets (e.g., Internet Protocol (IP) packets) sent over the connection 107. An IPsec tunnel may include encapsulating the entire original IP packet and adding a new packet header to protect the original header of the IP packet.

RAN110 may include one or more RAN nodes 111a and 111b (collectively referred to as "RAN node(s) 111") that enable

connections

103 and 104. As used herein, the terms "Access Node (AN)", "access point", "RAN node", and the like may describe a device that provides radio baseband functionality for data and/or voice connections between a network and one or more users. These access nodes may be referred to as Base Stations (BSs), next generation node BS (gnbs), RAN nodes, evolved nodebs (enbs), nodebs, Road Side Units (RSUs), transmission reception points (TRxP or TRP), etc., and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the term "NG RAN node" or the like may refer to a RAN node 111 (e.g., a gNB) operating in the NR or 5G system 100, and the term "E-UTRAN node" or the like may refer to a RAN node 111 (e.g., an eNB) operating in the LTE or 4G system 100. According to various embodiments, the RAN node 111 may be implemented as one or more dedicated physical devices such as a macro cell base station and/or a Low Power (LP) base station for a femto cell, pico cell or other similar cell providing a smaller coverage area, smaller user capacity or higher bandwidth than a macro cell.

In some embodiments, all or part of the RAN node 111 may be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as a Cloud Radio Access Network (CRAN) and/or a virtual baseband unit pool (vbbp). In these embodiments, the CRAN or vbbp may implement RAN functional partitioning, such as: PDCP partitioning, wherein RRC and PDCP layers are operated by the CRAN/vbbp, while other layer 2 (L2) protocol entities are operated by individual RAN nodes 111; MAC/PHY division, where RRC, PDCP, RLC and MAC layers are operated by the CRAN/vbbp, and PHY layers are operated by individual RAN nodes 111; or "lower PHY" division, where the RRC, PDCP, RLC, MAC layers and upper parts of the PHY layers are operated by the CRAN/vbup and lower parts of the PHY layers are operated by the individual RAN node 111. The virtualization framework allows freeing up processor cores of RAN node 111 to execute other virtualized applications. In some implementations, the individual RAN nodes 111 may represent individual gNB-DUs that are connected to the gNB-CUs via individual F1 interfaces (not shown in fig. 1). In these implementations, the gbb-DUs may include one or more remote radio heads or radio front-end modules (RFEM), and the gbb-CUs may be operated by a server (not shown) located in the RAN110 or by a server pool in a similar manner to the CRAN/vbbp. Additionally or alternatively, one or more RAN nodes 111 may be next generation enbs (NG-enbs), which are RAN nodes that provide E-UTRA user plane and control plane protocol terminations towards the UE 101 and which are connected to the 5GC via an NG interface.

In the V2X scenario, one or more RAN nodes 111 may be or act as RSUs. The term "roadside unit" or "RSU" may refer to any transportation infrastructure entity for V2X communication. The RSU may be implemented in or by a suitable RAN node or a fixed (or relatively stationary) UE, where the RSU in or by the UE may be referred to as a "UE-type RSU", the RSU in or by the eNB may be referred to as an "eNB-type RSU", the RSU in or by the gNB may be referred to as a "gNB-type RSU", and so on. In one example, an RSU is a computing device coupled with radio frequency circuitry located at the roadside that provides connectivity support for a passing vehicle UE 101(vUE 101). 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 may operate on the 5.9GHz Direct Short Range Communication (DSRC) band to provide very low latency communications required for high speed events, such as collision avoidance, traffic warnings, etc. Additionally or alternatively, the RSU may operate on the cellular V2X frequency band to provide the low latency communications described above as well as other cellular communication services. Additionally or alternatively, the RSU may operate as a WiFi hotspot (2.4GHz band) and/or provide a connection to one or more cellular networks to provide uplink and downlink communications. The computing device(s) and some or all of the radio frequency circuitry of the RSU may be enclosed in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide wired (e.g., ethernet) connectivity to a traffic signal controller and/or a backhaul network.

Any RAN node 111 may terminate the air interface protocol and may be the first point of contact for the UE 101. In some embodiments, any RAN node 111 may fulfill various logical functions of RAN110, including but not limited to Radio Network Controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

In an embodiment, the UEs 101 may be configured to communicate with each other or any of the RAN nodes 111 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, Orthogonal Frequency Division Multiple Access (OFDMA) communication techniques (e.g., for downlink communications) or single carrier frequency division multiple access (SC-FDMA) communication techniques (e.g., for uplink and ProSe or sidelink communications), using Orthogonal Frequency Division Multiplexing (OFDM) communication signals, although the scope of the embodiments is not limited in this respect. The OFDM signal may include a plurality of orthogonal subcarriers.

In some embodiments, the downlink resource grid may be used for downlink transmissions from any RAN node 111 to UE 101, while uplink transmissions may use similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which is the physical resource in the downlink per slot. Such a time-frequency plane representation is common practice for OFDM systems, which makes radio resource allocation intuitive. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid includes a plurality of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a set of resource elements; in the frequency domain, this may represent the minimum amount of resources that can currently be allocated. There are several different physical downlink channels transmitted using such resource blocks.

According to various embodiments, UE 101 and RAN node 111 communicate (e.g., transmit and receive) data over a licensed medium (also referred to as "licensed spectrum" and/or "licensed band") and an unlicensed shared medium (also referred to as "unlicensed spectrum and/or" unlicensed band "). The licensed spectrum may include channels operating in a frequency range of about 400MHz to about 3.8GHz, while the unlicensed spectrum may include a 5GHz band.

To operate in unlicensed spectrum, the UE 101 and RAN node 111 may operate using Licensed Assisted Access (LAA), enhanced LAA (elaa), and/or other elaa (felaa) mechanisms. In these implementations, UE 101 and RAN node 111 may perform one or more known medium sensing operations and/or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied prior to transmission in the unlicensed spectrum. The medium/carrier sensing operation may be performed according to a Listen Before Talk (LBT) protocol.

LBT is a mechanism in which a device (e.g., UE 101, RAN node 111, etc.) senses a medium (e.g., a channel or carrier frequency) and transmits when the medium is sensed to be idle (or when a particular channel in the medium is sensed to be unoccupied). The medium sensing operation may include Clear Channel Assessment (CCA) that utilizes at least Energy Detection (ED) to determine whether other signals are present on the channel to determine whether the channel is occupied or clear. The LBT mechanism allows the cellular/LAA network to coexist with incumbent systems in unlicensed spectrum and with other LAA networks. ED may include sensing Radio Frequency (RF) energy over an expected transmission band for a period of time and comparing the sensed RF energy to a predetermined or configured threshold.

Generally, an incumbent system in the 5GHz band is a WLAN based on IEEE 802.11 technology. WLANs employ a contention-based channel access mechanism known as carrier sense multiple access with collision avoidance (CSMA/CA). Here, when a WLAN node (e.g., a Mobile Station (MS) such as UE 101, AP 106) intends to transmit, the WLAN node may first perform a CCA prior to the transmission. In addition, a back-off mechanism is used to avoid collisions in the case where more than one WLAN node senses the channel as idle and transmits at the same time. The back-off mechanism may be a counter drawn randomly within the Contention Window Size (CWS) that is exponentially increased when collisions occur and reset to a minimum value when a transmission is successful. The LBT mechanism designed for LAA is somewhat similar to CSMA/CA of WLAN. In some implementations, an LBT procedure for a DL or UL transmission burst including PDSCH or PUSCH transmissions, respectively, may have an LAA contention window of variable length between X and Y extended cca (ecca) slots, where X and Y are minimum and maximum values of a CWS for the LAA. In one example, the minimum CWS for LAA transmission may be 9 microseconds (μ β); however, the size of the CWS and the Maximum Channel Occupancy Time (MCOT) (e.g., transmission bursts) may be based on government regulatory requirements.

The LAA mechanism is established based on the Carrier Aggregation (CA) technique of the LTE-Advanced (LTE-Advanced) system. In CA, each aggregated carrier is referred to as a Component Carrier (CC). The CCs may have bandwidths of 1.4, 3, 5, 10, 15, or 20MHz, and may be aggregated for up to five CCs, and thus, the maximum aggregated bandwidth is 100 MHz. In a Frequency Division Duplex (FDD) system, the number of aggregated carriers may be different for DL and UL, where the number of UL CCs is equal to or lower than the number of DL component carriers. In some cases, individual CCs may have different bandwidths than other CCs. In a Time Division Duplex (TDD) system, the number of CCs and the bandwidth of each CC are typically the same for DL and UL.

The CA also includes individual serving cells to provide individual CCs. The coverage of the serving cell may be different, e.g., because CCs on different frequency bands will experience different path losses. A primary serving cell or primary cell (PCell) may provide a primary cc (pcc) for both UL and DL and may handle Radio Resource Control (RRC) and non-access stratum (NAS) related activities. The other serving cells are referred to as secondary cells (scells), and each SCell may provide a separate secondary cc (scc) for both UL and DL. SCCs may be added and removed as needed, while changing the PCC may require the UE 101 to undergo handover. In LAA, eLAA, and feLAA, some or all scells may operate in unlicensed spectrum (referred to as "LAA scells"), and the LAA scells are assisted by pcells operating in licensed spectrum. When a UE is configured with more than one LAA SCell, the UE may receive a UL grant on the configured LAA SCell, the UL grant indicating different Physical Uplink Shared Channel (PUSCH) starting positions within the same subframe.

The Physical Downlink Shared Channel (PDSCH) may carry user data and higher layer signaling to the UE 101. A Physical Downlink Control Channel (PDCCH) may carry information on a transport format and resource allocation related to a PDSCH channel, and the like. It may also inform the UE 101 of transport format, resource allocation and H-ARQ (hybrid automatic repeat request) information related to the uplink shared channel. In general, downlink scheduling (allocation of control and shared channel resource blocks to UEs 101b within a cell) may be performed at any RAN node 111 based on channel quality information fed back from any UE 101. The downlink resource allocation information may be sent on a PDCCH for (e.g., allocated to) each UE 101.

The PDCCH may use Control Channel Elements (CCEs) to convey control information. The PDCCH complex-valued symbols may first be organized into quadruplets before mapping to resource elements, which may then be permuted using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements called Resource Element Groups (REGs). Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH may be transmitted using one or more CCEs, depending on the size of Downlink Control Information (DCI) and channel conditions. Four or more different PDCCH formats with different numbers of CCEs may be defined in LTE (e.g., aggregation level, L ═ 1, 2, 4, or 8).

Some embodiments may use the concept of resource allocation for control channel information, which is an extension of the above-described concept. For example, some embodiments may use an Enhanced Physical Downlink Control Channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more Enhanced Control Channel Elements (ECCEs). Similar to the above, each ECCE may correspond to nine sets of four physical resource elements referred to as Enhanced Resource Element Groups (EREGs). In some cases, ECCE may have other numbers of EREGs.

The RAN nodes 111 may be configured to communicate with each other via an interface 112. In embodiments where system 100 is an LTE system, interface 112 may be an X2 interface 112. An X2 interface may be defined between two or more RAN nodes 111 (e.g., two or more enbs, etc.) connected to the EPC 120 and/or two enbs connected to the EPC 120. In some implementations, the X2 interfaces can include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide a flow control mechanism for user data packets transmitted over the X2 interface and may be used to communicate information about user data transfer between enbs. For example, X2-U may provide specific sequence number information for user data transmitted from a master enb (menb) to a secondary enb (senb); information on successful in-order transmission of PDCP PDUs for user data from the SeNB to the UE 101; information of PDCP PDUs not delivered to the UE 101; information on a current minimum required buffer size at the SeNB for transmitting user data to the UE; and so on. X2-C may provide intra-LTE access mobility functions including context transfer from source eNB to target eNB, user plane transfer control, etc.; a load management function; and an inter-cell interference coordination function.

In embodiments where system 100 is a 5G or NR system, interface 112 may be an Xn interface 112. An Xn interface is defined between two or more RAN nodes 111 (e.g., two or more gnbs, etc.) connected to the 5GC 120, between a RAN node 111 (e.g., a gNB) connected to the 5GC 120 and an eNB, and/or between two enbs connected to the 5GC 120. In some implementations, the Xn interface can include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U can provide unsecured transport of user plane PDUs and support/provide data forwarding and flow control functionality. Xn-C may provide: management and error handling functions; managing the function of the Xn-C interface; mobility support for a UE 101 in CONNECTED mode (e.g., CM-CONNECTED) includes functionality to manage CONNECTED mode UE mobility between one or more RAN nodes 111. Mobility support may include context transfer from the old (source) serving RAN node 111 to the new (target) serving RAN node 111; and control of user plane tunnels between the old (source) serving RAN node 111 and the new (target) serving RAN node 111. The protocol stack of the Xn-U may include a transport network layer established above an Internet Protocol (IP) transport layer and a GTP-U layer above UDP(s) and/or IP layers for carrying user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol, referred to as the Xn application protocol (Xn-AP), and a transport network layer built over SCTP. SCTP can be located above the IP layer and can provide guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transport is used to deliver signaling PDUs. In other implementations, the Xn-U protocol stack and/or the Xn-C protocol stack may be the same as or similar to the user plane and/or control plane protocol stack(s) shown and described herein.

RAN110 is shown communicatively coupled to a core network, in this embodiment, Core Network (CN) 120. CN120 may include a plurality of network elements 122 configured to provide various data and telecommunications services to clients/subscribers (e.g., users of UE 101) connected to CN120 through RAN 110. The term "network element" may describe a physical or virtualized device used to provide wired or wireless communication network services. The term "network element" may be considered synonymous with and/or referred to as: a networking computer, network hardware, network device, router, switch, hub, bridge, radio network controller, radio access network device, gateway, server, Virtualized Network Function (VNF), Network Function Virtualization Infrastructure (NFVI), and/or the like. The components of CN120 may be implemented in one physical node or separate physical nodes, including components that read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, Network Function Virtualization (NFV) may be used to virtualize any or all of the above network node functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). Logical instantiations of the CN120 may be referred to as network slices, and logical instantiations of a portion of the CN120 may be referred to as network subslices. The NFV architecture and infrastructure may be used to virtualize one or more network functions or be executed by dedicated hardware onto physical resources including a combination of industry standard server hardware, storage hardware, or switches. In other words, the NFV system may be used to perform a virtual or reconfigurable implementation of one or more EPC components/functions.

In general, the application server 130 may be an element that provides applications that use IP bearer resources with a core network (e.g., UMTS Packet Service (PS) domain, LTE PS data services, etc.). The application server 130 may also be configured to support one or more communication services (e.g., voice over internet protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UE 101 via the EPC 120.

In an embodiment, the CN120 may be a 5GC (referred to as "5 GC 120" or the like), and the RAN110 may be connected with the CN120 via the NG interface 113. In an embodiment, the NG interface 113 may be divided into two parts: a NG user plane (NG-U) interface 114 that carries traffic data between RAN node 111 and User Plane Functions (UPFs); and S1 control plane (NG-C) interface 115, which is a signaling interface between RAN node 111 and the AMF.

In an embodiment, the CN120 may be a 5G CN (referred to as "5 GC 120," etc.), while in other embodiments, the CN120 may be an Evolved Packet Core (EPC). In the case where CN120 is an EPC (referred to as "EPC 120," etc.), RAN110 may connect with CN120 via S1 interface 113. In an embodiment, the S1 interface 13 may be divided into two parts: an S1 user plane (S1-U) interface 114, which carries traffic data between the RAN node 111 and the serving gateway (S-GW); and S1-Mobility Management Entity (MME) interface 115, which is a signaling interface between RAN node 111 and the MME.

Fig. 2 illustrates an example architecture of a system 200 including a 5GC 220 according to some embodiments of the present disclosure.

The system 200 is shown as including: a UE 201, which may be the same as or similar to the UE 101 previously discussed; (R) AN 210, which may be the same as or similar to RAN110 discussed previously, and which may include RAN node 111 discussed previously; and a Data Network (DN)203, which may be, for example, an operator service, internet access, or third party service; and a 5G core network (5GC or CN) 220.

The 5GC 220 may include an authentication server function (AUSF) 222; an access and mobility management function (AMF) 221; a Session Management Function (SMF) 224; a Network Exposure Function (NEF) 223; a Policy Control Function (PCF) 226; a Network Function (NF) repository function (NRF) 225; unified Data Management (UDM) 227; an Application Function (AF) 228; a User Plane Function (UPF) 202; and a Network Slice Selection Function (NSSF) 229.

The UPF 202 may serve as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session interconnect point to the DN 203, and a branch point to support multi-homed PDU sessions. The UPF 202 may also perform packet routing and forwarding, packet inspection, perform policy rules for the user plane part, lawful intercept packets (UP set), traffic usage reporting, perform QoS processing on the user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF to QoS traffic mapping), transport level packet marking in uplink and downlink, and downlink packet buffering and downlink data notification triggering. The UPF 202 may include an uplink classifier to support routing of traffic flows to a data network. DN 203 may represent various network operator services, internet access, or third party services. The DN 203 may include or be similar to the application server 130 previously discussed. The UPF 202 may interact with the SMF 224 via an N4 reference point between the SMF 224 and the UPF 202.

The AUSF222 may store data for authentication of the UE 201 and process authentication related functions. The AUSF222 may facilitate a common authentication framework for various access types. The AUSF222 may communicate with the AMF221 via an N12 reference point between the AMF221 and the AUSF 222; and may communicate with UDM 227 via an N13 reference point between UDM 227 and AUSF 222. Additionally, the AUSF222 may expose a Nausf service based interface.

The AMF221 may be responsible for registration management (e.g., for registering the UE 201, etc.), connection management, reachability management, mobility management, and lawful interception of AMF-related events, as well as access authentication and authorization. The AMF221 may be the termination point of the N11 reference point between the AMF221 and the SMF 224. The AMF221 may provide transport for Session Management (SM) messages between the UE 201 and the SMF 224 and act as a transparent proxy for routing SM messages. The AMF221 may also provide for transmission of Short Message Service (SMS) messages between the UE 201 and an SMS function (SMSF) (not shown in fig. 2). The AMF221 may act as a security anchor function (SEA), which may include interactions with the AUSF222 and the UE 201, receiving intermediate keys established as a result of the UE 201 authentication procedure. In the case of using USIM-based authentication, the AMF221 may acquire security materials from the AUSF 222. The AMF221 may also include a Security Context Management (SCM) function that receives keys from the SEA that it uses to derive access network-specific keys. Further, the AMF221 may be a termination point of the RAN CP interface, which may include or be AN N2 reference point between the (R) AN 211 and the AMF 221; the AMF221 may be the termination point of NAS (N1) signaling and perform NAS ciphering and integrity protection.

The AMF221 may also support NAS signaling with the UE 201 through an N3 interworking function (IWF) interface. An N3IWF may be used to provide access to untrusted entities. The N3IWF may be the termination point of the N2 interface between the (R) AN 210 and the AMF221 for the control plane and may be the termination point of the N3 reference point between the (R) AN 210 and the UPF 202 for the user plane. As such, AMF221 may process N2 signaling from SMF 224 and AMF221 for PDU sessions and QoS, encapsulate/decapsulate packets for IPSec and N3 tunneling, label N3 user plane packets in the uplink, and perform QoS corresponding to N3 packet labeling, which takes into account QoS requirements associated with such labels received over N2. The N3IWF may also relay uplink and downlink control plane NAS signaling between the UE 201 and the AMF221 via the N1 reference point between the UE 201 and the AMF221, and uplink and downlink user plane packets between the UE 201 and the UPF 202. The N3IWF also provides a mechanism to establish an IPsec tunnel with the UE 201. The AMF221 may expose a Namf service based interface and may be a termination point of an N14 reference point between two AMFs 221 and an N17 reference point between the AMF221 and a 5G device identification register (5G-EIR) (not shown in fig. 2).

The UE 201 may need to register with the AMF221 to receive network services. The Registration Management (RM) is used to register or deregister the UE 201 with the network (e.g., the AMF 221) and establish a UE context in the network (e.g., the AMF 221). The UE 201 may operate in an RM registration state or an RM deregistration state. In the RM deregistered state, the UE 201 is not registered with the network and the UE context in the AMF221 does not maintain valid location or routing information for the UE 201, so the AMF221 cannot reach the UE 201. In the RM registration state, the UE 201 registers with the network, and the UE context in the AMF221 may maintain valid location or routing information of the UE 201 so that the UE 201 may be reached by the AMF 221. In the RM registration state, the UE 201 may perform a mobility registration update procedure, perform a periodic registration update procedure triggered by the expiration of a periodic update timer (e.g., to inform the network that the UE 201 is still active), and perform a registration update procedure to update UE capability information or renegotiate protocol parameters with the network, etc.

The AMF221 may store one or more RM contexts for the UE 201, where each RM context is associated with a particular access to the network. The RM context may be a data structure, database object, etc. that indicates or stores registration status and periodic update timers, etc. for each access type. The AMF221 may also store a 5GC MM context, which may be the same as or similar to the (E) MM context previously discussed. In various embodiments, AMF221 may store the CE mode B restriction parameters for UE 201 in the associated MM context or RM context. The AMF221 may also derive this value from the UE's usage setting parameters already stored in the UE context (and/or MM/RM context) when needed.

The Connection Management (CM) may be used to establish and release a signaling connection between the UE 201 and the AMF221 through the N1 interface. The signaling connection is used to enable NAS signaling exchange between UE 201 and CN120 and includes AN Access Network (AN) signaling connection (e.g., RRC connection or UE-N3IWF connection for non-3 GPP) between the UE and the AN and AN N2 connection for UE 201 between the AN (e.g., RAN 210) and AMF 221. The UE 201 may operate in one of two CM states: a CM-IDLE (CM-IDLE) mode or a CM-CONNECTED (CM-CONNECTED) mode. When the UE 201 is operating in the CM-IDLE state/mode, the UE 201 may not have AN NAS signaling connection established with the AMF221 over the N1 interface, and there may be AN (R) AN 210 signaling connection (e.g., AN N2 and/or N3 connection) for the UE 201. When the UE 201 operates in the CM-CONNECTED state/mode, the UE 201 may have AN NAS signaling connection established with the AMF221 through the N1 interface, and there may be AN (R) AN 210 signaling connection (e.g., N2 and/or N3 connection) for the UE 201. Establishing AN N2 connection between the (R) AN 210 and the AMF221 may cause the UE 201 to transition from CM-IDLE mode to CM-CONNECTED mode, and when releasing N2 signaling between the (R) AN 210 and the AMF221, the UE 201 may transition from CM-CONNECTED mode to CM-IDLE mode.

The SMF 224 may be responsible for: session Management (SM) (e.g., session establishment, modification, and release, including tunnel maintenance between UPF and AN nodes); UE IP address assignment and management (including optional authorization); selecting and controlling the UP function; configuring traffic steering at the UPF to route traffic to the correct destination; terminating the interface to the policy control function; controlling a portion of policy enforcement and QoS; lawful interception (for SM events and interface with LI system); NAS message terminating SM part; a downlink data notification; the originator of the AN specific SM message, sent to the AN through N2 via AMF; the SSC pattern for the session is determined. SM may refer to the management of a PDU session, which may refer to a PDU connection service that provides or enables the exchange of PDUs between the UE 201 and a Data Network (DN)203 identified by a Data Network Name (DNN). The PDU session may be established upon request of the UE 201, modified upon request of the UE 201 and 5GC 220, and released upon request of the UE 201 and 5GC 220 using NAS SM signaling exchanged over the N1 reference point between the UE 201 and SMF 224. The 5GC 220 may trigger a specific application in the UE 201 based on a request from an application server. In response to receiving the trigger message, the UE 201 may communicate the trigger message (or related portion/information of the trigger message) to one or more identified applications in the UE 201. The identified application(s) in the UE 201 may establish a PDU session to a particular DNN. The SMF 224 may check whether the UE 201 request conforms to the user subscription information associated with the UE 201. In this regard, the SMF 224 may retrieve and/or request to receive update notifications from the UDM 227 regarding SMF 224 level subscription data.

SMF 224 may include the following roaming functions: processing the local enforcement to apply a QoS SLA (VPLMN); a charging data collection and charging interface (VPLMN); lawful interception (in the interface of VPLMN and LI systems for SM events); interaction with the foreign DN is supported to transmit signaling of PDU session authorization/authentication through the foreign DN. An N16 reference point between two SMFs 224 may be included in the system 200, which may be between another SMF 224 in the visited network and the SMF 224 in the home network in a roaming scenario. Additionally, the SMF 224 may expose an Nsmf service based interface.

NEF223 may provide a means for securely exposing services and capabilities provided by 3GPP network functions for third parties, internal exposure/re-exposure, application functions (e.g., AF 228), edge computing or fog computing systems, and the like. In such embodiments, NEF223 may authenticate, authorize, and/or limit AF. NEF223 may also translate information exchanged with AF 228 and information exchanged with internal network functions. For example, the NEF223 may convert between the AF service identifier and the internal 5GC information. NEF223 may also receive information from other Network Functions (NFs) based on exposed capabilities of the other network functions. This information may be stored as structured data in the NEF223 or in the data storage NF using a standardized interface. The stored information may then be re-exposed by the NEF223 to other NFs and AFs, and/or used for other purposes, such as analysis. In addition, NEF223 may expose an interface based on the Nnef service.

NRF 225 may support a service discovery function, receive NF discovery requests from NF instances, and provide information of discovered NF instances to NF instances. NRF 225 also maintains information of available NF instances and the services it supports. As used herein, the term "instantiation" or the like may refer to the creation of an instance, and "instance" may refer to the specific occurrence of an object, which may occur, for example, during execution of program code. Additionally, NRF 225 may expose an interface based on the Nnrf service.

PCF 226 may provide policy rules to control plane function(s) to enforce them, and may also support a unified policy framework to manage network behavior. PCF 226 may also implement a Front End (FE) to access subscription information related to policy decisions in the UDR of UDM 227. PCF 226 may communicate with AMF221 via an N15 reference point between PCF 226 and AMF221, which may include PCF 226 in a visited network and AMF221 in a roaming scenario. PCF 226 may communicate with AF 228 via an N5 reference point between PCF 226 and AF 228; and communicates with the SMF 224 via an N7 reference point between the PCF 226 and the SMF 224. The system 200 and/or CN120 may also include an N24 reference point between the PCF 226 (in the home network) and the PCF 226 in the visited network. In addition, PCF 226 may expose an interface based on Npcf services.

UDM 227 may process subscription related information to support processing of communication sessions by network entities and may store subscription data for UE 201. For example, subscription data may be transmitted between UDM 227 and AMF221 over an N8 reference point (not shown in fig. 2) between UDM 227 and AMF 221. UDM 227 may include two parts: an application FE and a User Data Repository (UDR) (the FE and UDR are not shown in fig. 2). The UDR may store subscription data and policy data for UDM 227 and PCF 226, and/or structured data and application data for exposure (including Packet Flow Description (PFD) for application detection, application request information for multiple UEs 201) for NEF 223. UDR 221 may expose an Nudr service-based interface to allow UDM 227, PCF 226 and NEF223 to access a particular set of stored data, as well as read, update (e.g., add, modify), delete and subscribe to notifications of relevant data changes in the UDR. The UDM may include a UDM FE that is responsible for credential handling, location management, subscription management, and the like. Several different front ends may serve the same user in different transactions. The UDM-FE accesses the subscription information stored in the UDR and executes authentication credential processing; user identification processing; access authorization; registration/mobility management; and subscription management. The UDR may interact with the SMF 224 via the N10 reference point between the UDM 227 and the SMF 224. UDM 227 may also support SMS management, where an SMS-FE implements similar application logic as previously described. In addition, UDM 227 may expose a numm service based interface.

The AF 228 can provide application impact on traffic routing, access Network Capability Exposure (NCE), and interact with the policy framework for policy control. The NCE may be a mechanism that allows the 5GC 220 and AF 228 to provide information to each other via the NEF223, which may be used for edge computing implementations. In such implementations, network operator and third party services may be hosted near the UE 201 access connection point to achieve efficient service delivery with reduced end-to-end delay and load on the transport network. For an edge calculation implementation, the 5GC may select a UPF 202 close to the UE 201 and perform traffic steering from the UPF 202 to the DN 203 via the N6 interface. This may be based on UE subscription data, UE location and information provided by the AF 228. In this way, the AF 228 may affect UPF (re) selection and traffic routing. Based on operator deployment, the network operator may allow the AF 228 to interact directly with the relevant NFs when the AF 228 is considered a trusted entity. In addition, the AF 228 may expose a Naf service-based interface.

NSSF 229 may select a set of network slice instances that serve UE 201. NSSF 229 may also determine allowed Network Slice Selection Assistance Information (NSSAI) and a mapping to a single NSSAI (S-NSSAI) of the subscription, if needed. The NSSF 229 may also determine a set of AMFs or a list of candidate AMFs 221 for serving the UE 201 based on a suitable configuration and possibly by querying the NRF 225. The selection of a set of network slice instances for the UE 201 may be triggered by the AMF221 (which registers the UE 201 by interacting with the NSSF 229), which may result in a change in the AMF 221. NSSF 229 may interact with AMF221 via the N22 reference point between AMF221 and NSSF 229; and may communicate with another NSSF 229 in the visited network over an N31 reference point (not shown in fig. 2). Additionally, NSSF 229 may expose an interface based on the NSSF service.

As previously described, the 5GC 220 may include an SMSF, which may be responsible for SMS subscription checking and verification, and relaying SM messages to/from the UE 201 from/to other entities, such as SMS-GMSC/IWMSC/SMS router. The SMS may also interact with AMF221 and UDM 227 for notification procedures that UE 201 may use for SMS delivery (e.g., set a UE unreachable flag, and notify UDM 227 when UE 201 is available for SMS).

The 5GC 220 may also include other elements not shown in fig. 2, such as a data storage system/architecture, a 5G device identity register (5G-EIR), a Secure Edge Protection Proxy (SEPP), and so on. The data storage system may include a structured data storage network function (SDSF), an unstructured data storage network function (UDSF), and so forth. Any NF may store unstructured data into or retrieve unstructured data (e.g., UE context) from the UDSF via the N18 reference point (not shown in fig. 2) between any NF and the UDSF. The individual NFs may share a UDSF for storing their respective unstructured data, or the individual NFs may each have their own UDSF located at or near the individual NFs. Additionally, the UDSF may expose an interface based on the Nudsf service (not shown in fig. 2). The 5G-EIR may be a NF that checks the status of a permanent device identifier (PEI) to determine if a particular device/entity is blacklisted from the network; the SEPP may be a non-transparent proxy that performs topology hiding, message filtering and policing on the inter-PLMN control plane interface.

Additionally, there may be more reference points and/or service-based interfaces between NF services in the NF; however, these interfaces and reference points are omitted from fig. 2 for clarity. In one example, the 5GC 220 may include an Nx interface, which is an inter-CN interface between the MME and the AMF221 to enable interworking between the EPC and the 5GC 220. Other example interfaces/references these points may include an N5G-EIR service based interface exposed by 5G-EIR, an N27 reference point between the NRF in the visited network and the NRF in the home network; and an N31 reference point between the NSSF in the visited network and the NSSF in the home network.

The 5GC 220 may include a Location Management Function (LMF) (not shown in fig. 2), which may communicate with the (R) AN 210 and/or the UE 201 via the AMF 221. The LMF may manage support for different location services for target UEs (e.g., UE 101 and UE 201), including positioning of the UEs and communicating assistance data to the UEs. The LMF may interact with a serving gNB (e.g., (R) AN 210) for the target UE to obtain location measurements and/or positioning-related information for the UE, including uplink measurements by the gNB and downlink measurements by the UE (which are provided to the gNB). The LMF may interact with the target UE to communicate assistance data when requesting a particular location service or to obtain a location estimate when requesting a location estimate.

Most of the network elements shown in fig. 3 are described above with reference to fig. 2. Furthermore, the network element "Network Slice Specific Authentication and Authorization Function (NSSAAF)" supports network slice specific authentication and authorization with an authentication, authorization, and charging (AAA) server (AAA-S). NSSAAF may contact AAA-S through an AAA proxy (AAA-P) if the AAA-S belongs to a third party. NSSAAF provides NSSAA service to the supplicant NF by relaying messages to the AAA-S or AAA-P and performing relevant protocol conversions as needed. It also provides notification to the current AMF that re-authentication and re-authorization of the UE or revocation of UE authorization is required. NSSAAF may expose a service-based interface, NSSAAF.

In some embodiments, the 5GS architecture of fig. 3 may be understood with reference to the architecture of 3GPP TS 23.501V16.6.0 (2020-09). However, the present disclosure is not limited in this respect.

As shown in fig. 4, the Edge Data Network (EDN) is a local data network. An Edge Application Server (EAS) and an Edge Enabler Server (EES) are included in the EDN. An Edge Configuration Server (ECS) provides configurations related to the EES, including details of the edge data network hosting the EES. The UE includes an Application Client (AC) and an Edge Enabler Client (EEC). The EAS(s), EES, and ECS may interact with a 3GPP core network (e.g., 5 GC).

The EES may provide the support functions required for EAS and EEC. The EEC may provide the support functions required by the AC. The ECS may provide the support functions required for the EEC to connect with the EES. The AC is an application residing in the UE that performs the client function. EAS is an application server residing in the EDN for performing server functions. The AC is connected to the EAS to take advantage of the services of the application with marginal computing advantages.

The EDGE-1 reference point may enable interaction between the EES and the EEC. The EDGE-2 reference point may enable interaction between the EES and the 3GPP core network. The EDGE-3 reference point may enable interaction between the EES and the EAS. The EDGE-4 reference point may enable interaction between the ECS and the EEC. The EDGE-5 reference point may enable interaction between the AC(s) and the EEC. The EDGE-6 reference point may enable interaction between the ECS and EES. The EDGE-7 reference point may enable interaction between EAS and 3GPP core networks. The EDGE-8 reference point may enable interaction between ECS and 3GPP core networks. The EDGE-9 reference point can enable interaction between the two EES. An EDGE-9 reference point may be provided between EES within different EDNs or within the same EDN.

In some embodiments, the architecture of fig. 4 may be understood with reference to the architecture of 3GPP TS 23.558V1.1.0 (2020-10). However, the present disclosure is not limited in this respect.

Edge computing in a 5G environment involves services or capabilities provided by multiple service providers (providers) and entities in the form of business roles:

-an Application Service Provider (ASP) providing edge application services to subscribers;

-an Edge Computing Service Provider (ECSP) providing an edge data network environment (e.g. infrastructure and platform) and edge enabled services (e.g. EAS deployment, registration and discovery) to the ASP;

mobile Network Operator (MNO) provides 5GS capability to support edge computing.

In a deployment, there may be scenarios where a single enterprise supports one or more business roles, i.e., an enterprise may play a single business role or multiple business roles, e.g., an enterprise may play MNO-only roles, or both MNO and ESCP roles.

In a 5G environment, there may be multiple business models in terms of charging for edge computing between the service provider and the serviced entity, including business-to-consumer (B2C), business-to-business (B2B), and business-to-everything (B2X), such as but not limited to:

-end user charging:

ASP charges subscribers for the use of edge applications;

MNO charges subscriber for the use of 5GS capability to support edge computation;

-service provider charging:

MNO charge industry consumers (e.g. ECSP) in total for the 5GS capability provided to support edge computation, rather than for each individual subscriber;

ECSP charges ASP for edge-enabled services and/or resources (e.g., edge-enabled infrastructure resources).

Some problems with charging for 5GS capabilities supporting edge computation are described in 3GPP Technical Report (TR)28.804V16.0.1(2019-10), but no solution is provided therein. For example, some problems are listed below.

Problem 1: the charging information reported by the SMF needs to contain parameters of the association between the edge application that the user has accessed and the 5 GS.

Problem 2: the MNO is an inter-provider charging mechanism that charges its customers (e.g., ASP or ECSP) for the 5GS capabilities provided to support edge computing.

Edge computing is used to support the latency aspect of performance sensitive services, especially ultra-reliable and low latency communication (URLLC) services. The 5GS provides QoS control and delivery capabilities to support the performance requirements of edge computing. Therefore, charging for 5GS capability to support edge computation needs to take into account the actual delivered QoS.

Fig. 5 illustrates a flow diagram of a method 500 for charging for 5GS capability to support edge computing, according to some embodiments of the present disclosure. Method 500 may include steps 510 through 530. In some embodiments, method 500 may include more or fewer steps, as the present disclosure is not limited in this respect.

At 510, a charging data request for charging for 5GS capability supporting edge computing is encoded for transmission to a charging function (CHF). From the CHF side, the CHF decodes the charging data request.

At 520, in response to the charging data request, the charging data response received from the CHF is decoded for confirmation of the charging data request. From the CHF side, the CHF encodes the charging data response to confirm the charging data request.

At 530, charging for 5GS capability to support edge computation is performed with CHF.

Fig. 6 illustrates an example architecture for 5G data connectivity converged charging, in accordance with some embodiments of the present disclosure. Method 500 may be performed by SMF. As shown in fig. 6, SMF embeds a Charging Trigger Function (CTF) and communicates with CHF over interface Nchf.

In some embodiments, the SMF may generate charging events for CHF for Protocol Data Unit (PDU) connectivity convergence charging or just offline charging.

In some embodiments, the CTF may generate charging events for CHF for a converged online and offline charging process. Charging Data Record (CDR) generation may be performed by a CHF acting as a Charging Data Function (CDF), which communicates them to a Charging Gateway Function (CGF). Finally, the CGF creates CDR files and forwards them to the billing domain (Bd) through the Bd interface.

In some embodiments, the CGF is external and the CHF acting as a CDF may forward the CDRs to the CGF over the Ga interface. When using an external CGF, the CGF may also be used by other network elements, depending on the network design and the operator's decision.

In some embodiments, the CGF is integrated with only one internal interface between the CHF and CGF. In this case, the relationship between CHF and CGF is 1: 1. The integrated CGF may support Ga interfaces from other CDFs.

In some embodiments, the CGF may also be an integrated component of the BD. In this case the Bd interface does not exist, but instead is a proprietary solution inside the Bd.

In some embodiments, the charging data request sent by the SMF may include a parameter indicating charging for 5GS capability to support edge computing. The parameters may include: AF Charging Identifier (AF Charging Identifier); afchargidd; a Network Slice Instance Identifier (Network Slice Instance Identifier); an Application Identifier (appId); flowDescription; or ethFlowdescription.

In one embodiment, the parameter "AF charging identifier" (see 3GPP TS32.255 V16.6.1(2020-09) and 3GPP TS 29.512V17.0.0(2020-09)) or "afchargidd" (see 3GPP TS 29.512V17.0.0(2020-09)) may be used to associate the charging data request, the charging information, and/or the CHF record data (e.g., CDR) with the charging of the PDU session supporting the edge application.

The parameter "AF charging identifier" or "afchargidd" may be provided to the SMF in Policy and Charging Control (PCC) rules for one or more service flows and may be contained in "PDU Container Information" (PDU Container Information) provided in the charging data request sent by the SMF and/or in the CHF record data (e.g., CDR) sent by the CHF.

In one embodiment, the parameter "network slice instance identifier" (see 3GPP TS32.255 V16.6.1(2020-09)) may be used to associate the charging data request, the charging information and/or the CHF record data with the charging of the PDU session supporting the edge application.

The parameter "network slice instance identifier" may be included in "PDU Session Charging Information (PDU Session Charging Information)" and provided in the Charging data request transmitted by the SMF and/or the CHF record data (e.g., CDR) transmitted by the CHF. Each edge application is associated with a dedicated network slice, and the CHF is preconfigured with an association between a network slice identifier and the edge application.

In one embodiment, the parameter "application identifier" (see "appId" in 3GPP TS 29.512V17.0.0(2020-09)) may be used to associate the charging data request, the charging information, and/or the CHF record data (e.g., CDR) with the charging of the PDU session supporting the edge application.

The parameter "application identifier" may be provided to the SMF in the PCC rule for one or more service flows. Including this parameter in the charging data request sent by the SMF and/or in the CHF record data will enable the CHF to associate them with the edge application.

In one embodiment, the parameter "application identifier" may not always be provided in the PCC rule. In this case, the parameter "flowDescription" or "ethFlowDescription" (see "appId" in 3GPP TS 29.512V17.0.0(2020-09)) may be used to associate the charging data request, the charging information and/or the CHF record data with the charging of the PDU session supporting the edge application.

In one embodiment, the parameter "flowDescription" or "ethFlowDescription" may be provided to the SMF in a PCC rule for a service flow. Including this parameter in the charging data request sent by the SMF and/or in the CHF record data will enable the CHF to associate them with the edge application.

In one embodiment, a "flowDescription" or "ethFlowDescription" may not always be provided in a PCC rule. In this case, the parameter "application identifier" may be used to associate the charging data request, the charging information and/or the CHF record data with the charging of the PDU session supporting the edge application.

The description with reference to fig. 6 relates to end user charging for 5GS capability to support edge computation. The inter-provider charging related solution to support the 5GS capability of edge computation will be described below.

The method 500 may be performed by a management service (MnS) producer (producer) or a Charging Enabling Function (CEF) of a Public Land Mobile Network (PLMN), which will be described below with reference to fig. 7 and 8.

Fig. 7 illustrates an example architecture of 5G fused inter-provider charging supported by MnS producers of PLMNs, according to some embodiments of the present disclosure. As shown in fig. 7, MnS producers of the PLMNs embed the CTFs and communicate with the CHF over the Nchf interface.

Fig. 8 illustrates an example architecture for 5G converged inter-provider charging supported by CEF in accordance with some embodiments of the present disclosure. As shown in fig. 8, CEF may support converged inter-provider charging. MnS producers of PLMNs may provide services MnS for consumption by CEF.

MnS producers or CEFs of PLMNs support fused inter-provider charging of 5G capabilities provided to their customers (e.g., ASPs or ECSPs) to support edge computing based on total UL/DL data volume (e.g., Key Performance Indicators (KPIs)) such as total UL/DL data volume of PLMN transmissions related to edge applications.

In some embodiments, alternatively or additionally, the charging information is collected by the SMF, MnS producer of the PLMN, or CEF and provided to the CHF for charging for the 5GS capability to support edge calculation. In some embodiments, the charging information may include parameters to indicate charging for 5GS capabilities to support edge computing, such as the AF charging identifiers described above, afChargId, network slice instance identifiers, application identifiers, flowDescription, ethFlowDescription, and the like.

In some embodiments, the charging for the 5GS capability to support edge computing, including both end user charging and inter-provider charging, may be based on monitored quality of service (QoS).

The 5GS provides QoS control and delivery capabilities to support edge applications with sensitive performance requirements, especially in terms of latency (for URLLC services). The actual QoS provided by 5GS to support edge computation may be related to the charge for 5GS capability provided to the consumer (end user or industry consumer). For example, two end users consuming the same amount of data in the same PLMN for the same edge application may need to be charged differently for the monitored QoS, if they are provided differently.

QoS monitoring is supported per QoS flow on a per UE basis in 5GS to assist URLLC services (see 3GPP TS 23.501V16.6.0(2020-09), article 5.33.3.2). With this QoS monitoring mechanism, the SMF (and UPF) can monitor and calculate the packet delay (packet delay between PDU Session Anchor (PSA) UPF and UE) of the 5GS (belonging to URLLC class of service) supporting edge applications on a per QoS flow, per UE basis. This may enable end-user charging for 5GS capabilities based on monitored packet delays.

Furthermore, inter-provider charging for 5GS capability based on monitored packet delays may also be implemented by the management plane via MnS or CEF with: performance measure of UL/DL packet delay in 5GS as defined in 3GPP TS 28.552 V17.0.0(2020-09) (e.g. article 5.4.9, e.g. average packet delay between PSA UPF and UE), and KPI of average end-to-end (e2e) UL/DL delay of network slice as defined in 3GPP TS 28.554V17.0.0(2020-09) (article 6.3.1.8).

In some embodiments, smf (ctf) optionally supports fused charging and charging information reporting for each edge application based on the following criteria:

QoS monitored for packet delay (e.g. UL/DL packet delay in 5GS) (see 3GPP TS 23.501V16.6.0(2020-09), article 5.33.3.2).

In some embodiments, the QoS monitored by the MnS producer or CEF for the PLMN is related to the average or distribution of packet delays in the 5GS supporting edge applications. In some embodiments, the MnS producer or CEF of the PLMN supports fused inter-provider charging based on one or more of the following criteria:

performance measurements related to the average UL/DL packet delay between PSA UPF and UE (see 3GPP TS 28.552 V17.0.0(2020-09), clause 5.4.9);

KPIs related to average e2e UL/DL delay of network slices supporting edge applications (see 3GPP TS 28.554V17.0.0(2020-09), article 6.3.1.8).

In some embodiments, the SMF, MnS producer of the PLMN, or CEF may include a parameter indicating the monitored QoS in the charging data request or charging information.

The charging mechanism for the 5GS capability to support edge computation is described above. The scheme for charging for edge-enabled resources and services will be described in detail below.

Fig. 9 illustrates a flow diagram of a method 900 for charging of edge-enabled resources and services, according to some embodiments of the present disclosure. Method 900 may include steps 910 through 930. In some embodiments, method 900 may include more or fewer steps, as the present disclosure is not limited in this respect.

At 910, a charging data request is encoded for transmission to the CHF, the charging data request for charging for the edge-enabled resource or service. From the CHF side, the CHF decodes the charging data request.

At 920, in response to the charging data request, the charging data response received from the CHF is decoded for confirmation of the charging data request. From the CHF side, the CHF encodes the charging data response to confirm the charging data request.

At 930, charging for edge-enabled resources or services is performed with the CHF.

Fig. 10 illustrates an example architecture of 5G fused inter-provider charging supported by MnS producers of Edge Computing Service Providers (ECSPs) according to some embodiments of the disclosure. The method 900 may be performed by an MnS producer of ECSP. As shown in fig. 10, the MnS producer of ECSP embeds the CTF and communicates with CHF over interface Nchf.

Fig. 11 illustrates an example architecture for 5G converged inter-provider charging supported by CEF in accordance with some embodiments of the disclosure. The method 900 may be performed by a CEF. As shown in fig. 11, CEF may support converged inter-provider charging for edge-enabled resources and services. MnS producers of ECSPs can provide MnS as a service for consumption by CEF.

In some embodiments, the ECSP or CEF may provide resources and capabilities to the ASP to enable EAS to run in the EDN, such as, but not limited to: EDN environments and resources (e.g., virtual Central Processing Units (CPUs), virtual memory, virtual disks, and virtual network resources); an EAS deployment; EAS registration; (ii) EAS discovery; or EAS application context transfer. The present disclosure is not limited in this respect.

Based on the availability of quotas, the charging mechanism of the ECSP or CEF may authorize or deny requests for EAS deployment, EAS registration, EAS discovery, and EAS application context transfer.

In some embodiments, an EAS deployment may include, but is not limited to: an EAS instantiation; an EAS update; an EAS modification; or EAS termination. The present disclosure is not limited in this respect.

In some embodiments, the ECSP or CEF may charge the ASP for resources provided for enabling and supporting EAS(s). Such inter-provider charging may be based on the resources allocated to the EAS(s), the resources actually used by the EAS, or the amount of data transmitted/received to/from the EAS(s) over the virtual network. In some embodiments, the resources allocated to the EAS may include, but are not limited to: a virtual Central Processing Unit (CPU), virtual memory, virtual disk, or virtual network bandwidth. The present disclosure is not limited in this respect. In some embodiments, the resources actually used by the EAS may include, but are not limited to: a virtual CPU, a virtual memory, or a virtual disk. The present disclosure is not limited in this respect.

Fig. 12 illustrates an example architecture for 5G converged inter-provider charging supported by EES according to some embodiments of the disclosure. Method 900 may be performed by an EES. As shown in fig. 12, the EES may support converged inter-provider charging for edge-enabled resources and services. The EES embeds the CTF and communicates with CHF over interface Nchf.

In some embodiments, the EES may request authorization from the CHF for some procedures including, but not limited to: EAS registration, EAS discovery, and EAS application context transfer. The present disclosure is not limited in this respect.

The present disclosure provides a charging mechanism for charging of 5GS capabilities to support edge computing and charging of edge-enabled resources and services to flexibly support all possible business models of cooperation between MNOs and related service providers. In this way, industrialization and deployment of edge computing can be enhanced.

Fig. 13 illustrates an example of an infrastructure device 1300 according to various embodiments. The infrastructure device 1300 (or "system 1300") may be implemented as any entity or non-entity (e.g., service or function) described in this disclosure. In other examples, system 1300 may be implemented in or by a client, application server(s) 130, and/or any other elements/devices discussed herein. System 1300 may include one or more of the following: an application circuit 1305, a baseband circuit 1310, one or more radio front-end modules 1315, a memory 1320, a Power Management Integrated Circuit (PMIC) 1325, a power tee circuit 1330, a network controller 1335, a network interface connector 1340, a satellite positioning circuit 1345, and a user interface 1350. In some embodiments, device 1300 may include additional elements, such as memory/storage, a display, a camera, sensors, or input/output (I/O) interface elements. In other embodiments, the components described below may be included in more than one device (e.g., for some implementations, the circuitry may be included separately in more than one device).

As used herein, the term "circuitry" may refer to, be part of, or include hardware components such as the following configured to provide the described functionality: electronic circuits, logic circuits, processors (shared, dedicated, or group) and/or memories (shared, dedicated, or group), Application Specific Integrated Circuits (ASICs), field-programmable devices (FPDs) (e.g., field-programmable gate arrays (FPGAs), Programmable Logic Devices (PLDs), complex PLDs (complex PLDs, CPLDs), high-capacity PLDs (HCPLDs), structured ASICs, or System on Chip (socs)), Digital Signal Processors (DSPs), and so forth. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. Furthermore, the term "circuitry" may also refer to a combination of one or more hardware elements (or circuitry used in an electrical or electronic system) and program code for performing the functions of the program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

The terms "application circuitry" and/or "baseband circuitry" may be considered synonymous with "processor circuitry" and may be referred to as "processor circuitry". As used herein, the term "processor circuit" may refer to, be part of, or include circuitry that: the circuit is capable of sequentially and automatically performing a sequence of arithmetic or logical operations; and recording, storing and/or transmitting digital data. The term "processor circuit" may refer to one or more application processors, one or more baseband processors, physical Central Processing Units (CPUs), single-core processors, dual-core processors, tri-core processors, quad-core processors, and/or any other device capable of executing or otherwise manipulating computer-executable instructions, such as program code, software modules, and/or functional processes.

The application circuitry 1305 may include one or more Central Processing Unit (CPU) cores and one or more of: a cache memory, a Low Drop Out (LDO) regulator, an interrupt controller, a Serial Interface such as SPI, I2C, or a Universal programmable Serial Interface module, a Real Time Clock (RTC), a timer-counter including interval and watchdog timers, a Universal input/output (I/O or IO), a memory card controller such as a Secure Digital (SD)/multimedia card (MMC), a Universal Serial Bus (USB) Interface, a Mobile Industrial Processor Interface (MIPI) Interface, and a Joint Test Access Group (JTAG) Test Access port. By way of example, the application circuitry 1305 may include one or more Intels

Or

A processor; ultramicron semiconductor (Advanced Micro Devices, AMD)

A processor, an Accelerated Processing Unit (APU), or

A processor; and so on. In some embodiments, system 1300 may not utilize application circuitry 1305, but may instead include, for example, a dedicated processor/controller to process IP data received from the EPC or 5 GC.

Additionally or alternatively, the application circuitry 1305 may include circuitry such as (but not limited to) the following: one or more Field Programmable Devices (FPDs), such as Field Programmable Gate Arrays (FPGAs), etc.; programmable Logic Devices (PLDs), such as complex PLDs (cplds), high capacity PLDs (hcplds), and the like; ASICs, such as structured ASICs and the like; programmable soc (psoc); and so on. In such embodiments, the circuitry of the application circuitry 1305 may comprise a logic block or logic architecture, including other interconnected resources, that may be programmed to perform various functions, such as the processes, methods, functions, etc., of the various embodiments discussed herein. In such embodiments, the circuitry of the application circuitry 1305 may include storage units (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., Static Random Access Memory (SRAM), antifuse, etc.) for storing logic blocks, logic architectures, data, etc. in a lookup table (LUT), and so forth.

Baseband circuitry 1310 may be implemented, for example, as a solder-in substrate including one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits. Although not shown, baseband circuitry 1310 may include one or more digital baseband systems, which may be coupled to a CPU subsystem, an audio subsystem, and an interface subsystem via an interconnection subsystem. The digital baseband subsystem may also be coupled to the digital baseband interface and the mixed signal baseband subsystem via additional interconnect subsystems. Each interconnection subsystem may include a bus system, a point-to-point connection, a Network On Chip (NOC) fabric, and/or some other suitable bus or interconnection technology, such as those discussed herein. The audio subsystem may include digital signal processing circuitry, buffer memory, program memory, voice processing accelerator circuitry, data converter circuitry such as analog-to-digital and digital-to-analog converter circuitry, analog circuitry including one or more amplifiers and filters, and/or other similar components. In an aspect of the disclosure, the baseband circuitry 1310 may include protocol processing circuitry with one or more instances of control circuitry (not shown) to provide control functions for digital baseband circuitry and/or radio frequency circuitry (e.g., radio front end module 1315).

The user interface circuitry 1350 may include one or more user interfaces designed to enable user interaction with the system 1300 or peripheral component interfaces designed to enable interaction with peripheral components of the system 1300. The user interface may include, but is not limited to, one or more physical or virtual buttons (e.g., a reset button), one or more indicators (e.g., a Light Emitting Diode (LED)), a physical keyboard or keypad, a mouse, a touchpad, a touch screen, a speaker or other audio emitting device, a microphone, a printer, a scanner, a headset, a display screen or display device, and so forth. The peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a Universal Serial Bus (USB) port, an audio jack, a power supply interface, and the like.

The Radio Front End Module (RFEM)1315 may include a millimeter wave RFEM and one or more sub-millimeter wave Radio Frequency Integrated Circuits (RFICs). In some implementations, the one or more sub-millimeter wave RFICs may be physically separate from the millimeter wave RFEM. The RFIC may include a connection to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In alternative implementations, both millimeter-wave and sub-millimeter-wave radio functions may be implemented in the same physical radio front end module 1315. RFEM 1315 may include both millimeter wave and sub-millimeter wave antennas.

The memory circuitry 1320 may include one or more of the following: volatile memory including Dynamic Random Access Memory (DRAM) and/or Synchronous Dynamic Random Access Memory (SDRAM); and nonvolatile memory (NVM), including high speed electrically erasable memory (often referred to as flash memory), phase change random access memory (PRAM), Magnetoresistive Random Access Memory (MRAM), and the like, and may include data from one or more of the above-mentioned sources

And

three-dimensional (3D) cross-point (XPOI)NT) memory. Memory circuit 1320 may be implemented as one or more of a solder-in package integrated circuit, a socket memory module, and a plug-in memory card.

The PMIC 1325 may include a voltage regulator, a surge protector, a power alarm detection circuit, and one or more backup power sources such as a battery or a capacitor. The power alarm detection circuit may detect one or more of power down (under voltage) and surge (over voltage) conditions. Power tee circuit 1330 can provide power drawn from a network cable to provide both power supply and data connectivity to infrastructure device 1300 using a single cable.

The network controller circuit 1335 may provide connectivity to the network using a standard network interface protocol such as ethernet, GRE tunnel based ethernet, Multiprotocol Label Switching (MPLS) based ethernet, or some other suitable protocol. Network connectivity to/from the infrastructure device 1300 may be provided via network interface connector 1340 using a physical connection, which may be electrical (commonly referred to as a "copper interconnect"), optical, or wireless. Network controller circuitry 1335 may include one or more special purpose processors and/or FPGAs to communicate using one or more of the above-described protocols. In some implementations, the network controller circuit 1335 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

The positioning circuitry 1345 may include circuitry to receive and decode signals transmitted by one or more constellations of navigation satellites of a Global Navigation Satellite System (GNSS). Examples of Navigation Satellite constellations (or GNSS) may include the Global Positioning System (GPS) in the united states, the Global Navigation System (GLONASS) in russia, the galileo System in the european union, the beidou Navigation Satellite System in china, the regional Navigation System or GNSS augmentation System (e.g., Indian Constellation Navigation with Indian Navigation (ic), the Quasi-Zenith Satellite System (QZSS) in japan, the Satellite-Integrated Doppler orbit imaging and Radio Positioning (dorsi) in france, etc.), and so forth. The positioning circuitry 1345 may include various hardware elements (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, and so forth to facilitate communication over-the-air (OTA) communication) to communicate with components of a positioning network (e.g., navigation satellite constellation nodes).

Nodes or satellites of the navigation satellite constellation(s) ("GNSS nodes") may provide positioning services by continuously transmitting or broadcasting GNSS signals along a line of sight that may be used by GNSS receivers (e.g., positioning circuitry 1345 and/or positioning circuitry implemented by clients or the like) to determine their GNSS positions. The GNSS signals may include a pseudorandom code known to the GNSS receiver (e.g., a sequence of ones and zeros) and a message including a time of transmission ToT (e.g., a defined point in the pseudorandom code sequence) of code epochs and a GNSS node position at ToT. A GNSS receiver may monitor/measure GNSS signals transmitted/broadcast by multiple GNSS nodes (e.g., four or more satellites) and solve various equations to determine a corresponding GNSS location (e.g., spatial coordinates). The GNSS receiver also implements a clock that is generally less stable and accurate than the atomic clock of the GNSS node, and the GNSS receiver may use the measured GNSS signals to determine a deviation of the GNSS receiver from real time (e.g., a deviation of the GNSS receiver clock from the GNSS node time). In some embodiments, the Positioning circuitry 1345 may include a Micro-Technology for Positioning, Navigation, and Timing (Micro-PNT) IC that uses a master Timing clock to perform position tracking/estimation without GNSS assistance.

The GNSS receiver may measure the time of arrival (ToA) of GNSS signals from multiple GNSS nodes according to its own clock. The GNSS receiver may determine a time of flight (ToF) value for each received GNSS signal based on ToA and ToT, and may then determine a three-dimensional (3D) position and clock bias based on the ToF. The 3D location may then be converted to latitude, longitude, and altitude. The positioning circuitry 1345 may provide data to the application circuitry 1305, which may include one or more of location data or time data. The application circuitry 1305 may use the time data to synchronize operations with other devices.

The components shown in fig. 13 may communicate with each other using interface circuitry. As used herein, the term "interface circuit" may refer to, be part of, or include a circuit that supports the exchange of information between two or more components or devices. The term "interface circuit" may refer to one or more hardware interfaces, such as a bus, an input/output (I/O) interface, a peripheral component interface, a network interface card, and so forth. Any suitable bus technology may be used in various implementations, which may include any number of technologies, including Industry Standard Architecture (ISA), Extended ISA (EISA), Peripheral Component Interconnect (PCI), PCI express, or any number of other technologies. The bus may be a dedicated bus, such as used in SoC-based systems. Other bus systems may be included, such as an I2C interface, an SPI interface, a point-to-point interface, and a power bus, among others.

Fig. 14 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 one or more of the methodologies discussed herein, according to some example embodiments. In particular, fig. 14 shows a diagrammatic representation of hardware resources 1400 that includes one or more processors (or processor cores) 1410, one or more memory/storage devices 1420, and one or more communication resources 1430, each of which may be communicatively coupled via a bus 1440. Hardware resource 1400 may be part of any entity or non-entity (e.g., service or function) described in this disclosure. For embodiments utilizing node virtualization (e.g., NFV), hypervisor 1402 may be executed to provide an execution environment for one or more network slices/subslices to utilize hardware resources 1400.

Processor 1410, such as 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 Radio Frequency Integrated Circuit (RFIC), another processor, or any suitable combination thereof, may include, for example, processor 1412 and processor 1414.

The memory/storage 1420 may include main memory, disk storage, or any suitable combination thereof. Memory/storage 1420 may include, but is not limited to, any type of volatile or non-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 storage, and the like.

The communication resources 1430 may include interconnection or network interface components or other suitable devices to communicate with one or more peripherals 1404 or one or more databases 1406 via a network 1408. For example, the communication resources 1430 can include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular communication components, NFC components, bluetooth components (e.g., bluetooth low energy), Wi-Fi components, and other communication components.

The instructions 1450 may include software, programs, applications, applets, apps, or other executable code for causing at least any of the processors 1410 to perform any one or more of the methods discussed herein. The instructions 1450 may reside, completely or partially, within the processor 1410 (e.g., within a processor's cache memory), the memory/storage 1420, or any suitable combination thereof. Further, any portion of instructions 1450 may be communicated to hardware resource 1400 from any combination of peripherals 1404 or database 1406. Thus, the processor 1410, memory/storage 1420, peripherals 1404, and the memory of database 1406 are examples of computer-readable and machine-readable media.

Fig. 15 shows a diagram of a network 1500 in accordance with various embodiments of the present disclosure. The network 1500 may operate in a manner consistent with the 3GPP technical specifications for LTE or 5G/NR systems. However, the example embodiments are not limited in this respect, and the described embodiments may be applied to other networks, such as future 3GPP systems and the like, that benefit from the principles described herein.

The network 1500 may include a UE1502, which may include any mobile or non-mobile computing device designed to communicate with the RAN 1504 via an over-the-air connection. The UE1502 may be, but is not limited to, a smartphone, a tablet, a wearable computer device, a desktop computer, a laptop computer, an in-vehicle infotainment device, an in-vehicle entertainment device, an instrument cluster, a heads-up display device, an in-vehicle diagnostic device, a dashboard mobile device, a mobile data terminal, an electronic engine management system, an electronic/engine control unit, an electronic/engine control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a networked appliance, a machine-type communication device, an M2M or D2D device, an internet of things device, and/or the like.

In some embodiments, the network 1500 may include multiple UEs directly coupled to each other through edge link interfaces. The UE may be an M2M/D2D device that communicates using a physical side link channel (e.g., without limitation, a physical side link broadcast channel (PSBCH), a physical side link discovery channel (PSDCH), a physical side link shared channel (PSSCH), a physical side link control channel (PSCCH), a physical side link fundamental channel (PSFCH), etc.).

In some embodiments, the UE1502 can also communicate with the AP 1506 over an over-the-air connection. The AP 1506 may manage WLAN connections, which may be used to offload some/all network traffic from the RAN 1504. The connection between the UE1502 and the AP 1506 can be in accordance with any IEEE 802.13 protocol, wherein the AP 1506 can be a Wireless Fidelity

A router. In some embodiments, the UE1502, RAN 1504, and AP 1506 may utilize cellular WLAN aggregation (e.g., LTE-WLAN aggregation (LWA)/lightweight ip (lwip)). Cellular WLAN aggregation may involve a UE1502 configured by a RAN 1504 to utilize both cellular radio resources and WLAN resources.

The RAN 1504 can include one or more access nodes, e.g., AN 1508. The AN 1508 may terminate the air interface protocol of the UE1502 by providing access stratum protocols including RRC, Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), and L1 protocols. In this manner, the AN 1508 may enable data/voice connectivity between the CN 1520 and the UE 1502. In some embodiments, the AN 1508 may be implemented in a separate device or as one or more software entities running on a server computer, as part of a virtual network, for example, which may be referred to as a CRAN or pool of virtual baseband units. AN 1508 may be referred to as a Base Station (BS), a gNB, a RAN node, AN evolved node b (eNB), a next generation eNB (ng-eNB), a node b (nodeb), a roadside unit (RSU), a TRxP, a TRP, etc. The AN 1508 may be a macrocell base station or a low-power base station that provides a microcell, picocell, or other similar cell with a smaller coverage area, smaller user capacity, or higher bandwidth than a macrocell.

In embodiments where the RAN 1504 includes multiple ANs, they may be coupled to each other over AN X2 interface (in the case where the RAN 1504 is AN LTE RAN) or AN Xn interface (in the case where the RAN 1504 is a 5G RAN). The X2/Xn interface, which in some embodiments may be separated into a control plane interface/user plane interface, may allow the AN to communicate information related to handover, data/context transfer, mobility, load management, interference coordination, etc.

The AN of the RAN 1504 can manage one or more cells, groups of cells, component carriers, and/or the like, respectively, to provide AN air interface for network access to the UE 1502. The UE1502 can be simultaneously connected with multiple cells provided by the same or different ANs of the RAN 1504. For example, the UE1502 and RAN 1504 may use carrier aggregation to allow the UE1502 to connect with multiple component carriers, each corresponding to a primary cell (Pcell) or a secondary cell (Scell). In a dual connectivity scenario, the first AN may be a primary node providing a Master Cell Group (MCG) and the second AN may be a secondary node providing a Secondary Cell Group (SCG). The first/second AN can be any combination of eNB, gNB, ng-eNB, etc.

The RAN 1504 may provide an air interface over licensed or unlicensed spectrum. To operate in unlicensed spectrum, a node may use a Licensed Assisted Access (LAA), enhanced LAA (elaa), and/or further enhanced LAA (felaa) mechanism based on Carrier Aggregation (CA) technology with PCell/Scell. Prior to accessing the unlicensed spectrum, the node may perform a media/carrier sensing operation based on, for example, a Listen Before Talk (LBT) protocol.

In a vehicle-to-everything (V2X) scenario, the UE1502 or AN 1508 may be or act as a Road Side Unit (RSU), which may refer to any transport infrastructure entity for V2X communications. The RSU may be implemented in or by AN appropriate AN or stationary (or relatively stationary) UE. An RSU implemented in or by a UE may be referred to as a "UE-type RSU"; an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU"; RSUs implemented in the next generation nodeb (gNB) or by the gNB may be referred to as "gNB-type RSUs"; and so on. In one example, an RSU is a computing device coupled with radio frequency circuitry located at the roadside that provides connectivity support to passing vehicular 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 may provide very low latency communications required for high speed events, e.g., collision avoidance, traffic warnings, etc. Additionally or alternatively, the RSU may provide other cellular/WLAN communication services. The components of the RSU may be enclosed in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide a wired connection (e.g., ethernet) to a traffic signal controller or backhaul network.

In some embodiments, the RAN 1504 may be an LTE RAN 1510 including evolved node bs (enbs), e.g., eNB 1512. The LTE RAN 1510 may provide an LTE air interface with the following characteristics: SCS at 15 kHz; a CP-OFDM waveform for DL and an SC-FDMA waveform for UL; turbo codes for data and TBCC for control, etc. The LTE air interface may rely on CSI-RS for CSI acquisition and beam management; relying on a PDSCH/PDCCH demodulation reference signal (DMRS) for PDSCH/PDCCH demodulation; and relying on CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation/detection at the UE. The LTE air interface may operate over the sub-6 GHz band.

In some embodiments, RAN 1504 may be a Next Generation (NG) -RAN 1514 with a gNB (e.g., gNB 1516) or gn-eNB (e.g., NG-eNB 1518). The gNB 1516 may connect with the 5G-enabled UE using a 5G NR interface. The gNB 1516 may be connected to the 5G core through an NG interface, which may include an N2 interface or an N3 interface. The Ng-eNB 1518 may also connect with the 5G core over the Ng interface, but may connect with the UE over the LTE air interface. The gNB 1516 and ng-eNB 1518 may be connected to each other through an Xn interface.

In some embodiments, the NG interface may be divided into two parts, a NG user plane (NG-U) interface, which carries traffic data between nodes of the NG-RAN 1514 and the UPF 1548, and a NG control plane (NG-C) interface, which is a signaling interface (e.g., N2 interface) between the NG-RAN 1514 and nodes of the access and mobility management function (AMF) 1544.

The NG-RAN 1514 may provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM for UL, and DFT-s-OFDM; polarity, repetition, simplex, and Reed-Muller (Reed-Muller) codes for control, and LDPC for data. The 5G-NR air interface may rely on CSI-RS, PDSCH/PDCCH DMRS similar to the LTE air interface. The 5G-NR air interface may not use CRS, but may use PBCH DMRS for PBCH demodulation; performing phase tracking of the PDSCH using the PTRS; and time tracking using the tracking reference signal. The 5G-NR air interface may operate over the FR1 frequency band, which includes the sub-6 GHz band, or the FR2 frequency band, which includes the 24.25GHz to 52.6GHz band. The 5G-NR air interface may include SSBs, which are regions of a downlink resource grid including PSS/SSS/PBCH.

In some embodiments, the 5G-NR air interface may use BWP for various purposes. For example, BWP may be used for dynamic adaptation of SCS. For example, the UE1502 may be configured with multiple BWPs, where each BWP configuration has a different SCS. When the BWP is indicated to the UE1502 to change, the SCS of the transmission also changes. Another use case for BWP is related to power saving. In particular, the UE1502 may be configured with multiple BWPs having different numbers of frequency resources (e.g., PRBs) to support data transmission in different traffic load scenarios. BWPs containing a smaller number of PRBs may be used for data transmission with smaller traffic load while allowing power savings at the UE1502 and, in some cases, the gNB 1516. BWPs containing a large number of PRBs may be used in scenarios with higher traffic loads.

The RAN 1504 is communicatively coupled to a CN 1520, which includes network elements, to provide various functions to support data and telecommunications services to customers/subscribers (e.g., users of the UE 1502). The components of the CN 1520 may be implemented in one physical node or in different physical nodes. In some embodiments, NFV may be used to virtualize any or all of the functionality provided by the network elements of CN 1520 onto physical computing/storage resources in servers, switches, and the like. A logical instance of a CN 1520 may be referred to as a network slice, and a logical instantiation of a portion of the CN 1520 may be referred to as a network subslice.

In some embodiments, the CN 1520 may be an LTE CN 1522, which may also be referred to as an Evolved Packet Core (EPC). The LTE CN 1522 may include a Mobility Management Entity (MME)1524, a Serving Gateway (SGW)1526, a Serving GPRS Support Node (SGSN)1528, a Home Subscriber Server (HSS)1530, a Proxy Gateway (PGW)1532, and a policy control and charging rules function (PCRF)1534, which are coupled to each other by an interface (or "reference point") as shown. The functions of the elements of LTE CN 1522 may be briefly introduced as follows.

The MME 1524 may implement mobility management functions to track the current location of the UE1502 to facilitate patrol, bearer activation/deactivation, handover, gateway selection, authentication, and so forth.

The SGW 1526 may terminate the S1 interface towards the RAN and route data packets between the RAN and the LTE CN 1522. SGW 1526 may be a local mobility anchor for inter-RAN node handovers and may also provide an anchor for inter-3 GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

The SGSN 1528 may track the location of the UE1502 and perform security functions and access control. In addition, SGSN 1528 may perform EPC inter-node signaling for mobility between different RAT networks; PDN and S-GW selection specified by MME 1524; MME selection for handover, etc. An S3 reference point between the MME 1524 and the SGSN 1528 may enable user and bearer information exchange for inter-3 GPP access network mobility in idle/active state.

The HSS 1530 may comprise a database for network users comprising subscription related information that supports network entities handling communication sessions. The HSS 1530 may provide support for routing/roaming, authentication, licensing, naming/addressing resolution, location dependencies, etc. An S6a reference point between the HSS 1530 and the MME 1524 may enable the transmission of subscription and authentication data to authenticate/grant a user access to the LTE CN 1520.

PGW 1532 may terminate the SGi interface towards a Data Network (DN)1536, which may include an application/content server 1538. PGW 1532 may route data packets between LTE CN 1522 and data network 1536. PGW 1532 may be coupled with SGW 1526 through S5 reference points to facilitate user plane tunneling and tunnel management. PGW 1532 may also include nodes (e.g., PCEFs) for policy enforcement and charging data collection. Additionally, the SGi reference point between PGW 1532 and data network 1536 may be, for example, an operator external public, private PDN, or operator internal packet data network for providing IMS services. PGW 1532 may be coupled with PCRF 1534 via a Gx reference point.

The PCRF 1534 is a policy and charging control element of the LTE CN 1522. The PCRF 1534 can be communicatively coupled to the application/content server 1538 to determine appropriate QoS and charging parameters for a service flow. The PCRF 1532 may provide the associated rules to the PCEF (via the Gx reference point) with the appropriate TFT and QCI.

In some embodiments, CN 1520 may be a 5G core network (5GC) 1540. 5GC 1540 may include an authentication server function (AUSF)1542, an access and mobility management function (AMF)1544, a Session Management Function (SMF)1546, a User Plane Function (UPF)1548, a Network Slice Selection Function (NSSF)1550, a network open function (NEF)1552, an NF storage function (NRF)1554, a Policy Control Function (PCF)1556, a Unified Data Management (UDM)1558, and an Application Function (AF)1560, which are coupled to each other by an interface (or "reference point") as shown. The functions of the elements of the 5GC 1540 can be briefly described as follows.

The AUSF 1542 may store data for authentication of the UE1502 and handle authentication related functions. AUSF 1542 may facilitate a common authentication framework for various access types. The AUSF 1542 may exhibit a Nausf service based interface in addition to communicating with other elements of the 5GC 1540 through reference points as shown.

The AMF 1544 may allow other functions of the 5GC 1540 to communicate with the UE1502 and the RAN 1504 and subscribe to notifications about mobility events of the UE 1502. The AMF 1544 may be responsible for registration management (e.g., registering the UE 1502), connection management, reachability management, mobility management, lawful interception of AMF related events, and access authentication and permission. AMF 1544 may provide for the transmission of Session Management (SM) messages between UE1502 and SMF 1546 and act as a transparent proxy for routing SM messages. The AMF 1544 may also provide for transmission of SMS messages between the UE1502 and the SMSF. AMF 1544 may interact with AUSF 1542 and UE1502 to perform various security anchoring and context management functions. Further, AMF 1544 may be a termination point of the RAN CP interface, which may include or be an N2 reference point between RAN 1504 and AMF 1544; the AMF 1544 may act as a termination point for NAS (N1) signaling and perform NAS ciphering and integrity protection. The AMF 1544 may also support NAS signaling with the UE1502 over the N3IWF interface.

The SMF 1546 may be responsible for SM (e.g., session establishment, tunnel management between UPF 1548 and AN 1508); UE IP address assignment and management (including optional permissions); selection and control of the UP function; configuring flow control at the UPF 1548 to route traffic to an appropriate destination; termination of the interface to the policy control function; controlling a portion of policy enforcement, charging, and QoS; lawful interception (for SM events and interface to the LI system); terminate the SM portion of the NAS message; a downlink data notification; initiating AN-specific SM message (sent to AN 1508 over N2 through AMF 1544); and determining an SSC pattern for the session. SM may refer to management of PDU sessions, and a PDU session or "session" may refer to a PDU connectivity service that provides or enables exchange of PDUs between the UE1502 and the data network 1536.

The UPF 1548 may serve as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point interconnected with the data network 1536, and a branch point to support multi-homed PDU sessions. The UPF 1548 may also perform packet routing and forwarding, perform packet inspection, perform user plane part of policy rules, lawful intercepted packets (UP collection), perform traffic usage reporting, perform QoS processing for the user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF to QoS flow mapping), transport level packet marking in uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. The UPF 1548 may include an uplink classifier to support routing of traffic flows to a data network.

The NSSF 1550 can select a set of network slice instances that serve the UE 1502. The NSSF 1550 may also determine allowed Network Slice Selection Assistance Information (NSSAI) and mapping to the subscribed individual NSSAI (S-NSSAI), if desired. The NSSF 1550 may also determine a set of AMFs to be used to serve the UE1502, or determine a list of candidate AMFs, based on a suitable configuration and possibly by querying the NRF 1554. Selection of a set of network slice instances for the UE1502 may be triggered by the AMF 1544 (with which the UE1502 registers by interacting with the NSSF 1550), which may result in a change in the AMF. NSSF 1550 may interact with AMF 1544 via the N22 reference point; and may communicate with another NSSF in the visited network via an N31 reference point (not shown). Further, NSSF 1550 may expose an interface based on the NSSF service.

NEF1552 may securely expose services and capabilities provided by 3GPP network functions for third parties, internal disclosure/re-disclosure, AFs (e.g., AF 1560), edge computing or fog computing systems, and the like. In these embodiments, NEF1552 may authenticate, license, or throttle AFs. NEF1552 may also translate information exchanged with AF1560 and information exchanged with internal network functions. For example, the NEF1552 may translate between the AF service identifier and the internal 5GC information. NEF1552 may also receive information from other NFs based on their public capabilities. This information may be stored as structured data at NEF1552 or at data store NF using a standardized interface. NEF1552 may then re-disclose the stored information to other NFs and AFs, or for other purposes such as analysis. Additionally, NEF1552 may expose an interface based on the Nnef service.

NRF 1554 may support a service discovery function, receive NF discovery requests from NF instances, and provide information of discovered NF instances to NF instances. NRF 1554 also maintains information of available NF instances and their supported services. As used herein, the terms "instantiate," "instance," and the like may refer to creating an instance, "instance" may refer to a specific occurrence of an object, which may occur, for example, during execution of program code. Further, NRF 1554 may expose an interface based on an nrrf service.

PCF 1556 may provide policy rules to control plane functions to enforce them and may also support a unified policy framework to manage network behavior. PCF 1556 may also implement a front end to access subscription information related to policy decisions in the UDR of UDM 1558. In addition to communicating with functions through reference points as shown, PCF 1556 also exhibits an Npcf service-based interface.

The UDM 1558 may process subscription-related information to support network entities handling communication sessions and may store subscription data for the UE 1502. For example, subscription data may be communicated via the N8 reference point between UDM 1558 and AMF 1544. The UDM 1558 may include two parts: front end and UDR are applied. The UDR may store policy data and subscription data for UDM 1558 and PCF 1556, and/or structured data and application data for disclosure (including PFD for application detection, application request information for multiple UEs 1502) for NEF 1552. UDR 221 may expose an Nudr service-based interface to allow UDM 1558, PCF 1556, and NEF1552 to access specific sets of stored data, as well as read, update (e.g., add, modify), delete, and subscribe to notifications of relevant data changes in the UDR. The UDM may include a UDM-FE that is responsible for handling credentials, location management, subscription management, and the like. Several different front ends may serve 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 permission, registration/mobility management, and subscription management. In addition to communicating with other NFs through reference points as shown, UDM 1558 may also expose a numm service based interface.

The AF1560 may provide application impact on traffic routing, provide access to NEF, and interact with the policy framework for policy control.

In some embodiments, the 5GC 1540 may enable edge computing by selecting operator/third party services that are geographically close to the point where the UE1502 attaches to the network. This may reduce latency and load on the network. To provide an edge computing implementation, the 5GC 1540 may select the UPF 1548 near the UE1502 and perform traffic steering from the UPF 1548 to the data network 1536 through the N6 interface. This may be based on UE subscription data, UE location, and information provided by the AF 1560. In this way, the AF1560 may affect UPF (re) selection and traffic routing. Based on operator deployment, the network operator may allow the AF1560 to interact directly with the relevant NFs when the AF1560 is considered a trusted entity. In addition, the AF1560 may expose a Naf service based interface.

The data network 1536 may represent various network operator services, internet access, or third party services that may be provided by one or more servers, including, for example, an application/content server 1538.

The following paragraphs describe examples of various embodiments.

Example 1 includes an apparatus comprising: an interface circuit; and a processor circuit coupled with the interface circuit, wherein the processor circuit is configured to: encoding a charging data request for charging of a fifth generation (5G) system (5GS) capability supporting edge computing for transmission via the interface circuit to a charging function (CHF); decoding a charging data response received from the CHF via the interface circuit in response to the charging data request, the charging data response confirming the charging data request; and performing a charge with the CHF for the 5GS capability that supports edge computing.

Example 2 includes the apparatus of example 1, wherein the charging comprises a converged charging.

Example 3 includes the apparatus of example 1, wherein the processor circuit is further to: performing charging of the edge computing enabled 5GS capability based on a monitored quality of service (QoS).

Example 4 includes the apparatus of example 3, wherein the monitored QoS is related to the edge-computed 5GS capable packet delay.

Example 5 includes the apparatus of example 1, wherein the apparatus is part of a Session Management Function (SMF).

Example 6 includes the apparatus of example 1 or 5, wherein the charging data request includes a parameter to indicate charging for the 5GS capability to support edge computing, wherein the parameter includes: an AF charging identifier; afchargidd; a network slice instance identifier; an application identifier; flowDescription; or ethFlowDescription.

Example 7 includes the apparatus of example 1 or 5, wherein the 5GS capability to support edge computing comprises a Protocol Data Unit (PDU) session to support edge computing.

Example 8 includes the apparatus of example 1, wherein the apparatus is part of: a management service (MnS) producer of a Public Land Mobile Network (PLMN); or a Charging Enable Function (CEF).

Example 9 includes the apparatus of examples 1 or 8, wherein the processor circuit is further to: performing charging for the edge computing enabled 5GS capability based on a total Uplink (UL)/Downlink (DL) data volume.

Example 10 includes the apparatus of example 1, wherein the processor circuit is further to: collecting charging information for the 5GS capability supporting edge computing; encoding the charging information for transmission to the CHF via the interface circuit; and performing charging for the 5GS capability supporting edge computing with the CHF based on the charging information.

Example 11 includes the apparatus of example 10, wherein the charging information includes a parameter to indicate a charge for the 5GS capability to support edge computing, wherein the parameter includes: an AF charging identifier; afchargidd; a network slice instance identifier; an application identifier; flowDescription; or ethFlowDescription.

Example 12 includes an apparatus comprising: an interface circuit; and a processor circuit coupled with the interface circuit, wherein the processor circuit is configured to: encoding a charging data request for charging of an edge enabled resource or service for transmission via the interface circuit to a charging function (CHF); decoding a charging data response received from the CHF via the interface circuit in response to the charging data request, the charging data response confirming the charging data request; and performing charging of the edge-enabled resources or services with the CHF.

Example 13 includes the apparatus of example 12, wherein the charging comprises a converged charging.

Example 14 includes the apparatus of example 12, wherein the apparatus is part of: a management service (MnS) producer of an Edge Computing Service Provider (ECSP); or a Charging Enabling Function (CEF).

Example 15 includes the apparatus of example 14, wherein the processor circuit is further to perform charging of the edge-enabled service for: an Edge Application Server (EAS) deployment; EAS registration; (ii) EAS discovery; or EAS application context transfer.

Example 16 includes the apparatus of example 15, wherein the EAS deployment comprises: an EAS instantiation; an EAS update; an EAS modification; or EAS termination.

Example 17 includes the apparatus of example 12 or 14, wherein the processor circuit is further to: the charging of the edge-enabled resources is performed based on resources allocated to the EAS, resources actually used by the EAS, or an amount of data transmitted to/received from the EAS via the virtual network.

Example 18 includes the apparatus of example 17, wherein the resources allocated to EAS include: a virtual Central Processing Unit (CPU); a virtual memory; a virtual disk; or virtual network bandwidth.

Example 19 includes the apparatus of example 17, wherein the resources actually used by the EAS include: a virtual CPU; a virtual memory; or a virtual disk.

Example 20 includes the apparatus of example 12, wherein the apparatus is part of: MnS producer of Edge Enabler Server (EES); or CEF.

Example 21 includes the apparatus of example 20, wherein the processor circuit is further to perform charging of the edge-enabled service for: EAS registration; (ii) EAS discovery; or EAS application context transfer.

Example 22 includes a method comprising: encoding a charging data request for charging of a fifth generation (5G) system (5GS) capability supporting edge computing for transmission to a charging function (CHF); decoding a charging data response received from the CHF in response to the charging data request, the charging data response confirming the charging data request; and performing a charge with the CHF for the 5GS capability that supports edge computing.

Example 23 includes the method of example 22, wherein the charging comprises a fused charging.

Example 24 includes the method of example 22, wherein the performing with the CHF a charge for the 5GS capability to support marginal computing further comprises: performing charging for the edge computing enabled 5GS capability based on a monitored quality of service (QoS).

Example 25 includes the method of example 24, wherein the monitored QoS relates to the packet delay supporting edge-computed 5GS capability.

Example 26 includes the method of example 22, wherein the method is implemented by a Session Management Function (SMF).

Example 27 includes the method of example 22 or 26, wherein the charging data request includes a parameter indicating charging for the 5GS capability to support edge computing, wherein the parameter includes: an AF charging identifier; afchargidd; a network slice instance identifier; an application identifier; flowDescription; or ethFlowDescription.

Example 28 includes the method of example 22 or 26, wherein the 5GS capability to support edge computing comprises a Protocol Data Unit (PDU) session to support edge computing.

Example 29 includes the method of example 22, wherein the method is implemented by: a management service (MnS) producer of a Public Land Mobile Network (PLMN); or a Charging Enable Function (CEF).

Example 30 includes the method of example 22 or 29, wherein the performing charging for the 5GS capability to support marginal computing with the CHF further comprises: performing charging for the edge computing enabled 5GS capability based on a total Uplink (UL)/Downlink (DL) data volume.

Example 31 includes the method of example 22, further comprising: collecting charging information for the 5GS capability supporting edge computing; encoding the charging information for transmission to the CHF; and performing charging for the 5GS capability supporting edge computing with the CHF based on the charging information.

Example 32 includes the method of example 31, wherein the charging information includes a parameter indicating a charge for the 5GS capability to support edge computing, wherein the parameter includes: an AF charging identifier; afchargidd; a network slice instance identifier; an application identifier; flowDescription; or ethFlowDescription.

Example 33 includes a method, comprising: encoding a charging data request for charging of an edge enabled resource or service for transmission to a charging function (CHF); decoding a charging data response received from the CHF in response to the charging data request, the charging data response confirming the charging data request; and performing charging of the edge-enabled resources or services with the CHF.

Example 34 includes the method of example 33, wherein the charging comprises a converged charging.

Example 35 includes the method of example 33, wherein the method is implemented by: a management service (MnS) producer of an Edge Computing Service Provider (ECSP); or a Charging Enable Function (CEF).

Example 36 includes the method of example 35, wherein the charging for the edge-enabled service is performed for: an Edge Application Server (EAS) deployment; EAS registration; (ii) EAS discovery; or EAS application context transfer.

Example 37 includes the method of example 36, wherein the EAS deployment comprises: an EAS instantiation; an EAS update; an EAS modification; or EAS termination.

Example 38 includes the method of example 33 or 35, wherein the performing a charge for the edge-enabled resources or services with the CHF further comprises: the charging of the edge-enabled resources is performed based on resources allocated to the EAS, resources actually used by the EAS, or an amount of data transmitted to/received from the EAS via the virtual network.

Example 39 includes the method of example 38, wherein the resources allocated to EAS include: a virtual Central Processing Unit (CPU); a virtual memory; a virtual disk; or virtual network bandwidth.

Example 40 includes the method of example 38, wherein the resources actually used by the EAS include: a virtual CPU; a virtual memory; or a virtual disk.

Example 41 includes the method of example 33, wherein the method is implemented by: MnS producer of Edge Enabler Server (EES); or CEF.

Example 42 includes the method of example 41, wherein charging for the edge-enabled service is performed for: EAS registration; (ii) EAS discovery; or EAS application context transfer.

Example 43 includes an apparatus comprising: a component for encoding a charging data request for charging of a fifth generation (5G) system (5GS) capability supporting edge computing for transmission to a charging function (CHF); means for decoding a charging data response received from the CHF in response to the charging data request, the charging data response confirming the charging data request; and a component for performing a charge for the 5GS capability supporting edge computing with the CHF.

Example 44 includes the apparatus of example 43, wherein the charging comprises a converged charging.

Example 45 includes the apparatus of example 43, wherein the means for performing further comprises: means for performing charging of the edge computing enabled 5GS capability based on a monitored quality of service (QoS).

Example 46 includes the apparatus of example 45, wherein the monitored QoS relates to the edge-computed 5GS capable packet delay.

Example 47 includes the apparatus of example 43, wherein the apparatus is part of a Session Management Function (SMF).

Example 48 includes the apparatus of example 43 or 47, wherein the charging data request includes a parameter to indicate charging for the 5GS capability to support edge computing, wherein the parameter includes: an AF charging identifier; afchargidd; a network slice instance identifier; an application identifier; flowDescription; or ethFlowDescription.

Example 49 includes the apparatus of example 43 or 47, wherein the 5GS capability to support edge computing comprises a Protocol Data Unit (PDU) session to support edge computing.

Example 50 includes the apparatus of example 43, wherein the apparatus is part of: a management service (MnS) producer of a Public Land Mobile Network (PLMN); or a Charging Enable Function (CEF).

Example 51 includes the apparatus of example 43 or 50, wherein the means for performing further comprises: means for performing charging for the edge computing enabled 5GS capability based on a total Uplink (UL)/Downlink (DL) data volume.

Example 52 includes the apparatus of example 43, further comprising: a component for collecting charging information for the 5GS capability supporting edge computing; means for encoding the charging information for transmission to the CHF; and means for performing charging for the 5GS capability supporting edge computing with the CHF based on the charging information.

Example 53 includes the apparatus of example 52, wherein the charging information includes a parameter to indicate a charge for the 5GS capability to support edge computing, wherein the parameter includes: an AF charging identifier; afchargidd; a network slice instance identifier; an application identifier; flowDescription; or ethFlowDescription.

Example 54 includes an apparatus comprising: a component for encoding a charging data request for charging of an edge enabled resource or service for transmission to a charging function (CHF); means for decoding a charging data response received from the CHF in response to the charging data request, the charging data response confirming the charging data request; and means for performing charging of the edge-enabled resource or service with the CHF.

Example 55 includes the apparatus of example 54, wherein the charging comprises a converged charging.

Example 56 includes the apparatus of example 54, wherein the apparatus is part of: a management services (MnS) producer of an Edge Computing Service Provider (ECSP); or a Charging Enable Function (CEF).

Example 57 includes the apparatus of example 56, wherein the charging for the edge-enabled service is performed for: an Edge Application Server (EAS) deployment; EAS registration; (ii) EAS discovery; or EAS application context transfer.

Example 58 includes the apparatus of example 57, wherein the EAS deployment comprises: an EAS instantiation; an EAS update; an EAS modification; or EAS termination.

Example 59 includes the apparatus of example 54 or 56, wherein the means for performing further comprises: a component for performing a charge for the edge-enabled resource based on a resource allocated to the EAS, a resource actually used by the EAS, or an amount of data transmitted to/received from the EAS via the virtual network.

Example 60 includes the apparatus of example 59, wherein the resources allocated to EAS comprise: a virtual Central Processing Unit (CPU); a virtual memory; a virtual disk; or virtual network bandwidth.

Example 61 includes the apparatus of example 59, wherein the resources actually used by the EAS include: a virtual CPU; a virtual memory; or a virtual disk.

Example 62 includes the apparatus of example 54, wherein the apparatus is part of: MnS producer of Edge Enabler Server (EES); or CEF.

Example 63 includes the apparatus of example 62, wherein the charging for the edge-enabled service is performed for: EAS registration; (ii) EAS discovery; or EAS application context transfer.

Example 64 includes a computer-readable medium having instructions stored thereon, wherein the instructions, when executed by a processor circuit, cause the processor circuit to perform the method of any of examples 22-42.

Example 65 includes a Session Management Function (SMF) as described and illustrated in the specification.

Example 66 includes a method performed at a Session Management Function (SMF) as described and illustrated in the specification.

Example 67 includes a charging function (CHF) as described and illustrated in the specification.

Example 68 includes a method performed at a charging function (CHF) as described and illustrated in the specification.

Example 69 includes a management services (MnS) producer as described and illustrated in the specification.

Example 70 includes a method performed at a management services (MnS) producer as described and illustrated in the specification.

Example 71 includes a Charging Enable Function (CEF) as described and illustrated in the specification.

Example 72 includes a method performed at a Charging Enablement Function (CEF) as described and illustrated in the specification.

Although certain embodiments have been illustrated and described herein for purposes of description, various alternative and/or equivalent embodiments or implementations calculated to achieve the same purposes may be substituted for the embodiments shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is manifestly intended that the embodiments described herein be limited only by the claims and the equivalents thereof.

Claims

1. An apparatus, comprising:

an interface circuit; and

a processor circuit coupled with the interface circuit,

wherein the processor circuit is to:

encoding a charging data request for charging of a fifth generation (5G) system (5GS) capability supporting edge computing for transmission via the interface circuit to a charging function (CHF);

decoding a charging data response received from the CHF via the interface circuit in response to the charging data request, the charging data response confirming the charging data request; and

performing a charge for the 5GS capability to support edge computing with the CHF.

2. The apparatus of claim 1, wherein the charging comprises a converged charging.

3. The apparatus of claim 1, wherein the processor circuit is further to:

performing charging of the edge computing enabled 5GS capability based on a monitored quality of service (QoS).

4. The apparatus of claim 3, wherein the monitored QoS is related to the packet delay supporting an edge-computed 5GS capability.

5. The apparatus of claim 1, wherein the apparatus is part of a Session Management Function (SMF).

6. The apparatus of claim 1 or 5, wherein the charging data request comprises a parameter indicating a charge for the 5GS capability to support marginal calculation, wherein the parameter comprises:

an AF charging identifier;

afChargId；

a network slice instance identifier;

an application identifier;

flowDescription; or

ethFlowDescription。

7. The apparatus of claim 1 or 5, wherein the 5GS capability to support edge computing comprises a Protocol Data Unit (PDU) session to support edge computing.

8. The apparatus of claim 1, wherein the apparatus is part of:

a management service (MnS) producer of a Public Land Mobile Network (PLMN); or

Charging Enabling Function (CEF).

9. The apparatus of claim 1 or 8, wherein the processor circuit is further to:

performing charging for the edge computing enabled 5GS capability based on a total Uplink (UL)/Downlink (DL) data volume.

10. The apparatus of claim 1, wherein the processor circuit is further to:

collecting charging information for the 5GS capability supporting edge computing;

encoding the charging information for transmission to the CHF via the interface circuit; and

performing charging for the 5GS capability supporting edge computing with the CHF based on the charging information.

11. The apparatus of claim 10, wherein the charging information comprises a parameter indicating a charge for the 5GS capability to support edge computing, wherein the parameter comprises:

an AF charging identifier;

afChargId；

a network slice instance identifier;

an application identifier;

flowDescription; or

ethFlowDescription。

12. An apparatus, comprising:

an interface circuit; and

a processor circuit coupled with the interface circuit,

wherein the processor circuit is to:

encoding a charging data request for charging of an edge enabled resource or service for transmission via the interface circuit to a charging function (CHF);

performing charging of the edge-enabled resources or services with the CHF.

13. The apparatus of claim 12, wherein the charging comprises a converged charging.

14. The apparatus of claim 12, wherein the apparatus is part of:

a management service (MnS) producer of an Edge Computing Service Provider (ECSP); or

Charging Enabling Function (CEF).

15. The apparatus of claim 14, wherein the processor circuit is further to perform charging for the edge-enabled service for:

an Edge Application Server (EAS) deployment;

EAS registration;

(ii) EAS discovery; or

EAS application context transfer.

16. The apparatus of claim 15, wherein the EAS deployment comprises:

an EAS instantiation;

an EAS update;

an EAS modification; or

The EAS is terminated.

17. The apparatus of claim 12 or 14, wherein the processor circuit is further to:

the charging of the edge-enabled resources is performed based on resources allocated to the Edge Application Server (EAS), resources actually used by the EAS, or an amount of data transmitted/received to/from the EAS via the virtual network.

18. The apparatus of claim 17, wherein the resources allocated to EAS comprise:

a virtual Central Processing Unit (CPU);

a virtual memory;

a virtual disk; or

Virtual network bandwidth.

19. The apparatus of claim 17, wherein the resources actually used by the EAS comprise:

a virtual Central Processing Unit (CPU);

a virtual memory; or

And (4) virtual disks.

20. The apparatus of claim 12, wherein the apparatus is part of:

MnS producer of Edge Enabler Server (EES); or

Charging Enabled Function (CEF).

21. The apparatus of claim 20, wherein the processor circuit is further configured to perform charging for the edge-enabled service for:

an Edge Application Server (EAS) registration;

(ii) EAS discovery; or

EAS application context transfer.