Indication of the end of a data burst

Abstract

In some embodiments, a network node may receive multiple Quality of Service (QoS) flows. The network node can determine which of the QoS flows corresponds to a single data burst and schedule radio resources based on the QoS flow corresponding to the single data burst. In some embodiments, the end of a data burst may be determined for multiple QoS flows corresponding to a single data burst.

Description

Technical Field

[0001] This application generally relates to a wireless communication system that includes signaling information regarding details of a data burst.

Background Art

[0002] Wireless mobile communication technologies use 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, the 3rd Generation Partnership Project (3GPP (registered trademark)) Long Term Evolution (LTE) (e.g., 4G), 3GPP (registered trademark) New Radio (NR) (e.g., 5G), and the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard for Wireless Local Area Network (WLAN) (commonly known to industry groups as Wi-Fi (registered trademark)).

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

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

[0005] Base stations used by a RAN can be compatible with that RAN. An example of an E-UTRAN base station is an Advanced Universal Terrestrial Radio Access Network (E-UTRAN) Node B (commonly also called Advanced Node B, Extended Node B, eNode B, or eNB). An example of an NG-RAN base station is a Next Generation Node B (sometimes referred to as gNode B or gNB).

[0006] A RAN provides communication services with external entities via a connection to the core network (CN). For example, E-UTRAN can utilize the Evolved Packet Core (EPC), and NG-RAN can utilize the 5G Core Network (5GC). [Brief explanation of the drawing]

[0007] To facilitate the identification of any particular element or action, the most significant digit(s) of the reference number refers to the number of the figure in which that element was first introduced. [Figure 1]Several network environments according to different embodiments are shown. [Figure 2] This illustrates data bursts that can be transmitted between application layers to exchange application data, according to several embodiments. [Figure 3] Time-dependent communication support information (TSCAI) is shown in several embodiments. [Figure 4] Several embodiments of TSC support containers are shown. [Figure 5] Several embodiments of the 1-byte RTP header extension format are shown. [Figure 6] Several embodiments of the 2-byte RTP header extension format are shown. [Figure 7] This document describes QoS classification processing for a single downlink flow network environment according to several embodiments. [Figure 8] This document demonstrates QoS classification behavior for PDU set marking for multiple downlink flows, according to several embodiments. [Figure 9] Three options for the EDB field are shown in several embodiments. [Figure 10] This figure shows an exemplary transmission timeline for XR traffic according to several embodiments. [Figure 11] Several embodiments of how to operate a network node are shown. [Figure 12] Several embodiments of how to operate the UPF are shown. [Figure 13] This specification shows an exemplary architecture of a wireless communication system according to embodiments disclosed herein. [Figure 14] This specification discloses a system for performing signaling between a wireless device and a network device, according to embodiments of this specification. [Modes for carrying out the invention]

[0008] Various embodiments are described with respect to the UE. However, references to the UE are provided for illustrative purposes only. The exemplary embodiments may be used with any electronic component, which consists of hardware, software, and / or firmware capable of establishing connectivity to a network and exchanging information and data with the network. Thus, the UE described herein is used to represent any suitable electronic component.

[0009] Regarding data burst indication, there may be several potential development areas. For example, in the case of XR data, as will be discussed in more detail herein, there may be multiple PDU sets during a data burst. If there is indication of the end of a data burst, the system can improve resource efficiency. Some embodiments herein provide an additional set of options for extending data burst end information.

[0010] Figure 1 shows a network environment 100 according to several embodiments. The network environment 100 may include a UE 102 that is communicatively coupled to an access node 104. The UE 102 and the access node 104 may communicate via an air interface that conforms to the 3GPP® TS, such as the one that defines the fifth-generation (5G) NR system standard. 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 to the UE 102.

[0011] The network environment 100 may further include a user plane function (UPF106) of the core network (CN), such as a fifth-generation core network (5GC). The UPF106 can be responsible for routing and forwarding user plane packets between the access node 104 and the external data network. The UPF106 can handle the user plane path of protocol data unit (PDU) sessions. The UPF106 may be coupled with a session management function (SMF) that constitutes traffic steering, QoS control, and policy-related functions in the UPF106 and performs PDU session management, IP address allocation, General-Purpose Packet Radio Services Tunneling Protocol - User Plane (GTP-U) tunnel management, selection and control of user plane functions, and downlink notification management.

[0012] Various components of the network environment 100 can perform Quality of Service (QoS) mapping operations for transmissions from the application / service layer 108. Unless otherwise described herein, these mapping operations may be similar to those described in the QoS model in Section 5.7 of 3GPP® TS 23.501 v17.9.0 (2023-06).

[0013] QoS mapping can be performed using a two-step method. In the first step, QoS flow classification may be performed to classify packets as part of a traffic discovery (or application discovery) process for QoS enforcement in a 5G system. Packets may be mapped to one or more QoS flows. A single PDU session may contain multiple QoS flows. In the second step, QoS flows may be mapped to data radio bearers (DRBs) for transmission over access network resources. UE 102 may perform the first step in step 110 and the second step in step 112. That is, access node 104 may perform the second step in step 114, and UPF 106 may perform the first step in step 116.

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

[0015] The stack represents the access and non-access layer protocol layers of UE102, providing communication over the wireless access network and core network. In step 110, the stack can perform QoS flow classification based on QoS rules by mapping uplink packets from IP flows to QoS flows and applying QoS flow markings. All packets in a QoS flow may be marked with the same QoS flow identifier (QFI). Figure 1 shows three QoS flows corresponding to QFI(1), QFI(2), and QFI(3).

[0016] Typically, traffic associated with the same QFI receives the same QoS processing. QFI can be used as a U-plane marking on the N3 interface (between RAN and UPF) and the N9 interface (between two UPFs) and can be unique within a PDU session. In some cases, QFI can also be carried in the radio header via the radio interface (Uu).

[0017] The stack can also perform QoS flow-DRB mapping at stage 112 to map the QoS flow to access network resources. The mapping at stage 112 can be an access layer operation performed, for example, by the service data adaptation protocol (SDAP) layer of the stack. Different QoS flows can be mapped to the same or different DRBs (e.g., n:1 or 1:1 mapping). Some 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 can add a new DRB with the corresponding QFI mapping to meet the QoS characteristics of the QoS flow. UE102 can determine the uplink data QoS binding (the association between the QoS flow and the DRB) based on explicit QoS signaling or determine the reflective QoS signaling based on downlink data QoS marking.

[0018] The access node 104 can perform flow mapping from DRB to QoS at stage 114, and the UPF106 can perform mapping from the QoS flow to the IP flow at stage 116. The IP flow can be provided to the application / service layer 108 that can reside in a device communicating with the UE102 in the data network (DN), or in the opposite direction, or within the UE102 itself. The application / service layer 108 can be, for example, in a server connected to the Internet via a digital subscriber line or a wireless local area network, another UE, or another XR user.

[0019] On the downlink, the UPF106 can perform QoS classification at stage 116 by classifying IP packets for QoS flow marking and other actions based on packet detection rules (PDRs).

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

[0021] The application / service layer 108 can operate on an application data unit (ADU) or PDU set that can be regarded as the smallest independently usable data unit. One ADU or PDU set can include a plurality of lower layer packets or PDUs. For example, one ADU or PDU set can include two or more RTP / IP packets or PDUs. Generally, there can be a 1:1 mapping between RTP packets and IP packets. However, in some cases, one RTP packet may be transmitted in multiple IP packets using IP fragmentation. This can be based on the maximum transmission unit (MTU) size available on the link. Furthermore, some RTP payload formats can enable aggregating multiple ADU or PDU sets into a single RTP payload.

[0022] An ADU can specify the coding format and RTP payload format within a 3GPP® file format (3GP) file. For audio and speech, an ADU can be specified as an encoded frame intended for transport. For the H.263 video compression standard, an ADU may contain the entire RTP payload. For the H.264 Advanced Video Coding (AVC) 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 contain any of the Type 1-5 RTP payload units. Other payload formats may exist, for example, in RFCs, 3GP files, etc., or may be application-specific.

[0023] Application / service layer 108 may operate on a set of PDUs, ADUs, or a larger data burst (represented by a bitstream), where the data burst may include a set of ADUs or PDU sets. A single set of PDUs or ADUs within a set may be packetized into multiple lower-layer data packets smaller than the ADU or PDU set. For example, an ADU or PDU set may be packetized into multiple RTP packets mapped to multiple IP packets or SDAP / Packet Data Convergence Protocol (PDCP) service data units (SDUs).

[0024] In some embodiments, the CN may control packet filtering within the wireless system. For a given service data flow (SDF), the coupling of service requirements and QoS flows may be based on policy and billing control (PCC) rules provided by a policy control function (PCF). A session management function (SMF) can perform binding of PCC rules to QoS flows based on QoS and service requirements. The SMF can provide QoS rules to the UE and PDRs to the UPF. These are also known as packet filters. For default PCC rules: traffic discovery filters (e.g., packet filters in UPF106) may be configured within the SMF and provided to UPF106 as one or more service data flow filters, or configured within UPF106 as application discovery filters identified by an application identifier.

[0025] One area of ​​research for developing QoS is providing support for low-latency communications and Extended Reality (XR) applications. Relevant key performance indicators (KPIs) and aspects of quality of service (QoS) can specify QoS, PDU set or application data unit (ADU) based QoS, and radio access network (RAN) support for enhanced granularity for XR-specific QoS parameters. QoS flow processing and corresponding data radio bearer (DRB) control may also be specified.

[0026] XR services can operate on a set of packet data units (PDUs) consisting of multiple IP packets. A set of PDUs can be mapped to a QoS flow. A set of PDUs can be identified by PDU set QoS parameters, as described in Section 5.7.7 v18.2.2 (2023-06) of Technical Specification (TS) 23.501, and by in-band markings known as PDU set information, as described in Section 5.37.5 of TS 23.501.

[0027] UPF106 may provide a protocol description indicating the protocols and payload types used by the SDF. The PCF can provision protocol descriptions within the PCC rules based on information provided by the Application Function (AF) and / or Local Operator Policy, and the SMF can configure UPF106 accordingly. Further details are provided in 23.501.

[0028] Figure 2 shows data bursts 202 that may be transmitted between application layers to exchange application data, according to several embodiments. A data burst may be a bitstream of related application data 204. The data may correspond to applications such as XR applications.

[0029] A bitstream can be divided into multiple Application Data Units (ADUs). A data burst 202 may contain a set of ADUs or a set of PDUs 206. Application layer data for XR is generally delivered in bursts that occur relatively periodically. The term PDU set can be considered equivalent to ADU in the context of XR.

[0030] A PDU set can be considered the smallest data unit that can be processed independently by the application layer. A single PDU set can contain multiple lower-layer packets or PDUs for over-the-air transmission. For example, a single PDU set can be packetized into multiple lower-layer packets or PDUs. A data burst 202 can consist of several PDU sets 206, each PDU set transmitted in several 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 can be defined as a set of multiple PDUs generated and transmitted by an application in a short period of time. A data burst can consist of one or more PDU sets.

[0031] From an application layer perspective, a data burst 202 can be associated with one or more PDU sets 206. Then, the PDU sets 206 in the data burst 202 can be associated with the same or different XR traffic flows, SDFs, or IP flows, and therefore they can be mapped to one or more QoS flows.

[0032] Figure 3 shows time-dependent communication (TSC) support information (TSCAI300), and Figure 4 shows the TSC support container (TSCAC400). A CN can use TSCAI300 and TSCAC400 (as defined in TS 23.501, Section 5.27) to provide network nodes with information regarding the characteristics of XR traffic flows. This information is provided at the QoS flow granularity. For example, TSCAI300 and TSCAC400 describe periodicity, referring to the time period between the start of two data bursts and the arrival time of the data bursts. This information is defined at the QoS flow granularity. However, multiple QoS flows may belong to the same data burst. Therefore, some embodiments of this specification describe methods for better defining data bursts. The more information a network node has for a data burst, the more efficiently it can schedule resources for the UE.

[0033] The PCF can provision protocol descriptions within PCC rules based on information provided by the AF and / or local operator policies. The protocol descriptions can be used to identify PDU set information, for example at the RTP level (e.g., via the N6 interface), to enable the UPF106 to map PDUs or packets associated with a PDU set within the radio system (e.g., on the N3 interface).

[0034] In addition, extensions for session reporting and UE power management may include data burst termination indications. These indications may relate to data bursts associated with QoS flows, as described in TSCAI300 / TSCAC400, or to data bursts that may generally encompass multiple QoS flows.

[0035] End of Data Burst (EoDB) indications can be provided to the Radio Access Network (RAN) by the UPF106. For example, End of Data Burst may be provided to the RAN to configure a UE power management scheme such as Connectivity Mode DRX. In accordance with requests and information from the SMF, the UPF106 can identify the last PDU of a data burst in downlink traffic based on the termination indication by protocol description and can provide the End of Data Burst indication to the RAN via the GPRS Tunneling Protocol (GTP-U) for the user plane of the last PDU of the data burst.

[0036] Using additional bits to indicate inter-burst times, which can vary dynamically for various reasons including application layer rate control, may be beneficial. This can allow the RAN to switch to the most appropriate power state. For example, there may be multiple bits to indicate the end of a frame or PDU set. Indicating when a data burst occurs may be useful for power saving. Other benefits of using additional bits may include ambiguity related to setting the M bit set in the RTP header, such as signaling extra data burst information (e.g., when multiple QoS flows belong to a data burst) or even as a mitigation in case a PDU with the EoDB bit does not reach the receiver.

[0037] Figure 5 shows a one-byte RTP header extension format 500 according to several embodiments. Figure 6 shows a two-byte RTP header extension format 600 according to several 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, an EDB field 504, and a PSI field 506.

[0038] The E field 502 is a 1-bit field that indicates the last PDU in a PDU set. The E field 502 is a flag that is set to 1 for the last PDU in a PDU set and to 0 for all other PDUs in the PDU set.

[0039] The EDB field 504 indicates the end of a data burst. The EDB field 504 is 3 bits long and indicates the end of a data burst. The 3 bits encode the indication of the end of a data burst according to the encoding guidelines provided in some embodiments.

[0040] The PSI field 506 is 4 bits and represents the importance of the PDU set. The PSI field 506 indicates the importance of this PDU set compared to other PDU sets within the same RTP stream or the same QoS flow. In Rel-18, the PSI field 506 can use two importance levels (1 bit). However, 3-4 bits can be used to provide additional granularity.

[0041] The first area of ​​interest may be when multiple media flows are associated with a data burst, as described elsewhere in this specification. Some of the embodiments may be used to determine the end of a data burst in such cases. For example, TSCAI and TSCAC are currently defined at the granularity of the QoS flows associated with a data burst. Even when two or more QoS flows are associated with a data burst, it may be possible to uniquely identify the end of the data burst.

[0042] A second area of ​​concern is the assumption that network nodes are provided with burst arrival times and periodicity via TSCAI. This information is provided for each QoS flow. Therefore, network nodes will know when multiple QoS flows are expected to arrive simultaneously. However, one of the traffic characteristics of XR is that the amount of data carried over a period of time is not always constant and can arrive in bursts. Therefore, data bursts do not always end simultaneously. The same is true for the start of the next data burst.

[0043] In some cases, an information network node may infer that incorrect data will arrive next. For example, a network node might infer (based on its knowledge from TSCAI) that data for QFI5 will arrive next, but in reality, QFI5 may not have application layer data for some time, and instead, QFI7 (also associated with the same RTP session) will have the data. The arrival time of QFI7 may be known to the network node. What is unknown to the network node is that QFI7 will be transmitted next. In some embodiments, the EDB field 504 (or a new RTP header extension) may convey such information. It should be noted that one of the traffic characteristics of XR is that the amount of data carried over a period of time is not always constant but bursty.

[0044] Figure 7 illustrates QoS classification operations 700 in a network environment 100 according to several embodiments. An exemplary 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.

[0045] The QoS classification operation 700 maps both PDU set #1 and PDU set #2 to a single QoS flow (QoS flow 1). The SMF 702 can provide packet filters to the UPF 106 as PDRs and to the UE stack 704 as QoS rules. For a given SDF, the coupling of service requirements and QoS flows can be based on policy and billing control (PCC) rules provided to the SMF 702 by the core network's policy control function (PCF) or application function (AF). The UPF 106 can receive the EDB 708 and E field as input (e.g., in the form of markings on the N6 interface) at DL. The UPF 106 can identify data bursts and insert EoDB markings into the last user plane packets of the data burst. The EoDB may be output toward the N3 interface. For example, the UPF may include an EoDB field 706 in the last packet of a data burst to communicate that PDU set #2 is the last PDU set of the data burst and to mark the PDUs indicating the end of the data burst.

[0046] Figure 8 shows a QoS classification operation 800 for PDU set marking for multiple downlink flows in several embodiments. The QoS classification operation 800 maps IP flows to QoS flows. SMF702 can provide packet filters to UPF106 as PDRs and to the UE stack 704 as QoS rules. For a given SDF, the coupling of service requirements and QoS flows can be based on policy and billing control (PCC) rules provided to SMF702 by the PCF or AF of the core network. UPF106 can include an EoDB field 804 in the last packet of the last PDU set of a data burst (e.g., PDU set #2 of IP flow 1) to communicate that the PDU set is the last PDU set of the data burst and mark the PDU as indicating the end of the data burst. The EoDB field 804 can mark the last PDU set on the downlink from the server.

[0047] Some embodiments of this specification provide an additional set of options for extending data burst termination information. Extensions can be made by assigning different semantics to the EDB field 504 or by introducing additional fields to the RTP header extension. Similarly, the UPF may need to be provided with rules for translating the proposed information to network nodes.

[0048] When multiple QoS flows are associated with a data burst termination indication, it can be useful for the system (particularly network nodes) to identify those flows. Therefore, some embodiments of this specification identify multiple QoS flows associated with such indications. When multiple DRX configurations exist, or when switching DRX configurations is supported for the UE, network nodes can utilize data burst termination to optimize the switching of DRX patterns. For example, a DRX configuration may have multiple offsets, which can be adjusted based on a pattern for the set of QoS flows associated with the data burst. Precise information about QoS flow versus data burst associations can also help network nodes prepare scheduling resources accordingly, as well as allocate CG / SPS.

[0049] Furthermore, network nodes can provide support information to the SMF702 and the core network to assist the UPF106 in identifying which QoS flows will be scheduled for near-simultaneous transmission (e.g., on the downlink). Alternatively, the UPF106 can extract this information from control information received from the SMF702 without such indication.

[0050] XR applications can utilize multiple traffic flows, SDFs, IP flows, IP5 tuples, etc., as part of an XR session or connection. Since RTP header extensions can be indicated for each set of PDUs, an application (in an application server (AS) or UE) can mark the end of a data burst by updating the RTP header extension associated with the last set of PDUs in the data burst. UPFs can further mark the end of a data burst heading to a RAN node on an N3 interface.

[0051] According to the current SA2 / SA4 framework, UPF106 marks the end of a data burst with the last set of PDUs in the data burst. This means that network nodes (e.g., RANs) can use this information to allocate radio resources and optimize for power saving. However, when multiple QoS flows are associated with a data burst, it is unclear how network nodes and / or UEs will know the exact set of QoS flows associated with the data burst. Such recognition can be used to optimize the scheduling of radio resources and UE power saving, which can also improve spectral efficiency. Therefore, some embodiments of this specification provide means for identifying the end of a data burst, the last packet in a data burst, and / or the last set of PDUs in a data burst associated with multiple QoS flows.

[0052] In some embodiments, to identify relationships between QoS flows in the time domain, a network node (e.g., RAN) may examine the periodicity and burst arrival time (BAT) of any configured QoS flows. For example, QoS flows with similar BATs (and / or periodicities) in a time frame may belong to the same data burst. The network node can determine the BAT and periodicity from, for example, TSCAI300 or from UE-based indications to the RAN. The timing of the start and end of data bursts can be inferred from this information. For example, the network node may identify QoS flows whose periodicity or BAT overlaps in time and infer the start and end of data bursts (consisting of multiple QoS flows) from this information.

[0053] In DL, the UPF can also set an EoDB on any (i.e., one of several) PDU sets / QoS flows associated with a data burst. When an EoDB indication is observed, network nodes do not expect any further data on any of the other QoS flows associated with the same data burst (within the same time frame). Similarly, in UL, the UE can provide an EoDB indication for a QoS flow or DRB, or the RAN can infer the end of a data burst based on the BSR (Buffer Status Report) or by implementation (e.g., per DRB or per QoS flow). In such cases, based on derived knowledge or configurations 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.

[0054] In some embodiments, an application server (or UE application) can set an EoDB for each data burst traffic flow to identify the last PDU set or the last PDU of the last PDU set. However, UPF106 may, accordingly, reflect EoDB marking for any QoS flow (e.g., on N3 in DL or on N6 in UL). The EoDB may be a single bit set on the traffic flow to identify the last PDU set or the last PDU of the last PDU set. As shown in Figures 7 and 8, multiple mapping rules exist for QoS flow associations (1:1, N:1, 1:M) between IP flows and QoS flows, and therefore this option can lead to more complex operation in the UPF106 / core network.

[0055] In such embodiments, the last PDU set or the last PDU in each QoS flow may have an RTP marking indicating the end of a data burst. In the case of a 1:1 mapping between IP flows and QoS flows, UPF106 can insert the EoDB marking into the RAN (e.g., on N3) or the DN (e.g., on N6). In the case of an N:1 mapping, the application server can set up EoDBs on N last PDU sets, but UPF106 may only consider one of them. In the case of a 1:M mapping, the application server can set up EoDBs for M last PDU sets on flows (1:M is configured by AS / AF), and UPF106 can ensure that this PDU set is sent to the RAN as the last PDU set.

[0056] In some embodiments, a UE or network node can associate multiple QoS flows mapped to the same PDU session or the same RTP session with a data burst. This may be defined in the specification or implemented by the implementation.

[0057] In some embodiments, a UE or network node can associate multiple QoS flows mapped to the same RTP session with a data burst. This may be defined in the specification or implemented by the implementation.

[0058] In some embodiments, network nodes may provide additional support information regarding the relationship between QoS flows and data bursts. This additional information may be provided to the network node in a separate information element (IE) or message and may provide information about which QoS flows will occur simultaneously and / or within the same data burst. Signaling of such information may be provided from the core network to the RAN (via N2 or N3) or alternatively from the UE to the RAN.

[0059] In some embodiments, the standard TSCAI300, which signals each QoS flow, may be extended to include additional parameters. These additional parameters may identify the relationship of the current QoS flow within a set of other QoS flows (e.g., in the time domain, for data bursts). The SMF702, based on PCC rules, can identify dependencies between QoS flows associated with a single TSCAI300 and supply parameter information accordingly. In some embodiments, the SMF702 can replicate the same TSCAI information (e.g., burst timing) for all QoS flows. Thus, the same timing information can be configured for all QoS flows.

[0060] Some embodiments introduce a new / common type of TSCAI applicable to multiple QoS flows. Network nodes may be given common information (e.g., in the time domain, about data bursts) about a set of relevant QoS flows through this new / common type of TSCAI. This type of TSCAI may not signal on a per-QoS flow basis. The new / common type of TSCAI may also have a reduced parameter set that targets only time-related information, such as burst timing.

[0061] In some embodiments, the PDU set information (see TS 23.501) and / or information within the RTP header extension fields (such as EDB field 504 or the new field) includes information regarding the association of multiple XR traffic flows, SDFs, or QoS flows with data bursts. In some embodiments, the system can receive, for example, I-frames and P-frames (or PDU sets of different PDU sets or different PSIs) in the same SDF or IP5 tuple, which can then map different media frames (e.g., I and P, or PDU sets of different PDU set types or different PSIs) to different QoS flows in the future.

[0062] In the embodiments described above, not only the core network but also the UE may provide additional support information to the network nodes. For example, the additional support information may be provided as signaling, support information, or TSCAI from the UE to the RAN. The embodiments described in relation to additional support information may be combined or used separately. The embodiments described above relating to data burst termination information (such as EoDB, EDB, or related indications) may be combined or used separately.

[0063] In some embodiments, a data burst may consist of multiple XR traffic or QoS flows. When multiple IP flows, SDFs, or application layer traffic flows are associated with an EDB indication (e.g., EDB field 504), the application, RTP sender (and / or UPF) can set the EDB bits in several ways. Furthermore, bits or packets (PDUs) in a data burst may belong to the same application, target the same device, or target the same PDU session or RTP session.

[0064] Figure 9 shows three options for the EDB field 902. A field having multiple EDB bits can be utilized in at least one of the methods shown in Figure 9. In some embodiments, the EDB field 504 may be the EDB field 902 of a one-byte RTP header extension format 500 or a two-byte RTP header extension format 600. In some embodiments, the EDB bits may be part of a new field or an extended EDB field.

[0065] In the first option 904, every bit position is associated with a single 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 may indicate a third traffic flow or QoS flow. Bits may be used to indicate the end of a traffic flow or QoS flow. Alternatively or additionally, these bits can be used in combination with other bits in the RTP header extension or PDU set information, such as the E bit or PSI.

[0066] In the second option 906, any bit position can be associated with one or more subsets of traffic flows. Furthermore, the exact subset can be pre-configured on the NGAP / F1AP / E1AP, or, with respect to the UE side, on the 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 may indicate a third subset of QoS flows. For example, if the first subset of QoS flows may correspond to QoS flows 1, 3, and 5, bit 1 may be used to indicate the end of QoS flows 1, 3, and 5. Alternatively or additionally, bits may be used in combination with other bits in the RTP header extension or PDU set information, such as the E bit or PSI.

[0067] In the third option 908, 3 bits may be used as a bitmap. The meaning of the values ​​can be flexibly assigned based on the NGAP / F1AP / E1AP (for network nodes) or NAS / RRC / SDP (for UE) configuration. For example, the bitmap may represent a special event, such as an upcoming EoDB. For example, the bitmap may be provided as an early indication, where the EoDB is expected in x PDU sets (or x PDUs), and x is given by the bitmap. In some embodiments, the bitmap may be flexibly configured via the NGAP or SDP to contain specific information. For example, the bitmap may be configured to contain information unrelated to the end of a data burst, such as in-sequence / out-of-order delivery mode for PDU sets in a data burst, announcements of limits or constraints, or error events.

[0068] The EDB field 902 is not limited to 3 bits. Depending on the space available in the RTP extension header, more than 3 bits may be used for the EDB field 902. For example, the PSI field 506 may not require 4 bits, and therefore more bits may be available for the EDB field 902. If more than 3 bits are used, the first option 904 can support a larger number of traffic flows.

[0069] In some embodiments, if the first option 904, the second option 906, or the third option 908 is not used, the EDB bit may be set independently for each QoS flow configured to split the application stream. In this way, the EDB bit may be set for each set of PDUs configured to be transmitted in a separate QoS flow according to a packet discovery filter. This can be used, for example, in conjunction with embodiments described herein in which an application server (or UE application) sets EoDB for all traffic flows to identify the last set of PDUs or the last PDU of the last set of PDUs.

[0070] The UPF may decode the bits in EDB field 902 and map them to indications to the RAN on the downlink. Similarly, on the uplink, the UE may set the bits in EDB field 902, and the UPF may set them to N6 or map them to indications to the application server. Note that this introduces a kind of QoS inter-flow association (for control, not data).

[0071] In some embodiments, an RTP extension header can be used to indicate the PSI level of the next set of PDUs. To optimize the operation of the UPF or network node scheduler and / or to allocate radio resources sufficiently quickly, one field in the RTP extension header can be used to indicate some information about the next set of PDUs. The field may be a new field, or a bit pattern in the EDB field can be used. Such RTP extension header fields (on N6 and within UE) and N3-related GTP-U information can be provided through one or more of the following options.

[0072] In the first option, while indicating the last PDU in a data burst (e.g., via the "E" bit), the EDB field or new header field may indicate whether the set of PDUs associated with the start of the next data burst is a significant set. Optionally, the EDB field or new header field may indicate the significance level that the PDU set will have.

[0073] In the second option, the importance of the next set of PDUs may be indicated during the ongoing data burst transmission. For example, the indication may be provided midway through the data burst while the EoDB is not yet known (e.g., the "E" bit has not yet been set). The EDB or a new field may indicate whether the next set of PDUs is an important set and / or what importance level it will have.

[0074] A third option may indicate the QFI of the QoS flow to which the following (important) PDU set belongs. Indications for the QFI of the QoS flow may be added to the first and / or second options. In other words, the indications may be in parameters other than the EDB or new header fields used for such information.

[0075] In some embodiments, indications for the following PDU sets can be signaled as an index in the EDB. For example, the indication may be a value specifically defined for this purpose. In some embodiments, the indication may be signaled as a separate field in the RTP header extension and / or GTP-U header. The indication may be a single bit or multiple bits, depending on how many levels of PSI (PDU set importance) are intended to be supported. In some embodiments, the UPF may provide rules for matching RTP headers containing such information and forwarding them to network nodes via N3.

[0076] Assuming that such grouping (in the time domain) of multiple XR traffic flows exists, or can be composed of, for example, an application server, AF, UE, or UE application, a network node may be made aware of this information through signaling. In the first option, the network node may use this information to identify QoS flows that are suitable to be scheduled together in a semi-persistent scheduling (SPS) or configuration grant (CG). In the second option, the network node may associate a group of QoS flows with multiple intermittent receive (DRX) cycles. In some embodiments, TSCAI may include mapping of EDB indications. In some embodiments, the network node implementation may observe data burst end indications for a set of QoS flows over time to identify, for example, the remapping of QoS flows to different DRB / logical channel (LCH) or CG / SPS.

[0077] One characteristic of XR traffic flow is that its size and timing can vary. For example, more or less data may be transmitted than initially advertised. Figure 10 shows an exemplary transmission timeline 1000 for XR traffic. As illustrated, XR periodic traffic can be associated with random jitter, where the actual packet arrival time may be offset from the nominal timing (based on traffic periodicity). Furthermore, packet size also changes over time.

[0078] Configured scheduling, such as configuration grants (CGs) and semi-persistent scheduling (SPSs), can be extended to adapt to such traffic characteristics on the uplink. To handle fluctuating packet sizes using CGs with fixed transport block sizes (TBSs), the system may encounter the following situations: When the packet size is larger than the TBS of a CG occasion, it cannot be contained within a single CG cycle, which can cause latency. When the packet size is smaller than the TBS of a CG occasion, it is resource-inefficient. Network nodes may allocate resources to other UEs.

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

[0080] In some cases, network nodes can infer such information from TSCAI. However, the availability of buffer states and application layer inputs can vary due to the quasi-periodic nature of XR traffic (e.g., varying size and arrival timing). In some embodiments, the following PDU set indications may be provided when needed. For example, indications may be provided when PDU sets or data burst arrival times are expected to shift significantly or arrive in a different order. That is, as long as the buffer states (and / or PDU set sizes) and burst arrival times do not vary beyond (configured or specified) thresholds, the RAN may be expected to rely on the TSCAI configuration and does not need to be provided by the application server, UPF, or UE.

[0081] Since QoS flows are identified by 5 bits (and IP tuples / SDFs require far more than 3 bits), in embodiments where a 3-bit EDB is used for such indications, network nodes may provide additional configuration information for mapping purposes. Such mapping information may be set up and signaled separately. For example, a mapping table may be used.

[0082] Figure 11 shows a method 1100 for operating a network node according to several embodiments. Method 1100 includes receiving multiple QoS flows 1102. Method 1100 further includes determining which of the QoS flows corresponds to a single data burst 1104. Method 1100 further includes scheduling radio resources based on the QoS flow corresponding to a single data burst.

[0083] In some embodiments, determining which of the QoS flows corresponds to a single data burst involves identifying the relationships between the QoS flows in the time domain by examining the periodicity and burst arrival time (BAT) of each QoS flow.

[0084] In some embodiments, method 1100 further includes receiving a data burst end (EoDB) indication that identifies the last PDU set or the last packet of a PDU set corresponding to a data burst.

[0085] In some embodiments, method 1100 further includes associating a QoS flow mapped to the same PDU session with a data burst.

[0086] In some embodiments, method 1100 further includes associating a QoS flow mapped to the same RTP session with a data burst.

[0087] In some embodiments, method 1100 further includes receiving additional support information regarding which of the QoS flows occur simultaneously or during a data burst.

[0088] In some embodiments, method 1100 further includes receiving parameters that identify the association between the current QoS flow and a set of other QoS flows, either via TSCAI or signaling from the UE.

[0089] In some embodiments, method 1100 further includes receiving common information about a set of relevant QoS flows.

[0090] In some embodiments, the PDU set information, or information in the RTP header extension field, or information signaled between the UE and the RAN, or information signaled within the RAN, includes information relating to the association between QoS flows and data bursts.

[0091] In some embodiments, method 1100 further includes receiving an RTP extension header that includes a field indicating whether the set of PDUs associated with the start of the next data burst will be a critical set of PDUs. In some embodiments, the field indicates a criticality level.

[0092] In some embodiments, method 1100 further includes receiving a header extension field indicating the next QoS flow that is expected to be transmitted.

[0093] Embodiments contemplated herein include apparatus comprising means for performing one or more elements of Method 1100. This apparatus may be, for example, a base station apparatus (such as a network device 1418 which is a base station, as described herein).

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

[0095] Embodiments contemplated herein include devices comprising logic, modules, or circuits for performing one or more elements of Method 1100. Such devices may be, for example, base station devices (such as network device 1418, which is a base station, as described herein).

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

[0097] Embodiments intended herein include signals described in or related to one or more elements of Method 1100.

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

[0099] Figure 12 shows a method 1200 for operating the UPF according to several embodiments. Method 1200 includes receiving a plurality of PDU sets associated with a data burst 1202. Method 1200 includes decoding bits of the data burst end field corresponding to one of the PDU sets in order to determine the end of the data burst. Method 1200 includes mapping bits corresponding to the EDB field to an indication of the end of the data burst. Method 1200 includes transmitting the indication of the end of the data burst to a network node.

[0100] In some embodiments, each bit position in the EDB field is associated with a single traffic flow.

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

[0102] In some embodiments, the bits include a bitmap having values ​​corresponding to the number of PDU sets until the end of the data burst.

[0103] In some embodiments, method 1200 further includes sending an RTP extension header to a network node that includes a field indicating information about the next set of PDUs.

[0104] In some embodiments, the field indicates whether the next set of PDUs associated with the start of the next data burst is a critical set of PDUs.

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

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

[0107] Embodiments contemplated herein include apparatus comprising means for performing one or more elements of Method 1200.

[0108] Embodiments contemplated herein include one or more non-temporary computer-readable media comprising instructions that cause an electronic device to execute one or more elements of method 1200 when one or more processors of the electronic device execute instructions.

[0109] Embodiments contemplated herein include devices comprising logic, modules, or circuits for performing one or more elements of Method 1200.

[0110] Embodiments contemplated herein include an apparatus comprising one or more processors and one or more computer-readable media containing instructions that, when executed by the one or more processors, cause the one or more processors to execute one or more elements of Method 1200.

[0111] Embodiments intended herein include signals described in or related to one or more elements of Method 1200.

[0112] Embodiments intended herein include a computer program or computer program product that includes instructions, and the execution of the program by a processing element causes the processing element to execute one or more elements of method 1200.

[0113] Figure 13 shows an exemplary architecture of the wireless communication system 1300 according to embodiments disclosed herein. The following description is provided for an exemplary wireless communication system 1300 that operates with LTE system standards and / or 5G or NR system standards provided by 3GPP® technical specifications.

[0114] As shown in Figure 13, the wireless communication system 1300 includes UE1302 and UE1304 (however any number of UEs may be used). In this example, UE1302 and UE1304 are shown as smartphones (e.g., handheld touchscreen mobile computing devices that can connect to one or more cellular networks), but it may also include any mobile or non-mobile computing devices configured for wireless communication.

[0115] UE1302 and UE1304 may be configured to communicate with RAN1306. In an embodiment, RAN1306 may be NG-RAN, E-UTRAN, etc., and UE1302 and UE1304 utilize connections (or channels) with RAN1306 (referred to as connection 1308 and connection 1310, respectively), each of which has a physical communication interface. RAN1306 may include one or more base stations (such as base stations 1312 and 1314) that enable connections 1308 and connection 1310.

[0116] In this example, connections 1308 and 1310 are air interfaces to enable such communication coupling and may correspond to RAT(s) used by RAN1306, such as LTE and / or NR.

[0117] In some embodiments, UE1302 and UE1304 can also directly exchange communication data via the sidelink interface 1316. UE1304 is configured to access an access point (shown as AP1318) via connection 1320, as shown in the figure. For example, connection 1320 may be a local radio connection such as a connection matching any IEEE 802.11 protocol, and AP1318 may be a Wi-Fi® router. In this example, AP1318 may be connected to another network (e.g., the Internet) without going through CN1324.

[0118] In this embodiment, UE1302 and UE1304 can be configured to communicate with each other or with base stations 1312 and / or 1314 using orthogonal frequency division multiplexing (OFDM) communication signals over a multi-carrier communication channel according to various communication technologies, such as orthogonal frequency division multiplexing (OFDMA) communication technology (e.g., for downlink communication) or single-carrier frequency division multiplexing (SC-FDMA) communication technology (e.g., for uplink and ProSe or sidelink communication), and the scope of the embodiment is not limited in this respect. The OFDM signal may include multiple orthogonal subcarriers.

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

[0120] RAN1306 is shown to be communicatively coupled to CN1324. CN1324 may comprise one or more network elements 1326 configured to provide various data and telecommunications services to customers / subscribers (e.g., users of UE1302 and UE1304) connected to CN1324 via RAN1306. The components of CN1324 may be implemented in one or separate physical devices, including components for reading and executing instructions from machine-readable or computer-readable media (e.g., non-temporary machine-readable storage media).

[0121] In the embodiment, CN1324 may be an EPC, and RAN1306 may be connected to CN1324 via S1 interface 1328. In the embodiment, S1 interface 1328 may be divided into two parts: an S1 user plane (S1-U) interface that carries traffic data between base station 1312 or base station 1314 and a serving gateway (S-GW), and an S1-MME interface which is a signaling interface between base station 1312 or base station 1314 and a mobility management entity (MME).

[0122] In the embodiment, CN1324 may be 5GC, and RAN1306 may be connected to CN1324 via NG interface 1328. In the embodiment, NG interface 1328 may be divided into two parts: an NG user plane (NG-U) interface that carries traffic data between base station 1312 or base station 1314 and user plane functions (UPF), and an S1 control plane (NG-C) interface that is a signaling interface between base station 1312 or base station 1314 and access and mobility management functions (AMF).

[0123] Generally, the application server 1330 may be an element that provides applications using Internet Protocol (IP) bearer resources (e.g., packet-switched data services) with the CN1324. The application server 1330 may also be configured to support one or more communication services (e.g., VoIP sessions, group communication sessions, etc.) for the UE1302 and UE1304 via the CN1324. The application server 1330 may communicate with the CN1324 via the IP communication interface 1332.

[0124] Figure 14 shows a system 1400 for performing signaling 1434 between a wireless device 1402 and a network device 1418 according to embodiments disclosed herein. System 1400 may be part of a wireless communication system as described herein. The wireless device 1402 may be, for example, a UE of the wireless communication system. The network device 1418 may be, for example, a base station (e.g., eNB or gNB) of the wireless communication system.

[0125] The wireless device 1402 may include one or more processors 1404. The processors 1404 can execute instructions to perform various operations of the wireless device 1402 as described herein. The processors 1404 may include one or more baseband processors, which are 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.

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

[0127] The wireless device 1402 may include one or more transceivers 1410, which may include radio frequency (RF) transmitter and / or receiver circuits that use the antenna 1412 of the wireless device 1402 to facilitate signaling (e.g., signaling 1434) between the wireless device 1402 and other devices (e.g., one or more network devices 1418) according to the corresponding RAT.

[0128] A wireless device (one or more) 1402 may include one or more antennas 1412 (e.g., one, two, four, or more). In embodiments having multiple antennas (one or more) 1412, the wireless device 1402 may leverage the spatial diversity of such multiple antennas (one or more) 1412 to transmit and / or receive multiple different data streams on the same time and frequency resources. This behavior is sometimes referred to as multiple input multiple output (MIMO) behavior (referring to the multiple antennas used in each of the transmitting and receiving devices that enable this embodiment). MIMO transmission by the wireless device 1402 may be achieved according to precoding (or digital beamforming) applied in the wireless device 1402, which multiplexes the data streams across the antennas (may be multiple) 1412 according to known or assumed channel characteristics so that each data stream is received at a desired location in the spatial domain (e.g., the location of the receiver associated with that data stream) with appropriate signal strength relative to the other streams. Certain embodiments may employ a single-user MIMO (SU-MIMO) method (where all data streams are directed to a single receiver) and / or a multi-user MIMO (MU-MIMO) method (where individual data streams may be directed to individual (different) receivers at different locations within the spatial domain).

[0129] In certain embodiments having multiple antennas, the wireless device 1402 may implement analog beamforming technology so that the phase of the signals transmitted by antenna(s) 1412 is relatively adjusted so that the (joint) transmission of antenna(s) 1412 can be directed (this is sometimes referred to as beam steering).

[0130] The wireless device 1402 may include one or more interfaces 1414. Interfaces 1414 may be used to provide input to or output from the wireless device 1402. For example, the wireless device 1402, which is a UE, may include interfaces 1414 such as microphones, speakers, touchscreens, and buttons to enable input and / or output to the UE by a user of the UE. Other interfaces of such a UE may consist of transmitters, receivers, and other circuits (other than, for example, the transceivers 1410 / antennas 1412 already described) that enable communication between the UE and other devices and may operate according to known protocols (e.g., Wi-Fi®, Bluetooth®, etc.).

[0131] 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 a combination thereof. For example, the data burst indicator module 1416 may be implemented as an instruction 1408 stored in a processor, circuit, and / or memory 1406 and executed by a processor(s) 1404. In some examples, the data burst indicator module 1416 may be incorporated into a processor(s) 1404 and / or a 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 general-purpose processor) and hardware components (e.g., logic gates and circuits) within a processor(s) 1404 or a transceiver(s) 1410.

[0132] The data burst indicator module 1416 may be used for various aspects of the present disclosure, for example, the aspects shown in Figures 1 to 13. The data burst indicator module 1432 is configured to associate QoS flows related to data bursts.

[0133] The network device 1418 may include one or more processors 1420. The processors 1420 can execute instructions to perform various operations of the network device 1418, as described herein. The processors 1420 may include one or more baseband processors, implemented using, for example, a CPU, DSP, ASIC, controller, FPGA device, another hardware device, firmware device, or any combination thereof configured to perform the operations described herein.

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

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

[0136] The network device 1418 may include one or more antennas 1428 (e.g., one, two, four, or more). In embodiments having multiple antennas 1428, the network device 1418 can perform MIMO, digital beamforming, analog beamforming, beam steering, and the like, as described.

[0137] The network device 1418 may include one or more interfaces 1430. Interfaces 1430 may be used to provide inputs to or outputs from the network device 1418. For example, a network device 1418 that is a base station may include interfaces 1430 consisting of transmitters, receivers, and other circuits (other than, for example, transceivers 1426 / antennas 1428 already described) that enable the base station to communicate with other equipment in the core network and / or enable the base station to communicate with external networks, computers, databases, etc., for the purpose of operating, managing, and maintaining the base station or other equipment operably connected thereto.

[0138] 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 a combination thereof. For example, the data burst indicator module 1432 may be implemented as an instruction 1424 stored in a processor, circuitry, and / or memory 1422 and executed by a processor(s) 1420. In some examples, the data burst indicator module 1432 may be incorporated into a processor(s) 1420 and / or a 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 general-purpose processor) and hardware components (e.g., logic gates and circuits) within a processor(s) 1420 or a transceiver(s) 1426.

[0139] The data burst indicator module 1432 may be used for various embodiments of this disclosure, for example, the embodiments shown in Figures 1 to 13. The data burst indicator module 1416 is configured to associate a QoS flow, traffic flow, DRB, RTP session, or PDU session with a data burst.

[0140] In one or more embodiments, at least one of the components shown in one or more of the aforementioned figures may be configured to perform one or more operations, techniques, processes and / or methods as described herein. For example, a baseband processor described herein in relation to one or more of the aforementioned figures may be configured to operate according to one or more of the examples described herein. In another embodiment, a circuit associated with a UE, base station, network element, etc., as described above in relation to one or more of the aforementioned figures may be configured to operate according to one or more of the examples described herein.

[0141] Any of the embodiments described above can be combined with any other embodiment (or combination of embodiments) unless otherwise specified. The above descriptions of one or more implementation forms are illustrative and illustrative, but are not intended to be exhaustive or to limit the scope of the embodiments to the exact forms disclosed. Modifications and variations are possible based on the above teachings or can be learned from the practice of various embodiments.

[0142] The embodiments and implementations of the systems and methods described herein may include a variety of operations that can be embodied by machine-executable instructions performed by a computer system. The computer system may include one or more general-purpose computers or dedicated computers (or other electronic devices). The computer system may include hardware components that include specific logic for performing operations, or it may include a combination of hardware, software, and / or firmware.

[0143] It should be recognized that the systems described herein include descriptions of specific embodiments. These embodiments may be combined into a single system, partially combined into other systems, divided into multiple systems, or otherwise divided or combined. In addition, parameters, attributes, aspects, etc. of one embodiment are intended to be used in another embodiment. Parameters, attributes, aspects are described in one or more embodiments for clarity only, and it should be recognized that parameters, attributes, aspects, etc. may be combined with or substituted for parameters, attributes, aspects, etc. of another embodiment unless specifically abandoned herein.

[0144] It should be fully understood that the use of personally identifiable information should adhere to privacy policies and practices that are generally recognized as meeting or exceeding industry or government requirements for maintaining user privacy. In particular, personally identifiable information data should be managed and handled in a manner that minimizes the risk of unintended or unauthorized access or use, and the nature of authorized use should be clearly indicated to the user.

[0145] While the foregoing has been described in some detail for clarity, it will be clear that certain changes and modifications can be made without departing from the principles. It should be noted that there are many alternative ways of implementing both the processes and apparatus described herein. Therefore, these embodiments should be considered illustrative and not limiting, and the description is not limited to the details given herein and may be modified within the appended claims and equivalents.

Claims

1. A method for operating a network node, wherein the method is Receiving multiple Quality of Service (QoS) flows, Determining which of the aforementioned QoS flows corresponds to a single data burst, A method comprising scheduling wireless resources based on the QoS flow corresponding to the single data burst.

2. The method according to claim 1, wherein determining which of the QoS flows corresponds to the single data burst includes identifying the relationship of the QoS flows in a time domain by examining the periodicity and burst arrival time (BAT) of each of the QoS flows.

3. The method according to claim 1, further comprising receiving a data burst end (EoDB) indication that identifies the last PDU set or the last packet of a PDU set corresponding to the single data burst.

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

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

6. The method according to claim 1, further comprising receiving additional support information regarding which of the QoS flows occur simultaneously or within a single data burst.

7. The method according to claim 1, further comprising receiving parameters that identify the association between the current QoS flow and a set of other QoS flows via time-dependent communication support information (TSCAI) or signaling from a user device (UE).

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

9. The method according to claim 1, wherein the packet data unit (PDU) set information, or information in a real-time protocol (RTP) header extension field, or information signaled between a user device (UE) and a radio access network (RAN), or information signaled within the RAN, includes information relating to the association between the QoS flow and the single data burst.

10. The method according to claim 1, further comprising receiving a Real-Time Protocol (RTP) extension header that includes a field indicating whether the set of packet data units (PDUs) associated with the initiation of the next data burst will be a critical set of PDUs.

11. The method according to claim 10, wherein the field indicates the importance level.

12. The method according to claim 1, further comprising receiving a header extension field indicating the next QoS flow that is expected to be transmitted.

13. A method for operating a user plane function (UPF), wherein the method is: Receiving multiple packet data unit (PDU) sets related to a data burst, To determine the end of the data burst, the bits of the data burst end (EDB) field corresponding to one of the PDU sets are decoded, Mapping the bit corresponding to the EDB field to the indication of the end of the data burst, A method comprising transmitting the indication of the termination of the data burst to a network node.

14. The method according to claim 13, wherein each bit position in the EDB field is associated with a single traffic flow.

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

16. The method according to claim 13, wherein the bit includes a bitmap having values ​​corresponding to the number of PDU sets up to the end of the data burst.

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

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

19. The method according to claim 18, wherein the field indicates the importance level.

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

21. An apparatus comprising means for carrying out the method described in any one of claims 1 to 20.

22. A computer-readable medium containing instructions, wherein, when the instructions are executed by one or more processors of an electronic device, the electronic device causes the electronic device to perform the method according to any one of claims 1 to 20.

Images