WO2017051381A1

WO2017051381A1 - Systems, methods, and apparatuses for reducing delay for sidelink transmissions

Info

Publication number: WO2017051381A1
Application number: PCT/IB2016/055716
Authority: WO
Inventors: Mattias Tan Bergström; Mats Folke; Marco BELLESCHI
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2015-09-25
Filing date: 2016-09-23
Publication date: 2017-03-30

Abstract

A method performed by a network node for reducing delay for sidelink transmissions is disclosed. The method comprises receiving a random access preamble from a user equipment (UE). The method further comprises sending a random access response message to the UE, where the random access response message includes a grant for uplink transmission. This grant for uplink transmission is an extended grant that is large enough to include an uplink buffer status report (BSR) and a sidelink BSR.

Description

SYSTEMS, METHODS, AND APPARATUSES FOR REDUCING DELAY FOR

SIDELINK TRANSMISSIONS

TECHNICAL FIELD

Embodiments presented herein relate to wireless communications, and in particular to methods, network nodes, wireless devices, computer programs, or computer program products for reducing delay for sidelink transmissions.

BACKGROUND D2D

Device-to-device (D2D) communication (which may interchangeably be referred to herein as proximity services (ProSe) or sidelink communication) is a widely used component of many existing wireless technologies, including ad hoc and cellular networks. Examples include Bluetooth and several variants of the IEEE 802.1 1 standards suite, such as WiFi Direct. These systems operate in unlicensed spectrum.

Recently, D2D communications as an underlay to cellular networks have been proposed as a means to take advantage of the proximity of communicating devices and at the same time to allow devices to operate in a controlled interference environment. Typically, it is suggested that such D2D communications share the same spectrum as the cellular system, for example by reserving some of the cellular uplink resources for D2D purposes. Another possibility is allocating dedicated spectrum for D2D purposes. Allocating dedicated spectrum for D2D purposes is a less likely alternative, however, as spectrum is a scarce resource and (dynamic) sharing between the D2D services and cellular services is more flexible and provides higher spectrum efficiency.

Devices that want to communicate, or even just discover each other, typically need to transmit various forms of control signalling. One example of such control signalling is the so-called (discovery) beacon signal, which at least carries some form of identity and is transmitted by a device that wants to be discoverable by other devices. Other devices can scan for the beacon signal and, once they have detected the beacon, can take appropriate action— such as trying to initiate a connection setup with the device transmitting the beacon. For certain communication modes (such as connectionless communication, which is typically employed for group-cast and broadcast transmission), the beacon signal might carry a scheduling assignment indicating the associated data transmission to potential receivers. Connectionless communication is typically a unidirectional communication mode that does not require acknowledged connection setup. The ProSe Study Item 3GPP TR 36.843 v12.0.1 recommends supporting D2D operation for out-of-network coverage user equipment (UEs). In such a case, different synchronization options are possible. As one example, UEs may synchronize to a global reference (e.g., a GPS), which is in general different from the synchronization reference of deployed networks. As another example, UEs may operate in a fully asynchronous fashion (i.e., no synchronization reference, at least for discovery). Yet another option is that clusters of UEs may synchronize to a specific UE (in the following referred to as Cluster Head (CH)), which provides local synchronization to its neighbor UEs. Different clusters are not necessarily synchronized. If out of network coverage synchronization is based on sync signals transmitted by CHs, it is necessary that UEs synchronize to the suitable synchronization reference (i.e., CH). A number of procedures may be considered, with some similarities to cell search in cellular networks, in which idle UEs search for sync signals from different cells and synchronize to, for example, the cell with the best signal strength. Similarly, ProSe enabled out of network coverage UEs might synchronize to the strongest CH in proximity.

UEs may discover unsynchronized beacons on a given carrier (or sub-band) by searching for discovery beacons in time over their configured/predefined resources. This can be done, for example, by time domain correlation of the received signal with the beacon's waveforms, similar to the way UEs search for cells using primary/secondary synchronization signals (PSS/SSS). UEs alternate wake-up and sleep cycles for reducing power consumption (i.e., discontinuous reception (DRX)). During sleep periods, only the memory and clocks are active, but the UE is unable to receive any signal. During wake-up time, the receiver is on. It is essential that the wake-up time periods are as narrow as possible compared to the sleep time in order to save battery.

Looking at coverage in a bit more detail, there are three different primary cases. In the first case, all communicating UEs are within network coverage. In this case, the network also controls the D2D communication, such as synchronization, scheduling, etc. In the next case, all communicating UEs are outside network coverage. In this context, out-of-coverage may mean that the UE is unable to successfully communicate with any cellular network which may act as support to ProSe operations, but other definitions of out-of-coverage are possible. In the out-of-coverage case, the UEs will mostly rely on pre-configured information (i.e., information that was obtained when the UE was connected to a network). With the use of beacons and scheduling requests/grants, other information is exchanged, such as synchronization and resources to use. A third case, partial coverage, results when some of the communicating UEs are within network coverage and some are not. A difficult case occurs when the receiving UE is within coverage (including either case that the transmitting UE is in or out-of-coverage). In such a case, it may be that the receiving UE communicated on the UL with the eNB; communication which will prevent the UE from receiving the broadcast from the UE out of coverage.

To better coordinate interference, the scheduling of D2D transmissions can be coordinated by the eNB when UEs are in network coverage. In order for the eNB to better assign a correct amount of transmission resources, the UEs send Sidelink buffer status reports (BSRs) to the eNB. A similar mechanism exists for coordination of uplink transmissions. The Sidelink BSR contains information about the amount of data currently available for transmission on the sidelink interface. As the UE may have some data available for transmission on the sidelink interface as well as some data available for transmission on the uplink interface, there may be occurrences when the UE transmits both a Sidelink BSR and an ordinary BSR that contains information about the amount of data currently available for transmission on the uplink. According to previous approaches, a UE performs buffer status reporting serially (i.e., the UE performs buffer status reporting for uplink and then sidelink, or vice versa, with only one buffer status report per MAC PDU). Such an approach may have certain deficiencies. For example, performing buffer status reporting serially delays network awareness of UE status, and may cause a service delay as a result of requesting/allocating resources for the UE's uplink data followed by the sidelink data. If the UE has triggered one Sidelink BSR and one ordinary BSR, but does not have enough radio resources to transmit both, it will prioritize the transmission of the ordinary BSR. V2X communication

D2D communication has paved the way to V2X (vehicle-to-X) communications, which includes any combination of direct communication between vehicles, pedestrians, and network infrastructure. The following traffic types are included in the V2X framework:

• V2V (vehicle-to-vehicle): covering LTE-based communication between vehicles.

• V2P (vehicle-to-pedestrian): covering LTE-based communication between a vehicle and a device carried by an individual (e.g. handheld terminal carried by a pedestrian, cyclist, driver or passenger).

· V2I/N (vehicle-to-infrastructure/network): covering LTE-based communication between a vehicle and a roadside unit/network. In particular, a roadside unit (RSU) is a transportation infrastructure entity (e.g. an entity transmitting speed notifications, or traffic lights) implemented in an eNodeB or a stationary UE. Compared with ProSe communications, that are mainly designed to support voice services and operate in low load scenarios, V2X communications are expected to support a different variety of traffic types (V2X/P/I/N) with different message sizes, priority, and periodicity. For example, according to ETSI, an Intelligent Transport System should be capable of generating periodic messages for non-critical traffic advertisements (e.g. queue warning, parking information, etc.), as well as event- triggered messages for road safety services where the packet delay budget requirements as well as the packet error loss rate should be quite stringent.

Additionally, high mobility and high load scenarios have to be taken into account in a V2X system. Random access

In LTE, as in any communication system, a mobile terminal may need to contact the network (e.g., via the eNodeB) without having a dedicated resource in the Uplink (from UE to base station). To handle this, a random access procedure is available where a UE that does not have a dedicated UL resource may transmit a signal to the base station. The first message (MSG1 or preamble) of this procedure is typically transmitted on a special resource reserved for random access, a physical random access channel (PRACH). This channel can for instance be limited in time and/or frequency (as in LTE). See Figure 1. The resources available for PRACH transmission are provided to the terminals as part of the broadcasted system information (or as part of dedicated RRC signalling in case of e.g. handover).

In LTE, the random access procedure can be used for a number of different reasons. Among these reasons are, without limitation:

. Initial access (for UEs in the RRCJDLE or EMM_DEREGISTERED states)

• Incoming handover

• Resynchronization of the UL

• Scheduling request (for a UE that is not allocated any other resource for contacting the base station)

• Positioning

The contention-based random access (CBRA) procedure used in LTE is illustrated in Figure 2. The UE starts the random access procedure by randomly selecting one of the preambles available for contention-based random access. The UE then transmits the selected random access preamble on the physical random access channel (PRACH) to eNode B in the network.

The network acknowledges any preamble it detects by transmitting a random access response (MSG2) including an initial grant to be used on the uplink shared channel, a temporary C-RNTI, and a time alignment (TA) update based on the timing offset of the preamble measured by the eNodeB on the PRACH. The MSG2 is transmitted in the DL to the UE and its corresponding PDCCH message CRC is scrambled with the RA- RNTI.

When receiving the random access response (MSG2) the UE uses the grant to transmit a message (MSG3) that in part is used to trigger the establishment of radio resource control and in part to uniquely identify the UE on the common channels of the cell. Besides, depending on the size of the grant provided in MSG2, the UE can also fill the MSG3 with MAC control elements (e.g. BSR, PHR, etc.) and possibly data.

The timing advance command provided in the random access response is applied in the UL transmission in MSG3. The eNB can change the resource blocks that are assigned for a MSG3 transmission by sending an UL grant that's CRC is scrambled with the Temporary C-RNTI. The MSG4 which is then contention resolution has its PDCCH CRC scrambled with the C-RNTI if the UE previously has a C-RNTI assigned. If the UE does not have a C- RNTI previously assigned, its PDCCH CRC is scrambled with the Temporary C-RNTI.

The procedure ends with the network solving any preamble contention that may have occurred for the case that multiple UEs transmitted the same preamble at the same time. This can occur since each UE randomly selects when to transmit and which preamble to use. If multiple UEs select the same preamble for the transmission on PRACH, there will be contention between these UEs that needs to be resolved through the contention resolution message (MSG4). The case when contention occurs is illustrated in Figure 3, where two UEs transmit the same preamble, s, at the same time. A third UE also transmits at the same RACH, but since it transmits with a different preamble, pi , there is no contention between this UE and the other two UEs.

The UE can also perform non-contention based random access. A non-contention based random access or contention free random access (CFRA) can e.g. be initiated by the eNB to get the UE to achieve synchronization in UL. The eNB initiates a contention-free random access either by sending a PDCCH order or indicating it in an RRC message. The latter of the two is used in case of HO.

The eNB can also order the UE through a PDCCH message to perform a contention based random access; the procedure for this is illustrated in Figure 2. The procedure for the UE to perform contention free random access is illustrated in Figure 4. Similar to the contention based random access the MSG2 is transmitted in the DL to the UE and its corresponding PDCCH message CRC is scrambled with the RA-RNTI. The UE considers the contention resolution successfully completed after it has received MSG2 successfully. For the contention free random access, as for the contention based random access, the MSG2 contain a timing alignment value. This enables the eNB to set the initial/updated timing according to the UE's transmitted preamble.

In LTE in Rel-10 the random access procedure is limited to the primary cell only. This implies that the UE can only send a preamble on the primary cell. Further MSG2 and MSG3 are only received and transmitted on the primary cell. MSG4 can however in Rel-10 be transmitted on any DL cell.

In LTE Rel-1 1 random access procedures are supported also on secondary cells, at least for the UEs supporting Rel-11 carrier aggregation. So far only network initiated random access on SCells is assumed.

The approaches discussed above all create additional delay, as the Sidelink BSR would be transmitted after the ordinary (uplink) BSR. This is because, typically, both cannot be fitted in MSG3 in the RA procedure.

Regarding V2X, even though 3GPP has not agreed yet on whether enhancements to the BSR mechanism are needed or not, latency issues may be of critical importance in a V2X framework. For instance, event-triggered messages that are generated for road safety purposes could need to fulfil strict latency requirements. Additionally, in V2X, latency might be negatively affected by mobility and high load.

SUMMARY

To address the foregoing problems with existing solutions, disclosed are methods in a user equipment and network node. Also disclosed is a user equipment and a network node. In this disclosure, for simplicity we will use ProSe terminology (e.g. SL BSR, SL grant, etc), but the described concept is applicable to V2X scenarios as well.

According to certain embodiments, a method performed by a network node for reducing delay for sidelink transmissions is disclosed. The method comprises receiving a random access preamble from a user equipment (UE). The method further comprises sending a random access response message to the UE, where the random access response message includes a grant for uplink transmission. This grant for uplink transmission is an extended grant that is large enough to include an uplink buffer status report (BSR) and a sidelink BSR.

According to additional embodiments, a method performed by a user equipment (UE) for reducing delay for sidelink transmissions is disclosed. The method comprises selecting a random access preamble from a plurality of sets of random access preambles. The method further comprises sending the selected random access preamble to a network node, and receiving a random access response message from the network node. The random access response message includes a grant for uplink transmission, wherein the size of the grant for uplink transmission is based on the set from which the random access preamble is selected.

According to additional embodiments, a method performed by a network node for reducing delay for sidelink transmissions is disclosed. The method comprises receiving a random access preamble from a user equipment and sending a random access response message to the UE. The random access response message includes a grant for uplink transmission. The method further comprises receiving a scheduled transmission from the UE, using the grant for uplink transmission, wherein the scheduled transmission does not include a sidelink buffer status report (BSR). The method further comprises determining from the scheduled transmission that the UE may have sidelink data available for transmission, and sending a sidelink grant to the UE.

According to additional embodiments, a method performed by a user equipment (UE) for reducing delay for sidelink transmissions is disclosed. The method comprises applying a first prioritization scheme for transmitting data when the UE has uplink data available for transmission or has a triggered uplink buffer status report (BSR). Otherwise, the method comprises applying a second prioritization scheme for transmitting data.

According to additional embodiments, a network node for reducing delay for sidelink transmissions is disclosed. The network node comprises processing circuitry and a memory. The memory contains instructions executable by the processing circuitry, whereby said network node is operative to receive a random access preamble from a user equipment (UE). The network node is further operative to send a random access response message to the UE, the random access response message including a grant for uplink transmission. The grant for uplink transmission is an extended grant that is large enough to include an uplink buffer status report (BSR) and a sidelink BSR. According to additional embodiments, a user equipment (UE) for reducing delay for sidelink transmissions is disclosed. The UE comprises processing circuitry and a memory. The memory contains instructions executable by the processing circuitry, whereby said UE is operative to select a random access preamble from a plurality of sets of random access preambles. The UE is further operative to send the selected random access preamble to a network node and receive a random access response message from the network node. The random access response message includes a grant for uplink transmission, wherein the size of the grant for uplink transmission is based on the set from which the random access preamble is selected.

According to additional embodiments, a network node for reducing delay for sidelink transmissions is disclosed. The network node comprises processing circuitry and a memory. The memory contains instructions executable by the processing circuitry, whereby said network node is operative to receive a random access preamble from a user equipment (UE). The network node is further operative to send a random access response message to the UE, the random access response message including a grant for uplink transmission. The network node is further operative to receive a scheduled transmission from the UE, using the grant for uplink transmission, wherein the scheduled transmission does not include a sidelink buffer status report (BSR). The network node is further operative to determine from the scheduled transmission that the UE may have sidelink data available for transmission, and send a sidelink grant to the UE.

According to additional embodiments, a user equipment (UE) for reducing delay for sidelink transmissions is disclosed. The UE comprises processing circuitry and a memory. The memory contains instructions executable by the processing circuitry, whereby said UE is operative to apply a first prioritization scheme for transmitting data when the UE has uplink data available for transmission or has a triggered an uplink buffer status report (BSR). Otherwise, the UE is operative to apply a second prioritization scheme for transmitting data.

The proposed solutions target both UE-centric and eNB-centric approaches such as 1) Increasing the size of the UL grant to allow transmission of both UL BSR and SL BSR in msg 3.

2) Separate sets of the RA preamble for the UE to very early indicate that it has sidelink data available.

3) Expedited sidelink grant, the eNB sends a sidelink grant before receiving the SL BSR.

4) Prioritization of the sidelink BSR over the UL BSR if the UE has no UL data available. Advantageously, one or more of the proposed solutions reduce the delay from the UE triggering an SL BSR until it receives the SL grant from the eNB. The proposed solutions are also beneficial in the context of V2X to reduce latency. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, attached claims, and drawings. Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the element, apparatus, component, means, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the disclosed embodiments and their features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which: Figure 1 is a schematic illustration of random-access-preamble transmission;

Figure 2 is a flow diagram illustrating signalling over the air interfaced for contention- based random access procedures;

Figure 3 is a schematic illustration of contention-based random access;

Figure 4 is a flow diagram illustrating signalling over the air interface for contention- free random access procedures;

Figure 5 is a block diagram illustrating an embodiment of a network, in accordance with certain embodiments;

Figure 6 is a flow chart of a network-based method, in accordance with certain embodiments; Figure 7 is a flow chart of a network-based method, in accordance with certain embodiments;

Figure 8 is a flow chart of a UE-assisted method, in accordance with certain embodiments;

Figure 9 is a flow chart of a network-based method, in accordance with certain embodiments;

Figure 10 is a flow chart of a UE-assisted method, in accordance with certain embodiments;

Figure 11 is a block schematic of an exemplary user equipment, in accordance with certain embodiments; Figure 12 is a block schematic of an exemplary network node, in accordance with certain embodiments; and Figure 13 is a block schematic of an exemplary radio network controller or core network node, in accordance with certain embodiments.

DETAILED DESCRIPTION

Some of the embodiments contemplated by the claims will now be described more fully hereinafter with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the claims and the claims should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description.

As described above, the proposed solutions may reduce the delay from the UE triggering an SL BSR until it receives the SL grant from the eNB, and may also be beneficial in reducing latency in the context of V2X. Figure 5 is a block diagram illustrating an embodiment of a network 100, in accordance with certain embodiments of this disclosure. Network 100 includes one or more UE(s) 1 10 (which may be interchangeably referred to as wireless devices 110), network node(s) 115 (which may be interchangeably referred to as eNodeBs (eNBs) or base stations 115). UEs 110 may communicate with network nodes 115 over a wireless interface. For example, UE 11 OA may transmit wireless signals to one or more of network nodes 115, and/or receive wireless signals from one or more of network nodes 1 15. The wireless signals may contain voice traffic, data traffic, control signals, and/or any other suitable information. In some embodiments, an area of wireless signal coverage associated with a network node 1 15 may be referred to as a cell. In some embodiments, UEs 1 10 may have D2D capability. Thus, UEs 1 10 may be able to receive signals from and/or transmit signals directly to another UE. For example, UE 11 OA may be able to receive signals from and/or transmit signals to UE 110D. In certain embodiments, network nodes 115 may interface with a radio network controller (not shown). The radio network controller may control network nodes 115 and may provide certain radio resource management functions, mobility management functions, and/or other suitable functions. In certain embodiments, the functions of the radio network controller may be performed by network node 115. The radio network controller may interface with a core network node. In certain embodiments, the radio network controller may interface with the core network node via an interconnecting network. The interconnecting network may refer to any interconnecting system capable of transmitting audio, video, signals, data, messages, or any combination of the preceding.

In some embodiments, the core network node may manage the establishment of communication sessions and various other functionalities for UEs 1 10. In some embodiments, the core network node may manage the establishment of communication sessions and various other functionality for UEs 110. UEs 1 10 may exchange certain signals with core network node using the non-access stratum (NAS) layer. In non-access stratum signalling, signals between UEs 1 10 and the core network node may be transparently passed through the radio access network. In certain embodiments, network nodes 1 15 may interface with one or more network nodes over an internode interface. For example, network nodes 115A and 115B may interface over an X2 interface.

In some embodiments, the non-limiting term UE is used. UEs 1 10 described herein can be any type of wireless device capable of communicating with network nodes 1 15 or another UE over radio signals. UE 1 10 may also be a radio communication device, target device, device-to-device (D2D) UE, machine-type-communication UE or UE capable of machine to machine communication (M2M), a sensor equipped with UE, iPad, Tablet, mobile terminal, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongle, Customer Premises Equipment (CPE), etc. Also, in some embodiments, generic terminology, "radio network node" (or simply "network node") is used. It can be any kind of network node, which may comprise a base station, radio base station, base transceiver station, base station controller, network controller, evolved Node B (eNB), Node B, relay node, access point, radio access point, Remote Radio Unit (RRU), Remote Radio Head (RRH), or any other suitable network node. Example embodiments of UEs 110, network nodes 115, and other network nodes (such as radio network controller or core network node) are described in more detail with respect to Figures 11 , 12, and 13, respectively.

Although Figure 5 illustrates a particular arrangement of network 100, the present disclosure contemplates that the various embodiments described herein may be applied to a variety of networks having any suitable configuration. For example, network 100 may include any suitable number of UEs 1 10 and network nodes 1 15, as well as any additional elements suitable to support communication between UEs or between a UE and another communication device (such as a landline telephone). Furthermore, although certain embodiments may be described as implemented in an LTE network, the embodiments may be implemented in any appropriate type of telecommunication system supporting any suitable communication standards and using any suitable components, and are applicable to any radio access technology (RAT) or multi-RAT systems in which the UE receives and/or transmits signals (e.g., data). For example, the various embodiments described herein may be applicable to LTE FDD/TDD, WCDMA/HSPA, GSM/GERAN, Wi Fi, WLAN, CDMA2000, or any other suitable RAT.

As described above, there are basically three different D2D communication coverage scenarios: an in-network coverage scenario; a partial-coverage scenario; and an out- of-coverage scenario. In the in-network coverage scenario, the communicating UEs 110 are within network coverage. In this case, the network also controls the D2D communication, such as synchronization, scheduling, etc. There are two types of resource allocation schemes for ProSe communication when in coverage: mode 1 and mode 2. By mode 1 , UE 1 10 requests resources for sidelink transmission from a network node 115. For example, UE 11 OA may request resources for sidelink transmission from network node 115A. By mode 2, UE 1 10 selects resources for transmission from a known resource pool.

In some cases, when operating according to mode 1 , a UE 110, such as UE 11 OA, may request different resources from network node 115A depending on what data is in UE buffer. For example, if UE 11 OA has only sidelink data in buffer, UE 11 OA may only request sidelink resources. If UE 1 10A has only uplink (UL) (e.g., LTE) data in buffer, UE 11 OA may only request UL resources. If UE 11 OA has both UL and sidelink data in buffer, UE 1 10A may request both UL and sidelink resources.

According to current specifications, during a random access procedure a UE first sends a random access preamble to the eNB. Upon reception of the preamble the eNB responds with a random access response (RAR) message including a grant for uplink transmission to the UE, a timing advance command and a Temporary C-RNTI. The UL grant provided to a UE in RAR is typically small. The reason for this is that the eNB will not know at this point in time whether and how much data the UE has to transmit. Hence, to avoid wasting of radio resources, the grant is usually small and set to a size allowing the UE to send only essential information such as a power headroom report (PHR) and a buffer status report (BSR).

In case a UE is operating on a sidelink channel, e.g. the UE is D2D-capable. Then when the sidelink data arrives the UE will trigger a Sidelink-BSR which in its turn will trigger the UE to send a Scheduling Request (SR) which in its turn will trigger the UE to perform a Contention Based Random Access procedure. It should be noted that when it herein says that the UE has no UL data available to transmit this may only refer to certain types of data. For example, it may only consider data which has been delivered to a MAC entity from an RLC and/or PDCP entity, and not data which has been generated in the MAC entity itself. This means that the UE may for example not consider MAC Control Elements as "data available for transmission."

Network based approach

Below will be described various embodiments relating to a network-based approach. Extended grants in RAR

In certain embodiments, the network will provide larger/extended grants in the RAR to ensure that the UE will be able to fit a SL-BSR in following transmission. This will allow the eNB to know whether and how much sidelink data the UE has in its buffers. With this information the eNB will have knowledge about whether the UE needs a sidelink grant and also how large this sidelink grant needs to be.

For instance, a method 600, according to particular embodiments, is shown in Figure 6. The method begins at step 602, when a network node may receive a random access preamble from a UE. At step 604, the network node sends a random access response message to the UE. This random access response message may include a grant for uplink transmission. Furthermore, the grant may be large enough so that the UE may use it for both a normal, uplink buffer status report and a sidelink buffer status report. By contrast, UL grants are usually only big enough to allow the UE to send only essential information such as a power headroom report (PHR) and a buffer status report (BSR). Thus, the UL grant provided in step 604 may be referred to as an extended UL grant. According to additional particular embodiments, at step 606, the network node may receive a sidelink BSR from the UE, using the extended UL grant. In step 608, the network node then determines from the sidelink BSR the amount of sidelink data that the UE has in its buffers for transmission. Then, in step 610, the network node sends a sidelink grant to the UE. The size of this sidelink grant may be based on the amount of sidelink data in the UE's buffers, as determined at step 608.

A drawback of these approaches is that if a certain UE does not need to send a SL- BSR, e.g. if the UE is not capable of sidelink communication or the UE is capable of sidelink communication but currently does not have any sidelink data available for transmission, in this case radio resources would be wasted by providing an extended grant to the UEs.

It should be noted that the eNB does not necessarily know when receiving a random access preamble, whether the UE sending the preamble is capable of sidelink communication or not. Hence the eNB may need to send an extended grant to all UEs, including UEs which are not capable of sidelink communication. According to particular embodiments, the network node may attempt to prevent and/or reduce the number of unnecessary extended grants that are sent in these situations. For instance, Figure 7 shows a method 700, wherein the network node receives a random access preamble from the UE in step 702. At step 704, the network node attempts to determine if the preamble is from a set used by UEs that are actually capable of sidelink data and/or from a set used by UEs which actually have sidelink data available for transmission. If yes 706 to either or both of these conditions, the network node may provide an extended uplink grant as discussed previously. If no 708, no extended uplink grant is provided. One way the network node can make this determination is based on whether the D2D UE capable of sidelink communication has been previously configured with periodical sidelink BSR reporting. If so, the eNB would know when the UE sends the preamble, it is due to the existence of an SL BSR, and hence that the UE could need an SL grant. This can be used as one way to limit the extended grants to only D2D-capable UEs.

Separate sets of preambles

Below will be described how separate preamble sets are used and the UE selects a preamble from this pool in case it is capable of sidelink communication and/or the UE has sidelink data available for transmission.

Figure 8 illustrates a method 800 performed by a UE, according to various particular embodiments. At step 802, the UE selects a random access preamble from a plurality of sets of random access preambles. At step 804, the UE sends the selected random access preamble to a network node. Then, at step 806, the UE receives a random access response message from the network node. This random access response message may include a grant for uplink transmission. The grant may be large enough so that the UE may use it for both a normal, uplink buffer status report and a sidelink buffer status report. Thus, the UL grant provided in step 806 may be referred to as an extended UL grant. Furthermore, the actual size of the extended grant may be based on the set of preambles from which the random access preamble was selected in step 802.

In response to the eNB receiving a preamble from such a preamble set, the eNB would have more information. For example, the eNB would know that the UE sending the preamble is capable of sidelink communication and/or the UE sending the preamble has sidelink data available for transmission.

With this information the eNB could determine whether to send an extended grant in RAR, e.g. only send an extended grant in response to preambles belonging to a certain set.

Separate set of preambles for sidelink capable UEs

In one embodiment a certain set of preambles are only used by UEs which are capable of sidelink communication and hence the eNB will know that if a preamble from this set is received then it would be a UE capable of sidelink communication which has sent the preamble. Thus, according to particular embodiments, the eNB may only provide extended grants in response to preamble transmissions from this set.

This has the benefit that the eNB will know that if a preamble is received from this set, then the UE which sent the preamble is capable of sidelink communication and hence such a UE may have sidelink data available for transmission, while if a preamble from another set is received then the UE would not be capable of sidelink communication and hence would not have sidelink data available for transmission.

Therefore, the eNB may provide an extended grant in the RAR for a preamble transmission coming from this set, but not for preambles of another set as UEs using the preambles of the other set will not have sidelink data available for transmission. Hence only extended grants are needed to be sent in response to preambles of the set used by sidelink capable UEs.

However, the approach of having a separate set of preambles for sidelink capable UEs has the limitation that the eNB will not know whether UE actually has data to transmit. Separate set of preambles for UEs having sidelink data to transmit

In another embodiment, a certain set of preamble are used by UEs which have sidelink data available for transmission and/or which has a triggered SL-BSR. The eNB will then know that a preamble received from this set indicates that the UE which transmitted the preamble. Similar to the embodiments discussed above, the eNB will know that if a preamble is received from this set, then the UE actually has data available for transmission, while a preamble from a different set does not have any data to transmit (even if the UE is capable). Thus, the eNB would only provide an extended grant for a preamble transmission coming from this set, but not for preambles of another set. Separate set of preambles - conditions on using

In the embodiments where a separate set of preambles is used, as described above, it is important to not make this set too large as any preamble reserved for this set would in practice be occupied and cannot be used by other UEs (e.g. UEs not capable of sidelink communication or UEs not having sidelink data available). However, the set should also be large enough to avoid excessive collisions by UEs using the preambles in this set.

In one embodiment a UE would only use a preamble from the separate set if the sidelink data available for transmission meets certain criteria. This ensures that preambles from this set are only applied when critical and hence, since the preambles from such a set are not used unnecessarily, the set can be made smaller.

Examples of criteria are provided in the list below. According to particular embodiments, a set is selected if one or more of these items, in any suitable combination, is satisfied: · Available sidelink data is above a threshold T. The threshold T may be specified in a specification, determined by the UE itself or signalled to the UE by the network (e.g. using RRC signalling). The eNB can then know that the UE needs at least a grant which is of size T if the UE has sent a preamble from the separate set.

· The available sidelink data has certain delay requirements. In case the sidelink data has strict delay requirements, i.e. needs to be transmitted before a relatively short time, then it is more critical that the eNB quickly provides a sidelink grant as otherwise the UE may not be able to transmit the data within the delay budget. One way to determine this is to use the PPPP (ProSe per packet priority) of the data. That way, the UE can be allowed to use the preamble from the separate set if it has a certain amount of data corresponding to a PPPP of high priority. In V2X, besides PPPP, any other tag referring to traffic type (e.g. V2V/I/P/N), message type/priority/periodicity (e.g. event- triggered, periodic messages) can be taken into account to select the preamble set. For instance, only event-triggered messages (that are more sensitive to latency) are allowed to select a separate preamble set.

• The available sidelink data is destined to be sent to a certain receiver (or group or receivers), e.g. a certain ProSe destination, etc. Data which should be transmitted to different receivers may be considered to have different priorities, hence the UE may only use preambles if the UE has sidelink data to transmit to a certain (group of) receiver(s).

• The UE is of a certain type, e.g. the UE is a relay UE or a normal UE. Expedited sidelink grant

While with some embodiments the eNB will be aware of whether the UE has sidelink data available for transmission as an extended grant has been used and hence a SL- BSR could have been included in message 3. However, as explained above, this has the limitation that extended grants in RAR must be signalled which in some cases may result in resource waste in case an extended grant is sent to a UE not having sidelink data to transmit (and hence not having a SL-BSR to transmit).

In one embodiment the eNB will, without having received a SL-BSR in message 3, determine that a UE has sidelink data available for transmission. This is illustrated in the method 900 of Figure 9. At step 902, the eNB receives a random access preamble from the UE. Then, at step 904, the eNB sends a random access response message, including a grant for uplink transmission, to the UE. At step 906, the eNB receives a scheduled transmission from the UE, using the UL grant sent at step 904. This scheduled transmission does not include a sidelink buffer status report. At step 908, the eNB determines, based on the transmission received at 906, that the UE may have sidelink data available for transmission. Based on this determination, the eNB sends a sidelink grant to the UE at step 910.

The eNB may make the determination of step 908 in a variety of ways. According to particular embodiments, it may make this determination by receiving in a message 3 (which is small enough to not fit a SL-BSR) only a UL-BSR which indicates that no UL- data is available for transmission. This could imply that the SR which triggered the preamble was send due to an SL-BSR has been triggered.

The eNB could, upon determining that the UE has SL-data available for transmission, send an SL-grant to the UE (without having received an SL-BSR).

It should be noted with this approach, i.e. sending a SL-grant to a UE without having received an SL-BSR, does not allow the eNB to know how much SL-data the UE has available for transmission hence the size of the SL-grant could not be done on how much sidelink data is available for transmission. Because sidelink communication is typically designed for VoIP, existing algorithms for buffer estimation can be reused as a way to determine the size of the SL grant without having received the SL BSR. Also in case of V2X communications, it is expected that message size is typically fixed both for periodic and event-triggered messages. Therefore, a default grant size can be provided to the UE on the basis of typical messages size payload. As such, a SL grant (of default size or of size indicated by a buffer estimator) can be provided by the eNB in case Sidelink BSR or SR has not been received for a certain amount of time. This can help to reduce latency when the SR (or Sidelink BSR) is not received due to interference in high mobility/load scenarios. To further refine this approach the eNB can configure UEs capable of sidelink communication with periodical sidelink BSR reporting. This way, when the UE sends the preamble, it is most likely due to the existence of an SL BSR, that can be taken as an additional indication to the UE having SL data available.

UE assisted approach

Below will be described various embodiments relating to a UE-assisted approach, as shown in Figure 10.

According to current LTE specifications (3GPP TS 36.321 v12.6.0) the UE shall prioritize transmissions according to the following:

Table 1 : Example of first prioritization.

For the Logical Channel Prioritization procedure, the MAC entity shall take into account the following relative priority in decreasing order:

- MAC control element for C-RNTI or data from UL-CCCH;

- MAC control element for BSR, with exception of BSR included for padding;

- MAC control element for PHR, Extended PHR, or Dual Connectivity PHR;

- MAC control element for Sidelink BSR, with exception of Sidelink BSR included for padding;

- data from any Logical Channel, except data from UL-CCCH;

- MAC control element for BSR included for padding;

- MAC control element for Sidelink BSR included for padding.

In the illustrated embodiment the UE applies a first prioritization (1004) in case the UE has UL-data available for transmission (or a triggered UL-BSR or the type of triggered UL-BSR) (1002) and a second prioritization (1006) is applied otherwise. The first prioritization may be as in the table above and the second prioritization is illustrated below (the difference illustrated with bold and underlined text).

Table 2: Example second prioritization.

- MAC control element for C-RNTI or data from UL-CCCH;

- MAC control element for PHR, Extended PHR, or Dual Connectivity PHR;

- MAC control element for BSR, with exception of BSR included for padding;

- data from any Logical Channel, except data from UL-CCCH;

- MAC control element for BSR included for padding;

- MAC control element for Sidelink BSR included for padding.

This would ensure that if the UE has triggered e.g. a periodic UL-BSR and a Sidelink- BSR, but the UE has no UL-data available for transmission (i.e. the periodic UL-BSR would indicate zero), the UE would prioritize the Sidelink-BSR for inclusion in a transmission. Hence, the UE may include a Sidelink-BSR in message 3 instead of including an UL-BSR.

Figure 1 1 is a block schematic of an exemplary user equipment (UE) 110, configured to perform the various methods in accordance with certain embodiments described above. UE 110 may refer to any type of wireless device communicating with a node and/or with another UE in a cellular or mobile communication system. Examples of UE 110 include a mobile phone, a smart phone, a PDA (Personal Digital Assistant), a portable computer (e.g., laptop, tablet), a sensor, a modem, a machine-type- communication (MTC) device / machine-to-machine (M2M) device, laptop embedded equipment (LEE), laptop mounted equipment (LME), USB dongles, a D2D capable device, or another device that can provide wireless communication. A UE 110 may also be referred to as UE, a station (STA), a device, or a terminal in some embodiments. UE 110 includes transceiver 1 110, processor 1120, and memory 1 130. In some embodiments, transceiver 1110 facilitates transmitting wireless signals to and receiving wireless signals from network node 1 15 (e.g., via an antenna), processor 1120 executes instructions to provide some or all of the functionality described above as being provided by UE 110, and memory 1130 stores the instructions executed by processor 1120. Processor 1120 may include any suitable combination of hardware and software implemented in one or more modules to execute instructions and manipulate data to perform some or all of the described functions of UE 110. In some embodiments, processor 1 120 may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more applications, and/or other logic.

Memory 1130 is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a processor. Examples of memory 1 130 include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information.

Other embodiments of UE 1 10 may include additional components beyond those shown in Figure 11 that may be responsible for providing certain aspects of the wireless device's functionality, including any of the functionality described above and/or any additional functionality (including any functionality necessary to support the solution described above).

In certain embodiments, UE 110 may include one or more modules (not pictured). For example, UE 110 may include a determining module, a communication module, a receiver module, an input module, a display module, and any other suitable modules. The determining module may perform the processing functions of UE 110. The determining module may include or be included in processor 1 120. The determining module may include analog and/or digital circuitry configured to perform any of the functions of the determining module and/or processor 1120. The functions of the determining module described above may, in certain embodiments, be performed in one or more distinct modules.

The communication module may perform the transmission functions of UE 1 10. The communication module may transmit messages to one or more of network nodes 115 of network 100. The communication module may include a transmitter and/or a transceiver, such as transceiver 1 110. The communication module may include circuitry configured to wirelessly transmit messages and/or signals. In particular embodiments, the communication module may receive messages and/or signals for transmission from the determining module. The receiving module may perform the receiving functions of UE 1 10. The receiving module may include a receiver and/or a transceiver. The receiving module may include circuitry configured to wirelessly receive messages and/or signals. In particular embodiments, the receiving module may communicate received messages and/or signals to the determining module. The input module may receive user input intended for UE 1 10. For example, the input module may receive key presses, button presses, touches, swipes, audio signals, video signals, and/or any other appropriate signals. The input module may include one or more keys, buttons, levers, switches, touchscreens, microphones, and/or cameras. The input module may communicate received signals to the determining module. The display module may present signals on a display of UE 1 10. The display module may include the display and/or any appropriate circuitry and hardware configured to present signals on the display. The display module may receive signals to present on the display from the determining module.

Figure 12 is a block schematic of an exemplary network node 115, configured to perform the various methods in accordance with certain embodiments described above. Network node 1 15 may be any type of radio network node or any network node that communicates with a UE and/or with another network node. Examples of network node 1 15 include an eNodeB, a node B, a base station, a wireless access point (e.g., a Wi-Fi access point), a low power node, a base transceiver station (BTS), relay, donor node controlling relay, transmission points, transmission nodes, remote RF unit (RRU), remote radio head (RRH), multi-standard radio (MSR) radio node such as MSR BS, nodes in distributed antenna system (DAS), O&M, OSS, SON, positioning node (e.g., E-SMLC), MDT, or any other suitable network node. Network nodes 1 15 may be deployed throughout network 100 as a homogenous deployment, heterogeneous deployment, or mixed deployment. A homogeneous deployment may generally describe a deployment made up of the same (or similar) type of network nodes 1 15 and/or similar coverage and cell sizes and inter-site distances. A heterogeneous deployment may generally describe deployments using a variety of types of network nodes 115 having different cell sizes, transmit powers, capacities, and inter-site distances. For example, a heterogeneous deployment may include a plurality of low- power nodes placed throughout a macro-cell layout. Mixed deployments may include a mix of homogenous portions and heterogeneous portions.

Network node 115 may include one or more of transceiver 1210, processor 1220, memory 1230, and network interface 1240. In some embodiments, transceiver 1210 facilitates transmitting wireless signals to and receiving wireless signals from UE 1 10 (e.g., via an antenna), processor 1220 executes instructions to provide some or all of the functionality described above as being provided by a network node 115, memory 1230 stores the instructions executed by processor 1220, and network interface 1240 communicates signals to backend network components, such as a gateway, switch, router, Internet, Public Switched Telephone Network (PSTN), core network nodes 130, radio network controllers 120, etc.

Processor 1220 may include any suitable combination of hardware and software implemented in one or more modules to execute instructions and manipulate data to perform some or all of the described functions of network node 1 15. In some embodiments, processor 1220 may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more applications, and/or other logic. Memory 1230 is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a processor. Examples of memory 1230 include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information.

In some embodiments, network interface 1240 is communicatively coupled to processor 1220 and may refer to any suitable device operable to receive input for network node 115, send output from network node 115, perform suitable processing of the input or output or both, communicate to other devices, or any combination of the preceding. Network interface 1240 may include appropriate hardware (e.g., port, modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate through a network.

In certain embodiments, network node 115 may include a determining module, a communication module, a receiving module, and any other suitable modules. In some embodiments, one or more of the determining module, communication module, receiving module, or any other suitable module may be implemented using one or more processors 1220 of Figure 9. In certain embodiments, the functions of two or more of the various modules may be combined into a single module.

The determining module may perform the processing functions of network node 115. The determining module may include or be included in processor 1220. The determining module may include analog and/or digital circuitry configured to perform any of the functions of the determining module and/or processor 1220. The functions of the determining module described above may, in certain embodiments, be performed in one or more distinct modules.

The communication module may perform the transmission functions of network node 115. The communication module may transmit messages to one or more of UEs 110. The communication module may include a transmitter and/or a transceiver, such as transceiver 1210. The communication module may include circuitry configured to wirelessly transmit messages and/or signals. In particular embodiments, the communication module may receive messages and/or signals for transmission from the determining module or any other module. The receiving module may perform the receiving functions of network node 1 15. The receiving module may receive any suitable information from a UE. The receiving module may include a receiver and/or a transceiver. The receiving module may include circuitry configured to wirelessly receive messages and/or signals. In particular embodiments, the receiving module may communicate received messages and/or signals to the determining module or any other suitable module.

Other embodiments of network node 115 may include additional components beyond those shown in Figure 12 that may be responsible for providing certain aspects of the radio network node's functionality, including any of the functionality described above and/or any additional functionality (including any functionality necessary to support the solutions described above). The various different types of network nodes may include components having the same physical hardware but configured (e.g., via programming) to support different radio access technologies, or may represent partly or entirely different physical components.

Figure 13 is a block schematic of an exemplary radio network controller or core network node 130, in accordance with certain embodiments. Examples of network nodes can include a mobile switching center (MSC), a serving GPRS support node (SGSN), a mobility management entity (MME), a radio network controller (RNC), a base station controller (BSC), and so on. The radio network controller or core network node 130 include processor 1320, memory 1330, and network interface 1340. In some embodiments, processor 1320 executes instructions to provide some or all of the functionality described above as being provided by the network node, memory 1330 stores the instructions executed by processor 1320, and network interface 1340 communicates signals to any suitable node, such as a gateway, switch, router, Internet, Public Switched Telephone Network (PSTN), network nodes 1 15, radio network controllers or core network nodes 130, etc. Processor 1320 may include any suitable combination of hardware and software implemented in one or more modules to execute instructions and manipulate data to perform some or all of the described functions of the radio network controller or core network node 130. In some embodiments, processor 1320 may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more applications, and/or other logic.

Memory 1330 is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a processor. Examples of memory 1330 include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information. In some embodiments, network interface 1340 is communicatively coupled to processor 1320 and may refer to any suitable device operable to receive input for the network node, send output from the network node, perform suitable processing of the input or output or both, communicate to other devices, or any combination of the preceding. Network interface 1340 may include appropriate hardware (e.g., port, modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate through a network.

Other embodiments of the network node may include additional components beyond those shown in Figure 13 that may be responsible for providing certain aspects of the network node's functionality, including any of the functionality described above and/or any additional functionality (including any functionality necessary to support the solution described above).

The steps described above are merely illustrative of certain embodiments. It is not required that all embodiments incorporate all the steps above nor that the steps be performed in the exact order depicted in the Figures. Certain aspects of the inventive concept have mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, embodiments other than the ones discussed above are equally possible and within the scope of the inventive concept, as defined by the appended claims. Moreover, as is understood by the skilled person, the herein disclosed embodiments are as such applicable also to other standards and communication systems and any feature from a particular figure disclosed in connection with other features may be applicable to any other figure and or combined with different features.

Claims

1. A method performed by a network node (115) for reducing delay for sidelink transmissions, the method comprising:

receiving (602) a random access preamble from a user equipment (UE) (1 10); and

sending (604) a random access response message to the UE (1 10), the random access response message including a grant for uplink transmission;

wherein the grant for uplink transmission is an extended grant that is large enough to include an uplink buffer status report (BSR) and a sidelink BSR.

2. The method according to claim 1 , further comprising:

receiving (606) a sidelink BSR from the UE (110), using the extended grant; determining (608) from the sidelink BSR an amount of sidelink data the UE (1 10) has in its buffers for transmission;

sending a (610) sidelink grant to the UE (1 10), wherein the size of the sidelink grant is based on the amount of sidelink data determined from the sidelink BSR.

3. The method according to claim 1 , further comprising:

determining, based on the random access preamble, whether the UE (1 10) has previously been configured for sidelink BSR reporting; and

wherein the extended grant is only provided if the UE (1 10) has previously been configured for sidelink BSR reporting.

4. A method performed by a user equipment (UE) (110) for reducing delay for sidelink transmissions, the method comprising:

selecting (802) a random access preamble from a plurality of sets of random access preambles;

sending (804) the selected random access preamble to a network node (115); and

receiving (806) a random access response message from the network node

(115), the random access response message including a grant for uplink transmission; wherein the size of the grant for uplink transmission is based on the set from which the random access preamble is selected.

5. The method according to claim 4, wherein the set from which the random access preamble is selected is only used for UEs which are capable of sidelink communication; and

6. The method according to claim 4, wherein the set from which the random access preamble is selected is only used for UEs which have sidelink data available for transmission; and

7. The method according to claim 6, wherein the set is only selected if one or more of the following criteria are satisfied:

amount of sidelink data is greater than or equal to a threshold value;

the available sidelink data includes an indication of strict delay requirements; the available sidelink data is destined for one or more prioritized receivers; and the UE (110) is a prioritized type of UE.

8. The method according to claim 4, wherein the set from which the random access preamble is selected is only used for UEs which have a triggered sidelink buffer status report (BSR); and

wherein the grant for uplink transmission is an extended grant that is large enough to include an uplink buffer status report BSR and a sidelink BSR.

9. A method performed by a network node (115) for reducing delay for sidelink transmissions, the method comprising:

receiving (902) a random access preamble from a user equipment (UE) (1 10); and

sending (904) a random access response message to the UE (1 10), the random access response message including a grant for uplink transmission; receiving (906) a scheduled transmission from the UE (110), using the grant for uplink transmission, wherein the scheduled transmission does not include a sidelink buffer status report (BSR);

determining (908) from the scheduled transmission that the UE (110) may have sidelink data available for transmission;

sending (910) a sidelink grant to the UE (110).

10. The method according to claim 9, wherein the scheduled transmission is a UL- BSR indicating that no UL data is available for transmission.

11. The method according to claim 9, wherein the size of the sidelink grant is a default value based on typical message size payload.

12. The method according to claim 9, wherein the size of the sidelink grant is estimated.

13. The method according to claim 9, wherein the determining step is based on not receiving a Sidelink BSR or Scheduling Request (SR) within a particular amount of time.

14. A method performed by a user equipment (UE) (1 10) for reducing delay for sidelink transmissions, the method comprising:

applying (1004) a first prioritization scheme for transmitting data when the UE (110) has uplink data available for transmission or has a triggered uplink buffer status report (BSR); and

otherwise applying (1006) a second prioritization scheme for transmitting data.

15. The method according to claim 14, wherein the first prioritization scheme takes into account the following in decreasing order of priority:

MAC control element for Cell Radio Network Temporary Identifier (C-RNTI) or data from Uplink Common Control Channel (UL-CCCH);

MAC control element for BSR, with exception of BSR included for padding; MAC control element for Power Headroom Report (PHR), Extended PHR, or Dual Connectivity PHR;

MAC control element for sidelink BSR, with exception of sidelink BSR included for padding;

data from any Logical Channel, except data from UL-CCCH;

MAC control element for BSR included for padding; and

MAC control element for sidelink BSR included for padding; and wherein the second prioritization scheme takes into account the following in decreasing order of priority:

MAC control element for C-RNTI or data from UL-CCCH;

MAC control element for PHR, Extended PHR, or Dual Connectivity PHR; MAC control element for BSR, with exception of BSR included for padding; Data from any Logical Channel, except data from UL-CCCH;

MAC control element for BSR included for padding; and

MAC control element for sidelink BSR included for padding.

16. A network node (115) for reducing delay for sidelink transmissions, the network node comprising:

processing circuitry (1220); and

a memory (1230), the memory (1230) containing instructions executable by the processing circuitry (1220), whereby said network node (115) is operative to:

receive (602) a random access preamble from a user equipment (UE) (110); and

send (604) a random access response message to the UE (1 10), the random access response message including a grant for uplink transmission;

17. The network node (1 15) according to claim 16, wherein the network node (115) is further operative to:

receive (606) a sidelink BSR from the UE (1 10), using the extended grant; determine (608) from the sidelink BSR an amount of sidelink data the UE (1 10) has in its buffers for transmission;

send (610) a sidelink grant to the UE (110), wherein the size of the sidelink grant is based on the amount of sidelink data determined from the sidelink BSR.

18. The network node (1 15) according to claim 16, wherein the network node (115) is further operative to:

determine, based on the random access preamble, whether the UE (110) has previously been configured for sidelink BSR reporting; and

19. A user equipment (UE) (110) for reducing delay for sidelink transmissions, the UE (110) comprising:

processing circuitry (1120); and

a memory (1130), the memory (1 130) containing instructions executable by the processing circuitry (1120), whereby said UE (1 10) is operative to:

select (802) a random access preamble from a plurality of sets of random access preambles;

send (804) the selected random access preamble to a network node (115); and

receive (806) a random access response message from the network node (115), the random access response message including a grant for uplink transmission; wherein the size of the grant for uplink transmission is based on the set from which the random access preamble is selected.

20. The UE (1 10) according to claim 19, wherein the set from which the random access preamble is selected is only used for UEs which are capable of sidelink communication; and

21. The UE (110) according to claim 19, wherein the set from which the random access preamble is selected is only used for UEs which have sidelink data available for transmission; and

22. The UE (110) according to claim 21 , wherein the set is only selected if one or more of the following criteria are satisfied:

amount of sidelink data is greater than or equal to a threshold value;

23. The UE (1 10) according to claim 19, wherein the set from which the random access preamble is selected is only used for UEs which have a triggered sidelink buffer status report (BSR); and

24. A network node (115) for reducing delay for sidelink transmissions, the network node (1 15) comprising:

processing circuitry (1220); and

receive (902) a random access preamble from a user equipment (UE)

(110); and

send (904) a random access response message to the UE (1 10), the random access response message including a grant for uplink transmission;

receive (906) a scheduled transmission from the UE (110), using the grant for uplink transmission, wherein the scheduled transmission does not include a sidelink buffer status report (BSR); determine (908) from the scheduled transmission that the UE (110) may have sidelink data available for transmission; and

send (910) a sidelink grant to the UE (110).

25. The network node (1 15) according to claim 24, wherein the scheduled transmission is an uplink BSR indicating that no uplink data is available for transmission.

26. The network node (115) according to claim 24, wherein the size of the sidelink grant is a default value based on typical message size payload.

27. The network node (115) according to claim 24, wherein the size of the sidelink grant is estimated.

28. The network node (115) according to claim 24, wherein the determining step is based on not receiving a Sidelink BSR or Scheduling Request (SR) within a particular amount of time.

29. A user equipment (UE) (110) for reducing delay for sidelink transmissions, the UE (110) comprising:

processing circuitry (1120); and

apply (1004) a first prioritization scheme for transmitting data when the UE (110) has uplink data available for transmission or has a triggered an uplink buffer status report (BSR); and

otherwise applying (1006) a second prioritization scheme for transmitting data.

30. The UE (1 10) according to claim 29, wherein the first prioritization scheme takes into account the following in decreasing order of priority:

MAC control element for Cell Radio Network Temporary Identifier (C-RNTI) or data from Uplink Common Control Channel (UL-CCCH); MAC control element for BSR, with exception of BSR included for padding;

MAC control element for Power Headroom Report (PHR), Extended PHR, or Dual Connectivity PHR;

data from any Logical Channel, except data from UL-CCCH;

MAC control element for BSR included for padding; and

MAC control element for C-RNTI or data from UL-CCCH;

MAC control element for PHR, Extended PHR, or Dual Connectivity PHR;

MAC control element for BSR, with exception of BSR included for padding;

Data from any Logical Channel, except data from UL-CCCH;

MAC control element for BSR included for padding; and

MAC control element for sidelink BSR included for padding.