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

Abstract

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: receive a user plane header processing instruction from an application function; and determining an occurrence of an event based at least in part on the received user plane header processing instruction.

Description

Technical Field

[0001] Examples and non-limiting embodiments generally relate to application functions, and more particularly, to user plane header processing. Background Art

[0002] In communication, the User Plane Function (UPF) supports: packet routing and forwarding, packet inspection, QoS handling, serves as an external PDU session point for interconnection with a Data Network (DN), and is an anchor point for mobility within and between RATs. Additionally, the Application Function (AF) supports: the influence of the application on traffic routing, access to the NEF, and interaction with the policy framework for policy control. The AF can be provided as part of the control plane or as part of the user plane, such as, for example, together with the data network. Summary of the Invention

[0003] The following summary of the invention is only intended as an example. The summary of the invention is not intended to limit the scope of the claims.

[0004] According to one aspect, an example provides 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 processing instruction from an application function; and determining the occurrence of an event based at least in part on the received user plane header processing instruction.

[0005] According to one aspect, an example provides a method comprising: receiving a user plane header processing instruction from an application function; and determining the occurrence of an event based at least in part on the received user plane header processing instruction.

[0006] According to one aspect, an example provides an apparatus comprising: means for receiving a user plane header processing instruction from an application function; and means for determining the occurrence of an event based at least in part on the received user plane header processing instruction.

[0007] According to one aspect, an example provides a program storage device readable by a device, the program storage device tangibly embodying a program of instructions executable by the device to perform operations comprising: receiving a user plane header processing instruction from an application function; and determining the occurrence of an event based at least in part on the received user plane header processing instruction.

[0008] According to one aspect, an example apparatus may be provided, the apparatus including: 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 processing instruction from an application function to a user plane function; and receiving, by the application function from the user plane function, an event report at least partially based on sending the at least one header processing instruction from the application function to the user plane function. The event report may be related to the detection or occurrence of a header processing event that at least partially corresponds to the at least one header processing instruction.

[0009] According to one aspect, an example method may be provided, the method including: sending at least one header processing instruction from an application function to a user plane function; and receiving, by the application function from the user plane function, an event report at least partially based on sending the at least one header processing instruction from the application function to the user plane function.

[0010] According to one aspect, an example embodiment may provide an apparatus including: means for sending at least one header processing instruction from an application function to a user plane function; and means for receiving, by the application function from the user plane function, an event report at least partially based on sending the at least one header processing instruction from the application function to the user plane function.

[0011] According to one aspect, an example embodiment may provide a program storage device readable by a device, the program storage device tangibly embodying a program of instructions executable by the device to perform operations including: sending at least one header processing instruction from an application function to a user plane function; and receiving, by the application function from the user plane function, an event report at least partially based on sending the at least one header processing instruction from the application function to the user plane function.

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

[0013] In conjunction with the accompanying drawings, the above aspects and other features are explained in the following description in conjunction with the accompanying drawings, in which:

[0014] Figure 1 is a block diagram of a possible and non-limiting example system in which an example embodiment may be practiced;

[0015] Figure 2 is a diagram showing example components in a control plane (CP) and a user plane (UP);

[0016] Figure 3 is a diagram showing an example of communication of a notification regarding a subscription event between an AF and a UPF;

[0017] Figure 4 is a diagram showing an example method; and

[0018] Figure 5 is a diagram showing an example method. Detailed Implementation Manner

[0019] The following abbreviations that may appear in the specification and / or drawings are defined as follows:

[0020] 3GPP Third Generation Partnership Project

[0021] 5G Fifth Generation

[0022] 5GC 5G Core Network

[0023] AF Application Function

[0024] AMF Access and Mobility Management Function

[0025] ATSSS Access Service Steering, Switching and Splitting

[0026] AUSF Authentication Server Function

[0027] CN Control Plane

[0028] CU Central Unit

[0029] DN Data Network

[0030] DU Distributed Unit

[0031] E2E End-to-End

[0032] EE Event Exposure

[0033] eNB (or eNodeB) Evolved Node B (e.g., LTE base station) EN-DC E-UTRA-NR Dual Connectivity

[0034] en-gNB or En-gNB A node that provides NR user plane and control plane protocol termination to the UE and acts as the secondary node in EN-DC E-UTRA Evolved Universal Terrestrial Radio Access, i.e., LTE radio access technology

[0035] FAR Forwarding Action Rule

[0036] gNB (or gNodeB) Base station for 5G / NR, i.e., a node that provides NR user plane and control plane protocol termination to the UE and is connected to the 5GC via the NG interface IE Information Element

[0039] I / F Interface

[0040] LTE Long Term Evolution

[0041] MAC Media Access Control

[0042] MME Mobility Management Entity

[0043] NEF Network Exposure Function

[0044] NF Network Function

[0045] ng or NG New Generation

[0046] ng-eNB or NG-eNB New Generation eNB NR New Radio

[0047] NRF Network Repository Function

[0048] NSSF Network Slice Selection Function

[0049] N / W or NW Network

[0050] PCF Policy Control Function

[0051] PDCP Packet Data Convergence Protocol

[0052] PFCP Packet Forwarding Control Protocol

[0053] PHY Physical Layer

[0054] QUIC Quick UDP Internet Connections

[0055] RAN Radio Access Network

[0056] Rel Release

[0057] RLC Radio Link Control

[0058] RRH Remote Radio Head

[0059] RRC Radio Resource Control

[0060] RU Radio Unit

[0061] Rx Receiver

[0062] SDAP Service Data Adaptation Protocol

[0063] SDF Service Data Flow

[0064] SID Study Item Description

[0065] SGW Serving Gateway

[0066] SMF Session Management Function

[0067] TCP Transmission Control Protocol

[0068] TS Technical Specification

[0069] Tx Transmitter

[0070] UDM Unified Data Management

[0071] UDP User Datagram Protocol

[0072] UE User Equipment (e.g., wireless, typically a mobile device)

[0073] UP User Plane

[0074] UPF User Plane Function

[0075] Go to Figure 1 , which shows a block diagram of one possible and non - limiting example in which an example can be practiced. A user equipment (UE) 110, a radio access network (RAN) node 170, and one or more network elements 190 are shown. For example, an example of a network device, network apparatus, or network entity can be understood to include at least a portion of a transmission reception point or a cell or a gNB or a node. In Figure 1In the example, user equipment (UE) 110 wirelessly communicates with a wireless network 100. The 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 by 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 can be address, data, or control buses and can include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, optical fibers, or other optical communication devices. 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, including one or both of portions 140-1 and / or 140-2, which can be implemented in a variety of ways. The module 140 can be implemented as module 140-1 in hardware, such as as part of one or more processors 120. The module 140-1 can also be implemented as an integrated circuit or by other hardware (such as a programmable gate array). In another example, the module 140 can be implemented as module 140-2, which is implemented as computer program code 123 and executed by one or more processors 120. For example, the one or more memories 125 and the computer program code 123 can be configured to, together with one or more processors 120, cause the user equipment 110 to perform one or more operations described herein. The UE 110 communicates with a RAN node 170 via a wireless link 111.

[0076] The RAN node 170 in this example is a base station that provides access to the wireless network 100 by wireless devices such as the UE 110. The RAN node 170 can be, for example, a base station for 5G (also known as New Radio (NR)). In 5G, the RAN node 170 can be an NG-RAN node, which is defined as a gNB or an ng-eNB. A gNB is a node that provides NR user plane and control plane protocol termination to the UE and is connected to the 5GC (such as, for example, (one or more) network elements 190) via the NG interface. An ng-eNB is a node that provides E-UTRA user plane and control plane protocol termination to the UE and is connected to the 5GC via the NG interface. The NG-RAN node can include multiple gNBs, which can also include a Central Unit (CU) (gNB-CU) 196 and (one or more) Distributed Units (DU) (gNB-DU), where the DU 195 is shown. Note that the DU can include or be coupled to and control a Radio Unit (RU). The gNB-CU is a logical node that hosts the RRC, SDAP, and PDCP protocols of the gNB or the RRC and PDCP protocols of the en-gNB, and controls the operation of one or more gNB-DUs. The gNB-CU terminates the F1 interface connected to the gNB-DU. The F1 interface is shown as reference numeral 198, although reference numeral 198 also shows the link between the remote element of the RAN node 170 and the centralized element of the RAN node 170, such as the link between the gNB-CU 196 and the gNB-DU 195. The gNB-DU is a logical node that hosts the RLC, MAC, and PHY layers of the gNB or the en-gNB, and its operation is partially controlled by the gNB-CU. One gNB-CU supports one or more cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface 198 connected to the gNB-CU. Note that the DU 195 is considered to include the transceiver 160, for example, as part of the RU, but some examples of this case can have the transceiver 160 as part of a separate RU, for example, under the control of the DU 195 and connected to the DU 195. The RAN node 170 can also be an eNB (evolved NodeB) base station for LTE (Long-Term Evolution), or any other suitable base station or node.

[0077] The RAN node 170 includes one or more processors 152, one or more memories 155, one or more network interfaces (N / W I / F) 161, and one or more transceivers 160 interconnected by 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 (multiple) processors 152, the memory 155, and the network interface 161. Note that the DU 195 may also contain its own one or more memories and (multiple) processors and / or other hardware, but these are not shown.

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

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

[0080] One or more buses 157 can be address, data, or control buses and can include any interconnection mechanism such as a series of lines on a motherboard or integrated circuit, fiber optic or other optical communication devices, wireless channels, etc. For example, one or more transceivers 160 can be implemented as a remote radio head (RRH) 195 for LTE or a distributed unit (DU) 195 for a gNB implementation for 5G, where other elements of the RAN node 170 may be physically located at a different location from the RRH / DU, and one or more buses 157 can be partially implemented as, for example, a fiber optic cable or other suitable network connection to connect other elements of the RAN node 170 (e.g., a central unit (CU), gNB-CU) to the RRH / DU 195. Reference numeral 198 also indicates those suitable (multiple) network links.

[0081] It should be noted that the description herein indicates that a "cell" performs functions, but it should be clear that the devices forming the cell will perform these functions. A cell forms part of a base station. That is, each base station can have multiple cells. For example, for a single carrier frequency and associated bandwidth, there can be three cells, each covering one-third of a 360-degree area, such that the coverage area of a single base station covers an approximately elliptical or circular shape. In addition, each cell can correspond to a single carrier, and a base station can use multiple carriers. Thus, if there are three 120-degree cells per carrier and there are two carriers, the base station has a total of 6 cells.

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

[0083] The wireless network 100 may implement network virtualization, which is the process of combining hardware and software network resources with network functions into a single software-based management entity (virtual network). Network virtualization involves platform virtualization, typically combined with resource virtualization. Network virtualization is classified as external virtualization and internal virtualization. External virtualization combines many networks or parts of networks into virtual units, and internal virtualization provides network-like functions for software containers on a single system. Note that the virtualized entities resulting from network virtualization still use hardware (such as processors 152 or 175 and memories 155 and 171) to some extent for implementation, and such virtualized entities also produce technical effects.

[0084] The computer-readable memories 125, 155, and 171 can be of any type suitable for the local technical environment and can 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 can be components for performing storage functions. The processors 120, 152, and 175 can be of any type suitable for the local technical environment and, by way of non-limiting example, can include one or more of the following: general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), and processors based on multi-core processor architectures. The processors 120, 152, and 175 can be components for performing functions such as controlling the UE 110, the RAN node 170, and other functions as described herein.

[0085] In general, various embodiments of the user equipment 110 can include, but are not limited to, cellular phones such as smart phones, tablet computers, personal digital assistants (PDAs) with wireless communication capabilities, portable computers with wireless communication capabilities, image capture devices such as digital cameras with wireless communication capabilities, game devices with wireless communication capabilities, music storage and playback devices with wireless communication capabilities, Internet devices that allow wireless Internet access and browsing, tablet computers with wireless communication capabilities, and portable units or terminals incorporating combinations of these functions.

[0086] Also referring to Figure 2 , an example control plane (CP) can include, for example, the following: NSSF, NEF, NRF, PCF, UDM, AF, AMF, AUSF, and SMF. Additionally, an example user plane (UP) can include the UE, RAN, UPF, and DN. A data network DN (such as an external data network) can also include one or more application functions AF. Note that this is merely an illustrative example showing some features and is not intended to be considered limiting.

[0087] The current FAR (Forwarding Action Rule) in the N4 interface includes a container for header enrichment, and the UPF uses this information to insert headers for uplink traffic at N6. However, the current packet headers can only be used for marking to steer multiple service functions in N6. The operator can decide to use packet headers that provide relevant information for application functions in the operator's platform. The features described herein can be used as enhancements to allow additional functions that enable the UPF to detect the headers of traffic to / from the UE and notify the AF after header detection.

[0088] Using the features described herein, the UPF can support a new service that allows NF service consumers or AFs to provide user plane header processing instructions. For example, this can relate to a specific user plane (UP) header and can include, for example, adding a header, or modifying a header, or removing a header, or replacing a header, or only relate to detecting a specific UP header. This may relate to the uplink (UL) direction or the downlink (DL) direction, or both the UL and DL directions. This service may include reporting one or more specific events. For example, a specific event may include when a header is detected, or a specific event may include when a header is modified, added, removed, replaced, or deleted.

[0089] In another example embodiment, the UPF Nupf_EventExposure service can support one or more new events that enable subscribed NFs to request to be notified when the UPF detects and / or acts on a specific header in a user plane packet for a target service (in the UL and / or DL directions).

[0090] The PFCP protocol (used between the SMF and the UPF) can also be extended to support new functionality.

[0091] In an example embodiment, the AF can provide the UPF with UP header processing instructions in one of the following ways:

[0092] - Directly call or subscribe to the new UPF service or UPF Nupf_EventExposure service described above. The AF can discover the UPF for a specific service (such as, for example, one or more given PDU sessions) and directly or indirectly call or subscribe to the UPF service.

[0093] - Provide such instructions to the NEF / PCF / SMF, and the SMF instructs the UPF to use UPF event exposure or the new UPF service or, for example, via PFCP extension accordingly.

[0094] The AF can provide the following information to request UP header processing, which can define what the UPF should monitor, what headers the UPF should process (such as, for example, add / modify / remove / replace / detect), and what actions can be taken by the UPF once one or more specific headers are found and under what conditions (if any). This may include:

[0095] · The target header for which an action is to be taken,

[0096] · A list of actions to be performed, and

[0097] · The conditions under which the actions are to be performed.

[0098] Communication regarding UPF event subscription from the AF can be either directly via N6 or indirect, such as via NEF / PCF / SMF using N33 for example. Once the AF has subscribed to the events of this UPF, the UPF can start monitoring the target traffic, and for each header and / or condition match, a given action (e.g., modify, remove, add) can be taken, and a related trigger report (e.g., header detection event or header processing event) can be generated and sent to the subscribed AF.

[0099] Using the features as described herein, features can be provided regarding the services / operations opened by the UPF and their required inputs. The AF can discover the UPF endpoints (reachable via N6) from the NEF (such as via N33 for example). Alternative methods can be provided without opening the UPF endpoints between the AF and the UPF, and then subscribing to new services and / or event exposure (EE) services from the UPF directly via N6 or indirectly via the NEF as an intermediary / agent.

[0100] One or more new event types can be provided. An example is shown in Table 1 below, which is an example labeled as a header processing event.

[0101] Table 1: Header Processing Event.

[0102]

[0103]

[0104]

[0105] Using this example, there are both new parameters / information and existing parameters / information in the table. Currently, the UPF events supported by the Nupf_EventExposure service [3GPP TS29.564 V18.2.0] include QoS monitoring, user data usage measurement, user data usage trend, and TSC management information. Using the features as described herein, new events (referred to as "header processing" in this example) can be used, which supplement the specified events and can be used via the Nupf_EventExposure service for example.

[0106] The following are provided as examples of subscription input descriptions:

[0107] One or more UE IP / MAC addresses.

[0108] "(One or more) target PDU sessions / (one or more) SDFs" - For SDFs, in the same way as defined and used in ATSSS, such as a 5-tuple. For PDU sessions, the public IP address of the UE for the PDU session can be provided.

[0109] "Requested Action" - Five actions for modifying data packets (report, modify, remove, replace, and add). In this case, information on "instructions and data for header processing" can also be provided. The "report" action is used to report header processing to a subscriber. Additionally, predefined header data ("header data injection for notification") can be included in the event report. It should be noted that if the service is E2E encrypted and the UPF is not allowed to decrypt it, certain actions still apply, such as the "report" action, where the AF can provide an index / offset to indicate where in the encrypted packet the UPF should report, or whether the UPF can only process metadata. Regarding metadata for E2E encrypted services, the UPF can detect available metadata / plaintext information from the encrypted data packet, and / or it may have available metadata related to the encrypted data packet that is transmitted to the UPF in other ways, i.e., not as part of the encrypted data packet.

[0110] "Instructions and Data for Header Processing" - This could be the entire header to be added / modified or instructions on how to modify an existing header. For example, HeaderType = N (e.g., N = 6 for TCP and N = 17 for UDP), Offset = M (M bytes from the start of the header), Data = <bytes to be inserted starting from the given offset>. For the remove action, this information can indicate which header is to be removed. For the "replace" action, this information can indicate which headers are to be replaced (and possibly at which offset) and what the replacement value is.

[0111] "UL and / or DL Direction" - Indicates the service direction for which monitoring and detection are performed.

[0112] "Instructions for Reporting" - Indicates whether the generated event report is just an indication without a given target header or whether the given target header should be included in the event report.

[0113] "Condition" - If provided, this information defines the conditionality of the action, i.e., the detection of the (multiple) given headers is not sufficient, and the provided condition must also be met until the (multiple) action is triggered. For example, the condition could be

[0114] "IS_EQUAL(UDP:Checksum,0)", which indicates that only UDP datagrams without a checksum are processed using the (multiple) given actions. Similarly, conditions can be used to select only IPv6 packets with a specific flow label (IPv6:Flow_label - field) value.

[0115] In addition to the known header fields, the header payload can also be located by using a set of <header type, offset, length, reference_value>.

[0116] "Header Data Injection for Notification" - If provided, this information may describe the header and / or parts of the header that are copied and returned as notificationItems in NotificationData. As described in the event description above, the event may involve "requested data samples" from the detected (multiple) headers. The requested data samples (also known as a new NotificationItem type) can be provided to carry new types of event data, such as injection data blocks from one or more given headers.

[0117] "Periodic Reporting Interval" - If provided, this value may indicate the frequency at which summary reports are generated and sent for periodic reporting.

[0118] isTrafficEncrypted - Indicates whether the traffic is E2E encrypted.

[0119] For new header processing events, a new event type ("eventNotificationUri") can be defined. For NotificationData (= ARRAY(notificationItems)), a new NotificationItem type can be provided to carry new types of event data, such as injection data blocks from a given header. Also refer to Figure 3 , which shows an example of the communication between the AF and the UPF regarding notifications for subscribed events. Before this occurs, the AF will subscribe to the event. Figure 3 Shows an example of how an event generated by the UPF can be directly delivered to the subscribed AF.

[0120] The following is an example of the header processing procedure for each received data packet for each subscribed event at the UPF:

[0121] · Check if the data packet belongs to the target traffic:

[0122] a. If yes, then continue with the following and

[0123] b. If no, then skip the packet.

[0124] · Check if isTrafficEncrypted = TRUE. If TRUE, the UPF can only work based on the metadata visible in the encrypted data packet and / or locally already available.

[0125] · Check if one or more "conditions" are given and:

[0126] a. If given, verify whether the verification condition is satisfied, and

[0127] b. If not given, skip the grouping or otherwise continue as follows.

[0128] After the above example of checking, the following are examples of actions that can be performed:

[0129] a. Common: If "header data injection for notification" is provided, collect the defined data blocks from the data grouping.

[0130] b. Report: Based on the "instructions for reporting", collect the given target header data from the data grouping (if required).

[0131] c. Modify: Modify the existing header(s) according to the "instructions and data for header processing"

[0132] Existing header(s).

[0133] d. Remove: Remove the existing header(s) according to the "instructions and data for header processing"

[0134] Existing header(s).

[0135] e. Add: Add the new header(s) according to the "instructions and data for header processing"

[0136] New header(s).

[0137] f. Replace: Replace the existing header(s) according to the "instructions and data for header processing"

[0138] Existing header(s).

[0139] Create a new NotificationData with the required notificationItems and send the event report back to the subscriber, or defer its sending according to the configuration, i.e., "delayed reporting".

[0140] Subscription for UPF processing of the UPF header using NEF, PCF, SMF, UPF paths:

[0141] As described above, except for the "direct" type of cases, alternatively there can be "indirect" type of cases. The following describes the alternative where the AF provides the UP header processing instructions via the NEF, PCF, SMF, and UPF.

[0142] After receiving the UP header processing instructions from the PCF / AF, the SMF can use any of the following options to provide the UP header instruction processing to the UPF:

[0143] a) The SMF invokes a new UPF service or subscribes to a new event of the Nupf_EventExposure service, as described in Table 1 - Header Handling Events.

[0144] b) The SMF provides new / extended PFCP instructions to the UPF for the PFCP session of a PDU session subject to UPF header handling instructions (PFCP is the protocol used between the SMF and the UPF to control the PFCP session of the PDU session - see 3GPP TS

[0145] 29.244).

[0146] Regarding the Nupf_EventExposure service, the same entity can send a subscription and receive notifications about the subscription. Subscriptions, unsubscriptions, and notifications are specified in clause 5.2.2.1 of 3GPP TS29.564 V18.2.0 and can include:

[0147] · Subscription: Enables the NF service consumer to subscribe to UPF event open notifications.

[0148] · Unsubscription: Enables the NF service consumer to unsubscribe from UPF event open notifications.

[0149] · Notification: Allows the UPF to directly send event notifications to the NF service consumer.

[0150] Currently, for the Nupf_EventExposure service, there is the following parameter "UPF Event Consumer Notification URI", which indicates the address to which event notifications generated by the subscription are sent. The SMF can use this parameter to indicate the AF address to which notifications are sent directly to it. A similar "notification / reporting address" indication can be provided for alternative "b)". With this example, the UPF can send notifications / reports to the correct entity.

[0151] Regarding the PFCP protocol, it currently only supports HTTP header enrichment for UL traffic. This is done by including a header enrichment IE in the FAR (Forwarding Action Rule) associated with one or more UL PDRs (Packet Detection Rules). As described in TS29.244:

[0152] "If the UP function indicates support for header enrichment of UL traffic (see clause 8.2.25), the CP function can provide the UP function with header enrichment information for uplink traffic by including one or more header enrichment IEs in the FAR. In this case, the UP function shall use this information to enrich the headers of the uplink traffic (e.g., HTTP header enrichment)."

[0153]

[0154] Figure 8.2.67-1: Header Enrichment

[0155] The header type indicates the type of the header. It shall be encoded as defined in Table 8.2.67-1.

[0156] Table 8.2.67-1: Header Types

[0157] Header type Value (decimal) HTTP 0 Reserved for future use. 1 to 31

[0158] The length of the header field name indicates the length of the header field name.

[0159] The header field name shall be encoded as an octet string.

[0160] The length of the header field value indicates the length of the header field value.

[0161] The header field value shall be encoded as an octet string.

[0162] For HTTP header types, the content of the header field name and the header field value shall conform to the HTTP header field format (see clause 3.2 of IETF RFC 7230

[23] ).

[0163] The features described herein can be used to extend the PFCP protocol to support similar new functions as described above. This includes at least one of the following:

[0164] · The SMF provides one or more new header processing IEs to the UPF in the FAR associated with the UL and / or DL PDR, where the header processing IE supports parameters such as the new parameters described above; or

[0165] · Extend the existing header enrichment IE to support some or all of the new functions / parameters described above.

[0166] The features described herein can be used to implement effective UP header processing in a way that is recognized by the AF or other consumers as a new UPF open event. The features described herein can be used as part of a potential solution for Work Task #4 in the 3GPP SA2 Rel19 FS_UPEAS_Ph2 Research Project Description (SID). The features described herein can be used to enhance the interface between the AF and the 5GC to allow additional functionality for allowing the UPF to process headers (e.g., detect IP headers, http headers, etc.), uplink and downlink, and reporting / notification. The features described herein can be used regarding what information the AF can instruct the UPF to monitor (such as, for example, processing headers) and what actions to perform. The features described herein can be used regarding how the UPF notifies the AF about header processing and what information is provided.

[0167] According to one example embodiment, an apparatus may be provided that includes: 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 processing instruction from an application function; and determining the occurrence of an event based at least in part on the received user plane header processing instruction.

[0168] At least one memory can store instructions which, when executed with at least one processor, cause the device to execute receiving a signal and cause the device to provide a determination of the occurrence of an event. The signal can include UP data. Alternatively, the signal can include user plane header processing instructions. The user plane header processing instructions can include information that is configured to be used by the device to define at least one of the following: header information, action information, or condition information. The header information can include at least one of the following: destination header information, or header type information. The destination header information can include header information located in at least one of the following: IP layer, transport layer, application layer, metadata of encrypted traffic. The destination header information can include the identification of one or more specific headers targeted by a subscription. The one or more specific headers can include a specific HTTP header. The action information can include information about at least one of the following actions: 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 can include an indication that a header has been added / modified / etc. and a description of the action performed, as a subscription may include multiple actions, each with its own (multiple) conditions. Thus, even if "action-1" has been completed while other actions have not expired due to their conditions not being met, the report may include not just a simple report of "event-1" indicating the occurrence of an event, but also a specific description of the actions taken or not taken. At least one memory can store instructions which, when executed with at least one processor, cause the device to perform monitoring of traffic to determine the occurrence of an event. At least one memory can store instructions which, when executed with at least one processor, cause the device to perform determining a target traffic, and wherein the monitoring of traffic includes monitoring the target traffic. At least one memory can store instructions which, when executed with at least one processor, cause the device to send a report based on a determination of the occurrence of an event. The determination of the occurrence of an event can be based on at least one of the following: user equipment IP address or MAC address, or service data flow of the user equipment identified by the user equipment IP address. The determination of the occurrence of an event can be based on the protocol data unit session of the user equipment identified by the user equipment IP address. The user plane header processing instructions can include information about at least one of the uplink direction or the downlink direction. The condition information can include at least one of the following: a first condition when a value is found from the header, or a different second condition when a value is not found from the header. The user plane header processing instructions can include information about header data injection instructions for sending a report. The user plane header processing instructions can include information about traffic encryption.Receiving a user plane header processing instruction from an application function may include receiving the user plane header processing instruction from at least one of the following: substantially directly from the application function, or indirectly using a session management function. At least one memory may store instructions which, when executed with at least one processor, cause the apparatus to perform at least one of the following: invoke a new user plane function service, or subscribe to a new event of the Nupf_EventExposure service, or determine new packet forwarding control protocol instructions for the apparatus, or determine extended packet forwarding control protocol instructions for the apparatus. Receiving a user plane header processing instruction from an application function may include receiving the user plane header processing instruction from a session management function and include using at least one of the following: a network exposure function, or a policy control function.

[0169] An example method may be provided, the method comprising: receiving user plane header processing instructions from an application function; and determining the occurrence of an event based at least in part on the received user plane header processing instructions. The method may include receiving a signal and causing the device to provide a determination of the occurrence of the event. The user plane header processing instructions may include information configured to be used by the device for defining at least one of the following: header information, action information, or condition information. The header information may include at least one of the following: destination header information or header type information. The destination header information may include header information located in at least one of the following: IP layer, transport layer, application layer, metadata of encrypted traffic. The destination header information may include the identification of one or more specific headers targeted by a subscription. The one or more specific headers may include a specific HTTP header. The action information may include information about at least one of the following actions: sending an event 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 include monitoring traffic to determine the occurrence of an event. The method may include determining a target traffic, wherein the monitoring of the traffic includes monitoring the target traffic. The method may include sending a report based on the determination of the occurrence of the event. The determination of the occurrence of the event may be based on at least one of the following: user equipment IP address or MAC address, or service data flow of the user equipment identified by the user equipment IP address. The determination of the occurrence of the event may be at least partially based on the protocol data unit session of the user equipment identified by the user equipment IP address. The user plane header processing instructions may include information about at least one of the uplink direction or the downlink direction. The condition information may include at least one of the following: a first condition when a value is found in the header, or a different second condition when the value is not found in the header. The user plane header processing instructions may include information about header data injection instructions for sending a report. The user plane header processing instructions may include information about traffic encryption. Receiving user plane header processing instructions from an application function may include receiving user plane header processing instructions from at least one of the following: substantially directly from the application function, or indirectly using a session management function. The method may include at least one of the following: invoking a new user plane function service, or subscribing to a new event of the Nupf_EventExposure service, or determining new packet forwarding control protocol instructions for the device, or determining extended packet forwarding control protocol instructions for the device. Receiving user plane header processing instructions from an application function may include receiving user plane header processing instructions from a session management function and include using at least one of the following: a network exposure function, or a policy control function.

[0170] An example embodiment may provide an apparatus that includes: means for receiving user plane header processing instructions from an application function; and means for determining the occurrence of an event based at least in part on the received user plane header processing instructions.

[0171] An example embodiment may provide a program storage device readable by a device, the program storage device tangibly embodying a program of instructions executable by the device to perform operations including: receiving user plane header processing instructions from an application function; and determining the occurrence of an event based at least in part on the received user plane header processing instructions.

[0172] In one type of example, a method may be provided that includes: receiving at least one user plane data packet; receiving user plane header processing instructions from an application function; and determining the occurrence of an event based at least in part on the received at least one user plane data packet and the received user plane header processing instructions.

[0173] According to an example embodiment, an apparatus may be provided that includes: 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 processing instruction from an application function to a user plane function; and receiving, by the application function from the user plane function, an event report based at least in part on sending at least one header processing instruction from the application function to the user plane function. The event report may be about the detection or occurrence of a header processing event that at least partially corresponds to the at least one header processing instruction.

[0174] Also refer to Figure 5 , an example method may be provided that includes: sending at least one header processing instruction from an application function to a user plane function, as shown by block 502; and receiving, by the application function from the user plane function, an event report based at least in part on sending at least one header processing instruction from the application function to the user plane function, as shown by block 504.

[0175] An example embodiment may provide an apparatus that includes: means for sending at least one header processing instruction from an application function to a user plane function; and means for receiving, by the application function from the user plane function, an event report based at least in part on sending at least one header processing instruction from the application function to the user plane function.

[0176] An example embodiment may provide a program storage device readable by a device, the program storage device tangibly embodying a program of instructions executable by the device to perform operations, the operations including: sending at least one header processing instruction from an application function to a user plane function; and receiving, by the application function from the user plane function, an event report at least in part based on sending at least one header processing instruction from the application function to the user plane function.

[0177] As used herein, the term "non-transitory" is a limitation of the medium itself (i.e., tangible, rather than a signal), rather than a limitation of data storage persistence (e.g., RAM versus ROM).

[0178] As used in this application, the term "circuitry" may refer to one or more or all of the following:

[0179] (a) Only hardware circuit implementations (such as, only implementations in analog and / or digital circuitry) and

[0180] (b) Combinations of hardware circuits and software, such as (where applicable):

[0181] (i) Combinations of (one or more) analog and / or digital hardware circuits with software / firmware and

[0182] (ii) Any portion of a (one or more) hardware processors (including (one or more) digital signal processors) with software and (one or more) memories, which work together to cause a device (such as a mobile phone or a server) to perform various functions, and

[0183] (iii) (One or more) hardware circuits and / or (one or more) processors, such as (one or more) microprocessors or a portion of (one or more) microprocessors, that require software (e.g., firmware) to operate, but the software may not be present when the operation does not require software.

[0184] This definition of circuitry applies to all uses of the term in this application, including in any claims. As a further example, as used in this application, the term "circuitry" also encompasses implementations of only hardware circuits or processors (or one or more processors) or a portion of a hardware circuit or processor and their (or its) attendant software and / or firmware. The term "circuitry" also encompasses, for example, if applicable to a particular claim element, a baseband integrated circuit or a processor integrated circuit for a mobile device or a similar integrated circuit in a server, a cellular network device, or other computing or network device.

[0185] It should be understood that the above description is illustrative only. Various alternatives and modifications can be devised by those skilled in the art. For example, the features described in the respective dependent claims can be combined with each other in any suitable combination(s). Additionally, the features in the above different embodiments can be selectively combined into new embodiments. Accordingly, this description is intended to cover all such alternatives, modifications, and variations that fall within the scope of the appended claims.

Claims

1. A device for communication, the device comprising: at least one processor; and at least one memory storing instructions which, when executed with the at least one processor, cause the device to perform: receive a user plane header processing instruction from an application function; and determine the occurrence of an event, at least in part based on the received user plane header processing instruction.

2. The device according to claim 1, wherein the at least one memory stores instructions which, when executed with the at least one processor, cause the device to perform: receive a signal and cause the device to provide the determination of the occurrence of the event.

3. The device according to claim 1, wherein the user plane header processing instruction includes information configured to be used by the device to define at least one of the following: header information, action information, or condition information.

4. The device according to claim 3, wherein the header information includes at least one of the following: destination header information, or header type information.

5. The device according to claim 4, wherein the destination header information includes header information located in at least one of the following: the IP layer, the transport layer, the application layer, metadata of an encrypted service.

6. The apparatus according to claim 5, wherein the target header information includes: The identification of one or more specific headers targeted by the user plane header processing instruction.

7. The device according to claim 6, wherein the one or more specific headers include a specific HTTP header.

8. The device according to claim 3, wherein the action information includes information about at least one of the following actions: send an event report, add a user plane header, remove a user plane header, modify a user plane header, or replace a user plane header.

9. The device according to claim 1, wherein the at least one memory stores instructions which, when executed with the at least one processor, cause the device to perform monitoring of a service to determine the occurrence of the event.

10. The apparatus according to claim 9, wherein the at least one memory stores instructions that, when executed with the at least one processor, cause the apparatus to perform: determining a target service, and wherein the monitoring of the service includes: Monitor the target service.

11. The device according to claim 1, wherein the at least one memory stores instructions which, when executed with the at least one processor, cause the device to perform: send an event report based on the determination of the occurrence of the event.

12. The device according to claim 1, wherein the determination of the occurrence of the event is based on at least one of the following: the user equipment IP address or MAC address, or the service data flow of the user equipment identified by the user equipment IP address.

13. The device according to claim 1, wherein the determination of the occurrence of the event is based on: the protocol data unit session of the user equipment identified by the user equipment IP address.

14. The device according to claim 1, wherein the user plane header processing instruction includes information indicating that it is applicable to the service in at least one of the uplink direction or the downlink direction.

15. The device according to claim 3, wherein the condition information includes at least one of the following: a first condition when a value is found from the header, or A different second condition when the value is not found in the header.

16. The apparatus according to claim 1, wherein the user plane header processing instruction comprises: Information about a header data injection instruction for sending a report, the report indicating at least a part of a header or headers to be replicated within the event report.

17. The apparatus according to claim 1, wherein the user plane header processing instruction comprises: Information about service encryption.

18. The apparatus according to claim 1, wherein receiving the user plane header processing instruction from the application function comprises: Receiving the user plane header processing instruction from at least one of the following: Essentially directly from the application function, or Indirectly from the application function via the session management function.

19. The apparatus according to claim 18, wherein the at least one memory stores instructions which, when executed with the at least one processor, cause the apparatus to perform at least one of the following: Invoking a new user plane function service, or Subscribing to a new event of the Nupf_EventExposure service, or Determining new packet forwarding control protocol instructions for the apparatus, or Determining extended packet forwarding control protocol instructions for the apparatus.

20. The apparatus according to claim 18, wherein receiving the user plane header processing instruction from the application function comprises: Receiving the user plane header processing instruction from the session management function and including using at least one of the following: The network exposure function, or The policy control function.

21. A method for communication, the method comprising: Receiving a user plane header processing instruction from an application function; And Determining the occurrence of an event at least in part based on the received user plane header processing instruction.

22. The method according to claim 21, comprising: Receiving a signal and causing the determination of the occurrence of the event to be provided.

23. The method according to claim 21, wherein the user plane header processing instruction includes information configured to be used to define at least one of the following: Header information, Action information, or Condition information.

24. A device for communication, the device comprising: Means for receiving a user plane header processing instruction from an application function; And Means for determining the occurrence of an event at least in part based on the received user plane header processing instruction.

25. A program storage device readable by a device, tangibly embodying a program of instructions executable by the device to perform operations, the operations comprising: Receiving a user plane header processing instruction from an application function; And Determining the occurrence of an event at least in part based on the received user plane header processing instruction.

Images