HK40013581A - A method and network node for communication - Google Patents

Description

Resource configuration and scheduling for direct transmission in a multi-network environment

Background

Wireless devices may communicate with each other through a wireless access network. The wireless devices may establish wireless links with radio access network nodes of the radio access network, after which each wireless device may be in data communication with the radio access network. Data communication between wireless devices may be accomplished by: the source wireless device sends data to the wireless access network, which then forwards the data to the destination wireless device.

Different types of wireless communication between wireless devices involves device-to-device (D2D) communication. In D2D communication, wireless devices that are sufficiently close to each other can transmit data directly to each other without first transmitting the data to the radio access network node. The establishment of the D2D link between wireless devices may still be controlled by the radio access network.

Drawings

Some implementations of the present disclosure are described with respect to the following figures.

Fig. 1 is a block diagram of an example network arrangement according to some implementations.

fig. 2A and 2B are block diagrams illustrating respective different types of roadside units, according to some examples.

FIG. 3 is a flow diagram of an example process according to some implementations.

Fig. 4 is a block diagram of an example network arrangement using a first implementation, in accordance with some examples of the present disclosure.

Fig. 5 is a flow diagram of a process performed in the network arrangement of fig. 4 according to some implementations.

fig. 6 is a block diagram of an example network arrangement using a second implementation according to further examples of the present disclosure.

Fig. 7 is a flow diagram of a process performed in the network arrangement of fig. 6 according to some implementations.

Fig. 8 is a block diagram of an example network arrangement using a third implementation according to further examples of the present disclosure.

Fig. 9 is a block diagram of an example network arrangement using a fourth implementation according to further examples of the present disclosure.

Fig. 10 and 11 are flowcharts of processes performed by the network arrangement of fig. 9 according to various implementations.

fig. 12 is a flow diagram of a process performed in a network arrangement according to an additional implementation.

fig. 13 is a block diagram of an example communication device according to some implementations.

Throughout the drawings, identical reference numbers designate similar, but not necessarily identical, elements. The figures are not necessarily to scale, and the sizes of some portions may be exaggerated to more clearly illustrate the examples shown. Moreover, the figures provide examples and/or implementations consistent with the description; however, the description is not limited to the examples and/or implementations provided in the figures.

Detailed description of the invention

In this disclosure, the use of the terms "a", "an" or "the" are also intended to include the plural forms as well, unless the context clearly indicates otherwise. Furthermore, the terms "comprising," "including," "having," or "having," when used in this disclosure, specify the presence of stated elements, but do not preclude the presence or addition of other elements.

Device-to-device (D2D) communication may be in accordance with D2D proximity-based services (ProSe) as defined by the third generation partnership project (3 GPP). ProSe is provided as part of the Long Term Evolution (LTE) standard implemented by 3 GPP. The LTE standard is also known as the evolved Universal terrestrial radio Access (E-UTRA) standard.

Although reference is made to the LTE standard in some examples, it should be noted that in alternative examples, other communication protocols may be employed, including new generation radio access protocols such as 3GPP New Radio (NR), fifth generation (5G) communication protocols, wireless LAN (e.g.) protocols, and so forth.

ProSe offers the following features: extending existing network coverage and permitting radio communications to be transmitted in the absence of a reachable wide area network, such as when the wireless device is located in a building basement or other congested area, or when the network infrastructure has failed. ProSe communication may also be applied to vehicle communication for road safety and traffic information applications, where vehicle communication may include vehicle-to-vehicle (V2V) communication, vehicle-to-pedestrian (V2P) communication, vehicle-to-infrastructure (V2I) communication, vehicle-to-network (V2N) communication, and the like. As used herein, a vehicle may refer to any or a combination of items of: trucks, trailers, tractors, automobiles, rail vehicles (e.g., trains), marine vessels (e.g., ships), aircraft, spacecraft, or any other movable structure that may carry cargo or people.

The sidelink refers to the ProSe radio communication scheme and, by extension, to the relevant set of protocols on the PC5 interface (user equipment (UE) to UE interface). ProSe sidelink communications may be used for Vehicle-to-Everything (V2X) communications, where V2X communications refer to any one or more of the following: V2V communication, V2P communication, V2I communication, V2N communication, and the like.

Although reference is made to V2X communications in some examples, it should be noted that implementations in accordance with some examples of the present disclosure may be applied to communications involving other types of wireless devices, including smartphones, tablet computers, notebook computers, desktop computers, gaming appliances, internet of things (IoT) devices, wearable devices (e.g., smartwatches, smart glasses, head-mounted devices, etc.), and so forth. As used herein, "UE" may refer to any wireless device. In some cases, a UE may be associated with a user, such as when the user carries or otherwise uses the UE. In other examples, a UE may refer to a wireless device that is not associated with a user when transmitting data, such as an IoT device that includes any or a combination of some of the following: sensor devices, thermostat control devices, household appliances, vehicles (or electronics in the vehicle), and the like.

Vehicles may communicate with roadside units (RSUs), such as traffic light devices (controlling traffic lights at road intersections), toll devices (for toll collection along roads), or any other type of device that may be provided along a road on which a vehicle may travel. Such communication between the vehicle and the RSU is an example of a V2I communication. More generally, an RSU may be referred to as an Intelligent Transport System (ITS) station capable of communicating with various UEs, including vehicles or other types of wireless devices. The ITS station refers to a station that provides tasks related to information and communication technology that supports and facilitates the safe and efficient transfer of people and goods, including V2X communications.

The RSU may provide road security services, such as over the 5.9GHz carrier spectrum (an unlicensed spectrum from the perspective of an LTE access network) allocated for ITS over a PC5 interface or other D2D interface. The RSU may also provide other services for the vehicle. The service provided by the RSU to the UE may be referred to as a V2X service.

Although reference is made to communication between a vehicle (or UE) and an RSU, it should be noted that implementations according to some examples of the present disclosure may be applied to other types of communication between a first wireless device and a second wireless device (or communication among more than two wireless devices), where "wireless device" may refer to a UE, a network node, or any other device capable of wireless communication.

In some cases, the UE and RSU may be controlled by different networks. In some examples, the network is a Public Land Mobile Network (PLMN). The PLMN may be identified by a Mobile Country Code (MCC) and a Mobile Network Code (MNC). The PLMN is established and operated by the network operator. Different PLMNs may be operated by different network operators, or in some cases, a network operator may operate more than one PLMN.

More generally, a "network" may refer to an arrangement of network infrastructure devices that provides a coverage area within which wireless devices can obtain services, including communication of data or other services. The networks may be operated by respective network operators. The two networks are independent or different from each other if they are operated by different network operators, or if the networks employ different radio access technologies, or if the networks are otherwise operated as different network infrastructures.

Fig. 1 shows an example arrangement involving multiple networks. In fig. 1, various UEs (including vehicles in the example of fig. 1) are depicted, wherein the UEs may communicate with respective radio access network nodes, which for LTE are referred to as evolved node bs or evolved node bs (enbs) or new generation node bs (gnbs). In the example of fig. 1, UE 102 is served by a first PLMN (PLMN-1) comprising eNB-1. Although only one eNB is shown for PLMN-1 in fig. 1, it should be noted that PLMN-1 may include multiple enbs in other examples.

Fig. 1 also shows a second PLMN, PLMN-2, which includes eNB-2 (in other examples, there may be more than one eNB-2). In the example of fig. 1, the UE 104 is served by PLMN-2. In addition, the RSU 106 is controlled by PLMN-2. In other examples, multiple RSUs may be controlled by PLMN-2.

As shown in fig. 1, UE-to-UE communication over the PC5 interface may be performed among the various UEs 102, 104 shown in fig. 1. The UE may also communicate with the RSU via a PC5 interface. The PC5 interface is an example of a direct wireless link between UEs or between a UE and another wireless device such as an RSU. The direct wireless link bypasses the network infrastructure node for data communication.

The communication link may be established between the UE and the respective eNB over a radio interface called the Uu interface, which is the radio interface between the UE and the radio access network or more specifically the E-UTRA network (E-UTRAN).

From the perspective of UE1 (one of UEs 102), PLMN-1 is the serving PLMN (also referred to as "PLMN-S") that controls the services provided to UE 1. The PLMN-S may be a home PLMN of the UE1, a visited PLMN of the UE1, or an equivalent PLMN (equivalent to the home PLMN or the visited PLMN), wherein the equivalent PLMN is identified as equivalent to another PLMN. The UE1 resides on a cell of PLMN-1 that provides various services including cellular connectivity, infotainment, etc. over the Uu interface.

when the UE1 is located in the coverage area provided by the home PLMN, the UE1 is served by the home PLMN of the UE 1. When the UE1 leaves the coverage area of the home PLMN, the UE1 may connect to the visited PLMN.

In the example of fig. 1, the PLMN-S for the UE1 is different from the PLMN controlling the RSU 106. In fig. 1, the PLMN controlling the RSU 106 is referred to as "PLMN-V", wherein the PLMN-V controls the communications performed by the RSU 106 and possibly other RSUs and associated PC 5/sidelink resources on the V2X frequency, which V2X frequency is used to provide transportation services, such as road safety services or other transportation services. PC 5/sidelink resources refer to resources such as channels, subframes, or any other frequency-based and/or time-based resources that may be used to perform sidelink communications between a UE and an RSU, or more generally, direct wireless communications between one wireless device and another wireless device.

The V2X frequency refers to a frequency or a frequency band used to perform V2X communication. For example, the V2X frequency may be part of a 5.9GHz carrier spectrum.

It should be noted that in the example of fig. 1, the PLMN-S of the UE1 does not control the PC 5/sidelink resources on the V2X frequency used to provide transport services.

In the example of fig. 1, the V2X server 110 (which may be referred to as a V2X application server in other examples) may provide V2X services to UEs through respective enbs (including eNB-1 and eNB-2). The UE 102 or 104 may communicate with the V2X server 110 through the respective eNB-1 or eNB-2.

a UE residing on or connected to an eNB in a given PLMN and a given geographic area may be preconfigured with a description of the sidelink reception and transmission resource pool used for V2X communication in that geographic area. The reception and transmission resource pools, also referred to as reception pool and transmission pool, respectively, refer to resource pools (e.g., frequency resources and/or time resources) that may be used for receiving or transmitting V2X communication data. However, the solution is not usable for coordinating sidelink resource sharing between different networks (such as different PLMNs), especially in cases where the resource configuration may change dynamically (e.g. load sharing between resources used by UEs for different PLMNs for transmission, or for congestion control).

Additionally, to transmit a message to the RSU for a given V2X service, a UE of any PLMN, while camped in a cell of that PLMN or of an equivalent PLMN, will be indicated to have V2X radio resources allocated (licensed) for sidelink communications from the UE to the RSU. According to the current LTE standard, the UE receives scheduling information identifying sidelink resource allocation (alternatively referred to as sidelink grant) through (enhanced) physical downlink control channel or (E) PDCCH of the serving cell in which the UE resides. And there is no mechanism available by which scheduling of shared sidelink resources assigned to UEs residing on different PLMNs may be distributed or dynamically coordinated among the PLMNs.

Example implementations consistent with the present disclosure enable a UE to remain connected to its serving PLMN while still being able to operate on V2X sidelink resources dynamically scheduled by different PLMNs in a coordinated manner.

Two types of RSUs are described in the current LTE standard. The first type of RSU is referred to as "UE-type RSU" and the second type of RSU is referred to as "eNB-type RSU". Fig. 2A shows an example arrangement depicting a connection between a UE a (e.g., a vehicle) and a UE-type RSU 202, which includes a UE B and a V2X application 204, the V2X application 204 referring to logic (in the form of machine-readable instructions such as software or firmware) executable by the UE B to provide V2X services. The V2X application 206 is executable on UE a. The V2X applications 204 and 206 may interact over a V5 interface, with UE a and RSU 202 communicating over a PC5 interface.

Fig. 2B shows an example arrangement depicting a connection between a UE a (e.g., a vehicle) and an eNB-type RSU 210, the eNB-type RSU 210 comprising a V2X application server 21 for providing V2X services, a local gateway (L-GW)214, and an eNB 216. The eNB216 communicates with UE a over the Uu interface. The V2X application 206 interacts with the V2X application server 212 through a V1 interface.

According to the current LTE standard, while a conventional eNB or eNB-type RSU (e.g., 210 in fig. 2B) may configure (using Radio Resource Control (RRC) signaling) and schedule (using a Media Access Control (MAC) layer) sidelink resources to a UE connected to the eNB or eNB-type RSU over a Uu interface, such interaction is not specified for or applicable to a PC5 interface between the UE-type RSU (e.g., 202 in fig. 2A) and the UE.

on the other hand, a sidelink connection is not specified or applicable between an eNB or eNB-type RSU and the UE, which is connected through the Uu interface. As shown in fig. 1, this restriction precludes certain connectivity requirements from being met in a multi-PLMN scenario.

If the V2X sidelink resources are scheduled by an eNB in the network controlling the RSU (e.g., PLMN-2 in fig. 1), it is necessary to make the RSU aware of the allocated (granted) resources for sidelink transmission from the RSU to the UE, and the configured receive pool for sidelink transmission from the UE to the RSU.

If the V2X sidelink resources are scheduled by the RSU, the UE needs to be made aware of the allocated (granted) resources for sidelink transmission from the UE to the RSU, and the configured reception pool for sidelink transmission from the RSU to the UE.

Although exchanging side link resource configuration or allocation information over the Uu interface between the UE-type RSU and the eNB may be considered, this possibility would consume radio resources in the licensed spectrum of the mobile network operator and may therefore be desirable in certain situations.

Furthermore, it should be noted that according to the current LTE standard, a UE cannot be simultaneously connected (attached) to multiple PLMNs over the Uu interface.

example implementations of the present disclosure

As shown in fig. 3, to address the problem of a UE being connected to a second network different from the first network, which controls resources for direct wireless transmissions, such as V2X transmissions, a first network node of the first network, which may be an eNB or RSU, sends a transmission configuration to a second network node of the second network in response to a request from a first UE served by the second network (at 302), where the transmission configuration relates to a configuration for use in direct wireless transmissions between the first UE and a wireless device (e.g., RSU).

The first network node further transmits (at 304) scheduling information for granting resources for use by the first UE in the direct wireless transmission. In some examples, the scheduling information may be sent by the first network node to the second network node for forwarding to the first UE. In other examples, the scheduling information may be sent by the first network node directly to the first UE.

A UE performing sidelink communications may operate in a network scheduling mode (also referred to as sidelink mode 3 in some examples). In the network scheduling mode, if the UE is not already in this state, the UE transitions to an RRC _ CONNECTED state to transfer (transmit or receive) data, wherein the RRC _ CONNECTED state is a state in which the UE has established an RRC connection with a radio access network (e.g., E-UTRAN). In addition, in the network scheduling mode, the UE requests transmission resources related to the sidelink from the network, and the network schedules resources for transmission of sidelink control information and data. Since the network controls transmissions through the PC5 interface, collision-free transmissions can be made in the network scheduling mode.

for the network scheduling mode, different types of information are provided at the transmitter side and the receiver side. In some cases, the transmitter may be a UE transmitting to an RSU (receiver). In other cases, the transmitter may be an RSU that is transmitted to the UE (receiver).

In other examples, the UE may operate in an autonomous mode (also referred to as sidelink mode 4 in some examples) in which the UE autonomously selects resources from a pool of resources and performs transport format selection to transmit sidelink control information and data.

In some embodiments, for transmissions from UEs to RSUs, different UEs are allocated resources for orthogonal transmissions between UEs to avoid collisions. A scheduler located at the network side (e.g., in the eNB or RSU) may be used and the allocated resources are transmitted to the UE. The information transmitted by the scheduler may include:

1) The transport pool configuration is referred to as "SL pool INFO" in fig. 4, 6, 8, and 9. In some examples, the transmission pool configuration may be carried in SL-comm resource pool V2X (SL communication resource pool V2X) according to 3GPP TS 36.331.

2) Resource allocation (e.g., frequency resources and/or time resources) within a transmission pool, such as, for example, information described by Downlink Control Information (DCI) format 5A according to the 3GPP TS 36.212 LTE standard. In fig. 4, 6, 8, and 9, the resource allocation may be referred to as "SL SCHEDULING".

In some examples, the scheduling information transmitted by the first network node in task 304 of fig. 3 may include the above-described resource allocation.

In addition, sidelink transmission configuration parameters may be sent to the UE, where the sidelink transmission configuration parameters may include any or a combination of the following: parameters related to Modulation and Coding Scheme (MCS), MAC configuration parameters to configure the MAC layer, one or more priority values associated with the logical channels to be used, etc. In fig. 4, 6, 8, and 9, such a sidelink transmission CONFIGURATION parameter may be referred to as "SL TX CONFIGURATION" or "SL TX CONFIGURATION".

The transmission configuration sent by the first network node in task 302 of fig. 3 may include one or more of the sidelink transmission configuration parameters described above.

for transmissions from the RSU to the UE, a scheduler located in the RSU or the controlling eNB may ensure resource orthogonality of the radio resources under its control, and each UE may determine the granted resources from the Sidelink Control Information (SCI) received from the RSU.

For reception, the receiver needs to know the resources in which the sidelink information can be received, commonly referred to as the receive pool, i.e. the resources the receiver needs to monitor. A reception pool refers to a pool of resources that a receiver uses to receive data.

According to the current LTE standard, the pool configuration information and sidelink transmission parameters may be preconfigured and/or may be provided to the UE using RRC signaling (e.g., over the Uu interface). In addition, implementing real-time scheduling may be implemented through MAC signaling (over the Uu interface) between the eNB and the UE.

In some examples, the object achieved in accordance with some examples of the disclosure is to perform any one or more of:

1) coordinating the configuration of transmission and reception resource pools used for sidelink communications between a V2X device and RSUs, the V2X device residing on different serving PLMNs.

2) The allocation (scheduling) of sidelink resources is coordinated for transmission from V2X devices residing on different serving PLMNs to the RSU.

3) If multiple RSUs with overlapping radio coverage are controlled by a given eNB, the resources for sidelink transmissions are coordinated between these RSUs and different UEs within the RSU coverage

In some examples, two different RSU architectures may be applied to example implementations according to the present disclosure:

1) One UE-type RSU (fig. 2A) that provides V2X service to a UE over a first radio interface, such as a PC5 interface, while being connected to a radio access network (eNB) over a second radio interface, such as a Uu interface. Implementation 2c discussed below addresses this RSU architecture.

2) The new hybrid RSU provides V2X services to UEs over a radio interface such as a PC5 interface (as a UE-type RSU) while connecting to enbs over a network interface such as X2 or similar interfaces (as an eNB-type RSU). Implementations 2a, 2b and 3 discussed below address this mixed type of RSU. In some examples, benefits of the hybrid RSU may include any one or more of the following. The mixed type RSU supports RSU connectivity to the neighboring eNB through the existing interface type (e.g., X2 interface). The mixed type RSU supports connectivity of the RSU with multiple networks (e.g., PLMNs). The hybrid RSU may avoid using the Uu interface on the licensed spectrum. Licensed spectrum refers to spectrum licensed by government regulatory agencies and/or standards bodies for delivery of services by a network. Unlicensed spectrum refers to spectrum that is located outside of licensed spectrum.

For simplicity, the term "pool" or "resource pool" may be used in the context of sidelink scheduling mode resource transmission to specify radio resources configured for and used by a scheduler.

implementation 1

Resources used for sidelink transmission by UEs served by different networks (e.g., PLMNs) are shared or partitioned among the different networks. The relevant pool and its corresponding frequency should be controlled by the network controlling the RSU.

A single (shared) pool or multiple pools may be used, such as for different V2X services and/or for UEs served by different PLMNs, etc. For example, a transmission pool may be divided into separate frequencies ("subchannels"), with each partition (partition) being used for transmissions by UEs served by a different PLMN. Alternatively or in combination, the pool may be divided in time (e.g., UEs of different PLMNs are allocated different subframes).

Information on how resources are coordinated, shared or divided is pre-configured (or provided) in the respective network node and UE. If dynamic adjustment of resources is provided, the dynamic resource adjustment may be signaled as: control information between network nodes (over a network interface), between a network node and a UE (e.g., over a radio interface such as the Uu interface), between an RSU and a UE, or between UEs (e.g., over a radio interface such as the PC5 interface).

One or more resource pool configuration techniques as part of implementation 1 support coordinated PC5 scheduling for UEs attached to different networks and may be used with any of implementations 2a, 2b, and 2c discussed below.

As discussed further above, both RSUs and UEs attached to different networks will be provided with information describing the pool or partition to be used for sidelink transmission and reception. This information should not typically change in a very dynamic manner. For example, a resource configuration change may be triggered by a frequency plan change, a traffic change, or a congestion condition.

One or a combination of the following technical sets may be considered for coordinating a pool or pool partition.

1) the first set of technologies may use the preconfigured or provisioned technologies described in 3GPP TS 23.285. For example, the V2X control function may be used to provide parameters to the UE to communicate using V2X. The V2X control function may provide PLMN-specific parameters to the UE that allow the UE to use V2X in a particular PLMN. The V2X control function may also be used to provide the UE with parameters that are used when the UE is not being served by the radio access network (e.g., E-UTRAN). For example, the parameters that may be provided for V2X communications over the PC5 interface may include authorization policies (related to when the UE is authorized to perform V2X communications over the PC5 interface), radio parameters (e.g., frequency bands) with geographic region(s) that will be configured in the UE to be able to perform V2X communications over the PC5 reference point when the E-UTRAN is not providing service, and so on. For example, parameters may be provided in a Universal Integrated Circuit Card (UICC) or Management Engine (ME), using Open Mobile Alliance (OMA) Device Management (DM), controlling functions over a V2X interface at V3, over an application server at V1 interface, through operations and management (O & M), through proprietary or non-standardized interfaces, and so forth.

2) The second set of techniques may use control information signaling from the network to the UE, such as:

a. the signaling from the network to the UE (case a) may include system information broadcast by the network or the PLMN (e.g., eNB) controlling the RSU. In this case, UEs attached to other networks or PLMNs may read the system information broadcast by the RSU network (using additional receivers, reading gaps of other PLMNs, PLMN reselection, etc.).

b. the signaling from the network to the UE (case b) may include system information broadcast in all cooperating networks. In this case b, the information may be transferred from the PLMN of the RSU to the other PLMNs, e.g., at the Radio Access Network (RAN) layer, through an X2 interface between enbs of different PLMNs, or through an X2 interface between the RSU and an eNB in another PLMN, through VX2 control functions between enbs of different PLMNs (e.g., using a V6 interface), through an IPX (IP packet switching) interface between networks of different service providers. In this case b, the UE does not have to read the System Information Blocks (SIBs) of the other networks.

Implementation for resource configuration (and allocation) may depend in part on whether the RSU is capable of autonomous control and configuration of the pool (or partition), or whether pool configuration is performed by controlling an eNB or other network element.

If the RSUs are able to control and configure the pool (or partition), problems may arise if geographical radio coverage areas controlled by different RSUs overlap and/or if radio frequencies configured for transmission in adjacent or overlapping areas overlap or collide. One solution to this problem is to define a location-based pool, e.g., using non-colliding radio resources assigned for transmissions in neighboring regions.

in another example, if the controlling eNB is to control and configure the pool (or partition), the eNB may coordinate the radio resources allocated to different RSUs in the eNB area to avoid resource conflicts and reduce interference.

Alternatively, self-organizing network (SON) technology or any similar adaptive technology may be used to configure sidelink resources, such as by adjusting resource bandwidth when adding or removing RSUs in the network, or depending on local load conditions.

If the sidelink resource pool must be reconfigured in a dynamic manner, a process may be introduced or enhanced to not alter the V2X transmission during the transmission pool reconfiguration (e.g., by temporarily allowing the use of an "exception pool" or other resource pool configured for this purpose). An abnormal resource pool may refer to a resource pool that is used only under certain conditions, e.g., the abnormal pool may be associated with a geographical location, or the abnormal pool may be used during movement of the UE between two neighboring cells or geographical areas.

Realization 2a

fig. 4 depicts an example arrangement to implement implementation 2a in accordance with some techniques. In implementation 2a, the sidelink scheduler 402 is included in an RSU (e.g., RSU1-V), and the sidelink scheduler 402 schedules sidelink resources for UEs of all PLMNs (e.g., PLMN-S, PLMN-V, PLMN-Z) that share RSU1-V for road safety V2X service or other types of transport service within RSU radio coverage.

The RSU1-V is controlled by the PLMN-V providing V2X services, which also controls another RSU (RSU2-V) that also includes the side link scheduler 404.

The RSU1-V is a hybrid RSU that is also connected to neighboring enbs (e.g., eNB-S as part of PLMN-S and eNB-Z as part of PLMN-Z) over an interface such as the X2 interface. In some examples, the X2 interface used may be an X2 variant that uses only a subset of the messages and processes of the mature X2 interface (e.g., the subset includes messages and processes for sidelink resource coordination).

With respect to implementation 2a, a sidelink scheduler is included in the hybrid RSU and sidelink requests and grants are transmitted via the UE' S serving eNB (e.g., eNB-S or eNB-Z).

Figure 4 also shows a UE-S served by the PLMN-S and a UE-Z served by the PLMN-Z. The UE-S may perform V2X communication with RSU1-V, while the UE-Z may perform V2X communication with RSU 2-V. The UE-S resides on or is connected to the PLMN-S for obtaining home PLMN services (e.g., entertainment or other non-secure services for non-V2X services via the Uu interface and possibly via the PC5 interface) and services provided by the V2X PLMN-V over RSU1-V over V2X frequency over PC5 interface.

In the example arrangement depicted in fig. 4, the UE-S may send a request to the eNB-S for a V2X transmission. The UE-S may also provide additional information as to whether the V2X transmission requires isolated resources (dynamic resources for a single transmission) or semi-persistent scheduling (SPS) resources (where certain allocations are repeating periodically). Thus, the eNB-S may forward the request and the additional information received from the UE-S to the RSU1-V over the respective X2 interface. Based on the received information, a sidelink scheduler (402) in the RSU1-V may configure sidelink resources and allocate a single grant or semi-persistent allocation, and transmit the configuration and scheduling information to a requesting eNB (eNB-S), which in turn forwards the corresponding information to the requesting UE (UE-S).

Fig. 4 shows RSU1-V and eNB-S that may convey a transport pool configuration called SL POOLS INFO (410). The eNB-S may forward the transmission pool configuration to the UE-S, such as by using a system information block (SIB 21) or using dedicated RRC signaling (412). Also, for example, CONFIGURATION information such as transport CONFIGURATION information may be communicated between RSU1-V and eNB-S via RRC signaling (referred to as SL TX CONFIGURATION (414)), and between eNB-S and UE-S (referred to as SL TX CONFIGURATION (418)). Further, information required in triggering and SCHEDULING sidelink resources transmitted between the RSU1-V, eNB-S and the UE-S is referred to as SL SCHEDULINGs (406) and (408).

Once the UE-S is provided with one or more transmission pool configurations (412), transmission configurations (418), and scheduling information (408), the UE-S may perform V2X sidelink transmissions (416) to RSU1-V (using the PC5 interface between the UE-S and RSU 1-V).

A similar process may be applied to V2X sidelink communications between UE-Z and RSU 2-V.

fig. 5 is a message flow diagram depicting messages and corresponding tasks exchanged among UE-S, eNB-S and RSU1-V, according to some examples. Tasks and messages are assigned reference numerals.

502: UEs (UE-S) capable of V2X side link communication are authorized and configured to use V2X services over the PC5 interface on the V2X frequency of the V2X PLMN (PLMN-V) providing link security services (or more generally V2X services). The UE-S is within the coverage area of the PLMN-S and resides on a cell served by the eNB-S. The UE is in an RRC-IDLE state (radio connection has not been established) or in an RRC _ CONNECTED state (radio connection has been established).

504: both the eNB-S of PLMN-S and the RSU1-V of PLMN-V have been pre-configured (or provided) with pool information for V2X sidelink communications. Pool information may be exchanged over an X2 interface, and may also be configured using any of the techniques described in implementation 1.

506: the UE-S obtains system information if the UE-S is in the RRC-IDLE state, such as in SystemInformationBlockType21 (systeminformationblockclass 21) broadcast by the network if the UE-S has not stored a valid version of the system information block. If the UE-S is in the RRC-CONNECTED state, the UE-S can acquire updated SIB 21 information. The UE-S identifies the V2X sidelink radio resource (pool) to be used on the network signaled V2X frequency.

508: if the UE-S is in the RRC-IDLE state, the UE-S establishes an RRC connection and enters an RRC _ CONNECTED state.

510: the UE-S initiates transmission of a sidelink indication message (referred to as a sidelink UE information message in some examples) to the eNB-S, which indicates to the network that the UE-S is interested in V2X sidelink communications on V2X frequency, and possibly includes a V2X service list.

511: the UE-S may initiate transmission of one or more additional indication messages, such as a UEAssistanceInformation message.

The sidelink indication message or one or more additional indication messages may indicate whether the UE-S is interested in dynamic sidelink transmissions, semi-persistent sidelink transmissions, or other sidelink transmission types that may be defined.

512. 513: upon receiving the indication message (the sidelink indication message and/or one or more additional indication messages) sent by the UE-S at 510 and/or 511, the eNB-S may check whether the UE-S is authorized to use the sidelink of V2X on the requested frequency and forward some or all of the information included in the received indication to the relevant RSU, e.g., RSU1-V (such as by using techniques to implement 4b discussed further below), in a second message, such as an X2 message over a corresponding X2 interface. One or more identities identifying the requesting UE (UE-S) and possibly the originating eNB (eNB-S) and/or PLMN-S may be included in the X2 message.

514: in response to the X2 message (512), the RSU1-V sends an X2 response message containing sidelink configuration information back to the requesting eNB (eNB-S) over the X2 interface. The configuration information may include information indicating the network scheduled resources that provide the resource pool to be used on the V2X frequency (if different from the resources preconfigured and broadcast by the requesting eNB). The response message may optionally include transmission configuration information such as the MCS to be used, a MAC Buffer Status Report (BSR) configuration (and/or other types of MAC configurations), or a priority value associated with the logical channel to be used. The aforementioned information may include information for the scheduled mode of operation as specified by the SL-V2X-ConfigDedcated-r 14 abstract syntax notation one (ASN.1) structure. Not all indication messages received from the eNB-S may be acknowledged by the configuration message response.

516: after receiving the X2 response message (514), the eNB-S sends a configuration message to the UE-S indicating the network scheduled resources, such as an RRCConnectionReconfiguration message. The configuration message may assign a radio identifier to the UE-S, such as SL-V-RNTI for semi-persistent scheduling (a sidelink radio network temporary identifier for V2X) or SL-V-SPS-RNTI, and may provide V2X frequencies and associated resource pools, as well as any other information that may have been received from RSU1-V (such as transmission configuration).

518: the UE-S sends information to the eNB-S, such as a side-link BSR as specified by the LTE standard, to request side link resources for transmission. The BSR procedure is triggered by the UE to report pending data in the uplink to the network node to request transmission resources. If there are no uplink resources available for transmission of the BSR, the UE may trigger a Scheduling Request (SR) procedure, which results in an uplink grant that allows transmission of the BSR.

in some implementations, the side-chain BSR is a MAC control element that includes the following fields for each reported target destination:

1) Destination index: the destination index field identifies the ProSe destination. This value is set to the index of the destination reported in the network-provided destinationinflisti (destination info list) information element. For V2X, the destinationinfisti includes V2X sidelink communication transmission(s) destination for which the UE has requested E-UTRAN in the sidelink ueinformation message to assign dedicated resources for V2X sidelink communication transmission(s).

2) LCG ID: the logical channel group ID field identifies the logical channel group(s) for which buffer status is being reported.

3) Buffer size: size of BSR buffer in UE.

520: upon receiving the side-link BSR (516), the eNB-S forwards the received BSR message (or an equivalent form containing similar information), such as an X2 message over a corresponding X2 message interface, and one or more identities defined at the 512 location or the like, in a second message to the RSU 1-V.

522: the RSU1-V allocates V2X sidelink resources to the requesting UE over the X2 interface in a message such as an X2 message and transmits scheduling information to the requesting eNB (eNB-S). In some examples, the scheduling information may be encoded according to DCI format 5A specified by the LTE standard, or according to any other form containing similar information. The RSUs 1-V may include timing and synchronization information, such as the time of the initial grant resource, and/or the offset between interconnected PLMN clock systems or System Frame Numbers (SFNs).

524: after receiving the X2 message (522), the eNB-S forwards the scheduling information received from the RSU1-V to the UE-S. In some examples, the scheduling information may be encoded according to DCI format 5A or according to another format and may be transmitted over the Uu interface on an (E) PDCCH channel with a Cyclic Redundancy Check (CRC) that is scrambled with SL-V-RNTI, SL-V-SPS-RNTI, or other identifier previously assigned. DCI format 5A may be used by an eNB to schedule transmission resources (control and data) for V2X sidelink communications in a network scheduled resource allocation mode (e.g., sidelink mode 3). The DCI may be further adapted to provide resource allocation for SPS, e.g., may include SPS process activation or deactivation commands. The DCI may include timing or synchronization information. Alternatively, the eNB-S may send the scheduling information to the UE-S within an RRC dedicated message.

526: the UE-S transmits its data over a PC5 interface on a radio channel such as a side link shared channel (SL-SCH) using resources scheduled by the RSU1-V and indicated by the serving eNB (eNB-S). In some examples, the V2X sidelink control information may be encoded according to SCI format 1 as specified by the LTE standard or an equivalent SCI format.

A specific X2 message type and format may be defined for the message sent at 512, 514, 520, or 522, or an existing message may be adapted for this purpose.

In other examples, where the UE-S sends a SidelinkUEInformation message or another message for isolated or semi-persistent transmission, variants may be considered for reducing latency. In this case, BSR information may be added to the messages (510 and 512), and in exchange, RSU1-V may allocate sidelink resources and provide scheduling information along with V2X sidelink configuration (514), which V2X sidelink configuration is forwarded to the scheduled UE (UE-S) in an RRCConnectionReconfiguration (516) message. The UE-S will then use the scheduled resources without performing tasks 518, 520, 522, and 524.

Alternatively or additionally, the messages of tasks 510 and 512 may contain additional information about the transmission for which the resource is requested. For example, the additional information may include additional QoS information, periodic transmission intervals, information size, priority or urgency attributes, low delay indicators, time periods during which cyclic resources will be required for such low delay and/or urgency priority transmissions. In this case, RSU1-V may allocate semi-persistent or over-allocated resources for certain durations and provide corresponding scheduling information in tasks 514 and 516. The UE-S may reuse the scheduled resources without performing tasks 518, 520, 522, and 524.

Alternatively or additionally, the messages of tasks 510, 511, 512, and 513 may be transmitted at different occasions or at different timings than depicted in the message flow diagram of fig. 5, for example, due to a change in the occurrence conditions of the V2X transmission, or due to a change in the transmission interval, due to a change in the size of the information, or due to a change in the transmission priority, etc.

In some examples, cross-carrier scheduling may be used by the eNB to indicate to the UE that the carrier used for V2X service is different from the frequency used by the serving PLMN (resources on the V2X carrier are scheduled by different nodes).

The sidelink resource allocation information for transmission may employ real-time information transmission between the sidelink scheduler 402 and a remote device (e.g., UE-S) using the allocated resources. Different latency requirements (and processing) may be considered, for example, for dynamic (isolated) allocation and for SPS allocation.

realization of 2b

Fig. 6 depicts an example arrangement to implement implementation 2b in accordance with some techniques. The arrangement shown in FIG. 6 is similar to the arrangement shown in FIG. 4, except that the side chain scheduler 602 is included in the eNB-V of the PLMN-V, and further in FIG. 6, each of RSU1-V and RSU2-V does not have a side chain scheduler. It should be noted that in the arrangement of FIG. 4, each of RSU1-V and RSU2-V includes a respective side link scheduler 402 or 404.

In FIG. 6, each of RSU1-V and RSU2-V is a hybrid RSU that can communicate with eNB-V over an interface such as an X2 interface.

With respect to implementation 2b, the sidelink scheduler is included in the controlling eNB controlling the hybrid RSU, while the sidelink allocation request and scheduling information is transmitted via the serving eNB (e.g., eNB-S or eNB-Z) of the UE.

in FIG. 6, an eNB-V, which is part of a PLMN-V providing V2X service, controls RSU1-V and RSU 2-V. In some examples, the eNB-V may serve one or more cells that overlap with the geographic area covered by the RSU. In the discussion that follows, the eNB-V may be referred to as a "control eNB" that schedules sidelink resources in each RSU radio coverage area for UEs of all PLMNs (e.g., PLMN-S, PLMN-V, PLMN-Z) that share RSU1-V or RSU2-V for road safety V2X service or other V2X service.

In FIG. 6, each RSU1-V or RSU2-V is configured with required pool information that is used to schedule sidelink transmissions from the UEs.

The controlling eNB (eNB-V) is connected to a neighboring eNB (eNB-S, eNB-Z) of the respective network through a network interface such as an X2 interface.

An eNB (e.g., eNB-S) in the PLMN (PLMN-S) serving the UE-S may receive a request for V2X transmissions from the UE-S, which must be isolated or SPS resources, and thus forward the request and associated information to the controlling eNB (eNB-V) over the respective X2 interface. The controlling eNB (eNB-V) may configure and allocate the corresponding sidelink resources and transmit the configuration and allocation information to the requesting eNB (eNB-S), which in turn forwards the corresponding information to the requesting UE.

In FIG. 6, SL POOLS INFO, SL TX CONGURATION (or SL TX CONFIG) and SL SCHEDULING information may be communicated between eNB-V, eNB-S and UE-S, respectively, in a manner similar to that described with respect to FIG. 4 between RSUs 1-V, eNB-S and UE-S.

fig. 7 is a message flow diagram depicting messages exchanged among UE-S, eNB-S, eNB-V and RSU1-V and corresponding tasks, according to some examples. Tasks and messages are assigned reference numerals.

Tasks and messages in fig. 7 that share the same reference numbers as fig. 5 are the same or similar to corresponding tasks or messages of fig. 5. However, in fig. 7, messages 512, 513, 514, 520, and 522 in fig. 5 are replaced with messages 712, 713, 714, 720, and 722, respectively, in fig. 7. Messages 712, 714, 720 and 722 are exchanged between the eNB-S and eNB-V in fig. 7 rather than between the eNB-S and RSU1-V as in fig. 5. The contents of messages 712, 714, 720, and 722 are similar to those of corresponding messages 512, 514, 520, and 522 in fig. 5.

Also, according to the technique of implementation 1, in FIG. 7, the UE transmission pool information (704) is similar to information 504 of FIG. 5, except that the information 704 is shared by the serving eNB of the PLMN-S (eNB-S), the controlling eNB of the PLMN-V (eNB-V) and the RSU 1-V.

in implementation 2b, the scheduling of sidelink transmissions for RSU1-V may be as follows:

1) Local to RSU 1-V. In this case, RSU transport pool configuration and associated signaling, if applicable, may be implemented according to one of the pool configuration techniques of implementation 1.

2) Provided by a controlling eNB (eNB-V) of a PLMN-V that allows coordinating sidelink scheduling for several RSUs under control of the controlling eNB (eNB-V). In this case, scheduling signaling is performed between each RSU and the control eNB, and may be similar to signaling between the serving eNB (eNB-S) and the control eNB (eNB-V) for UE resource scheduling (in this case, RSU1-V may request sidelink resources from the control eNB).

In some examples, the cross-carrier scheduling indication may be used by the eNB to indicate to the UE that the carrier used for V2X service is different from the frequency used by the serving PLMN (resources on the V2X carrier are scheduled by different nodes).

Realization 2c

Fig. 8 depicts an example arrangement to implement implementation 2c in accordance with some techniques. The arrangement shown in fig. 8 is a variation of the arrangement used for implementation 2b shown in fig. 6. However, in FIG. 8, each of the RSUs 1-V and 2-V is a UE-type RSU that communicates with the eNB-V over a respective Uu interface. The RSU1-V receives V2X sidelink information from the controlling eNB via the Uu interface instead of the X2 interface.

With respect to implementation 2c, the sidelink scheduler is included in the controlling eNB controlling the UE-type RSU, while the sidelink request assignment and scheduling information is transmitted via the serving eNB (e.g., eNB-S or eNB-Z) of the UE.

The controlling eNB (eNB-V) is connected to the neighboring enbs of the respective network through a network interface such as an X2 interface.

The message flow diagram and related sequencing and procedures for implementation 2c are the same or similar to the message flow diagram and related sequencing and procedures for implementation 2a shown in fig. 7, except that task 704 of fig. 7 is modified to communicate UE transmission pool information over the Uu interface between the controlling eNB (eNB-V) and RSU 1-V.

Implementation 3

fig. 9 depicts an example arrangement to implement implementation 3 in accordance with some techniques. In implementation 3, similar to implementation 2a, the sidelink scheduler 402 is included in RSU1-V and the sidelink scheduler 404 is included in RSU 2-V. In each RSU radio coverage area, each sidelink scheduler 402 or 404 schedules sidelink resources for UEs of all PLMNs (e.g., PLMN-S, PLMN-V, PLMN-Z) that share RSU1-V or RSU2-V, respectively, for road safety V2X service or other types of transportation service.

With regard to implementation 3, the sidelink scheduler is included in the hybrid RSU and the sidelink request and scheduling information is transmitted over the PC5 interface (i.e., the request and scheduling information may be sent directly between the RSU and the UE over a D2D radio interface such as a PC5 interface).

In implementation 3, resource allocation techniques are provided through the PC5 interface. In contrast, in implementation 2a, the resource allocation technique is provided via the serving eNB (eNB-S). In implementation 3, the UE requests sidelink resources from RSU1-V and in response, the UE is allocated sidelink resources by RSU1-V over a PC5 interface (SL SCHEDULING info 902 depicted in FIG. 9), which PC5 interface is transmitted over a radio channel such as a SL-SCH channel. The allocated sidelink resources may be described by information in a particular format (such as SCI format 1 or equivalent SCI format) directly between the RSU and the UE without having to route the request or response via the UE's serving eNB.

In implementation 3, some of the sidelink resources to be used by the UE over the PC5 interface for initial transmission and/or for subsequent resource requests may be pre-allocated by the RSU1-V and transmitted via the UE's serving eNB. Alternatively or additionally, some scheduled sidelink resources may be based on a subset of resources or (sub-) channels (e.g. signaled in a broadcast or dedicated message) predefined or configured by a standard.

In implementation 3 shown in FIG. 9, the transport pool CONFIGURATION (referred to as SL POOLS INFO) and transport CONFIGURATION information (referred to as SL TX CONFORMATION or SL TX CONFIG) are communicated between the RSU1-V, eNB-S and the UE-S.

in a variant of implementation 3, part or all of the sidelink transmission CONFIGURATION information (SL TX CONFIGURATION) may be sent over the PC5 interface (between RSU1-V and UE-S) instead of being sent over the serving eNB. The sidelink resources for transmitting control information (transmission parameters, PC5 scheduling requests) may be pre-allocated by RSU1-V or autonomously selected by UE-S. In this case, the RSU1-V may not need to be connected to different neighboring enbs of the respective PLMN.

Fig. 10 is a message flow diagram depicting messages and corresponding tasks exchanged among UE-S, eNB-S and RSU1-V, according to some examples. Tasks and messages are assigned reference numerals. Tasks 502, 504, 506, and 508 in FIG. 10 are similar to the corresponding tasks in FIG. 5.

1010: task 1010 in fig. 10 involves the UE-S sending a sidelink indication message (referred to as a SidelinkUEInformation message in some examples).

1011: similar to task 511 of fig. 5, task 1011 involves the UE-S possibly sending one or more additional indication messages to the eNB-S.

1012. 1013: tasks 1012 and/or 1013 in fig. 10 involve the eNB-S forwarding some or all of the information included in the received indication message to the RSU1-V in a second message, such as an X2 message over an X2 interface. In each of tasks 1010 and 1012, the respective message may include a logical UE identity, which may be associated with the source layer 2ID of the UE. The logical UE identity may be an authenticated identity for secure sidelink transmissions between the UE and the RSU. Each UE is assigned a layer 2ID for V2X communications over a PC5 reference point, and the layer 2ID is included in the source layer 2ID field of each frame that the UE transmits over the layer 2 link. The UE may self-assign a layer 2ID for V2X communication on the PC5 reference point. In other implementations, the logical UE identity may be assigned by the RSU and transmitted in tasks 1014 and 1016.

1014: in response to the X2 message (1012), the RSU1-V sends an X2 response message (1014) to the requesting eNB (eNB-S) over the X2 interface. The X2 response message may include information indicating a "PC 5 scheduled" mode, which may be a new sidelink mode. Alternatively, for example, if the legacy mode and the new mode cannot be used simultaneously in some scenarios, the existing "scheduled" indication may be reused.

The X2 response message (1014) may include pre-allocated link resources to be used by the UE for initial transmission on the PC5 and/or subsequent transmission such as a resource request. The pre-allocated resources may be identified by a number of parameters (e.g., one or more frequencies, resource size, whether the allocation interval is periodic, allocation time window, or grant number) and may be determined by RSU1-V based on information provided in one or more indication messages sent in tasks 1010 and 1012, which may include QoS, periodicity, minimum or maximum transmission window duration, etc.

The pre-allocated sidelink resources for one or more UEs may be located in an identified subset of sidelink resources in frequency and/or time, where the subset may be predefined or configured by applicable standards (e.g., in a broadcast or dedicated message). Thus, the resources pre-allocated to a particular UE may be indicated to the UE using an index or any other parameter or combination of parameters that uniquely indicates one or more grants in the identified subset of resources. The subset may be identified as one or more sidelink grant channels or sub-channels.

pre-allocated sidelink resources may be specified for transmitting data or control information (e.g., V2X resource requests), or both.

The X2 response message (1014) may also include pool information, MCS and MAC information (similar to task 514 in fig. 5), logical UE identity and/or other security related information.

1016: after receiving the X2 response message (1014), the eNB-S sends an RRCConnectionReconfiguration message to the UE-S, which instructs the PC5 to schedule resources, assigns the SL-V-RNTI (or SL-V-SPS-RNTI) to the UE-S, and provides additional information received from the RSU (similar to task 516 of fig. 5).

1018: if the UE-S has been allocated sidelink resources for sending only V2X resource requests, the UE-S sends a V2X resource request to request sidelink resources for data transmission, the V2X resource request indicating logical channel (S) information and associated buffer size, similar to the information contained in the sidelink BSR.

1020: the RSU1-V allocates V2X sidelink resources to the UE-S according to the received resource request and transmits a scheduling message containing scheduling information to the UE-S over the PC5 interface, e.g., on the SL-SCH channel. The scheduling message may include SPS configuration or activation information, if applicable. The V2X sidelink scheduling message may include an identity identifying the UE. This may be the source layer 2ID of the UE (or the corresponding ProSe UE ID), or any other identification that may be uniquely associated with the UE.

the scheduled sidelink resources may be specified for transmitting data or control information (e.g., V2X resource requests), or both.

1022: the scheduled UE-S transmits (1020) on the SL-SCH or on the other side link channel using the resources scheduled by RSU1-V as indicated by the serving eNB in the RRCConnectionReconfiguration message (1016) or in the scheduling information received through PC 5. The sidelink transmission (1022) from the UE-S may contain data or control information (e.g., V2X resource request), or both. The embedded resource request may be transmitted in the form of the information described for 1018, or may be a "more" request that by default applies to the previous request parameters.

The X2 message type and format may be defined for the messages sent at 1012 and 1014, or existing messages may be adapted for this purpose.

Fig. 11 shows a variant of implementation 3, which differs from the variant shown in fig. 10. In the variant of fig. 11, the sidelink configuration is sent over the PC5 interface, rather than being sent over the serving eNB, eNB-S (messages 1112, 1114, 1118, and 1120 instead of messages 1012, 1014, 1018, and 1020 in fig. 10). Further, the number of PC5 resources for transmitting control information (transmission parameters, PC5 scheduling request) may be pre-allocated by the RSU1-V or may be autonomously selected by the UE-S.

In the variation of fig. 11, the RSU1-V may not need to be connected to different neighboring enbs of the respective PLMNs.

508: it should be noted that in fig. 11, the UE-S in the RRC-IDLE state does not have to establish an RRC connection for transmission over the PC5 interface. However, the UE-S may establish an RRC connection if desired.

1112: the UE-S sends an indication message over the PC5 interface, referred to in some examples as a V2X Sidelink UE Information (V2X Sidelink UE Information) message indicating to the RSU1-V that the UE-S is interested in V2X Sidelink communications over the V2X frequency and possibly including a V2X service list. The UE-S may send an additional indication message. The one or more indication messages may be an indication of whether the UE-S is interested in dynamic, semi-persistent other sidelink transmission types that may be defined.

Additionally, the UE-S may include a logical UE identity, which may be associated with the source layer 2ID of the UE. The logical UE identity may be an authentication identity for secure sidelink transmission between the UE-S and the RSU 1-V. In other implementations, the logical UE identity may be assigned by RSU1-V and transmitted in message 1114. The UE-S may also include other security related information.

1114: in response to an indication message, such as a V2X Sidelink UE Information message, the RSU1-V sends V2X Sidelink configuration Information to the UE-S, which may include pool Information, MCS and MAC Information (similar to 514 of message fig. 5), logical UE identity and/or other security related Information.

The RSU1-V may include pre-allocated sidelink resources to be used by the UE-S for initial transmissions on the PC5 and/or subsequent transmissions such as resource requests. The pre-allocated resources may be determined by the RSU1-V based on information provided in one or more indication messages, such as sidelink UE information in message 1112.

Realization of 4a

Implementation 4a may be used in combination with the implementations described above. Implementation 4a refers to a technique to allow the sidelink scheduler to account for inter-PLMN scheduling delays. Implementations 2a, 2b and 2c introduce an additional network node (eNB-S of PLMN-S) in the data path between the side-link scheduler and the scheduled UE (UE-S).

Even though the performance of a network interface such as the X2 interface should minimize additional delay, for example for LTE advanced networks, techniques may be introduced to account for this additional delay and ensure that scheduled UEs receive DCI in time for sidelink transmissions so that the scheduled UEs can use the scheduled resources and transmit in the allocated subframes.

in some examples, the techniques may include configuring, estimating, measuring, and negotiating delay components of a transmission path including an X2 interface between different PLMNs. The technique may further include determining a shortest time before the resource is scheduled and/or a maximum transmission delay of the scheduling information such that the scheduling information is received and processed by the scheduled UE at an appropriate time for using the granted resource for sidelink transmissions.

In general, in determining the timing of the scheduling information, a sidelink scheduler (which sends scheduling information for sidelink resources used by the UE in direct wireless transmission) uses delay information related to communications over an interface between the first network and the second network.

In some examples, the following parameters and definitions are considered:

SF 1: a subframe in which scheduling information is generated and transmitted by a side-chain routing scheduler (located in an RSU or eNB of PLMN-V);

tX 2: delays in transmitting scheduling information, including inherent processing time, over an X2 interface or similar interface between a side-link scheduler (located in the RSU or eNB in PLMN-V) and a serving eNB (located in PLMN-S);

tUu: delayed transmission of DCI over a Uu interface or similar interface between a serving eNB and a UE;

rt 1: UE reaction time;

SF 2: the subframe at which the initial sidelink transmission is granted by the PC 5.

To ensure that a scheduled UE receives DCI or more generally scheduling information for sidelink transmission on time to be able to use the granted resources and transmit in the allocated sub-frame, SF2 is set in the sidelink scheduler such that:

SF2≥SF1+tX2+tUu+rt1

It will be appreciated that different formulas involving different timing components may be used to calculate the total transmission delay over the path that should be considered.

Knowing or estimating the total delay at the network node including the side-link scheduler will allow the side-link scheduler to properly determine the minimum value of SF 2. The maximum value for the different delay components (e.g., rt1) is specified or may be evaluated (e.g., tUu, tX2) and configured per interface instance or per connected PLMN.

Additionally or alternatively, techniques may be implemented to measure or estimate the delay component, for example, sending one or more "pings" or other request commands (solicitation commands) or one or more acknowledgement commands over the X2 interface for determining the round trip time and deriving the corresponding latency.

Additionally or alternatively, the maximum DCI transmission delay may be negotiated, requested or enforced by a side-chain routing scheduler to the serving eNB in the PLMN-S, more generally configured or agreed between the interacting PLMNs in order to limit the delay occurring at the Uu interface.

Realization of 4b

Implementation 4b routes UE requests or other messages to the appropriate RSU.

Since the serving eNB may be connected to several RSUs or control enbs, or the control eNB may be connected to several RSUs, UE requests or other messages may have to be routed to the appropriate RSUs or appropriate control enbs in the V2X network.

in an implementation 2a, 2b, 2c or 3, if the serving eNB (in PLMN-S) is connected to several RSUs (implementations 2a, 3) or several control enbs (implementations 2b, 2c) in PLMN-V, the serving eNB must route UE requests or other messages to the appropriate RSUs or appropriate control enbs. Similarly, where applicable, the control eNB may be connected to several RSUs, and in this case the control eNB must route UE requests or other messages to the appropriate RSUs.

For this purpose, different variants are proposed, in which the routing can be based on:

1) Is mapped to a V2X destination layer 2ID for a given V2X service. If the destination stratum 2ID value can distinguish between different RSUs within the eNB coverage area, it can be mapped to different V2X services. In this variant, the destination stratum 2ID may be identified by a field (e.g., destination index) included in the BSR, or by information associated with any message intended for a given RSU.

2) RSU source layer 2ID (or corresponding ProSe UE ID) broadcast by RSU. In this case, the RSU source layer 2ID may be sent as RRC information (e.g., within the SidelinkUEInformation message or within another RRC message). The RSU source layer 2ID may have to be updated or sent when the UE enters the coverage area of the RSU. Alternatively, the RSU source layer 2ID may be included in the SR/BSR information.

3) The current UE location. A mapping table containing geographical location information about the connected RSU or control eNB may be used to map the current UE location to the appropriate RSU or control eNB. Since it is assumed that V2X UEs within coverage must transmit location information to the network, the routing to the appropriate RSU may be based on the reported UE location. Depending on the interconnectivity architecture applicable to the implementation under consideration, the serving eNB or the controlling eNB may be configured with a mapping table containing geographical location information of the RSU (e.g., RSU geographical location and radio coverage area information such as radius or coverage area geographical description, or any other relevant information). A similar mapping table may be configured in the serving eNB containing geographical location information of the connected controlling eNB to which the solution is applicable.

Realization of 4c

The request eNB implementing 4c to PLMN-S pre-allocates a set of sidelink resources that can be used for future sidelink resource allocations.

Alternatively, or in addition to the techniques described for implementations 2a, 2b, and 2c, instead of obtaining a sidelink resource allocation for each resource request, the serving eNB may obtain a sidelink resource set from the RSU (implementation 2a) or the controlling eNB (implementation 2b or 2c) to be used by the serving eNB for future allocations to the requesting UE. In implementation 4c, a sidelink scheduler included in the RSU or in the controlling eNB, which is responsible for scheduling these sidelink resources to the requesting UE, essentially transmits ownership of the sidelink resource set to the requesting eNB on a semi-static (i.e., temporary) basis.

The set of sidelink resources may be pre-allocated by the RSU in response to receiving a sidelink resource request from an eNB of the PLMN-S, or in response to receiving a sidelink resource request for a plurality of UEs from the eNB. The set of side link resources may be used by the eNB to schedule side link resources to individual ones of the one or more UEs. With regard to implementation 4c, in response to receiving a sidelink resource request from a UE, the eNB schedules resources from within the sidelink resource set from which it has been obtained from the RSU.

The benefit of implementing 4c is that as long as the set contains free resources and is valid, full round trip delay for future resource allocation requests will be avoided. When all free resources in a previously obtained set are exhausted, or when the set is determined to no longer be valid (e.g., a resource validity time has expired), a new set may be requested and/or allocated.

Fig. 12 is a message flow diagram for implementation 4 c.

1202: the eNB sends a request for a set of sidelink resources to the RSU for future use.

1204: upon receiving a request from the eNB for sidelink resources, the RSU may employ implementation 4c depending on one or more factors, such as:

-available side link resources,

-estimated PC5 traffic load,

-traffic patterns or trends or other information provided by the eNB,

-traffic patterns or request history observed at the RSU,

-estimated, calculated or configured delay or timing components of transmissions between RSU node and UE (see implementation 4a),

-a time window configured or requested for multiple allocations,

-and so on.

similarly, implementation 4c may be employed by the eNB based on the following factors:

-a current sidelink resource request frequency from one or more UEs,

-future estimated side link resource requirements,

Indicating a number of UEs interested in sidelink service (e.g., UEs indicating sidelink interest or V2X interest indication),

QoS, priority, PPPP (ProSe per packet priority) of traffic from the UE currently interested in the sidelink,

-and so on.

1204: in response to a request from the eNB, the RSU sends scheduling information for the set of sidelink resources to the eNB for use in processing future sidelink requests from the UE. The scheduling information may include an identification for a set of sidelink resources and validity information for each sidelink resource. The set of sidelink resources obtained by the eNB may comprise a pool of resources that are valid for a specified duration. The resource pool may comprise a set of frequency subchannels or a set of subframes or a combination of both. The resource pool may contain periodic or aperiodic resources.

1206: the eNB stores the set of sidelink resources received from the RSU in a storage medium of the eNB. The eNB may also store the validity information side link resources in the set.

1208: the UE sends a first sidelink resource request to the eNB.

1210: in response to receiving the first sidelink resource request from the UE, the eNB may determine whether the request may be serviced by using resources from a sidelink resource set received from the RSU.

1212: the eNB may transmit scheduling information from a set of sidelink resources in response to a first sidelink resource request from the UE if the resources may be served using the set of sidelink resources. The eNB may mark resources scheduled to the UE as authorized or used.

1214: the UE sends a second sidelink resource request to the eNB.

1216: in response to receiving the second sidelink resource request from the UE, the eNB may determine whether the second sidelink request may be serviced by using resources from a set of sidelink resources received from the RSU.

1218: if not, e.g. because all resources from the set have been used or their validity time has expired, the eNB may send a new sidelink resource request for new sidelink resources from the RSU.

1220: in response to the request sent at 1218, the RSU sends a sidelink resource grant to the eNB.

1222: in response to the second sidelink resource request from the UE, the eNB forwards a sidelink resource grant to the UE.

the eNB and/or RSU may fall back to the non-pre-allocated resource allocation mode when the conditions for using the above techniques are no longer met.

System/device architecture

Fig. 13 is a block diagram of a communication device 1300, which may be any of the following: a UE, RSU, radio access network node (e.g., eNB), or other network node. The communication device 1300 includes a processor 1302 (or multiple processors). The processor may comprise a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit.

The communication device 1300 further includes a non-transitory machine-readable or computer-readable storage medium 1304 storing machine-readable instructions executable on the processor 1302 to perform specified tasks. Instructions executable on a processor may refer to instructions executable on a single processor or multiple processors.

In some examples, the machine-readable instructions include side link resource management instructions 1306 that are executable on the processor 1302 to perform the tasks described above.

The communication device 1300 further includes a communication transceiver 1308, which can be a wireless transceiver (e.g., a radio frequency or RF transceiver) that communicates over a wireless network, or a wired transceiver that communicates over a wired network.

The storage medium 1304 may include any or some combination of the following: semiconductor memory devices such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks such as fixed, floppy, and removable disks; another magnetic medium, including magnetic tape; optical media such as Compact Discs (CDs) or Digital Video Discs (DVDs); or other types of storage devices. It should be noted that the instructions discussed above may be provided on one computer-readable or machine-readable storage medium, or may be provided on multiple computer-readable or machine-readable storage media distributed in a large system, possibly with multiple nodes. Such computer-readable or machine-readable storage media are considered to be part of an article (or article of manufacture). An article or article of manufacture may refer to any manufactured component or components. The one or more storage media may reside within a machine that executes the machine-readable instructions, or may be located at a remote site where the machine-readable instructions are downloaded over a network for execution.

In the previous description, numerous details were set forth to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations in accordance with the details discussed above. It is intended that the appended claims cover such modifications and variations.

Claims (20)

1. A method, comprising:

Sending, by a first network node of a first network, a transmission configuration to a second network node of a second network in response to a request from a User Equipment (UE), the UE served by the second network, the transmission configuration relating to a configuration used for direct wireless transmission between the UE and a wireless device; and

Transmitting, by the first network node, scheduling information granting resources for use by the UE in the direct wireless transmission.

2. The method of claim 1, wherein the scheduling information is sent to the second network node for forwarding to the UE.

3. The method of claim 2, wherein the first network node is the wireless device, the wireless device comprising a scheduler that generates the scheduling information.

4. the method of claim 3, wherein the wireless device is a roadside unit (RSU).

5. The method of claim 3, wherein the direct wireless transmission comprises a sidelink transmission.

6. The method according to claim 2, wherein the first network node is a base station comprising a scheduler generating the scheduling information.

7. The method of claim 6, wherein the wireless device is a roadside unit (RSU) served by the second network.

8. the method of claim 7, wherein the RSU is to communicate with the base station over an X2 interface.

9. The method of claim 7, wherein the RSU is to communicate with the base station over a Uu interface.

10. The method of claim 1, wherein the scheduling information is sent by the first network node directly to a UE.

11. The method of claim 1, wherein the transmission configuration comprises one or more of: parameters relating to a Modulation and Coding Scheme (MCS), MAC configuration parameters to configure a Medium Access Control (MAC) layer, and priority values associated with logical channels to be used.

12. The method of claim 1, wherein the scheduling information comprises one or more of: frequency resources, time resources, scheduling intervals, and scheduling durations.

13. The method of claim 1, further comprising:

Sending, by the first network node, resource pool information to the second node, the resource pool information relating to a pool of resources provided by the first network for direct wireless transmission.

14. The method of claim 1, further comprising:

Using, by a scheduler that transmits the scheduling information, delay information relating to communication over an interface between the first network and the second network when determining timing of the scheduling information that is granted for resources used by the UE in the direct wireless transmission.

15. The method of claim 1, further comprising:

selecting, by the second network node, the first network node from among a plurality of network nodes based on a factor; and

Routing, by the second network node, the request from the UE to the first network node.

16. The method of claim 1, further comprising:

Indicating, by the first network node to the second network node, a set of resources for use by the second network node when granting a request from a UE for resources to perform direct wireless transmissions with the wireless device.

17. A User Equipment (UE), comprising:

A wireless transceiver to communicate with a wireless device; and

At least one processor configured to:

sending a request for resources to be processed by a scheduler in a first network node of a first network;

Receiving, in response to the request from the UE, a transmission configuration from a second network node of a second network, the UE served by the second network, the transmission configuration relating to a configuration used for direct wireless transmission between the UE and the wireless device; and

receiving scheduling information granting the resources for use by the UE in the direct wireless transmission.

18. The UE of claim 17, wherein the direct wireless transmission is a vehicle-to-anything (V2X) sidelink transmission.

19. The UE of claim 17, wherein the second network node is a base station serving the UE, and the first network node is a base station of the second network or a roadside unit (RSU) served by the second network.

20. A first network node of a first network, comprising:

A wireless transceiver to communicate with a User Equipment (UE), the UE connected to a second network node of a second network; and

At least one processor configured to:

Receiving a request for resources over a direct wireless link between the first network node and the UE;

Sending a transmission configuration to the UE over the direct wireless link, the transmission configuration relating to a configuration used for direct wireless transmission between the UE and the first network node; and

Transmitting scheduling information to the UE over the direct wireless link, the scheduling information granting the resources for use by the UE in the direct wireless transmission.