CN108370606B

CN108370606B - Early connection release

Info

Publication number: CN108370606B
Application number: CN201780004741.9A
Authority: CN
Inventors: 奥利维尔马可; 杰罗姆贝尔托雷莱; 班尼阿苏利纳
Original assignee: JRD Communication Shenzhen Ltd
Current assignee: JRD Communication Shenzhen Ltd
Priority date: 2016-02-05
Filing date: 2017-01-19
Publication date: 2022-05-06
Anticipated expiration: 2037-01-19
Also published as: GB2547028B; CN108370606A; GB201602101D0; WO2017133470A1; GB2547028A

Abstract

The invention discloses a method and a system for realizing early release after message exchange is finished. Various messages and message flows between the UE and the eNodeB are proposed to enable an indication that the radio link may be released.

Description

Early connection release

Technical Field

The present invention relates to a method and apparatus for releasing a radio connection, and in particular to a connection used by an autonomous device in a cellular network.

Background

Autonomous devices that communicate using a cellular (or other) radio connection are commonly referred to as the internet of things (internet of things). Typically, internet of things devices are autonomous and are expected to operate for long periods of time without human intervention. Therefore, power consumption is a key aspect of the performance of internet of things devices.

The communication mode of the internet of things device is characterized by wide transmission of a small amount of data. For example, the upstream transmission may be 20-200 bytes. In 50% of the cases, downlink data follows uplink transmissions. There is a long period of silence before the next similar communication.

For such a mode, it is inefficient to keep the link continuously open. The protocol will typically open a link, transmit, and then close the link to save capacity and power. However, the predetermined time will typically delay the closing of the link to ensure that there is no further transmission. In internet of things type transmission, the delay may represent a significant portion of the total power required for transmission.

In the overall architecture of the cellular standard maintained by the 3GPP, the 3GPP proposes a protocol for Narrow Band (NB) operation of internet of things devices. In particular, implementations in the LTE standard are being explored. In the protocol, a communication cycle starts with device wake-up and synchronization, followed by a transition to the RRC CONNECTED RRC _ CONNECTED state. Then a communication exchange is performed, after which the device enters a Discontinuous Reception (DRX) mode to reduce power consumption. A typical DRX mode includes a short period of the first period and a long period of the second period. If no further communication is required after the second phase, the device will release the RRC connection and return to RRC IDLE. The DRX cycle may last several seconds compared to the time of actual communication of several tens of milliseconds, and may account for more than 50% of the total power consumption.

Therefore, in this communication mode, it is desirable to reduce power consumption of the internet of things devices.

The embodiments described below are not limited to implementations that solve any or all of the disadvantages of known systems.

Disclosure of Invention

This abstract presents a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. In accordance with the present disclosure, a method is set forth in the appended claims.

Drawings

Embodiments of the invention will now be described, by way of example, with reference to the following drawings:

figure 1 is a schematic illustration of a first information exchange without subsequent DL data down connection release;

fig. 2 is a schematic illustration of a first information exchange with subsequent connection release under DL data;

fig. 3 is a schematic illustration of a second information exchange without subsequent DL data down-link release;

FIG. 4 is a schematic illustration of a second information exchange with subsequent connection release under DL data;

FIG. 5 is a diagram illustrating a PDCP data PDU format with RAI;

FIG. 6 is a diagram of a PDCP control PDU with RAI;

FIG. 7 is a diagram of PDU types;

fig. 8 is a schematic illustration of a third information exchange without subsequent DL data down connection release;

fig. 9 is a diagram of a third information exchange with subsequent connection release under DL data.

Detailed Description

Embodiments of the present invention are described below by way of example only. These examples represent the best practices presently known to the applicant, although they are not the only way to achieve this goal. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

The internet of things communication mode may consume a significant portion of power while the device is waiting in DRX before releasing the connection and going back to sleep. One attribute of internet of things communication is that the device transmitting the data typically knows the length of the data, and the time when the transaction is completed. Thus, when a device completes a connection, the device may indicate to the network so that the network may release the connection.

The 3GPP is studying two sets of proposals for NB-IoT protocols, one using the User Plane (UP) and the other using the Control Plane (CP) of the LTE network to transmit user data. The present disclosure relates to the implementation of one UP. The present disclosure also relates to implementation of non-access stratum signaling (NAS) in a CP using SRB1 bearers. When integrity protection is not added to the access stratum, the NAS method may be used. Within the UE, NAS is a protocol above RRC, such as 3GPP TS 36.300. The UE NAS counterpart resides in a mobility management entity of the core network like 3GPP TS 36.300.

Fig. 1 shows a sequence of information between a device (UE) and a mobile network, the network connecting the UE via the Uu interface. Typically the mobile network will be an LTE network and information will be exchanged between the UE and the eNodeB to which the UE is connected.

In step 101-. In the conventional manner, SRB0 and SRB1 bearers are suitably utilized, and DRB bearers are utilized for transmission of data. DL means downlink, and UL means uplink. In the BSR message, the UE indicates the amount of data that is desired to be transmitted, and the UL grant message indicates to the UE the resources allocated by the eNoDEB for this transmission.

In step 104, the standard message 4- "RRC connection setup (SRB 0)" and an additional IE may be used to indicate that the UE may receive the REL bit on NAS at step 108. Thus, the UE will only perform RRC connection release, only when the REL bit is transmitted over NAS and not in RRC message from eNoDEB. In particular, the UE will ignore the incoming RRC connection release message.

In step 105, the data is transmitted through the DRB, and in step 106, the data is acknowledged on the RLC layer.

As described above, the UE knows the data to send and therefore knows when the transmission is complete and no longer needs to be linked. In this example, the UE also knows that there is no expected acknowledgement for the data. In step 107, the UE transmits an RRC message requesting release of the connection. Alternatively, an existing RRC message with an attached IE may be used. For example, the UE assistance information RRC message, which is typically used to indicate the power setting mode, may be used with a new IE representing the release request. In the following description, the term RRC connection release request message is used to cover any message that gives the required indication.

In step 108, the eNoDEB sends an RLC ACK for the RRC connection release request and also releases the RRC connection release message to release the connection. The Poll/UL grant message requests RLC acknowledgement. The RRC connection release indication to release the connection may be transmitted in the form of a REL bit on the NAS, and upon receipt, the UE sends the required RLC ACK and then releases the connection in step 109.

The procedure of fig. 1 thus allows for a quick release of the connection after the data transmission is completed without waiting for the DRX cycle to complete.

Fig. 2 shows a flow chart of a similar method as in fig. 1, but where downlink data is expected after uplink data transmission. Step 201-.

Step 207-. The process of fig. 2 therefore achieves connection release quickly after the last data transfer.

Although the processes of fig. 1 and 2 provide the ability to release connections early, they also require additional transmissions compared to standard switches. The RRC connection release request is a separate message and cannot be sent after the data transmission transaction is over (i.e., RLC ACK for UL/DL data is received or transmitted). This is because data is transmitted through the DRB and the RRC connection release request is transmitted through the SRB. Since the RLC maintains order only in logical channels and not between channels, if an RRC connection release request is sent before the RLC acknowledges data, the RRC connection release request may arrive before the data, potentially resulting in loss of the data.

If the RRC connection release request is sent as a separate message (in the method shown in fig. 1 and 2) at the end of the transaction, UL resources cannot be requested in advance. In step 103, the BSR will cover only the resources transmitting UL data in step 105. Since the RRC connection release request is sent as a separate message, the request is not considered in the BSR sent in step 103 or step 203. The PRACH/scheduling request procedure may need to be able to send an RRC connection release request message, adding further overhead to the method since up to 3 UL messages are required in

steps

107 and 207.

Fig. 3 shows an early procedure for further implementing the connection, the number of messages being reduced compared to the procedure of fig. 1.

Steps 301 to 304 are the same as steps 101 to 104 described in fig. 1. At step 305, data is transmitted on the DRB in a conventional manner, but an RRC connection release request message is also sent on the SRB 1. The BSR value sent in step 303 takes into account the data packet and the RRC connection release request message.

As described above, the RLC does not maintain the order between messages on DRBs and SRBs. The RRC connection release request message may thus arrive before the data packet, which may result in data loss. In fact, SRB1 generally takes precedence over DRBs and therefore may arrive first in the wrong order.

To allow reception in different orders, the RRC connection release request message includes details of the last UL PDCP PDU sent by the UE, which PDU was transmitted by the UE. This ensures that when the RRC connection release request message is received, the connection can be maintained until all data is received, even if the RRC connection release request is received before the data. Step 306-307 corresponds to

steps

108 and 109, unless step 306 is not initiated until the last data packet indicated in the RRC connection release request is received.

Fig. 4 shows a further procedure for achieving an early release of a connection expecting DL data after UL data. The

steps

401 and 404 are the same as the

steps

201 and 204 described in fig. 1. In step 405, data is transmitted on the DRB and an RRC connection release request message is sent on SRB1 as described with respect to step 305. The BSR at step 403 considers the packet and the RRC connection release request message. Steps 406 to 409 correspond to steps 206 to 209 of fig. 2, except that only an RLC acknowledgement is sent in step 407, since the earlier request has been released in step 405. The connection release message in step 408 cannot be sent in advance to ensure ordering (in step 406) with DL data. Although the procedure of fig. 4 includes the same number of steps as fig. 2, the number of transmissions is reduced because the PRACH is not required to transmit the RRC connection release request message.

The RRC connection release request message may include one or more information items used by the eNoDEB in the procedures of fig. 3 and 4. Including the PDCP Sequence Number (SN) of the final PDCP packet to ensure reception of all data. The RRC connection release request message may also include an information element indicating whether subsequent downlink data is not expected (case of fig. 3) or expected (case of fig. 4).

For NB internet of things applications, up to 7-bit PDCP SNS have been agreed to be used, but LSBs of only a small number of SNS may be required. The message may also include a DRB ID for the data. Only one DRB is used in the proposed NB internet of things solution, so this is not necessary, but several DRBs may be established in other systems. The message may also indicate whether subsequent DL data is expected after the UL data. In solutions that do not require a DRB ID, only one additional byte is needed in the release message to provide the required information, even if all 7 bits of the PDCP SN are included, compared to the message structure that can be used for the procedure of figures 1 and 2.

As described above, the lack of mandatory ordering between SRB1 and DRB channels forces messages to be transmitted in an order, each message being sent only after a previous message has been acknowledged. This can be avoided if the RRC connection release request message can be transmitted in a data transmission on the DRB channel.

This can be achieved by modifying the PDCP header including information related to the connection release. Since the information will be sent with the data on the DRB, the order is maintained and there is no need to wait for an acknowledgement or indicate a packet number, as shown in the example above.

Two bits may be used in the header to give the required indication:

firstly, REL: release request- -if SDDE is not set, after UL PDU, if SDDE is set, after response DL PDU.

II, SDDE: subsequent downlink data anticipation

This data may be referred to as Release Assist Information (RAI). The PDCP data PDU format is symmetric for uplink and downlink. The SDE bit will be defined as NA in DL direction, while the REL bit can be used to indicate implicit release in DL direction.

As described above, it has been proposed to use 7-bit PDCP SNs in NB internet of things. However, this may be further reduced because 7 bits are unlikely to be needed. Fig. 5 shows an example of a PDCP header using 5-bit SN.

Another method of using the PDCP header is to define a PDCP control PDU to provide RAI information, for example, named "RAI control PDU". The RLC layer ensures in-order delivery, so the RAI control PDU can be related to a specific PDCP data PDU (previous or next in the flow) without including a number.

Preferably, the RAI control PDU is sent after the last UL PDCP data PDU to ensure reception after the last UL PDCP data PDU.

Fig. 6 shows an example structure of a RAI control PDU, which includes the SDDE information element as described above, as well as the regular element. The request for connection release is implicit in the transmission of the message, and thus no specific field corresponding to the above-mentioned RE is required. A new PDU type will be needed, as shown for example in fig. 7. Defining and using the RAI control PDU may be better than modifying the PDCP header unless the PDCP header can be modified without extension. If the header is extended, a penalty is added to each message, while control PDUs need to be sent only when needed.

The UE will preferably receive the last PDU from the application layer along with the information that it is the last UL PDU, and either expect or not expect a DL response. The PDCP layer will accordingly generate the required RAI control PDUs after the last UL PDCP PDU for transmission. The BSR transmitted prior to data transmission will take into account 1 byte of the RAI control PDU and it is likely that in most cases the RAI control PDU will be located in the last Transport Block (TB) of the UL message and no separate transmission will take place. Only when the TB happens to be completely filled with data that needs to be transmitted separately.

In the implementation of the NB internet of things, only one single DRB is proposed. However, if multiple DRBs are possible, the range of RAI control PDUs can be defined as DRBs that are transmitted only over them. The connection can be released only if all active DRBs request release. Alternatively, a single RAI control PDU may be sufficient to request the release of the connection, in which case the UE must coordinate the transmission of that PDU to ensure that it is not sent until all DRBs complete transmission.

The possibility of the UE sending RAI information (RRC or PDCP level as described above) may be subject to a specific grant from the network, either from a dedicated message or from broadcast system information. This may avoid the UE supporting the feature of sending signals to networks that do not support this feature.

As described above, the RRC connection release request message may be sent as an indication in a modified PDCP header or as a PDCP control PDU. Similarly, the RRC connection release message may also be provided in a PDCP header or a PDCP control PDU. The method removes one message exchange (explicit RRC connection release and RLC ACK) when DL data is expected. The PDCP header may be modified to include a Rel-BIT to provide RRC connection release messages, or a "release" PDCP control PDU may be used.

In the previous examples, an explicit message or indication from the eNoDEB acknowledged by the UE is used to release the connection and ensure correct synchronization of RRC states in the UE and the eNoDEB. However, autonomous release may also be achieved after earlier sending of the RAI information.

Fig. 8 shows an auto-release message exchange where there is no subsequent DL data expected. Steps 801 to 804 correspond to steps 101 to 104 discussed above. At step 805, data is transmitted on the DRB and an RRC connection release request message is transmitted on SRB 1. Once the eNodeB receives the RRC connection release request message, it sends an RLC ACK in step 806. When receiving the RLC ACK, the UE assumes that the request was successfully received and releases the connection to RRC idle. The procedure assumes that the eNodeB acts correctly on the RRC connection release request message and that the UE receives and acts correctly on the RLC ACK in order to maintain RRC state synchronization. If the UE does not receive an RLC ACK, it may assume that the RRC connection release request message was not successfully received by the eNodeB and may resend the RRC connection release request message until an RLC ACK is received or until a radio link failure is declared. The eNodeB may derive whether the UE has released the connection based on HARQ feedback, or to account for no further scheduling requests. The procedure of fig. 8 reduces the number of messages required because no RRC connection release message and associated RLC ACK are required.

Fig. 9 shows an auto-release message exchange where subsequent DL data is expected. Steps 901 to 904 are the same as discussed with reference to steps 201 to 204. In step 905, data and RRC connection release request messages are sent, as shown in fig. 8, step 805. In step 906, DL data is received at the UE, along with an RLC ACK of the RRC connection release request message. Once the UE has sent the RLC ACK of DLC data in step 907, the connection may be released.

A similar autonomous release procedure may be implemented for transmitting release requests on DRBs.

To ensure that the network maintains sufficient control over the RRC connection, the autonomous release may be subject to a specific grant from the eNoDEB when the connection is first established. For example, an indication may be provided in an RRC connection setup or recovery message, allowing for autonomous release of the connection. When allowed DL data is desired, it may further indicate whether to release autonomously and/or when expected DL data is allowed.

Those skilled in the art will recognize that methods according to embodiments may be performed by software computer programs, hardware, or a combination of software and hardware.

These methods are provided by way of example only. The disclosure of the present application is not limited to the specific combination of steps shown in the figures, and the steps described herein include any suitable subset or combination of steps performed in any suitable order. Portions of the method may be performed in parallel.

"user equipment" (UE) is used herein to refer to any device with processing and communication capabilities such that it is capable of performing methods in accordance with embodiments of the present invention. Those skilled in the art will recognize that such processing and communication capabilities may be incorporated into many different devices, and thus the term "user equipment" includes mobile telephones, personal digital assistants, personal computers, and many other devices.

It will be appreciated that the above method is applicable to any other wireless technology without losing the effect sought.

It will be apparent to the skilled person that any of the ranges or device values given herein may be extended or modified without losing the effect sought.

It is to be understood that the benefits and advantages described above may relate to one embodiment, or may relate to multiple embodiments. The embodiments are not limited to embodiments that solve any or all of the stated problems or that have any or all of the stated benefits and advantages.

Any reference to an "item refers to one or more of those items. The term "comprising" as used herein is meant to encompass the identified method blocks or elements, but such blocks or elements do not include an exclusive list, and a method or apparatus may encompass additional blocks or elements.

The steps of the methods described herein may be performed in any suitable order, or simultaneously where appropriate. Moreover, individual blocks may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.

It will be understood that the above description of the preferred embodiments is given by way of example only and that various modifications may be made by those skilled in the art. Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the scope of this invention.

Claims

1. A method for releasing a data connection over a radio link between a mobile device and a base station, the method being performed at the mobile device and comprising the steps of:

transmitting data from the base station on a first data channel,

transmitting a connection release request to the base station on a first signal channel, wherein the connection release request contains an identification of last data transmitted on the first data channel and an indication of expected subsequent data,

subsequently receiving data transmitted from the base station on the first data channel,

an acknowledgement is sent to the data that the data was,

receiving a connection release message from the base station, an

The data connection is released.

2. The method of claim 1 wherein the last data identification is a PDCP packet sequence number.

3. The method of claim 1 wherein the last data identifier is a PDCP packet sequence number and a radio bearer identifier.

4. A method according to any of claims 1 or 2, wherein said connection release message is transmitted from said base station to said mobile device in response to an acknowledgement at said base station of receipt of said data transmitted from said base station to said mobile device.

5. The method of claim 4, wherein the connection release message is a NAS message including a NAS release information element.

6. The method of claim 5, wherein the information element is transmitted from the base station to indicate a subsequent transmission of the NAS release information element.

7. The method of claim 6, wherein the information element is transmitted to indicate that connection release is disabled when the connection release message is an RRC message.

8. The method of claim 1, wherein the connection release message is an RRC message.

9. A method for releasing a data connection over a radio link between a mobile device and a base station, the method being performed at the mobile device and comprising the steps of:

transmitting data to the base station on a first data channel,

and transmitting a connection release request to said base station on a first signal channel, wherein said connection release request contains an identification of the last data transmitted on said first data channel and release assistance information,

receiving data on the first data channel from the base station,

after receiving an acknowledgement of the connection release request and receiving data from the base station, sending an acknowledgement and releasing the data connection,

wherein the release assistance information comprises an indication that a subsequent data transmission from the base station to the mobile device is expected.

10. The method according to claim 9, wherein the releasing of the data connection is explicitly granted by an indication in a dedicated or broadcast message.

11. The method of claim 9, wherein the connection release message is sent after data transmission when the indication is provided.

12. The method according to claim 9 or 10 or 11, wherein sending the release assistance information in an RRC or PDCP message requires explicit authorization via an indication in a dedicated or broadcast message.

13. A method for releasing a data connection over a radio link between a mobile device and a base station, the method being performed at the base station and comprising the steps of:

receiving data from the mobile device on a first data channel,

receiving a connection release request from said mobile device on a first signal channel, wherein said connection release request contains an identification of last data transmitted on said first data channel and an indication of expected subsequent data,

subsequently transmitting data to the mobile device on the first data channel,

sending a connection release message to the mobile device, an

The data connection is released.

14. The method of claim 13, wherein the identification of the last data is a PDCP packet sequence number.

15. The method of claim 13, wherein the last data identification is a PDCP packet sequence number and a radio bearer identification.

16. A method according to claim 13 or 14, wherein the connection release information is transmitted from the base station to the mobile device in dependence on data received at the base station, and wherein the data transmitted from the base station to the mobile device is acknowledged.

17. A method for releasing a data connection over a radio link between a mobile device and a base station, the method being performed at the base station and comprising the steps of:

receiving data from the mobile device on a first data channel,

receiving a connection release request from the mobile device on a first signal channel, wherein the connection release request contains an identification of last data transmitted on the first data channel and release assistance information,

transmitting data to said mobile device on said first data channel, receiving an acknowledgement of said data, and

the data connection is released and the data connection is released,

18. A method according to claim 17, wherein when providing said indication, said connection release message is sent after said data has been sent.