WO2021007802A1

WO2021007802A1 - Sidelink connection management based on an end-of-data indication

Info

Publication number: WO2021007802A1
Application number: PCT/CN2019/096342
Authority: WO
Inventors: Tao Chen; Nathan Edward Tenny
Original assignee: Mediatek Singapore Pte. Ltd.
Priority date: 2019-07-17
Filing date: 2019-07-17
Publication date: 2021-01-21

Abstract

Under current design assumptions on the NR sidelink, there is no periodic reference signal that is always sent; reference signals may, for example, accompany user traffic, and during periods with no traffic, there may be no corresponding reference signal. The present invention provides apparatus and methods for the Rx UE to distinguish these two cases and declare RLF appropriately when the link has been lost, while maintaining the link during periods of traffic inactivity when it has no basis to infer that the link quality has degraded. In some embodiments, methods of connection management between two UEs interacting over a sidelink interface are proposed. The described methods use an indication of the end of expected data, potentially together with a supervisory timer, to achieve substantially synchronous management of the connection between two peer UEs.

Description

SIDELINK CONNECTION MANAGEMENT BASED ON AN END-OF-DATA INDICATION

TECHNICAL FIELD

The disclosed embodiments relate generally to wireless communication, and, more particularly, to sidelink connection management.

BACKGROUND

The NR sidelink interface, also known as the PC5 interface, connects two user equipments (UEs) directly, without passing through a base station (e.g. a gNB) . The sidelink interface may be used to carry a variety of services, including unicast services between a single pair of peer UEs. When traffic is sent from one UE to another as part of a service, the peer UEs may be referred to as the transmitting UE (Tx UE) and the receiving UE (Rx UE) .

In the existing art, the Rx UE monitors the condition of the radio link between the two UEs, primarily by evaluating the reception of reference signals (RSs) sent by the Tx UE. If the RSs are received with sufficiently poor signal-and-interference-to-noise ratio (SINR) , the Rx UE may declare an out-of-sync (OOS) condition, while if the RSs are received with a good SINR, the Rx UE may declare an in-sync (IS) condition. Indications of the IS or OOS condition, referred to as IS/OOS indications, may be delivered from a lower protocol layer of the Rx UE (for example, a physical (PHY) layer) to an upper layer of the Rx UE (for example, a radio resource control (RRC) layer) , and the upper layer may be responsible for determining when the IS/OOS indications justify declaring a condition of radio link failure (RLF) . The IS/OOS indications may be delivered periodically or aperiodically. This process of monitoring the radio conditions may be referred to as radio link monitoring (RLM) .

The RSs on the sidelink interface are not necessarily transmitted periodically; for instance, they may be transmitted in association with user traffic, and not transmitted when there is no user traffic. Such an aperiodic transmission scheme poses a challenge for RLM, because if the Rx UE measures extremely poor SINR, it cannot easily infer whether this means that RSs were sent but lost over the air (indicating bad link conditions) , or that no RSs were sent at all (in which case the link condition may be good) . The present invention describes methods of data transmission on the sidelink interface that facilitate effective RLM during periods when no traffic is transmitted.

SUMMARY

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, where like numerals indicate like components, illustrate embodiments of the invention.

Figure 1 illustrates indication of data of data inactivity from Tx UE to Rx UE in accordance with embodiments of the current invention.

Figure 2 illustrates indication of no RS when no data are expected in accordance with embodiments of the current invention.

Figure 3 illustrates RLF due to loss of traffic without an indication of traffic end in accordance with embodiments of the current invention.

Figure 4 illustrates operation of the inactivity timer in accordance with embodiments of the current invention.

Figure 5 illustrates handling of configured grant validity time in accordance with embodiments of the current invention.

Figure 6 shows an exemplary block diagram of a UE in accordance with embodiments of the current invention.

DETAILED DESCRIPTION

Reference will now be made in detail to some embodiments of the invention, examples of which are illustrated in the accompanying drawings.

The current design of the NR sidelink is described in 3GPP TR 38.885, specifically its application to vehicle-to-everything (V2X) communication. Access stratum aspects of the LTE sidelink are specified in several documents, with connection management aspects concentrated notably in 3GPP TS 36.300 and 3GPP TS 36.331.

RLM operation and RLF declaration on the NR Uu interface are described in 3GPP TS 38.300 and 3GPP TS 38.331. The very similar RLM operation and RLF declaration on the LTE Uu interface are described in 3GPP TS 36.300 and 3GPP TS 36.331.

Under current design assumptions on the NR sidelink, there is no periodic reference signal that is always sent; reference signals may, for example, accompany user traffic, and during periods with no traffic, there may be no corresponding reference signal. As noted above, this creates a challenge for radio link monitoring (RLM) on the sidelink, since the Rx UE cannot easily distinguish loss of the connection from an absence of traffic-both situations may result in a period of no reference signals being received. The present invention provides methods for the Rx UE to distinguish these two cases and declare RLF appropriately when the link has been lost, while maintaining the link during periods of traffic inactivity when it has no basis to infer that the link quality has degraded.

As described above, RLM as performed by the Rx UE on the sidelink interface comprises monitoring the condition of RSs that may be transmitted along with data traffic (or control/data channels) , with the resulting IS/OOS indications informed to upper protocol layers of the Rx UE. In a service with a bursty data pattern, there may be periods when no data are transmitted by the Tx UE, and the Rx UE cannot easily distinguish these periods from loss of the link, since both conditions result in poor SINR readings when the Rx UE attempts to detect the RSs. Here, RS for RLM may comprise one or multiple RSs including DMRS in the control/data channel, CSI-RS, and PSS/SSS/PBCH-DMRS if Tx UE is a sync source.

The upper layers of the protocol stack may exchange keep-alive signalling, which prevents a connection from being seen as inactive and released by the upper layers while the service is still in progress. This keep-alive signalling may be accompanied by RSs, allowing the Rx UE to measure the quality of the link when the keep-alive message is sent. However, Rx UE may not know exactly when to expect a keep-alive message, meaning that it is difficult to distinguish a situation of poor link quality from a situation where the keep-alive message has not been sent yet. (For example, the keep-alive message may be sent with a certain minimum periodicity, but with no guarantee of its exact scheduling. ) Furthermore, because the keep-alive message incurs signalling overhead, it may be desirable to transmit it infrequently; accordingly, the RSs accompanying the keep-alive messages may not be dense enough to provide a good model of the link quality, and so the RLM system may need to operate on a shorter time scale than the transmission of the keep-alive messages. Because of these issues, the keep-alive messages may not by themselves address the need for an RLM mechanism that can cope with periodic of no traffic and no RSs.

As an approach to resolve this issue, the Tx UE may convey to the Rx UE an indication when no traffic is expected for a substantial time. The indication may take various forms, for example:

an end marker associated with the last packet of data to be transmitted;

a buffer status report (BSR) indicating when the Tx UE’s transmit buffer is empty;

an indication of whether a resource grant is released;

a signalling message indicating that the Rx UE is requested to transition to a different or “altered” mode of RLM.

A possible mode of operation of such an indication is shown in Figure 1. In step 1, the Rx UE performs normal RLM procedures, e.g., measuring the received quality of RSs on the link with the Tx UE. In step 2, the Tx UE sends data to the Rx UE; this step may be repeated an indefinite number of times. The data may be accompanied by or otherwise associated with RSs, allowing the Rx UE to perform RLM procedures. In step 3, the Tx UE determines that no further traffic is expected for a time, and at step 4 it sends an indication to that effect to the Rx UE. The determining at step 3 may be controlled by the Tx UE implementation, and may, for example, involve information from upper layers related to the expected traffic pattern of the currently transmitted service (s) . At step 5, responsive to the indication, the Rx UE enters an altered mode of RLM operation. The altered mode may include, for example, reduced monitoring for RSs, changes to the timing and/or content of the IS/OOS indications sent by lower layers to upper layers, discontinuous reception (DRX) operation with concomitant changes to the reception pattern for RLM, and so on.

When no RSs are sent, it may not be possible for the Rx UE to make an informed judgement as to the condition of the link. Accordingly, the IS/OOS indications sent during a period of no RSs may not be accurate or meaningful. This issue may be resolved by allowing a third state (in addition to the IS and OOS states) for the IS/OOS indications, which could be identified as “RS absent” or “don’t know” , i.e., the Rx UE does not know if the link is in sync or out of sync. When RLM operates in the altered mode referred to above, the IS/OOS indications may take this third value, which may be interpreted by upper layers as meaning no (known) change from the last indication. For example, if traffic ended with the link being reported as in sync, the IS/OOS indications during a subsequent period of no traffic may indicate “RS absent” and be interpreted by upper layers as “still in sync” . In other words, if traffic ended “cleanly” (as determined based on the indication sent by the Tx UE) , the Rx UE knows to expect a period of no RSs and does not interpret their absence as meaning the link is out of sync. An example of this operation is shown in Figure 2.

In step 1 of Figure 2, the Tx UE sends data and accompanying RSs to the Rx UE. The RSs are received with good quality and the PHY layer of the Rx UE sends corresponding IS indications to the RRC layer of the Rx UE, signifying that the link is deemed in sync. In step 2, the Tx UE sends an indication of the end of traffic transmission to the Rx UE. This indication may take various forms as described above. In response to the indication, the PHY layer of the Rx UE begins sending “No RS” indications to the RRC layer of the Rx UE, signifying that no RSs are expected and accordingly no IS/OOS evaluations are being performed by the PHY layer of the Rx UE. In step 3, this situation persists for a period of no traffic, with the PHY layer of the Rx UE continuing to emit “No RS” indications. In step 4, traffic and RSs resume from the Tx UE, and the PHY layer of the Rx UE begins sending normal IS/OOS indications to the RRC layer of the Rx UE. In the example of the figure, the resumed RSs are assumed to be received with good quality, so the PHY layer indicates to the RRC layer that the link is in sync.

As an alternative to the “No RS” indications of Figure 2, the lower layers of the Rx UE (for example, the PHY layer) may continue to send IS indications to the upper layers of the Rx UE (for example, the RRC layer) . This has a similar effect to the “No RS” indications, since the IS indications prevent the upper layers from declaring RLF during the period of no traffic. As a further alternative, the lower layers may send no indications to the upper layers during the period of no traffic. In this case, the upper layers should be designed not to expect strictly periodic IS/OOS indications, and the upper layers should interpret the absence of any indication as meaning that the link is still considered to be in sync, at least while the UE operates in the altered RLM mode.

From the perspective of the Rx UE, the procedure of Figure 2 suggests that the link is considered in sync during the period of no traffic, because traffic ended “gracefully” , i.e., the indication from the Tx UE in step 2 conveyed to the Rx UE that a period of no traffic was expected. In a complementary situation, detected traffic may end without an indication, for example, due to link degradation. Such link degradation may occur suddenly for various reasons, meaning that link loss is not necessarily preceded by OOS indications. (For example, a directional transmission, such as a beamformed transmission in millimetre-wave frequency ranges, may easily be interrupted by an obstruction such as a user moving behind a building, and the interruption may be sudden. ) In this case, the Rx UE should interpret a period of no traffic as reflecting link loss. This situation is shown in Figure 3.

The procedure of Figure 3 starts in a similar manner to that of Figure 2. In step 1, the Tx UE transmits data and accompanying RSs to the Rx UE. The Rx UE receives the RSs in good condition, and accordingly, the PHY layer of the Rx UE sends IS indications to the RRC layer of the Rx UE. However, in step 2, the link fails due to a degradation of radio conditions (which may be caused, for instance, by an obstruction or by the communicating UEs quickly moving out of range) . In particular, the Tx UE does not convey an indication of the end of traffic, so the Rx UE is not guided to switch to an altered mode of RLM operation. Accordingly, the PHY layer of the Rx UE begins sending OOS indications to the RRC layer of the Rx UE, since it is operating in a default RLM mode and not receiving RSs successfully. In step 3, this situation continues; the Rx UE does not detect traffic or accompanying RSs, and it continues to deem the link OOS, with OOS indications being sent from the PHY layer of the Rx UE to the RRC layer of the Rx UE. In step 4, the Rx UE reaches some criterion for RLF declaration (for instance, the expiration of a timer and/or the accumulation of a threshold number of OOS indications) and declares RLF. The handling of the RLF declaration may comprise an indication to upper layers, an autonomous release of the connection with the Tx UE, an attempt to re-establish the connection either with the original Tx UE or with a different peer UE, and so on.

It should be noted that the Tx UE may operate RLM mechanisms complementary to those operated by the Rx UE, based, for example, on whether or not the Tx UE receives expected feedback (for example, HARQ or RLC acknowledgements) to the traffic it transmits. In Figure 3, during the period of no detected traffic in step 3 and after the RLF declaration in step 4, the Rx UE will not be transmitting acknowledgements, since it is not receiving any traffic. Thus the Tx UE also has the opportunity to detect the failure of the link, which helps to prevent the two peer UEs in the connection from losing synchronisation of their connection states. Furthermore, the keep-alive signalling will eventually fail, potentially resulting in the upper layers of the Tx UE determining that the connection should be torn down.

In some embodiments, an inactivity timer mechanism may allow some time for recovery of the link or for traffic to restart before the lower layers (for example, the PHY layer) of the Rx UE begin sending OOS indications to the upper layers (for example, the RRC layer) of the Rx UE. For example, when an “end of traffic” indication is received by the Rx UE, the Rx UE may start an inactivity timer. During the operation of the inactivity timer, the lower layers of the Rx UE may send “No RS” indications to the upper layers of the Rx UE, in accordance with the altered mode of RLM activity described above. However, if the inactivity timer expires, the Rx UE may revert to the default mode of RLM activity, and the lower layers of the Rx UE may begin sending OOS indications to the upper layers of the Rx UE. This approach is suitable for services with bursty traffic where an estimate of the time between bursts can be made. Its operation is shown in Figure 4.

In step 1 of Figure 4, the Tx UE sends data and RSs to the Rx UE successfully, as in the previous figures. The Rx UE receives the RSs in good condition, so the lower layers of the Rx UE (for example, the PHY layer) send IS indications to the upper layers of the Rx UE (for example, the RRC layer) . In step 2, the Tx UE reaches the end of its current burst of traffic and sends an indication to the Rx UE, signifying the end of traffic and guiding the Rx UE to enter an altered mode of RLM activity. In step 3, the Rx UE starts an inactivity timer. In step 4, there is a period of no data and no RSs, during which the lower layers of the Rx UE, in accordance with the altered mode of RLM activity, send “No RS” indications to the upper layers of the Rx UE. In step 5, data transmission from the Tx UE resumes, but the transmission is lost over the air, so the Rx UE is not aware that data transmission has resumed. Accordingly, the lower layers of the Rx UE continue sending “No RS” indications to the upper layers of the Rx UE. At step 6, the inactivity timer expires, and the Rx UE reverts to the default mode of RLM operation, meaning that its lower layers now begin sending OOS indications to its upper layers, since the lower layers are not detecting any RSs successfully. At step 7, in response to some criteria such as the expiration of a timer and/or receiving a threshold number of OOS indications, the upper layers of the Rx UE declare RLF.

As noted above, the indication of the end of expected traffic activity may take any of several forms. For the indication to be delivered along with traffic, it may be expedient to have it carried in a medium access control (MAC) layer, e.g. as a MAC control element (CE) . The indication may, for example, take the form of a MAC CE containing a BSR, wherein the BSR indicates that one or more transmit buffers related to the concerned service (s) are empty. A new MAC CE specific to the indication may also be defined. Alternatively, the indication may be carried in a separate control message, such as a PC5 radio resource control (PC5-RRC) message sent by the Tx UE. In some embodiments, the indication may be negative, i.e. an explicit indication may be sent to convey that more traffic is expected, and the absence of such an explicit indication is understood to mean “end of traffic” .

In particular, a service with periodic or quasi-periodic data transmission may be sent using a configured grant (CG) issued to the Tx UE, which reserves certain radio resources in a recurring fashion so that the Tx UE can occupy them repeatedly without requesting new radio resources. The CG may have an associated validity time. Information about the CG, including the validity time, may be delivered to the Rx UE to assist with reception, and the Rx UE may assume that traffic is expected during the period that the CG remains valid. In this situation, the explicit indication that more traffic is expected may take the form of extending the validity time, e.g., renewing the CG with updated information including a new validity time. The Rx UE may understand that no more traffic is expected when the CG’s validity time is allowed to expire. Accordingly, the Rx UE may implement various techniques for RLM as discussed above, such as immediately transitioning to an altered mode of RLM operation, starting an inactivity timer, and so on, in response to the expiration of the CG’s validity time.

An example of this operation is shown in Figure 5. In step 1, the Tx UE requests a CG from a serving gNode B (gNB) . In step 2, the gNB provides a CG, and in step 3, the Tx UE delivers information about the CG to the Rx UE, including the validity time. Other information such as the granted radio resources may also be provided to the Rx UE to assist with reception. In step 4, the Tx UE sends data to the Rx UE using the resources in the CG. In step 5, the Tx UE requests an update to the CG (for instance, because it determines that more traffic is expected and it needs to prevent the CG from expiring) from the gNB. In step 6, the gNB provides an update to the CG, which may take the form of a new CG or of a set of changes to the existing CG. In step 7, the Tx UE sends to the Rx UE information about the updated CG, including the new validity time. The Tx UE may also include additional information about the updated CG, for example, the granted radio resources. In step 8, the Tx UE sends data to the Rx UE using the resources in the (updated) CG. In step 9, the validity time expires, without an additional update to the CG; the Rx UE detects this expiration. (Although not shown in the figure, it should be noted that the Tx UE also is aware of the expiration and ceases to send data on the resources of the CG, since the grant is no longer valid. ) In step 10, responsive to the expiration of the validity time, the Rx UE takes RLM-related actions such as transitioning to an altered RLM mode, as discussed above. Alternatively, step 10 may take the form of starting an inactivity timer.

Figure 6 shows an exemplary block diagram of a UE 800 according to an embodiment of the disclosure. The UE 800 can be configured to implement various embodiments of the disclosure described herein. The UE 800 can include a processor 810, a memory 820, and a radio frequency (RF) module 830 that are coupled together as shown in figure 6. In different examples, the UE 800 can be a mobile phone, a tablet computer, a desktop computer, a vehicle carried device, and the like.

The processor 810 can be configured to perform various functions of the UE 120 described above with reference to figures 1-5. The processor 810 can include signal processing circuitry to process received or to be transmitted data according to communication protocols specified in, for example, LTE and NR standards. Additionally, the processor 810 may execute program instructions, for example, stored in the memory 820, to perform functions related with different communication protocols. The processor 810 can be implemented with suitable hardware, software, or a combination thereof. For example, the processor 810 can be implemented with application specific integrated circuits (ASIC) , field programmable gate arrays (FPGA) , and the like, that includes circuitry. The circuitry can be configured to perform various functions of the processor 810.

In one example, the memory 820 can store program instructions that, when executed by the processor 810, cause the processor 810 to perform various functions as described herein. The memory 820 can include a read only memory (ROM) , a random access memory (RAM) , a flash memory, a solid state memory, a hard disk drive, and the like.

The RF module 830 can be configured to receive a digital signal from the processor 810 and accordingly transmit a signal to a base station in a wireless communication network via an antenna 840. In addition, the RF module 830 can be configured to receive a wireless signal from a base station and accordingly generate a digital signal which is provided to the processor 810. The RF module 830 can include digital to analog/analog to digital converters (DAC/ADC) , frequency down/up converters, filters, and amplifiers for reception and transmission operations. For example, the RF module 830 can include converter circuits, filter circuits, amplification circuits, and the like, for processing signals on different carriers or bandwidth parts.

The UE 800 can optionally include other components, such as input and output devices, additional CPU or signal processing circuitry, and the like. Accordingly, the UE 800 may be capable of performing other additional functions, such as executing application programs, and processing alternative communication protocols.

The processes and functions described herein can be implemented as a computer program which, when executed by one or more processors, can cause the one or more processors to perform the respective processes and functions. The computer program may be stored or distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with, or as part of, other hardware. The computer program may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems. For example, the computer program can be obtained and loaded into an apparatus, including obtaining the computer program through physical medium or distributed system, including, for example, from a server connected to the Internet.

The computer program may be accessible from a computer-readable medium providing program instructions for use by or in connection with a computer or any instruction execution system. A computer readable medium may include any apparatus that stores, communicates, propagates, or transports the computer program for use by or in connection with an instruction execution system, apparatus, or device. The computer-readable medium can be magnetic, optical, electronic, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. The computer-readable medium may include a computer-readable non-transitory storage medium such as a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM) , a read-only memory (ROM) , a magnetic disk and an optical disk, and the like. The computer-readable non-transitory storage medium can include all types of computer readable medium, including magnetic storage medium, optical storage medium, flash medium and solid state storage medium.

Although the present disclosure has been described with exemplary embodiments, various changes and modifications may be suggested to one skilled in the art. It is intended that the present disclosure encompass such changes and modifications as fall within the scope of the appended claims.

Claims

A method of radio link monitoring operable in a receiving device, comprising:

performing radio link monitoring in a default mode;

receiving data from a transmitting device;

receiving, from the transmitting device, an indication of whether further data transmission is expected; and

if further data transmission is not expected, switching to an altered mode of radio link monitoring.
The method of claim 1, wherein the default mode of radio link monitoring comprises a first protocol layer of the receiving device sending in-sync/out-of-sync (IS/OOS) indications to a second protocol layer of the receiving device, and wherein the altered mode of radio link monitoring comprises the first protocol layer sending to the second protocol layer indications that no reference signal is expected.
The method of claim 2, wherein the first protocol layer is a physical layer.
The method of claim 2, wherein the second protocol layer is a radio resource control (RRC) layer.
The method of claim 1, wherein the altered mode of radio link monitoring comprises running an inactivity timer, and wherein switching to the altered mode of radio link monitoring comprises starting the inactivity timer.
The method of claim 5, further comprising declaring a radio link failure when the inactivity timer expires.
The method of claim 5, further comprising switching to the default mode of radio link monitoring when the inactivity timer expires.
The method of claim 1, wherein the altered mode of radio link monitoring comprises declaring a radio link failure.
The method of claim 1, wherein the default mode of radio link monitoring comprises a first protocol layer of the receiving device sending IS/OOS indications to a second protocol layer of the receiving device responsive to one or more measurements of reference signals (RSs) , and wherein the altered mode of radio link monitoring comprises the first protocol layer sending IS/OOS indications to the second protocol layer without considering one or more measurements of RSs.
The method of claim 9, wherein the first protocol layer is a physical layer.
The method of claim 9, wherein the second protocol layer is an RRC layer.
The method of claim 9, wherein the altered mode of radio link monitoring comprises the first protocol layer sending IS indications to the second protocol layer when further data transmission is not expected.
The method of claim 1, wherein the indication of whether further data transmission is expected comprises a signal from the transmitting device indicating that no further data transmission is expected.
The method of claim 1, wherein the indication of whether further data transmission is expected comprises a signal from the transmitting device indicating that an expiration time for a configured grant is extended.
The method of claim 1, wherein the indication of whether further data transmission is expected is carried by a message of a radio resource control (RRC) protocol.
The method of claim 1, wherein the indication of whether further data transmission is expected is carried by a control element (CE) of a medium access control (MAC) protocol.
The method of claim 1, wherein the indication of whether further data transmission is expected comprises an end marker accompanying a packet of data.
The method of claim 1, wherein the indication of whether further data transmission is expected comprises a buffer status report (BSR) .
The method of claim 18, wherein further data transmission is not expected if the BSR indicates a transmission buffer as being empty.