Quality of Service Flow Model for Low-Latency Services

Abstract

An entity in a core network (CN) of a wireless communication system receives (1602) quality of service (QoS) parameters related to handling based on a protocol data unit (PDU) set of traffic, uses the QoS parameters to perform (1604) QoS binding of a service data flow to a QoS flow for a particular media type, generates (1606) a QoS profile associated with a QoS flow identifier (QFI) of the QoS flow, and transmits (1606) the QoS profile to a radio access network (RAN) via which the UE accesses the CN.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to and claims the benefit of the filing dates of U.S. Provisional Patent Application No. 63 / 382,450, entitled "Framework of QoS Flow Model for XR and Media Services," filed November 4, 2022, and U.S. Provisional Patent Application No. 63 / 480,096, entitled "Framework of QoS Flow Model for XR and Media Services," filed January 16, 2023, the entire contents of which are expressly incorporated herein by reference.

[0002] The present disclosure relates generally to wireless communications, and more particularly to supporting traffic organized into packet data unit (PDU) sets. [Background technology]

[0003] This background discussion is provided for the purpose of outlining the context for the present disclosure. To the extent described in this background section, the work of the inventors named herein, and aspects of the present specification that may not qualify as prior art at the time of filing, are not admitted expressly or impliedly as prior art to the present disclosure.

[0004] Base stations operating in accordance with fifth-generation (5G) New Radio (NR) requirements support significantly greater bandwidth than fourth-generation (4G) base stations. In some cases, base stations can transmit data associated with eXtended Reality (XR), which refers to technologies such as augmented reality (AR), virtual reality (VR), mixed reality (MR), and cloud gaming, to user devices or user equipment (UE). The technologies generally involve quasi-periodic streaming and are associated with high data rates and low latency requirements.

[0005] The 3rd Generation Partnership Project recently proposed to consider support for XR and media (XRM) to provide 5G Systems (5GS) support for advanced media services, such as High Data Rate Low Latency (HDRLL) services, AR / VR / XR services, and tactile / multi-modality communication services. More specifically, the objectives include enhancing network exposure to support interactions between 5GS and XRM applications, as well as enhancing quality of service (QoS) and policies for XR and media service transmissions.

[0006] When supporting XR communications (or, more generally, data-intensive services), an application running on a user equipment (UE) may receive or generate data bursts, which can be understood as multiple units (PDUs) communicated within a relatively short period of time. A data burst may include one or more PDU Sets. A PDU Set generally includes one or more PDUs carrying the payload of one unit of information generated at the application level (e.g., frame(s) or video slice(s) for an XR service). A PDU in a PDU Set also corresponds to a particular QoS flow.

[0007] To support XRM services for PDU-set-based handling in 5GS, a radio access network (RAN), such as a next-generation RAN (NG-RAN), must be aware of the XRM services provided by the 5G core network (CN). The RAN receives PDU set QoS parameters in a QoS profile from the Access & Mobility Management Function (AMF) and the Session Management Function (SFM) over the N2 interface. The RAN also receives PDU set information for downlink XRM traffic from the User Plane Function (UPF) over the N3 interface, or PDU set information for uplink XRM traffic from the UE over the Uu interface. The RAN must perform PDU set-based QoS handling for radio resource scheduling using the received PDU set QoS parameters and the PDU set information included in the PDUs received from the UPF over the user plane N3 interface. More specifically, the PDU set information may be present in the General Packet Radio Service (GPRS) Tunneling Protocol (GTP)-U header information of the PDU.

[0008] Currently, the 5G CN provides the RAN with one QoS profile including QoS parameters and QoS flow IDs (QFIs) during the PDU Session establishment / modification procedure. Based on the QoS profiles of multiple QoS flows, the RAN can determine and perform mapping of one or more QoS flows to a DRB. Thus, the RAN can provide some flexibility in radio resource management by multiplexing multiple QoS flows with similar QoS requirements to one DRB.

[0009] Existing techniques are based on certain assumptions regarding QoS flows, PDU set types, DRBs, and QoS parameters (see Figures 6A-D discussed below), which may not always result in efficient handling of traffic.

[0010] The existing QoS model in 5GS operates between the UE and the PDU Session Anchor (PSA) UPF. 5GS, including 5G CM, RAN, and UE, can support PDUs on a per-PDU-Set basis by considering application traffic information in the Real-time Transport Protocol (RTP) / Secure RTP (SRTP) extension header. To enable per-PDU-Set QoS handling, the PDU-Set based QoS model must address at least the following:

[0011] It is unclear what granularity of QoS parameters is needed for PDU-Set-based QoS flows that belong to the same media stream. Currently, RANs are unable to schedule radio resources for aggregated QoS flows and on a per-QoS-flow basis, and are unable to handle PDU-Set-based QoS flows.

[0012] Furthermore, it is not clear what information the application server (AS) can provide to the 5G CN via user plane and / or control plane signaling. On the one hand, application layer information may not directly map to QoS characteristics of PDUs in the transport layer and radio resource units in the radio network layer. On the other hand, application implementation aspects vary in some configurable settings between the AS and the application client on the UE, even for the same media codec. There is no framework to provide additional information when more advanced media codecs become available and applicable to PDU set handling in 5GS.

[0013] Furthermore, it is not clear how the 5G CN should bind a service data flow, for example a service data flow corresponding to an IP5 tuple flow, to one or more QoS flows and / or more granular sub-QoS flows based on the PDU set information from the AS.

[0014] Furthermore, it is not clear what information in the QoS profile the 5G CN can provide to the RAN through the N2 interface.

[0015] It also remains unclear what PDU set information the UPF can apply or deliver to the RAN and how the RAN enforces 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

[0016] An example embodiment of the disclosed technology is a method in a core network (CN) of a wireless communication system, the method including receiving quality of service (QoS) parameters related to protocol data unit (PDU) set-based handling of traffic, performing QoS binding of a service data flow (SDF) to at least one QoS flow for a particular media type using the QoS parameters, 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), wherein a UE accesses the CN via the RAN.

[0017] Another example embodiment of these techniques is a device that includes processing hardware and is configured to implement the above methods. [Brief explanation of the drawings]

[0018] [Figure 1] FIG. 1 is a block diagram of an example wireless communication system, such as 5GS, that supports PDU set handling in the uplink direction using the techniques of the present disclosure. [Figure 2] 2 is a block diagram of an example protocol stack according to which the UE of FIG. 1 can communicate with the RAN of FIG. 1. [Figure 3] A service-based representation of the 5GS architecture, including an overall non-roaming reference architecture of the policy and charging control framework for 5GS. [Figure 4] A reference point-based representation of the 5GS architecture, including the overall non-roaming reference architecture of the policy and charging control framework for 5GS. [Figure 5] FIG. 1 is a high-level messaging diagram of an example scenario in which a UE uses XRM services using PDU set handling. [Figure 6A] 1 illustrates the existing one-to-one mapping between PDU sets and QoS flows in a non-access stratum (NAS), and one-to-one mapping between QoS flows and data radio bearers (DRBs) in an application server (AS). [Figure 6B] 1 illustrates the existing one-to-one mapping between PDU sets and QoS flows in a NAS and the possible multiplexing of QoS flows in an AS. [Figure 6C] 1 illustrates the existing possible multiplexing of a set of PDUs within one QoS flow in a NAS and the one-to-one mapping between QoS flows and DRBs in an AS. [Figure 6D] 1 illustrates existing possible multiplexing of PDU sets within one QoS flow in a NAS and demultiplexing of types of PDU sets from QoS flows to multiple DRBs in an AS. [Figure 7] Illustrates a QoS model where traffic of one particular media type corresponds to a particular IP flow. [Figure 8] FIG. 8 is a messaging diagram of an example scenario of QoS provisioning using, for example, the QoS model of FIG. 7. [Figure 9] A QoS model is illustrated according to which the application layer uses different IP flows for different PDU set types of a media stream. [Figure 10]A QoS model is illustrated, according to which the application layer uses the same IP flow for different PDU set types of a media stream, and the SMF binds one SDF to multiple QoS flows for different PDU set types. [Figure 11A] Illustrate a QoS model, according to which the application layer uses the same IP flow for different PDU set types of a media stream, and the SMF binds one SDF for different PDU set types to one QoS flow with multiple sub-QoS flows. [Figure 11B] 11A illustrates a QoS model similar to that of FIG. 11A, but in which the UPF identifies each sub-QoS flow based on detected packet header information. [Figure 12] 1 is a flowchart of an example method for generating a PDU set configuration in an AS or AF. [Figure 13] 10 is a flowchart of an example method for processing PS-Importance Configuration policies in an SMF. [Figure 14] 1 is a flowchart of an example method for generating an N4 message for a UPF, which may be implemented in an SMF. [Figure 15] 1 is a flowchart of an example method for providing QoS rules to a UE, which may be implemented in an SMF. [Figure 16] 1 is a flowchart of an example method for supporting QoS flows based on PDU sets that may be implemented in an SMF. DETAILED DESCRIPTION OF THE INVENTION

[0019] The devices and logical entities discussed below improve the existing end-to-end QoS flow model to efficiently accommodate XRM services based on PFU Set QoS Parameters and PDU Set Identification Information.

[0020] In particular, the solution discussed below includes a reference QoS model for QoS provisioning between a UE and a PSA UPF. According to one implementation of the reference QoS model, traffic of one specific media type with specific QoS requirements 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 a Session Management Function (SMF) binds one Service Data Flow (SDF) to multiple QoS flows for the 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 one SDF for the different PDU set types to one QoS flow with multiple sub-QoS flows.

[0021] In some implementations, a network node may characterize each Sub-QoS flow by a PDU Set Type, a PDU Set Importance Level, or both, based on information detected by the UPF from upper layers of the packet header. For example, for RTP / SRTP-based media streams, the characterization may be based on bits included in existing RTP / SRTP extension headers or new extension headers, and for slice-based media streams, the characterization may be based on NAL bits in the Network Abstraction Layer header.

[0022] 1 , an example wireless communication system 100 may implement one or more of the techniques of this disclosure to support PDU set-based handling of traffic, particularly uplink traffic from a UE. The example 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) network. The base stations 104 and 106 may operate within a RAN 105 connected to the CN 110. The CN 110 may also be implemented as a sixth generation (6G) core or other suitable core network.

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

[0024] The several NFs that make up the CN 110 are discussed below with reference to Figures 3 and 4. One or more of the NFs of the CN 110 implement a PDU set controller 112, which determines how and when to provide the UEs 102A and 102B with information related to uplink PDU set-based handling.

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

[0026] The base station 104 comprises processing hardware that may include one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable memory that stores instructions (not shown) for execution by the one or more general-purpose processors. Additionally or alternatively, the processing hardware may include special-purpose processing units.

[0027] The UE 102A includes processing hardware 130A, which may include one or more general-purpose processors, such as a CPU, non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The UE 102A also includes a transceiver 132A for communicating with the RAN 105 over a radio interface. Furthermore, the UE 102A includes memory 134A that stores a PDU set controller 140A. An example application 142 can use the PDU set controller 140A to operate on PDU sets. For example, the application 142 can set RTP headers to utilize PDU set-based processing. The UE 102B can have a similar implementation.

[0028] 2 illustrates, in a simplified manner, an example protocol stack 200 according to which a UE 102 can communicate with an eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106). In the example stack 200, a EUTRA physical layer (PHY) 202A provides transport channels to a EUTRA MAC sublayer 204A, which in turn provides logical channels to a EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides RLC channels to a EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, an NR PHY 202B provides transport channels to an NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide data transfer services to a Service Data Adaptation Protocol (SDAP) 212 or a Radio Resource Control (RRC) sublayer (not shown in FIG. 2). In some implementations, the UE 102 supports both the EUTRA stack and the NR stack as shown in FIG. 2 to support handover between EUTRA and NR base stations and / or to support DC over the EUTRA and NR interfaces. Furthermore, as illustrated in FIG. 2, the UE 102 can support layering of the NR PDCP 210 over the EUTRA RLC 206A and the SDAP sublayer 212 over the NR PDCP sublayer 210.

[0029] 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, layered directly or indirectly on the PDCP layer 208 or 210) and output packets that may be referred to as protocol data units (PDUs) (e.g., to the RLC layer 206A or 206B). For simplicity, this disclosure will refer to both SDUs and PDUs as "packets," except where the distinction between SDUs and PDUs is relevant.

[0030] On the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide a signaling radio bearer (SRB) or an RRC sublayer (not shown in FIG. 2) to exchange, for example, RRC messages or non-access stratum (NAS) messages. On the user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide a data radio bearer (DRB) to support data exchange. The data exchanged on the NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0031] Figure 3 is a service-based representation 300 of a 5GS architecture that the system of Figure 1 may implement. In representation 300, the overall non-roaming reference architecture of the Policy and Charging Control (PCC) framework for 5GS includes components illustrated using solid lines, and other components illustrated using dashed lines. According to this representation, network functions enable other authorized network functions to access their services. Components outside the PCC framework include a Network Slicing 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 the UE 102, the RAN 105, and a data network (DN) 330. An application server (AS) 390 can operate within the DN 330.

[0032] 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.

[0033] When the UPF 370 acts as a PDU Session Anchor (PSA) UPF to support PDU-set-based QoS handling for XRM services, the PSA UPF 370 identifies PDUs belonging to a PDU set and determines subsequent PDU set information, for example, based on an RTP extension header defined in 3GPP TS 26.522 that the PSA UPF 370 sends 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, for example). The PDU set information can include (i) PDU Set Sequence Number, (ii) Indication of End PDU of the PDU set, (iii) PDU Sequence Number within the PDU set, (iv) PDU Set Size in bytes, and (v) PDU Set Importance, which identifies the relative importance of the PDU set compared to other PDU sets within the QoS flow. NG-RAN may use the Priority Level across QoS flows and the PDU Set Importance within a QoS flow for PDU set level packet discarding in case of congestion.

[0034] Figure 4 is a reference point-based representation 400 of the 5GS architecture. In Figure 4, the non-roaming reference architecture of the PCC framework for 5GS is illustrated as solid blocks and connections, while components and connections outside the PCC framework are illustrated using dashed lines.

[0035] Referring to scenario 500 of Figure 5, during the registration procedure 510, the AMF determines whether the UE 102 is authorized to use the XRM service based on the UE's XRM Service Capability and the XRM Service Authorization included in the subscription data received from the UDM. After successful registration 510, the UE requests a PDU Session Establishment procedure (520), and the XRM service-capable NG-RAN can perform PDU set handling for the 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 from the UPF over the N3 interface. The UE or the network initiates a PDU Session Modification Procedure (530) for the existing PDU session.

[0036] The SMF determines the QoS Profile for the QoS flow based on the received Policy Control and Charging (PCC) rule or pre-configuration. The PSA UPF performs the following: (i) identifying PDUs belonging to a PDU set based on the Protocol Description based on the received Packet Detection Rule (PDR), (ii) marking the GTP-U header for PDU set information as described in clause 5.37.5.2 of TS 23.501, and (iii) enforcing parameters based on the PDU set based on the received QoS Enforcement Rule (QER).

[0037] The network instructs the UE by uplink PDU set-based handling information to perform PDU set-based handling including PDU set identification and marking for the uplink media service data flow received from the upper layer providing the NG-RAN in the band uplink PDU set information.

[0038] According to one implementation aspect, the RAN 105 performs PDU set-based QoS handling for radio resource management based on the following information: (i) Uplink PDU Set Information received from the UE over the air interface, and (ii) a QoS profile containing uplink PDU set-based QoS parameters.

[0039] The uplink PDU set information may include one or more of: (i) a PDU set sequence number; (ii) an indication of the end PDU of the PDU set; (iii) a PDU sequence number within the PDU set; (iv) a 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 in the QoS flow.

[0040] Next, several example types of mapping of PDUs to QoS flows are considered with reference to Figures 6A-D, which correspond to different combinations of one-to-one mapping and multiplexing / demultiplexing between PDU sets, QoS flows, and DRBs.

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

[0042] According to the example model of Figure 6B, the RAN 105 needs enhancements to multiplex different QoS flows with different PDU set QoS requirements and map them to one DRB based on the following assumptions: the CN 110 binds different types of PDU sets to different QoS flows, and one QoS profile includes multiple sets of QoS parameters for multiple QoS flows. Here, a specific solution is needed for the RAN 105 to determine whether to map multiple QoS flows to the same DRB or different DRBs based on the PDU set-based QoS requirements.

[0043] According to the example model of Figure 6C, the RAN 105 needs a mechanism to demultiplex different sub-QoS flows within a QoS flow and map the sub-QoS flows to different DRBs based on the following assumptions: the CN 110 binds different types of PDU sets to different sub-QoS flows, and one QoS profile contains multiple sets of QoS parameters for multiple sub-QoS flows. A solution is needed that allows the RAN 105 to decide whether to map sub-QoS flows to the same or different DRBs based on the QoS requirements based on the PDU sets.

[0044] Next, based on PDU set QoS parameters and PDU set identification information, several techniques for enhancing the existing end-to-end QoS flow model to accommodate XRM services are discussed with reference to FIGS.

[0045] At least some of the techniques discussed below rely on one or more of the following assumptions: an IP flow represents an IP5 tuple and the SDF contains packet filters that define application traffic for mapping to QoS flows; 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 encompasses one or more sub-QoS flows; one or more QoS flows can be associated with one PDU session; and a PDU Session Resource Setup Request can be implemented as an N2 PDU Session Request message as defined in TS 23.502, clauses 4.3.2 and 4.3.3.

[0046] Referring to FIG. 7, a reference QoS model 700 illustrates an example QoS provisioning between a UE, such as UE 102, and a PSA UPF, such as UPF 370.

[0047] Using the QoS model 700, an application (e.g., application 142) requests QoS requirements on a per-PDU basis for a specific SDF (IP flow traffic) of one media type, e.g., video, voice, or XR. The SMF 366 can perform QoS binding of the SDF from one IP flow to one QoS flow for each media type and send the corresponding QoS profile to the RAN 105. Each QoS profile can be associated with one QFI and QoS parameters for one 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 mapping of one or more QoS flows to one DRB. In other words, the RAN 105 can implement a one-to-one mapping.

[0048] Generally speaking, the communication system 100 can implement the following series of high-level procedures or steps (discussed in more detail below with reference to FIG. 8 ) to support traffic using the QoS model 700: (i) in step A associated with the IP layer 710, an application (e.g., application 142) requests different QoS requirements from the CN 110 for each IP flow traffic of one media type, e.g., video, voice, XR; 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 sends a QoS profile to the RAN 105, where the QoS profile indicates the QFI and the QoS parameters; and in step E associated with the RAN SDAP layer 730, the RAN 105 performs mapping between the QoS flow and the DRB.

[0049] In particular, with continuing reference to FIG. 7, the RAN 105 may perform a mapping from QoS Flow 1 to DRB1 and from QoS Flow 2 to DRB2 for each corresponding QFI according to scenario 702, or may perform a mapping from QoS Flow 1 to DRB1 and from QoS Flow 2 to DRB2 according to scenario 704.

[0050] FIG. 8 is a messaging diagram of an example scenario 800 in which events 802, 810, 812, 820, 850, and 852 correspond generally to step A discussed above with reference to the QoS models of FIGS. 7 and 9-12; events 840 and 842 correspond generally to step B; events 860 and 862 correspond generally to step C; events 870 and 872 correspond generally to step D; and events 882-884 correspond to step E.

[0051] At the beginning of scenario 800, UE 102, SMF 366, and UPF 370 perform 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) (802).

[0052] The AS 390 sends a request to enable PDU set handling in the 5G network for the XRM service (810). The AF 358 then sends information including PDU set-related QoS requirements and PDU set configuration information to the PCF 360 via an AF request message (812). 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 and 812 may occur before the UE 102 performs PDU session establishment (802).

[0053] The PCF 360 then generates appropriate PCC rules, which may include or be based on the PDU set-related QoS parameters and PDU set configuration information. The PCF 366 can generate the PCC rules using the information received (812) from the AF 358. The PCF 360 sends (820) the PCC rules (PCC rules as parameters) to the SMF 366 via an SM Policy Association Establishment / Modification message.

[0054] The SMF 366 performs QoS flow binding with the SDF (830). The SDF can be associated with a packet filter set, such as an IP5 tuple, and can correspond to an IP flow. The SMF 366 then generates an N4 message with N4 rules based on the PCC rules received from the PCF 360 (842) and sends the N4 message to the UPF 370 (842).

[0055] 8 , the SMF 366 generates 860 a QoS profile(s) based on the PCC rules received from the PCF 360. The SMF 366 further provides 860 the QoS profiles to nodes in the RAN 105 via the AMF 364. In particular, the SMF 366 may send a Namf_Communication_N1N2MessageTransfer message to the AMF 364, the message including one or more of: (i) a PDU Session ID; (ii) N2 SM information (e.g., PDU Session ID, QFI(s), QoS Profile(s)); or (iii) an N1 SM container (NAS message). The NAS message may be a PDU Session Establishment Accept message, where the PDU Session Establishment Accept message includes the QoS rule(s) and associated QoS Flow level QoS parameters. The AMF 364 may then send an N2 PDU session request message containing the NAS message to the RAN 105 for delivery to the UE 102 (860).

[0056] The SMF 366 provides 862 the QoS rules to the UE 102 using the remaining steps of the PDU Session Establishment procedure or the PDU Session Modification procedure, depending on the procedure that the UE 102 previously initiated 802. To configure 862 the UE 102, the RAN 105 can use, for example, an RRC Connection Reconfiguration procedure. The RAN 105 can provide configuration parameters based on information received from the SMF 366 to generate the necessary NG-RAN resources associated with the QoS rules for the received PDU session request. For example, the RAN 105 can provide an SDAP-config configuration to the UE 102, where the SDAP-config configuration includes a mapping list of DRBs with assigned lists of QoS flows according to a one-DRB-to-many QoS flow allocation scheme for uplink communications, downlink communications, or both.

[0057] When the XRM media traffic is available for transmission to the UE 102, the AS 390 performs AS operations on the XRM media traffic for delivery over the 5G network (850) and sends the DL packet to the UPF 370 over the N6 interface (852).

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

[0059] The RAN 105 then performs 880 PDU set-based QoS handling, maps the QoS flow(s) to the DRB(s), and uses the DRB(s) to transmit 882 DL packets over the NR_Uu interface to the UE 102. For this purpose, the RAN 105 uses the PDU set-related information in the GTP-U header received over the N3 interface, the QoS profile, and the PDU set configuration information received from the SMF 366 over the N2 interface.

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

[0061] 9, the reference QoS model 900 differs from the reference QoS model 700 of FIG. 7 in the mapping between SDFs (e.g., IP flows) and PDUs. Unlike 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 a media stream.

[0062] In particular, in accordance with the reference QoS model 900, the AS 390 separates frames or slices corresponding to different PDU set types of the same media type, e.g., video, into different IP flows that may have the same IP address but, for example, different ports.

[0063] The AS 390 can generate a request including a PDU set configuration that the RAN 105 can use for PDU set-based scheduling (see, e.g., event 810). The request can also include different QoS requirements for different IP flows and aggregated QoS requirements for IP flows that belong to the same media stream. The RAN 105 can then perform PDU set-based scheduling and handling of QoS flows for each PDU set type based on the QoS profiles that belong to the same media stream type.

[0064] The AF 358 can request QoS requirements (see, for example, event 812), which include PDU set-based QoS (PS-QoS) parameters for binding QoS flows to SDF / IP flows associated with the same media stream, and a QoS Flow Correlation Id. The PS-QoS parameters may include one or more of: (i) PDU Set Delay Budget (PSDB), (ii) PDU Set Error Rate (PSER), which may be an aggregation of different causes including PDU Set Dropping Rate (PSDR), (iii) PDU Set Type, e.g., PSDR, which defines the PDU Set dropping rate expected by the application for I / P / B frames, or PDU Set Importance Level, which binds the SDF to the QoS flow(s), (iv) PDU Set Priority, (v) PDU Set Periodicity, and (vi) PDU Set Integrated Indication, which may be an indication of whether the application layer requires all of the PDUs to use the PDU set. QoS Flow Correlation Id serves to correlate IP flows belonging to the same media stream and is a parameter specified by AS390.

[0065] The communication system 100 can implement a series of high-level procedures or steps discussed below for supporting traffic using the QoS model 900 (see also FIG. 8). In step A, the AS390 application server transmits IP flows based on the PDU set type. PS-QoS requirements are applied on a per IP flow basis. The AF358 requests different QoS requirements for each IP flow, so that each set of QoS requirements corresponds to one respective IP flow, and each IP flow is associated with one PDU set type.

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

[0067] Next, in step C, the SMF 366 sends the QoS profile to the RAN 105 over the N2 interface. The QoS profile may include one or more of the PS-QoS parameters, the QFI, the QoS flow correlation ID, and the PDU session ID. The SMF 366 may use the QoS flow correlation ID to map QoS flows belonging to the same media stream to one PDU session ID. In one implementation, if one PDU session applies to a specific XRM media type, for example, video, the SMF 366 does not send the QoS flow correlation ID to the RAN 105.

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

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

[0070] In another implementation, the PDU set configuration includes a PDU set flow descriptor (e.g., an IP5 tuple) and a PST indication configuration policy that the AS390 can use to inform the SMF366 of the PDU set type that the application uses for the IP flow of the media stream.

[0071] In yet another implementation, the PDU set configuration additionally 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 that includes the PS-importance configuration policy, which enables the UPF 370 to determine the PS-importance level based on the upper layer packet header, for example, depending on the I bit, D bit, both 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 a PDU within a QoS flow or sub-QoS flow, which is different from the PDU set priority included in the PS-QoS parameters. Furthermore, in step C, the SMF 366 can use the PS-importance configuration policy to inform the RAN 105 of the PS-importance level, for example, high / medium / low or the digitization level, to be marked in the UPF 370.

[0072] Referring to FIG. 10, the reference QoS model 1000 differs from the reference QoS models 700 and 900 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 the media stream, and the SMF 366 binds one SDF to multiple QoS flows for different PDU set types.

[0073] In particular, when using the reference QoS model 100, the AF 358 generates a request containing a PDU set configuration that the SMF 366 can use to configure the UPF 370 to identify and mark arriving PDUs and to configure the RAN 105 to handle PDU set-based scheduling. The request can also include QoS requirements within the same IP flows 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.

[0074] Furthermore, the N2 message sent 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 for the DRBs based on one or more QoS profiles associated with multiple QFIs and PS-QoS parameters.

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

[0076] Furthermore, when using the reference QoS model 1000, the SMF 366 can generate a QoS flow correlation ID for correlating QoS flows that belong to the same media stream.

[0077] The communication system 100 can implement a series of high-level procedures or steps discussed below for supporting traffic using the QoS model 1000 (see also FIG. 8 ). In step A, the AS 390 transmits an IP flow for a media stream, e.g., video. The AS 390 marks each media unit in a (new) dedicated extended RTP header or an N6 tunnel header for encrypted traffic, in addition to the RTP / SRTP extension header. The AS 390 can mark using a PDU set indication, which the UPF 380 uses to distinguish PDUs that require PDU set handling in 5GC. The AF 358 requests PDU set configurations and QoS requirements for the IP flow of the media stream. For this purpose, the AF 358 can specify aggregated QoS parameters for the media stream and PDU set-based QoS requirements for each PDU set type as part of the QoS requirements.

[0078] 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.

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

[0080] In other implementations, the SMF 366 transmits multiple QoS profiles with different granularity. The QoS profiles can include an aggregated QoS profile for each media stream identified by a QoS flow correlation ID, which in turn includes the QoS flow correlation ID, aggregated QoS parameters, a PDU session ID, and an optional list of QFIs associated with the QoS flow correlation ID. The QoS profiles can also include QoS flow-specific QoS profiles, which include the QFI, the QoS flow correlation ID, and the PS-QoS parameters.

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

[0082] 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 can perform mapping from QoS Flow 1 to DRB 1 and from QoS Flow 2 to DRB 2 for each corresponding QFI according to scenario 1002, or can perform mapping from QoS Flow 1 to DRB A and from QoS Flow 2 to DRB A for each corresponding QFI according to scenario 1004.

[0083] Referring to FIG. 11A, the reference QoS model 1100A differs 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 the media stream, and the SMF 366 binds one SDF for different PDU set types to one QoS flow with multiple sub-QoS flows.

[0084] Similar to the approach discussed with reference to Figure 10, the AF 358 generates a request containing a PDU set configuration that the SMF 366 can use to configure the UPF 370 to identify and mark arriving PDUs and to configure the RAN 105 to handle PDU set-based scheduling. Also similar to the approach of Figure 10, the request can contain QoS requirements within the same IP flows belonging to the same media stream. However, here the SMF 366 binds one or more SDFs to multiple sub-QoS flows based on the PDU set type and the received PDU set configuration.

[0085] The N2 message sent 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 for the DRB based on one or more QoS profiles associated with one QFI and multiple sub-QoS flows (with different XQFIs), as well as PS-QoS parameters.

[0086] The AF 358 can request QoS requirements and include the following parameters for the same media stream in the request: aggregated (or unified) QoS parameters for service data flows (IP5 tuples) associated with one QFI, and / or PS-QoS parameters per PDU set type or per sub-QoS flow. The aggregated QoS parameters and PS-QoS parameters can include elements similar to those discussed above with reference to FIG. 10.

[0087] To support traffic using QoS model 1100A, communication system 100 can implement a series of high-level procedures or steps similar to those discussed above with reference to QoS model 1000, with the following modifications.

[0088] 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 358. The SMF 366 configures the UPF 370 based on the PDU set configuration.

[0089] In step C, the SMF 366 generates and uses the QFI to map sub-QoS flows belonging to the same media stream to one PDU Session ID, and then sends the QoS profile over the N2 interface to the RAN 105. In one such implementation, one QoS profile includes: (i) aggregated QoS parameters associated with the QFI, (ii) PS-QoS parameters associated with the XQFI, and (iii) a PDU Session ID.

[0090] In other implementations, the SMF 366 transmits multiple QoS profiles with different granularities. The QoS profile may include a QoS profile associated with one QFI, including a QFI, aggregated QoS parameters, a PDU session ID, and (optionally) a list of XQFIs associated with the QFI. The SMF 366 also transmits a QoS profile per sub-QoS flow basis, where the QoS profile includes a QFI, an XQFI, and PS-QoS parameters. The XQFI may identify a sub-QoS flow.

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

[0092] 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 performs mapping from sub-QoS flow 1 to DRB 1 and from sub-QoS flow 2 to DRB 2 for each corresponding QFI+XQFI according to scenario 1102A, or performs mapping from sub-QoS flow 1 to DRB A and from sub-QoS flow 2 to DRB A for each corresponding QFI according to scenario 1104A.

[0093] According to another approach discussed with reference to FIG. 11B, the UPF 370 identifies each sub-QoS flow based on detected packet header information. The communication system 100 can also support sub-QoS flows within a QoS flow and rely on a QoS model 1100B similar to the QoS model 1100A to provide PDU set information with different granularity to the RAN 105. However, according to the technique discussed with reference to FIG. 11A, the SMF 366 defines each sub-QoS flow during the procedure of binding an SDF to a QoS flow. Each sub-QoS flow obtains an XQFI during this procedure. According to the technique of FIG. 11B, the UPF 370 identifies each sub-QoS flow based on detected packet header information.

[0094] In particular, for QoS model 1100A, UPF 370 is configured with QoS flows identifiable by QFIs and sub-QoS flow information corresponding to XQFI(s). 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 RAN 105 relies on the QoS profile with the corresponding QFI and XQFI for PDU scheduling and DRB mapping.

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

[0096] In one implementation, the UPF 370 uses a PDU Set Identification, an RTP / SRTP extension header type, to identify PDU sets. For each DL PDU received over the N6 or N19 interface, for which the service protocol has been determined, the UPF 370 applies the rules for PDU Set Identification to determine PDU Set Information. The UPF 370 provides the PDU Set Information to the RAN 105 in a GTP-U header. The PDU Set Information may include: a PDU Set Sequence Number, which is a cyclic counter incremented for each PDU set instance; an End of PDU Set PDU, 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 in the PDU set and reset at PDU set boundaries; a PDU Set Size in bytes; and a PDU Set Importance, which identifies the importance of the PDU set within the QoS flow.

[0097] As indicated above, a QoS flow can include multiple sub-QoS flows. In one implementation consistent with QoS model 11000B, each sub-QoS flow is associated with a specific PDU set type. In other words, each sub-QoS flow is for a set of PDUs with the same PDU set type. In another implementation, each sub-QoS flow is associated with a specific PDU set importance level, such that a particular sub-QoS flow is for a set of PDUs 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 particular sub-QoS flow is for a set of PDUs with the same PDU set importance level and the same PDU set type.

[0098] Thus, the RAN 105 can identify sub-QoS flows based on the PDU set importance level, the PDU set type, or both. The UPF 370 can provide a value in the GTP-U header when transmitting a PDU over the N3 interface. The UPF 370 detects the PDU and determines which sub-QoS flow the PDU belongs to using one of the example approaches discussed below.

[0099] 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 upper-layer packet headers. For example, for I / P / B frames, the PDU set importance level can depend on the I bit, the D bit, 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 PDU set type can depend on specific NAL bits in the existing NAL header or the special-purpose (new) extended NAL header.

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

[0101] 11A and 11B, the AF 358 can generate a request containing a PDU set configuration that the SMF 366 can use to configure the UPF 370 to identify and mark arriving PDUs in GTP-U headers, which the UPF 370 then sends to the RAN 105 to handle PDU set-based scheduling. The request from the AF 358 can include QoS requirements to be applied within the same IP flow belonging to the same media stream. The SMF 366 binds one or more SDFs to one QoS flow, which encompasses multiple sub-QoS flows. The UPF 370 can detect and identify each sub-QoS flow based on the XQFI assigned by the SMF (matched to QoS model 1100A), or the PDU set type detected by the UPF 370 (matched to QoS model 1100B, PDU set type option), or the PDU set importance level detected by the UPF 370 (matched to the PDU set configuration from QoS model 1100B, SMF 366 option), or the PDU set importance level with the PDU set type detected by the UPF 370 (matched to QoS model 1100B, PDU set importance level, and PDU set type option).

[0102] Further, with respect to the models of Figures 11A and 11B, the N2 message traveling from CN 110 to RAN 105 can include a PDU set-based QoS profile encompassing PDU set QoS parameters for each sub-QoS flow, and RAN 105 can identify sub-SoS flows by XQFI (matched to QoS model 1100A), PDU set type (matched to QoS model 1100B, local configuration option), PDU set importance level (matched to PDU set configuration from QoS model 1100B, SMF366 option), or PDU set importance level and PDU set type (matched to QoS model 1100B, PDU set importance level and PDU set type options).

[0103] The RAN 105 performs PDU set-based scheduling for the DRBs based on the PDU set-based QoS profile received from the SMF 366 and the GTP-U header of the PDU received from the UPF 370 over the N3 interface.

[0104] The AF 358 can request QoS requirements, including parameters for the SDF (e.g., IP5 tuple) of the media stream. The SDF corresponds to the QFI that the SMF 366 assigns after QoS. The aggregated (or consolidated) QoS parameters can include one or more of: (i) aggregated PSDB, (ii) aggregated PSER, or (iii) aggregated PDU set periodicity. The PS-QoS parameters per sub-QoS flow can include: (i) PSDB, (ii) PSER, which can correspond to an aggregation of causes including PSDR, (iii) PDU set periodicity, (iv) PSDR, or (v) PDU set consolidated indication.

[0105] When the QoS requirements encompass both aggregated / integrated QoS parameters and PS-QoS parameters per sub-QoS flow, the SMF 366 can configure a QoS profile (for transmission to the RAN 105) based on the PDU set with the aggregated QoS parameters and PS-QoS parameters per sub-QoS flow.

[0106] Based on the PDU set configuration information, when the QoS requirements include only aggregated / aggregated QoS parameters, the PCF 370 and / or SMF 366 can determine the referenced PS-QoS parameters for each sub-QoS flow corresponding to (i) the XQFI (matched to the QoS model 1100A), or the PDU set type (matched to the QoS model 1100B, PDU set type option), the PDU set importance level (matched to the QoS model 1100B, PDU set importance level option), or the PDU set importance level and the PDU set type (matched to the QoS model 1100B, PDU set importance level and PDU set type options). When the QoS requirements include only aggregated / aggregated QoS parameters, the SMF 366 can configure a PDU set-based QoS profile (for transmission to the RAN 105) with the aggregated QoS parameters and the referenced PS-QoS parameters for each sub-QoS flow.

[0107] Based on the information in the PDU set configuration, when the QoS requirements encompass only PS-QoS parameters per sub-QoS flow, the PCF 366 and / or SMF 366 can determine aggregated (or unified) QoS parameters, such as aggregated PSDB, aggregated PSER, or aggregated PDU set periodicity. In this case, the SMF 366 configures a QoS profile based on the PDU set using the aggregated QoS parameters and PS-QoS parameters specified on a per sub-QoS flow basis.

[0108] 11B, one QoS flow can include multiple sub-QoS flows. At least three options are available for characterizing each of the sub-QoS flows: According to the PDU Set Type option, each sub-QoS flow is for a PDU set with the same PDU set type. For example, sub-QoS flow 1 is for an I-frame, and sub-QoS flow 2 is for a B-frame. According to the PDU Set Importance Level option, each sub-QoS flow is for a PDU set with the same PDU set importance level. For example, sub-QoS flow 1 is for a PDU set with importance level 1, and sub-QoS flow 2 is for a PDU set importance level 2. According to the PDU Set Importance Level and PDU Set Type options, each sub-QoS flow is for a PDU set associated with the same PDU set importance level and PDU set type. For example, sub-QoS flow 1 is for an I-frame with PDU set importance level 1, and sub-QoS flow 2 is for an I-frame with PDU set importance level 2.

[0109] To support traffic using QoS model 1100B, communication system 100 may implement a series of high-level procedures or steps similar to those discussed above with reference to QoS model 1110A, with the following modifications.

[0110] In step B, the SMF 366 performs QoS binding from one IP flow to one QoS flow and configures the UPF 370 based on the PDU set configuration and QoS requirements received from the AF 358. A QoS flow may include multiple sub-QoS flows according to at least the following options that the UPF 370 may implement, as discussed above: (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 options, each sub-QoS flow is for a PDU set associated with the same PDU set importance level and PDU set type.

[0111] In step C, the SMF 366 generates and uses a QFI to map the service data flow of the media stream to one PDU Session ID, determines QoS parameters, and sends the QoS profile including the QoS parameters over the N2 interface to the RAN 105. 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 one QoS profile, and the QoS profile includes the PDU Session ID, the QFI, the aggregated QoS parameters, and the PS-QoS parameters on a per sub-QoS flow basis (according to one of the PDU Set Type option, the PDU Set Importance Level option, or the PDU Set Importance Level and PDU Set Type options discussed above); according to scenario 1104B, one QoS flow is associated with multiple QoS profiles, the QoS profile corresponds to the QFI, and the QoS profile includes the QFI, the aggregated QoS parameters, and the PDU Session ID. Furthermore, according to the latter option, the sub-QoS profile per sub-QoS flow basis can be based on one of the PDU set type option, the PDU set importance level option, or the PDU set importance level and PDU set type options. The sub-QoS profile can include correlated QFIs, PDU set types and / or PDU set importance levels, and PS-QoS parameters.

[0112] In step D, when the UPF 370 detects a PDU marked with a PS indication and (optionally) a PST indication 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. The PDU set information may include 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, as well as the PDU set importance level and / or PDU set type according to one of the PDU set type option, the PDU set importance level option, or the PDU set importance level and PDU set type option. The UPF 370 then transmits the PDU with the GTP-U header to the RAN 105.

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

[0114] An example technique for generating a PDU set configuration will now be discussed with reference to Figure 12. The method 1200 can be implemented, for example, in the AS 390 and / or the AF 358. For convenience, the method will be discussed with reference to the application layer.

[0115] In block 1202, the application layer generates a PDU set indication to the SMF 366, indicating that the SMF 366 should apply PDU set integrated handling to the service data flow. In block 1210, the application layer generates a PDU set flow description in the UPF, indicating the RTP / SRTP extension header type that the UPF 370 should use for PDU set identification. In block 1220, the application generates a PDU set type indication (PST indication) that indicates the PST type used by the application for the media stream. The SMF 366 and / or UPF 370 use the PDT indication to distinguish PDU set types and associate them with different respective QoS flows when the application applies a specific PST indication configuration policy (e.g., when the application uses a specific upper layer packet header). When the AF 358 does not specify a PST indication, the SMF 366 and the UPF 370 use a reconfiguration setting based on a standard value or based on an RTP / SRTP extension header or a NAL header.

[0116] In some implementations, the method 1200 further includes optional block 1230, in which 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 in the SMF 366. The SMF 366 can use the PS-importance configuration policy to configure the UPF 370 with PDU set marking rules that include the PS-importance configuration policy, which enables the UPF 370 to determine the PS-importance level based on upper layer packet headers, for example, depending on the I-bit, D-bit, or both D-bits, or other bits, or NAL bits in the RTP / SRTP extension header or a new extended RTP header.

[0117] 13, the method 1300 may be implemented in the SMF 366, for example, to process a PS-importance configuration policy. In block 1302, the SMF 366 receives the PS-importance configuration policy, for example, from the AF 358 or the AS 390. In block 1304, the SMF 366 may use the PS-importance configuration policy to configure the UPF 370 with PDU set marking rules that include the PS-importance configuration policy.

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

[0119] In block 1306, the SMF 366 notifies the RAN 105 of the PDU set type (e.g., I / P / B frame or slice) marked by the UPF 370 along with the PS-importance level (e.g., high, medium, or low, or an appropriate set of discrete levels). The PS-importance level overrides local configuration in the RAN 105.

[0120] 14, the SMF 366 may implement an example method 1400 for generating an N4 message to the UPF 370 for PDU set handling for transmission over the N4 interface. The SMF 366 may perform the method 1400 in step B of the scenario discussed above with reference to the QoS model.

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

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

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

[0124] In block 1404, the SMF 366 sends an N4 message to the UPF 370.

[0125] 15 is a messaging diagram of an example method 1500 that the SMF 366 may implement to provide QoS rules to the UE 102, for example, during a PDU session establishment or modification procedure. The SMF 366 may modify or augment existing QoS flow descriptions, as discussed below, to enable the UE 102 to handle QoS flows based on PDU sets.

[0126] In block 1502, the SMF 366 can include a PDU set indication in a UE message. The SMF 366 can provide the PDU set indication along with the QoS rule, including the QoS Rule Identifier (QRI), QoS rule length, rule operation code, default QoS rule (DQR) bit, number of packet filters, packet filter list, packet filter priority, and QFI. The SMF 366 can also provide, in the same or a separate message, the QoS flow description, including the QFI, and operation code (create, modify, delete), QoS parameters (5QI, GFBR / MFBR uplink / downlink, averaging window, EPS bearer ID), etc.

[0127] Next, in block 1504, the SMF 366 may include additional QoS parameters for the PDU set, including one or more of (i) PDFB, (ii) PSER, or (iii) aggregated PDU set periodicity, for the aggregated (or consolidated) QoS associated with one QFI.

[0128] For PS-QoS parameters per PDU set type or sub-QoS flow of a QoS flow (corresponding to a particular QFI), which can identify sub-QoS flows based on XQFI (according to QoS model 1100A), PDU set importance level (according to QoS model 1100B), or PDU set type (according to QoS model 1100B), SMF 266 can include in the UE message one or more of: (i) PSDB; (ii) PSER, which can be an aggregation of different causes 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 consolidated indication.

[0129] In block 1506, the SMF 366 sends a UE message to the UE 102.

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

[0131] The following explanations may be applied to the above explanations.

[0132] In some embodiments, "message" is used and can be replaced with "information element (IE)." In some embodiments, "IE" is used and can be replaced with "field." In some embodiments, "configuration" can be replaced with "configurations" or configuration parameters.

[0133] A user device (e.g., UE 102) capable of implementing the techniques of this disclosure may be any suitable device capable of wireless communication, such as a smartphone, tablet computer, laptop computer, mobile game console, point-of-sale (POS) terminal, health management device, drone, camera, media streaming dongle or other personal media device, wearable device such as a smart watch, wireless hotspot, femtocell, or broadband router. Furthermore, a user device may in some cases be embedded in an electronic system such as a vehicle head unit or advanced driver assistance system (ADAS). Furthermore, a user device may operate as an Internet of Things (IoT) device or a mobile internet device (MID). Depending on the type, a user device may include one or more general-purpose processors, computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

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

[0135] If implemented in software, the techniques may be provided as part of an operating system, a library used by multiple applications, a specific software application, etc. The software may be executable by one or more general-purpose processors or one or more special-purpose processors.

Claims

1. 1. A method in a core network (CN) of a wireless communication system, comprising: receiving quality of service (QoS) parameters related to protocol data unit (PDU) set based handling of traffic; performing QoS binding of a Service Data Flow (SDF) to at least one QoS flow for a particular media type using said QoS parameters; generating a QoS profile associated with a QoS flow identifier (QFI) of the QoS flow for the media type; transmitting the QoS profile to a radio access network (RAN), through which the UE accesses the CN; and A method comprising:

2. The method of claim 1 , wherein receiving the QoS parameters comprises receiving a Policy and Charging Control (PCC).

3. The method of claim 2 , wherein the PCC rule includes a PDU set configuration.

4. The method of any one of claims 1 to 3, wherein performing the QoS flow binding comprises binding the SDF to multiple QoS flows for different respective PDU set types.

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

6. defining the plurality of sub-QoS flows for the duration of the binding; assigning each of the plurality of sub-QoS flows a respective sub-QoS flow ID (XQFI); The method of claim 5 further comprising:

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. 8. The method of claim 1, further comprising configuring a User Plane Function (UPF) with PDU set marking rules.

9. The method of claim 8 , wherein the configuring comprises 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 of claim 9 , further comprising transmitting the PS-importance configuration policy to the RAN.

11. The method according to any one of claims 1 to 10, wherein the SDF includes only traffic of the particular media type.

12. The method of claim 11 , wherein the media type is one of voice, video, or extended reality (XR).

13. The method of any one of claims 1 to 12, wherein the QoS profile is further associated with one or more QoS parameters for the particular media type.

14. The method of any one of claims 1 to 13, wherein the SDF is an Internet Protocol (IP) flow.

15. A device comprising processing hardware and configured to implement the method according to any one of claims 1 to 14.

Images