Video codec-aware wireless access network architecture and unequal error protection coding

Abstract

An apparatus and method for video codec-aware RAN configuration and unequal error protection coding is disclosed. The apparatus includes a processor that detects a video coded traffic stream and a video codec specification used to encode the traffic stream, determines awareness of application data units of traffic of the video coded traffic stream as video coded network abstraction layer (NAL) units, aligns the NAL units to partitions of PHY transport elements and subsequent channel coding elements for video coded traffic aware PHY transport, determines allocation of channel coding rates of the partitions, and applies forward error correction coding taking into account the determined allocation of channel coding rates of the video coded traffic aware PHY transport to partitions of the channel coding elements.

Description

[Technical field]

[0001] The subject matter disclosed herein relates generally to wireless communications, and more particularly to video codec aware radio access network configurations and unequal error protection coding. [Background technology]

[0002] In wireless networks, emerging applications such as augmented reality ("AR") / virtual reality ("VR") / extended reality ("XR"), cloud gaming ("CG"), device tele-operation (e.g., vehicle tele-operation, robotic arm tele-operation, etc.), 3D video conferencing, smart distance learning, etc. are expected to drive the growth of video traffic. Even though the aforementioned applications may require different quantitative constraints and configurations in terms of rate, reliability, latency, and quality of service ("QoS"), such constraint sets are expected to challenge current and future communication networks in delivering high fidelity quality of experience ("QoE") at ever-increasing resolutions. As the quality of rendering end devices improves and their costs fall over time, such applications are expected to steadily spread and further raise the bar of QoE for end applications. Therefore, there is a high interest in providing scalable and reliable solutions from a communication network perspective for next generation media content distribution systems and their immersive digital reality applications. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] 3GPP Technical Report TR 26.928 (v16.0.0 - November 2020), 5G; Extended Reality (XR) in 5G [Non-Patent Document 2] S4-211210: [FS_XRTraffic]: Permanent document, v0.8.0, Reporter Qualcomm Inc. (2021) [Non-Patent Document 3] ITU-T Series H: Audiovisual and Multimedia Systems: Infrastructure of Audiovisual Services - Coding of Moving video, Advanced Video Coding for Generic Audiovisual Services (H.264) (v08 / 2021) [Non-Patent Document 4] ITU-T Series H: Audiovisual and Multimedia Systems: Infrastructure of Audiovisual Services - Coding of Moving video, High Efficiency Video Coding (H.265) (v08 / 2021) [Non-Patent Document 5] ITU-T Series H: Audiovisual and Multimedia Systems: Infrastructure of Audiovisual Services - Coding of Moving video, Versatile Video Coding (H.266) (v08 / 2020) [Non-Patent Document 6] de Rivaz, P. and Haughton, J., (2018), AV1 Bitstream & Decoding Process Specification, The Alliance for Open Media, 182, https: / / aomediacodec.github.io / av1-spec / av1-spec.pdf [Non-Patent Document 7] 3GPP Technical Specification TS 23.501 (V17.2.0 - September 2021), System architecture for the 5G System (5GS); Stage 2 (Release 17) [Non-Patent Document 8] 3GPP Technical Specification TS 26.244 (v 16.1.0 - October 2020), Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; 5G; Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP) (Release 16) [Non-Patent Document 9] 3GPP Technical Specification TS 38.212 (v16.5.0 - April 2021), 5G; NR; Multiplexing and channel coding [Non-Patent Document 10] 3GPP Technical Specification TS 38.214 (v16.5.0 - April 2021), 5G; NR; Physical layer procedures for data Summary of the Invention [Means for solving the problem]

[0004] Disclosed are procedures for video codec-aware Radio Access Network ("RAN") configuration and unequal error protection coding, which may be implemented by an apparatus, a system, a method, and / or a computer program product.

[0005] In one embodiment, a first apparatus includes a processor that detects a video encoded traffic stream and a video codec specification used to encode the video encoded traffic stream. In one embodiment, the processor determines awareness of video encoded traffic application data units ("ADUs") of the video encoded traffic stream as video encoded network abstraction layer ("NAL") units of data. In one embodiment, the processor aligns video encoded NAL units of the video encoded traffic stream to partitions of PHY transport elements and subsequent channel coding elements for video encoded traffic aware physical layer ("PHY") transport based at least on the determined awareness of the video encoded ADUs. In one embodiment, the processor determines channel coding rate allocations of partitions of channel coding elements based on the video encoded traffic aware PHY transport. In one embodiment, the processor applies forward error correction ("FEC") coding to protect against errors in the over-the-air transmission, taking into account at least an allocation of a determined channel coding rate of the video-coded traffic-aware PHY transport to a partition of the channel coding element.

[0006] In one embodiment, the first method includes detecting a video encoded traffic stream and a video codec specification used to encode the video encoded traffic stream. In one embodiment, the first method includes determining awareness of video encoded traffic ADUs of the video encoded traffic stream as video encoded NAL units of data. In one embodiment, the first method includes aligning video encoded NAL units of the video encoded traffic stream to partitions of PHY transport elements and subsequent channel coding elements for video encoded traffic aware PHY transport based at least on the determined awareness of the video encoded ADUs. In one embodiment, the first method includes determining an assignment of a channel coding rate of the partitions of the channel coding elements based on the video encoded traffic aware PHY transport. In one embodiment, the first method includes applying FEC coding at least taking into account the assignment of the determined channel coding rate of the video encoded traffic aware PHY transport to the partitions of the channel coding elements to protect against errors in the over the air transmission.

[0007] In one embodiment, the second device includes a transceiver that receives an indication of a variable length and / or variable code rate TB partition element aligned to the plurality of NAL units and receives the variable length and / or variable code rate TB partition element aligned to the NAL units. In one embodiment, the second device includes a processor that decodes FEC encoding of the plurality of video coded NAL unit data contained in the TB partition element and uses the received plurality of video coded NAL unit data to reconstruct and decode the transmitted video coded stream for video playback.

[0008] In one embodiment, the second method includes receiving an indication of a variable length and / or variable code rate TB partition element aligned to the plurality of NAL units, and receiving the variable length and / or variable code rate TB partition element aligned to the NAL units. In one embodiment, the second method includes decoding an FEC encoding of the plurality of video coded NAL unit data contained in the TB partition element, and using the received plurality of video coded NAL unit data to reconstruct and decode the transmitted video coded stream for video playback.

[0009] A more particular description of the embodiments briefly described above will be made by reference to specific embodiments illustrated in the accompanying drawings, in which the embodiments will be described and explained with more specificity and detail, with the understanding that these drawings illustrate only some embodiments and therefore should not be considered limiting in scope. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a schematic block diagram illustrating an embodiment of a wireless communication system for video codec-aware RAN configuration and unequal error protection coding. [Diagram 2] FIG. 1 illustrates an embodiment of a split-rendering architecture for a mobile network based on an edge / cloud video application server and an XR UE device. [Diagram 3] FIG. 1 illustrates a simplified block diagram embodiment of a generic video codec that performs both spatial and temporal (motion) compression of a video source. [Figure 4] FIG. 1 illustrates one embodiment of an overview of a communications system architecture. [Diagram 5]FIG. 2 illustrates an embodiment of a video coded elementary stream and its partitioning in multiple NAL units. [Figure 6] A diagram illustrating an embodiment of RAN awareness configuration of video encoded NAL data / ADU and associated importance. [Figure 7] FIG. 1 illustrates an embodiment of a packet-oriented schematic diagram of RAN level processing without traffic content awareness. [Figure 8] FIG. 1 illustrates an embodiment showing a mapping of video frames to variable length video codec NAL unit aware coding partitions of a PHY transport block. [Figure 9] FIG. 13 illustrates an embodiment showing FEC with UEP of TB with two different FEC coding rates R1 < R2, where a lower FEC coding rate R1 is assigned to the CBG / mTB aligned with NAL unit data considered to be more important, and a higher FEC coding rate R2 is assigned to the CBG / mTB aligned with NAL unit data considered to be less important. [Figure 10] FIG. 2 is a block diagram illustrating an embodiment of a user equipment device that may be used for video codec-aware RAN configuration and unequal error protection coding. [Figure 11] FIG. 2 is a block diagram illustrating an embodiment of a network device that may be used for video codec-aware RAN configuration and unequal error protection coding. [Figure 12] 1 is a flow diagram illustrating one embodiment of a method for video codec-aware RAN configuration and unequal error protection coding. [Figure 13] 1 is a flow diagram illustrating an embodiment of another method for video codec-aware RAN configuration and unequal error protection coding. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] As will be appreciated by one skilled in the art, aspects of the embodiments may be embodied as a system, apparatus, method, or program product. Accordingly, the embodiments may take the form of an all-hardware embodiment, an all-software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects.

[0012] For example, the disclosed embodiments may be implemented as a hardware circuit comprising custom very large scale integrated ("VLSI") circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, etc. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code which may be organized, for example, as an object, procedure, or function.

[0013] Furthermore, embodiments may take the form of a program product embodied in one or more computer readable storage devices storing machine readable code, hereinafter referred to as code, computer readable code, and / or program code. The storage devices may be tangible, non-transitory, and / or non-transmitting. The storage devices may not embody signals. In certain embodiments, the storage devices employ only signals to access the code.

[0014] Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device that stores the code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micro-mechanical, or semiconductor system, apparatus, or device, or any suitable combination thereof.

[0015] More specific examples (non-exhaustive list) of storage devices include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory ("RAM"), a read-only memory ("ROM"), an erasable programmable read-only memory ("EPROM" or flash memory), a portable compact disk read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the context of this specification, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0016] The code for carrying out the operations of the embodiments may be any number of lines and may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, and conventional procedural programming languages ​​such as the "C" programming language, and / or machine code such as assembly language. The code may run entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the last scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network ("LAN"), wireless LAN ("WLAN"), or wide area network ("WAN"), or a connection to an external computer may be made (e.g., via the Internet using an Internet Service Provider ("ISP").

[0017] Furthermore, the described features, structures, or characteristics of the embodiments may be combined in any suitable manner. In the following description, numerous specific details, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., are provided to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that the embodiments may be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other cases, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the embodiments.

[0018] Reference throughout this specification to "one embodiment," "an embodiment," or similar language means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Thus, throughout this specification, the appearances of the phrases "in one embodiment," "in an embodiment," and similar language may, but do not necessarily, all refer to the same embodiment and may mean "one or more, but not all, embodiments" unless otherwise specified. The terms "including," "comprising," "having," and variations thereof mean "including, but not limited to," unless otherwise specified. An enumerated list of items does not imply that any or all of the items are mutually exclusive, unless otherwise specified. Additionally, the terms "a," "an," and "the" refer to "one or more," unless otherwise specified.

[0019] As used herein, a list using the conjunction "and / or" includes any single item in the list or a combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term "one or more of" includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term "one of" includes only one of any single item in the list. For example, "one of A, B, and C" includes only A, only B, or only C, and excludes the combination of A, B, and C. As used herein, "a member selected from the group consisting of A, B, and C" includes only one of A, B, or C, and excludes the combination of A, B, and C. As used herein, "a member selected from the group consisting of A, B, and C and combinations thereof" includes only A, only B, only C, the combination of A and B, the combination of B and C, the combination of A and C, or the combination of A, B, and C.

[0020] Aspects of the embodiments are described below with reference to schematic flow charts and / or schematic block diagrams of methods, apparatus, systems, and program products according to the embodiments. It will be understood that each block of the schematic flow charts and / or schematic block diagrams, and combinations of blocks in the schematic flow charts and / or schematic block diagrams, may be implemented by code. This code may be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing apparatus to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing apparatus produce means for performing the functions / acts specified in the flow charts and / or block diagrams.

[0021] The code may be stored in a storage device that can instruct a computer, other programmable data processing apparatus, or other device to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture that includes instructions that perform the functions / acts specified in the flowcharts and / or block diagrams.

[0022] The code may be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to produce a computer-implemented process such that the code executing on the computer or other programmable apparatus provides a process for performing the functions / acts specified in the flow charts and / or block diagrams.

[0023] The flowcharts and / or block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and program products according to various embodiments. In this regard, each block in the flowcharts and / or block diagrams may represent a module, segment, or portion of code that includes one or more executable instructions of code for implementing the specified logical function(s).

[0024] It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks of the illustrated figures, or portions thereof.

[0025] Various arrow types and line types may be used in the flow charts and / or block diagrams, but they are understood not to limit the scope of the corresponding embodiments. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the illustrated embodiments. For example, arrows may indicate waiting or monitoring periods of unspecified duration between recited steps of the illustrated embodiments. It is also noted that each block of the block diagrams and / or flow charts, and combinations of blocks in the block diagrams and / or flow charts, may be implemented by dedicated hardware-based systems that perform the specified functions or acts, or a combination of dedicated hardware and code.

[0026] The description of the elements in each figure may refer to the elements in the procedure figures. Like numbers refer to like elements in all figures, including alternative embodiments of like elements.

[0027] Generally, this disclosure describes systems, methods, and apparatus for video codec-aware RAN configuration and unequal error protection coding. In certain embodiments, the methods may be performed using computer code embodied in a computer-readable medium. In certain embodiments, the apparatus or system may include a computer-readable medium including computer-readable code that, when executed by a processor, causes the apparatus or system to perform at least a portion of the solutions described below.

[0028] Emerging applications such as Augmented Reality ("AR") / Virtual Reality ("VR") / Extended Reality ("XR"), Cloud Gaming ("CG"), device remote teleoperation (e.g., vehicle teleoperation, robotic arm teleoperation, etc.), 3D video conferencing, smart distance education, etc. are expected to drive the growth of video traffic. Even though the aforementioned applications may require different quantitative constraints and configurations in terms of rate, reliability, latency, and quality of service ("QoS"), such constraint sets are expected to challenge current and future communication networks in providing high fidelity Quality of Experience ("QoE") at ever-increasing resolutions. As the quality of rendering end devices improves and their cost drops over time, such applications are expected to steadily spread and further raise the bar of QoE for end applications. Hence, there is a high interest in providing scalable and reliable solutions from a communication network perspective for next-generation media content delivery systems and their immersive digital reality applications.

[0029] Communication networks are one crucial component of such applications. Another key technology in scaling the deployment of these immersive media experiences is video encoding and compression of source video information. This is crucial in reducing the size of raw image data to a point where communication systems can reliably transmit video content over a variety of challenging network conditions associated with mobile and wireless data systems and applications. Currently, the communication plane is completely separated from the encoding plane of the video source, which makes optimizing transmission strategies for reliable QoE for such video-intensive applications difficult and / or limited. Despite current advances in video codec development (e.g., H.266 standard release), the data growth rate of high-resolution multiview / AR / XR / 3D applications exceeds the compression gain. Therefore, there is interest in developing mechanisms to assist communication and access networks in understanding codec-specific semantics and leveraging the latter in designing and configuring optimized transmission strategies for the above-mentioned video applications.

[0030] In one embodiment, the present disclosure proposes a method for adaptively configuring, aligning, and Unequal Error Protection ("UEP") FEC coding of RAN PHY transport blocks ("TBs") and their partitions based on video coding data awareness, including segmentation of TBs into variable length partitions as mini-TBs and video codec-aware alignment to codec data units (e.g., slices, parameter sets, etc.), UEP configuration with hybrid automatic repeat request incremental redundancy ("HARQ-IR") at mini-TB level and UEP configuration with mini-TBs of various code rates for initial transmissions for transport block segmentation, variable length / code rate configuration of TB partitions based on importance of video coded data to be transported, and related signaling mechanisms for configuring RAN PHY coding based on video coded ADU / NAL unit data awareness.

[0031] FIG. 1 illustrates a wireless communication system 100 for video codec-aware RAN configuration and unequal error protection coding according to an embodiment of the present disclosure. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a fifth generation radio access network ("5G-RAN") 115, and a mobile core network 140. The 5G-RAN 115 and the mobile core network 140 form a mobile communication network. The 5G-RAN 115 may be comprised of a 3rd Generation Partnership Project ("3GPP") access network 120 including at least one cellular base unit 121, and / or a non-3GPP access network 130 including at least one access point 131. The remote unit 105 communicates with the 3GPP access network 120 using a 3GPP communication link 123 and / or with the non-3GPP access network 130 using a non-3GPP communication link 133. Even though a particular number of remote units 105, 3GPP access networks 120, cellular base units 121, 3GPP communication links 123, non-3GPP access networks 130, access points 131, non-3GPP communication links 133, and mobile core networks 140 are shown in FIG. 1, those skilled in the art will recognize that any number of remote units 105, 3GPP access networks 120, cellular base units 121, 3GPP communication links 123, non-3GPP access networks 130, access points 131, non-3GPP communication links 133, and mobile core networks 140 may be included in the wireless communications system 100.

[0032] In one implementation, the RAN 120 complies with a 5G system defined in 3GPP specifications. For example, the RAN 120 may be a NextGen RAN ("NG-RAN") that implements a New Radio ("NR") radio access technology ("RAT") and / or a Long Term Evolution ("LTE") RAT. In another example, the RAN 120 may include a non-3GPP RAT (e.g., Wi-Fi or a WLAN compliant with the Institute of Electrical and Electronics Engineers ("IEEE") 802.11 family). In another implementation, the RAN 120 complies with an LTE system defined in 3GPP specifications. However, more broadly, the wireless communication system 100 may implement any other open or proprietary communication network, such as the Worldwide Interoperability for Microwave Access ("WiMAX") or IEEE 802.16 family of standards, among other networks. This disclosure is not intended to be limited to any particular wireless communications system architecture or protocol implementation.

[0033] In one embodiment, the remote unit 105 may include a computing device such as a desktop computer, a laptop computer, a personal digital assistant ("PDA"), a tablet computer, a smartphone, a smart television (e.g., a television connected to the Internet), a smart appliance (e.g., an appliance connected to the Internet), a set-top box, a game console, a security system (including security cameras), an in-vehicle computer, a network device (e.g., a router, a switch, a modem), etc. In some embodiments, the remote unit 105 includes a wearable device such as a smart watch, a fitness band, an optical head mounted display, etc. In one embodiment, the remote unit 105 includes a device for presenting a virtual reality environment, an augmented reality environment, and / or an extended reality environment, e.g., a head mounted display unit.

[0034] Additionally, the remote unit 105 may be referred to as a user equipment (UE) device, a subscriber unit, a mobile phone, a mobile station, a user, a terminal, a mobile terminal, a fixed terminal, a subscriber station, a user terminal, a wireless transmit / receive unit ("WTRU"), a device, or other terminology used in the art. In various embodiments, the remote unit 105 includes a subscriber identity and / or identification module ("SIM") and a mobile equipment ("ME") that provides mobile termination functions (e.g., wireless transmission, handover, voice encoding and decoding, error detection and correction, signaling, and access to the SIM). In certain embodiments, the remote unit 105 may include terminal equipment ("TE") and / or may be incorporated into a home appliance or device (e.g., a computing device as described above).

[0035] The remote unit 105 may communicate directly with one or more of the cellular base units 121 in the 3GPP access network 120 by uplink ("UL") and downlink ("DL") communication signals. Furthermore, the UL and DL communication signals may be carried on a 3GPP communication link 123. Similarly, the remote unit 105 may communicate with one or more access points 131 in the non-3GPP access network 130 by UL and DL communication signals carried on a non-3GPP communication link 133. Here, the access networks 120 and 130 are intermediate networks that provide the remote unit 105 with access to the mobile core network 140.

[0036] In some embodiments, the remote unit 105 communicates with a remote host (e.g., in the data network 150 or the data network 160) via a network connection with the mobile core network 140. For example, an application 107 (e.g., a web browser, a media client, a telephony and / or a voice over Internet protocol ("VoIP") application) in the remote unit 105 may trigger the remote unit 105 to establish a protocol data unit ("PDU") session (or other data connection) with the mobile core network 140 via the 5G-RAN 115 (e.g., via the 3GPP access network 120 and / or the non-3GPP network 130). The mobile core network 140 then relays traffic between the remote unit 105 and the remote host using the PDU session. The PDU session represents a logical connection between the remote unit 105 and the user plane function ("UPF") 141.

[0037] In order to establish a PDU session (or packet data network ("PDN") connection), the remote unit 105 must register with the mobile core network 140 (also referred to as "attached to the mobile core network" in the context of fourth generation ("4G") systems). It should be noted that the remote unit 105 may establish one or more PDU sessions (or other data connections) with the mobile core network 140. Thus, the remote unit 105 may have at least one PDU session for communicating with the packet data network 150. Additionally--or alternatively--the remote unit 105 may have at least one PDU session for communicating with the packet data network 160. The remote unit 105 may establish additional PDU sessions for communicating with other data networks and / or other communication peers.

[0038] In the context of 5G systems ("5GS"), the term "PDU session" refers to a data connection that provides end-to-end ("E2E") user plane ("UP") connectivity between a remote unit 105 and a particular data network ("DN") via the UPF 141. A PDU session supports one or more QoS flows. In certain embodiments, there may be a one-to-one mapping between QoS flows and QoS profiles such that all packets belonging to a particular QoS flow have the same 5G QoS Identifier ("5QI").

[0039] In the context of a 4G / LTE system, such as the Evolved Packet System ("EPS"), a PDN connection (also called an EPS session) provides an E2E UP connection between a remote unit and a PDN. The PDN connection procedure establishes an EPS bearer, e.g., a tunnel between the remote unit 105 and a Packet Gateway ("P-GW"), not shown, in the Evolved Packet Core Network ("EPC"). In a particular embodiment, there is a one-to-one mapping between EPS bearers and QoS profiles, such that all packets belonging to a particular EPS bearer have the same QoS Class Identifier ("QCI").

[0040] As described in further detail below, the remote unit 105 may use a first data connection (e.g., PDU session) established with a first mobile core network, EPC (not shown), to establish a second data connection (e.g., part of a second PDU session) with a second mobile core network 140. When establishing a data connection (e.g., PDU session) with the second mobile core network 140, the remote unit 105 registers with the second mobile core network 140 using the first data connection.

[0041] The cellular base units 121 may be distributed in a geographical region. In certain embodiments, the cellular base units 121 may be referred to as an access terminal, a base, a base station, a Node B ("NB"), an evolved Node B (abbreviated as eNodeB or "eNB" and also known as an evolved Universal Terrestrial Radio Access Network ("E-UTRAN") Node B), a 5G / NR Node B ("gNB"), a home Node B, a relay node, a device, or any other terminology used in the art. The cellular base units 121 are generally part of a RAN, such as a 3GPP access network 120, which may include one or more controllers communicatively coupled to one or more corresponding cellular base units 121. These and other elements of a radio access network are not shown, but are generally familiar to those skilled in the art. The cellular base units 121 connect to a mobile core network 140 via the 3GPP access network 120.

[0042] The cellular base unit 121 may serve multiple remote units 105 in a serving area, e.g., a cell or a sector of a cell, via a 3GPP wireless communication link 123. The cellular base unit 121 may directly communicate with one or more of the remote units 105 by communication signals. In general, the cellular base unit 121 transmits DL communication signals to serve the remote units 105 in the time, frequency, and / or space domains. Furthermore, the DL communication signals may be carried on the 3GPP communication link 123. The 3GPP communication link 123 may be any suitable carrier in a licensed or unlicensed radio spectrum. The 3GPP communication link 123 facilitates communication between one or more of the remote units 105 and / or one or more of the cellular base units 121. It should be noted that during NR operation over an unlicensed spectrum (referred to as “NR-U”), the base unit 121 and the remote unit 105 communicate over an unlicensed (e.g., shared) radio spectrum.

[0043] The non-3GPP access networks 130 may be distributed in a geographical region. Each non-3GPP access network 130 may serve a number of remote units 105 within a serving area. An access point 131 of the non-3GPP access network 130 may directly communicate with one or more remote units 105 by receiving UL communication signals and transmitting DL communication signals to serve the remote units 105 in the time, frequency, and / or spatial domains. Both DL and UL communication signals are carried on a non-3GPP communication link 133. The 3GPP communication link 123 and the non-3GPP communication link 133 may employ different frequencies and / or different communication protocols. In various embodiments, the access point 131 may communicate using an unlicensed radio spectrum. The mobile core network 140 may serve the remote units 105 via the non-3GPP access networks 130 as described in more detail herein.

[0044] In some embodiments, the non-3GPP access network 130 connects to the mobile core network 140 via an interworking entity 135. The interworking entity 135 provides interworking between the non-3GPP access network 130 and the mobile core network 140. The interworking entity 135 supports connections via "N2" and "N3" interfaces. As shown, both the 3GPP access network 120 and the interworking entity 135 communicate with an Access and Mobility Management Function ("AMF") 143 using the "N2" interface. The 3GPP access network 120 and the interworking entity 135 also communicate with the UPF 141 using the "N3" interface. Although shown as being outside the mobile core network 140, in other embodiments, the interworking entity 135 may be part of the core network. Although shown as being outside the non-3GPP RAN 130, in other embodiments, the interworking entity 135 may be part of the non-3GPP RAN 130.

[0045] In certain embodiments, the non-3GPP access network 130 may be controlled by the operator of the mobile core network 140 and may have direct access to the mobile core network 140. Such a deployment of a non-3GPP AN is referred to as a "trusted non-3GPP access network." A non-3GPP access network 130 is considered "trusted" when it is operated by a 3GPP operator or a trusted partner and supports certain security features such as strong air interface encryption. In contrast, a deployment of a non-3GPP AN that is not controlled by the operator (or trusted partner) of the mobile core network 140, does not have direct access to the mobile core network 140, or does not support certain security features is referred to as an "untrusted" non-3GPP access network. An interworking entity 135 deployed in the trusted non-3GPP access network 130 may be referred to herein as a Trusted Network Gateway Function ("TNGF"). An interworking entity 135 deployed in the untrusted non-3GPP access network 130 may be referred to herein as a non-3GPP interworking function ("N3IWF"). Although shown as part of the non-3GPP access network 130, in some embodiments the N3IWF may be part of the mobile core network 140 or may be located in the data network 150.

[0046] In one embodiment, the mobile core network 140 is a 5G Core ("5GC") or EPC that may be coupled to a data network 150, such as the Internet and a private data network, among other data networks. The remote units 105 may have a subscription or other account with the mobile core network 140. Each mobile core network 140 belongs to a single public land mobile network ("PLMN"). This disclosure is not intended to be limited to any particular wireless communications system architecture or protocol implementation.

[0047] The mobile core network 140 includes several network functions ("NFs"). As shown, the mobile core network 140 includes at least one UPF 141. The mobile core network 140 also includes multiple control plane functions, including but not limited to an AMF 143 that provides services to the 5G-RAN 115, a session management function ("SMF") 145, a policy control function ("PCF") 147, an authentication server function ("AUSF") 148, a unified data management ("UDM"), and a unified data repository function ("UDR").

[0048] The UPF 141 is responsible for packet routing and forwarding, packet inspection, handling of QoS, and external PDU sessions for interconnecting data networks ("DNs") in the 5G architecture. The AMF 143 is responsible for termination of non-access stratum ("NAS") signaling, encryption & integrity protection of NAS, registration management, connection management, mobility management, access authentication and authorization, security context management. The SMF 145 is responsible for session management (e.g., session establishment, modification, release), allocation & management of remote unit (e.g., UE) IP addresses, DL data notification, and traffic steering configuration of the UPF for proper traffic routing.

[0049] The PCF 147 is responsible for providing a unified policy framework, policy rules to the control plane ("CP") functions, and access subscription information for policy decisions in the UDR. The AUSF 148 acts as an authentication server.

[0050] The UDM is responsible for Authentication and Key Agreement ("AKA") credential generation, user identification, access authorization, and subscription management. The UDR is a repository of subscriber information and can be used to provide services to many network functions. For example, the UDR may store subscription data, policy related data, subscriber related data that is allowed to be exposed to third party applications, etc. In some embodiments, the UDM is co-located with the UDR and is denoted as a combined entity "UDM / UDR" 149.

[0051] In various embodiments, the mobile core network 140 may also include a Network Exposure Function ("NEF") (responsible for making network data and resources easily accessible by customers and network partners, for example, via one or more application programming interfaces ("APIs"), a Network Repository Function ("NRF") (which provides registration and discovery of NF services, allowing NFs to identify each other's appropriate services and communicate with each other via APIs), or other NFs defined for 5GC. In particular embodiments, the mobile core network 140 may include an Authentication, Authorization, and Accounting ("AAA") server.

[0052] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, each of which utilizes a particular network slice. Here, a "network slice" refers to a portion of the mobile core network 140 optimized for a particular traffic type or communication service. A network instance may be specified by a single Network Slice Selection Assistance Information ("S-NSSAI"), while a set of network slices that the remote unit 105 is authorized to use is specified by the NSSAI. In certain embodiments, the various network slices may include separate instances of network functions, such as the SMF and UPF 141. In some embodiments, the different network slices may share some common network functions, such as the AMF 143. For ease of illustration, the different network slices are not shown in FIG. 1, but their support is assumed.

[0053] In one embodiment, the network 100 includes an application server 142 that hosts applications for use by the mobile network 140, the RAN 115, the remote units 105, etc. As pertinent to the subject matter disclosed herein, the application server 142 may host video codec-aware applications used to determine and indicate the importance of underlying NAL units of a video encoded elementary stream. The importance indicators may be located in the mobile network 140 (e.g., in the UPF 141), in the RAN 115 (e.g., at higher layers), etc.

[0054] 1, those skilled in the art will recognize that any number and type of network functions may be included in the mobile core network 140. Furthermore, if the mobile core network 140 includes an EPC, the depicted network functions may be replaced by appropriate EPC entities, such as a Mobility Management Entity ("MME"), a Serving Gateway ("S-GW"), a P-GW, a Home Subscriber Server ("HSS"), etc.

[0055] 1 shows components of a 5G RAN and a 5G core network, the described embodiments for using pseudonyms for access authentication over non-3GPP access apply to other types of communication networks and RATs, including IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA 2000, Bluetooth, ZigBee, Sigfox, etc. For example, in a 4G / LTE variant that includes an EPC, the AMF 143 may be mapped to the MME, the SMF may be mapped to the control plane portion of the P-GW and / or the MME, the UPF 141 may be mapped to the S-GW and user plane portion of the P-GW, the UDM / UDR 149 may be mapped to the HSS, etc.

[0056] As shown, a remote unit 105 (e.g., a UE) may connect to a mobile core network (e.g., a 5G mobile communications network) via two types of access: (1) via a 3GPP access network 120 and (2) via a non-3GPP access network 130. The first type of access (e.g., the 3GPP access network 120) uses a 3GPP-defined type of wireless communication (e.g., NG-RAN), and the second type of access (e.g., the non-3GPP access network 130) uses a non-3GPP-defined type of wireless communication (e.g., WLAN). 5G-RAN 115 refers to any type of 5G access network that can provide access to the mobile core network 140, including the 3GPP access network 120 and the non-3GPP access network 130.

[0057] By way of background, the common framework adopted at the 3GPP level for immersive XR and high performance video content transmission, e.g., 3GPP Technical Report TR 26.928 (v16.0.0 - November 2020), 5G; Extended Reality (XR) in 5G, S4-211210: [FS_XRTraffic]: Permanent document, v0.8.0, reported by Qualcomm Inc., (2021), relies on the concept of split rendering. It uses an application server located at the edge and connected to the core network ("CN"), which is used to encode application video content and forward it to the RAN for mobile communication. In return, the RAN communicates with the connected UE, which may use additional hardware / software processing to render the video content to match the user's pose / input / control state. This architectural approach is shown in Figure 2 for reference.

[0058] FIG. 2 shows a split rendering architecture for a mobile network based on an edge / cloud video application server and an XR UE device 203. The device 203 is connected to a radio access network 208, which is further connected to an application server 202 via a core network 205. The application server 202 may deliver XR media based on local XR processed content or based on remote XR processed content. The processing may take into account and / or further process tracking and sensing information uplinked by the XR UE device 203. The application server 202 streams the XR multimedia content via a content delivery gateway 210 to which the XR UE device 203 is connected by any real-time transport protocol. After decoding the XR content received from the application server 202, the XR device 203 may locally render the XR content on the display using the XR engine 212 of the XR device 203 and additional local hardware / software capabilities and / or XR pre-rendered content, as well as XR-related XR metadata.

[0059] In the illustrated embodiment, therefore, the video application server 202 is used to process, encode, transcode, and / or provide to the XR UE 203 local video content 204 or remote video content 206 associated with the AR / XR / CG / teleoperation application session. As a result, the video application server 202 may encode / transcode and control the video viewport content and transmit it in the downlink to the RAN 208 based on UE specific parameters, configurations, and sensed inputs that may affect the rendering viewpoint, rate, quality, panning, etc. This overall architecture is expected to enable scalable AR / XR / CG / teleoperation applications and use cases with low latency, high rate, and efficient energy usage, leveraging the benefits of various compute and network domains (e.g., cloud, edge, smart handsets / headsets). The architecture is therefore universally applicable to both split rendering with asynchronous time warping, e.g., where a video application server encodes a rasterized pre-processed viewport representation to assist the UE, and split rendering with device-side viewport rendering, e.g., where a video viewport may be fully or partially rendered on the device side given the media encoded video content and its available corresponding metadata.

[0060] In one embodiment, in the context of the video coding domain, interactivity including these applications requires guarantees in terms of meeting packet error rate ("PER") and packet delay budget ("PDB") for the QoE of rendering the associated video stream at the UE. Jitter of the video source and the stochastic nature of wireless channels of mobile communication systems make the former difficult to meet, especially for certain high-rate digital video transmissions, e.g., 4K, 3D video, 2x2K eye-buffered video, etc.

[0061] In one embodiment, the current video source information is encoded based on a 2D representation of the video content. The encoded elementary stream video content is generally organized into two abstraction layers, e.g., NAL and video coding layer ("VCL"), intended to separate the storage domain and the video coding domain, respectively, regardless of the source encoder. The NAL syntax encapsulates the VCL information and provides an abstract containerization mechanism for the encoded stream during transmission, e.g., for disk storage / caching / transmission and / or parsing / decoding.

[0062] On the other hand, the VCL encapsulates the video encoding procedure of an encoder and compresses the source coded video information based on some entropy coding method, e.g., context-adaptive binary arithmetic encoding ("CABAC"), context-adaptive variable-length coding ("CAVLC"), etc. A simplified description of the VCL procedure for generally encoding video content is as follows: pictures 302 in a video sequence are partitioned 304 into coding units of configured size (e.g., macroblocks, coding tree units, or variations thereof).The coding unit then uses some tree partitioning structures (see ITU-T Series H: Audiovisual and Multimedia Systems: Infrastructure of Audiovisual Services - Coding of Moving video, Advanced Video Coding for Generic Audiovisual Services (H.264) (v08 / 2021), ITU-T Series H: Audiovisual and Multimedia Systems: Infrastructure of Audiovisual Services - Coding of Moving video, High Efficiency Video Coding (H.265) (v08 / 2021), ITU-T Series H: Audiovisual and Multimedia Systems: Infrastructure of Audiovisual Services - Coding of Moving video, Versatile Video Coding (H.266) (v08 / 2020)), for example under a bipartite / ternary / quadtree, or according to some predefined geometrically motivated 2D segmentation patterns (see de Rivaz, available at https: / / aomediacodec.github.io / av1-spec / av1-spec.pdf). P. and Haughton, J., (2018), AV1 Bitstream & Decoding Process Specification, The Alliance for Open Media, 182), for example, it may be split under a 10-way split.

[0063] In one embodiment, the encoder uses such inter-encoding unit visual references to encode picture content in a residual-based differential manner. The residual is determined given a prediction mode related to the reconstruction of information. Two modes of prediction are universally available as intra prediction 306 (also called intra for short) or inter prediction 308 (or inter for short). The intra mode is based on deriving and predicting the residual based on the content of other encoding units in the current picture, for example by calculating the residual of the current encoding unit given the coded content of the neighboring encoding units of the current encoding unit. On the other hand, the inter mode is based on deriving and predicting the residual based on the content of encoding units from other pictures, for example by calculating the residual of the current encoding unit given the content of the neighboring coded pictures of the current encoding unit.

[0064] The residual is then further transformed for compression using some multi-dimensional (2D / 3D) spatial multi-modal transform 310, e.g., a frequency-based or wavelet-based linear transform, to extract the most prominent frequency components of the coding unit residual. The insignificant high frequency contributions of the residual are removed and the floating-point transformed representation of the remaining residual is further quantized (312) based on some parametric quantization procedure to a selected number of bits per sample, e.g., 8 / 10 / 12 bits. Finally, the transformed and quantized residuals and their associated motion vectors relative to their prediction references in either intra or inter mode are encoded using an entropy encoding mechanism to compress the information based on the probability distribution of the source bit content. The output of this operation is a bitstream 316 of the VCL coded residual content. A simplified comprehensive diagram of the blocks of a recent hybrid (applying both temporal and spatial compression with intra / inter prediction) video codec is shown in FIG. 3.

[0065] FIG. 3 shows a generic video codec that performs both spatial and temporal (motion) compression of a video source. Encoder blocks are captured in the domain tagged "encoder". Decoder blocks are captured in the light grey domain tagged "decoder". Those skilled in the art may associate the above generic diagram describing a hybrid codec with a number of state-of-the-art video codecs, such as but not limited to MPEG-1, MPEG-2, MPEG-4 (collectively referred to as MPEG-x), H.264, H.265, H.266 (collectively referred to as H.26x), or VP8 / VP9 / AV1. Thus, the concepts utilized herein are considered in a broad sense hereafter, unless specifically clarified and scoped to any codec embodiment.

[0066] The coded residual bitstream is then encapsulated in an elementary stream as NAL units ready for storage or transmission over a network. NAL units are the main syntax elements of a video codec; they may encapsulate encoded video metadata, e.g., video / sequence / picture parameter sets ("VPS" / "SPS" / "PPS"), supplemental enhancement information ("SEI") messages, etc., as well as encoded video headers and residual data, typically as picture slices (pictures or similarly partitions of a video frame). The typical syntax of the encapsulation carries information described by codec-specific semantics that are intended to determine the usage of the metadata and video encoded data and to aid the decoding process.

[0067] The NAL unit encapsulation syntax consists of a header portion that determines the beginning of the NAL unit and the type of NAL unit, and a raw byte payload sequence that contains information related to the NAL unit. The NAL unit payload is then formed from the payload syntax or payload-specific header and the associated payload-specific syntax. An important subset of NAL units is formed from parameter sets, e.g., VPS, SPS, PPS, SEI message and configuration NAL units (collectively also known as non-VCL NAL units), as well as picture slice NAL units that contain video encoded data as VCL information. An effective decoder: Implement a bitstream parser to extract the necessary metadata information and VCL related metadata from the NAL unit sequence; Decoding the VCL residual coded data sequence into its transformed and quantized values; Apply an inverse linear transformation to recover the significant content of the residuals; Performing intra or inter prediction to reconstruct the luma and color representations of each coding unit; Applying additional filtering and error concealment procedures; · May reproduce raw picture sequence representation as video playback.

[0068] These operations and procedures may occur in the order listed, or out of order, depending on the specific implementation of the decoder.

[0069] Current RAN implementations do not consider any knowledge of the application data payloads they are required to serve. However, this level of intelligence may be necessary when dealing with AR / XR / CG / Teleoperation traffic containing multiple streams that may require different QoS flows with heterogeneous but nearly deterministic rate, latency, and reliability requirements for the provision of a satisfactory QoE. Considerations regarding video codec and application awareness at the (5th generation) 5G RAN level have started (see S4-211210: [FS_XRTraffic]: Permanent document, v0.8.0, Reporter Qualcomm Inc., (2021)), with Group of Pictures (GoP) and prediction type (e.g., intra / inter prediction) currently considered as the main characteristics for determining the relevance of video coded slices (as a partition of a picture / frame) at the RAN level. By definition, a GoP represents a temporal sequence of video frames that starts (or ends) with an intra-coded video frame (I-frame) and is followed by multiple forward predicted frames (P-frames) or bidirectionally predicted frames (B-frames). A group of picture parameter sets is further described by its associated VPS NAL unit (containing a description of video layer attributes and encoder configuration), SPS NAL unit (containing a description of sequence-level attributes and encoder configuration), and PPS NAL unit (containing a description of picture-level attributes and encoder configuration).

[0070] Specifically, the GoP-oriented importance of a slice as a video frame partition is based on whether the slice contains intra-coded elements (I slice) or inter-coded elements (P slice for slices with several inter-coded coding units that reference previous references, or B slice for slices with inter-coded coding units that reference previous and later references in the video sequence in both directions), as well as the offset to the last intra-coded picture in the current GoP given the cyclic GoP encoding configuration. Thus, if a slice is an I slice and belongs to the current intra-coded picture, it has the highest importance, but when the slice may be a P / B slice and belongs to an inter-coded picture further away from the last intra-coded picture, the importance decreases linearly to 1. This mechanism, as briefly highlighted in Table 1, may oversimplify some aspects of video coding and visual perception by equally weighting coding units and subsequent regions of a picture to their lowest importance, given the specifications of common video codecs.

[0071] As a result, if a slice contains both intra-coded and inter-coded coding units, the slice is de-prioritized in terms of importance even though it may contain a more significant portion of the intra-coded components that are more relevant than the inter-coded components.

[0072] [Table 1]

[0073] In one embodiment related to layer-based streaming and dynamic control, video codecs are designed to compress video information sources under the constraint of a rate-distortion tradeoff, such that their encoding is not specifically targeted for lossy mobile wireless communications, where the characteristics of the wireless channel randomly affect the transfer of encoded bits. Given multiple network hops separating the video source from the RAN, or similarly the video decoder at the receiver, dynamic adaptation of the video source encoding based on channel statistics often involves large feedback loop delays. Scalable expansion of video codecs (at the expense of increased encoding / decoding complexity) is achieved by layered encoding using spatial and / or temporal video coding layers.

[0074] As a result, the encoded video content may be progressively encoded / transmitted / decoded, assuming some hierarchical relationship between the video layers (e.g., base video layer, enhancement layer #1, enhancement layer #2, etc.). Such encoding / decoding procedures have either been developed as extensions to existing codec families, e.g., H.264, or have been incorporated into new generation codecs, such as H.265, H.266, etc. This scalable layered approach, together with the bandwidth ("BW") occupied by each individual layer, offers the possibility of dynamic streaming adaptation of the video source rate outside the practically applicable video encoder domain.

[0075] Regarding the 3GPP RAN overview and E2E XR (video) transport architecture, in 5G NR RAN, and in previous releases of 3GPP, the lower layers of the RAN do not have specific knowledge of the traffic of the higher layers that serve as Data Radio Bearers ("DRBs") on the physical wireless channel between the CN / data network and the UE. Therefore, no optimized decisions can be made in properly scheduling the associated traffic and controlling the rates of the various application streams for transmission with the high granularity and low latency adaptability constraints required by the highly mobile environment.

[0076] Interactive multimedia applications such as AR / VR / XR with high rate and low latency constraints for the transmission of video coded data synchronized with any user interaction are such particular use cases with high QoE requirements. To provide such applications reliably and robustly, the RAN may benefit from metadata and available insight into the AR / VR / XR video traffic required to be carried over the air.

[0077] However, certain embodiments do not provide such capabilities and procedures. As shown in Figure 4, PDUs related to XR application sessions of application servers 402 connected to CN 404 are forwarded over Internet Protocol ("IP") through the UPF of CN 404 to RAN 406. Multimedia traffic may be further supported by a real-time multimedia transport protocol, such as Real-time Transport Protocol ("RTP"), to handle jitter, packet loss, and out-of-order delivery that may occur within the framework of a typical IP network.

[0078] The QoS associated with IP packets of the XR traffic is handled by the CN 404 via QoS flows 408 created in the UPF within the established PDU session. This procedure is opaque to the RAN 406, which only manages the mapping of QoS flows 408 associated with received IP packets to their corresponding DRBs, given the QoS profile associated with the indicators of each QoS flow 408. For example, in 5GS, the QoS flows 408 are characterized by 5QI (see 3GPP Technical Specification TS 23.501 (V17.2.0 - September 2021), System architecture for the 5G System (5GS); Stage 2 (Release 17)).

[0079] This latter mapping of QoS flows 408 to DRBs is performed in the RAN 406 by the Service Data Adaptation Protocol ("SDAP") layer 410. The SDAP service data units ("SDUs") are then processed by the Packet Data Convergence Protocol ("PDCP") 412, which performs, among other things, header compression and encryption, and the output is further processed by the Radio Link Control ("RLC") 414, which may perform segmentation of the PDCP 412 SDUs and implements automatic request response ("ARP") repeat retransmissions. The RLC 414 SDUs are then processed through a logical channel interface by the Medium Access Control ("MAC") layer 416, which handles logical channel multiplexing, hybrid automatic repeat request ("HARQ"), scheduling, and scheduled retransmission functions. Finally, the MAC SDUs are combined into TBs at the level of the PHY layer 418 via transport channels. The PHY handles encoding / decoding, rate matching, modulation / demodulation, radio resource mapping, multi-antenna mapping, and other typical wireless low-layer functions.

[0080] The PHY TBs, which are appended with their own cyclic redundancy check ("CRC") of 16 or 24 bit blocks for error detection, are further partitioned into coding blocks ("CBs") of the same size. The CBs are also appended with a 24 bit CRC for error detection, and after this operation, they are FEC encoded by the PHY. The HARQ procedure in 5G NR ensures incremental redundancy retransmission of the entire TB if either the CB or the TB CRC check fails, thus effectively guaranteeing reliability on the wireless link. Furthermore, considering the increasing size of the TB, 5G NR also introduced a code block group (CBG) structure for grouping one or more CBs into a CBG. CBGs, when appropriately configured by Radio Resource Control ("RRC"), support independent HARQ within the same HARQ process as the encompassing TB, primarily via downlink control information ("DCI") signaling via CBG Transmit Indicator ("CBGTI") and CBG Flush Indicator ("CBGFI"). Thus, to reduce retransmission delays and resource utilization, several mechanisms for generic retransmission exist in 5G NR, but the underlying blocks enabling the latter are at best quasi-statically allocated and fixed in size in practice, which makes dynamic alignment and awareness adaptation to video coded traffic difficult.

[0081] As a result, all dynamic adaptations required at the RAN level to meet the requirements of QoS flows are constrained only to meet hard thresholds in terms of statistical PER, PDB or guaranteed bit rate (GBR), without any prior information of the content / importance of the transmitted data. As already outlined, for multimedia video traffic, not all packets / data segments (e.g., video frames / slices) are equally important, and even not all bits are equal in achieving a satisfactory level of QoE for the end user. Therefore, for a reliable, robust and user-oriented immersive video experience, it is of interest for the transmission strategies of the lower layers of the RAN to exploit the knowledge of the importance of the video encoded data segments that have to be transmitted, and to adapt the forward error correction wireless channel coding and retransmission configurations to adequately protect the transmitted information.

[0082] Generally, the subject matter herein presents a solution for video coded traffic and importance awareness at the RAN level for PHY layer configuration of transport blocks. Thus, methods for RAN transport block configuration including alignment and mapping of video coded data units to variable sized coding blocks and coding block groups, and dynamic code rate allocation of coding blocks and coding block groups, respectively, taking into account the importance of video coded data units are provided as part of two sets of embodiments.

[0083] In one embodiment, the encoded video content is encapsulated in a storage / transport abstraction layer, e.g., NAL, e.g., according to the H.26x standard. The NAL partitions the elementary video stream into NAL units 502 as the basic unit of storage of the video encoded content, either stored on disk or transmitted over a packet-based network. The NAL units 502 are further partitioned into a header portion 504 as the NAL prefix and a NAL payload 506 containing raw uncoded (VPS / SPS / PPS / SEI) or coded (video slice / slice segment) byte information. The NAL unit header 504 is formed of a delimiter for identifying the NAL unit start position and information about the content of the NAL unit payload, e.g., NAL unit type, NAL byte length, video coding layer / temporal layer identifier, as highlighted in FIG. 5, which shows a video coded elementary stream and its partitioning in multiple NAL units. A NAL unit is formed from a header and a payload, which contains information about the type, size, and video coding attributes and parameters of the information contained in the NAL unit data.

[0084] By parsing the NAL unit payload 506 and interpreting the specific semantics of the payload header 504 and the entropy video non-encoded data, based on the NAL unit type, more information about the content of the NAL unit may be gathered. This procedure may be performed in real-time with linear complexity and low latency overhead on specialized hardware embodiments or software implementations. Extracting this information may form a feature set of attributes that semantically describe the NAL unit 502 from the video codec's point of view in order to classify / estimate / predict / predict the importance of the NAL unit 502 for the playback of the encoded video elementary stream. This procedure of classification / estimation / prediction / prediction may be performed at various instances of the end-to-end transmission chain before the scheduling and transmission configuration functions of the RAN, as it serves as an importance indicator of the video encoded NAL data.

[0085] Similar to typical real-time transport protocols over packet-switched networks, e.g., RTP / User Datagram Protocol ("UDP") / IP, the smallest independently usable data unit of an application / stream, an ADU, may be represented by a NAL unit 502, a NAL unit data fragment (if the NAL unit exceeds the maximum size of the RTP payload given by the maximum transmission unit ("MTU") and is fragmented across multiple RTP payloads), or one of multiple NAL units 502 (however, for the latter two cases, hint sample signaling to detect multiple NAL units exists in the RTP hint track information) (3GPP Technical Specification TS 26.244 (v 16.1.0 - October 2020), Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; 5G; Transparent end-to-end packet switched streaming service (PSS); See 3GPP file format (3GP) (Release 16). Thus, for video coded traffic, these indications of importance at the granularity of the NAL unit are inherently aligned with the ADU. Thus, these indications of importance may be further leveraged within the processing domain of the RAN for the radio resource and link control layer to better schedule and forward the high rate, low latency video coded traffic associated with immersive AR / VR / XR applications over the mobile RAN.

[0086] Typically, the RAN level does not include any ADU-specific knowledge of the traffic being served, as shown in Figure 4. Thus, the configuration, scheduling, and transmission of the RAN depends on the QoS flows and their mapping to the DRB configuration signaled by the CN's UPF. Although the target PER, PDB, or GBR values ​​of the QoS flows and their associated QoS profiles ensure proper configuration of the lower levels of the RAN, this contract between the CN and the RAN does not include any finer granularity indicators of the traffic content encapsulated in the QoS flows to help the RAN statistically meet its contractual agreement at the QoS profile level. This is especially problematic for high-rate, low-latency video-encoded XR traffic, which has a noisy periodicity due to inherent source and network jitter, since the RAN may need additional knowledge of the data it is forwarding over the air for better decision-making in scheduling and transmission / retransmission link control procedures to meet the target PER, PDB, and GBR numbers.

[0087] This knowledge represents RAN awareness of the video encoded content and its relevance to the end user's QoE. When equipped with such awareness (such as an importance indicator per video coded ADU / NAL unit), the RAN may better determine how to prioritize traffic and dynamically adapt its configuration, rate, and FEC to reach the target PER, PDB, and GBR of the associated QoS flow of the video coded traffic packets. A system overview for high level RAN awareness of video coded traffic and its importance is shown in FIG. 6 in comparison with the conventional system shown in FIG. 4. As shown in FIG. 6, awareness of the video coded NAL unit / ADU traffic and importance in the RAN 606 is indicated by a video coded NAL data detector and importance indicator 601. Such indicator filters may be located at least one of: (1) application server 602, (2) within the CN UPF 604 or an extension thereof, and (3) deployed at higher layers of the RAN 606. Thus, the NAL data importance indicators 601 are used to annotate the video coded elementary streams and provide the control plane of the RAN with awareness of the video coded data content and its importance.

[0088] The latter embodiment of RAN awareness of video coded traffic and its expected importance may better map XR video encoded traffic content to RAN TBs and their corresponding FEC coded partitions, e.g., CBs, and group similarly important video information within CBGs. This video codec aware partitioning and grouping of application data into RAN transport blocks may be further leveraged to dynamically adapt transmission rates with finer granularity and provide selective error protection, e.g., UEP, depending on the importance of the video encoded data, respectively, to better handle potential retransmissions in case of bit errors at the receiver side, as detailed later.

[0089] The current lack of RAN awareness of the inherent traffic structure and / or importance provided on the DRB may cause problems for applications targeting high rates and low latency over a rapidly changing and potentially congested wireless spectrum. Thus, video wireless transmissions generally suffer from misalignment of NAL units or similarly ADUs and RAN data packets, resulting in visual defects whenever recoverability of the original transmitted data at the receiver side cannot be achieved.

[0090] A typical example is when a NAL unit containing a slice (in a one-to-one frame-slice mapping) is segmented across multiple TBs at the PHY transport level, and one of the TBs corresponding to the slice header or similarly the payload information cannot be restored (e.g., the maximum number of retransmissions or the time interval is exceeded). Eventually, the entire frame related to the slice is lost, generating a "frozen" visual effect during playback, while all subsequent frames referencing the lost frame are affected by the loss of motion vector references, further impairing the video playback with video artifacts.

[0091] Moreover, retransmissions may further impair the throughput and latency of subsequent video data transmissions. Other more complex scenarios may lead to similar visual impairments at the receiver that are typical of video-encoded wireless digital transmissions. Thus, similar results are expected to a greater extent for high-rate, low-latency AR / VR / XR / CG applications that challenge the current capabilities of RAN capacity, where the inherent structure of video-encoded data may not be utilized.

[0092] However, considering an embodiment in which the RAN has prior knowledge and is aware of the structure and / or importance of the video coded traffic, at least by one of RAN level video coded data inspection and higher level metadata labeling / dedicated importance indication, the inherent structure and priority of the video coded data content may be exploited, so that the video coded data can be better segmented and scheduled / mapped / grouped to the RAN TBs and their contained FEC CBs / CBGs. Such an embodiment provides coordinated support of transport of video coded traffic over the air, provides selective protection mechanisms for the served traffic, and reduces expected retransmission overhead associated with erroneously received data segments within the TB. Figure 7 illustrates a RAN with no awareness of video coded data from a cross-layer packet-oriented perspective.

[0093] In particular, Figure 7 shows a packet-oriented schematic diagram of RAN level processing without traffic content awareness. In one embodiment, all IP packets (collectively 702) are treated the same at lower levels of the RAN, regardless of the encapsulated ADU payload. "H" stands for Header.

[0094] Basic high-rate, low-latency immersive media traffic with video-encoded data, such as for CG / AR / XR applications, requires a steady data rate of around 100 Mbps, while more advanced applications, with higher resolution in the spatial dimension (e.g., 3D rendering), require much higher data rates. Thus, the associated TBs at the PHY level tend to be very large in practice, and their retransmissions are expensive in terms of resource utilization and scheduling of subsequent transmissions on constrained resources.

[0095] Furthermore, considering practical MTU constraints at the packet size level, ADUs / IP packets imported into the RAN may be limited to a fixed MTU (e.g., 1500 bytes for Ethernet encapsulation), which forces some segmentation and fragmentation of the original NAL unit data into NAL unit data segments. Thus, an ADU encapsulates the latter video-encoded data as a complete NAL unit data, a fragment of NAL unit data (e.g., a NAL unit data segment), or one of several NAL unit data segments (of which a subset may represent a complete NAL unit data). Since a NAL unit is the smallest independent data unit of a video codec, hereafter we refer to an ADU as NAL unit data, unless there is reference to a possibly recoverable mapping between the two (by the segmentation / fragmentation / signaling procedures of higher layer protocols) as described above.

[0096] In some embodiments, therefore, video coded NAL unit data or NAL unit data segments (e.g., non-VCL NAL units of a VPS / SPS / PPS, VCL NAL units of a complete video coded slice, or visually and logically segmented / partitioned parts thereof, e.g., a row / column of a video coding block, multiple connected video coding units, etc.) received via IP packets via some real-time streaming protocol may require alignment with TBs and / or their partitions (e.g., a CBG / CB in current 5G NR RAN, or a set of CBs in its extension, i.e., a mini TB ("mTB")) at the PHY level to better support radio resource utilization and retransmissions.

[0097] Hereinafter, mTB refers to a segment of a TB, and multiple mTBs form a TB. Thus, an mTB in some embodiments may be formed from one FEC CB or multiple FEC CBs, so that the segmentation of TBs in an mTB does not necessarily have to be equally divided in size across all mTBs as is currently the case in the 3GPP PHY layer, which uses fixed-size (equal division) CBGs. As a result, an mTB in some embodiments is a variable-size CBG that is aware of video-coded traffic.

[0098] Hereinafter, an alignment is generally the result of one of the following procedures: Encapsulating NAL unit data (e.g., VPS / PPS / SPS / SEI messages / video coded slices) or a sequence of NAL unit data (e.g., VPS / PPS / SPS / SEI messages / video coded slices) within one CB; Encapsulating NAL unit data (e.g., VPS / PPS / SPS / SEI messages / video coded slices) or a sequence of NAL unit data (e.g., VPS / PPS / SPS / SEI messages / video coded slices) within one CBG / mTB, and / or Encapsulating a sequence of NAL unit data segments (e.g., individual video coded slices, video coded slice segments (e.g., video coded rows or any geometrically contiguous collection of coded coding block unit partitions of the same slice), one of one or more video coded tile partitions of a video coded slice) within one CBG / mTB.

[0099] As a result, in some embodiments, individual NAL unit data or NAL unit data segments may be sequentially aligned and mapped to CBs and / or grouped as CBGs. The mapping may be used in conjunction with CBG-based retransmission to enable selective retransmission of only erroneous CBGs and contained NAL data units rather than retransmission of the complete large TB, thus saving radio resource utilization in contrast to current techniques in 3GPP RAN procedures.

[0100] Multiple NAL data units or NAL data unit segments received from higher layers (e.g., MAC SDUs) may in one embodiment be multiplexed into one CB, provided that their aggregated size does not exceed the maximum size of the CB given a particular FEC codebook design. The remaining free bits (if any) in the CB may be filled / utilized by one of the known bit fields / bit sequences (e.g., if the number of remaining bits is less / greater than a threshold number of bits) or may be left for utilization of additional PHY layer signaling procedures (e.g., demodulation reference signal ("DM-RS"), channel state information reference signal ("CSI-RS"), phase tracking reference signal ("PT-RS"), etc.). In one latter embodiment, the UE is indicated a pattern index that can be used to determine the resource elements ("RE") used for utilizing additional PHY layer signaling procedures, such as via a DCI scheduling the Physical Downlink Shared Channel ("PDSCH") / Physical Uplink Shared Channel ("PUSCH") or via an Uplink Control Information ("UCI") requesting PUSCH scheduling / scheduling update.

[0101] In an embodiment, the UE is configured with: a first maximum number of CBGs per transport block for transmission / reception related to a first attribute (such as traffic-aware scheduling), and A second maximum number of CBGs per transport block for transmission / reception related to a second attribute (e.g. traffic-unaware scheduling)

[0102] In an embodiment, the scheduling DCI indicates whether the scheduled transmission is based on traffic awareness (e.g., as described in this disclosure) (the scheduler is aware of certain traffic characteristics of the data being scheduled, such as ADU / NAL unit boundaries / importance, etc.).

[0103] In one embodiment, the input bit sequence to the code block segmentation is b 0 , b 1 , b 2 , b 3 , ..., b B-1 where B > 0 (where "B" is the number of TB bits). B is the maximum code block size K cb If it is greater, a segmentation of the input bit sequence is performed and an additional CRC sequence of L = 24 bits is appended to each code block.

[0104] For the LDPC base graph 1, the maximum code block size is

[0105] K cb = 8448.

[0106] For LDPC base graph 2, the maximum code block size is

[0107] K cb = 3840.

[0108] The total number of code blocks, C, is determined by:

[0109] If B ≦ K cb , and all the NAL units mapped to the TB have the same importance

[0110] L = 0

[0111] Number of code blocks: C = 1

[0112] B' = B

[0113] else

[0114] Q = B

[0115] C = 0

[0116] B' = 0

[0117] While Q > 0

[0118] Determine w

[0119] Q = Q - w

[0120] C = C + 1

[0121] B' = B' + w + L1

[0122] endwhile

[0123] end if

[0124] "w" is K cb - determined to be the number of consecutive sets of bits from the queue Q of bits belonging to NAL units with the same / similar importance (such as determined from the scheme of the present disclosure) not larger than L1, where "L1" is the CRC length of the code block. In an example, L1 = 24. In another example, L1 is determined based on an indication (such as DCI or MAC-CE), e.g., DCI scheduling the transmission of the input bit sequence.

[0125] In an example, if the determined "w" is less than the threshold, the UE checks whether Q - w > 0, and if so, the UE sets w1 = w and considers the w1 bit as part of the second set of "w" bits to determine a second "w" > w1.

[0126] If a NAL data unit or NAL data unit segment is larger than the CB size, the NAL data unit will fill the respective CB and subsequent CBs by itself to its completion (e.g., until no data segments from the NAL data unit remain), and the remaining free bits of the last CB will be filled / utilized by one of the known bit fields / bit sequences or left for utilization of additional PHY layer signaling procedures (e.g., DM-RS, CSI-RS, etc.). The next NAL data unit or NAL data unit segment will instead be aligned with the next available CB, allowing in some embodiments a collection of CBs encapsulating a complete NAL data unit to be grouped as a CBG. In one embodiment, a field / pattern / bit sequence indicates whether the NAL data unit / data unit segment has changed for the CB / CBG compared to the previous CB / CBG, respectively. In an example, the DCI scheduling the PDSCH indicates for each CBG whether the NAL data unit / data unit segment has changed compared to the previous CBG. In an example, the bit field length of such an indicator is M - 1, where "M" is the number of CBGs (or the bit length of the CBGTI field in the DCI format of the scheduling DCI).

[0127] In an embodiment, when the UE is configured to receive a CBG-based transmission by receiving an upper layer parameter codeBlockGroupTransmission for the PDSCH, the UE determines the number of CBGs for reception of the transport block as M = min(N, C) It is determined as follows.

[0128] N is the maximum number of CBGs per transport block configured by maxCodeBlockGroupsPerTransportBlock for the PDSCH, and C is the number of code blocks in a transport block (e.g., according to the procedures defined in 3GPP Technical Specification TS 38.212 (v16.5.0 - April 2021), 5G; NR; Multiplexing and channel coding, or determined in the above embodiments).

[0129] To determine the code block that is mapped to CBG m, for m=0, 1, ..., M - 1, the following procedure may be performed by some embodiments.

[0130] set m = 0

[0131] set q = C-1

[0132] set c = 1

[0133] CBG#0 = {code block 0}

[0134] while q > 0

[0135] determine whether code block 'c' is associated with the same / similar NAL unit or has the same / similar importance as that of code block c-1

[0136] if yes, and the size of CBG#m is not larger than a threshold (eg, the size in terms of number of CBs and / or in terms of total bits), CBG#m = union of (CBG#m, code block c)

[0137] if no

[0138] m = m + 1

[0139] CBG# = {code block c}

[0140] q = q - 1

[0141] c = c + 1

[0142] endwhile

[0143] In an example, a scheduling DCI or another DCI / MAC control element ("MAC-CE") / RRC indication indicates a CB to CBG mapping, e.g., a first mapping is a CBG mapping according to 3GPP Technical Specification TS 38.214 (v16.5.0 - April 2021), 5G; NR; Physical layer procedures for data, section 5.1.7.1, and a second mapping is according to the CB to CBG mapping described in this disclosure.

[0144] Since the size of the CB is determined semi-statically (see 3GPP Technical Specification TS 38.212 (v16.5.0 - April 2021), 5G; NR; Multiplexing and channel coding) given the overall TB size, i.e., TBS, which is determined based on the available radio resources (e.g., transmission layer, resource element / resource block, slot format, MCS, etc.), the alignment of variable length NAL data units to the CB and subsequent grouping into CBGs may not be a simple task in some embodiments and spectral efficiency may be affected. Therefore, in other embodiments, the TB may be fully segmented into variable length CBGs (e.g., as a many-to-one CB-to-CBG mapping) that allow independent retransmission scheduling within the same HARQ process. Such elements are mTBs, taking into account their variable length characteristics and the variable segmentation of the TB as defined above.

[0145] Since mTBs are variable-length TB partitions aligned with NAL data units, the number and size of mTBs are appropriately and dynamically signaled for decoding at the receiver side. This signaling of mTB size may be performed in an embodiment by at least one of the following: a dedicated pattern / bit field in DM-RS signaling, a DCI scheduling the corresponding PDSCH / PUSCH containing the CBG / mTB, a UCI request for scheduling / scheduling update of the corresponding PUSCH containing the CBG / mTB, periodic information signaling in DCI aligned with a slot format indicator ("SFI"), or front-loaded signaling encoded with a predefined low-complexity efficient FEC mechanism (e.g., Bose-Chaudhuri-Hocquenghem ("BCH") code, Polar code, Golay code, etc.) as part of the mTB's encompassing TB. In an example, the DCI for scheduling the PDSCH / PUSCH includes a bit field indicating the CBG / CB / mTB size for each CBG / CB / mTB. The length of the bit field may be a multiple of the number of CBG / CB / mTBs. For example, in one embodiment, for each CBG / mTB, the corresponding CBG / mTB size is indicated by a 2-bit indication that selects one size from four possible sizes.

[0146] In an embodiment, the minimum size of mTB is determined by considering the design of the FEC to avoid excessive segmentation of data and still take advantage of the coding gain of long codewords, and is set to a certain threshold mTB. min In such an embodiment, within one mTB, grouping of relatively small NAL unit data or data segments originating from different NAL units is allowed.

[0147] Furthermore, in some embodiments, as mentioned above, the size of the CBs forming the mTBs that span the entire NAL unit data or multiple NAL unit data segments belonging to a NAL unit data element may be partitioned equally. In such embodiments, the equal partitioning of an mTB of size S into M CBs is determined by the maximum codeword bit size configuration of the FEC codebook design used to channel encode the CBs and their corresponding CRCs, i.e., C max In some embodiments, M is determined taking into consideration:

number

number

[0148] In some embodiments, only VCL NAL unit data or data segments thereof (e.g., video coded slices / video coded slice data partitions) may be considered for mapping to CB / CBG / mTBs, while non-VCL NAL unit data or data segments may be treated generically for reduced complexity implementation. In an example, a DCI scheduling PDSCH / PUSCH including a CB / CBG / mTB indication of CB / CBG / mTB association to a NAL data unit / data unit segment indicates a special index (e.g., NAL alignment not applicable) for the CB / CBG corresponding to the non-VCL NAL unit data or data segment.

[0149] An embodiment illustrating the mapping of a video frame formed from four slices 802a-d to a variable size CBG / mTB contained in a TB is shown in Fig. 8. Fig. 8 shows an embodiment showing the mapping of a video frame to variable length video codec NAL unit aware coding partitions of a PHY transport block. A frame is formed from two tiles that are sliced ​​into four video slices representing the four NAL unit divisions that are fragmented by the IP layer to a maximum transport size and transmitted over the air by the wireless network to a receiver.

[0150] As can be seen, the NAL unit data aligned segmentation of TBs into variable-sized CBG / mTBs 804a-e provides an effective partition alignment to the variable-sized NAL unit data, in contrast to the video-coded traffic-unaware uniform segmentation and grouping approach of the current technology. Furthermore, the spectral and radio resource availability of CBG-based retransmissions is maintained by the video-coded traffic-aware variable-sized CBG / mTBs. For example, when a block of CBG / mTB#3 804c is received in error, that block of CBG / mTB#3 804c may be retransmitted and restored separately from the larger TB it encompasses, thus saving significant radio and spectral resources while also reducing the delay of the HARQ process as is desirable for high-rate low-latency AR / VR / XR immersive applications.

[0151] The proposed alignment of NAL unit data or NAL unit data segments to TBs and their contained FEC block partitions (e.g., CB / CBG / mTB) offers an embedded rate-compatible and scalable retransmission strategy given the 5G NR asynchronous incremental redundancy ("IR") HARQ mechanism. This is the effect of soft combining HARQ with redundancy version ("RV"), which exploits the structure of the FEC (e.g., low-density parity check ("LDPC") code) to refresh the coded information bits transmitted to the receiver at each transmission cycle. As a result, at each retransmission, the receiver can update the coding rate to

number

[0152] However, in some embodiments with limited bandwidth or radio resources, a more efficient use of the latter may be required. In such cases, a video codec-aware RAN with knowledge of the importance of the video encoded data may apply the latter to protect various NAL unit data and their data segments non-uniformly by FEC UEP coding. Current implementations of 5G NR consider rate-compatible FEC designs (e.g., LDPC, Polar codes), but these are only leveraged between retransmissions of the same CB. However, CBs within a TB are jointly coded at the same rate.

[0153] Instead, in some embodiments for video encoded data transmission where bandwidth and radio resources are scarce compared to throughput demands, at least one of the video codec importance, delay, and jitter characteristics (either probabilistically determined at the RAN level or signaled by source application / CN mechanisms) of the NAL unit data / data segments representing the video encoded traffic may be taken into account to characterize an overall importance level at the PHY layer and to prioritize more important data (e.g., NAL unit I slice data / data segments, NAL unit data of the base coding layer) in the coding domain, to the detriment of less important data (e.g., NAL unit P / B slice data / data segments, NAL unit data of the enhanced spatial / temporal coding layer).

[0154] In one embodiment, the code rate of the more important NAL unit data / NAL unit data segment (e.g., a video coded slice or partition thereof) or NAL unit data sequence (e.g., a video coding layer) is less than the code rate R 2 > R 1 A code rate lower than R 1In embodiments using high importance NAL unit data / NAL unit data segments (e.g., video slices or partitions thereof) or NAL unit data sequences (e.g., video coding layers), medium importance NAL unit data / NAL unit data segments (e.g., video coded slices or partitions thereof) or NAL unit data sequences (e.g., video coding layers), and low importance NAL unit data / NAL unit data segments (e.g., video coded slices or partitions thereof) or NAL unit data sequences (e.g., video coding layers), 0 < R 1 ≦ R 2 ≦ R 3 The most important data is transmitted at the lowest rate R so that R = 1 ≦ 1 (R = 1 may correspond to uncoded transmission in an embodiment). 1 and data of medium importance may be coded at an intermediate rate R 2 and less important data may be coded at the highest rate R 3 In some embodiments, R 1 = R 2 = R 3 The case ≠ represents a subset where the importance of the video coded data is not considered / discarded, and the coding domain is a subset of the proposed solution space for performing regular FEC without UEP.

[0155] FIG. 9 shows that the lower FEC coding rate R 1 The higher FEC coding rate R is achieved by CBG / mTB 904, which is aligned with the less important NAL unit data. 2 Two different FEC coding rates R 1 < R 2In this paper, we present an embodiment showing FEC with UEP for TB with 0 But R 0 The bit sequence encoded by 1 , R 2 A superset of code rates R = {R 0 , R 1 , R 2} is an embodiment of a rate-compatible codebook design using

[0156] For a tractable solution, in some embodiments, the importance levels are determined by a preselected, finite, discrete, ordered superset of rate-compatible code rates achievable by rate-compatible FEC implementations (e.g., quasi-cyclic LDPC codes, protograph-based Polar codes, punctured turbo codes, etc.) where higher code rates can be obtained from lower code rates without increasing complexity by pruning or puncturing, respectively, while performing the same encoding and decoding procedures. i |0 ≦ i < n, n∈N, 0 < R i < R j < 1∀i, j} and mapped to R. Thus, the encoding / decoding blocks can utilize the same encoder / decoder design by adaptively selecting punctured / pruned entries depending on the rate in R. Thus, in one embodiment, coding block partitions of TB, e.g., CB / CBG / mTB, will be coded at a rate selected from R depending on the required level of FEC, taking into account the importance level of their contained data, e.g., video coded NAL units / NAL unit segments (e.g., video coded slices or partitions thereof) or NAL unit data sequences (e.g., video coding layers).

[0157] In a video codec-aware embodiment of 5G NR / Beyond 5G NR with NAL units / NAL unit segments aligned to L mTBs, a method for code rate allocation (for mTBs within a TB) given a superset R and available radio resources (e.g., resource elements, transmission layers, resource blocks) may include the sum

number

[0158] mTB i indicates the size in bits of the mTB taking into account alignment to NAL units / NAL unit segments.

[0159] The summation in Equation 1 is upper bounded by an estimate of the coded bit rate capacity of the radio link over the TB transmission interval, taking into account the available radio resources and statistical link information for the selection of the MCS configuration and the subsequent determination of the TB size as the TBS. Thus, the right hand side becomes:

number

number

[0160] In some embodiments including TB-level UEP, the coding block partitions (e.g., CB / CBG / mTB) of the TB have variable code rates from superset R that require signaling in addition to the variable number and size of the coding block partitions. This signaling of the variable code rate per coding block partition may be performed in embodiments based on a table indexed, taking into account the FEC design, via a specific bit field configuration, by at least one of DM-RS signaling, DCI scheduling PDSCH / PUSCH including CBG / mTB of the UEP TB, UCI request for scheduling / scheduling update of PUSCH including CBG / mTB of the UEP TB, periodic information signaling of DCI aligned with SFI, and frontload signaling encoded with a predefined low-complexity (e.g., BCH code, Polar code, Golay code, etc.) efficient FEC mechanism as part of the encompassing TB of the CB / CBG / mTB.

[0161] In some embodiments, the superset R may be reduced to one of its subsets specific to a given FEC implementation or configuration. In other embodiments, the superset R may include special rates "0" and "1". Rate 0 simply indicates discarding coding block partitions aligned to the NAL units / NAL unit segments of the TB, while rate 1 represents uncoded transmission of data, e.g., no FEC. The discarding of NAL unit data / NAL unit data segments operation may in some embodiments be associated with less critical NAL unit data elements (e.g., extended spatial / temporal video coding layers, video coded B / P frames / slices that do not serve as references for any other frames / slices in the video coded sequence, etc.) that may otherwise exceed the wireless link capacity and subsequently impact the overall video coded stream QoE, or alternatively the video coded QoS flow, but whose loss is not critical to the perceived video playback quality.

[0162] 10 illustrates a user equipment device 1000 that may be used for video codec-aware RAN configuration and unequal error protection coding according to an embodiment of the present disclosure. In various embodiments, the user equipment device 1000 is used to implement one or more of the solutions described above. The user equipment device 1000 may be an embodiment of the remote unit 105 and / or UE described above. Additionally, the user equipment device 1000 may include a processor 1005, a memory 1010, an input device 1015, an output device 1020, and a transceiver 1025.

[0163] In some embodiments, the input devices 1015 and the output devices 1020 are combined into a single device, such as a touch screen. In certain embodiments, the user equipment device 1000 may not include any input devices 1015 and / or output devices 1020. In various embodiments, the user equipment device 1000 may include one or more of the processor 1005, the memory 1010, and the transceiver 1025, and may not include the input devices 1015 and / or the output devices 1020.

[0164] As shown, the transceiver 1025 includes at least one transmitter 1030 and at least one receiver 1035. In some embodiments, the transceiver 1025 communicates with one or more cells (or wireless coverage areas) supported by one or more base units 121. In various embodiments, the transceiver 1025 is operable in an unlicensed spectrum. Further, the transceiver 1025 may include multiple UE panels supporting one or more beams. In addition, the transceiver 1025 may support at least one network interface 1040 and / or application interface 1045. The application interface 1045 may support one or more APIs. The network interface 1040 may support 3GPP reference points such as Uu, N1, PC5, etc. As will be appreciated by one skilled in the art, other network interfaces 1040 may be supported.

[0165] The processor 1005, in one embodiment, may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, the processor 1005 may be a microcontroller, a microprocessor, a central processing unit ("CPU"), a graphics processing unit ("GPU"), an auxiliary processing unit, a field programmable gate array ("FPGA"), or a similar programmable controller. In some embodiments, the processor 1005 executes instructions stored in the memory 1010 to perform the methods and routines described herein. The processor 1005 is communicatively coupled to the memory 1010, the input device 1015, the output device 1020, and the transceiver 1025. In a particular embodiment, the processor 1005 may include an application processor (also known as a "main processor") that manages application domains and operating system ("OS") functions, and a baseband processor (also known as a "baseband radio processor") that manages radio functions.

[0166] In various embodiments, the processor 1005 and transceiver 1025 control the user equipment device 1000 to implement the UE behavior described above. In one embodiment, the transceiver 1025 receives an indication of a variable length and / or variable code rate TB partition element aligned with a plurality of NAL units and receives a variable length and / or variable code rate TB partition element aligned with the NAL units. In one embodiment, the processor 1005 decodes the FEC encoding of the plurality of video coded NAL unit data contained in the TB partition element and uses the received plurality of video coded NAL unit data to reconstruct and decode the transmitted video coded stream for video playback.

[0167] The memory 1010, in one embodiment, is a computer-readable storage medium. In some embodiments, the memory 1010 includes a volatile computer storage medium. For example, the memory 1010 may include RAM, including dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, the memory 1010 includes a non-volatile computer storage medium. For example, the memory 1010 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory 1010 includes both volatile and non-volatile computer storage media.

[0168] In some embodiments, memory 1010 stores data related to video codec-aware RAN configuration and unequal error protection coding. For example, memory 1010 may store various parameters, panel / beam configurations, resource allocations, policies, etc., as discussed above. In particular embodiments, memory 1010 also stores program code and associated data, such as operating system or other controller algorithms running on user equipment device 1000.

[0169] The input device 1015, in one embodiment, may include any known computer input device, including a touch panel, buttons, a keyboard, a stylus, a microphone, etc. In some embodiments, the input device 1015 may be integrated with the output device 1020, for example as a touch screen or similar touch-sensitive display. In some embodiments, the input device 1015 includes a touch screen, such that text may be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, the input device 1015 includes two or more different devices, such as a keyboard and a touch panel.

[0170] The output device 1020, in one embodiment, is designed to output visual, auditory, and / or tactile signals. In some embodiments, the output device 1020 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 1020 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, and the like to a user. As another non-limiting example, the output device 1020 may include a wearable display that is separate from but communicatively coupled to the remainder of the user equipment device 1000, such as a smart watch, smart glasses, a head-up display, and the like. Additionally, the output device 1020 may be a component of a smartphone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, and the like.

[0171] In certain embodiments, the output device 1020 includes one or more speakers for generating sound. For example, the output device 1020 may generate an audible alert or notification (e.g., a beep or chime). In some embodiments, the output device 1020 includes one or more haptic devices for generating vibration, movement, or other haptic feedback. In some embodiments, all or a portion of the output device 1020 may be integrated with the input device 1015. For example, the input device 1015 and the output device 1020 may form a touchscreen or similar touch-sensitive display. In other embodiments, the output device 1020 may be located near the input device 1015.

[0172] The transceiver 1025 communicates with one or more network functions of a mobile communications network via one or more access networks. The transceiver 1025 operates under the control of the processor 1005 to transmit messages, data, and other signals and to receive messages, data, and other signals. For example, the processor 1005 may selectively activate the transceiver 1025 (or a portion thereof) at a particular time to transmit and receive messages.

[0173] The transceiver 1025 includes at least one transmitter 1030 and at least one receiver 1035. The one or more transmitters 1030 may be used to provide UL communication signals to the base unit 121, such as UL transmissions described herein. Similarly, the one or more receivers 1035 may be used to receive DL communication signals from the base unit 121, as described herein. Although only one transmitter 1030 and one receiver 1035 are shown, the user equipment device 1000 may have any suitable number of transmitters 1030 and receivers 1035. Furthermore, the transmitters 1030 and receivers 1035 may be any suitable type of transmitter and receiver. In one embodiment, the transceiver 1025 includes a first transmitter / receiver pair used to communicate with a mobile communication network over a licensed radio spectrum and a second transmitter / receiver pair used to communicate with a mobile communication network over an unlicensed radio spectrum.

[0174] In certain embodiments, a first transmitter / receiver pair used to communicate with a mobile communications network over a licensed radio spectrum and a second transmitter / receiver pair used to communicate with a mobile communications network over an unlicensed radio spectrum may be combined into a single transceiver unit, e.g., a single chip that performs functions for use in both the licensed and unlicensed radio spectrum. In some embodiments, the first transmitter / receiver pair and the second transmitter / receiver pair may share one or more hardware components. For example, a particular transceiver 1025, transmitter 1030, and receiver 1035 may be implemented as physically separate components that access shared hardware and / or software resources, such as, for example, a network interface 1040.

[0175] In various embodiments, one or more transmitters 1030 and / or one or more receivers 1035 may be implemented and / or integrated in a single hardware component, such as a multi-transceiver chip, a system-on-chip, an application specific integrated circuit ("ASIC"), or other type of hardware component. In particular embodiments, one or more transmitters 1030 and / or one or more receivers 1035 may be implemented and / or integrated in a multi-chip module. In some embodiments, other components, such as a network interface 1040 or other hardware components / circuits, may be integrated in a single chip with any number of transmitters 1030 and / or receivers 1035. In such embodiments, the transmitters 1030 and receivers 1035 may be logically configured as a transceiver 1025 using one or more common control signals, or as modular transmitters 1030 and receivers 1035 implemented in the same hardware chip or multi-chip module.

[0176] 11 illustrates a network device 1100 that may be used for video codec-aware RAN configuration and unequal error protection coding according to an embodiment of the present disclosure. In one embodiment, the network device 1100 may be one implementation of a RAN node, such as the base unit 121, RAN node 210, or gNB described above. Additionally, the base network device 1100 may include a processor 1105, a memory 1110, an input device 1115, an output device 1120, and a transceiver 1125.

[0177] In some embodiments, the input device(s) 1115 and the output device(s) 1120 are combined into a single device, such as a touch screen. In certain embodiments, the network device 1100 may not include any input device(s) 1115 and / or output device(s) 1120. In various embodiments, the network device 1100 may include one or more of the processor 1105, the memory 1110, and the transceiver 1125, and may not include the input device(s) 1115 and / or the output device(s) 1120.

[0178] As shown, the transceiver 1125 includes at least one transmitter 1130 and at least one receiver 1135, where the transceiver 1125 communicates with one or more remote units 105. In addition, the transceiver 1125 may support at least one network interface 1140 and / or an application interface 1145. The application interface 1145 may support one or more APIs. The network interface 1140 may support 3GPP reference points such as Uu, N1, N2, and N3. As will be appreciated by one skilled in the art, other network interfaces 1140 may be supported.

[0179] The processor 1105, in one embodiment, may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, the processor 1105 may be a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or similar programmable controller. In some embodiments, the processor 1105 executes instructions stored in the memory 1110 to perform the methods and routines described herein. The processor 1105 is communicatively coupled to the memory 1110, the input device 1115, the output device 1120, and the transceiver 1125. In a particular embodiment, the processor 1105 may include an application processor (also known as a “main processor”) that manages application domains and operating system (“OS”) functions, and a baseband processor (also known as a “baseband radio processor”) that manages radio functions.

[0180] The memory 1110, in one embodiment, is a computer-readable storage medium. In some embodiments, the memory 1110 includes a volatile computer storage medium. For example, the memory 1110 may include RAM, including DRAM, SDRAM, and / or SRAM. In some embodiments, the memory 1110 includes a non-volatile computer storage medium. For example, the memory 1110 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory 1110 includes both volatile and non-volatile computer storage media.

[0181] In some embodiments, memory 1110 stores data related to video codec-aware RAN configuration and unequal error protection coding. For example, memory 1110 may store the parameters, configurations, resource allocations, policies, etc. described above. In certain embodiments, memory 1110 also stores program code and associated data, such as operating system or other controller algorithms running on network device 1100.

[0182] The input device 1115, in one embodiment, may include any known computer input device including a touch panel, buttons, a keyboard, a stylus, a microphone, etc. In some embodiments, the input device 1115 may be integrated with the output device 1120, for example as a touch screen or similar touch-sensitive display. In some embodiments, the input device 1115 includes a touch screen such that text may be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, the input device 1115 includes two or more different devices, such as a keyboard and a touch panel.

[0183] The output device 1120, in one embodiment, is designed to output visual, auditory, and / or tactile signals. In some embodiments, the output device 1120 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 1120 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, and the like to a user. As another non-limiting example, the output device 1120 may include a wearable display separate from but communicatively coupled to the rest of the network device 1100, such as a smart watch, smart glasses, a head-up display, and the like. Additionally, the output device 1120 may be a component of a smartphone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, and the like.

[0184] In certain embodiments, the output device(s) 1120 include one or more speakers for generating sound. For example, the output device(s) 1120 may generate an audible alert or notification (e.g., a beep or chime). In some embodiments, the output device(s) 1120 include one or more haptic devices for generating vibration, movement, or other haptic feedback. In some embodiments, all or a portion of the output device(s) 1120 may be integrated with the input device(s) 1115. For example, the input device(s) 1115 and the output device(s) 1120 may form a touchscreen or similar touch-sensitive display. In other embodiments, the output device(s) 1120 may be located near the input device(s) 1115.

[0185] The transceiver 1125 includes at least one transmitter 1130 and at least one receiver 1135. The one or more transmitters 1130 may be used to communicate with a UE, as described herein. Similarly, the one or more receivers 1135 may be used to communicate with a network function of a non-public network ("NPN"), a PLMN, and / or a RAN, as described herein. Although only one transmitter 1130 and one receiver 1135 are shown, the network device 1100 may have any suitable number of transmitters 1130 and receivers 1135. Moreover, the transmitters 1130 and receivers 1135 may be any suitable type of transmitter and receiver.

[0186] In one embodiment, the processor 1105 detects the video encoded traffic stream and the video codec specification used to encode the video encoded traffic stream. In one embodiment, the processor 1105 determines awareness of the video encoded traffic ADUs of the video encoded traffic stream as video encoded NAL units of data. In one embodiment, the processor 1105 aligns the video encoded NAL units of the video encoded traffic stream to partitions of physical layer ("PHY") transport elements and subsequent channel coding elements for video encoded traffic aware transport based at least on the determined awareness of the video encoded ADUs. In one embodiment, the processor 1105 aligning based at least on the determined awareness of the video encoded ADUs includes the processor 1105 mapping the video encoded NAL units to PHY transport elements based at least on the determined awareness of the video encoded ADUs.

[0187] In one embodiment, the processor 1105 determines an allocation of channel coding rates of partitions of the channel coding element based on the video-coded traffic-aware PHY transport. In one embodiment, the processor 1105 applies FEC coding to protect against over-the-air transmission errors, taking into account at least the determined allocation of channel coding rates of the video-coded traffic-aware PHY transport to partitions of the channel coding element.

[0188] In one embodiment, the processor 1105 determines awareness of ADUs of video coded traffic by at least one of identifying boundaries of individual NAL units contained therein and determining an assigned importance value to each NAL unit, where the importance value is derived by upper or higher layers and / or functions and signaled synchronously with the NAL unit via an information field encapsulated in at least one of upper layer protocol header information and control information elements aligned to the dedicated NAL unit.

[0189] In one embodiment, the processor 1105 determines one or more mTBs as flexible partition elements of the PHY TB, where the mTB includes variable length sized contiguous block segments of the TB with individually determined constant FEC channel coding rates and individual retransmission configuration capabilities based on negative acknowledgement ("NACK") receiver feedback, such that multiple consecutive mTBs partition the TB unevenly.

[0190] In one embodiment, the processor 1105 aligns the video-encoded NAL units by mapping at least one ADU to at least one of an encapsulation of at least one NAL unit data within one CB, an encapsulation of at least one NAL unit data within one CBG and / or mTB, and an encapsulation of a sequence of NAL unit data segments within the CBG and / or mTB.

[0191] In one embodiment, alignment of at least one NAL unit data of a video encoded traffic stream to a PHY transport element is performed within one CB by grouping the CBs within one CBG and / or mTB.

[0192] In one embodiment, the alignment of at least one of the NAL unit data, the plurality of NAL unit data, and the plurality of NAL unit data segments is mapped and contained within one CBG and / or mTB such that the data spans multiple CBs and the last CB of the sequence is formed as one of: a sequence of data bits that fully utilizes the size of the CB, a sequence of data bits that partially utilizes the size of the CB, where the free bits are utilized in a known, fixed bit sequence, and a sequence of data bits that partially utilizes the size of the CB, where the free bits are released to the PHY as additional resource for utilization.

[0193] In one embodiment, the processor 1105 utilizes the free bits released to the PHY as additional resources for radio reference signaling related procedures related to at least one of the following: DM-RS to assist the receiver in over-the-air detection, demodulation, and demapping; one of CSI-RS and SRS to assist the receiver in channel estimation procedures; and PT-RS to assist the receiver in phase noise tracking and phase noise correction procedures.

[0194] In one embodiment, the indication to the receiver of the released additional resources and their mapping to the PHY REs is performed by a pattern index in one of the DCI scheduling the PDSCH and / or PUSCH, the UCI requesting PUSCH scheduling and / or scheduling update, and the UCI associated with the PUSCH transmission.

[0195] In one embodiment, the processor 1105 configures a mapping of NAL unit data, a plurality of NAL unit data, and TB elements to one of at least one NAL unit data segment for video coded ADU traffic aware transmission via one of a semi-statically determined fixed size CBG configured to support individual CBG retransmission upon individual CBG NACK feedback from the receiver and a dynamically sized mTB configured to support individual mTB retransmission upon individual mTB NACK feedback from the receiver.

[0196] In one embodiment, the processor 1105 signals the determined video coded traffic awareness based on the TB of the at least one video coded ADU traffic-aware CBG via at least one of DCI scheduling of a corresponding PDSCH and / or PUSCH including the video coded traffic-aware CBG and a UCI request for the corresponding PDSCH and / or UCI associated with the PUSCH including the video coded traffic-aware CBG.

[0197] In one embodiment, the processor 1105 signals to the receiver the size of the dynamically sized mTB by at least one of a dedicated pattern and / or bit field in DM-RS signaling, DCI scheduling of the corresponding PDSCH and / or PUSCH including the mTB, a UCI request for corresponding PUSCH scheduling and / or scheduling update including the mTB, UCI related to the PUSCH transmission including the mTB, periodic information signaling of DCI aligned with the SFI, and frontload bit field signaling embedded in the TB containing the mTB, where the bit field is encoded with a predetermined FEC code.

[0198] In one embodiment, the processor 1105 determines a predetermined minimum size limit for an mTB within a TB to avoid channel coding loss of short codewords due to excessive segmentation of the TB into short-sized mTBs, and multiple NAL unit data may be combined within such an mTB to meet the minimum size limit.

[0199] In one embodiment, the processor 1105 partitions the mTB of size S into M CBs, where M is:

number

number

[0200] In one embodiment, a subset of non-VCL NAL units are not considered for alignment of NAL units to CBGs and / or mTBs to reduce alignment complexity, but all CBs, CBGs, and / or mTBs that include non-VCL NAL units of the subset are indicated to the receiver by one of a special index of DCI incorporated in the scheduling of the PDSCH and / or PUSCH that includes the CB, CBG, and / or mTB, a special index of UCI incorporated in the scheduling and / or scheduling update request of the PUSCH that includes the CB, CBG, and / or mTB, and a special index of UCI incorporated in the UCI associated with the PUSCH transmission that includes the CB, CBG, and / or mTB.

[0201] In one embodiment, the processor 1105 is configured to determine whether the CBG and / or mTB contained in the TB are a preselected finite discrete ordered superset R = {R i |0 ≦ i < n, n∈N, 0 < R i < R j < 1 ∀i, j, i < j}, the TB is FEC encoded using UEP such that it is assigned a varying code rate based on

[0202] In one embodiment, the processor 1105 indicates to the receiver the assigned coding rates from the rate-compatible superset R for the individual CBGs and / or mTBs forming the UEP coded TB by a bit field configuration contained in at least one of the DM-RS signaling resource, the DCI for scheduling the PDSCH and / or PUSCH including the CBG and / or mTB of the UEP TB, the UCI request for corresponding PUSCH scheduling and / or scheduling update including the CBG and / or mTB of the UEP TB, the UCI related to the PUSCH transmission including the CBG and / or mTB of the UEP TB, the periodic information signaling of the DCI aligned with the SFI, and the frontload information field of the UEP TB encoded with a predefined FEC code.

[0203] In one embodiment, the allocation of individual coding rates to the CBGs and / or mTBs forming the UEP TB is carried out by assigning at least two different coding rates to the CBGs and / or mTBs, R 1 < R 2 whereby a first lower coding rate R 1 is used, and a second higher coding rate R2 is used inversely proportional to the importance value of the NAL unit data contained in the CBG and / or mTB, within the combined constraints of the available radio link resources and the estimated coding bit rate capacity over the transmission interval of the TB on statistical information.

[0204] In one embodiment, the rate-compatible superset R further includes coding rates "1" and "0", where coding rate "1" indicates non-FEC coded transmission of associated CBGs and / or mTBs with assigned coding rate "1" and coding rate "0" indicates discarding for transmission of associated CBGs and / or mTBs with assigned coding rate "0".

[0205] 12 is a flow diagram of a method 1200 for video codec-aware RAN configuration and unequal error protection coding. The method 1200 may be performed by a network entity, such as a base node, a gNB, and / or a network equipment device 1100. In some embodiments, the method 1200 may be performed by a processor executing program code, e.g., a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, etc.

[0206] In one embodiment, the method 1200 includes detecting 1205 a video encoded traffic stream and a video codec specification used to encode the video encoded traffic stream. In one embodiment, the method 1200 includes determining 1210 awareness of video encoded traffic ADUs of the video encoded traffic stream as video encoded NAL units of data. In one embodiment, the method 1200 includes 1215 aligning, based on at least the determined awareness of the video encoded ADUs, the video encoded NAL units of the video encoded traffic stream to partitions of PHY transport elements and subsequent channel encoding elements for video encoded traffic aware PHY transport.

[0207] In one embodiment, the method 1200 includes determining 1220 an allocation of channel coding rates of partitions of channel coding elements based on the video coded traffic aware PHY transport. In one embodiment, the method 1200 includes applying 1225 FEC coding, taking into account at least the determined allocation of channel coding rates of the video coded traffic aware PHY transport to partitions of channel coding elements, to protect against over-the-air transmission errors, and the method 1200 ends.

[0208] 13 is a flow diagram of a method 1300 for video codec-aware RAN configuration and unequal error protection coding. The method 1300 may be performed by a remote unit 105, such as a UE or user equipment device 1000. In some embodiments, the method 1300 may be performed by a processor executing program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0209] In one embodiment, the method 1300 includes receiving 1305 an indication of variable length and / or variable code rate TB partition elements aligned to a plurality of NAL units. In one embodiment, the method 1300 includes receiving 1310 a variable length and / or variable code rate TB partition element aligned to a NAL unit.

[0210] In one embodiment, the method 1300 includes a step 1315 of decoding the FEC encoding of the plurality of video encoded NAL unit data contained in the TB partition element. In one embodiment, the method 1300 includes a step 1320 of reconstructing and decoding a video encoded stream transmitted for video playback using the plurality of video encoded NAL unit data, and the method 1300 ends.

[0211] A first apparatus for video codec-aware RAN configuration and unequal error protection coding is disclosed. The first apparatus may include a network entity such as a base node, a gNB, and / or a network equipment device 1100. In some embodiments, the first apparatus includes a processor that executes program code, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, etc.

[0212] In one embodiment, the first apparatus includes a processor that detects a video encoded traffic stream and a video codec specification used to encode the video encoded traffic stream. In one embodiment, the processor determines awareness of video encoded traffic application data units ("ADUs") of the video encoded traffic stream as video encoded network abstraction layer ("NAL") units of data. In one embodiment, the processor aligns the video encoded NAL units of the video encoded traffic stream to partitions of physical layer ("PHY") transport elements and subsequent channel coding elements for video encoded traffic aware transport based at least on the determined awareness of the video encoded ADUs.

[0213] In one embodiment, the processor determines an assignment of channel coding rates of partitions of the channel coding element based on the video-coded traffic-aware PHY transport. In one embodiment, the processor applies forward error correction ("FEC") coding to protect against over-the-air transmission errors, taking into account at least the determined assignment of channel coding rates of the video-coded traffic-aware PHY transport to partitions of the channel coding element.

[0214] In one embodiment, the processor determines awareness of a video coding traffic ADU by at least one of identifying boundaries of individual NAL units contained therein and determining an assigned importance value to each NAL unit, the importance value being derived by an upper or higher layer and / or function and signaled synchronously with the NAL unit via an information field encapsulated in at least one of upper layer protocol header information and a control information element aligned to the dedicated NAL unit.

[0215] In one embodiment, the processor determines one or more mini transport blocks ("mTBs") as flexible partition elements of the PHY TB, where the mTBs include variable length sized contiguous block segments of the TB with individually determined constant forward error correction ("FEC") channel coding rates and individual retransmission configuration capabilities based on negative acknowledgement ("NACK") receiver feedback, such that multiple consecutive mTBs non-uniformly partition the TB.

[0216] In one embodiment, the processor aligns video-encoded NAL units by mapping at least one ADU to at least one of an encapsulation of at least one NAL unit data within one coding block ("CB"), an encapsulation of at least one NAL unit data within one CB group ("CBG") and / or mTB, and an encapsulation of a sequence of NAL unit data segments within the CBG and / or mTB.

[0217] In one embodiment, alignment of at least one NAL unit data of a video encoded traffic stream to a PHY transport element is performed within one CB by grouping the CBs within one CBG and / or mTB.

[0218] In one embodiment, the alignment of at least one of the NAL unit data, the plurality of NAL unit data, and the plurality of NAL unit data segments is mapped and contained within one CBG and / or mTB such that the data spans multiple CBs and the last CB of the sequence is formed as one of: a sequence of data bits that fully utilizes the size of the CB, a sequence of data bits that partially utilizes the size of the CB, where the free bits are utilized in a known, fixed bit sequence, and a sequence of data bits that partially utilizes the size of the CB, where the free bits are released to the PHY as additional resource for utilization.

[0219] In one embodiment, the processor utilizes the free bits released to the PHY as additional resources for over-the-air reference signaling related procedures related to at least one of a demodulation reference signal ("DM-RS") to assist the receiver in over-the-air detection, demodulation, and demapping, one of a channel state information reference signal ("CSI-RS") and a sounding reference signal ("SRS") to assist the receiver in channel estimation procedures, and a phase tracking reference signal ("PT-RS") to assist the receiver in phase noise tracking and phase noise correction procedures.

[0220] In one embodiment, the indication to the receiver of the released additional resources and their mapping to PHY resource elements ("RE") is performed by a pattern index in one of the downlink control information ("DCI") scheduling the physical downlink shared channel ("PDSCH") and / or the physical uplink shared channel ("PUSCH"), the uplink control information ("UCI") requesting PUSCH scheduling and / or a scheduling update, and the UCI associated with the PUSCH transmission.

[0221] In one embodiment, the processor configures a mapping of NAL unit data, a plurality of NAL unit data, and TB elements to one of at least one NAL unit data segment for video coded ADU traffic-aware transmission via one of a semi-statically determined fixed size CBG configured to support individual CBG retransmissions upon individual CBG NACK feedback from the receiver and a dynamically sized mTB configured to support individual mTB retransmissions upon individual mTB NACK feedback from the receiver.

[0222] In one embodiment, the processor signals the determined video coded traffic awareness based on a TB of the at least one video coded ADU traffic-aware CBG via at least one of DCI scheduling of a corresponding PDSCH and / or PUSCH including the video coded traffic-aware CBG and a UCI request for the corresponding PDSCH and / or UCI associated with the PUSCH including the video coded traffic-aware CBG.

[0223] In one embodiment, the processor signals to the receiver the size of the dynamically sized mTB by at least one of a dedicated pattern and / or bit field in DM-RS signaling, DCI scheduling of the corresponding PDSCH and / or PUSCH including the mTB, a UCI request for corresponding PUSCH scheduling and / or scheduling update including the mTB, UCI related to the PUSCH transmission including the mTB, periodic information signaling of the DCI aligned with a slot format indicator ("SFI"), and frontload bit field signaling embedded in a TB containing the mTB, where the bit field is encoded with a predetermined FEC code.

[0224] In one embodiment, the processor determines a predetermined minimum size limit for an mTB within a TB to avoid channel coding loss of short codewords due to excessive segmentation of the TB into short-sized mTBs, and multiple NAL unit data may be combined within such an mTB to meet the minimum size limit.

[0225] In one embodiment, the processor partitions an mTB of size S into M CBs, where M is:

number

number

[0226] In one embodiment, a subset of non-video coding layer ("non-VCL") NAL units are not considered for alignment of NAL units to CBGs and / or mTBs to reduce alignment complexity, but all CBs, CBGs, and / or mTBs that include the subset of non-VCL NAL units are indicated to the receiver by one of a special index of DCI incorporated in the scheduling of the PDSCH and / or PUSCH that includes the CB, CBG, and / or mTB, a special index of UCI incorporated in the scheduling and / or scheduling update request of the PUSCH that includes the CB, CBG, and / or mTB, and a special index of UCI incorporated in the UCI associated with the PUSCH transmission that includes the CB, CBG, and / or mTB.

[0227] In one embodiment, the processor is configured to determine whether the CBG and / or mTB contained in the TB are a preselected finite discrete ordered superset R = {R i |0 ≦ i < n, n∈N, 0 < R i < R j < 1 ∀i, j, i < j}, the TBs are FEC encoded with unequal error protection ("UEP") such that they are assigned varying code rates based on

[0228] In one embodiment, the processor indicates to the receiver the assigned coding rates from the rate-compatible superset R for the individual CBGs and / or mTBs forming the UEP coded TB by a bit field configuration contained in at least one of the DM-RS signaling resource, the DCI for scheduling the PDSCH and / or PUSCH including the CBG and / or mTB of the UEP TB, the UCI request for corresponding PUSCH scheduling and / or scheduling update including the CBG and / or mTB of the UEP TB, the UCI related to the PUSCH transmission including the CBG and / or mTB of the UEP TB, the periodic information signaling of the DCI aligned with the SFI, and the frontload information field of the UEP TB encoded with a predefined FEC code.

[0229] In one embodiment, the allocation of individual coding rates to the CBGs and / or mTBs forming the UEP TB is carried out by assigning at least two different coding rates to the CBGs and / or mTBs, R 1 < R 2 whereby a first lower coding rate R 1 is used, and a second higher coding rate R 2 is used inversely proportional to the importance value of the NAL unit data contained in the CBG and / or mTB, within the combined constraints of the available radio link resources and the estimated coding bit rate capacity over the transmission interval of the TB on statistical information.

[0230] In one embodiment, the rate-compatible superset R further includes coding rates "1" and "0", where coding rate "1" indicates non-FEC coded transmission of associated CBGs and / or mTBs with assigned coding rate "1" and coding rate "0" indicates discarding for transmission of associated CBGs and / or mTBs with assigned coding rate "0".

[0231] A first method for video codec-aware RAN configuration and unequal error protection coding is disclosed. The first method may be performed by a network entity, such as a base node, a gNB, and / or a network equipment device 1100. In some embodiments, the first method may be performed by a processor executing program code, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, etc.

[0232] In one embodiment, the first method includes detecting a video encoded traffic stream and a video codec specification used to encode the video encoded traffic stream. In one embodiment, the first method includes determining awareness of video encoded traffic application data units ("ADUs") of the video encoded traffic stream as video encoded network abstraction layer ("NAL") units of data. In one embodiment, the first method includes aligning video encoded NAL units of the video encoded traffic stream to partitions of physical layer ("PHY") transport elements and subsequent channel coding elements for video encoded traffic aware transport based at least on the determined awareness of the video encoded ADUs.

[0233] In one embodiment, the first method includes determining an allocation of channel coding rates of partitions of a channel coding element based on the video-coded traffic-aware PHY transport. In one embodiment, the first method includes applying forward error correction ("FEC") coding, taking into account at least the determined allocation of channel coding rates of the video-coded traffic-aware PHY transport to partitions of the channel coding element, to protect against errors in over-the-air transmissions.

[0234] In one embodiment, a first method includes determining awareness of a video coding traffic ADU by at least one of identifying boundaries of individual NAL units contained therein and determining an assigned importance value to the individual NAL units, the importance value being derived by an upper or higher layer and / or function and signaled synchronously with the NAL unit via an information field encapsulated in at least one of upper layer protocol header information and a control information element aligned to the dedicated NAL unit.

[0235] In one embodiment, a first method includes determining one or more mini transport blocks ("mTBs") as flexible partition elements of a PHY TB, where the mTBs include variable-length sized contiguous block segments of the TB with individually determined constant forward error correction ("FEC") channel coding rates and individual retransmission configuration capabilities based on negative acknowledgement ("NACK") receiver feedback, such that multiple consecutive mTBs non-uniformly partition the TB.

[0236] In one embodiment, a first method includes aligning video-encoded NAL units by mapping at least one ADU to at least one of an encapsulation of at least one NAL unit data within one coding block ("CB"), an encapsulation of at least one NAL unit data within one CB group ("CBG") and / or mTB, and an encapsulation of a sequence of NAL unit data segments within the CBG and / or mTB.

[0237] In one embodiment, alignment of at least one NAL unit data of a video encoded traffic stream to a PHY transport element is performed within one CB by grouping the CBs within one CBG and / or mTB.

[0238] In one embodiment, the alignment of at least one of the NAL unit data, the plurality of NAL unit data, and the plurality of NAL unit data segments is mapped and contained within one CBG and / or mTB such that the data spans multiple CBs and the last CB of the sequence is formed as one of: a sequence of data bits that fully utilizes the size of the CB, a sequence of data bits that partially utilizes the size of the CB, where the free bits are utilized in a known, fixed bit sequence, and a sequence of data bits that partially utilizes the size of the CB, where the free bits are released to the PHY as additional resource for utilization.

[0239] In one embodiment, the first method includes utilizing the free bits released in the PHY as additional resources for related procedures of over-the-air reference signaling related to at least one of a demodulation reference signal ("DM-RS") that assists the receiver in over-the-air detection, demodulation, and demapping, one of a channel state information reference signal ("CSI-RS") and a sounding reference signal ("SRS") that assists the receiver in channel estimation procedures, and a phase tracking reference signal ("PT-RS") that assists the receiver in phase noise tracking and phase noise correction procedures.

[0240] In one embodiment, the indication to the receiver of the released additional resources and their mapping to PHY resource elements ("RE") is performed by a pattern index in one of the downlink control information ("DCI") scheduling the physical downlink shared channel ("PDSCH") and / or the physical uplink shared channel ("PUSCH"), the uplink control information ("UCI") requesting PUSCH scheduling and / or a scheduling update, and the UCI associated with the PUSCH transmission.

[0241] In one embodiment, the first method includes configuring a mapping of NAL unit data, a plurality of NAL unit data, and TB elements to one of at least one NAL unit data segment for video coded ADU traffic-aware transmission via one of a semi-statically determined fixed size CBG configured to support individual CBG retransmissions upon individual CBG NACK feedback from the receiver and a dynamically sized mTB configured to support individual mTB retransmissions upon individual mTB NACK feedback from the receiver.

[0242] In one embodiment, the first method includes signaling the determined video coded traffic awareness based on a TB of the at least one video coded ADU traffic-aware CBG via at least one of DCI scheduling of a corresponding PDSCH and / or PUSCH including the video coded traffic-aware CBG and a UCI request for the corresponding PDSCH and / or UCI related to the PUSCH including the video coded traffic-aware CBG.

[0243] In one embodiment, the first method includes signaling the size of the dynamically sized mTB to a receiver by at least one of a dedicated pattern and / or bit field in DM-RS signaling, DCI scheduling of a corresponding PDSCH and / or PUSCH including the mTB, a UCI request for corresponding PUSCH scheduling and / or scheduling update including the mTB, UCI related to a PUSCH transmission including the mTB, periodic information signaling of DCI aligned with a slot format indicator ("SFI"), and frontload bit field signaling embedded in a TB containing the mTB, where the bit field is encoded with a predefined FEC code.

[0244] In one embodiment, the first method includes a step of determining a predetermined minimum size limit for an mTB within a TB to avoid channel coding loss of short codewords due to excessive segmentation of the TB into short-sized mTBs, and multiple NAL unit data may be combined within such an mTB to meet the minimum size limit.

[0245] In one embodiment, the first method comprises partitioning an mTB of size S into M CBs, where M is:

number

number

[0246] In one embodiment, a subset of non-video coding layer ("non-VCL") NAL units are not considered for alignment of NAL units to CBGs and / or mTBs to reduce alignment complexity, but all CBs, CBGs, and / or mTBs that include the subset of non-VCL NAL units are indicated to the receiver by one of a special index of DCI incorporated in the scheduling of the PDSCH and / or PUSCH that includes the CB, CBG, and / or mTB, a special index of UCI incorporated in the scheduling and / or scheduling update request of the PUSCH that includes the CB, CBG, and / or mTB, and a special index of UCI incorporated in the UCI associated with the PUSCH transmission that includes the CB, CBG, and / or mTB.

[0247] In one embodiment, the first method is to select a CBG and / or mTB contained in the TB from a preselected finite discrete ordered superset R = {R i |0 ≦ i < n, n∈N, 0 < R i < R j < 1 ∀i, j, i < j}, FEC encoding the TBs with unequal error protection ("UEP") such that the TBs are allocated varying coding rates based on

[0248] In one embodiment, the first method includes indicating to the receiver assigned coding rates from a rate-compatible superset R for individual CBGs and / or mTBs forming the UEP coded TB by bit field configurations contained in at least one of: a DM-RS signaling resource; a DCI for scheduling a PDSCH and / or PUSCH including a CBG and / or mTB of the UEP TB; a UCI request for corresponding PUSCH scheduling and / or scheduling update including the CBG and / or mTB of the UEP TB; a UCI related to a PUSCH transmission including the CBG and / or mTB of the UEP TB; periodic information signaling of the DCI aligned with the SFI; and a frontload information field of the UEP TB encoded with a predefined FEC code.

[0249] In one embodiment, the allocation of individual coding rates to the CBGs and / or mTBs forming the UEP TB is carried out by assigning at least two different coding rates to the CBGs and / or mTBs, R 1 < R 2 whereby a first lower coding rate R 1 is used, and a second higher coding rate R 2 is used inversely proportional to the importance value of the NAL unit data contained in the CBG and / or mTB, within the combined constraints of the available radio link resources and the estimated coding bit rate capacity over the transmission interval of the TB on statistical information.

[0250] In one embodiment, the rate-compatible superset R further includes coding rates "1" and "0", where coding rate "1" indicates non-FEC coded transmission of associated CBGs and / or mTBs with assigned coding rate "1" and coding rate "0" indicates discarding for transmission of associated CBGs and / or mTBs with assigned coding rate "0".

[0251] A second apparatus for video codec-aware RAN configuration and unequal error protection coding is disclosed. The second apparatus may include a remote unit 105, such as a UE or user equipment device 1000. In some embodiments, the second apparatus includes a processor that executes program code, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, etc.

[0252] In one embodiment, the second apparatus includes a transceiver that receives an indication of variable length and / or variable code rate transport block ("TB") partition elements aligned to a plurality of network abstraction layer ("NAL") units and receives the variable length and / or variable code rate TB partition elements aligned to the NAL units.

[0253] In one embodiment, the second device includes a processor that decodes forward error correction ("FEC") encoding of the plurality of video encoded NAL unit data contained in the TB partition element and uses the received plurality of video encoded NAL unit data to reconstruct and decode the transmitted video encoded stream for video playback.

[0254] A second method for video codec-aware RAN configuration and unequal error protection coding is disclosed. The second method may be performed by a remote unit 105, such as a UE or user equipment device 1000. In some embodiments, the second method may be performed by a processor executing program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0255] In one embodiment, the second method includes receiving an indication of variable length and / or variable code rate transport block ("TB") partition elements aligned with a plurality of network abstraction layer ("NAL") units, and receiving the variable length and / or variable code rate TB partition elements aligned with the NAL units.

[0256] In one embodiment, the second method includes decoding forward error correction ("FEC") encoding of the plurality of video encoded NAL unit data contained in the TB partition element, and using the received plurality of video encoded NAL unit data to reconstruct and decode the transmitted video encoded stream for video playback.

[0257] The embodiments may be embodied in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is therefore indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope. [Explanation of symbols]

[0258] 100 Wireless communication system 105 Remote Unit 107 Applications 115 5G-RAN 120 3GPP Access Network 121 Cellular Base Unit 123 3GPP communication links 130 Non-3GPP Access Networks, Non-3GPP RAN 131 Access Points 133 Non-3GPP Communication Links 135 Interworking Entities 140 Mobile Core Network 141 UPF 142 Application Server 143 AMF 145 SMF 147 PCF 148 AUSF 149 UDM / UDR 150 Data Network 160 Data Network 202 Application Server 203 XR UE device 204 Local Video Content 205 Core Network 206 Remote Video Content 208 Wireless Access Network 210 Content Delivery Gateway 212 XR engine 302 Pictures 306 Intra Prediction 308 Inter Prediction 310 Multi-dimensional (2D / 3D) spatial multi-modal transformation 316 bitstream 402 Application Server 404CN 406 RAN 408 QoS Flow 410 SDAP Layer 412 PDCP 414 RLC 416 MAC Layer 418 PHY Layer 502 NAL Units 504 Header 506 NAL Payload 601 VIDEO ENCODED NAL DATA DETECTOR AND IMPORTANCE INDICATOR, NAL DATA IMPORTANCE INDICATOR 602 Application Server 604CN UPF 606 RAN 702 IP packets 802a~d slices 804a~e CBG / mTB 902 CBG / mTB aligned to NAL unit data with higher importance rating 904 CBG / mTB aligned to NAL unit data with lower importance 1000 User Equipment Device 1005 Processor 1010 Memory 1015 Input Devices 1020 output device 1025 Transceiver 1030 Transmitter 1035 Receiver 1040 Network Interface 1045 Application Interface 1100 Network Equipment 1105 Processor 1110 Memory 1115 Input Devices 1120 Output Device 1125 Transceiver 1130 Transmitter 1135 Receiver 1140 Network Interface 1145 Application Interface 1200 methods 1300 methods

Claims

1. 1. A wireless transmitter device comprising: a processor, the processor comprising: Detecting a video encoded traffic stream and a video codec specification used to encode the video encoded traffic stream; determining awareness of application data units ("ADUs") of video coded traffic of the video coded traffic stream as video coded network abstraction layer ("NAL") units of data; aligning the video coded NAL units of the video coded traffic stream to partitions of physical layer ("PHY") transport elements and subsequent channel coding elements for video coded traffic aware transport based on at least the determined awareness of the video coded ADUs; determining an allocation of channel coding rates for partitions of the channel coding element based on the video coded traffic aware PHY transport; applying forward error correction ("FEC") coding taking into account at least the allocation of the determined channel coding rate of said video coded traffic aware PHY transport to partitions of channel coding elements to protect against errors in the over-the-air transmission; A wireless transmitter device.

2. The processor, Identifying the boundaries of the individual NAL units contained within; determining an assigned importance value for each NAL unit, the importance value being derived by an upper or higher layer and / or function and signaled synchronously with the NAL unit via an information field encapsulated in at least one of upper layer protocol header information and a control information element aligned to a dedicated NAL unit; The apparatus of claim 1 , further comprising: a first ADU for determining whether the ADU is aware of the video encoded traffic;

3. 2. The apparatus of claim 1, wherein the processor determines one or more mini transport blocks ("mTBs") as flexible partition elements of a PHY transport block ("TB"), the mTBs including variable length sized contiguous block segments of the TB including one or more coding blocks ("CBs") with individually determined constant forward error correction ("FEC") channel coding rates and individual retransmission configuration capabilities based on negative acknowledgment ("NACK") receiver feedback, such that multiple consecutive mTBs partition the transport block ("TB") non-uniformly.

4. The processor, encapsulation of at least one NAL unit data within one CB; encapsulation of at least one NAL unit data within one CB group ("CBG") and / or mTB; Encapsulation of sequences of NAL unit data segments within a CBG and / or mTB and 4. The apparatus of claim 3, further comprising: an apparatus for aligning the video-encoded NAL units by mapping at least one ADU to at least one of the NAL units.

5. The alignment of at least one of the NAL unit data, the plurality of NAL unit data, and the plurality of NAL unit data segments is such that the data spans a plurality of CBs, and the last CB of the sequence is a sequence of data bits that fully utilizes the size of said CB; a sequence of data bits that partially utilizes the size of the CB, where free bits are utilized in a known, fixed bit sequence; a sequence of data bits that partially utilizes the size of the CB, with free bits being released to the PHY as additional resources for utilization; The device of claim 4, wherein the CBG and / or mTB are mapped and contained within one CBG and / or mTB so as to form one of the CBG and / or mTB.

6. The processor, a demodulation reference signal ("DM-RS") to aid in the receiver's radio detection, demodulation, and demapping; one of a Channel State Information Reference Signal ("CSI-RS") and a Sounding Reference Signal ("SRS") to assist the receiver in a channel estimation procedure; a phase tracking reference signal ("PT-RS") that assists the receiver in phase noise tracking and phase noise correction procedures; 6. The apparatus of claim 5, further comprising: a PHY for receiving a radio reference signal from a PHY in accordance with a first embodiment of the present invention;

7. an indication to the receiver of the released additional resources and a mapping of the released additional resources to PHY resource elements ("REs"); Downlink control information ("DCI") for scheduling a physical downlink shared channel ("PDSCH") and / or a physical uplink shared channel ("PUSCH"); uplink control information ("UCI") requesting PUSCH scheduling and / or scheduling updates; UCI related to PUSCH transmission; The apparatus of claim 5 , wherein the pattern index is in one of:

8. The processor, a semi-statically determined fixed size CBG configured to support individual CBG retransmissions upon individual CBG NACK feedback from the receiver; a dynamically sized mTB configured to support individual mTB retransmissions upon individual mTB NACK feedback from the receiver; 5. The apparatus of claim 4, further comprising: a TB element mapping for a video-encoded ADU traffic-aware transmission over one of the NAL unit data, the plurality of NAL unit data, and the at least one NAL unit data segment.

9. The processor, based on a TB of at least one video encoded ADU traffic aware CBG, - scheduling of DCI for a corresponding PDSCH and / or PUSCH including the video coded traffic aware CBG; a UCI request for a corresponding PDSCH and / or a UCI associated with a PUSCH including the video coded traffic aware CBG; The apparatus of claim 8, further comprising: a signaling unit configured to signal awareness of the determined video encoded traffic via at least one of:

10. The processor, Dedicated patterns and / or bit fields in DM-RS signaling; DCI scheduling of a corresponding PDSCH and / or PUSCH including the mTB; and a UCI request for a corresponding PUSCH scheduling and / or scheduling update that includes the mTB; and UCI associated with a PUSCH transmission including the mTB; periodic information signaling of DCI aligned with a slot format indicator ("SFI"); front-loaded bit-field signaling embedded in a TB included in the mTB, the bit-field being encoded with a predefined FEC code; 10. The apparatus of claim 8, further comprising: a signaling unit for signaling a size of the dynamically sized mTB to a receiver by at least one of:

11. The processor is configured to select a preselected finite discrete ordered superset R = {R i |0 ≦ i < n, n∈N, 0 < R i < R j 5. The apparatus of claim 4, further comprising: FEC encoding the TBs with unequal error protection ("UEP") such that the TBs are assigned varying code rates based on {i, j, i < j}.

12. The processor, DM-RS signaling resources; and DCI for scheduling a PDSCH and / or a PUSCH including a CBG and / or an mTB of a UEP TB; a UCI request for a corresponding PUSCH scheduling and / or scheduling update including the CBG and / or the mTB of the UEP TB; UCI associated with a PUSCH transmission including the CBG and / or the mTB of the UEP TB; periodic information signaling of DCI aligned with SFI; a frontload information field of the UEP TB encoded with a predefined FEC code; 12. The apparatus of claim 11, further comprising: a bit field configuration included in at least one of the bit field configurations indicating to a receiver an assigned coding rate from the rate-compatible superset R for each of the CBGs and / or mTBs forming a UEP-coded TB.

13. The allocation of individual coding rates to the CBG and / or the mTB forming the UEP TB is performed by allocating at least two different coding rates, and R 1 < R 2 whereby a first lower coding rate R 1 is used, and a second higher coding rate R 2 The apparatus of claim 12, wherein the CBG and / or mTB are used within the combined constraints of an estimated coding bit rate capacity over a transmission interval of the TB on available radio link resources and statistical information, inversely proportional to the importance value of the NAL unit data contained in the CBG and / or mTB.

14. 1. A method in a wireless transmitter device, comprising: detecting a video encoded traffic stream and a video codec specification used to encode said video encoded traffic stream; determining awareness of video coded traffic Application Data Units ("ADUs") of the video coded traffic stream as video coded Network Abstraction Layer ("NAL") units of data; aligning the video coded NAL units of the video coded traffic stream to partitions of physical layer ("PHY") transport elements and subsequent channel coding elements for video coded traffic aware transport based on at least the determined awareness of the video coded ADUs; determining an allocation of channel coding rates for partitions of the channel coding element based on the video coded traffic aware PHY transport; applying forward error correction ("FEC") coding taking into account at least the allocation of the determined channel coding rate of said video coded traffic aware PHY transport to partitions of channel coding elements to protect against errors in the wireless transmission; 23. A method in a wireless transmitter device comprising:

15. A receiver node device, A transceiver comprising: receiving an indication of variable length and / or variable code rate transport block ("TB") partition elements aligned with a plurality of network abstraction layer ("NAL") units; a transceiver for receiving TB partition elements of variable length and / or variable code rate aligned to the NAL units; 1. A processor comprising: Decoding a forward error correction ("FEC") encoding of the plurality of video-encoded NAL unit data contained in the TB partition element; a processor that uses the received plurality of video encoded NAL unit data to reconstruct and decode a transmitted video encoded stream for video playback; A receiver node apparatus comprising:

Images