End of data burst indications

Abstract

In some embodiments, a network node may receive multiple quality of service (QoS) flows. The network node may determine which of the QoS flows correspond with a single data burst, and schedule radio resources based on the QoS flows corresponding with the single data burst. In some embodiments, an end of data burst may be determined for the multiple QoS flows corresponding to the single data burst.

Description

END OF DATA BURST INDICATIONSTECHNICAL FIELD

[0001] This application relates generally to wireless communication systems, including signaling information regarding details of a data burst.BACKGROUND

[0002] Wireless mobile communication technology uses various standards and protocols to transmit data between a base station and a wireless communication device. Wireless communication system standards and protocols can include, for example, 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) (e.g., 4G). 3GPP New Radio (NR) (e.g., 5G), and Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard for Wireless Local Area Networks (WLAN) (commonly known to industry groups as Wi-Fi®).

[0003] As contemplated by the 3GPP, different wireless communication systems' standards and protocols can use various radio access networks (RANs) for communicating between a base station of the RAN (which may also sometimes be referred to generally as a RAN node, an access node, an access network (AN), a network node, or simply a node) and a wireless communication device known as a user equipment (UE). 3GPP RANs can include, for example, Global System for Mobile communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), Evolved Universal Terrestrial Radio Access Network (E- UTRAN), and / or Next-Generation Radio Access Network (NG- RAN).

[0004] Each RAN may use one or more radio access technologies (RATs) to perform communication between the base station and the UE. For example, the GERAN implements GSM and / or EDGE RAT, the UTRAN implements Universal Mobile Telecommunication System (UMTS) RAT or other 3GPP RAT, the E-UTRAN implements LTE RAT (sometimes simply referred to as LTE), and NG-RAN implements NR RAT (sometimes referred to herein as 5G RAT, 5G NR RAT, or simply NR). In certain deployments, the E-UTRAN may also implement NR RAT. In certain deployments, NG-RAN may also implement LTE RAT.

[0005] A base station used by a RAN may correspond to that RAN. One example of an E-UTRAN base station is an Evolved Universal Terrestrial Radio Access Network (E- UTRAN) Node B (also commonly denoted as evolved Node B, enhanced Node B, eNodeB, or eNB). One example of an NG-RAN base station is a next generation Node B (also sometimes referred to as a g Node B or gNB).

[0006] A RAN provides its communication services with external entities through its connection to a core network (CN). For example, E-UTRAN may utilize an Evolved Packet Core (EPC) while NG-RAN may utilize a 5G Core Network (5GC).BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0007] To easily identify the discussion of any particular element or act. the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

[0008] FIG. 1 illustrates a network environment in accordance with some embodiments.

[0009] FIG. 2 illustrates a Data Burst that may be transmitted between the application layers to exchange application data in accordance with some embodiments.

[0010] FIG. 3 illustrates time sensitive communication assistance information (TSCAI) in accordance with some embodiments.

[0011] FIG. 4 illustrates a TSC assistance container in accordance with some embodiments.

[0012] FIG. 5 illustrates a one-byte RTP header extension format in accordance with some embodiments.

[0013] FIG. 6 illustrates a two-byte RTP header extension format in accordance with some embodiments.

[0014] FIG. 7 illustrates a QoS classification operation of the network environment for a single downlink flow in accordance with some embodiments.

[0015] FIG. 8 illustrates a QoS classification operation for PDU Set marking for multiple downlink flows in accordance with some embodiments.

[0016] FIG. 9 illustrates three options for an EDB field in accordance with some embodiments.

[0017] FIG. 10 illustrates an example transmission timeline for XR traffic in accordance with some embodiments.

[0018] FIG. 11 illustrates a method of operating a network node in accordance with some embodiments.

[0019] FIG. 12 illustrates a method of operating a UPF in accordance with some embodiments.

[0020] FIG. 13 illustrates an example architecture of a wireless communication system, according to embodiments disclosed herein.

[0021] FIG. 14 illustrates a system for performing signaling between a wireless device and a network device, according to embodiments disclosed herein.DETAILED DESCRIPTION

[0022] Various embodiments are described with regard to a UE. However, reference to a UE is merely provided for illustrative purposes. The example embodiments may be utilized with any electronic component that may establish a connection to a network and is configured with the hardware, software, and / or firmware to exchange information and data with the network. Therefore, the UE as described herein is used to represent any appropriate electronic component.

[0023] There may be a number of potential areas of development with respect to Data Burst indications. For example, as will be discussed in more detail herein, with XR data there may be multiple PDU sets in a Data Burst. If there were an indication of the end of Data Burst, the system may improve resource efficiency. Some embodiments herein provide an additional set of options to enhance the End of Data Burst information.

[0024] FIG. 1 illustrates a network environment 100 in accordance with some embodiments. The network environment 100 may include a UE 102 communicatively coupled with an access node 104. The UE 102 and the access node 104 may communicate over air interfaces compatible with 3 GPP TSs such as those that define Fifth Generation (5G) NR system standards. The access node 104 may be a base station such as a gNB to provide one or more 5G New Radio (NR) cells that present NR user plane and control plane protocol terminations toward the UE 102.

[0025] The network environment 100 may further include a user plane function (UPF 106) of a core network (CN), for example, a 5thGeneration Core network (5GC). The UPF 106 may be responsible for routing and forwarding user-plane packets between the access node 104 and an external data network. The UPF 106 may handle the user plane path of protocol data unit (PDU) sessions. The UPF 106 may be coupled with a sessionmanagement function (SMF) that configures traffic steering, QoS control and policy related functions at the UPF 106, performs PDU session management, IP address allocation, general packet radio service tunneling protocol - user plane (GTP-U) tunnel management, selection and control of user plane functions, and downlink notification management.

[0026] Various components of the network environment 100 may perform quality of service (QoS) mapping operations for transmissions from the application / service layer 108. Except as otherwise described herein, these mapping operations may be similar to those described in the QoS model of clause 5.7 of 3GPP TS 23.501 V17.9.0 (2023-06).

[0027] The QoS mapping may be performed with a two-step approach. In a first step, QoS flow classification may be performed to classify packets as part of a traffic detection (or application detection) process for QoS enforcement in a 5G system. The packets may be mapped to one or more QoS flows. One PDU session may include a plurality of QoS flows. In a second step, QoS flows may be mapped to data radio bearers (DRBs) for transmission over resources of an access network. The UE 102 may perform the first step at stage 110 and the second step at stage 112; the access node 104 may perform the second step at stage 114; and the UPF 106 may perform the first step at stage 116.

[0028] In the uplink, the application / service layer 108 of the UE 102 may provide data packets in one or more IP flows 118 of a service data flow (SDF) to a stack. While IP flows are described throughout, embodiments may be equally applicable to other types of packet flows (for example, Ethernet). An SDF may be a flow of packets that represent a service being delivered to the subscriber. For example, an SDF may be a flow of audio / video packets that provide a streaming media service to a subscriber. An SDF may have one or more packet flows.

[0029] The stack represents access stratum and non-access stratum protocol layers of the UE 102 that provide for communicating over the radio-access and core networks. The stack may perform QoS flow classification at stage 110 based on QoS rules by mapping uplink packets from the IP flows to QoS flows and applying QoS flow marking. All packets of a QoS flow may be marked with the same QoS flow identifier (QFI). FIG. 1 illustrates three QoS flows corresponding with QFI(l), QFI(2), and QFI(3).

[0030] Typically, traffic associated with the same QFI will receive the same QoS treatment. The QFI may be used as a U-plane marking on the N3 interface (betweenRAN and UPF) and the N9 interface (between two UPFs) and may be unique within a PDU session. In some instances, the QFI may also be carried in a radio header over the radio interface (Uu).

[0031] The stack may also perform the QoS flow-to-DRB mapping at stage 112 to map the QoS flows to access network resources. The mapping at stage 112 may be an access stratum operation performed by, for example, a service data adaptation protocol (SDAP) layer of the stack. Different QoS flows may be mapped to the same or different DRBs (for example, n:l or 1: 1 mapping). Several QoS flows belonging to the same PDU session may be mapped to the same DRB. However, QoS flows belonging to different PDU sessions may not be mapped to the same DRB. The RAN may add new DRB with corresponding QFI mappings to fulfill QoS characteristics of a QoS flow. The UE 102 may determine uplink data QoS binding (association between QoS flows and DRBs) based on explicit QoS signaling or reflective QoS signaling based on downlink data QoS marking.

[0032] The access node 104 may perform DRB-to-QoS flow mapping at stage 114 and the UPF 106 may perform QoS flow to IP flow mapping at stage 116. The IP flows may be provided to the application / service layer 108 that may reside in a data network (DN) or, in the opposite direction, at a device in communication with the UE 102 or in the UE 102 itself. The application / service layer 108 may be in a server, another UE, or another XR-user connected to the Internet over, for example, a digital subscriber line or a wireless local area network.

[0033] In the downlink, the UPF 106 may perform QoS classification at stage 116 by classifying the IP packets for QoS flow marking and other actions based on packet detection rules (PDRs).

[0034] After the UPF 106 maps the IP flows to the QoS flows at stage 116, the access node 104 may perform QoS flow-to-DRB mapping at stage 114 to map the QoS flows to access network resources. The UE 102 may perform DRB-to-QoS flow mapping at stage 112 and QoS flow to IP flow mapping at stage 110.

[0035] The application / service layer 108 may operate on application data units (ADUs) or PDU Sets, which may be considered the smallest independently usable data unit. One ADU or PDU Set may contain a plurality of lower-layer packets or PDUs. For example, one ADU or PDU Set may include more than one RTP / IP packets or PDUs. In general, there may be a 1: 1 mapping between RTP and IP packets. However, in some cases oneRTP packet may be transmitted in a plurality of IP packets using IP fragmentation. This may be based on a maximum transmission unit (MTU) size available on a link. Further, some RTP payload formats may allow aggregation of multiple ADUs or PDU Sets into a single RTP payload.

[0036] An ADU may be specified for coding formats and RTP payload formats in a 3GPP file format (3GP) file. For audio and speech, an ADU may be specified as a coded frame intended for transport. For H.263 video compression standard, an ADU may include an entire RTP payload. For H.264 advanced video coding (AVC) standard or H.265 high-efficiency video coding (HEVC) standard, an ADU may be a network adaptation layer unit (NALU). For timed text, an ADU may include any of the type 1-5 RTP payload units. Other payload formats may exist in, for example, RFCs, 3GP files, etc., or can be specific to an application.

[0037] The application / service layer 108 may operate on PDU Sets, ADUs or larger Data Bursts (represented by a bitstream) where a Data Burst may include a set of ADUs or PDU Sets. A single PDU Set or ADU in the set may get packetized into a plurality of lower layer data packets that are smaller than the ADU or PDU Set. For example, an ADU or PDU Set may be packetized into a plurality of RTP packets mapped to a plurality of IP packets or SDAP / packet data convergence protocol (PDCP) service data units (SDUs).

[0038] In some embodiments, the CN may have control of packet filters in the wireless system. For a given Service Data Flow (SDF), the binding of service requirements and QoS flows may be based on Policy and Charging Control (PCC) rules provided by the policy control function (PCF). The session management function (SMF) may perform the binding of PCC rules to QoS Flows based on the QoS and service requirements. The SMF may provide QoS rules to the UE and PDRs to the UPF. These are also known as packet filters. For pre-defined PCC rules: Traffic detection filters (e.g., packet filters, in the UPF 106) can be configured either in the SMF and provided to the UPF 106 as service data flow filter(s) or can be configured in the UPF 106 as an application detection filter identified by an application identifier.

[0039] One area of study for developing QoS is providing support for low latency communication and extended reality (XR) applications. Related key performance indicators (KPIs) and quality of service (QoS) aspects may specify radio access network (RAN) support for enhanced granularity for QoS, PDU Set or application data unit(ADU)-based QoS, and XR-specific QoS parameters. QoS flow handling and corresponding data radio bearer (DRB) control may also be specified.

[0040] XR services can operate on a packet data unit (PDU) Set comprised of multiple IP packets. A PDU Set can be mapped to a QoS flow. PDU Sets can be identified through PDU Set QoS parameters, as described in Technical Specification (TS) 23.501 clause 5.7.7 V18.2.2 (2023-06), and in-band markings known as PDU Set Information, as described in TS 23.501 clause 5.37.5.

[0041] The UPF 106 may be provided with a protocol description which indicates the protocol and payload type used by the SDF. The PCF may provision the Protocol Description within PCC Rules based on the information provided by the application function (AF) and / or the local operator policies, and the SMF may configure the UPF 106 accordingly. Details are specified in 23.501.

[0042] FIG. 2 illustrates a Data Burst 202 that may be transmitted between the application layers to exchange application data in accordance with some embodiments. The Data Burst may be a bit stream of interrelated application data 204. The data may correspond to an application such as, for example, an XR application.

[0043] The bitstream may be divided into a plurality' of Application Data Units (ADUs). The Data Burst 202 may include a set of ADUs or PDU Sets 206. Application layer data for XR is typically delivered in bursts that occur relatively periodical. The term PDU Set may be considered equivalent to an ADU in the context of XR.

[0044] The PDU Set may be considered the smallest data unit that can be independently processed by an application layer. One PDU Set may contain a plurality- of lower-layer packets or PDUs intended for over-the-air transmission. For example, one PDU Set may be packetized into a plurality of lower-layer packets or PDUs. A Data Burst 202 can consist of several PDU Sets 206 where each PDU Set is transmitted in a number of smaller data packets or PDUs, such as real-time protocol (RTP) packets mapped to IP packets / PDCP SDUs. For example, in the case of an audio codec, a PDU Set is defined as an audio frame. In the case of H.264 (AVC) or H.265 (HEVC), a PDU Set is defined as a NAL unit (NALU). A Data Burst may be defined as a set of multiple PDUs generated and sent by the application in a short period of time. A Data Burst can be composed of one or multiple PDU Sets.

[0045] From an application layer perspective, a Data Burst 202 may be associated with one or multiple PDU Sets 206. In turn, PDU Sets 206 in a Data Burst 202 may beassociated with the same or different XR traffic flows, SDFs, or IP flows, so they can map to a single or multiple QoS flows.

[0046] FIG. 3 illustrates time Sensitive communication (TSC) assistance information (TSCAI 300), and FIG. 4 illustrates a TSC assistance container (TSCAC 400). The CN can use TSCAI 300 and TSCAC 400 (as defined in TS 23.501, clause 5.27) to provide a network node with information about the characteristics of an XR traffic flow. This information is provided at the granularity of a QoS flow. For example, TSCAI 300 and TSCAC 400 describes periodicity that refers to the time period between the start of two Data Bursts, and the Data Burst arrival time. This information is defined at the granularity of the QoS flow. However, multiple QoS flows can belong to the same Data Burst. Accordingly, some embodiments herein describe methods to better define Data Bursts. The more information that the network node has for the Data Bursts the more efficiently the network node may schedule resources for a UE.

[0047] The PCF may provision a Protocol Description within PCC Rules based on the information provided by the AF and / or the local operator policies. The protocol description may be used to identify PDU Set Information for example on RTP level (e.g., over the N6 interface), in order to enable the UPF 106 to map PDUs or packets associated with a PDU Set within the wireless system (e.g., on the N3 interface).

[0048] In addition, extensions for Session Reporting and UE power saving management may include an end of Data Burst indication. The end of Data Burst indication may relate to the Data Burst associated with a QoS flow as described in TSCAI 300 / TSCAC 400, or a Data Burst in general which may encompass multiple QoS flows.

[0049] An indication of end of Data Burst (EoDB) may be provided to the radio access network (RAN) by the UPF 106. For example, the end of Data Burst may be provided to the RAN to configure UE power management schemes like connected mode DRX. According to the request and information from the SMF, the UPF 106 may identify the last PDU of a Data Burst in the downlink traffic based on the end indication according to the Protocol Description and may provide an end of Data Burst indication to the RAN over GPRS Tunneling Protocol for the User Plane (GTP-U) of the last PDU of a Data Burst.

[0050] There may be a benefit of using additional bits to indicate inter-burst time, which may change dynamically due to various reasons, including application-layer rate control. This can enable the RAN to switch to the most appropriate power state. Forexample, there may be multiple bits to indicate the end of a frame or PDU Set. Indicating such timing of the Data Burst may be useful for power saving. There may be other benefits of using additional bits such as an ambiguity related with the setting of M-bits set in the RTP header, to signal extra data burst information (e.g. when multiple QoS flows belong to a data burst), or even as a mitigation in case the PDU with the EoDB bit does not reach the receiver.

[0051] FIG. 5 illustrates a one-byte RTP header extension format 500, in accordance with some embodiments. FIG. 6 illustrates a two-byte RTP header extension format 600, in accordance with some embodiments. As shown, both the one-byte RTP header extension format 500 and the two-byte RTP header extension format 600 include an E field 502, EDB field 504, and a PSI field 506.

[0052] The E field 502 is a one-bit field that indicates the end PDU of the PDU Set. The E field 502 is a flag that shall be set to 1 for the last PDU of the PDU Set and set to 0 for all other PDUs of the PDU Set.

[0053] The EDB field 504 indicates an end of Data Burst. The EDB field 504 is three bits in length and indicates the end of a Data Burst. The three bits encode the end of Data Burst indication as per the encoding guidelines provided in some embodiments.

[0054] The PSI field 506 is four bits and represents the PDU Set importance. The PSI field 506 indicates the importance of this PDU Set compared to other PDU Sets within the same RTP stream or within the same QoS flow. The PSI field 506 may use two importance levels (1 bit) in Rel-18. But 3-4 bits may be used to provide additional granularity.

[0055] A first problem area may be where multiple media flows are associated with a data burst, as mentioned elsewhere herein. Some of the embodiments may be used to determine the end of data burst in such a case. For example, TSCAI and TSCAC are currently defined at the granularity of a QoS flow, associated with a data burst. It may be possible to uniquely identify the end of a data burst even when more than one QoS flow is associated with a data burst.

[0056] A second problem area may be that it may be assume that the network node is provided with burst arrival times and periodicity via TSCAI. This information is provided on a per QoS flow basis. Therefore, the network node would know when multiple QoS flows are expected to arrive at the same time. However, one of the traffic characteristics of XR is that the amount of data carried over a period of time is notalways constant, and it may come in bursts. Therefore, a Data Burst may not always end at the same time. The same implication can be made for the start of the next Data Burst.

[0057] In some cases, the information network node may infer the wrong data is next to arrive. For example, the network node (based on its knowledge from TSCAI) may infer that data for QFI 5 would be next to arrive, while in reality QFI 5 may not have application layer data for a short while and instead QFI 7 (which is also associated with the same RTP session) is going to have data. The arrival time of QFI 7 may be known to the network node. What is not known to the network node is that QFI 7 will be next to transmit. In some embodiments, EDB field 504 (or a new RTP header extension) may convey such information. Note that one of the traffic characteristics of XR is that the amount of data carried over a period of time is not always constant, and it is bursty.

[0058] FIG. 7 illustrates a QoS classification operation 700 of the network environment 100 in accordance with some embodiments. The illustrate embodiment shows a single IP flow mapped to a single QoS flow. Alternatively, or additionally, a single IP flow (SDF / application traffic flow) may be mapped to multiple QoS flows, using PDRs and QoS rules.

[0059] The QoS classification operation 700 maps both PDU Set #1 and PDU Set #2 to one QoS flow7(QoS flow 1). The SMF 702 may provide packet filters to the UPF 106 as PDRs and to the UE Stack 704 as QoS rules. For a given SDF. the binding of service requirements and QoS flows may be based on policy and charging control (PCC) rules provided to the SMF 702 by the policy control function (PCF) or application function (AF) of the core netw ork. The UPF 106 may receive an EDB 708 and E field as an input (e.g., in the form of a marking on the N6 interface) in the DL. The UPF 106 may identity7the data burst and insert an EoDB marking in the last user plane packet of the data burst. The EoDB may be an output towards the N3 interface. For instance, the UPF may include an EoDB field 706 in the last packet of the Data Burst to convey that PDU Set #2 is the last PDU Set of the Data Burst and to mark the PDU that signifies the end of the data burst.

[0060] FIG. 8 illustrates a QoS classification operation 800 for PDU Set marking for multiple downlink flows, in accordance with some embodiments. The QoS classification operation 800 maps IP flows to QoS flows. The SMF 702 may provide packet filters to the UPF 106 as PDRs and to the UE Stack 704 as QoS rules. For a given SDF, the binding of service requirements and QoS flow's may be based on policy and chargingcontrol (PCC) rules provided to the SMF 702 by the PCF or AF of the core network. The UPF 106 may include an EoDB field 806 in the last packet of the last PDU Set of the Data Burst (e.g., PDU Set #2 of IP flow 1) to convey that the PDU Set is the last PDU Set of the Data Burst and to mark PDU that signifies the end of the data burst. An EDB field 804 may mark the last PDU Set in a downlink from the server.

[0061] Some embodiments herein, provide an additional set of options to enhance the End of Data Burst information. The enhancements could be done by allocating the EDB field 504 with different semantics, or by introducing an additional field in the RTP header extension. Likewise, a UPF may need to be provided with rules to convert the proposed information to the network node.

[0062] If multiple QoS flows are associated with an End of Data Burst indication it may be useful for the system (especially the network node) to identify those flows. Accordingly, some embodiments herein identify the multiple QoS flows associated with such an indication. When multiple DRX configurations exist or when switching of configurations of DRX is supported for a UE, the network node may utilize the End of Data Burst to optimize the switching of DRX pattern. For example, a DRX configuration may have multiple offsets and can adjust based on a pattern for a set of QoS flows associated with a Data Burst. Accurate information about the QoS flow to Data Burst association may also help the network node to prepare schedule resources accordingly, as well as allocate CGs / SPS.

[0063] Further, a network node may provide assistance information to the SMF 702 and the core network to assist the UPF 106 in identifying which QoS flows are going to be scheduled for transmission at roughly the same time (e g., in downlink). Alternatively, the UPF 106 can extract this information from control information received from the SMF 702 without such an indication.

[0064] An XR application may utilize multiple traffic flows, SDFs, IP flows, IP 5 tuples, etc. as part of an XR session or connection. Since the RTP header extension may be indicated per PDU Set, the application (at Application Server (AS) or UE) may mark the end of the Data Burst by updating the RTP header extension associated with the last PDU Set in a Data Burst. The UPF may further mark the end of data burst towards the RAN node on the N3 interface.

[0065] According to the current SA2 / SA4 framework, the UPF 106 marks the end of the Data Burst in the last PDU Set of a Data Burst. This means the network node (e.g.,the RAN) could use this information to allocate radio resources and optimize for power saving. However, if multiple QoS flows are associated with a Data Burst, it is unclear how the network node and / or UE would know the exact set of QoS flows associated with a Data Burst. Such awareness may be used to optimize the scheduling of radio resources and UE power saving, it can also enhance spectrum efficiency. Accordingly, some embodiments herein provide means for identifying the end of the data burst, the last packet in the data burst and / or the last PDU Set of a Data Burst associated with multiple QoS flows.

[0066] In some embodiments, to identify the relation of QoS flows in the time domain, the network node (e.g., the RAN) may examine periodicity and burst arrival time (BAT) of each and every QoS flow configured. For example, QoS flows with a similar BAT (and / or periodicity) in a timeframe may belong to the same Data Burst. The network node may determine the BAT and the periodicity from e.g. the TSCAI 300 or from a UE- based indication to the RAN. The timing of the start and stop of a Data Burst may be inferred from that information. For example, the network node may be able to identify QoS flows where periodicity or BAT are overlapping in time and infer the start and stop of the data burst (consisting of multiple QoS flows) from that information.

[0067] In the DL, the UPF may also set EoDB on any (i.e., on one out of multiple) PDU Set / QoS flow associated with the data burst. Once an EoDB indication was observed, the network node does not expect further data on any of the other QoS flows associated with the same data burst (in the same timeframe). Likewise in the UL, the UE may provide for a QoS flow or DRB an EoDB indication or the RAN may infer the end of a data burst based on BSR (buffer status reports) or by implementation (e.g., per DRB or per QoS flow). In such case, based on the derived knowledge or based on a configuration indicating which QoS flows belong to the same data burst, one EoDB indication on any of the associated QoS flows may be interpreted as the end of the data burst.

[0068] In some embodiments, the Application Server (or the UE application) may set the EoDB on every traffic flow of a data burst, identifying the last PDU Set or the last PDU of the last PDU Set. However, the UPF 106 may reflect the EoDB marking (e.g.. on N3 in the DL or on N6 in the UL) for each and every QoS flow accordingly. The EoDB may be one bit set on the traffic flows to identify the last PDU Set or the last PDU of the last PDU Set. As shown on FIGS. 7 and 8, multiple mapping rules exist for QoS flowassociation between IP flows and QoS flows (1: 1, N:l, 1:M), so this option may lead to more complex operations in the UPF 106 / core network.

[0069] In such embodiments, the last PDU Set or the last PDU of each QoS Flow may have the RTP marking indicating the end of a data burst. For 1: 1 mapping between IP flows and QoS flows, the UPF 106 can insert the EoDB marking to the RAN (e.g., on N3) or to the DN (e.g., on N6). For N: 1 mapping, the Application Server can set the EoDB on N last PDU Sets, but UPF 106 may consider only one of them. For 1 :M mapping, the Application Server may set the EoDB for the last PDU Set on the M flows (1 :M is configured by the AS / AF) and the UPF 106 may ensure that this PDU Set is sent as the last PDU Set to the RAN.

[0070] In some embodiments, the UE or network node may associate multiple QoS flows mapped to the same PDU session or the same RTP session with a Data Burst. This may be defined in a specification or done by implementation.

[0071] In some embodiments, the UE or network node may associate multiple QoS flows mapped to the same RTP session with a Data Burst. This may be defined in a specification or done by implementation.

[0072] In some embodiments, the network node may be provided with additional assistance information for the relation to the QoS flows and the data burst. The additional information may be provided to the network node in a separate information element (IE) or message and may provide information as to which QoS flows would occur at the same time and / or in the same data burst. The signaling of such information can be provided from the core network to RAN (over N2 or over N3) or alternatively from the UE to RAN.

[0073] In some embodiments, the normal TSCAI 300, which is signaled per-QoS flow, may be extended to contain an additional parameter. The additional parameter may identify the association (e.g.. in the time domain, for a Data Burst) of the current QoS flow within a set of other QoS flows. The SMF 702 based on PCC Rules may identify the dependency between QoS flows associated with a single TSCAI 300 and supply the parameter information accordingly. In some embodiments, the SMF 702 may duplicate the same TSCAI information (e.g.. burst timing) for all QoS Flows. Accordingly, the same timing information may be configured for all of the QoS Flows.

[0074] Some embodiments introduce a new / common type of TSCAI applicable to multiple QoS flows. The network node may be provided with common information (e.g.,in the time domain, for a Data Burst) for a set of related QoS flows through the new / common type of TSCAI. This type of TSCAI may not be signaled per QoS flow. The new / common type TSAI may even have a reduced parameter set targeting only the time related information such as burst timing.

[0075] In some embodiments. PDU Set Information (refer to TS 23.501) and / or information in a RTP header extension field (such as EDB field 504, or a new field) includes information about the association of multiple XR traffic flows, SDFs, or QoS flows with a Data Burst. In some embodiments, the system may receive e.g. I-frames and P-frames (or different PDU Set types or PDU Sets of different PSI) in the same SDF or IP 5-tuple where different media frames (e.g.. I and P, or different PDU Set types or PDU Sets of different PSI) can be mapped to different QoS flows in the future.

[0076] Not only the core netw ork but also the UE may provide the network node with the additional assistance information in the embodiments discussed above. For example, the additional assistance information may be provided as signaling, assistance information or TSCAI from the UE to the RAN. The embodiments described in relation to the additional assistance information may be combined or can be used separately. The embodiments in relation to the end of data burst information (such as EoDB, EDB or related indications) described above may be combined or can be used separately.

[0077] In some embodiments, a Data Burst may consist of multiple XR traffic or QoS flows. If multiple IP flows. SDFs, or application layer traffic flows are associated with an EDB indication (e.g., EDB field 504), an application, a RTP sender (and / or the UPF) may set the EDB bits in a number of ways. Moreover, the bits or packets (PDUs) in a data burst may belong to the same application, may be targeted towards the same device, or may be targeted towards the same PDU Session or RTP session.

[0078] FIG. 9 illustrates three options for an EDB field 902. A field w ith multiple EDB bits may be utilized in at least one of the ways shown in FIG. 9. In some embodiments, the EDB field 504 may be the EDB field 902 of the one-byte RTP header extension format 500 or the two-byte RTP header extension format 600. In some embodiments, the EDB bits may be a new’ field or part of an extended EDB field.

[0079] In a first option 904. every’ bit position is associated with one traffic flow. In other words, bit 1 may indicate a first traffic flow- or QoS flow, bit 2 may indicate a second traffic flow or QoS flow, and bit 3 a third traffic flow or QoS flow. The bits may be used to indicate the end of the traffic flows or QoS flow s. Alternatively, oradditionally, the bits may be used in combination with other bits in a RTP header extension or PDU Set Information, such as the E-bit or PSI.

[0080] In a second option 906, every bit position may be associated with a subset of one or more traffic flows. Further, the exact subset can be pre-configured over NGAP / F1AP / E1AP, or for the UE side the exact subset can be pre-configured over NAS / RRC or SDP. For example, bit 1 may indicate a first subset of QoS flows, bit 2 may indicate a second subset of QoS flows, and bit 3 a third subset of QoS flows. For example, if the first subset of QoS flows could correspond to QoS flows 1, 3, and 5, then bit 1 may be used to indicate the end of QoS flows 1. 3, and 5. Alternatively or additionally, the bits may be may be used in combination with other bits in a RTP header extension or PDU Set Information, such as the E-bit or PSI.

[0081] In a third option 908, the three bits may be used as a bitmap. The meaning of the values can be flexibly assigned based on NGAP / F1AP / E1AP (for network node) or NAS / RRC / SDP (for UE) configuration. For example, the bitmap may represent a special event such as a pre-announcement of an upcoming EoDB. For instance, the bitmap may be provided as an early indication, where EoDB is expected in x number of PDU Sets (or x number of PDUs) where x is given by the bitmap. In some embodiments, the bitmap may be flexibly configured over NGAP or SDP to contain certain information. For example, the bitmap may be configured to contain information unrelated with the end of the data burst such as in-sequence / out-of-order delivery' mode for the PDU Sets in a Data Burst, the announcement of a limitation or restriction, error event, etc.

[0082] The EDB field 902 may not limited to 3 bits. More than 3 bits may be used for EDB field 902 depending on the space available in the RTP extension header. For example. PSI field 506 may not need 4 bits and so more bits can be available for EDB field 902. If there are more than 3 bits, the first option 904 can support a higher number of traffic flows.

[0083] In some embodiments, if the first option 904, the second option 906. or the third option 908 are not used, EDB bits may be set independently for each QoS flow the application stream is configured to be split into. In this way, the EDB bits may be set for each PDU Set that is configured to be transmitted in separate QoS Flows according to the Packet Detection Filter. This can be used, for example, together with the embodiments described herein where the Application Server (or the UE application) setsthe EoDB on every' traffic flow, identifying the last PDU Set or the last PDU of the last PDU Set.

[0084] The UPF may decode the bits of the EDB field 902 and may map them to an indication to the RAN in downlink. Likewise in uplink, the UE may set the bits of the EDB field 902 and the UPF would set them on N6 or map them to an indication to the Application Server. Note that this introduces some kind of inter QoS flow association (for control, not for data).

[0085] In some embodiments, the RTP extension header may be used to indicate the PSI level of the next PDU Set. In order to optimize UPF or network node scheduler operation and / or allocate radio resources early enough, one field in the RTP extension header may be used to indicate some information about the next PDU Set. The field may be a new field or a bit pattern in the EDB field can be used. Such RTP extension header field (on N6 and in the UE) and N3 related GTP-U information can be provided through one or multiple of the following options.

[0086] In a first option, while indicating the last PDU in a Data Burst (via e.g., the “E" bit), the EDB field or a new header field may indicate whether the PDU Set associated with the start of the next data burst is going to be an important PDU Set or not.Optionally, the EDB field or the new header field may indicate the importance level that the PDU Set is going to have.

[0087] In a second option, the importance of the next PDU set may be indicated during an ongoing Data Burst transmission. For example, the indication may be provided in the middle of a Data Burst, while EoDB is not yet known (e.g., the “E” bit is not yet set). The EDB or a new field may indicate whether the next PDU Set is an important PDU Set or not, and / or which Importance level it is going to have.

[0088] In a third option, the QFI of the QoS flow for which the next (important) PDU Set belongs to may be indicated. The indication for the QFI of the QoS flow may be in addition to the first and / or the second options. In other words, the indication may be in a parameter other than EDB, or other than the new header field used for such information.

[0089] In some embodiments, the indication about the next PDU Set can be signaled as one index in EDB. For example, the indication may be a value specifically defined for this purpose. In some embodiments, the indication can be signaled as a separate field in the RTP header extension and / or GTP-U header. The indication can be a single bit or multiple bits depending on how many levels of PSI (PDU Set Importance) are intendedto be supported. In some embodiments, the UPF may be provided with a rule to match the RTP header containing such information and forward it to the network node over N3.

[0090] Assuming such grouping (in the time domain) of multiple XR traffic flows exists or can be configured by, for example, an Application Server, AF, UE or UE Application, the network node can be made aware of this information through signaling. In a first option, the network node may use this information to identify QoS flows suitable to be scheduled together in a Semi Persistent Scheduling (SPS) or configured grant (CG). In a second option, the network node may associate groups of QoS flows with multiple Discontinuous Reception (DRX) cycles. In some embodiments, TSCAI may contain a mapping of EDB indications. In some embodiments, the network node implementation may observe end of data burst indications for a set of QoS flows over time to identify a remapping of QoS flows to, for example, different DRBs / logical channels (LCHs) or CGs / SPS.

[0091] One characteristic of XR traffic flow is that it may vary in size and timing. For instance, more data or less data then was originally advertised may be sent. FIG. 10 illustrates an example transmission timeline 1000 for XR traffic. As shown, the XR periodic traffic may be associated with random jitter, where the actual packet arrival time may be offset from the nominal timing (based on traffic periodicity). Further, the packet size also varies over time.

[0092] Configured scheduling such as configured grant (CG) and semi-persistent scheduling (SPS) may be enhanced to accommodate such traffic characteristics in uplink. To cope with varying packet size with CG with fixed transport block size (TBS), a system may encounter the following situations. When the packet size is larger than the TBS of a CG occasion, it cannot be accommodated within one CG cycle which can cause latency. When the packet size is smaller than the TBS of a CG occasion, it is not resource efficient. The network node could have allocated the resource to other UEs.

[0093] Some embodiments may provide an indication of a next PDU set for out-of- order PDU sets. Assuming multiple XR traffic flows are associated with the same connection, device, application or server, an application or the network may be aware of the buffer status and other processing related information from related traffic flows (e.g., terminating at the same device, same RTP session, same connection, same application). Therefore, it can be possible to predict on which XR traffic flow / QoS flow the next packet is expected to be submitted for transmission. Thus, EDB or a new headerextension field may be used to indicate such a next XR traffic flow and QoS flow expected to be transmitted.

[0094] In some instances, the network node can infer such information from TSCAI. However, buffer states and availability of application layer input may fluctuate due to the quasi-periodical nature of XR traffic (e.g., changing size and arrival timing). In some embodiments, the next PDU Set indication may be provided when needed. For example, the indication may be provided when the PDU Sets or Data Burst arrival times are expected to shift significantly or arrive in a different order. That is, as long as buffer states (and / or PDU Set size) and burst arrival times do not fluctuate more than a (configured or specified) threshold, the RAN may be expected to rely on the configuration in TSCAI and no indication needs to be provided by the Application Server, UPF, or UE.

[0095] Since a QoS flow is identified by 5 bits (and also the IP tuple / SDF requires much more than 3 bits), in embodiments where a 3-bit EDB is to be used for such indication the network node may be provided with extra configuration information for mapping purposes. Such mapping information can be setup and signaled separately. For example, a mapping table or similar may be used.

[0096] FIG. 11 illustrates a method 1100 of operating a network node in accordance with some embodiments. The method 1100 includes receiving 1102 multiple QoS flows. The method 1100 further includes determining 1104 which of the QoS flows correspond with a single data burst. The method 1100 further includes scheduling radio resources based on the QoS flows corresponding with the single data burst.

[0097] In some embodiments, determining which of the QoS flows correspond with the single data burst comprises identifying a relation of the QoS flows in a time domain by examining periodicity' and burst arrival time (BAT) of each of the QoS flows.

[0098] In some embodiments, the method 1100 further comprises receiving an End of Data Burst (EoDB) indication identifying a last PDU Set or a last packet of a PDU Set corresponding to the data burst.

[0099] In some embodiments, the method 1100 further comprises associating the QoS flows mapped to a same PDU session with the data burst.

[0100] In some embodiments, the method 1100 further comprises associating the QoS flows mapped to a same RTP session with the data burst.

[0101] In some embodiments, the method 1100 further comprises receiving additional assistance information as to which of the QoS flows would occur at a same time or in the data burst.

[0102] In some embodiments, the method 1100 further comprises receiving a parameter identifying an association of a current QoS flow with a set of other QoS flows via a TSCAI or via signaling from a U).

[0103] In some embodiments, the method 1100 further comprises receiving common information for a set of related QoS flows.

[0104] In some embodiments, the PDU Set Information or information in a RTP header extension field or information signaled between a UE and a RAN or information signaled within the RAN includes information about an association of the QoS flows with the data burst.

[0105] In some embodiments, the method 1100 further comprises receiving a RTP extension header comprising a field indicating whether a PDU set associated with a start of a next data burst is going to be an important PDU set. In some embodiments, the field indicates an importance level.

[0106] In some embodiments, the method 1100 further comprises receiving a header extension field that indicates a next QoS flow expected to be transmitted.

[0107] Embodiments contemplated herein include an apparatus comprising means to perform one or more elements of the method 1100. This apparatus may be, for example, an apparatus of a base station (such as a network device 1418 that is a base station, as described herein).

[0108] Embodiments contemplated herein include one or more non -transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of the method 1100. This non-transitory computer- readable media may be. for example, a memory of a base station (such as a memory 1422 of a network device 1418 that is a base station, as described herein).

[0109] Embodiments contemplated herein include an apparatus comprising logic, modules, or circuitry to perform one or more elements of the method 1100. This apparatus may be. for example, an apparatus of a base station (such as a network device 1418 that is a base station, as described herein).

[0110] Embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of the method 1100. This apparatus may be, for example, an apparatus of a base station (such as a network device 1418 that is a base station, as described herein).[OHl] Embodiments contemplated herein include a signal as described in or related to one or more elements of the method 1100.

[0112] Embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out one or more elements of the method 1100. The processor may be a processor of a base station (such as a processor(s) 1420 of a network device 1418 that is a base station, as described herein). These instructions may be, for example, located in the processor and / or on a memory of the base station (such as a memory 1422 of a network device 1418 that is a base station, as described herein).

[0113] FIG. 12 illustrates a method 1200 of operating a UPF in accordance with some embodiments. The method 1200 includes receiving 1202 multiple PDU sets associated with a data burst. The method 1200 includes decoding bits of an end of data burst field corresponding to one of the PDU sets to determine an end of the data burst. The method 1200 includes mapping the bits corresponding to the EDB field to an indication of an end of the data burst. The method 1200 includes sending the indication of the end of the data burst to a network node.

[0114] In some embodiments, each bit position of the EDB field is associated with one traffic flow.

[0115] In some embodiments, each bit position is associated with a subset of one or more traffic flows.

[0116] In some embodiments, the bits comprise a bitmap with a value corresponding to a number of PDU sets until an end of the data burst.

[0117] In some embodiments, the method 1200 further comprises sending, to a network node, an RTP extension header comprising a field indicating information about a next PDU set.

[0118] In some embodiments, the field indicates whether the next PDU Set that is associated with a start of a next data burst is an important PDU set.

[0119] In some embodiments, the field indicates an importance level.

[0120] In some embodiments, the method 1200 further comprises sending a header extension field to indicate a next traffic flow or QoS flow expected to be transmitted.

[0121] Embodiments contemplated herein include an apparatus comprising means to perform one or more elements of the method 1200.

[0122] Embodiments contemplated herein include one or more non -transitory' computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of the method 1200.

[0123] Embodiments contemplated herein include an apparatus comprising logic, modules, or circuitry to perform one or more elements of the method 1200.

[0124] Embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of the method 1200.

[0125] Embodiments contemplated herein include a signal as described in or related to one or more elements of the method 1200.

[0126] Embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out one or more elements of the method 1200.

[0127] FIG. 13 illustrates an example architecture of a wireless communication system 1300, according to embodiments disclosed herein. The following description is provided for an example wireless communication system 1300 that operates in conjunction with the LTE system standards and / or 5G or NR system standards as provided by 3 GPP technical specifications.

[0128] As shown by FIG. 13, the wireless communication system 1300 includes UE 1302 and UE 1304 (although any number of UEs may be used). In this example, the UE 1302 and the UE 1304 are illustrated as smartphones (e.g., handheld touchscreen mobilecomputing devices connectable to one or more cellular networks), but may also comprise any mobile or non-mobile computing device configured for wireless communication.

[0129] The UE 1302 and UE 1304 may be configured to communicatively couple with a RAN 1306. In embodiments, the RAN 1306 may be NG-RAN. E-UTRAN, etc. The UE 1302 and UE 1304 utilize connections (or channels) (shown as connection 1308 and connection 1310, respectively) with the RAN 1306, each of which comprises a physical communications interface. The RAN 1306 can include one or more base stations (such as base station 1312 and base station 1314) that enable the connection 1308 and connection 1310.

[0130] In this example, the connection 1308 and connection 1310 are air interfaces to enable such communicative coupling, and may be consistent with RAT(s) used by the RAN 1306, such as. for example, an LTE and / or NR.

[0131] In some embodiments, the UE 1302 and UE 1304 may also directly exchange communication data via a sidelink interface 1316. The UE 1304 is shown to be configured to access an access point (shown as AP 1318) via connection 1320. By way of example, the connection 1320 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, wherein the AP 1318 may comprise a Wi-Fi® router. In this example, the AP 1318 may be connected to another network (for example, the Internet) without going through a CN 1324.

[0132] In embodiments, the UE 1302 and UE 1304 can be configured to communicate using orthogonal frequency division multiplexing (OFDM) communication signals with each other or with the base station 1312 and / or the base station 1314 over a multicarrier communication channel in accordance with various communication techniques, such as. but not limited to, an orthogonal frequency division multiple access (OFDMA) communication technique (e.g., for downlink communications) or a single carrier frequency division multiple access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect. The OFDM signals can comprise a plurality of orthogonal subcarriers.

[0133] In some embodiments, all or parts of the base station 1312 or base station 1314 may be implemented as one or more software entities running on server computers as part of a virtual network. In addition, or in other embodiments, the base station 1312 or base station 1314 may be configured to communicate with one another via interface1322. In embodiments where the wireless communication system 1300 is an LTE system or an NR system operating in MR-DC with EPC (EN-DC, e.g., when the CN 1324 is an EPC), the interface 1322 may be an X2 interface. The X2 interface may be defined between two or more base stations (e.g., two or more eNBs or an eNB and a gNB or between two gNBs and the like) that connect to an EPC, and / or between two eNBs connecting to the EPC. In embodiments where the wireless communication system 1300 is an NR system (e.g., when CN 1324 is a 5GC), the interface 1322 may be an Xn interface. The Xn interface is defined between two or more base stations (e.g., two or more gNBs and the like) that connect to 5GC, between a base station 1312 (e.g., a gNB) connecting to 5GC and an eNB, and / or between two gNBs connecting to 5GC (e.g., CN 1324).

[0134] The RAN 1306 is shown to be communicatively coupled to the CN 1324. The CN 1324 may comprise one or more network elements 1326, which are configured to offer various data and telecommunications services to customers / subscribers (e.g., users of UE 1302 and UE 1304) who are connected to the CN 1324 via the RAN 1306. The components of the CN 1324 may be implemented in one physical device or separate phy sical devices including components to read and execute instructions from a machine- readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium).

[0135] In embodiments, the CN 1324 may be an EPC, and the RAN 1306 may be connected with the CN 1324 via an SI interface 1328. In embodiments, the SI interface 1328 may be split into two parts, an SI user plane (Sl-U) interface, which carries traffic data between the base station 1312 or base station 1314 and a serving gateway (S-GW), and the SI -MME interface, which is a signaling interface between the base station 1312 or base station 1314 and mobility management entities (MMEs).

[0136] In embodiments, the CN 1324 may be a 5GC, and the RAN 1306 may be connected with the CN 1324 via an NG interface 1328. In embodiments, the NG interface 1328 may be split into two parts, an NG user plane (NG-U) interface, which carries traffic data between the base station 1312 or base station 1314 and a user plane function (UPF), and the SI control plane (NG-C) interface, which is a signaling interface betw een the base station 1312 or base station 1314 and access and mobility management functions (AMFs).

[0137] Generally, an application server 1330 may be an element offering applications that use internet protocol (IP) bearer resources with the CN 1324 (e.g., packet switched data services). The application server 1330 can also be configured to support one or more communication services (e.g., VoIP sessions, group communication sessions, etc.) for the UE 1302 and UE 1304 via the CN 1324. The application server 1330 may communicate with the CN 1324 through an IP communications interface 1332.

[0138] FIG. 14 illustrates a system 1400 for performing signaling 1434 between a wireless device 1402 and a network device 1418, according to embodiments disclosed herein. The system 1400 may be a portion of a wireless communications system as herein described. The wireless device 1402 may be, for example, a UE of a wireless communication system. The network device 1418 may be, for example, a base station (e.g., an eNB or a gNB) of a wireless communication system.

[0139] The wireless device 1402 may include one or more processor(s) 1404. The processor(s) 1404 may execute instructions such that various operations of the wireless device 1402 are performed, as described herein. The processor(s) 1404 may include one or more baseband processors implemented using, for example, a central processing unit (CPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a controller, a field programmable gate array (FPGA) device, another hardware device, a firmware device, or any combination thereof configured to perform the operations described herein.

[0140] The wireless device 1402 may include a memory 1406. The memory 1406 may be a non-transitory computer-readable storage medium that stores instructions 1408 (which may include, for example, the instructions being executed by the processor(s) 1404). The instructions 1408 may also be referred to as program code or a computer program. The memory 1406 may also store data used by. and results computed by. the processor(s) 1404.

[0141] The wireless device 1402 may include one or more transceiver(s) 1410 that may include radio frequency (RF) transmitter circuitry and / or receiver circuitry that use the antenna(s) 1412 of the wireless device 1402 to facilitate signaling (e.g., the signaling 1434) to and / or from the wireless device 1402 with other devices (e.g., the network device 1418) according to corresponding RATs.

[0142] The wireless device 1402 may include one or more antenna(s) 1412 (e.g., one, two, four, or more). For embodiments with multiple antenna(s) 1412, the wireless device1402 may leverage the spatial diversity of such multiple antenna(s) 1412 to send and / or receive multiple different data streams on the same time and frequency resources. This behavior may be referred to as, for example, multiple input multiple output (MIMO) behavior (referring to the multiple antennas used at each of a transmitting device and a receiving device that enable this aspect). MIMO transmissions by the wireless device 1402 may be accomplished according to precoding (or digital beamforming) that is applied at the wireless device 1402 that multiplexes the data streams across the antenna(s) 1412 according to known or assumed channel characteristics such that each data stream is received with an appropriate signal strength relative to other streams and at a desired location in the spatial domain (e.g., the location of a receiver associated with that data stream). Certain embodiments may use single user MIMO (SU-MIMO) methods (where the data streams are all directed to a single receiver) and / or multi user MIMO (MU-MIMO) methods (where individual data streams may be directed to individual (different) receivers in different locations in the spatial domain).

[0143] In certain embodiments having multiple antennas, the wireless device 1402 may implement analog beamforming techniques, whereby phases of the signals sent by the antenna(s) 1412 are relatively adjusted such that the (joint) transmission of the antenna(s) 1412 can be directed (this is sometimes referred to as beam steering).

[0144] The wireless device 1402 may include one or more interface(s) 1414. The interface(s) 1414 may be used to provide input to or output from the wireless device 1402. For example, a wireless device 1402 that is a UE may include interface(s) 1414 such as microphones, speakers, a touchscreen, buttons, and the like in order to allow for input and / or output to the UE by a user of the UE. Other interfaces of such a UE may be made up of transmitters, receivers, and other circuitry (e.g., other than the transceiver(s) 1410 / antenna(s) 1412 already described) that allow for communication between the UE and other devices and may operate according to known protocols (e.g., Wi-Fi®, Bluetooth®, and the like).

[0145] The wireless device 1402 may include a data burst indicator module 1416. The data burst indicator module 1416 may be implemented via hardware, software, or combinations thereof. For example, the data burst indicator module 1416 may be implemented as a processor, circuit, and / or instructions 1408 stored in the memory' 1406 and executed by the processor(s) 1404. In some examples, the data burst indicator module 1416 may be integrated within the processor(s) 1404 and / or the transceiver(s)1410. For example, the data burst indicator module 1416 may be implemented by a combination of software components (e.g., executed by a DSP or a general processor) and hardware components (e.g., logic gates and circuitry) within the processor(s) 1404 or the transceiver(s) 1410.

[0146] The data burst indicator module 1416 may be used for various aspects of the present disclosure, for example, aspects of FIGS. 1-13. The data burst indicator module 1432 is configured to associate QoS flows associated with a data burst.

[0147] The network device 1418 may include one or more processor(s) 1420. The processor(s) 1420 may execute instructions such that various operations of the network device 1418 are performed, as described herein. The processor(s) 1420 may include one or more baseband processors implemented using, for example, a CPU, a DSP, an ASIC, a controller, an FPGA device, another hardware device, a firmware device, or any combination thereof configured to perform the operations described herein.

[0148] The network device 1418 may include a memory 1422. The memory 1422 may be a non-transitory computer-readable storage medium that stores instructions 1424 (which may include, for example, the instructions being executed by the processor(s) 1420). The instructions 1424 may also be referred to as program code or a computer program. The memory 1422 may also store data used by, and results computed by, the processor(s) 1420.

[0149] The network device 1418 may include one or more transceiver(s) 1426 that may include RF transmitter circuitry and / or receiver circuitry that use the antenna(s) 1428 of the network device 1418 to facilitate signaling (e.g., the signaling 1434) to and / or from the network device 1418 with other devices (e.g.. the wireless device 1402) according to corresponding RATs.

[0150] The network device 1418 may include one or more antenna(s) 1428 (e g., one, two, four, or more). In embodiments having multiple antenna(s) 1428, the network device 1418 may perform MIMO, digital beamforming, analog beamforming, beam steering, etc., as has been described.

[0151] The network device 1418 may include one or more interface(s) 1430. The interface(s) 1430 may be used to provide input to or output from the network device 1418. For example, a network device 1418 that is a base station may include interface(s) 1430 made up of transmitters, receivers, and other circuitry' (e.g., other than the transceiver(s) 1426 / antenna(s) 1428 already described) that enables the base station tocommunicate with other equipment in a core network, and / or that enables the base station to communicate with external networks, computers, databases, and the like for purposes of operations, administration, and maintenance of the base station or other equipment operably connected thereto.

[0152] The network device 1418 may include a data burst indicator module 1432. The data burst indicator module 1432 may be implemented via hardware, software, or combinations thereof. For example, the data burst indicator module 1432 may be implemented as a processor, circuit, and / or instructions 1424 stored in the memory 1422 and executed by the processor(s) 1420. In some examples, the data burst indicator module 1432 may be integrated within the processor(s) 1420 and / or the transceiver(s) 1426. For example, the data burst indicator module 1432 may be implemented by a combination of software components (e.g., executed by a DSP or a general processor) and hardware components (e.g., logic gates and circuitry) within the processor(s) 1420 or the transceiver(s) 1426.

[0153] The data burst indicator module 1432 may be used for various aspects of the present disclosure, for example, aspects of FIGS. 1-13. The data burst indicator module 1416 is configured to associate QoS flows, traffic flows, DRBs, RTP sessions or PDU sessions with a data burst.

[0154] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and / or methods as set forth herein. For example, a baseband processor as described herein in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth herein. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth herein.

[0155] Any of the above described embodiments may be combined with any other embodiment (or combination of embodiments), unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0156] Embodiments and implementations of the systems and methods described herein may include various operations, which may be embodied in machine-executable instructions to be executed by a computer system. A computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components that include specific logic for performing the operations or may include a combination of hardware, software, and / or firmware.

[0157] It should be recognized that the systems described herein include descriptions of specific embodiments. These embodiments can be combined into single systems, partially combined into other systems, split into multiple systems or divided or combined in other ways. In addition, it is contemplated that parameters, attributes, aspects, etc. of one embodiment can be used in another embodiment. The parameters, attributes, aspects, etc. are merely described in one or more embodiments for clarity', and it is recognized that the parameters, attributes, aspects, etc. can be combined with or substituted for parameters, attributes, aspects, etc. of another embodiment unless specifically disclaimed herein.

[0158] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

[0159] Although the foregoing has been described in some detail for purposes of clarity, it will be apparent that certain changes and modifications may be made without departing from the principles thereof. It should be noted that there are many alternative ways of implementing both the processes and apparatuses described herein. Accordingly, the present embodiments are to be considered illustrative and not restrictive, and the description is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

CLAIMS1. A method of operating a network node, the method comprising: receiving multiple quality of service (QoS) flows; determining which of the QoS flows correspond with a single data burst; and scheduling radio resources based on the QoS flows corresponding with the single data burst.

2. The method of claim 1, wherein determining which of the QoS flows correspond with the single data burst comprises identifying a relation of the QoS flows in a time domain by examining periodicity and burst arrival time (BAT) of each of the QoS flows.

3. The method of claim 1, further comprising receiving an End of Data Burst (EoDB) indication identifying a last PDU Set or a last packet of a PDU Set corresponding to the single data burst.

4. The method of claim 1, further comprising associating the QoS flows mapped to a same PDU session with the single data burst.

5. The method of claim 1, further comprising associating the QoS flows mapped to a same RTP session with the single data burst.

6. The method of claim 1, further comprising receiving additional assistance information as to which of the QoS flows would occur at a same time or in the single data burst.

7. The method of claim 1, further comprising receiving a parameter identifying an association of a current QoS flow with a set of other QoS flows via a time Sensitive communication assistance information (TSCAI) or via signaling from a user equipment (UE).

8. The method of claim 1, further comprising receiving common information for a set of related QoS flows.

9. The method of claim 1, wherein packet data unit (PDU) Set Information or information in a real-time protocol (RTP) header extension field or information signaled between a user equipment (UE) and a Radio Access Network (RAN) or informationsignaled within the RAN includes information about an association of the QoS flows with the single data burst.

10. The method of claim 1, further comprising receiving a real-time protocol (RTP) extension header comprising a field indicating whether a packet data unit (PDU) set associated with a start of a next data burst is going to be an important PDU set.

11. The method of claim 10, wherein the field indicates an importance level.

12. The method of claim 1, further comprising receiving a header extension field that indicates a next QoS flow expected to be transmitted.

13. A method of operating a user plane function (UPF), the method comprising: receiving multiple packet data unit (PDU) sets associated with a data burst; decoding bits of an end of data burst (EDB) field corresponding to one of the PDU sets to determine an end of the data burst; mapping the bits corresponding to the EDB field to an indication of the end of the data burst; and sending the indication of the end of the data burst to a network node.

14. The method of claim 13, wherein each bit position of the EDB field is associated with one traffic flow.

15. The method of claim 13, wherein each bit position is associated with a subset of one or more traffic flows.

16. The method of claim 13, wherein the bits comprise a bitmap with a value corresponding to a number of PDU sets until the end of the data burst.

17. The method of claim 13, further comprising sending, to the network node, an RTP extension header comprising a field indicating information about a next PDU set.

18. The method of claim 17, wherein the field indicates whether the next PDU Set that is associated with a start of a next data burst is an important PDU set.

19. The method of claim 18, wherein the field indicates an importance level.

20. The method of claim 13, further comprising sending a header extension field to indicate a next traffic flow or QoS flow expected to be transmitted.

21. An apparatus comprising means to perform the method of any of claim 1 to claim 20.

22. A computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform the method of any of claim 1 to claim 20.

Images