GB2547028A

GB2547028A - Early connection release

Info

Publication number: GB2547028A
Application number: GB1602101.6A
Authority: GB
Inventors: Marco Olivier; Bertorelle Jérôme; Assouline Benny
Original assignee: TCL Communication Ltd
Current assignee: TCL Communication Ltd
Priority date: 2016-02-05
Filing date: 2016-02-05
Publication date: 2017-08-09
Anticipated expiration: 2036-02-05
Also published as: CN108370606B; CN108370606A; GB2547028B; WO2017133470A1; GB201602101D0

Abstract

Several methods are described to enable the early release of a data connection after completion of a message exchange. Various messages and message flows between a User Equipment (UE) and an eNodeB are proposed to enable a positive indication that a radio link release can be requested by the UE. These include, receiving an acknowledgement that data transmitted over a data channel has been received, transmitting a connection release request that includes an identity of the last data transmitted on the first data channel, and a control Packet Data Unit (PDU) that comprises release assistance information indicating a request by the mobile device to release the connection. An embodiment describes the UE as an Internet of Things (IoT) device which utilizes the method to reduce power consumption by releasing a connection early rather than waiting for a Discontinuous Reception (DRX) period to expire. The connection release message may be an NAS or RRC message.

Description

EARLY CONNECTION RELEASE

TECHNICAL FIELD

[0001] This disclosure relates to methods and apparatus for releasing radio connections, in particular connections utilised by autonomous devices in a cellular network.

BACKGROUND

[0002] Autonomous devices communicating using cellular (or other) radio connections are commonly known as the “Internet of Things” (loT). Typically loT devices are autonomous and expected to function for extended periods of time without human intervention. Power consumption is therefore a critical aspect of the performance of loT devices.

[0003] The communication patterns of loT devices are characterised by widely spaced transmissions of small amounts of data. For example an uplink transmission may be of 20 - 200 bytes. In 50% of cases the uplink transmission may be followed by downlink data. There is then an extended silence before the next similar exchange.

[0004] For such patterns it is inefficient to keep a link open continuously and thus protocols typically open a link, make the transmission, and then close the link to save capacity and power. However, typically link closure is delayed by a predefined time to ensure there are no further transmissions. In loT type transmission that delay may represent a significant portion of the total power required to make the transmission.

[0005] 3GPP are proposing protocols for Narrow Band (NB) operation of loT devices within the general structure of the cellular standards maintained by 3GPP. In particular, implementations within the LTE standards are being explored. In the proposals a communication cycle starts with a device waking up and synchronising followed by a transition to the RRC_CONNECTED state. The communications exchange is then performed, after which the device enters a Discontinuous Reception (DRX) mode in order to reduce power consumption. Typically the DRX mode comprises a first period of short cycles followed by a second period of longer cycles. If no further communications are required after the second period, the device releases the RRC connection and returns to RRCJDLE. The DRX period may last several seconds compared to a few tens of milliseconds for the actual communications, and may represent more than 50% of the total power consumption.

[0006] There is therefore a need to reduce the power consumption of loT devices during such communication patterns.

[0007] The embodiments described below are not limited to implementations which solve any or all of the disadvantages of known systems.

SUMMARY

[0008] This Summary is provided to introduce 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. Methods according to the current disclosure are set out in the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Embodiments of the invention will be described, by way of example, with reference to the following drawings, in which: [0010] Figure 1 shows a first message exchange for connection release without subsequent DL data; [0011] Figure 2 shows a first message exchange for connection release with subsequent DL data; [0012] Figure 3 shows a second message exchange for connection release without subsequent DL data; [0013] Figure 4 shows a second message exchange for connection release with subsequent DL data; [0014] Figure 5 shows a PDCP data PDU format with RAI; [0015] Figure 6 shows a PDCP control PDU with RAI; [0016] Figure 7 shows PDU types; [0017] Figure 8 shows a third message exchange for connection release without subsequent DL data; and [0018] Figure 9 shows a third message exchange for connection release with subsequent DL data.

DETAILED DESCRIPTION

[0019] Embodiments of the present invention are described below by way of example only. These examples represent the best ways of putting the invention into practice that are currently known to the Applicant although they are not the only ways in which this could be achieved. 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.

[0020] loT communication patterns may cause a significant portion of power consumption to be while a device waits in DRX before releasing a connection and returning to sleep. An attribute of loT communications is that the device transmitting data is generally aware of the length of the data and when a transaction is completed. The device may thus be able to indicate to the network when it has finished with a connection and thus the network can release the connection.

[0021] 3GPP are working on two sets of proposals for NB-loT protocols, one using User Plane (UP) and one using the Control Plane (CP) of an LTE network for the carriage of user data. The current disclosure relates to a UP implementation. The current disclosure also relates to an implementation flavour in CP where the Non Access Stratum signalling (NAS) over an SRB1 bearer is used. The NAS method can be used when the integrity protection is not added to the Access Stratum. Within the UE, NAS is a protocol above RRC as per 3GPP TS 36.300. The counterpart of UE NAS resides in the Mobility Management Entity of the Core Network as per 3GPP TS 36.300.

[0022] Figure 1 shows a sequence of messages between a device (UE) and the mobile network to which the UE is connected, across the Uu interface. Typically the mobile network will be an LTE network and the messages will be exchange between the UE and the eNodeB to which the UE is connected.

[0023] At steps 101 - 104 standard messages are exchanged across the Uu interface in order to establish a connection for the transmission of data. In the conventional manner the SRB0 and SRB1 bearers are utilised as appropriate, and a DRB bearer is utilised for transmission of data. DL refers to downlink, UL to uplink. In the BSR message the UE indicates the amount of data it wishes to transmit, and the UL grant message indicates to the UE the resources allocated by the eNodeB for that transmission.

[0024] At step 104 Standard Message 4 — “RRC Connection Setup (SRB0)” with an additional IE may be utilised to indicate that the UE can expect to receive the REL bit over NAS at step 108. As a consequence, the UE would perform the RRC connection release only if the REL bit is conveyed over NAS and not when conveyed in an RRC message from the eNodeB. In particular, the UE would ignore an incoming RRC Connection Release message.

[0025] At step 105 the data is transmitted over the DRB and at step 106 the data is acknowledged at the RLC layer.

[0026] As outlined above, the UE is aware of the data to be sent and thus knows when the transmission is completed and the link is no longer required. In this example the UE also knows there is no acknowledgement expected for the data. At step 107 the UE transmits an RRC message requesting release of the connection. This message may be a new RRC message, named “RRC Connection Release Request’’ in Figure 1, defined for this purpose. Alternatively, an existing RRC message with an additional IE may be utilised. For example, the UE Assistance Information RRC message, which is usually used to indicate power setting modes, could be utilised 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 giving the required indication.

[0027] At step 108 the eNodeB transmits the RLC ACK for the RRC connection release request, and also an RRC Connection Release message to release the connection. The Poll/UL Grant message requests an RLC acknowledgement. The RRC Connection Release indication to release the connection can be conveyed in the form of the REL bit over NAS. Upon receipt, at step 109, the UE transmits the required RLC ACK and then releases the connection.

[0028] The process of Figure 1 thus allows the connection to be released quickly after completion of data transfer, without a requirement to wait for DRX cycles to complete.

[0029] Figure 2 shows a flow chart of a method similar to that of Figure 1, but in which downlink data is expected following the uplink data transmission. Steps 201-205 correspond to steps 101-105 of Figure 1, but at step 206 a downlink data packet is transmitted over DRB as well as the RLC ACK for the uplink data.

[0030] Steps 207 - 209 are then equivalent to steps 107 - 109. The process of Figure 2 thus achieves connection release promptly after the last data transmission.

[0031] Although the processes of Figures 1 and 2 give the ability to release the connection early, they also require additional transmissions compared to a standard exchange. The RRC Connection Release Request is a separate message and cannot be transmitted until after the end of the data transmission transaction (i.e. receipt or transmission of the RLC ACK for the UL/DL data). This is because the data is sent over DRB, whereas the RRC Connection Release Request is sent over SRB. Since RLC only maintains order within a logical channel, not between them, if the RRC Connection Release Request was sent before RLC acknowledgement of the data it would be possible for the RRC Connection Release Request to arrive before the data, thus potentially causing loss of that data.

[0032] If the RRC Connection Release Request is sent as a separate message (as in the methods of Figures 1 and 2) at the end of the transaction, UL resources cannot be requested in advance. In step 103, the BSR would cover only resources to send the UL data in step 105. As the RRC Connection Release Request is sent as a separate message it is not taken into account in the BSR sent at step 103 or step 203. A PRACH/scheduling request procedure may be required to be able to send the RRC Connection Release Request message, adding further overhead to the method, as up to 3 UL messages would be needed in steps 107 and 207.

[0033] Figure 3 shows a further process for achieving early release of a connection, with a reduced number of messages compared to the process of Figure 1.

[0034] Steps 301 - 304 are the same as steps 101 - 104 described in relation to Figure 1. At step 305 the data is transmitted on DRB in the conventional way, but an RRC Connection Release Request message is also sent on SRB1. The BSR value transmitted at step 303 takes into account the data packet and the RRC Connection Release Request message.

[0035] As explained above, RLC does not maintain order between messages on DRB and SRB. The RRC Connection Release Request message may thus arrive before the data packet, which may cause data to be lost. In fact, SRB1 is usually prioritised over DRB and thus is likely to arrive first, in the incorrect order.

[0036] In order to allow for reception in a different order, the RRC Connection Release Request message includes details of the last UL PDCP PDU that was transmitted by the UE. This ensures that upon receipt of the RRC Connection Release Request message the connection can be maintained until all data is received, even if the RRC Connection Release Request is received before the data. Steps 306 - 307 are then equivalent to steps 108 and 109, except step 306 is not initiated until the last data packet indicated in the RRC Connection Release Request is received.

[0037] Figure 4 shows a further process for achieving early release of a connection where DL data is expected following the UL data. Steps 401-404 are the same as steps 201-204 described in relation to Figure 1. At step 405, as described in relation to step 305, the data is transmitted on DRB and the RRC Connection Release Request message on SRB1. The BSR at step 403 takes into account the data packet and the RRC Connection Release Request message. Steps 406 - 409 are then equivalent to steps 206-209 of Figure 2, except that at step 407 only a RLC acknowledgement is sent, because the release request has already been sent earlier at step 405. The connection release message at step 408 cannot be sent earlier to ensure its ordering with the DL data at step (406) is maintained. Although the process of Figure 4 comprises the same number of steps as Figure 2, the number of transmissions is reduced as no PRACH is required to send the RRC Connection Release Request message.

[0038] In the processes of Figures 3 and 4, the RRC Connection Release Request message may include one or more items of information for use by the eNodeB. The PDCP Sequence Number (SN) of the final PDCP packet is included to ensure reception of all data. The RRC Connection Release Request message may also include an information element indicating if subsequent downlink data is not expected (case of Figure 3) or expected (case of Figure 4).

[0039] For NB loT applications it has been agreed that up to 7 bit PDCP SNs will be utilised, but it is possible that only a few LSBs of the SN may be required. The message may also include the DRB id used for the data. In the proposed NB loT solution only one DRB is utilised and so this is not required, but in other systems several DRBs could be established. The message may also indicate whether subsequent DL data is expected after the UL data. In a solution where the DRB id is not required, even if all 7 bits of the PDCP SN are included, only one additional byte is needed in the release message to provide the required information, compared to the message structure that could be utilised for the processes of Figures 1 and 2.

[0040] As has been explained above, the lack of enforced ordering between SRB1 and DRB channels enforces transmission of messages in a certain sequence, each message only being transmitted after a preceding message has been acknowledged. This could be avoided if it were possible to transmit an equivalent of an RRC Connection Release Request message within the data transmission over the DRB channel.

[0041] This can be achieved by modifying the PDCP header to include information relating to the release of the connection. Since the information would be transmitted on DRB with the data the ordering is maintained and there is thus no need to wait for acknowledgements or indicate packet numbers as in the above examples.

[0042] Two bits may be utilised in the header to give the required indication:- I. REL : Release request - after this UL PDU if SDDE is not set, after response DL PDU if SDDE set II. SDDE : Subsequent Downlink Data Expected [0043] This data may be referred to as Release Assistance Information (RAI). PDCP data PDU formats are symmetrical for uplink and downlink. The SDDE bit would be defined NA in the DL direction, while the REL bit could be used to instruct an implicit release in the DL direction.

[0044] As mentioned above it has been proposed to use a 7 bit PDCP SN in NB loT. However, this could be reduced further as it is unlikely 7 bits will be required. Figure 5 shows an example PDCP header using a 5 bit SN.

[0045] An alternative to utilising the PDCP header is to define a PDCP control PDU to provide the RAI information, for example, named “RAI control PDU”. The RLC layer ensures in-order delivery and therefore the RAI control PDU can be related to a specific PDCP data PDU (previous or next in the flow), without having to include numbering.

[0046] It may be preferable that the RAI control PDU is sent after the last UL PDCP data PDU to ensure that it is received after the last UL PDCP data PDU.

[0047] Figure 6 shows an example structure for an RAI control PDU which comprises an SDDE information element as discussed above, as well as conventional elements. The request for connection release is implicit in the transmission of the message and therefore a specific field corresponding to REL above is not required. A new PDU type will be required, for example as shown in Figure 7. Defining and using an RAI control PDU may be preferable to modifying the PDCP header, unless the PDCP header can be modified without an extension. If the header is extended a penalty is added to every message, whereas the control PDU only needs to be transmitted when it is required.

[0048] The UE would preferably receive the last PDU from the application layer together with the information that it is the last UL PDU, and that a DL response is expected or not. The PDCP layer would accordingly generate the required RAI control PDU for transmission after the last UL PDCP PDU. The BSR transmitted prior to data transmission would have taken into account the 1 byte for the RAI control PDU and it is likely that in most cases the RAI control PDU will be in the last Transport Block (TB) of the UL message and will not generate a separate transmission. It is only if the TB happens to be perfectly filled by the data that a separate transmission would be needed.

[0049] In the NB loT implementation only a single DRB is proposed. However, if multiple DRBs are possible, then the scope of the RAI control PDU may be defined as only the DRB on which it is transmitted. The connection can then only be released once all active DRBs have requested a release. Alternatively, a single RAI control PDU may be sufficient to request release of the connection, in which case the UE must coordinate transmission of that PDU to ensure it is only sent once transmissions on all DRBs are complete.

[0050] The possibility for a UE to send the RAI information (at RRC or PDCP level as described above) can be subject to specific authorization from the network, either from a dedicated message or from broadcast system information. This can avoid a UE which supports the feature sending signalling to networks which do not supporting the feature.

[0051] As explained above the RRC Connection Release Request message can be transmitted as an indication in a modified PDCP packet header or as a PDCP control PDU. Similarly, the RRC Connection Release message can also be provided in a PDCP packet header or as a PDCP control PDU. When DL data is expected this approach removes one message exchange (explicit RRC Connection Release and RLC ACK). The PDCP header may be modified to include one REL bit to provide the RRC Connection Release message, or a “release” PDCP control PDU can be used.

[0052] In the previous examples, an explicit message or indication from the eNodeB, confirmed by the UE, is utilised to release the connection and ensure correct synchronisation of RRC state at the UE and eNodeB. However, an autonomous release could also be implemented, following the earlier sending of the RAI information.

[0053] Figure 8 shows a message exchange for autonomous release where no subsequent DL data is expected. Steps 801 - 804 are equivalent to steps 101 - 104 discussed above. At step 805 the data is transmitted on DRB and an RRC Connection Release Request message is transmitted on SRB1. Once the eNodeB receives the RRC Connection Release Request message it sends an RLC ACK at step 806. Upon receipt of the RLC ACK the UE assumes the request was successfully received and releases the connection to RRC IDLE. This process assumes the eNodeB correctly acts upon the RRC Connection Release Request message, and that the UE correctly receives and acts upon the RLC ACK, in order for RRC state synchronisation to be maintained. If the UE does not receive the RLC ACK it can assume the RRC Connection Release Request message was not successfully received by the eNodeB and can retransmit the RRC Connection Release Request message until an RLC ACK is received or until a radio link failure is declared. The eNodeB can derive whether the UE has released the connection based on HARQ feedback, or by considering the absence of further scheduling requests. The process of Figure 8 reduces the number of messages required as no RRC Connection Release message and associated RLC ACK is required.

[0054] Figure 9 shows a message exchange for autonomous release where subsequent DL data is expected. Steps 901 - 904 are the same as discussed with reference to steps 201 - 204. At step 905 the data and an RRC Connection Release Request message are transmitted as described in relation to Figure 8, step 805. At step 906 the DL data is received at the UE, together with the RLC ACK of the RRC Connection Release Request message. Once the UE has sent its RLC ACK if the DL data at step 907, the connection can be released.

[0055] A similar autonomous release process can be implemented for transmission of the release request over DRB.

[0056] In order to ensure the network maintains sufficient control over RRC connections, autonomous release could be subject to specific authorisation from the eNodeB when the connection is first set up. For example, an indication could be provided in the RRC Connection Setup or Resume message that autonomous release is permissible for the connection. It can further indicate whether autonomous release when no DL data is expected and/or autonomous release when DL data is expected are allowed.

[0057] Those skilled in the art will appreciate that methods according to the embodiments may be carried out by software computer programs, hardware, or a combination of software and hardware.

[0058] These methods are provided by way of example only. The disclosure of this application is not restricted by the specific combination of steps shown in the figures, and described herein, but includes any appropriate subsets or combinations of steps performed in any appropriate order. Sections of the method may be performed in parallel.

[0059] The term 'user equipment' (UE) is used herein to refer to any device with processing and telecommunication capability such that it can perform the methods according to the embodiments of the present invention. Those skilled in the art will realize that such processing and telecommunication capabilities can be incorporated into many different devices and therefore the term 'user equipment' includes mobile telephones, personal digital assistants, PCs and many other devices.

[0060] It will be appreciated that the methods described above apply to any other wireless technologies without losing the effect sought.

[0061] Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person.

[0062] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages.

[0063] Any reference to 'an' item refers to one or more of those items. The term 'comprising' is used herein to mean including the method blocks or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or apparatus may contain additional blocks or elements.

[0064] The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, 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.

[0065] It will be understood that the above description of a preferred embodiment 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 performed at the mobile device and comprising the steps of transmitting data to the base station on a first data channel, in response to receiving an acknowledgement of the transmitted data, transmitting a connection release request message to the base station on a first signalling channel, receiving a connection release message from the base station, and releasing the data connection.

2. A method according to claim 1, wherein the acknowledgement is an RLC acknowledgement.

3. A method according to claim 1 or claim 2, wherein the connection release message is a NAS message including a NAS release information element.

4. A method according to claim 3, wherein an information element was transmitted from the base station to indicate the subsequent transmission of the said NAS release information element.

5. A method according to claim 4, wherein the said information element was transmitted to indicate to disable the connection release when the connection release message is an RRC message.

6. A method according to claim 1 or claim 2, wherein the connection release message is transmitted by the base station in response to receipt of the connection release request.

7. A method according to claim 1 or claim 2, wherein the connection release message is an RRC message.

8. A method for releasing a data connection over a radio link between a mobile device and a base station, the method performed at the mobile device and comprising the steps of transmitting data to the base station on a first data channel, subsequently receiving data, which data was transmitted from the base station to the mobile device on the first data channel, in response to receiving the data from the base station, transmitting a connection release request to the base station, receiving a connection release message from the base station, and releasing the data connection.

9. A method according to claim 8, wherein the connection release message is a NAS message including a NAS release information element.

10. A method according to claim 9, wherein an information element was transmitted from the base station to indicate the subsequent transmission of the said NAS release information element.

11. A method according to claim 10, wherein the said information element was transmitted to indicate to disable the connection release when the connection release message is an RRC message.

12. A method according to claim 1 or claim 2, wherein the connection release message is an RRC message.

13. A method according to any of claim 8, wherein the connection release message is transmitted by the base station in response to receipt of the connection release request.

14. A method according to claim 8, wherein the connection release message is an RRC message.

15. A method for releasing a data connection over a radio link between a mobile device and a base station, the method performed at the mobile device and comprising the steps of transmitting data to the base station on a first data channel, transmitting a connection release request to the base station on a first signalling channel, wherein the connection release request includes an identity of the last data transmitted on the first data channel, receiving a connection release message from the base station, and releasing the data connection.

16. A method according to claim 15, wherein the connection release message is a NAS message including a NAS release information element.

17. A method according to claim 16, wherein an information element was transmitted from the base station to indicate the subsequent transmission of the said NAS release information element.

18. A method according to claim 17, wherein the said information element was transmitted to indicate to disable the connection release when the connection release message is an RRC message.

19. A method according to claim 15, wherein the connection release message is transmitted by the base station in response to receipt of the connection release request and the data indicated as the last data transmitted on the first data channel.

20. A method according to claim 15, wherein the identity of the last data is a PDCP packet sequence number.

21. A method according to claim 15, wherein the identity of the last data is a PDCP packet sequence number and a radio bearer identity.

22. A method according to claim 1 or claim 2, wherein the connection release message is an RRC message.

23. A method for releasing a data connection over a radio link between a mobile device and a base station, the method performed at the mobile device and comprising the steps of transmitting data from to the base station on a first data channel, transmitting a connection release request to the base station on a first signalling channel, wherein the connection release request includes an identity of the last data transmitted on the first data channel and an indication that subsequent data is expected, subsequently receiving data transmitted from the base station on the first data channel, transmitting an acknowledgement of the data, receiving a connection release message from the base station, and releasing the data connection.

24. A method according to claim 23, wherein the identity of the last data is a PDCP packet sequence number.

25. A method according to claim 23, wherein the identity of the last data is a PDCP packet sequence number and a radio bearer identity.

26. A method according to any of claim 23 or claim 24, wherein the connection release message is transmitted from the base station to the mobile device in response to receiving, at the base station, an acknowledgement of the data transmitted from the base station to the mobile device.

27. A method according to claim 26, wherein the connection release message is a NAS message including a NAS release information element.

28. A method according to claim 27, wherein an information element was transmitted from the base station to indicate the subsequent transmission of the said NAS release information element.

29. A method according to claim 28, wherein the said information element was transmitted to indicate to disable the connection release when the connection release message is an RRC message.

30. A method according to claim 23, wherein the connection release message is an RRC message.

31. A method for releasing a data connection over a radio link between a mobile device and a base station, the method performed at the mobile device and comprising the steps of transmitting data to the base station on a first data channel, the data packet headers comprising release assistance information indicating a request by the mobile device to release the connection, receiving a connection release message from the base station, and releasing the data connection.

32. A method according to any of claim 31, wherein the release assistance information further comprises an indication that a subsequent data transmission from the base station to the mobile device is expected, and wherein when such an indication is provided the connection release message is transmitted after that data has been transmitted.

33. A method according to claim 31 or claim 32, wherein the packet headers are PDCP headers.

34. A method according to any of claims 31 to 33, wherein the connection release message is transmitted from the base station in response to receipt of the release assistance information at the base station.

35. A method according to claim 31, wherein the connection release message is an RRC message.

36. A method for releasing a data connection over a radio link between a mobile device and a base station, the method performed at the mobile device and comprising the steps of transmitting data to the base station on a first data channel, transmitting on the first data channel a control PDU comprising release assistance information indicating a request by the mobile device to release the connection from the mobile device to the base station, receiving a connection release message from the base station, and releasing the data connection.

37. A method according to claim 36, wherein the control PDU is a PDCP control PDU.

38. A method according to claim 36 or claim 37, wherein the connection release message is transmitted by the base station in response to receiving the release assistance information.

39. A method for releasing a data connection over a radio link between a mobile device and a base station, the method performed at the mobile device and comprising the steps of transmitting data to the base station on a first data channel, transmitting a connection release request to the base station on a first signalling channel, wherein the connection release request includes an identity of the last data transmitted on the first data channel, and releasing the connection upon receipt of an acknowledgement of the connection release request.

40. A method according to claim 39, wherein the releasing of the connection is subject to an explicit authorization from the base station.

41. A method for releasing a data connection over a radio link between a mobile device and a base station, the method 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 the base station on a first signalling channel, wherein the connection release request includes an identity of the last data transmitted on the first data channel and the release assistance information, receiving data on the first data channel from the base station, upon receipt of an acknowledgement of the connection release request and receipt of the data from the base station, transmitting an acknowledgement, and releasing the data connection.

42. A method according to claim 41, wherein the releasing of the connection is subject to an explicit authorization by an indication in a dedicated or broadcasted message.

43. A method according to claim 41, wherein the release assistance information further comprises an indication that a subsequent data transmission from the base station to the mobile device is expected, and wherein when such an indication is provided the connection release message is transmitted after that data has been transmitted.

44. A method according to claim 41 or claim 42 or claim 43, wherein the sending of the release assistance information in an RRC or PDCP message is subject to an explicit authorization by an indication in a dedicated or broadcasted message.

45. A method for releasing a data connection over a radio link between a mobile device and a base station, the method performed at the base station and comprising the steps of receiving data from a mobile device on a first data channel, receiving a connection release request message from the mobile device on a first signalling channel, transmitting a connection release message to the mobile device in response to receipt of the connection release request message, and releasing the data connection.

46. A method for releasing a data connection over a radio link between a mobile device and a base station, the method performed at the base station and comprising the steps of receiving data from a mobile device on a first data channel, transmitting data to the mobile device on the first data channel, receiving a connection release request from the mobile device, transmitting to the mobile device a connection release message, and releasing the data connection.

47. A method according to claim 46, wherein the connection release message is transmitted by the base station in response to receipt of the connection release request.

48. A method for releasing a data connection over a radio link between a mobile device and a base station, the method performed at the base station and comprising the steps of receiving data from a mobile device on a first data channel, receiving a connection release request from the mobile device on a first signalling channel, wherein the connection release request includes an identity of the last data transmitted on the first data channel, transmitting a connection release message to the mobile device, and releasing the data connection.

49. A method according to claim 48, wherein the connection release message is transmitted by the base station in response to receipt of the connection release request and the data indicated as the last data transmitted on the first data channel.

49. A method according to claim 48 or claim 49, wherein the identity of the last data is a PDCP packet sequence number.

50. A method according to claim 48, wherein the identity of the last data is a PDCP packet sequence number and a radio bearer identity.

51. A method for releasing a data connection over a radio link between a mobile device and a base station, the method 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 signalling channel, wherein the connection release request includes an identity of the last data transmitted on the first data channel and an indication that subsequent data is expected, subsequently transmitting data to the mobile device on the first data channel, transmitting to the mobile device a connection release message, and releasing the data connection.

52. A method according to claim 51, wherein the identity of the last data is a PDCP packet sequence number.

53. A method according to claim 51, wherein the identity of the last data is a PDCP packet sequence number and a radio bearer identity.

54. A method according to claim 51 or claim 52, wherein the connection release message is transmitted from the base station to the mobile device in response to receiving, at the base station, an acknowledgement of the data transmitted from the base station to the mobile device.

55. A method for releasing a data connection over a radio link between a mobile device and a base station, the method performed at the base station and comprising the steps of receiving data from the mobile device on a first data channel, the data packet headers comprising release assistance information indicating a request by the mobile device to release the connection, transmitting to the mobile device a connection release message, and releasing the data connection.

56. A method according to any of claim 55, wherein the release assistance information further comprises an indication that a subsequent data transmission from the base station to the mobile device is expected, and wherein when such an indication is provided the connection release message is transmitted after that data has been transmitted.

57. A method according to claim 55 or claim 56, wherein the packet headers are PDCP headers.

58. A method according to of claims 55 to 57, wherein the connection release message is transmitted from the base station in response to receipt of the release assistance information at the base station.

59. A method for releasing a data connection over a radio link between a mobile device and a base station, the method performed at the base station and comprising the steps of receiving data from the mobile device on a first data channel, receiving on the first data channel a control PDU comprising release assistance information indicating a request by the mobile device to release the connection from the mobile device to the base station, transmitting to the mobile device a connection release message, and releasing the data connection.

60. A method according to claim 59, wherein the control PDU is a PDCP control PDU.

61. A method according to claim 59 or claim 60, wherein the connection release message is transmitted by the base station in response to receiving the release assistance information.

62. A method for releasing a data connection over a radio link between a mobile device and a base station, the method 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 signalling channel, wherein the connection release request includes an identity of the last data transmitted on the first data channel, and transmitting to the mobile device an acknowledgement of receipt of the connection release request.

63. A method for releasing a data connection over a radio link between a mobile device and a base station, the method performed at the base station and comprising the steps of receiving data from the mobile device on a first data channel, and receiving a connection release request from the mobile device on a first signalling channel, wherein the connection release request includes an identity of the last data transmitted on the first data channel and the release assistance information, transmitting data to the mobile device on the first data channel, receiving an acknowledgement of the data, and releasing the data connection.

64. A method according to any of claim 63, wherein the release assistance information further comprises an indication that a subsequent data transmission from the base station to the mobile device is expected, and wherein when such an indication is provided the connection release message is transmitted after that data has been transmitted.