Transmitting device, method and integrated circuit

Abstract

The present disclosure relates to a transmitting device, a method and an integrated circuit, a transmitting device for transmitting vehicle data to one or more receiving devices via a side link interface, wherein the transmitting device performs autonomous radio resource allocation for transmitting the vehicle data via the side link interface, wherein the transmitting device comprises: a circuit for obtaining one or more quality of service configurations provided in the transmitting device, generating vehicle data in an application layer, and forwarding the generated vehicle data together with a priority indication indicating the priority of the vehicle data to a transport layer, in which, depending on the priority indication obtained together with the vehicle data and a mapping provided in the transmitting device associating each of the one or more quality of service configurations with a priority indication value, one of the obtained one or more quality of service configurations is determined, and autonomous radio resource allocation is performed based on the determined one quality of service configuration, and a transmitting unit for transmitting the vehicle data to the one or more receiving devices via the side link interface according to the performed autonomous radio resource allocation.

Description

[0001] This application is a divisional application of the Chinese invention patent application with the application date of May 15, 2017, application number 201780034416.7, invention name “Support for Improved Service Quality of V2X Transmissions”, and applicant being Panasonic Electric (USA) Intellectual Property Corporation. Technical Field

[0002] The present disclosure relates to improved QoS support for sending vehicle data via a sidelink interface.The present disclosure provides a corresponding (onboard) mobile terminal, a base station and a corresponding method. Background Art

[0003] Long Term Evolution (LTE)

[0004] The third generation mobile systems (3G) based on WCDMA radio access technology are being widely deployed around the world. The first step to enhance or evolve this technology requires the introduction of High Speed ​​Downlink Packet Access (HSDPA) and Enhanced Uplink (also known as High Speed ​​Uplink Packet Access (HSUPA)) to provide a highly competitive radio access technology.

[0005] In order to prepare for further increased user demand and to be competitive with new radio access technologies, 3GPP introduced a new mobile communication system called Long Term Evolution (LTE). LTE is designed to meet operators' needs for high-speed data and media transmission and high-capacity voice support for the next decade. The ability to provide high bit rates is a key measure of LTE.

[0006] The work item (WI) specification of the Long Term Evolution (LTE) called Evolved UMTS Terrestrial Radio Access (UTRA) and UMTS Terrestrial Radio Access Network (UTRAN) is finalized as Release 8 (LTE Rel.8). The LTE system represents an efficient packet-based radio access and a radio access network that provides fully IP-based functions with low latency and low cost. In LTE, multiple scalable transmission bandwidths, such as 1.4, 3.0, 5.0, 10.0, 15.0 and 20.0 MHz, are specified to achieve flexible system deployment using a given spectrum. In the downlink, radio access based on orthogonal frequency division multiplexing (OFDM) is adopted, because it has inherent resistance to multipath interference (MPI) due to low symbol rate, use of cyclic prefix (CP) and its association with different transmission bandwidth arrangements. Radio access based on single carrier frequency division multiple access (SC-FDMA) is adopted in the uplink, because considering the limited transmit power of the user equipment (UE), the provision of wide area coverage is prioritized over increasing the peak data rate. Many key packet radio access technologies are adopted, including Multiple Input Multiple Output (MIMO) channel transmission technology, and an efficient control signaling structure is implemented in LTE Release 8 / 9.

[0007] LTE Architecture

[0008] The overall LTE system architecture is as follows Figure 1 As shown. E-UTRAN consists of eNodeBs, providing E-UTRA user plane (PDCP / RLC / MAC / PHY) and control plane (RRC) protocol terminations to user equipment (UE). The eNodeB (eNB) hosts the physical (PHY) layer, medium access control (MAC) layer, radio link control (RLC) layer, and packet data control protocol (PDCP) layer including user plane header compression and encryption functions. It also provides radio resource control (RRC) functions corresponding to the control plane. It performs many functions including radio resource management, admission control, scheduling, enhancement of negotiated uplink quality of service (QoS), cell information broadcast, encryption / decryption of user and control plane data, and compression / decompression of downlink / uplink user plane packet headers. The eNodeBs are interconnected to each other via the X2 interface.

[0009] The eNodeB is also connected to the EPC (Evolved Packet Core) via the S1 interface, more specifically to the MME (Mobility Management Entity) via S1-MME and to the Serving Gateway (SGW) via S1-U. The S1 interface supports a many-to-many relationship between the MME / Serving Gateway and the eNodeB. The SGW routes and forwards user data packets, while also acting as a mobility anchor for the user plane during inter-eNodeB handovers, and as an anchor for mobility between LTE and other 3GPP technologies (terminating the S4 interface and relaying traffic between 2G / 3G systems and PDN GW). For user devices in idle state, when downlink data arrives at the user device, the SGW terminates the downlink data path and triggers paging. It manages and stores user device contexts, such as parameters for IP bearer services or network internal routing information. It also performs replication of user traffic in the event of lawful interception.

[0010] The MME is a key control node for the LTE access network. It is responsible for idle mode user device tracking and paging processes, including retransmissions. It is involved in bearer activation / deactivation processing and is also responsible for selecting the SGW of the user device at the time of initial attachment and at intra-LTE handover involving core network (CN) node relocation. It is responsible for authenticating the user (by interacting with the HSS). Non-Access Stratum (NAS) signaling terminates at the MME, and it is also responsible for generating and allocating temporary identities to user devices. It checks the authorization of the user device to camp on the service provider's public land mobile network (PLMN) and enforces user device roaming restrictions. The MME is the termination point for encryption / integrity protection of NAS signaling in the network and handles security key management. The MME also supports legal signaling interception. The MME also provides control plane functions for mobility between LTE and 2G / 3G access networks, where the S3 interface terminates from the SGSN at the MME. The MME also terminates the S6a interface to the home HSS for roaming user devices.

[0011] Component Carrier Structure in LTE

[0012] The downlink component carriers of a 3GPP LTE system are subdivided in the time-frequency domain in so-called subframes. In 3GPP LTE, each subframe is divided into Figure 2The two downlink time slots shown in FIG. 1 include a control channel region (PDCCH region) within the first OFDM symbol. Each subframe consists of a given number of OFDM symbols in the time domain (12 or 14 OFDM symbols in 3GPP LTE (Release 8)), where each OFDM symbol spans the entire bandwidth of the component carrier. Therefore, an OFDM symbol consists of multiple modulation symbols sent on each subcarrier. In LTE, the transmitted signal in each time slot consists of N DL RB ×N RB SC subcarriers and N DL symb OFDM symbol resource grid. DL RB is the number of resource blocks within the bandwidth. DL RB Depends on the downlink transmission bandwidth configured in the cell and should satisfy

[0013]

[0014] Where N min,DL RB =6, and N max,DL RB =110 are the minimum downlink bandwidth and maximum downlink bandwidth supported by the current version of the specification. RB SC is the number of subcarriers in a resource block. For a normal cyclic prefix subframe structure, N RB SC =12 and N DL symb =7.

[0015] Assuming, for example, a multi-carrier communication system employing OFDM (such as used, for example, in 3GPP Long Term Evolution (LTE)), the smallest unit of resources that can be allocated by the scheduling unit is a "resource block". A physical resource block (PRB) is defined as consecutive OFDM symbols in the time domain (e.g., 7 OFDM symbols) and as in Figure 28) , Section 6.2, available from http: / / www.3gpp.org and incorporated herein by reference).

[0016] One subframe consists of two slots, so that when a so-called "normal" CP (cyclic prefix) is used, there are 14 OFDM symbols in a subframe, and when a so-called "extended" CP is used, there are 12 OFDM symbols in a subframe. For terminology reasons, in the following, time-frequency resources that are equivalent to the same consecutive subcarriers across a complete subframe are referred to as "resource block pairs" or equivalently "RB pairs" or "PRB pairs".

[0017] The term "component carrier" refers to the combination of several resource blocks in the frequency domain. In future versions of LTE, the term "component carrier" is no longer used; instead, the term is changed to "cell", which refers to the combination of downlink and optionally uplink resources. The link between the carrier frequency of the downlink resources and the carrier frequency of the uplink resources is indicated in the system information sent on the downlink resources.

[0018] Similar assumptions on the component carrier structure will also apply to later releases.

[0019] Carrier aggregation in LTE-A to support wider bandwidth

[0020] The World Radiocommunication Conference (WRC-07) in 2007 decided on the spectrum for advanced IMT. Although the overall spectrum for advanced IMT was determined, the actual available frequency bandwidth varies according to each region or country. However, after the outline of the available spectrum was determined, the standardization of the radio interface began with the Third Generation Partnership Project (3GPP). At the 3GPP TSG RAN#39 meeting, a research project description on "FurtherAdvancements for E-UTRA (LTE-Advanced)" was approved. This research project covers technical components to be considered for the evolution of E-UTRA, for example, to meet the requirements for advanced IMT.

[0021] The bandwidth that the Advanced LTE system can support is 100MHz, while the LTE system can only support 20MHz. Nowadays, the lack of radio spectrum has become a bottleneck for the development of wireless networks, and it is therefore difficult to find a frequency band wide enough for the Advanced LTE system. Therefore, it is urgent to find a way to obtain a wider radio spectrum band, among which the possible answer is the carrier aggregation function.

[0022] In carrier aggregation, two or more component carriers are aggregated to support wider transmission bandwidth up to 100 MHz. Several cells in an LTE system are aggregated into one wider channel wide enough for 100 MHz in an LTE-Advanced system, even though the cells in LTE may be in different frequency bands.

[0023] All component carriers may be configured as LTE Release 8 / 9 compatible, at least when the bandwidth of the component carrier does not exceed the bandwidth supported by the LTE Release 8 / 9 cell. Not all component carriers aggregated by a user device may necessarily be Release 8 / 9 compatible. Existing mechanisms (e.g., restrictions) may be used to prevent Rel-8 / 9 user devices from camping on a component carrier.

[0024] A user device can receive or transmit on one or more component carriers (corresponding to multiple serving cells) simultaneously depending on its capabilities. An LTE-A Release 10 user device with receiving and / or transmitting capabilities for carrier aggregation can receive and / or transmit on multiple serving cells simultaneously, whereas an LTE Release 8 / 9 user device can only receive and transmit on a single serving cell if the structure of the component carriers follows the Release 8 / 9 specifications.

[0025] Carrier aggregation is supported for both contiguous and non-contiguous component carriers, with each component carrier limited to a maximum of 110 resource blocks (using 3GPP LTE (Release 8 / 9) numerology) in the frequency domain.

[0026] It is possible to configure a 3GPP LTE-A (Release 10) compatible user device to aggregate different numbers of component carriers originating from the same eNodeB (base station) and different numbers of possible different bandwidths in the uplink and downlink. The number of downlink component carriers that can be configured depends on the downlink aggregation capability of the UE. Conversely, the number of uplink component carriers that can be configured depends on the uplink aggregation capability of the UE. It is currently not possible to configure a mobile terminal with more uplink component carriers than downlink component carriers. In a typical TDD deployment, the number of component carriers and the bandwidth of each component carrier in the uplink and downlink are the same. Component carriers originating from the same eNodeB do not need to provide the same coverage.

[0027] The spacing between the center frequencies of consecutive aggregated component carriers should be a multiple of 300kHz. This is to be compatible with the 100kHz frequency raster of 3GPP LTE (Release 8 / 9) and at the same time maintain the orthogonality of subcarriers with 15kHz spacing. Depending on the aggregation scenario, a spacing of n×300kHz can be facilitated by inserting a small number of unused subcarriers between consecutive component carriers.

[0028] The nature of multiple carrier aggregation is only exposed to the MAC layer. For both uplink and downlink, one HARQ entity is needed in the MAC for each aggregated component carrier. There is at most one transport block per component carrier (in the absence of SU-MIMO in the uplink). A transport block and its potential HARQ retransmissions need to be mapped on the same component carrier.

[0029] When carrier aggregation is configured, the mobile terminal has only one RRC connection with the network. In the RRC connection establishment / reestablishment, similar to LTE version 8 / 9, a cell provides security inputs (one ECGI, one PCI and one ARFCN) and non-access stratum mobility information (such as TAI). After the RRC connection establishment / reestablishment, the component carrier corresponding to the cell is called the downlink primary cell (Primary Cell, PCell). In the connected state, each user device is always configured with one and only one downlink PCell (DL PCell) and one uplink PCell (UL PCell). Within the configured component carrier set, other cells are called secondary cells (Secondary Cell, SCell); the carriers of the SCell are the downlink secondary component carrier (DL SCC) and the uplink secondary component carrier (UL SCC). For a UE, up to five serving cells can be configured, including the PCell.

[0030] MAC layer / entity, RRC layer, physical layer

[0031] The LTE layer 2 user plane / control plane protocol stack includes four sublayers, RRC, PDCP, RLC and MAC. The medium access control (MAC) layer is the lowest sublayer in the layer 2 architecture of the LTE radio protocol stack and is defined by, for example, 3GPP technical standard TS 36.321, current version 13.1.0 (NPL 2). The connection with the physical layer below is through the transport channel, and the connection with the RLC layer above is through the logical channel. Therefore, the MAC layer performs multiplexing and demultiplexing between logical channels and transport channels: the MAC layer on the sending side constructs a MAC PDU (called a transport block) from the MAC SDU received through the logical channel, while the MAC layer on the receiving side restores the MAC SDU from the MAC PDU received through the transport channel.

[0032] The MAC layer provides data transfer services to the RLC layer through logical channels (see subsections 5.4 and 5.3 of TS 36.321), which are either control logical channels that carry large control data (e.g., RRC signaling) or traffic logical channels that carry user plane data. On the other hand, data from the MAC layer is exchanged with the physical layer through transport channels, which are classified as downlink or uplink. Data is multiplexed into transport channels depending on how it is sent over the air.

[0033] The physical layer is responsible for the actual transmission of data and control information via the air interface, i.e., the physical layer carries all information from the MAC transport channel over the air interface on the transmission side. Some important functions performed by the physical layer include coding and modulation, link adaptation (AMC), power control, cell search (for initial synchronization and switching purposes), and other measurements for the RRC layer (within the LTE system and between systems). The physical layer performs transmission based on transmission parameters such as modulation scheme, coding rate (i.e., modulation and coding scheme, MCS), number of physical resource blocks, etc. More information about physical layer functions can be found in the 3GPP technical standard 36.213 current version 13.1.1 (NPL 3), which is incorporated herein by reference.

[0034] The Radio Resource Control (RRC) layer controls the communication between the UE and the eNB at the radio interface and the mobility of the UE moving across several cells. The RRC protocol also supports the transmission of NAS information. For UEs in RRC_IDLE, RRC supports notification of incoming calls from the network. RRC connection control covers all procedures related to the establishment, modification and release of RRC connections, including paging, measurement configuration and reporting, radio resource configuration, initial security activation, and the establishment of signaling radio bearers (SRBs) and radio bearers carrying user data (data radio bearers, DRBs).

[0035] The radio link control (RLC) sublayer mainly includes ARQ functions and supports data segmentation and concatenation, that is, the RLC layer performs framing of RLC SDUs to place them in the size indicated by the MAC layer. The latter two minimize protocol overhead independently of the data rate. The RLC layer is connected to the MAC layer via logical channels. Each logical channel transmits different types of traffic. The layer above the RLC layer is usually the PDCP layer, but in some cases it is the RRC layer, that is, the RRC messages sent on the logical channels BCCH (Broadcast Control Channel), PCCH (Paging Control Channel) and CCCH (Common Control Channel) do not require security protection, so they bypass the PDCP layer and go directly to the RLC layer.

[0036] Uplink access scheme for LTE

[0037] For uplink transmission, power efficient user terminal transmission is necessary to maximize coverage. Single carrier transmission combined with FDMA with dynamic bandwidth allocation has been selected as the evolved UTRA uplink transmission scheme. The main reason for preferring single carrier transmission is the lower peak-to-average power ratio (PAPR) compared to multi-carrier signals (OFDMA), and the corresponding improved power amplifier unit efficiency and improved coverage (higher data rate for a given terminal peak power). During each time interval, the Node B allocates a unique time / frequency resource for sending user data to the user, thereby ensuring orthogonality within the cell. Orthogonal access in the uplink ensures increased spectral efficiency by eliminating intra-cell interference. Interference due to multipath propagation is handled at the base station (Node B) by inserting a cyclic prefix in the transmitted signal.

[0038] The basic physical resource for data transmission consists of a frequency resource of size BWgrant during a time interval, such as a subframe in which the coded information bits are mapped. It should be noted that a subframe, also called a transmission time interval (TTI), is the minimum time interval for user data transmission. However, it is possible to allocate a frequency resource BWgrant for a period longer than one TTI to a user by concatenating subframes.

[0039] Layer 1 / Layer 2 control signaling

[0040] In order to inform the scheduled users of their allocation status, transmission format and other transmission related information (e.g., HARQ information, transmit power control (TPC) commands), L1 / L2 control signaling is sent on the downlink together with the data. Assuming that the user allocation can change between subframes, the L1 / L2 control signaling is multiplexed with the downlink data in the subframe. It should be noted that user allocation may also be performed based on TTI (Transmission Time Interval), where the TTI length can be a multiple of the subframe. The TTI length can be fixed in the service area for all users, can be different for different users, or can even be dynamic for each user. In general, L1 / 2 control signaling only needs to be sent once per TTI. Without loss of generality, it is assumed below that TTI is equivalent to one subframe.

[0041] L1 / L2 control signaling is sent on the Physical Downlink Control Channel (PDCCH). The PDCCH carries messages as Downlink Control Information (DCI), which in most cases includes resource allocations and other control information for a mobile terminal or UE group. In general, several PDCCHs may be sent in one subframe.

[0042] In general, the information sent in L1 / L2 control signaling for allocating uplink or downlink radio resources (particularly LTE(-A) Release 10) can be categorized into the following items:

[0043] - User ID , indicating the assigned user. This is usually included in the checksum by masking the CRC with the user identity;

[0044] - Resource allocation information , indicating the resources (e.g., resource blocks, RBs) to which the user is allocated. Alternatively, this information is called a resource block allocation (RBA). Note that the number of RBs allocated to a user can be dynamic;

[0045] - Carrier indicator , if the control channel allocation sent on the first carrier relates to resources of the second carrier (i.e., resources on the second carrier or resources associated with the second carrier) (cross-carrier scheduling), then using the carrier indicator;

[0046] - Modulation and coding schemes , which determines the modulation scheme and coding rate used;

[0047] - HARQ Information , which is particularly useful in the retransmission of a data message or parts thereof, such as a new data indicator (NDI) and / or a redundancy version (RV);

[0048] - Power Control Commands , to adjust the transmission power of the allocated uplink data or control information transmission;

[0049] - Reference signal information , such as an applied cyclic shift and / or an orthogonal cover code index, which will be used for transmission or reception of a reference signal associated with the allocation;

[0050] - Uplink or downlink allocation index , used to identify the order of allocation, which is particularly useful in TDD systems;

[0051] - Skip information , e.g., indicating whether and how resource hopping should be applied in order to increase frequency diversity;

[0052] - CSI Request , used to trigger the transmission of channel state information in the allocated resources; and

[0053] - Multi-cluster information , which is a flag used to indicate and control whether transmission occurs in a single cluster (contiguous RB set) or multiple clusters (at least two non-contiguous continuous RB sets). 3GPP LTE-(A) Release 10 introduced multi-cluster allocation.

[0054] It should be noted that the above list is not exhaustive and, depending on the DCI format used, not all mentioned information items need to be present in every PDCCH transmission.

[0055] Downlink control information occurs in several formats that differ in their overall size and, as mentioned above, in the information contained in their fields. The different DCI formats currently defined for LTE are as follows and are defined in 3GPP TS 36.212, "Multiplexing and channel coding", section 5.3.3.1 (current version v13.1.0 (NPL 4), http: / / www.3gpp.org 3GPP technical standard TS 36.212, current version 13.1.0, defines control information for the sidelink interface in subsection 5.4.3, which is incorporated herein by reference.

[0056] Reference List

[0057] Non-patent literature

[0058] NPL 1: 3GPP TS 36.211, Version 13.1.0

[0059] NPL 2: 3GPP TS 36.321, Version 13.1.0

[0060] NPL 3: 3GPP TS 36.213, version 13.1.1

[0061] NPL 4: 3GPP TS 36.212, version v13.1.0

[0062] NPL 5: 3GPP TS 23.203, Version 14.0.0

[0063] NPL 6: 3GPP TR 23.713, version v13.0.0

[0064] NPL 7: 3GPP TS 36.300, Version 13.3.0

[0065] NPL 8: 3GPP TS 23.303, version 13.4.0

[0066] NPL 9: 3GPP TR 21.905, Version 13.0.0

[0067] NPL 10: ETSI EN 302 637-2 v1.3.1

[0068] NPL 11: ETSI EN 302 637-3 v 1.2.1 Summary of the invention

[0069] Non-limiting and exemplary embodiments provide an improved transmission device and a corresponding method for transmitting vehicle data and for properly taking into account quality of service requirements. The independent claims provide non-limiting and exemplary embodiments. Advantageous embodiments are limited by the dependent claims.

[0070] According to one aspect of the present invention, a transmitting device for transmitting vehicle data to one or more receiving devices via a side link interface is disclosed, wherein the transmitting device performs autonomous radio resource allocation for transmitting vehicle data via the side link interface, wherein the transmitting device includes: a circuit for obtaining one or more quality of service configurations provided in the transmitting device, generating vehicle data in an application layer, and forwarding the generated vehicle data together with a priority indication indicating the priority of the vehicle data to a transport layer, in which the transport layer determines one of the one or more quality of service configurations obtained depending on the priority indication obtained together with the vehicle data and a mapping provided in the transmitting device associating each of the one or more quality of service configurations with a priority indication value, and performs autonomous radio resource allocation based on the determined one quality of service configuration, and a transmitting unit for transmitting the vehicle data to the one or more receiving devices via the side link interface according to the performed autonomous radio resource allocation.

[0071] According to another aspect of the present invention, a method for sending vehicle data from a sending device to one or more receiving devices via a side link interface is disclosed, wherein the sending device performs autonomous radio resource allocation for sending the vehicle data via the side link interface, the method including the following steps performed by the sending device: obtaining one or more quality of service configurations provided in the sending device, generating vehicle data in an application layer, and forwarding the generated vehicle data together with a priority indication indicating the priority of the vehicle data to a transport layer, the transport layer determining one of the one or more quality of service configurations obtained depending on the priority indication obtained together with the vehicle data and a mapping provided in the sending device that associates each of the one or more quality of service configurations with a priority indication value, and the transport layer performing autonomous radio resource allocation based on the determined one quality of service configuration, and sending the vehicle data to the one or more receiving devices via the side link interface based on the performed autonomous radio resource allocation.

[0072] According to another aspect of the present invention, an integrated circuit is disclosed for controlling processing of a transmitting device for sending vehicle data from a transmitting device to one or more receiving devices via a side link interface, wherein the transmitting device performs autonomous radio resource allocation for sending the vehicle data via the side link interface, the processing comprising: obtaining one or more quality of service configurations provided in the transmitting device, generating vehicle data in an application layer, and forwarding the generated vehicle data together with a priority indication indicating the priority of the vehicle data to a transport layer, the transport layer determining one of the one or more quality of service configurations obtained depending on the priority indication obtained together with the vehicle data and a mapping provided in the transmitting device associating each of the one or more quality of service configurations with a priority indication value, and the transport layer performing autonomous radio resource allocation based on the determined one quality of service configuration, and sending the vehicle data to the one or more receiving devices via the side link interface based on the performed autonomous radio resource allocation.

[0073] Several aspects are provided on how to support specific quality of service requirements for vehicle communications via the sidelink interface, especially when the UE is responsible for radio resource allocation. The basic scenario is that a sending device (such as an onboard UE) should send vehicle data to other devices via the sidelink interface. The onboard UE should support UE autonomous resource allocation as well as base station controlled resource allocation.

[0074] Correspondingly, according to the first aspect, the necessary quality of service parameters are sent together with the vehicle data to the lower layer responsible for the vehicle data transmission. The quality of service parameters are then used in the UE autonomous resource allocation performed by the vehicle UE to obtain suitable transmission parameters for transmitting the vehicle data while trying to implement the quality of service requirements. The vehicle data is then sent according to the obtained transmission parameters.

[0075] According to the second aspect, different quality of service configurations (each with a quality of service parameter) are defined, and the onboard UE performs resource allocation and transmission of vehicle data according to one of the quality of service configurations. Specifically, the application layer generates vehicle data and QoS configuration indications and forwards both to the responsible transport layer. In turn, the transport layer determines the corresponding quality of service configuration and quality of service parameters, and based on this performs UE autonomous radio resource allocation in order to obtain the necessary transmission parameters. The transport layer then sends the vehicle data via the side link interface.

[0076] According to the third aspect, the execution of UE autonomous resource allocation or base station controlled resource allocation depends on the data to be sent. Correspondingly, the on-board UE supports these two resource allocation modes provided for the side link interface, but executes one of them according to the data to be sent. It is assumed that the quality of service is only supported by the resource allocation controlled by the base station. Specifically, the application layer generates vehicle data and can, for example, generate a corresponding quality of service support indication, which indicates whether the quality of service should be supported by the lower layer. The quality of service indication can be forwarded to the corresponding transport layer of the on-board UE together with the vehicle data, and then the on-board UE executes the resource allocation indicated by the quality of service indication. The transmission parameters thus obtained (taking into account or not taking into account the quality of service requirements) are then used to actually send the vehicle data.

[0077] According to a fourth aspect, the sidelink logical channel prioritization process is improved by additionally considering the aggregate maximum bit rate of the onboard UE, which indicates the maximum throughput of vehicle data sent by the onboard UE via the sidelink interface. This additional parameter limits the throughput of vehicle data to be sent by the transmitting device via the sidelink interface.

[0078] Correspondingly, in a general first aspect, the technology disclosed herein is characterized by a transmitting device for transmitting vehicle data to one or more receiving devices via a side link interface. The transmitting device performs autonomous radio resource allocation to transmit vehicle data via the side link interface. The application layer of the transmitting device generates vehicle data and forwards the vehicle data to the transport layer responsible for transmitting the vehicle data via the side link interface together with a priority indication and one or more quality of service parameters. The transport layer performs autonomous radio resource allocation based on the received priority indication and one or more quality of service parameters. The transport layer sends the vehicle data to one or more receiving devices via the side link interface according to the performed autonomous radio resource allocation. Correspondingly, in a general first aspect, the technology disclosed herein is characterized by a method for transmitting vehicle data from a transmitting device to one or more receiving devices via a side link interface. The transmitting device performs autonomous radio resource allocation to transmit vehicle data via the side link interface. The method includes the following steps performed by the transmitting device. The vehicle data is generated in the application layer and forwarded to the transport layer responsible for transmitting the vehicle data via the side link interface together with a priority indication and one or more quality of service parameters. The transport layer performs autonomous radio resource allocation based on the received priority indication and one or more quality of service parameters. The transport layer sends the vehicle data to one or more receiving devices via the sidelink interface according to the autonomous radio resource allocation performed.

[0079] Correspondingly, in a general first aspect, the technology disclosed herein is characterized by a sending device for sending vehicle data to one or more receiving devices via a side link interface. The sending device performs autonomous radio resource allocation to send vehicle data via the side link interface. The receiving unit of the sending device receives system information broadcast by a radio base station in its radio cell, the system information including one or more quality of service configurations. The application layer of the sending device generates vehicle data and forwards the generated vehicle data together with an indication to a transport layer responsible for transmitting the vehicle data via the side link interface. The transport layer determines one of the one or more quality of service configurations received depending on the indication received together with the vehicle data. The transport layer performs autonomous radio resource allocation based on the determined one quality of service configuration. The transport layer sends the vehicle data to one or more receiving devices via the side link interface based on the performed autonomous radio resource allocation.

[0080] Correspondingly, in a general first aspect, the technology disclosed herein is characterized by a method for sending vehicle data from a sending device to one or more receiving devices via a side link interface. The sending device performs autonomous radio resource allocation to send vehicle data via the side link interface. The method includes the following steps performed by the sending device. System information broadcast by a radio base station in its radio cell is received by the sending device, the system information including one or more quality of service configurations. The vehicle data is generated in the application layer and forwarded to the transport layer responsible for transmitting the vehicle data via the side link interface together with an indication. The transport layer determines one of the one or more quality of service configurations received based on the indication received with the vehicle data, and performs autonomous radio resource allocation based on the determined one quality of service configuration. The vehicle data is sent to one or more receiving devices via the side link interface based on the performed autonomous radio resource allocation.

[0081] Correspondingly, in a general first aspect, the technology disclosed herein is characterized by a transmitting device for transmitting vehicle data to one or more receiving devices via a side link interface. The transmitting device performs autonomous radio resource allocation to transmit vehicle data via the side link interface. An aggregate maximum bit rate is defined for the transmitting device, which indicates the maximum allowed total vehicle data throughput of the transmitting device via the side link interface. The application layer of the transmitting device generates vehicle data and forwards the vehicle data to a transport layer responsible for transmitting the vehicle data via the side link interface. The transport layer performs autonomous radio resource allocation for the vehicle data, including the selection of frequency-time radio resources. The transport layer performs a side link logical channel prioritization process for allocating the selected frequency-time radio resources to generate data packets carrying vehicle data, and the side link logical channel process regards the aggregate maximum bit rate as a limit on the throughput of the vehicle data sent by the transmitting device via the side link interface. The transport layer uses the allocated frequency-time radio resources to send the generated data packets carrying vehicle data to one or more receiving devices.

[0082] Correspondingly, in a general first aspect, the technology disclosed herein is characterized by a method for sending vehicle data from a transmitting device to one or more receiving devices via a side link interface. The transmitting device performs autonomous radio resource allocation to send vehicle data via the side link interface. An aggregate maximum bit rate is defined for the transmitting device, which indicates the maximum allowed total vehicle data throughput of the transmitting device via the side link interface. The method includes the following steps performed by the transmitting device. The application layer generates vehicle data, which is forwarded to the transport layer responsible for transmitting the vehicle data via the side link interface. The transport layer performs autonomous radio resource allocation for the vehicle data, including the selection of frequency-time radio resources. The transport layer performs a side link logical channel prioritization process for allocating the selected frequency-time radio resources to generate data packets carrying vehicle data, and the side link logical channel process regards the aggregate maximum bit rate as a limit on the throughput of vehicle data sent by the transmitting device via the side link interface. The transport layer uses the allocated frequency-time radio resources to send the generated data packets carrying vehicle data to one or more receiving devices.

[0083] Additional benefits and advantages of the disclosed embodiments will be apparent from the description and drawings. Benefits and / or advantages may be provided individually by the various embodiments and features disclosed in the description and drawings, and need not be provided in full in order to obtain one or more of them.

[0084] These general and specific aspects may be implemented using systems, methods and computer programs, and any combination of systems, methods and computer programs. BRIEF DESCRIPTION OF THE DRAWINGS

[0085] Hereinafter, exemplary embodiments are described in more detail with reference to the accompanying drawings and accompanying drawings.

[0086] Figure 1 An exemplary architecture of a 3GPP LTE system is shown.

[0087] Figure 2 An exemplary downlink resource grid for a downlink time slot of a subframe defined for 3GPP LTE (Release 8 / 9) is shown.

[0088] Figure 3 It schematically illustrates how a layer 2 link for ProSe communication is established over PC5.

[0089] Figure 4 The usage of transmit / receive resources for overlay (LTE) and underlay (D2D) systems is illustrated.

[0090] Figure 5 Scheduling assignments and transmission of D2D data for two UEs are illustrated.

[0091] Figure 6 D2D communication timing for UE autonomous scheduling mode 2 is illustrated.

[0092] Figure 7 The D2D communication timing for scheduling mode 1 scheduled by the eNB is illustrated.

[0093] Figure 8 An exemplary architecture model for ProSe for non-roaming scenarios is illustrated.

[0094] Fig. 9 is a diagram for the first embodiment, illustrating the operation of the in-vehicle transmitting UE.

[0095] Fig.10 2 is a diagram for the second embodiment, illustrating the operation of the in-vehicle transmitting UE.

[0096] Fig.11 is a diagram for the third embodiment, illustrating the operation of the in-vehicle transmitting UE. DETAILED DESCRIPTION

[0097] Basis of the Disclosure

[0098] Quality of Service

[0099] Multiple applications can be running in a UE at any time, each with different requirements for its quality of service. For example, a UE can participate in a VoIP (Voice over IP) call while browsing a web page or downloading an FTP file. VoIP has more stringent quality of service requirements in terms of delay and delay jitter than web browsing and FTP, which require a lower packet loss rate. In order to support multiple QoS requirements, different bearers are established within the Evolved Packet System, for example, associated with QoS.

[0100] In general, bearers can be divided into two categories based on the nature of the quality of service they provide, minimum guaranteed bit radio (GBR) bearers and non-GBR bearers. GBR bearers can be used for applications such as IP voice and have an associated GBR value to which dedicated transmission resources are permanently allocated (e.g., by an admission control function in the eNodeB). If resources are available, then a GBR bearer may be allowed to have a bit rate higher than the GBR. In this case, the maximum bit rate (MBR) parameter sets an upper limit on the bit rate that can be expected from a GBR bearer. Non-GBR bearers do not guarantee any specific bit rate and can be used for applications such as web browsing or FTP transfers. For these bearers, no bandwidth resources are permanently allocated to the bearer.

[0101] In the access network, the eNodeB is responsible for ensuring the necessary QoS for the bearer over the radio interface. When establishing a new bearer, the MME signals the eNodeB with a Bearer Setup Request (EPS Bearer Identity, EPS Bearer QoS, Session Management Request, S1-TEID) message, which then maps the EPS Bearer QoS to the Radio Bearer QoS. It then signals the UE with an RRC Connection Reconfiguration (Radio Bearer QoS, Session Management Request, EPS RB Identity) message.

[0102] The EPS bearer QoS profile includes the parameters QCI (QoS Class Identifier), ARP (Allocation and Reservation Priority), GBR (Guaranteed Bit Rate) and MBR (Maximum Bit Rate). Each EPS bearer (GBR and non-GBR type) is associated with the following bearer level QoS parameters:

[0103] - QoS Class Identifier (QCI);

[0104] - Allocation and Retention Priority (ARP).

[0105] QCI is a scalar that is used as a reference to access node-specific parameters that control the bearer-level packet forwarding processing to be performed by the LTE node (e.g., scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.), and has been pre-configured by the operator that owns the access node (e.g., eNodeB). A one-to-one mapping of standardized QCI values ​​to standardized characteristics is obtained in TS 23.203, as shown in the following table, which is based on Table 6.1.7 in TS 23.203 current version 14.0.0 (NPL 5).

[0106] [Table 1]

[0107]

[0108]

[0109] Obviously, each QCI contains standardized characteristics such as resource type (GBR or non-GBR), priority (1-9; lower values ​​mean higher priority), packet delay budget (allowed packet delay ranges from 50ms to 300ms), packet error loss rate (allowed packet loss ranges from 10 -2 to 10 -6 ). By predefining and standardizing the performance characteristics of each QCI value, network operators can ensure that the same minimum QoS requirements are provided to different services / applications used in an LTE network consisting of various nodes from several vendors.

[0110] The priority and packet delay budget from the QCI (and to some extent the acceptable packet loss rate) determine the RLC mode configuration (i.e., transparent, unacknowledged, acknowledged) and how the scheduling unit in the MAC handles packets sent over the bearer (e.g., in terms of scheduling policy, queue management policy, and rate shaping policy).

[0111] Logical Channel Priority, LCP, Procedure

[0112] For the uplink, the process by which the UE creates a MAC PDU to be transmitted using the allocated radio resources is fully standardized; the LCP procedure is designed to ensure that the UE meets the QoS of each configured radio bearer in an optimal and consistent manner between different UE implementations. Based on the uplink transmission resource grant message signaled on the PDCCH, the UE must decide the amount of data for each logical channel to be included in the new MAC and, if necessary, allocate space for MAC control elements.

[0113] When constructing a MAC PDU with data from multiple logical channels, the simplest and most intuitive approach is the absolute priority-based approach, where MAC PDU space is allocated to logical channels in descending order of logical channel priority. That is, data from the highest priority logical channel is served first in the MAC PDU, followed by data from the next highest priority logical channel until the MAC PDU space is exhausted. Although the absolute priority-based approach is very simple in terms of UE implementation, it can sometimes lead to starvation of data from low-priority logical channels; starvation means that data from low-priority logical channels cannot be sent because data from high-priority logical channels occupy all MAC PDU space.

[0114] In LTE, a prioritized bit rate (PBR) is defined for each logical channel in order to send data in order of importance, but also to avoid starvation of data with lower priority. PBR is the minimum data rate guaranteed for a logical channel. Even if a logical channel has a low priority, at least a small amount of MAC PDU space is allocated to guarantee the PBR. Therefore, the starvation problem can be avoided by using PBR.

[0115] Logical channel priority is for example standardized in the current version v13.1.0 of 3GPP TS 36.321 in subsection 5.4.3.1 which is incorporated herein by reference.When a new transmission is performed, the Logical Channel Prioritization (LCP) procedure is applied.

[0116] LTE Device-to-Device (D2D) Proximity Services (ProSe)

[0117] Proximity-based applications and services represent an emerging social technology trend. The identified areas include services related to commercial services and public safety that will be of interest to operators and users. The introduction of Proximity Services (ProSe) capabilities in LTE will allow the 3GPP industry to serve this developing market and will simultaneously serve the pressing needs of several public safety communities working together on LTE.

[0118] Device-to-device (D2D) communication is a technical component of LTE-Rel.12. Device-to-device (D2D) communication technology allows D2D as the underlying layer of the cellular network to improve spectrum efficiency. For example, if the cellular network is LTE, all physical channels carrying data use SC-FDMA for D2D signaling. In D2D communication, user devices use cellular resources to send data signals to each other via direct links rather than through radio base stations. Throughout this disclosure, the terms "D2D", "ProSe" and "sidelink" are interchangeable.

[0119] D2D communication in LTE mainly focuses on two aspects: discovery and communication.

[0120] ProSe (Proximity-based Services) direct discovery is defined as a procedure used by a ProSe-enabled UE to discover other ProSe-enabled UEs in its vicinity via the PC5 interface using E-UTRA direct radio signals.

[0121] In D2D communication, UEs use cellular resources to send data signals to each other via direct links instead of through a base station (BS). D2D users communicate directly while remaining under BS control, i.e., at least when in the coverage of an eNB. Therefore, D2D can improve system performance by reusing cellular resources.

[0122] It is assumed that D2D operates in the uplink LTE spectrum (in the case of FDD) or uplink subframes of the cell providing coverage (in the case of TDD, except when outside of coverage). In addition, D2D transmission / reception does not use full duplex on a given carrier. From the perspective of an individual UE, D2D signal reception and LTE uplink transmission on a given carrier do not use full duplex, i.e., simultaneous D2D signal reception and LTE UL transmission are not possible.

[0123] In D2D communication, when a specific UE1 has a transmitting role (transmitting user equipment or transmitting terminal), UE1 transmits data and another UE2 (receiving user equipment) receives it. UE1 and UE2 can change their transmitting and receiving roles. The transmission from UE1 can be received by one or more UEs such as UE2.

[0124] ProSe direct communication layer 2 link

[0125] In short, ProSe direct one-to-one communication is achieved by establishing a secure Layer 2 link on PC5 between two UEs. Each UE has a Layer 2 ID for unicast communication, which is included in the source Layer 2 ID field of each frame it sends on the Layer 2 link and in the destination Layer 2 ID of each frame it receives on the Layer 2 link. The UE needs to ensure that the Layer 2 ID used for unicast communication is at least locally unique. Therefore, the UE should be prepared to use unspecified mechanisms to handle Layer 2 ID conflicts with neighboring UEs (for example, self-assigning a new Layer 2 ID for unicast communication when a conflict is detected). The Layer 2 link used for one-to-one ProSe direct communication is identified by the combination of the Layer 2 IDs of the two UEs. This means that the UE can participate in multiple Layer 2 links for one-to-one ProSe direct communication using the same Layer 2 ID.

[0126] ProSe Direct Communication One-to-One consists of the following procedures, as detailed in Section 7.1.2 of TR 23.713 current version v13.0.0 (NPL 6), incorporated herein by reference:

[0127] - Establishment of a secure layer 2 link on PC5.

[0128] -IP address / prefix assignment.

[0129] -Layer 2 link maintenance on PC5.

[0130] -Layer 2 link release on PC5.

[0131] Figure 3 Illustrate how to establish a secure layer 2 link on the PC5 interface.

[0132] 1. UE-1 sends a direct communication request message to UE-2 in order to trigger mutual authentication. The link initiator (UE-1) needs to know the layer 2 ID of the peer (UE-2) to perform step 1. As an example, the link initiator may learn the layer 2 ID of the peer by first performing a discovery procedure or by participating in a ProSe one-to-many communication involving the peer.

[0133] 2. UE-2 initiates a procedure for mutual authentication. Successful completion of the authentication procedure completes the establishment of a secure layer 2 link on PC5.

[0134] UEs participating in isolated (non-relayed) one-to-one communications may also use link-local addresses. The PC5 signaling protocol shall support a keep-alive functionality that is used to detect when UEs are out of ProSe communication range so that they can proceed with an implicit Layer 2 link release. A Layer 2 link release over PC5 may be performed using a Disconnect Request message sent to the other UE, which also deletes all associated context data. Upon receiving the Disconnect Request message, the other UE responds with a Disconnect Response message and deletes all context data associated with the Layer 2 link.

[0135] ProSe direct communication related logo

[0136] 3GPP TS 36.300, current version 13.3.0, (NPL 4) defines the following identities for ProSe direct communication in subsection 8.3:

[0137] - SL-RNTI : (Sidelink Radio Network Temporary Identifier) ​​A unique identifier used for ProSe direct communication scheduling;

[0138] - Source layer 2 ID : Identifies the sender of data in sidelink ProSe direct communication. The source layer 2 ID is 24 bits long and is used together with the ProSe layer 2 destination ID and LCID to identify the RLC UM entity and PDCP entity in the receiver;

[0139] - Destination Layer 2 ID : Identifies the destination of data in Sidelink ProSe Direct Communication. The destination Layer 2 ID is 24 bits long and is split into two bit strings in the MAC layer:

[0140] --One bit string is the LSB portion (8 bits) of the destination layer 2 ID and is forwarded to the physical layer as the sidelink control layer-1 ID. This identifies the destination of the desired data in the sidelink control and is used to filter packets at the physical layer.

[0141] --The second bit string is the MSB part (16 bits) of the destination layer 2 ID and is carried within the MAC header. This is used to filter packets at the MAC layer.

[0142] No access stratum signaling is required for group formation and configuration of source layer 2 ID, destination layer 2 ID and side link control L1 ID in the UE. These identities are either provided by higher layers or derived from identities provided by higher layers. In case of multicast and broadcast, the ProSe UE ID provided by higher layers is directly used as source layer 2 ID, and the ProSe layer 2 group ID provided by higher layers is directly used as destination layer 2 ID in the MAC layer.

[0143] Radio Resource Allocation for Proximity Services

[0144] From the transmitting UE perspective, a ProSe-enabled UE (ProSe-enabled UE) can operate in two modes for resource allocation:

[0145] Mode 1 refers to an eNB-scheduled resource allocation mode, in which the UE requests transmission resources from the eNB (or Release 10 relay node), and the eNodeB (or Release 10 relay node) in turn schedules the resources used by the UE to send direct data and direct control information (e.g., scheduling assignments). In order to send data, the UE needs to be in RRC_CONNECTED. Specifically, the UE sends a scheduling request (D-SR or random access) to the eNB, followed by a buffer status report (BSR) in the usual way (see also the following section "Transmission procedure for D2D communication"). Based on the BSR, the eNB can determine that the UE has data for ProSe direct communication transmission and can estimate the resources required for the transmission.

[0146] On the other hand, mode 2 refers to a UE autonomous resource selection mode, in which the UE selects resources (time and frequency) from a resource pool by itself to send direct data and direct control information (i.e. SA). At least one resource pool is defined, for example, by the content of SIB 18, i.e., by the field commTxPoolNormalCommon, and these specific resource pools are broadcast in the cell and are then available to all UEs in the cell that are still in the RRC_Idle state. Effectively, the eNB can define up to four different instances of the pool, i.e., four resource pools for the transmission of SA messages and direct data, respectively. However, in Rel-12, even if the UE is configured with multiple resource pools, it should always use the first resource pool defined in the list. This restriction is removed for Rel-13, i.e., the UE can transmit on multiple configured resource pools within one SC period. It is further outlined below (further specified in TS36.321) how the UE selects a resource pool for transmission.

[0147] As an alternative, another resource pool may be defined by the eNB and signaled in SIB18, i.e. by using the field commTxPoolExceptional which may be used by the UE in exceptional cases.

[0148] Which resource allocation mode the UE intends to use may be configured by the eNB. In addition, which resource allocation mode the UE intends to use for D2D data communication may also depend on the RRC state (i.e., RRC_IDLE or RRC_CONNECTED) and the coverage state of the UE (i.e., in coverage, out of coverage). If the UE has a serving cell (i.e., the UE is RRC_CONNECTED or is camping on a cell in RRC_IDLE), then the UE is considered to be in coverage.

[0149] Figure 4 The usage of transmit / receive resources for overlay (LTE) and underlay (D2D) systems is illustrated.

[0150] Basically, the eNodeB controls whether the UE can apply Mode 1 or Mode 2 transmission. Once the UE knows the resources on which it can send (or receive) D2D communication, it only uses the corresponding resources for the corresponding transmission / reception. Figure 4 In the D2D subframe, the D2D subframe will only be used to receive or send D2D signals. Since the UE as a D2D device will operate in half-duplex mode, it can either receive or send D2D signals at any time point. Similarly, Figure 4 The other subframes shown may be used for LTE (overlay) transmission and / or reception.

[0151] Transmission process for D2D communication

[0152] The D2D data transmission procedure according to Rel.12 / 13 differs depending on the resource allocation mode. As described above, for Mode 1, the eNB explicitly schedules resources for scheduling allocation and D2D data communication following a corresponding request from the UE. Specifically, the eNB may inform the UE that D2D communication is generally allowed, but that Mode 2 resources (i.e., resource pools) are not provided; this may be done, for example, by exchanging the UE's D2D communication interest indication and the corresponding response (i.e., D2D communication response), wherein the corresponding exemplary ProseCommConfig information element will not include commTxPoolNormalCommon, which means that a UE wishing to start direct communication involving transmissions must request the E-UTRAN to assign resources for each individual transmission. Therefore, in this case, the UE must request resources for each individual transmission, and in the following, the different steps of the request / grant procedure for this Mode 1 resource allocation are exemplarily listed:

[0153] - Step 1: UE sends SR (scheduling request) to eNB via PUCCH;

[0154] - Step 2: The eNB grants UL resources scrambled by C-RNTI via PDCCH (for the UE to send BSR);

[0155] - Step 3: The UE sends a D2D BSR indicating the buffer status via PUSCH;

[0156] - Step 4: The eNB grants D2D resources scrambled by SL-RNTI via PDCCH (for UE to send data).

[0157] - Step 5: The D2D Tx UE sends SA / D2D data according to the grant received in step 4.

[0158] The Scheduling Assignment (SA), also known as SCI (Sidelink Control Information), is a compact (low payload) message containing control information, such as pointers to time-frequency resources, modulation and coding schemes, and a group destination ID for the corresponding D2D data transmission. The SCI transmits sidelink scheduling information for one (ProSE) destination ID. The content of the SA (SCI) substantially corresponds to the grant received in step 4 above. The D2D grant and the SA content (i.e., the SCI content) are defined in subsection 5.4.3 of 3GPP Technical Standard TS 36.212, current version 13.1.0, incorporated herein by reference, where in particular SCI format 0 is defined (see the content of SCI format 0 above).

[0159] On the other hand, for Mode 2 resource allocation, the above steps 1-4 are basically not required, and the UE autonomously selects radio resources for SA and D2D data transmission from a transmission resource pool configured and provided by the eNB.

[0160] Figure 5 Scheduling assignments for two UEs (UE-1 and UE-2) and transmission of D2D data are exemplarily illustrated, wherein resources for sending scheduling assignments are periodic and resources for D2D data transmission are indicated by corresponding scheduling assignments.

[0161] Figure 6 A specific example of D2D communication timing for Mode 2 autonomous scheduling during one SA / data period (also called SC period, Sidelink Control period) is illustrated. Figure 7 The figure shows the D2D communication timing for Mode 1 eNB scheduled allocations during one SA / data period. In Rel. 13, 3GPP defines the SC period as a time period consisting of the transmission of a scheduling assignment and its corresponding data. Figure 6As can be seen in the figure, the UE sends a scheduling assignment using the transmission pool resources (SA_Mode2_Tx_pool) for mode 2 scheduling assignments after the SA offset time. The first transmission of SA is followed by three retransmissions of the same SA message. The UE then starts D2D data transmission after the first subframe of the SA resource pool with a certain configured offset (Mode2data_offset) (given by SA_offset), i.e., more specifically the T-RPT bitmap / pattern. A D2D data transmission of a MAC PDU (i.e., transport block) includes its first initial transmission and several retransmissions. In order Figure 6 (and Figure 7 ), assuming that three retransmissions are performed (i.e., the 2nd, 3rd, and 4th transmissions of the same MAC PDU). The Mode2 T-RPT bitmap (Time Resource Mode of Transmission, T-RPT) basically defines the timing of a MAC PDU transmission (1st transmission) and its retransmissions (2nd, 3rd, and 4th transmissions). The SA mode basically defines the timing of the initial transmission of the SA and its retransmissions (2nd, 3rd, and 4th transmissions).

[0162] As currently specified in the standards, for one sidelink grant, e.g., whether sent by the eNB or selected by the UE itself, the UE may send multiple transport block MAC PDUs (only one per subframe (TTI), i.e., one after another), but only to one ProSe destination group. Moreover, the retransmission of one transport block must be completed before the first transmission of the next transport block starts, i.e., each sidelink grant uses only one HARQ process to transmit multiple transport blocks. Furthermore, the UE may have and use several sidelink grants in each SC period, but select a different ProSe destination for each of them. Thus, in one SC period, the UE may send data to only one ProSe destination at a time.

[0163] As from Figure 7 As is evident from FIG. 1 , for the resource allocation mode scheduled by the eNB (mode 1), the D2D data transmission (i.e., more specifically the T-RPT mode / bitmap) starts in the next UL subframe after the last SA transmission repetition in the SA resource pool. Figure 6 As explained, the Mode 1 T-RPT bitmap (Time Resource Mode of Transmission T-RPT) basically defines the timing of a MAC PDU transmission (1st transmission) and its retransmission (2nd, 3rd and 4th transmission).

[0164] The sidelink data transmission procedure can be found in 3GPP standard document TS 36.321 v13.1.0, section 5.14, which is incorporated herein by reference. Therein, Mode 2 autonomous resource selection is described in detail, distinguishing between being configured with a single radio resource pool or multiple radio resource pools.

[0165] The above discussion is about the current status of the 3GPP standard for D2D communication. However, it should be noted that there are ongoing discussions on how to further improve and enhance D2D communication, which will likely result in some changes to D2D communication in future releases. The present disclosure, which will be described later, also applies to those later releases.

[0166] For example, for 3GPP Rel.14, which is currently under development, 3GPP may decide to change the transmission timing so as to no longer be based on the SC period, as discussed above, but in a different manner (e.g., based on the same / similar subframes as the Uu interface transmission). Correspondingly, the above detailed examples on how transmission on the sidelink (PC5) interface may be performed are merely exemplary and may be applicable to Rel.13, but may not be suitable for subsequent versions of the corresponding 3GPP standard.

[0167] ProSe network architecture and ProSe entities

[0168] Figure 8 A high-level exemplary architecture for a non-roaming case is illustrated, including different ProSe applications in respective UEs A and B, and a ProSe application server and ProSe functions in the network. Figure 8 The example architecture of is taken from TS 23.303 v.13.2.0, Chapter 4.2, "Architectural Reference Model," which is incorporated herein by reference.

[0169] The functional entities are described and explained in detail in TS 23.303 subsection 4.4 "Functional Entities", which is incorporated herein by reference. The ProSe function is a logical function for the network-related actions required for ProSe and plays a different role for each feature of ProSe. The ProSe function is part of the 3GPP EPC and provides all relevant network services related to proximity services, such as authorization, authentication, data processing, etc. For ProSe direct discovery and communication, the UE can obtain the specific ProSe UE identity, other configuration information and authorization from the ProSe function via the PC3 reference point. There may be multiple deployed ProSe functions in the network, but for ease of illustration, a single ProSe function is presented. The ProSe function consists of three main sub-functions that perform different roles depending on the ProSe feature: Direct Provision Function (DPF), Direct Discovery Name Management Function, and EPC-level Discovery Function. The DPF is used to supply the UE with the necessary parameters for using ProSe direct discovery and ProSe direct communication.

[0170] The term "UE" used in the connection refers to a ProSe-enabled UE that supports ProSe functionality, such as

[0171] - ProSe control information is exchanged between the ProSe-enabled UE and the ProSe function over the PC3 reference point.

[0172] - Procedure to enable ProSe direct discovery of other ProSe-enabled UEs over the PC5 reference point.

[0173] -The process of one-to-many ProSe direct communication over the PC5 reference point.

[0174] -The process of acting as a ProSe UE to Network Relay. The remote UE communicates with the ProSe UE to Network Relay over the PC5 reference point. The ProSe UE to Network Relay uses Layer 3 packet forwarding.

[0175] - Exchange of control information between ProSe UEs over the PC5 reference point, e.g. for UE-to-network relay detection and ProSe direct discovery.

[0176] - ProSe control information is exchanged between another ProSe-enabled UE and the ProSe function over the PC3 reference point. In the ProSe UE to network relay case, the remote UE shall send this control information over the PC5 user plane to be relayed towards the ProSe function over the LTE-Uu interface.

[0177] - Configuration of parameters (e.g., including IP address, ProSe Layer 2 group ID, group security material, radio resource parameters). These parameters can be pre-configured in the UE or, if in overlay, provided to the ProSe function in the network via signaling over the PC3 reference point.

[0178] The ProSe application server supports the storage of EPC ProSe user ID and ProSe function ID, as well as the mapping of application layer user ID and EPC ProSe user ID. The ProSe application server (AS) is an entity outside the scope of 3GPP. The ProSe application in the UE communicates with the ProSe AS via the application layer reference point PC1. The ProSe AS is connected to the 3GPP network via the PC2 reference point.

[0179] LCP procedure for D2D, sidelink logical channel

[0180] The LCP procedure for D2D according to Rel. 13 will be different from the LCP procedure given above for "normal" uplink LTE data sent on the Uu interface. The following information is extracted from TS 36.321, current version 13.1.0, subsection 5.14.1.3.1, which describes the LCP procedure for ProSe; the entire contents of which are incorporated herein by reference.

[0181] The logical channel prioritization process is applied when a new transmission is performed. Each sidelink logical channel has an associated priority, which can be PPPP (ProSe per-packet priority, explained later). Multiple sidelink logical channels can have the same associated priority. The mapping between priority and LCID is left to the UE implementation.

[0182] The MAC entity shall perform the following logical channel prioritization procedure for each SCI sent during the SC period:

[0183] - The MAC entity shall allocate resources to the sidelink logical channel as follows:

[0184] -- Step 0: Among the sidelink logical channels with data available for transmission, select a ProSe destination with the highest priority sidelink logical channel that was not previously selected for this SC period;

[0185] -- Step 1: Allocate resources to the sidelink logical channel with the highest priority among the sidelink logical channels belonging to the selected ProSe destination and having data available for transmission;

[0186] -- Step 2: If any resources remain, the sidelink logical channels belonging to the selected ProSe destination are served in descending order of priority until either the data for the sidelink logical channel or the SL grant is exhausted, whichever comes first. Sidelink logical channels configured with the same priority should be served equally.

[0187] - During the above scheduling process, the UE shall also follow the following rules:

[0188] The UE shall allocate resources to the sidelink logical channels according to the following rules:

[0189] - If the entire SDU (or partially transmitted SDU) fits into the remaining resources, the UE shall not segment the RLC SDU (or partially transmitted SDU);

[0190] - If the UE segments RLC SDUs from a sidelink logical channel, it should maximize the size of the segments to fit as much of the grant as possible;

[0191] -UE should maximize the transmission of data;

[0192] - If the MAC entity is given a sidelink grant size equal to or greater than 10 bytes while having data available for transmission, the MAC entity shall not send only padding.

[0193] NOTE: The above rules imply that the order in which the sidelink logical channels are served is left to the UE implementation.

[0194] In general, for one MAC PDU, the MAC should only consider logical channels with the same source layer 2 ID - destination layer 2 ID pair, i.e., for one MAC PDU, the MAC entity in the UE should only consider logical channels of the same ProSe destination group, which basically means that the UE selects the ProSe destination during the LCP procedure. In Rel-13, multiple sidelink grants are allowed within an SC period. For each sidelink grant, the UE can send data for only one ProSe destination group as in Rel-12. However, since the UE can be configured to have more than one valid sidelink grant within one SC period, the sending UE can send data to different ProSe destinations, i.e., each SL grant must send data to a different ProSe destination.

[0195] QoS support for ProSe

[0196] In Rel-13, ProSe one-to-many communications generally support QoS. For this reason, the so-called ProSe per-packet priority (PPPP) is introduced, for example, in TS 23.303, Version 13.4.0 (NPL8), Section 5.4.6. The ProSe per-packet priority is a scalar value associated with a protocol data unit (e.g., an IP packet) that defines the priority treatment to be applied to the transmission of that protocol data unit, i.e., the priority treatment of transmissions on the PC5 interface. In other words, ProSe PPP is a mechanism for allowing prioritization of packets when using ProSe direct communication, including for ProSe UE-to-UE and also for ProSe relays.

[0197] When the ProSe upper layer (ie, above the PC5 access layer) passes a protocol data unit for transmission to the PC5 access layer, the ProSe upper layer provides a ProSe per-packet priority from a range of 8 possible values.

[0198] The ProSe per-packet priority is independent of the destination Layer 2 ID and is applicable to both one-to-one and one-to-many ProSe direct communications. The ProSe per-packet priority is selected by the application layer, for example, based on various criteria that are beyond the scope of this specification (such as latency requirements for services like voice packet transmission or control signaling like signaling related to floor control).

[0199] The ProSe per-packet priority is independent of the mode in which the UE accesses the medium, i.e., whether eNB scheduling or UE autonomous resource allocation mode is used for ProSe communication. The application layer is unaware of which allocation mode is being used by the lower layers of the ProSe-UE. The ProSe access layer uses the ProSe per-packet priority associated with the protocol data unit received from the upper layers to prioritize the transmission relative to other intra-UE transmissions (i.e., protocol data units associated with different priorities waiting for transmission in the same UE) and inter-UE transmissions (i.e., protocol data units associated with different priorities waiting for transmission in different UEs).

[0200] It is expected that priority queues (intra-UE and inter-UE) are served in strict priority order, i.e., the UE or eNB serves all packets associated with ProSe per-packet priority N before serving packets associated with priority N+1 (lower numbers mean higher priority).

[0201] Priority handling on the interface itself will be specified in TS36.321, i.e. the Logical Channel Priority LCP procedure. For each sidelink logical channel, there will be an associated priority, for example, similar to the logical channel priority in legacy LTE UL operation. The creation of sidelink logical channels will be left to the UE implementation, similar to Rel-12. In addition to considering the source / destination ID of the packet when creating the logical channel, the UE will also consider the priority of the packet. Protocol data units with essentially the same PPPP value (and the same source / destination ID) will be served by one sidelink logical channel with a certain associated logical channel priority (which is the same as PPPP).

[0202] As described above, during the logical channel prioritization process when the UE receives a SL grant, the UE selects the ProSe group of sidelink logical channels with the highest PPPP among the sidelink logical channels with SL data, and then serves all sidelink logical channels belonging to the selected ProSe destination group in descending order of priority.

[0203] Vehicle-to-everything (V2X) services

[0204] New study items have been set up in 3GPP in Rel.14 to consider the usefulness of new LTE features for the automotive industry - including proximity services (ProSe) and LTE-based broadcast services. ProSe features are therefore considered to provide a good basis for V2X services. Cooperative services in vehicular scenarios are becoming essential for future connected vehicles in the ITS (Intelligent Transport Systems) research area. They should reduce the number of road traffic fatalities, increase road capacity, reduce the carbon footprint of road transport, and increase the user experience during travel.

[0205] V2X communication is the transfer of information from a vehicle to any entity that may affect the vehicle and vice versa. This information exchange can be used to improve safety, mobility and environmental applications to include driver assistance vehicle safety, speed adaptation and warnings, emergency response, travel information, navigation, traffic operations, commercial fleet planning and payment transactions.

[0206] LTE support for V2X services encompasses three types of different use cases, as follows:

[0207] -V2V: Covers LTE-based communications between vehicles.

[0208] -V2P: covers LTE-based communications between vehicles and personally carried devices (e.g., handheld terminals carried by pedestrians, cyclists, drivers or passengers).

[0209] -V2I: Covers LTE-based communications between vehicles and roadside units.

[0210] These three types of V2X can use "cooperative awareness" to provide smarter services to end users. This means that traffic entities (such as vehicles, roadside infrastructure, and pedestrians) can collect knowledge of their local environment (e.g., information received from other nearby vehicles or sensor devices) to process and share this knowledge in order to provide smarter services, such as cooperative collision warnings or autonomous driving.

[0211] Regarding V2V communication, E-UTRAN allows such (vehicle) UEs in close proximity to each other to exchange V2V related information using E-UTRA(N) when the permission, authorization and proximity criteria are met. The proximity criteria can be configured by the MNO (Mobile Network Operator). However, UEs supporting V2V services can exchange such information when served or not by E-UTRAN supporting V2X services.

[0212] Devices supporting V2V applications (onboard UEs) send application layer information (e.g. about their location, dynamics and attributes as part of the V2V service). The V2V payload must be flexible to accommodate different information contents and can send information periodically according to the configuration provided by the MNO.

[0213] V2V is primarily broadcast-based; V2V includes exchanging V2V-related application information directly between different devices and / or, due to the limited direct communication range of V2V, exchanging V2V-related application information between different devices via an infrastructure supporting V2X services (e.g., RSU, application server, etc.).

[0214] Regarding V2I communication, a device supporting a V2I application sends application layer information to a roadside unit, which in turn may send the application layer information to a group of devices or devices supporting the V2I application.

[0215] V2N (Vehicle to Network, eNB / CN) is also introduced, where one party is a UE and the other party is a service entity, both parties support V2N applications and communicate with each other via an LTE network.

[0216] Regarding V2P communication, E-UTRAN allows these UEs in close proximity to each other to exchange V2P related information using E-UTRAN when the permission, authorization and proximity criteria are met. The proximity criteria can be configured by the MNO. However, UEs supporting V2P services can exchange such information even when not served by E-UTRAN supporting V2X services.

[0217] A UE supporting V2P applications sends application layer information. Such information can be broadcast by a vehicle with a UE supporting V2X services (e.g., a warning to pedestrians) and / or by a pedestrian with a UE supporting V2X services (e.g., a warning to a vehicle).

[0218] V2P includes exchanging V2P-related application information directly between different UEs (one for vehicles and the other for pedestrians) and / or, due to the limited direct communication range of V2P, exchanging V2P-related application information between different UEs via the infrastructure supporting V2X services (e.g., RSU, application server, etc.).

[0219] For this new study item V2X, 3GPP provides specific terms and definitions in TR 21.905, current version 13.0.0 (NPL9), which can be reused in this application.

[0220] Roadside Unit (RSU): An entity that supports V2I services that can be sent to and received from UEs using V2I applications. RSU can be implemented in an eNB or a fixed UE.

[0221] V2I service: A type of V2X service where one party is the UE and the other party is the RSU, and both parties use V2I applications.

[0222] V2N service: A type of V2X service where one party is the UE and the other party is the service entity, both parties use V2N applications and communicate with each other via an LTE network entity.

[0223] V2P service: A type of V2X service where both communicating parties are UEs using V2P applications.

[0224] V2V service: A type of V2X service where both communicating parties are UEs using V2V applications.

[0225] V2X service: A type of communication service involving a transmitting or receiving UE using a V2V application via 3GPP transport. Based on the other party involved in the communication, it can be further divided into V2V service, V2I service, V2P service, and V2N service.

[0226] Many ITS services have common communication requirements:

[0227] - Periodic status exchange. ITS services usually need to know the status of vehicles or roadside terminals. This means the periodic exchange of data packets with information about location, speed, identifiers, etc.

[0228] - Asynchronous Notifications. This type of message is used to notify about specific service events. In contrast to the previous status messages, reliable delivery of these messages to a single terminal or a group of terminals is usually a key requirement.

[0229] Examples of the use of the first communication type may exist in traffic efficiency services, such as remote vehicle monitoring, which collects periodic status data from vehicles or safety services (such as cooperative collision avoidance), which require motion information about surrounding vehicles to detect potential impacts. Asynchronous notifications mainly exist in safety services, such as slippery road or post-collision warnings.

[0230] Different types of messages are defined and will be defined for V2V communication. ETSI has defined two different types of messages for Intelligent Transport Systems (ITS), see the corresponding European standards ETSI EN 302 637-2v1.3.1 (NPL 10) and ETSI EN302 637-3v 1.2.1 (NPL 11):

[0231] -Cooperative Awareness Messages (CAM), which are continuously triggered by vehicle dynamics to reflect vehicle status.

[0232] - Decentralized Environmental Notification Message (DENM), which is triggered only when a vehicle-related safety event occurs.

[0233] Since V2V and ITS standardization is in its infancy, it is expected that other messages may be defined in the future.

[0234] ITS-Stations (ITS-S) continuously (periodically) broadcast CAM to exchange status information with other ITS-Ss and therefore have a greater impact on traffic load than event-triggered (aperiodic) DENM messages. Essentially a CAM message is a heartbeat message broadcast periodically by each vehicle to its neighbors to provide information on presence, location, temperature and basic status. In contrast, DENM is an event-triggered message broadcast to warn road users of dangerous events. For this reason, the traffic characteristics of the CAM messages defined by ETSI for ITS are considered to be more representative of V2V traffic.

[0235] In the above, periodic cooperative awareness messages have been described. However, it should be noted that while some of the above information has been standardized, other information such as periodicity and message size has not yet been standardized and is based on assumptions. In addition, standardization may change in the future, and therefore may also change various aspects of how to generate and transmit CAMs. Therefore, the above detailed description of the CAM should be understood as an example conceived for illustrative purposes.

[0236] In order to enable the vehicle-mounted UE to have radio resources for sending CAM on the side link, mode 1 and / or mode 2 radio resource allocation can be envisaged, as explained above. For mode 1 radio resource allocation, the eNB allocates resources for SA messages and data for each SA period. However, when there is a large amount of traffic (e.g., high-frequency periodic traffic), the overhead on the Uu link from the UE to the eNB will be large.

[0237] It is apparent from the above that much V2V traffic is periodic, so that 3GPP has agreed that for sidelink V2V communication Mode 1 (ie, eNB-scheduled radio resource allocation), the eNB and UE will support sidelink semi-persistent radio resource allocation.

[0238] For UE autonomous resource allocation mode (mode 2), it is obvious that the collision problem (i.e., when more than one Tx UE selects the same RB to deliver a message) will affect the QoS experienced by the user. For Rel-12 / 13, the data (PSSCH) collision problem of UE autonomous resource allocation mode is not discussed because the QoS of PC5 / sidelink is not a major requirement. However, for V2X services, it is inevitable to improve the QoS for UE autonomous resource allocation mode. 3GPP generally agrees to improve the QoS of UE autonomous resource selection through sensing and "semi-persistent" transmission (also known as radio resource reservation).

[0239] In more detail, it is agreed to support sensing mechanisms and semi-persistent transmissions as autonomous resource control / selection mechanisms for the V2X sidelink. The UE will indicate within the PSSCH (SA / SCI) that it has data on a selected set of periodically occurring resources until resource selection occurs. This resource reservation information (signaled within the SCI) can be used by other UEs that intend to send V2X messages for resource selection, so that resources already reserved / booked by other UEs are not considered for radio resource selection. This resource reservation / booking process only applies to traffic arriving with packets (e.g. CAM messages) with a certain periodicity.

[0240] As mentioned above, the indication of reserved radio resources in the scheduling information can be monitored ("sensed") by other (on-board) devices. In general, sensing is used when identifying a set of candidate resources for transmission. To this end, the sensing process divides the frequency resources into different groups:

[0241] - "Unavailable" resources. These are resources on which the UE is not allowed to transmit because these resources have been booked / reserved by other UEs.

[0242] - "Candidate resources". These are resources on which the UE may / can perform transmissions, and may be further categorized into "primary resources" and "secondary resources".

[0243] Sensing should be implemented in a simple way so as not to increase the complexity of the UE too much. It should also be noted that there may be multiple ways / options on how to implement the sensing algorithm. One possible implementation option is that each UE has a mapping with a prediction of frequency resources spanning at most, for example, 1 second, starting from the next subframe. That is, at time P when a packet arrives at a buffer in the UE, the UE has a mapping of all frequency resources for subframe P to L, which basically represents the maximum time span (according to QoS) until the packet should be sent, regardless of whether each resource is "unavailable" or a candidate.

[0244] "Unavailable" resources are determined based on SCI decoding (resource booking / reservation). It should be noted that the details of the selection of actual resources (from a resource candidate set) for transmission have not yet been finalized in 3GPP and still need to be discussed. An exemplary method is to randomly perform the selection of actual resources for transmission in the candidate resource set, thereby assigning equal probabilities to all selections. Randomness may be appropriate to ensure that UEs with similar resource mappings select different resources. As long as the candidate resource set is large enough, the use of random selection can ensure that the probability of UEs with relevant observations selecting the same resource is low. As a basis, the UE considers the nearest resources classified as candidate resources for (re)transmission of the transport block. Further restrictions can be applied to ensure that the candidate resources meet other relevant requirements (such as waiting time, bandwidth, etc.). All these resources constitute a candidate resource set for transmission. Another method is to also use additional energy-based sensing results in order to select actual transmission resources among the candidate resources (as opposed to random selection). It should be noted that, through mapping with RB-level information, the UE has complete flexibility and does not need to know the size of the transport block to schedule when sensing.

[0245] In order to better support and guarantee different QoS requirements for V2X services, current discussions in 3GPP provide solutions using additional QoS parameters. There is a distinction between the PC5 interface and the Uu interface.

[0246] For example, one solution proposed so far for the PC5 interface is that the MME provides the eNB with the UE-PC5-AMBR (aggregate maximum bit rate) as part of the UE context information. Thus, the eNB can use the UE-PC5-AMBR to limit UE PC5 transmissions by allocating resources appropriately. As explained, when requesting resources (mode 1 - eNB is scheduled), priority information from the application layer (e.g., PPPP) is sent by the UE to the eNB. The eNB will then infer the packet delay budget and reliability from the priority information provided by the UE and use it for priority handling. The mapping between priority information and packet delay budget / reliability can be based on, for example, provision of the O&M configuration or defined in the specification.

[0247] Currently no appropriate solution is discussed for Mode 2 UE autonomous resource allocation, so that only the QoS requirements for Mode 1 can be ensured. However, identical treatment of the QoS requirements for Mode 1 and Mode 2 seems to be preferred. Especially, considering that the V2X application is not (at present) informed about the mode adopted by the lower layers to send V2X data.

[0248] Moreover, one solution currently being investigated in 3GPP for the Uu interface is to introduce 1 GBR QCI and 1 non-GBR QCI for V2X services.

[0249] [Table 2]

[0250]

[0251] It is clear that the 3GPP community is currently investigating different solutions on how to best achieve QoS for the transmission of V2X data.

[0252] Therefore, the present disclosure will provide solutions that facilitate overcoming one or more of the above-mentioned problems.

[0253] DETAILED DESCRIPTION OF THE DISCLOSURE

[0254] A mobile station or mobile node or user terminal or user device is a physical entity within a communication network. A node may have several functional entities. A functional entity refers to a software or hardware module that implements and / or provides a predetermined set of functions to other functional entities of a node or network. A node may have one or more interfaces that attach the node to a communication facility or medium through which the node can communicate. Similarly, a network entity may have logical interfaces that attach the functional entity to a communication facility or medium through which it can communicate with other functional entities or corresponding nodes.

[0255] The terms "radio resources" and "frequency-time radio resources" used in the claims and application should be broadly understood to refer to physical radio resources, such as time-frequency resources.

[0256] The term "direct communication transmission" used in this application should be broadly understood as transmission directly between two user devices, that is, not via a radio base station (e.g., eNB). Correspondingly, the direct communication transmission is performed on a "direct side link connection", which is a term used for a connection established directly between two user devices. For example, in 3GPP, the term D2D (device to device) communication or ProSe communication or side link communication is used. The terms "direct side link connection", "side link interface" will be understood broadly and can be understood in the 3GPP context as the PC5 interface described in the background technology section.

[0257] The term "ProSe" or its unabbreviated form "Proximity Services" used in this application is applied in the context of proximity-based applications and services in LTE systems, as exemplified in the background section. Other terms such as "D2D" are also used in this context to refer to device-to-device communication for proximity services.

[0258] As used throughout the application, the term "vehicle-mounted mobile terminal" may be understood exemplarily in the context of the new 3GPP study item or work item V2X (vehicle-to-everything communication) described in the background technology section. Correspondingly, a vehicle-mounted mobile terminal should be broadly understood as a mobile terminal that is specifically installed in a vehicle (e.g., a car, a commercial truck, a motorcycle, etc.) to perform vehicle communication, i.e., to transmit vehicle-related information to other entities (such as vehicles, infrastructure, pedestrians), for example for safety or driver assistance purposes. Optionally, the vehicle-mounted mobile terminal can access information available at a navigation system (assuming it is also installed in the car), such as map information, etc.

[0259] As used throughout the application, the terms "autonomous radio resource allocation" and "radio base station controlled radio resource allocation" may be exemplarily understood in the context of 3GPP proximity services, allowing two modes for resource allocation; namely, mode 1 (i.e., radio base station controlled radio resource allocation) in which the radio base station allocates resources according to its control, and mode 2 (i.e., autonomous radio resource allocation) in which the terminal (or transmitting device) autonomously selects resources (without the radio base station).

[0260] As used throughout the application, the terms "application layer" and "transport layer" may be understood exemplarily as abstract entities within the UE / transmitting device that are responsible for the corresponding processes, i.e., the generation of application data (such as vehicle data) and the transmission of data (e.g., also including radio resource allocation), respectively. The "application layer" and the "transport layer" may or may not correspond to layers in the OSI (Open Systems Interconnection) layer model. The layers themselves may be exemplarily implemented in software and / or hardware to perform their functionality. In one example, the "application layer" may be part of layer 3 or the ProSe layer of the UE / transmitting device. On the other hand, the "transport layer" may exemplarily be layers 1 and 2 of the UE / transmitting device (i.e., the physical layer and the PDCP, RLC, MAC layers, respectively).

[0261] As explained in the background section, 3GPP has introduced a new study item for LTE-assisted vehicular communications, which will exchange V2X traffic between various vehicle-mounted mobile terminals and other stations based on ProSe procedures. In addition, there have been discussions and proposals to support quality of service requirements, especially for vehicle communications via the sidelink interface. So far, the discussions have focused on providing appropriate quality of service parameters for the eNB. However, in that case, there is at least one question, namely, how to support quality of service for vehicle communications when resource allocation mode 2 is used for transmitting vehicle data, in which the UE performs radio resource allocation autonomously (i.e., without help from the eNB).

[0262] The inventors conceived the following exemplary embodiments to alleviate the problems described above.

[0263] The specific implementation of various embodiments will be implemented in the broad specifications given by the 3GPP standards and partly described in the background technology section, with specific key features added as described in the following embodiments. It should be noted that the embodiments can be advantageously used in, for example, mobile communication systems, such as the 3GPP LTE-A (Release 10 / 11 / 12 / 13 / 14 or higher) communication systems described above in the technical background section. However, the embodiments are not limited to their use in these specific exemplary communication networks.

[0264] The scenarios and assumptions made for illustration should not be understood as limiting the scope of the present disclosure, but are merely examples for better understanding of the present disclosure. It should be appreciated by those skilled in the art that the general principles of the present disclosure as set forth in the claims can be applied to different scenarios and in ways not explicitly described herein.

[0265] The various embodiments primarily provide for improved transmission of vehicle data from a transmitting device to one or more receiving devices via a sidelink interface, which also involves the allocation of radio resources. Other functions (i.e., functions that are not changed by the various embodiments) may remain exactly the same as described in the background section, or may be changed without any consequences for the various embodiments. This may include, for example, other processes, such as how the transmission of periodic data is accurately performed by the transmitting device using the transmission parameters obtained through resource allocation, or how the various ProSe devices discover each other.

[0266] One exemplary scenario in which various embodiments can be applied is V2X communication, as illustrated in the background section. Thus, the transmitting and receiving devices can be, for example, UEs in vehicles, roadside units, "ordinary" mobile terminals carried by pedestrians, etc.

[0267] Various different embodiments are presented and described in conjunction with exemplary and illustrative V2X scenarios, which will become apparent from the following. It is assumed that a vehicle-mounted UE (generally, a transmitting device) is installed in a vehicle and is capable of performing vehicle communications based on a D2D framework (i.e., via a side link PC5 interface), as described in the background technology section of this application. Correspondingly, vehicle data should be sent by the vehicle-mounted UE to other entities (generally, receiving devices) that are interested in the data.

[0268] In addition, it is assumed that the vehicle-mounted UE supports two resource allocation modes, namely, eNodeB-controlled resource allocation mode 1 and UE autonomous resource allocation mode 2, whose exemplary implementation is described in the background technology section. Some embodiments focus on improving UE autonomous resource allocation mode 2 to properly support and meet quality of service requirements. Either of the two resource allocations is performed by the vehicle-mounted UE to obtain the necessary transmission parameters, and then the actual transmission of vehicle data is performed based on those transmission parameters.

[0269] For the purpose of illustration, the in-vehicle UE is considered to have a protocol stack including various layers, such as Layer 1 (physical), Layer 2 (PDCP, RLC, MAC), Layer 3 (non-access layer such as IP protocol, ProSe function). Each layer performs different functions. For the purpose of illustration, the protocol stack is simplified to include only one or more application layers and a transport layer, where the application layer is basically responsible for generating application data (such as vehicle data of vehicle applications), and the transport layer is responsible for transmitting data through the (side link) interface (for example, vehicle data or other non-vehicle data generated by the corresponding application layer is passed to the transport layer).

[0270] First embodiment

[0271] Hereinafter, a first embodiment for solving the above-mentioned problems will be described in detail. Different implementations and variations of the first embodiment will also be explained.

[0272] As explained in the background section, the so-called ProSe per-packet priority (PPPP) was introduced in Release 13 to support priority handling and quality of service handling for ProSe one-to-many communications. PPPP allows the ProSe upper layer (i.e., the application layer responsible for generating data) to prioritize data packets (together with PPPP) passed down to the lower layer (i.e., the transport layer) for transmission. Thus, the transport layer can use PPPP to prioritize received data, for example, relative to other intra-UE data (i.e., data from other applications within the same onboard UE).

[0273] In short, according to the first embodiment, in addition to PPPP, the application layer can also forward parameters related to the quality of service requirements of the vehicle data to the transport layer. The radio resource allocation process according to mode 2 performed in the transport layer takes into account the received parameters (i.e., PPPP and QoS parameters) to obtain the transmission parameters to be used for transmitting the vehicle data to the receiving entity. Thereby, it is possible to achieve QoS support for sending vehicle data also for the UE autonomous resource allocation mode.

[0274] In an exemplary implementation of the first embodiment, one or more of the QCI characteristics that have been standardized for 3GPP LTE may be reused as QoS parameters. Specifically, 3GPP has standardized different parameters (such as resource type (GBR or non-GBR), priority, packet delay budget, and packet error loss rate) to support QoS (see section 6.1.7.2 "Standardized QCI characteristics" of TS 23.203 v14.0.0, which is incorporated herein by reference). It can be seen that the priority level standardized in section 6.1.7.2 corresponds to PPPP (as mentioned above when introduced for ProSe communications) and can therefore be considered as a parameter separate from other QoS parameters. Alternatively, PPPP can be considered as another QoS parameter.

[0275] In short, the resource type basically indicates whether a specific bit rate is guaranteed when sending data. The packet delay budget defines an upper limit on the time it takes for a packet to be sent from the sending entity (onboard UE) to the receiving entity. The packet error loss rate (PELR) defines an upper limit on the rate of packets that are not successfully delivered to the receiving entity. The packet error loss rate can be set to support high reliability without application layer message retransmission while considering a low packet delay budget that may result in a higher PELR.

[0276] According to a first embodiment, the application layer responsible for vehicle communication generates V2X data. As mentioned earlier, the application layer sets its PPPP when passing the V2X message to the lower layer for transmission. The mapping of the application layer V2X message priority to PPPP is based on, for example, a pre-configuration in the UE. The configuration of such mapping on the UE is beyond the scope of 3GPP and is independent of the embodiments discussed herein. Since the application layer generally knows the type of V2X data to be sent, similar to the corresponding PPPP, the application layer can also provide one or more of the QoS parameters corresponding to the generated V2X data mentioned above to the lower layer. Similarly, the mapping between the application layer V2X data and the QoS parameters is based on, for example, a pre-configuration in the UE. The V2X data, PPPP, and one or more QoS parameters are passed down the protocol stack to the transport layer responsible for performing radio resource allocation and V2X data transmission.

[0277] According to one example, QoS parameters (and PPPP) are forwarded to the transport layer with each packet. Thus, by selectively distinguishing QoS requirements for exactly the same PPPP, it is possible to properly support QoS for any data packet transmission. Alternatively, when PPPP is forwarded with each packet, the QoS parameters may be provided to the transport layer only at the beginning (i.e., when a new service is started and the corresponding sidelink logical channel in the lower layer is established) (e.g., once). The transport layer of the onboard UE can then associate subsequent data packets forwarded with the same PPPP with the previously received QoS parameters based on the received PPPP; a sidelink logical channel configured for a specific PPPP is associated with the QoS parameters received when that sidelink logical channel was established. This has the advantage of reducing inter-layer communication because QoS parameters do not need to be sent with each data packet.

[0278] As mentioned above, the onboard UE performs resource allocation according to Mode 2 (i.e., UE autonomous) to obtain the necessary transmission parameters, whereby PPP and QoS parameters will be further taken into account, for example, in a corresponding manner to that performed by the eNB for Mode 1 resource allocation. In more detail, performing Mode 2 resource allocation typically involves selecting a suitable modulation scheme and coding rate and selecting sufficient frequency-time radio resources to send the encoded data. In addition, D2D data transmission will likely involve blind repetition of transport blocks (e.g., without HARQ feedback) in order to increase transmission reliability. Assuming that the total number of transmissions is flexible and not pre-configured, the radio resource allocation may also involve determining the number of transmissions of data packets that should be performed in total by the onboard UE.

[0279] Resource allocation should be performed based on the parameters received from the upper layer for the V2X data to be transmitted. For example, the modulation scheme and / or the coding rate may be selected so that the packet error loss rate may be met. Similarly, by increasing the total number of transmissions of one transport block, the onboard UE may reduce the packet error loss rate. Therefore, the number of transmissions may be selected based on the packet error loss rate.

[0280] On the other hand, the packet delay budget can be used during radio resource allocation, for example, when the on-board UE determines available frequency-time radio resources based on previously obtained sensing results. Since it is agreed to support the sensing of semi-persistent transmission of the autonomous resource control / selection mechanism for PC5 transmission of vehicle data, the sending device selects unused / idle radio resources for the transmission (including retransmission) of data packets based on the sensing results performed on the sensing window, where the transmission resources should be within the delayed packet budget. For example, in the case where the packet delay budget is 20ms, the on-board UE should ensure that all transmissions of data packets occur within 20ms when the packets arrive at the UE's buffer unit. Moreover, the packet delay budget can be used in the on-board UE to determine expired data packets (i.e., data packets that exceed the packet delay budget), in which case such data packets can be discarded.

[0281] When allocating the determined frequency-time radio resources to generate a transport block carrying V2X data, the priority level (or PPPP) received from the application layer may be used, for example, in the sidelink logical channel prioritization process. In one exemplary implementation, the frequency-time radio resources are allocated to transmit data in descending order of the PPPP of the V2X data (more specifically, the logical channel established according to the PPPP of the V2X data). The transport block thus created is then transmitted by the vehicle-mounted UE to other receiving devices.

[0282] Fig. 9 is a diagram illustrating an exemplary implementation of the first embodiment, which shows the functions performed by the application and transport layers. It is apparent from this that the application layer generates V2X data, then determines the corresponding priority and QoS parameters of the V2X data and provides it to the underlying transport layer responsible for transmission. The transport layer then performs UE autonomous resource allocation based on the received parameters and priority, and continues to send the V2X data to other devices via the PC5 interface.

[0283] Moreover, according to another implementation of the first embodiment, information about UE-PC5-AMBR (aggregate maximum bit rate for the side link interface) can be provided to the on-board UE. UE-PC5-AMBR can be understood as the maximum total data throughput allowed for the UE to transmit over the side link interface. In other words, when sending data via the side link interface, the UE is limited to a specific average bit rate (data per unit time). According to this general definition, the AMBR is UE-specific and interface-specific, but applies to all side link logical channels (i.e., side link logical channels carrying vehicle or non-vehicle data).

[0284] In one variant, the UE-PC5-AMBR may be provided to the onboard UE in a corresponding dedicated message from the eNB, for example, during the attach procedure. During the attach procedure, the MME obtains the UE-PC5-AMBR based on the UE subscription from the HSS (Home Subscriber Server) and the network operator's policy. This UE-PC5-AMBR is then sent from the MME to the eNB during the initial context establishment procedure for the UE. The eNB may then also inform the UE of the UE-PC5-AMBR value. Alternatively, the UE may be provided with a UE-PC5-AMBR value from a higher layer (application) based on some pre-configuration.

[0285] UE-PC5-AMBR can be used as a parameter in the sidelink logical channel prioritization process to limit the amount of data to be sent via the sidelink interface. In an exemplary implementation, a token bucket algorithm can be used in the sidelink LCP process to implement this limitation (e.g., similar to the ordinary legacy LCP process described in the background technology section). Specifically, a token bucket can be defined for the sidelink logical channel so that as long as the bucket is not empty (i.e., >0), radio resources can only be allocated to the sidelink logical channel. However, it is also foreseeable that other implementations that do not use the token bucket algorithm apply the limitations given by the UE-PC5-V2X-AMBR parameter.

[0286] A specific exemplary implementation of this adjusted sidelink LCP procedure is given below. As done in the current sidelink logical channel prioritization procedure, the UE shall allocate resources to the sidelink logical channels in a strict priority order. For simplicity reasons, the selection of the destination (ProSe destination) is not considered here. The corresponding lower layer (i.e., MAC) shall allocate resources to the (relevant) sidelink logical channels in the following steps:

[0287] 1. All sidelink logical channels with data available for transmission are served in descending order of priority until the data or SL grants for the sidelink logical channels are exhausted or the bucket is empty (whichever comes first).

[0288] 2. The MAC entity shall reduce the bucket level by the total size of the MAC SDU served in the above steps.

[0289] According to another exemplary embodiment, the lower layer (transport layer) indicates to the application layer the resource allocation mode that the vehicle-mounted UE is configured with / is using. This information is used in the application to decide whether the transport layer needs to be provided with QoS parameters for data packets. More specifically, only for the case where the vehicle-mounted UE operates in the UE autonomous resource allocation mode (mode 2), the application layer needs to provide QoS information / parameters to the lower layer.

[0290] Second embodiment

[0291] In the following, a second embodiment is given, which deals with the same problem as the problem solved by the first embodiment, namely, the problem described at the beginning of the specific implementation method, namely, how to achieve quality of service support for vehicle communications via a side link interface, specifically, the on-board UE is performing UE autonomous radio resource allocation.

[0292] In short, according to the second embodiment, at least one quality of service configuration is defined, which indicates one or more quality of service parameters. Then, the sending device having the QoS configuration selects a suitable QoS configuration according to the vehicle data to be sent via the side link interface. In a similar manner to the first embodiment, the radio resource allocation performed by the onboard UE according to mode 2 takes into account the QoS parameters of one QoS configuration when obtaining transmission parameters. The vehicle data is sent according to the performed radio resource allocation and the corresponding obtained transmission parameters. Therefore, when performing mode 2 resource allocation, it is also possible to support different QoS requirements for sending V2X data via the PC5 interface.

[0293] As already explained in conjunction with the first embodiment, one or more of the standardized 3GPP LTE QoS parameters (i.e., packet delay budget, packet error loss rate, resource type) may be reused to achieve quality of service. With regard to these QoS parameters made in conjunction with the first embodiment, reference is made to the more detailed description.

[0294] Various different QoS configurations (also referred to as QoS classes) can be defined to differentiate the quality of service requirements suitable for vehicle data. As explained in the background section, proposals have been made on how to define the QoS requirements for V2X data transmission over the Uu interface. Specifically, the following two different QoS configurations (determined by QCI 75 and 79, respectively) are proposed:

[0295] [Table 3]

[0296]

[0297] According to the second embodiment, these QoS configurations of the table can serve as a guide for how to apply QoS to V2X data transmission on the PC5 side link interface. Specifically, one possible QoS configuration then defines the resource type as GBR, the packet delay budget as 50ms, and the packet error loss rate as 10 -2 , while the other QoS configuration then defines the resource type as non-GBR, the packet delay budget as 50ms, and the packet error loss rate as 10 -2 It should be noted that the above are merely examples and that different constellations and values ​​of the parameters may be chosen appropriately.

[0298] As is evident from the table above, the QoS requirements on the Uu interface foresee different priority levels. Regarding QoS support on the peer link interface, the priority parameters of the listed QoS configurations may not be needed, given that ProSe Per-Packet Priority (PPPP) has been standardized to indicate the priority of D2D (vehicle) data. In other words, PPPP can be used separately from the QoS configuration.

[0299] On the other hand, it may also make sense to standardize the priorities for different QoS configurations, so as to have a consistent QoS definition for vehicle data, regardless of the specific application layer that generates the vehicle data. In this case, PPPP will not be used (and therefore will not be forwarded to the lower layers), or PPPP (if generated by the application) may be overwritten by the priority given by the selected QoS configuration (still alternatively, if forwarded, PPPP may override the priority).

[0300] Alternatively, another possible QoS parameter for vehicle data transmission via the sidelink interface would be the number of repetitions, ie the total number of transmissions of a transport block, as explained in more detail in the first embodiment.

[0301] In any case, different QoS configurations can therefore be defined, respectively distinguishing one or more of the QoS parameters (such as packet delay budget, packet loss rate and resource type). In fact, different vehicle data can therefore be processed differently with respect to their QoS requirements.

[0302] There are several possibilities on how to provide the QoS configuration to the onboard UE. According to an exemplary implementation of the second embodiment, the eNB broadcasts information about the different QoS configurations in its radio cell so that all (onboard) UEs receive the information. For example, the eNB may broadcast a V2X-specific system information block including the QoS configuration (and possibly other V2X-related information). Alternatively, the onboard UE may be provided by dedicated signaling with the QoS configuration, for example when configuring the resource allocation mode or the onboard UE may be pre-configured with the QoS configuration.

[0303] In any case, it is assumed that the onboard UE is therefore provided with different QoS configurations and can therefore selectively use an appropriate QoS configuration to meet certain QoS requirements for transmitting vehicle data via the sidelink interface. The QoS configuration should be selected so as to be appropriate for the vehicle data to be transmitted. The mapping between application layer V2X data and the appropriate QoS configuration is, for example, based on a pre-configuration in the UE. Alternatively, the V2X to QoS class mapping may be provided to the onboard UE using a system information block broadcasted by the eNodeB (e.g. the V2X-specific system information block mentioned above) or dedicated signaling as outlined above.

[0304] The application layer generating the vehicle data can correctly determine which QoS configuration is most suitable for the generated V2X data, and can provide the corresponding indication together with the generated data to the lower layer (transport layer) responsible for transmitting the V2X data via the side link interface. In turn, the transport layer can determine the QoS configuration and therefore the corresponding QoS parameters, and then use these QoS configurations and QoS parameters during the radio resource allocation process to obtain the necessary parameters for transmitting the V2X data. The above indication generated by the application layer for identifying the QoS configuration selected for the generated V2X data can be similar to the QCI, i.e., the QoS class indicator known in the 3GPP standard. As presented in the table above, QCI values ​​75 and 79 were exemplarily suggested during the 3GPP discussion to identify two QoS classes defined for vehicle messages sent via the Uu interface. In a similar manner, the QCI value can be used to distinguish different QoS configurations to be used by the vehicle UE. When notified about the QoS configuration indicator value, the transport layer can determine the corresponding QoS configuration intended to be met for transmitting the V2X data. According to an exemplary implementation of the first embodiment, the application layer forwards the QoS configuration indicator to the lower layer together with the data packet. Based on this information, the lower layer (transport layer) knows which QoS configuration to apply for the transmission of this data packet. Optionally, the application layer can also forward the PPPP for V2X data to the transport layer; specifically, for the case where the QoS configuration does not specify a priority level. On the other hand, if the QoS configuration also specifies a specific priority for V2X data, then in theory no separate PPPP indication is needed (or the PPPP will be overwritten by the priority given by the QoS configuration, or vice versa).

[0305] Fig.10is a diagram illustrating an exemplary implementation of the second embodiment, in which the QCI is used as an indicator between the application and the transport layer to identify the corresponding QoS configuration. It is apparent from this that when generating V2X data, the application layer determines the corresponding priority (e.g., PPPP) of the V2X data and the QoS configuration that should be enforced in the lower layer for the V2X data. The corresponding QoS class indication (i.e., QCI) is provided together with the V2X data and optionally together with the priority of the transport layer. In turn, the transport layer determines the QoS configuration and therefore the corresponding QoS parameters based on the received QCI. UE autonomous resource allocation can be performed by the transport layer based on the received priority and the QoS parameters of the determined QoS configuration, so that the actual transmission of the V2X data is then performed therein.

[0306] Alternatively ( Fig.10 In the embodiment of the present invention, instead of using a QoS configuration indicator as an indicator for identifying a QoS configuration of a data packet (or a sidelink logical channel, respectively), PPPP may be used in the described aspect. As explained above, PPPP indicates the priority of vehicle data generated in the application layer; the mapping of the application layer V2X message priority to PPPP is based on, for example, a pre-configuration in the UE. The transport layer then receives the vehicle data and PPPP from the application layer, and on this basis determines which QoS configuration to apply to the transmission of the V2X data. A suitable mapping between different PPPP values ​​and QoS configurations may be based, for example, on a pre-configuration in the UE. Another option is to receive a PPPP to QoS configuration mapping in a corresponding system information block broadcast by the eNodeB, or via dedicated signaling from the eNB. Alternatively, a PPPP to QoS class mapping may be provided from the application layer to the transport layer.

[0307] In one example, an indication (which may be a QoS configuration indicator or PPPP) may be forwarded from the application layer to the transport layer with each packet.

[0308] The above description makes it possible to determine the QoS based on the vehicle data to be sent. However, it can also be seen that the implementation of the second embodiment lies in applying the QoS configuration to the corresponding sidelink logical channel. Specifically, the vehicle data is processed by different sidelink logical channels, for example, differentiated by their priorities, so that vehicle data with the same priority (and with the same source and destination ID) are processed by the same sidelink logical channel. QoS can be regarded as a concept that is generally applied at a level specific to a bearer / logical channel. Therefore, it can also be said that the transport layer identifies the sidelink logical channel to which the QoS (configuration) is to be applied.

[0309] In case data of different sidelink logical channels are multiplexed in one TB, for example, during the sidelink logical channel procedure, the QoS parameters (e.g., packet delay budget or reliability) used for radio resource selection and subsequent transmission of transport blocks on the PC5 interface should be selected based on the logical channel with the highest priority. Alternatively, the QoS parameters used for radio resource selection and subsequent transmission of transport blocks should be based on the QoS parameters with the most stringent requirements, i.e., using the smallest packet delay budget of the logical channels involved.

[0310] In any case, the transport layer obtains the relevant QoS parameters that should be met for the transmission of V2X data. Therefore, the transport layer (for example, specifically the MAC and physical layer) can perform mode 2 radio resource allocation and actual transmission of V2X data taking into account the QoS parameters. Details on how to take into account different QoS parameters have been provided in conjunction with the first embodiment. In short, the modulation scheme and / or the coding rate can be selected so that the packet error loss rate is met. The packet error loss rate is an important parameter for determining the total number of transmissions of a transport block. The packet delay budget can be used during radio resource allocation to determine the available resources based on previously obtained sensing results, taking into account that the transmission of data packets will occur within the packet delay budget. In addition, the discarding of expired data packets can also depend on the packet delay budget. The priority level of the QoS configuration (or alternatively PPPP) is used, for example, in the sidelink logical channel prioritization process to prioritize the sidelink logical channel when allocating radio resources.

[0311] According to a further implementation of the second embodiment, information about UE-PC5-AMBR (aggregate maximum bit rate for the side link interface) can be provided to the on-board UE. As already described in conjunction with the first embodiment, UE-PC5-AMBR can be understood as the maximum total data throughput allowed for the UE to transmit over the side link interface. There are several possibilities on how to provide UE-PC5-AMBR for the on-board UE, for example, within the system information broadcast carrying the QoS configuration. Alternatively, the UE-PC5-AMBR can be provided to the on-board UE in a corresponding dedicated message from the eNB, for example, during the attachment process; refer to the corresponding paragraphs for the first embodiment for details. UE-PC5-AMBR can be used as a parameter in the sidelink logical channel prioritization process to limit the amount of data to be sent over the side link interface. As already described for the first embodiment, this parameter can be used as a parameter in a token bucket algorithm. A specific exemplary implementation of this token bucket algorithm for the sidelink LCP process is given in conjunction with the first embodiment, and can also be used in the context of the second embodiment.

[0312] Therefore, while QoS processing in resource allocation mode 1 is left to the eNB responsible for said aspect, the second embodiment provides a solution where it is also possible to support QoS processing for UE autonomous resource allocation mode 2 performed by the onboard UE when sending vehicle data via the PC5 interface.

[0313] Third embodiment

[0314] In the following, a third embodiment is given, which deals with the same problem as the problem solved by the first and second embodiments, i.e., the problem explained at the beginning of the specific implementation, i.e., how to implement quality of service support for vehicle communication via a side link interface, specifically, the vehicle-mounted UE is performing UE autonomous radio resource allocation. For the third embodiment, it is exemplarily assumed that QoS support is mainly provided by mode 1 resource allocation, and UE autonomous resource allocation according to mode 2 does not necessarily support the satisfaction of QoS requirements. In particular, an exemplary assumption is that QoS support is mainly applied to mode 1 resource allocation, where the eNodeB determines QoS parameters for vehicle data, for example, from PPPP sent by the vehicle-mounted UE when requesting radio resources and scheduling requests and / or buffer status reports. The corresponding mapping between the received PPPP and the QoS parameters (e.g., of the corresponding QoS configuration) can be pre-configured in the eNodeB, for example. However, according to this exemplary assumption, the necessary information about the QoS parameters is not provided to the vehicle-mounted UE, so that the vehicle-mounted UE cannot consider the QoS requirements of the data when performing UE autonomous resource allocation (mode 2).

[0315] According to the third embodiment, the on-board UE supports two resource allocation modes and is also configured to perform radio resource allocation depending on the vehicle data to be sent. In more detail, as explained in the background technology section, in the prior art, the on-board UE determines which radio resource allocation to apply based on the configuration from the eNodeB (for example, based on the existence of the corresponding UE autonomous mode 2 resource pool). Alternatively, the resource allocation mode to be used by the UE may also depend on the RRC state (i.e., whether the on-board UE is RRC connected) or on the coverage state of the UE (i.e., within coverage, outside coverage). On the other hand, the third embodiment provides a solution by distinguishing different data and selectively applying mode 1 resource allocation or mode 2 resource allocation.

[0316] In short, the vehicle UE (e.g., application layer) generates the vehicle data to be sent and passes it to the transport layer responsible for the actual transmission. Depending on the vehicle data (e.g., whether QoS should be supported for that data), the appropriate radio resource allocation mode is selected, and then the selected resource allocation process is performed to obtain appropriate transmission parameters. For example, if QoS should be supported for specific vehicle data, the vehicle UE will select mode 1 resource allocation and will request radio resources from the eNodeB accordingly, and the eNodeB will determine the transmission parameters taking into account the QoS requirements of the specific vehicle data. On the other hand, if QoS should not be supported for specific vehicle data, the vehicle UE will select mode 2 resource allocation and will autonomously and automatically determine the transmission parameters. In either case, using the obtained transmission parameters, the transport layer then performs the transmission of the data. Therefore, by performing either mode 1 radio resource allocation (to be able to meet specific QoS requirements) or mode 2 radio resource allocation (if specific QoS should not be supported), it is possible to selectively apply QoS support to specific vehicle data transmission.

[0317] Fig.11 is a diagram exemplarily illustrating the implementation of the third embodiment. It is apparent from this that the transport layer is responsible for determining whether to use mode 1 or mode 2 resource allocation based on the V2X data, for example based on a suitable mapping. Therefore, the transport layer will then perform the corresponding mode 1 or mode 2 resource allocation determined previously, and then continue to send the V2X data according to the transmission parameters obtained through the resource allocation.

[0318] In an exemplary implementation of the third embodiment, the selection of the appropriate radio resource allocation mode to be used can be based on an indication from the application layer. In other words, the application layer that generates the vehicle data will indicate whether QoS should be applied to specific vehicle data. Correspondingly, the appropriate QoS support indication is forwarded to the responsible transport layer together with the vehicle data, and the responsible transport layer then follows the received indication to perform the corresponding radio resource allocation (according to mode 1 or mode 2) to obtain the necessary transmission parameters. In an exemplary implementation, a flag can be used as a QoS support indication, which is forwarded to the lower layer together with the vehicle data.

[0319] In another exemplary implementation, PPPP may be used as a QoS support indication by associating a specific PPPP value with a Mode 1 or Mode 2 radio resource allocation mode. Similarly, given that a sidelink logical channel is established with PPPP (for the same source destination ID) in mind such that there is one sidelink logical channel per PPPP, certain sidelink logical channels may be configured to use Mode 1 resource allocation to ensure QoS compliance, while other sidelink logical channels may be configured to use Mode 2 resource allocation, where specific QoS requirements are not guaranteed to be met. In other words, the onboard UE determines the radio resource allocation mode to apply based on the sidelink logical channels that have data available for transmission.

[0320] There are several possibilities as to how to configure which logical channel (PPP or specific concrete data, respectively) will use which resource allocation mode. The appropriate mapping can be either defined by the upper layers (the application layer generating the vehicle data) or configured by the eNodeB. For example, the eNodeB can broadcast the appropriate mapping in its radio cell so that it is obtained by all on-board UEs in the cell, or the eNodeB can send dedicated messages to the on-board UEs individually in said aspect. As an example, certain higher priority vehicle services (such as safety-related transmissions or transmissions related to voice calls) can be configured to be sent with QoS support (e.g. short packet delay budget or low packet error loss rate) and should therefore be sent using the Mode 1 radio resource allocation mode. In contrast, other vehicle services may not benefit from QoS support and therefore resource allocation according to Mode 2 is sufficient.

[0321] Therefore, depending on the radio resource allocation mode, the on-board UE may have to first connect to the eNodeB. Specifically, when sending vehicle data for a sidelink logical channel for which mode 1 radio resource allocation is to be performed, the on-board UE must be connected to the eNodeB (so that a scheduling request and / or a buffer status report can be sent), and therefore, if it is not yet connected to the eNodeB, an RRC connection with the eNodeB must first be established. The transmitting device can then perform mode 1 resource allocation in the usual manner by requesting transmission parameters from the radio base station, for example, including first sending a scheduling request, and in response to being provided with appropriate frequency-time radio resources, sending a sidelink buffer status report indicating the amount of vehicle data to be sent (only for sidelink logical channels associated with mode 1 resource allocation). As mentioned earlier, the eNodeB is responsible for handling the QoS requirements related to the vehicle data by selecting appropriate transmission parameters in the described aspects. The transmission parameters (e.g., frequency-time resources, modulation and coding scheme, and optionally the total number of transmissions to be performed for the transmission block) are then used by the transport layer to perform the transmission of the vehicle data.

[0322] Therefore, according to the third embodiment, mode 1 and mode 2 resource allocation are respectively performed depending on the data, and thus QoS is selectively supported depending on the data (or in other words, depending on the sidelink logical channel that processes the data). Therefore, even in the case where the mode 2 radio resource allocation itself is not suitable for supporting QoS, it is possible to achieve consistent QoS support for specific vehicle data (i.e., benefiting from QoS).

[0323] As a result, it is possible for the UE to perform two radio resource allocations simultaneously, ie when two or more separate transport blocks are sent in one subframe (eg when MIMO is used or when carrier aggregation is used).

[0324] Moreover, considering that the sidelink logical channels configured according to the third embodiment may be associated with different radio resource allocation modes, the sidelink logical channel prioritization process needs to be adjusted in the said aspect. Specifically, after being provided with the corresponding transmission parameters (including the frequency-time resources to be allocated), the transport layer generally performs a sidelink logical channel prioritization process so as to allocate the received frequency-time radio resources to the sidelink logical channels having data available for transmission. However, in this case, the sidelink LCP process should only consider those sidelink logical channels associated with the resource allocation mode and providing the frequency-time radio resources to be allocated by the sidelink LCP process. For example, assuming that the vehicle-mounted UE performs mode 1 radio resource allocation and correspondingly receives transmission parameters from the eNodeB, the subsequent sidelink LCP process should only consider those sidelink logical channels associated with mode 1 radio resource allocation, so that the available frequency-time radio resources are preferentially allocated to the mode 1 sidelink logical channels. On the contrary, assuming that the on-board UE performs Mode 2 radio resource allocation and determines the transmission parameters autonomously accordingly, the subsequent sidelink LCP process should only consider those sidelink logical channels associated with Mode 2 radio resource allocation, so that the available frequency-time radio resources are preferentially allocated to Mode 2 sidelink logical channels.

[0325] An exemplary implementation may foresee two separate MAC entities, one responsible for performing the sidelink LCP procedure for mode 1 sidelink logical channels and the other responsible for performing the sidelink LCP procedure for mode 2 sidelink logical channels. Alternatively, only one MAC entity may be provided in the vehicle UE, which is then alternately responsible for performing the sidelink LCP procedure for either mode 1 or mode 2 sidelink logical channels as required.

[0326] Fourth embodiment

[0327] In the following, a fourth embodiment is presented, which addresses similar problems as those solved by the previous embodiments. Specifically, improved QoS support for transmission of vehicle data via a sidelink interface shall be provided.

[0328] In a specific implementation of the first and second embodiments, an additional QoS parameter UE-PC5-AMBR (aggregate maximum bit rate for the sidelink interface) is considered for UE autonomous resource allocation, specifically in the sidelink logical channel prioritization process performed by the on-board UE to allocate radio resources to various sidelink logical channels with vehicle data available for transmission.

[0329] According to a fourth embodiment, another QoS parameter is foreseen, namely, the V2X-specific UE-PC5-AMBR, which defines the maximum throughput that the UE is allowed to transmit vehicle data via the side link interface. Correspondingly, when sending vehicle data via the side link interface, the UE is limited to a specific average maximum bit rate. Unlike the previously mentioned UE-PC5-AMBR, this new QoS parameter (e.g., which may be referred to as UE-PC5-V2X-AMBR) refers only to vehicle data, i.e., to the side link logical channel carrying vehicle data; it should not be applied to limit the transmission throughput of non-vehicle data via the side link interface. Therefore, the UE-PC5-V2X-AMBR is specific to the UE, to the side link interface, and to the V2X side link logical channel.

[0330] The UE-PC5-V2X-AMBR may be provided to the onboard UE in various ways. According to an exemplary implementation of the fourth embodiment, the eNodeB may send the parameter in a corresponding dedicated message, for example, during the attachment process (in a similar manner as described for the parameter UE-PC5-AMBR in the first and second embodiments). Specifically, during the attachment process, the MME obtains the UE-PC5-V2X-AMBR based on the UE subscription from the HSS and the network operator's policy. The MME may then forward this parameter to the eNodeB during the initial context establishment process for the UE, which may then be further forwarded to the UE in a broadcast or dedicated message. Alternatively, the UE-PC5-V2X-AMBR may be provided to the UE from a higher layer (application), for example based on some pre-configuration.

[0331] Instead of UE-PC5-AMBR, a new QoS parameter UE-PC5-V2X-AMBR can be used during the sidelink logical channel prioritization process in order to limit the amount of vehicle data that the UE can send via the sidelink interface at a time. In one exemplary implementation, a token bucket algorithm can be used in the aspect. A token bucket can be defined for the sidelink logical channel carrying vehicle data so that radio resources can only be allocated to the V2X sidelink logical channel as long as the bucket is not empty (i.e., >0). However, other implementations that do not use the token bucket algorithm to apply the restrictions given by the UE-PC5-V2X-AMBR parameter are also foreseen. A specific exemplary implementation of such an adjusted sidelink LCP process is given below. The corresponding lower layer (i.e., MAC) should allocate resources to the (relevant on-board) sidelink logical channel in the following steps:

[0332] 1. All sidelink logical channels with data available for transmission are served in decreasing order of priority until the data or SL grants for the sidelink logical channels are exhausted or the bucket is empty (whichever comes first).

[0333] 2. The MAC entity shall reduce the bucket level by the total size of the MAC SDU serving the vehicle side link logical channel in the above steps.

[0334] The UE-PC5-V2X-AMBR will not be considered in the sidelink logical channel prioritization process associated with non-vehicle sidelink logical channels, such as sidelink logical channels carrying data such as MCPTT (critical mission push). In other words, there is no restriction on the transmission of non-vehicle data, and the sidelink LCP process will allocate available frequency-time radio resources without such restriction on non-vehicle sidelink logical channels. Alternatively, the previously discussed UE-PC5-AMBR can be used to limit the throughput of non-vehicle data during the sidelink LCP process. Refer to the previous description in conjunction with the first embodiment.

[0335] For the case where the UE has both vehicle and non-vehicle side link logical channels (e.g., MCPTT traffic or voice call) established for transmission on the PC5 interface, the UE according to the embodiment will not multiplex vehicle-mounted and non-vehicle data in one transmission block (TB). Therefore, according to the implementation, the UE will only consider certain side link logical channels (or only all vehicle side link logical channels or all non-vehicle side link logical channels) when performing resource selection and logical channel prioritization process. For this reason, the lower layer should know which side link logical channel is the vehicle side link logical channel or the non-vehicle side link logical channel respectively, regardless of whether the data packet provided by the application layer carries vehicle data or non-vehicle data. This information is based on an exemplary implementation provided by the application layer to the lower layer (transport layer) (e.g., together with the data packet). Alternatively, PPPP can indicate whether the data packet contains vehicle / non-vehicle data, that is, certain PPPP values ​​are reserved for vehicle data. As another alternative, the source layer 2ID or the destination layer 2ID can indicate whether the data packet of the side link logical channel carries vehicle / non-vehicle data.

[0336] Therefore, the vehicle-mounted UE is also able to enforce the UE-PC5-V2X-AMBR parameters for Mode 2 radio resource allocation.

[0337] Other embodiments

[0338] Four different embodiments of how to implement QoS support are described above for the scenario of sending V2X data via the side link interface. The various embodiments above can also be combined together, as described below.

[0339] The fourth embodiment improves the sidelink LCP procedure performed by the vehicle UE by additionally considering UE-PC5-V2X-AMBR (i.e., V2X-specific aggregate maximum bit rate for vehicle data transmission via the PC5 interface). This improvement of the fourth embodiment can be combined with any one of the first, second and third embodiments.

[0340] For example, in the first and second embodiments, UE-PC5-V2X-AMBR will be a parameter that the vehicle-mounted UE additionally considers when allocating frequency-time radio resources to various V2X side link logical channels (for example, obtained by performing radio resource allocation according to the first / second embodiment). UE-PC5-V2X-AMBR can either replace the UE-PC5-AMBR described in the first embodiment, or can be used to limit the transmission throughput of vehicle data, while the UE-PC5-AMBR parameter can be used to limit the transmission throughput of non-vehicle data during the side link LCP process.

[0341] Moreover, for the third embodiment, the UE-PC5-V2X-AMBR may be used in the sidelink logical channel prioritization procedure performed by the onboard UE after obtaining the corresponding transmission parameters from the eNodeB. Although it may be assumed that for mode 1 resource allocation, the corresponding restrictions given by the UE-PC5-V2X-AMBR have been applied by the eNodeB, it is equally possible to implement the corresponding restrictions in the sidelink LCP procedure performed by the onboard UE. Similarly, for mode 2 resource allocation, although other QoS parameters are not considered during resource allocation, the UE-PC5-V2X-AMBR may still be used in the sidelink LCP procedure.

[0342] The third embodiment basically allows resource allocation to depend on the data to be sent, or in other words provides a solution in which resource allocation can be specific to a specific sidelink logical channel. Therefore, by associating that data (or more precisely, the corresponding sidelink logical channel) with mode 1 resource allocation, it is possible to enforce QoS requirements for specific data; in the third embodiment, it is exemplarily assumed that mode 2 resource allocation does not (or at least only in a limited way) support QoS. It is possible to combine the first and second embodiments with the third embodiment. Although the solutions provided by the first and second embodiments are also mode 2 resource allocations performed by the vehicle UE taking into account QoS parameters, for the benefit of the eNodeB, it is still possible to control the vehicle UE so that the vehicle UE performs a specific resource allocation mode for specific vehicle data. In addition, the QoS support indication mentioned in conjunction with the third embodiment can be regarded as another QoS parameter forwarded to the lower layer together with the vehicle data in various implementations of the first embodiment. On the other hand, with respect to the second embodiment, the resource mode indication can be another QoS parameter in the QoS class / configuration. Correspondingly, in the first and second embodiments, the transport layer will execute the corresponding resource allocation mode as indicated by the QoS parameter.

[0343] Other embodiments

[0344] According to a first aspect, a transmitting device for transmitting vehicle data to one or more receiving devices via a side link interface is provided. The transmitting device performs autonomous radio resource allocation to transmit the vehicle data via the side link interface. The application layer of the transmitting device generates the vehicle data and forwards the vehicle data together with a priority indication and one or more quality of service parameters via the side link interface to a transport layer responsible for transmitting the vehicle data. The transport layer performs autonomous radio resource allocation based on the received priority indication and the one or more quality of service parameters. The transport layer sends the vehicle data to the one or more receiving devices via the side link interface according to the performed autonomous radio resource allocation.

[0345] According to a second aspect provided in addition to the first aspect, the one or more quality of service parameters indicate at least one of the following:

[0346] - Packet delay budget: indicates the upper limit time allowed for sending the vehicle data when the vehicle data becomes available for transmission,

[0347] - Packet Error Loss Rate: indicates the allowed vehicle data loss rate,

[0348] - Resource type: with or without guaranteed bitrate.

[0349] According to a third aspect provided in addition to one of the first to second aspects, performing autonomous radio resource allocation for transmitting vehicle data includes:

[0350] - selection of frequency-time radio resources, and / or

[0351] -selecting a modulation and coding scheme, optionally based on a packet error loss rate, and / or

[0352] - Determining a number of repetitions indicative of a number of transmissions of vehicle data, optionally based on a packet error loss rate.

[0353] According to a fourth aspect in addition to one of the first to third aspects, the transmitting device further supports autonomous radio resource allocation and radio resource allocation controlled by a radio base station for transmitting vehicle data via a side link interface. The transmitting device is configured to perform autonomous radio resource allocation and radio resource allocation controlled by a radio base station depending on data to be transmitted. The transport layer determines radio resource allocation for transmitting vehicle data depending on the vehicle data. The transport layer performs autonomous radio resource allocation and transmits the vehicle data according to the performed autonomous radio resource allocation.

[0354] According to a fifth aspect in addition to one of the first to fourth aspects, an aggregate maximum bit rate is defined for a transmitting device, indicating a maximum allowed total data throughput of the transmitting device via a side link interface. Optionally, the aggregate maximum bit rate is configured by a radio base station controlling the transmitting device. The aggregate maximum bit rate is used in a side link logical channel prioritization process as a limit on the data throughput of the transmitting device via the side link interface, the side link logical channel prioritization process being performed by the transmitting device to allocate radio resources to generate data packets carrying vehicle data.

[0355] According to a sixth aspect other than one of the first to fifth aspects, the transmitting device determines whether a packet delay budget of the vehicle data is exceeded, and in the affirmative, discards the vehicle data.

[0356] According to a seventh aspect, a method for sending vehicle data from a sending device to one or more receiving devices via a side link interface is provided. The sending device performs autonomous radio resource allocation for sending vehicle data via the side link interface. The method comprises the following steps performed by the sending device. The vehicle data is generated in the application layer and forwarded to the transport layer responsible for transmitting the vehicle data via the side link interface together with a priority indication and one or more quality of service parameters. The transport layer performs autonomous radio resource allocation based on the received priority indication and the one or more quality of service parameters. The transport layer sends the vehicle data to the one or more receiving devices via the side link interface according to the performed autonomous radio resource allocation.

[0357] According to the eighth aspect in addition to the seventh aspect, the one or more quality of service parameters indicate at least one of the following:

[0358] - Packet delay budget: indicates the upper limit time allowed for sending the vehicle data when the vehicle data becomes available for transmission,

[0359] - Packet Error Loss Rate: indicates the allowed vehicle data loss rate,

[0360] - Resource type: with or without guaranteed bitrate.

[0361] According to a ninth aspect other than the seventh or eighth aspect, performing autonomous radio resource allocation for transmitting vehicle data includes:

[0362] - selection of frequency-time radio resources, and / or

[0363] -selecting a modulation and coding scheme, optionally based on a packet error loss rate, and / or

[0364] - Determining a number of repetitions indicative of a number of transmissions of vehicle data, optionally based on a packet error loss rate.

[0365] According to the tenth aspect in addition to one of the seventh to ninth aspects, an aggregated maximum bit rate is defined for a transmitting device, indicating a maximum allowed total data throughput of the transmitting device via a side link interface. Optionally, the aggregated maximum bit rate is configured by a radio base station controlling the transmitting device. The aggregated maximum bit rate is used in a side link logical channel prioritization process as a limit on the data throughput of the transmitting device via the side link interface, the side link logical channel prioritization process being performed by the transmitting device to allocate radio resources to generate data packets carrying vehicle data.

[0366] According to the eleventh aspect in addition to one of the seventh to tenth aspects, the method further includes the step of determining, by the transmitting device, whether a packet delay budget of the vehicle data is exceeded, and in the affirmative case, discarding the vehicle data.

[0367] According to a twelfth aspect, a transmitting device for transmitting vehicle data to one or more receiving devices via a side link interface is provided. The transmitting device performs autonomous radio resource allocation to transmit vehicle data via the side link interface. A receiving unit of the transmitting device receives system information broadcast by a radio base station in its radio cell, the system information including one or more quality of service configurations. An application layer of the transmitting device generates vehicle data and forwards the generated vehicle data together with an indication to a transport layer responsible for transmitting the vehicle data via the side link interface. The transport layer determines one of the one or more quality of service configurations received depending on the indication received together with the vehicle data. The transport layer performs autonomous radio resource allocation based on the determined one quality of service configuration. The transport layer sends the vehicle data to one or more receiving devices via the side link interface according to the performed autonomous radio resource allocation.

[0368] According to a thirteenth aspect provided in addition to the twelfth aspect, the system information is received in a system information block specific to vehicle communication.

[0369] According to the fourteenth aspect provided in addition to the twelfth or thirteenth aspect, each of the one or more quality of service configurations indicates at least one of the following:

[0370] - Packet delay budget: indicates the upper limit time allowed for sending the vehicle data when the vehicle data becomes available for transmission,

[0371] - Packet Error Loss Rate: indicates the allowed vehicle data loss rate,

[0372] - Resource type: with or without guaranteed bitrate.

[0373] According to a fifteenth aspect provided in addition to one of the twelfth to fourteenth aspects, the system information further includes an aggregate maximum bit rate indicating a maximum allowed total data throughput of a transmitting device via a side link interface. The aggregate maximum bit rate is used in a side link logical channel prioritization process as a limit on a data throughput of the transmitting device via the side link interface, the side link logical channel prioritization process being performed by the transmitting device to allocate radio resources to generate data packets carrying vehicle data.

[0374] According to a sixteenth aspect provided in addition to one of the twelfth to fifteenth aspects, the indication sent to the transport layer together with the vehicle data is a priority indication indicating the priority of the vehicle data. The transport layer determines a quality of service configuration using the received priority indication and a mapping stored in the sending device, the mapping associating each of the one or more quality of service configurations with a priority indication value. Optionally, the mapping is received in system information broadcast by the radio base station in its radio cell or provided by the application layer.

[0375] According to the seventeenth aspect provided in addition to one of the twelfth to sixteenth aspects, the application layer determines which quality of service configuration to use and generates a quality of service class indication indicating the determined one quality of service configuration. The indication sent to the transport layer together with the vehicle data is the generated quality of service class indication. Optionally, a priority indication is sent to the transport layer together with the vehicle data, the priority indication indicating the priority of the vehicle data.

[0376] According to the eighteenth aspect, a method for sending vehicle data from a sending device to one or more receiving devices via a side link interface is provided. The sending device performs autonomous radio resource allocation to send vehicle data via the side link interface. The method includes the following steps performed by the sending device. System information broadcast by a radio base station in its radio cell is received by the sending device, the system information including one or more quality of service configurations. The application layer generates vehicle data and forwards the generated vehicle data together with an indication to a transport layer responsible for transmitting the vehicle data via the side link interface. The transport layer determines one of the one or more quality of service configurations received depending on the indication received with the vehicle data, and performs autonomous radio resource allocation based on the determined one quality of service configuration. Based on the autonomous radio resource allocation performed, the vehicle data is sent to the one or more receiving devices via the side link interface.

[0377] According to the nineteenth aspect provided in addition to the eighteenth aspect, the one or more quality of service parameters indicate at least one of the following:

[0378] - Packet delay budget: indicates the upper limit time allowed for sending the vehicle data when the vehicle data becomes available for transmission,

[0379] - Packet Error Loss Rate: indicates the allowed vehicle data loss rate,

[0380] - Resource type: with or without guaranteed bitrate.

[0381] According to the twentieth aspect provided in addition to the eighteenth or nineteenth aspect, the system information also includes an aggregate maximum bit rate indicating the maximum allowed total data throughput of the transmitting device via the side link interface. The aggregate maximum bit rate is used in the side link logical channel prioritization process as a limit on the data throughput of the transmitting device via the side link interface, and the side link logical channel prioritization process is performed by the transmitting device to allocate radio resources to generate data packets carrying vehicle data. According to the twenty-first aspect provided in addition to one of the eighteenth to twentieth aspects, the indication sent to the transport layer together with the vehicle data is a priority indication indicating the priority of the vehicle data. The transport layer uses the received priority indication and the mapping stored in the transmitting device to determine a quality of service configuration, which associates each of the one or more quality of service configurations with a priority indication value. Optionally, the mapping is received in the system information broadcast by the radio base station in its radio cell or provided by the application layer.

[0382] According to the twenty-second aspect provided in addition to one of the eighteenth to twenty-first aspects, the method further comprises the following steps: determining, by the application layer, which quality of service configuration to use and generating, by the application layer, a quality of service class indication, the indication indicating the determined one quality of service configuration. The indication sent to the transport layer together with the vehicle data is the generated quality of service class indication. Optionally, the method further comprises the step of sending a priority indication together with the vehicle data to the transport layer, the priority indication indicating the priority of the vehicle data.

[0383] According to the twenty-third aspect, a transmitting device for transmitting vehicle data to one or more receiving devices via a side link interface is provided. The transmitting device supports autonomous radio resource allocation and radio resource allocation controlled by a radio base station for transmitting vehicle data via a side link interface. The transmitting device is configured to perform autonomous radio resource allocation and radio resource allocation controlled by a radio base station depending on the data to be transmitted. The application layer of the transmitting device generates first vehicle data and second vehicle data. The application layer forwards the first vehicle data and the second vehicle data to the transport layer responsible for transmitting the vehicle data via the side link interface. The transport layer determines the radio resource allocation for transmitting the first vehicle data depending on the first vehicle data, and determines the radio resource allocation for transmitting the second vehicle data depending on the second vehicle data. The transport layer performs the determined radio resource allocation for the first vehicle data according to the determined radio resource allocation and sends the first vehicle data to the one or more receiving devices via the side link interface. The transport layer performs the determined radio resource allocation for the second vehicle data according to the determined radio resource allocation and sends the second vehicle data to the one or more receiving devices via the side link interface.

[0384] According to the twenty-fourth aspect provided in addition to the twenty-third aspect, one or more quality of service requirements for data transmission are considered when performing radio resource allocation controlled by the radio base station, and are not considered when performing autonomous radio resource allocation.

[0385] According to the twenty-fifth aspect provided in addition to the twenty-third or twenty-fourth aspect, each of the plurality of sidelink logical channels is associated with an autonomous radio resource allocation or a radio resource allocation controlled by a radio base station. The transmitting device determines the radio resource allocation for transmitting the vehicle data based on the sidelink logical channel to which the vehicle data belongs. Optionally, the plurality of sidelink logical channels are established for transmitting the vehicle data and are configured based on a priority indication provided by an application layer together with the vehicle data.

[0386] According to the twenty-sixth aspect provided in addition to one of the twenty-third to twenty-fifth aspects, the association between each of the plurality of sidelink logical channels and the specific radio resource allocation is configured as follows:

[0387] - a radio base station controlling the transmitting device, optionally wherein the radio base station sends a broadcast or dedicated message to the transmitting device comprising information about the association, or

[0388] -The application layer of the sending device.

[0389] According to a twenty-seventh aspect provided in addition to one of the twenty-third to twenty-sixth aspects, radio resource allocation controlled by a radio base station for transmitting vehicle data includes:

[0390] - if the sending device is not connected to a radio base station, connecting to the radio base station,

[0391] - requesting transmission parameters from the radio base station by sending a scheduling request and / or a sidelink buffer status report indicating the amount of vehicle data to be transmitted using a radio resource allocation controlled by the radio base station,

[0392] - in response to the request, receiving transmission parameters for sending the vehicle data from the radio base station, optionally wherein the transmission parameters include at least one of a frequency-time radio resource, a modulation and coding scheme, and a repetition number indicating a number of transmissions of the vehicle data.

[0393] Autonomous radio resource allocation for transmitting first vehicle data includes:

[0394] - selection of frequency-time radio resources, and / or

[0395] - selection of a modulation and coding scheme, and / or

[0396] - Determine a repetition number indicating the number of transmissions of the vehicle data.

[0397] According to the twenty-eighth aspect, a method for sending vehicle data from a sending device to one or more receiving devices via a side link interface is provided. The sending device supports autonomous radio resource allocation and radio resource allocation controlled by a radio base station for sending vehicle data via the side link interface. The sending device is configured to perform autonomous radio resource allocation and radio resource allocation controlled by a radio base station according to the data to be sent. The method includes the following steps performed by the sending device. The application layer of the sending device generates first vehicle data and second vehicle data, and forwards the first vehicle data and the second vehicle data to the transport layer responsible for transmitting the vehicle data via the side link interface. The transport layer of the sending device determines the radio resource allocation for transmitting the first vehicle data depending on the first vehicle data. In addition, the transport layer determines the radio resource allocation for transmitting the second vehicle data depending on the second vehicle data. The transport layer performs the determined radio resource allocation for the first vehicle data according to the determined radio resource allocation, and sends the first vehicle data to the one or more receiving devices via the side link interface. The transport layer performs the determined radio resource allocation for the second vehicle data according to the determined radio resource allocation and sends the second vehicle data to the one or more receiving devices via the side link interface.

[0398] According to the twenty-ninth aspect provided in addition to the twenty-eighth aspect, one or more quality of service requirements for data transmission are considered when performing radio resource allocation controlled by the radio base station, and are not considered when performing autonomous radio resource allocation.

[0399] According to the 30th aspect provided in addition to the 28th or 29th aspect, each of the plurality of sidelink logical channels is associated with an autonomous radio resource allocation or a radio resource allocation controlled by a radio base station. The method further comprises the following steps: determining, by a transmitting device, a radio resource allocation for transmitting vehicle data based on the sidelink logical channel to which the vehicle data belongs. Optionally, the plurality of sidelink logical channels are established for transmitting vehicle data and are configured based on a priority indication provided by an application layer together with the vehicle data.

[0400] According to the 31st aspect provided in addition to one of the 28th to 30th aspects, the association between each of the plurality of sidelink logical channels and the specific radio resource allocation is configured as follows:

[0401] - a radio base station controlling the transmitting device, optionally wherein the radio base station sends a broadcast or dedicated message to the transmitting device comprising information about the association, or

[0402] -The application layer of the sending device.

[0403] According to a thirty-second aspect provided in addition to one of the twenty-eighth to thirty-first aspects, radio resource allocation controlled by a radio base station for transmitting vehicle data includes:

[0404] - if the sending device is not connected to a radio base station, connecting to the radio base station,

[0405] - requesting transmission parameters from the radio base station by sending a scheduling request and / or a sidelink buffer status report indicating the amount of vehicle data to be transmitted using a radio resource allocation controlled by the radio base station,

[0406] - in response to the request, receiving transmission parameters for sending the vehicle data from the radio base station, optionally wherein the transmission parameters include at least one of a frequency-time radio resource, a modulation and coding scheme, and a repetition number indicating a number of transmissions of the vehicle data.

[0407] Autonomous radio resource allocation for transmitting first vehicle data includes:

[0408] - selection of frequency-time radio resources, and / or

[0409] - selection of a modulation and coding scheme, and / or

[0410] - Determine a repetition number indicating the number of transmissions of the vehicle data.

[0411] According to a thirty-third aspect, a transmitting device for transmitting vehicle data to one or more receiving devices via a side link interface is provided. The transmitting device performs autonomous radio resource allocation to transmit vehicle data via the side link interface. An aggregate maximum bit rate is defined for the transmitting device, which indicates the maximum allowed total vehicle data throughput of the transmitting device via the side link interface. The application layer of the transmitting device generates vehicle data and forwards the vehicle data to the transport layer responsible for transmitting the vehicle data via the side link interface. The transport layer of the transmitting device performs autonomous radio resource allocation for the vehicle data, including the selection of frequency-time radio resources. The transport layer performs a side link logical channel prioritization process for allocating the selected frequency-time radio resources to generate data packets carrying vehicle data. The side link logical channel process regards the aggregate maximum bit rate as a limit on the throughput of vehicle data sent by the transmitting device via the side link interface. The transport layer uses the allocated frequency-time radio resources to send the generated data packets carrying vehicle data to the one or more receiving devices.

[0412] According to a thirty-fourth aspect provided in addition to the thirty-third aspect, an aggregate maximum bit rate is used in sidelink logical channel prioritization as an upper limit parameter of a token bucket in a token bucket algorithm for vehicle data.

[0413] According to the thirty-fifth aspect provided in addition to the thirty-third or thirty-fourth aspect, the application layer generates non-vehicle data, and the sidelink logical channel prioritization process does not consider the aggregate maximum bit rate when allocating radio resources to generate data packets carrying the non-vehicle data.

[0414] According to a thirty-sixth aspect provided in addition to any one of the aforementioned aspects, the sending device is a vehicle mobile terminal, a roadside unit or a mobile terminal.

[0415] According to a thirty-seventh aspect, a method for sending vehicle data from a transmitting device to one or more receiving devices via a side link interface is provided. The transmitting device performs autonomous radio resource allocation to send vehicle data via the side link interface. An aggregate maximum bit rate is defined for the transmitting device, indicating the maximum allowed total vehicle data throughput of the transmitting device via the side link interface. The method includes the following steps performed by the transmitting device. The application layer of the transmitting device generates vehicle data and forwards the vehicle data to the transport layer responsible for transmitting the vehicle data via the side link interface. The transport layer of the transmitting device performs autonomous radio resource allocation for the vehicle data, including the selection of frequency-time radio resources. The transport layer performs a side link logical channel prioritization process for allocating the selected frequency-time radio resources to generate data packets carrying vehicle data. The side link logical channel process regards the aggregate maximum bit rate as a limit on the throughput of the vehicle data sent by the transmitting device via the side link interface. The transport layer uses the allocated frequency-time radio resources to send the generated data packets carrying vehicle data to the one or more receiving devices.

[0416] According to the thirty-eighth aspect provided in addition to the thirty-seventh aspect, the aggregate maximum bit rate is used in the side link logical channel prioritization as an upper limit parameter of the token bucket in the token bucket algorithm for vehicle data.

[0417] According to the thirty-ninth aspect provided in addition to the thirty-seventh or thirty-eighth aspect, the application layer generates non-vehicle data, and the sidelink logical channel prioritization process does not consider the aggregate maximum bit rate when allocating radio resources to generate data packets carrying the non-vehicle data.

[0418] According to one aspect of the present invention, a sending device for sending vehicle data to one or more receiving devices via a side link interface, wherein the sending device performs autonomous radio resource allocation for sending the vehicle data via the side link interface, wherein the sending device includes: an application layer, which generates the vehicle data, wherein the application layer forwards the vehicle data together with a priority indication and one or more quality of service parameters via the side link interface to a transport layer responsible for transmitting the vehicle data, and the transport layer, which performs autonomous radio resource allocation based on the received priority indication and the one or more quality of service parameters, wherein the transport layer sends the vehicle data to the one or more receiving devices via the side link interface based on the performed autonomous radio resource allocation.

[0419] According to the aforementioned sending device, the one or more quality of service parameters indicate at least one of the following: -Packet delay budget: indicating the upper limit time allowed for sending the vehicle data when the vehicle data becomes available for transmission, -Packet error loss rate: indicating the allowed vehicle data loss rate, -Resource type: with or without a guaranteed bit rate.

[0420] According to the aforementioned transmitting device, wherein an aggregate maximum bit rate is defined for the transmitting device, indicating the maximum allowed total data throughput of the transmitting device via the side link interface, optionally, wherein the aggregate maximum bit rate is configured by a radio base station controlling the transmitting device, and wherein the aggregate maximum bit rate is used for a side link logical channel prioritization process as a limitation on the data throughput of the transmitting device via the side link interface, and the side link logical channel prioritization process is performed by the transmitting device to allocate radio resources to generate data packets carrying the vehicle data.

[0421] According to another aspect of the present invention, a method for sending vehicle data from a sending device to one or more receiving devices via a side link interface, wherein the sending device performs autonomous radio resource allocation for sending the vehicle data via the side link interface, the method comprising the following steps performed by the sending device: generating the vehicle data in an application layer, and forwarding the vehicle data together with a priority indication and one or more quality of service parameters via the side link interface to a transport layer responsible for transmitting the vehicle data, and based on the received priority indication and the one or more quality of service parameters, the transport layer performs autonomous radio resource allocation, and based on the performed autonomous radio resource allocation, the transport layer sends the vehicle data to the one or more receiving devices via the side link interface.

[0422] According to the aforementioned method, the one or more quality of service parameters indicate at least one of the following: -Packet delay budget: indicating the upper limit time allowed for sending the vehicle data when the vehicle data becomes available for transmission, -Packet error loss rate: indicating the allowed vehicle data loss rate, -Resource type: with or without a guaranteed bit rate.

[0423] According to another aspect of the present invention, a sending device for sending vehicle data to one or more receiving devices via a side link interface, wherein the sending device performs autonomous radio resource allocation for sending the vehicle data via the side link interface, wherein the sending device includes: a receiving unit, which receives system information broadcast by a radio base station in its radio cell, the system information including one or more quality of service configurations, an application layer, which generates the vehicle data and forwards the generated vehicle data together with an indication via the side link interface to a transport layer responsible for transmitting the vehicle data, the transport layer, which determines one of the one or more quality of service configurations received depending on the indication received together with the vehicle data, and the transport layer performs the autonomous radio resource allocation based on the determined one quality of service configuration, and wherein the transport layer sends the vehicle data to the one or more receiving devices via the side link interface according to the performed autonomous radio resource allocation.

[0424] According to the aforementioned sending device, each of the one or more quality of service configurations indicates at least one of the following: -Packet delay budget: indicating the upper limit time allowed for sending the vehicle data when the vehicle data becomes available for transmission, -Packet error loss rate: indicating the allowed vehicle data loss rate, -Resource type: with or without a guaranteed bit rate.

[0425] According to the aforementioned sending device, the indication sent to the transport layer together with the vehicle data is a priority indication, indicating the priority of the vehicle data, wherein the transport layer uses the received priority indication and the mapping stored in the sending device to determine the one quality of service configuration, the mapping associating each of the one or more quality of service configurations with a priority indication value, and optionally, wherein the mapping is received in the system information broadcast by the radio base station in its radio cell or provided by the application layer.

[0426] According to the aforementioned sending device, the application layer determines which quality of service configuration to use and generates a quality of service class indication indicating a determined quality of service configuration, wherein the indication sent to the transport layer together with the vehicle data is the generated quality of service class indication, and optionally, wherein a priority indication is sent to the transport layer together with the vehicle data, and the priority indication indicates the priority of the vehicle data.

[0427] According to another aspect of the present invention, a method for sending vehicle data from a sending device to one or more receiving devices via a side link interface, wherein the sending device performs autonomous radio resource allocation for sending the vehicle data via the side link interface, the method comprising the following steps performed by the sending device: receiving system information broadcast by a radio base station in its radio cell, the system information including one or more quality of service configurations, generating the vehicle data in an application layer and forwarding the generated vehicle data together with an indication via the side link interface to a transport layer responsible for transmitting the vehicle data, determining by the transport layer one of the one or more quality of service configurations received depending on the indication received together with the vehicle data, and based on the determined one quality of service configuration, performing the autonomous radio resource allocation by the transport layer, and sending the vehicle data to the one or more receiving devices via the side link interface based on the performed autonomous radio resource allocation.

[0428] According to the aforementioned method, each of the one or more quality of service configurations indicates at least one of the following: -Packet delay budget: indicating the upper limit time allowed for sending the vehicle data when the vehicle data becomes available for transmission, -Packet error loss rate: indicating the allowed vehicle data loss rate, -Resource type: with or without a guaranteed bit rate.

[0429] According to another aspect of the present invention, a sending device for sending vehicle data to one or more receiving devices via a side link interface, wherein the sending device performs autonomous radio resource allocation for sending the vehicle data via the side link interface, wherein an aggregate maximum bit rate is defined for the sending device, indicating the maximum total vehicle data throughput allowed by the sending device via the side link interface, wherein the sending device includes: an application layer, which generates the vehicle data, wherein the application layer forwards the vehicle data via the side link interface to a transport layer responsible for transmitting the vehicle data, the transport layer, which performs the autonomous radio resource allocation for the vehicle data, including the selection of frequency-time radio resources, the transport layer, which performs a side link logical channel prioritization process for allocating the selected frequency-time radio resources to generate data packets carrying the vehicle data, the side link logical channel process regards the aggregate maximum bit rate as a limitation on the throughput of the vehicle data sent by the sending device via the side link interface, and the transport layer, which uses the allocated frequency-time radio resources to send the generated data packets carrying the vehicle data to the one or more receiving devices.

[0430] According to the aforementioned transmitting device, the aggregate maximum bit rate is used as an upper limit parameter of a token bucket in a token bucket algorithm for the vehicle data in the sidelink logical channel prioritization.

[0431] According to the aforementioned transmitting device, the application layer generates non-vehicle data, and the sidelink logical channel prioritization process does not consider the aggregate maximum bit rate when allocating radio resources to generate data packets carrying the non-vehicle data.

[0432] According to another aspect of the present invention, a method for sending vehicle data from a sending device to one or more receiving devices via a side link interface, wherein the sending device performs autonomous radio resource allocation for sending the vehicle data via the side link interface, wherein an aggregate maximum bit rate is defined for the sending device, indicating the maximum allowed total vehicle data throughput of the sending device via the side link interface, and the method includes the following steps performed by the sending device: the vehicle data is generated by an application layer and forwarded by the application layer to a transport layer responsible for transmitting the vehicle data via the side link interface, the autonomous radio resource allocation of the vehicle data is performed by the transport layer, including the selection of frequency-time radio resources, the side link logical channel prioritization process is performed by the transport layer for allocating the selected frequency-time radio resources to generate data packets carrying the vehicle data, the side link logical channel process regards the aggregate maximum bit rate as a limit on the throughput of the vehicle data sent by the sending device via the side link interface, and the transport layer uses the allocated frequency-time radio resources to send the generated data packets carrying the vehicle data to the one or more receiving devices.

[0433] Hardware and software implementations of the present disclosure

[0434] Other exemplary embodiments involve implementing the various embodiments described above using hardware, software, or software in cooperation with hardware. In this regard, a user terminal (mobile terminal) and an eNodeB (base station) are provided. The user terminal and the base station are suitable for performing the methods described herein, including corresponding entities that appropriately participate in the methods, such as a receiving unit, a sending unit, and a processing unit.

[0435] It is also recognized that various embodiments can be implemented or executed using a computing device (processor). The computing device or processor can be, for example, a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, etc. Various embodiments can also be performed or embodied by combining these devices. Specifically, each functional block used in the description of each of the above embodiments can be implemented as an integrated circuit by LSI. They can be formed into a chip individually, or a chip can be formed to include part or all of the functional blocks. They can include data input and output coupled thereto. Depending on the difference in integration, the LSI here can be referred to as IC, system LSI, super LSI or ultra LSI. However, the technology for implementing integrated circuits is not limited to LSI, and can be implemented by using a dedicated circuit or a general-purpose processor. In addition, an FPGA (field programmable gate array) that can be programmed after LSI manufacturing or a reconfigurable processor in which the connection and setting of the circuit unit placed inside the LSI can be reconfigured can be used.

[0436] In addition, various embodiments may also be implemented by software modules executed by a processor or directly in hardware. Combinations of software modules and hardware implementations are also possible. Software modules may be stored on any type of computer-readable storage medium, such as RAM, EPROM, EEPROM, flash memory, registers, hard disk, CD-ROM, DVD, etc. It should also be noted that the various features of different embodiments may be combined individually or arbitrarily with respect to the features of another embodiment.

[0437] It will be appreciated by those skilled in the art that many changes and / or modifications may be made to the present disclosure as shown in the specific embodiments. Therefore, the present embodiments are to be considered in all aspects as illustrative and not restrictive.

Claims

1. A transmitting device for transmitting vehicle data to one or more receiving devices via a side link interface, wherein the transmitting device performs autonomous radio resource allocation for transmitting the vehicle data via the side link interface, wherein the transmitting device comprises: Circuit, obtaining one or more quality of service configurations provided in the sending device, generating the vehicle data in an application layer and forwarding the generated vehicle data to a transport layer together with a priority indication indicating a priority of the vehicle data, determining, in the transport layer, one of the one or more obtained quality of service configurations depending on the priority indication obtained together with the vehicle data and a mapping provided in the sending device associating each of the one or more quality of service configurations with a priority indication value, and performing said autonomous radio resource allocation based on the determined one quality of service configuration, and A transmitting unit transmits the vehicle data to the one or more receiving devices via the side link interface according to the performed autonomous radio resource allocation.

2. The transmitting device according to claim 1, wherein: Each of the one or more quality of service configurations indicates at least one of: - Packet delay budget: indicates the upper limit time allowed for sending the vehicle data when the vehicle data becomes available for transmission, - Packet Error Loss Rate: indicates the allowed vehicle data loss rate, - Resource type: with or without guaranteed bitrate.

3. The transmitting device according to claim 1 or 2, in, The mapping is received in system information broadcasted by a radio base station in its radio cell or provided by the application layer.

4. The transmitting device according to one of claims 1 to 3, wherein: The circuit determines in the application layer which quality of service configuration to use and generates a quality of service class indication indicating the determined one quality of service configuration, wherein the indication forwarded to the transport layer with the vehicle data is the generated quality of service class indication.

5. The transmitting device according to claim 1, wherein: In order to send the vehicle data when different sidelink logical channels are multiplexed in one transmission block TB, the quality of service QoS parameters for radio resource selection and transmission of the TB are selected based on the sidelink logical channel associated with the highest priority indication among the different sidelink logical channels associated with the priority indication, so as to transmit the TB via the sidelink interface.

6. A method for transmitting vehicle data from a transmitting device to one or more receiving devices via a side link interface, wherein the transmitting device performs autonomous radio resource allocation for transmitting the vehicle data via the side link interface, the method comprising the following steps performed by the transmitting device: obtaining one or more quality of service configurations provided in the sending device, generating the vehicle data in an application layer and forwarding the generated vehicle data to a transport layer together with a priority indication indicating a priority of the vehicle data, determining, by the transport layer, one of the one or more obtained quality of service configurations in dependence on the priority indication obtained together with the vehicle data and a mapping provided in the sending device associating each of the one or more quality of service configurations with a priority indication value, performing, by the transport layer, the autonomous radio resource allocation based on the determined one quality of service configuration, and The vehicle data is transmitted to the one or more receiving devices via the sidelink interface in accordance with the performed autonomous radio resource allocation.

7. The method according to claim 6, wherein: Each of the one or more quality of service configurations indicates at least one of: - Packet delay budget: indicates the upper limit time allowed for sending the vehicle data when the vehicle data becomes available for transmission, - Packet Error Loss Rate: indicates the allowed vehicle data loss rate, - Resource type: with or without guaranteed bitrate.

8. An integrated circuit that controls processing of a transmitting device for transmitting vehicle data from the transmitting device to one or more receiving devices via a sidelink interface, wherein: The transmitting device performs autonomous radio resource allocation for transmitting the vehicle data via the side link interface, the integrated circuit comprising: circuitry for obtaining one or more quality of service configurations provided in said transmitting device, circuitry for generating the vehicle data in an application layer and forwarding the generated vehicle data to a transport layer together with a priority indication indicating a priority of the vehicle data, circuitry for determining, by the transport layer, one of the one or more obtained quality of service configurations in dependence upon the priority indication obtained with the vehicle data and a mapping provided in the sending device associating each of the one or more quality of service configurations with a priority indication value, circuitry for performing, by the transport layer, the autonomous radio resource allocation based on the determined one quality of service configuration, and Circuitry for transmitting the vehicle data to the one or more receiving devices via the sidelink interface in accordance with the performed autonomous radio resource allocation.

Images