CN112385262A - Techniques in resource utilization and quality of service support in new air interface vehicle to ten-thousand side link communications - Google Patents

Abstract

Embodiments of the present disclosure describe methods, apparatus, storage media, and systems for configuring efficient data transfer via a new air vent (NR) vehicle-to-everything (V2X) sidelink operation. Various embodiments describe how to exploit various QoS requirements associated with different use cases and enable multiplexing/demultiplexing of data packets of different user equipments onto the same Medium Access Control (MAC) Protocol Data Unit (PDU). This implementation may improve UE and/or network efficiency in NR V2X sidelink communications. Other embodiments may be described and claimed.

Description

Techniques in resource utilization and quality of service support in new air interface vehicle to ten-thousand side link communications

Cross Reference to Related Applications

Priority of U.S. provisional patent application No. 62/780,877 entitled "Methods for Efficient Resource Utilization and QoS Support for NR V2X sildelink UE", filed on 12/17/2018, the entire disclosure of which is hereby incorporated by reference in its entirety.

Technical Field

Embodiments of the present invention generally relate to the field of wireless communications.

Background

The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure. Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this disclosure and are not admitted to be prior art by inclusion in this section.

Various use case requirements for advanced vehicle to everything (V2X) in communications involving the fifth generation (5G) new air interface (NR) include unicast, multicast, broadcast and other appropriate modes of communication. Existing sidelink V2X (V2X) communications may not efficiently use network resources according to different quality of service (QoS) requirements associated with various use case scenarios.

Drawings

The embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings.

Fig. 1 schematically illustrates AN example of a network including a User Equipment (UE) and AN Access Node (AN) in a wireless network, in accordance with various embodiments.

Fig. 2 illustrates example components of a device, in accordance with various embodiments.

Fig. 3A illustrates an example Radio Frequency Front End (RFFE) that includes a millimeter wave (mmWave) RFFE and one or more sub-millimeter wave Radio Frequency Integrated Circuits (RFICs), in accordance with some embodiments. Fig. 3B illustrates an alternative RFFE, in accordance with various embodiments.

Fig. 4A-4D illustrate some example Medium Access Control (MAC) subheaders, in accordance with various embodiments.

Fig. 5A illustrates an example MAC Control Element (CE) when formatting a control message, in accordance with various embodiments. Fig. 5B illustrates an example MAC Protocol Data Unit (PDU) format.

Fig. 6A illustrates an operational flow/algorithm structure of a process from a sender UE perspective that facilitates initiating NR V2X sidelink communications from the sender UE perspective, in accordance with various embodiments. Fig. 6B illustrates an operational flow/algorithm structure of a process from the perspective of a receiving UE that facilitates initiating NR V2X sidelink communications from the perspective of a sending UE, in accordance with various embodiments.

Fig. 7 illustrates example interfaces of baseband circuitry, in accordance with some embodiments.

FIG. 8 illustrates hardware resources, in accordance with some embodiments.

Detailed Description

In the following detailed description, reference is made to the accompanying drawings which form a part hereof wherein like numerals designate like parts throughout, and in which is shown by way of illustration embodiments which may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. The following detailed description is, therefore, not to be taken in a limiting sense.

Various operations may be described as multiple discrete actions or operations in turn, in a manner that is most helpful in understanding the claimed subject matter. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may be performed out of the order presented. The operations described may be performed in a different order than the described embodiments. Various additional operations may be performed in additional embodiments and/or described operations may be omitted.

For the purposes of this disclosure, the phrases "a or B" and "a and/or B" mean (a), (B), or (a and B). For the purposes of this disclosure, the phrases "A, B or C" and "A, B and/or C" mean (a), (B), (C), (a and B), (a and C), (B and C), or (A, B and C).

The description may use the phrases "in an embodiment" or "in embodiments," which may each refer to one or more of the same or different embodiments. Furthermore, the terms "comprising," "including," "having," and the like, as used with respect to embodiments of the present disclosure, are synonymous.

As used herein, the term "circuitry" may refer to, may be part of, or may include any combination of integrated circuits (e.g., Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), etc.), discrete circuits, combinational logic circuits, system on a chip (SOC), system in a package (SiP) that provide the described functionality. In some embodiments, circuitry may execute one or more software or firmware modules to provide the described functionality. In some embodiments, the circuitry may comprise logic operable, at least in part, in hardware.

As used herein, the term "V-UE" or "vehicular UE" may refer to, may be part of, or may include any combination of UEs, which are further described below with reference to fig. 1. V-UE or vehicle UE may refer to, may be part of, or may include any combination of vehicle systems. Throughout this disclosure, "UE," "V-UE," and "vehicle UE" are used interchangeably, unless stated otherwise.

The advanced V2X use case has surpassed road safety applications. Advanced V2X in NR-enabled communication may be adapted to various requirements according to various use cases. These requirements may include, but are not limited to, latency, end-to-end reliability, payload, transmission rate, data rate, and minimum required communication range. In general, the payload may be measured in bytes or similar units. The transmission rate may be measured in number of messages per second or similar units. The maximum end-to-end delay may be measured in milliseconds (ms) or similar units. Reliability may be measured in percentage or similar units. The data rate may be measured in megabytes per second (Mbps) or similar units. The minimum required communication range may be measured in meters or similar units. For example, the latency of V2X communication may need to be as small as 3ms due to an emergency trajectory, and may be up to 100ms for some less critical scenarios. End-to-end reliability may need to be in the range of 90-99.999%. Example data rates may require up to 1000Mbps for an extended sensor use case. Some of these requirements may be more stringent than the basic V2X use cases in Long Term Evolution (LTE) V2X communications. The existing LTE QoS framework may not be suitable for meeting these ranges of requirements.

Embodiments described herein may include, for example, apparatus, methods, and storage media for configuring efficient data transmission via NR V2X side link operations. Embodiments may support various QoS requirements associated with different use cases and enable multiplexing/demultiplexing of data packets for different UEs onto the same Medium Access Control (MAC) Protocol Data Unit (PDU). This implementation may improve UE and/or network efficiency in NR V2X sidelink communications.

Fig. 1 schematically illustrates an example wireless network 100 (hereinafter "network 100"), in accordance with various embodiments herein. Network 100 may include a UE105 in wireless communication with AN 110. In some embodiments, the network 100 may be an NR SA network. The UE105 may be configured, for example, to connect to communicatively couple with AN 110. In this example, connection 112 is shown as an air interface to enable communicative coupling and may conform to a cellular communication protocol, such as the 5G NR protocol operating at mmWave and sub-6GHz, global system for mobile communications (GSM) protocol, Code Division Multiple Access (CDMA) network protocol, push-to-talk (PTT) protocol, and so forth.

The UE105 is illustrated as a smartphone (e.g., a handheld touchscreen mobile computing device connectable to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a Personal Data Assistant (PDA), a pager, a laptop computer, a desktop computer, a wireless handset, a Customer Premises Equipment (CPE), a Fixed Wireless Access (FWA) device, a vehicle-mounted UE, or any computing device that includes a wireless communication interface. In some embodiments, the UE105 may include an internet of things (IoT) UE, which may include a network access layer designed for low power IoT applications that utilize short-term UE connections. IoT UEs may utilize technologies such as narrowband IoT (NB-IoT), machine-to-machine (M2M), or Machine Type Communication (MTC) to exchange data with MTC servers or devices via Public Land Mobile Networks (PLMNs), proximity-based services (ProSe) or device-to-device (D2D) communication, sensor networks, or IoT networks. The M2M or MTC data exchange may be a machine initiated data exchange. NB-IoT/MTC network descriptions interconnect NB-IoT/MTC UEs, which may include uniquely identifiable embedded computing devices (within the internet infrastructure), with short-term connections. The NB-IoT/MTC UE may execute background applications (e.g., keep-alive messages, status updates, location-related services, etc.).

The UE105 may be a vehicle VE (V-UE), which is part of a vehicle with cellular communication capabilities or a vehicle system that includes a communication subsystem for cellular communication. In some implementations, a V-UE may include multiple baseband chips for connecting with individual access networks. For example, the V-UE may include a cellular network baseband system on chip (SoC) to attach to and establish network connectivity with a cellular network and/or other UEs/V-UEs to enable sidelink communications.

AN110 may enable or terminate connection 112. AN110 may be referred to as a Base Station (BS), a node B, AN evolved node B (enb), a next generation node B (gNB or NG-gnnb), AN NG-RAN node, a cell, a serving cell, a neighbor cell, etc., and may include a ground station (e.g., a ground access point) or a satellite station that provides coverage within a certain geographic area.

AN110 may be the first point of contact for UE 105. In some embodiments, AN110 may perform various logical functions including, but not limited to, Radio Network Controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

In some embodiments, the downlink resource grid may be used for downlink transmissions from AN110 to a UE105, while uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. This time-frequency plane representation is a common practice for Orthogonal Frequency Division Multiplexing (OFDM) systems, which makes it intuitive for radio resource allocation. Each column and first row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in the radio frame. The smallest time-frequency unit in the resource grid is denoted as a resource element. Each resource grid comprises several resource blocks, which describe the mapping of a specific physical channel to resource elements. Each resource block comprises a set of resource elements; in the frequency domain, this may represent the minimum number of resources that can currently be allocated. There are several different physical downlink channels carried with such resource blocks.

A Physical Downlink Shared Channel (PDSCH) may carry user data and higher layer signaling to the UE 105. A Physical Downlink Control Channel (PDCCH) may carry information about transport formats and resource allocations related to the PDSCH channel, and so on. It may also inform the UE105 about transport format, resource allocation and hybrid automatic repeat request (HARQ) information related to the uplink shared channel. In general, downlink scheduling (assigning control and shared channel resource blocks to UEs 105 within a cell) may be performed at AN110 based on channel quality information fed back from any of the UEs 105. The downlink resource assignment information may be sent on a PDCCH used for (e.g., assigned to) the UE 105.

The PDCCH may use Control Channel Elements (CCEs) to carry control information. The PDCCH complex-valued symbols may first be organized into quadruplets before being mapped to resource elements, which may then be permuted with a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements called Resource Element Groups (REGs). Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped for each REG. Depending on the size of Downlink Control Information (DCI) and channel conditions, the PDCCH may be transmitted using one or more CCEs.

Some embodiments may use the concept of resource allocation for control channel information, which is an extension of the above-described concept. For example, some embodiments may utilize an enhanced physical downlink control channel (ePDCCH) that uses PDSCH resources for control information transmission. The ePDCCH may be transmitted with one or more Enhanced Control Channel Elements (ECCEs). Similar to the above, each ECCE may correspond to nine sets of four physical resource elements called Enhanced Resource Element Groups (EREGs). ECCE may have other numbers of EREGs in some cases.

As shown in fig. 1, UE105 may include millimeter wave communication circuitry grouped according to functionality. The circuitry shown here is for illustration, and the UE105 may include other circuitry shown in fig. 3. The UE105 may include protocol processing circuitry 115, and the protocol processing circuitry 115 may implement one or more of layer operations related to Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), Radio Resource Control (RRC), and non-access stratum (NAS). Protocol processing circuitry 115 may include one or more processing cores (not shown) to execute instructions and one or more memory structures (not shown) to store program and data information.

The UE105 may also include digital baseband circuitry 125, and the digital baseband circuitry 125 may implement physical layer (PHY) functions including one or more of the following: HARQ functionality, scrambling and/or descrambling, encoding and/or decoding, layer mapping and/or demapping, modulation symbol mapping, received symbol and/or bit metric determination, multi-antenna port precoding and/or decoding (which may include one or more of space-time, space-frequency, or spatial coding), reference signal generation and/or detection, preamble sequence generation and/or decoding, synchronization sequence generation and/or detection, control channel signal blind decoding, and other related functions.

UE105 may also include transmit circuitry 135, receive circuitry 145, Radio Frequency (RF) circuitry 155, and RF front end (RFFE)165, where RFFE 165 may include or be connected to one or more antenna panels 175.

In some embodiments, RF circuitry 155 may include multiple parallel RF chains or branches for one or more of transmit or receive functions; each chain or branch may be coupled to one antenna panel 175.

In some embodiments, protocol processing circuitry 115 may include one or more instances of control circuitry (not shown) to provide control functions for digital baseband circuitry 125 (or simply "baseband circuitry 125"), transmit circuitry 135, receive circuitry 145, radio frequency circuitry 155, RFFE 165, and one or more antenna panels 175.

UE reception may be established by and via one or more antenna panels 175, RFFE 165, RF circuitry 155, receive circuitry 145, digital baseband circuitry 125, and protocol processing circuitry 115. One or more antenna panels 175 can receive transmissions from AN110 via receive beamformed signals received by the multiple antennas/antenna elements of one or more antenna panels 175. More details about the UE105 architecture are illustrated in fig. 2, 3 and 6. Transmissions from AN110 may be transmit beamformed by antennas of AN 110. In some embodiments, the baseband circuitry 125 may contain both transmit circuitry 135 and receive circuitry 145. In other embodiments, baseband circuitry 125 may be implemented in separate chips or modules, such as one chip including transmit circuitry 135 and another chip including receive circuitry 145.

Similar to the UE105, the AN110 may include mmWave/sub-mmWave communication circuitry grouped according to functionality. AN110 may include protocol processing circuitry 120, digital baseband circuitry 130 (or simply "baseband circuitry 130"), transmit circuitry 140, receive circuitry 150, RF circuitry 160, RFFE 170, and one or more antenna panels 180.

Cell transmissions may be established by and via the protocol processing circuitry 120, the digital baseband circuitry 130, the transmit circuitry 140, the RF circuitry 160, the RFFE 170, and the one or more antenna panels 180. One or more antenna panels 180 may transmit signals by forming transmit beams. Fig. 3 illustrates further details regarding the RFFE 170 and the antenna panel 180.

Fig. 2 illustrates example components of a device 200, according to some embodiments. In contrast to fig. 1, fig. 2 illustrates example components of UE105 or AN110 from a receive and/or transmit functional viewpoint, and may not include all of the components described in fig. 1. In some embodiments, device 200 may include at least application circuitry 202, baseband circuitry 204, RF circuitry 206, RFFE circuitry 208, and a plurality of antennas 210 together as shown. The baseband circuitry 204 may be similar to the baseband circuitry 125 and substantially interchangeable with the baseband circuitry 125 in some embodiments. The plurality of antennas 210 may constitute one or more antenna panels for beamforming. The illustrated components of the apparatus 200 may be included in a UE or AN. In some embodiments, the apparatus 200 may include fewer elements (e.g., a cell may not utilize the application circuitry 202, but rather include a processor/controller to process IP data received from the EPC). In some embodiments, device 200 may include additional elements, such as memory/storage, a display, a camera, a sensor, or an input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., for a cloud RAN (C-RAN) implementation, the circuitry may be included separately in more than one device).

The application circuitry 202 may include one or more application processors. For example, the application circuitry 202 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, etc.). The processor may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the device 200. In some embodiments, the processor of the application circuitry 202 may process IP data packets received from the EPC.

The baseband circuitry 204 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 204 may be similar to the baseband circuitry 125 and the baseband circuitry 130 and substantially interchangeable with the baseband circuitry 125 and the baseband circuitry 130 in some embodiments. Baseband circuitry 204 may include one or more baseband processors or control logic to process baseband signals received from the receive signal path of RF circuitry 206 and to generate baseband signals for the transmit signal path of RF circuitry 206. The baseband circuitry 204 may interface with the application circuitry 202 to generate and process baseband signals and to control the operation of the RF circuitry 206. For example, in some embodiments, the baseband circuitry 204 may include a third generation (3G) baseband processor 204A, a fourth generation (4G) baseband processor 204B, a fifth generation (5G) baseband processor 204C, or other baseband processor(s) 204D for other existing generations, generations in development, or generations to be developed in the future (e.g., second generation (2G), sixth generation (6G), etc.). The baseband circuitry 204 (e.g., one or more of the baseband processors 204A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 206. In other embodiments, some or all of the functionality of the baseband processors 204A-D may be included in modules stored in the memory 204G and executed via a Central Processing Unit (CPU) 204E. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency offset, and the like. In some embodiments, the modulation/demodulation circuitry of baseband circuitry 204 may include Fast Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, the encoding/decoding circuitry of baseband circuitry 204 may include convolution, tail-biting convolution, turbo, viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functions are not limited to these examples, and other suitable functions may be included in other embodiments.

In some embodiments, the baseband circuitry 204 may include one or more audio Digital Signal Processors (DSPs) 204F. The audio DSP 204F may include elements for compression/decompression and echo cancellation, and may include other suitable processing elements in other embodiments. The components of the baseband circuitry may be combined as appropriate in a single chip, in a single chipset, or in some embodiments arranged on the same circuit board. In some embodiments, some or all of the constituent components of the baseband circuitry 204 and the application circuitry 202 may be implemented together, for example, on an SOC.

In some embodiments, the baseband circuitry 204 may provide communications compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 204 may support communication with an evolved universal terrestrial radio access network (E-UTRAN) or other Wireless Metropolitan Area Network (WMAN), Wireless Local Area Network (WLAN), Wireless Personal Area Network (WPAN). Embodiments in which the baseband circuitry 204 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

The RF circuitry 206 may utilize modulated electromagnetic radiation through a non-solid medium to enable communication with a wireless network. In various embodiments, RF circuitry 206 may include one or more switches, filters, amplifiers, and the like to facilitate communication with a wireless network. The RF circuitry 206 may include receiver circuitry 206A, which receiver circuitry 206A may include circuitry to down-convert RF signals received from the RFFE circuitry 208 and provide baseband signals to the baseband circuitry 204. The RF circuitry 206 may also include transmitter circuitry 206B, which transmitter circuitry 206B may include circuitry to up-convert baseband signals provided by the baseband circuitry 204 and provide RF output signals to the RFFE circuitry 208 for transmission.

In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, RF circuitry 206 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and baseband circuitry 204 may include a digital baseband interface to communicate with RF circuitry 206.

In some dual-mode embodiments, separate radio Integrated Circuit (IC) circuits may be provided to process signals for each spectrum, although the scope of the embodiments is not limited in this respect.

The RFFE circuitry 208 may include a receive signal path that may include circuitry configured to operate on RF beams received from one or more antennas 210. The RF beam may be a transmit beam formed and transmitted by AN110 when operating in the mmWave or sub-mmWave frequency range. RFFE circuitry 208 coupled to one or more antennas 210 may receive the transmit beams and advance them to RF circuitry 206 for further processing. The RFFE circuitry 208 may also include a transmit signal path that may include circuitry configured to amplify signals provided by the RF circuitry 206 for transmission by one or more of the antennas 210, with or without beamforming. In various embodiments, the amplification by the transmit or receive path may be done in only the RF circuitry 206, only the RFFE circuitry 208, or both the RF circuitry 206 and the RFFE circuitry 208.

In some embodiments, the RFFE circuitry 208 may include a TX/RX switch to switch between transmit mode and receive mode operation. The RFFE circuitry 208 may include a receive signal path and a transmit signal path. The receive signal path of the RFFE circuitry 208 may include a Low Noise Amplifier (LNA) to amplify the received RF beam and provide an amplified receive RF signal as an output (e.g., to the RF circuitry 206). The transmit signal path of RFFE circuitry 208 may include a Power Amplifier (PA) to amplify an input RF signal (e.g., provided by RF circuitry 206) and one or more filters to generate the RF signal for beamforming and subsequent transmission (e.g., by one or more of the one or more antennas 210).

The processor of the application circuitry 202 and the processor of the baseband circuitry 204 may be used to execute elements of one or more instances of a protocol stack. For example, the processor of the baseband circuitry 204, alone or in combination, may be used to perform layer 3, layer 2, or layer 1 functions, while the processor of the application circuitry 202 may utilize data (e.g., packet data) received from these layers and further perform layer 4 functions (e.g., Transmission Communication Protocol (TCP) and User Datagram Protocol (UDP) layers). As referred to herein, layer 3 may include a Radio Resource Control (RRC) layer, which is described in more detail below. As referred to herein, layer 2 may include a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, and a Packet Data Convergence Protocol (PDCP) layer, which are described in more detail below. Layer 1, as referred to herein, may comprise the Physical (PHY) layer of the UE/AN, which is described in more detail below.

Fig. 3A illustrates an embodiment of a radio frequency front end 300 including mmWave RFFE 305 and one or more sub-6GHz Radio Frequency Integrated Circuits (RFICs) 310. mmWave RFFE 305 may be similar to RFFE 165, RFFE 170, and/or RFFE circuitry 208 and may be substantially interchangeable in some embodiments. When operating in FR2 or mmWave, mmWave RFFE 305 may be used for UE 105; the RFIC 310 may be used for the UE105 when operating in the FR1, sub-6GHz, or LTE frequency bands. In this embodiment, one or more RFICs 310 may be physically separated from mmWave RFFE 305. RFIC 310 may include a connection to one or more antennas 320. RFFE 305 may be coupled to multiple antennas 315, and these antennas 315 may form one or more antenna panels.

FIG. 3B illustrates an alternative embodiment of RFFE 325. In this aspect, both millimeter wave and sub-6GHz radio functions may be implemented in the same physical RFFE 330. RFFE 330 may contain both millimeter wave antenna 335 and sub-6GHz antenna 340. The RFFE 330 may be similar to and substantially interchangeable with the RFFE 165, RFFE 170, and/or RFFE circuitry 208 in some embodiments.

Fig. 3A and 3B illustrate embodiments of various RFFE architectures for a UE105 or AN 110.

In LTE networks, V2X sidelink communications may be broadcast-based. For example, all packets may be blindly transmitted by the vehicular UE via the sidelink. In some cases, the packet may alternatively be retransmitted a fixed number of times. The QoS provided by such broadcast mechanisms may be based on indicating a single priority value (e.g., ProSe Per Packet Priority (PPPP)) associated with each V2X packet. This acts AS the primary QoS metric for any Access Stratum (AS) layer process. Such AS layer procedures may be MAC layer scheduling and/or multiplexing, and associated resource selection and transmission reservation. In contrast, QoS management is based on RRC configuration of appropriate MAC layer parameters related to a specific logical channel in operation over the Uu interface, which is the radio interface between the UE and the radio access network.

Traditionally, replication of transmissions on multiple carriers of the PDCP layer is used to enhance reliability, and one or more QoS metrics may be used to indicate a reliability requirement for each packet (e.g., ProSe Per Packet Reliability (PPPR)). However, due to the inherent nature of the broadcast in the conventional V2X transmission, there may not be any feedback mechanism in this process. Thus, LTE V2X packets may be associated with one or more QoS parameters, and one or more radio layers may be intended to meet packet-based associated QoS requirements.

In NR, one-to-one and/or one-to-many type V2X communication via sidelink may be established to enable unicast or multicast V2X communication. Accordingly, two (or more) UEs involved in such V2X sidelink communications may establish a connection between them and exchange certain information, such that a set of rules applicable to a particular V2X communication may be agreed upon and established between the two UEs. One or more of the set of rules may correspond to a set of QoS requirements fulfilled for sidelink V2X communications. There may be one or more schemes in resolving QoS requirements or implementing the QoS framework. For example, an extended and/or unified QoS metric based on per-packet QoS may be used, regardless of whether the application layer or upper layer is different between two different RATs and associated interfaces.

In some embodiments, NR resource allocation for V2X sidelink transmission may use two different modes. One of them is a network scheduling mode (e.g., mode 1), in which the network (e.g., eNB or gNB) schedules certain resources. Another mode is an autonomous resource reservation/reselection mode (e.g., mode 2), where the UE105 may select or determine resources based on sensing by the UE 105. In mode 2, achieving certain QoS requirements may be challenging unless non-competing resources are allocated, since mode 2 is inherently based on the concept of collision detection and avoidance on the broadcast channel.

Service Data Adaptation Protocol (SDAP) and bearer configuration

Traditionally in LTE V2X sidelink communications, packets generated by the application layer are assigned ProSe sidelink (PC5) or sidelink QoS identifiers or parameters based on some mapping performed by the respective V2X function. The packet may then be passed to the AS layer along with this QoS parameter. In contrast, NR V2X may use a QoS flow based model or a side link bearer based model, which may be similar to NR Uu links. This operation can help seamless switching between NR Uu and NR side links. Note that both the PC5 and the sidelink refer to V2X communication without a network between UEs after resources for communication have been determined and established. The terms "PC 5" and "side chain" may be used interchangeably throughout this disclosure. In addition, V2X is an example communication over a sidelink. Which may be any device-to-device communication using a cellular sidelink.

In an embodiment, it may be beneficial for the SDAP layer to enable mapping of incoming QoS flows to sidelink radio bearers. The SDAP layer may also mark flows with QoS Flow Identification (QFI) for uplink and/or downlink packets. In some embodiments, QFI may be used by only two V2X UEs for further mapping with the appropriate Vehicle Quality Index (VQI) or 5G QoS identifier (5 QI).

In an embodiment, if SDAP is not supported by sidelink communications, an incoming service request from the V2X layer may have an associated 5QI/VQI mapping. Corresponding sidelink bearers may be established between the two V2X UEs involved in NR V2X sidelink communications. The AS layer may perform mapping the service request to a Data Radio Bearer (DRB) Identification (ID). This mapping may be performed based on the generation of side link bearers. In addition, the MAC layer may perform mapping of one or more DRB IDs to one or more Logical Channel (LC) IDs.

Further, the V2X layer may provide supported or available network resource selection mode information with service information for the V2X UE(s) to initiate network-based scheduling resource selection (e.g., mode 1) or autonomous resource selection (e.g., mode 2). The autonomous resource selection mode may include one or more sub-modes, such as using scheduled UEs, pre-configuration, dynamic resource selection, and so forth. If both mode 1 and mode 2 are available, the UE may determine which mode and/or sub-mode to use for a particular V2X sidelink transmission. Additionally or alternatively, the network may provide the indication and/or assistance information to the UE as such. Such information may be configured to the UE via one or more control elements, such as SidelinkUEInformation, RRCReconfiguration, and so forth.

In an embodiment, an end marker may be sent if resource reselection or reconfiguration of DRBs occurs corresponding to a given sidelink radio bearer. Additionally or alternatively, the same or a different end-marker may also be sent if the unicast link is lost or feedback from the receiver UE is not received by the sender UE.

In an embodiment, the sender UE may determine whether the QoS requirements are fulfilled based on feedback information from the receiver UE. Such feedback information may be via HARQ and/or RLC. The QoS requirements may be associated with a service, a QoS flow, a bearer, an LCID, or other suitable basis corresponding to one or more packets. Upon such a determination, the sending UE may evaluate and determine one or more changes in mode operation. The sending UE may then initiate such a mode change based on information received from the network if it is under coverage of the network.

Extensions of MAC headers for side link unicast/multicast support

Traditionally in V2X sidelink communications, the associated MAC subheader and MAC header fields may include one or more of the following fields:

-V: a MAC PDU format version number field indicating which version of the sidelink shared channel (SL-SCH) subheader is used. Three format versions are defined in this version of the specification, and this field should therefore be set to "0001", "0010", and "0011". If the DST field is 24 bits, this field may be set to "0011". The V field size may be 4 bits;

-SRC: the Source layer 2ID field carries the identity of the source. It is set to the ProSe UE ID. The SRC field size may be 24 bits;

-a DST: the DST field may be 16 bits or 24 bits. If it is 16 bits, it carries the 16 most significant bits of the destination layer 2 ID. If it is 24 bits, it may be set to the destination layer 2 ID. For sidelink communications, the destination stratum 2ID may be set to the ProSe layer 2 group ID or ProSe UE ID. For V2X sidelink communications, the destination tier 2ID may be set to an identifier provided by an upper layer. This identifier may be a multicast identifier if the V field is set to "0001". If the V field is set to "0010," then this identifier may be a unicast identifier.

-LCID: the logical channel ID field uniquely identifies a logical channel instance within the scope of a source layer 2ID and destination layer 2ID pair of a corresponding MAC Service Data Unit (SDU) or padding. There may be one LCID field for each MAC SDU or padding included in the MAC PDU. In addition, when single-byte or two-byte padding is desired, but cannot be achieved by padding at the end of the MAC PDU, one or two additional LCID fields may be included in the MAC PDU. The values of LCIDs from "01011" to "10100" may identify logical channels for transmitting duplicated RLC SDUs from logical channels having a range from "00001" to "01010" respectively in chronological order from the values of LCIDs. The LCID field size may be 5 bits;

-L: the length field indicates the length of the corresponding MAC SDU in bytes. There may be one L field for each MAC PDU subheader except for the last subheader. The size of the L field may be indicated by the F field;

-F: the format field indicates the size of the length field, as indicated in table 6.2.4-2. There may be one F field for each MAC PDU subheader except for the last subheader. The size of the F field may be 1 bit. If the size of the MAC SDU is less than 128 bytes, the value of the F field may be set to 0; otherwise it can be set to 1;

-E: the extension field is a flag indicating whether there are more fields in the MAC header. The E field may be set to "1" to indicate another set of at least R/R/E/LCID fields. The E field may be set to "0" to indicate that the MAC SDU or padding starts with the next byte;

-R: reserved bit, set to "0".

Fig. 4A-4D illustrate some example MAC subheaders, in accordance with various embodiments. These MAC subheaders may also be used for LTE related communications. For example, the MAC header may include one or more MAC subheaders, source and destination IDs, and MAC SDUs. In LTE, there may be only one or more SDUs specified by one destination ID for each PDU. In the V2X sidelink communication, the destination layer 2ID may be set to an identifier provided by an upper layer. For example, if the "V" field in fig. 4D is set to "0001", this identifier may be a multicast identifier or indicate multicast. Some additional functionality may be required if there is more efficient unicast communication over the sidelink in the NR V2X communication. Note that fig. 4A-4D and the corresponding description are with respect to 3GPP Technical Specification (TS)36.321v14.8.0 (9/28/2018).

In NR V2X communications, if the UE performs unicast link establishment with more than one receiver UE or has multicast communication with more than one receiver UE, it may be feasible to multiplex different SDUs within one MAC PDU to efficiently use the assigned sidelink grants. In some embodiments, the respective Source (SRC)/Destination (DEST) layer 2ID fields/length/number of bits may remain the same, such that no physical layer changes may be required as these fields will be passed down to one or more lower layers.

In embodiments, the LCID may be extended to support activation and/or deactivation of or indication associated with multiplexing of more than one SDU. The LCID may represent a corresponding logical channel ID and have logical channel data corresponding to a particular QoS requirement or 5QI characteristic. In some embodiments, there may be 8, 16, or more LCIDs supported by the UE.

In some embodiments, the first set of LCIDs may be classified as being used in mode 1 operation, while the second set of LCIDs may be classified as being used in mode 2 operation. Additionally or alternatively, the third set of LCIDs may be classified as being used in both mode 1 and mode 2. Other classifications and rankings may be used to assign an LCID its available operations. For example, a particular LCID or set of LCIDs may be specified to enable the following functions:

activate/deactivate a specific operation mode (e.g., mode 1 or mode 2) to the destination V2X UE or the recipient UE for fast enablement. Additionally or alternatively, such information may be exchanged via PC5 RRC messages.

Activation/deactivation or start/stop indications for one or more multiplexed or to-be-multiplexed SDUs for transmission. In addition, the corresponding demultiplexing filter or multiplexing group ID may be transmitted within the data portion of the corresponding MAC SDU. Such an indication may be transmitted or sent to the individual recipient UEs with which the sending UE intends to establish a unicast communication. This indication may also be implemented or exchanged via a PC5 RRC message.

The PC5-RRC message may be utilized to share the above activation/deactivation with the respective recipient UE, which may cause some latency and/or signaling overhead. However, using the PC5-RRC message may provide advantages based on the acknowledgement-response procedure.

In an embodiment, a specific set of LCIDs may be assigned to support PC5-RRC messages between the sender and receiver UEs. Table 1 illustrates an example of such a set of LCIDs.

Table 1

Fig. 5A illustrates an example MAC Control Element (CE) when formatting a control message, in accordance with various embodiments. Certain LCID values (e.g., table 1) may be applied to the MAC CE to generate or form a corresponding control message in the PC5-RRC signaling. In this scheme with the MAC CE format, for a source/destination (SRC/DEST) pair for which mode 1 or mode 2 is to be used, a corresponding activation/deactivation command may be transmitted along with the LCID. Each row (e.g., row 505) in fig. 5A indicates a byte, which includes eight bits. Some alignment and/or filling may be achieved if necessary, but this is not shown in fig. 5A. In summary, the source and destination stratum 2 IDs may be 24 bits per LTE V2X side link communication. NR-based V2X side chains communication may use the same or different number of bits. LCIDi 510 may represent LCID2, LCID3, etc. The "L" field may indicate the length of the number of LCIDs. Note that fig. 5A is merely exemplary, and other similar formats of control signaling may be used.

In an embodiment, since the MAC PDU may include a header and MAC SDUs in the NR V2X communication, multiplexed MAC SDUs may be supported within one MAC PDU. In order to enable multiplexing of multiple MAC SDUs within one MAC PDU so that allocated resources can be efficiently used in a better manner, the sender UE may exchange corresponding information with the receiver UE via a PC5-RRC message while establishing a connection for transmission. Such information may include a multiplexing ID indicating that more than one SDU belonging to different recipient UEs is to be included within one MAC PDU. This ID can thus identify the recipient UE that has the SDU within the MAC PDU. Such information may also include a corresponding LCID associated with the UE. The sender UE may use one or more specific LCIDs to represent an instance of one MAC SDU with a specific MAC PDU. These LCIDs may be exchanged via PC5-RRC messages.

In addition, the MAC PDU may include the following indication, as shown in fig. 5B.

The "M" field 515: "M" may be used in one of the "R" fields to indicate that the destination ID represents the ID of a group of unicast UEs and that a particular filter (e.g., LCID) is to be applied by the destination to obtain a MAC PDU or particular MAC SDU(s) within the message. Additionally or alternatively, the "V" field 520 may be used to indicate a multicast packet and the same LCID may be used for all members of the multicast. In contrast, the "M" field 515 may indicate that the group ID is to be multiplexed with a group of unicast UEs.

"DEST (multiplex group ID)" field 525: the "DEST (multiplex group ID)" field 525 may include 16 or 24 bits to represent a group of unicast IDs. In some embodiments, the respective mapping of destination IDs to multiplex group IDs may be performed based on the particular UE implementation.

Note that fig. 5B is merely exemplary, and other similar formats of control signaling may be used. Note also that the NR MAC PDU format may be adjusted or modified to represent the V2X sidelink shared channel MAC.

Fig. 6A illustrates an operational flow/algorithm structure 600 of a process that facilitates initiating NR V2X sidelink communication from the perspective of a sender UE, in accordance with various embodiments. The operational flow/algorithm structure 600 may be performed by the UE105 or its circuitry (including, for example, the digital baseband circuitry 125).

The operational flow/algorithm structure 600 may include, at 610, determining one or more QoS indicators for a flow of packets generated by the application layer and to be transmitted by the UE in NR side link V2X communication. This determination may be based on specific QoS requirements assigned by the application layer. The UE may also receive a stream of packets from the application layer or some other corresponding layer(s). The one or more QoS indicators may be referred to as one or more QoS parameters. The QoS indicator or parameter may be associated with a VQI and/or a 5 QI.

The operational flow/algorithm structure 600 may also include, at 620, establishing a side link radio bearer based on the determined one or more QoS indicators. The sidelink radio bearer may be established by the SDAP layer if available. Further, the UE may generate a QFI for the flow of packets. This may include both uplink and downlink packets.

In an embodiment, the UE may map the service associated with the flow to a data radio bearer ID associated with the sidelink radio bearer at the application service layer.

In some embodiments, the UE may not have an SDAP layer. Thus, a corresponding incoming service request from the V2X layer may have an associated VQI/5QI mapping. The AS layer may perform mapping of the service request to the DRB ID. Further mapping of DRB ID to LCID may be performed by the corresponding MAC layer.

The operational flow/algorithm structure 600 may also include, at 630, transmitting the flow of packets to the recipient UE in an NR sidelink V2X communication via one or more resources corresponding to the established sidelink radio bearer. To transmit a stream of packets to a recipient UE, the sender UE may initiate network scheduled resource selection or autonomous resource selection and determine one or more resources to transmit one or more multiplexed packets.

In an embodiment, the UE may generate an end marker corresponding to a sidelink radio bearer if the unicast of the UE is lost or there is no feedback message sent by the recipient UE. In addition, the UE may decode the feedback message for transmission or reception of the one or more multiplexed packets upon receiving the feedback message from the recipient UE and determine whether the determined one or more QoS indicators are satisfied based on the decoded feedback message. The feedback message may be a HARQ/RLC related message or similar.

Fig. 6B illustrates an operational flow/algorithm structure 605 of a process that facilitates initiating NR V2X sidelink communication from the perspective of a recipient UE, in accordance with various embodiments. The operational flow/algorithm structure 605 may be executed by the UE105 or its circuitry (including, for example, the digital baseband circuitry 125).

The operational flow/algorithm structure 605 may include, at 615, decoding a stream of packets including a sidelink radio bearer having one or more QoS indicators after receiving the stream of packets from the sender UE in an NR sidelink V2X communication. The receiving may be via one or more resources configured based on mode 1 or mode 2 scheduling.

The operational flow/algorithm structure 605 may also include, at 625, generating a feedback message after decoding the stream of packets.

The operational flow/algorithm structure 605 may also include, at 635, sending a feedback message to the sender UE via the one or more resources configured by the sender UE or the network for NR side link V2X communication.

In some embodiments, the receiving UE may also decode a message upon receipt indicating activation or deactivation of a set of LCIDs with respect to a network scheduled resource mode or an autonomous resource mode in sidelink V2X communications.

In some embodiments, the sending UE may also decode another message indicating activation or deactivation of multiplexing of more than one SDU into one PDU for data transmission to one or more receiving UEs in NR side link V2X communication.

Fig. 7 illustrates example interfaces of baseband circuitry, in accordance with some embodiments. As described above, the baseband circuitry 204 of FIG. 2 may include the processors 204A-204E and the memory 204G utilized by the processors. The processors 204A-204E of the UE105 may perform some or all of the operational flow/ algorithm structure 600 or 605 in accordance with various embodiments with respect to fig. 5A and 5B. Each of the processors 204A-204E may include a memory interface 704A-704E, respectively, to send/receive data to/from the memory 204G.

The baseband circuitry 204 may also include one or more interfaces to communicatively couple to other circuitry/devices, such as a memory interface 712 (e.g., an interface to send/receive data to/from a memory external to the baseband circuitry 204), an application circuitry interface 714 (e.g., an interface to send/receive data to/from the application circuitry 202 of fig. 2), an RF circuitry interface 716 (e.g., an interface to send/receive data to/from the RF circuitry 206 of fig. 2), a wireless hardware connectivity interface 718 (e.g., an interface to/from a Near Field Communication (NFC) component, a wireless communication interface,

component (e.g. low energy consumption)

)、

Interfaces for components and other communication components to send/receive data) and a power management interface 720 (e.g., an interface to send/receive power or control signals).

Fig. 8 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies discussed herein, according to some example embodiments. In particular, fig. 8 shows a diagrammatic representation of hardware resources 800, hardware resources 800 including one or more processors (or processor cores) 810, one or more memory/storage devices 820, and one or more communication resources 830, each of which may be communicatively coupled via a bus 840. For embodiments utilizing node virtualization (e.g., Network Function Virtualization (NFV)), hypervisor 802 may be executed to provide an execution environment for one or more network slices/subslices utilizing hardware resources 800.

Processor 810 (e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP) (e.g., a baseband processor), an Application Specific Integrated Circuit (ASIC), a Radio Frequency Integrated Circuit (RFIC), another processor, or any suitable combination of these) may include, for example, processor 812 and processor 814.

Memory/storage 820 may include a main memory, a disk storage device, or any suitable combination of these. The memory/storage 820 may include, but is not limited to, any type of volatile or non-volatile memory, such as Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid state memory devices, and so forth.

The communication resources 830 may include interconnection or network interface components or other suitable devices to communicate with one or more peripherals 804 or one or more databases 806 via the network 808. For example, communication resources 830 may include wired communication components (e.g., for use withOver a Universal Serial Bus (USB) coupling), a cellular communication component, an NFC component,

Component (e.g. low energy consumption)

)，

Components and other communication components.

The instructions 850 may include software, programs, applications, applets, apps, or other executable code for causing at least any of the processors 810 to perform any one or more of the methods discussed herein (e.g., operational flows 600 and 605). For example, in embodiments where the hardware resources 800 are implemented into the UE105, the instructions 850 may cause the UE to perform some or all of the operational flow/algorithm structure 600. The instructions 850 may cause AN110 to perform some or all of the operational flow/algorithm structure 605. The instructions 850 may reside, completely or partially, within at least one of the processors 810 (e.g., within a cache memory of the processor), within the memory/storage 820, or any suitable combination of these. Further, any portion of instructions 850 may be communicated to hardware resource 800 from any combination of peripherals 804 or database 806. Thus, the memory of processor 810, memory/storage 820, peripherals 804, and database 806 are examples of computer-readable and machine-readable media.

Some non-limiting examples of various embodiments are provided below.

Example 1 may include a method comprising: determining one or more quality of service (QoS) indicators for a flow of packets generated by an application layer and to be transmitted by a UE in a new air interface (NR) side-link vehicle-to-anything (V2X) communication; establishing a sidelink radio bearer based on the determined one or more QoS indicators; and transmitting the stream of packets to a recipient UE via one or more resources corresponding to the established sidelink radio bearer in the NR sidelink V2X communication.

Example 2 may include a method as described in example 1 and/or some other example herein, further comprising: a QoS flow Identification (ID) is generated for the flow of the packet.

Example 3 may include the method of example 2 and/or some other example herein, wherein to establish the side-link radio bearer, the UE is to establish the side-link radio bearer according to a Service Data Adaptation Protocol (SDAP).

Example 4 may include a method as described in example 1 and/or some other example herein, further comprising: mapping, at an application service layer, a service associated with the flow to a data radio bearer Identification (ID) associated with the sidelink radio bearer.

Example 5 may include the method of example 1 and/or some other example herein, wherein the one or more QoS indicators are associated with a Vehicle Quality Index (VQI) or a 5G QoS identifier (5 QI).

Example 6 may include the method of example 1 and/or some other example herein, wherein transmitting the stream of packets to the recipient UE is to initiate network scheduled resource selection or autonomous resource selection; and determining one or more resources for a flow transmitting the packet.

Example 7 may include a method as described in example 1 and/or some other example herein, further comprising: generating an end marker corresponding to the sidelink radio bearer if at least one of the one or more resources is to be re-determined or the data radio bearer is to be re-configured.

Example 8 may include a method as described in examples 1-7 and/or some other example herein, further comprising: and if the unicast link of the UE is lost or no feedback message sent by the UE of the receiving party exists, generating an end mark corresponding to the side link radio bearer.

Example 9 may include a method as described in example 8 and/or some other example herein, further comprising: decoding the feedback message for transmission or reception of one or more multiplexed packets upon receiving the feedback message from the recipient UE; and determining whether the determined one or more QoS indicators are satisfied based on the decoded feedback message.

Example 10 may include the method of examples 1-9 and/or some other example herein, wherein the method is performed by the sender UE and/or the sender vehicle UE and/or a portion thereof in NR V2X sidelink communications.

Example 11 may include a method comprising generating a first message indicating an activation or deactivation of a set of Logical Channel Identifications (LCIDs) for a network scheduled resource mode or an autonomous resource mode in a new air interface (NR) sidelink vehicle-to-anything (V2X) communication; generating a second message indicating activation or deactivation of multiplexing of more than one Service Data Unit (SDU) into one Protocol Data Unit (PDU) for data transmission to one or more recipient UEs in the NR side link V2X communication; and after generating, sending the first message and the second message to the one or more recipient UEs.

Example 12 may include a method as described in example 11 and/or some other example herein, further comprising: generating an SDU comprising a multiplexing group Identification (ID) for multiplexing the more than one Service Data Unit (SDU) into the Protocol Data Unit (PDU); multiplexing the SDU with one or more additional SDUs into the one PDU; and transmitting a third message including the PDU to the one or more recipient UEs.

Example 13 may include a method as described in example 12 and/or some other example herein, wherein the SDU comprises one or more demultiplexing filters.

Example 14 may include a method as described in example 12 and/or some other example herein, further comprising: generating a fourth message indicating that one or more LCIDs in the set of LCIDs correspond to one of the one or more recipient UEs; and sending the fourth message to one of the one or more recipient UEs.

Example 15 may include the method of example 11 and/or some other example herein, wherein the set of LCIDs is a first set of LCIDs, and the first message further indicates a second set of LCIDs for both a network scheduled resource mode and an autonomous resource mode in the NR side link V2X communication.

Example 16 may include the method of examples 11-15 and/or some other example herein, wherein any or all of the first message, the second message, and the third message are NR side link Radio Resource Control (RRC) messages.

Example 17 may include the method of examples 11-16 and/or some other example herein, wherein the method is performed by the sender UE and/or the sender vehicle UE and/or a portion thereof in the NR V2X sidelink communication.

Example 18 may include a method comprising: upon receiving a flow of packets from a sender UE in a new air interface (NR) side link vehicle-to-anything (V2X) communication, decoding the flow of packets including a side link radio bearer having one or more quality of service (QoS) indicators; generating a feedback message after decoding the packetized stream; and sending the feedback message to the sender UE via the one or more resources configured by the sender UE for the NR side link V2X communication.

Example 19 may include a method as described in example 18 and/or some other example herein, further comprising: decoding a first message upon receipt, the first message indicating activation or deactivation of a set of Logical Channel Identifications (LCIDs) for a network scheduled resource mode or an autonomous resource mode in the NR sidelink V2X communication.

Example 20 may include a method as described in example 18 or 19 and/or some other example herein, further comprising: decoding a second message upon receipt, the second message indicating activation or deactivation of multiplexing of more than one Service Data Unit (SDU) into one Protocol Data Unit (PDU) for data transmission in the NR side link V2X communication to one or more recipient UEs.

Example 21 may include the method of examples 18-20 and/or some other example herein, wherein the method is performed by the recipient UE and/or the recipient vehicle UE and/or a portion thereof in the NR V2X sidelink communication.

Example 22 may include an apparatus comprising means for performing one or more elements of a method described in or relating to any of examples 1-21 or any other method or process described herein.

Example 23 may include one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of a method described in any of examples 1-21 or in relation to any of examples 1-21, or any other method or process described herein.

Example 24 may include an apparatus comprising logic, modules, and/or circuitry to perform one or more elements of a method described in or relating to any of examples 1-21 or any other method or process described herein.

Example 25 may include a method, technique, or process as described in any of examples 1-21 or in relation to any of examples 1-21, or some portion or fragment thereof.

Example 26 may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions, which when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process as described in any of examples 1-21 or in relation to any of examples 1-21, or some portion thereof.

The present disclosure is described with reference to flowchart illustrations or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations or block diagrams, and combinations of blocks in the flowchart illustrations or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart or block diagram block or blocks.

The description herein of illustrated implementations, including those described in the abstract, is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. While specific implementations and examples are described herein for illustrative purposes, various alternative or equivalent embodiments or implementations calculated to achieve the same purposes may be made in accordance with the above detailed description without departing from the scope of the disclosure, as will be recognized by those skilled in the relevant art.

Claims (23)

1. One or more computer-readable media (CRM) comprising instructions that, when executed by one or more processors of a User Equipment (UE), cause the UE to:

determining one or more quality of service (QoS) indicators for a flow of packets generated by an application layer and to be transmitted by the UE in a new air interface (NR) side-link vehicle-to-anything (V2X) communication;

establishing a sidelink radio bearer based on the determined one or more QoS indicators; and

in the NR side link V2X communication, the stream of packets is transmitted to a recipient UE via one or more resources corresponding to the established side link radio bearer.

2. The one or more CRMs of claim 1, wherein the instructions, when executed, further cause the UE to:

a QoS flow Identification (ID) is generated for the flow of the packet.

3. The one or more CRMs of claim 2, wherein to establish the side-link radio bearer, the UE is to establish the side-link radio bearer according to a Service Data Adaptation Protocol (SDAP).

4. The one or more CRMs of claim 1, wherein the instructions, when executed, further cause the UE to:

at an application service layer, mapping a service associated with the flow to a data radio bearer Identification (ID) associated with the sidelink radio bearer.

5. The one or more CRMs of claim 1, wherein the one or more QoS indicators are associated with a Vehicle Quality Index (VQI) or a 5G QoS identifier (5 QI).

6. The one or more CRMs of claim 1, wherein to transmit the stream of packets to the recipient UE, the instructions, when executed, cause the UE to:

initiating network scheduling resource selection or autonomous resource selection; and

one or more resources for a flow transmitting the packet are determined.

7. The one or more CRMs of claim 6, wherein the instructions, when executed, further cause the UE to:

generating an end marker corresponding to the sidelink radio bearer if at least one of the one or more resources is to be re-determined or the data radio bearer is to be re-configured.

8. The one or more CRMs of any of claims 1-7, wherein the instructions, when executed, further cause the UE to:

and if the unicast link of the UE is lost or no feedback message sent by the UE of the receiving party exists, generating an end mark corresponding to the side link radio bearer.

9. The one or more CRMs of claim 8, wherein the instructions, when executed, further cause the UE to:

decoding the feedback message for transmission or reception of one or more multiplexed packets upon receiving the feedback message from the recipient UE; and

determining whether the determined one or more QoS indicators are satisfied based on the decoded feedback message.

10. One or more computer-readable media (CRM) comprising instructions that, when executed by one or more processors of a User Equipment (UE), cause the UE to:

generating a first message indicating activation or deactivation of a set of Logical Channel Identifications (LCIDs) for a network scheduled resource mode or an autonomous resource mode in a new air interface (NR) sidelink vehicle-to-anything (V2X) communication;

generating a second message indicating activation or deactivation of multiplexing of more than one Service Data Unit (SDU) into one Protocol Data Unit (PDU) for data transmission to one or more recipient UEs in the NR side link V2X communication; and

after generating, sending the first message and the second message to the one or more recipient UEs.

11. The one or more CRMs of claim 10, wherein the instructions, when executed, further cause the UE to:

generating an SDU comprising a multiplexing group Identification (ID) with respect to multiplexing the more than one Service Data Unit (SDU) into the Protocol Data Unit (PDU);

multiplexing the SDU with one or more additional SDUs into the one PDU; and

transmitting a third message including the PDU to the one or more recipient UEs.

12. The one or more CRMs of claim 11, wherein the SDU comprises one or more demultiplexing filters.

13. The one or more CRMs of claim 11, wherein the instructions, when executed, further cause the UE to:

generating a fourth message indicating that one or more LCIDs in the set of LCIDs correspond to one of the one or more recipient UEs; and

sending the fourth message to one of the one or more recipient UEs.

14. The one or more CRMs of claim 10, wherein the set of LCIDs is a first set of LCIDs, and the first message further indicates a second set of LCIDs for both a network scheduled resource pattern and an autonomous resource pattern in the NR side link V2X communication.

15. The one or more CRMs of any of claims 10-14 wherein any or all of the first message, the second message, and the third message is an NR side link Radio Resource Control (RRC) message.

16. An apparatus of a User Equipment (UE), comprising:

a processing circuit to:

determining one or more quality of service (QoS) parameters for a flow of packets generated by an application layer and to be transmitted by the UE in a new air interface (NR) side link vehicle-to-anything (V2X) communication;

generating a sidelink radio bearer for the flow of packets based on the determined one or more QoS parameters; and

interface circuitry coupled with the processing circuitry, the interface circuitry to: transmitting the stream of packets to at least one recipient UE via one or more resources corresponding to the sidelink radio bearer.

17. The apparatus of claim 16, wherein the processing circuitry is to: generating the side link radio bearer according to a Service Data Adaptation Protocol (SDAP), and the interface circuitry is further to: a QoS flow Identification (ID) corresponding to the flow of the packet is generated.

18. The apparatus of claim 16, wherein the processing circuit is further to:

determining one or more resources in a network scheduled resource mode or an autonomous resource selection mode for a flow transmitting the packet.

19. The apparatus of claim 18, wherein the processing circuitry is further to:

generating an end marker in the sidelink radio bearer based on resource reselection for transmitting one or more transmission packets.

20. The apparatus of claim 16, wherein the processing circuit is further to: generate an end marker in the sidelink radio bearer based on decoding a feedback message regarding receipt of the transmitted one or more transmit packets, and the interface circuitry is further to: receiving the feedback message from the recipient UE.

21. An apparatus of a User Equipment (UE), comprising:

means for decoding a stream of packets from a sender UE upon receiving the stream of packets in a new air interface (NR) sidelink vehicle-to-anything (V2X) communication, the stream of packets including a sidelink radio bearer having one or more quality of service (QoS) indicators;

means for generating a feedback message upon decoding the packetized stream; and

means for sending the feedback message to the sender UE via one or more resources configured by the sender UE for the NR sidelink V2X communication.

22. The apparatus of claim 21, further comprising:

means for decoding a first message upon receipt, the first message indicating activation or deactivation of a set of Logical Channel Identifications (LCIDs) for a network scheduled resource mode or an autonomous resource mode in the NR sidelink V2X communication.

23. The apparatus of claim 21, further comprising:

means for decoding a second message upon receipt, the second message indicating activation or deactivation of multiplexing more than one Service Data Unit (SDU) into one Protocol Data Unit (PDU) for data transmission to one or more recipient UEs in the NR side link V2X communication.

Images