Resource allocation status subscription for application-related functions

Abstract

To provide a method and an apparatus for resolving a problem in resource allocation status subscription of an Application Related Function (ARF).SOLUTION: A method of ARF operation includes sending a request to an Exposing Function (EF). The request includes a resource allocation confirmation indication indicating whether a resource allocation status notification is required and a resource allocation status characteristic indicating whether the ARF supports the resource allocation status. The resource allocation status notification is used to indicate resource allocation success or resource allocation failure. The method also includes receiving, from the EF, a response including a status response characteristic indicating whether both the ARF and the EF support the resource allocation status.SELECTED DRAWING: Figure 12B

Description

[Technical Field]

[0001] The present disclosure relates to solving interoperability problems between application related functions (ARFs) and publishing functions (EFs) in cellular communication systems, and in particular to solving problems in resource allocation status subscription for ARFs. [Background technology]

[0002] In general, all terms used herein should be interpreted in accordance with the ordinary meaning of that term in the relevant technical field unless a different meaning is expressly given and / or a different meaning is suggested from the context in which the term is used. All references to elements, devices, components, means, steps, etc. should be openly interpreted as referring to at least one instance of the element, device, component, means, step, etc., unless expressly stated otherwise. The steps of any method disclosed herein need not be performed in the exact order disclosed, unless a step is expressly described as following or preceding another step and / or it is implied that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, whenever appropriate. Similarly, any advantage of any of the embodiments may be applied to any other embodiment, and vice versa. Other objects, features, and advantages of the enclosed embodiments will become apparent from the following description.

[0003] Disclosure of 4G network capabilities The external exposure of network capabilities in the EPC was driven by MTC (Machine Type Communication). As shown in Figure 1, the Service Capability Exposure Function (SCEF) provides a means for securely exposing services and capabilities offered by 3GPP network interfaces. The SCEF provides a means for discovering exposed services and capabilities. The SCEF provides access to network capabilities through a homogeneous network application programming interface (e.g., network API) specified on the T8 interface. The SCEF abstracts services from the underlying 3GPP network interfaces and protocols. T8 is the interface between the SCEF and the Service Capability Server or Application Server (SCS / AS). The network services exposed by the SCEF can be accessed by the SCS / AS through APIs on the T8 interface (see TS 23.682, Section 4.2).

[0004] A third-party SCS / AS may request that a data session (AS session) to a UE served by a third-party service provider be set up with a specific QoS (e.g., low latency or jitter) and priority handling. This capability is exposed to the SCS / AS via the SCEF. As illustrated in Figure 2, the SCS / AS can request the network to provide QoS to the AS session based on application and service requirements using a QoS reference parameter that references predefined QoS information. When the SCEF receives a request to provide QoS to an AS session from the SCS / AS, the SCEF acts as an AF according to the TS 23.203

[27] specification and forwards the request to provide QoS to the AS session to the Policy and Charging Rules Function (PCRF) via the Rx interface. If the SCEF is notified about a bearer-level event of the Rx session (e.g., transmission resources are released / lost), the SCEF shall notify the SCS / AS about the bearer-level event of the Rx session (see TS 23.682, clauses 4.5.11 and 5.11).

[0005] The SCS / AS may request the SCEF to start or stop sponsoring a UE's data session (AS session) served by a third-party service provider, i.e., to know whether one of the third-party service providers is charged (start) or not (stop) for the traffic. As illustrated in Figure 3, the SCS / AS may request to be set as the charging destination at the setup of the AS session, i.e., to sponsor the traffic, or to change the charging destination during an ongoing AS session. The SCEF acts as an AF, and existing functionality specified in TS 23.203

[27] for sponsored data connectivity is used to support this functionality. When the SCEF is informed that the Rx session has been terminated (e.g., due to the release of the PDN connection), it shall notify the SCS / AS accordingly and forward any accumulated usage reports received from the PCRF (see TS 23.682, clauses 4.5.12 and 5.12).

[0006] Disclosure of network capabilities in 5G As shown in Figure 4, the Network Exposure Function (NEF) supports the external exposure of network function capabilities. The external exposure can be categorized as monitoring capability, provisioning capability, policy / charging capability, and analysis / reporting capability. The monitoring capability is for monitoring specific events of the UE in the 5G system and enabling such monitoring event information to be externally exposed via the NEF. The provisioning capability is for enabling an external party to provision information that can be used for the UE in the 5G system. The policy / charging capability is for handling the UE's QoS and charging policy based on a request from an external party. The analysis / reporting capability is for enabling an external party to fetch or subscribe / unsubscribe to analysis information generated by the 5G system. The policy / charging capability consists of a means to authorize requests for session and charging policies, enforce QoS policies, and apply accounting functions. This can be used to handle specific QoS / priority for the UE's sessions and to set applicable charging destinations or charging rates. The N33 reference point provides an API equivalent to the T8 interface to the AF (see TS23.501, section 5.20).

[0007] QoS required by AF in 5G is supported by the NEF N33 API in TS 29.522 (clause 4.4.9), which reuses the SCEF T8 API in TS 29.122 (clause 4.4.13). Figures 5 and 6 show the information flows for setting up an AF session with required QoS procedures in TS 23.502, clause 4.15.6.6, and updating an AF session with required QoS procedures in TS 23.502, clause 4.15.6.6a.

[0008] The configuration of the charging destination is supported by the NEF N33 API in TS 29.522 (clause 4.4.8), which reuses the SCEF T8 API in TS 29.122 (clause 4.4.4). Correspondingly, Figures 7 and 8 show the information flows for the configuration of the charging destination procedure during AF session setup and AF session update in TS 23.502, clauses 4.15.6.4 and 4.15.6.5.

[0009] Problems with existing solutions In the existing technology (3GPP TS29.122 Release 16), a public function (such as a NEF or SCEF) may send an event notification of resource allocation status (such as resource allocation success or resource allocation failure) to an application-related function (such as an AF or SCS / AS). However, such an event is not specified in pre-Release 16 versions. Therefore, when an application-related function (of Release 16 version or later) communicates with a public function (of pre-Release 16 version), if the application-related function (of Release 16 version or later) expects to receive an event notification of resource allocation status, but the public function (of pre-Release 16 version) does not support such an event, the application-related function (of Release 16 version or later) will wait indefinitely.

[0010] Additionally, even if the publishing function supports resource allocation status events (resource allocation success or resource allocation failure), the publishing function may not send the event notification to the application-related function, which may then wait forever for the result of the resource allocation success or failure. Summary of the Invention

[0011] Certain aspects of the present disclosure and embodiments thereof may provide solutions to the aforementioned problems or other problems. Disclosed herein are methods and apparatus in which resource allocation confirmation indications and resource allocation status characteristics are used to resolve problems in resource allocation status subscriptions of application-related functions.

[0012] Various embodiments are proposed herein that address one or more of the problems disclosed herein. In one embodiment, a method of operation of an Application Related Function (ARF) includes sending a request to an Exposing Function (EF). Herein, the request includes a resource allocation confirmation indication indicating whether a resource allocation status notification is required. The resource allocation status notification indicates resource allocation success or resource allocation failure.

[0013] In one embodiment, the request further includes a resource allocation status characteristic that indicates whether the ARF supports resource allocation status.

[0014] In one embodiment, the method of ARF operation further includes receiving a response from the EF including a status response characteristic, wherein the status response characteristic indicates whether both the ARF and the EF support resource allocation status.

[0015] In one embodiment, when the resource allocation confirmation indication indicates that a resource allocation status notification is required by the ARF and the status response characteristic indicates that both the ARF and the EF support resource allocation status, the response further includes a resource allocation status notification.

[0016] In one embodiment, when the resource allocation confirmation indication indicates that a resource allocation status notification is not requested by the ARF and / or the status response characteristic indicates that at least one of the ARF and the EF does not support the resource allocation status, the method further includes inhibiting waiting for a resource allocation status notification from the EF.

[0017] In one embodiment, when the resource allocation confirmation indication indicates that a resource allocation status notification is not requested by the ARF, the method further includes refraining from waiting for a resource allocation status notification from the EF.

[0018] In one embodiment, when the status response characteristic indicates that at least one of the ARF and the EF does not support resource allocation status, the method further includes inhibiting waiting for a resource allocation status notification from the EF.

[0019] In one embodiment, the request is a request to set up an AS or AF session with the required QoS, a request to update an AS or AF session with the required QoS, a request to set a charging destination when setting up an AS or AF session, or a request to change a charging destination during an AS or AF session, and the response is a response to set up an AS or AF session with the required QoS, a response to update an AS or AF session with the required QoS, a response to set a charging destination when setting up an AS or AF session, or a request to change a charging destination during an AS or AF session.

[0020] In one embodiment, the resource allocation confirmation indication uses a bitmask to indicate whether resource allocation status notification is required, the resource allocation status characteristic uses a bitmask to indicate whether the ARF supports resource allocation status, and the status response characteristic uses a bitmask to indicate whether both the ARF and the EF support resource allocation status.

[0021] In one embodiment, the ARF is in a fifth generation system. The ARF is an application function (AF) and the EF is a network publishing function (NEF).

[0022] In one embodiment, the request is a request to set up an AF session with the required QoS, a request to update an AF session with the required QoS, a request to set a charging destination at AF session setup, or a request to change a charging destination during an AF session, and the response is a response to set up an AF session with the required QoS, a response to update an AF session with the required QoS, a response to set a charging destination at AF session setup, or a request to change a charging destination during an AF session.

[0023] In one embodiment, the ARF is in a fourth generation system, where the ARF is a service capability server or application server (SCS / AS) and the EF is a service capability publishing function (SCEF).

[0024] In one embodiment, the request is a request to set up an AS session with the required QoS, a request to update an AS session with the required QoS, a request to set a charging destination when setting up an AS session, or a request to change a charging destination during an AS session, and the response is a response to set up an AS session with the required QoS, a response to update an AS session with the required QoS, a response to set a charging destination when setting up an AS session, or a request to change a charging destination during an AS session.

[0025] Corresponding embodiments of the ARF are also disclosed. In one embodiment, the ARF is adapted to send a request to the EF and receive a response from the EF. Herein, the request includes a resource allocation confirmation indication indicating whether a resource allocation status notification is required and a resource allocation status characteristic indicating whether the ARF supports the resource allocation status. The resource allocation status notification indicates resource allocation success or resource allocation failure. The response includes a status response characteristic indicating whether both the ARF and the EF support the resource allocation status.

[0026] In one embodiment, a network node implementing the ARF comprises a network interface and processing circuitry associated with the network interface. The processing circuitry is configured to cause the network node to send a request to the EF and receive a response from the EF. Herein, the request includes a resource allocation confirmation indication indicating whether a resource allocation status notification is required and a resource allocation status characteristic indicating whether the ARF supports the resource allocation status. The response includes a status response characteristic indicating whether both the ARF and the EF support the resource allocation status.

[0027] In one embodiment, a method of EF operation includes receiving a request from an ARF, where the request includes a resource allocation confirmation indication indicating whether a resource allocation status notification is required, the resource allocation status notification indicating resource allocation success or resource allocation failure.

[0028] In one embodiment, the request further includes a resource allocation status characteristic that indicates whether the ARF supports resource allocation status.

[0029] In one embodiment, the method of EF operation further includes transmitting a response from the EF including a status response characteristic, wherein the status response characteristic indicates whether both the ARF and the EF support resource allocation status.

[0030] In one embodiment, when the resource allocation confirmation indication indicates that a resource allocation status notification is required by the ARF and the status response characteristic indicates that both the ARF and the EF support resource allocation status, the response further includes a resource allocation status notification.

[0031] In one embodiment, when the resource allocation confirmation indication indicates that a resource allocation status notification is not requested by the ARF and / or the status response characteristic indicates that at least one of the ARF and the EF does not support the resource allocation status, the method further includes inhibiting waiting for a resource allocation status notification from the EF.

[0032] In one embodiment, when the resource allocation confirmation indication indicates that a resource allocation status notification is not requested by the ARF, the method further includes refraining from waiting for a resource allocation status notification from the EF.

[0033] In one embodiment, when the status response characteristic indicates that at least one of the ARF and the EF does not support resource allocation status, the method further includes inhibiting waiting for a resource allocation status notification from the EF.

[0034] In one embodiment, the request is a request to set up an AS or AF session with the required QoS, a request to update an AS or AF session with the required QoS, a request to set a charging destination when setting up an AS or AF session, or a request to change a charging destination during an AS or AF session, and the response is a response to set up an AS or AF session with the required QoS, a response to update an AS or AF session with the required QoS, a response to set a charging destination when setting up an AS or AF session, or a request to change a charging destination during an AS or AF session.

[0035] In one embodiment, the resource allocation confirmation indication uses a bitmask to indicate whether resource allocation status notification is required, the resource allocation status characteristic uses a bitmask to indicate whether the ARF supports resource allocation status, and the status response characteristic uses a bitmask to indicate whether both the ARF and the EF support resource allocation status.

[0036] In one embodiment, the ARF is in a fifth generation system, the ARF is an AF, and the EF is an NEF.

[0037] In one embodiment, the request is a request to set up an AF session with the required QoS, a request to update an AF session with the required QoS, a request to set a charging destination at AF session setup, or a request to change a charging destination during an AF session, and the response is a response to set up an AF session with the required QoS, a response to update an AF session with the required QoS, a response to set a charging destination at AF session setup, or a request to change a charging destination during an AF session.

[0038] In one embodiment, the ARF is in a fourth generation system, the ARF is an SCS / AS, and the EF is an SCEF.

[0039] In one embodiment, the request is a request to set up an AS session with the required QoS, a request to update an AS session with the required QoS, a request to set a charging destination when setting up an AS session, or a request to change a charging destination during an AS session, and the response is a response to set up an AS session with the required QoS, a response to update an AS session with the required QoS, a response to set a charging destination when setting up an AS session, or a request to change a charging destination during an AS session.

[0040] In one embodiment, the method of EF operation further includes, after receiving the request, determining whether the resource allocation status is supported by the EF.

[0041] In one embodiment, the method of operation of the EF further includes granting the request from the ARF.

[0042] In one embodiment, the method of operation of the EF further includes interacting with a policy function (PF) when authorization is granted.

[0043] In one embodiment, the PF is a Policy and Charging Rules Function (PCRF) or a Policy Control Function (PCF).

[0044] In one embodiment, when resource allocation status is not supported by at least one of the ARF and the EF, the EF subscribes to the PF to obtain resource allocation status notifications, but does not send resource allocation status notifications to the ARF.

[0045] In one embodiment, when both the ARF and the EF support resource allocation status, the EF subscribes to the PF to obtain resource allocation status notifications only if the resource allocation status notifications are required by the ARF.

[0046] Corresponding embodiments of the EF are also disclosed. In one embodiment, the EF is adapted to receive a request from the ARF and send a response to the ARF. Herein, the request includes a resource allocation confirmation indication indicating whether a resource allocation status notification is required and a resource allocation status characteristic indicating whether the ARF supports the resource allocation status. The resource allocation status notification indicates resource allocation success or resource allocation failure. The response includes a status response characteristic indicating whether both the ARF and the EF support the resource allocation status.

[0047] In one embodiment, a network node implementing the EF comprises a network interface and processing circuitry associated with the network interface. The processing circuitry is configured to cause the network node to receive a request from the ARF and to send a response to the ARF. Herein, the request includes a resource allocation confirmation indication indicating whether a resource allocation status notification is required and a resource allocation status characteristic indicating whether the ARF supports the resource allocation status. The response includes a status response characteristic indicating whether both the ARF and the EF support the resource allocation status.

[0048] Certain embodiments may provide one or more of the following technical advantages: For example, certain embodiments solve an interoperability problem between an ARF and an EF: The ARF does not wait indefinitely when expecting to receive a resource allocation status notification indicating resource allocation failure or resource allocation success from an EF that does not support sending such notifications.

[0049] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate several aspects of the present disclosure and, together with the description, serve to explain the principles of the disclosure. [Brief explanation of the drawings]

[0050] [Figure 1] A diagram showing the architecture for service capability disclosure function in a 4G network. [Figure 2] FIG. 1 illustrates a procedure for setting up an AS session with required QoS. [Figure 3] 10A and 10B show procedures for setting or changing the billing destination at the time of AS session setup or during an AS session, respectively. [Figure 4] FIG. 1 illustrates an architecture for network publication functions in a 5G network. [Figure 5] FIG. 1 illustrates a procedure for setting up an AF session with required QoS. [Figure 6] FIG. 10 illustrates a procedure for updating an AF session with required QoS. [Figure 7] FIG. 10 is a diagram showing a procedure for setting a charging destination when an AF session is set up. [Figure 8] FIG. 10 is a diagram showing a procedure for changing the billing destination during an AS session. [Figure 9] FIG. 1 illustrates an example of a cellular communication system, according to some embodiments of the present disclosure. [Figure 10] FIG. 1 illustrates an example of an architecture for a service capability disclosure function in a 4G network. [Figure 11] FIG. 1 illustrates an example of an architecture for network disclosure functions in a 5G network. [Figures 12A-12C] 12 illustrates operations within the architecture shown in FIG. 10 or FIG. 11 in accordance with some embodiments of the present disclosure. [Figure 13] FIG. 2 is a schematic block diagram of a network node according to some embodiments of the present disclosure. [Figure 14] FIG. 14 is a schematic block diagram illustrating a virtualized embodiment of the network node of FIG. 13 in accordance with some embodiments of the present disclosure. [Figure 15] FIG. 14 is a schematic block diagram of the network node of FIG. 13 in accordance with some other embodiments of the present disclosure. [Figure 16] FIG. 1 illustrates a communication network connected to a host computer through an intermediate network, according to some embodiments of the present disclosure. [Figure 17] FIG. 2 is a generalized block diagram of a host computer communicating with a UE via a base station over a partial wireless connection, in accordance with some embodiments of the present disclosure. [Figure 18] 1 is a flowchart illustrating a method implemented in a communication system according to one embodiment of the present disclosure. [Figure 19]1 is a flowchart illustrating a method implemented in a communication system according to one embodiment of the present disclosure. [Figure 20] 1 is a flowchart illustrating a method implemented in a communication system according to one embodiment of the present disclosure. [Figure 21] 1 is a flowchart illustrating a method implemented in a communication system according to one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0051] The embodiments described below represent information to enable those skilled in the art to practice the embodiments and illustrate the best modes for practicing the embodiments. Upon reading the following description in light of the accompanying drawings, those skilled in the art will understand the concepts of the present disclosure and will recognize applications of these concepts not addressed in detail herein. These concepts and applications should be understood to fall within the scope of the present disclosure.

[0052] Wireless Node: As used herein, a "wireless node" is either a wireless access node or a wireless communication device.

[0053] Radio Access Node: As used herein, a "radio access node" or "radio network node" or "radio access network node" is any node in a Radio Access Network (RAN) of a cellular communications network that operates to transmit and / or receive signals wirelessly. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a 3rd Generation Partnership Project (3GPP) fifth-generation (5G) NR network, or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a Home eNB, etc.), a relay node, a network node implementing some of the functionality of a base station or a gNB distributed unit (gNB-DU), or a network node implementing some of the functionality of some other type of radio access node.

[0054] Core Network Node: As used herein, a "core network node" is any type of node in a core network or any node implementing a core network function. Some examples of a core network node include, for example, a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capabilities Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

[0055] Communications Device: As used herein, a "communications device" is any type of device that has access to an access network. Some examples of communications devices include, but are not limited to, a mobile phone, a smartphone, a sensor device, a meter, a vehicle, a home appliance, a medical device, a media player, a camera, or any type of consumer electronics product, such as, but not limited to, a television, a radio, a lighting device, a tablet computer, a laptop computer, or a personal computer (PC). A communications device may be a portable, handheld, computer-based, or vehicle-mounted mobile device that is enabled to communicate voice and / or data via a wireless or wired connection.

[0056] Wireless Communication Device: One type of communication device is a wireless communication device, which can be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of wireless communication devices include, but are not limited to, user equipment devices (UEs) in 3GPP networks, machine-type communication (MTC) devices, and Internet of Things (IoT) devices. Such wireless communication devices can be or can be integrated into mobile phones, smartphones, sensor devices, meters, vehicles, home appliances, medical devices, media players, cameras, or any type of consumer electronics, such as, but not limited to, televisions, radios, lighting devices, tablet computers, laptop computers, or PCs. Wireless communication devices can be portable, handheld, computer-based, or vehicle-mounted mobile devices enabled to communicate voice and / or data over a wireless connection.

[0057] Network Node: As used herein, a "network node" is any node that is part of either the RAN or the core network of a cellular communications network / system.

[0058] Transmitting / Receiving Point (TRP): In some embodiments, a TRP can be either a network node, a radio head, a spatial relationship, or a transmission configuration indicator (TCI) state. In some embodiments, a TRP can be represented by a spatial relationship or a TCI state. In some embodiments, a TRP can use multiple TCI states.

[0059] It should be noted that the description provided herein focuses on 3GPP cellular communication systems, and therefore 3GPP terminology or terminology similar to 3GPP terminology is often used, however, the concepts disclosed herein are not limited to 3GPP systems.

[0060] It should be noted that in the description herein, reference may be made to the term "cell." However, it is important to note that, particularly with regard to 5G NR concepts, beams may be used instead of cells, and therefore the concepts described herein are equally applicable to both cells and beams.

[0061] 9 illustrates an example of a cellular communication system 900 in which embodiments of the present disclosure may be implemented. In embodiments described herein, the cellular communication system 900 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC), or a 4G system (4GS) such as LTE. In this example, the RAN includes base stations 902-1 and 902-2, which in 5GS include NR base stations (gNBs) and optionally Next Generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to 5GC), and in 4GS include eNBs that control corresponding (macro) cells 904-1 and 904-2. Base stations 902-1 and 902-2 are generally referred to herein collectively as base stations 902 and individually as base stations 902. Similarly, (macro) cells 904-1 and 904-2 are generally referred to herein collectively as (macro) cells 904 and individually as (macro) cells 904. The RAN may also include several low-power nodes 906-1 through 906-4 that control corresponding small cells 908-1 through 908-4. The low-power nodes 906-1 through 906-4 may be small base stations (such as pico or femto base stations), or remote radio heads (RRHs), or the like. Notably, although not shown, one or more of the small cells 908-1 through 908-4 may alternatively be provided by the base station 902. The low-power nodes 906-1 through 906-4 are generally referred to herein collectively as low-power nodes 906 and individually as low-power nodes 906. Similarly, the small cells 908-1 through 908-4 are generally referred to herein collectively as small cells 908 and individually as small cells 908. The cellular communication system 900 also includes a core network 910, referred to as 5GC in 5G systems (5GS). The base station 902 (and optionally the low power node 906 ) is connected to a core network 910 .

[0062] Base station 902 and low power node 906 serve wireless communication devices 912-1 through 912-5 within corresponding cells 904 and 908. Wireless communication devices 912-1 through 912-5 are generally referred to herein collectively as wireless communication devices 912 and individually as wireless communication devices 912. In the following description, wireless communication devices 912 are often UEs, although the disclosure is not limited thereto.

[0063] 10 and 11 illustrate several system architectures of a cellular communication system 900 in which embodiments of the present disclosure may be implemented. Figure 10 illustrates a schematic diagram of the 3GPP architecture for service capability disclosure in a 4G network, which is the same as Figure 4.2-2 of 3GPP TS23.682V16.6.0, the entire disclosure of which is incorporated herein by reference. The system architecture of Figure 10 may comprise several example elements, such as a Service Capability Server / Application Server (SCS / AS) 1000, a Service Capability Publishing Function (SCEF) 1002, a Home Subscriber Server (HSS) 1004, a Policy and Charging Rules Function (PCRF) 1006, a Packet Flow Description Function (PFDF) 1008, a Mobility Management Entity / Serving General Packet Radio Service (GPRS) Support Node (MME / SGSN) 1010, a Broadcast Multicast-Service Center (BM-SC) 1012, a Serving-Call Session Control Function (S-CSCF) 1014, a RAN Congestion Awareness Function (RCAF) 1016, and a network entity 1018. The network elements and interfaces shown in Figure 10 may be the same as the corresponding network elements and interfaces described in 3GPP TS23.682 V16.6.0.

[0064] Figure 11 shows a non-roaming architecture for a Network Publication Function Reference Point Representation (5G Core Network), which is the same as Figure 4.2.3-5 of 3GPP TS23.501V16.4.0, the entire disclosure of which is incorporated herein by reference. The system architecture of Figure 11 may include several exemplary elements, such as an Application Function (AF) 1100, a Network Publication Function (NEF) 1102, and a Network Function (NF) 1104. In one embodiment, the NF 1104 may be a Policy Control Function (PCF) 1104, and an N30 interface is between the NEF 1102 and the PCF 1104. The network elements, reference points, and interfaces shown in Figure 11 may be the same as the corresponding network elements, reference points, and interfaces described in 3GPP TS23.501V16.4.0.

[0065] An exposing functional entity, such as the SCEF 1002 in FIG. 10 or the NEF 1102 in FIG. 11, may provide a means for securely exposing services and capabilities offered by a network (such as a 3GPP network) interface. The exposing functional entity provides a means for discovering the exposed services and capabilities. The exposing functional entity may provide access to network capabilities via a network application programming interface (e.g., a network API). The exposing functional entity may abstract services from the underlying network interfaces and protocols.

[0066] There may be various types of network-exposed services. For example, a monitoring capability may be used to monitor specific events of terminal devices in a network, such as a 4G / 5G system, and make such monitored event information available for external exposure via an exposing functional entity, such as the SCEF 1002 or NEF 1102. A provisioning capability may be used to allow an external party to provision information that may be used for a terminal device, such as a UE, in a network, such as a 4G / 5G system. A policy / charging capability may be used to handle QoS (Quality of Service) and charging policies for a terminal device, such as a UE, based on a request from an external party. An analysis reporting capability may be used to allow an external party to fetch or subscribe / unsubscribe to analysis information generated by a network, such as a 4G / 5G system. A data capability may be used to allow an external party to communicate with a terminal device, such as a UE, via an application programming interface.

[0067] In one embodiment, the publishing function entity may support network publishing functions and network publishing services as described in 3GPP TS23.501 V16.4.0, hi another embodiment, the publishing function entity may support network publishing functions as described in 3GPP TS23.682 V16.6.0.

[0068] 12A illustrates operations within the architecture shown in FIG. 10 or FIG. 11 according to some embodiments of the present disclosure. As illustrated, an application-related function (ARF) 1200 sends a request, and an exposing function (EF) 1202 receives the request (step 1210). Herein, the ARF 1200 may be the SCS / AS 1000 shown in the 4G system of FIG. 10 or the AF 1100 shown in the 5G system of FIG. 11. The EF 1202 may be the SCEF 1002 shown in the 4G system of FIG. 10 or the NEF 1102 shown in the 5G system of FIG. 11.

[0069] The request from the ARF 1200 to the EF 1202 may be different requests for different network systems and / or different procedures. For example, in the 4G system shown in Figure 10, the request may be a request to set up an AS session with the required QoS (using the On-Demand QoS Request message described in 3GPP TS23.682 V16.6.0), a request to update the AS session with the required QoS, a request to set a charging destination when setting up an AS session (using the Charging Destination Set Request message described in 3GPP TS23.682 V16.6.0), or a request to change a charging destination during an AS session (using the Charging Destination Change Request message described in 3GPP TS23.682 V16.6.0). As another example, in the 5G system shown in FIG. 11, the request may be a request to set up an AF session with the required QoS (using the Nnef_AFsessionWithQoS_Create request message described in 3GPP TS23.502 V16.5.0), a request to update an AF session with the required QoS (Nnef_AFsessionWithQoS_Update request message described in 3GPP TS23.502 V16.5.0), a request to set a charging destination when setting up an AF session (Nnef_ChargeableParty_Create request message described in 3GPP TS23.502 V16.5.0), or a request to change a charging destination during an AF session (Nnef_ChargeableParty_Update request message described in 3GPP TS23.502 V16.5.0).

[0070] The request from ARF 1200 to EF 1202 includes a resource allocation status characteristic and a resource allocation confirmation indication. In this specification, the resource allocation status characteristic indicates whether ARF 1200 supports resource allocation status, and the resource allocation confirmation indication indicates whether a resource allocation status notification is required by ARF 1200 according to the resource allocation status characteristic. If ARF 1200 requests a resource allocation status notification, ARF 1200 will wait for a resource allocation status notification from EF 1202. If ARF 1200 does not request a resource allocation status notification, ARF 1200 will not wait for a resource allocation status notification from EF 1202.

[0071] In one embodiment, a bitmask may be used for the resource allocation status characteristic to indicate whether the ARF 1200 supports resource allocation status. The resource allocation status characteristic may utilize a value set of "0 and 1" or "true and false." When the value of the resource allocation status characteristic is "1" or "true," the resource allocation status characteristic indicates that the ARF 1200 supports resource allocation status (that the ARF 1200 is capable of receiving a resource allocation status notification (from the EF 1202) indicating resource allocation failure or resource allocation success). When the value of the resource allocation status characteristic is "0" or "false," the resource allocation status characteristic indicates that the ARF 1200 does not support resource allocation status.

[0072] Similarly, a bit mask may be used for the resource allocation confirmation indicator to indicate whether a resource allocation status notification is required by the ARF 1200. The resource allocation confirmation indicator may utilize a value set of "0 and 1" or "true and false." When the value of the resource allocation confirmation indicator is "1" or "true," the resource allocation confirmation indicator indicates that a resource allocation status notification is required by the ARF 1200. When the value of the resource allocation confirmation indicator is "0" or "false," the resource allocation confirmation indicator indicates that a resource allocation status notification is not requested by the ARF 1200.

[0073] After receiving the request, the EF 1202 determines whether the resource allocation status is supported by the EF 1202 (whether the EF 1202 is capable of sending a resource allocation status notification (to the ARF 1200) indicating a resource allocation failure or a resource allocation success) (step 1212). The ARF 1200 can receive the resource allocation status notification only if the resource allocation status is supported by both the ARF 1200 and the EF 1202.

[0074] In the EF 1202, the EF 1202 also authorizes the request from the ARF 1200 (step 1214). Authorization is performed based on which request is to be implemented. Once authorization is granted, the EF 1202 interacts with a policy function (PF) 1204 (step 1216). In this specification, the PF 1204 may be the PCRF 1006 shown in the 4G system of FIG. 10 or the PCF 1104 shown in the 5G system of FIG. 11. The EF 1202 provides at least some information included in the request (from the ARF 1200) to the PF 1204, and the PF 1204 determines whether the request is authorized and notifies the EF 1202 if the request is not authorized. Furthermore, during the interaction with the PF 1204, the EF 1202 may also request to be informed by the PF 1204 about the resource allocation status.

[0075] In one embodiment, when resource allocation status is supported by both ARF 1200 and EF 1202, EF 1202 subscribes to PF 1204 to obtain resource allocation status notifications only if resource allocation status notifications are required by ARF 1200 (the value of resource allocation confirmation indication is “1” or “true”). Herein, resource allocation status notifications indicate resource allocation failure or resource allocation success, such as an INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION event and an INDICATION_OF_FAILED_RESOURCES_ALLOCATION event.

[0076] In one embodiment, when resource allocation status is not supported by at least one of the ARF 900 and the EF 1202, the EF 1202 may still subscribe to the PF 1204 to obtain resource allocation status notifications, but does not pass the resource allocation status notifications to the ARF 1200. Herein, the EF 1202 may perform certain local statistics based on the subscribed events.

[0077] The EF 1202 then sends a response, and the AF 120 receives the response (step 1218). Herein, the response from the EF 1202 to the ARF 1200 can be different responses depending on the implemented request. For example, in the 4G system shown in Figure 10, the response can be a response to set up an AS session with the required QoS (using the On-Demand QoS Response message described in 3GPP TS23.682 V16.6.0), a response to update the AS session with the required QoS, a response to set a charging destination when setting up an AS session (using the Charging Destination Set Response message described in 3GPP TS23.682 V16.6.0), or a response to change a charging destination during an AS session (using the Charging Destination Change Response message described in 3GPP TS23.682 V16.6.0). As another example, in the 5G system shown in FIG. 11, the response may be a response to set up an AF session with the required QoS (using the Nnef_AFsessionWithQoS_Create response message described in 3GPP TS23.502 V16.5.0), a response to update an AF session with the required QoS (the Nnef_AFsessionWithQoS_Update response message described in 3GPP TS23.502 V16.5.0), a response to set a charging destination when setting up an AF session (the Nnef_ChargeableParty_Create response message described in 3GPP TS23.502 V16.5.0), or a response to change a charging destination during an AF session (the Nnef_ChargeableParty_Update response message described in 3GPP TS23.502 V16.5.0).

[0078] The response includes a status response characteristic that indicates whether both the ARF 1200 and the EF 1202 support resource allocation status. In one embodiment, a bit mask is used for the status response characteristic to indicate whether both the ARF 1200 and the EF 1202 support resource allocation status. The status response characteristic may utilize a value set of "0 and 1" or "true and false." When the value of the status response characteristic is "1" or "true," the status response characteristic indicates that both the ARF 1200 and the EF 1202 support resource allocation status. When the value of the status response characteristic is "0" or "false," the status response characteristic indicates that at least one of the ARF 1200 and the EF 1202 does not support resource allocation status.

[0079] By receiving a status response characteristic with a value of “1” or “true,” ARF 1200 is notified that both ARF 1200 and EF 1202 support resource allocation status. As a result, if the value of the resource allocation confirmation indication is “1” or “true” (resource allocation status notification is required by ARF 1200), the response from EF 1202 to ARF 1200 further includes a resource allocation status notification indicating resource allocation failure or resource allocation success, such as an INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION event and an INDICATION_OF_FAILED_RESOURCES_ALLOCATION event. However, if the value of the resource allocation confirmation indication is “0” or “false” (resource allocation status notification is not required by ARF 1200), EF 1202 does not send a resource allocation status notification to ARF 1200, although it is capable of doing so. ARF 1200 refrains from waiting for a resource allocation status notification (step 1220).

[0080] The ARF 1200 is notified that at least one of the ARF 1200 and the EF 1202 does not support resource allocation status by receiving a status response characteristic with a value of “0” or “false.” The ARF 1200 then refrains from waiting for resource allocation status notification (step 1220).

[0081] 12B is a flowchart illustrating the operation of an application-related function such as ARF 1200, according to some embodiments. In step 1210, ARF 1200 sends a request including a resource allocation status characteristic and a resource allocation confirmation indication to a publishing function such as EF 1202. The resource allocation status characteristic indicates whether ARF 1200 supports resource allocation status, and the resource allocation confirmation indication indicates whether a resource allocation status notification is required by ARF 1200 according to the resource allocation status characteristic. Then, in step 1218, ARF 1200 receives a response from EF 1202 including a status response characteristic indicating whether both ARF 1200 and EF 1202 support resource allocation status, and optionally a resource allocation status notification to indicate resource allocation failure or resource allocation success. In one embodiment, if the resource allocation confirmation indication indicates that a resource allocation status notification is required by the ARF 1200 and the status response characteristic indicates that both the ARF 1200 and the EF 1202 support the resource allocation status, the response also includes a resource allocation status notification to indicate resource allocation failure or resource allocation success. In another embodiment, when the status response characteristic indicates that at least one of the ARF 1200 and the EF 1202 does not support the resource allocation status, the response does not include a resource allocation status notification, and in step 1220, the ARF 1200 refrains from waiting for a resource allocation status notification from the EF.

[0082] FIG. 12C is a flowchart illustrating the operation of a publishing function such as EF 1202, according to some embodiments. In step 1210, EF 1202 receives a request from an application-related function such as ARF 1200, the request including a resource allocation status characteristic and a resource allocation confirmation indication. Herein, the resource allocation status characteristic indicates whether ARF 1200 supports resource allocation status, and the resource allocation confirmation indication indicates whether resource allocation status notification is required by ARF 1200 according to the resource allocation status characteristic. Then, in step 1212, EF 1202 determines whether the resource allocation status is supported by EF 1202. In step 1214, EF 1202 authorizes the request from ARF 1200. Herein, step 1212 may be performed before, after, or simultaneously with step 1214. If the request is authorized, in step 1216, EF 1202 interacts with a policy function such as PF 1204. During interaction with PF 1204, EF 1202 may request to be notified by PF 1204 about resource allocation status. Finally, in step 1218, EF 1202 sends a response to ARF 1200 that includes a status response characteristic indicating whether both ARF 1200 and EF 1202 support resource allocation status, and optionally a resource allocation status notification to indicate resource allocation failure or resource allocation success. In one embodiment, if the resource allocation confirmation indication indicates that resource allocation status notification is required by ARF 1200 and the status response characteristic indicates that both ARF 1200 and EF 1202 support resource allocation status, the response also includes a resource allocation status notification to indicate resource allocation failure or resource allocation success. In another embodiment, when the status response characteristic indicates that at least one of ARF 1200 and EF 1202 does not support resource allocation status, the response does not include a resource allocation status notification.

[0083] One exemplary implementation of at least some aspects of the embodiments described herein is described below as changes to 3GPP TS29.122 V16.8.0, with changes made to, among other things, clauses 4.4.4, 4.4.13, 5.5.2.1.2 (including Table 5.5.2.1.2-1), 5.5.4 (including Table 5.5.4-1), 5.14.2.1.2 (including Table 5.14.2.1.2-1), 5.15.2.2.3 (including Table 5.14.2.2.3-1), 5.14.4 (including Table 5.14.4-1), A.2, A.5, and A.14. Sections 5.2.1.2.5 (including Table 5.2.1.2.5-1), 5.2.1.2.6 (including Table 5.2.1.2.6-1), and 5.2.1.3.3 (including Table 5.2.1.3.3-1) have been made obsolete. New sections have been added: 5.5.2.1.x (including Table 5.5.2.1.x-1), 5.5.2.1.y (including Table 5.5.2.1.y-1), 5.5.2.x, 5.5.2.x.1, 5.5.2.x.2 (including Table 5.5.2.x.2-1), and 5.5.2.x.3 (including Table 5.5.2.x.3-1). TIFF0007749089000001.tif11170

[0084] 4.4.4 Procedures for changing billing destination during session setup or during a session This procedure is used by the SCS / AS to request that traffic be sponsored from the beginning or to request that it be billed via the T8 interface at a later point in time.

[0085] When setting up a connection between an AS and a UE via the SCEF, the SCS / AS shall send an HTTP POST request to the SCEF targeting the "ChargedTransaction" resource to be charged for the session to be set up. The body of the HTTP POST message shall contain the SCS / AS identifier, the UE IP address, the IP flow description, the sponsor ID, the ASP ID, the sponsored provisioning status, the notification destination URI identifying the recipient of the notification in the "notificationDestination" attribute, and may also include the time period and / or traffic volume used for the sponsored provisioning. The SCS / AS may also request to activate a previously selected policy for background data transfer by including the associated reference ID in the body of the HTTP POST message.

[0086] After receiving the HTTP POST request, if the authorization performed by the SCEF is successful, the SCEF acts as an AF and interacts with the PCRF via the Rx interface as specified in 3GPP TS29.214

[10] or 3GPP TS29.201

[13] to trigger the modification of the PCRF-initiated IP-CAN session. The SCEF may map the SCS / AS identifier to an AF application identifier and may request to be informed about the traffic plane status. When the duration and / or traffic volume are received from the AF, the SCEF should subscribe to USAGE_REPORT events with the PCRF. If the "ResAllocStatus" feature is supported and "resconfirmInd" is set to true, the SCEF shall subscribe the PCRF to the INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION and INDICATION_OF_FAILED_RESOURCES_ALLOCATION events.

[0087] After receiving a successful response from the PCRF, the SCEF shall create a new "Individual Charged Transaction" resource representing the charged transaction, addressed by a URI containing the SCS / AS identity and the transaction identifier created by the SCEF, and shall respond to the SCS / AS with a 201 Created status code including a Location header field containing the URI of the created resource. The SCS / AS shall use the received URI in the Location header in subsequent requests to the SCEF to reference this charged transaction. If the SCEF receives a response with an error code from the PCRF, the SCEF shall not create the resource and shall respond to the SCS / AS with the corresponding failure code as described in clause 5.2.6.

[0088] To update the sponsored provisioning status of an established AS session, the SCS / AS shall send an HTTP PATCH message to the SCEF targeting the relevant "Individual Charged Transaction" resource, requesting to change the sponsored provisioning status. Upon receiving the HTTP PATCH message, the SCEF shall make the changes and interact with the PCRF to modify the Rx session as specified in 3GPP TS 29.214

[10] or 3GPP TS 29.201

[13] . After receiving a response with a successful result code from the PCRF, the SCEF shall send an HTTP response to the SCS / AS with a 200 OK status code and the result in the HTTP response body. If the SCS / AS requests to disable sponsored provisioning, the cumulative usage received from the PCRF shall be included. If the SCEF receives a response with an error code from the PCRF, the SCEF shall not update the resource and shall respond to the SCS / AS with the corresponding failure code as described in Section 5.2.6.

[0089] When the SCEF receives a traffic plane notification (e.g., a usage threshold is reached or a transmission resource is lost) or is notified that an Rx session has been terminated (e.g., due to the release of a PDN connection), it shall send an HTTP POST message containing the notified event (e.g., session termination) and the accumulated usage to the SCS / AS identified by the notification destination URI received during session setup. The SCS / AS shall respond with an HTTP response to confirm the received notification.

[0090] To delete an established AS session, the SCS / AS shall send an HTTP DELETE message targeting the associated "Individual Charged Transaction" resource to the SCEF. After receiving the HTTP DELETE message, the SCEF shall delete all properties of the resource (as specified in 3GPP TS29.214

[10] or 3GPP TS29.201

[13] ) and interact with the PCRF to terminate the Rx session. After receiving a response from the PCRF, the SCEF shall send an HTTP response with the corresponding status code and the accumulated usage amount (if received from the PCRF) to the SCS / AS. TIFF0007749089000002.tif11170

[0091] 4.4.13 Procedure for setting up an AS session with the required QoS This procedure is used to set up an AS session with the QoS required for the service as specified in 3GPP TS23.682 [2].

[0092] To create an initial AS session, the SCS / AS shall send an HTTP POST message to the SCEF for the "AS Session with Required QoS Subscription" resource. The body of the HTTP POST message shall include the SCS / AS identifier, UE IP address, IP flow description, QoS reference, and notification address. The body of the HTTP POST message may also include the duration and / or traffic volume intended for the sponsored data connectivity.

[0093] After receiving the HTTP POST message, the SCEF may authorize the request and check whether the total number of requested QoS references exceeds the SCS / AS limit. If authorization is successful, the SCEF shall map the SCS / AS identifier to an AF application identifier and, if necessary, map the SCS / AS identifier to an ASP identity and a sponsor identity. NOTE 1: Before the QoS reference is mapped to the Rx parameter, the SCEF may perform a mapping from the namespace of the third party SCS / AS to the namespace of the operator. NOTE 2: QoS references that refer to predefined QoS information in the SCEF can be mapped to media component descriptions (e.g., bandwidth, media type) according to the SLA.

[0094] If the authorization performed by the SCEF is successful, the SCEF, acting as an AF, shall interact with the PCRF via the Rx interface as specified in 3GPP TS29.214

[10] or 3GPP TS29.201

[13] and trigger the modification of the PCRF-initiated IP-CAN session. The SCEF shall also request to be informed about the transmission resource status, i.e., INDICATION_OF_RELEASE_OF_BEARER, and optionally, INDICATION_OF_LOSS_OF_BEARER and INDICATION_OF_RECOVERY_OF_BEARER. If a duration and / or traffic volume is received from the AF, the SCEF should subscribe the PCRF to the USAGE_REPORT event. If the "ResAllocStatus" characteristic is not supported, the SCEF shall subscribe the PCRF to the INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION and INDICATION_OF_FAILED_RESOURCES_ALLOCATION events, otherwise the SCEF shall subscribe the PCRF to the INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION and INDICATION_OF_FAILED_RESOURCES_ALLOCATION events only if "resconfirmInd" is set to true.

[0095] After receiving an AAA message with a successful result code on the Rx interface from the PCRF, the SCEF shall create a resource representing the AS session "Individual AS Session with the Required QoS", addressed by a URI containing the SCS / AS identity and the AS session identifier created by the SCEF, and shall respond to the SCS / AS with a 201 Created message containing the result in the HTTP response body and a Location header field containing the URI of the created resource. The SCS / AS shall use the received URI in the Location header in subsequent requests to the SCEF to reference this AS session. Otherwise, the SCEF shall send an HTTP response with the corresponding status code to the SCS / AS and include the result in the HTTP response body. If the SCEF receives a response with an error code from the PCRF, the SCEF shall not create the resource and shall respond to the SCS / AS with the corresponding failure code as described in clause 5.2.6.

[0096] To update an established AS session, the SCS / AS may send an HTTP PUT message to the SCEF for the "Individual AS Session with Required QoS Subscription" resource, requesting the replacement of all properties in the existing resource addressed by the URI received in the response to the request that created the resource. The UE IP address shall remain unchanged from the value previously provided. After receiving such a message, the SCEF shall make the changes (as specified in 3GPP TS 29.214

[10] or 3GPP TS 29.201

[13] ) and interact with the PCRF to modify the Rx session. After receiving a response with a successful result code from the PCRF, the SCEF shall replace all properties of the existing resource and send an HTTP response with the corresponding status code to the SCS / AS, including the result in the body of the HTTP response. If the SCEF receives a response with an error code from the PCRF, the SCEF shall not update the resource and shall respond to the SCS / AS with the corresponding failure code as described in Section 5.2.6.

[0097] The SCS / AS may also send an HTTP PATCH message to the SCEF for the "Individual AS Session with Required QoS Subscription" resource requesting to modify some created properties (e.g., flow description). After receiving the HTTP PATCH message, the SCEF shall make the changes (as specified in 3GPP TS29.214

[10] or 3GPP TS29.201

[13] ) and interact with the PCRF to modify the Rx session. After receiving a response from the PCRF, the SCEF shall send an HTTP response with the corresponding status code to the SCS / AS and include the result in the body of the HTTP response.

[0098] When the SCEF receives a traffic plane notification (e.g. a usage threshold has been reached or transmission resources have been lost) or when the SCEF is notified that an Rx session has been terminated (e.g. due to the release of a PDN connection), it shall send an HTTP POST message containing the notified event (e.g. session termination) and the accumulated usage (if received from the PCRF) to the callback URI "notificationUri" provided by the SCS / AS during the creation of the individual AS session with the required QoS subscription. The SCS / AS shall respond with an HTTP response to confirm the received notification.

[0099] To delete an established AS session, the SCS / AS shall send an HTTP DELETE message for the "individual AS session with the required QoS subscription" to the SCEF. After receiving the HTTP DELETE message, the SCEF shall delete all properties (as specified in 3GPP TS29.214

[10] or 3GPP TS29.201

[13] ) and interact with the PCRF to terminate the Rx session. After receiving a response from the PCRF, the SCEF shall send an HTTP response with the corresponding status code to the SCS / AS and include the accumulated usage (if received from the PCRF). TIFF0007749089000003.tif63170

[0100] 5.5.2.1.2 Type: ChargeableParty This type represents the billing destination settings. The same structure is used in the setting request and setting response. TIFF0007749089000004.tif255170TIFF0007749089000005.tif217170

[0101] 5.5.2.1.x Type: NotificationData This type represents the parameters that are notified to the SCS / AS about bearer level events. TIFF0007749089000006.tif62170

[0102] 5.5.2.1.y Type:EventReport This type represents an event report. TIFF0007749089000007.tif80170

[0103] 5.5.2.x Referenced Simple Data Types and Enumerations 5.5.2.x.1 Introduction This section specifies simple data types and enumerations that are referenced from the data structures specified in the previous section. In addition, the data types and enumerations specified in Section 5.2.1 may be referenced.

[0104] 5.5.2.x.2 Simple Data Types The simple data types specified in Table 5.5.2.x.2-1 shall be supported. TIFF0007749089000008.tif24170

[0105] 5.5.2.x.3 Enumeration:Event The enumeration Event represents the events reported by the SCEF. TIFF0007749089000009.tif113170

[0106] 5.5.4 Properties Used The following table specifies the characteristics applicable to the ChargeableParty API. These characteristics are negotiated as described in Section 5.2.7. TIFF0007749089000010.tif117170

[0107] 5.14.2.1.2 Type:AsSessionWithQoSSubscription This type represents an AS session request with a specific QoS for a service provided by an SCS / AS to an SCEF over the T8 interface. The structure is used for subscription requests and responses. TIFF0007749089000011.tif255170TIFF0007749089000012.tif224170

[0108] 5.14.2.2.3 Enumeration:UserPlaneEvent The enumeration UserPlaneEvent represents a user plane event. TIFF0007749089000013.tif202170

[0109] 5.14.4 Properties Used The following table specifies the characteristics applicable to the AsSessionWithQoS API. These characteristics are negotiated as described in Section 5.2.7. TIFF0007749089000014.tif167170

[0110] FIG. 13 is a schematic block diagram of a network node 1300 according to some embodiments of the present disclosure. Optional elements are represented by dashed boxes. The network node 1300 may be, for example, a network node implementing an ARF 1200 or an EF 1202 having the functionality described herein. As shown, the network node 1300 includes one or more processors 1304 (e.g., a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), and / or the like), a memory 1306, and a network interface 1308. The one or more processors 1304 are also referred to herein as processing circuits. The one or more processors 1304 operate to provide one or more functions of the network node 1300 described herein (e.g., one or more functions of the ARF 1200 or the EF 1202 with respect to FIGS. 12A, 12B, and / or 12C). In some embodiments, the functionality is implemented in software stored, for example, in memory 1306 and executed by one or more processors 1304 .

[0111] 14 is a schematic block diagram illustrating a virtualized embodiment of a network node 1300 in accordance with some embodiments of the present disclosure. As used herein, a “virtualized” network node is an implementation of a network node 1300 in which at least a portion of the functionality of the network node 1300 is implemented as a virtual component (e.g., via a virtual machine executing on a physical processing node in the network). As shown, in this example, the network node 1300 may include one or more processing nodes 1400 coupled to or included as part of a network 1402. Each processing node 1400 includes one or more processors 1404 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 1406, and a network interface 1408.

[0112] In this example, the functions 1410 of network node 1300 described herein (e.g., one or more functions of ARF 1200 or EF 1202) are implemented in any desired manner in one or more processing nodes 1400. In some particular embodiments, some or all of the functions 1410 of network node 1300 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment hosted by processing node 1400.

[0113] In some embodiments, a computer program is provided that includes instructions that, when executed by at least one processor, cause the at least one processor to perform functions of the network node 1300 or a node (e.g., processing node 1400) that implement one or more of the functions 1410 of the network node 1300 within a virtual environment according to any of the embodiments described herein. In some embodiments, a carrier is provided that comprises the aforementioned computer program product. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium (e.g., a non-transitory computer-readable medium such as a memory).

[0114] 15 is a schematic block diagram of a network node 1300 according to some other embodiments of the present disclosure. The network node 1300 includes one or more modules 1500, each of which is implemented in software. The modules 1500 provide the functionality of the network node 1300 described herein (e.g., one or more functions of the ARF 1200 or the EF 1202). This discussion is equally applicable to the processing node 1400 of FIG. 14, where the modules 1500 may be implemented in one of the processing nodes 1400 or distributed across multiple processing nodes 1400.

[0115] 16 , according to one embodiment, a communications system includes a communications network 1600, such as a 3GPP-type cellular network, comprising an access network 1602, such as a RAN, and a core network 1604. The access network 1602 comprises multiple base stations 1606A, 1606B, 1606C, such as Node Bs, eNBs, gNBs, or other types of wireless access points (APs), each defining a corresponding coverage area 1608A, 1608B, 1608C. Each base station 1606A, 1606B, 1606C can be connected to the core network 1604 via a wired or wireless connection 1610. A first UE 1612 located in the coverage area 1608C wirelessly connects to or is configured to be paged by the corresponding base station 1606C. A second UE 1614 in the coverage area 1608A can wirelessly connect to the corresponding base station 1606A. Although multiple UEs 1612, 1614 are shown in this example, the disclosed embodiments are equally applicable to situations where only one UE is in the coverage area or connected to the corresponding base station 1606.

[0116] The communications network 1600 itself is connected to a host computer 1616, which may be embodied in hardware and / or software of a standalone server, a cloud-implemented server, a distributed server, or as a processing resource in a server farm. The host computer 1616 may be owned or controlled by a service provider, or may be operated by or on behalf of the service provider. Connections 1618 and 1620 between the communications network 1600 and the host computer 1616 may extend directly from the core network 1604 to the host computer 1616 or may proceed through an optional intermediate network 1622. The intermediate network 1622 may be one of a public network, a private network, or a hosted network, or a combination of two or more of them; if present, the intermediate network 1622 may be a backbone network or the Internet; in particular, the intermediate network 1622 may comprise two or more subnetworks (not shown).

[0117] The communication system of FIG. 16 as a whole enables connectivity between connected UEs 1612, 1614 and a host computer 1616. The connectivity may be described as an over-the-top (OTT) connection 1624. The host computer 1616 and connected UEs 1612, 1614 are configured to communicate data and / or signaling via the OTT connection 1624 using the access network 1602, the core network 1604, any intermediate networks 1622, and possible further infrastructure (not shown) as intermediaries. The OTT connection 1624 may be transparent in the sense that the involved communication devices through which the OTT connection 1624 passes are unaware of the routing of the uplink and downlink communications. For example, the base station 1606 may not be, or need not be, informed about the past routing of incoming downlink communications involving data originating from the host computer 1616 that is to be forwarded (e.g., handed over) to the connected UE 1612. Similarly, the base station 1606 does not need to be aware of the future routing of outgoing uplink communications originating from the UE 1612 and destined for the host computer 1616 .

[0118] An exemplary implementation of the UE, base station, and host computer described in the previous paragraph, according to one embodiment, will now be described with reference to FIG. 17. In the communication system 1700, the host computer 1702 comprises hardware 1704 including a communication interface 1706 configured to set up and maintain wired or wireless connections with interfaces of different communication devices of the communication system 1700. The host computer 1702 further comprises a processing circuit 1708, which may have storage and / or processing capabilities. In particular, the processing circuit 1708 may comprise one or more programmable processors, ASICs, FPGAs, or combinations thereof (not shown) adapted to execute instructions. The host computer 1702 further comprises software 1710, which is stored on or accessible by the host computer 1702 and executable by the processing circuit 1708. The software 1710 includes a host application 1712. The host application 1712 may be operable to provide services to a remote user, such as the UE 1714, connecting via an OTT connection 1716 that terminates at the UE 1714 and the host computer 1702. In providing services to the remote user, the host application 1712 may provide user data that is transmitted using the OTT connection 1716.

[0119] The communications system 1700 further includes a base station 1718 provided within the communications system, the base station 1718 comprising hardware 1720 that enables the base station 1718 to communicate with the host computer 1702 and the UE 1714. The hardware 1720 may include a communications interface 1722 for setting up and maintaining wired or wireless connections with interfaces of different communications devices of the communications system 1700, as well as a wireless interface 1724 for setting up and maintaining at least a wireless connection 1726 with a UE 1714 located in a coverage area (not shown in FIG. 17 ) served by the base station 1718. The communications interface 1722 may be configured to facilitate a connection 1728 to the host computer 1702. The connection 1728 may be direct, or the connection 1728 may pass through a core network of the communications system (not shown in FIG. 17 ) and / or one or more intermediate networks outside the communications system. In the illustrated embodiment, the hardware 1720 of the base station 1718 further includes processing circuitry 1730, which may comprise one or more programmable processors, ASICs, FPGAs, or combinations thereof (not shown) adapted to execute instructions. The base station 1718 further has software 1732 stored internally or accessible via an external connection.

[0120] The communications system 1700 further includes the previously mentioned UE 1714. The hardware 1734 of the UE 1714 may include a wireless interface 1736 configured to set up and maintain a wireless connection 1726 with a base station serving a coverage area in which the UE 1714 is currently located. The hardware 1734 of the UE 1714 further includes a processing circuit 1738, which may comprise one or more programmable processors, ASICs, FPGAs, or combinations thereof (not shown) adapted to execute instructions. The UE 1714 further includes software 1740, which is stored on or accessible by the UE 1714 and executable by the processing circuit 1738. The software 1740 includes a client application 1742. The client application 1742, with the support of the host computer 1702, may be operable to provide services to a human or non-human user of the UE 1714. On the host computer 1702, a running host application 1712 may communicate with a running client application 1742 via an OTT connection 1716 that terminates at the UE 1714 and the host computer 1702. In providing services to a user, the client application 1742 may receive request data from the host application 1712 and provide user data in response to the request data. The OTT connection 1716 may carry both the request data and the user data. The client application 1742 may interact with the user to generate the user data that the client application 1742 provides.

[0121] It should be noted that the host computer 1702, base station 1718, and UE 1714 shown in Figure 17 may be similar to or equivalent to the host computer 1616, one of the base stations 1606A, 1606B, 1606C, and one of the UEs 1612, 1614, respectively, of Figure 16. That is, the inner workings of these entities may be as shown in Figure 17, and alternatively, the surrounding network topology may be that of Figure 16.

[0122] 17, the OTT connection 1716 is depicted abstractly to show communication between the host computer 1702 and the UE 1714 via a base station 1718, without explicit reference to intermediary devices and the strict routing of messages through these devices. The network infrastructure may determine the routing, which may be configured to be hidden from the UE 1714, the service provider operating the host computer 1702, or both. While the OTT connection 1716 is active, the network infrastructure may also make decisions as it dynamically changes the routing (e.g., based on load balancing considerations or network reconfiguration).

[0123] The wireless connection 1726 between the UE 1714 and the base station 1718 follows the teachings of embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of the OTT service provided to the UE 1714 using the OTT connection 1716 of which the wireless connection 1726 forms the last segment.

[0124] Measurement procedures may be provided to monitor data rates, latency, and other factors that one or more embodiments target for improvement. There may also be optional network functionality for reconfiguring the OTT connection 1716 between the host computer 1702 and the UE 1714 in response to fluctuations in the measurement results. The measurement procedures and / or the network functionality for reconfiguring the OTT connection 1716 may be implemented in the software 1710 and hardware 1704 of the host computer 1702, or in the software 1740 and hardware 1734 of the UE 1714, or both. In some embodiments, sensors (not shown) may be deployed in or associated with communication devices through which the OTT connection 1716 passes, and the sensors may participate in the measurement procedures by providing values ​​of the monitored quantities exemplified above or other physical quantities from which the software 1710, 1740 may calculate or estimate the monitored quantities. The reconfiguration of the OTT connection 1716 may include message formats, retransmission settings, preferred routing, etc.; the reconfiguration need not affect the base station 1718, and the reconfiguration may be unknown or unrecognizable to the base station 1718. Such procedures and functions are known and may be practiced in the art. In some embodiments, the measurements may involve proprietary UE signaling that facilitates the host computer 1702 measurements of throughput, propagation time, latency, etc. The measurements may be implemented in that the software 1710 and 1740 cause messages, specifically empty or “dummy” messages, to be sent using the OTT connection 1716 while the software 1710 and 1740 monitors propagation times, errors, etc.

[0125] FIG. 18 is a flowchart illustrating a method implemented in a communications system, according to one embodiment. The communications system includes a host computer, a base station, and a UE, which may be as described with reference to FIGS. 16 and 17. For brevity of this disclosure, only drawing references to FIG. 18 are included in this section. In step 1800, the host computer provides user data. In sub-step 1802 of step 1800 (which may be optional), the host computer provides the user data by executing a host application. In step 1804, the host computer initiates a transmission carrying the user data to the UE. In step 1806 (which may be optional), the base station transmits the user data carried in the host computer initiated transmission to the UE, in accordance with the teachings of embodiments described throughout this disclosure. In step 1808 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

[0126] FIG. 19 is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be as described with reference to FIGS. 16 and 17. To simplify this disclosure, only drawing references to FIG. 19 are included in this section. In step 1900 of the method, the host computer provides user data. In an optional substep (not shown), the host computer provides the user data by executing a host application. In step 1902, the host computer initiates a transmission carrying the user data to the UE. In accordance with the teachings of embodiments described throughout this disclosure, the transmission may be via a base station. In step 1904 (which may be optional), the UE receives the user data carried in the transmission.

[0127] FIG. 20 is a flowchart illustrating a method implemented in a communications system according to one embodiment. The communications system includes a host computer, a base station, and a UE, which may be as described with reference to FIGS. 16 and 17. To simplify this disclosure, only drawing references to FIG. 20 are included in this section. In step 2000 (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step 2002 (which may be optional), the UE provides user data. In sub-step 2004 (which may be optional) of step 2000, the UE provides the user data by executing a client application. In sub-step 2006 (which may be optional) of step 2002, the UE executes a client application that provides the user data in response to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the particular manner in which the user data is provided, in sub-step 2008 (which may be optional), the UE initiates transmission of the user data to the host computer. In method step 2010, the host computer receives user data transmitted from the UE in accordance with the teachings of the embodiments described throughout this disclosure.

[0128] Figure 21 is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be as described with reference to Figures 16 and 17. For brevity of this disclosure, only drawing references to Figure 21 are included in this section. In step 2100 (which may be optional), the base station receives user data from the UE in accordance with the teachings of embodiments described throughout this disclosure. In step 2102 (which may be optional), the base station initiates transmission of the received user data to the host computer. In step 2104, the host computer receives the user data carried in a transmission initiated by the base station.

[0129] Any suitable step, method, feature, function, or benefit disclosed herein may be performed through one or more functional units or modules of one or more virtual devices. Each virtual device may comprise several of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory, such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. The program code stored in memory includes program instructions for implementing one or more communication and / or data communication protocols, as well as instructions for executing one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause each functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0130] Although the processes in the figures may indicate a particular order of operations performed by some embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform operations in a different order, combine some operations, overlap some operations, etc.).

[0131] In this disclosure, at least some of the following abbreviations may be used: In case of inconsistencies between abbreviations, the way the abbreviation is used above shall prevail: If listed multiple times below, the first listing shall prevail over any subsequent listings. 3GPP 3rd Generation Partnership Project 5G (fifth generation) 5GC 5th generation core 5GS 5th Generation System AF application function AMF access and mobility features ·AN Access Network AP access point ARF application related functions AS Application Server ASIC Application Specific Integrated Circuit AUSF authentication server function CPU Central Processing Unit ·DN Data Network DSP Digital Signal Processor eNB Enhanced or Evolved Node B EF public features EPS Evolved Packet System E-UTRA Enhanced Universal Terrestrial Radio Access FPGA Field Programmable Gate Array ·gNB New wireless base station gNB-DU New Radio Base Station Distributed Unit HSS Home Subscriber Server IoT Internet of Things IP Internet Protocol LTE Long-Term Evolution MME Mobility Management Entity MTC Machine Type Communication NEF network publishing function NF network function ·NR New Radio NRF Network Function Repository Function NSSF network slice selection function OTT (Over-the-Top) PC Personal Computer PCF policy control function PF policy function PCRF policy and charging rule function P-GW Packet Data Network Gateway QoS Quality of Service RAM Random Access Memory RAN Radio Access Network ROM (Read-Only Memory) RRH Remote Radio Head RTT Round Trip Time SCEF Service Capability Publication Function SCS Service Capability Server SMF session management function TCI Transmission Setting Indicator TRP sending / receiving points ·UDM Integrated Data Management UE User Equipment UPF user plane function

[0132] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure, and all such improvements and modifications are considered to be within the scope of the concepts disclosed herein.

Claims

1. A method of operation of an Exposure Function (EF) (1202), comprising: receiving (1210) a request from an Application Related Function (ARF) (1200) including a resource allocation confirmation indication indicating whether a resource allocation status notification is required, wherein the resource allocation status notification indicates a resource allocation success or a resource allocation failure; The method, wherein the request further includes a resource allocation status characteristic indicating whether the ARF supports resource allocation status.

2. 12. The method of claim 1, further comprising: transmitting (1218) a response to the ARF including a status response characteristic indicating whether both the ARF and the EF support the resource allocation status.

3. 3. The method of claim 2, wherein the response further includes a resource allocation status notification when the resource allocation confirmation indication indicates that the resource allocation status notification is required by the ARF and the status response characteristic indicates that both the ARF and the EF support the resource allocation status.

4. 3. The method of claim 2, wherein when the resource allocation confirmation indication indicates that the resource allocation status notification is not requested by the ARF and / or the status response characteristic indicates that at least one of the ARF and the EF does not support the resource allocation status, the method further comprises: refraining from waiting for a resource allocation status notification from the EF (1220).

5. 5. The method of claim 4, wherein when the resource allocation confirmation indication indicates that the resource allocation status notification is not requested by the ARF, the method further comprises: refraining from waiting for a resource allocation status notification from the EF (1220).

6. 5. The method of claim 4, wherein when the status response characteristic indicates that at least one of the ARF and the EF does not support the resource allocation status, the method further comprises: refraining from waiting for a resource allocation status notification from the EF (1220).

7. The request: a request to set up an AS or AF session with the required QoS; a request to update the AS session or the AF session with a required QoS; A request to set up a billing destination when setting up an AS or AF session, or A request to change the billing destination during the AS session or the AF session and The response: a response to set up an AS or AF session with the required QoS; a response to update the AS session or the AF session with the required QoS; A response to set up a billing destination when setting up an AS or AF session, or Response for changing the billing destination during the AS session or the AF session 7. The method according to claim 2, wherein

8. the ARF is in a fifth generation system; The ARF is an Application Function (AF) (1100), The method according to any one of claims 2 to 7, wherein the EF is a Network Publishing Function (NEF) (1102).

9. The request: A request to set up an AF session with the required QoS; a request to update the AF session with the required QoS; A request to set up a billing destination when setting up an AF session, or A request to change the billing destination during the AF session and The response: a response to set up an AF session with the required QoS; a response to update the AF session with the required QoS; A response to set up a billing destination when setting up an AF session, or Response for changing the charging destination during the AF session The method of claim 8, wherein

10. the ARF is in a fourth generation system; The ARF is a service capability server or application server (SCS / AS) (1000), The method according to any one of claims 2 to 7, wherein the EF is a Service Capabilities Exposure Function (SCEF) (1102).

11. The request: a request to set up an AS session with the required QoS; a request to update the AS session with the required QoS; A request to set up a billing destination when setting up an AS session, or A request to change the billing destination during the AS session and The response: a response to set up an AS session with the required QoS; a response for updating the AS session with the required QoS; A response to set up the billing destination when setting up an AS session, or Response for changing the billing destination during the AS session The method of claim 10, wherein

12. The method of claim 1 , further comprising: after receiving the request, determining whether the resource allocation status is supported by the EF (step 1212).

13. and / or granting the request from the ARF (step 1214).

13. The method of claim 12, further comprising interacting with a policy function (PF) (1204) when said authorization is granted (step 1216).

14. The method of claim 13, wherein the PF is a Policy and Charging Rules Function (PCRF) (1006) or a Policy Control Function (PCF) (1104).

15. 15. The method of claim 13 or 14, wherein when the resource allocation status is not supported by at least one of the ARF and the EF, the EF subscribes to the PF to obtain the resource allocation status notification, but does not send the resource allocation status notification to the ARF.

16. The method of claim 13 or 14, wherein when both the ARF and the EF support the resource allocation status, the EF subscribes to the PF to obtain the resource allocation status notification only when the resource allocation status notification is required by the ARF.

17. A publishing function (EF) (1202) adapted to perform the method according to any one of claims 1 to 16.

18. A network node (1300) implementing an Exposed Function (EF) (1202), comprising: A network interface (1308); a processing circuit (1304) associated with said network interface; 17. A network node (1300) comprising: a processing circuit configured to cause said network node to execute a method according to any one of claims 1 to 16.

Images