Quality of service flow model for low latency services

Abstract

An entity in a core network (CN) of a wireless communication system receives quality of service (QoS) parameters related to processing of traffic based on a protocol data unit (PDU) set (1602); performing QoS binding of the service data stream to a QoS stream for a certain media type using the QoS parameters (1604); generating a QoS profile associated with a QoS flow identifier (QFI) of the QoS flow; and transmitting the QoS profile to a Radio Access Network (RAN) via which the UE accesses the CN (1606).

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority and the benefit of U.S. Provisional Patent Application No. 63 / 382,450, filed on November 4, 2022, titled "Framework of QoS Flow Model for XR and Media Services", and U.S. Provisional Patent Application No. 63 / 480,096, filed on January 16, 2023, titled "Framework of QoS Flow Moel for XR and Media Services". The entire contents of these provisional applications are hereby incorporated by reference in their entirety. Field of the Invention

[0003] The present disclosure generally relates to wireless communication and, more particularly, to supporting traffic organized as a set of packet data units (PDUs). Background Art

[0004] This background description is provided for the purpose of generally presenting the background of the present disclosure. The work of the currently named inventors (to the extent it is described in this background section) and aspects of this description that may not be prior art at the time of filing are neither expressly nor implicitly admitted to be prior art of the present disclosure.

[0005] Base stations operating according to Fifth - Generation (5G) New Radio (NR) requirements support much larger bandwidths than Fourth - Generation (4G) base stations. In some cases, a base station may transmit data associated with extended reality (XR) to a user device or user equipment (UE), where extended reality refers to technologies such as augmented reality (AR), virtual reality (VR), mixed reality (MR), and cloud gaming. These technologies generally involve quasi - periodic streaming and are associated with high data rate and low latency requirements.

[0006] The 3rd Generation Partnership Project has recently proposed to study the support for extended reality and media (XRM) to provide 5G System (5GS) support for advanced media services such as high - data - rate low - latency (HDRLL) services, AR / VR / XR services, and tactile / multimodal communication services. More specifically, the goals include enhancing network openness to support the interaction between 5GS and XRM applications, and enhancing the quality of service (QoS) and policies for XR service and media service transmission.

[0007] When supporting XR communication (or more generally, data-intensive services), an application executed on a user equipment (UE) can receive or initiate a data burst, which can be understood as a plurality of units (PDUs) transmitted within a relatively short time period. A data burst can include one or more PDU sets. Generally speaking, a PDU set includes one or more PDUs carrying the payload of an information unit generated at the application level (e.g., a frame or a video slice for an XR service, etc.). The PDUs in a PDU set also correspond to a certain QoS flow.

[0008] To support XRM services for PDU set-based processing in 5GS, a radio access network (RAN), such as a next-generation RAN (NG-RAN), must know the XRM services provided by the 5G core network (CN). The RAN receives PDU set QoS parameters in a QoS profile from a session management function (SMF) via an access and mobility management function (AMF) and through an N2 interface. The RAN further receives PDU set information received for downlink XRM traffic from a user plane function (UPF) via an N3 interface, or PDU set information for uplink XRM traffic from the UE via a Uu interface. The RAN must use the received PDU set QoS parameters and the PDU set information included in the PDUs received from the UPF via the user plane N3 interface to perform PDU set-based QoS processing for radio resource scheduling. More specifically, the PDU set information can reside in the general packet radio service (GPRS) tunneling protocol (GTP)-U header information of the PDU.

[0009] Currently, the 5G CN provides a QoS profile including QoS parameters and a QoS flow ID (QFI) to the RAN during a PDU session establishment / modification procedure. Based on the QoS profile of multiple QoS flows, the RAN can determine and perform the mapping of one or more QoS flows to data radio bearers (DRBs). Therefore, the RAN can provide a certain degree of flexibility for radio resource management by multiplexing multiple QoS flows with similar QoS requirements for one DRB.

[0010] The prior art is based on certain assumptions regarding QoS flows, types of PDU sets, DRBs, and QoS parameters (see Figures 6A to 6D discussed below), which may not always result in efficient handling of traffic.

[0011] The existing QoS model in 5GS operates between the UE and the PSA (PDU Session Anchor) UPF. 5GS, which includes 5G CM, RAN, and UE, can support PDUs on a per-PDU set basis by considering the application traffic information in the Real-time Transport Protocol (RTP) / Secure RTP (SRTP) extension headers. To enable QoS handling on a per-PDU set basis, the per-PDU set QoS model will need to address at least the following issues.

[0012] For per-PDU set QoS flows, it is not clear what granularity of QoS parameters is required for per-PDU set QoS flows belonging to the same media stream. The RAN currently cannot schedule radio resources and handle per-PDU set QoS flows based on aggregated QoS flows and on a per-QoS flow basis.

[0013] Furthermore, it is not clear what information the Application Server (AS) can signal to the 5G CN via the user plane and / or via the control plane. On the one hand, application layer information may not directly map to the QoS characteristics of PDUs in the transport layer and radio resource units in the radio network layer. On the other hand, even for the same media code, the application implementation may differ in some configurable settings between the AS and the application client on the UE. In the case where more advanced media codecs become available and applicable to per-PDU set processing in 5GS, there is no framework for providing additional information.

[0014] Still further, it is not clear how the 5G CN should bind service data flows (e.g., service data flows corresponding to IP 5-tuple flows) to one or more QoS flows and / or sub-QoS flows with a higher granularity based on the per-PDU set information from the AS.

[0015] Moreover, it is not clear what information in the QoS profile the 5G CN can provide to the RAN via the N2 interface.

[0016] In addition, it is still not clear what per-PDU set information the UPF can apply or deliver to the RAN, and how the RAN can enforce the QoS parameters of one or more QoS flows belonging to the same or different IP flows to schedule data radio bearers (DRBs) on a per-PDU set basis. Summary of the Invention

[0017] An example embodiment of the technology disclosed herein is a method in a core network (CN) of a wireless communication system, the method comprising: receiving quality of service (QoS) parameters related to the handling of a set of protocol data units (PDUs) for traffic; using the QoS parameters to perform QoS binding of service data flows (SDFs) to at least one QoS flow of a certain media type; generating a QoS profile associated with a QoS flow identifier (QFI) of the QoS flow of the media type; and transmitting the QoS profile to a radio access network (RAN) via which a UE accesses the CN.

[0018] Another example embodiment of these technologies is an apparatus comprising processing hardware and configured to implement the above method. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 is a block diagram of an example wireless communication system such as 5GS that uses the technology disclosed herein to support PDU set handling in the uplink direction;

[0020] Figure 2 is Figure 1 the UE of which can be based on an example protocol stack of its communication with the Figure 1 RAN;

[0021] Figure 3 is a service-based 5GS architecture representation, including the overall non-roaming reference architecture of the policy and charging control framework of 5GS;

[0022] Figure 4 is a reference point-based 5GS architecture representation, including the overall non-roaming reference architecture of the policy and charging control framework of 5GS;

[0023] Figure 5 is a high-level messaging diagram of an example scenario in which a UE uses an XRM service that utilizes PDU set handling;

[0024] Figure 6A shows the existing one-to-one mapping between PDU sets and QoS flows in the non-access stratum (NAS), and the one-to-one mapping between QoS flows and data radio bearers (DRBs) at an application server (AS);

[0025] Figure 6B shows the existing one-to-one mapping between PDU sets and QoS flows in the NAS, and the possible multiplexing of QoS flows at the AS;

[0026] Figure 6C shows the existing possible multiplexing of PDU sets in one QoS flow in the NAS, and the one-to-one mapping between QoS flows and DRBs at the AS;

[0027] Figure 6D Shows the existing possible multiplexing of PDU sets in a QoS flow in the NAS, and the demultiplexing of various types of PDU sets from the QoS flow to multiple DRBs at the AS;

[0028] Figure 7 Shows a QoS model in which the traffic of a specific media type corresponds to a certain IP flow;

[0029] Figure 8 Is an example scenario of message passing for QoS provisioning using a QoS model such as Figure 7 ;

[0030] Figure 9 Shows the QoS model according to which the application layer uses different IP flows for different PDU set types of the media stream;

[0031] Figure 10 Shows the QoS model according to which the application layer uses the same IP flow for different PDU set types of the media stream and the SMF binds one SDF to multiple QoS flows for different PDU set types;

[0032] Figure 11A Shows the QoS model according to which the application layer uses the same IP flow for different PDU set types of the media stream and the SMF binds one SDF to one QoS flow having multiple sub-QoS flows for different PDU set types;

[0033] Figure 11B Shows a QoS model similar to Figure 11A but in which the UPF identifies each sub-QoS flow based on the detected packet header information;

[0034] Figure 12 Is a flowchart of an example method for generating a PDU set configuration at the AS or AF;

[0035] Figure 13 Is a flowchart of an example method for processing a PS importance configuration policy at the SMF;

[0036] Figure 14 Is a flowchart of an example method that can be implemented in the SMF for generating an N4 message for the UPF;

[0037] Figure 15 Is a flowchart of an example method that can also be implemented in the SMF for providing QoS rules to the UE; and

[0038] Figure 16 Is a flowchart of an example method that can be implemented in the SMF for supporting PDU set-based QoS flows. Detailed implementation manners

[0039] The apparatuses and logical entities discussed below improve the existing end-to-end QoS flow model to efficiently adapt to the XRM service based on PDU set QoS parameters and PDU set identification information.

[0040] More specifically, the solutions discussed below include a reference QoS model for QoS provisioning between a UE and a PSA UPF. According to one implementation of the reference QoS model, the traffic of a specific media type with a certain QoS requirement corresponds to an IP flow. According to another implementation of the reference QoS model, the application layer uses different IP flows for different PDU set types (e.g., I / P / B frames or slices of a video stream) of a media stream. According to yet another implementation of the reference QoS model, the application layer uses the same IP flow for different PDU set types (e.g., I / P / B frames or slices) of a media stream, and the session management function (SMF) binds a service data flow (SDF) to multiple QoS flows for different PDU set types. In yet another implementation, the application layer uses the same IP flow for different PDU set types (e.g., I / P / B frames or slices) of a media stream, and the SMF binds an SDF to a QoS flow with multiple sub-QoS flows for different PDU set types.

[0041] In some implementations, a network node may characterize each sub-QoS flow based on information detected by the UPF from a higher layer of a packet header, by PDU set type, PDU set importance level, or both. For example, for an RTP / SRTP-based media stream, the characterization may be based on bits included in an existing RTP / SRTP extension header or a new extension header; for a slice-based media stream, the characterization may be based on NAL bits in a network abstraction layer header.

[0042] First, referring to Figure 1 , the exemplary wireless communication system 100 may implement one or more of the techniques of the present disclosure for supporting PDU set-based processing of traffic, particularly uplink traffic from a UE. The exemplary wireless communication system 100 includes UEs 102A and 102B, base stations (BSs) 104, 106, and a core network (CN) 110 such as a fifth generation (5G) core (5GC). The base stations 104 and 106 may operate in a radio access network (RAN) 105 connected to the CN 110. The CN 110 may also be implemented as a sixth generation (6G) core or another suitable core network.

[0043] Base station 104 covers cell 124, and base station 106 covers cell 126. If base station 104 is a gNB, then cell 124 is an NR cell. If base station 124 is an ng-eNB, then cell 124 is an Evolved Universal Terrestrial Radio Access (E-UTRA) cell. Similarly, if base station 106 is a gNB, then cell 126 is an NR cell, and if base station 126 is an ng-eNB, then cell 126 is an E-UTRA cell. Cells 124 and 126 may be located in the same Radio Access Network Notification Area (RNA) or different RNAs. Cells 124 and 126 may partially overlap such that UE 102A or 102B may select, reselect, or handover from one of cells 124 and 126 to the other. In general, RAN 105 may include any number of base stations, and each of the base stations may cover one, two, three, or any other suitable number of cells. UE 102 may support at least the 5G NR (or simply "NR") air interface to communicate with base stations 104 and 106. Each of base stations 104 and 106 may be connected to CN 110 via an interface (e.g., S1 or NG interface). Base stations 104 and 106 may also be interconnected via an interface for interconnecting NGRAN nodes (e.g., X2 or Xn interface).

[0044] Reference is made below to Figure 3 and Figure 4 which discusses several NFs that make up CN 110. One or more NFs of CN 110 implement a PDU set controller 112 that determines how and when to provide UE 102A and 102B with information related to PDU set-based handling of the uplink.

[0045] Although Figure 1 not shown for the sake of clutter, CN 110 may include processing hardware that may include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions executed by the one or more general-purpose processors. Additionally or alternatively, the processing hardware may include a dedicated processing unit. The processing hardware may be configured to implement the techniques of the present disclosure to enable 5GS support for advanced media services.

[0046] Base station 104 is equipped with processing hardware that may include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory (not shown) storing instructions executed by the one or more general-purpose processors. Additionally or alternatively, the processing hardware may include a dedicated processing unit.

[0047] UE 102A is equipped with processing hardware 130A, which may include one or more general-purpose processors such as a CPU, and a non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or a dedicated processing unit. UE 102A also includes a transceiver 132A to communicate with the RAN 105 via a radio interface. Further, UE 102A includes a memory 134A storing a PDU set controller 140A. An example application 142 may use the PDU set controller 140A to operate on the PDU set. For example, the application 142 may set the RTP header to utilize PDU set-based processing. UE 102B may have a similar implementation.

[0048] Figure 2 An example protocol stack 200 is shown in a simplified manner, according to which the UE 102 may communicate with an eNB / ng-eNB or a gNB (e.g., one or more of base stations 104, 106). In the example stack 200, the physical layer (PHY) 202A of EUTRA provides a transport channel to the EUTRA MAC sublayer 204A, which in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides an RLC channel to the EUTRA PDCP sublayer 208 and in some cases to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides a transport channel to the NR MAC sublayer 204B, which in turn provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides a data transfer service to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn may provide a data transfer service to the service data adaptation protocol (SDAP) 212 or the radio resource control (RRC) sublayer ( Figure 2 not shown in the figure). In some implementations, the UE102 supports both the EUTRA and NR stacks as Figure 2 shown, to support handover between EUTRA and NR base stations and / or to support DC via EUTRA and NR interfaces. Further, as Figure 2 shown, the UE 102 may support the layering of NR PDCP 210 on EUTRA RLC 206A, and the layering of the SDAP sublayer 212 on the NR PDCP sublayer 210.

[0049] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets that may be referred to as service data units (SDUs) (e.g., from an Internet Protocol (IP) layer that is directly or indirectly layered on the PDCP layer 208 or 210), and output packets that may be referred to as protocol data units (PDUs) (e.g., output to the RLC layer 206A or 206B). Except where the differences between SDUs and PDUs are relevant, for simplicity, this disclosure refers to both SDUs and PDUs as "packets".

[0050] For example, on the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide signaling radio bearers (SRBs) or an RRC sublayer ( Figure 2 not shown in figure) to exchange RRC messages or non-access stratum (NAS) messages. On the user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide data radio bearers (DRBs) to support data exchange. Data exchanged on the NR PDCP sublayer 210 may be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0051] Figure 3 is Figure 1 The service-based 5GS architecture representation 300 that a system can implement. In the representation 300, the overall non-roaming reference architecture of the policy and charging control (PCC) framework of 5GS includes components shown using solid lines, and other components are shown using dashed lines. According to this representation, a network function enables other authorized network functions to access the services of the network function. Components outside the PCC framework include a network slice selection function (NSSF) 302, a network repository function (NRF) 306, a unified data management (UDM) 308, an edge application server discovery function (EASDF) 310, a network slice-specific authentication and authorization function (NSAAF) 312, an authentication server function (AUSF) 314, a service communication proxy (SCP) 316, and a network slice admission control function (NSACF) 316. The non-PCC architecture further includes a UE 102, a RAN 105, and a data network (DN) 330. An application server (AS) 390 may operate in the DN 330.

[0052] The PCC framework in architecture 300 includes a Unified Data Repository (UDR) 352, a Network Exposure Function (NEF) 354, a Network Data Analytics Function (NWDAF) 356, an Application Function (AF) 357, a Policy Control Function (PCF) 360, a Charging Function (CHF) 362, an Access and Mobility Management Function (AMF) 364, a Session Management Function (SMF) 366, and a User Plane Function (UPF) 370.

[0053] When the UPF 370 operates as a PDU session anchor (PSA) UPF to support PDU set-based QoS handling for XRM services, the PSA UPF 370 identifies the PDUs belonging to the PDU set and determines subsequent PDU set information based on, for example, the RTP extension header defined in 3GPP TS 26.522. The PSA UPF 370 transmits this PDU set information in the GTP-U header to the NG-RAN 105. The NG-RAN 105 can use the PDU set information for PDU set-based QoS handling (e.g., as described in 3GPP TS 23.501). The PDU set information can include (i) a PDU set sequence number, (ii) an indication of the end PDU of the PDU set, (iii) PDU sequence numbers within the PDU set, (iv) the PDU set size in bytes, and (v) a PDU set importance that identifies the relative importance of the PDU set compared to other PDU sets within a QoS flow. The NG-RAN can use the priority levels across QoS flows and the PDU set importance within a QoS flow for PDU set-level packet dropping in case of congestion.

[0054] Figure 4 is a 5GS architecture representation 400 based on reference points. In Figure 4 it, the non-roaming reference architecture of the PCC framework of 5GS is shown as blocks and connections with solid lines, and the components and connections outside the PCC framework are shown with dashed lines.

[0055] Refer to Figure 5 Scenario 500, during the registration procedure 510, the AMF determines whether the UE 102 is authorized to use XRM services based on the UE's XRM service capabilities and the XRM service authorization included in the subscription data received from the UDM. After successful registration 510, the UE requests 520 a PDU session establishment procedure, and the NG-RAN supporting XRM services can perform PDU set handling for QoS flows in the PDU session based on the XRM service authorization and information received from the SMF via the N2 message and the GTP-U header received from the UPF via the N3 interface. The UE or the network initiates 530 a PDU session modification procedure for an existing PDU session.

[0056] The SMF determines the QoS profile for a QoS flow, which is based on the received Policy Control and Charging (PCC) rules or pre-configuration. The PSA UPF performs the following: (i) identifies the PDUs belonging to a PDU set according to the protocol description based on the received Packet Detection Rule (PDR), (ii) marks the GTP-U header with the PDU set information as described in clause 5.37.5.2 of TS 23.501, and (iii) performs PDU set-based parameters based on the received QoS Enforcement Rule (QER).

[0057] The network uses the PDU set-based processing information of the uplink to instruct the UE to perform PDU set-based processing including PDU set identification and marking on the uplink media service data stream received from the upper layer, so as to provide NG-RAN in-band uplink PDU set information.

[0058] According to one implementation, the RAN 105 performs PDU set-based QoS processing for radio resource management based on the following information: (i) the uplink PDU set information received from the UE through the air interface, and (ii) the QoS profile containing the PDU set-based QoS parameters of the uplink.

[0059] The uplink PDU set information may include one or more of the following: (i) the PDU set sequence number, (ii) the indication of the end PDU of the PDU set, (iii) the PDU sequence number within the PDU set, (iv) the PDU set size in bytes, and (v) the PDU set importance, which identifies the relative importance of the PDU set compared to other PDU sets within the QoS flow.

[0060] Next, refer to Figures 6A to 6D Consider several example types of the mapping of PDUs to QoS flows. These models correspond to different combinations of one-to-one mapping and multiplexing / demultiplexing between PDU sets, QoS flows, and DRBs.

[0061] Generally speaking, Figures 6A to 6D the QoS model assumes that different QoS parameters can correspond to QoS flows. However, for PDU set-based QoS flows, it is still unclear what granularity of QoS parameters is required for PDU set-based QoS flows belonging to the same media stream. For example, according to Figure 6A the model, the RAN cannot schedule radio resources and process PDU set-based QoS flows according to the aggregated QoS flows or on a per-QoS flow basis.

[0062] According to Figure 6BIn an example model, RAN 105 needs to be enhanced to multiplex different QoS flows with different QoS requirements for PDU sets and map these flows to a DRB based on the following assumptions: CN 110 binds different types of PDU sets to different QoS flows, and a QoS profile includes multiple QoS parameter sets for multiple QoS flows. Here, RAN 105 needs a specific solution to determine whether to map multiple QoS flows to the same DRB or different DRBs according to the QoS requirements based on the PDU sets.

[0063] According to Figure 6C In an example model, RAN 105 needs a mechanism to demultiplex different sub-QoS flows in a QoS flow and map the sub-QoS flows to different DRBs based on the following assumptions: CN 110 binds different types of PDU sets to different sub-QoS flows, and a QoS profile includes multiple QoS parameter sets for multiple sub-QoS flows. A solution is needed to allow RAN 105 to determine whether to map the sub-QoS flows to the same DRB or different DRBs according to the QoS requirements based on the PDU sets.

[0064] Next, referring to Figures 7 to 12 several techniques for enhancing the existing end-to-end QoS flow model to accommodate XRM services based on PDU set QoS parameters and PDU set identification information are discussed.

[0065] At least some of the techniques discussed below rely on one or more of the following assumptions: An IP flow represents an IP 5-tuple, and an SDF includes a packet filter that defines the application traffic to be mapped to a QoS flow; a QoS flow is identified by a QFI; a sub-QoS flow is identified by a sub-QoS flow ID (XQFI) such that a QoS flow contains one or more sub-QoS flows; one or more QoS flows can be associated with a PDU session; a PDU session resource establishment request can be implemented as an N2 PDU session request message defined in clauses 4.3.2 and 4.3.3 of TS23.502.

[0066] Referring to Figure 7 , with reference to the QoS model 700, an example QoS provisioning between a UE such as UE 102 and a PSA UPF such as UPF 370 is shown.

[0067] Using the QoS model 700, an application (e.g., application 142) requests QoS requirements for a certain SDF (IP flow traffic) of a media type (e.g., video, voice, or XR) on a per-PDU basis. The SMF 366 can perform QoS binding of the SDF from an IP flow to a QoS flow for each media type and can transmit the corresponding QoS profile to the RAN 105. Each QoS profile can be associated with a QFI and QoS parameters for a media type. The UPF 270 can mark the GTP-U header of each PDU with the corresponding QFI, and the RAN 105 can perform radio resource scheduling and the mapping of one or more QoS flows to a DRB. In other words, the RAN 105 can implement a one-to-one mapping.

[0068] Generally, the communication system 100 can implement the following sequence of high-level procedures or steps for supporting traffic using the QoS model 700 (discussed in more detail below with reference to Figure 8 ): (i) In step A associated with the IP layer 710, an application (e.g., application 142) requests different QoS requirements for each IP flow traffic of a media type (e.g., video, voice, XR) from the CN 110; in step B associated with the 5GC layer 720, the SMF 366 performs QoS binding from the IP flow to the QoS flow identified by the QFI; in step C associated with the 5GC layer 720, the UPF 370 marks the GTP-U header of each PDU with the QFI; in step D associated with the 5GC layer 720, the SMF 366 transmits the QoS profile to the RAN 105, where the QoS profile indicates the QFI and QoS parameters; and in step E associated with the RAN SDAP layer 730, the RAN 105 performs the mapping between the QoS flow and the DRB.

[0069] In particular, continuing to refer to Figure 7 , the RAN 105 can perform the mapping from QoS flow 1 to DRB1 and from QoS flow 2 to DRB 2 for the corresponding QFI according to scenario 702, or perform the mapping from QoS flow 1 and from QoS flow 2 to DRB A according to scenario 704.

[0070] Figure 8 is the message passing diagram of the example scenario 800, where the events 802, 810, 812, 820, 850, and 852 generally correspond to step A discussed above with reference to Figure 7 and Figures 9 to 12 in the QoS model; the events 840, 842 generally correspond to step B; the events 860, 862 generally correspond to step C; the events 870, 872 generally correspond to step D; and the events 882 to 884 correspond to step E.

[0071] At the start of scenario 800, the UE 102, SMF 366, and UPF 370 perform 802 PDU session establishment (e.g., according to clause 4.3.2.2.1 of TS 23.502) or PDU session modification (e.g., according to clause 4.3.3 of TS 23.502).

[0072] The AS 390 transmits 810 a request to enable PDU set handling at the 5G network for the XRM service. The AF 358 then transmits 812 information to the PCF 360 via an AF request message that includes PDU set-related QoS requirements and PDU set configuration information. The AF request may include, for example, an Nnef_AFsessionWithQoS_Create request as defined in clause 4.15.6.6 of TS 23.502. In some scenarios, events 810, 812 occur before the UE 102 performs 802 PDU session establishment.

[0073] Next, the PCF 360 generates appropriate PCC rules, which may include or be based on PDU set-related QoS parameters and PDU set configuration information. The PCF 366 may use the information received 812 from the AF 358 to generate the PCC rules. The PCF 360 transmits 820 the PCC rules (where the PCC rules are parameters) to the SMF 366 via an SM policy association establishment / modification message.

[0074] The SMF 366 performs 830 the binding of QoS flows to SDFs. The SDFs may be associated with a packet filter set such as an IP 5-tuple and may correspond to IP flows. The SMF 366 then generates 842 an N4 message with N4 rules based on the PCC rules received from the PCF 360 and transmits 842 the N4 message to the UPF 370.

[0075] Continue to refer to Figure 8, the SMF 366 generates a QoS profile 860 based on the PCC rules received from the PCF 360. The SMF 366 further provides the QoS profile 860 to the nodes in the RAN 105 via the AMF 364. More specifically, the SMF 366 may transmit a Namf_Communication_N1N2MessageTransfer message to the AMF 364, which message includes one or more of the following: (i) the PDU session ID, (ii) N2 SM information (e.g., PDU session ID, QFI, QoS profile), or (iii) an N1 SM container (NAS message). The NAS message may be a PDU session establishment acceptance message, which PDU session establishment acceptance message includes QoS rules and associated QoS flow level QoS parameters. Then, the AMF 364 may transmit an N2 PDU session request message including the NAS message to the RAN 105 for delivery to the UE 102.

[0076] According to the procedure previously initiated by the UE 102 802, the SMF 366 uses the remaining steps of the PDU session establishment procedure or the PDU session modification procedure to provide QoS rules 862 to the UE 102. For example, to configure the UE 102 862, the RAN 105 may use the RRC connection reconfiguration procedure. The RAN 105 may provide configuration parameters based on the information received from the SMF 366 to generate the required NG-RAN resources related to the QoS rules for the received PDU session request. For example, the RAN 105 may provide SDAP-config settings to the UE102, which settings include a mapping list of DRBs having a list of QoS flows allocated according to a one-DRB-to-multiple-QoS-flows allocation scheme for uplink communication, downlink communication, or both.

[0077] When XRM media traffic is available for transmission to the UE 102, the AS 390 performs AS operations 850 on the XRM media traffic for delivery over the 5G network and transmits DL packets 852 to the UPF 370 via the N6 interface.

[0078] In response to receiving the DL packet 852 (e.g., DL PDU), the UPF 370 identifies a PDU set 870 based on a previously received N4 rule or local configuration at the UPF370. The UPF 370 marks the GTP-U header of the DL PDU according to the PDU set-based QoS handling in the N4 rule instructions. The UPF 370 transmits a PDU 872 with the PDU set information marked in the GTP-U header to the RAN 105.

[0079] Next, the RAN 105 performs QoS handling based on PDU sets 880, maps the QoS flow to a DRB, and uses the DRB to transmit DL packets 882 to the UE 102 via the NR_Uu interface. For this purpose, the RAN 105 uses the PDU set-related information in the GTP-U header received via the N3 interface, the QoS profile, and the PDU set configuration information received from the SMF 366 via the N2 interface.

[0080] The UE 102 receives the DL packets associated with the DRB, maps the DRB 884 to the QoS flow based on the previously received SDAP-config 860, and forwards the QoS flow to the upper-layer application (e.g., application 142) based on the DL QoS rules previously configured 860 by the SMF 266.

[0081] Now refer to Figure 9 , the difference between the reference QoS model 900 and Figure 7 the reference QoS model 700 lies in the mapping between the SDF (e.g., IP flow) and the PDU. Different from the reference QoS model 700, here, the application layer uses different IP flows for different PDU set types (e.g., I / P / B frames or slices) of the media stream.

[0082] More specifically, according to the reference QoS model 900, the AS 390 divides the frames or slices corresponding to different PDU set types of the same media type (e.g., such as video) into different IP flows. For example, these IP flows can have the same IP address but different ports.

[0083] The AS 390 can generate a request including the PDU set configuration, and the RAN 105 can use this PDU set configuration for PDU set-based scheduling (e.g., see event 810). This request can also include different QoS requirements for different IP flows and aggregated QoS requirements for IP flows belonging to the same media stream. The RAN 105 can then perform PDU set-based scheduling and handle the QoS flow for each PDU set type based on the QoS profile belonging to the same media stream type.

[0084] AF 358 may request QoS requirements (e.g., see Event 812), which include PDU Set-based QoS (PS-QoS) parameters for the binding of QoS flows for SDF / IP flows associated with the same media stream, and a QoS flow association Id. The PS-QoS parameters may include one or more of the following: (i) PDU Set Delay Budget (PSDB), (ii) PDU Set Error Rate (PSER), which may be an aggregation of different reasons including PDU Set Drop Rate (PSDR), (iii) PSDR, which defines the PDU set drop rate expected by the application for a PDU set type (e.g., I / P / B frames) or the PDU set importance level for binding the SDF to the QoS flow, (iv) PDU Set Priority, (v) PDU Set Periodicity, and (vi) PDU Set Comprehensive Indication, which may be an indication of whether the application layer requires all PDUs to use the PDU set. The QoS flow association Id serves to associate IP flows belonging to the same media stream and is a parameter specified by AS 390.

[0085] Communication system 100 may implement the sequence of advanced procedures or steps discussed below for supporting traffic using QoS model 900 (also see Figure 8 ). In step A, the AS 390 application server transmits IP flows based on the PDU set type. The PS-QoS requirements apply on a per-IP flow basis. AF 358 requests different QoS requirements for each IP flow such that each set of QoS requirements corresponds to a respective IP flow, and each IP flow is associated with a PDU set type.

[0086] In step B, the SMF 366 performs QoS binding from an IP flow to a QoS flow. The SMF 366 further transmits an N4 message including a Packet Detection Rule (PDR) and a QoS Enforcement Rule (QER) to the UPF 370. The PDR may include a packet filter that the UPF 370 can use to identify IP flows of a specific PDU set type. The QER may include QoS parameters with an associated QFI.

[0087] Next, in step C, the SMF 366 transmits a QoS profile to the RAN 105 via the N2 interface. The QoS profile may include one or more of the PS-QoS parameters, QFI, QoS flow association ID, and PDU session ID. The SMF 366 may use the QoS flow association ID to map QoS flows belonging to the same media stream to a PDU session ID. In one implementation, if a PDU session applies to a specific XRM media type, e.g., video, the SMF 366 does not transmit the QoS flow association ID to the RAN 105.

[0088] In step D, the UPF 370 identifies a PDU set based on a PDU set PDR (PS-PDR), marks the QFI in the GTP-U header of each PDU, and transmits the PDU to the RAN 105 via the N3 interface.

[0089] Finally, in step E, the RAN 105 performs radio resource scheduling based on all QoS profiles having the same QoS flow association ID. The RAN 105 then maps the QoS flow to the DRB for each QFI, i.e., according to a one-to-one mapping scheme. For example, the RAN 105 may perform the mapping from QoS flow 1 to DRB 1 and from QoS flow 2 to DRB 2 for the corresponding QFI according to scenario 902, or perform the mapping from QoS flow 1 and from QoS flow 2 to DRB A according to scenario 904.

[0090] In another implementation, the PDU set configuration includes a PDU set flow descriptor (e.g., an IP 5-tuple) and a PST indication configuration policy, and the AS 390 can use the PDU set flow descriptor and the PST indication configuration policy to notify the SMF 366 of the PDU set type used by the application for the IP flow of the media stream.

[0091] In yet another implementation, the PDU set configuration further includes a PS importance configuration policy. The SMF 366 can use the PS importance configuration policy in the following manner. In step B, the SMF 366 can configure the UPF 370 with a PDU set marking rule including the PS importance configuration policy, which allows the UPF 370 to determine the PS importance level based on the upper layer packet header, e.g., depending on the I bit, D bit, two D bits, or other bits in the RTP / SRTP extension header or the new extended RTP header, or the NAL bit. The PS importance level can further indicate the importance of the PDUs within the QoS flow or sub-QoS flow, which is different from the PDU set priority level included in the PS-QoS parameter. Further, in step C, the SMF 366 can use the PS importance configuration policy to notify the RAN 105 of the PS importance level marked at the UPF 370, e.g., high / medium / low or a digital level.

[0092] Reference Figure 10 , the difference between the reference QoS model 1000 and the reference QoS models 700 and 900 discussed above is that here, the application layer uses the same IP flow for different PDU set types (e.g., I / P / B frames or slices) of the media stream, and the SMF 366 binds one SDF to multiple QoS flows for different PDU set types.

[0093] More specifically, when using the reference QoS model 100, the AF 358 generates a request including a PDU set configuration that the SMF 366 can use to configure the UPF 370 to identify and mark the arriving PDUs, and to configure the RAN 105 to handle PDU set-based scheduling. The request may also include QoS requirements within the same IP flow belonging to the same media stream. The SMF 366 binds one or more SDFs to multiple QoS flows based on the PDU set type and the received PDU set configuration.

[0094] Further, the N2 message transmitted by the SMF 366 to the RAN 105 may include a PDU set-based QoS profile. The RAN 105 may perform PDU set-based scheduling on the DRB based on one or more QoS profiles associated with multiple QFIs and PS-QoS parameters.

[0095] The AF 358 may request QoS requirements and include in the request the following parameters for the same media stream: aggregated (or combined) QoS parameters for the aggregation of the media stream and / or PS-QoS parameters for each PDU set type or each QoS flow associated with the media stream. For example, the aggregated QoS parameters may include aggregated PSDB, aggregated PSER, and aggregated PDU set periodicity. The PS-QoS parameters may include one or more of the following: (i) PSDB, (ii) PSER, which may be an aggregation of different reasons including PSDR, (iii) PDU set type priority, which defines the priority of the PDU set type for a QoS flow or sub-QoS flow, (iv) PSDR, which corresponds to the expected rate of discarding PDU sets of a PDU set type such as I / P / B frames, (v) PDU set importance level, which binds the SDF to the QoS flow, (vi) PDU set periodicity, or (vii) PDU set combined indication, which may be an indication of whether the application layer requires all PDUs to use the PDU set.

[0096] Further, when using the reference QoS model 1000, the SMF 366 may generate a QoS flow association ID to associate QoS flows belonging to the same media stream.

[0097] The communication system 100 may implement the following discussion for using the QoS model 1000 (see also Figure 8)A sequence of advanced procedures or steps to support traffic. In step A, the AS 390 transmits an IP flow for a media stream (e.g., video). In addition to the RTP / SRTP extension headers, the AS 390 also marks each media unit in a (new) dedicated extended RTP header or N6 tunnel header of the encrypted traffic. The AS 390 can use the PDU set indication for marking, and the UPF 380 uses this PDU set indication to distinguish PDUs that require PDU set processing in the 5GC. The AF 358 requests the PDU set configuration and the QoS requirements for the IP flow of the media stream. For this purpose, as part of the QoS requirements, the AF 358 can specify the aggregated QoS parameters for the media stream and the PDU set-based QoS requirements for each PDU set type.

[0098] In step B, the SMF 366 performs QoS binding from one IP flow to multiple QoS flows based on the PDU set configuration and QoS requirements received from the AF 358. The SMF 366 configures the UPF 370 based on the PDU set configuration.

[0099] In step C, the SMF 366 generates and uses a QoS flow association ID to map QoS flows belonging to the same media stream to one PDU session ID. The SMF 366 then transmits at least one QoS profile to the RAN 105 via the N2 interface. In one such implementation, one QoS profile is associated with the QoS flow association ID and includes the following: (i) aggregated QoS parameters and the associated QoS flow association ID, (ii) PS-QoS parameters and a list of associated QFs, and (iii) the PDU session ID.

[0100] In another implementation, the SMF 366 transmits multiple QoS profiles with different granularities. The QoS profile can include an aggregated QoS profile for each media stream identified by the QoS flow association ID, and this aggregated QoS profile in turn includes the QoS flow association ID, aggregated QoS parameters, the PDU session ID, and an optional list of QFIs associated with the QoS flow association ID. The QoS profile can also include a QoS profile specific to the QoS flow, which includes the QFI, the QoS flow association ID, and the PS-QoS parameters.

[0101] In step D, when the UPF 370 detects a PDU marked with the PST indication and based on the PS-PDR, before sending the PDU to the RAN 105 via the N3 interface, the UPF 370 marks the GTP-U header of each PDU based on the PDU set marking rules using the corresponding QFI, PDU set information, and importance level.

[0102] In step E, the RAN 105 performs radio resource scheduling and mapping of QoS flows to DRBs based on one or more QoS profiles. The RAN 105 may perform the mapping of QoS flow 1 to DRB 1 and QoS flow 2 to DRB 2 for the corresponding QFI according to scenario 1002, or perform the mapping of QoS flow 1 and QoS flow 2 to DRB A for the corresponding QFI according to scenario 1004.

[0103] Reference Figure 11A , the reference QoS model 1100A is different from the reference QoS model discussed above in that here, the application layer uses the same IP flow for different PDU set types (e.g., I / P / B frames or slices) of a media stream, and the SMF 366 binds one SDF to one QoS flow with multiple sub-QoS flows for different PDU set types.

[0104] Similar to the reference Figure 10 discussed method, the AF 358 generates a request including PDU set configuration, which the SMF 366 can use to configure the UPF 370 to identify and mark the arriving PDUs and configure the RAN 105 to handle PDU set-based scheduling. Also similar to the Figure 10 method, the request may include QoS requirements within the same IP flow of the same media stream. However, here, the SMF 366 binds one or more SDFs to multiple QoS flows based on the PDU set type and the received PDU set configuration.

[0105] The N2 message transmitted by the SMF 366 to the RAN 105 may include a PDU set-based QoS profile. The RAN 105 may perform PDU set-based scheduling on the DRB based on one or more QoS profiles associated with one QFI and multiple sub-QoS flows (with different XQFIs) and PS-QoS parameters.

[0106] The AF 358 may request QoS requirements and include the following parameters for the same media stream in the request: aggregated (or combined) QoS parameters for the service data flow (IP 5-tuple) associated with one QFI, and / or PS-QoS parameters for each PDU set type or each sub-QoS flow. The aggregated QoS parameters and PS-QoS parameters may include elements similar to those discussed above with reference to Figure 10 discussed.

[0107] To support traffic using the QoS model 1100A, the communication system 100 may implement an advanced procedure or sequence of steps similar to the advanced procedure or sequence of steps discussed above with reference to the QoS model 1000, with the following modifications.

[0108] In step B, the SMF 366 performs QoS binding from one IP flow to multiple sub-QoS flows based on the PDU set configuration and QoS requirements received from the AF 358. The SMF 366 configures the UPF 370 based on the PDU set configuration.

[0109] In step C, the SMF 366 generates and uses a QFI to map sub-QoS flows belonging to the same media flow to one PDU session ID, and then transmits the QoS profile to the RAN 105 via the N2 interface. In one such implementation, a QoS profile includes the following: (I) aggregated QoS parameters associated with the QFI, (ii) PS-QoS parameters associated with the XQFI, and (iii) the PDU session ID.

[0110] In another implementation, the SMF 366 transmits multiple QoS profiles with different granularities. The QoS profile may include a QoS profile associated with a QFI, which includes the QFI, aggregated QoS parameters, the PDU session ID, and (optionally) a list of XQFI associated with the QFI. The SMF 366 may also transmit the QoS profile on a per-sub-QoS flow basis, where the QoS profile includes the QFI, XQFI, and PS-QoS parameters. The XQFI may identify the sub-QoS flow.

[0111] In step D, when the UPF 370 detects a PDU marked with a PS indication, (optionally) a PST indication, and based on a PS-PDR, the UPF 370 marks the GTP-U header of each PDU with the corresponding QFI+XQFI, PDU set parameters, and (optionally) the PDU set importance level based on the PDU set marking rule. The UPF 370 then transmits the PDU to the RAN 105 via the N3 interface.

[0112] In step E, the RAN 105 performs radio resource scheduling and mapping of sub-QoS flows to DRBs based on one or more QoS profiles. The RAN 105 may perform mapping from sub-QoS flow 1 to DRB 1 and from sub-QoS flow 2 to DRB 2 for the corresponding QFI+XQFI according to scenario 1102A, or mapping from sub-QoS flow 1 and from sub-QoS flow 2 to DRB A for the corresponding QFI according to scenario 1104A.

[0113] According to the reference Figure 11BAnother method discussed is that the UPF 370 identifies each sub-QoS flow based on the detected packet header information. The communication system 100 can rely on a QoS model 1100B similar to the QoS model 1100A to also support sub-QoS flows within a QoS flow and provide the RAN 105 with PDU set information with different granularities. However, according to the reference Figure 11A discussed technology, during the procedure of binding the SDF to the QoS flow, the SMF 366 defines each sub-QoS flow. During this procedure, each sub-QoS flow obtains an XQFI. According to Figure 11B the technology, the UPF 370 identifies each sub-QoS flow based on the detected packet header information.

[0114] More specifically, for the QoS model 1100A, the UPF 370 is configured with QoS flow corresponding to the QFI (identifiable by the QFI) and sub-QoS flow information corresponding to the XQFI. The UPF 370 marks the XQFI in the GTP-U header of the identified PDU based on the PDU set type in the packet header, and the RAN 105 relies on the QoS profile with the corresponding QFI and XQFI for PDU scheduling and DRB mapping.

[0115] For the QoS model 1100B, the UPF 370 marks additional PDU set information including the PDU set importance level and / or PDU set type in the GTP-U header of the identified PDU based on the information contained in the higher layer packet header received through the N6 interface. The RAN 105 relies on the QoS profile corresponding to the QFI of the sub-QoS flow and the PDU set QoS parameters. The sub-QoS flow is associated with the PDU set importance level and / or PDU set type for PDU scheduling and DRB mapping.

[0116] In one implementation, the UPF 370 uses a PDU set identifier to identify the PDU set, and the PDU set identifier is an RTP / SRTP extension header type. For each DL PDU received via the N6 interface or the N19 interface for which the service protocol has been determined, the UPF 370 applies the rules of the PDU set identifier and determines the PDU set information. The UPF 370 provides the PDU set information in the GTP-U header to the RAN 105. The PDU set information may include a PDU set sequence number, which is a cyclic counter incremented for each PDU set instance; an end PDU of the PDU set, which is a flag indicating the last PDU of the PDU set instance; a PDU sequence number within the PDU set, which is a cyclic counter incremented for each PDU within the PDU set and reset at the PDU set boundary; the PDU set size in bytes; and the PDU set importance, which identifies the importance of the PDU set within the QoS flow.

[0117] As indicated above, a QoS flow may include multiple sub-QoS flows. In one implementation consistent with the QoS model 11000B, each sub-QoS flow is associated with a certain PDU set type. In other words, each sub-QoS flow is for a PDU set with the same PDU set type. In another implementation, each sub-QoS flow is associated with a certain PDU set importance level, such that a certain sub-QoS flow is for a PDU set with the same PDU set importance level. In yet another implementation, each sub-QoS flow is associated with a PDU set importance level and a PDU set type, such that a certain sub-QoS flow is for a PDU set with the same PDU set importance level and the same PDU set type.

[0118] Therefore, the RAN 105 can identify the sub-QoS flow based on the PDU set importance level, the PDU set type, or both. When transmitting PDUs via the N3 interface, the UPF 370 can provide the value in the GTP-U header. The UPF 370 detects the PDUs and uses one of the example methods discussed below to determine which sub-QoS flow the PDUs belong to.

[0119] In one implementation, the UPF 370 uses a local configuration that indicates how the UPF 370 can determine the PDU set type, the PDU set importance level, or both based on the upper layer packet header. For example, for I / P / B frames, the PDU set importance level can depend on the I bit, the D bit, or both D bits, or other bits, in the RTP / SRTP extension header or the new extended RTP header. The PDU set type can depend on bits in the RTP / SRTP extension header or the new extended RTP header defined by the PDU set configuration information. For media slices, the PDU set importance level or the PDU set type can depend on specific NAL bits in the existing NAL header or a dedicated (new) extended NAL header.

[0120] In another implementation, the UPF 370 uses a PDU set configuration that the SMF 366 obtains from the SMF as discussed below with reference to Figure 12 For example, for I / P / B frames, the PDU set importance level, the PDU set type, or both can depend on the PDU set configuration that defines specific bits in the RTP / SRTP extension header or a dedicated (new) extended RTP header. For media slices, the PDU set importance level, the PDU set type, or both can depend on the PDU set configuration that defines specific NAL bits in the existing NAL header or a dedicated (new) extended NAL header.

[0121] Reference Figure 11A and Figure 11B , the AF 358 can generate a request that includes the PDU set configuration, and the SMF 366 can use the PDU set configuration to configure the UPF 370 to identify and mark the arriving PDUs in the GTP-U header, and the UPF 370 then transmits the arriving PDUs to the RAN 105 for PDU set-based scheduling. The request from the AF 358 can include QoS requirements applicable within the same IP flow that belongs to the same media stream. The SMF 366 binds one or more SDFs to one QoS flow that includes multiple sub-QoS flows. The UPF 370 can detect and identify each sub-QoS flow based on the XQFI allocated by the SMF (according to QoS model 1100A), or the PDU set type detected by the UPF 370 (according to QoS model 1100B, PDU set type option), or the PDU set importance level detected by the UPF 370 (according to QoS model 1100B, PDU set configuration from the SMF 366 option), or the PDU set importance level and the PDU set type detected by the UPF 370 (according to QoS model 1100B, PDU set importance level and PDU set type option).

[0122] Further with respect to Figure 11A and Figure 11BFor a model that travels from CN 110 to RAN 105, the N2 message can include a PDU set-based QoS profile, which contains PDU set QoS parameters for each sub-QoS flow. Among them, RAN 105 can identify sub-QoS flows through XQFI (according to QoS model 1100A), PDU set type (according to QoS model 1100B, local configuration option), PDU set importance level (according to QoS model 1100B, PDU set configuration from the SMF 366 option), or PDU set importance level and PDU set type (according to QoS model 1100B, PDU set importance level and PDU set type option).

[0123] RAN 105 performs PDU set-based scheduling on the DRB based on the PDU set-based QoS profile received from SMF 366 and the GTP-U header of the PDUs received from UPF 370 through the N3 interface.

[0124] AF 358 can request QoS requirements including parameters of the SDF (e.g., IP 5-tuple) for the media stream. The SDF corresponds to the QFI allocated by SMF 366 after QoS. The aggregated (or comprehensive) QoS parameters can include one or more of the following: (i) aggregated PSDB, (ii) aggregated PSER, or (iii) aggregated PDU set periodicity. The PS-QoS parameters for each sub-QoS flow can include (I) PSDB, (ii) PSER, which can correspond to the aggregation of the reasons including PSDR, (iii) PDU set periodicity, (iv) PSDR, or (v) PDU set comprehensive indication.

[0125] When the QoS requirements contain the aggregated / comprehensive QoS parameters and PS-QoS parameters for each sub-QoS flow, SMF 366 can use the aggregated QoS parameters and PS-QoS parameters for each sub-QoS flow to configure the PDU set-based QoS profile (for sending to RAN 105).

[0126] When the QoS requirements only include aggregated / combined QoS parameters, based on the information configured for the PDU set, the PCF 370 and / or the SMF 366 can determine the reference PS-QoS parameters for each sub-QoS flow corresponding to: (i) the XQFI (according to QoS model 1100A), or the PDU set type (according to QoS model 1100B, PDU set type option), the PDU set importance level (according to QoS model 1100B, PDU set importance level option), or the PDU set importance level and the PDU set type (according to QoS model 1100B, PDU set importance level and PDU set type option). When the QoS requirements only include aggregated / combined QoS parameters, the SMF 366 can use the aggregated QoS parameters of each sub-QoS flow and the reference PS-QoS parameters to configure the PDU set-based QoS profile (for sending to the RAN 105).

[0127] When the QoS requirements only include the PS-QoS parameters of each sub-QoS flow, based on the information in the PDU set configuration, the PCF 366 and / or the SMF 366 can determine the aggregated (or combined) QoS parameters, such as the aggregated PSDB, the aggregated PSER, or the aggregated PDU set periodicity. In this case, the SMF 366 uses the aggregated QoS parameters and the PS-QoS parameters specified on a per-sub-QoS flow basis to configure the PDU set-based QoS profile.

[0128] Therefore, continuing to refer to Figure 11B , a QoS flow can include multiple sub-QoS flows. At least the following three options can be used to characterize each sub-QoS flow in the sub-QoS flows. According to the PDU set type option, each sub-QoS flow is for PDU sets with the same PDU set type. For example, sub-QoS flow 1 is for I-frames, and sub-QoS flow 2 is for B-frames. According to the PDU set importance level option, each sub-QoS flow is for PDU sets with the same PDU set importance level. For example, sub-QoS flow 1 is for PDU sets with an importance level of 1, and sub-QoS flow 2 is for PDU sets with an importance level of 2. According to the PDU set importance level and PDU set type option, each sub-QoS flow is for PDU sets associated with the same PDU set importance level and PDU set type. For example, sub-QoS flow 1 is for I-frames with a PDU set importance level of 1, and sub-QoS flow 2 is for I-frames with a PDU set importance level of 2.

[0129] To support traffic using QoS model 1100B, the communication system 100 can implement an advanced procedure or sequence of steps similar to the one discussed above with reference to QoS model 1110A, with the following modifications.

[0130] In step B, the SMF 366 performs QoS binding from an IP flow to a QoS flow and configures the UPF 370 based on the PDU set configuration and QoS requirements received from the AF 358. Depending on at least the following options that can be implemented by the UPF 370, the QoS flow can include multiple sub-QoS flows: (i) according to the PDU set type option, each sub-QoS flow is for a PDU set with the same PDU set type, (ii) according to the PDU set importance level option, each sub-QoS flow is for a PDU set with the same PDU set importance level, and (iii) according to the PDU set importance level and PDU set type option, each sub-QoS flow is for a PDU set associated with the same PDU set importance level and PDU set type, as discussed above.

[0131] In step C, the SMF 366 generates and uses a QFI to map the service data flow of the media stream to a PDU session ID, determines QoS parameters, and transmits a QoS profile including the QoS parameters to the RAN 105 via the N2 interface. The SMF 366 can provide the QoS profile to the RAN 105 according to at least the following two options: According to scenario 1102B, the QFI identifies a QoS profile identified by the QFI, and the QoS profile includes the PDU session ID, QFI, aggregated QoS parameters, and PS-QoS parameters on a per-sub-QoS flow basis (according to one of the PDU set type option, PDU set importance level option, or PDU set importance level and PDU set type option discussed above); According to scenario 1104B, a QoS flow is associated with multiple QoS profiles, the QoS profiles correspond to the QFI, and the QoS profiles include the QFI, aggregated QoS parameters, and PDU session ID. Further, according to the latter option, the sub-QoS profile on a per-sub-QoS flow basis can be based on one of the PDU set type option, PDU set importance level option, or PDU set importance level and PDU set type option. The sub-QoS profile can include the associated QFI, PDU set type, and / or PDU set importance level, and PS-QoS parameters.

[0132] In step D, when the UPF 370 detects a PDU marked with a PS indication, marked with an (optional) PST indication, and based on the PS-PDR and PDU set marking rules, the UPF 370 marks the GTP-U header of the PDU with the QFI and PDU set information. In addition to the PDU set sequence number, the end PDU of the PDU set, the PDU sequence number within the PDU set, and the PDU set size in bytes, the PDU set information may further include a PDU set importance level and / or a PDU set type according to one of the PDU set type option, the PDU set importance level option, or both the PDU set importance level and the PDU set type option. The UPF 370 then transmits the PDU with the GTP-U header to the RAN 105.

[0133] In step E, based on one QoS profile or multiple QoS profiles, the RAN 105 performs radio resource scheduling and maps the QoS flows to DRBs based on the QoS profiles. According to scenario 1102B, the RAN 105 performs the mapping based on one QoS profile according to one of the PDU set type option, the PDU set importance level option, or both the PDU set importance level and the PDU set type option discussed above, such as one QoS flow to a DRB for each QFI and PDU set importance level and / or PDU set type. According to scenario 1104B, the RAN 105 performs the mapping based on multiple QoS profiles such that, for example, based on the associated QFI and PDU set importance level and / or PDU set type (again according to one of the PDU set type option, the PDU set importance level option, or both the PDU set importance level and the PDU set type option), sub-QoS flow 1 is mapped to DRB A and sub-QoS flow 2 is mapped to DRB A. As a more specific example consistent with scenario 1104B, based on the QFI and PDU set importance level, in the form of a one-to-one mapping, sub-QoS flow 1 is mapped to DRB A and sub-QoS flow 2 is mapped to DRB A. In some cases, different QFIs (bound to different SDFs) with similar QoS parameters and the same PDU set importance level are mapped to the same DRB.

[0134] Next, refer to Figure 12 Discuss an example technique for generating a PDU set configuration. For example, method 1200 may be implemented in the AS390 and / or the AF 358. For convenience, this method is discussed with reference to the application layer.

[0135] At block 1202, the application layer generates a PDU set indication for instructing the SMF 366 that the SMF 366 should apply PDU set comprehensive processing to service data flows. At block 1210, the application layer generates a PDU set flow description for instructing the UPF 370 which RTP / SRTP extension header type should be used for PDU set identification at the UPF. At block 1220, the application generates a PDU set type indication (PST indication) of the PST type used by the application for the media flow. When the application applies a specific PST indication configuration policy (e.g., when the application uses a specific upper layer packet header), the SMF 366 and / or the UPF 370 use the PDT indication to distinguish PDU set types and associate these types with different corresponding QoS flows. When the AF 358 does not specify a PST indication, the SMF 366 and the UPF 370 use reconfiguration settings based on standard values or based on RTP / SRTP extension headers or NAL headers.

[0136] In some implementations, method 1200 further includes optional block 1230, wherein the application layer further includes a PS importance configuration policy in the PDU set configuration. When included in the PDU set configuration, this parameter overrides the local configuration at the SMF 366. The SMF 366 may use the PS importance configuration policy to configure the UPF 370 with PDU set marking rules including the PS importance configuration policy, which allows the UPF 370 to determine the PS importance level based on the upper layer packet header, e.g., according to the I bit, the D bit, two D bits, or other bits in the RTP / SRTP extension header or the new extended RTP header, or the NAL bit.

[0137] More particularly, referring to Figure 13 , method 1300 may be implemented in the SMF 366 to, for example, process the PS importance configuration policy. At block 1302, for example, the SMF 366 receives a PS importance configuration policy from the AF 358 or the AS 390. At block 1304, the SMF 366 may use the PS importance configuration policy to configure the UPF 370 with PDU set marking rules including the PS importance configuration policy.

[0138] In one scenario or implementation, for QoS flow or sub-QoS flow binding, the SMF 366 applies the PS importance level to associate a PDU set with the same or different PDU set importance levels, associates PDU sets based on the PDU set type, or associates PDU sets based on both the PDU set importance level and the PDU set type. In another scenario or implementation, for the inter-PDU set of a QoS flow or sub-QoS flow, the SMF 366 indicates the PS importance level and / or the PDU set type for each PDU set of the QoS flow or sub-QoS flow, where the PS importance level and / or the PDU set type is different from the PDU set type priority included in the PS-QoS parameters. In another scenario or implementation, for the intra-PDU set, the PS importance level and / or the PDU set type may indicate the importance level and / or the PDU set type of each PDU within the PDU set.

[0139] At block 1306, the SMF 366 notifies the RAN 105 of the PS importance level (e.g., high, medium, or low, or a suitable set of discrete levels) and the PDU set type (e.g., I / P / B frames or slices) marked by the UPF 370. The PS importance level takes precedence over the local configuration at the RAN 105.

[0140] Now referring Figure 14 , the SMF 366 may also implement the example method 1400 to generate an N4 message for the UPF 370 for PDU set processing for transmission over the N4 interface. The SMF 366 may execute method 1400 at step B of the scenarios discussed above with reference to the QoS model.

[0141] At block 1402, the SMF 366 includes a PDR in the N4 message. The PDR may include a packet filter that the UPF 370 uses to identify a PDU set based on the PDU set configuration, which includes a PDU set type indication (when the QoS model 1000 or 1100A applies) and an RTP / SRTP extension header or a network abstraction layer header (when the QoS model 1000, 1100A, or 1100B applies).

[0142] At block 1404, the SMF 366 includes a QER in the N4 message. The QER provides PDU set-based QoS parameters with an associated QFI (when the QoS model 1000 applies), or provides PDU set-based QoS information with an associated QFI+XQFI (when the QoS model 1100A applies), or provides a set of PDU set-based QoS parameters with an associated QFI for a sub-QoS flow based on the PDU set importance level and / or the PDU set type (when the QoS model 1100B applies).

[0143] At block 1406, the SMF 366 includes in the N4 message a PDU set marking rule that provides information related to the QFI, PDU set information, and a PS importance configuration policy configured based on the PDU set (when QoS model 1000 applies), or provides information related to QFI+XQFI, PDU set parameters configured based on the PDU set (when QoS model 1100A applies), or provides information for marking the GTP-U header, including the QFI, PDU set information, and a PS importance configuration policy configured based on the PDU set (when QoS model 1100B applies).

[0144] At block 1404, the SMF 366 transmits an N4 message to the UPF 370.

[0145] Figure 15 It is a message transfer diagram of an example method 1500 that the SMF 366 can implement to provide QoS rules to the UE 102, for example, during a PDU session establishment or modification procedure. As discussed below, the SMF 366 can modify or add an existing QoS flow description so that the UE 102 can handle PDU set-based QoS flows.

[0146] At block 1502, the SMF 366 can include a PDU set indication in the UE message. The SMF 366 can provide the PDU set indication and QoS rules that include a QoS rule identifier (QRI), the length of the QoS rule, a rule operation code, a default QoS rule (DQR) bit, the number of packet filters, a packet filter list, packet filter precedence, and the QFI. The SMF 366 can also provide in the same or a separate message QoS flow descriptions that include the QFI and operation codes (create, modify, delete), QoS parameters (5QI, GFBR / MFBR uplink / downlink, average window, EPS bearer ID), etc.

[0147] Next, at block 1504, the SMF 366 can include additional QoS parameters for the PDU set. For the aggregated (or combined) QoS associated with one QFI, these additional QoS parameters include one or more of the following: (i) PDFB, (ii) PSER, or (iii) aggregated PDU set periodicity.

[0148] For the PS-QoS parameters of each PDU set type or sub-QoS flow (corresponding to a certain QFI) of a QoS flow, where the sub-QoS flow can be identified based on the XQFI (according to QoS model 1100A), the PDU set importance level (according to QoS model 1100B), or the PDU set type (according to QoS model 1100B), the SMF 266 may include one or more of the following in the UE message: (i) PSDB, (ii) PSER, which may be an aggregation of different reasons including PSDR, (iii) PDU set type priority, which defines the priority of the PDU set type for the QoS flow or sub-QoS flow, (iv) PSDR, (v) PDU set periodicity, or (vi) PDU set comprehensive indication.

[0149] At block 1506, the SMF 366 transmits a UE message to the UE 102.

[0150] Finally, Figure 16 is a messaging diagram of an example method 1600 that the SMF 366 can implement to support QoS flows for media types. At block 1602, the SMF may receive PDU set related QoS parameters (e.g., see event 820). At block 1604, the SMF may perform QoS binding of SDFs from one SDF (or IP flow) to one QoS flow for each media type (e.g., see event 840). At block 1606, the SMF may transmit QoS to the RAN (e.g., see event 860).

[0151] The following description may apply to the above description.

[0152] In some implementations, "message" is used and "information element (IE)" can be used instead of "message". In some implementations, "IE" is used and "field" can be used instead of "IE". In some implementations, "configuration" can be replaced by "multiple configurations" or configuration parameters.

[0153] A user device (e.g., UE 102) that can implement the technology of the present disclosure can be any suitable device capable of wireless communication, such as a smart phone, a tablet computer, a laptop computer, a mobile game console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device such as a smart watch, a wireless hotspot, a femtocell, or a broadband router. Further, in some cases, the user device can be embedded in an electronic system such as a host unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, computer-readable memory, a user interface, one or more network interfaces, one or more sensors, and the like.

[0154] Certain embodiments in the present disclosure are described as including logic or a plurality of components or modules. A module can be a software module (e.g., code or machine-readable instructions stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing certain operations and can be configured or arranged in a particular manner. A hardware module can include dedicated circuitry or logic that is persistently configured to perform certain operations (e.g., as a dedicated processor, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), a digital signal processor (DSP), etc.). A hardware module can also include programmable logic or circuitry that is temporarily configured by software to perform certain operations (e.g., as included within a general-purpose processor or other programmable processor). The decision to implement a hardware module in dedicated and permanently configured circuitry or in temporarily configured circuitry (e.g., circuitry configured by software) can be driven by cost and time considerations.

[0155] When implemented in software, these technologies can be provided as part of an operating system, a library used by multiple applications, a specific software application, etc. The software can be executed by one or more general-purpose processors or one or more dedicated processors.

Claims

1. A method in a core network CN of a wireless communication system, the method comprising: Receiving quality of service QoS parameters related to the processing of a protocol data unit PDU set for traffic; Using the QoS parameters to perform QoS binding of a service data flow SDF to at least one QoS flow for a certain media type; Generating a QoS profile associated with a QoS flow identifier QFI of the QoS flow for the media type; And Transmitting the QoS profile to a radio access network RAN via which a UE accesses the CN.

2. The method according to claim 1, wherein, The receiving of the QoS parameters includes receiving policy and charging control PCC.

3. The method according to claim 2, wherein, The PCC rule includes PDU set configuration.

4. The method according to any one of the preceding claims, wherein, The performing of the QoS flow binding includes: Binding the SDF to multiple QoS flows for different corresponding PDU set types.

5. The method according to any one of claims 1 to 3, wherein, The performing of the QoS flow binding includes: Binding the SDF to one QoS flow having multiple sub-QoS flows for different corresponding PDU set types.

6. The method according to claim 5, further comprising: Defining the multiple sub-QoS flows during the binding; And Assigning a corresponding sub-QoS flow ID XQFI to each of the multiple sub-QoS flows.

7. The method according to claim 5 or 6, wherein, The different PDU set types correspond to types of frames of a video stream.

8. The method according to any one of the preceding claims, further comprising: Configuring a user plane function UPF with PDU set marking rules.

9. The method according to claim 8, wherein The configuration includes: Configuring the UPF with a PS importance configuration policy for determining a PS importance level based on an upper layer packet header.

10. The method according to claim 9, further comprising: Transmitting the PS importance configuration policy to the RAN.

11. The method according to any one of the preceding claims, wherein: The SDF includes only traffic of the certain media type.

12. The method according to claim 11, wherein, The media type is one of voice, video, or extended reality XR.

13. The method according to any one of the preceding claims, wherein: The QoS profile is further associated with one or more QoS parameters for the certain media type.

14. The method according to any one of the preceding claims, wherein, The SDF is an Internet protocol IP flow.

15. An apparatus comprising processing hardware and configured to implement the method according to any one of the preceding claims.

Images