UPF handling and reporting of user plane headers in both UL and DL directions

Abstract

The current Forwarding Action Rule (FAR) is a rule which can be presented to a user plane element by a control plane element by including a container for header enrichment. The user plane function (UP

Description

[0001] The example and non-limiting embodiments relate generally to an application function and, more particularly, to user plane header handling. BRIEF DESCRIPTION OF PRIOR DEVELOPMENTS

[0002] In communications, a user plane function (UPF) supports: packet routing &forwarding, packet inspection, QoS handling, acts as an external PDU session point of interconnecting to Data Network (DN), and is an anchor point for intra- &inter-RAT mobility. Also, an application function (AF) supports: application influence on traffic routing, accessing NEF, and interaction with a policy framework for policy control. An AF may be provided as part of a control plane or part of a user plane, such as with a data network for example. SUMMARY OF THE INVENTION

[0003] The following summary is merely intended to be an example. The summary is not intended to limit the scope of the claims.

[0004] In accordance with one aspect, an example is provided with an apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed with the at least one processor, cause the apparatus to perform: receiving a user plane header handling instruction from an application function; and determining occurrence of an event based, at least partially, upon the received user plane header handling instruction.

[0005] In accordance with one aspect, an example is provided with a method comprising: receiving a user plane header handling instruction from an application function; and determining occurrence of an event based, at least partially, upon the received user plane header handling instruction.

[0006] In accordance with one aspect, an example is provided with an apparatus comprising: means for receiving a user plane header handling instruction from an application function; and means for determining occurrence of an event based, at least partially, upon the received user plane header handling instruction.

[0007] In accordance with one aspect, an example is provided with a program storage device readable by an apparatus, tangibly embodying a program of instructions executable with the apparatus for performing operations, the operations comprising: receiving a user plane header handling instruction from an application function; and determining occurrence of an event based, at least partially, upon the received user plane header handling instruction.

[0008] In accordance with one aspect, an example apparatus may be provided comprising: at least one processor; and at least one memory storing instructions that, when executed with the at least one processor, cause the apparatus to perform: sending at least one header handling instruction from an application function to a user plane function; and receiving an event report by the application function from the user plane function based, at least partially, upon the sending at least one header handling instruction from an application function to a user plane function. The event report may be in regard to detection or occurrence of a header handling event at least partially corresponding to the at least one header handling instruction.

[0009] In accordance with one aspect, an example method may be provided comprising: sending at least one header handling instruction from an application function to a user plane function; and receiving an event report by the application function from the user plane function based, at least partially, upon the sending at least one header handling instruction from an application function to a user plane function.

[0010] In accordance with one aspect, an example embodiment may be provided with an apparatus comprising: means for sending at least one header handling instruction from an application function to a user plane function; and means for receiving an event report by the application function from the user plane function based, at least partially, upon the sending at least one header handling instruction from an application function to a user plane function.

[0011] In accordance with one aspect, an example embodiment may be provided with a program storage device readable by an apparatus, tangibly embodying a program of instructions executable with the apparatus for performing operations, the operations comprising: sending at least one header handling instruction from an application function to a user plane function; and receiving an event report by the application function from the user plane function based, at least partially, upon the sending at least one header handling instruction from an application function to a user plane function.

[0012] According to some aspects, there is provided the subject matter of the independent claims. Some further aspects are provided in subject matter of the dependent claims. BRIEF DESCRIPTION OF DRAWINGS

[0013] The foregoing aspects and other features are explained in the following description, taken in connection with the accompanying drawings, wherein:

[0014] FIG. 1 is a block diagram of one possible and non-limiting example system in which the example embodiments may be practiced;

[0015] FIG. 2 is a diagram illustrating example components in a control plane (CP) and a user plane (UP);

[0016] FIG. 3 is a diagram illustrating an example of communications between an AF and a UPF regarding notification on a subscribed event;

[0017] FIG. 4 is a diagram illustrating an example method; and

[0018] FIG. 5 is a diagram illustrating an example method. DETAILED DESCRIPTION

[0019] The following abbreviations that may be found in the specification and / or the drawing figures are defined as follows: 3 GPP third generation partnership project 5G fifth generation 5GC 5G core network AF application function AMF access and mobility management function ATSSS access traffic steering, switching and splitting AUSF authentication server function CN control plane cu central unit DN data network DU distributed unit E2E end to end EE event exposure eNB (or eNodeB) EN-DC evolved Node B (e.g., an LTE base station) E-UTRA-NR dual connectivity en-gNB or En-gNB node providing NR user plane and control plane protocol terminations towards the UE, and acting as secondary node in EN-DC E-UTRA evolved universal terrestrial radio access, i.e., the LTE radio access technology FAR forwarding action rule gNB (or gNodeB) base station for 5G / NR, i.e., a node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC IE information element I / F interface LTE long term evolution MAC medium access control MME mobility management entity NEF network exposure function NF network function ng or NG new generation ng-eNB or NG-eNB new generation eNB NR new radio NRF network repository function NSSF network slice selection function N / WorNW network PCF policy control function PDCP packet data convergence protocol PFCP packet forwarding control protocol 5 PHY physical layer QUIC quick UDP internet connection RAN radio access network Rei release RT C ixl, v. radio link control 10 RRH remote radio head RRC radio resource control RU radio unit Rx receiver SDAP service data adaptation protocol 15 SDF service data flow SID study item description SGW serving gateway SMF session management function TCP transport control protocol 20 TS technical specification Tx transmitter UDM unified data management UDP user datagram protocol UE user equipment (e.g., a wireless, typically mobile device) 25 UP user plane UPF user plane function

[0020] Turning to FIG. 1, this figure shows a block diagram of one possible and non-limiting example in which the examples may be practiced. A user equipment (UE) 110, radio access network (RAN) node 170, and network element(s) 190 are illustrated. Examples of network 30 equipment, network device, or a network entity might be understood to include, at least part of, a transmission reception point or a cell or a gNB or node for example. In the example of FIG. 1, the user equipment (UE) 110 is in wireless communication with a wireless network 100. A UE is a wireless device that can access the wireless network 100. The UE 110 includes one or more processors 120, one or more memories 125, and one or more transceivers 130 interconnected through one or more buses 127. Each of the one or more transceivers 130 includes a receiver, Rx, 132 and a transmitter, Tx, 133. The one or more buses 127 may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. The one or more transceivers 130 are connected to one or more antennas 128. The one or more memories 125 include computer program code 123. The UE 110 includes a module 140, comprising one of or both parts 140-1 and / or 140-2, which may be implemented in a number of ways. The module 140 may be implemented in hardware as module 140-1, such as being implemented as part of the one or more processors 120. The module 140-1 may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the module 140 may be implemented as module 140-2, which is implemented as computer program code 123 and is executed by the one or more processors 120. For instance, the one or more memories 125 and the computer program code 123 may be configured to, with the one or more processors 120, cause the user equipment 110 to perform one or more of the operations as described herein. The UE 110 communicates with RAN node 170 via a wireless link 111.

[0021] The RAN node 170 in this example is a base station that provides access by wireless devices such as the UE 110 to the wireless network 100. The RAN node 170 may be, for example, a base station for 5G, also called New Radio (NR). In 5G, the RAN node 170 may be a NG-RAN node, which is defined as either a gNB or a ng-eNB. A gNB is a node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG interface to a 5GC (such as, for example, the network element(s) 190). The ng-eNB is a node providing E-UTRA user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC. The NG-RAN node may include multiple gNBs, which may also include a central unit(CU) (gNB-CU) 196 and distributed unit(s) (DUs) (gNB-DUs), of which DU 195 is shown. Note that the DU may include or be coupled to and control a radio unit (RU). The gNB-CU is a logical node hosting RRC, SDAP and PDCP protocols of the gNB or RRC and PDCP protocols of the en-gNB that controls the operation of one or more gNB-DUs. The gNB-CU terminates the Fl interface connected with the gNB-DU. The Fl interface is illustrated as reference 198, although reference 198 also illustrates a link between remote elements of the RAN node 170 and centralized elements of the RAN node 170, such as between the gNB-CU 196 and the gNB-DU 195. The gNB-DU is a logical node hosting RLC, MAC and PHY layers of the gNB or en-gNB, and its operation is partly controlled by gNB-CU. One gNB-CU supports one or multiple cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the Fl interface 198 connected with the gNB-CU. Note that the DU 195 is considered to include the transceiver 160, e.g., as part of a RU, but some examples of this may have the transceiver 160 as part of a separate RU, e g., under control of and connected to the DU 195. The RAN node 170 may also be an eNB (evolved NodeB) base station, for LTE (long term evolution), or any other suitable base station or node.

[0022] The RAN node 170 includes one or more processors 152, one or more memories 155, one or more network interfaces (N / W I / F(s)) 161, and one or more transceivers 160 interconnected through one or more buses 157. Each of the one or more transceivers 160 includes a receiver, Rx, 162 and a transmitter, Tx, 163. The one or more transceivers 160 are connected to one or more antennas 158. The one or more memories 155 include computer program code 153. The CU 196 may include the processor(s) 152, memories 155, and network interfaces 161. Note that the DU 195 may also contain its own memory / memories and processor(s), and / or other hardware, but these are not shown.

[0023] The RAN node 170 includes a module 150, comprising one of or both parts 150-1 and / or 150-2, which may be implemented in a number of ways. The module 150 may be implemented in hardware as module 150-1, such as being implemented as part of the one or more processors 152. The module 150-1 may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the module 150 may be implemented as module 150-2, which is implemented as computer program code 153 and is executed by the one or more processors 152. For instance, the one or more memories 155 and the computer program code 153 are configured to, with the one or more processors 152, cause the RAN node 170 to perform one or more of the operations as described herein. Note that the functionality of the module 150 may be distributed, such as being distributed between the DU 195 and the CU 196, or be implemented solely in the DU 195.

[0024] The one or more network interfaces 161 communicate over a network such as via the links 176 and 131. Two or more gNBs 170 may communicate using, e.g., link 176. The link 176 may be wired or wireless or both and may implement, for example, an Xn interface for 5G, an X2 interface for LTE, or other suitable interface for other standards.

[0025] The one or more buses 157 may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like. For example, the one or more transceivers 160 may be implemented as a remote radio head (RRH) 195 for LTE or a distributed unit (DU) 195 for gNB implementation for 5G, with the other elements of the RAN node 170 possibly being physically in a different location from the RRH / DU, and the one or more buses 157 could be implemented in part as, for example, fiber optic cable or other suitable network connection to connect the other elements (e.g., a central unit (CU), gNB-CU) of the RAN node 170 to the RRH / DU 195. Reference 198 also indicates those suitable network link(s).

[0026] It is noted that description herein indicates that “cells” perform functions, but it should be clear that equipment which forms the cell will perform the functions. The cell makes up part of a base station. That is, there can be multiple cells per base station. For example, there could be three cells for a single carrier frequency and associated bandwidth, each cell covering one-third of a 360 degree area so that the single base station’s coverage area covers an approximate oval or circle. Furthermore, each cell can correspond to a single carrier and a base station may use multiple carriers. So if there are three 120 degree cells per carrier and two carriers, then the base station has a total of 6 cells.

[0027] The wireless network 100 may include a network element or elements 190 that may include core network functionality, and which provides connectivity via a link or links 181 with a further network, such as a telephone network and / or a data communications network (e.g., the Internet). Such core network functionality for 5G may include access and mobility management function(s) (AMF(S)) and / or user plane functions (UPF(s)) and / or session management function(s) (SMF(s)). Such core network functionality for LTE may include MME (Mobility Management Entity ) / SGW (Serving Gateway) functionality. These are merely exemplary functions that may be supported by the network element(s) 190, and note that both 5G and LTE functions might be supported. The RAN node 170 is coupled via a link 131 to a network element 190. The link 131 may be implemented as, e.g., an NG interface for 5G, or an SI interface for LTE, or other suitable interface for other standards. The network element 190 includes one or more processors 175, one or more memories 171, and one or more network interfaces (N / W I / F(s)) 180, interconnected through one or more buses 185. The one or more memories 171 include computer program code 173. The one or more memories 171 and the computer program code 173 are configured to, with the one or more processors 175, cause the network element 190 to perform one or more operations.

[0028] The wireless network 100 may implement network virtualization, which is the process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Network virtualization involves platform virtualization, often combined with resource virtualization. Network virtualization is categorized as either external, combining many networks, or parts of networks, into a virtual unit, or internal, providing network-like functionality to software containers on a single system. Note that the virtualized entities that result from the network virtualization are still implemented, at some level, using hardware such as processors 152 or 175 and memories 155 and 171, and also such virtualized entities create technical effects.

[0029] The computer readable memories 125, 155, and 171 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The computer readable memories 125, 155, and 171 may be means for performing storage functions. The processors 120, 152, and 175 may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples. The processors 120, 152, and 175 may be means for performing functions, such as controlling the UE 110, RAN node 170, and other functions as described herein.

[0030] In general, the various embodiments of the user equipment 110 can include, but are not limited to, cellular telephones such as smart phones, tablets, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances permitting wireless Internet access and browsing, tablets with wireless communication capabilities, as well as portable units or terminals that incorporate combinations of such functions.

[0031] Referring also to FIG. 2, an example control plane (CP) may comprise, for example, the following: NSSF, NEF, NRF, PCF, UDM, AF, AMF, AUSF and SMF. Also, an example user plane (UP) may comprise the UE, RAN, UPF and DN. The data network DN, such as an external data network, may also comprise one or more application functions AF. Please note that this is merely an example illustration to show some of the features and is not intended to be considered as limiting.

[0032] The current FAR (Forwarding Action Rule) in N4 interface includes the Container for header enrichment, and the UPF uses this information to insert headers for uplink traffic at the N6. However, the current packet headers can just be used for marking to steer through a number of service functions in the N6. An operator may decide to make use of packet headers that provide relevant information to Application Function in an operator platform. Features as described herein may be used as an enhancement to allow additional functionality to permit a UPF to detect the header of traffic to / from the UE, and notify the AF after the header detection.

[0033] With features as described herein, the UPF may support a new service that allows a NF service consumer or an AF to provision user plane header handling instructions. For example, this may be in regard to a specific user plane (UP) header and may comprise, for example, to add a header, or to modify a header, or to remove a header, or to replace a header, or merely in regard to detecting a specific UP header. This may be in regard to the uplink (UL) direction, or the downlink (DL) direction, or both in the UL and DL directions. This service may include reporting one or more specific events. For example a specific event might comprise when a header is detected, or a specific event might comprise when a header is modified, added, removed, replaced, or deleted.

[0034] In another example embodiment the UPF Nupf EventExposure service may support a new event(s) enabling a subscribed NF to request to be notified when the UPF detects and / or acts on a specific header in the user plane packets of a targeted traffic, in the UL and / or DL directions.

[0035] The PFCP protocol (used between the SMF and UPF) may also be extended to support the new functionalities.

[0036] In example embodiments, the AF may provide UP header handling instructions to the UPF by either: - invoking, or subscribing to, directly the new aforementioned UPF service or the UPF Nupf EventExposure service. The AF may discover the UPF of specific traffic, such as a given PDU session(s) for example, and invoke, or subscribe to, the UPF service directly or indirectly. - providing such instructions to the NEF / PCF / SMF, and the SMF instructing the UPF to proceed accordingly using the UPF event exposure or new UPF service, or via PFCP extensions for example.

[0037] The AF may provide the following information to request UP header handling which may define what the UPF should monitor, what headers the UPF should handle (such as add / modify / remove / replace / detect for example) and, once specific header(s) is(are) found, then what actions may be taken by the UPF and under which conditions (if any). This may include: • Target headers against which the actions are taken, • List of actions to be done, and • Conditions under which actions are done.

[0038] Communication regarding the UPF event subscription from AF can be direct via N6 or indirect such as, for example, via NEF / PCF / SMF using N33. Once the AF has subscribed to this UPF’s event, the UPF may start to monitor the targeted traffic and for each header and / or conditions match, the given action(s) (e.g., Modify, Remove, Add) may be taken and a relevant triggered report (e.g. Header Detection event or Header Handling event) may be generated and sent to the subscribed AF.

[0039] With features as described herein, features may be provided in regard to the services / operations exposed by the UPF and the input they require. An AF can discover (such 5 as via N33 for example) the UPF endpoints (that are reachable via N6) from NEF. An alternative method may be provided without the UPF endpoint exposure between AF and UPF, and then subscribes the New Service and / or Event Exposure (EE) service from UPF either directly via N6 or indirectly via NEF as an intermediary / proxy.

[0040] A new event type(s) may be provided. An example is shown in Table 1 below and is 10 example labeled as a Header Handling event. Table 1: Header Handling event. Description This event provides Header Handling information including header insertion / deletion, possible header modifications and requested data samples from the detected header(s). Subscription type Direct Subscription via N6 or indirect subscription via NEF Subscription inputs to UPF Required: - NF ID, indicating the identity of the network function instance creating the subscription. - Target of Event, indicating the target(s) to be monitored, e.g., * a specific PDU Session of a UE identified with a UE IP address; or * any UE (identified by the "anyUE" flag) or UE IP / MAC address(es); or * a specific SDF of a UE identified with a UE IP address. * GPSI(s), External Group Identifier, DNN / S-NSSAI. - List of UPF events requested to be subscribed, i.e., - Event Reporting Mode (One-time Report or Periodic Report). - UPF event consumer notification URI. - Target header(s): Could be at IP layer, transport layer, Application layer, meta data of encrypted traffic and, for a given layer, the specific header(s) that are targeted by the subscription (e.g., a specific HTTP header). - Requested actions (Report, Modify, Remove, Add, Replace) - Instructions for reporting. - Data and instructions for header handling. - UL and / or DL directions. Optional: - Conditions: “if the given value is FOUND from the given header“ or “if the given value is NOT FOUND from the given header“. - Header data injection for notification: “All”, {{header, offset, length}, ...,}. - isTrafficEncrypted. - Reporting period, defining the period for periodic reporting. - Notification correlation ID. Report type Event triggered Report (for each action performed) Periodic Report (summary of actions done since the last report)

[0041] With this example, there are both new and existing parameters / information present in the table. Currently, UPF events supported by the Nupf^EventExposure service [3GPP TS 29.564 V18.2.0] include QoS Monitoring, User Data Usage Measures, User Data Usage Trends, and TSC Management Information. With features as described herein, a new event (called “Header Handling” in this example) may be used which complements the specified events, and may be used via the Nupf_EventExposure service for example.

[0042] The following is provided as examples of subscription input clarifications: UE IP / MAC address(es). ‘Target PDU session(s) / SDF(s)’ - For SDFs, the same way as defined and used in ATSSS, e g., 5-tuple. For PDU sessions, UE’s public IP address for a PDU session could be provided. ‘Requested actions’ - 5 actions for modifying data packet (Report, Modify, Remove, Replace, and Add) in which case ‘Data and instructions for header handling’ info may be provided as well. "Report" action is used to report header handling back to the subscriber. Additionally, the predefined header data (‘Header data injection for notification’) could be enclosed in the event report. It is worth to note that, if traffic is E2E encrypted and the UPF is not allowed to decrypt it, then some actions can still be applicable, e.g. the action "Report", where the AF may provide an index / offset to indicate to the UPF from where to do the reporting in the encrypted packet, or also if the UPF can work on the metadata only. Regarding metadata for E2E encrypted traffic, UPF may detect available metadata / clear text info from the encrypted data packets and / or it could have available metadata related to the encrypted data packets that is communicated in some other way to the UPF, i.e., not part of the encrypted data packets. ‘Data and instructions for header handling’ - This could be the whole header to be added / modified or then it could be instructions on how to modify the existing header, e g., HeaderType=N (where N=6 means TCP and N=17 means UDP, for example), Offset=M (M bytes from the beginning of the header), Data=<bytes to be inserted starting from the given offset>. For a Remove action, this info may indicate what header(s) is(are) to be removed. For a "Replace" action, this info may indicate which headers to be replaced (and possibly at which offset) and what are the replacing value. ‘UL and / or DL directions’ - Indicates the traffic direction for which monitoring and detection is done. ‘Instructions for reporting’ - Indicate if the resulting event report is only an indication without the given target headers or if the given target headers should be enclosed in the event report. ‘Conditions’ - If provided, then this info defines the actions’ conditionality, i.e., it is not enough that the given header(s) is(are) detected, but provided conditions must also fulfill until the action(s) is(are) triggered. For instance, a condition could be as “IS_EQUAL(UDP:Checksum, 0) indicating that only LDP datagrams without checksum are processed with the given action(s). Similarly, condition could be used to select only IPv6 packets with certain flow label (IPv6 :Flow_label-field) value. Besides known header fields, also header payload could be targeted by using <header type, offset, length, reference_value> set. ‘Header data injection for notification’ - If provided, then this info may describe what headers and / or parts of them are copied and returned as notificationitems in NotificationData. As noted in the Description of the event above, the event may involve “requested data samples” from the detected header(s). The requested data samples, also referred as a new Notificationitem type, may be provided to carry a new type of event data such as, for example, injected data blocks from one or more given headers. ‘Periodic reporting interval’ - If provided, then this value may indicate for periodic reporting how often the summary report is generated and sent. isTrafficEncrypted - Indicates if the traffic is E2E encrypted or not.

[0043] For a new Header Handling event, a new event type (“eventNotificationUri”) may be defined. For NotificationData (=NRKNN(notificationItems)'), new NotificationItem types may be provided to carry new type of event data like injected data blocks from the given headers. Referring also to FIG. 3, this illustrates an example of communications between an AF and a UPF regarding notification for a subscribed event. Before this happens, an AF will have subscribed to an event. FIG. 3 illustrates one example of how UPF generated events could be delivered directly to the subscribed AF.

[0044] The following is an example of a header handling process at the UPF for each received data packet per the subscribed event: • Check if the data packet belongs to the target traffic and: a. if it does, then continue below and b. if it does not, skip the packet. • Check if isTrafficEncrypted=TRUE. If TRUE, then the UPF can only work based on metadata visible in the encrypted data packets and / or already locally available. • Check if one or more ‘Conditions’ is given and: a. if given, then verify whether conditions are met, and b. if not given, then skip the packet or otherwise continue below.

[0045] After the above example of checks, the following are examples of actions which may be performed: a. Common: if ‘Header data injection for notification’ is provided, then collect the defined data blocks from the data packet. b. REPORT: Based on ‘Instructions for reporting’, collect the given target headers data from the data packet, if needed. c. MODIFY: Modify existing header(s) according to ‘Data and instructions for header handling’. d. REMOVE: Remove existing header(s) according to ‘Data and instructions for header handling’. e. ADD: Add new header(s) according to ‘Data and instructions for header handling’. f. REPLACE: Replace existing header(s) according to ‘Data and instructions for header handling’.

[0046] Create new NotificationData with the required notiflcationltems and send the event report back to the subscribed, or postpone its sending according to the configuration, i.e., “delayed reporting”.

[0047] Subscription to UPF handling of UP headers using the NEF, PCF, SMF, UPF path:

[0048] As noted above, besides a “direct” type of situation, there may alternatively be an “indirect” type of situation. The following describes the alternative whereby the AF provides UP headers handling instructions via the NEF, PCF, SMF and UPF.

[0049] Upon receipt of the UP header handling instructions from the PCF / AF, the SMF may provide the UP header instruction handling to the UPF using either of the following options: a) the SMF invokes the new UPF service, or subscribes to the new events of the Nupf EventExposure service, as described in Table 1 - Header Handling event. b) the SMF provides new / extended PFCP instructions to the UPF, for the PFCP session of the PDU session that is subject to the UP header handling instructions (PFCP is the protocol used between the SMF and UPF to control the PFCP session of a PDU session - see 3GPP TS 29.244).

[0050] Regarding the Nupf EventExposure service, the same entity may be sending a subscription and receiving a notification on the subscription. Subscribe, Unsubscribe, and Notify are noted in Clause 5.2.2.1 of 3GPP TS 29.564 V18.2.0, and may comprise: • Subscribe: enables an NF service consumer to subscribe to UPF event exposure notifications. • Unsubscribe: enables an NF service consumer to unsubscribe from UPF event exposure notifications. • Notify: allows the UPF to send event notifications directly to NF service consumers.

[0051] Currently, for a NupfEventExposure service, there is the following parameter “UPF event consumer notification URI”, indicating the address where to send the event notifications generated by the subscription. The SMF may use this parameter to indicate the AF’s address 5 towards which the notifications are directly sent. A similar “notification / reporting address” indication might be provided for the “b)” alternative noted above. With this example, the UPF may send notifications / reports to the correct entity.

[0052] Regarding the PFCP protocol, it currently only supports HTTP Header Enrichment for the UL traffic. This is done by including an Header Enrichment IE in the FAR 10 (Forwarding Action Rule) associated to one or more UL PDRs (Packet Detection Rule). As noted in TS 29.244: "If the UP function indicated support of Header Enrichment of UL traffic (see clause 8.2.25). the CP function may provide the UP function with header enrichment information for uplink traffic, by including one or more Header Enrichment IE(s) in the FAR. In this 15 case, the UP function should use this information to enrich the header of the uplink traffic (e.g. HTTP header enrichment)." Octets Bits 87654321 1 to 2 3 to 4 5 6 7 to m P (p+1) to q s to (n+4) Type = 98 (decimal) Length = n Spare Header Type Length of Header Field Name Header Field Name Length of Header Field Value Header Field Value These octet(s) is / are present only if explicitly specified Figure 8.2.67-1: Header Enrichment Header Type indicates the type of the Header. It shall be encoded as defined in Table 8.2.67-1. Table 8.2.67-1: Header Type Header Type Value (Decimal) HTTP 0 Spare, for future use. 1 to 31 Length of Header Field Name indicates the length of the Header Field Name. Header Field Name shall be encoded as an OctetString. Length of Header Field Value indicates the length of the Header Field Value. Header Field Value shall be encoded as an OctetString. For a HTTP Header Type, the contents of the Header Fie ld Name and Header Field Value shall comply with the HTTP header fieldformat (see clause 3.2 of IETF RFC 7230

[23] ).

[0053] Features as described herein may be used for extending the PFCP protocol in order to support the similar new functionalities as described above. This includes at least one of: • the SMF providing one or more new Header Handling lEs to the UPF, in the FAR associated to UL and / or DL PDRs, with the Header Handling IE supporting parameters such as the new parameters noted above; or • extending the existing Header Enrichment IE to support part or all of the new functionalities / parameters noted above.

[0054] Features as described herein may be used to enables effective UP header handling in a way recognized by AFs or other consumers as a new UPF exposure event. Features as described herein may be used as part of a potential solution for Work Task #4 in 3GPP SA2 Rei 19 FS_UPEAS_Ph2 Study item Description (SID). Features as described herein may be used to enhance the interface between AF and 5GC to allow additional functionality to permit UPF handling of headers (e.g. detection of IP header, http header, etc.), uplink and downlink, as well as reporting / notifications. Features as described herein may be used in regard to what information the AF may instruct the UPF to monitor (such as handling headers for example), and which actions to do. Features as described herein may be used in regard to how the UPF may notify the AF about header handling and what information is provided.

[0055] In accordance with one example embodiment, an apparatus may be provided comprising: at least one processor; and at least one memory storing instructions that, when executed with the at least one processor, cause the apparatus to perform: receiving a user plane header handling instruction from an application function; and determining occurrence of an event based, at least partially, upon the received user plane header handling instruction.

[0056] The at least one memory may store instructions that, when executed with the at least one processor, cause the apparatus to perform receiving a signal and causing provisioning by the apparatus of the determining of the occurrence of the event. The signal may comprise UP data. Alternatively, the signal may comprise the user plane header handling instruction. The user plane header handling instruction may comprise information configured to be used by the apparatus for defining at least one of: header information, action information, or condition information. The header information may comprise at least one of: target header information, or header type information. The target header information may comprise header information located in at least one of: an IP layer, a transport layer, an application layer, metadata of encrypted traffic. The target header information may comprise identification of one or more specific header(s) that are targeted by a subscription. The one or more specific header(s) may comprise a specific HTTP header. The action information may comprise information regarding at least one action of: sending a report, adding a user plane header, deleting a user plane header, removing a user plane header, modifying a user plane header, changing a user plane header, or replacing a user plane header. The report may comprise an indication that there has been an adding / modifying / etc. with regard to a header as well as a description of the performed action, since a subscription might include multiple actions each with its own condition(s). Thus, even if ”action-l” was done, and other actions were not due because their conditions did not fulfil, the report may comprise more than a simple report for “event-1” indicating the occurrence of the event, but may also include a description of what exactly was done in terms of the action(s) done or the action not done. The at least one memory may store instructions that, when executed with the at least one processor, cause the apparatus to perform monitoring of traffic to determine the occurrence of the event. The at least one memory may store instructions that, when executed with the at least one processor, cause the apparatus to perform determining target traffic, and where the monitoring of the traffic comprises monitoring the target traffic. The at least one memory may store instructions that, when executed with the at least one processor, cause the apparatus to perform sending a report based upon the determining of the occurrence of the event. The determining of the occurrence of the event may be based upon at least one of: a user equipment IP address or MAC address, or a service data flow of a user equipment identified with a user equipment IP address. The determining of the occurrence of the event may be based upon a protocol data unit session of a user equipment identified with a user equipment IP address. The user plane header handling instruction may comprise information regarding at least one of an uplink direction or a downlink direction. The condition information may comprise at least one of: a first condition when a value is found from a header, or a different second condition when the value is not found from the header. The user plane header handling instruction may comprise information regarding a header data injection instruction for sending a report. The user plane header handling instruction may comprise information regarding traffic encryption. The receiving of the user plane header handling instruction from the application function may comprise receiving the user plane header handling instruction from at least one of: substantially directly from the application function, or indirectly with a session management function. The at least one memory may store instructions that, when executed with the at least one processor, cause the apparatus to at least one of: invoke a new user plan function service, or subscribe to a new event of a NupfEventExposure service, or determine a new packet forwarding control protocol instruction for the apparatus, or determine an extended packet forwarding control protocol instruction for the apparatus. The receiving of the user plane header handling instruction from the application function may comprise receiving the user plane header handling instruction from the session management function and comprising use of at least one of: a network exposure function, or a policy control function.

[0057] An example method may be provided comprising: receiving a user plane header handling instruction from an application function; and determining occurrence of an event based, at least partially, upon the received user plane header handling instruction. The method may comprise receiving a signal and causing provisioning of the determining of the occurrence of the event. The user plane header handling instruction may comprise information configured to be used for defining at least one of: header information, action information, or condition information. The header information may comprise at least one of: target header information, or header type information. The target header information may comprise header information located in at least one of: an IP layer, a transport layer, an application layer, metadata of encrypted traffic. The target header information may comprise identification of one or more specific header(s) that are targeted by a subscription. The one or more specific header(s) may comprise a specific HTTP header. The action information may comprise information regarding at least one action of: sending a report, adding a user plane header, deleting a user plane header, removing a user plane header, modifying a user plane header, changing a user plane header, or replacing a user plane header. The method may comprise monitoring of traffic to determine the occurrence of the event. The method may comprise determining target traffic, where the monitoring of the traffic comprises monitoring the target traffic. The method may comprise sending a report based upon the determining of the occurrence of the event. The determining of the occurrence of the event may be based, at least partially, upon at least one of: a user equipment or MAC address, or a service data flow of a user equipment identified with a user equipment IP address. The determining of the occurrence of the event may be based, at least partially, upon a protocol data unit session of a user equipment identified with a user equipment IP address. The user plane header handling instruction may comprise information regarding at least one of an uplink direction or a downlink direction. The condition information may comprise at least one of: a first condition when a value is found from a header, or a different second condition when the value is not found from the header. The user plane header handling instruction may comprise information regarding a header data injection instruction for sending a report. The user plane header handling instruction may comprise information regarding traffic encryption. The receiving of the user plane header handling instruction from the application function may comprise receiving the user plane header handling instruction from at least one of: substantially directly from the application function, or indirectly with a session management function. The method may comprise at least one of: invoking a new user plan function service, or subscribing to a new event of a Nupf EventExposure service, or determining a new packet forwarding control protocol instruction for the apparatus, or determining an extended packet forwarding control protocol instruction for the apparatus. The receiving of the user plane header handling instruction from the application function may comprise receiving the user plane header handling instruction from the session management function and comprising use of at least one of: a network exposure function, or a policy control function.

[0058] An example embodiment may be provided with an apparatus comprising: means for receiving a user plane header handling instruction from an application function; and means for determining occurrence of an event based, at least partially, upon the received user plane header handling instruction.

[0059] An example embodiment may be provided with a program storage device readable by an apparatus, tangibly embodying a program of instructions executable with the apparatus for performing operations, the operations comprising: receiving a user plane header handling instruction from an application function; and determining occurrence of an event based, at least partially, upon the received user plane header handling instruction.

[0060] In one type of example, a method may be provided comprising receiving at least one user plane data packet; receiving a user plane header handling instruction from an application function; and determining occurrence of an event based, at least partially, upon the received at least one user plane data packet and the received user plane header handling instruction.

[0061] In accordance with one example embodiment, an apparatus may be provided comprising: at least one processor; and at least one memory storing instructions that, when executed with the at least one processor, cause the apparatus to perform: sending at least one header handling instruction from an application function to a user plane function; and receiving an event report by the application function from the user plane function based, at least partially, upon the sending at least one header handling instruction from an application function to a user plane function. The event report may be in regard to detection or occurance of a header handling event at least partially corresponding to the at least one header handling instruction.

[0062] Referring also to FIG. 5, an example method may be provided comprising: sending at least one header handling instruction from an application function to a user plane function as illustrated with block 502; and receiving an event report by the application function from the user plane function based, at least partially, upon the sending at least one header handling instruction from an application function to a user plane function as illustrated with block 504.

[0063] An example embodiment may be provided with an apparatus comprising: means for sending at least one header handling instruction from an application function to a user plane function; and means for receiving an event report by the application function from the user plane function based, at least partially, upon the sending at least one header handling instruction from an application function to a user plane function.

[0064] An example embodiment may be provided with a program storage device readable by an apparatus, tangibly embodying a program of instructions executable with the apparatus for performing operations, the operations comprising: sending at least one header handling instruction from an application function to a user plane function; and receiving an event report by the application function from the user plane function based, at least partially, upon the sending at least one header handling instruction from an application function to a user plane function.

[0065] The term “non-transitory,” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM).

[0066] As used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and / or digital hardware circuit(s) with software / firmware and (ii) any portions of hardware processor(s) with software (including digital signal processors)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (iii) hardware circuit(s) and or processor(s), such as a microprocessors) or a portion of a microprocessor's), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.”

[0067] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar 5 integrated circuit in server, a cellular network device, or other computing or network device.

[0068] It should be understood that the foregoing description is only illustrative. Various alternatives and modifications can be devised by those skilled in the art. For example, features recited in the various dependent claims could be combined with each other in any suitable combination(s). In addition, features from different embodiments described above could be 10 selectively combined into a new embodiment. Accordingly, the description is intended to embrace all such alternatives, modifications and variances which fall within the scope of the appended claims.

Claims

What is claimed is:

1. An apparatus comprising:at least one processor; andat least one memory storing instructions that, when executed with the at least one processor, cause the apparatus to perform:receiving a user plane header handling instruction from an application function; anddetermining occurrence of an event based, at least partially, upon the received user plane header handling instruction.

2. The apparatus as claimed in claim 1 where the at least one memory stores instructions that, when executed with the at least one processor, cause the apparatus to perform receiving a signal and causing provisioning by the apparatus of the determining of the occurrence of the event.

3. The apparatus as claimed in any one of claims 1-2 where the user plane header handling instruction comprises information configured to be used by the apparatus for defining at least one of:header information,action information, orcondition information.

4. The apparatus as claimed in claim 3 where the header information comprises at least one of:target header information, orheader type information.

5. The apparatus as claimed in claim 4 where the target header information comprises header information located in at least one of:an IP layer,a transport layer,an application layer,metadata of encrypted traffic.

6. The apparatus as claimed in claim 5 where the target header information comprises identification of one or more specific header(s) that are targeted by the user plane header handling instruction.

7. The apparatus as claimed in claim 6 where the one or more specific header(s) comprise a specific HTTP header.

8. The apparatus as claimed in any one of claims 3-7 where the action information comprises information regarding at least one action of:sending an event report,adding a user plane header,removing a user plane header,modifying a user plane header, orreplacing a user plane header.

9. The apparatus as claimed in any one of claims 1-8 where the at least one memory stores instructions that, when executed with the at least one processor, cause the apparatus to perform monitoring of traffic to determine the occurrence of the event.

10. The apparatus as claimed in claim 9 where the at least one memory stores instructions that, when executed with the at least one processor, cause the apparatus to perform determining target traffic, and where the monitoring of the traffic comprises monitoring the target traffic.

11. The apparatus as claimed in any one of claims 1-10 where the at least one memory stores instructions that, when executed with the at least one processor, cause the apparatus to perform sending an event report based upon the determining of the occurrence of the event.

12. The apparatus as claimed in any one of claims 1-11 where the determining of the occurrence of the event is based upon at least one of:a user equipment IP address or MAC address, ora service data flow of a user equipment identified with a user equipment IP address.

13. The apparatus as claimed in any one of claims 1-12 where the determining of the occurrence of the event is based upon:a protocol data unit session of a user equipment identified with a user equipment IP address.

14. The apparatus as claimed in any one of claims 1-13 where the user plane header handling instruction comprises information indicating that it applies to the traffic of at least one of an uplink direction or a downlink direction.

15. The apparatus as claimed in claim 3 where the condition information comprises at least one of:a first condition when a value is found from a header, ora different second condition when the value is not found from the header.

16. The apparatus as claimed in any one of claims 1-15 where the user plane header handling instruction comprises information regarding a header data injection instruction for sending a report which indicates headers, or at least part of a header, that are requested to be copied within the event report.

17. The apparatus as claimed in any one of claims 1-16 where the user plane header handling instruction comprises information regarding traffic encryption.

18. The apparatus as claimed in any one of claims 1-17 where the receiving of the user plane header handling instruction from the application function comprises receiving the user plane header handling instruction from at least one of:substantially directly from the application function, orindirectly from the application function via a session management function.

19. The apparatus as claimed in claim 18 where the at least one memory stores instructions that, when executed with the at least one processor, cause the apparatus to at least one of:invoke a new user plane function service, orsubscribe to a new event of a NupfEventExposure service, ordetermine a new packet forwarding control protocol instruction for the apparatus, ordetermine an extended packet forwarding control protocol instruction for the apparatus.

20. The apparatus as claimed in claim 18 where the receiving of the user plane header handling instruction from the application function comprises receiving the user plane header handling instruction from the session management function and comprising use of at least one of:a network exposure function, ora policy control function.

21. A method comprising:receiving a user plane header handling instruction from an application function; anddetermining occurrence of an event based, at least partially, upon the received user plane header handling instruction.

22. The method as claimed in claim 21 comprising receiving a signal and causing provisioning of the determining of the occurrence of the event.

23. The method as claimed in any one of claims 21-22 where the user plane header handling instruction comprises information configured to be used for defining at least one of:header information,action information, or5 condition information.

24. An apparatus comprising:means for receiving a user plane header handling instruction from an application function; andmeans for determining occurrence of an event based, at least partially, upon the received 10 user plane header handling instruction.

25. A program storage device readable by an apparatus, tangibly embodying a program of instructions executable with the apparatus for performing operations, the operations comprising:receiving a user plane header handling instruction from an application function; and15 determining occurrence of an event based, at least partially, upon the received userplane header handling instruction.31

Images