WO2018058353A1

WO2018058353A1 - Feedback for single cell point to multipoint for narrowband internet of things and/or machine type communication

Info

Publication number: WO2018058353A1
Application number: PCT/CN2016/100512
Authority: WO
Inventors: Yanji Zhang; Yuantao Zhang
Original assignee: Nokia Technologies Beijing Co Ltd; Nokia Technologies Oy
Current assignee: Nokia Technologies Beijing Co Ltd; Nokia Technologies Oy
Priority date: 2016-09-28
Filing date: 2016-09-28
Publication date: 2018-04-05
Anticipated expiration: 2019-03-28

Abstract

Feedback mechanisms may be helpful for various communication systems. For example, narrowband intemet of things and/or machine type communication systems may benefit from feedback for single cell point to multipoint communication. A method can include monitoring, by user equipment, for a single cell multicast traffic channel transmission. The method can also include contingently sending, by the user equipment, feedback based on how the single cell multicast traffic channel transmission is received, using a physical random access channel preamble.

Description

FEEDBACK FOR SINGLE CELL POINT TO MULTIPOINT FOR NARROWBAND INTERNET OF THINGS AND/OR MACHINE TYPE COMMUNICATION

BACKGROUND：

Field：

Feedback mechanisms may be helpful for various communication systems. For example， narrowband internet of things and/or machine type communication systems may benefit from feedback for single cell point to multipoint communication.

Description of the Related Art：

Third generation partnership project (3GPP) long term evolution (LTE) has release 14 (Rel. 14) work items (WIs) ， “Enhancements of NB-IoT” and “Further Enhanced MTC， ” which specify new features for enhancement of narrowband (NB) Internet of things (IoT) and enhanced machine type communication (eMTC) . Support of downlink (DL) multicast transmission in this context may by accomplished by extending Rel13 single cell (SC) point-to-multipoint (SC-PTM) .

The Rel-13 SC-PTM architecture can be the basis for multi-cast design for NB-IoT and machine type communication (MTC) . Reception of multi-cast in radio resource control (RRC) idle (RRC_IDLE) mode may be required for both NB-IoT and MTC， although reception of multi-cast in RRC connected (RRC_CONNECTED) mode is not required for NB-IoT and may or may not be required for MTC. Service continuity of multi-cast may need to be supported as in Rel-13 for idle mode for NB-IoT and MTC.

The legacy single cell multicast traffic channel (SC-MTCH) mechanism in which the SC-MTCH is scheduled by physical downlink control channel (PDCCH) can be reused for multi-cast in NB-IoT and MTC to achieve flexible scheduling.

Repetition for SC-MTCH transmission can be applied to multi-cast in NB-IoT and MTC. Unacknowledged mode (UM) can be used for SC-PTM in NB-IoT and MTC. System information block (SIB) 20 (SIB20) or a somewhat modified variant can be used for SC multicast control channel (SC-MCCH) configuration， for example providing a new SIB20-NB for NB-IoT.

Both SC-MCCH and SC-MTCH may be scheduled on an anchor carrier and/or non-anchor carrier for NB-IoT. SC-MCCH and SC-MTCH may be scheduled on different carriers for NB-IoT and for MTC， for example narrowband for MTC.

Uplink (UL) feedback can improve SC-PTM spectral efficiency under some circumstance. For example， a feedback mechanism for NB-IoT can be used so that an evolved Node B (eNB) can retransmit the missing part of the multi-cast to reduce user equipment (UE) power consumption.

As mentioned above， reception of multi-cast in RRC_IDLE mode may be required by both NB-IoT and MTC. For the UE in connected state， the UE can keep the UL synchronization and the UE context. Regular hybrid automatic repeat request (HARQ) operation can be applied to control the data retransmission. Conventionally， however， a UE in idle mode could unlikely send any UL data/signal without UL synchronization and available UL resource assignment.

SUMMARY：

According to certain embodiments， a method can include monitoring， by user equipment， for a single cell multicast traffic channel transmission. The method can also include contingently sending， by the user equipment， feedback based on how the single cell multicast traffic channel transmission is received， using a physical random access channel preamble.

In certain embodiments， a method can include sending a single cell multicast traffic channel transmission to a user equipment. The method can also include monitoring for feedback based on how the single cell multicast traffic channel transmission is received by the user equipment. The feedback can use a physical random access channel preamble.

An apparatus， according to certain embodiments， can include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code can be configured to， with the at least one processor， cause the apparatus at least to monitor， by user equipment， for a single cell multicast traffic channel transmission. The at least one memory and the computer program code can also be configured to， with the at least one processor， cause the apparatus at least to contingently send， by the user equipment， feedback based on how the single cell multicast traffic channel transmission is received， using a physical random access channel preamble.

An apparatus， in certain embodiments， can include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code can be configured to， with the at least one processor， cause the apparatus at least to send a single cell multicast traffic channel transmission to a user equipment. The at least one memory and the computer program code can also be configured to， with the at least one processor， cause the apparatus at least to monitor for feedback based on how the single cell multicast traffic channel transmission is received by the user equipment. The feedback can use a physical random access channel preamble.

According to certain embodiments， an apparatus can include means for monitoring， by user equipment， for a single cell multicast traffic channel transmission. The apparatus can also include means for contingently sending， by the user equipment， feedback based on how the single cell mulficast traffic channel transmission is received， using a physical random access channel preamble.

In certain embodiments， an apparatus can include means for sending a single cell multicast traffic channel transmission to a user equipment. The apparatus can also include means for monitoring for feedback based on how the single cell multicast traffic channel transmission is received by the user equipment. The feedback can use a physical random access channel preamble.

A computer program product may be， according to certain embodiments， encoded with instructions for performing a process. The process can include monitoring， by user equipment， for a single cell multicast traffic channel transmission. The process can also include contingently sending， by the user equipment， feedback based on how the single cell multicast traffic channel transmission is received， using a physical random access channel preamble.

A computer program product may be， in certain embodiments， encoded with instructions for performing a process. The process can include sending a single cell multicast traffic channel transmission to a user equipment. The process can also include monitoring for feedback based on how the single cell multicast traffic channel transmission is received by the user equipment. The feedback can use a physical random access channel preamble.

According to certain embodiments， a non-transitory computer-readable medium can be encoded with instructions that， when executed in hardware， perform a process. The process can include monitoring， by user equipment， for a single cell multicast traffic channel transmission. The process can also include contingently sending， by the user equipment， feedback based on how the single cell multicast traffic channel transmission is received， using a physical random access channel preamble.

In certain embodiments， a non-transitory computer-readable medium can be encoded with instructions that， when executed in hardware， perform a process. The process can include sending a single cell multicast traffic channel transmission to a user equipment. The process can also include monitoring for feedback based on how the single cell multicast traffic channel transmission is received by the user equipment. The feedback can use a physical random access channel preamble.

BRIEF DESCRIPTION OF THE DRAWINGS：

For proper understanding of the invention， reference should be made to the accompanying drawings， wherein：

Figure 1 illustrates resource allocation option 1 of DL multicast transmission feedback， according to certain embodiments.

Figure 2 illustrates resource allocation option 2 of DL multicast transmission feedback， according to certain embodiments.

Figure 3 illustrates methods according to certain embodiments.

Figure 4 illustrates a system according to certain embodiments.

DETAILED DESCRIPTION：

Certain embodiments provide methods and systems to provide feedback for downlink (DL) multicast transmission for Rel. 14 bandwidth limited (BL) user equipment (UEs) or UEs in coverage enhancement (CE) and NB-IoT UEs in IDLE state.

A physical random access channel (PRACH) preamble transmission scheme can be reused for sending feedback for DL multicast transmission， for example for sending feedback for SC-MTCH transmission.

The PRACH preamble can be applied to indicate a negative acknowledgment (NACK) for SC-MTCH reception on the UE side. For example， if the UE fails to decode the SC-MTCH， the UE can transmit a PRACH preamble to inform an evolved Node B (eNB) or other access node of such failure. The UE does not need to respond with anything for successful reception.

The UE could retransmit the response in case it does not receive any retransmitted SC-MTCH. The UE can ramp up the transmitted power and/or repeat more times autonomously or according to a predefined rule.

There can be a dedicated frequency resource for DL multicast transmission feedback， which can be separate from the PRACH resource for normal RA procedure. The dedicated frequency resource can be configured as additional parameters for SC-MTCH.

If each SC-MTCH supports only one coverage enhancement (CE) level， a common frequency resource could be allocated for all the SC-MTCHs， which may contain one or a number of narrowbands for eMTC or physical resource blocks (PRBs) for NB-IoT. Each SC-MTCH can be assigned a group of preambles， which can be mapped to specific CE level.

Alternatively， if each SC-MTCH has different frequency allocation， the mapping between the preamble groups and different CE levels can be defined within a SC-MTCH.

The feedback mechanism can be enabled by adding the configuration for supporting feedback inside SCPTMConfiguration. Upon failed reception of SC-MTCH， the UE can select the frequency resource from the configured parameters based on the UE’s CE level and/or the session of multimedia broadcast multicast service (MBMS) it is receiving.

The feedback could be sent from the K DL subframes (K milliseconds) after the MTCH transmission， where K may be predefined or broadcasted. If the eNB does not receive any feedback from the specific subframe， the eNB can consider the MTCH transmission successful.

Thus， for example， the Rel14 BLUEs or UEs in CE and NB-IoT UEs in IDLE state can provide feedback for DL multicast transmission by reusing the PRACH preamble transmission scheme， in certain embodiments.

To differentiate from the normal PRACH transmission， a separate frequency resource could be configured for SC-PTM feedback specifically. For example， a different narrowband for eMTC or the different PRB for NB-IoT can be configured for SC-PTM feedback specifically.

In order to accommodate different CE levels of the UE， the mapping between the SC-PTM feedback resource and the CE level could be provided， which can have the following potential configurations depending on how the MBMS service is grouped.

According to a first option， referred to for conveniences as option 1， the MBMS service can be linked with the CE level. In this case， a common frequency resource could be assigned for all the SC-MTCHs which may contain a number ofnarrowbands for eMTC or PRBs for NB-IoT. Each SC-MTCH can have a dedicated preamble group associated to a specific CE level for feedback. Each preamble group can contain one or multiple preambles.

According to a second option， referred to for conveniences as option 2， the MBMS service can be independent from CE level. Each SC-MTCH may support multiple CE levels. The same preamble could be multiplexed among different SC-MTCH. Each SC-MTCH can have different frequency allocation. For each SC-MTCH， the mapping between the preamble group and different CE level can be defined.

Assume the cell supports three SC-MTCHs and three CE levels. The configuration of the two options can be seen from Figures 1 and 2.

Figure 1 illustrates resource allocation option 1 of DL multicast transmission feedback， according to certain embodiments. As shown in Figure 1，for option 1 each SC-MTCH can be mapped with different CE levels.

For example， the eNB can define three preamble groups which are mapped to different CE levels separately. The eNB may define a common frequency resource that contains two narrowbands/PRBs， from which a UE could select for sending feedback for DL multicast transmission.

As illustrated in Figure 1， UE 1 can receive MBMS service from SC-MTCH 3， and may send feedback from Narrowband/PRB 2 by transmitting a preamble from preamble group 2.

UE 2 can receive SC-MTCH 1 and UE 3 can receive SC-MTCH 2. UE2 and UE3 may both send feedback from narrowband/PRB 1. The eNB could differentiate them from the preamble decoded. For example， UE 2 can transmit a preamble selected from preamble group 1 and UE 3 can transmit a preamble selected from preamble group 3.

Figure 2 illustrates resource allocation option 2 of DL multicast transmission feedback， according to certain embodiments. As shown in Figure 2， for option 2 each SC-MTCH may support multiple CE levels.

The eNB can define a different frequency area， such as narrowband and/or PRB， for each SC-MTCH. As illustrated in Figure 2， when a UE sends NACK for a SC-MTCH transmission， the UE can first select the preamble from the preamble group based on the UE’s CE level. Then， the UE can send the preamble from the preconfigured frequency resource， such as narrowband/PRB， associated with the SC-MTCH.

Such resource allocation for potential feedback for DL multicast transmission could be defined optionally in SCPTMConfiguration as additional configuration for SC-MTCH. In addition， the eNB may decide whether such a feedback mechanism is allowed for a SC-MTCH based on the eNB’s mapped service type or supported CE level. The presence of the new parameters could be used as an implicit indication for this purpose.

Upon failed reception of SC-MTCH， if the feedback configuration has been provided， the UE could send a preamble as NACK at the K DL subframes after the SC-MTCH transmission， where K may be predefined or broadcasted.

The preamble can be selected randomly from the configured preamble group based on the UE’s CE level or/and the session of MBMS service the UE is receiving. The frequency information can be provided by the new configuration in SCPTMConfiguration.

Those two options could coexist by appropriate ASN. 1 definition， and the eNB could decide the approach for feedback configuration based on the eNB’s own implementation.

The eNB can start detecting the UL feedback from the preconfigured resource (s) after the SC-MTCH transmission， based on the received preamble and/or the frequency resource the preamble is received. If the eNB decodes the NACK， it can retransmit the failed DL multicast transmission broadcast (TB) for the corresponding SC-MTCH， otherwise， the eNB can consider the DL multicast TB transmission successful.

Certain embodiments may have various benefits and/or advantages. For example， the eNB may only need to retransmit the failed TB instead of the whole MBMS service application data packet. The application of the preamble to indicate the NACK for DL mulficast transmission could improve the DL spectrum utilization efficiency and reduce the UE power consumption.

Figure 3 illustrates methods according to certain embodiments. As shown in Figure 3， a method can include， at 310， monitoring， by user equipment， for a single cell multicast traffic channel transmission. The method can also include， at 320， contingently sending， by the user equipment， feedback based on how the single cell multicast traffic channel transmission is received， using a physical random access channel preamble.

The can be sent as negative acknowledgment when the single cell multicast traffic channel transmission is received with an error. The feedback can be sent only when the single cell multicast traffic channel transmission is not successfully received. For example， the unsuccessful reception of the single cell multicast traffic channel transmission can be the basis for sending the feedback.

The method can further include， at 330， monitoring for a subsequent single cell multicast traffic channel transmission responsive to the feedback. The method can additionally include， at 340， contingently sending， by the user equipment， a further feedback based on whether the subsequent single cell multicast traffic channel retransmission is received.

The method can further include， at 345， ramping up， by the user equipment， transmitted power of the further feedback relative to the feedback. The method can also include， at 347， repeatedly sending， by the user equipment， the further feedback until a responsive single cell multicast traffic channel retransmission is received. The repeated sending can be used in combination with the ramping up. For example， each successive repetition can have greater transmitted power.

The feedback can be sent on a dedicated frequency resource for downlink multicast transmission feedback. The dedicated frequency resource can be separate from a physical random access channel resource for normal random access procedure. The dedicated frequency resource can include a common frequency resource allocated for all single cell multicast traffic channels.

The method can additionally include， at 350， selecting， by the user equipment， the preamble randomly from a configured preamble group. The selection can be based on a coverage enhancement level of the user equipment and/or a session of multimedia broadcast multicast service the user equipment is receiving.

The above steps at 310-350， as well as 305 discussed below， can be performed by a device such as， for example， a user equipment. The following steps 360-395 may be performed by an access node， such as an eNB.

The method can include， at 360， sending a single cell multicast traffic channel transmission to a user equipment. The method can also include， at 370， monitoring for feedback based on how the single cell multicast traffic channel transmission is received by the user equipment. The feedback can use a physical random access channel preamble.

The method can further include， at 380， enabling a feedback mechanism by configuring the user equipment to provide the feedback. The configuring can include providing frequency information in an information element， such as SCPTMConfiguration. The configuration can be received by the user equipment at 305.

The method can additionally include， at 390， upon feedback being detected， retransmitting the single cell multicast traffic channel transmission. If that retransmitted transmission fails to be received correctly， further feedback can be received at 395.

Figure 4 illustrates a system according to certain embodiments of the invention. It should be understood that each block of the flowchart of Figure 3 may be implemented by various means or their combinations， such as hardware， software， firmware， one or more processors and/or circuitry. In one embodiment， a system may include several devices， such as， for example， network element 410 and user equipment (UE) or user device 420.

The system may include more than one UE 420 and more than one network element 410， although only one of each is shown for the purposes of illustration. A network element can be an access point， a base station， an eNode B (eNB) ， or any other network element.

Each of these devices may include at least one processor or control unit or module， respectively indicated as 414 and 424. At least one memory may be provided in each device， and indicated as 415 and 425， respectively. The memory may include computer program instructions or computer code contained therein， for example for carrying out the embodiments described above. One or

more transceiver

416 and 426 may be provided， and each device may also include an antenna， respectively illustrated as 417 and 427. Although only one antenna each is shown， many antennas and multiple antenna elements may be provided to each of the devices. Other configurations of these devices， for example， may be provided. For example， network element 410 and UE 420 may be additionally configured for wired communication， in addition to wireless communication， and in such a

case antennas

417 and 427 may illustrate any form of communication hardware， without being limited to merely an antenna.

Transceivers

416 and 426 may each， independently， be a transmitter， a receiver， or both a transmitter and a receiver， or a unit or device that may be configured both for transmission and reception. The transmitter and/or receiver (as far as radio parts are concerned) may also be implemented as a remote radio head which is not located in the device itself， but in a mast， for example. It should also be appreciated that according to the “liquid” or flexible radio concept， the operations and functionalities may be performed in different entities， such as nodes， hosts or servers， in a flexible manner. In other words， division of labor may vary case by case. One possible use is to make a network element to deliver local content. One or more functionalities may also be implemented as a virtual application that is provided as software that can run on a server.

A user device or user equipment 420 may be a mobile station (MS) such as a mobile phone or smart phone or multimedia device， a computer， such as a tablet， provided with wireless communication capabilities， personal data or digital assistant (PDA) provided with wireless communication capabilities， portable media player， digital camera， pocket video camera， navigation unit provided with wireless communication capabilities or any combinations thereof. The user device or user equipment 420 may be a sensor or smart meter， or other device that may usually be configured for a single location.

In an exemplifying embodiment， an apparatus， such as a node or user device， may include means for carrying out embodiments described above in relation to Figure 3.

Processors

414 and 424 may be embodied by any computational or data processing device， such as a central processing unit (CPU) ， digital signal processor (DSP) ， application specific integrated circuit (ASIC) ， programmable logic devices (PLDs) ， field programmable gate arrays (FPGAs) ， digitally enhanced circuits， or comparable device or a combination thereof. The processors may be implemented as a single controller， or a plurality of controllers or processors. Additionally， the processors may be implemented as a pool of processors in a local configuration， in a cloud configuration， or in a combination thereof.

For firmware or software， the implementation may include modules or units of at least one chip set (e.g.， procedures， functions， and so on) .

Memories

415 and 425 may independently be any suitable storage device， such as a non-transitory computer-readable medium. A hard disk drive (HDD) ， random access memory (RAM) ， flash memory， or other suitable memory may be used. The memories may be combined on a single integrated circuit as the processor， or may be separate therefrom. Furthermore， the computer program instructions may be stored in the memory and which may be processed by the processors can be any suitable form of computer program code， for example， a compiled or interpreted computer program written in any suitable programming language. The memory or data storage entity is typically internal but may also be external or a combination thereof， such as in the case when additional memory capacity is obtained from a service provider. The memory may be fixed or removable.

The memory and the computer program instructions may be configured， with the processor for the particular device， to cause a hardware apparatus such as network element 410 and/or UE 420， to perform any of the processes described above (see， for example， Figure 3) . Therefore， in certain embodiments， a non-transitory computer-readable medium may be encoded with computer instructions or one or more computer program (such as added or updated software routine， applet or macro) that， when executed in hardware， may perform a process such as one of the processes described herein. Computer programs may be coded by a programming language， which may be a high-level programming language， such as objective-C， C， C++， C#， Java， etc.， or a low-level programming language， such as a machine language， or assembler. Alternatively， certain embodiments of the invention may be performed entirely in hardware.

Furthermore， although Figure 4 illustrates a system including a network element 410 and a UE 420， embodiments of the invention may be applicable to other configurations， and configurations involving additional elements， as illustrated and discussed herein. For example， multiple user equipment devices and multiple network elements may be present， or other nodes providing similar functionality， such as nodes that combine the functionality of a user equipment and an access point， such as a relay node.

One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order， and/or with hardware elements in configurations which are different than those which are disclosed. Therefore， although the invention has been described based upon these preferred embodiments， it would be apparent to those of skill in the art that certain modifications， variations， and alternative constructions would be apparent， while remaining within the spirit and scope of the invention.

List of Abbreviations

CE Coverage Enhancement

IOT Internet of thing

DL Downlink

LTE Long term evolution

MBMS Multimedia Broadcast Multicast Service

MTC Machine type communication

NB Narrowband

NW Network

PRACH Physical Random Access channel

RRC Radio Resource Control

SC-MTCH Single Cell Multicast Transport Channel

SC-PTM Single Cell Point To Multiploint

UE User equipment

Claims

A method， comprising：

monitoring， by user equipment， for a single cell multicast traffic channel transmission； and

contingently sending， by the user equipment， feedback based on how the single cell multicast traffic channel transmission is received， using a physical random access channel preamble.
The method of claim 1， wherein the feedback is sent as negative acknowledgment when the single cell multicast traffic channel transmission is received with an error.
The method of claim 1， wherein the feedback is sent only when the single cell multicast traffic channel transmission is not successfully received.
The method of claim 1， further comprising：

monitoring for a subsequent single cell multicast traffic channel transmission responsive to the feedback.
The method of claim 4， further comprising：

contingently sending， by the user equipment， a further feedback based on whether the subsequent single cell multicast traffic channel retransmission is received.
The method of claim 5， further comprising：

ramping up， by the user equipment， transmitted power of the further feedback relative to the feedback.
The method of claim 5， further comprising：

repeatedly sending， by the user equipment， the further feedback until a responsive single cell multicast traffic channel retransmission is received correctly.
The method of claim 1， wherein the feedback is sent on a dedicated frequency resource for downlink multicast transmission feedback， wherein the dedicated frequency resource is separate from a physical random access channel resource for normal random access procedure.
The method of claim 8， wherein the dedicated frequency resource comprises a common frequency resource allocated for all single cell multicast traffic channels.
The method of claim 8， wherein feedback is sent on a preconfigured frequency resource associated with the single cell multicast traffic channel.
The method of claim 10， further comprising：

selecting a preamble from a preamble group based on a coverage enhancement level of the user equipment，

wherein sending the feedback comprises sending the selected preamble on the preconfigured frequency resource.
The method of claim 11， wherein the preamble group comprises one preamble or multiple preambles.
The method of claim 1， wherein timing of the feedback is predefined or received in a broadcast message.
The method of claim 1， further comprising：

selecting， by the user equipment， the preamble randomly from a configured preamble group.
The method of claim 14， wherein the selection is based on a coverage enhancement level of the user equipment and/or a session of multimedia broadcast multicast service the user equipment is receiving.
A method， comprising：

sending a single cell multicast traffic channel transmission to a user equipment； and

monitoring for feedback based on how the single cell multicast traffic channel transmission is received by the user equipment， wherein the feedback uses a physical random access channel preamble.
The method of claim 16， further comprising：

enabling a feedback mechanism by configuring the user equipment to provide the feedback.
The method of claim 17， wherein the configuring comprises providing frequency information in an information element.
The method of claim 17， wherein the configuring comprises providing a preamble allocation for the feedback.
The method of claim 17， wherein the configuring comprises broadcasting a timing for the feedback.
The method of claim 17， further comprising：

upon feedback being detected， retransmitting the single cell multicast traffic channel transmission.
An apparatus， comprising：

at least one processor； and

at least one memory including computer program code，

wherein the at least one memory and the computer program code are configured to， with the at least one processor， cause the apparatus at least to perform a process， the process comprising the method according to any of claims 1-21.
An apparatus， comprising：

means for performing a process comprising the method according to any of claims 1-21.
A computer program product encoding instructions for performing a process， the process comprising the method according to any of claims 1-21.
A non-transitory computer-readable medium encoded with instructions that， when executed in hardware， perform a process， the process comprising the method according to any of claims 1-21.