System and method for conveying a change in resources associated with a subscription

Abstract

According to an aspect, there is provided a method for execution by a first network node configured to interact with a core network to provide services. The method involves sending, to a second network node, a subscription request for receiving notification reports of NAT (Network Address Translation) information related to one or more applications or all applications deployed in an application server for a PDU (Protocol Data Unit) session; The method also involves receiving, from the second network node, a message indicating change in public IP address(es) and / or port(s) associated with the PDU session, wherein the notification report is received in accordance with an event reporting mode. Finally, the method involves implementing the change accordingly. For example, the first network node can update an internal configuration or settings based on the change for future communication. In this way, finite resources can be released and / or reused when appropriate.

Description

[0001] SYSTEM AND METHOD FOR CONVEYING A CHANGE IN RESOURCES ASSOCIATED WITH A SUBSCRIPTION

[0002] Related Application

[0003] [1] This application claims priority from European application no. 24383071.8 filed on October 3, 2024 and entitled “System and Method for Conveying a Change in Resources Associated with a Subscription”, which is incorporated by reference in its entirety.

[0004] Field of the Disclosure

[0005] [2] This disclosure relates to mobile communication systems, and more particularly to resource handling for a PDU (Packet Data Unit) session.

[0006] Background

[0007] [3] Referring now to Figure 1 , shown is a block diagram of a 5G (Fifth Generation) System Architecture 200 for an SBA (Service-Based Architecture) UPF (User Plane Function) 202. This is a reference model (in service-based interface representation) with a focus on the UPF 202. Some notable architectural aspects include an AF (Application Function) 204, an SMF (Session Management Function) 206, and the UPF 202. These notable architectural aspects are briefly described below.

[0008] [4] The AF 204 interacts with a CN (Core Network) in order to provide services that may for example influence traffic routing (and / or service chaining) and interact with the Policy and charging control framework. The AF 204 is only with respect to its interaction with the CN. Based on operator deployment, an AF 204 is considered to be trusted by an operator and can be allowed to interact directly with relevant NFs (Network Functions). An AF 204 not allowed by the operator to access directly the NFs shall use the external exposure framework and interact via an NEF (Network Exposure Function) 203. P112132WQ01

[0009] - 2 -

[0010] [5] The SMF 206 support(s) different functionalities. The SMF 206 is in charge of session management, for example PDU (Packet Data Unit) session establishment, modification and release, including setting up and maintaining a tunnel between the UPF 202 and an AN (Access Network) node. The SMF 206 receives PCC (Policy and Charging Control) rules for a PDU session from the PCF and configures the UPF 202 accordingly using PDRs (Packet Detection Rules) and other rules associated with QoS (Quality of Service), forwarding or reporting instructions among other. Based on the PCC rules, the SMF 206 determines which QoS flows are to be established between a UE (User Equipment) and the UPF 202, and instructs the UE, the AN (via the AMF), and the UPF 202 accordingly. The SMF 206 also manages indirect subscriptions to the UPF exposure when the subscription is per a certain UE or groups of UEs.

[0011] [6] The UPF 202 supports handling of user plane traffic based on the rules received from the SMF 206, for example packet inspection and different enforcement actions such as Sponsored Data or QoS handling.

[0012] [7] 3GPP (Third Generation Partnership Project) introduced in Release 18 a standardized SBI (Service Based Interface) for UPF data collection. Before that, only the SMF 206 had an interface towards the UPF 202 (i.e. N4 interface), based on PFCP (Packet Forwarding Control Protocol). The SBI interface does not replace the N4 interface and is not limited to SMF 206, and is instead used by other NFs as the NWDAF (Network Data Analytics Function) 205 to do data collection from the UPF 202.

[0013] [8] UPEAS (UPF enhancement for Exposure And SBA) is a work item under the 3GPP - see SP-240995 entitled “New WID on UPF enhancement for Exposure And SBA Phase 2” dated June 18-21 , 2024. UPF Event Exposure service is supported in 5GS since Release 17 and enhanced in Release 18. Release 18 has defined mechanisms for both direct and indirect subscription to the UPF Event Exposure Service. In Release 19, further study is proposed on whether and how to enhance UPF information exposure, including the direct or indirect subscription to the UPF event exposure service.

[0014] [9] According to UPEAS, Key Issue #2 is to identify use cases for enhancements on UPF event exposure service and for each use case determine whether and how the consumer can directly or indirectly contact the UPF 202 for its subscription. The following aspects may be studied in relation to UPF exposure service(s): whether there are use cases that involve other enhancements on UPF exposure services.

[0015]

[0010] According to UPEAS, conclusions for Key Issue #2 include:

[0016] • UPF event exposure service is enhanced to allow NF consumer to obtain one NATed (Network Address Translated) UE public IP (Internet Protocol) address and Port for a particular PDU Session from the SMF 206 and UPF, based on the private UE IP address allocated by 5GC (Fifth Generation Core).

[0017] • The remote end IP address is mandatory input for the above to avoid exposing the full NAT mapping for a UE.

[0018] NOTE 1 : Whether it is needed to define a new SMF service will be determined in normative phase.

[0019] • NEF / NWDAF can use UE IP address to discover the PSA UPF and subscribe directly to PSA UPF for data collection.

[0020]

[0011] 3GPP SA2 has approved various CRs (Change Requests) including 3GPP SP-241305 entitled “Enhancement of getting public UE IP address and port number” dated Sept 2024, 3GPP SP-241306 entitled “Enhancement of getting public UE IP address and port number” dated Sept 2024, and 3GPP SP-241307 entitled “Public UE IP address exposure” dated Sept 2024, which are hereinafter collectively referred to as the “approved CRs”. These approved CRs introduce changes for 3GPP TS 23.501 entitled “System architecture for the 5G System (5GS)” version 18.6.0 dated June 2024 (hereinafter “TS 23.501”), 3GPP TS 23.502 entitled “Procedures for the 5G System (5GS)” version 18.6.0 dated June 2024 (hereinafter “TS 23.502”), and 3GPP TS 23.288 entitled “Architecture enhancements for 5G System (5GS) to support network data analytics services” version 18.6.0 dated June 2024 (hereinafter “TS 23.288”). These approved CRs aim to support a new type of event for UPF event exposure, specifically to obtain one NATed public IP address and port for a particular PDU session. As per the approved CRs, an AF provides, as input for the UPF event exposure subscription, a private IP address (previously gathered from the 5G Core), an endpoint IP address and optional a DNN (Data Network Name). The intent of the approved CRs is to address the use case where an AF seeks to identify the public IP address and port(s) of a specific UE that is sending traffic to the AF, in order to provide ad-hoc services to the UE, for example due to a special subscription to the AF where traffic may be prioritized.

[0021] Summary of the Disclosure

[0022]

[0012] It is noted that IP(s) and port(s) are finite resources. However, the proposed method in the approved CRs does not include a mechanism to notify the AF when a previously notified IP(s) and port(s) combination has been released for the UE and is no longer valid. It is desirable to have a mechanism to release and reuse such finite resources under certain conditions. In addition, the AF may wish to identify only the public IP(s) and port(s) of specific traffic flows (i.e., flows that match certain applications or filters in the UPF) rather than all the IP(s) and port(s) of the UE. The application and filters may be provided by the AF to the UPF through PFD(s) (Packet Flow Descriptions). This is currently not feasible with the proposed solution in the approved CRs.

[0023]

[0013] Some embodiments disclosed herein set out to solve, address, or mitigate one or more of the foregoing deficiencies with the proposed solution in the approved CRs. For example, some embodiments provide a mechanism that enables an AF to retrieve Public IP(s) and port(s) that certain PDU session are using to connected with a remote end IP, and to receive updates when resources are allocated or released for the PDU session. Also, some embodiments extend a subscription to uniquely identify a PDU session based on the new input parameters, allow further filtering (per application and / or filter), and allow extended information in the notification per destination port and configurable notification report type.

[0024]

[0014] According to an aspect, there is provided a method for execution by a first network node configured to interact with a core network to provide services. The method involves sending, to a second network node, a subscription request for receiving notification reports of NAT (Network Address Translation) information related to one or more applications or all applications deployed in an application server for a PDU (Protocol Data Unit) session. The method also involves receiving, from the second network node, a message indicating change in public IP address(es) and / or port(s) associated with the PDU session, wherein the notification report is received in accordance with an event reporting mode. Finally, the method involves implementing the change accordingly.

[0025]

[0015] For example, the first network node can update an internal configuration or settings based on the change for future communication. In this way, finite resources can be released and / or reused as may be appropriate. For example, in the case of an IP address and / or port having been released, such resources can be released and perhaps reused for some other purpose. Additionally, or alternatively, in the case of a new IP address and / or port having been assigned, such resources can be assigned as appropriate.

[0026]

[0016] In some implementations, the event reporting mode is continuous event triggered for a plurality of notification reports. In some implementations, the notification reports are continuously received based on an event being triggered until the subscription to this event ends due to a maximum number of notification reports or the event being unsubscribed explicitly.

[0027]

[0017] In some implementations, the method also involves sending, to the second network node, a message specifying parameters for the subscription including the public IP address(es) and / or port(s) for the subscription, such that the subscription can be established based on the parameters as specified by the first network node. In some implementations, the parameters further comprise any one or more of (i) application ID(s) and / or traffic filters, (ii) extended-info, and (iii) notification-mode.

[0028]

[0018] In some implementations, the first network node comprises an AF (Application Function) and the second network node comprises an NEF (network Exposure Function).

[0029]

[0019] According to another aspect, there is provided a non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a first network node, configure the first network node to implement a method as summarized above.

[0020] According to another aspect, there is provided a first network node. The first network node has a network interface configured to communicate with other network nodes, and control circuitry coupled to the network interface. The control circuitry is configured to send, to a second network node, a subscription request for receiving notification reports of NAT (Network Address Translation) information related to one or more applications or all applications deployed in an application server for a PDU (Protocol Data Unit) session. The control circuitry is configured to receive, from the second network node, a message indicating change in public IP address(es) and / or port(s) associated with a subscription, wherein the notification report is received in accordance with an event reporting mode. The control circuitry is configured to implement the change accordingly. The control circuitry is configured to implement a method as summarized above.

[0030]

[0021] According to another aspect, there is provided a method for execution by a third network node. The method involves receiving a subscription from a first or second network node, wherein the subscription is for receiving notification reports of NAT (Network Address Translation) information related to one or more applications or all applications deployed in an application server for a PDU (Protocol Data Unit) session. The method also involves sending a notification report to the first or second network node, wherein the notification report is sent in accordance with an event reporting mode.

[0031]

[0022] In some implementations, the event reporting mode is continuous event triggered for a plurality of notification reports. In some implementations, the third network node continuously generates the notification reports based on an event being triggered until the subscription to this event ends due to a maximum number of notification reports or the event being unsubscribed explicitly. In some implementations, the method also involves receiving, from the first or second network node, a message indicating the event reporting mode.

[0032]

[0023] In some implementations, the notification reports indicate whether there is a change in public IP address(es) and / or port(s) associated with the PDU session. In some implementations, the change in the public IP address(es) and / or port(s) includes an IP address and / or port having been assigned. In some implementations, the change in the public IP address(es) and / or port(s) associated with the PDU session includes an IP address and / or port having been released.

[0033]

[0024] In some implementations, the method also involves receiving, from the first or second network node, a message specifying parameters for the subscription including public IP address(es) and / or port(s) for the subscription. The subscription can be established based on the parameters as specified by the first or second network node. In some implementations, the parameters further comprise any one or more of (i) application ID(s) and / or traffic filters, (ii) extended-info, and (iii) notification-mode.

[0034]

[0025] In some implementations, the second network node comprises an NEF (network Exposure Function), and the third network node comprises a UPF (User Plane Function).

[0035]

[0026] According to another aspect, there is provided a non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a third network node, configure the third network node to implement a method as summarized above.

[0036]

[0027] According to another aspect, there is provided a third network node. The third network node has a network interface configured to communicate with other network nodes, and control circuitry coupled to the network interface. The control circuitry is configured to receive a subscription from first or second network node, wherein the subscription is for receiving notification reports of NAT (Network Address Translation) information related to one or more applications or all applications deployed in an application server for a PDU (Protocol Data Unit) session. The control circuitry is also configured to send a notification report to the first or second network node, wherein the notification report is sent in accordance with an event reporting mode. The control circuitry is configured to implement a method as summarized above.

[0037]

[0028] Other aspects and features of the present disclosure will become apparent, to those ordinarily skilled in the art, upon review of the following description of the various embodiments of the disclosure. Brief Description of the Drawings

[0038]

[0029] Embodiments will now be described with reference to the attached drawings in which:

[0039] Figure 1 is a block diagram of a 5G (Fifth Generation) System Architecture for an SBA (Service-Based Architecture) UPF (User Plane Function);

[0040] Figure 2 is a block diagram of a communication system, in accordance with an embodiment of the disclosure;

[0041] Figures 3 is a sequence diagram of a method of conveying a change in resources associated with a PDU session;

[0042] Figure 4 is a sequence diagram of another method of conveying a change in resources associated with a PDU session;

[0043] Figure 5 is a sequence diagram of a method of subscription creation;

[0044] Figure 6 is a schematic of an example cellular communications system in which some embodiments of the present disclosure may be implemented;

[0045] Figures 7A and 7B are block diagrams of a wireless communication system represented as a 5G network architecture in which some embodiments of the present disclosure may be implemented;

[0046] Figures 8 and 10 are block diagrams of a radio access node according to some embodiments of the present disclosure;

[0047] Figure 9 is a block diagram that illustrates a virtualized embodiment of a radio access node according to some embodiments of the present disclosure; and

[0048] Figures 11 and 12 are block diagrams of a wireless communication device.

[0049] Detailed Description of Embodiments

[0050]

[0030] It should be understood at the outset that although illustrative implementations of one or more embodiments of the present disclosure are provided below, the disclosed systems and / or methods may be implemented using any number of techniques. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended embodiment along with their full scope of equivalents.

[0051] Introduction

[0052]

[0031] Referring now to Figure 2, shown is a block diagram of a communication system 100, in accordance with an embodiment of the disclosure. The communication system 100 has a first network node 110 (e.g. AF) configured to interact with a core network to provide services, a second network node 120 (e.g. NEF), a third network node 130 (e.g. NRF) configured to handle user plane traffic, and may have other network nodes 140a-c as well. The network nodes 110, 120, 130 and 140a-140c are operatively coupled via at least one network 102. Details of the network 102 are omitted for simplicity, but the network 102 may for example include components of a core network and components of a radio access network. The communication system 100 also has several communication devices 150a-150c such as UEs, and may have other components that are not shown for simplicity.

[0053]

[0032] The first network node 110 has a network interface 115 configured to communicate with other nodes of the communication system 100, a CRM 119, and control circuitry 116 coupled to the network interface 115 and the CRM 119. In some implementations, the control circuitry 116 includes a processor 117 that executes software, which can stem from a memory 118. However, other implementations are possible and are within the scope of this disclosure. The first network node 110 can have additional components, but these are not shown for simplicity.

[0054]

[0033] The second network node 120 has a network interface 125 configured to communicate with other nodes of the communication system 100, a CRM 129, and control circuitry 126 coupled to the network interface 125 and the CRM 129. In some implementations, the control circuitry 126 includes a processor 127 that executes software, which can stem from a memory 128. However, other implementations are possible and are within the scope of this disclosure. The second network node 120 can have additional components, but these are not shown for simplicity.

[0034] The third network node 130 has a network interface 135 configured to communicate with other nodes of the communication system 100, a CRM 139, and control circuitry 136 coupled to the network interface 135 and the CRM 139. In some implementations, the control circuitry 136 includes a processor 137 that executes software, which can stem from a memory 138. However, other implementations are possible and are within the scope of this disclosure. The third network node 130 can have additional components, but these are not shown for simplicity.

[0055]

[0035] The control circuitry 116, 126 and 136 of the network nodes 110, 120 and 130 collectively operate to implement a method of conveying a change in resources associated with a PDU session. The operation by the network nodes 110, 120 and 130 will be described below with reference to Figure 3. Although the method of Figure 3 is described below with reference to the communication system 100 shown in Figure 1 , it is to be understood that the method of Figure 3 is applicable to other communication systems. In general, the method of Figure 3 is applicable to any appropriately configured communication system.

[0056]

[0036] At step 3-1 , the second network node 120 establishes a subscription between the first network node 110 (e.g. AF) and the third network node 430 (e.g. UPF). Details of how the subscription is established, including relevant signalling, are omitted for simplicity. Example details are provided later with reference to Figure 4.

[0057]

[0037] It is noted that there may be an existing PDU session(s) that utilizes resources including public IP address(es) and / or port(s). The PDU session is a logical connection that can provide end-to-end user plane data connectivity between a UE 154a and a data network within the networks 102. At step 3-2, unbeknownst to the first network node 110, there is a change to those resources.

[0058]

[0038] At step 3-3, in accordance with an embodiment of the disclosure, upon the change in the public IP(s) and / or port(s) associated with the PDU session, the second network node 120 sends, to the first network node 110, a message indicating the change in the public IP address(es) and / or port(s). In some implementations, the notification report is received in accordance with an event reporting mode (e.g. one-time, periodic, or continuous event triggered).

[0059]

[0039] In this way, changes to the public IP address(es) and / or port(s) can be provided to the first network node 110, which in turn can implement those changes at step 3-4. For example, the first network node 110 can update an internal configuration or settings based on the change so that future communication. In the case of an IP address and / or port having been released, such resources can be removed and perhaps reused for some other purpose. Additionally, or alternatively, in the case of a new IP address and / or port having been assigned, such resources can be assigned as appropriate.

[0060]

[0040] In some implementations, the event reporting mode is continuous event triggered for a plurality of notification reports. In some implementations, the notification reports are continuously received based on an event being triggered until the subscription to this event ends due to a maximum number of notification reports or the event being unsubscribed explicitly.

[0061]

[0041] In some implementations, as shown at step 3-2a, the third network node 130 sends, to the second network node 120, a message indicating the change in the public IP address(es) and / or port(s) associated with the PDU session. The message at step 3-2a may be similar to the message at step 3-3. In this way, the second network node 120 acts as a conduit to relay information from the third network node 130 to the first network node 110. However, other implementations are possible, such as the second network node 120 determining or detecting the change in the public IP address(es) and / or port(s) associated with the PDU session.

[0062]

[0042] In another embodiment, the subscription is for receiving notification reports of NAT (Network Address Translation) information related to one or more applications or all applications deployed in the first network node 110 for the PDU session. The second network node 120 receives a notification report from the third network node 120, and then forwards the notification report to the first network node 110.

[0043] In some implementations, the second network node 120 receives, from the third network node 130, a message indicating whether the subscription is included for immediate reporting. This can be the same message shown at step 3-2a, or a separate message. Regardless, the second network node 120 can learn whether there is to be immediate reporting or not. In this way, configurable notification report type can be supported.

[0063]

[0044] In some implementations, the second network node 120 receives, from the first network node 110, a message specifying parameters for the subscription including the public IP address(es) and / or port(s) for the subscription. The subscription is established based on the parameters as specified by the first network node. In this way, the first network node 110 can identify only the public IP(s) and port(s) of specific traffic flows (i.e., flows that match certain applications or filters in the UPF) rather than all the IP(s) and port(s) of the UE. Other parameters can be specified as well. Example details are provided later with reference to Figure 4.

[0064]

[0045] According to another embodiment of the disclosure, there is provided a non- transitory CRM having recorded thereon statements and instructions that, when executed by the processor 117 of the first network node 110, implement a method as described herein. The non-transitory computer readable medium can be the memory 118 and / or the CRM 119 of the first network node 110 shown in Figure 2, or some other non-transitory CRM.

[0065]

[0046] According to another embodiment of the disclosure, there is provided a non- transitory CRM having recorded thereon statements and instructions that, when executed by the processor 127 of the second network node 120, implement a method as described herein. The non-transitory computer readable medium can be the memory 128 and / or the CRM 129 of the second network node 120 shown in Figure 2, or some other non-transitory CRM.

[0066]

[0047] According to another embodiment of the disclosure, there is provided a non- transitory CRM having recorded thereon statements and instructions that, when executed by the processor 137 of the third network node 130, implement a method as described herein. The non-transitory computer readable medium can be the memory 138 and / or the CRM 139 of the third network node 130 shown in Figure 2, or some other non-transitory CRM.

[0067]

[0048] Examples of a non-transitory CRM include memory, an SSD (Solid State Drive), a hard disk drive, a CD (Compact Disc), a DVD (Digital Video Disc), a BD (Blu-ray Disc), a memory stick, etc. Other non-transitory CRMs are also possible.

[0068]

[0049] The illustrated examples described herein focus on software implementations. However, other implementations are possible and are within the scope of this disclosure. Other implementations can include additional or alternative hardware components, such as any appropriately configured FPGA (Field-Programmable Gate Array), ASIC (Application-Specific Integrated Circuit), and / or microcontroller, for example. Thus, the control circuitry 116 of the first network node 114, the control circuitry 126 of the second network node 124, and the control circuitry 136 of the third network node 134 can instead be implemented with any suitable combination of hardware, software and / or firmware.

[0069]

[0050] Further example details are provided in the following sections. It is to be understood that the following sections are very specific and are provided merely for exemplary purposes, such that other implementations are possible and within the scope of the disclosure.

[0070] Further Example Details

[0071]

[0051] Referring now to Figure 4, shown is a sequence diagram of another method of conveying a change in resources associated with a PDU session. The method can be executed by a communication system, for example the communication system 100 shown in Figure 2. In the illustrated example, an AF 410, an NEF 420, and a UPF 430 are provided as 5G implementations of the first network node 110, the second network node 110, and third network node 110, respectively, and additional nodes are also provided including an NWDAF 411 and an NRF 431 . However, other implementations are possible.

[0052] At step 4-0, the AF 410 obtain a private IP from a 5GC that will be used to query the UPF 430 about the NAT translation IP(s) and port(s).

[0072]

[0053] At step 4-1 , the untrusted AF 410 subscribes to the Nnef_UEAddress service by sending a subscription request. In specific implementations, the subscription request includes some or all of the following parameters:

[0073] • Service-Target: UE private IP, remote end public IP, and DNN.

[0074] #NOTE: DNN is used to identify the target UE when overlapping IP is supported on the UPF 430.

[0075] • Service-Filter: S-NSSAI and / or either Application ID(s) or Traffic filters.

[0076] • Extended-Info: This IE when true, indicates request for extended information per destination port (e.g. tethering indication, traffic type, matched application or traffic filter)

[0077] • Notification-Mode: This IE indicates how the notifications shall be generated: o Full Report: Each new notification will send the entire list of public IP(s) and port(s) associated with the service target, e.g.

[0078] First Notification:

[0079] • Public IP1 : A.B.C.D Port: 1 Extended-Info: tethering

[0080] • Public IP1 : A.B.C.D Port: 2 Extended-Info: video-traffic

[0081] • Public IP1 : A.B.C.D Port: 3 Extended-Info: n / a

[0082] Second Notification:

[0083] • Public IP1 : A.B.C.D Port: 1 Extended-Info: tethering

[0084] • Delta Report: Each new notification will send the modification from previous report of public IP(s) and port(s) associated with the service target, e.g. o First Notification:

[0085] Public IP1 : A.B.C.D Port: 1 Extended-Info: tethering ■ Public IP1 : A.B.C.D Port: 2 Extended-Info: video-traffic

[0086] ■ Public IP1 : A.B.C.D Port: 3 Extended-Info: n / a o Second Notification:

[0087] ■ Public IP1 : A.B.C.D Port: 2 Status: Released

[0088] ■ Public IP1 : A.B.C.D Port: 3 Status: Released

[0089]

[0054] At step 4-2, the NEF 420 authorizes the AF 410.

[0090]

[0055] At steps 4-3 and 4-4, the NEF 420 discovers through the NRF 431 the UPF 430 serving the ranges of IPs of the UE’s private IP.

[0091]

[0056] At step 4-5, the NEF 420 subscribes to the UPF 430 event exposure service for the UE NAT mapping event by sending an Nupf_EventExposure_Subscribe event. In specific implementations, the Nupf_EventExposure_Subscribe event includes some or all of the following information:

[0092] • Event-type: UE NAT Mapping

[0093] • Event-Target: UE private IP, remote end public IP and DNN.

[0094] #NOTE: DNN is used to identify the target UE when overlapping IP is supported on the UPF 430.

[0095] • Event-Filter: S-NSSAI and / or either Application ID(s) or Traffic filters.

[0096] • Extended-Info: This IE when true, indicates request for extended information per destination port (e.g. tethering indication, traffic type, matched application or traffic filter)

[0097] • Notification-Mode: This IE indicates how the notifications shall be generated: o Full Report: Each new notification will send the entire list of public IP(s) and port(s) associated with the service target. o Delta Report: Each new notification will send the modification from previous report of public IP(s) and port(s) associated with the service target.

[0057] At step 4-6, the UPF 430 notifies the NEF 420 by sending a Nupf_EventExposure_Notify message with the format and information according to the instructions provided in the subscription.

[0098]

[0058] At step 4-7, the NEF 420 notifies the AF 410 by sending a Nnef_UEAddress_Notify message with the information already provided by the UPF 430 in step 4-6.

[0099]

[0059] At step 4-8, the AF 410 correlates UE data collection and NWDAF request.

[0100]

[0060] At steps 4-9 and 4-10, at any moment there is a change in the public IP(s) and port(s) associated to the event subscription, in that case the UPF 430 send a new notification including the new status, following the format requested in the subscription.

[0101]

[0061] Based on the foregoing, it can be seen that embodiments disclosed herein provide a mechanism to solve, address, or mitigate one or more of the foregoing deficiencies with the proposed solution in the approved CRs. In some implementations, the mechanism allows the AF to obtain the Public IP(s) and port(s) of a certain PDU session being used to connect with the AF, and enables a method to notify when an IP(s) and / or port(s) have been released for the PDU session. Furthermore, in some implementations, the mechanism enhances the event exposure to subscribe to certain applications and / or filters, and provides further information in the notification that the AF can use to apply different enforcements (e.g., tethering indication).

[0102]

[0062] In some implementations, the mechanism enables one or more of the following features.

[0103] • Extend the Nupf_EventExposure_Subscribe message for the "UE NAT Mapping Information" event to include Application ID(s) and / or traffic filters (Including e.g transport protocol types, as udp or tcp, or application layer types) as optional input filter parameters.

[0104] Extend the Nupf_EventExposure_Subscribe message to define the reporting type as continuous report, i.e. extend the enumeration "UpfEventTrigger" to include event based continuous report, so that the UPF generates a notification report indicating if the previous reported NATed UE IP address and port has been released, or / and a NATed UE IP address may be allocated. And indicate the type of report (i.e. full report, delta report, etc).

[0105] • Extend the Nupf_EventExposure_Notify message for the "UE NAT Mapping Information" event to notify when a previously provided resource (Public IP(s) and / or port(s)) has been booked or released for a PDU session, associated with a timestamp when it is booked or released. When the application ld(s) are not included, the UPF may report a map of NATed UE IP addresses together with port, where the application id is used as a key.

[0106] • Extend the Nupf_EventExposure_Notify message for the "UE NAT Mapping Information" event to provide flow information per destination port, including but not limited to a tethering indication.

[0107]

[0063] In some implementations, the mechanism enables one or more of the following advantages.

[0108] • Use Case Unlocking: The solution enables the use case proposed in SA2 CRs to obtain Public IP(s) and port(s) that a specific PDU session is using to connect with an AF providing further filtering, either Application ID(s) or Traffic filters.

[0109] • Notification of Resource Allocation and Release: The solution allows for notifying the AF when previously notified Public IP(s) and port(s) have been released for the PDU session.

[0110] • Extended Information Per Destination TCP / UDP Port or ICMP identifier: The solution provides extended information per port that the AF can use to apply different enforcements (e.g., tethering indication or traffic type).

[0111] • Flexibility on how Nupf_EventExposure service send the notifications so operators may tune (depending on SLA agreement with AF) their preferences trading off between near to real-time notifications (more notification information and rate) or periodic reports bulks.

[0112]

[0064] In some implementations, the SMF and the UPF are cloud-based products. However, other implementations are possible.

[0113]

[0065] This section describes how some embodiments disclosed herein can be implemented in one or more standards. It is note that this section is very specific and that other implementations are possible.

[0114]

[0066] The following 3GPP spec could be updated to incorporate the present invention: 3GPP TS 29.564 entitled “5G System; User Plane Function Services; Stage 3” version 18.5.0 dated 2024-06 (hereinafter “TS 29.564”). Summary of changes include:

[0115] • Introduce the new Event Exposure Event "UE_NAT_MAPPING_INFO" along with new data types to support it, namely UeNatMappinglnfo and NatMapping. Introduce the Continuous (event-triggered) Report mode for this event. Additionally, introduce the Event Reporting Format to define the format of the notifications when the Continuous (event-triggered) Report mode is utilized.

[0116] • Extend Nupf_EventExposure_Subscribe

[0117] • Extend Nupf_EventExposure_Notify

[0118] Consequences if not approved:

[0119] • No alignment between TS 23.501 , TS 23.502, TS 23.288 and TS 29.564 specs, i.e. no state 3 support for UE NAT Mapping event exposure.

[0120]

[0067] Example changes to TS 29.564 are provided below, with additions shown with underline.

[0121] 4 Overview

[0122] 4.1 Introduction The UPF supports the following functionalities which are provided via Service Based Interface:

[0123] - Subscription to notifications of events exposed by the UPF;

[0124] - Notification about UPF events; and

[0125] - Translation of (NATed) Public UE IP address and port to (5GC) Private UE IP address.

[0126] NOTE: Translation of (5GC) Private UE IP address to (NATed) Public UE IP address and port(s) is provided by using UPF event exposure event "UE NAT MAPPING INFO".

[0127] 5.2.1.3.x UE NAT Mapping Information

[0128] Table 5.2.1.3.4-1 : UE NAT Mapping Information

[0129] 5.2.2.2 Subscribe

[0130] 5.2.2.2.1 General

[0131] The Subscribe service operation is used by a NF Service Consumer to subscribe to UPF event exposure notifications, e.g. for the purpose of UPF data collection for a specified PDU session or any UE.

[0132] NOTE: NF service consumers can only be SMF, NWDAF or DCCF in this release of the specification.

[0133] 5.2.2.2.2 Creation of a subscription

[0134] An NF Service Consumer shall invoke the Subscribe service operation towards the UPF to create a subscription to monitor at least one UPF event. The NF Service Consumer may subscribe to multiple events in a subscription. A subscription may be associated with one UE's PDU session or with any UE.

[0135] The NF Service Consumer shall request to create a new subscription by using the HTTP method POST with the URI of the subscriptions collection, see clause 6.1.3.2.

[0136] Figure 5 (Figure 5.2.2.2.2-1 in TS 29.564) Subscription creation

[0137] 1 . The NF Service Consumer shall send a POST request to create a subscription resource in the UPF. The content of the POST request shall contain a representation of the individual subscription resource to be created.

[0138] The NF Service Consumer shall include the following information in the HTTP message body:

[0139] - NF ID, indicating the identity of the network function instance creating the subscription;

[0140] - Target of Event Reporting, indicating the target(s) to be monitored, i.e. - a specific PDU Session of a UE identified with a UE IP address for an IP PDU session type;

[0141] - a specific PDU Session of a UE identified with a SUPI (and S-NSSAI / DNN) for a non-IP PDU session type; or

[0142] - any UE (identified by the "anyUE" flag);

[0143] - List of UPF events requested to be subscribed;

[0144] - Type of measurement, for UPF events supporting multiple types of measurement, e.g. for a subscription to the UserDataUsageMeasures event;

[0145] - Event Reporting Mode, indicating how the events shall be reported (One-time Report±Periodic Report or Continuous (event triggered) Report);

[0146] - UPF event consumer notification URI, indicating the address where to send the event notifications generated by the subscription; and

[0147] - Public IP address of remote end when subscription applies to "UE NAT MAPPING INFO" event.

[0148] The NF Service Consumer may include the following information in the HTTP message body:

[0149] - The S-NSSAI and / or the DNN of PDU sessions to which the subscription applies;

[0150] - either one or more Application I D(s) or traffic filters identifying the traffic to be monitored by the subscription;

[0151] - Granularity of Measurement, indicating that the granularity of the required measurements is per PDU Session, per data flow or per application;

[0152] - Reporting period, defining the period for periodic reporting;

[0153] - Maximum number of reports, defining the maximum number of reports after which the event subscription ceases to exist;

[0154] - Expiry time, suggested by the NF Service Consumer representing the time up to which the subscription is desired to be kept active and the time after which the subscribed event(s) shall stop generating reports; - Reporting suggestion information, i.e. Report urgency indicating whether the event report can be delayed (i.e. it is delay-tolerant) and if so, the Reporting time information defining the last valid reporting time for the UPF to report the detected event;

[0155] - Deactivate notification flag, indicating that the notification of the available events shall be muted until the event consumer NF (e.g. NWDAF or DCCF) provides the retrieval notification flag to retrieve the stored events;

[0156] - Immediate Report Flag per event, indicating an immediate report to be generated with the current event status;

[0157] - Notification Correlation ID, indicating the correlation identity to be signalled in the event notifications generated by the subscription;

[0158] - Sampling ratio, defining the random subset of PDU sessions among target PDU sessions, in which case the UPF shall only report the event(s) related to the selected subset of PDU sessions;

[0159] - partitioningCriteria, defining the criteria for partitioning PDU sessions before applying the sampling ratio;

[0160] - Muting Exception Instructions, which specify instructions to apply to the subscription and the stored events when an exception occurs at the UPF while the event is muted (e.g., the buffer of stored event reports is full, or the number of stored event reports exceeds a certain number), if the EEMM feature is supported (see clause 6.1.8);T

[0161] - Port(s) number(s) of the remote end when subscription applies to "UE NAT MAPPING INFO" event; and / or

[0162] - IP domain when subscription applies to "UE NAT MAPPING INFO" event. a. On success (i.e. if the request is accepted), the UPF shall include a HTTP Location header to provide the location of the newly created resource (subscription) together with the status code 201 in the response message indicating that the requested resource is created.

[0163] If the NF Service Consumer has included more than one events in the event subscription and some of the events cannot be subscribed, the UPF shall accept the request and provide the successfully subscribed event(s) in the CreatedEventSubscription.

[0164] If the NF Service Consumer has included the Immediate Report Flag with the value true in the event subscription, and if the current status of the events subscribed are available, the UPF shall include the current status of the events subscribed in the response. Otherwise, the UPF shall generate reports for the events and notify the NF service consumer using the Nupf_EventExposure_Notify service operation. If the events with the Immediate Report Flag set to true are subscribed via an SMF, the notification shall be sent to the actual NF service consumer directly, i.e. the current status of the events subscribed shall not be included in the subscription creation response.

[0165] If the NF Service Consumer has set the event reporting option to ONE_TIME and if the UPF has included the current status of the events subscribed in the response, then the UPF shall not do any subsequent event notification for the corresponding events.

[0166] The response, based on operator policy and taking into account the expiry time included in the request, may contain the expiry time, as determined by the UPF, after which the subscription becomes invalid. Once the subscription expires, if the NF Service Consumer wants to keep receiving notifications, it shall create a new subscription in the UPF. The UPF shall not provide the same expiry time for many subscriptions in order to avoid all of them expiring and recreating the subscription at the same time. If the expiry time is not included in the response, the NF Service Consumer shall consider the subscription to be valid without an expiry time.

[0167] If the sampling ratio ("sampRatio") attribute is included in the subscription without a partitioningCriteria, the UPF shall select a random subset of PDU sessions among target PDU sessions according to the sampling ratio and only report the event(s) related to the selected subset of PDU sessions. If the partitioningCriteria attribute is also included along with sampling ratio, the UPF shall apply the sampling ratio on the group of PDU sessions determined according to the partitioning criteria.

[0168] If the "notifFlag" attribute is included and set to "DEACTIVATE" in the request by e.g. the NWDAF or DCCF, the UPF shall mute the event notification and store the available events. Additionally, if the UPF supports the EEMM feature (see clause 6.1.8) and if the NF service consumer includes event muting instructions in the request, the UPF should evaluate the received event muting instructions against to local actions (if configured) and, if the subscription creation request is accepted, the UPF may indicate the following information to the NF service consumer in the response:

[0169] - the maximum number of notifications that the UPF expects to be able to store for the subscription;

[0170] - an estimate of the duration for which notifications can be buffered.

[0171] 2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.2.3.1-3 shall be returned. For a 4xx / 5xx response, the message body shall contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.2.3.1-3.

[0172] If the UPF supports the EEMM features (see clause 6.1.8), the NF service consumer sets the "notifFlag" attribute to "DEACTIVATE" and event muting instructions in the request, but the UPF cannot accept the received instructions, the UPF may reject the request with a 403 Forbidden response and the application error "MUTING_EXC_INSTR_NOT_ACCEPTED".

[0173] For a subscription request targeting a PDU session, if the UPF cannot find a unique PDU session due to no DNN and / or S-NSSAI being received in the request, the UPF shall reject the request with a 403 Forbidden response and the application error "REJECTION_DUE_TO_NO_DNN_SNSSAI" (see clause 54.4.1.2 of 3GPP TS 23.502 [3]).

[0174] 5.2.2.3 Notify

[0175] 5.2.2.3.1 General

[0176] The Notify service operation is invoked by the UPF, to send a notification, towards the notification URI, when certain event included in the subscription has taken place. See Figure 5.2.2.3.2-1.

[0177] For the events "USER.DATA.USAGE.MEASURES", "USER DATA USAGE TRENDS" and

[0178] "UE NAT MAPPING INFO", the UPF shall use the HTTP method POST, using the notification URI received in the subscription creation as specified in clause 5.2.2.2.2, including e.g. the subscription ID, Event ID(s) for which event has happened, notification correlation ID provided by the NF service consumer at the time of event subscription, to send a notification.

[0179] If the subscription is targeting PDU sessions of any UE, i.e. the "anyUe" is set to true in the subscription creation request, the UPF shall perform the requested measurements for every PDU session that matches the event filter information (i.e. S-NSSAIs, DNNs, either Application ID(s) or traffic filters) and send notification(s) with multiple Notification Item lEs within the Notification Data wherein each Notification Item shall correspond to a report on one subscribed event per PDU session. If the subscription request included a sampling ratio, the notification may include the sampling ratio achieved by the UPF.

[0180] For the events "QOS_MONITORING" and "TSC_MNGT_INFO", the UPF shall use the HTTP method POST, using the notification URI received from the SMF via N4 interface, see clause 5.33.5 of 3GPP TS 29.244

[0015] ,

[0181] For the event "USER_DATA_USAGE_MEASURES", the event notification may contain following information:

[0182] - Volume Measurement: measurements of data volume exchanged (UL, DL and / or overall) and / or number of packets exchanged (UL, DL and / or overall) determined for the requested Granularity of Measurements.

[0183] - Throughput Measurement: measurements of data throughput (UL and DL) determined for the requested Granularity of Measurements.

[0184] - Application related Information: URLs and / or Domain information (Domain name and protocol) detected in the target traffic identified by the information included in the subscription request, e.g. an application id.

[0185] When the granularity of the measurement is per data flow, the notification shall include the packet filter set and the Applications Identifier if available.

[0186] For the event "USER_DATA_USAGE_TRENDS", the event notification may contain following information:

[0187] - Throughput Statistic Measurement (average and / or peak throughput) over the measurement determined for the requested Granularity of Measurements.

[0188] When the granularity of the measurement is per data flow, the notification shall include the packet filter set and the Applications Identifier if available.

[0189] For the event "QOS_MONITORING", this service operation is used by the UPF to send the following types of event notifications:

[0190] Periodic notification on the downlink packet delay, uplink packet delay, and / or the round trip packet delay between the UPF (PSA) and UE;

[0191] - Event triggered notification on the downlink packet delay, uplink packet delay, and / or the round trip packet delay between the UPF (PSA) and UE, i.e. when the packet delay exceeds a defined threshold;

[0192] - Notification on the downlink packet delay, uplink packet delay, and / or the round trip packet delay between the UPF (PSA) and UE when the PDU session is released.

[0193] - Event triggered notification of congestion information of the QoS flow on the UL and / or DL directions received from the NG-RAN, upon a change of the congestion information.

[0194] For the event "TSC_MNGT_INFO", the event notification may contain the following information:

[0195] - Port Management Information Container(s) for one or more NW-TT ports and / or

[0196] - a User Plane Node Management Information Container.

[0197] The event notification shall also contain the following information:

[0198] - the related NW-TT port number(s), if Port Management Information Container(s) is present; and

[0199] - the notification correlation ID received from the SMF, if any.

[0200] For the event " UE NAT MAPPING INFO ", this service is used by the UPF to send the of event notifications:

[0201] - One-time report, whether in the subscription the event reporting mode is set to “ONE TIME” and the indication for immediate reporting is set to true;

[0202] - Event triggered notification on the assigned (NATed) Public UE IP address and / or port(s) assigned, i.e. when new Public IP address and / or port(s) has been assigned to the PDU Session; and

[0203] - Event triggered notification on the released (NATed) Public UE IP address and / or port(s) released, i.e. when a Public IP address and / or port(s) has been released for the PDU Session.

[0204] - If the current status of the event subscribed is not available at the UPF (e.g. there is no UE NAT mapping vet), the UPF sends an empty array to the consumer as part of the UPF event subscription response if the immediate reporting flag is included, otherwise the empty array is sent in the event subscription notify.

[0205] 6.1.6 Data Model

[0206] 6.1.6.1 General

[0207] This clause specifies the application data model supported by the API. Table 6.1 .6.1-1 specifies the data types defined for the Nupf_EventExposure service.

[0208] Table 6.1.6.1-1 : Nupf_EventExposure specific Data Types

[0209] Table 6.1.6.1-2 specifies data types re-used by the Nupf_EventExposure service from other specifications, including a reference to their respective specifications and when needed, a short description of their use within the Nupf_EventExposure service. Table 6.1.6.1-2: Nupf_EventExposure re-used Data Types

[0210] 6.1.6.2.3 Type: Notification Item

[0211] Table 6.1.6.2.3-1 : Definition of type Notification Item

[0212] 6.1.6.2.11 Type: UpfEventSubscription

[0213] Table 6.1.6.2.11-1 : Definition of type UpfEventSubscription

[0214] 6.1.6.2.13 Type: UpfEvent

[0215] Table 6.2.6.2.13-1 : Definition of type UpfEvent

[0216] 6.1.6.2.x Type: UeNatMappinglnfo

[0217] Table 6.1.6.2.X-1 : Definition of type UeNatMappinglnfo

[0218] 6.1.6.2.y Type: NatMapping

[0219] Table 6.1.6.2.17-1 : Definition of type NatMapping

[0220] 6.1.6.3.3 Enumeration: EventType

[0221] The enumeration EventType represents the type of event to which the NF service consumer may subscribe to and for which the notification is generated. It shall comply with the provisions defined in table 6.1 .5.3.3-1 .

[0222] Table 6.1.6.3.3-1 : Enumeration EventType

[0223] 6.1.6.3.4 Enumeration: UpfEventTrigger

[0224] Table 6.1.6.3.4-1 : Enumeration UpfEventTrigger

[0225] 6.1.6.3.x Enumeration: NatMappinqStatus

[0226] Table 6.1.6.3.8-1 : Enumeration NatMappinqStatus

[0227] Additional Details

[0228]

[0068] Additional details are provided below with reference to Figures 6 through 13. It is to be understood that these details are very specific for exemplary purposes only.

[0229]

[0069] Figure 6 illustrates one example of a cellular communications system 500 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 500 is a 5GS (5G system) including a NG-RAN (Next Generation RAN) and a 5GC (5G Core). In this example, the RAN includes base stations 102-1 and 502-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC), controlling corresponding (macro) cells 504-1 and 504-2. The base stations 502-1 and 502-2 are generally referred to herein collectively as base stations 502 and individually as base station 502. Likewise, the (macro) cells 504-1 and 504-2 are generally referred to herein collectively as (macro) cells 504 and individually as (macro) cell 504. The RAN may also include a number of low power nodes 506-1 through 506-4 controlling corresponding small cells 508-1 through 508-4. The low power nodes 506-1 through 506-4 can be small base stations (such as pico or femto base stations) or RRHs (Remote Radio Heads), or the like. Notably, while not illustrated, one or more of the small cells 508-1 through 508-4 may alternatively be provided by the base stations 502. The low power nodes 506-1 through 506-4 are generally referred to herein collectively as low power nodes 506 and individually as low power node 506. Likewise, the small cells 508-1 through 508-4 are generally referred to herein collectively as small cells 508 and individually as small cell 508. The cellular communications system 500 also includes a core network 510, which in the 5G System (5GS) is referred to as the 5GC. The base stations 502 (and optionally the low power nodes 506) are connected to the core network 510.

[0230]

[0070] The base stations 502 and the low power nodes 506 provide service to wireless communication devices 512-1 through 512-5 in the corresponding cells 504 and 508. The wireless communication devices 512-1 through 512-5 are generally referred to herein collectively as wireless communication devices 512 and individually as wireless communication device 512. In the following description, the wireless communication devices 512 are oftentimes UEs, but the present disclosure is not limited thereto.

[0231]

[0071] Referring now to Figure 7A, shown is a block diagram of a wireless communication system represented as a 5G network architecture composed of core NFs (Network Functions), where interaction between any two NFs is represented by a point-to- point reference point / interface. Figure 7A can be viewed as one particular implementation of the system 500 of Figure 6.

[0072] Seen from the access side the 5G network architecture shown in Figure 7A includes a plurality of UEs 613 connected to either a RAN 607 or an (Access Network) as well as an AMF 600. Typically, the R(AN) 607 comprises base stations, e.g. such as eNBs or gNBs or similar. Seen from the core network side, the 5GC NFs shown in Figure 7A include a NSSF 602, an AUSF 604, a UDM 606, the AMF 600, a SMF 608, a PCF 610, and an AF (Application Function) 612.

[0232]

[0073] Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE 613 and AMF 600. The reference points for connecting between the AN 607 and AMF 600 and between the AN 607 and UPF 614 are defined as N2 and N3, respectively. There is a reference point, N11 , between the AMF 600 and SMF 608, which implies that the SMF 608 is at least partly controlled by the AMF 600. N4 is used by the SMF 608 and UPF 614 so that the UPF 614 can be set using the control signal generated by the SMF 608, and the UPF 614 can report its state to the SMF 608. N9 is the reference point for the connection between different UPFs 614, and N14 is the reference point connecting between different AMFs 600, respectively. N15 and N7 are defined since the PCF 610 applies policy to the AMF 600 and SMF 608, respectively. N12 is utilized for the AMF 600 to perform authentication of the UE 613. N8 and N10 are defined because the subscription data of the UE 613 is utilized for the AMF 600 and SMF 608.

[0233]

[0074] The 5GC network aims at separating UP and CP. The UP carries user traffic while the CP carries signaling in the network. In Figure 7A, the UPF 614 is in the UP and all other NFs, i.e., the AMF 600, SMF 608, PCF 610, AF 612, NSSF 602, AUSF 604, and UDM 606, are in the CP. Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the RTT (Round Trip Time) between UEs and data network for some applications involving low latency.

[0234]

[0075] The core 5G network architecture is composed of modularized functions. For example, the AMF 600 and SMF 608 are independent functions in the CP. Separated AMF 600 and SMF 608 allow independent evolution and scaling. Other CP functions like the PCF 610 and AUSF 604 can be separated as shown in Figure 7A. Modularized function design enables the 5GC network to support various services flexibly.

[0235]

[0076] Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the CP, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The UP supports interactions such as forwarding operations between different UPFs.

[0236]

[0077] Referring now to Figure 7B, shown is a block diagram of a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points / interfaces used in the 5G network architecture of Figure 7A. However, the NFs described above with reference to Figure 7B correspond to the NFs shown in Figure 7A. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In Figure 7B, the service based interfaces are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the service based interface of the AMF 600 and Nsmf for the service based interface of the SMF 608, etc. The NEF 603 and the NRF 601 in Figure 7B are not shown in Figure 7A discussed above. However, it should be clarified that all NFs depicted in Figure 7A can interact with the NEF 603 and the NRF 601 of Figure 7B as necessary, though not explicitly indicated in Figure 7A.

[0237]

[0078] Some properties of the NFs shown in Figures 7A and 7B may be described in the following manner. The AMF 600 provides UE-based authentication, authorization, mobility management, etc. A UE 613 even using multiple access technologies is basically connected to a single AMF 600 because the AMF 600 is independent of the access technologies. The SMF 608 is responsible for session management and allocates IP (Internet Protocol) addresses to UEs. It also selects and controls the UPF 614 for data transfer. If a UE 613 has multiple sessions, different SMFs 608 may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF 612 provides information on the packet flow to the PCF 610 responsible for policy control in order to support QoS. Based on the information, the PCF 610 determines policies about mobility and session management to make the AMF 600 and SMF 608 operate properly. The AUSF 604 supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM 606 stores subscription data of the UE 613. The DN (Data Network), not part of the 5GC network, provides Internet access or operator services and similar.

[0238]

[0079] An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

[0239]

[0080] Figure 8 is a schematic block diagram of a radio access node 700 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The radio access node 700 may be, for example, a base station 102 or 106 or a network node that implements all or part of the functionality of the base station 102 or gNB described herein. As illustrated, the radio access node 700 includes a control system 702 that includes one or more processors 704 (e.g., CPUs (Central Processing Units), ASICs (Application Specific Integrated Circuits), FPGAs (Field Programmable Gate Arrays), and / or the like), memory 706, and a network interface 708. The one or more processors 704 are also referred to herein as processing circuitry. In addition, the radio access node 700 may include one or more radio units 710 that each includes one or more transmitters 712 and one or more receivers 714 coupled to one or more antennas 716. The radio units 710 may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) 710 is external to the control system 702 and connected to the control system 702 via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) 710 and potentially the antenna(s) 716 are integrated together with the control system 702. The one or more processors 704 operate to provide one or more functions of a radio access node 700 as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 706 and executed by the one or more processors 704.

[0081] Figure 9 is a schematic block diagram that illustrates a virtualized embodiment of the radio access node 700 according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures. Again, optional features are represented by dashed boxes.

[0240]

[0082] As used herein, a “virtualized” radio access node is an implementation of the radio access node 700 in which at least a portion of the functionality of the radio access node 700 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the radio access node 700 may include the control system 702 and / or the one or more radio units 710, as described above. The control system 702 may be connected to the radio unit(s) 710 via, for example, an optical cable or the like. The radio access node 700 includes one or more processing nodes 800 coupled to or included as part of a network(s) 802. If present, the control system 702 or the radio unit(s) 710 are connected to the processing node(s) 800 via the network 802. Each processing node 800 includes one or more processors 804 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 806, and a network interface 808.

[0241]

[0083] In this example, functions 810 of the radio access node 700 described herein are implemented at the one or more processing nodes 800 or distributed across the one or more processing nodes 800 and the control system 702 and / or the radio unit(s) 810 in any desired manner. In some particular embodiments, some or all of the functions 810 of the radio access node 700 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 800. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 800 and the control system 702 is used in order to carry out at least some of the desired functions 810. Notably, in some embodiments, the control system 702 may not be included, in which case the radio unit(s) 810 communicates directly with the processing node(s) 800 via an appropriate network interface(s).

[0084] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of radio access node 700 or a node (e.g., a processing node 800) implementing one or more of the functions 810 of the radio access node 700 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. 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 memory).

[0242]

[0085] Figure 10 is a schematic block diagram of the radio access node 700 according to some other embodiments of the present disclosure. The radio access node 700 includes one or more modules 800, each of which is implemented in software. The module(s) 800 provide the functionality of the radio access node 700 described herein. This discussion is equally applicable to the processing node 800 of Figure 9 where the modules 800 may be implemented at one of the processing nodes 800 or distributed across multiple processing nodes 800 and / or distributed across the processing node(s) 800 and the control system 702.

[0243]

[0086] Figure 11 is a schematic block diagram of a wireless communication device 900 according to some embodiments of the present disclosure. As illustrated, the wireless communication device 900 includes one or more processors 902 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 904, and one or more transceivers 906 each including one or more transmitters 908 and one or more receivers 910 coupled to one or more antennas 912. The transceiver(s) 906 includes radio-front end circuitry connected to the antenna(s) 912 that is configured to condition signals communicated between the antenna(s) 912 and the processor(s) 902, as will be appreciated by on of ordinary skill in the art. The processors 902 are also referred to herein as processing circuitry. The transceivers 906 are also referred to herein as radio circuitry. In some embodiments, the functionality of the wireless communication device 900 described above may be fully or partially implemented in software that is, e.g., stored in the memory 904 and executed by the processor(s) 902. Note that the wireless communication device 900 may include additional components not illustrated in Figure 11 such as, e.g., one or more user interface components (e.g., an input / output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and / or the like and / or any other components for allowing input of information into the wireless communication device 900 and / or allowing output of information from the wireless communication device 900), a power supply (e.g., a battery and associated power circuitry), etc.

[0244]

[0087] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the wireless communication device 900 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. 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 memory).

[0245]

[0088] Figure 12 is a schematic block diagram of the wireless communication device 900 according to some other embodiments of the present disclosure. The wireless communication device 900 includes one or more modules 1000, each of which is implemented in software. The module(s) 1000 provide the functionality of the wireless communication device 900 described herein.

[0246]

[0089] Each station 1106A, 1106B, 1106C is connectable to the core network 1104 over a wired or wireless connection 1110. A first UE 1112 located in coverage area 1108C is configured to wirelessly connect to, or be paged by, the corresponding base station 1106C. A second UE 1114 in coverage area 1108A is wirelessly connectable to the corresponding base station 1106A. While a plurality of UEs 1112, 1114 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 1106.

[0247]

[0090] The telecommunication network 1100 is itself connected to a host computer 1116, which may be embodied in the hardware and / or software of a standalone server, a cloud-implemented server, a distributed server, or as processing resources in a server farm. The host computer 1116 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. Connections 1118 and 1120 between the telecommunication network 1100 and the host computer 1116 may extend directly from the core network 1104 to the host computer 1116 or may go via an optional intermediate network 1122. The intermediate network 1122 may be one of, or a combination of more than one of, a public, private, or hosted network; the intermediate network 1122, if any, may be a backbone network or the Internet; in particular, the intermediate network 1122 may comprise two or more sub-networks (not shown).

[0248]

[0091] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include DSPs (Digital Signal Processor), 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 ROM (Read Only Memory), RAM (Random Access Memory), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[0249]

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

[0250]

[0093] Additional embodiments for the second network node (e.g. NEF) are described in the following clauses:

[0251] 1 . A method for execution by a second network node (e.g. NEF), comprising: establishing a subscription between (i) a first network node configured to interact with a core network to provide services and (ii) a third network node configured to handle user plane traffic, wherein the subscription is for receiving notification reports of NAT (Network Address Translation) information related to one or more applications or all applications deployed in the first network node for a PDU (Protocol Data Unit) session; receiving a notification report from the third network node; and forwarding the notification report to the first network node.

[0252] 2. The method of clause 1, wherein establishing the subscription comprises: receiving, from the first network node, a subscription creation request message including one or more application id(s) and traffic filter to get corresponding NAT mapping information including public IP address(es) and / or port(s) allocated specifically for these applications and traffic filters; and sending, to the third network node, the subscription creation request message including the one or more application id (s) and traffic filter to get the corresponding NAT mapping information including the public IP address(es) and / or port(s) allocated specifically for these applications and traffic filters.

[0253] 3. The method of clause 1 or clause 2, wherein the notification report from the third network node comprises a list of UE NAT mapping information for the PDU session.

[0254] 4. The method of clause 3, wherein each UE NAT mapping information comprises at least some of: a public IP address as a NATed IP address, a used transport protocol and its corresponding port number, a NAT mapping status indicating if the public address is newly assigned, or has been allocated, or is released, one or more application ids and / or traffic filters to which the NATed IP address and port are corresponding, and a tethering indication to indicate if the application(s) are consumed by a device behind the UE.

[0255] 5. The method of any one of clausesl to 4, wherein the first network node comprises an AF (Application Function), the second network node comprises an NEF (network Exposure Function), and the third network node comprises a UPF (User Plane Function).

[0256] 6. A non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a second network node, configure the second network node to implement a method according to any one of clauses 1 to 5.

[0257] 7. A second network node (e.g. NEF), comprising: a network interface configured to communicate with other network nodes; control circuitry coupled to the network interface and configured to: establish a subscription between (i) a first network node configured to interact with a core network to provide services and (ii) a third network node configured to handle user plane traffic, wherein the subscription is for receiving notification reports of NAT (Network Address Translation) information related to one or more applications or all applications deployed in the first network node for a PDU (Protocol Data Unit) session; receive a notification report from the third network node; and forward the notification report to the first network node.

[0258] 8. The second network node of clause 7, wherein the control circuitry is further configured to implement a method according to any one of clauses 2 to 5.

[0094] Additional embodiments for the first network node (e.g. AF) are described in the following clauses:

[0259] 9. A method for execution by a first network node configured to interact with a core network to provide services, comprising: receiving, from a second network node, a message indicating change in public IP address(es) and / or port(s) associated with a subscription; and changing resources allocated for the subscription accordingly.

[0260] 10. The method of clause 9, wherein: the change in the public IP address(es) and / or port(s) associated with the subscription includes a new Public IP address and / or port having been assigned; and changing resources allocated for the subscription accordingly comprises allocating the new Public IP address and / or port.

[0261] 1 1 . The method of clause 9 or clause 10, wherein: the change in the public IP address(es) and / or port(s) associated with the subscription includes an IP address and / or port having been released; changing resources allocated for the subscription accordingly comprises releasing the IP address and / or port.

[0262] 12. The method of any one of clauses 9 to 11, further comprising: sending, to the second network node, a message specifying parameters for the subscription including the public IP address(es) and / or port(s) for the subscription; wherein the subscription is established based on the parameters as specified by the first network node. 13. The method of clause 4, wherein the parameters further comprise any one or more of (i) application ID(s) and / or traffic filters, (ii) extended-info, and (iii) notification-mode.

[0263] 14. The method of any one of clauses 9 to 5, wherein the first network node comprises an AF (Application Function) and the second network node comprises an NEF (network Exposure Function).

[0264] 15. A non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a first network node, configure the first network node to implement a method according to any one of clauses 9 to 6.

[0265] 16. A first network node, comprising: a network interface configured to communicate with other network nodes; control circuitry coupled to the network interface and configured to: receive, from a second network node, a message indicating change in public IP address(es) and / or port(s) associated with a subscription; and change resources allocated for the subscription accordingly.

[0266] 17. The first network node of clause 8, wherein the control circuitry is further configured to implement a method according to any one of clauses 10 to 6.

[0267]

[0095] Numerous modifications and variations of the present disclosure are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended embodiments, the disclosure may be practised otherwise than as specifically described herein.

Claims

Claims:1 . A method for execution by a first network node configured to interact with a core network to provide services, comprising: sending, to a second network node, a subscription request for receiving notification reports of NAT (Network Address Translation) information related to one or more applications or all applications deployed in an application server for a PDU (Protocol Data Unit) session; receiving, from the second network node, a message indicating change in public IP address(es) and / or port(s) associated with the PDU session, wherein the notification report is received in accordance with an event reporting mode; and implementing the change accordingly.

2. The method of claim 1 , wherein the notification report comprises a plurality of notification reports, and the event reporting mode is continuous event triggered.

3. The method of claim 2, wherein the notification reports are continuously received based on an event being triggered until the subscription to this event ends due to a maximum number of notification reports or the event being unsubscribed explicitly.

4. The method of any one of claims 1 to 3, further comprising: sending, to the second network node, a message specifying parameters for the subscription including the public IP address(es) and / or port(s) for the subscription; wherein the subscription is established based on the parameters as specified by the first network node.

5. The method of claim 4, wherein the parameters further comprise any one or more of (i) application ID(s) and / or traffic filters, (ii) extended-info, and (iii) notificationmode.

6. The method of any one of claims 1 to 5, wherein the first network node comprises an AF (Application Function) and the second network node comprises an NEF (network Exposure Function).

7. A non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a first network node, configure the first network node to implement a method according to any one of claims 1 to 6.

8. A first network node, comprising: a network interface configured to communicate with other network nodes; control circuitry coupled to the network interface and configured to: send, to a second network node, a subscription request for receiving notification reports of NAT (Network Address Translation) information related to one or more applications or all applications deployed in an application server for a PDU (Protocol Data Unit) session; receive, from the second network node, a message indicating change in public IP address(es) and / or port(s) associated with a subscription, wherein the notification report is received in accordance with an event reporting mode; and implementing the change accordingly.

9. The first network node of claim 8, wherein the control circuitry is further configured to implement a method according to any one of claims 2 to 6.

10. A method for execution by a third network node, comprising: receiving a subscription from a first or second network node, wherein the subscription is for receiving notification reports of NAT (Network Address Translation) information related to one or more applications or all applications deployed in an application server for a PDU (Protocol Data Unit) session; andsending a notification report to the first or second network node, wherein the notification report is sent in accordance with an event reporting mode.11 . The method of claim 10, wherein the notification report comprises a plurality of notification reports, and the event reporting mode is continuous event triggered.

12. The method of claim 11 , wherein the third network node continuously generates the notification reports based on an event being triggered until the subscription to this event ends due to a maximum number of notification reports or the event being unsubscribed explicitly.

13. The method of any one of claims 10 to 12, comprising: receiving, from the first or second network node, a message indicating the event reporting mode.

14. The method of any one of claims 10 to 13 wherein the notification reports indicate whether there is a change in public IP address(es) and / or port(s).

15. The method of claim 14, wherein the change in the public IP address(es) and / or port(s) associated with the PDU session includes an IP address and / or port having been assigned.

16. The method of claim 14, wherein the change in the public IP address(es) and / or port(s) associated with the PDU session includes an IP address and / or port having been released.

17. The method of any one of claims 10 to 16, further comprising: receiving, from the first or second network node, a message specifying parameters for the subscription including public IP address(es) and / or port(s) for the subscription; wherein the subscription is established based on the parameters as specified by the first or second network node.

18. The method of claim 17, wherein the parameters further comprise any one or more of (i) application ID(s) and / or traffic filters, (ii) extended-info, and (iii) notificationmode.

19. The method of any one of claims 10 to 18, wherein the second network node comprises an NEF (network Exposure Function), and the third network node comprises a UPF (User Plane Function).

20. A non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a third network node, configure the third network node to implement a method according to any one of claims 10 to 19.21 . A third network node, comprising: a network interface configured to communicate with other network nodes; control circuitry coupled to the network interface and configured to: receive a subscription from first or second network node, wherein the subscription is for receiving notification reports of NAT (Network Address Translation) information related to one or more applications or all applications deployed in an application server for a PDU (Protocol Data Unit) session; and send a notification report to the first or second network node, wherein the notification report is sent in accordance with an event reporting mode.

22. The third network node of claim 21 , wherein the control circuitry is further configured to implement a method according to any one of claims 13 to 19.

Images