PDU set processing capability indication for XR traffic

By determining the PDU set processing capability of the RAN node in the SMF and sending corresponding instructions to the UPF, the loss of PDU sets and resource waste in wireless communication is solved, and efficient transmission and processing of XR services is achieved.

CN119404589APending Publication Date: 2025-02-07LENOVO (BEIJING) LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202280097530.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2022-07-08
Publication Date
2025-02-07

AI Technical Summary

Technical Problem

The prior art is difficult to effectively deal with the loss of PDU sets in wireless communications and resource waste, especially in XR services. The lost PDU sets cannot be effectively restored by the application layer, resulting in resource waste.

Method used

The transmission and processing of the PDU set is optimized by determining the PDU set processing capability of the RAN node in the SMF and sending a corresponding indication to the UPF, activate or deactivate the PDU set processing.

Benefits of technology

The instructions and optimization of PDU set processing capabilities are realized, resource waste is reduced, and transmission efficiency and quality of XR services are improved.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119404589A_ABST
    Figure CN119404589A_ABST
Patent Text Reader

Abstract

Methods and apparatus for PDU set processing capability indication are disclosed. In one embodiment, a session management function (SMF) includes a processor and a transceiver coupled to the processor, where the processor is configured to determine a PDU set processing capability of a RAN node; and transmitting, via the transceiver to the UPF, an indication to activate or deactivate PDU set processing for the PDU session or QoS flow in accordance with the PDU set processing capability of the RAN node to which the UPF is connected.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The subject matter disclosed herein relates generally to wireless communications, and more particularly to PDU set processing capability indication for XR traffic. Background Art

[0002] The following abbreviations are defined herein, at least some of which are referenced within the following description: New Radio (NR), Very Large Scale Integration (VLSI), Random Access Memory (RAM), Read Only Memory (ROM), Erasable Programmable Read Only Memory (EPROM or Flash Memory), Compact Disc Read Only Memory (CD-ROM), Local Area Network (LAN), Wide Area Network (WAN), User Equipment (UE), Evolved Node B (eNB), Next Generation Node B (gNB), Uplink (UL), Downlink (DL), Central Processing Unit (CPU), Graphics Processing Unit (GPU), Field Programmable Gate Array (FPGA), Orthogonal Frequency Division Multiplexing (OFDM), Radio Resource Control (RRC), User Entity / Device (Mobile Terminal), Extended Reality (XR), Augmented Reality (AR), Virtual Reality (VR), Cloud Gaming (CG), Protocol Data Unit (PDU), XR and Media Services (XRM), Quality of Service (QoS), Application Function (AF), Service Data Flow (SDF), Internet Protocol (IP), User Plane Function (UPF), Intermediate UPF (I-UPF) , Radio Access Network (RAN), PDU Session Anchor (PSA), GPRS Tunneling Protocol User Plane (GTP-U), Packet Flow Description (PFD), Packet Flow Description Function (PFDF), PDU Set Delay Budget (PSDB), PDU Set Error Rate (PSER), Session Management Function (SMF), 5G System (5GS), Policy Control Function (PCF), Network Exposure Function (NEF), Technical Specification (TS), Policy and Charging Control (PCC), Packet Flow Description (PFD), Unified Data Repository (UDR), Operation and Maintenance (OAM), Single Network Slice Selection Assistance Information (S-NSSAI), Data Network Name (DNN), Evolved Universal Terrestrial Radio Access (E-UTRA), Cell Global Identifier (CGI), Access and Mobility Management Function (AMF), Tracking Area Identity (TAI), Network Repository Function (NRF), Access Stratum (AS), Non-Access Stratum (NAS), QoS Flow ID (QFI), Information Element (IE), 5G Core (5GC), Sequence Number (SN), Core Network (CN), Data Network (DN).

[0003] Extended reality (XR), including augmented reality (AR) and virtual reality (VR), as well as cloud gaming (CG), are important media applications for 5G.

[0004] A PDU set consists of one or more PDUs that carry the payload of a unit of information generated at the application layer (e.g., a frame or video slice for an XRM service) that has the same importance requirement at the application layer. The application layer requires all PDUs in a PDU set to use the corresponding unit of information. In some cases, even if some PDUs are being lost, the application layer is still able to recover parts of the information unit.

[0005] For XR and media services, it is proposed to support PDU aggregation, integrated packet processing and differentiated QoS processing.

[0006] PDU set integrated packet processing means that groups of packets belonging to the same PDU set will be processed in an integrated manner. For example, the 5G system may discard some packets but try to deliver other packets of the same PDU set. Due to the discarded packets, other delivered packets may be useless to the client and thus waste radio resources. Therefore, if one or more (e.g., a certain number or a certain proportion) of PDUs in a PDU set have been lost, the remaining PDUs in the PDU set are useless to the application layer and should not be sent over the air interface.

[0007] Differentiated QoS processing is based on the importance of PDU sets. For example, packets (i.e., PDUs) belonging to less important PDU sets can be processed differently to reduce resource waste. For example, if congestion occurs, less important PDU sets can be discarded.

[0008] The present invention is directed to a PDU set processing capability indication. Summary of the invention

[0009] A method and apparatus for PDU set processing capability indication are disclosed.

[0010] In one embodiment, the SMF includes a processor and a transceiver, the transceiver being coupled to the processor, wherein the processor is configured to determine the PDU set processing capability of the RAN node; and to send an indication to the UPF via the transceiver to activate or deactivate PDU set processing for a PDU session or QoS flow based on the PDU set processing capability of the RAN node to which the UPF is connected.

[0011] In some embodiments, PDU set processing includes PDU set identification and GTP-U header marking at the PSA UPF, or GTP-U header marking at an intermediate UPF.

[0012] In some embodiments, the PDU set processing capability of the RAN node is determined based on the ID of the RAN node, the regional information, and at least one of a combination of the DNN and the S-NSSAI.

[0013] In some embodiments, the PDU set processing capability of the RAN node is determined by retrieving the PDU set processing capability of the RAN node from the NRF.

[0014] In some embodiments, the PDU set processing capability of the RAN node is determined by receiving the PDU set processing capability of the RAN node via the transceiver during the PDU session establishment procedure.

[0015] In some embodiments, the PDU set processing capability of the RAN node is determined to not support PDU set integrated packet processing by receiving an indication via the transceiver that an unknown GTP-U extension header was found.

[0016] In some embodiments, the PDU set processing capability of the RAN node is determined by receiving, via the transceiver, the PDU set processing capability of the RAN node included in the path switch request transmission.

[0017] In some embodiments, the RAN node is a target RAN node in a handover and if the processor determines that the PDU set processing capability of the target RAN node is different from the PDU set processing capability of the source RAN node, an indication is sent to the UPF.

[0018] In some embodiments, the PDU set processing capability of the secondary RAN node is determined by receiving the PDU set processing capability of the secondary RAN node from the primary RAN node via the transceiver.

[0019] In some embodiments, the processor is further configured to transmit, via the transceiver, to the RAN node an indication of whether PDU set processing is necessary.

[0020] In another embodiment, the method at the SMF includes determining the PDU set processing capability of the RAN node; and sending an indication to the UPF to activate or deactivate PDU set processing for the PDU session or QoS flow based on the PDU set processing capability of the RAN node to which the UPF is connected.

[0021] In yet another embodiment, a network node (eg, a RAN node) of a network architecture includes: a processor and a transceiver coupled to the processor, wherein the processor is configured to send a PDU set processing capability of the RAN node to a core network node via the transceiver.

[0022] In some embodiments, the PDU set processing capabilities of the RAN node are sent to the SMF via the AMF.

[0023] In some embodiments, the PDU set processing capability of the RAN node is sent in response to a request from the SMF.

[0024] In some embodiments, the PDU set processing capabilities of the RAN node are sent to the UPF or SMF in response to receiving a DL packet containing an unknown new GTP-U extension header.

[0025] In some embodiments, the PDU set processing capability of the RAN node is sent in response to at least one of: receiving XR specific information included in a handover request; receiving an indication to provide PDU set processing capability; and determining that the PDU set processing capability of the RAN node is different from the PDU set processing capability of the source RAN node in the handover.

[0026] In some embodiments, the processor is further configured to send the PDU set processing capability of the secondary RAN node to the core network node via the transceiver.

[0027] In a further embodiment, the method at the RAN node comprises sending the PDU set handling capability of the RAN node to the core network node. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] A more particular description of the embodiments briefly described above will be presented by reference to specific embodiments shown in the accompanying drawings. Understanding that these drawings depict only some embodiments and are therefore not to be considered limiting of scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0029] Figure 1 The first sub-embodiment of the third embodiment is shown;

[0030] Figure 2 The second sub-embodiment of the third embodiment is shown;

[0031] Figure 3 A third sub-embodiment of the third embodiment is shown;

[0032] Figure 4 A fourth sub-embodiment of the third embodiment is shown;

[0033] Figure 5 The first sub-embodiment of the fourth embodiment is shown;

[0034] Figure 6 The second sub-embodiment of the fourth embodiment is shown;

[0035] Figure 7 The first sub-embodiment of the fifth embodiment is shown;

[0036] Figure 8 The second sub-embodiment of the fifth embodiment is shown;

[0037] Fig. 9 The sixth embodiment is shown in FIG.

[0038] Fig.10 is a schematic flow chart illustrating an embodiment of a method;

[0039] Fig.11 is a schematic flow chart illustrating a further embodiment of the method; and

[0040] Fig.12 is a schematic block diagram illustrating another apparatus according to an embodiment. DETAILED DESCRIPTION

[0041] As will be appreciated by those skilled in the art, certain aspects of the embodiments may be embodied as systems, devices, methods, or program products. Thus, the embodiments may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.), or a combination of software and hardware embodiments, which are generally referred to herein as "circuits," "modules," or "systems." In addition, the embodiments may take the form of a program product embodied in one or more computer-readable storage devices storing machine-readable code, computer-readable code, and / or program code (hereinafter referred to as "code"). The storage device may be tangible, non-temporary, and / or non-transmitting. The storage device may not embody a signal. In a certain embodiment, the storage device employs only a signal for accessing the code.

[0042] Certain functional units described in this specification may be labeled as "modules" to more particularly emphasize their independent implementation. For example, a module may be implemented as a hardware circuit including a custom very large scale integration (VLSI) circuit or gate array, an off-the-shelf semiconductor such as a logic chip, a transistor, or other discrete components. A module may also be implemented in a programmable hardware device such as a field programmable gate array, a programmable array logic, a programmable logic device, etc.

[0043] Modules can also be implemented in code and / or software for various types of processors to perform. The identified code module can, for example, include one or more physical or logical blocks of executable code, which can, for example, be organized as objects, processes or functions. However, the executable files of the identified modules do not need to be physically located together, but can include different instructions stored in different locations, which, when logically connected together, include the module and achieve the stated purpose of the module.

[0044] In fact, code modules can include a single instruction or multiple instructions, and can even be distributed on several different code segments, among different programs and across several memory devices. Similarly, operating data can be identified and illustrated in this article within the module, and can be embodied in any suitable form and organized within the data structure of any suitable type. The operating data can be collected as a single data set, or can be distributed in different locations, including being distributed on different computer-readable storage devices. When a module or part of a module is implemented with software, the software portion is stored on one or more computer-readable storage devices.

[0045] Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing code. The storage device may be, for example but not necessarily, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical or semiconductor system, apparatus or device, or any suitable combination of the foregoing.

[0046] A non-exhaustive list of more specific examples of storage devices would include the following: an electrical connection with one or more cables, a portable computer floppy disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0047] The code for performing the operations of the embodiments may include any number of lines and may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, etc., as well as traditional procedural programming languages ​​such as the "C" programming language, etc., and / or machine languages ​​such as assembly language. The code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the last scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0048] References to "one embodiment", "embodiment" or similar language throughout this specification mean that a particular feature, structure or characteristic described in conjunction with the embodiment is included in at least one embodiment. Therefore, unless otherwise expressly specified, the phrases "in one embodiment", "in an embodiment" and similar language throughout this specification may, but not necessarily, all refer to the same embodiment, but rather mean "one or more but not all embodiments". Unless otherwise expressly specified, the terms "include", "comprising", "having" and their variations mean "including but not limited to". Unless otherwise expressly specified, the list of items listed does not mean that any or all items are mutually exclusive. Unless otherwise expressly specified, the terms "one", "an" and "the" also refer to "one or more".

[0049] In addition, the described features, structures or characteristics of various embodiments may be combined in any suitable manner. In the following description, many specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the embodiments. However, those skilled in the relevant art will recognize that the embodiments may be practiced without one or more specific details or using other methods, components, materials, etc. In other cases, well-known structures, materials or operations are not shown or described in detail to avoid any ambiguity in various aspects of the embodiments.

[0050] The various aspects of different embodiments are described below with reference to the schematic flow charts and / or schematic block diagrams of the methods, devices, systems and program products according to the embodiments. It will be understood that each frame of the schematic flow charts and / or schematic block diagrams, and the combination of frames in the schematic flow charts and / or schematic block diagrams can be implemented by code. The code can be provided to a processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine, so that instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions specified in the schematic flow charts and / or schematic block diagrams for one or more frames.

[0051] The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other device to function in a specific manner so that the instructions stored in the storage device produce a product including instructions for implementing the functions specified in the schematic flowchart and / or schematic block diagram.

[0052] The code may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operation steps to be executed on the computer, other programmable apparatus or other device to produce a computer-implemented process, so that the code executed on the computer or other programmable apparatus provides for implementing the flowcharts and / or block diagrams. Figure 1 A procedure that specifies the functions in one or more boxes.

[0053] The schematic flow charts and / or schematic block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, systems, methods, and program products according to various embodiments. In this regard, each box in the schematic flow charts and / or schematic block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions of the code for implementing (one or more) specified logical functions.

[0054] It should also be noted that in some alternative implementations, the functions annotated in the blocks may not occur in the order noted in the drawings. For example, two blocks shown in succession may be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order, depending on the functionality involved. Other steps and methods that are equivalent in function, logic, or effect to one or more blocks or portions thereof of the illustrated drawings may be envisioned.

[0055] Although various arrow types and line types can be adopted in flow chart and / or block diagram, they are understood to not limit the scope of corresponding embodiment.In fact, some arrows or other connectors can be used to indicate only the logical flow of the described embodiment.For example, the waiting or monitoring period of the unspecified duration between the enumeration steps of the described embodiment can be indicated by an arrow.It will be noted that the combination of each frame in the block diagram and / or flow chart and the frame in the block diagram and / or flow chart can be realized by a system based on special hardware or a combination of special hardware and code that performs a specified function or action.

[0056] The description of an element in each figure may refer to an element of a previous figure. Like reference numerals in all figures refer to like elements, including alternative embodiments of the like elements.

[0057] Before describing the process of the present disclosure, an overview of delivery of an XR service is described, which can be a service generated by an XR, CG application, or other types of media applications.

[0058] XR services are initiated by the application server and sent to the UPF, and are delivered through a service data flow (SDF) or an IP packet flow. Each packet is a PDU.

[0059] A PDU session is established between the UPF and the UE. Different QoS flows can exist in the established PDU session. Typically, XR services are delivered in the QoS flow of the PDU session, from the UPF to the RAN node (e.g., NR-RAN node: gNB, or LTE node: eNB) and from the RAN node to the UE. An intermediate UPF (I-UPF) can exist between the UPF (called PSA UPF) and the RAN node.

[0060] PDU aggregation processing at the RAN node means that the RAN node is able to perform PDU aggregation integrated packet processing and differentiated QoS processing.

[0061] In order for the RAN node to perform PDU set processing (i.e., PDU set integrated packet processing and differentiated QoS processing) for a specific service (e.g., XR and media services, which can be referred to as XR services hereinafter), the UPF to which the RAN node is connected needs to perform PDU set identification and marking of the specific service (referred to as PDU set processing at the UPF). This means that the UPF needs to identify the PDUs of a PDU set for which the RAN node performs PDU set processing and mark them for the RAN node. For example, the UPF obtains PDU set related information (e.g., PDU set sequence number, start and / or end indication, PDU sequence number within the PDU set, importance, dependency, etc.) of a specific service (e.g., XR and media services) by reading the RTP and / or SRTP header and / or payload of the PDU set carrying the specific service or based on the implementation, and inserts the obtained PDU set related information into the GTP-U extension header of the N3 interface (i.e., the interface between the RAN node and the UPF) and / or the N9 interface (i.e., the interface between the UPFs). Therefore, PDU set processing at the UPF means PDU set identification and GTP-U header marking performed at the UPF. The RAN node is able to perform PDU set processing (i.e., PDU set integrated packet processing and differentiated QoS processing) on ​​the PDUs, where PDU set related information is included in the GTP-U extended header of each of the PDUs.

[0062] The present disclosure proposes that the AF may indicate whether PDU set processing is necessary for XR services, or whether PDU set processing is unnecessary for XR services. This means that PDU set processing may not be necessary (e.g., by an instruction from the AF, or by default), or PDU set processing may be necessary (e.g., by an instruction from the AF).

[0063] By the way, if the AF provides an indication of whether PDU set processing is necessary, the indication can be associated with at least one of a specific application identifier, a specific flow description, and a specific packet flow description (PFD). For example, a new IE (e.g., an indication of whether PDU set processing is necessary) can be introduced in the AF request. The value of the indication can be "1" (or "true"), which indicates that PDU set processing is necessary, or "0" (or "false"), which indicates that PDU set processing is not necessary. Alternatively, the existing IE "PDU set processing indication" can be reused to indicate whether PDU set processing is necessary. For example, if the PDU set processing indication is included in the AF request, it means that PDU set processing is necessary for the associated service (e.g., XR service); and if the PDU set processing indication is not included in the AF request, it means that PDU set processing is not necessary for the associated service.

[0064] If PDU set processing is not necessary for XR services, XR services can be sent without PDU set processing. In other words, for XR services, it is acceptable for the UPF not to perform PDU set identification and GTP-U header marking, and therefore, the RAN node does not perform PDU set integrated packet processing and differentiated QoS processing.

[0065] On the other hand, if PDU set processing is necessary for XR services, the UPF shall perform PDU set identification and GTP-U header marking (i.e., PDU set processing at the UFP), and the RAN node shall perform PDU set integrated packet processing and differentiated QoS processing (i.e., PDU set processing at the RAN node). However, some RAN nodes may not support PDU set processing. This means that RAN nodes that do not support PDU set processing cannot process XR services for which PDU set processing is necessary.

[0066] RAN nodes that do not support PDU set processing cannot process XR services. On the other hand, if PDU set processing is unnecessary for XR services, RAN nodes that do not support PDU set processing can send XR services without PDU set processing.

[0067] The present disclosure proposes that whether a RAN node supports PDU set processing at the RAN node can be regarded as a capability of the RAN node or a preference of the RAN node (e.g., based on the network load or performance of the RAN node). The PDU set processing capability can be indicated as "true" (or "1"), meaning that PDU set processing is supported, or as "false" (or "0"), meaning that PDU set processing is not supported.

[0068] By the way, the PDU set processing capability can be extended to PDU set processing capability information. The PDU set processing capability information includes the type of PDU set processing (if the PDU set processing capability indicates that the RAN node supports PDU set processing) in addition to the PDU set processing capability (which indicates whether the RAN node supports PDU set processing). The type of PDU set processing can be, for example, 1) packets of one PDU set type in one QoS flow or packets with the same importance value; or 2) packets of more than one PDU set type in one QoS flow or packets with different importance values. It is obvious that the type of PDU set processing can be further indicated only when the PDU set processing capability is "true" (that is, PDU set processing is supported). In the following description, when the PDU set processing capability is indicated as "true", it is assumed that the type of PDU set processing can be further indicated.

[0069] In this disclosure, RAN nodes can be classified into three types.

[0070] Type #1 RAN nodes are not aware of the additional signaling and / or IEs introduced for XR services and therefore do not support PDU set processing at the RAN node. LTE eNB and legacy NR gNB can be examples of Type #1 RAN nodes. Examples of additional signaling and / or IEs are PDU Set Delay Budget (PSDB) and PDU Set Error Rate (PSER) etc. These additional IEs can be considered as unknown IEs for Type #1 RAN nodes. Type #1 RAN nodes can reject or ignore the unknown IEs.

[0071] Type #2 RAN nodes are aware of the additional signaling and / or IEs introduced for XR services, but do not support PDU set processing at the RAN node, or do not want to perform PDU set processing at the RAN node due to network conditions. Type #2 RAN nodes can ignore the additional signaling and / or IEs introduced for XR services. In other words, Type #2 RAN nodes process XR services without PDU set processing (PDU set processing is unnecessary for them).

[0072] Type #3 RAN nodes are aware of the additional signaling and / or IEs introduced for XR services and support PDU set processing at the RAN node.

[0073] It is assumed that the UPF is able to always support PDU set processing at the UPF. This means that the UPF is able to perform PDU set processing at the UPF or not perform PDU set processing at the UPF. If the RAN node to which the UPF is connected supports PDU set processing at the RAN node, the UPF shall perform PDU set processing at the UPF (e.g., PDU set identification and GTP-U header marking). In addition, if the RAN node provides the type of PDU set processing, the SMF notifies the UPF to perform packet detection and forwarding based on the type of PDU set processing. For example, if the RAN node supports type 1) packets of one PDU set type in one QoS flow or packets with the same importance value, the SMF configures the importance value associated with the QFI. That is, the UPF shall read the importance value of the DL packet and mark the packet with the corresponding QFI. In this way, the SMF notifies the RAN node of the mapping relationship between the importance value and the QFI. Then, there is no need to insert the importance value in the extended GTP-U header toward the RAN node. If the RAN node supports type 2) packets of more than one PDU set type in one QoS flow or packets with different importance values, the UPF shall read the importance value of the DL packet and insert the importance value into the extended GTP-U header towards the RAN node. In this way, the RAN node is able to obtain the importance value of the DL packet from the extended GTP-U header. Otherwise (which means that PDU set processing at the RAN node is not supported at the RAN node to which the UPF is connected), the UPF shall not perform PDU set processing at the UPF. In addition, if PDU set processing is necessary for a specific service (e.g., XR service), the RAN node that does not support PDU set processing is not eligible to process the specific service.

[0074] By the way, there may be an intermediate UPF between the RAN node and the UPF (in this case, it is called PSA UPF). If the PSA UPF performs PDU set processing, the intermediate UPF should perform GTP-U header marking; and if the PSA UPF does not perform PDU set processing, GTP-U header marking should not be performed. GTP-U header marking at the intermediate UPF can also be called PDU set processing at the UPF.

[0075] In order to implement adaptive PDU set processing at the UPF (i.e., if the PDU set processing at the RAN node to which the UPF is connected is supported, the UPF performs the PDU set processing at the UPF, and if the PDU set processing at the RAN node to which the UPF is connected is not supported, the UPF does not perform the PDU set processing at the UPF), it is necessary to know whether the RAN node supports PDU set processing (i.e., the PDU set processing capability of the RAN node).

[0076] According to the above classification of RAN nodes, the PDU set processing capability of a Type #1 RAN node or a Type #2 RAN node is "false" (i.e., does not support PDU set processing at the RAN node), while the PDU set processing capability of a Type #3 RAN node is "true" (i.e., supports PDU set processing at the RAN node).

[0077] The UPF obtains the PDU set processing capability of the RAN node from the SMF. This means that the SMF should obtain (or determine) the PDU set processing capability of the RAN node to which the UPF is connected, and inform the UPF to perform or not perform PDU set processing at the UPF.

[0078] The SMF may obtain the PDU set processing capability of the RAN node in various ways and in various situations (or in various use cases).

[0079] First, as mentioned above, the AF can provide an indication of whether PDU set processing is necessary, for example, for XR services. The SMF can know whether PDU set processing is necessary for XR services in one of the following ways:

[0080] Approach #1: The AF provides an indication to the PCF (via the NEF) associated with the flow description based on the procedures of AF sessions with required QoS in TS 23.502 4.15.6.6, or the impact of AF on traffic routing in TS23.502 4.3.6. The PCF will provide the SMF with a PCC rule containing an indication of whether the PDU set processing associated with the service data flow filter (e.g., for XR traffic) is necessary.

[0081] Method #2: The AF provides an indication of whether the PDU set processing associated with the application identifier and PFD is necessary to the NEF (e.g., a PFDF in the NEF, or a NEF having the function of PFD) based on the PFD management procedure in TS 23.502 4.18.2. The NEF stores the indication of whether the PDU set processing associated with the application identifier and PFD is necessary in the UDR. The PCF provides the SMF with the PCC rule with the application identifier. The SMF retrieves the indication and PFD for the application identifier from the UDR via the NEF based on the procedure in TS 23.502 4.18.3.

[0082] The following embodiment describes how the SMF obtains (or determines) the PDU set processing capability of the RAN node. The PDU set processing capability of the RAN node can be "true" (or "1") indicating that the RAN node supports PDU set processing, or can be "false" (or "0") indicating that the RAN node does not support PDU set processing. If the PDU set processing capability of the RAN node is "true", the type of PDU set processing can be further obtained.

[0083] According to a first embodiment, the SMF may be pre-configured (e.g., through OAM) with 1) a mapping of the PDU set processing capability of a RAN node to the RAN node ID of the RAN node, or 2) a mapping of the PDU set processing capability of a RAN node within an area (e.g., a tracking area) to the area information of the area, or 3) a mapping of the PDU set processing capability of a RAN node to a combination of a DNN and an S-NSSAI (e.g., S-NSSAI, or DNN and S-NSSAI). The PDU set processing capability of each RAN node may be pre-configured. The SMF checks whether the RAN node (e.g., a target RAN node in a handover process) supports PDU set processing based on at least one of (a) the RAN node ID, (b) the area information, and (c) the combination of the DNN and the S-NSSAI.

[0084] According to a first example of the first embodiment, the SMF obtains the RAN node ID (e.g., ng-eNB ID or gNB ID) from the user location information provided by the AMF or by the RAN node (e.g., the target RAN node in the case of handover). The user location information includes the E-UTRA CGI for LTE and the NR CGI for NR, which contains the gNB ID in the NR cell identity or the ng-eNB ID in the E-UTRA CGI. The SMF retrieves the PDU set processing capability of the RAN node ID (e.g., ng-eNB ID, gNB ID, etc.) based on the pre-configuration.

[0085] In a second example of the first embodiment, the SMF obtains the DNN and S-NSSAI associated with the XR service from the AMF, and checks whether the RAN node (e.g., the target RAN node in a handover case) supports PDU set processing based on pre-configuration.

[0086] In a third example of the first embodiment, the SMF obtains the TAI from the user location information provided by the AMF or by the RAN node (e.g., the target RAN node in the case of handover). The SMF retrieves the PDU set processing capability of the TAI based on pre-configuration.

[0087] In a first embodiment, the PDU set processing capability of each RAN node is preconfigured in the SMF. The SMF identifies the RAN node (e.g., by at least one of (a) RAN node ID, (b) regional information, and (c) a combination of DNN and S-NSSAI) and retrieves the PDU set processing capability of the RAN node.

[0088] According to a second embodiment, the SMF may retrieve the PDU set handling capabilities of a RAN node (e.g., a target RAN node) from the NRF. It is assumed that the AMF has provided the NRF with a mapping of the PDU set handling capabilities of the RAN nodes to the RAN node IDs of the RAN nodes. This means that the PDU set handling capabilities of each RAN node are maintained in the NRF. For the PDU set handling capabilities of the RAN node, the SMF transmits a request with the RAN node ID of the RAN node to the NRF. The NRF responds with the PDU set handling capabilities of the RAN node.

[0089] According to the third embodiment, the PDU set processing capability of the RAN node can be indicated during the PDU session establishment process.

[0090] According to the first sub-embodiment of the third embodiment, the UE triggers the AMF to provide the PDU set processing capability of the RAN node to the SMF.

[0091] Figure 1 A first sub-embodiment of the third embodiment is shown.

[0092] In optional step 110, the RAN node (e.g., Type #2 RAN node or Type #3 RAN node) provides its PDU set handling capability to the AMF during the NG interface setup procedure. The PDU set handling capability of the RAN node provided to the AMF can be "true" (e.g., provided by a Type #3 RAN node) or "false" (e.g., provided by a Type #2 RAN node). If the RAN node (e.g., Type #1 RAN node) does not provide the PDU set handling capability to the AMF during the NG interface setup procedure, the AMF assumes that the PDU set handling capability of the RAN node is "false".

[0093] In step 120, the UE transmits a NAS message containing a PDU session establishment request and an XR service indication to the AMF via the RAN node. The XR service indication instructs the AMF to provide the PDU set processing capability of the RAN node to the SMF. The XR service indication is a new indication that the service indication added to the routing description associated with the service description for the XR service in the UE routing policy is provided to the lower layer (e.g., the NAS layer in the first sub-embodiment). That is, if the application matches the service descriptor of a specific URSP rule, based on the indication of providing the XR service indication to the lower layer, the URSP processing layer of the UE provides the XR service indication to the lower layer (e.g., the NAS layer).

[0094] The AMF retrieves the PDU set processing capability of the RAN node upon receiving the XR service indication included in step 120. The PDU set processing capability of the RAN node may be provided in step 110, or determined to be "false" if the PDU set processing capability of the RAN node is not received in step 110. In step 130, the AMF provides the PDU session establishment request and the PDU set processing capability of the RAN node to the SMF.

[0095] The PDU session establishment request and the PDU set processing capabilities of the RAN node may be included in a Nsmf_PDUSession_CreateSMContext request or a Nsmf_PDUSession_UpdateSMContext request.

[0096] Steps 120 and 130 correspond to steps 1 and 3 of the PDU session establishment process. Incidentally, step 2 of the PDU session establishment process involves the AMF selecting the SMF, which is irrelevant to the present invention. Steps 4-21 of the PDU session establishment process will follow step 130. The first sub-embodiment improves step 10 of the PDU session establishment process (for example, step 10a is improved, while step 10b remains unchanged). Specifically, the SMF determines an indication of PDU set processing at the UPF for a PDU session (for example, the PDU session only carries XR services) or for a specific QoS flow (for example, when only a specific QoS flow of the PDU session carries XR services) according to the received PDU set processing capability of the RAN node. That is, if the PDU set processing capability of the RAN node is "true", the indication of PDU set processing at the UPF for the PDU session or for a specific QoS flow should be "true", and if the PDU set processing capability of the RAN node is "false", the indication of PDU set processing at the UPF for the PDU session or for a specific QoS flow should be "false". In step 10a of the PDU Session Establishment procedure (i.e. after steps 4-9 of the PDU Session Establishment procedure), an indication of the PDU Set processing at the UPF for the PDU Session or for a particular QoS Flow is provided to the UPF in an N4 Session Establishment or Modification Request. In step 10b of the PDU Session Establishment procedure, the UPF transmits an N4 Session Establishment or Modification Response. Steps 11-21 of the PDU Session Establishment procedure are performed.

[0097] The first sub-embodiment may also improve steps 11-12 of the PDU session establishment process. Specifically, the SMF may optionally include an indication of whether PDU set processing is necessary in the N2 SM information for the RAN node via the AMF.

[0098] According to the second sub-embodiment of the third embodiment, the UE triggers the RAN node to provide the PDU set processing capability of the RAN node to the SMF.

[0099] Figure 2 A second sub-embodiment of the third embodiment is shown.

[0100] In step 210, the UE transmits an RRC message including a PDU session establishment request and an XR service indication to the RAN node. In the second sub-embodiment, the XR service indication is a new indication for providing a service indication to a lower layer (e.g., the AS layer in the second sub-embodiment), which is added to the routing description associated with the service description for the XR service in the UE routing policy.

[0101] In step 220, the RAN node forwards the PDU session establishment request and the PDU set processing capability of the RAN node to the AMF. The PDU set processing capability of the RAN node is provided in response to receiving the XR service indication in step 210.

[0102] In step 230, the AMF provides the SMF with the PDU session establishment request received in step 220 and the PDU set processing capability of the RAN node.

[0103] After that, application and reference Figure 1 The same steps as described above are omitted for detailed description.

[0104] In the first and second sub-embodiments of the third embodiment, it is assumed that the RAN node (e.g., type #2 RAN node or type #3 RAN node) is aware of the new signaling or IE introduced for the XR service. In addition, the RAN node actively notifies the AMF of the PDU set processing capability (e.g., in step 110 or step 220).

[0105] According to the third sub-embodiment of the third embodiment, the SMF checks the PDU set processing capability of the RAN node by itself.

[0106] Figure 3 A third sub-embodiment of the third embodiment is shown.

[0107] In step 310, the UE transmits a NAS message including a PDU session establishment request to the AMF via the RAN node.

[0108] In step 320, the AMF transmits a PDU session establishment request to the SMF.

[0109] In step 330, the SMF determines the PDU set processing capability of the RAN node. For example, the SMF may determine the PDU set processing capability of the RAN node according to the first embodiment or the second embodiment.

[0110] After that, application and reference Figure 1 or Figure 2 The same steps as described above are omitted for detailed description.

[0111] According to a fourth embodiment of the third embodiment, the RAN node responds to the SMF with a PDU set handling indication when the SMF provides XR specific information.

[0112] Figure 4 A fourth sub-embodiment of the third embodiment is shown.

[0113] First, a PDU session establishment procedure (eg, steps 1 to 21 ) is performed.

[0114] Assume that AF provides a PFD for XR service, which contains XR specific information. As long as PCF provides an application identifier in the PCC rule, SMF retrieves PFD from UDR based on the application identifier and identifies XR service based on the XR specific information contained in PFD. Alternatively, AF provides a flow description for XR service, which contains XR specific information. PCF provides PCC rules including flow description to SMF, which contains XR service indication. This means that SMF is able to identify that PDU session is established for XR service.

[0115] In step 410, the SMF transmits N2 SM information to the RAN node via the AMF, which contains XR specific information. The XR specific information indicates that the XR service will be sent in a PDU session or in a specific QoS flow, and requires the RAN node to provide the PDU set processing capability of the RAN node. The N2 SM information is a PDU session resource setup request transport IE included in the PDU session resource request message transmitted from the AMF to the RAN node.

[0116] In step 420, upon receiving the XR specific information, the RAN node (e.g., a Type #2 RAN node or a Type #3 RAN node) transmits a response (e.g., N2 SM information) containing the PDU set processing capabilities of the RAN node. The N2 SM information is a PDU Session Resource Setup Response Transport IE contained in a PDU Session Resource Response message transmitted from the RAN node to the SMF. On the other hand, the Type #1 RAN node cannot recognize the XR specific information contained in the N2 SM information and therefore does not transmit a response. Alternatively, the Type #1 RAN node may transmit a rejection of the N2 SM information (i.e., the PDU Session Resource Setup Response Transport IE) with a cause "Unknown IE".

[0117] Thus, in step 420, the SMF may receive, for example, a response from a type #3 RAN node, the response including the PDU set handling capability of the RAN node as "true", or, for example, a response from a type #2 RAN node, the response including the PDU set handling capability of the RAN node as "false", or no response or, for example, a rejection from a type #1 RAN node. If no response is received or a rejection is received in step 420, the SMF determines that the RAN node does not support PDU set handling, i.e., the PDU set handling capability of the RAN node as "false".

[0118] The SMF determines which steps to perform based on the PDU set processing capabilities of the RAN node and whether PDU set processing is necessary.

[0119] Case 1: The PDU set handling capability of the RAN node is determined to be "false" (e.g., by receiving a response from a type #2 RAN node containing the PDU set handling capability of the RAN node as "false", or by not receiving any response from a type #1 RAN node) (i.e., PDU set handling is not supported), and PDU set handling is necessary (e.g., for XR services). In case 1, steps 4301 and 4401 are performed. If all QoS flows of the PDU session are used for XR services, in step 4301, the SMF triggers the N4 session release procedure to release the PDU session. In step 4401, the SMF notifies the RAN node to release the PDU session. If only some QoS flows in the PDU session are used for XR services, in step 4301, the SMF triggers the N4 session modification procedure to release the QoS flows used for the XR service. In step 4401, the SMF notifies the RAN node to release the QoS flows used for the XR service through a PDU session modification message.

[0120] Case 2: The PDU set handling capability of the RAN node is determined to be "false" (e.g., by receiving a response from a Type #2 RAN node containing the PDU set handling capability of the RAN node as "false", or by not receiving any response from a Type #1 RAN node) (i.e., PDU set handling is not supported), and PDU set handling is not necessary (e.g., for XR services). In Case 2, step 4302 is performed. In step 4302, the SMF triggers the N4 Session Modification Request procedure to deactivate PDU set handling at the UPF, for example, by setting the PDU Set Handling Indication in the N4 Session Modification Request to "false".

[0121] Case 3: The PDU Set Handling capability of the RAN node is determined to be "True" (e.g., by receiving a response from a Type #3 RAN node containing the PDU Set Handling capability of the RAN node as "True") (i.e., PDU Set Handling is supported). In Case 3, step 4303 is performed. In step 4303, the SMF triggers the N4 Session Modification Request procedure to activate PDU Set Handling at the UPF, e.g., by setting the PDU Set Handling Indication in the N4 Session Modification Request to "True".

[0122] Steps 410 , 420 and 4301 as well as 4401 , 4302 or 4303 can be considered as part of the PDU session establishment procedure.

[0123] In the third embodiment, the PDU set processing capability of the RAN node can be indicated during the PDU session establishment process. Alternatively, the PDU set processing capability of the RAN node can be indicated during the PDU session modification process in a manner similar to the first to fourth sub-embodiments of the third embodiment described above.

[0124] According to a fourth embodiment, if the RAN node does not support PDU set processing (i.e., the PDU set processing capability of the RAN node is "false"), the RAN node responds upon receiving an unknown new GTP-U extension header (e.g., PDU set processing for XR services).

[0125] According to a first sub-embodiment of the fourth embodiment, the RAN node informs the UPF that it does not support PDU set processing through the user plane.

[0126] Figure 5 A first sub-embodiment of the fourth embodiment is illustrated.

[0127] The RAN node receives a DL packet in step 510. The RAN node finds that there is a new unknown GTP-U extension header or a new GTP-U extension header with PDU set related information.

[0128] In step 520, the RAN node notifies the UPF that it does not support PDU set handling through the user plane. For example, the RAN node inserts a PDU set handling indication in the GTP-U header of the UL packet, whose value is "0" or "false", which means that the RAN node does not support PDU set handling.

[0129] On receiving the PDU Set Handling indication, the UPF realises that the RAN node does not support PDU Set Handling. If there is no intermediate UPF (which means the UPF is a PSA UPF), the PSA UPF stops the PDU Set identification and GTP-U header marking (i.e. stops the PDU Set Handling at the UPF).

[0130] If the UPF is an intermediate UPF, the intermediate UPF notifies the upstream UPF (e.g., another intermediate UPF, PSA UPF) that the RAN node does not support PDU set processing until the PSA UPF realizes that the RAN node does not support PDU set processing.

[0131] In addition, the UPF (e.g., PSA UPF) informs the SMF that it has stopped PDU set processing for a specific N4 session or for (N4 session, QFI) in step 530. By doing so, the SMF can inform the UPF that restarting the PDU set identification and GTP-U header marking for the new RAN node supporting PDU set processing is possible.

[0132] According to a second sub-embodiment of the fourth embodiment, the RAN node informs the SMF that it does not support PDU set processing through the control plane.

[0133] Figure 6 A second sub-embodiment of the fourth embodiment is shown.

[0134] The RAN node receives a DL packet in step 610. The RAN node finds that there is a new unknown GTP-U extension header or a new GTP-U extension header with PDU set related information.

[0135] In step 620, the RAN node informs the SMF that it does not support PDU set processing through the control plane.

[0136] In step 630, the SMF notifies the UPF (eg, PSA UPF) to stop PDU set processing (ie, PDU set identification and GTP-U header marking).

[0137] According to a fifth embodiment, the PDU set handling capability is indicated during a handover procedure between a source RAN node and a target RAN node.

[0138] Assume that the PDU set processing capability of the source RAN node is different from the PDU set processing capability of the target RAN node. If the PDU set processing capability of the source RAN node is the same as the PDU set processing capability of the target RAN node, then there is no need to change the PDU set processing at the UPF.

[0139] In the first sub-embodiment of the fifth embodiment, it is assumed that the source RAN node (e.g., type #3 RAN node) supports PDU set processing for XR services, while the target RAN node (e.g., type #1 RAN node or type #2 RAN node) does not support PDU set processing for XR services.

[0140] Because the source RAN node supports PDU set processing for XR services, SMF has notified UPF to perform PDU set identification and GTP-U header marking for XR services. By the way, if there is an intermediate UPF, PDU set identification and GTP-U header marking for XR services should be performed at PSA UPF, and GTP-U header marking for XR services should be performed at the intermediate UPF.

[0141] Figure 7 A first sub-embodiment of the fifth embodiment is shown.

[0142] In step 710, the source RAN node transmits a handover request message to the target RAN node via the Xn interface. XR specific information (e.g., PSDB, PSER, etc.) associated with a specific PDU session ID or a specific PDU session ID and a QoS flow identifier (QFI) is included in the handover request message. The handover request message can optionally include any one of the following messages: 1) an indication of whether PDU set processing is necessary for the XR service; 2) the PDU set processing capability of the source RAN node; and (3) an indication that the target RAN node provides the PDU set processing capability of the target RAN node to the SMF.

[0143] In step 720, the target RAN node transmits a handover response message to the source RAN node.

[0144] The Type #1 target RAN node ignores the unknown IE in the Handover Request message. This means that the Type #1 target RAN node has no knowledge of the XR specific information contained in the Handover Request. The Type #1 target RAN node does not include any new indication in the Path Switch Request transmission.

[0145] Type #2 The target RAN node is aware of the XR specific information contained in the handover request and decides whether to include the PDU set handling capability in the path switch request transmission.

[0146] Type #2 The target RAN node may decide to include the PDU set processing capability based on at least one of the following reasons:

[0147] (1) The target RAN node identifies the XR service from the XR specific information associated with a specific PDU Session ID or the PDU Session ID and QFI contained in the handover request.

[0148] (2) The target RAN node receives an indication from the source RAN node to provide PDU set processing capabilities to the 5GC (e.g., to the SMF via the AMF).

[0149] (3) The target RAN node receives the PDU set processing capability of the source RAN node. The target RAN node determines that its PDU set processing capability is different from the PDU set processing capability of the source RAN node.

[0150] In step 730, the target RAN node transmits a path switch request transmission to the SMF via the AMF. The path switch request transmission is included in the path switch request message in the NG interface from the target RAN node to the AMF. Thereafter, it is included in the Nsmf_PDUSession_UpdateSMContext request message from the AMF to the SMF.

[0151] Type #2 The target RAN node transmits a path switch request transmission to the SMF via the AMF, which includes the PDU set processing capabilities of the target RAN node (e.g., "false"). Type #1 The target RAN node transmits a path switch request transmission to the SMF via the AMF, which does not include the PDU set processing capabilities of the target RAN node.

[0152] In step 740, the SMF determines whether the PDU set processing capability has changed from the source RAN node to the target RAN node.

[0153] First, the SMF confirms the existence of a PDU session or QoS flow associated with the XR service by checking the UE context. For a type #1 target RAN node that does not include any new indication (i.e., does not include PDU set processing capability) in the path switch request transmission in step 730, the SMF determines that the type #1 target RAN node does not support PDU set processing. For a type #2 target RAN node, the SMF determines that the target RAN node does not support PDU set processing based on the PDU set processing capability provided in step 730. Alternatively, the SMF may determine the PDU set processing capability of the RAN node on its own, for example, if the PDU set processing capability is not included in the path switch request transmission in step 730. For example, the SMF may determine the PDU set processing capability of the RAN node according to the first embodiment or the second embodiment.

[0154] When the SMF determines that the PDU set processing capability of the target RAN node (i.e., "false") is different from the PDU set processing capability of the source RAN node (i.e., "true"), the SMF determines that the PDU set processing at the UPF should be deactivated. In step 750, the SMF transmits an N4 session modification request including a PDU set processing indication to the UPF (e.g., PSA UPF, intermediate UPF) to which the target RAN node is connected. In a first sub-embodiment of the fifth embodiment, the PDU set processing indication may only indicate that the PDU set processing at the UPF is deactivated for a specific N4 session ID or (N4 session ID, QFI) associated with the XR service. For example, the PDU set processing indication may be "false" or "0". This means that the PDU set identification and GTP-U header marking for a specific N4 session ID should be stopped. The N4 session ID is used between the SMF and the UPF, and has a one-to-one mapping relationship with the PDU session ID used between the SMF and the RAN node (e.g., the target RAN node). The SMF has a mapping between the PDU session ID and the N4 session ID. Alternatively, in order to provide a "false" PDU set processing indication, if no PDU set processing indication is provided in step 750, it means that PDU set processing is not supported.

[0155] In step 760, the UPF responds to the SMF with an N4 session modification response message.

[0156] In step 770, the SMF responds to the target RAN node via the AMF with a Path Switch Request Confirmation transmission. Optionally, the Path Switch Request Confirmation transmission includes an indication of whether PDU set processing is necessary (e.g., not necessary in the first sub-embodiment of the fifth embodiment).

[0157] In the second sub-embodiment of the fifth embodiment, it is assumed that the source RAN node (e.g., type #1 RAN node or type #2 RAN node) does not support PDU set processing for XR services, while the target RAN node (e.g., type #3 RAN node) supports PDU set processing for XR services.

[0158] Because the source RAN node does not support PDU set processing for XR services, the SMF has not yet notified the UPF to perform PDU set identification and GTP-U header marking for XR services. For example, the SMF transmits an indication of PDU set processing associated with N4 session ID or (N4 session ID, QFI) to the UPF, and its value is "0" or "false". Alternatively, the SMF does not transmit an indication of PDU set processing to the UPF.

[0159] Figure 8 A second sub-embodiment of the fifth embodiment is shown.

[0160] In step 810, the source RAN node transmits a handover request message to the target RAN node via the Xn interface. The handover request message transmitted by the type #1 RAN node does not include XR specific information. The handover request message transmitted by the type #2 RAN node may include XR specific information. The handover request message may also optionally include any one of the following messages: (1) an indication of whether PDU set processing is necessary for the XR service; (2) the PDU set processing capability of the source RAN node; and (3) an indication that the target RAN node provides the PDU set processing capability of the target RAN node to the SMF.

[0161] In step 820, the target RAN node transmits a handover response message to the source RAN node.

[0162] In step 830, the target RAN node transmits a path switch request transmission to the SMF via the AMF. If the target RAN node receives XR specific information in step 810, the target RAN node may include its PDU set processing capability in the path switch request transmission, or the target RAN node always includes its PDU set processing capability in the path switch request transmission. If the target RAN node does not receive XR specific information in step 810, the target RAN node may not include its PDU set processing capability in the path switch request transmission. Type #3 The PDU set processing capability of the target RAN node is "true".

[0163] In step 840, the SMF determines whether the PDU set processing capability has changed from the source RAN node to the target RAN node.

[0164] First, the SMF confirms the existence of a PDU Session or QoS Flow associated with the XR service by checking the UE context. If the type #3 target RAN node includes PDU set processing capability in the path switch request transmission, the SMF is able to make a decision based on the PDU set processing capability included in the path switch request transmission (i.e., "true"). If the type #3 target RAN node does not include PDU set processing capability in the path switch request transmission, the SMF can request the target RAN node to provide its PDU set processing capability. Therefore, the target RAN node responds with its PDU set processing capability. New SMF-related IEs between the SMF and the RAN node can be designed for the request and response of PDU set processing capability. Alternatively, existing IEs between the SMF and the RAN node can be reused.

[0165] When the SMF determines that the PDU set processing capability of the target RAN node (i.e., "true") is different from the PDU set processing capability of the source RAN node (i.e., "false"), the SMF determines that the PDU set processing at the UPF should be activated. In step 850, the SMF transmits an N4 session modification request including a PDU set processing indication to the UPF to which the target RAN node is connected (e.g., PSA UPF, intermediate UPF). In the second sub-embodiment of the fifth embodiment, the PDU set processing indication may only indicate that the PDU set processing at the UPF is activated for a specific N4 session ID or (N4 session ID, QFI) associated with the XR service. For example, the PDU set processing indication may be "true" or "1". This means that PDU set identification and GTP-U header marking for a specific N4 session ID or (N4 session ID, QFI) should be performed. Alternatively, if the type of PDU set processing is provided together with the PDU set processing capability, the SMF may also notify the UPF to map different types of PDU sets of an application to different QoS flows, or to map all types of PDU sets of an application to one QoS flow based on the type of PDU set processing.

[0166] In step 860, the UPF responds to the SMF with an N4 session modification response message.

[0167] In step 870, the SMF responds to the target RAN node via the AMF with a Path Switch Request Confirmation transmission. Optionally, the Path Switch Request Confirmation transmission includes an indication of whether PDU set processing is necessary (e.g., not necessary in the second sub-embodiment of the fifth embodiment).

[0168] According to the sixth embodiment, in the DC case, the PDU set processing capability is indicated when the PDU session is separated at the UPF.

[0169] Dual Connectivity (DC) is defined in TS 37.340. The UE is connected to one RAN node, which is called the Primary Node (MN). The MN is a radio access node that provides a control plane connection to the core network. The UE is also connected to another RAN node, which is called the Secondary Node (SN). The SN does not have a control plane connection to the core network. The UPF can split the PDU session between the MN and the SN. This means that some QoS flows of the PDU session are transferred to the MN, while other QoS flows of the PDU session are transferred to the SN.

[0170] For example, there are three QoS flows for a PDU session for an XR service. First, all QoS flows are sent to the MN. It is assumed that the MN supports PDU set integrated packet processing. Therefore, the SMF notifies the UPF to activate PDU set processing for all three QoS flows at the UPF. Assume that the MN decides to separate the PDU session at the UPF. For example, some QoS flows (e.g., 2 QoS flows) of the PDU session are transmitted to the MN, while other QoS flows (e.g., 1 QoS flow) are transmitted from the UPF to the SN. The first tunnel is between the UPF and the MN, and the second tunnel is between the UPF and the SN. If the PDU set processing capability of the SN is different from the PDU set processing capability of the MN (assuming that the MN and the SN exchange their PDU set processing capabilities during the Xn setup or SN addition process), it is necessary for the MN to notify the core network (e.g., SMF) that the SN does not support PDU set integrated packet processing.

[0171] Fig. 9 A sixth embodiment is shown in the drawings.

[0172] In step 910, the MN provides the SMF with the PDU set processing capability for each tunnel of the PDU session. For example, when determining the PDU session separation, the MN provides the PDU set processing capability associated with the DL TNL and the PDU set processing capability associated with the additional DL TNL in addition to the PDU session ID, (DL TNL, associated QoS flow) and (additional DL TNL, associated QoS flow).

[0173] Alternatively, if it is assumed that the core network (e.g., SMF) already knows the PDU set processing capability of the MN (e.g., according to any one of the first to fifth embodiments described above), when determining PDU session separation, if the PDU set processing capability of the SN (i.e., associated with the additional DL TNL) is different from the PDU set processing capability of the MN (i.e., associated with the DL TNL), the MN only provides the PDU set processing capability associated with the additional DL TNL.

[0174] For example, PDU set handling capability can be added to the QoS flow of each TNL information defined in TS 38.413 9.3.2.8. The PDU set handling capability can be in the form of "0" (or "false") indicating "PDU set handling is not supported" or "1" (or "true") indicating "PDU set handling is supported".

[0175] IE / Group Name exist scope IE Types and References Semantic Description UP transport layer information M 9.3.2.2 List of associated QoS flows M 9.3.1.99 PDU set processing capability O "0" or "false" means that PDU set processing is not supported, "1" or "true" means that PDU set processing is supported.

[0176] Table 1: QoS flow per TNL information

[0177] In addition to always including the PDU Set Handling Capability, if the PDU Set Handling Capability is included, it means that PDU Set Handling at the RAN node will be performed for the associated QoS Flow. Otherwise (if the PDU Set Handling Capability is not included), it means that PDU Set Handling will not be performed for the associated QoS Flow.

[0178] The QoS flow for each TNL information of the two tunnels may be included in the PDU session resource modification indication, or the PDU session resource setup response or the PDU session resource modification response from the MN to the SMF.

[0179] In step 920, the SMF notifies the UPF to activate or deactivate the PDU set processing for a specific QoS flow of the N4 session by triggering the N4 session establishment or modification procedure. Assuming that the MN decides to offload QoS flow #3 to the SN, the SMF knows from step 910 that the PDU set processing at the SN will not be performed for QoS flow #3. Therefore, the SMF notifies the UPF to stop the PDU set processing for QFI=3 of the N4 session.

[0180] In step 930, the UPF responds with an N4 Session Establishment or Modification Response.

[0181] Fig.10 1 is a schematic flow chart illustrating an embodiment of a method 1000 according to the present application. In some embodiments, the method 1000 is performed by a network function such as an SMF or a network function having an SMF. In some embodiments, the method 1000 can be performed by a processor that executes program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, etc.

[0182] Method 1000 may include: 1002 determining the PDU set processing capability of the RAN node; and 1004 sending an indication to the UPF to activate or deactivate PDU set processing for a PDU session or QoS flow based on the PDU set processing capability of the RAN node to which the UPF is connected.

[0183] In some embodiments, PDU set processing includes PDU set identification and GTP-U header marking at the PSA UPF, or GTP-U header marking at an intermediate UPF.

[0184] In some embodiments, the PDU set processing capability of the RAN node is determined based on the ID of the RAN node, the regional information, and at least one of a combination of the DNN and the S-NSSAI.

[0185] In some embodiments, the PDU set processing capability of the RAN node is determined by retrieving the PDU set processing capability of the RAN node from the NRF.

[0186] In some embodiments, the PDU set handling capability of the RAN node is determined by receiving the PDU set handling capability of the RAN node during a PDU session establishment procedure.

[0187] In some embodiments, the PDU set processing capability of the RAN node is determined to not support PDU set packet processing by receiving an indication that an unknown GTP-U extension header was found.

[0188] In some embodiments, the PDU set processing capability of the RAN node is determined by receiving the PDU set processing capability of the RAN node included in the path switch request transmission.

[0189] In some embodiments, the RAN node is a target RAN node in a handover and if it is determined that the PDU set handling capability of the target RAN node is different from the PDU set handling capability of the source RAN node, an indication of this is sent to the UPF.

[0190] In some embodiments, the PDU set processing capability of the secondary RAN node is determined by receiving the PDU set processing capability of the secondary RAN node from the primary RAN node.

[0191] In some embodiments, the method further comprises transmitting to the RAN node an indication whether PDU set processing is necessary.

[0192] Fig.11 1 is a schematic flow chart illustrating an embodiment of a method 1100 according to the present application. In some embodiments, the method 1100 is performed by a network node such as a RAN node (e.g., an NG-RAN node). In some embodiments, the method 1100 may be performed by a processor that executes program code, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, etc.

[0193] The method 1100 may include sending 1102 a PDU set processing capability of the RAN node to a core network node.

[0194] In some embodiments, the PDU set processing capabilities of the RAN node are sent to the SMF via the AMF.

[0195] In some embodiments, the PDU set processing capability of the RAN node is sent in response to a request from the SMF.

[0196] In some embodiments, the PDU set processing capabilities of the RAN node are sent to the UPF or SMF in response to receiving a DL packet containing an unknown new GTP-U extension header.

[0197] In some embodiments, the PDU set processing capability of the RAN node is sent in response to at least one of: receiving XR-specific information contained in a handover request; receiving an indication to provide PDU set processing capability; and determining that the PDU set processing capability of the RAN node is different from the PDU set processing capability of the source RAN node in the handover.

[0198] In some embodiments, the method further comprises: sending the PDU set processing capability of the secondary RAN node to the core network node.

[0199] Fig.12 is a schematic block diagram illustrating an apparatus according to one embodiment.

[0200] A network function or a network node or a network entity (e.g., an SMF or a RAN node) includes a processor, a memory, and a transceiver. Processor implementation Fig.10 or the functions, processes and / or methods set forth in 11.

[0201] The SMF includes a processor and a transceiver coupled to the processor, wherein the processor is configured to determine the PDU set processing capability of the RAN node; and send an indication to the UPF via the transceiver to activate or deactivate PDU set processing for a PDU session or QoS flow based on the PDU set processing capability of the RAN node to which the UPF is connected.

[0202] In some embodiments, PDU set processing includes PDU set identification and GTP-U header marking at the PSA UPF, or GTP-U header marking at an intermediate UPF.

[0203] In some embodiments, the PDU set processing capability of the RAN node is determined based on the ID of the RAN node, the regional information, and at least one of a combination of the DNN and the S-NSSAI.

[0204] In some embodiments, the PDU set processing capability of the RAN node is determined by retrieving the PDU set processing capability of the RAN node from the NRF.

[0205] In some embodiments, the PDU set processing capability of the RAN node is determined by receiving the PDU set processing capability of the RAN node via the transceiver during the PDU session establishment procedure.

[0206] In some embodiments, the PDU set processing capability of the RAN node is determined to not support PDU set integrated packet processing by receiving an indication via the transceiver that an unknown GTP-U extension header was found.

[0207] In some embodiments, the PDU set processing capability of the RAN node is determined by receiving, via the transceiver, the PDU set processing capability of the RAN node included in the path switch request transmission.

[0208] In some embodiments, the RAN node is a target RAN node in a handover and if the processor determines that the PDU set processing capability of the target RAN node is different from the PDU set processing capability of the source RAN node, an indication is sent to the UPF.

[0209] In some embodiments, the PDU set processing capability of the secondary RAN node is determined by receiving the PDU set processing capability of the secondary RAN node from the primary RAN node via the transceiver.

[0210] In some embodiments, the processor is further configured to transmit, via the transceiver, to the RAN node an indication of whether PDU set processing is necessary.

[0211] The RAN node comprises a processor and a transceiver coupled to the processor, wherein the processor is configured to send a PDU set processing capability of the RAN node to a core network node via the transceiver.

[0212] In some embodiments, the PDU set processing capabilities of the RAN node are sent to the SMF via the AMF.

[0213] In some embodiments, the PDU set processing capability of the RAN node is sent in response to a request from the SMF.

[0214] In some embodiments, the PDU set processing capabilities of the RAN node are sent to the UPF or SMF in response to receiving a DL packet containing an unknown new GTP-U extension header.

[0215] In some embodiments, the PDU set processing capability of the RAN node is sent in response to at least one of: receiving XR-specific information included in a handover request; receiving an indication to provide PDU set processing capability; and determining that the PDU set processing capability of the RAN node is different from the PDU set processing capability of the source RAN node in the handover.

[0216] In some embodiments, the processor is further configured to send the PDU set processing capability of the secondary RAN node to the core network node via the transceiver.

[0217] The radio interface protocol layer can be implemented by a processor. The memory is connected to the processor to store various information for driving the processor. The transceiver is connected to the processor to send and / or receive messages or information. Needless to say, the transceiver can be implemented as a transmitter for sending information and a receiver for receiving information.

[0218] The memory may be located inside or outside the processor and connected to the processor through various well-known means.

[0219] In the above-described embodiments, the components and features of the embodiments are combined in a predetermined form. Unless otherwise clearly stated, each component or feature should be considered as an option. Each component or feature can be implemented as not being associated with other components or features. Further, the embodiment can be configured by associating some components and / or features. The order of the operations described in the embodiment can be changed. Some components or features of any embodiment can be included in another embodiment or replaced with components and features corresponding to another embodiment. It is obvious that claims that are not clearly cited in the claims are combined to form embodiments or are included in new claims.

[0220] The embodiments may be implemented by hardware, firmware, software or a combination thereof. In the case of hardware implementation, the exemplary embodiments described herein may be implemented using one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, etc., according to the hardware implementation.

[0221] Embodiments may be practiced in other specific forms. The described embodiments will be considered in all respects to be illustrative only and not restrictive. Therefore, the scope of the present invention is indicated by the appended claims rather than by the foregoing description. All changes within the meaning and scope of the equivalents of the claims are encompassed within their scope.

Claims

1. A session management function (SMF) of a network architecture, comprising: processor; as well as a transceiver coupled to the processor, Wherein, the processor is configured to determining the protocol data unit (PDU) set processing capabilities of a radio access network (RAN) node; and An indication is sent to a user plane function (UPF) via the transceiver to activate or deactivate PDU set processing for a PDU session or quality of service (QoS) flow according to the PDU set processing capability of the RAN node to which the UPF is connected.

2. The SMF according to claim 1, wherein: The PDU set processing includes PDU set identification and GPRS Tunneling Protocol User Plane (GTP-U) header marking at the PDU Session Anchor (PSA) UPF, or GTP-U header marking at the intermediate UPF.

3. The SMF according to claim 1, wherein: The PDU set processing capability of the RAN node is determined based on an ID of the RAN node, regional information, and at least one of a combination of a data network name (DNN) and single network slice selection assistance information (S-NSSAI).

4. The SMF according to claim 1, wherein: The PDU set handling capability of the RAN node is determined by retrieving the PDU set handling capability of the RAN node from a Network Repository Function (NRF).

5. The SMF according to claim 1, wherein: The PDU set processing capability of the RAN node is determined by receiving the PDU set processing capability of the RAN node via the transceiver during a PDU session establishment procedure.

6. The SMF according to claim 1, wherein: The PDU aggregation processing capability of the RAN node is determined to not support PDU aggregation packet processing by receiving, via the transceiver, an indication that an unknown GTP-U extension header is found.

7. The SMF according to claim 1, wherein: The PDU set processing capability of the RAN node is determined by receiving, via the transceiver, the PDU set processing capability of the RAN node included in a path switch request transmission.

8. The SMF of claim 1, wherein: The RAN node is a target RAN node in a handover, and If the processor determines that the PDU set processing capability of the target RAN node is different from the PDU set processing capability of the source RAN node, the indication is sent to the UPF.

9. The SMF of claim 1, wherein: The PDU set processing capability of the secondary RAN node is determined by receiving the PDU set processing capability of the secondary RAN node from the primary RAN node via the transceiver.

10. The SMF of claim 1, wherein: The processor is further configured to transmit, via the transceiver, to the RAN node an indication of whether PDU set processing is necessary.

11. A method performed at a session management function (SMF), comprising: Determine the protocol data unit (PDU) set processing capabilities of the Radio Access Network (RAN) nodes; as well as An indication is sent to a user plane function (UPF) to activate or deactivate PDU set handling for a PDU session or a quality of service (QoS) flow according to the PDU set handling capability of the RAN node to which the UPF is connected.

12. A radio access network (RAN) node of a network architecture, comprising: processor; as well as a transceiver coupled to the processor, Wherein, the processor is configured to A protocol data unit (PDU) set processing capability of the RAN node is sent to a core network node via the transceiver.

13. The RAN node according to claim 12, wherein: The PDU set handling capabilities of the RAN node are sent to a Session Management Function (SMF) via an Access and Mobility Management Function (AMF).

14. The RAN node according to claim 12, wherein: The PDU set processing capability of the RAN node is sent in response to a request from the SMF.

15. The RAN node according to claim 12, wherein: sending the PDU set processing capability of the RAN node in response to at least one of: Receive XR-specific information included in the handoff request; receiving an indication of providing a PDU set processing capability; as well as It is determined that the PDU set processing capability of the RAN node is different from the PDU set processing capability of a source RAN node in handover.