Features associated with PDU set information for multiplexing data streams

Abstract

Systems, methods, and instrumentalities are presented for handling packet data unit (PDU) set information for multiplexed data streams. A network node can generate a multiplexed data stream including a first PDU set, a second PDU set, and an indication of non-sequential PDU set sequence numbers. The first PDU set can be associated with a first data stream. The second PDU set can be associated with a second data stream. The apparatus can determine a first mapping between a first subset of the non-sequential PDU set sequence numbers and first sequential PDU set sequence numbers associated with the first data stream. The apparatus can determine a second mapping between a second subset of the non-sequential PDU set sequence numbers and sequential PDU set sequence numbers associated with the second data stream. The apparatus can transmit the multiplexed data stream, an indication of the first mapping, and an indication of the second mapping.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 574,359, filed April 4, 2024, the contents of which are incorporated herein by reference. Background Technology

[0002] Mobile communication using wireless communication continues to evolve. The fifth generation can be referred to as 5G. Previous (traditional) generations of mobile communication can be, for example, fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0003] This paper describes systems, methods, apparatuses, and tools related to the processing of PDU set information for multiplexing data streams.

[0004] An apparatus (e.g., a network node) can generate a multiplexed data stream including a first set of Packet Data Units (PDUs), a second set of PDUs, and indications of sequence numbers for non-sequential PDU sets. The first set of PDUs may be associated with a first data stream. The second set of PDUs may be associated with a second data stream. The apparatus can determine a first mapping between a first subset of the non-sequential PDU set sequence numbers and a first set of sequence numbers of the sequential PDU sets associated with the first data stream. The apparatus can determine a second mapping between a second subset of the non-sequential PDU set sequence numbers and a second set of sequence numbers of the sequential PDU sets associated with the second data stream. The apparatus can transmit the multiplexed data stream, the indication of the first mapping, and the indication of the second mapping.

[0005] An apparatus (e.g., a network node) may receive a first multiplexed data stream, the first multiplexed data stream including a first set of Packet Data Units (PDUs), a second set of PDUs, and an indication of a sequence number for an out-of-order PDU set. The first set of PDUs may be associated with the first data stream. The second set of PDUs may be associated with a second data stream. The apparatus may determine a first mapping associated with the first data stream based on the sequence number of the out-of-order PDU set. The apparatus may determine a second mapping associated with the second data stream based on the sequence number of the out-of-order PDU set. The apparatus may transmit the second multiplexed data stream, the indication of the first mapping, and the indication of the second mapping.

[0006] The device (e.g., a first network node) may receive configuration information indicating information associated with multiplexed data streams and information associated with split data streams. The device may receive data from an application server. The device may identify a first stream and a second stream in the received data. Based on the configuration information, the device may determine a first mapping between the first stream and a first Quality of Service (QoS) stream, and a second mapping between the second stream and a second QoS stream. Based on the first and second mappings, the device may determine metadata associated with the received data. The device may send the received data and metadata to a second network node.

[0007] Information associated with a multiplexed flow indicates the number of multiplexed flows. Information associated with a split data flow indicates one or more QoS flows carrying the split flow.

[0008] Metadata may indicate at least one of the following: information to help the second network node identify multiplexed streams in the received data, information about where the set of PDUs of the split stream is found, or sequence number offset. Attached Figure Description

[0009] Figure 1A This is a system diagram illustrating an exemplary communication system that can implement one or more of the disclosed embodiments.

[0010] Figure 1B The illustration is based on an embodiment and can be used Figure 1A The diagram shows a system diagram of an exemplary wireless transmit / receive unit (WTRU) used in a communication system.

[0011] Figure 1C The illustration is based on an embodiment and can be used Figure 1A The diagram shows an exemplary radio access network (RAN) and an exemplary core network (CN) used within a communication system.

[0012] Figure 1D The illustration is based on an embodiment and can be used Figure 1A The diagram shows another exemplary RAN and another exemplary CN used within the communication system.

[0013] Figure 2 The diagram illustrates an exemplary Quality of Service (QoS) management system.

[0014] Figure 3 The diagram illustrates an example of a multiplexed flow.

[0015] Figure 4 The illustration shows an exemplary technique for creating multiplexed streams.

[0016] Figure 5 The illustration shows an example of a service on a multiplexed QoS flow.

[0017] Figure 6 The illustration shows an example of PDU set information carried in a QoS flow.

[0018] Figure 7A and Figure 7B The illustration shows an exemplary downlink extended real-world flow multiplexed over one or more QoS flows. Detailed Implementation

[0019] Figure 1AThis diagram illustrates an exemplary communication system 100 that can implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcasting, etc., to multiple wireless users. The communication system 100 enables multiple wireless users to access this content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero Tail Unique Word DFT Spread Spectrum OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0020] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. As an example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (WTRUs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain scenarios), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any WTRU in WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a WTRU.

[0021] The communication system 100 may also include base station 114a and / or base station 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks (such as CN 106 / 115, Internet 110, and / or other networks 112). As an example, base stations 114a and 114b may be base transceivers (BTS), Node-B, eNodeB, home Node B, gNB, NR NodeB, field controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are depicted as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0022] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0023] Through air interface 116, base stations 114a and 114b can communicate with one or more WTRUs among WTRUs 102a, 102b, 102c, and 102d. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

[0024] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0025] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro) to establish air interface 116.

[0026] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish air interface 116.

[0027] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0028] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, transitional standard 2000 (IS-2000), transitional standard 95 (IS-95), transitional standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN), etc.

[0029] Figure 1A Base station 114b can be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and can use any suitable RAT to facilitate wireless connectivity in a local area, such as a commercial location, home, vehicle, campus, industrial facility, air corridor (e.g., used by a drone), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technology (such as IEEE 802.11) to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can use a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-APro, NR, etc.) to establish a picocell or femtocell. Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0030] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more WTRUs of WTRUs 102a, 102b, 102c, and 102d. Data may have varying Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1AAs shown, but will be understood, RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may be using NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0031] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). Internet 110 may include globally interconnected computer networks and apparatus systems using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

[0032] Some or all of the WTRUs 102a, 102b, 102c, and 102d in communication system 100 may include multi-mode capability (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks on different wireless links). For example, Figure 1A The WTRU102c shown can be configured to communicate with base station 114a, which can employ cellular-based radio technology, and with base station 114b, which can employ IEEE 802 radio technology.

[0033] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It will be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0034] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmitting / receiving element 122. Although... Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and transceiver 120 may, for example, be integrated together in an electronic package or chip.

[0035] Transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In embodiments, for example, transmitting / receiving element 122 may be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 may be configured to transmit and / or receive both RF and optical signals. It will be understood that transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0036] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmit / receive elements 122. More specifically, WTRU 102 may employ MIMO technology. Thus, in one embodiment, WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0037] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 may have multi-mode capability. Therefore, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate over various RATs (such as, for example, NR and IEEE 802.11).

[0038] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit), and can receive user input data from the speaker / microphone 124, keypad 126, and / or display / touchpad 128. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Additionally, the processor 118 can access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in said memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital storage (SD) card, etc. In other embodiments, processor 118 may access information from memory that is not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store the data in said memory.

[0039] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0040] Processor 118 may also be coupled to GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of WTRU 102. In addition to or alternative to information from GPS chipset 136, WTRU 102 may receive location information via air interface 116 from base stations (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0041] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (e.g., for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0042] WTRU 102 may include a full-duplex radio device for which the transmission and reception of some or all of the signals (e.g., associated with a specific subframe of both UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio device may include an interference management unit to reduce and / or substantially eliminate self-interference through hardware (e.g., a choke) or through signal processing (e.g., a separate processor (not shown) or through processor 118). In an embodiment, WTRU 102 may include a half-duplex radio device for which the transmission and reception of some or all of the signals (e.g., associated with a specific subframe of either UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0043] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0044] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. Each eNode-B 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, eNode-B 160a may, for example, use multiple antennas to transmit and receive radio signals from WTRU 102a.

[0045] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, one or more decisions, scheduling of users in the UL and / or DL, etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0046] Figure 1C CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. Although each of the preceding elements is depicted as part of CN 106, it will be understood that any one of these elements may be owned and / or operated by an entity other than a CN operator.

[0047] The MME 162 can be connected to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0048] The SGW 164 can be connected to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-eNode-B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0049] SGW 164 can be connected to PGW 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0050] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication devices. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), or can communicate with said IP gateway, which serves as an interface between CN 106 and PSTN 108. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0051] Although WTRU is Figure 1A-1D While described as a wireless terminal, it is envisioned that in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

[0052] In a representative embodiment, the other network 112 may be a WLAN.

[0053] In an Infrastructure Basic Services Set (BSS) mode, a WLAN may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access to a Distribution System (DS) or another type of wired / wireless network, or have an interface with a Distribution System (DS) or another type of wired / wireless network that carries services into and / or out of the BSS. Services originating outside the BSS destined for a STA can be delivered to the AP via the AP. Services originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. For example, services between STAs within the BSS can be sent via the AP, where the source STA can send services to the AP and the AP can deliver the services to the destination STA. Services between STAs within the BSS may be considered and / or referred to as peer-to-peer services. Using Direct Link Establishment (DLS), peer-to-peer services can be sent between source and destination STAs (e.g., directly between source and destination STAs). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using Standalone BSS (IBSS) mode may not have access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs within a STA) can communicate directly with each other. IBSS communication mode may sometimes be referred to herein as "ad-hoc" communication mode.

[0054] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be of fixed width (e.g., a 20 MHz bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, carrier-sense multiple access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, each STA (including the AP) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that particular STA can back off. In a given BSS, one STA (e.g., only one station) can transmit at any given time.

[0055] For example, a high-throughput (HT) STA can communicate using a 40 MHz wide channel by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0056] High-throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining adjacent 20 MHz channels. A 160 MHz channel can be formed by combining eight adjacent 20 MHz channels, or by combining two non-adjacent 80 MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be delivered via a segment resolver that divides the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. The streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0057] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. In 802.11af and 802.11ah, the channel operating bandwidth and carrier are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0058] WLAN systems that support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can still be 1 MHz wide even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Assignment Vector (NAV) settings can depend on the status of the primary channel. If, for example, the primary channel is busy due to a STA (that only supports the 1 MHz operating mode) transmitting to the AP, the entire available band can be considered busy even if most of the band remains idle and may be available.

[0059] In the United States, the available frequency bands for 802.11ah are from 902 MHz to 928 MHz. In South Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6 MHz to 26 MHz.

[0060] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0061] RAN 113 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may use beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0062] Using transmissions associated with scalable digital theory, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. Using various or scalable length subframes or transmission time intervals (TTIs) (e.g., including a varying number of OFDM symbols and / or an absolute time of continuously varying lengths), WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c.

[0063] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without also accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more gNBs from gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate with / connect to gNBs 180a, 180b, and 180c, and also communicate with / connect to another RAN, such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-B 160a, 160b, and 160c can be used as mobility anchors for WTRU 102a, 102b, and 102c, and gNB 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRU 102a, 102b, and 102c.

[0064] Each gNB in ​​gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, etc. Figure 1D As shown, gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0065] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0066] AMF 182a and 182b can be connected to one or more gNBs (gNBs) 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slices (e.g., handling different PDU sessions with different requirements), selecting specific SMFs 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slices can be used by AMF 182a and 182b to customize CN support for WTRU 102a, 102b, and 102c, for example, based on the type of service being used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and services for Machine Type Communication (MTC) access. AMF 162 can provide control plane functions for switching between RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-APro, and / or non-3GPP access technologies, such as WiFi.

[0067] SMF 183a and 183b can be connected to AMF 182a and 182b in CN 115 via the N11 interface. SMF 183a and 183b can also be connected to UPF 184a and 184b in CN 115 via the N4 interface. SMF 183a and 183b can select and control UPF 184a and 184b, and configure the routing of services through UPF 184a and 184b. SMF 183a and 183b can perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, or Ethernet-based.

[0068] UPF 184a and 184b can be connected via the N3 interface to one or more gNBs 180a, 180b, and 180c in RAN 113. This provides WTRU 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0069] CN 115 can facilitate communication with other networks. For example, CN 115 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), or may communicate with said IP gateway, which serves as an interface between CN 115 and PSTN 108. Additionally, CN 115 may provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to DNs 185a and 185b via UPFs 184a and 184b, through their N3 interfaces and the N6 interface between UPFs 184a and 184b and local data networks (DNs) 185a and 185b.

[0070] Considering Figure 1A-1D and Figure 1A-1D The corresponding descriptions herein regarding WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF183a-b, DN 185a-b, and / or any other device(s) described herein may be performed by one or more emulation elements / devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0071] The simulation device may be designed to perform one or more tests on other devices in a laboratory environment and / or in a carrier network environment. For example, while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network, the one or more simulation devices may perform one or more or all of the functions to test other devices within the communication network. While being temporarily implemented / deployed as part of a wired and / or wireless communication network, the one or more simulation devices may perform one or more or all of the functions. The simulation device may be directly coupled to another device for testing purposes, and / or may use over-the-air wireless communication to perform the tests.

[0072] While not implemented / deployed as part of a wired and / or wireless communication network, the one or more simulation devices may perform the one or more functions (including all functions). For example, the simulation devices may be used in test scenarios in test laboratories and / or non-deployed (e.g., test) wired and / or wireless communication networks to perform testing of one or more components. The one or more simulation devices may be test equipment. Wireless communication via direct RF coupling and / or through an RF circuit system (e.g., the RF circuit system may include one or more antennas) may be used by the simulation devices to transmit and / or receive data.

[0073] The following abbreviations and acronyms are used throughout this disclosure. 5GS 5G system 5QI 5G QoS identifier AF Application Functions AL Application layer AMF Access and mobility management functions API Application Programming Interface AS application server CSRC Contribution Source CN Core Network DL downlink DRB Data radio bearer DRX Discontinuous reception DSCP Differentiated service code points EDB Data burst ends FAR Forwarding Action Rules FEC Forward error correction GBR Guaranteed bit rate GTP-U General Tunneling Protocol User Plane ID identifier IP Internet Protocol MFBR Maximum stream bit rate NEF Network exposure function MASQUE Multiplexing application substrate on QUIC encryption MOQ Media on QUIC PCC Policy and billing control PCF Policy control function PDB Packet delay budget PDCP Packet Data Convergence Protocol PDF Group detection filter PDR Grouping detection rules PDU Protocol Data Unit PER Grouping error rate PSA UPF PDU Session Anchoring UPF PSDB PDU set delay budget PSER PDU set error rate PSI PDU set importance PSIHI PDU Integrated Disposal Instructions PSN PDU serial number PSSN PDU set serial number PSSize PDU set size QFSID QoS Flow ID QoS Service quality QUIC QUIC protocol (QUIC is the name, not an acronym) RAN Radio access network RLC Radio link control RTP Real-time Protocol SCI Flow-related information SDP Session Description Protocol SMF Session management function SN Serial Number SSRC Synchronization source ToS / TC Service type / business category TSCAI Time-Sensitive Communication Auxiliary Information UDP User Datagram Protocol UE User Equipment UPF User plane functionality UL uplink WTRU Wireless Transmitter / Receiver Unit XR Extended Reality XRM XR Media .

[0074] An apparatus (e.g., a network node) can generate a multiplexed data stream including a first set of Packet Data Units (PDUs), a second set of PDUs, and indications of sequence numbers for non-sequential PDU sets. The first set of PDUs may be associated with a first data stream. The second set of PDUs may be associated with a second data stream. The apparatus can determine a first mapping between a first subset of the non-sequential PDU set sequence numbers and a first set of sequence numbers of the sequential PDU sets associated with the first data stream. The apparatus can determine a second mapping between a second subset of the non-sequential PDU set sequence numbers and a second set of sequence numbers of the sequential PDU sets associated with the second data stream. The apparatus can transmit the multiplexed data stream, the indication of the first mapping, and the indication of the second mapping.

[0075] An apparatus (e.g., a network node) may receive a first multiplexed data stream, the first multiplexed data stream including a first set of Packet Data Units (PDUs), a second set of PDUs, and an indication of a sequence number for an out-of-order PDU set. The first set of PDUs may be associated with the first data stream. The second set of PDUs may be associated with a second data stream. The apparatus may determine a first mapping associated with the first data stream based on the sequence number of the out-of-order PDU set. The apparatus may determine a second mapping associated with the second data stream based on the sequence number of the out-of-order PDU set. The apparatus may transmit the second multiplexed data stream, the indication of the first mapping, and the indication of the second mapping.

[0076] The UPF can receive rules (e.g., N4 rules) from the SMF. Rules can include multiplexing and splitting information. The UPF can receive XR data from the application server. The UPF can identify flows within the received XR data. The UPF can map flows to QoS flows based on the received rules. The UPF can determine the PDU set metadata and flow metadata to include with the received XR data. The UPF can send the XR data and metadata to the RAN node.

[0077] Multiplexing and splitting information may include information related to restrictions on multiplexed or split flows (e.g., the number of flows, other QoS flows carrying split flows, etc.).

[0078] PDU set metadata may include information to help RAN nodes identify multiplexed flows, information about where to find the PDU set of split flows, offsets (e.g., SN_offset), etc.

[0079] RAN nodes can perform similar actions.

[0080] Figure 2 This illustration shows an example of Quality of Service (QoS) management (e.g., in a 5G system).

[0081] QoS management can be based on QoS flows (e.g., in 5GS). PDUs in a QoS flow (e.g., all PDUs) can receive the same processing in the RAN and in the UPF in the core network. A QoS flow can be the finest granularity of QoS differentiation within a PDU session. A QoS flow can have QoS specifications (e.g., requirements). For example, QoS specifications can include 5QIs (e.g., resource type, priority level, PDB, PER, average window, maximum data burst size, etc.), ARP, RQA, notification control, stream bit rate (e.g., MFBR, GBR), aggregate bit rate, maximum packet loss rate, etc.

[0082] QoS management can be implemented in, for example Figure 2 The 5G system (5GS) shown is enabled in the system.

[0083] exist Figure 2In section 1, the Application Function (AF) can supply QoS specifications (e.g., requirements) for service flows to the network (e.g., PCF). For example, the AF can supply QoS specifications to the network by using NEF service APIs (e.g., such as Nnef_AFsessionWithQoS_Create).

[0084] At point 2, QoS information can be used by the PCF to configure PCC rules. Based on the rules configured in the PCF, the SMF can configure QoS profiles for RAN nodes, PDRs for UPF, and QoS rules for WTRU.

[0085] At point 3, the PDU can reach the UPF via the N6 interface. At point 4, the UPF can use the configured PDR to map services to QoS flows. The UPF can create tunnels to the RAN node. The UPF can send arriving PDUs to the RAN node in GTP-U packets.

[0086] At point 5, the RAN node can use the configured QoS profile to determine how to manage GTP-U packets. This management may include how to schedule packets to WTRUs and whether packets should be dropped. If scheduled, packets may be delivered to WTRUs (e.g., on a configured Data Radio Bearer (DRB)).

[0087] Processing can be defined for XR media services (e.g., additional processing). For example, XR services can be transmitted as a set of PDUs. The QoS profile can have specifications (e.g., requirements) for the PDU set. The header of the GTP-U PDU can carry PDU set information.

[0088] In some examples, it can be assumed that a single XR stream is mapped to a QoS stream.

[0089] This document provides one or more features associated with PDU set disposal.

[0090] To support QoS processing based on PDU sets, the PSA UPF can identify PDUs belonging to a PDU set. The UPF can determine the PDU set information. The UPF can send the PDU set information to the NG-RAN in the GTP-U header. The PDU set information can then be used by the NG-RAN for QoS processing based on the PDU set.

[0091] PDU set information may include: PDU set sequence number; indication of the end / last PDU in the PDU set; PDU sequence numbers within the PDU set; PDU set size (e.g., in bytes); PDU set importance (e.g., identifying the relative importance of the PDU set compared to other PDU sets within the QoS flow); etc.

[0092] To determine PDU set information, PSA UPF may rely on information carried in the received packets and / or on the implementation. For example, if XRM service is carried over RTP, the RTP header may include one or more of the following.

[0093] The RTP header may include an indication of the end / last PDU of the PDU set (e.g., a 1-bit indication). This field may be a flag that is set to 1 for the last PDU in the PDU set and to 0 for all other PDUs in the set.

[0094] The RTP header may include an indication of the end of a data burst (e.g., a 3-bit indication referred to as the EDB field). The EDB field may be 3 bits in length. The EDB field indicates the end of a data burst. The 3 bits may encode the data burst end indication (e.g., following encoding guidelines).

[0095] The RTP header may include an indication of the importance of a PDU set (e.g., a 4-bit indication known as the PSI field). The PDU set importance field indicates the importance of the PDU set compared to other PDU sets within the same QoS flow. Lower values ​​indicate higher-importance PDU sets. For example, the most important PDU set may be indicated by 0, and the least important PDU set may be indicated by 15.

[0096] The RTP header may include an indication of the PDU set sequence number (e.g., a 10-bit indication known as the PSSN field). The PSSN field encodes the sequence number of the PDU set to which the current PDU belongs. For example, the PSSN field can be used as a 10-bit numeric identifier for the PDU set.

[0097] The RTP header may include an indication of the PDU sequence number within the PDU set (e.g., a 6-bit indication known as the PSN field). The PSN field indicates the sequence number of the current PDU within the PDU set. The PSN field may be set to 0 for the first PDU in the PDU set and incremented by one for each PDU in the PDU set in the order of transmission from the sender (e.g., monotonically).

[0098] The RTP header may include an indication of the PDU set size (e.g., a 24-bit indication referred to as the PSSize field). The PDU set size indicates the total size of all PDUs in the PDU set to which this PDU belongs. The PSSize field may be optional and / or subject to SDP signaling offer / response negotiation (e.g., where the application server can indicate whether it will be able to offer the size of the PDU set for this RTP stream). If not enabled, the PSSize field may not exist. If enabled, but the application server cannot determine the PDU set size for a particular PDU set, the PSSize field may indicate a value of 0 (e.g., among all PDUs in that PDU set). The PSSize field indicates the size of the PDU set, including the RTP / UDP / IP header encapsulation overhead for its corresponding PDUs. PSSize may be represented in bytes.

[0099] The network can be configured with PDU set QoS specifications (e.g., requirements) or information (e.g., PDU set information in addition to that carried in the GTP-U header). Information can be defined per QoS flow. The PDU set QoS specification can be the same for all PDU sets carried in a QoS flow (e.g., all PDU sets). The following PDU set QoS specifications can be defined for XRM service flows.

[0100] The PDU set delay budget (PSDB) defines an upper bound on the delay that the PDU set may experience for transmission between the N6 endpoint at the WTRU and UPF (e.g., the duration between the reception time of the first PDU (at the N6 endpoint for DL ​​or at the WTRU for UL) and the time when all PDUs in the PDU set have been successfully received (at the WTRU for DL ​​or at the N6 endpoint for UL).

[0101] The PDU set error rate (PSER) defines an upper bound on the rate at which a set of PDUs has been processed by the sender of a link-layer protocol (e.g., RLC in a 3GPP-accessed RAN) but has not been successfully delivered by the corresponding receiver to an upper layer (e.g., PDCP in a 3GPP-accessed RAN).

[0102] PDU Set Integration Disposal Information (PSIHI) can indicate whether the PDUs in the PDU set (e.g., all PDUs) will be used by the application layer on the receiving side (e.g., whether the use of the PDU set is required).

[0103] One or more PDU set QoS specifications (e.g., additional requirements) may be considered. The PDU set FEC success rate can be the percentage of PDUs that the WTRU needs to deliver (e.g., needs to be successfully delivered) to the WTRU, allowing the WTRU to recover the entire PDU set.

[0104] One or more PDU set service characteristics may be provided to NG-RAN by the core network. NG-RAN may configure WTRU power saving management schemes for connected mode DRX. One or more PDU set service characteristics may include: UL and / or DL ​​periodicity; N6 jitter information associated with DL periodicity; indication of the end of a data burst; etc.

[0105] Periodicity of UL and / or DL ​​and / or N6 jitter associated with DL periodicity can be provided to NG-RAN by the core network (e.g., via TSCAI). The core network can receive this information from the AF. The core network can derive this information at the UPF. The information can be transmitted to NG-RAN via the SMF and AMF.

[0106] This paper provides one or more features associated with multiplexed streams. Figure 3 The diagram illustrates an example of a multiplexed flow.

[0107] XR media services can include various types of streams (e.g., video streams, audio streams, haptic feedback, other metadata, or sensor data for a more immersive experience). To enable these immersive services, different media types can be multiplexed into (e.g., a single) data stream (e.g., before reaching the 5GS ingress). Each stream (e.g., each stream) can have its own set of PDUs. In this case, a QoS stream can carry the multiplexed stream, such as... Figure 3 As shown in the image.

[0108] Figure 4 The diagram illustrates an example of creating a multiplexed stream. XR stream multiplexing can occur at the application layer (e.g., RTP, for example, ...). Figure 4 (as shown in d)); occurs at the transport layer (e.g., QUIC, e.g., as shown in d). Figure 4 (as shown in c)); occurs based on the PCC rules provided to the UPF (e.g., as shown in c). Figure 4 (as shown in a) and b) in the figure); etc.

[0109] A framework (e.g., a QoS framework identified by 3GPP) may not support differentiated QoS for multiplexed traffic flows (e.g., if flows share the same IP 5-tuple). A framework (e.g., an enhanced framework) may support differentiated QoS for multiplexed traffic flows. A framework may involve the apparatus performing one or more of the following actions: The apparatus may identify (e.g., a single) multiplexed traffic flows within a transport connection that have different QoS specifications (e.g., requirements). The apparatus may perform QoS flow mapping for traffic flows with different QoS specifications (e.g., requirements). The AF may provide information to assist the apparatus in performing traffic detection (e.g., the apparatus may determine whether and what information to request from the AF for traffic detection). The AF may provide information to the system (which may be a 5GS) related to the QoS specifications (e.g., requirements) of different traffic flows (e.g., the apparatus may determine whether and how the AF provides the system with the QoS specifications of different traffic flows).

[0110] One or more multiplexing options can be used to map SDFs to QoS flows. For example, a first multiplexing option may involve mapping an SDF flow to each QoS flow. A second multiplexing option may involve mapping M SDF flows to each QoS flow (e.g., where all M flows may have the same QoS parameters and PDU set QoS parameters, as well as similar PDU set service characteristics). A third multiplexing option may involve mapping M SDF flows to each QoS flow (e.g., where all M flows may have the same QoS parameters and PDU set QoS parameters, as well as different PDU set service characteristics). Another multiplexing option may involve mapping M SDF flows to each QoS flow (e.g., where all M flows have the same QoS parameters and different PDU set QoS parameters and different PDU set service characteristics, or have some of the same PDU set QoS parameters and some of different PDU set QoS parameters). A fifth multiplexing option may involve mapping a portion of N SDF flows to QoS flows. In this case, the N flows may have the same QoS parameters and one or more PDU set QoS parameters (e.g., the same PSI). The N flows may have the same or different PDU set characteristics.

[0111] Figure 5 The illustration shows an example of traffic multiplexing on a QoS flow (e.g., based on a fourth or fifth multiplexing option). As illustrated, QoS flow 1 can multiplex traffic from multiple (e.g., four) traffic flows (e.g., flow 1, flow 2, flow 3, and flow 4). QoS flow 2 can carry traffic from a flow (e.g., flow 3). Traffic from flow 3 can be split across QoS flow 1 and QoS flow 2.

[0112] Figure 6 The illustration is in Figure 5 An example of PDU set information carried in a QoS stream. About Figure 5 and Figure 6 One or more of the following may apply.

[0113] In the example, the set of PDUs arriving at the NG-RAN (or RAN node) may come from different flows. The PDU set information carried in these PDUs may be unrelated. The NG-RAN (or RAN node) can track different PDU sets from individual flows.

[0114] A given QoS flow can consist of PDUs from multiple flows, and the traffic on a QoS flow may be a mixture of traffic from potentially different flows. If the RAN node obtains PDU set information from the PDUs present in the QoS flow, the RAN node can know (e.g., needs to know) which PDU set information applies to which PDU sets.

[0115] In the example, the mapping from flow to QoS flow can result in the flow being split across one or more QoS flows. NG-RAN (or RAN node) can handle PDUs arriving at NG-RAN (or RAN node) with missing PDU sets.

[0116] If a flow / SDF is split across two QoS flows, some PDU sets of that flow can pass through QoS flow 1, and some can pass through QoS flow 2. The RAN node can handle the gaps in the PDU set SN of the flow. At the RAN node, the QoS flow can be mapped to the DRB. If an SDF is split across two or more QoS flows, the QoS flows can be mapped to the same DRB.

[0117] As used herein, the terms flow, data flow, or subflow may be used interchangeably. A data flow may represent a service originating from an application source (e.g., an application server or WTRU). For example, a data flow may be a video data flow, an audio data flow, or a haptic data flow. Data flows may be temporally related. For example, an audio data flow may be time-synchronized with a video data flow (e.g., if necessary).

[0118] As used herein, the term "stream" can refer to a service substream (e.g., a media service substream) that is multiplexed within a service stream (e.g., multiplexed within an application connection). "Stream" and "XR stream" may be used interchangeably.

[0119] The streams described in this article may be (for example, assumed to be) XR streams. This is for illustrative purposes only. It should be understood that streams can have any type.

[0120] As used herein, the term "end-to-end connection" can be used to refer to a connection between a WTRU and an application server (e.g., one used to transfer one or more data streams). For example, an end-to-end connection could be an RTP session. In the example, an end-to-end connection could be a QUIC connection (e.g., where multiple streams are multiplexed). The different streams could be audio and video, or different video layers (e.g., each on its own stream).

[0121] As used herein, a PDU set may refer to one or more PDUs (e.g., one or more frames, one or more video slices, etc.) that carry a payload of an information unit (e.g., a single unit) generated at the application level for an Extended Reality (XR) service. A PDU set may have one or more PDUs. The PDUs in a PDU set may carry PDU set information.

[0122] As used herein, the term "PDU set information" may refer to the information carried by the PDUs accompanying a PDU set. PDU set information helps characterize the PDU set. Exemplary PDU set information may include PDU set size, PDU set sequence number, end PDU indication, etc.

[0123] As used herein, the term "PDU set QoS specification" (e.g., PDU set QoS requirement) may refer to a QoS specification that processes the attributes of a PDU set. For example, a PDU set QoS specification may be PDSB, PSER, PSIHI, etc.

[0124] As used herein, multimodal data can refer to data from different types of devices / sensors or data output to different types of destinations (e.g., one or more WTRUs) for the same task or application. Multimodal data can include more than one unimodal data. There may be strong dependencies between (e.g., each) unimodal data. Unimodal data can refer to (e.g., one) type of data.

[0125] The features(one or more) described herein may relate to flows (e.g., where each flow has different PDU set QoS characteristics and / or PDU set service characteristics and / or PDU set QoS parameters). Flows (e.g., each flow) may (e.g., may require) be identified by UPF and WTRU (e.g., individually). The procedures described herein may be applied to a group of flows having similar PDU set QoS characteristics and / or PDU set service characteristics and / or PDU set QoS parameters (e.g., and being treated as a flow group). In this case, the described features(one or more) may apply to the flow group (e.g., rather than individual flows).

[0126] As used herein, the terms "flow-based QoS" or "(one or more) flow-based QoS parameters" can refer to (one or more) QoS parameters that apply to the entire flow. For example, (one or more) flow-based QoS parameters may include PDU set delay budget, PDU set error rate, AL FEC success rate, etc.

[0127] As used herein, the terms "QoS based on PDU set" or "(one or more) QoS parameters based on PDU set" may refer to (one or more) QoS parameters applicable to a PDU set. For example, QoS parameters based on PDU set may include PDU set delay budget, PDU set error rate, etc.

[0128] As used herein, the terms "QoS based on QoS flow" or "(one or more) QoS parameters based on QoS flow" can refer to (one or more) QoS parameters applicable to a QoS flow. For example, (one or more) QoS parameters based on QoS flow may include packet error rate, packet delay budget, etc.

[0129] As used herein, the term "AL FEC success rate" may refer to the ratio of PDUs in a PDU set that allow the receiver to decode (e.g., the entire) PDU set and (e.g., require) be correctly received.

[0130] The features described in this article (one or more) can be used to manage reusable PDU sets and split PDU sets.

[0131] The network may (e.g., be configured to) multiplex sets of PDUs from different flows over QoS flows. The network may (e.g., be configured to) split a set of PDUs from a single flow across two or more QoS flows.

[0132] UPF can identify the PDU set to be multiplexed and / or the PDU set to be split. UPF can include (e.g., new) flow metadata in the GTP-U packet header sent to the RAN. UPF can renumber the PDU set SN to compensate for multiplexing and splitting.

[0133] RAN nodes can identify sets of PDUs belonging to flows that are multiplexed or split across two or more QoS flows. RAN nodes can be configured with prioritization rules to process PDU sets arriving from different QoS flows.

[0134] The features described in this paper (one or more) can provide the network with the flexibility to reuse and / or split the set of PDUs from the multiplexed stream.

[0135] Figure 7A and Figure 7B The illustration shows a DLXR stream that is multiplexed or split across two or more QoS streams (e.g., a single QoS stream).

[0136] exist Figure 7A In this context, at point 1, the AF can provide system flow information (e.g., 5G system flow information) related to multiplexing or splitting a flow onto a QoS flow, as described herein.

[0137] At point 2, the PCF can generate PCC rules. The PCF can provide the rules to the SMF. The SMF can determine one or more QoS profiles. The SMF can send one or more QoS profiles to the RAN node. The SMF can determine QoS rules. The SMF can send the QoS rules to the WTRU. The SMF can determine N4 rules. The SMF can send the N4 rules to the UPF. The N4 rules may include PDR and FAR. The N4 rules may include multiplexing information related to how to multiplex a flow on a QoS flow, and / or splitting information related to how to split a flow on one or more QoS flows. The QoS profile may include multiplexing information related to how a flow is multiplexed on a QoS flow, and / or splitting information related to how a flow is split on two or more QoS flows. The QoS profile may include instructions on how to handle out-of-order delivery of PDU sets and / or instructions on how to map split flows to DRBs.

[0138] Flow multiplexing can occur before the traffic flow to QoS flow mapping operation. For example, if multiplexing information indicates that flow ID1 is to be (e.g., needs to) multiplexed with flow ID3 (e.g., if flow ID1 and flow ID3 are determined to be multiplexed onto the same QoS flow), then the QoS parameters and configuration of the QoS flows can (e.g., may need to) satisfy the relevant specifications for flow ID1 and flow ID3 (e.g., both). For example, if flow ID1 and flow ID3 are indicated to be multiplexed, the AF may have provided one or more QoS-related parameters (e.g., the PDB specification (PDB 1) associated with flow ID1 and the PDB specification (PDB 3) associated with flow ID3, which may have similar values). The PCF may have determined that the PDB requirements associated with the QoS flows that can carry both flows are PDB values ​​similar to PDB 1 or PDB 3, or a function of both values. The system (which may be a 5GS (e.g., including the AF and PCF)) may be able to provide consistent multiplexing information and QoS specifications. If the network cannot provide such information, the PCF may reject the AF request (e.g., because there are no QoS parameters that satisfy both flows). The PCF can determine QoS flow parameters (e.g., based on local configuration) that may or may not meet (e.g., all) the specifications of the service flow and the flow. The PCF or other NFs can perform one or more actions to allow the parsing of QoS parameters and multiplexing specifications / indications / information associated with different flows of the service flow.

[0139] At point 3, PDUs from the XR stream can reach the UPF.

[0140] At point 4, the UPF can identify the XR flow of arriving PDUs based on the configured PDR. The UPF can map PDUs to QoS flows. The UPF can prepare GTP-U packets to carry PDUs to RAN nodes. The UPF can determine the GTP-U header information. This information may include PDU set metadata and / or flow metadata. The UPF can determine the PDU set SN to be included in the GTP-U header information (e.g., to ensure the order of the PDU set SN).

[0141] exist Figure 7B In this context, at point 5, a GTP-U PDU can be sent to the RAN node. The traffic of a flow can be split across two or more QoS flows.

[0142] At point 6, the RAN node can identify flows within a QoS flow. The RAN node can map flows to DRBs (e.g., based on the configuration received at point 2). The RAN node can make scheduling decisions based on the set of PDUs received on the split flow.

[0143] At point 7, the RAN node can send the PDU to the WTRU via one or more data radio bearers.

[0144] The identification, mapping, and processing shown in the UPF (at location 4) are applicable to DL services. The same identification, mapping, and processing are applicable to UL services at the WTRU.

[0145] The device and / or network can manage the non-sequential PDU set SN on QoS flows. The non-sequential PDU set SN on QoS flows can occur in one or more (e.g., two) scenarios.

[0146] In the first scenario, the UPF can receive a first multiplexed service flow from the application server. In this case, the PDU set from (e.g., each) flow can be multiplexed. The sequence numbers of the PDU sets on the received multiplexed service flow can be non-ordered. The UPF can (e.g., based on the first multiplexed service flow) generate a second multiplexed service flow. The UPF can send the second multiplexed service flow to the RAN node. For example, the UPF can encapsulate the PDU set of the first multiplexed service flow into a GTP-U PDU and send the GTP-U PDU through the second multiplexed flow.

[0147] In the second scenario, the UPF can receive multiple service flows (e.g., from one or more application servers). The N4 rule can instruct the UPF to multiplex the service flows onto a third multiplexed flow. The N4 rule can also instruct the UPF to send the third multiplexed service flow to the RAN node. The UPF can encapsulate a set of PDUs from multiple service flows into a GTP-U PDU and send the GTP-UPDU via the third multiplexed flow.

[0148] The network can handle (e.g., process) (e.g., a single) set of non-sequential PDUs (SN) on a QoS flow. RAN nodes can handle (e.g., process) a set of non-sequential PDUs (SN) carrying multiplexed flows. RAN nodes can apply flow-based QoS to QoS flows.

[0149] A RAN node can receive a set of PDUs with an out-of-order PDU set SN on a QoS flow (e.g., due to flow multiplexing and splitting at the UPF). A RAN node can receive PDU sets from two or more (e.g., three) multiplexed flows (e.g., flow 1, flow 2, flow 3). The PDU sets from these (e.g., each of these) flows may have an ordered PDU set SN. Multiplexed flows may have out-of-order PDU set SNs. The RAN node can receive information (e.g., additional information may be required) to help resolve the out-of-order PDU set SNs. The UPF can provide this information to the RAN node. The UPF can perform mapping of the out-of-order PDU set SNs.

[0150] In the first example (e.g., the first option for managing non-sequential PDU set SNs), the mapping may involve one or more of the following: The UPF may identify individual flows (e.g., based on flow ID information carried in the RTP header). The UPF may include a flow ID (e.g., a QoS flow ID (QFSID)) in each PDU multiplexed in a QoS flow. In some examples, the UPF may identify individual flows (e.g., based on information carried in the RTP header). The UPF may generate a QFSID to be included (e.g., in each PDU multiplexed in a QoS flow). The QFSID may be provided as part of an N4 rule. In this case (e.g., the first option), the UPF may set the PDU set SN to be equal to the PSSN carried in the RTP header. The UPF may include the PDU set SN and / or QFSID in the GTP-U packet header. The RAN node can use the QFSID to identify which PDU sets originate from the same flow. The PDU set SN may be sequential for each identified flow. RAN nodes can use QFSID to identify the set of PDUs to be applied to (e.g., any) flow-based QoS.

[0151] In the second example (e.g., the second option), the mapping may involve one or more of the following: The UPF may renumber the PDU set SN to compensate for the multiplexing and / or splitting of flow traffic. For example, the UPF may not use the PSSN as the PDU set SN. For example, the UPF may determine (e.g., ensure) that the PDU set SNs are ordered on each flow. The UPF may increment the PDU set SN of each PDU set multiplexed on a QoS flow. For example, the UPF may increment the PDU set SN by 1 for each PDU set sent to the RAN node. In this case, the RAN node may expect (e.g., the ordered PDU set SN for each) QoS flow. In this case, the RAN node may not be able to determine the flow to which the PDU set arriving on the QoS flow belongs. The RAN node may not be able to provide flow-level QoS (e.g., any flow-level QoS). The UPF may include flow-level QoS parameters with (e.g., each) PDU set. For example, the UPF may include a PSDB applied to the flow, a PSER applied to the flow, an FEC success rate applied to the flow, etc. The RAN node may not know the original PSSN of the PDU set. The UPF may include an offset (e.g., SN_offset) with (e.g., each) PDU set. The SN_offset may be used by the RAN node to recover the (e.g., original) PSSN associated with the PDU set. For example, a multiplexed flow may have a set of PDU sets (e.g., PDU set SN1 for flow 1, PDU set SN1 for flow 2, PDU set SN2 for flow 2, PDU set SN3 for flow 2, PDU set SN1 for flow 1, and / or PDU set SN1 for flow 3).

[0152] A PDU set SN can be mapped to a set of sequential PDU set sequence numbers (e.g., sequential PDU set SN 100 to sequential PDU set SN 105). Each PDU set can be associated with an SN offset (e.g., having an SN offset). The SN offset can be determined by subtracting the sequential PDU set SN (e.g., the one associated with the PDU set) from the PDU set SN. For example, the SN offsets of sequential PDU sets SN 100 to SN 105 of a multiplexed stream could be 99, 100, 100, 100, 102, and 104, respectively. If the SN is a modulo-maximum SN (e.g., max_SN), the subtraction can be considered a (modulo max_SN) subtraction.

[0153] This document provides one or more characteristics associated with AF supply.

[0154] AF can (for example, by providing information) assist network management in multiplexing or splitting XR streams.

[0155] The AF can provide parameters related to how the UPF maps flows to one or more QoS flows. These parameters enable / permit AF control over how flows are transmitted through the core network and radio access network. For example, the AF can prefer that the network deliver PDU sets in order (e.g., guarantee the in-order delivery of PDU sets), provide similar QoS treatment for PDU sets within a flow (e.g., all PDU sets), or split traffic (e.g., if deemed necessary or beneficial to meet QoS specifications).

[0156] The AF can configure XR flow-related information to the network (which may be a 5G network) (e.g., using APIs enhanced for multiplexing and / or splitting flows). For example, the NEF service API (e.g., "Nnef_AFsessionWithQoS_Create") can be enhanced to include: flow information (e.g., QoS specifications / requirements for the PDU set per flow); indications as to whether the network should provide similar processing for all PDU sets of the flow (e.g., which the AF can use to tell the network that it should attempt to map all PDU sets of the flow to the same QoS flow and / or DRB); indications as to whether the network should guarantee the in-order delivery of PDU sets within the flow (e.g., which the AF can use to tell the network that it expects PDU sets to arrive at the WTRU in order); and indications as to whether the flow can be split (e.g., which the AF can use to tell the network that it can split flow PDUs and PDU sets as it deems necessary, as long as QoS is maintained; the network can split PDU sets on different QoS flows and / or different DRBs; if...). If the flow can be split, the AF can provide additional reasons for the split, such as the importance of the PDU set based on the PDU set, loss requirements, latency requirements, etc.; an indication of whether the flow can be multiplexed with other flows on a QoS flow; an indication of whether the flow can be mapped to a unique QoS flow; a list of flows that can be multiplexed (e.g., an indication to the network that the current flow can be multiplexed with any flow on the same QoS flow, such as a list of flow identifiers or flow characteristics that identify individual flows (e.g., multiplexing only video I-frames); a list of flows that cannot be multiplexed (e.g., an indication to the network that the current flow cannot be multiplexed with any flow on the same QoS flow, such as a list of flow identifiers or flow characteristics that identify individual flows (e.g., do not multiplex video I-frames and video P / B frames together); combinations thereof; etc.

[0157] The NEF service API may include multiplexing criteria. Multiplexing criteria can provide one or more conditions that allow certain flows to be multiplexed (e.g., without flow ID). For example, multiplexing criteria can be based on the type of PDU set QoS parameters provided for (e.g., one) flow. For example, a criterion may indicate that flows provided with PSIHL as a PDU set QoS parameter are multiplexed in the same QoS flow, and / or flows provided with PSDB as a PDU set QoS parameter are multiplexed together. Different flows may have (e.g., a single) type of PDU set QoS parameters (e.g., not necessarily one or more PDU set QoS parameters). Flows can be multiplexed in this way to facilitate PDU set-based QoS handling at the RAN. Multiplexing criteria can be based on whether a flow carries FEC data or a repair PDU or a source PDU. Multiplexing criteria may indicate that a flow carrying FEC or repair PDUs is multiplexed onto (e.g., a single) QoS flow, and a flow carrying source PDUs is multiplexed onto another QoS flow.

[0158] The NEF service API may include Flow-Related Information (SCI). SCI provides correlations between different flows or between a flow and a QoS flow. SCI identifies the associated flows. SCI provides information indicating how associated flows exchange when they exist. SCI may, for example, indicate flow affinity: if (e.g., both) flows exist / when (e.g., both) flows exist, flows S1 and S2 may (e.g., must) be multiplexed on QoS flow Q1. SCI may, for example, indicate flow anti-affinity: if both exist, flows S1 and S2 may (e.g., must) be on QoS flows Q1 and Q2 respectively (e.g., considering that when (e.g., only) one flow exists, either S1 or S2 may be on Q1). SCI may, for example, indicate flow attraction: (one or more) flows should (e.g., preferably) be pulled toward a certain QoS flow (e.g., if possible).

[0159] This article provides examples of UPF processing. UPF can be configured to multiplex or split streams. UPF can be configured to manage multiplexed or split streams.

[0160] The PCF can determine PCC rules based on the flow information supplied by the AF. The PCF can provide these rules to the SMF. The SMF can determine N4 rules based on the PCC rules. The PCF can provide the N4 rules to the UPF. The N4 rules may include PDF and / or QoS flow mapping rules.

[0161] The N4 rule may include the following information for the UPF. The N4 rule may include an indication of whether a stream (e.g., a stream recognized by the PDF) can be multiplexed with other streams. If a stream can be multiplexed, the N4 rule may include information for limiting multiplexing. Limitations may be based on: the maximum number of streams that can be multiplexed with a stream recognized by the PDF, the stream's attributes or characteristics, and / or the stream identifier. For example, a limit may indicate that streams carrying video I-frames should be multiplexed (e.g., only multiplexed).

[0162] The N4 rule may include an indication of whether a stream (e.g., a stream identified by a PDF) can be split. Splitting can be done by PDU or by PDU set. If the stream can be split, the N4 rule may include how the split can be implemented. For example, splitting may be based on PDU set importance (e.g., where the UPF can split the stream such that a high-importance PDU set is transmitted on one QoS stream and a lower-importance PDU set is transmitted on another QoS stream). In the example, splitting may be based on PDU set size (e.g., where the UPF can split the stream such that a large PDU set is transmitted on one QoS stream and a smaller PDU set is transmitted on another QoS stream).

[0163] The N4 rule may include an indication of whether the UPF should recognize the start of a new stream's transmission. For example, the start of a transmission could be the first PDU. The N4 rule may also include an indication of whether the UPF should recognize the last transmission of a stream (e.g., the last PDU).

[0164] The N4 rule may include an indication of whether certain PDUs or sets of PDUs will (e.g., need to) be repeated on different QoS flows if a flow is split. For example, the N4 rule may indicate that PDUs and / or sets of PDUs with a data burst end indication for that flow will (e.g., need to) be repeated (e.g., sent on two QoS flows). This indication can increase the likelihood that the PDUs will be successfully received by the RAN (e.g., on the fastest possible path).

[0165] If a flow can be split (e.g., indicated as being able to be split), the PCF may have already identified it in the PCC rules of the traffic flow associated with that flow, and / or an indication regarding the split ratio (e.g., if available). In this case, the PCF can use the split ratio to determine whether a portion of the GBR (e.g., that should be provided for the traffic) can be allocated / added to another QoS flow. For example, if it is estimated that 10% of the total traffic will be sent on a second QoS flow (QoS flow ID 2), and if 100Mbps is used (e.g., needed for) the initial traffic satisfied by a QoS flow, then the GBR can be split into a 90Mbps GBR allocation for QoS flow ID 1 and a 10Mbps GBR allocation for QoS flow ID 2. The GBR allocation associated with a specific traffic flow can be used to determine the GBR that QoS flow ID 1 and QoS flow ID 2 will (e.g., need) provide (e.g., QFI1 needs to provide an initial 30Mbps for another traffic flow and 90Mbps for that traffic flow, and QFI2 needs to guarantee 10Mbps for another traffic flow and additionally guarantee 10Mbps for a portion of that traffic flow).

[0166] In the case of video services (e.g., where I-frames and P-frames are carried within the video stream), a service split ratio can be used. If the video stream splitting is based on PDU set importance values, I-frames can be sent through a first QoS stream, and P-frames can be sent through a second QoS stream. Application functions can (e.g., depending on application type and other conditions) know the average proportion of I-frames from the video service and / or the proportion of P-frames from the video service (e.g., using a service mode). Systems (such as 5GS) can split the (e.g., required) GBR of the video stream into GBR allocations added to different QoS streams.

[0167] UPF can perform one or more actions associated with the PDUs of the identified and mapped streams (e.g., for the PDUs of the identified and mapped streams).

[0168] Actions at the UPF can be performed after the UPF has done the following: identified the PDUs of a flow; mapped these PDUs to QoS flows; and prepared to send the PDUs to the RAN node via a GTP-U tunnel. Multiple flows can be multiplexed on QoS flows. (For example, the PDUs (or sets of PDUs) of a single flow can be split across QoS flows. The UPF can create GTP-U packets to carry the identified PDUs. The UPF can be configured with Forwarding Action Rules (FARs) (e.g., which tell the UPF how to forward GTP-U packets to the RAN node and / or what to include in the header of these GTP-U packets).

[0169] In the first UPF action, the UPF can add PDU set metadata and / or flow metadata to the GTP-U header. The metadata can be used to assist RAN nodes (e.g., for scheduling, packet dropping, setting CDRX parameters, associating PDU sets with flows, applying flow-based QoS, etc.).

[0170] The first stream metadata can be the QoS stream ID (QFSID).

[0171] Two (or more) applications (e.g., App1 and App2) can carry XRM services in the same PDU session (e.g., because they have the same ASP and / or S-NSSAI / DNN values).

[0172] Applications (e.g., two applications) may have a common flow ID value. Flow 1, which belongs to a business flow from App 1, has a flow ID A, and a second flow 2, which belongs to a business flow from App 2, has the same flow ID A (e.g., the flows do not have to represent the same type of business; it is possible that the flow IDs assigned or assigned by the two apps just happen to result in a common flow ID value).

[0173] The 5GS (e.g., UPF) can determine to renumber the flow IDs to resolvable values ​​(e.g., because if a PDU from App1 and a PDU from App2 have the same flow ID A and are carried on the same QoS flow 1, the RAN might not be able to distinguish them). The SMF can determine the renumbering rules and provide them to the UPF (e.g., using the original flow ID and AppID to generate the flow IDs). The SMF can provide the renumbering rules to the WTRU (e.g., for UL services). If the UPF determines the flow ID mapping, the UPF can inform the SMF of the updated flow ID renumbering, and the SMF can send the updated mapping to the WTRU.

[0174] Secondary stream metadata can be an indication that the PDU is the last PDU in the stream. For example, metadata can be used by RAN nodes to determine that the next set of PDUs to be received comes from a different stream.

[0175] Third-stream metadata can be an indication that a PDU is the first PDU in a stream. For example, metadata can be used by a RAN node to determine that the set of PDUs being received comes from a different stream than the last set of PDUs received.

[0176] The fourth stream metadata can be associated with the PDUs of a stream split across a QoS stream. This can include one or more of the following: an indication that one or more of the stream's previous (e.g., earlier) PDU sets were sent on another QoS stream; the number of PDU sets transmitted via the other QoS stream; an indication that the stream's next (e.g., next) PDU set will be sent on another QoS stream; the number of PDU sets to be transmitted via the other QoS stream; a list of one or more PDU set SNs sent on the other QoS stream; a list of one or more (PDU set SN, QFSID) pairs (e.g., identifying the PDU set SN of the stream (QFSID) sent on the other QoS stream, which allows the UPF to send information about stream j' via the PDUs of stream 'k'); the QoS stream ID of the stream split (e.g., the UPF can use metadata to indicate that some PDU sets of stream j' can be transmitted via QoS stream 'm'); etc.

[0177] The fifth stream metadata can be SN_Offset. This can be used in option 2 to manage the non-sequential PDU set SN. The RAN node can add the SN_offset to the received PDU set SN to restore the original PSSN of the PDU set.

[0178] The sixth-flow metadata can be associated with flow-based QoS. For example, metadata may include the PSER to be applied to this PDU set, the PSDB to be applied to this PDU set, the PSIHI to be applied to this PDU set, the AL FEC success rate to be applied to this PDU set, etc. The sixth-flow metadata can be sent as a value or as an index to a value table. The value table can be provided to the RAN node a priori, for example, in a QoS profile. The index can point to a specific value in the value table.

[0179] UPF can renumber PDU set SNs to compensate for the multiplexing and / or splitting of streaming services, as described in this article.

[0180] RAN nodes can perform processing. RAN nodes can be configured to manage flows multiplexed on QoS flows and / or flows split on one or more QoS flows. RAN nodes can be configured to manage multiplexed flows or split flows.

[0181] RAN nodes can receive flow-based configuration information from the network. For example, the PCF can determine PCC rules based on flow information supplied by the AF (e.g., and provide these to the SMF). The SMF can determine QoS profile rules based on the PCC rules. The SMF can provide the QoS profile to the RAN nodes.

[0182] Configuration information may include one or more of the following for each QoS flow: an indication of whether the QoS flow carries split flow traffic; an indication of whether the QoS flow carries unsplit flow traffic; an indication of whether the split PDU set will (e.g., needs) be considered in PDU set monitoring at the RAN node (e.g., if the flow is split into 2 QoS flows based on PSI, the network may not want the RAN node to include the PDU set carried on the lower priority QoS flow when calculating PSER); etc.

[0183] Configuration information may include one or more of the following for each flow: a flow identifier (QFSID); an indication of whether the traffic of the flow can be split on a QoS flow (e.g., telling the RAN node whether gaps in the PDU set SN are expected); an indication of whether the flow can be split; etc. For example, configuration information may include the QFI of the QoS flow carrying the split flow. The network may also indicate to the RAN node that traffic transmitted through another QoS flow has a lower (or higher) priority (e.g., PSI) than traffic transmitted in the current QoS flow. The network may also indicate to the RAN node that traffic transmitted through another QoS flow has a larger (or smaller) PDU set size than traffic transmitted through the current QoS flow.

[0184] Configuration information may include timers that allow processing of split-flow traffic arriving via different QoS flows. For example, if a flow is split across QoS flows QFI1 and QFI2 (each with different CN-PDB values: CN-PDB1 and CN-PDB2), the PDUs of the PDU set split across (e.g., both) QoS flows may inherently arrive at the RAN node with a delay relative to that offset (e.g., CN-PDB1 - CN-PDB2). In this case, the RAN may be configured with timers that take that offset into account.

[0185] Configuration information may include instructions on how to map split-flow traffic to DRBs. For example, the network may request that split-flow traffic (e.g., received over different QoS flows) be mapped to the same DRB or different DRBs. The network may leave the decision to the RAN node. Configuration information may also include instructions on whether to send traffic out of order to WTRUs if the flow is split across two or more QoS flows.

[0186] Configuration information may include flow-based QoS parameters. For example, flow-based QoS parameters may include PSER to be applied to the PDU set of the flow, PSDB to be applied to the PDU set of the flow, PSIHI to be applied to the PDU set of the flow, AL FEC success rate to be applied to the PDU set of the flow, etc.

[0187] Configuration information may include flow characteristics to help identify the flow. For example, a RAN node may be configured with information about the PSI value or range of PSI values ​​associated with the flow. As another example, the RAN may be configured with information about the PDU set size value or range of PDU set sizes associated with the flow.

[0188] A RAN node may take one or more actions to process a multiplexed or split flow. If a RAN node receives a QoS flow that is multiplexed or a flow that is split across two or more QoS flows, the RAN node may take one or more actions.

[0189] In the first exemplary RAN node action, the RAN node may (e.g., needs to) identify individual flows carried within a QoS flow. The RAN node may rely on the QFSID included in the GTP-U header to identify individual flows. The RAN node may also rely on other information in the GTP-U header to identify flows. For example, the RAN node may use PDU set information to help identify the start and end of a PDU set. The RAN node may use flow characteristics to help associate a PDU set with a specific flow.

[0190] In a second exemplary RAN node action, the RAN node may (e.g., needs to) identify whether / when a PDU set has been transmitted on another QoS stream. The RAN node may make this determination based on one or more of the following: receiving an out-of-order PDU set SN on the QoS stream used for identification; receiving an indication in the GTP-U header that the PDU set has been transmitted via another QoS stream (e.g., and receiving an indication of (one or more) missing PDU set SNs and / or stream identifiers (e.g., QFSIDs); receiving a virtual PDU from the UPF containing an indication that the PDU set has been transmitted via another QoS stream (e.g., the virtual PDU RAN may include an indication of (one or more) missing PDU set SNs); etc.

[0191] In the third exemplary RAN node action, for a flow split across two QoS flows, the RAN node can receive a set of PDUs with a burst end indication through one QoS flow. The RAN node can discard the set of PDUs on the other QoS flow and put the WTRU into sleep mode.

[0192] In one or more RAN node actions described in this paper, the RAN node may make a scheduling decision based on knowing that the set of PDUs arriving through different QoS flows belongs to the same flow.

[0193] For example, in the fourth exemplary RAN node action, for a flow split across two or more QoS flows, if the RAN node determines that a PDU set of the same flow has already been transmitted via another QoS flow, the RAN node may delay the transmission of the PDU set. If the RAN node determines that a PDU set with 'PDU set SN = k' is missing on a QoS flow, the RAN node may start a timer and postpone the transmission of a PDU set with 'PDU set SN = k+1' until it either transmits the PDU set with 'PDU set SN = k' or until the timer expires. An exemplary application of the fourth RAN node action could be in the case of video I-frames and video P-frames. For example, a video P-frame with PSSN 10, transmitted via QoS flow 2, may arrive at the RAN node before a PDU set with PSSN 9, which is a video I-frame, transmitted via QoS flow 1. In this case, the RAN node may wait for the video I-frame to arrive and then decide to transmit the video P-frame (e.g., because the loss of the video I-frame might make sending the video P-frame to the WTRU useless).

[0194] In the fifth exemplary RAN node action, for a flow split across two or more QoS flows, if the RAN node determines that a PDU set of the same flow that has been transmitted over another QoS flow arrives at the RAN node too late, the RAN node may discard the PDU set. For example, if the RAN node determines that a PDU set with 'PDU set SN = k' is missing on a QoS flow, and the RAN node has already transmitted a PDU set with 'PDU set SN = k+1', the RAN node may discard the PDU set with 'PDU set SN = k'.

[0195] In the sixth exemplary RAN node action, for a flow split across two or more QoS flows, the RAN node may prioritize the PDU set received via another QoS flow. For example, if the RAN node determines that a PDU set with 'PDU set SN = k' is missing on a QoS flow, and the RAN node receives a PDU set with 'PDU set SN = k+1', then the RAN node may prioritize the PDU set with 'PDU set SN = k'.

[0196] In the seventh exemplary RAN node action, for a flow split across two or more QoS flows, if the RAN node determines that a PDU set has been waiting for too long, the RAN node may prioritize the transmission of the PDU set. For example, if the RAN node determines that a PDU set with 'PDU set SN = k' is missing on a QoS flow, the RAN node may start a timer when this PDU set is received. If the timer expires and the PDU set with 'PDU set SN = k' has still not been transmitted, the RAN node may prioritize the PDU set with 'PDU set SN = k'.

[0197] In the eighth exemplary RAN node action, the RAN node may indicate to the WTRU that the PDU set is missing and can be transmitted via another DRB.

[0198] Although the features and elements described above are described in specific combinations, each feature or element may be used alone without other features and elements of the preferred embodiment, or in various combinations with or without other features and elements.

[0199] While the implementations described herein may consider 3GPP-specific protocols, it will be understood that the implementations described herein are not limited to this scenario and are applicable to other wireless systems. For example, while the solutions described herein consider LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it will be understood that the solutions described herein are not limited to this scenario and are also applicable to other wireless systems. For example, although the system has been described with reference to 3GPP, 5G, and / or NR network layers, the contemplated embodiments extend beyond implementations using specific network layer technologies. Similarly, potential implementations extend to all types of service layer architectures, systems, and embodiments. The techniques described herein can be applied independently and / or in combination with other resource allocation techniques.

[0200] The processes described herein can be implemented in computer programs, software, and / or firmware, which are incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and / or optical media (such as CD-ROMs and / or DVDs). The processor associated with the software can be used to implement a radio frequency transceiver for use in WTRUs, terminals, base stations, RNCs, and / or any host computer.

[0201] It will be understood that the entity performing the processes described herein can be a logical entity, which can be implemented in the form of software (e.g., computer-executable instructions) stored in the memory of a mobile device, network node, or computer system and executed on the processor of the mobile device, network node, or computer system. That is, the process can be implemented in the form of software (e.g., computer-executable instructions) stored in the memory of a mobile device and / or network node (such as a node or computer system), which, when executed by the node's processor, performs the process in question. It will also be understood that any transmission and reception processes illustrated in the figures can be executed by the node's communication circuitry under the control of the node's processor and the computer-executable instructions (e.g., software) it executes.

[0202] The various techniques described herein can be implemented in combination with hardware or software, or, where appropriate, with a combination of both. Therefore, implementations and devices of the subject matter described herein, or certain aspects or portions thereof, can take the form of program code (e.g., instructions) embodied in a tangible medium (including any other machine-readable storage medium), wherein when the program code is loaded into and executed by a machine such as a computer, the machine becomes a device for practicing the subject matter described herein. Where the program code is stored on a medium, it is possible that the program code in question is stored on one or more media that collectively perform the action in question; that is, the one or more media together contain code for performing the action. However, in the presence of more than one single medium, it is not required that any particular portion of the code be stored on any particular medium. Where the program code is executed on a programmable device, the computing device typically includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. For example, one or more programs can implement or use the processes described in conjunction with the subject matter described herein by means of APIs, reusable controls, etc. Such programs are preferably implemented in high-level procedural or object-oriented programming languages ​​to communicate with computer systems. However, if desired, one or more programs may be implemented in assembly or machine language. In any case, the language may be a compiled or interpreted language and combined with the hardware implementation.

[0203] While exemplary embodiments may refer to the use of aspects of the subject matter described herein in the context of one or more independent computing systems, the subject matter described herein is not limited thereto, but can be implemented in any computing environment, such as a networked or distributed computing environment. Furthermore, aspects of the subject matter described herein can be implemented in or across multiple processing chips or devices, and storage can similarly be affected across multiple devices. Such devices may include personal computers, web servers, handheld devices, supercomputers, or computers integrated into other systems, such as automobiles and aircraft.

[0204] In describing preferred embodiments of the subject matter of this disclosure, as illustrated in the figures, specific terminology has been used for clarity. However, the claimed subject matter is not intended to be limited to the specific terminology chosen so far, and it will be understood that each specific element includes all technical equivalents that operate in a similar manner to achieve a similar purpose.

Claims

1. A network node, comprising: The processor is configured as follows: A multiplexed data stream is generated, the multiplexed data stream including a first set of Packet Data Units (PDUs), a second set of PDUs, and an indication of a sequence number of a non-sequential set of PDUs, wherein the first set of PDUs is associated with a first data stream, and the second set of PDUs is associated with a second data stream; Determine a first mapping between a first subset of the non-sequential PDU set sequence numbers and a first set of sequential PDU set sequence numbers associated with the first data stream; Determine a second mapping between a second subset of the non-sequential PDU set sequence numbers and a second set of sequential PDU set sequence numbers associated with the second data stream; and Send the multiplexed data stream, the indication of the first mapping, and the indication of the second mapping.

2. The network node of claim 1, wherein the multiplexed data stream further includes a third PDU set associated with the third data stream, and the processor is further configured to: Determine a third mapping between a third subset of the non-sequential PDU set sequence numbers and a third set of sequential PDU set sequence numbers associated with the third data stream; and Send the instruction for the third mapping.

3. The network node of claim 1, wherein the indication of the first mapping includes a PDU set delay budget (PSDB) applied to the first data stream, a PDU set error rate (PSER) applied to the first data stream, or a forward error correction (FEC) success rate applied to the first data stream.

4. The network node of claim 1, wherein the indication of the first mapping includes an indication of a sequence number offset.

5. The network node of claim 1, wherein the processor is further configured to: Determine the first data radio bearer (DRB) associated with the first data stream; and Determine the second DRB associated with the second data stream.

6. The network node of claim 1, wherein the processor is further configured to: Determine that the first PDU set is associated with the first data stream, wherein the indication of the first mapping includes a first Quality of Service (QoS) flow identifier among the PDUs of the first PDU set; and The second PDU set is associated with the second data stream, wherein the indication of the second mapping includes a second QoS stream identifier among the PDUs of the second PDU set.

7. The network node of claim 1, wherein the multiplexed data stream is received via a single Quality of Service (QoS) stream.

8. The network node of claim 1, wherein the indication of the first mapping and the indication of the second mapping are included in the Real-Time Protocol (RTP) header associated with the multiplexed data stream.

9. A network node, comprising: The processor is configured as follows: Receive a first multiplexed data stream, the first multiplexed data stream including a first set of packet data units (PDUs), a second set of PDUs, and an indication of a sequence number of a non-sequential set of PDUs, wherein the first set of PDUs is associated with a first data stream, and the second set of PDUs is associated with a second data stream; A first mapping associated with the first data stream is determined based on the sequence number of the non-sequential PDU set. A second mapping associated with the second data stream is determined based on the sequence number of the non-sequential PDU set. and Send a second multiplexed data stream, an indication of the first mapping, and an indication of the second mapping.

10. The network node of claim 9, wherein the processor is further configured to: Receive a first data stream including a first set of packet data units (PDUs), a second data stream including a second set of PDUs, and an instruction to multiplex the first data stream and the second data stream onto the second multiplexed data stream, wherein the first set of PDUs and the second set of PDUs have non-sequential PDU set sequence numbers.

11. The network node of claim 10, wherein the instruction to multiplex the first data stream and the second data stream is received from the session management function via an N4 rule.

12. The network node of claim 9, wherein the processor is further configured to: The first PDU set is determined to be associated with the first data stream, wherein the indication of the first mapping includes a PDU set delay budget (PSDB) applied to the first data stream, a PDU set error rate (PSER) applied to the first data stream, or a forward error correction (FEC) success rate applied to the first data stream.

13. The network node of claim 9, wherein the processor is further configured to: The first PDU set is determined to be associated with the first data stream, wherein the indication of the first mapping includes an indication of a sequence number offset.

14. The network node of claim 9, wherein the sequence number offset is calculated per PDU set as the difference between the sequential PDU set sequence number and the non-sequential PDU set sequence number associated with the PDU set.

15. The network node of claim 9, wherein the processor is further configured to: Determine that the first PDU set is associated with the first data stream, wherein the indication of the first mapping includes a first Quality of Service (QoS) flow identifier among the PDUs of the first PDU set; and The second PDU set is associated with the second data stream, wherein the indication of the second mapping includes a second QoS stream identifier among the PDUs of the second PDU set.

16. The network node of claim 9, wherein the second multiplexed data stream is transmitted via a single Quality of Service (QoS) stream.

17. The network node of claim 9, wherein the Quality of Service (QoS) flow identifier is based on a flow identifier included in the Real-Time Protocol (RTP) header associated with the first multiplexed data flow.

18. The network node of claim 9, wherein the processor is further configured to: If the first data stream and the second data stream share the same flow identifier, an indication is sent to the SMF regarding a possible renumbering of the flow identifier of the Quality of Service (QoS) flow associated with the first data stream or the second data stream.

19. The network node of claim 9, wherein the indication of the first mapping includes an indication that this is the last or first PDU of the flow.

Images