JP7162702B2 - Improved semi-persistent resource allocation for V2V traffic - Google Patents

Description

The present disclosure relates to improved semi-persistent resource allocation between mobile terminals and radio base stations. The present disclosure provides an integrated circuit for controlling the processing of a corresponding (vehicle) mobile terminal.

<Long Term Evolution (LTE)>
The third generation mobile communication system (3G), based on WCDMA(R) radio access technology, is being deployed on a wide scale around the world. As a first step in enhancing or developing/evolving this technology, High-Speed Downlink Packet Access (HSDPA) and High-Speed Uplink Packet Access (HSUPA). A so-called enhanced uplink has been introduced, offering a very competitive radio access technology.

In order to meet the increasing demand from users and to ensure competitiveness with new radio access technologies, 3GPP has introduced a new mobile communication system called Long Term Evolution (LTE). LTE is designed to meet carrier needs for high-speed data and media transmission as well as high-capacity voice support over the next decade. The ability to provide high bitrates is a key strategy in LTE.

A work item (WI) on Long Term Evolution (LTE), called Evolved UMTS Terrestrial Radio Access (UTRA) and UMTS Terrestrial Radio Access Network (UTRAN). The specification has been finalized as Release 8 (LTE Release 8). The LTE system represents an efficient packet-based radio access and radio access network that offers full IP-based functionality at low latency and low cost. In LTE, scalable multiple frequencies such as 1.4 MHz, 3.0 MHz, 5.0 MHz, 10.0 MHz, 15.0 MHz, and 20.0 MHz are used to achieve flexible system deployment with the given spectrum. Send bandwidth is specified. In the downlink, the inherent immunity to multipath interference (MPI) due to the low symbol rate, the use of cyclic prefixes (CPs), and various transmission bandwidth arrangements and Radio access based on Orthogonal Frequency Division Multiplexing (OFDM) was adopted because of its compatibility. In the uplink, considering that the transmission power of the user equipment (UE: User Equipment) is limited, priority is given to providing a wide area coverage rather than improving the peak data rate, single carrier frequency Single-carrier frequency division multiple access (SC-FDMA) based radio access has been adopted. LTE Release 8/9 adopts many key packet radio access technologies, including multiple-input multiple-output (MIMO) channel transmission techniques, to achieve a highly efficient control signaling structure. .

<LTE architecture>
Figure 1 shows the overall LTE architecture. E-UTRAN consists of eNodeBs and provides termination of E-UTRA User Plane (PDCP/RLC/MAC/PHY) and Control Plane (RRC) protocols towards User Equipment (UE). The eNodeB (eNB) consists of a physical (PHY) layer, a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, which contains user plane header compression and ciphering functionality, and the Packet Data Control Protocol (PDCP) layer. The eNodeB (eNB) also provides Radio Resource Control (RRC) functionality for the control plane. The eNodeB (eNB) performs radio resource management, admission control, scheduling, negotiated uplink Quality of Service (QoS) enforcement, cell information broadcast, encryption/decryption of user plane and control plane data, as well as compression/decompression of downlink/uplink user plane packet headers. eNodeBs are interconnected by an X2 interface.

The eNodeBs are also connected via the S1 interface to the EPC (Evolved Packet Core), more specifically via the S1-MME to the MME (Mobility Management Entity) and via the S1-U It is connected to a Serving Gateway (SGW). The S1 interface supports many-to-many relationships between MME/Serving Gateways and eNodeBs. The SGW serves as a user plane mobility anchor during handovers between eNodeBs and as an anchor for mobility between LTE and other 3GPP technologies (terminating the S4 interface, between 2G/3G systems and PDN GWs). relay traffic) while routing and forwarding user data packets. For idle user equipment, the SGW terminates the downlink data path and triggers paging when downlink data for that user equipment arrives. The SGW manages and stores user equipment context, eg parameters of IP bearer services or network internal routing information. The SGW also duplicates user traffic in case of lawful interception.

The MME is the main control node for the LTE access network. The MME is responsible for idle mode user equipment tracking and paging procedures, including retransmissions. The MME is involved in the bearer activation/deactivation process and is responsible for selecting the SGW for the user equipment during initial attach and during intra-LTE handover with Core Network (CN) node relocation. is also responsible. The MME is responsible for authenticating the user (by interacting with the HSS). Non-Access Stratum (NAS) signaling is terminated at the MME, which is also responsible for generating and assigning temporary identities to user equipment. The MME checks authorization of the user equipment to camp on the service provider's Public Land Mobile Network (PLMN) and enforces roaming restrictions for the user equipment. The MME is the termination point in the network for ciphering/integrity protection of NAS signaling and handles security key management. Lawful interception of signaling is also supported by the MME. The MME also provides the S3 interface from the SGSN and terminating at the MME to control plane functions for mobility between LTE and 2G/3G access networks. The MME also terminates the S6a interface towards the home HSS for roaming user equipment.

個のサブキャリアと

個のＯＦＤＭシンボルのリソースグリッドによって記述される。

は、帯域幅内のリソースブロックの数である。

は、セルにおいて設定されているダウンリンク送信帯域幅に依存し、

を満たし、この場合、

および

は、それぞれ、現在のバージョンの仕様によってサポートされている最小ダウンリンク帯域幅および最大ダウンリンク帯域幅である。

は、１つのリソースブロック内のサブキャリアの数である。通常のサイクリックプレフィックスのサブフレーム構造の場合、

および

である。 <Component carrier structure in LTE>
The downlink component carriers of the 3GPP LTE system are subdivided into so-called subframes in the time-frequency domain. In 3GPP LTE, each subframe is divided into two downlink slots as shown in Figure 2, the first downlink slot containing the 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)), each OFDM symbol spanning the entire bandwidth of a component carrier. Thus, each OFDM symbol consists of a number of modulation symbols sent on respective subcarriers. In LTE, the signal transmitted in each slot is

subcarriers and

is described by a resource grid of OFDM symbols.

is the number of resource blocks in the bandwidth.

depends on the configured downlink transmission bandwidth in the cell,

and in this case

and

are respectively the minimum and maximum downlink bandwidths supported by the current version of the specification.

is the number of subcarriers in one resource block. For a normal cyclic prefix subframe structure,

and

is.

Assuming a multi-carrier communication system, e.g. using OFDM, such as that used in 3GPP Long Term Evolution (LTE), the smallest unit of resources that can be allocated by the scheduler is one "resource block ”. A physical resource block (PRB) consists of consecutive OFDM symbols in the time domain (eg, 7 OFDM symbols) and consecutive subcarriers in the frequency domain (eg, 12 component carriers), as illustrated in FIG. subcarriers). Thus, in 3GPP LTE (Release 8), a physical resource block consists of resource elements and corresponds to one slot in the time domain and 180 kHz in the frequency domain (further details on the downlink resource grid can be found at http:/ See, eg, section 6.2 of current version 13.0.0 of Non-Patent Document 1, available at www.3gpp.org and incorporated herein by reference).

One subframe consists of two slots, so there are 14 OFDM symbols in a subframe when the so-called "normal" CP (cyclic prefix) is used and the so-called "extended" CP is There are 12 OFDM symbols in a subframe when used. For the purpose of terminology, time-frequency resources equivalent to the same contiguous subcarriers spanning an entire subframe are hereinafter referred to as "resource block pairs" or equivalently "RB pairs" or "PRB pairs".

The term "component carrier" refers to a combination of several resource blocks in the frequency domain. In future releases of LTE, the term "component carrier" will no longer be used, instead the terminology will be changed to "cell", which refers to a combination of downlink and optionally uplink resources. A linking between the carrier frequencies of the downlink resources and the carrier frequencies of the uplink resources is indicated in the system information transmitted on the downlink resources.

Similar assumptions regarding the component carrier structure apply to subsequent releases.

<Carrier aggregation in LTE-A for wider bandwidth support>
At the World Radiocommunication Conference 2007 (WRC-07), the frequency spectrum for IMT-Advanced was decided. Although the overall frequency spectrum for IMT-Advanced has been determined, the actual available frequency bandwidth varies from region to region and country to country. However, following the decision to outline the available frequency spectrum, the 3rd Generation Partnership Project (3GPP) began standardizing the radio interface. At the 3GPP TSG RAN #39 meeting, the work item description on "Further Advancements for E-UTRA (LTE-Advanced)" was approved. This study item covers technical elements to be considered in evolving E-UTRA, eg, to meet the requirements of IMT-Advanced.

The LTE system can only support 20MHz, while the bandwidth that the LTE-Advanced system can support is 100MHz. Today, the scarcity of radio spectrum has become a bottleneck in the development of wireless networks, and as a result it is difficult to find wide enough spectrum bands for LTE-Advanced systems. As a result, there is an urgent need to find ways to acquire wider wireless spectrum bands, and a possible answer is carrier aggregation functionality.

In carrier aggregation, two or more component carriers are aggregated to support wider transmission bandwidths up to 100 MHz. Several cells in the LTE system are aggregated into one wider channel in the LTE-Advanced system, which is wide enough for 100 MHz even though the cells are in different frequency bands in LTE.

All component carriers can be configured to be LTE Release 8/9 compatible, at least when the component carrier bandwidth does not exceed the supported bandwidth of an LTE Release 8/9 cell. All component carriers aggregated by a user equipment may not necessarily be Release 8/9 compatible. Existing mechanisms (eg, barring) may be used to prevent Rel-8/9 user equipment from camping on component carriers.

A user equipment may receive or transmit simultaneously on one or more component carriers (corresponding to multiple serving cells) depending on its capabilities. An LTE-A Release 10 user equipment with receive and/or transmit capabilities for carrier aggregation can simultaneously receive and/or transmit on multiple serving cells, while LTE Release 8 A/9 user equipment can only receive and transmit on one serving cell as long as the component carrier structure complies with Release 8/9 specifications.

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

Configure 3GPP LTE-A (Release 10) compatible user equipment to aggregate different numbers of component carriers originating from the same eNodeB (base station), possibly with different bandwidths on the uplink and downlink. It is possible to The number of downlink component carriers that can be configured depends on the UE's downlink aggregation capability. Conversely, the number of uplink component carriers that can be configured depends on the UE's uplink aggregation capability. It may not currently be 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 are the same for uplink and downlink. Component carriers originating from the same eNodeB need not provide the same coverage.

The spacing of the center frequencies of consecutively aggregated component carriers shall be a multiple of 300 kHz. This is to maintain compatibility with the 100 kHz frequency raster of 3GPP LTE (Release 8/9) while maintaining orthogonality of 15 kHz spaced subcarriers. In some aggregation scenarios, n×300 kHz spacing can be facilitated by inserting a small number of unused subcarriers between consecutive component carriers.

The impact of aggregating multiple carriers only extends to the MAC layer. For both uplink and downlink, one HARQ entity per aggregated component carrier is required in MAC. There is at most one transport block per component carrier (without SU-MIMO for uplink). A transport block and its possible HARQ retransmissions should be mapped to the same component carrier.

When carrier aggregation is configured, the mobile terminal has only one RRC connection with the network. During establishment/re-establishment of RRC connection, similar to LTE Rel-8/9, one cell provides security inputs (one ECGI, one PCI and one ARFCN) and non-access stratum mobility information (e.g. TAI). offer. After establishment/re-establishment of the RRC connection, the component carrier corresponding to the cell in question is called the downlink primary cell (PCell). In the connected state, there is always only one Downlink PCell (DL PCell) and one Uplink PCell (UL PCell) per user equipment. Within the set of configured component carriers, other cells are called Secondary Cells (SCells), and the carriers of the SCells are referred to as Downlink Secondary Component Carriers (DL SCCs) and Uplink Secondary Components. It is called a carrier (UL SCC: Uplink Secondary Component Carrier). Up to five serving cells including PCell can be configured for one UE.

<MAC layer/entity, RRC layer, physical layer>
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 within the Layer 2 architecture of the LTE radio protocol stack and is defined, for example, by the current version 13.0.0 of [2]. Connections to the physical layer below are via transport channels and connections to the RLC layer above are via logical channels. Therefore, the MAC layer multiplexes and demultiplexes between the logical channels and the transport channels, i.e. the MAC layer on the transmitting side takes the MAC SDUs received via the logical channels and converts them into transport blocks known as transport blocks. The MAC layer at the receiving side recovers the MAC SDU from the MAC PDU received over the transport channel.

the MAC layer provides data transmission services for the RLC layer via logical channels (see Sections 5.4 and 5.3 of Non-Patent Document 2, incorporated herein by reference); A logical channel is either a control logical channel carrying control data (eg RRC signaling) or a traffic logical channel carrying user plane data. On the other hand, data from the MAC layer is exchanged with the physical layer via transport channels, which are classified as downlink or uplink. Data is multiplexed into transport channels depending on how it is transmitted over the air.

The physical layer is responsible for the actual transmission of data and control information over the air interface, ie it conveys all information from the MAC transport channels over the transmitting air interface. Some of the important functions performed by the physical layer include coding and modulation, link adaptation (AMC), power control, cell search (for initial synchronization and handover purposes) and other measurements for the RRC layer (LTE intra-system and inter-system). The physical layer performs transmission based on transmission parameters such as modulation scheme, coding rate (ie, modulation and coding scheme, MCS), number of physical resource blocks, and so on. Detailed information about physical layer functionality is described in Non-Patent Document 3, current version 13.0.0, which is incorporated herein by reference.

The Radio Resource Control (RRC) layer controls the communication between the UE and the eNB on the radio interface and the mobility of the UE moving across several cells. The RRC protocol also supports transmission of NAS information. For UEs in RRC_IDLE state, RRC supports notification of incoming calls from the network. RRC connection control is responsible for paging, measurement setup and notification, radio resource setup, initial security activation, and establishment of Signaling Radio Bearers (SRBs) and radio bearers carrying user data (Data Radio Bearers, DRBs). It covers all procedures related to RRC connection establishment, modification and release, including Radio Bearer establishment.

The radio link control (RLC) sublayer primarily provides ARQ functionality and supports data segmentation and concatenation, i.e., the RLC layer uses RLC to size RLC SDUs as indicated by the MAC layer. Frame the SDU. The latter two minimize protocol overhead regardless of data rate. The RLC layer is connected to the MAC layer via logical channels. Each logical channel carries a different type of traffic. The layer above the RLC layer is usually the PDCP layer, but can also be the RRC layer, namely the logical channels BCCH (Broadcast Control Channel), PCCH (Paging Control Channel) and RRC messages sent on CCCH (Common Control Channel) do not require security protection and therefore enter the RLC layer directly, bypassing the PDCP layer. The main services and functions of the RLC sublayer include:
- Transmission of higher layer PDUs supporting AM, UM or TM data transmission - Error correction through ARQ - Segmentation according to TB size - When required (e.g. radio quality, i.e. supported TB Concatenation of SDUs for the same radio bearer is FFS In-order delivery of higher layer PDUs Duplicate detection Protocol error detection and recovery SDU discard Reset The ARQ functionality provided by RLC is discussed in more detail in a later section.

<Uplink access scheme for LTE>
Uplink transmissions require power efficient user equipment transmissions 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 reasons for favoring single-carrier transmission are the lower Peak-to-Average Power Ratio (PAPR) compared to multi-carrier signals (OFDMA) and the corresponding improved power amplifier efficiency and improvements. coverage (higher data rate for a given terminal peak power). During each time interval, the eNodeB assigns users unique time/frequency resources for transmitting user data, thereby ensuring intra-cell orthogonality. 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 (eNodeB) with the help of inserting a cyclic prefix into the transmitted signal.

A basic physical resource used for data transmission consists of a frequency resource of size BW grant during one time interval, e.g. a subframe, to which coded information bits are mapped. It should be noted that a subframe, also called transmission time interval (TTI), is the minimum time interval for user data transmission. However, by concatenating subframes, it is possible to allocate frequency resources BWgrant to users for a period longer than one TTI.

<Layer 1/Layer 2 control signaling>
L1/L2 control signaling is used to inform scheduled users of their allocation status, transport format, and other transmission-related information (e.g., HARQ information, transmit power control (TPC) commands). Sent on the downlink along with the data. L1/L2 control signaling is multiplexed with downlink data within subframes, assuming that user allocations can change from subframe to subframe. It should be noted that user allocation may also be performed on a TTI (Transmission Time Interval) basis, in which case the TTI length may be a multiple of subframes. The TTI length may be fixed for all users within the coverage area, different for different users, or even dynamic for each user. In general, L1/2 control signaling only needs to be sent once per TTI. Without loss of generality, the following assumes that the TTI is one subframe.

L1/L2 control signaling is transmitted on the Physical Downlink Control Channel (PDCCH). The PDCCH carries messages as Downlink Control Information (DCI), which in most cases contains resource allocations and other control information for mobile terminals or groups of UEs. Several PDCCHs can be transmitted in one subframe.

In general, information sent within L1/L2 control signaling to allocate uplink radio resources or downlink radio resources (particularly LTE(-A) Release 10) can be categorized into the following items:

- User identification information: indicates the user to be assigned. This is usually included in the checksum by masking the CRC with user identification information.
- Resource Allocation Information: Indicates the resource (eg Resource Block (RB)) to which the user is allocated. Alternatively, this information is referred to as the resource block assignment (RBA). Note that the number of RBs to which a user is assigned can be dynamic.
- Carrier indicator: used when a control channel transmitted on a first carrier allocates resources associated with a second carrier, i.e. resources on or associated with a second carrier (cross carrier scheduling).
- Modulation/coding method: Determines the modulation method and coding rate to be adopted.
- HARQ information: such as new data indicator (NDI) and/or redundancy version (RV), which is particularly useful when retransmitting data packets or parts thereof.
- Power control command: adjusts the transmission power of the uplink data or control information transmissions to which it is assigned.
- Reference signal information: such as the applied cyclic shift and/or orthogonal cover code index used to transmit or receive the reference signal in connection with the allocation.
- Uplink Allocation Index or Downlink Allocation Index: used to identify the order of allocations, particularly useful in TDD systems.
- Hopping information: indication information, eg, whether and how to apply resource hopping to increase frequency diversity.
- CSI request: used to trigger transmission of channel state information on allocated resources.
- Multi-cluster information: indicates and controls whether transmission occurs in a single cluster (set of contiguous RBs) or in multiple clusters (at least two non-contiguous, contiguous sets of RBs). is a flag used for Multi-cluster allocation was introduced by 3GPP LTE-(A) Release 10.

Note that the above list is not exhaustive, and depending on the DCI format used, not all listed information items need be present in each PDCCH transmission.

Downlink control information occurs in several formats, which differ in overall size and also in the information contained in the fields mentioned above. The different DCI formats currently defined for LTE are: org, which is incorporated herein by reference). For example, the following DCI Format can be used to convey resource grants for the uplink.

- Format 0: DCI Format 0 is used for transmission of resource grants for PUSCH using single antenna port transmission in uplink transmission mode 1 or 2;

- Format 4: DCI format 4 is used for scheduling of PUSCH using closed-loop spatial multiplexing transmission in uplink transmission mode 2;

Non-Patent Document 4, current version 13.0.0, defines control information for sidelinks in Section 5.4.3, which is incorporated herein by reference.

<Semi-persistent scheduling (SPS)>
In the downlink and uplink, the eNodeB schedules to dynamically allocate resources to user equipments over the L1/L2 control channel (PDCCH) in each transmission time interval, and in the L1/L2 control channel (PDCCH) , user equipments are addressed via their own C-RNTI. As already mentioned above, the CRC of the PDCCH is masked with the C-RNTI of the addressed user equipment (so-called dynamic PDCCH). Only user equipments with a matching C-RNTI can correctly decode the content onto the PDCCH, ie a CRC check helps. This kind of PDCCH signaling is also called dynamic (scheduling) grant. A user equipment monitors the L1/L2 control channel for dynamic grants in each transmission time interval to find possible assignments (downlink and uplink) to which it is assigned.

Also, E-UTRAN can persistently allocate uplink/downlink resources for initial HARQ transmission. If requested, retransmissions are explicitly signaled via the L1/L2 control channel. Since retransmissions are scheduled dynamically, this kind of operation is called semi-persistent scheduling (SPS), i.e. resources are allocated to user equipments on a semi-persistent basis (semi-persistent resource allocation: semi-persistent resource allocation). The advantage is that PDCCH resources for initial HARQ transmission are saved. Semi-persistent scheduling may be used on Release 10 PCells, but not on SCells.

One example of a service that can be scheduled using semi-persistent scheduling is Voice over IP (VoIP). During the talk spurt, VoIP packets are generated every 20 ms in the codec. As such, the eNodeB can persistently allocate uplink or individual downlink resources every 20ms, so that the resources can be used for the transmission of Voice over IP packets. In general, semi-persistent scheduling is beneficial for services with predictable traffic behavior, ie constant bit rate, periodic packet arrival times.

The user equipment also monitors the PDCCH in subframes that are persistently allocated resources for initial transmission. A dynamic (scheduling) grant, ie a PDCCH with a C-RNTI masked CRC, can override the semi-persistent resource allocation. If the user equipment finds its C-RNTI on the L1/L2 control channel in a subframe in which the user equipment has assigned semi-persistent resources, this L1/L2 control channel assignment is Overriding the persistent resource allocation for the interval, the user equipment just obeys the dynamic grant. If the user equipment does not find a dynamic grant, it will transmit/receive according to the semi-persistent resource allocation.

Configuration of semi-persistent scheduling is done by RRC signaling. For example, the periodicity of the persistent allocation, e.g. PS_PERIOD, is signaled within Radio Resource Control (RRC) signaling. Activation and precise timing of persistent allocation and physical resource and transport format parameters are transmitted via PDCCH signaling. Once semi-persistent scheduling is activated, the user equipment follows the semi-persistent resource allocation per PS_PERIOD according to the SPS activated PDCCH. Essentially, the user equipment stores the content of the SPS activated PDCCH and follows the PDCCH with a signaled periodicity.

A separate identity is introduced to distinguish the dynamic PDCCH from the PDCCH that activates semi-persistent scheduling (also called SPS-activated PDCCH). Basically, the CRC of the SPS activated PDCCH is masked with this additional identifier referred to as SPS C-RNTI in the following. The size of the SPS C-RNTI is also 16 bits, the same as the normal C-RNTI. Furthermore, the SPS C-RNTI is also user equipment specific, ie each user equipment configured for semi-persistent scheduling is assigned a unique SPS C-RNTI.

When the user equipment detects that a semi-persistent resource allocation has been activated by the corresponding SPS activated PDCCH, the user equipment stores the contents of the PDCCH (i.e. the semi-persistent resource allocation) and Apply it every scheduling interval, ie periodicity signaled via RRC. As already mentioned, dynamic assignments, ie assignments signaled on the dynamic PDCCH, are only "one-time assignments". Retransmissions of SPS assignments are also signaled using the SPS C-RNTI. The NDI bit (new data indicator) is used to distinguish SPS activations from SPS retransmissions. SPS activation is indicated by setting the NDI bit to zero. An SPS PDCCH with the NDI bit set to 1 indicates a retransmission for the semi-persistently scheduled initial transmission.

Similar to activating semi-persistent scheduling, the eNodeB can also deactivate semi-persistent scheduling, also referred to as SPS resource release. There are several options for how the semi-persistent scheduling deallocation can be signaled. One option is to use PDCCH signaling with some PDCCH fields set to some predetermined value, i.e. SPS PDCCH indicating zero size resource allocation. Another option is to use MAC control signaling.

Further information is provided below on how the eNB knows if periodic data is sent by the UE and when to somehow set up the SPS configuration.

When a new bearer is established, according to the dedicated bearer activation procedure of Non-Patent Document 5, the MME sends a Bearer Setup Request (EPS Bearer Identity, EPS Bearer QoS). QoS), Session Management Request (S1-TEID) messages to the eNodeB. The eNodeB maps EPS bearer QoS to Radio Bearer QoS. The eNodeB then signals an RRC Connection Reconfiguration (Radio Bearer QoS, Session Management Request, EPS RB Identity) message to the UE.

The EPS bearer QoS profile includes the parameters QCI, ARP, GBR and MBR. Each EPS bearer (GBR and non-GBR) is associated with the following bearer-level QoS parameters:

- QoS Class Identifier (QCI)
- Allocation and Retention Priority (ARP)
QCI is a scalar used as a reference to access node-specific parameters that control bearer-level packet forwarding processing (e.g., scheduling weights, grant thresholds, queue management thresholds, link-layer protocol settings, etc.). and is preset by the operator who owns the access node (e.g. eNodeB). A one-to-one mapping of normalized QCI values to standardized properties is incorporated in [6], as shown in the following table based on that in [6].

As can be seen from the table, a QCI value of 1 corresponds to "conversational audio" or voice over IP (VoIP). When the eNB receives a "Bearer Setup Request" message with a QCI value of 1, the eNB indicates that this bearer is established for VoIP and sets the SPS to allocate periodic resources for the UE to transmit VoIP data. I know it can be applied.

<LTE Device-to-Device (D2D) Proximity Service (ProSe)>
Proximity-based applications and services represent an emerging socio-technical trend. Identified areas include commercial and security-related services of interest to operators and users. The introduction of Proximity Services (ProSe) capabilities in LTE will enable the 3GPP industry to serve this evolving market while also serving the urgent needs of several security communities that are jointly committed to LTE.

Device-to-device (D2D) communication is a technology component introduced by LTE Release 12 that enables D2D as an underlay to cellular networks to increase spectral efficiency. For example, if the cellular network is LTE, all physical channels carrying data use SC-FDMA for D2D signaling. In D2D communication, user equipments transmit data signals to each other over direct links using cellular resources instead of going through radio base stations. Throughout the present invention, the terms "D2D", "ProSe" and "sidelink" are interchangeable.

D2D communication in LTE focuses on two areas: Discovery and Communication.

ProSe (Proximity-based Service) Direct Discovery allows ProSe-enabled UEs to discover other ProSe-enabled UEs using E-UTRA direct radio signals over the PC5 interface. Defined as a procedure used for nearby discovery.

In D2D communication, UEs transmit data signals to each other over a direct link using cellular resources instead of going through a base station (BS). D2D users communicate directly while under the control of the BS, ie at least when within the coverage of the eNB. Therefore, D2D can improve system performance by reusing cellular resources.

D2D is envisioned to operate in the uplink LTE spectrum (for FDD) or uplink subframes (other than out-of-coverage for TDD) of the cell providing coverage. Furthermore, D2D transmission/reception does not use full duplex on a given carrier. From an individual UE's point of view, a given carrier D2D signal reception and LTE uplink transmission does not use full duplex, i.e. D2D signal reception and LTE UL transmission are not possible at the same time.

In D2D communication, when one particular UE1 takes on the role of transmission (transmitting user equipment or transmitting terminal), UE1 transmits data and another UE2 (receiving user equipment) receives it. UE1 and UE2 can exchange their transmission and reception roles. A transmission from UE1 may be received by one or more UEs, such as UE2.

<ProSe Direct Communication Layer 2 Link>
Briefly, ProSe direct point-to-point communication is achieved by establishing a secure Layer 2 link over PC5 between two UEs. Each UE has a unicast, contained within the Source Layer 2 ID field of every frame that the UE transmits on the Layer 2 link and within the Destination Layer 2 ID field of every frame that the UE receives on the Layer 2 link. It has a Layer 2 ID for communication. The UE needs to ensure that Layer 2 IDs for unicast communications are at least locally unique. As such, UEs should be prepared to handle Layer 2 ID collisions with neighboring UEs using unspecified mechanisms (e.g. self-assign a new Layer 2 ID). A layer 2 link for ProSe direct communication one-to-one is identified by a combination of the layer 2 IDs of the two UEs. This means that a UE can engage in multiple Layer 2 links for ProSe direct communication one-to-one using the same Layer 2 ID.

ProSe direct communication one-to-one is described in detail in Section 7.1.2 of Non-Patent Document 7, current version v13.0.0, which is incorporated herein by reference, as follows: Consists of procedures.
• Establishment of a secure Layer 2 link via PC5.
• IP address/prefix allocation.
- Maintenance of layer 2 link via PC5.
• Release of layer 2 link via PC5.

FIG. 3 shows a method of establishing a secure Layer 2 link over the PC5 interface.

1. UE-1 sends a Direct Communication Request message to UE-2 to trigger mutual authentication. The link initiator (UE-1) needs to know the Layer 2 ID of the peer (UE-2) in order to perform step 1. As an example, a link initiator may learn the Layer 2 IDs of peers by first performing a discovery procedure or by participating in a ProSe one-to-many communication involving peers.

2. UE-2 initiates a procedure for mutual authentication. Successful completion of the authentication procedure completes the establishment of a secure Layer 2 link via PC5.

UEs engaged in isolated (non-relayed) point-to-point communication may also use link-local addresses. The PC5 Signaling Protocol supports a keep-alive function used to detect when the UE is not within ProSe coverage so that the UE can proceed with an implicit Layer 2 link release. and Layer 2 link release via PC5 can be done by 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 will respond with a Disconnect Response message and delete all context data associated with the layer 2 link.

<ProSe direct communication related identification information>
The current version 13.2.0 of Non-Patent Document 8 defines the following identification information to be used for ProSe direct communication in Section 8.3.
• SL-RNTI: A unique identification used for ProSe direct communication scheduling.
• Source Layer-2 ID: Identifies the sender of the data in the sidelink ProSe direct communication. The Originator Layer 2 ID is 24 bits long and is used together with the ProSe Layer 2 Destination ID and LCID for identification of the RLC UM and PDCP entities at the receiver.
• Destination Layer-2 ID: Identifies the target of the data in the sidelink ProSe direct communication. The Destination Layer 2 ID is 24 bits long and is split into two bit strings at the MAC layer.
• One bit string is the LSB part (8 bits) of the destination Layer 2 ID and is transferred to the physical layer as the Sidelink Control Layer-1 ID. It identifies the intended data target in Sidelink Control and is used to filter packets at the physical layer.
• The second bit string is the MSB part (16 bits) of the destination Layer 2 ID, carried in the MAC header. It is used to filter packets at the MAC layer.

No access stratum signaling is required for group formation and to set the source layer 2 ID, destination layer 2 ID and sidelink control L1 ID in the UE. These identities are either provided by higher layers or are derived from identities provided by higher layers. For groupcasts and broadcasts, the ProSe UE ID provided by the higher layers is used directly as the source Layer 2 ID, and the ProSe Layer 2 Group ID provided by the higher layers is passed to the destination layer at the MAC layer. 2 Used directly as ID. For one-to-one communication, the higher layers provide the source Layer 2 ID and the destination Layer 2 ID.

<Radio Resource Allocation for Proximity Service>
From the perspective of the transmitting UE, a proximity service capable UE (ProSe capable UE) can operate in two modes for resource allocation.

Mode 1 refers to eNB-scheduled resource allocation, where the UE requests transmission resources from the eNB (or Release 10 relay node) and the eNodeB (or Release 10 relay node) then sends direct data and direct control information. schedule the resources used by the UE to transmit the (eg, Scheduling Assignment). The UE needs to be RRC_CONNECTED to send data. Specifically, the UE sends a Scheduling Request (D-SR or Random Access) to the eNB, followed in the usual way by a Buffer Status Report (BSR) (see section “D2D (See also Transmission Procedures for 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.

Mode 2, on the other hand, refers to UE autonomous resource selection, where the UE itself selects resources (time and frequency) from the resource pool to transmit direct data and direct control information (ie SA). One resource pool is defined for example by the content of SIB18, i.e. by the field commTxPoolNormalCommon, this particular resource pool is broadcast in the cell and then commonly used for all UEs in the cell still in RRC_Idle state. It is possible. In practice, an eNB may define up to four different instances of said pools, ie four resource pools for SA messages and direct data transmission respectively. However, in Release 12, the UE shall always use the first resource pool defined in the list, even if multiple resource pools are configured. This constraint is removed for Release 13, ie a UE can transmit on multiple configured resource pools within one SC period. How the UE selects resource pools for transmission is further outlined below (further specified in 3GPP TS 36.321 [2]).

Alternatively, another resource pool can be defined by the eNB and signaled in SIB18, ie by using the field commTxPoolExceptional, which can be used by the UE in exceptional cases.

Which resource allocation mode the UE will use is configurable by the eNB. Furthermore, which resource allocation mode the UE will use for D2D data communication depends on the RRC state, i.e. RRC_IDLE or RRC_CONNECTED, and the UE's coverage state, i.e. in-coverage or out-of-coverage. can also depend on A UE is considered in-coverage if it has a serving cell (ie the UE is RRC_CONNECTED or is camping on a cell in RRC_IDLE state).

The following rules apply to the UE with respect to resource allocation mode.
• If the UE is out of coverage, the UE can only use mode 2.
• If the UE is in coverage, the UE may use Mode 1 if the eNB configures the UE accordingly.
• If the UE is in coverage, the UE may use mode 2 if the eNB configures the UE accordingly.
• When no exceptional conditions exist, the UE may change from Mode 1 to Mode 2 and vice versa only if configured to do so by the eNB. When the UE is in-coverage, the UE shall only use the mode indicated by the eNB configuration unless one of the exceptional cases occurs.
• The UE considers itself to be in an exceptional condition, eg while T311 or T301 is running.
• When exceptional cases occur, the UE is temporarily allowed to use Mode 2 even if it is configured to use Mode 1.

While in the coverage area of an E-UTRA cell, the UE uses the resources allocated by that cell, even if the resources of that carrier are pre-configured, for example in the UICC (Universal Integrated Circuit Card). ProSe direct communication transmission shall be performed on the UL carrier only in

For UEs in RRC_IDLE state, the eNB may choose one of the following options.
- The eNB may provide a Mode 2 transmission resource pool in the SIB. UEs that are authorized for ProSe Direct Communication use these resources for ProSe Direct Communication in RRC_IDLE state.
- The eNB may indicate in the SIB that it supports D2D but does not provide resources for ProSe direct communication. The UE needs to enter RRC_CONNECTED state to perform ProSe direct communication transmission.

For UEs in RRC_CONNECTED state:
• A UE in RRC_CONNECTED that is authorized to perform a ProSe direct communication transmission indicates to the eNB that it wishes to perform a ProSe direct communication transmission when it needs to perform a ProSe direct communication transmission.
• The eNB checks if the UE in RRC_CONNECTED state is authorized for ProSe direct communication transmission using the UE context received from the MME.
• The eNB may configure a UE in RRC_CONNECTED state with a mode 2 resource allocation transmission resource pool that can be used without restriction while the UE is in RRC_CONNECTED state by dedicated signaling. Alternatively, the eNB allows a UE in the RRC_CONNECTED state to use Mode 2 resource allocation transmission resources by means of dedicated signaling, where the UE is allowed to use it only in exceptional cases and otherwise rely on Mode 1. Can be set in pool.

The resource pool for scheduling assignments when the UE is out of coverage can be configured as follows.
• The resource pool used for reception is preconfigured.
• The resource pool used for transmission is pre-configured.

The resource pool for scheduling assignments when the UE is in coverage can be configured as follows.
- The resource pool used for reception is configured by the eNB in dedicated or broadcast signaling via RRC.
• If Mode 2 resource allocation is used, the resource pool used for transmission is configured by the eNB via RRC.
If Mode 1 resource allocation is used, the SCI (Sidelink Control Information) resource pool (also called scheduling assignment (SA) resource pool) used for transmission is known to the UE. can't
• If Mode 1 resource allocation is used, the eNB schedules specific resources to use for sidelink control information (scheduling allocation) transmission. The specific resources allocated by the eNB are within the resource pool for the reception of SCI provided to the UE.

FIG. 4 shows transmission/reception resource usage for overlay (LTE) and underlay (D2D) systems.

Basically, the eNodeB controls whether the UE may apply Mode 1 or Mode 2 transmission. Once a UE knows its resources on which it can transmit (or receive) D2D communications, the UE uses the corresponding resources only for corresponding transmission/reception. For example, in FIG. 4, the D2D subframes are used only to receive or transmit D2D signals. A UE, as a D2D device, operates in half-duplex mode and can therefore either transmit or receive a D2D signal at any point in time. Similarly, another subframe shown in FIG. 4 may be used for LTE (overlay) transmission and/or reception.

<Transmission procedure for D2D communication>
The D2D data communication procedure differs depending on the resource allocation mode. As described above, for Mode 1, the eNB explicitly schedules scheduling assignments and resources for D2D data communication after a corresponding request from the UE. Specifically, the UE may be notified by the eNB that D2D communication is basically allowed but no Mode 2 resources (i.e. resource pool) are provided, which is e.g. (D2D Communication Interest Indication) and the corresponding response D2D Communication Response, where the information element of the corresponding exemplary ProseCommConfig does not include commTxPoolNormalCommon, i.e. includes sending A UE wishing to initiate direct communication must request a resource allocation from the E-UTRAN for each individual transmission. Thus, in such cases, the UE has to request resources for each individual transmission, and the following exemplarily enumerates the different steps of the request/grant procedure for this Mode 1 resource allocation.
- Step 1: UE transmits SR (Scheduling Request: Scheduling Request) to eNB via PUCCH.
Step 2: eNB grants UL resources (for UE to transmit BSR) over PDCCH, scrambling with C-RNTI.
- Step 3: UE sends D2D BSR over PUSCH indicating buffer status.
Step 4: eNB grants D2D resources (for UE to send data) over PDCCH, scrambling with D2D-RNTI.
Step 5: The D2D transmitting UE transmits SA/D2D data according to the grant received in step 4.

Scheduling Assignment (SA), also referred to as SCI (Sidelink Control Information), contains control information, such as pointers to time-frequency resources for the corresponding D2D data transmission, modulation and coding schemes, and It is a compact (low payload) message containing a Group Destination ID. SCI carries sidelink scheduling information for one (ProSe) destination ID. The content of SA (SCI) basically follows the grant received in step 4 above. The contents of the D2D grant and SA are defined in section 5.4.3 of the current version 13.0.0 of Non-Patent Document 4, which is incorporated herein by reference, and specifies SCI format 0. (see content of SCI format 0 above).

On the other hand, for Mode 2 resource allocation, the above steps 1-4 are basically unnecessary, and the UE autonomously selects resources for SA and D2D data transmission from the transmission resource pool configured and provided by the eNB. choose purposefully.

FIG. 5 exemplarily shows scheduling assignments and transmission of D2D data for two UEs, UE-1 and UE-2, where resources for transmitting scheduling assignments are periodic and D2D data transmission The resources used for are indicated by corresponding scheduling assignments.

FIG. 6 shows D2D communication timing for mode 2, autonomous scheduling, for one SA/data period, also known as SC period or sidelink control period. FIG. 7 shows the D2D communication timing for Mode 1, eNB-scheduled allocation, for one SA/data period. An SC period is a period consisting of a scheduling assignment and the corresponding transmission of data. As can be seen from FIG. 6, the UE transmits the scheduling assignment using the transmission pool resource SA_Mode2_Tx_pool for scheduling assignment for mode 2 after the SA offset time. The first transmission of SA is followed by eg three retransmissions of the same SA message. The UE then sends the D2D data transmission, or more specifically the T-RPT bitmap/pattern, at some configured offset (Mode2data_offset) after the first subframe of the SA resource pool (given by SA_offset). to start. One D2D data transmission of a MAC PDU (ie transport block) consists of its first initial transmission and several retransmissions. For the illustration of FIG. 6 (and of FIG. 7), it is assumed that three transmissions (ie, second, third and fourth transmissions of the same MAC PDU) are performed. The Mode 2 T-RPT bitmap (time resource pattern of transmission, T-RPT) is basically a MAC PDU transmission (1st transmission) and its retransmissions (2nd, 3rd and 4th second transmission) timing. The SA pattern basically defines the timing of the initial transmission of the SA and its retransmissions (2nd, 3rd and 4th transmissions).

For one sidelink grant, e.g. either sent by the eNB or selected by the UE itself, as currently specified in the standard, the UE sends multiple transport blocks, MAC PDUs. (only once per subframe (TTI), ie in sequence), but only for one ProSe destination group. Also, the retransmission of one transport block must finish before the first transmission of the next transport block begins, i.e. for multiple transport block transmissions, per sidelink grant Only one HARQ process is used. Furthermore, a UE can have and use several sidelink grants per SC period, but a different ProSe destination should be selected for each of the sidelink grants. Thus, in one SC period, the UE can transmit data to one ProSe destination only once.

As evident from FIG. 7, for the resource allocation mode (mode 1) scheduled by the eNB, the D2D data transmission, or more specifically the T-RPT pattern/bitmap, is the last SA in the SA resource pool. It starts in the next UL subframe after the transmission repetition. As already explained with respect to FIG. 6, the Mode 1 T-RPT bitmap (time resource pattern of transmission, T-RPT) is basically a MAC PDU transmission (first transmission) and its retransmission. Define the timing of the transmissions (2nd, 3rd and 4th transmissions).

The sidelink data transmission procedure is described in Non-Patent Document 2, v13.0.0, Section 5.14, which is incorporated herein by reference. Mode 2 autonomous resource selection is detailed therein, distinguishing between configurations with a single radio resource pool and configurations with multiple radio resource pools. The following steps are taken from the above section of [2], assuming Mode 2 autonomous resource selection.

In order to transmit on SL-SCH (sidelink shared channel), a MAC entity must have at least one sidelink grant. Sidelink grants are selected as follows:

A MAC entity is configured by higher layers to transmit using one or more pools of resources such that more data than can be transmitted in the current SC period is sent to the STCH (sidelink traffic channel: sidelink traffic channel), for each sidelink grant to be selected, the MAC entity shall:
If configured by a higher layer to use a single, pool of resources:
- Select the pool of resources in question for use.
If otherwise configured by a higher layer to use multiple, pools of resources:
- a pool of resources from a pool of resources set by a higher layer whose associated priority list contains the highest priority of the sidelink logical channels in the MAC PDU to be transmitted; choose to use.

Note: If more than one pool of resources has an associated priority list containing the priority of the sidelink logical channel with the highest priority in the MAC PDU to be transmitted, these pools of resources Which one to choose is left to the UE implementation.
• Randomly select time and frequency resources for SCI of SL-SCH and sidelink grant from the selected resource pool. A random function should be able to choose each of the allowed choices with equal probability.
- Selected to determine the set of subframes in which the transmission of the SCI and the transmission of the first transport block occurs according to Section 14.2.1 of Non-Patent Document 3, which is incorporated herein by reference. Use sidelink grants (this step refers to the selection of T-RPT and SA patterns, as described in connection with FIG. 7).
a configured sidelink grant that occurs within a subframe starting at the beginning of the first available SC period beginning at least four subframes after the subframe in which the sidelink grant was selected; consider
• clear the configured sidelink grants at the end of the corresponding SC period;

Note: Retransmissions on SL-SCH cannot occur after the configured sidelink grant has been cleared.

Note: If the MAC entity is configured by higher layers to transmit using one or more pools of resources, how many in one SC period, considering the number of sidelink processes It is up to the UE implementation to select the sidelink grant.

The MAC entity shall: for each subframe:

- if the MAC entity has a configured sidelink grant that occurs within this subframe - if the configured sidelink grant corresponds to the transmission of the SCI - to the physical layer, the configured sidelink Command to send the SCI corresponding to the grant.
- otherwise, if the configured sidelink grant corresponds to the transmission of the first transport block,
- Deliver the configured sidelink grant and associated HARQ information to the sidelink HARQ entity for this subframe.

Note: If a MAC entity has multiple configured grants that occur within one subframe, and due to single cluster SC-FDM limitations, it can handle all of them If not, it is up to the UE implementation which one of them to process according to the above procedure.

The above sentence, taken from 3GPP technical standards, can be further clarified. For example, the step of randomly selecting time and frequency resources is random with respect to which particular time/frequency resources are selected, but not, e.g., with respect to the total amount of time/frequency resources selected. do not have. The amount of resources selected from the resource pool depends on the amount of data to be transmitted on the sidelink to be selected autonomously. The amount of data to be sent then depends on the previous step of selecting a ProSe destination group and the corresponding amount of data ready to be sent to said ProSe destination group. A ProSe destination is first selected, as described later in the sidelink LCP procedure.

Furthermore, as evident from Section 5.14.1.2.2 of v13.0.0 of Non-Patent Document 2, which is incorporated herein by reference, the sidelink associated with the sidelink HARQ entity The process is responsible for instructing the physical layer to generate and execute transmissions accordingly. Briefly, after determining the sidelink grant and the sidelink data to be transmitted, the physical layer takes care of the actual transmission of the sidelink data based on the sidelink grant and the required transmission parameters. pay.

Discussed above is the current state of the 3GPP standards for D2D communication. However, it should be noted that there are ongoing discussions on how to further improve and extend D2D communication, which is likely to result in some changes being introduced to D2D communication in future releases. The invention is intended to be applicable to these later releases as well, as described below.

<ProSe Network Architecture and ProSe Entities>
FIG. 8 shows a high-level exemplary architecture for the non-roaming case, including different ProSe applications in respective UEs A and B, and ProSe application servers and ProSe functions in the network. The example architecture of FIG. 8 is described in Non-Patent Document 9, v. Taken from 13.2.0, chapter 4.2 "Architectural Reference Model".

Functional entities are presented and described in detail in Section 4.4, "Functional Entities," of Non-Patent Document 9, which is incorporated herein by reference. A ProSe Function is a logical function used for network-related operations required for ProSe and plays a different role for each of ProSe's features. The ProSe function is part of 3GPP's EPC and provides all relevant network services such as authorization, authentication, data manipulation, etc. related to proximity services. For ProSe direct discovery and communication, the UE may obtain specific ProSe UE identification information, other configuration information, and authorization from the ProSe function through the PC3 reference point. A single ProSe function is presented for ease of illustration, although multiple ProSe functions can be deployed in a network. The ProSe function has three main sub-functions that perform different roles depending on the characteristics of the ProSe: Direct Provision Function (DPF), Direct Discovery Name Management Function (DPF) and EPC level. It consists of a discovery function (EPC-level Discovery Function). DPF is used to supply the UE with the necessary parameters to use ProSe Direct Discovery and ProSe Direct Communication.

The term "UE" used in the above context refers to a ProSe capable UE that supports, for example, the following ProSe functionality.
• Exchange of ProSe control information between ProSe capable UEs and ProSe functions through the PC3 reference point.
• A procedure for open ProSe direct discovery of other ProSe capable UEs through the PC5 reference point.
• Procedures for direct one-to-many ProSe communication through the PC5 reference point.
• Procedures for operating as a ProSe UE-to-Network Relay. The Remote UE communicates with the ProSe UE-Network Repeater through the PC5 reference point. The ProSe UE-Network Repeater uses Layer 3 packet forwarding.
• Exchanging control information between ProSe UEs through the PC5 reference point, eg for UE-network repeater detection and ProSe direct discovery.
• Exchange of ProSe control information between another ProSe capable UE and the ProSe function through the PC3 reference point. In the ProSe UE-Network Relay case, the remote UE sends this control information through the PC5 user plane to be relayed towards the ProSe functionality over the LTE-Uu interface.
• Setting parameters (including, for example, IP address, ProSe Layer 2 Group ID, Group security material, radio resource parameters). These parameters can be preconfigured at the UE or provided to the ProSe function in the network by signaling through the PC3 reference point when in coverage.

The ProSe Application Server supports EPC ProSe User ID and ProSe Function ID storage and Application Layer User ID and EPC ProSe User ID mapping. A ProSe Application Server (AS) is an entity outside the scope of 3GPP. ProSe applications in the UE communicate 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.

<Vehicle communication - V2X service>
New considerations have been defined in 3GPP to consider the utility of new LTE features to the automotive industry, including proximity services (ProSE) and LTE-based broadcast services. As such, the ProSe functionality is seen as providing a good foundation for V2X services. Connected vehicle technology aims to address some of the biggest challenges in the ground transportation industry, including safety, mobility and traffic efficiency.

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

LTE support for V2X services includes three different types of use cases:
V2V (Vehicle-to-Vehicle): Covers LTE-based communication between vehicles.
Vehicle-to-Pedestrian (V2P): Covers LTE-based communication between vehicles and devices carried by individuals (eg handheld terminals carried by pedestrians, cyclists, drivers or passengers).
V2I (Vehicle-to-Infrastructure): Covers LTE-based communication between vehicles and roadside units.

These three types of V2X can use "collaborative awareness" to provide more intelligent services to end-users. It enables transport entities such as vehicles, roadside infrastructure, and pedestrians to gather knowledge of their local environment (e.g., information received from other vehicles or sensor devices in the vicinity) to facilitate coordinated collisions. That knowledge can be processed and shared to provide more intelligent services such as alerts or autonomous driving.

For V2V communication, E-UTRAN allows UEs in close proximity to each other to exchange V2V related information using E-UTRA(N) when authorization, admission and locality criteria are met. to enable. The proximity criteria can be set by an MNO (Mobile Network Operator). However, UEs supporting V2V services may exchange such information when served or not served by an E-UTRAN supporting V2X services.

A UE that supports V2V applications transmits application layer information (eg, its location, dynamics and attributes as part of the V2V service). The V2V payload should be flexible to accommodate different information content, and the information can be transmitted periodically according to the settings provided by the MNO.

V2V is primarily broadcast-based and V2V does not allow direct exchange of V2V-related application information between separate UEs and/or between separate UEs due to the limited direct communication range of V2V. exchange of V2V-related application information via the infrastructure supporting V2X services, such as RSUs, application servers, etc.

For V2I communication, a UE supporting V2I applications sends application layer information to a roadside unit, which in turn sends application layer information to a group or UEs supporting V2I applications. can do.

V2N (Vehicle-to-Network, eNB/CN) has also been introduced, where one communicating entity is the UE and the other communicating entity is the serving entity, both supporting V2N applications and communicating with each other over the LTE network.

For V2P communication, E-UTRAN enables UEs in close proximity to each other to exchange V2P-related information using E-UTRAN when authorization, admission and locality criteria are met. . Locality criteria can be set by the MNO. However, UEs supporting V2P services can exchange such information even when not served by an E-UTRAN supporting V2X services.

UEs supporting V2P applications transmit application layer information. Such information may be provided by vehicles with UEs supporting V2X services (e.g., pedestrian warnings) and/or by pedestrians with UEs supporting V2X services (e.g., vehicle warnings). can be broadcast.

V2P requires direct exchange of V2P-related application information between separate UEs (one for vehicles and the other for pedestrians) and/or the direct communication range of V2P is limited. exchange of V2P-related application information between UEs of the same type via infrastructure supporting V2X services, such as RSUs, application servers, etc.

For this new study item V2X, 3GPP has provided specific terminology and definitions in the current version 13.0.0 of Non-Patent Document 10, which can be reused for this application.

Road Side Unit (RSU): An entity that supports V2I services that can transmit to and receive from UEs using V2I applications. RSU can be implemented in an eNB or a stationary UE.
V2I service: A type of V2X service, one communicating entity is the UE and the other communicating entity is the RSU, both using V2I applications.
V2N service: A type of V2X service where one communicating entity is the UE and the other communicating entity is the serving entity, both using V2N applications and communicating with each other via the LTE network entity.
V2P service: A type of V2X service where both parties of the communication are UEs using V2P applications.
V2V service: A type of V2X service where both parties of the communication are UEs using V2V applications.

V2X service: A type of communication service involving transmitting or receiving UEs using V2V applications over 3GPP transport. V2X services can be further divided into V2V services, V2I services, V2P services, and V2N services based on the other communicating parties involved in the communication.

Different types of messages have been and will be defined for V2V communication. For Intelligent Transport Systems (ITS), two different types of messages have already been defined by ETSI, the corresponding European standards v1.3.1 of Non-Patent Document 11 and Non-Patent See reference 12, v1.2.1.

• Cooperative Awareness Message (CAM): continuously triggered by vehicle dynamics to reflect vehicle state.
• Decentralized Environmental Notification Message (DENM): Triggered only when a vehicle-related safety-relevant event occurs.

V2V standardization and ITS standardization are rather in the beginning and it is expected that other messages may be defined in the future.

Since the CAM is continuously broadcast by the ITS-S to exchange status information with other ITS Stations (ITS-S), it has a greater impact on traffic load than event-triggered DENM messages. . For this reason, the traffic characteristics of CAM messages defined by ETSI for ITS are considered more representative of V2V traffic.

Cooperative Awareness Messages (CAMs) are messages exchanged between ITS-Ss in an ITS network to create and maintain awareness of each other and to support cooperative operation of vehicles using the road network. Point-to-multipoint communication shall be used to transmit the CAM from the originating ITS-S to the receiving ITS-S located within direct communication range of the originating ITS-S. . CAM generation shall be triggered and managed by the Collaborative Recognition Basic Service, which defines the time interval between two consecutive CAM messages. Currently, the upper and lower bounds on the transmission interval are 100ms (ie CAM generation rate 10Hz) and 1000ms (ie CAM generation rate 1Hz). The underlying principle of ETSI ITS is to send the CAM when there is new information to share (eg new position, new acceleration or new heading value). Correspondingly, when the vehicle is moving slowly and at a constant heading and speed, a high CAM generation rate provides no real benefit and the CAM displays minimal difference. A vehicle's CAM transmission frequency varies from 1 Hz to 10 Hz as a function of vehicle dynamics (eg, speed, acceleration, and heading). For example, the slower the vehicle drives, the fewer CAMs are triggered and transmitted. Vehicle speed is a major influencing factor for CAM traffic generation.

Trigger conditions for CAM generation are currently defined in Section 6.1.3 of v1.3.1 of Non-Patent Document 11 and are shown below.

1) The elapsed time since the last CAM generation provides the minimum time interval between two consecutive CAM generations to reduce CAM generation according to the channel usage requirements of T_GenCam_Dcc (decentralized congestion control (DCC)) parameter), given one of the following ITS-S dynamics related conditions:
• The absolute value of the difference between the current heading of the originating ITS-S and the heading included in the CAM previously transmitted by the originating ITS-S exceeds 4°.
- The distance between the current position of the originating ITS-S and the position contained in the CAM previously transmitted by the originating ITS-S exceeds 4m.
• The absolute value of the difference between the current velocity of the originating ITS-S and the velocity contained in the CAM previously transmitted by the originating ITS-S exceeds 0.5 m/s.

2) Elapsed time since last CAM generation is equal to or greater than T_GenCam and equal to or greater than T_GenCam_Dcc. The parameter T_GenCam represents the currently valid upper bound for the CAM generation interval.

If one of the above two conditions is met, the CAM shall be generated immediately.

The CAM contains state and attribute information of the originating ITS-S. The content of the CAM varies depending on the type of ITS-S, as explained in more detail below. For vehicle ITS-S, status information may include time, location, state of motion, activated systems, etc., and attribute information may include data on dimensions, vehicle type, and role in road traffic. Upon receiving the CAM, the receiving ITS-S becomes aware of the existence, type and status of the originating ITS-S. The received information can be used by the receiving ITS-S to support some ITS applications. For example, by comparing the status of the originating ITS-S with its own status, the receiving ITS-S assesses the risk of collision with the originating ITS-S and, if necessary, the HMI (Human Machine Interface) ) to inform the driver. As detailed in Section 7 of v1.3.1 of Non-Patent Document 11, which is incorporated herein by reference, a CAM consists of a common ITS PDU header and multiple containers. , together they form the CAM. The ITS PDU header is a common header containing information about the protocol version, message type, and ITS-S ID of the originating ITS-S. For vehicle ITS-S, the CAM shall contain one basic container and one high frequency container, and may also contain one low frequency container and one or more other special containers. The basic container contains basic information related to the originating ITS-S. The high frequency container contains highly dynamic information of the outgoing ITS-S. The low frequency container contains static information of the originating ITS-S and highly non-dynamic information. The special vehicle container contains information specific to the vehicle role of the originating vehicle ITS-S. A general configuration of a CAM is shown in FIG.

The table below provides an overview and packet sizes for the different components of V2V message data.

Vehicle ITS-S generates a CAM which shall contain at least one frequent vehicle container and optionally a low frequency vehicle container. Vehicles ITS-S that have a specific role in road traffic, such as public transport, shall provide status information within a special vehicle container.

Each V2V message exchanged between vehicles must meet security requirements, including anonymity and integrity protection. Different security schemes can have different security performance and overhead levels, which are directly related to packet size (due to security overhead) and message frequency (e.g., how often security certificates are attached). Affect.

Both ETIS ITS and IEEE 1609.2 consider a public key infrastructure (PKI) based security solution for V2X communication and are asymmetric based application layer security solutions. Normally, every V2X message needs to carry a signature and either a certificate or a digest of a certificate to achieve anonymity and integrity protection. Typical sizes for signatures, digests, and certificates are 64 bytes, 8 bytes, and 117 bytes, respectively.

As explained above, CAM messages may have different periodicities and/or different message sizes. Furthermore, the periodicity may even change over time depending on speed and other (less influential) factors such as heading or angle. To provide an overview, identify the different possible message components (HF, LF, certificate) and the resulting periodicities and message sizes according to three different typical rate ranges; We provide the table below.

As can be seen from the table above, the size of the components, and thus the size of the CAM, remain the same, but their generation/transmission frequency varies for different speed ranges. For the table above, the CAM HF component is assumed to be sent along with the signature and digest, resulting in a message size of approximately 122 bytes (i.e. 8 bytes for the header, 18 bytes for the basic container, enough to transmit 23 bytes for the frequent container, 64 bytes for the signature, and 8 bytes for the digest). The CAM LF component is piggybacked to the high frequency component and has an additional size of almost 60 bytes, so the resulting CAM size with all containers/components is 182 bytes. The certificate component (also referred to as the security component) that is piggybacked to the high frequency component has an additional size of approximately 117 bytes, resulting in a resulting CAM size of 299 bytes with all containers/components. bytes, or 239 bytes without the CAM LF container/component.

Figure 10 illustrates the occurrence of three different components in response to the three different rate ranges introduced above, and how this results in different overall message sizes and overall periodicity. indicates whether In FIG. 10, the dashed rectangles contain different components and shall indicate that the components are sent as one CAM message rather than being sent separately.

The above has described the periodic collaborative recognition messages in great detail, and also defined their different contents, inherent periodicity and message size. However, it should be noted that while some of the above information has already been standardized, others such as periodicity and message size have not yet been standardized and are based on assumptions. Furthermore, standardization may change in the future, and thus aspects of how CAMs are generated and transmitted. Furthermore, currently the different components discussed above (CAM HF, CAM LF, certificates) are sent together, i.e. in one message, when they fit together, which means that It doesn't necessarily have to be. In the future, these containers/components may also be sent separately from each other, possibly including headers and possibly base containers in each as well. Consequently, the above detailed description of the CAM should be understood as an example considered for illustrative purposes, although the message sizes and periodicities are realistic and based on simulation results. The above CAM messages and their content, periodicity, and message size are used throughout this application to explain the basic principles of the present invention. Important for the present invention is that V2V communication requires the vehicular UE to transmit different data in a periodic manner, such as (relative) speed, angle, heading and possibly vehicle distance. It can be expected that the periodicity can change quickly as a function of vehicle dynamics, among other factors. Consequently, the challenge is that the vehicular UE should be able to send several periodic packets with different message sizes, with different and varying periodicity.

In order for vehicular UEs to have radio resources on the sidelink to transmit the CAM, mode 1 and/or mode 2 radio resource allocation is envisaged as explained above. For Mode 1 radio resource allocation, the eNB allocates resources for SA messages and data every SA period. However, during high traffic times (eg, frequent periodic traffic), the overhead on the Uu link from the UE to the eNB can be large.

As is clear from the above, 3GPP has agreed that for sidelink V2V communication mode 1 (i.e. eNB scheduled radio resource allocation), sidelink semi-persistent radio resource allocation is supported by eNB and UE. As noted, much V2V traffic is periodic.

However, the currently standardized semi-persistent allocation mechanism needs to be improved and adapted to the requirements and challenges of V2V traffic.

3GPP TS 36.211, "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)" 3GPP TS 36.321 3GPP TS 36.213 3GPP TS 36.212, "Multiplexing and channel coding" 3GPP TS 23.401 3GPP TS 23.203 3GPP TR 23.713 3GPP TS 36.300 3GPP TS 23.303 3GPP TR 21.905 ETSI EN 302 637-2 ETSI EN 302 637-3 3GPP TS 36.331

A non-limiting exemplary embodiment provides an improved resource allocation method for vehicular communications for vehicular mobile terminals.

The independent claims provide non-limiting exemplary embodiments. Advantageous embodiments are according to the dependent claims.

Accordingly, in one general first aspect, the technology disclosed herein features a vehicular mobile terminal for transmitting periodic data to one or more receiving entities. A vehicular mobile terminal supports transmission of periodic data comprising one or more different data components to be transmitted with different possible transmission periodicities and/or different possible message sizes. The transmitting unit of the vehicular mobile terminal transmits information about the periodic data to the radio base station responsible for allocating radio resources to the vehicular mobile terminal. Information about the transmitted periodic data may be used by the radio base station to determine possible different transmission periodicities and/or possible different message sizes of one or more data components of the periodic data. is such that it is possible to determine The receiving unit of the vehicle mobile terminal receives from the radio base station a plurality of semi-persistent radio resource settings set by the radio base station based on the received information about the periodic data. Each of the plurality of semi-persistent radio resource settings are configured to be usable for transmitting at least one of the supported data components. The transmitter then indicates to the radio base station that one or more of the data components should be transmitted by the vehicular mobile terminal. A receiving unit for activating one or more of a plurality of semi-persistent radio resource configurations for periodically allocating radio resources for the vehicular mobile terminal to transmit each of the indicated data components. An activation command is received from the radio base station. The transmitter then transmits one or more data components to one or more receiving entities based on radio resources and transmission periodicity, as configured by the activated one or more semi-persistent radio resource configurations. Send to

Accordingly, in one general first aspect, the technology disclosed herein provides a radio for allocating radio resources to a vehicular mobile terminal for transmitting periodic data to one or more receiving entities. It features a base station. A vehicular mobile terminal supports transmission of periodic data comprising one or more different data components to be transmitted with different possible transmission periodicities and/or different possible message sizes. The receiving part of the radio base station receives information from the mobile mobile terminal for the vehicle regarding periodic data to be transmitted by the mobile mobile terminal for the vehicle to one or more receiving entities. The radio base station processor determines the different data components supported, as well as possible different transmission periodicities and/or different possible message sizes of one or more data components. A processor configures a plurality of semi-persistent radio resource settings based on the determined transmission periodicity and/or the determined message size. Each of the plurality of semi-persistent radio resource settings are configured to be usable for transmitting at least one of the supported data components. The transmission unit of the radio base station transmits information regarding the set plurality of semi-persistent radio resource settings to the vehicle mobile terminal. The receiving unit receives an indication from the mobile vehicular terminal that one or more of the data components should be transmitted by the mobile vehicular terminal. The processor then selects a plurality of semi-persistent data components to be activated for the vehicular mobile terminal to periodically allocate radio resources for the vehicular mobile terminal to transmit each of the indicated data components. Select one or more of the radio resource settings. The transmitting unit is further configured to transmit an activation command to the vehicular mobile terminal to activate the selected one or more semi-persistent radio resource settings for the vehicular mobile terminal.

Further benefits and advantages of the disclosed embodiments will be apparent from the specification and drawings. These benefits and/or advantages may be individually provided by various embodiments and features of the disclosure herein, and all are provided to obtain one or more of these benefits and/or advantages. you don't have to.

These general and specific aspects may be implemented using systems, methods and computer programs, and any combination of systems, methods and computer programs.

Exemplary embodiments are described in more detail below with reference to the accompanying figures and drawings.

1 shows an exemplary architecture of a 3GPP LTE system; 3 shows an exemplary downlink resource grid for downlink slots of subframes defined in 3GPP LTE (Release 8/9). Fig. 4 schematically shows how to establish a layer 2 link through PC 5 for ProSe communication. Fig. 3 shows transmission/reception resource usage for overlay (LTE) and underlay (D2D) systems; 4 shows scheduling assignments and transmission of D2D data for two UEs. Figure 3 shows D2D communication timing for UE autonomous scheduling mode 2; Fig. 3 shows D2D communication timing for scheduling mode 1 scheduled by an eNB; Fig. 3 shows an exemplary architectural model for ProSe for non-roaming scenarios; 4 shows an exemplary structure of a CAM message; It shows the transmission of several different CAM components with varying periodicities and message sizes for three different speed ranges. Fig. 3 shows the transmission of three different CAM components and the use of three SPS settings for the transmission of the CAM, according to an exemplary implementation of the first embodiment; It also shows the transmission of three different CAM components and the use of three SPS settings for the transmission of the CAM, according to a further exemplary implementation of the first embodiment, here assigned by the SPS settings. radio resources are tied together. It also shows the transmission of three different CAM components and the use of three SPS settings for the transmission of the CAM, according to a further exemplary implementation of the first embodiment, where the corresponding SPS settings The allocated radio resources are sufficient to transmit a complete CAM message. 3 also shows the transmission of three different CAM components and the use of nine different SPS settings for the transmission of the CAM, according to a further exemplary implementation of the first embodiment, wherein the vehicular UE has three It is intended to support different speed ranges. 3 also shows the transmission of 3 different CAM components and the use of 10 different SPS settings for the transmission of the CAM, according to a further exemplary implementation of the first embodiment; It is intended to support two different speed ranges.

A “mobile station” or “mobile node” or “user terminal” or “user equipment” is a physical entity within a communication network. One node may have several functional entities. A functional entity refers to a software or hardware module that implements and/or provides a given set of functions to another functional entity of a node or network. A node may have one or more interfaces that attach the node to a communication device or medium through which the node can communicate. Similarly, a network entity may have a logical interface that attaches the functional entity to a communication device or medium through which the network entity may communicate with another functional entity or correspondent node.

The term "radio resource" as used in the set of claims and this application should be broadly understood to refer to physical radio resources, such as time-frequency resources.

The term “direct communication transmission” as used in the present application should be broadly understood as a transmission between two user equipments directly, ie without going through a radio base station (eg eNB). Accordingly, direct communication transmissions are carried out over a “direct sidelink connection”, a term used to refer to a connection established directly between two user equipments. For example, in 3GPP, the terminology Device-to-Device (D2D) communication is used, or ProSe communication, or sidelink communication. The term "direct sidelink connection" should be broadly understood as the PC5 interface mentioned in the background section and can be understood in the context of 3GPP.

As used herein, the term "ProSe" or its abbreviated form "Proximity Services" refers to proximity-based applications in LTE systems, as illustratively described in the background section. and in the context of Services. Other terminology such as "D2D" is also used in this context to refer to Device-to-Device communication for proximity services.

The term "vehicle mobile terminal" as used throughout this application should be understood in the context of the new 3GPP study item V2X (vehicular communication), as explained in the background art section. Accordingly, the vehicular mobile terminal performs vehicular communication, i.e. communicating information related to the vehicle to other entities (vehicles, infrastructure, pedestrians, etc.), for example for safety or driver assistance purposes. To do so, it shall be understood broadly as a mobile terminal specifically mounted in a vehicle (eg, passenger car, commercial truck, motorcycle, etc.). Optionally, the vehicle mobile terminal may have access to information available in the navigation system (provided that it is also installed in the vehicle), such as map information.

As described in the Background section, 3GPP has introduced new considerations for LTE-assisted vehicular communications, which include various vehicular mobile terminals and other stations. It is based on ProSe procedures for exchanging V2V traffic between Furthermore, semi-persistent radio resource allocation shall be supported by V2V traffic for mode 1 sidelink allocation so as to reduce the amount of scheduling performed by the eNB. However, current SPS mechanisms are not adapted to V2V traffic and its characteristics. For example, for normal semi-persistent scheduling on the Uu link (ie between eNB and UE), eNB receives QCI information (QoS class identifier) from MME (Mobility Management Entity). The QCI information indicates that a particular bearer configured between the eNB and the UE is configured to carry VoIP traffic, so that the eNB receives periodic traffic generated by the UE on that bearer. to learn about The eNB may then configure semi-persistent radio resource allocation for the UE by sending RRC signaling to the UE to configure the SPS periodicity. Then, when the UE actually needs to send VoIP data over that bearer and sends a corresponding buffer status notification indicating that there is data to be sent for VoIP traffic, the eNB will send the SPS A PDCCH is sent to the UE to activate the configuration, and within that SPS configuration the PDCCH message also indicates which radio resources the UE is allowed to use periodically (thus, allocate a certain amount of radio resources). Accordingly, the UE uses SPS resources to periodically transmit VoIP traffic.

However, the eNB has no knowledge of the traffic type (e.g., periodicity or message size) transmitted by a particular vehicle over the sidelink connection, and as a result the eNB has no knowledge of Neither the amount of resources to be allocated nor the periodicity of these semi-persistent radio resources can be determined properly.

Even if the eNB somehow receives information about the traffic to be transmitted by the vehicular UE, the vehicular UE must transmit V2V traffic with different periodicity and/or different message sizes. not, which is significantly different from the VoIP traffic type for which current SPS mechanisms are designed. Furthermore, the periodicity with which the V2V traffic is to be transmitted is variable, as the periodicity may change depending on vehicle dynamics, eg, the speed at which the vehicle is traveling. Therefore, currently standardized SPS mechanisms are inadequate to address these different V2V usage scenarios.

The following exemplary embodiments have been conceived by the inventors to alleviate one or more of the problems described above.

Specific implementations of the various embodiments are given by the 3GPP standards, with the addition of certain key features as described below, in relation to the various embodiments, and partially described in the Background section. should be implemented with broad specifications, as Embodiments may be advantageously used, for example, in mobile communication systems such as 3GPP LTE-A (Release 10/11/12/13) communication systems (or later releases) as described in the Technical Background section above. , the embodiment is not limited to its use in this particular exemplary communication network.

The description should not be construed as limiting the scope of the disclosure, but merely as exemplifications of embodiments for a better understanding of the disclosure. Those skilled in the art will be able to apply the general principles of the disclosure, as articulated in the claims, to different scenarios and in ways not explicitly described herein. You should know that. For purposes of explanation, some assumptions are made, but they are not intended to limit the scope of the embodiments below.

Various embodiments primarily provide an improved semi-persistent resource allocation procedure between a UE (for a vehicle) and an eNB responsible for allocating radio resources to the UE (for a vehicle). As such, other functionality (i.e., functionality that does not change with the various embodiments) may remain exactly as described in the background section, or have no effect on the various embodiments. can be changed without This includes, for example, other procedures regarding how the actual transmission of periodic data is performed by the vehicular UE after the vehicular UE has been allocated suitable semi-persistent radio resources.

(First embodiment)
In the following, a first embodiment for solving the above problems will be described in detail. Different implementations and variations of the first embodiment are also described.

Exemplarily, a vehicular UE is assumed to be implemented in a vehicle and capable of performing vehicular communications based on the D2D framework described in the Background section of this application. However, as will be explained in more detail later, the underlying principles of the present invention are not constrained to be applied solely by a vehicular UE, for example via the Uu interface to an eNB or a PC5 interface. It can also be implemented by regular (i.e. non-vehicular) UEs that transmit periodic data to other UEs via (sidelink connections). However, for the discussion below, it is assumed that it is a vehicular UE that needs to transmit V2V data periodically.

If the periodic data is sent to another (vehicular) UE (via the PC5 interface), its eNB (via the Uu interface), the roadside unit (possibly via the PC5 interface) and/or the vehicular UE A vehicular UE transmits (broadcasts) periodic data destined for other (vehicular) UEs, although it may also be possible for vehicular UEs to transmit (broadcast) periodic data destined for other (vehicular) UEs. It is further assumed that transmissions from a vehicular UE can be assumed to be point-to-multipoint, thus reaching all receiving entities within its area.

The periodic data to be transmitted by the vehicular UE is, for example, the Coordination Awareness Message (CAM), which is described in detail in the Background section. A characteristic of CAM that is relevant to the present invention is that the CAM is transmitted in a periodic manner. However, CAMs may have different, even varying transmission periodicities and/or different message sizes (i.e., the amount of data to be transmitted, for which the vehicular UE requires radio resources). In this respect, the semi-persistent scheduling scenario is very different from the normal VoIP usage scenario. VoIP manifests fixed periodicity and fixed message sizes that are manageable by semi-persistent radio resource allocation.

It should be noted that CAM is but one example of such periodic data, and that the present invention is applicable to other data types that may be standardized in the future for vehicular or non-vehicle communications. be. Especially for vehicular communications, vehicular UEs are likely to have to periodically broadcast (status and attributes) data with different and/or even varying periodicities, and thus different periodicities. As a result, messages with more or less data may have to be sent at different time instances.

As will be explained in detail below, CAM messages are a good example of this kind of periodic data, so the first embodiment and the used to describe its variations.

The different CAM components (e.g. CAM HF, CAM LF, certificates, CAM component) exists. In the following, only one CAM message is transmitted/broadcast by the vehicular UE at a particular time instance, but said CAM message is for different CAM components (i.e. different periodicities) to be transmitted at that time instance. CAM components that occur at the time instance in question, regardless of having a . In other words, in the case that different CAM components are to be transmitted by the vehicular UE at the same time (SC period of the PC5 interface), the different CAM components are piggybacked together to form a single CAM message, which is then sent. For piggybacking to actually work, the periodicities of the different CAM components are adjusted (i.e., multiples of each other) so that different CAM components actually occupy the same time instance at a particular time. There is a need. Thus, a single CAM may have a single periodicity (given by the maximum transmission rate of the CAM components to be transmitted (e.g. CAM HF components)) but different content, and therefore different messages. size (i.e., different CAM components are included in a single CAM message at different time instances) and are sent in a cyclical manner, and the different message sizes also vary periodically (e.g., FIG. 10 and related (see description to do). Thus, the radio resource allocation mechanism needs to allocate different amounts of radio resources at different time instances.

Alternatively, different CAM components with different periodicities can be sent as separate CAM messages. Note that each separate CAM message would need to include at least a header, and possibly also a basic container (see FIG. 9 and related description), thus requiring more radio resources. Considering this can be a disadvantage, it is avoided by piggybacking the CAM components together in the first alternative. However, providing separate CAM messages has the advantage that the need to coordinate different periodicities of each CAM component can be avoided, i.e. the periodicity of each CAM component can be freely defined. There is In this case, the CAM messages have different periodicities and different message sizes.

3GPP standardization is not yet complete about the transmission rates of the different CAM components, whether piggybacking is optional or mandatory, or exactly how the different CAM components are transmitted. do not agree with In either case, it is subject to change in future releases. The underlying principles of the present invention can be applied to any of these modifications, even though minor adaptations may have to be applied to make up these modifications.

In the following it is mainly assumed that only one CAM message is transmitted by the vehicular UE at a particular time instance, ie different CAM components form a single CAM message.

Furthermore, the required transmission periodicity of the CAM components may change rapidly over time as a function of vehicle dynamics such as speed, heading, and/or angle, and possibly other factors may be defined in the future. is expected.

In summary, a (vehicular) UE transmits periodic data (eg, CAM) to other receiving entities (eg, other stations for vehicles). In order to transmit periodic data, a vehicular UE needs radio resources, which can be allocated, for example, by the eNB, for example, according to the ProSe Mode 1 radio resource allocation described in the Background section. According to a first embodiment, the eNodeB allocates semi-persistent radio resources to the vehicular UE so that the vehicular UE can periodically transmit pending periodic data.

Providing an overview in advance, the first embodiment can be conceptually divided into a preparation phase and an execution phase. In the preparation phase, different SPS settings are set by the eNodeB for later transmission of periodic data that is supported by the vehicular UE and may therefore be transmitted by the vehicular UE in the future. The vehicular UE is configured with various different SPSs that can be activated during the execution phase as required. The execution phase may be considered to begin when the vehicular UE begins transmitting some or all of the supported periodic data. Accordingly, a particular SPS setting among the previously provisioned SPS settings is activated in the UE and then used by the vehicular UE to transmit pending periodic data. During the execution phase, either the message size or the periodicity of the pending periodic data may change, so that different SPS settings among the previously provisioned SPS settings are executed with different periodicities. , or must be activated in the vehicular UE to still be able to transmit periodic data with different message sizes.

The preparation phase will now be described in more detail. In order for the eNodeB to be able to set up the appropriate SPS settings for periodic data supported by the UE, the eNodeB needs to know about periodic data that may be transmitted by vehicular UEs in the future. Typically, an SPS configuration allocates a certain amount of radio resources in a periodic manner (i.e. at periodic time instances), and the certain amount of radio resources corresponds to the amount of data the UE needs to transmit (e.g. CAM message size). Accordingly, the eNodeB may determine one or more possible different periodicities and/or different possible message sizes that may be transmitted by the vehicular UE in the future. UEs send information about periodic data to the eNodeB. By learning this information and subsequently activating one or more of these SPS settings for vehicular UEs, vehicular UEs were periodically assigned with the activated SPS settings. An eNodeB can configure several different SPS settings in such a way that radio resources can be used to actually transmit one or more of the supported periodic data.

Thus, after having set up multiple SPS settings, the eNodeB sends corresponding information about the multiple SPS settings to the vehicular UE so that the vehicular UE knows the multiple SPS settings that may be activated in the future. offer. In this way, eNodeBs and vehicular UEs are ready to handle one or more transmissions of the supported periodic data.

The execution phase will now be described in more detail. Then the vehicular UE may eventually want to transmit some or all of the CAM data components and need radio resources (semi-persistently allocated) to perform the transmission. It is assumed. In response, the vehicular UE informs the eNB which CAM components it wants to transmit, and the eNB responds by transmitting all currently waiting CAM components from the pre-arranged SPS settings. Select one or more SPS configurations that allocate appropriate radio resources to vehicular UEs such that: The eNB then activates the selected SPS configuration(s) in the UE accordingly, eg by sending an appropriate activation command.

In response, the vehicular UE activates a specific SPS configuration, as instructed by the eNodeB, so that an active It is possible to use periodic radio resources scheduled according to the customized SPS configuration.

As explained above, according to the first embodiment, it is possible to allocate SPS resources to a vehicular UE even if the periodicity and/or message size of the data to be transmitted by the vehicular UE may vary. It is possible. As a result, the Uu link between the eNodeB and the UE would otherwise need to repeatedly perform dynamic radio resource allocation (see e.g. ProSe Mode 1 discussion in Background section) every SC period. It is possible to reduce the above signaling overhead. Furthermore, the buffer status notification used by the vehicular UE to indicate that (periodic) data is waiting to be transmitted triggers dynamic resource allocation each time there is periodic data coming to the UE side. There is no need to send from the UE to the eNB to do so.

FIG. 11 illustrates three different CAM components to enable transmission of three different CAM components (certificate, CAM LF component, and CAM HF component) according to an exemplary implementation of the first embodiment. Fig. 4 exemplarily shows that the SPS settings are activated. For this exemplary implementation of the first embodiment, one SPS setting is set for one particular CAM data component. Accordingly, a vehicular UE wishing to transmit three different CAM components can use the periodic radio resources allocated by SPS setting 1 to transmit the CAM HF component, and transmit the CAM LF component. Periodic radio resources allocated by SPS configuration 2 may be used to transmit certificates, and periodic radio resources allocated by SPS configuration 3 may be used to transmit certificates.

Depending on whether different CAM components are sent in one message or in separate messages, different SPS settings are combined by the vehicular UE so that a larger combined CAM message can be sent. or can be used separately from each other to send separate CAM messages.

A more specific embodiment that the first embodiment can take is shown below.

In a broad implementation of the first embodiment, the vehicular UE has one or more different data components to be transmitted with possibly different transmission periodicities and/or possibly different message sizes. It is assumed, but not specified in more detail, to support the transmission of periodic data containing As explained above, a challenge posed to the SPS allocation mechanism of the first embodiment is that the transmission of vehicular data may involve different periodicities and/or different message sizes. be. This is explained in more detail based on the CAM messages introduced in the Background section.

According to one possible exemplary scenario, the vehicular UE supports transmission of several CAM components, such as a CAM HF component, a CAM LF component, and security credentials. Accordingly, the possible message sizes depend on which CAM components are sent in the CAM message. An overview of the different possible message sizes is given in the table below.

For the table above, the different CAM components sent at the same time instance are in one such that the CAM LF component and the CAM security certificate are each piggybacked to the base CAM HF component sent at the highest transmission rate. It is assumed to form a single CAM message. Correspondingly, the message size varies with time instance as listed in the right column of the table and as exemplarily shown in FIG. Due to periodicity, Figure 11 does not show the transmission of the CAM HF components + CAM security credentials, in that respect see the middle part of Figure 10).

Different CAM components are different such that each possible CAM message to be sent at a particular time instance must be sent with a different periodicity as exemplarily shown in the table below. should be sent with regularity.

The transmission periodicity value assumed above is the periodicity of the CAM component in question in the CAM message that has the lowest transmission rate (e.g., for a CAM message containing a CAM HF component and a CAM LF component, CAM LF 500ms) of the component. The indicated transmission periodicity should not be understood as the transmission periodicity of a particular CAM message. For example, a CAM message containing a CAM HF component and a CAM LF component is not actually sent every 500ms (it is sent every 1000ms, see Figure 11).

The exemplary assumed values in the table above for transmission periodicity are assumed for a single vehicle speed range above 144 km/h, where that speed range is the only one supported by the vehicular UE. It is assumed to be one

According to another possible exemplary scenario, the vehicular UE has only one CAM component, e.g. fixed periodicity supports transmissions of 100 ms (see table above). However, a special property of V2V data is that the periodicity of different CAM components can vary with vehicle dynamics, eg the speed at which the vehicle UE is traveling. As a result, even if the vehicular UE supports transmission of only one CAM component, the periodicity with which one CAM component should be transmitted will change over time and some periodicity will be taken into account by the SPS allocation mechanism. It can again result in needing to be put in. This is illustrated in the table below.

According to another possible example scenario, the vehicular UE supports transmission of various CAM components (e.g., CAM HF, CAM LF, and all three CAM components of security certificates) and In addition, it shall support several speeds (ranges). The resulting varying periodicities and message sizes are apparent from the table below.

As illustrated above, there can be many different combinations of CAM components (left column of the table above) and different possible CAM message sizes (e.g. 122 bytes, 182 bytes, 299 bytes, or 239 bytes), and depending on the specific CAM component for the vehicular UE and/or possibly the supported speed (range), different possible periodicities (e.g. 100ms, 200ms, 300ms, 500ms, 600ms, 1000ms, 1200ms). The SPS settings configured by the eNB in the preparation phase need to take this into account and allow the vehicular UE to transmit any (combination) of the supported periodic data with the appropriate Shall match the resulting CAM message transmission periodicity and/or resulting CAM message size supported by the vehicular UE so that the SPS setting is activated later.

A variety of different SPS settings are provided by eNodeBs, as illustrated for selected examples above. In particular, initially several different periodicities should be taken into account for the sake of brevity, but the periodicity itself does not change with time (e.g. due to speed changes). It is assumed that the UE supports transmission of several CAM components, but only one speed range, eg the highest speed range above 144 km/h.

In the exemplary implementation of the first embodiment described above, such that there is one separate SPS setting that matches each possible CAM component that the vehicular UE supports to transmit , three different SPS settings 1, 2 and 3 are set by the eNodeB. Considering that for possible combinations of CAM HF components and CAM security certificates, this particular combination does not occur due to the exemplary periodicity for separate CAM components, this particular Note that the example does not require separate SPS settings.

SPS setting 1 allocates specific radio resources sufficient to transmit a basic CAM HF component of 122 bytes every 100 ms, which is the periodicity of the CAM HF component. Accordingly, the UE uses the periodic radio resources allocated by SPS setting 1 to transmit CAM messages containing CAM HF components.

SPS setting 2 also allocates specific radio resources sufficient to transmit an additional (piggybacked) CAM LF component of 60 bytes every 500 ms, which is the periodicity of the CAM LF component. Accordingly, the UE uses the periodic radio resources allocated by SPS setting 2 to transmit CAM messages containing CAM LF components. In addition, SPS configuration 3 allocates specific radio resources sufficient to transmit 117 bytes of additional (piggybacked) security credentials every 1000ms corresponding to the periodicity of the security credentials. In response, the UE uses periodic radio resources allocated by SPS setting 3 to transmit CAM messages containing security credentials.

FIG. 12 illustrates the use of the three SPS settings exemplarily assumed above for transmission of CAM messages by a vehicular UE, according to an exemplary implementation of the first embodiment. As can be seen from Figure 12, the three SPS settings correspond to three different data components to be transmitted by the vehicular UE. A dashed box containing multiple data components to be sent at the same time instance indicates that these different data components are sent as one CAM message, as illustratively assumed above. shall be As can be seen from FIG. 12, at time instances when several CAM components are to be sent in one CAM message, the vehicular UE sends the entire CAM message (i.e. including multiple CAM components). Combine the radio resources allocated by multiple SPS configurations so as to have sufficient radio resources available for . For example, when transmitting a CAM HF component together with a CAM LF component, the radio resources allocated via SPS settings 1 and 2 are combined (i.e., summed and used together), resulting in Have sufficient radio resources available. Similarly, when transmitting a CAM HF component together with a CAM LF component and security certificates, the radio resources allocated via SPS settings 1, 2 and 3 are combined so that the entire combined CAM message have sufficient radio resources available to transmit

As just mentioned, radio resources allocated by different SPS settings may have to be combined for time instances when a vehicular UE transmits a larger combined CAM message. According to an alternative implementation of the first embodiment below, this combination of radio resources separately allocated by the SPS configuration is no longer necessary. Instead, separate SPS settings are set in such a way that the size of the resulting single CAM message is already taken into account. In line with the discussion above, the following table exemplarily shows this alternative implementation of the first embodiment.

As can be seen from the table, the SPS settings have a larger amount of radio resources allocated by the respective SPS setting, thereby resulting in a larger CAM message when several CAM components are sent within one CAM message. It differs from the previous embodiment in that size is taken into account.

Corresponding to FIG. 12, FIG. 13 shows how different SPS settings are used by a vehicular UE to transmit periodic CAM data (components). At the time instances when the vehicular UE transmits several CAM components in one CAM message, the vehicular UE has sufficient radio resources among the activated SPS settings to transmit a larger CAM message. shall choose an SPS setting that provides As in the previous exemplary implementation of the first embodiment, the vehicular UE selects SPS setting 1 to send CAM messages containing only CAM HF components. On the other hand, when transmitting the CAM HF component together with the CAM LF component, radio resources are required to transmit a total of 182 bytes, resulting in the transmission of said CAM message containing the CAM HF component and the CAM LF component. To do so, the vehicle UE shall select SPS setting 2 and use the specific radio resources allocated by SPS setting 2 . Correspondingly, when transmitting the CAM HF component together with the CAM LF component and the security certificate, radio resources are required to transmit a total of 299 bytes, so that the vehicular UE uses SPS setting 3 shall be selected. Thus, the vehicular UE uses specific radio resources allocated by SPS setting 3 to transmit said CAM message containing three components.

The above-discussed implementation of the first embodiment, according to FIGS. 12 and 13, allows the vehicular UE to operate in several speed ranges, for example three assumed speed ranges, above 144, from 72 onwards. 144, and 48-72, can also be applied, resulting in additional different periodicities supported for each CAM component.

The table below shows that the radio resources allocated by different SPS settings are required by the vehicular UE to gather enough radio resources to be able to transmit a combined CAM message containing several data components. It is assumed that they can be combined (see discussion for FIG. 12).

As can be seen from the table above, in the preparation phase the eNodeB enables the vehicular UE to transmit the corresponding CAM components in a periodic manner later upon activating one or more SPS settings. Nine separate SPS configurations are configured, each of which allocates radio resources with appropriate periodicity to do so.

Depending on the current speed of the vehicular UE, the eNodeB will activate either SPS settings 1, 2 and 3 when the speed is above 144km/h or when the speed is between 72km/h and 144km/h. configures the vehicular UE to activate SPS settings 4, 5 and 6, or activate SPS settings 7, 8 and 9 when the speed is between 48 km/h and 72 km/h.

FIG. 14 illustrates how nine separate SPS settings can be used by a vehicular UE to periodically transmit CAM messages of different sizes. The upper part of FIG. 14 (ie with reference to speeds above 144 km/h) basically corresponds to FIG. 12 and will not be described again. For the speed range 72 km/h to 144 km/h, FIG. 14 shows SPS settings 4, 5, and 6 activated by the vehicular UE so as to be able to transmit CAM messages of different sizes. It shows how to combine the radio resources allocated by . In particular, a CAM message composed of a CAM HF component and a CAM LF component may be transmitted by a vehicular UE by combining the radio resources allocated by SPS settings 4 and 5. A CAM message, composed of all three components (CAM HF, CAM LF, security certificate), is transmitted by the vehicular UE by combining and using radio resources allocated by SPS settings 4, 5 and 6. can be sent. A CAM message composed of a CAM HF component and a security certificate can be transmitted by a vehicular UE by combining and using radio resources allocated by SPS settings 4 and 6.

For the speed range 48 km/h to 72 km/h, FIG. 14 shows that vehicle UEs are assigned with activated SPS settings 7, 8, and 9 to be able to transmit CAM messages of different sizes. It shows how the radio resources are combined. In particular, a CAM message composed of a CAM HF component and a CAM LF component may be transmitted by a vehicular UE by combining the radio resources allocated by SPS settings 7 and 8. A CAM message composed of all three components (CAM HF, CAM LF, Security Certificate) is transmitted by the vehicular UE by combining and using radio resources allocated by SPS settings 7, 8 and 9. be able to.

In the following, the alternative implementation of the first embodiment described in connection with FIG. 13 can now also be extended to vehicular UEs supporting several speed ranges.

FIG. 15 shows the corresponding use of different SPS settings by a vehicular UE to transmit various possible CAM messages. The upper part of FIG. 15 (with reference to speeds above 144 km/h) essentially corresponds to FIG. 13 and will not be described again. For the speed range 72 km/h to 144 km/h, four different SPS settings are set by the eNodeB to support the transmission of all possible CAM components. Unlike the scenario for speed ranges above 144 km/h, the vehicular UE actually has to send a CAM message consisting of a CAM HF component and a CAM security certificate. In this alternative implementation of the first embodiment, the eNodeB thus has a separate SPS setting for this possible CAM message, i.e. enough to send 239 bytes every 1000 ms. The SPS settings 7, which allocate specific radio resources, must be configured. The radio resources of SPS settings 4 and 6 could be flexibly combined to allocate sufficient (but not too much) resources to transmit CAM messages consisting of CAM HF components and security certificates ( 14), so this SPS setting 7 was not needed in the previous implementation of the first embodiment.

To reiterate, several SPS settings are set by the eNodeB to support the different possible speed ranges that the UE may run (as an example of vehicle dynamics affecting the periodicity of various CAM data components). is prepared. In such a scenario, when having multiple SPS settings, the possible speed ranges supported by the vehicular UE affect the different periodicities that should be taken into account, so the eNB is informed about them. It is also necessary to One option is to provide explicit information about the speed range supported by the vehicular UE, from which the eNB needs to be considered when preparing multiple SPS settings, resulting in periodic data. For example, together with or separately from the information on the periodicity, send to the eNB so that different periodicities of the components can be determined. Another option is for the vehicular UE to detect various possible periodicities, including periodicity in the supported speed range, so that the UE does not need to additionally inform the eNB about the supported speed range. pre-transmitting, eNBs assume that they have access to specific information that allows this relationship to be established, such as standardized definitions for CAM messages and component periodicity in different speed ranges. Then, from the different reported periodicities, the supported speed range can be deduced.

Furthermore, when the UE actually wants to start transmitting periodic data, the eNB may select and activate a provisioned SPS setting for the indicated speed range that the vehicular UE is currently experiencing. So the UE shall inform the eNB about its current speed (or about the speed range it is currently in). Information about the current speed may be sent by the vehicular UE, for example, together with or separately from an indication of which data components the vehicular UE wishes to send. For example, one exemplary implementation of the first embodiment is that this indication information is a buffer status notification indicating that data is waiting in the corresponding buffer in the UE for a particular logical channel group. stipulates. Correspondingly, information about the current speed of the vehicular UE can also be sent within the buffer status notification.

Furthermore, as noted above, the periodicity of the CAM data components may depend on vehicle dynamics such as speed, which may vary over time. Therefore, a further implementation of the first embodiment allows to vary the activated SPS settings depending on the current vehicle dynamics (eg speed of the vehicular UE). In that regard, the vehicular UE may monitor its own speed and determine if the speed range has changed compared to the speed range it was in before. In this case, the vehicular UE may inform the eNodeB of this speed range change. Alternatively, the vehicular UE may periodically send information about its current speed to the eNodeB so that the eNodeB itself can determine when the speed range associated with the SPS setting is changed by the vehicular UE. In any case, a change in speed range thus selects and activates a different SPS setting provided for the indicated speed range in question instead of the previously activated SPS setting. so that the eNodeB can be triggered. The vehicular UE receives such an activation command for the changed SPS settings and no longer uses the previously activated SPS settings, but uses the newly activated SPS settings.

According to another alternative implementation of the first embodiment, instead of sending the current speed or the current changed speed range to the eNodeB, the vehicular UE is configured to change the specific speed range by itself. can actually identify the corresponding SPS settings needed for that changed speed range and send a request to the eNodeB to use these new SPS settings due to the speed range change. obtain. The eNodeB may then receive this request and decide whether or not to comply with the request itself. In response, the eNodeB may determine that the change in SPS configuration is valid and accordingly send a response to the request to activate the requested SPS configuration. Thus, the vehicular UE no longer uses the previously activated SPS settings, but now uses the newly activated SPS settings.

As just described, when changing the SPS settings in the vehicular UE due to changes in vehicle dynamics (e.g. speed), according to one possible implementation of the first embodiment, the vehicular UE , to avoid that some of the components are not sent due to frequent changes in speed, and consequent frequent changes in SPS settings, all of the CAM components (i.e., a CAM message containing all CAM components) You can always start by sending.

As explained above, the vehicular UE transmits to the eNB information about the supported periodic data that the vehicular UE may have to transmit in the future. This can be implemented in various ways, as will be explained in detail with reference to the following implementations of the first embodiment. According to an exemplary implementation of the first embodiment, the vehicular UE is capable of transmitting CAM messages/components that the vehicular UE supports and as a result of which may actually have to be transmitted in the future. , the eNodeB may be explicitly informed of the possible different periodicities and/or the possible different message sizes. Thus, for example, information regarding periodic data may include a list of possible periodicities and/or possible CAM message sizes supported by the vehicular UE. In this way, the eNodeB can prepare appropriate SPS settings for the various different periodicities and/or message sizes supported.

According to this implementation variant of the first embodiment, the information about the periodic data can be sent in one message or in at least two separate messages. In particular, information about possible periodicity and possible message size can be provided in one message, e.g. SidelinkUEInformation currently defined in the standard to indicate sidelink information to the eNodeB The frequency it is interested in communicating with, and the sidelink communication destination for which the UE requests that dedicated resources be allocated for it) (v13.0 of Non-Patent Document 13, incorporated herein by reference). .0 section 6.2.2)). The following defines an exemplary extended SidelinkUEInformation message according to this implementation of the first embodiment.
<Sidelink UE Information message>
--ASN1START
Sidelink UEInformation-r12 ::= SEQUENCE {
critical Extensions CHOICE {
c1 CHOICE {
Sidelink UE Information-r12 Sidelink UE Information-r12-IEs,
spare3 NULL, spare2 NULL, spare1 NULL
},
criticalExtensions Future SEQUENCE { }
}
}
Sidelink UEInformation-r12-IEs ::= SEQUENCE {
commRxInterestedFreq-r12 ARFCN-ValueEUTRA-r9 OPTIONAL,
commTxResourceReq-r12 SL--CommTxResourceReq-r12 OPTIONAL,
discRxInterest-r12 ENUMERATED {true} OPTIONAL,
discTxResourceReq-r12 INTEGER (1..63) OPTIONAL,
late NonCritical Extension OCTET STRING OPTIONAL,
nonCriticalExtension SidelinkUEInformation-v13x0-IEs OPTIONAL
}
Sidelink UEInformation-v13x0-IEs ::= SEQUENCE {
commTxResourceReq121-r13 SL-CommTxResourceReqUC-r13 OPTIONAL,
commTxResourceInfoReqRelay-r13 SEQUENCE {
commTxResourceReqRelay-r13 SL-CommTxResourceReqUC-r13,
ue-Type-r13 ENUMERATED {relayUE, remoteUE}
}
OPTIONAL,
discTxResourceReq-v13x0 SEQUENCE {
carrierFreqDiscTx-r13 INTEGER(1..maxFreq),
discTxResourceReqAddFreq-r13 SL-DiscTxResourceReqPerFreqList-r13 OPTIONAL
}
OPTIONAL,
discTxResourceReqPS-r13 SL-DiscTxResourceReq-r13 OPTIONAL,
discRxGapReq-r13 SL-GapRequest-r13 OPTIONAL,
discTxGapReq-r13 SL-GapRequest-r13 OPTIONAL,
disc SysInfoReportList-r13 SL-SysInfoReportList-r13 OPTIONAL,
nonCriticalExtension SEQUENCE { } OPTIONAL
}
SL-CommTxResourceReq-r12 ::= SEQUENCE {
carrierFreq-r12 ARFCN-Value EUTRA-r9 OPTIONAL,
destinationInfoList-r12 SL-DestinationInfoList-r12
}
SL-CommTxResourceReqUC-r13 ::= SEQUENCE {
carrierFreq-r13 ARFCN-Value EUTRA-r9 OPTIONAL,
destinationInfoListUC-r13 SL-DestinationInfoListUC-r13
}
SL-DiscTxResourceReqPerFreqList-r13 ::= SEQUENCE (SIZE (1..maxFreq)) OF SL-DiscTxResourceReq-r13
SL-DiscTxResourceReq-r13 ::= SEQUENCE {
carrierFreq-r13 ARFCN-Value EUTRA-r9 OPTIONAL,
discTxResourceReq-r13 INTEGER (1..63)
}
SL-DestinationInfoList-r12 ::= SEQUENCE (SIZE (1.. max SL-Dest-r12)) OF SL-DestinationIdentity-r12
SL-DestinationIdentity-r12 ::= BIT STRING (SIZE (24))
SL-DestinationInfoListUC-r13 ::= SL-DestinationInfoList-r12
SL-SysInfoReportList-r13 ::= SEQUENCE (SIZE (1.. max SL-DiscSysInfoReportFreq-r13)) OF SL-SysInfoReport-r13
Sidelink UEInformation-v14x0-IEs ::= SEQUENCE {
commTxResourceReq121-r14 SL-CommTxResourceReq-14 OPTIONAL,
. . . . . }
SL-CommTxResourceReq-r14 ::= SEQUENCE {
carrierFreq-r14 ARFCN-ValueEUTRA-r9 Optional
destinationInfoListUC-r14 SL-DestinationInfoList-r14
SL-Traffic-r14 SL-TrafficList-r14 Optional
}
SL-TrafficList-r14 ::= SEQUENCE (SIZE (1.. max SL-Traffic-r14)) OF SL-TrafficType-r14
SL-TrafficType-r14 ::= SEQUENCE {
trafficType ENUMERATED {periodic, non-periodic}
period ENUMERATED {
sf100, sf200, sf300, sf500,
sf600, sf1000, sf1200, spare10,
spare9, spare8, spare7, spare6,
spare5, spare4, spare3, spare2,
spare 1}
messageSize INTEGER (1...300)

Additional elements that are illustratively introduced into the SidelinkUEInformation message in this implementation of the first embodiment are bolded and boxed above. Clearly then, there is a periodicity field that allows a variety of different periodicities to be indicated, such as those mentioned above for CAM messages. Similarly, a message size field is provided that allows various different message sizes to be indicated, each with a value of 1-300 bytes. Optionally, the traffic type field allows the UE to inform the eNodeB whether the data is periodic or aperiodic.

Alternatively, instead of indicating the message size together with the possible periodicity, according to a further variant of the first embodiment, the message size (i.e. the amount of data the UE wants to send) is indicated together with the buffer status notification. and the buffer status notification indicates that data is waiting to be transmitted by the vehicular UE. In this case, in one example of the preparation phase, the eNodeB only receives information about the different possible periodicities and not about the different possible message sizes, so that the different possible periodicities , proceed to prepare different SPS settings. For example, multiple SPS configurations provisioned by an eNodeB differ with respect to periodicity, but it is not clear as to which and how many radio resources are allocated by the SPS configuration. Then, when the vehicular UE wishes to actually start transmitting one or more of the possible data components, the corresponding buffers are filled, thus triggering a buffer status notification to be sent to the eNodeB. and, based on that, actually determine the amount of data the UE wishes to communicate for one or more possible data components. In response, the eNodeB selects and activates a corresponding appropriate SPS setting (with a corresponding appropriate periodicity) and then activates the selected SPS setting for the vehicular UE while simultaneously For activated SPS configurations, indicate which resources are allocated by each activated SPS configuration.

In other words, unlike as previously described in connection with FIGS. 11-15, in this particular variation of the first embodiment, the eNodeB pre-specifies the radio resources (e.g., 122 bytes to transmit). No SPS configuration 1) that defines sufficient radio resources for 1), only periodicity is specified. For example, the eNodeB may provide SPS setting 1 to support transmission of CAM HF components by vehicular UEs with a periodicity of 100 ms (assuming a speed range of >144 km/h), and for other SPS settings It is the same. For the scenario assumed for Figure 12, the eNodeB thus provides three different SPS settings, ie for three periodicities of 100ms, 500ms and every 1000ms respectively. For the scenario assumed for Figure 14, the eNodeB provides 9 different SPS settings, 3 each for each speed range.

According to another exemplary implementation of the first embodiment, in addition or instead of transmitting information about possible different periodicities and/or different possible message sizes , the vehicular UE may inform the eNodeB about the specific data components that the vehicular UE is supported to transmit. For example, in this way the periodicity information may include a list identifying data components that the vehicular UE is supported to transmit in the future. The eNodeB has access to information about possible periodicities and message sizes associated with these identified data components, e.g., 3GPP standards specify different possible CAMs and their We can explicitly define the size and periodicity for the components of . In this way, the eNodeB can thus prepare appropriate SPS settings for the different supported periodicities and/or message sizes.

Although not specified in detail above, the activation command sent by the eNodeB to the vehicular UE to activate the selected SPS settings is exemplary as a message sent over the PDCCH, the physical downlink control channel. can be implemented in For example, in a similar manner as for currently specified SPS mechanisms, the eNodeB may send one or more DCIs to activate one or more of the previously configured SPS settings. In one example, a new C for DCI for sidelink activation/deactivation because the UE needs to know that the DCI is for the sidelink SPS and not for the Uu SPS or Uu link dynamic assignment. - RNTI can be used. As mentioned above, for certain implementations of the first embodiment, the PDCCH message may also identify the specific radio resource that the UE is to use for the activated SPS configuration.

Although not specified in detail above, the eNodeB shall inform the UE about the SPS settings after determining the SPS settings. This may be implemented as an RRC message, eg sps-ConfigSidelink within a radioResourceConfigDedicated message. The current SPS settings for the Uu link are sent in the radioResourceConfigDedicated message. To indicate the SPS settings for the sidelink, a new element can be created as sps-ConfigSidelink, which can also be sent within the radioResourceConfigDedicated message. As explained above, the SPS configurations configured by the eNodeB in the preparation phase may, for example, specify both periodicity and radio resources, or may configure only periodicity (in which case The radio resource can then be specified together with the activation command sent from the eNodeB to the UE).

While implementations of the first embodiment have been described in terms of V2V and vehicular UEs communicating with other vehicular UEs over sidelink connections, the underlying principles of the first embodiment are: It can also be applied to transmit vehicular data between a vehicular UE and e.g. an eNodeB via the Uu interface or between a vehicular UE and a roadside unit via e.g. a PC5 interface.

Furthermore, although the implementation of the first embodiment has been described in terms of a vehicular UE, the underlying principle of the first embodiment is to communicate with an eNB or other "normal" via a sidelink connection. It can also be performed by a "regular" UE communicating with a UE for a vehicle.

<Hardware and software implementation of the present disclosure>
Another exemplary embodiment relates to implementation of the various embodiments described above using hardware, software, or software cooperating with hardware. In this connection a user terminal (mobile terminal) is provided. A user terminal is adapted to carry out the methods described herein, including corresponding entities, such as receivers, transmitters, processors, etc., which are appropriately involved in these methods.

It is further recognized that various embodiments can be implemented or performed using a computing device (processor). A computing device or processor may be, for example, a general purpose processor, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate array (FPGA), or other programmable logic device. Various embodiments may be performed or embodied by combinations of these devices. Specifically, each functional block used in the description of each of the above embodiments can be realized by LSI as an integrated circuit. These functional blocks may be formed individually as chips, or a single chip may be formed to include some or all of the functional blocks. These chips may include data inputs and outputs coupled to them. Here, LSI may also be called IC, system LSI, super LSI, or ultra LSI depending on the degree of integration. However, the technology for implementing integrated circuits is not limited to LSIs, and may be realized by using dedicated circuits or general-purpose processors. In addition, an FPGA (Field Programmable Gate Array) that can be programmed after the LSI is manufactured, or a reconfigurable processor that can reconfigure the connections and settings of the circuit cells arranged inside the LSI. good too.

Furthermore, various embodiments may be implemented by software modules, which are executed by a processor or directly in hardware. Also a combination of software modules and a hardware implementation may be possible. The software modules may be stored on any kind of computer readable storage media, for example RAM, EPROM, EEPROM, flash memory, registers, hard disks, CD-ROM, DVD, etc. It is further noted that individual features of a plurality of different embodiments may be the subject of another embodiment, individually or in any combination.

It will be appreciated by those skilled in the art that various changes and/or modifications may be made to the present disclosure as shown in the specific embodiments. Accordingly, the present embodiments are to be considered in all respects as illustrative and not restrictive.

Claims (6)

1. An integrated circuit for controlling a radio base station process for allocating radio resources to a vehicular mobile terminal for transmitting periodic data to one or more receiving entities, said vehicular mobile terminal comprising: supporting the transmission of said periodic data comprising one or more different data components to be sent in some different transmission period and/or possibly different message sizes, said process comprising:
a process of receiving from the vehicular mobile terminal information regarding the periodic data to be transmitted by the vehicular mobile terminal to the one or more receiving entities;
determining the possible different transmission periodicities and/or the possible different message sizes of the different supported data components and the one or more data components;
A process of configuring a plurality of semi-persistent radio resource configurations based on the determined transmission periodicity and/or the determined message size, each of the plurality of semi-persistent radio resource configurations comprising: configured to be used to transmit at least one of the data components of the
a process of transmitting information about the configured plurality of semi-persistent radio resource configurations to the vehicle mobile terminal;
receiving from the vehicular mobile terminal an indication that one or more of the data components should be transmitted by the vehicular mobile terminal;
of the plurality of semi-persistent radio resource configurations to be activated for periodically allocating radio resources for the vehicular mobile terminal for the vehicular mobile terminal to transmit each of the data components. selecting one or more of the
sending an activation command to the vehicular mobile terminal to activate the selected one or more semi-persistent radio resource configurations for the vehicular mobile terminal;
An integrated circuit containing The received information about the periodic data comprises:
information about some or all of the different possible transmission periodicities and/or different possible message sizes of the one or more data components transmitted by the vehicular mobile terminal; said information regarding a message size of at least one data component to be received from said vehicular mobile terminal together with a buffer status notification indicating that data is waiting to be transmitted for said one data component; , information, or
information about the different data components, the different possible transmission periodicities and/or the different possible messages based on the received information about the different possible data components; information that determines the size, including
The integrated circuit of Claim 1. receiving information from the vehicular mobile terminal about vehicle parameters indicative of vehicle dynamics, including at least speed, supported by the vehicular mobile terminal; and based on the received information about the vehicle parameters, the one or more determining the possible different transmission periodicities of supported data components;
The plurality of semi-persistent radios to receive from the vehicular mobile terminal information about the vehicle parameters that the vehicular mobile terminal is currently experiencing and to activate based on the received current vehicle parameters. selecting said one or more of the resource settings, said information about said current vehicle parameters, together with indication information that one or more data components should be transmitted by said vehicle mobile terminal; received from a vehicle mobile terminal,
3. An integrated circuit according to claim 1 or 2. receiving information about a changed vehicle parameter from the vehicle mobile terminal, and replacing the previously selected and activated semi-persistent radio resource configuration with another semi-persistent radio resource based on the changed vehicle parameter; selecting a configuration and sending a further activation command to the vehicular mobile terminal to activate the selected other semi-persistent radio resource configuration; or
receiving a request to activate a semi-persistent radio resource setting other than the pre-activated semi-persistent radio resource setting from the vehicle mobile terminal, and activating the other semi-persistent radio resource setting; determining whether or not, and if yes, sending a further activation command to the vehicular mobile terminal to activate another semi-persistent radio resource configuration instead of the previously activated semi-persistent radio resource configuration. death,
said further activation command is sent in a message over the PDCCH, the physical downlink control channel;
4. The integrated circuit of claim 3. each of the configured and transmitted plurality of semi-persistent radio resource configurations,
Radio resources and periodicity suitable for transmitting at least one of said supported data components, wherein said plurality of semi-persistent radio resource configurations is a Radio Resource Control (RRC) protocol message radio resource and periodicity transmitted within, or
periodicity for transmitting at least one of said data components, said information relating to said radio resource that can be used by said vehicular mobile terminal for transmitting at least one of said data components; said activation command for activating one or more of the semi-persistent radio resource configurations of said radio resource, said activation command and said information about said radio resource being transmitted via PDCCH, the physical downlink control channel specify the periodicity sent in the message,
5. An integrated circuit as claimed in any one of claims 1 to 4. The plurality of semi-persistent radio resource configurations are configured such that there is one semi-persistent radio resource configuration per data component with a unique message size and a unique transmission periodicity, or
The data components transmitted by the vehicular mobile terminal at the same time instance are transmitted as one message, and the plurality of semi-persistent radio resource configurations allows the vehicular mobile terminal to transmitted by the vehicular mobile terminal to transmit the message comprising the one or more data components based on the activated semi-persistent radio resource configuration corresponding to the included data components. configured such that there is one semi-persistent radio resource configuration for each possible message containing one or more of the data components to be
6. An integrated circuit as claimed in any one of claims 1 to 5.

Images