Modulation-based UEP-hierarchical modulation

Abstract

Methods and apparatus for communicating in a wireless network are disclosed. In an embodiment, a wireless transmit receive unit (WTRU) is adapted to transmit and receive PHY-layer packets of a data stream with another device (e.g., a base station or peer-to-peer device) using a video-aware unequal protection (UEP) modulation configuration that may distinguish the transmitted / received packets according to a hierarchy utilized in the application layer. In an example, when a base layer (BL) application packet is included, the PPDU may be modulated with a first configuration; when an enhancement layer (EL) application packet is included, modulation may be performed with a second configuration. Examples of the first and second configurations may be differentiated based on bit allocations in a single constellation. In a second example, the first and second configurations may be differentiated based on bit allocation and distance in a single constellation. Various combinations and other embodiments are described.

Description

[0001] Related applications

[0002] This application claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 423,367, filed on November 7, 2022, entitled “Modulation-Based UEP - Hierarchical Modulation,” the entire contents of which are incorporated herein by reference. Background Art

[0003] The evolving wireless networks for mobile media services, cloud augmented and virtual reality (AR / VR), cloud gaming, video-based remote control of machines or drones, etc. are expected to be accompanied by a significant increase in traffic in the near future. Despite using different compression technologies and codecs, all these types of media traffic flows have some common characteristics. These characteristics are very useful for potential improvements in transmission control and efficiency in the evolution of radio access network (RAN) architecture. However, current architectures typically treat media services together with other data services without fully utilizing these commonalities. For example, data packets within an application data frame have dependencies on each other because the application needs all of these packets to decode the frame. Therefore, the loss of one packet will render other related packets useless, even if they may have been successfully transmitted. For example, some applications may impose requirements in terms of media units (application data units) rather than in terms of individual packets / PDUs.

[0004] In another example, packets within the same video stream but of different frame types (I / P / B frames) or even different positions within a group of pictures (GoP) frame contribute differently to the user experience (e.g., frames corresponding to base layer pictures of a first resolution and frames corresponding to enhancement layers providing a second, higher resolution picture), so a layered QoS scheme for processing within the video stream can potentially relax requirements and thus improve efficiency. However, current system implementations lack the ability to correctly distinguish data types at lower layers of the network stack (e.g., the physical (PHY) layer). Summary of the Invention

[0005] To address the above and other problems in existing implementations, the present application is directed to systems and methods for unequal error protection (UEP)-layered modulation. Specifically, certain embodiments relate to distinguishing data in the PHY layer, for example, distinguishing data packets for transmission and / or reception based on the relative importance of corresponding data packets from the application layer contained in the data packets for transmission and / or reception. For example, a wireless transmit and receive unit (WTRU) can distinguish received data packets based on the modulation configuration used and prioritize / group them, for example, into video base layer (BL) data and video enhancement layer (EL) data. In one example, the WTRU applies a single constellation method configured in the WTRU to demodulate a signal received in the downlink. The WTRU can distinguish received data packets (e.g., BL or EL) based on the point in the constellation that modulates them. Physical packet data units (PPDUs) can be grouped into sets based on their priority and mapped to modulations so that, for example, base layer video data packets are demodulated with a higher priority. Thus, in some implementations, the mapping or grouping can follow a hierarchy or form a layered constellation, where packets from a first set are mapped to a first constellation subset and packets from a second set are mapped to a second constellation subset, where the second constellation subset is a child or subset of the first constellation. Various other embodiments are also described. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] A more detailed understanding may be obtained from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals represent like elements, and in which:

[0007] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

[0008] Figure 1B is a diagram illustrating that according to an embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within the illustrated communication system;

[0009] Figure 1C is a diagram illustrating that according to an embodiment, Figure 1A a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) for use within the illustrated communication system;

[0010] Figure 1D is a diagram illustrating that according to an embodiment, Figure 1A A system diagram of another exemplary RAN and another exemplary CN used within the illustrated communication system;

[0011] Figure 2 is a block diagram illustrating an exemplary multimodal interaction system;

[0012] Figure 3 is an exemplary diagram comparing an example video game group of pictures (GOP) frame viewing order and an example frame transmission order;

[0013] Figure 4 Pictured Figure 3 the impact of errors in the examples;

[0014] Figure 5 illustrates an example row architecture for a layered video scheme, where video quality is progressively refined;

[0015] Figure 6 is an example representation of the dependency relationship for the GOP=2 partition mode of an H.264 / AVC video stream;

[0016] Figure 7 is an example representation of dependencies for GOP=4 in a Scalable Video Coding (SVC) stream;

[0017] Figure 8 is an example representation of GOP=4 in a stereoscopic video stream encoded by Multiview Video Coding (MVC);

[0018] Figure 9 shows an exemplary video stream packaged into a Real Time Protocol (RTP) packet data unit (PDU) stream;

[0019] Figure 10 is a block diagram illustrating a system using a Quality of Service (QoS) model extended for media PDU classification;

[0020] Figure 11 illustrates an example of a set of PDUs within a Packet QoS flow;

[0021] Figure 12 is an example representation of control plane protocol stack layers according to various embodiments;

[0022] Figure 13 is an example representation of user plane protocol stack layers according to various embodiments;

[0023] Figure 14A is a sequence diagram between network entities according to an exemplary embodiment, which illustrates an overview of video layer-aware scheduling;

[0024] Figure 14B is a sequence diagram between network entities according to another exemplary embodiment, which demonstrates an overview for video layer-aware scheduling;

[0025] Figure 15 An example of single constellation based operation signaling according to an embodiment is illustrated;

[0026] Figure 16illustrates an exemplary embodiment of signaling using a single constellation-bit allocation;

[0027] Figure 17 is an exemplary embodiment of signaling using a single constellation - joint bit and distance allocation;

[0028] Figure 18 A flow chart and method for a wireless transmit and receive unit (WTRU) to enable a single constellation unequal error protection (UEP) framework during downlink (DL) transmissions according to an embodiment are shown;

[0029] Figure 19 A flow chart and method for a WTRU to enable a single constellation UEP framework during uplink (UL) transmission according to an embodiment are shown;

[0030] Figure 20 is a representation illustrating an embodiment using six quadrature amplitude modulation (QAM) bit splitting for three different priority traffic flow layers;

[0031] Figure 21 is a flow chart of a method for a WTRU to communicate in a wireless network according to an embodiment using a single constellation in the downlink;

[0032] Figure 22 is a flow chart of a method for communicating by a WTRU in a wireless network according to an embodiment using a single constellation in the uplink; and

[0033] Figure 23 is a flow chart of a method by a WTRU for communicating in a wireless network according to an embodiment using a single constellation in uplink with feedback. DETAILED DESCRIPTION

[0034] Figure 1A is a diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content (e.g., voice, data, video, messaging, broadcast, etc.) to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing 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 discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0035] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated process chain environments), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0036] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly connect to at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or other networks 112. For example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNodeB (eNB), a Home NodeB, a Home eNodeB, a next-generation NodeB (e.g., a gNodeB (gNB)), a New Radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0037] Base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless 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 wireless service coverage for a particular geographic area, which may be relatively fixed or vary 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. Thus, in one embodiment, base station 114a may include three transceivers, one for each cell sector. In an embodiment, base station 114a may employ multiple-input, multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0038] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0039] More specifically, as described above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. 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 Uplink (UL) Packet Access (HSUPA).

[0040] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-APro).

[0041] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using NR.

[0042] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may jointly implement LTE radio access and NR radio access, e.g., using dual connectivity (DC) principles. Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple radio access technologies and / or transmissions to / from multiple types of base stations (e.g., eNBs and gNBs).

[0043] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

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

[0045] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may 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 described in detail in the text, the CN 106 may be configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Figure 1A Although not shown in the figures, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0046] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) of the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

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

[0048] Figure 1B is a system diagram illustrating an exemplary WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, 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 peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0049] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of 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), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0052] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

[0053] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information from and store data in any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. The 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. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0055] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0056] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide one or more additional features, functions, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Module, frequency modulation (FM) radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Peripheral device 138 may include one or more sensors. The sensor may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

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

[0058] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0059] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. Each of the eNode-Bs 160a, 160b, 160c may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0060] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Figure 1C As shown, eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0061] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0062] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. The MME 162 may also provide control plane functions for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0063] The SGW 164 may be connected to each eNode B 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may also perform other functions, such as anchoring the user plane during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0064] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0065] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional wired communications devices. For example, the CN 106 may include or communicate with an IP gateway, such as an IP Multimedia Subsystem (IMS) server, that serves as an interface between the CN 106 and the PSTN 108. The CN 106 may also provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned by other service providers.

[0066] Even though the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments such terminals may (eg, temporarily or permanently) employ a wired communication interface with a communication network.

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

[0068] A WLAN in infrastructure basic service set (BSS) mode 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 or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic in and out of the BSS. Traffic originating from outside the BSS and destined for a STA may be delivered to the STA via the AP. Traffic originating from a STA destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic flows between STAs within a BSS may be sent via the AP, for example, where a source STA may send a traffic flow to the AP, and the AP may deliver the traffic flow to the destination STA. Traffic flows between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic flows. Peer-to-peer traffic flows may be sent (e.g., directly) between a source and destination STA via a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

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

[0070] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0071] Very high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining 8 consecutive 20MHz channels, or by combining two non-contiguous 80MHz channels (which can be called an 80+80 configuration). For the 80+80 configuration, the data after channel coding can be passed through a segment parser that can separate the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing are performed on each stream separately. The stream can be mapped onto two 80MHz channels, and the data is sent by the transmitting STA. At the receiver of the receiving STA, the above-mentioned operations for the 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

[0072] 802.11af and 802.11ah support operating modes below 1 GHz. In 802.11af and 802.11ah, the channel operating bandwidth and carriers are reduced relative to the bandwidths and carriers 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 uses non-TVWS spectrum to support 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths. According to a representative embodiment, 802.11ah can support metered type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0073] WLAN systems that support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as a primary channel. The bandwidth of the primary channel is 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 lowest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for a STA that supports (e.g., only supports) a 1 MHz mode (e.g., an MTC-type device), the primary channel can 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 allocation vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy (e.g., due to a STA (supporting only 1 MHz operating mode) transmitting to the AP), all available frequency bands may be considered busy, even if most of the available frequency band remains idle.

[0074] In the United States, 802.11ah operates in the 902MHz to 928MHz band. In South Korea, the available band is from 917.5MHz to 923.5MHz. In Japan, the available band is from 916.5MHz to 927.5MHz. Depending on the country code, the total available bandwidth for 802.11ah ranges from 6MHz to 26MHz.

[0075] Figure 1D 1 is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may employ NR wireless technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0076] The RAN 104 may include gNBs 180a, 180b, and 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. Each of the gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit and / or receive signals to and from the gNBs 180a, 180b, and 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit and / or receive wireless signals to and from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers (not shown) to the WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, and 180c may implement coordinated multi-point transmission (CoMP). For example, the WTRU 102a may receive coordinated transmissions from both gNB 180a and gNB 180b (and / or gNB 180c).

[0077] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or varying absolute time lengths).

[0078] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without concurrently accessing other RANs (e.g., the eNode-Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNBs 180a, 180b, 180c while also communicating / connecting with another RAN (e.g., the eNode-Bs 160a, 160b, 160c). For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may serve as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for the serving WTRUs 102a, 102b, 102c.

[0079] Each gNB 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, interworking between DC, NR, and E-UTRA, routing user plane data to a user plane function (UPF) 184a, 184b, routing control plane information to an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0080] Figure 1DThe illustrated CN 106 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. While the aforementioned elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0081] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, mobility management, and the like. The AMF 182a, 182b may use network slicing to customize CN support based on the type of service being used by the WTRU 102a, 102b, 102c. For example, different network slices may 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-to-cell (MTC) access. The AMFs 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies (e.g., WiFi).

[0082] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, and so on.

[0083] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N3 interface. This may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0084] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Furthermore, the CN 106 may provide the WTRUs 102a, 102b, 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, the WTRUs 102a, 102b, 102c may connect to a local DN 185a, 185b through the UPFs 184a, 184b via the N3 interface to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0085] Given that Figures 1A to 1D

[0015] As described herein, one or more or all of the functionality described herein (involving one or more of the following: the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein) may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functionality described herein. For example, an emulation device may be used to test other devices and / or emulate network and / or WTRU functionality.

[0086] The simulation device can be designed to perform one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as a part of a wired or wireless communication network to test other devices in the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as a part of a wired or wireless communication network. The simulation device can be directly coupled to another device for testing purposes and / or perform testing using over-the-air wireless communication. One or more simulation devices can perform one or more (including all) functions when not being implemented / deployed as a part of a wired or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a wired and / or wireless communication network that is not deployed (e.g., tested) to realize testing of one or more components. One or more simulation devices can be test devices. The simulation device can use direct RF coupling and / or wireless communication through RF circuits (e.g., which may include one or more antennas) to send and / or receive data.

[0087] As mentioned earlier, given the characteristics of extended reality (XR) and other media services, a lot of research and development is underway in the investigation of enhanced QoS mechanisms. It is also recognized that in order to help applications adapt to network conditions and provide better quality of experience (QoE), the exposure of network information to applications should be investigated and enhanced, especially for media services with large traffic bursts. XR / media traffic flows are characterized by high throughput, low latency, and high reliability, and UE battery power may affect the user experience because high throughput requires high power consumption on the terminal side. Therefore, considering these requirements that are expected to be more stringent in the future, limited wireless resources, and end-to-end QoS policy control from a system perspective, further system optimization and enhancements beyond the current 5G enhancement solutions are needed to support further trade-offs between throughput, latency, reliability, and device battery life.

[0088] Some advanced XR or media services may include more modalities in addition to video and audio streams, such as information from different sensors and tactile or emotional data (e.g., haptic data or sensor data) for a more immersive experience. To support the early requirements of such tactile and multimodal communication services, efforts are already underway to investigate how to address the service requirements of different types of traffic flows using coordinated QoS selection and packet processing, guaranteed latency and reliability, and time synchronization of these parallel messages to ensure the best possible service experience. Service requirements are only expected to become more extreme.

[0089] Regarding multimodal communication services, these services involve multimodal data, a term used to describe input data from different types of devices / sensors or output data to different types of destinations (e.g., one or more WTRUs) required for the same task or application. Multimodal data consists of multiple unimodal data with strong dependencies between each unimodal data. Unimodal data can be considered a single data type.

[0090] refer to Figure 2 , depicts an example of a multimodal interaction system 200. As shown, a multimodal output 212 is generated based on input 204 from multiple sources. In a multimodal interaction system, a modality is a type or representation of information in a particular interactive system. Multimodal interaction is the process of exchanging information in multiple modalities. Modal types include motion, emotion, gesture, etc. Modal representations include video, audio, haptics (vibration or other motion that provides tactile or haptic sensations to a person or machine), etc. Examples of multimodal communication services may include immersive multimodal virtual reality (VR) applications, remote-controlled robots, immersive VR games, skill set sharing for collaborative perception and operation of robots, selective immersion in live events, tactile feedback for personnel exclusion zones in dangerous remote environments, etc.

[0091] Video service flow (in Figure 2 A video stream (represented as a video stream in the example for simplicity) is typically structured as a group of pictures (GOP), where each picture constitutes a video frame. Figure 3 is an illustrative diagram comparing an example of a video game group of pictures (GOP) frame viewing order 302 with an example of a frame transmission order 304. Frames come in different types, and different frame types serve different purposes and have different importance for video application rendering. An "I" frame is a frame that is compressed based solely on the information contained in the frame; without reference to any other video frames before or after it. "I" stands for "intra" coding. A "P" frame is a frame that is compressed using data contained in the frame itself as well as data from the nearest previous I or P frame. "P" stands for "predicted." A "B" frame is a frame that is compressed using data from the nearest previous I or P frame and the nearest subsequent I or P frame. "B" stands for "bidirectional," meaning that the frame data may depend on frames before and after it in the video sequence. A group of pictures, or GOP, is a series of frames consisting of a single I frame and zero or more P and B frames. A GOP always starts with an I frame and ends with the last frame before the next subsequent I frame. All frames in a GOP depend (directly or indirectly) on data in the initial I frame. Open GOP and closed GOP are terms that refer to the relationship between one GOP and another. A closed GOP is self-contained; that is, no frames in the GOP reference or are based on any frames outside the GOP. An open GOP uses data from subsequent I-frames to calculate some of the B-frames in that GOP.

[0092] It should be noted that the second I frame (in Figure 3 The first frame of the next GOP is shown in gray on the right side of the frame viewing order 302, approximately one-third of the way from the right in the frame transmission order 304. B frames 11 and 12 are based on this I frame because this is an open GOP structure.

[0093] As mentioned above, packets of the same video stream but of different frame types (I / P / B frames) or even at different positions in a GoP contribute differently to the user experience. Figure 4 For example, error 402 on P frame 4 will cause error 404 to be induced on B frames 2, 3, 6, and 7. Error 402 may also propagate as propagation errors 406A, 406B to P frames 7 and 10, causing further errors 408A, 408B to be induced on B frames 8, 9, 11, and 12.

[0094] Video compression algorithms can encode a video stream into multiple video layers, allowing the receiver to gradually refine the reconstructed video quality. This is driven by the need for video distribution to support heterogeneous devices, unreliable networks, and bandwidth fluctuations. Typically, the most important layer is called the video base layer (BL), and less important layers are called video enhancement layers (EL), which depend on the video BL. In addition, the EL may be further dependent on even less important ELs. If the video BL or video EL is lost or damaged during its transmission, the dependent layers cannot be used by the decoder and must be discarded.

[0095] Many video coding techniques have been investigated and standardized. Figure 5 An example of a multi-layer video stream spanning the length of a GoP is shown. As shown, a layered video encoder 502 can provide a multiplexed stream comprising substreams or layers 506A-506D via a multiplexer 504, which may be at different bit rates or throughputs. Each stream can be decoded by a corresponding layered video decoder 508A to 508D for output to a variety of devices. In many implementations, a single video decoder can provide decoding for different channels; therefore, the multiple decoders 508 can be replaced by a single decoder capable of receiving and decoding multiple substreams 506.

[0096] exist Figure 6 , the layers of the video stream are referred to as partitions A, B, and C. In this example, "B->A" means that partition B depends on partition A, and "B->I" means that frame B 604A is predicted from frame I 602. Similarly, frame P 606A can be predicted from frames B 604A, 604B, and frame P 606B can be predicted from frame B 604A.

[0097] exist Figure 7, illustrates layer dependencies in a Scalable Video Coding (SVC) stream. Video layers L0, L1, and L2 represent video BL, video spatial EL, and video temporal EL, respectively. In this example, "->" means "depends on," while "-->" means "predicted from." As shown, frame B 704A is predicted from frame I 702 and frame B 708A; frame B 704B is predicted from frame B 708A and frame P 706A, and so on.

[0098] exist Figure 8 , the dependency relationship in Multi-view Video Coding (MVC) from the Joint Video Team (JVT) standard is exemplified. In this example, "->" means "depends on," while "-->" means "predicted from." As shown, frames in a first view 710A can be used as a basis for predicting other frames in that view (e.g., frame B 704A is predicted from frame I 702), and can also be used as a basis for predicting frames in a second view 710B (e.g., frame P 706A is predicted from frame I 702).

[0099] In some embodiments, the video data may be interpreted as multimodal data, which is composed of multiple unimodal data. Each unimodal data may be interpreted as a video frame or a video layer within a video frame, depending on whether the video frame is composed of multiple video layers.

[0100] The processing of PDU sets within a bearer or QoS flow according to certain exemplary embodiments will now be described. In one example, application data needs to be transmitted to a cellular system via a transport network. This requires that the application data be packaged. An example of such packaging can use Real-Time Protocol (RTP) packets or RTP PDUs. An example of packaging a video stream into RTP PDU packets is as follows: Figure 9 As shown, it includes I frame 802, B frames 804A, 804B and P frame 806.

[0101] As mentioned above, the packets within an application data frame have dependencies on each other because the application needs all of them to decode the frame. Therefore, the loss of one packet will render other related packets useless, even if they have been successfully transmitted. For example, XR applications impose requirements in terms of media units (application data units) rather than individual packets / PDUs. Therefore, in one embodiment, a PDU set can be defined, which consists of one or more PDUs carrying a payload of an information unit (media data unit) generated at the application layer (for example, a video frame, or video slice, or video layer for a video XRM service, or unimodal data within multimodal data). In some implementations, the application layer requires all PDUs in the PDU set to use the corresponding information unit. In other implementations, when some PDUs are lost, the application layer can still recover part or all of the information units.

[0102] Within a QoS flow or bearer, packets of a packetized media data unit (PDU) may have different levels of importance, such as Figure 10 As shown. It should be noted that QoS flow is the finest granularity of QoS differentiation in PDU session in 5G core network. Similarly, bearer is the finest granularity of QoS differentiation for bearer-level QoS control in radio access network (RAN) or core network of earlier generation than 5G core network. One or more QoS flows can be mapped to a bearer in RAN. Figure 10 In FIG, a bearer corresponds to an access network (AN) network resource illustrated by a tunnel between the AN and the WTRU 1002 (denoted as an example of a "UE"). A user plane function (UPF) 1006 may provide offloading and QoS marking of packets.

[0103] For example, XR media (XRM) service PDUs have dependencies on each other. The other PDUs (e.g., I-frames, video base layer, first single-modal data in multimodal data) that the PDUs depend on (e.g., P-frames, B-frames, video enhancement layer, second single-modal data in multimodal data) are expected to be more important and should be transmitted first, or different levels of packet scheduling and error resilience are provided. For example, in some video XRM services, P-frames and B-frames are as important as I-frames and are used to build smooth video. Dropping these P-frames and B-frames will cause jitter in QoE, which is no better than abandoning the entire service. In some other video XRM services, P-frames and B-frames are used to enhance high definition, such as from 720p to 1080p. When network resources cannot transmit all service data, dropping these P-frames and B-frames makes sense to maintain the service.

[0104] PDUs with the same importance level within a QoS flow or bearer can be considered as PDU sets (for example, video frames, or video layers, or unimodal data within multimodal data). In one embodiment, XRM service data can be classified as a list of continuous PDU sets. In addition to the importance level, the QoS requirements for XRM service flows are consistent. Therefore, XRM service flows can be mapped to QoS flows. And the QoS flow should include a list of PDU sets with different importance levels. The PDU set may include a PDU list, and in an exemplary embodiment, each PDU set may have the following factors:

[0105] -Sequence number of the PDU set;

[0106] - Importance level of the PDU set;

[0107] - PDU set boundary information; for example, in one embodiment, (i) a start marker of a PDU set, which is valid only for the first PDU of a PDU set (as shown in the example figure, unless the next PDU is the first PDU of another PDU set, the network cannot know whether the current PDU is the last PDU of the current PDU set, and in order to avoid always waiting for the next PDU to estimate whether the currently received PDU is the last PDU of the PDU set, it is recommended not to mark the last PDU of the PDU set, but to mark the first PDU of the PDU set); and (ii) a sequence number of the PDU within the PDU set, which can be used to allow support for out-of-order detection and reordering; and

[0108] - The sequence number of the dependent PDU set. (If the current PDU set 2 depends on PDU set 1, then PDU set 2 should carry the sequence number of PDU set 1.)

[0109] An example of the PDU sets 1102A and 1102B according to one embodiment is as follows: Figure 11 An example of a PDU aggregate header is shown in Table 1 below:

[0110]

[0111] Table 1

[0112] The above fields may be fixed length or variable length in various implementations and may appear in any order. In some implementations, one or more fields may not exist.

[0113] The description of various embodiments may include the following: The term "layer" is used in different contexts in the embodiments described herein to mean very different things, depending on the context in which it is used. There are at least the following different contexts and distinctions in the use of the term layer in the description of these embodiments, and are explained below.

[0114] The term video layer as used herein generally refers to the previously described PDU sets, where PDU sets (and PDUs within a PDU set) can be allocated in the cellular system access stratum (AS) or non-access stratum (NAS) based on the relative importance of the PDU sets (e.g. Figure 10 and Table 1) provide differentiated transmission processing or reception processing. In addition, the functions of telecommunication systems (particularly cellular communication systems) are usually structured into different groups of related functions, traditionally referred to as "protocol layers". Examples of 5G protocol stack layers for control plane and user plane are shown as follows: Figure 12 and Figure 13 As shown. Figure 12 As shown in FIG, the control plane may include the following protocol layers: PHY, MAC, RLC, PDCP, RRC, and NAS. Figure 13As shown, the user plane may include the following protocol layers: PHY, MAC, RLC, PDCP, SDAP. The access layer may be composed of PHY, MAC, RLC, PDCP, SDAP protocol layers. Therefore, the terms "video layer" and "protocol layer" are described with respect to exemplary embodiments to mean two very different concepts. From the perspective of a given protocol stack layer, the upper layer of the protocol stack means one or more protocol stack layers above the given protocol layer, and the lower layer of the protocol stack means one or more protocol stack layers below the mentioned protocol layer. For example, from the perspective of the PHY protocol stack layer, the upper layer of the protocol stack may be the RRC layer, and from the perspective of the RRC layer, the upper layer of the protocol stack may be the NAS layer or the application layer. Similarly, for example, from the perspective of SDAP, the upper layer of the protocol stack may be the network Internet Protocol (IP) layer or the transport RTP protocol stack layer, or the application layer, and the lower layer of the protocol stack may be the PDCP layer. As Figure 12 and 13 As shown, different devices or network nodes or functions (e.g., UE 1202, gNB 1204, AMF 1206; and UE 1302 and gNB 1304) may provide functions at different layers of the protocol stack. For example, AMF 1206 may provide NAS functions to UE 1202 that are not provided by gNB 1204. Such communications may be provided by lower layers of the network stack (e.g., RRC protocol, PDCP protocol, etc.), and the gNB may be unaware of such communications.

[0115] In addition to the term RTP PDU (as previously described), various embodiments contemplate the PDU as an access layer protocol layer PDU for purposes of differentiated PDU aggregation send processing or receive processing. It should be noted that for all practical purposes, the RTP PDU can be segmented into access layer protocol layer PDUs or aggregated into access layer protocol layer PDUs.

[0116] Multiple-Input Multiple-Output (MIMO) Layer or MIMO Spatial Layer: A MIMO layer is an independent data stream that can be transmitted simultaneously between a base station and one or more users. Single-User MIMO (SU-MIMO) is the ability to send one or more data streams (i.e., MIMO layers) from a transmit array to a single user. The number of layers that can be supported (called the rank) depends on the wireless channel. In Multi-User MIMO (MU-MIMO), the base station uses the same time and frequency resources to send different MIMO layers simultaneously to different users in different beams, thereby increasing network capacity.

[0117] As mentioned earlier, for XR and multimodal traffic flows, regardless of the codec used, there are some common features that can be used for better transmission control and efficiency. Media application properties that can exploit this potential may include information such as the relative importance of a PDU set among multiple PDU sets derived from the packetization of the media data stream, the scheduling deadline of the PDUs within a PDU set, and the content delivery benchmark used for the PDUs within a PDU set (such as "all or nothing", "valid until first loss", or "forward error correction (FEC) with static or variable bit rate". The content delivery benchmark may help define whether a PDU in a PDU set is delivered or discarded after missing a deadline, or can no longer meet the content benchmark of its associated PDU set, or has already met the content benchmark of its associated PDU set.

[0118] Various embodiments described herein can achieve solutions: Figure 10 The illustrated QoS framework for media PDU classification provides differentiated transmission or reception processing for a PDU set and its corresponding PDUs within a QoS flow or bearer, taking into account the relative importance or priority of the PDU set and its corresponding PDUs. Specifically, certain embodiments may implement the application of different modulation and coding schemes (i.e., modulation order and coding rate) to support differentiated transmission or reception processing for a PDU set and its corresponding PDUs, provided that their relative importance or priority is visible to the physical layer.

[0119] For example, the video base layer (video BL) should provide more robust error protection than the video enhancement layer (video EL) by applying a less aggressive MCS. Furthermore, more important video ELs should provide more robust error protection than less important video ELs. As previously mentioned, the term video layer is generally used herein to refer to a PDU or a set of PDUs consisting of PDUs of equal importance, as defined herein. In certain embodiments, a video base layer is a set of PDUs or packet service units (PSUs) with video base layer importance. Furthermore, in this embodiment, a video enhancement layer is a PDU or set of PDUs with corresponding video enhancement layer importance. While the term video layer is used throughout this specification to describe PHY protocol layer processing that supports differentiated transmit or receive processing, it should be understood that the embodiments described herein are broadly applicable to any metric where RAN protocol stack PDUs can be differentiated based on the video layer they represent, and thus processed according to the importance or priority level of their corresponding video layer. In some implementations, if a second video EL is dependent on a first video EL (e.g., using frames of the first video EL for prediction or decoding), the first video EL can have a higher priority or be more important than the second video EL. Therefore, if a layer or frame is used to decode or predict other frames or layers, it may be more important and deserve a higher QoS setting.

[0120] In an exemplary embodiment, a WTRU is enabled to notify its ability to implement unequal error protection (UEP) for video. For example, the WTRU capabilities may be reported to a base station (BS) to enable high-reliability video transmission. In an embodiment, the WTRU reports various important capabilities to the BS to implement features of the embodiment, such as the supported modulation order, maximum bandwidth, subcarrier spacing, etc. for downlink and uplink. In an embodiment, the UE may report one or more of the following capabilities to the BS:

[0121] -Distinguish different video layers at the lower level of the protocol stack;

[0122] -Support differentiated processing of video layer;

[0123] -Support differentiated processing of video frames;

[0124] -Support differentiated processing of video frames within GOP;

[0125] -Supports differential processing of video frames across GOPs;

[0126] - Simultaneously modulate / demodulate different video layers using different constellations;

[0127] - Encode / decode different video layers separately; and / or

[0128] - Jointly encoding / decoding different video layers in upper or lower protocol stack layers, or both, e.g. to support video layer-aware forward error correction (LA-FEC), also known as inter-layer forward error correction (IL-FEC).

[0129] The identifiers described above can inform the BS what the WTRU can handle and which embodiments are applicable for video transmission. Example WTRUs may include not only smartphones, tablets, etc., but also IoT devices for low-cost, low-power wide area network applications, such as mid-tier cost reduction capability (REDCAP) devices for industrial wireless sensor network (IWSN) applications, examples of which include electricity meters, parking meters, security cameras, networked fire hydrants, networked mailboxes, etc. Anticipated use cases for the embodiments described herein may include applications requiring uplink or downlink video, or applications requiring only uplink or downlink video traffic. Furthermore, the concepts described in this disclosure are equally applicable to any multimodal traffic stream, which may not include video traffic but rather traffic streams of two or more different modalities, such as audio, sensor-related traffic streams (e.g., temperature, humidity, pressure, smell, etc.), or tactile data (e.g., pressure, texture, vibration, temperature, etc.) when touching a surface to support immersive reality applications, generally denoted herein as XR applications. Such traffic streams may be formatted with different levels of resolution, accuracy levels / quantization, or precision levels / quantization. Such a level of resolution, accuracy or precision may be equivalent to a layer of a video service flow or an equivalent term described in the embodiments of this document. Therefore, the unequal error protection method described herein is also applicable to this service flow.

[0130] The embodiments described herein may also be applicable to any RAT, including cellular RATs, such as 5G cellular RATs or future 6G cellular RATs, and 802.11 WLAN (Wi-Fi) RATs, that may support these capabilities. Furthermore, while the embodiments may be described in terms of a Uu interface interacting with a base station, these embodiments are equally applicable to communications over sidelink interfaces, such as PC5 interfaces, D2D, or any wireless link where advantages may be gained.

[0131] Figure 14A An overview of a video layer-aware scheduling method and apparatus according to an embodiment is shown. In general, the steps may include one or more of the following.

[0132] At 1408, in some embodiments, the WTRU (1402, also referred to as a target UE) signals its capabilities to a scheduler (e.g., a gNB 1404, a base station, or other such device or network node), e.g., autonomously based on a trigger from upper layers of the WTRU 1402 protocol stack, or optionally upon request by the scheduler at 1406 (shown in dashed lines).

[0133] At 1410, the WTRU 1402 establishes an RRC connection and associated one or more signaling bearers, and one or more data radio bearers, in this example through an RRC reconfiguration procedure. The WTRU 1402 may be configured with measurement and reporting configurations as part of the RRC reconfiguration procedure at 1412.

[0134] At 1414, the WTRU 1402 may report measurement results to the scheduler 1404. The measurement results may include measurement results to support scheduling operations, including throughput measurements, RRM measurements, and other link quality assessment related measurements, such as the experienced block error rate, bit error rate, or packet error rate, or other metrics / amounts of deviation / delta between the target QoS / QoE and the experienced QoS or QoE. Examples of measurement reports include a buffer status report (BSR), or a scheduling request (SR) requesting resources for BSR reporting, or a power headroom report (PHR). For BSR, PHR, or SR, the WTRU may report these measurement results on a per-video layer basis so that the scheduler understands the uplink scheduling requirements at the WTRU at the video layer or any other video partition granularity. It should be noted that two or more video layers may be associated with the same bearer or QoS flow. In many implementations, the WTRU may report these measurements at a level of granularity that enables the scheduler to understand the scheduling requirements for either direction of communication (i.e., uplink or downlink) beyond the level of QoS treatment differentiation traditionally provided by existing QoS flows or bearer frameworks. Other examples of measurements reported by the WTRU may include RSRP, RSRQ, RSSI, SINR, or CSI.

[0135] In some aspects, in dashed box 1416, at 1418, in some implementations, the WTRU 1402 may receive scheduling downlink control information (DCI) comprising one or more scheduling parameters for DL reception via video layer-aware MCS-based processing, or for UL transmission via video layer-aware MCS-based processing.

[0136] At 1420 , the WTRU may perform DL reception through video layer-aware MCS-based processing according to the received RRC configuration and DCI scheduling information, and may process the received data at 1422 .

[0137] At 1424, the WTRU may process the UL data for transmission using video layer-aware MCS-based processing based on the received RRC configuration and DCI scheduling information, and at 1426, may perform UL transmission of the processed data.

[0138] In some other aspects, in dashed box 1428, at 1430, the WTRU may receive DCI that schedules uplink transmissions but does not schedule downlink receptions. Specifically, in some implementations, the WTRU receives DCI that includes one or more scheduling parameters for an UL transmission that utilizes video layer-aware MCS-based processing. At 1432, the WTRU may process the UL data for transmission using video layer-aware MCS-based processing based on the received RRC configuration and DCI scheduling information, and at 1434, the WTRU may perform an UL transmission of the processed data.

[0139] In some implementations, the WTRU provides feedback to the scheduler at 1436. The feedback may include additional measurements to support scheduling information, HARQ feedback, a WTRU suggestion for per-video layer MCS selection for subsequent DL scheduling or uplink scheduling, a WTRU suggestion for switching to a single constellation-based approach, a separate constellation-based approach, or a hybrid constellation-based approach, or any combination of these or other information or measurements.

[0140] and Figure 14A similar, Figure 14B is a sequence diagram illustrating an overview of video layer-aware scheduling between network entities, such as a UE or WTRU 1402 and a gNB, RSU, or scheduling entity 1404, according to another exemplary embodiment. Similar to 1408, at 1450, the WTRU may send an indication of its video layer processing capabilities to a base station or other network device, including its ability to distinguish between different video layers belonging to the same QoS flow; its ability to differentially process different video layers belonging to the same QoS flow; and / or its ability to create a layered modulation constellation.

[0141] At 1452, a base station or other network device may send and the WTRU may receive a modulation configuration. In some embodiments, the configuration may include one or more configured modulation schemes for layered video coding transmission. In some embodiments, the configuration may include one or more layered modulation configuration parameters. In some embodiments, the configuration may include both one or more configured modulation schemes and one or more layered modulation configuration parameters. The WTRU may receive the configuration information and configure the codec accordingly.

[0142] At 1454, in some embodiments, the WTRU may perform one or more radio-related and / or layer-specific measurements, and / or may send such measurements or channel characteristic identifiers to a base station or other network device. The measurement results or identifiers may be provided via one or more management reports or quality reports, or via header fields or payloads of other data packets. In some embodiments, the measurements may include one or more of RSSI, RSRP, RSRQ, SINR, or CSI measurements. In some embodiments, the measurements may include one or more layer-specific BSRs. In some embodiments, the measurements may include one or more BSRs indicating the amount of data for each video layer. In some embodiments, the measurements may include one or more channel time variation indicators. In some embodiments, the measurements may include one or more channel frequency selectivity indicators. In some embodiments, the measurements may include any combination of the above measurements and / or any other type and form of measurements.

[0143] At 1456, in some embodiments, in response to the reported measurement results, the base station or network device may generate and send dynamic scheduling information and / or modulation scheme updates to the WTRU. In some embodiments, the dynamic scheduling information may include one or more resource allocations. In some embodiments, the dynamic scheduling information may include an indication of one or more HARQ redundancy versions (RVs). In some embodiments, the dynamic scheduling information may include one or more MCS configurations. In some embodiments, the dynamic scheduling information may include any combination of the above or other such information. In some embodiments, the modulation scheme update may include activating or deactivating a particular layered modulation scheme (e.g., a bit allocation or a joint bit and distance allocation). In some embodiments, the modulation scheme update may include one or more layered modulation configuration parameters. In some embodiments, the layered modulation configuration parameters may include one or more layered modulation schemes. In some embodiments, the layered modulation configuration parameters may include one or more bounds or parameters for bit allocations for different video layers (e.g., 4 bits for a first base layer, 2 bits for an enhancement layer, 2 bits for a second enhancement layer, etc.). In some embodiments, the layered modulation configuration parameters may include a minimum distance between constellation points carrying different base layer / enhancement layer symbols. In some embodiments, the modulation scheme update may include any combination of the above updates or other such configuration information.

[0144] At 1458, in some embodiments, the WTRU may encode the bitstreams for the different video layers. For example, the WTRU may capture video for transmission (e.g., via the WTRU's camera or via another device), or may receive a video stream for transmission from an application, another device, etc. The WTRU may encode the bitstream using any suitable coding scheme and may perform any other required processing (e.g., compression, upsampling or downsampling, color adjustment, etc.).

[0145] At 1460, in some embodiments, the WTRU may determine the number of bits and constellation distance allocation for each video layer. The number of bits and / or constellation distance may be determined based on the configuration parameters received from the base station or other network device at 1456. The WTRU may also construct a hierarchical constellation diagram. Although referred to and described in terms of a constellation diagram, in some implementations, the WTRU may construct the hierarchical constellation as a data array, a data string, an index of constellation points assigned to each layer, or any other suitable type and form of data structure.

[0146] At 1462, in some embodiments, the WTRU may determine or identify a modulation constellation symbol from the layered constellation based on the determined bit allocation and / or distance allocation. In various implementations, this determination may be performed for each video layer in parallel or serially (e.g., iteratively for the base layer, then for the enhancement layer, etc.).

[0147] At 1464, in some embodiments, the WTRU may multiplex the determined or identified bits of the different layers onto the determined modulation constellation symbol for transmission. As discussed in more detail below, the multiple bits allocated to each video layer (e.g., base layer and enhancement layer) may be concatenated based on the modulation configuration and the determined modulation constellation symbol. This symbol may be transmitted or broadcast to a base station and / or other network devices or the WTRU.

[0148] At 1466, in some embodiments, the WTRU may send feedback information to the base station or other network device. The feedback information may include its bit and distance allocation (e.g., as determined at 1460). In some embodiments, the feedback information may be transmitted via a PUCCH transmission. In other embodiments, the feedback information may be multiplexed with the modulated video symbols and transmitted via the PUSCH. In some embodiments, when channel conditions or characteristics change, the WTRU may send additional radio-related and / or layer-specific measurements, as shown at 1454, to allow for dynamic reconfiguration of the modulation scheme and / or scheduling as needed.

[0149] In various embodiments, differentiated processing of video traffic can include, in one embodiment, the protocol stack physical layer can be capable of identifying data belonging to different video layers and applying differentiated processing to each video layer, such as between the video base layer and each video enhancement layer at various PHY processing stages. Subsequently, the protocol stack physical layer can also be capable of transmitting different video layers simultaneously.

[0150] In one example, video data or a bitstream may be divided into data blocks, where each data block may have one or more of the following characteristics: (1) a video frame to which the data block belongs; (2) a video layer to which the data block belongs; and / or (3) a video GOP to which the data block belongs.

[0151] It should be noted that although the UEP of various embodiments is expressed in terms of differential processing of video layers, it is also applicable to differential processing of video data blocks, where the data blocks may have one or more characteristics: the video frame to which the data block belongs, the video layer to which the data block belongs, or the GOP to which the video data block belongs.

[0152] In various embodiments, differencing can be applied to video frames, or a combination of video frames and video layers. For example, embodiments can use differencing for video layers within a video frame or for video layers across video frames. Although embodiments are described with respect to a video base layer and a video enhancement layer, various embodiments are equally applicable to use cases where there is a video base layer and two or more video enhancement layers.

[0153] Embodiments for modulation constellation allocation to the video layer will now be described.In certain embodiments, applying different modulation and coding schemes may be an exemplary method to differentiate video layers at a UE, base station, or any other control or scheduling entity.

[0154] Some exemplary modulation constellation allocation schemes are described below, although other schemes may also be used. Three examples of differentiating video layers based on modulation constellation allocation include: (i) a single-root constellation-based scheme; (ii) a scheme based on independent or multiple-root constellations; and / or (iii) a hybrid constellation scheme.

[0155] In one example, a root constellation may be defined and configured in the WTRU based on the WTRU's maximum modulation order, which defines the possible modulation constellation points. In a single root constellation approach, the modulation constellations applied to each video layer are derived from the same root constellation, for example, based on the minimum distance between the modulation constellation points specific to the video layer and the number of bits allocated to the modulation symbol in the bit set, such as Figure 15As shown. In addition, constellations can be assigned to each video enhancement layer in a hierarchical manner. For example, assuming a video has a video base layer BL and video enhancement layers L1 and L2, the modulation constellation of video layer L1 may be derived from the modulation constellation of video BL, while the modulation constellation of video layer L2 may be derived from the modulation constellation of video enhancement layer L1. As used herein, the terms hierarchical modulation and single constellation scheme / diagram are used interchangeably.

[0156] In another embodiment, referred to as an independent root constellation scheme, the modulation constellation applied to each video layer may be derived from two or more root constellations. For example, in this embodiment, the scheduler may use different sets of constellations for different video layers. In yet another embodiment, the different video layers may be grouped into subgroups of video layers. The scheduler uses the same constellation for video layers within the same subgroup and different constellations for video layers in different subgroups.

[0157] In an embodiment referred to as a hybrid constellation scheme, a combination of a single root constellation scheme and an independent root constellation scheme can be applied. For example, a first root constellation is assigned to a video base layer and a second root constellation is assigned to an enhancement layer, wherein a modulation constellation is assigned to each video enhancement layer using the second root constellation using a single root constellation scheme. In this example, assuming that one or more video enhancement layers can be distinguished, a second root constellation is assigned to the first video enhancement layer, and one or more modulation constellations of the remaining one or more video enhancement layers are derived from the second root constellation in a layered manner following the single root constellation scheme. For example, assuming that the video data is structured as a video base layer BL and video enhancement layers L1, L2, and L3, the first root constellation can be assigned to the video base layer BL, the second root constellation is assigned to the video enhancement layer L1, the modulation constellation of video layer L2 can be derived from the second root constellation, and the modulation constellation of video layer L3 can be derived from the modulation constellation of video enhancement layer L2. Various combinations and alternatives can also be applied. Thus, in some implementations, the mapping or grouping may follow a hierarchy or form a layered constellation, where packets from a first set are mapped to a first constellation subset or a root constellation, and packets from a second set are mapped to a second constellation subset or a constellation derived from the root constellation, the second constellation subset being a child or subset of the first constellation or otherwise created or determined based on the first constellation.

[0158] Hereinafter, the terms hierarchical modulation and single constellation scheme / diagram may be used interchangeably. Furthermore, the terms single-root constellation-based scheme and single-constellation-based scheme, or simply single-constellation scheme, may be used interchangeably. Similarly, the terms independent-root-constellation-based scheme, multi-root-constellation-based scheme, independent-constellation-based scheme, multi-constellation-based scheme, or simply multi-root-constellation scheme or independent-constellation scheme may be used interchangeably.

[0159] An embodiment of UEP-based PHY operation for using layered modulation-based UEP will now be described. This embodiment focuses on how to apply the layered modulation-based UEP scheme based on reported WTRU capabilities, channel conditions, scheduling constraints, and other system considerations.

[0160] Modulation-based UEP is used herein to distinguish different video layers by using different modulations based on their importance. For example, the bitstream from a high-importance video layer (i.e., video BL) may be modulated using a low modulation order, while the bitstream from a low-importance video layer (i.e., video EL) may be modulated using a high modulation order. The BS may decide to utilize this scheme based on the capabilities reported by the WTRU to the BS. The WTRU may then receive a configuration from the BS (e.g., via RRC signaling) indicating the modulation-based UEP scheme used to modulate transmit data or demodulate receive data.

[0161] Hierarchical modulation schemes can be applied within a single constellation framework. Figure 15 , shows an overview of a single constellation diagram, where the device's modulator 1506 uses hierarchical quadrature amplitude modulation (HQAM) to map different bitstreams from different video layers to specific bits in the constellation diagram. More specifically, the bitstream from the video BL 1502 is assigned to the most significant bit (MSB) in the constellation diagram, while the bitstream from the video EL 1504 is assigned to the least significant bit (LSB). As used herein, a constellation diagram may be referred to as a constellation set, which may include constellation subsets. Each constellation subset may include one or more constellation points. Furthermore, the terms constellation region and constellation subset may be used interchangeably.

[0162] The WTRU may receive the modulation scheme to be used from the BS or eNB via RRC signaling. If the configuration received by the WTRU includes multiple modulation schemes, the configuration may also include whether the modulation scheme is activated or deactivated. The WTRU may receive activation or deactivation commands for modulation schemes previously configured into the WTRU via RRC signaling via MAC CE, DCI, or SCI signaling.

[0163] To implement some of the embodiments described herein, the WTRU may receive UL / DL scheduling parameters from the BS, which it uses to provide differentiated PHY-based processing for different video layers based on the different modulation and coding schemes applied to the different video layers. In one example, the WTRU may receive one or more scheduling parameters for DL data reception from the BS via a DCI message supporting dynamic or semi-persistent scheduling. Similarly, the WTRU may receive one or more scheduling parameters for UL data transmission via a DCI message supporting one or more dynamic scheduling, or via RRC signaling. Certain embodiments focus on the implementation of differentiated processing for the video layer, i.e., the WTRU is able to receive differentiated configured modulation and coding scheme parameters for a video base layer or one or more video enhancement layers, and the WTRU is able to process the video base layer and one or more video enhancement layers differently, for example, by mapping modulation symbols to one or more different time-frequency resources (Res), modulation modes, or coding schemes based on the video layer to which the modulation symbols are allocated.

[0164] In one embodiment, a single constellation may be used for both video layers. In the single constellation embodiment, differentiated error protection between the various video layers may be achieved by applying the following aspects: (i) the number of bits allocated to the video BL and the video EL; and / or (ii) the level of protection provided to each layer by the distance between the constellation regions.

[0165] For example, the scheduler can change the minimum distance between constellation regions with different MSB values (called Figure 15 The protection level provided to the video BL bits is controlled by changing the distance d_2 ( Figure 15 As shown in FIG. 1 , i.e., the distance between constellation points within a region with the same video BL information, may change the protection provided to the LSBs of the video EL data. Thus, two (or more) modulation schemes based on a single constellation may be configured in the WTRU, for example, Figure 16 The bit allocation based scheme and Figure 17 The joint bit and distance allocation scheme shown.

[0166] An exemplary embodiment may define the mapping of video enhancement layer bits based on the mapping of video base layer bits. In differential mapping, a given symbol is mapped based on the information bit (its representation) and the previous symbol. Embodiments of the present invention may map video enhancement layer bits in a differential manner, where video enhancement layer bits (sub-symbols) are mapped based on the mapping of video enhancement layer bits to video base layer bits. For higher order modulation, this approach may provide additional tools to control UEP performance and improve the performance of video enhancement layer decoding.

[0167] A variant embodiment of a single constellation scheme can be applied to one video BL and multiple videos EL. For example, Figure 15 Each constellation area in the [ ] can contain multiple video ELs. In this case, as the priority of a video EL increases, the bits allocated to that video EL increase in order. For example, the lowest-priority video EL can be assigned a certain number of LSBs, while another higher-priority video EL can be assigned a certain number of bits following the LSBs assigned to the lowest-priority video EL. Furthermore, the minimum distance between each video EL constellation point can be varied based on the level of protection to be provided for that video layer.

[0168] Figure 17 Figure 17 is an example representation where a video stream is encoded as a video base layer and a video enhancement layer, referred to as Video BL 1702 and Video EL1 1704. In this example diagram, a 64-QAM constellation is used to provide the UEP for both video layers. Both layers in this example use 2 bits per constellation symbol. At the top, the diagram illustrates that the two MSBs are used to encode the two bits from Video BL and the two LSBs are used to transmit Video EL2. From a WTRU processing perspective, the WTRU will first decode the Video BL - shown as symbol detection on the green diamond symbol 1706. This is shown on the left side of the diagram. Once the Video BL decoding is complete, the WTRU will process the Video EL1 bits in the two LSB bits of the constellation symbol at 1708. Detecting the Video EL1 bits translates to detecting the red diamond symbol in the center of this diagram.

[0169] The WTRU may receive one or more modulation schemes based on a single constellation through dynamic signaling or semi-statically via RRC signaling. The activation or deactivation command of the modulation scheme configured through RRC signaling may be done through, for example, MAC CE, DCI or SCI signaling.

[0170] Based on the differentiated treatment provided for different video layers based on the number of bits allocated to each video layer and the level of protection provided, the WTRU should receive additional parameter sets to be able to separate the received video BL and video EL bitstreams. In one embodiment, the WTRU uses the received parameters to adjust the mapping between modulation symbols and time-frequency resources. Similarly, the WTRU uses the received parameters to identify the appropriate modulation order and code rate for signal transmission / reception.

[0171] The parameters that the WTRU should receive from the BS to implement the single constellation based UEP framework mainly depend on the applied single constellation based solution, as shown in Table 2 below:

[0172]

[0173] Table 2. Modulation-based parameters received by the UE under a single constellation modulation scheme

[0174] In an exemplary embodiment, modulation-based parameters received by a WTRU are discussed. In an exemplary embodiment, the WTRU may use one of different defined MCS tables to determine the modulation order and coding rate based on the received MCS index. In one example, the WTRU may determine the table from which it identifies the modulation and coding scheme based on received RRC signaling, the received DCI format, and the RNTI used to scramble the CRC appended to the received DCI.

[0175] For embodiments using semi-static bit allocation, there should be a table available at both the BS and the WTRU that defines the different possible numbers of bits to allocate to one of the video layers (i.e., video BL) at different modulation orders. The WTRU accordingly receives configuration parameters for differentiated handling of the video layers.

[0176] For embodiments using semi-static joint bit and distance allocation, there should be a table available at both the WTRU and the BS that defines the different combinations of bit allocation and distance allocation for each modulation order. The WTRU accordingly receives configuration parameters for video layer differential processing.

[0177] For embodiments using a bit allocation scheme, the WTRU may be configured with any number of bits for each video layer that is less than the configured modulation order. The WTRU accordingly receives configuration parameters for differentiated processing of the video layers.

[0178] For embodiments using joint bit and distance allocation, the number of bits received by the WTRU for each video layer should be a multiple of 2 in order to be able to construct a new constellation set (HQAM-based constellation set). The WTRU accordingly receives configuration parameters for differentiated processing of the video layer.

[0179] According to an exemplary embodiment, the WTRU may receive the above parameters: (i) as part of a DCI message prior to a DL transmission of a PDSCH under dynamic and semi-persistent scheduling; (ii) as part of a DCI message granting an UL transmission of a PUSCH under dynamic scheduling and CS type 2; and / or (iii) as part of RRC signaling granting an UL transmission of a PUSCH under CS type 1.

[0180] refer to Figure 18 , describes a method for a WTRU to communicate using a single constellation UEP framework during DL transmission. For example, a WTRU may perform one or more of the following actions to process a PDSCH containing two video layer data within an allocated time slot for DL reception.

[0181] In some implementations, at 1802, based on RRC signaling and activation / deactivation of different UEP-based modulation schemes received, possibly via DCI messages, MAC CEs, or SCI signaling, the WTRU determines whether it is configured with a single constellation modulation scheme. If so, it proceeds with the following steps. Otherwise, at 1804, it performs other actions, which will be discussed later.

[0182] If a single constellation modulation scheme is configured, then in some implementations, at 1806, the WTRU uses the time-frequency resources received via the DCI message to detect DL symbols transmitted on the time-frequency resources allocated for DL reception.

[0183] At 1808, the WTRU identifies the received MCS index and determines from which table to select the index to identify the modulation order (M) and code rate to be used. As previously described, the WTRU has been (pre-)configured with an MCS configuration table (e.g., one or more MCS configuration lookup tables). The received MCS index points to an MCS configuration in the MCS configuration table. The MCS configuration to which the received MCS index points includes the modulation order (M) and code rate to be used.

[0184] At 1810, based on RRC signaling and activation / deactivation of different UEP-based modulation schemes, which may be received via DCI messages, MAC CEs, or SCI signaling, the WTRU determines whether it is configured with a bit allocation or a joint bit and distance allocation scheme. In addition, it may determine whether it is configured with dynamic or semi-static single constellation operation.

[0185] The WTRU determines the modulation order to be applied to the video BL and video EL to demodulate the received modulation symbols. The WTRU applies the single constellation option configured in the WTRU to demodulate the received PDSCH. The following describes the actions that the WTRU performs to demodulate the PDSCH signal received on the allocated time-frequency resources in a frequency-first, time-second manner for the different single constellation options considered.

[0186] If the WTRU is configured with bit allocation only, then at 1812, the WTRU identifies the received number of MSBs of the modulation symbol allocated to the BL (N_BL); and identifies the constellation set and constellation subset for the video base layer and the video enhancement layer using the minimum distance M,d_1 and N_BL. Note that in semi-static operation, the WTRU uses the received index to identify the number of allocated MSBs from the configured lookup table, as described in Table 2.

[0187] Otherwise, if the WTRU is configured with joint bit and distance allocation, then at 1814, the WTRU determines the number of received modulation symbol MSBs allocated to the BL (N BL) to understand the number of regions representing different video BL data The WTRU also determines the minimum distance d1 between constellation points (symbols) carrying different video BL bits and the minimum distance d2 between modulation constellation points carrying different video EL bits. BL , d1 and d2 create a constellation set based on HQAM. Specifically, the constellation set includes 2 M constellation points (constellation set), divided evenly into The WTRU uses the minimum distance d1 and N BL Identify the constellation subset of the video base layer. Then, Within each of the areas, the WTRU creates a Note that in the semi-static method, the WTRU uses the received index for the selected constellation to obtain the number of MSBs allocated to the video BL, the minimum distance between the video BL modulation symbols, and the minimum distance between the video EL modulation symbols.

[0188] At 1818, based on the identified modulation order M, the WTRU demodulates the received symbols using the constellation set corresponding to the modulation order. The WTRU then BL bits (identified in step 4) are allocated to video BL, and the remaining bits are allocated to video EL.

[0189] At 1820, the WTRU assembles the video BL bitstream obtained from the allocated time-frequency resources in a frequency-first, time-second manner to reconstruct the protocol stack physical layer (PHY) code blocks for the video BL. Similarly, the WTRU then reconstructs the protocol stack physical layer code blocks for the video EL.

[0190] At 1822 , the WTRU first decodes the protocol stack physical layer code blocks for the video BL based on the code rate determined at 1808 .

[0191] At 1824, the WTRU checks whether the PHY code block of video BL is decoded correctly. If not, at 1826, the WTRU discards the received protocol stack physical layer code block corresponding to video EL, and at 1828, the WTRU sends a negative acknowledgement (NACK) to the base station or serving node to request retransmission.

[0192] If the PHY code blocks of the video BL are correctly decoded, then at 1830, the WTRU decodes the PHY code blocks of the video EL based on the same code rate used to decode the video BL code blocks; and at 1832, the WTRU checks whether the PHY code blocks of the video EL are correctly decoded. If the PHY code blocks of the video EL are not correctly decoded, the WTRU may or may not require retransmission of the video EL based on its required QoS. If the WTRU requires retransmission of the video EL, then at 1834, the WTRU sends a NACK to the serving node or base station. If the WTRU does not require retransmission of the video EL or the video EL code blocks are correctly decoded, then at 1836, the WTRU sends an ACK to the serving node or base station, and at 1838, the WTRU concatenates the two correctly decoded code blocks of the video layer to construct a transport block to be transmitted to the upper layer of the protocol stack.

[0193] In some implementations, the WTRU may determine whether retransmission of the video EL is required based on its priority, importance (e.g., whether it is used to decode or predict other frames), QoS level, transmission characteristic measurements (e.g., received signal strength, noise or interference, bandwidth, latency, etc.), or any other type and form of factors or combination of factors.

[0194] refer to Figure 19 , describes a method for a WTRU to communicate using a single constellation UEP framework during UL transmission. For UL transmission, the WTRU may perform one or more of the following operations to process a PUSCH containing two video layer data within an allocated time slot for UL transmission.

[0195] In some implementations, the WTRU sends a buffer status report (BSR) to a base station (BS), access point, or other serving node via the PUSCH as part of a MAC CE at 1902. The sent BSR may be used to inform the BS of the amount of data the WTRU needs to send for each video layer.

[0196] At 1904, the WTRU may receive an UL grant and scheduling related parameters via a DCI message if dynamic scheduling or CS Type 2 is configured, or via RRC signaling if CS Type 1 is configured.

[0197] At 1906, the WTRU determines the code rate it will use to encode the Video BL and Video EL bitstreams by determining the received MCS index and the table from which the MCS index was selected. As previously described, the WTRU has been (pre-)configured with an MCS configuration table (e.g., one or more MCS configuration lookup tables). The received MCS index points to an MCS configuration in the MCS configuration table. The MCS configuration to which the received MCS index points includes the code rate to be used by the WTRU.

[0198] At 1908, the WTRU encodes the video BL bitstream and the video EL bitstream using the code rate it determined at 1906 to generate a coded PHY code block for the video BL code block and a coded PHY code block for the video EL.

[0199] At 1910, before performing modulation, the WTRU may identify which modulation scheme it will apply to modulate the bitstream of each video layer. To do this, based on RRC signaling and activation / deactivation of different UEP-based modulation schemes, which may be received through DCI messages, MAC CEs, or SCI signaling, the WTRU determines whether it is configured with a single constellation modulation scheme. If so, it proceeds to 1914. Otherwise, at 1912, it performs other actions, which will be discussed later.

[0200] At 1914, the WTRU identifies the received MCS index and determines from which table to select the MCS index to identify the modulation order (M) to use. As previously described, the WTRU has been (pre-)configured with an MCS configuration table (e.g., one or more MCS configuration lookup tables). The received MCS index points to an MCS configuration in the MCS configuration table. The MCS configuration to which the received MCS index points includes the modulation order M.

[0201] At 1916, based on RRC signaling and activation / deactivation of different UEP-based modulation schemes possibly received via DCI messages, MAC CEs, or SCI signaling, the WTRU determines whether it is configured with a bit allocation or a joint bit and distance allocation scheme. Additionally, it may determine whether it is configured with dynamic or semi-static single constellation-based operation.

[0202] The WTRU determines the modulation order it applies to the video BL and video EL. The WTRU applies the single constellation option configured therein to modulate the coded video BL and video EL code blocks. In the following, a method for the WTRU to modulate the PHY code blocks for the video BL and video EL is described.

[0203] If the WTRU is configured with bit allocation only, then at 1918, the WTRU identifies the number of MSBs (N) of the received modulation symbols allocated to the BL. BL ), and use the minimum distance M, d1 and N BL Constellation sets and constellation subsets for video base layer and video enhancement layer are identified.

[0204] If the WTRU is configured with joint bit and distance allocation, then at 1920, the WTRU identifies the number of MSBs (N) received that are allocated to the video BL. BL ), the minimum distance between constellation points carrying different video BL symbols (d1) and the minimum distance between constellation points carrying different EL symbols (d2).

[0205] At 1922, the WTRU can BL , d1 and d2 create a constellation set based on HQAM. Specifically, the constellation set includes 2 M constellation points (constellation set), divided evenly into The WTRU uses the minimum distance d1 and N BL Identify the constellation subset of the video base layer. Then, Within each of the areas, the WTRU creates a constellation points to identify the constellation subset for the enhancement layer. As described above, such a constellation including constellation subsets may be referred to as a layered constellation. At 1924, the WTRU combines N constellation points for the video BL. BL bits (identified at 1918 or 1920) and (MN) for video EL BL ) bits to create M bits, where the modulation symbol bit for BL is the MSB.

[0206] At 1926, the WTRU performs modulation by mapping the created M bits to corresponding constellation points.

[0207] At 1928, the WTRU determines the allocated time-frequency resources for PUSCH transmission based on the received parameters for time domain allocation and frequency domain allocation.

[0208] At 1930, the WTRU maps the modulated symbols to the time-frequency resources (identified at 1928) in a frequency-first, time-second manner.

[0209] The data mapped on the scheduled resources are then transmitted in the uplink direction.

[0210] The previous discussion focused on the use of application video data containing two video layers with different priorities to help explain the concept of UEP. In practice, a video stream is usually encoded into more than two video layers. Below, an exemplary embodiment is disclosed to illustrate a single constellation-based UEP for providing differentiated transmission processing (or reception) for three video layers.

[0211] Figure 20This is an example representation of a video stream encoded as a video base layer 2002 and two video enhancement layers, referred to as video EL1 2004 and video EL2 2006. In this example diagram, a 64-QAM constellation is used to provide UEP for these three video layers. All three layers in this example use two bits per constellation symbol. At the top, the legend shows that the two MSBs are used to encode two bits from the video base layer (BL), the next two bits (located in the middle of the symbol bits) are used to transmit two bits from video EL1, and the two LSBs are used to transmit video EL2. From a WTRU processing perspective, the WTRU will first decode the video base layer (BL), shown as symbol detection on the green diamond symbol 2008. This is shown on the left side of the diagram. After decoding the video base layer (BL), the WTRU will process the video EL1 in the two middle bits of the constellation symbol at 2010. Detecting the video EL1 bits translates to detecting the red diamond symbol in the middle of the diagram. After detecting the video EL1 bits, the WTRU can further zoom in to attempt to detect the two LSBs of video EL2, shown on the right side of the diagram at 2012.

[0212] In this UEP constellation diagram containing three video layers, the relative error probability is determined by the careful choice of the constellation parameters d1, d2 and d3. Additional control and adjustment of the relative error probability can be achieved by having additional constellation design parameters (such as the vertical distance and unequal spacing between constellation points).

[0213] Embodiments of dynamically adapting the UEP will now be discussed. The previous sections provided tools whereby different streams or video layers can be treated with different priorities at the protocol stack PHY layer, in particular by enabling the UEP on the modulation constellation. One issue is the dynamic adaptation of the UEP based on the intrinsic priority of the data content (video layer), device capabilities, and system aspects including scheduling decisions, available capacity, system load, and changing radio conditions.

[0214] In embodiments using dynamic UEP adaptation, measurements and feedback may be important. The following are measurements that can be used to dynamically adapt to different UEP schemes.

[0215] Channel Time Variation and Estimation for Feedback: A measure of how quickly channel radio conditions change over time can play an important role in the dynamic adaptation of UEP embodiments. This measurement may include an estimate of the rate of change of the channel phase, or it may be based solely on the channel amplitude, ignoring the phase. This measurement can be refined by taking the form of Doppler estimates between available channel estimates at different points in time. Additional conditions in terms of averaging and filtering can be defined to keep this quantity stable before it is fed back and used for dynamic adaptation.

[0216] For the DL direction, the device can estimate the rate of change of channel conditions by estimating on one or more existing reference signals (RS). These RSs can be the DMRS of the SSB, the DMRS of the data, the CSI-RS, or even the SSB itself. New, more suitable RSs can also be defined specifically for this purpose. These RSs can be WTRU-specific, group-common, or cell / beam-specific, which can allow the WTRU to estimate Doppler.

[0217] Once a suitable measure of channel time variation has been estimated, the WTRU should feed this amount back to the network so that it can be used in conjunction with other parameters / constraints for dynamic adaptation of the UEP. The indication of channel time variation may be transmitted in the form of a single bit flag that may indicate that the channel time variation is greater than a predefined or configured threshold. In an alternative embodiment, the network may configure the size / mode of the channel time variation feedback, which may be selected from multiple options defined for a given network. A subset of these options may be indicated to the WTRU as part of a semi-static configuration. The estimated channel time variation indication, after appropriate processing / filtering, may be provided as feedback to the network, for example as part of uplink control information (UCI). In one embodiment, the UCI carrying the channel time variation indication may be transmitted in the PUCCH or PUSCH. The channel time variation feedback may be configured to be periodic, semi-static, or aperiodic. The network may configure appropriate parameters that control the periodicity of this feedback.

[0218] Furthermore, channel frequency selectivity estimation and feedback may be required. Channel variation in the frequency domain, or channel frequency selectivity, may be another important parameter for judiciously selecting UEP implementations to combat frequency selectivity and avoid deep fades affecting prioritized video layers / data. In one embodiment, the measured quantity may involve including an estimate of the rate of change of the channel phase, or it may be based solely on the channel amplitude, ignoring the phase. Additional conditions in terms of averaging and filtering may be defined to ensure that the quantity remains stable before being fed back and used for dynamic adaptation.

[0219] For the DL direction, the device can estimate channel frequency selectivity by performing multiple channel estimates over different portions of the bandwidth. These estimates can be performed using a suitable RS or combination of RSs, examples of which include the DMRS for the SSB, the DMRS for data, the CSI-RS, or even the SSB itself. New RSs can also be defined specifically for this purpose. These RSs can be WTRU-specific, group-common, or cell / beam-specific, potentially allowing the WTRU to estimate the channel over different frequency portions. In one embodiment, DMRS Type 1 and Type 2 are suitable for estimating channel frequency selectivity because they span all physical resource blocks (PRBs) in the scheduled resources. Similarly, many existing CSI-RS patterns can be used to estimate channel frequency selectivity. Once a suitable metric for channel frequency selectivity is estimated, the WTRU should feed this quantity back to the network so that it can be combined with other parameters / constraints for dynamic adaptation of the UEP. Various options can be defined regarding how averaging, filtering, or some requirement for a minimum number of measurements to be averaged before feeding this quantity back to the network. In one example, the indication of channel frequency selectivity can be transmitted in the form of a single-bit flag that can indicate that the channel frequency selectivity is greater than a predefined or configured threshold.

[0220] In some embodiments, the network may configure the size / mode of the channel frequency selectivity feedback, which may be selected from several options defined in the specification. A subset of these options may be indicated to the WTRU as part of a semi-static configuration. The estimated channel frequency selectivity indication, after appropriate processing / filtering, may be provided as feedback to the network as part of the uplink control information (UCI). The UCI carrying the channel frequency selectivity indication may be transmitted in the PUCCH or PUSCH. The channel frequency selectivity feedback may be configured to be periodic, semi-static, or aperiodic, and the network may configure appropriate parameters that control the periodicity of this feedback.

[0221] The previous discussion provides some quantities that the WTRU can estimate / measure and report to the network in a suitable format. In compatible embodiments, the WTRU may directly request specific parameters for the constellation and video layer mappings it desires to use. In one example, these may be the expected reception parameters it desires to use for receiving DL layered video. For the UL case, the requested parameters may be the parameters the WTRU desires to use for transmitting layered video in the uplink direction to the base station.

[0222] In certain embodiments, the indication of modulation-based UEP parameters may include constellation design parameters (eg, distance parameters), bit allocation for different video layers, and relative mapping of video layers as previously described.

[0223] Direct feedback on the requested modulation-based UEP can be transmitted in the uplink direction by transmitting the feedback to the base station as part of the uplink control information. This information can be transmitted as part of the PUCCH or PUSCH. In addition, the base station can configure this reporting to be periodic, semi-static or aperiodic. To cover dynamic embodiments, this reporting can be event-triggered, where a suitable trigger can be defined to report this feedback. An example of a suitable trigger can be a channel variation in time or frequency exceeding a configured threshold. Upon receiving a direct request for modulation-based UEP parameters, the base station can use this feedback, radio measurement feedback (if available) and other system considerations to adjust the UEP parameters for subsequent transmissions.

[0224] An embodiment of dynamic adaptation for single constellation differentiation may involve allocating and splitting available resources / capacity / bits for different video layers with different priorities. Variable factors such as traffic flow (video layer), various system design considerations, WTRU capabilities, and some long-term channel characteristics of the associated WTRUs may be used to dynamically allocate different resources or priorities to different video layers in a UEP solution.

[0225] To fully utilize available resources for multi-layer video transmission, the UEP embodiments discussed herein should utilize dynamic adjustments to cope with network dynamics, which may include changes in system load, the capacity of different cells as the WTRU moves, and changing radio conditions. Different measurement quantities have been previously determined, and the WTRU can estimate these quantities and report them to the network in a suitable format that reflects the current channel conditions.

[0226] As an example for a single constellation, if the channel time variation exceeds a certain threshold, the probability of the WTRU successfully decoding a given higher-order constellation decreases with the channel time variation because the quality of the channel estimate decreases in direct proportion to the channel time variation. The network may use the time variation indication to adjust the rate of the video base layer and one or more video enhancement layers. Another possibility may be to stop transmitting one of the video enhancement layers if the network estimates that the WTRU will not be able to decode it anyway. The network's decision on the updated bit allocation for dynamic splitting and transmitting a given number of video layers may be indicated to the WTRU through dynamic signaling.

[0227] Previous embodiments have identified how the transmitting device can dynamically update layered video parameters, the allocation of different video layer bits to constellation bits, and the bit size of each video layer for a given constellation. In another embodiment, the constellation design parameters themselves can be updated to achieve a more appropriate constellation form based on system considerations, WTRU capabilities, feedback from the receiver regarding channel variations, and so on. For example, the previously discussed constellation design parameters d1, d2, and d3 can be updated relative to the available information elements. The updates to the constellation design parameters result in changes in the expected detection probabilities for different video layers. Therefore, when design considerations change, such changes can provide a basis for achieving a given prioritization of different video layers.

[0228] In another example, the constellation may be set to switch from a single-root constellation to a multi-root constellation, or a multi-root constellation may be updated to another multi-root constellation with different parameters.

[0229] In yet another compatible design, the mapping of different video layers to constellations may be updated, eg, updating the mapping of a given video enhancement layer based on detected bits (sub-symbols) corresponding to the video base layer.

[0230] In various other embodiments, dynamic switching of UEP configurations can be performed without feedback. For modulation-based UEP embodiments, one configuration can build a layered modulation constellation for the transmission / reception of layered video, while another configuration can lay the foundation for a modulation constellation design specific to the video layer. For example, a base station can provide relevant configurations for a layered constellation and a separate video layer-specific constellation, while providing an indication of the active configuration. This configuration can then be used for the transmission of UL or DL layered video data. Given changing requirements, channel conditions, and system considerations, the network can switch the active configuration. The signaling for switching the active configuration can be sent through semi-static signaling, or in a more dynamic manner by indicating it in the DCI. This can be easily implemented by providing a single bit flag indicating the active configuration.

[0231] In another compatible design, the WTRU may request the base station to switch the active configuration for layered video transmission / reception. This configuration switch request may be sent to the base station in the uplink direction. An example of signaling to achieve this is to include this active configuration indication in the UEP feedback.

[0232] Figure 21An exemplary embodiment for UEP layered video transmission based on a single constellation in the DL direction is shown. In this embodiment, a WTRU may report its capabilities and assistance information to a base station (BS), access point, gNB, or serving node (collectively, BS or serving node) at 2102. In response, the BS or serving node provides a UEP configuration based on a single layered constellation for layered video transmission at 2104. This configuration provides parameters specific to the video layer, including bit size, constellation part, distance, and bit mapping for the constellation. The configuration may indicate dynamic update options for a subset of these parameters. In one example, the scheduling DCI provides time-frequency resources and may complete the constellation design information. In one design, the configuration provides a set of parameters, which are later completed by dynamic indications. In another compatible design, the configuration may provide a set of parameters, such as those related to constellation selection and construction with an appropriate distance, some of which may then be overridden by dynamic indications. The UEP parameter overriding as part of the dynamic indication at 2106 enables the network to respond to dynamic traffic flow changes, network system load changes, and channel variations. After decoding the DCI, the WTRU receives scheduling data from the indicated time-frequency resources at 2108. At 2110, the WTRU also prepares a constellation for receiving the video layer using information received from the BS or serving node. At 2112, the WTRU demodulates the video base layer and then uses the relevant portion of the layered constellation to demodulate the video enhancement layer at 2114. After demodulation, the WTRU continues channel decoding the demodulated video layer at 2116. At 2118, the WTRU prepares UEP feedback, which may request the BS or serving node to provide a specific target constellation set for the next transmission. The UEP feedback may also include an indication of channel time and frequency variations to allow for appropriate UEP processing / scheduling for subsequent transmissions. These estimates may be prepared on reference symbols that are part of the scheduled resources, or the BS or serving node may transmit dedicated reference symbols for such estimates. The WTRU transmits the UEP feedback in the uplink direction at 2120.

[0233] refer to Figure 22, illustrates a method for a WTRU to communicate in a wireless network using uplink layered video transmission using a single-constellation UEP. In this embodiment, at 2202, the WTRU may report its capabilities and assistance information to the BS or serving node. In response, at 2204, the BS or serving node provides a single-constellation UEP configuration for layered video transmission in the UL direction. This configuration provides parameters for the video layer-specific mapping on the layered constellation, distances, and bit mapping rules for the single constellation. The configuration may indicate a dynamic update option for a subset of these parameters. The scheduling DCI provides the UL time-frequency resources and may complete the constellation design information at 2206 by providing any missing elements in the RRC configuration or updating certain elements configured in the RRC configuration. After decoding the DCI, the WTRU performs channel coding for the different video layers at 2208 and then multiplexes the layered coded bits according to the configuration at 2210. At 2212, the WTRU may prepare the indicated constellation for the video layer to be transmitted. Then, at 2214, the WTRU modulates the multiplexed video layer data onto the constellation. The WTRU then transmits the UEP modulated layered video data on the scheduled UL time-frequency resources at 2216.

[0234] Figure 23 An exemplary embodiment of a method for a WTRU to communicate in a wireless network using UEP layered video transmission based on a single constellation in the UL direction and providing feedback to a base station in the UL direction is illustrated. In this embodiment, at 2302, the WTRU may report its capabilities and assistance information to the base station or serving node. In response, at 2304, the base station or serving node provides a UEP configuration based on a single constellation for layered video transmission in the UL direction. This configuration provides parameters for the video layer-specific mapping on the layered constellation, distances, and bit mapping rules for the single constellation. The configuration may indicate a dynamic update option for a subset of these parameters. At 2306, the scheduling DCI provides the UL time-frequency resources and may complete the constellation design information by providing missing elements in the RRC configuration or updating certain elements configured in the RRC configuration. After decoding the DCI, at 2308, the WTRU performs channel coding for the different video layers and then multiplexes the layered video coding bits according to the configuration at 2310. At 2312, the WTRU prepares the indicated constellation for the video layer to be transmitted. At 2314, the WTRU may modulate the multiplexed layered video data onto a constellation. At 2316, the WTRU may prepare WTRU feedback, which may include a target constellation for subsequent transmission and may additionally indicate video layer-specific mapping and constellation design parameters. The WTRU may then multiplex the UEP feedback with the layered video data at 2318. At 2320, the WTRU may transmit the multiplexed UEP feedback and layered video data on the scheduled UL time-frequency resources.

[0235] In some aspects, the present disclosure relates to a method that includes determining, by a wireless transmit / receive unit (WTRU), a first number of bits for a first media packet and a second number of bits for a second media packet. The method also includes determining, by the WTRU, a modulation constellation symbol based on the determined first number of bits and the second number of bits. The method also includes multiplexing, by the WTRU, the first number of bits of the first media packet and the second number of bits of the second media packet onto the determined modulation constellation symbol for transmission. The method also includes sending, by the WTRU, feedback information to a network device, the feedback information including an identification of the first number of bits and a first constellation distance, and the second number of bits and the second constellation distance.

[0236] In some implementations, the method includes transmitting, by the WTRU, a multiplexed modulation constellation symbol. In some implementations, the method includes identifying, by the WTRU, a first constellation subset based on a first number of bits and identifying a second constellation subset based on a second number of bits, wherein the first constellation subset and the second constellation subset constitute a layered constellation. In some implementations, the method includes determining, by the WTRU, a first constellation distance for a first media data packet and a second constellation distance for a second media data packet. In further implementations, determining the modulation constellation symbol is further based on the first constellation distance and the second constellation distance.

[0237] In some implementations, the method includes: reporting, by the WTRU, to a network device, an identification of the WTRU's ability to distinguish between different video layers; and receiving, by the WTRU, from the network device, a modulation configuration for transmitting the different video layers. In further implementations, the method includes reporting, by the WTRU, to a network node, one or more layer-specific buffer status reports.

[0238] In some implementations of the method, multiplexing the first number of bits of the first media packet and the second number of bits of the second media packet onto the determined modulation constellation symbol includes assigning the first number of bits of the first media packet to the first most significant bit of the modulation constellation symbol, and assigning the second number of bits of the second media packet to the second most significant bit of the modulation constellation symbol. In further implementations, the first most significant bit is more reliable than the second most significant bit. In some implementations, the first media packet includes base layer data of a video signal, and the second media packet includes enhancement layer data of the video signal.

[0239] In another aspect, the present disclosure relates to a wireless transmit / receive unit (WTRU). The WTRU includes one or more transceivers and one or more processors. The one or more processors are configured to: determine a first number of bits for a first media packet and a second number of bits for a second media packet; determine a modulation constellation symbol based on the determined first number of bits and the second number of bits; multiplex the first number of bits of the first media packet and the second number of bits of the second media packet onto the determined modulation constellation symbol for transmission; and send feedback information to a network device, the feedback information including an identification of the first number of bits and a first constellation distance, and the second number of bits and the second constellation distance.

[0240] In some implementations, the one or more processors are further configured to transmit the multiplexed modulation constellation symbol via the one or more transceivers. In some implementations, the one or more processors are further configured to identify a first constellation subset based on a first number of bits and to identify a second constellation subset based on a second number of bits, wherein the first constellation subset and the second constellation subset constitute a layered constellation. In some implementations, the one or more processors are further configured to determine a first constellation distance for the first media data packet and a second constellation distance for the second media data packet. In further implementations, the modulation constellation symbol is determined based on the first constellation distance and the second constellation distance.

[0241] In some implementations, the one or more processors are further configured to: report to a network device an identification of the WTRU's ability to distinguish between different video layers; and receive, from the network device, modulation configurations for transmitting different video layers. In further implementations, the one or more processors are further configured to report to the network node one or more layer-specific buffer status reports. In some implementations, the one or more processors are further configured to: assign a first number of bits of a first media packet to a first most significant bit of a modulation constellation symbol, and assign a second number of bits of a second media packet to a second most significant bit of the modulation constellation symbol. In further implementations, the first most significant bit is more reliable than the second most significant bit. In some implementations, the first media packet includes base layer data of a video signal, and the second media packet includes enhancement layer data of the video signal.

[0242] Although the technical features and elements are described above in specific combinations, it should be understood by those skilled in the art that each technical feature or element can be used alone or in any combination with other technical features and elements; in addition, the method described herein may be implemented by a computer program, software or firmware contained in a computer-readable medium for execution by a computer or processor, wherein the computer-readable medium includes electronic signals transmitted through a wired or wireless connection and a computer-readable storage medium, and the computer-readable storage medium includes but is not limited to read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as built-in hard disks and removable disks), magneto-optical media and optical media (such as CD-ROMs and digital versatile discs (DVDs)); the processor combined with the software can be used to implement a radio frequency transceiver used in a wireless transmit receive unit (WTRU), user equipment (UE), terminal, base station, radio network controller (RNC) or any host computer.

Claims

1. A method comprising: determining, by a wireless transmit / receive unit (WTRU), a first number of bits for a first media packet and a second number of bits for a second media packet; determining, by the WTRU, a modulation constellation symbol based on the determined first number of bits and the second number of bits; multiplexing, by the WTRU, the first number of bits of the first media data packet and the second number of bits of the second media data packet onto the determined modulation constellation symbols for transmission; and The WTRU sends feedback information to a network device, where the feedback information includes an identification of the first number of bits, the first constellation distance, the second number of bits, and the second constellation distance.

2. The method according to claim 1, further comprising: The multiplexed modulation constellation symbols are transmitted by the WTRU.

3. The method according to any one of claims 1 and 2, further comprising: A first constellation subset is identified by the WTRU based on the first number of bits, and a second constellation subset is identified based on the second number of bits, wherein the first constellation subset and the second constellation subset constitute a layered constellation.

4. The method according to any one of the preceding claims, further comprising: A first constellation distance for the first media data packet and a second constellation distance for the second media data packet are determined by the WTRU. The method according to claim 4 , wherein the determination of the modulation constellation symbol is further based on the first constellation distance and the second constellation distance.

6. The method according to any one of the preceding claims, further comprising: The WTRU reports, to the network device, an identifier of the WTRU's capability of distinguishing between different video layers; as well as A modulation configuration for transmitting the different video layers is received by the WTRU from the network device.

7. The method according to claim 6, further comprising: One or more layer-specific buffer status reports are reported by the WTRU to the network node.

8. The method of any preceding claim, wherein multiplexing the first number of bits of the first media data packet and the second number of bits of the second media data packet onto the determined modulation constellation symbols comprises: The first number of bits of the first media data packet is allocated to the first most significant bit of the modulation constellation symbol, and the second number of bits of the second media data packet is allocated to the second most significant bit of the modulation constellation symbol.

9. The method of claim 8, wherein the first most significant bit is more reliable than the second most significant bit.

10. The method according to any of the preceding claims, wherein the first media data packet comprises data of a base layer of a video signal, and wherein the second media data packet comprises data of an enhancement layer of the video signal.

11. A wireless transmit / receive unit (WTRU) comprising one or more transceivers and one or more processors; wherein the one or more processors are configured to: determining a first number of bits for a first media data packet and a second number of bits for a second media data packet; determining a modulation constellation symbol based on the determined first number of bits and the second number of bits; multiplexing the first number of bits of the first media data packet and the second number of bits of the second media data packet onto the determined modulation constellation symbols for transmission; and Feedback information is sent to a network device, where the feedback information includes identifiers of the first number of bits, the first constellation distance, the second number of bits, and the second constellation distance.

12. The WTRU of claim 11 , wherein the one or more processors are further configured to transmit the multiplexed modulation constellation symbols via the one or more transceivers.

13. The WTRU of any one of claims 11 and 12, wherein the one or more processors are further configured to: A first constellation subset is identified based on the first number of bits, and a second constellation subset is identified based on the second number of bits, wherein the first constellation subset and the second constellation subset constitute a layered constellation.

14. The WTRU of any one of claims 11 to 13, wherein the one or more processors are further configured to determine a first constellation distance for the first media data packet and a second constellation distance for the second media data packet.

15. The WTRU of claim 14, wherein determination of the modulation constellation symbol is further based on the first constellation distance and the second constellation distance.

16. The WTRU of any one of claims 11 to 15, wherein the one or more processors are further configured to: reporting to the network device an identification of the WTRU's ability to distinguish between different video layers; and A modulation configuration for transmitting the different video layers is received from the network device.

17. The WTRU of claim 16, wherein the one or more processors are further configured to report one or more layer-specific buffer status reports to the network node.

18. The WTRU of any one of claims 11 to 17, wherein the one or more processors are further configured to: The first number of bits of the first media data packet is allocated to the first most significant bit of the modulation constellation symbol, and the second number of bits of the second media data packet is allocated to the second most significant bit of the modulation constellation symbol.

19. The WTRU of claim 18, wherein the first most significant bit is more reliable than the second most significant bit.

20. The WTRU of any one of claims 11 to 19, wherein the first media data packet comprises data for a base layer of a video signal, and wherein the second media data packet comprises data for an enhancement layer of the video signal.

Images