WO2022205340A1

WO2022205340A1 - Enhancement for multi shot based rach sdt scheme

Info

Publication number: WO2022205340A1
Application number: PCT/CN2021/085025
Authority: WO
Inventors: Jagdeep Singh Ahluwalia; Haibo Xu; Mengchen ZHANG; Yinghao GUO
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2021-04-01
Filing date: 2021-04-01
Publication date: 2022-10-06
Also published as: CN117044298A

Abstract

Described is a user device (300) configured to transmit a message to a node (301) during an ongoing communication session, the message comprising a field comprising an indirect indication of the number of packets of the ongoing communication session remaining to be transmitted by the user device.

Description

ENHANCEMENT FOR MULTI SHOT BASED RACH SDT SCHEME

FIELD OF THE INVENTION

This invention relates to a multi shot random access channel (RACH) based small data transmission (SDT) scheme.

BACKGROUND

Small data transmission (SDT) in radio resource control (RRC) INACTIVE mode is being specified for the 3GPP Release 17.

Prior methods have been more focused on supporting Single Shot (one packet) transmission during the small data transmission. However, to support multi shot SDT, there are a number of factors that need to be taken into account, as the multi shot procedure design may be more complex and may require additional information exchange between the user equipment (UE) device and the network to efficiently support a multi shot SDT procedure.

Qcom, in R2-2101223, have proposed to utilize UE assistance/traffic pattern information, which is quite similar to the configuration (CG) request message in long term evolution (LTE) , which may be taken as the basis for any improvement.

The assistance information (or small data request message) may be a radio resource control (RRC) message or may comprise new RRC parameters in the existing RRC message or a MAC control element (CE) . The assistance information could be similar to the CG request message for further or subsequent small data transfer. The UE assistance information message should be able to provide the information, such as the amount of data in the buffer and/or the future small data traffic profile (i.e. one or multiple) .

The following contents may be considered in the UE assistance information. Firstly, buffer status information, to indicate the amount of data UE may already have in the buffer. Secondly, small data traffic pattern, to indicate the type of small data traffic, either one-shot or multi-shot traffic. The traffic pattern can also optionally include the periodicity of traffic arrival and the possible amount of data for each traffic occasion in case of a multi shot traffic.

Figures 1A and 1B show communication flows between a user equipment (UE) 100 and a gNodeB (gNB) 101. The use of CG allocations within the RRCRelease message for subsequent data transmission for a RACH based STD procedure according to a known method is illustrated.

In Figure 1A, in RRC_INACTIVE mode, the RRCResumeRequest, Small Data Request Message, and Segmented UL small data are sent from the UE 100 to the gNB 101 at 102. At 103, the RRCRelease (+CG Config) are sent from the gNB 101 to the UE 100 over MSGB with downlink (DL) data. At 104, subsequent uplink (UL) data is sent from the UE 100 to the gNB 101 on CG resource.

In Figure 1B, in RRC_INACTIVE mode, the Random Access Preamble is sent from the UE 101 to the gNB 101 in MSG1 at 105. At 106, the Random Access Response is sent from the gNB 101 to the UE 100 in MSG2. The RRCResumeRequest, Small Data Request Message, and Segmented user data are sent from the UE 100 to the gNB 101 over MSG3 at 107. At 108, the RRCRelease (+CG Config) are sent from the gNB 101 to the UE 100 over MSG4. At 109, subsequent UL data is sent from the UE 100 to the gNB 101 on CG resource.

However there are problems with the RRC Release Message being sent in MSGB or MSG4. If the RRC Release message is sent first and then the subsequent data is transmitted, it remains unclear when the SDT procedure ends or when is considered as completed. Further, it is unclear which keys are used to encrypt the subsequent data packets. For example, it may be unclear if the new key is received in the RRC Release message, or the key with which the first data packet was sent.

Further, if the new key is used in the current session, it is unclear how the new key should be delivered to the UE for the next session. There is no possibility for the network to send a RRC Resume message to transition the UE to RRC_Connected State after RRC Release message.

It is desirable to develop an multi shot RACH based SDT scheme where the UE is able to transmit or receive multiple small packets of data while remaining in RRC INACTIVE mode.

SUMMARY

According to one aspect there is provided a user device configured to transmit a message to a node during an ongoing communication session, the message comprising a field comprising an indirect indication of the number of packets of the ongoing communication session remaining to be transmitted by the user device.

The session may be a small data transmission session. In this case the node may usefully manage aspects of the session in dependence on the indication.

The node may be a target node. The user device may be configured to transmit the message to the target node when transitioning from a source node to the target node during an ongoing communication session. In this case the target node may make use of the indication to help manage the transfer of the session. The node may be a base station. The node may be a gNodeB (gNB) .

The user device may store data mapping numbers of packets remaining to be transmitted to data tokens, the user device being configured to select one of the data tokens as content for the field. This may be a convenient way to determine the appropriate content. The mapping data may be a look-up table or it may be stored algorithmically.

The mapping data may map one of the data tokens to zero packets remaining to be transmitted. This can indicate that the session is ending.

The mapping data may map one of the data tokens to one packet remaining to be transmitted. The mapping data may map one of the data tokens only to one packet remaining to be transmitted. This may be efficient since a session having a single packet remaining may be a relatively frequent occurrence.

The mapping data may map one or more of the data tokens to respective ranges of numbers of packets remaining to be transmitted. This can avoid having too many tokens and thereby reduce the number of bits needed to represent each token.

The ranges may include one or more of: (i) less than two, (ii) less than five, (iii) two to five, (iv) six to ten, (v) less than ten, and (vi) an undefined non-zero number of packets. One or more of these may break the range of possible values down with efficiency.

The user device may be configured to transmit the message as an uplink radio resource control, RRC, message and the communication session is implemented via a small data transmission, SDT, procedure. This may provide compatibility with existing architectures.

The user device may be configured to generate the uplink RRC message as an RRC SDT Cell Update message transmitted as part of a small data transmission, SDT, random access channel, RACH, procedure. This may provide compatibility with existing architectures.

The user device may be configured to provide downlink packet data convergence protocol, PDCP, status report data of the communication session for transmission from the target node to the source node. This can assist in the transfer of the session.

The user device may be configured to continue in an RRC_INACTIVE State and maintain the PDCP sequence numbers for the ongoing communication session for data radio bearers and signal radio bearers. This can assist in the transfer of the session.

According to a second aspect there is provided a network device configured to operate as a target node for a user device which is transitioning from a source node to the target node during an ongoing communication session in a communications network, the target node configured to: receive a message from the user device comprising a field comprising an indirect indication of the number of packets of the ongoing communication session remaining to be transmitted by the user device as part of the ongoing communication session; and establish a data forwarding tunnel between the source node and the target node in a manner determined based on the indication of remaining packets.

The anchor node of the tunnel may be determined in dependence on the indication. This can help to manage the tunnel.

Whether the session is continued using dynamic grant or configured grant may be determined in dependence on the indication. This can allow efficient ongoing management of the session.

The network device may be configured to determine the manner in dependence on the indication. This can allow the network device to manage the future handling of the session in dependence on the number of remaining packets.

The message (which may be a NAS message) , or another message received by the network from the user device, comprises a positioning measurement report and the network comprises a device configured to determine whether to relocate or to anchor the session in dependence on the positioning measurement report. This can allow the management of the session to be dependent on the position of the user device.

The network device may be configured to: in response to the message from the user device transmit to the user device a downlink message comprising one or more of: (i) configured grant configuration data for the user device, (ii) a temporary radio network identifier for the user device, (iii) a Physical Uplink Control Channel (PUCCH) and/or sounding reference signal (SR) configuration . (iv) a nextHopChainingCount (NCC) (v) Radio Link Monitoring (RLM) and/or Beam Management (BM) configuration for inactive state. This may provide compatibility with existing architectures.

According to a third aspect there is provided a user device configured to transmit an uplink message to a node during an ongoing communication session, the uplink message comprising a field comprising a direct or indirect indication of the number of packets of the ongoing communication session remaining to be transmitted by the user device, the user device being configured to be responsive to data received in a downlink response message to the uplink message to adopt a subsequent communication mode for the session.

The node may be a target node and the user device may be configured to transmit the message when transitioning from a source node to the target node during the communication session. This can assist in the transitioning of the session.

The user device may be responsive to the downlink response message containing one or more of: (i) configured grant configuration data for the user device, (ii) a temporary radio network identifier for the user device, (iii) a Physical Uplink Control Channel (PUCCH) and/or sounding reference signal configuration (iv) a nextHopChainingCount (NCC) (v) Radio Link Monitoring (RLM) and/or Beam Management (BM) configuration for inactive state, (vi) contention resolution information. This may provide compatibility with existing architectures.

The device may be configured to, on receiving the downlink message, stop a timer that was started in response to an RRCResumeRequest message or a functional analogue thereof. This can resolve ambiguity in when to stop such a timer. The timer may be a T319 timer.

The user device may be configured to verify a connected network by means of the downlink message and to continue data transmission consequent on the message only if the network is verified. This can avoid continuation with the wrong network.

The user device may be configured to discontinue monitoring of a control channel in response to the downlink message. This can reduce consumption of resources. The control channel may be an L1 control channel PDCCH.

The downlink message may comprise a field to which the user device is responsive to maintain a small data transmission session. This can allow the network to signal whether to continue such a session.

The user device may be responsive to the downlink message not comprising the said field to terminate a small data transmission session. This can allow the network to discontinue such a session.

The downlink message may be a Downlink RRC Message. This may provide compatibility with existing architectures.

The user device described above may be configured to, in response to there being a non-zero number of packets of the ongoing communication session remaining to be transmitted, send a power headroom report to a network node. This can assist the network in managing the session.

BRIEF DESCRIPTION OF THE FIGURES

The present invention will now be described by way of example with reference to the accompanying drawings. In the drawings:

Figures 1A and 1B schematically illustrate communication flows between a user equipment (UE) and a gNodeB (gNB) illustrating the use of CG allocations within the RRCRelease message for subsequent data transmission for a RACH based STD procedure.

Figure 2 shows a flowchart illustrating an example of the steps performed by a target node in a communication system.

Figures 3A and 3B show communication flows between a user equipment (UE) and a gNodeB (gNB) according to embodiments of the present invention.

DETAILED DESCRIPTION

Embodiments of the present invention can provide a solution where the UE device is able to transmit or receive multiple small packets of data while remaining in RRC INACTIVE Mode and, using the approach described herein, a multi shot SDT procedure may be enhanced by enhancing the UE traffic pattern Information.

In embodiments of the present invention, the traffic pattern Information that is transferred from the UE device can be enhanced such that it contains either an index to a lookup table, which can indicate the range of the number of subsequent packets to be transmitted, or the exact number of packets to be transmitted.

Generally, as will be described in more detail below, the UE can be configured to transmit a message to a node during an ongoing communication session which comprises a field comprising an indirect indication of the number of packets of the ongoing communication session remaining to be transmitted by the user device.

Such granular or exact information in terms of the number of packets to be transmitted may provide full flexibility to the network to take a decision based on the traffic pattern information received along with MSG A or MSG 3 and other factors, such as device battery, device mobility and network load condition, to either continue using dynamic grant (DG) , or to use configured grant (CG) for the subsequent transmission in the current SDT session.

Signaling this information may provide full flexibility to the network to take a decision based on the traffic pattern information received to efficiently allocate resources to save UE power, as will be described in more detail below.

For SDT, there may be number of use cases where the number of occasions/packets to transmit for subsequent data can be known beforehand at the UE. This may also be true for the cases where NAS signaling messages containing positioning measurement reports, which might be configured as periodic reports, are transferred to the network using SDT.

Examples of such periodic traffic includes (R2-2006582) heart-beat/keep-alive traffic from IM/email clients and other apps, traffic from wearables (such as periodic positioning information etc) , industrial wireless sensor networks transmitting temperature or pressure readings periodically, smart meters and smart meter networks sending periodic meter readings.

Parameters such as requestedNumOccasions, which indicates the requested number of PUR grant occasions in LTE within the PURConfigurationRequest message, may not be granular. There may be two possible values for this, one and infinite, which are not effective from the resource allocation point of view for SDT. It is desirable to improve this, as SDT will support a wide variety of use cases.

To enhance the traffic pattern information within MSG 3, the UE may provide a number of occasions/packets to transmit, for example in the terms of an index to a lookup table, as shown in Table 1, or an exact number of packets along with the requested TBS and periodicity.

With only three bits used for the index in the example illustrated in Table 1, sufficient information may be provided to the network for selection between DG and CG resource allocations.

Table 1:

Some possible variations for indicating number of packets for transmission may include:

(i) the number of packets remaining to be transmitted = the total packets to transmit in SDT session -1 (initial transmission) in case of SDT procedure initiation;

(ii) the number of packets remaining to be transmitted (in the target cell after cell reselection) = the total packets to transmit in SDT Session (packets already transmitted/acknowledged in the source cell) ;

(iii) subsequent transmission needed (True/False) ;

(iv) any variant of the range shown in Table 1.

Other implementations are possible.

This may also be useful when SRB 2 is used for transferring NAS signaling messages containing positioning measurement reports which are periodic in nature. In this case, such information may be known as an AS layer, or informed from NAS layer to AS layer.

This information may also be transferred to the last serving gNB node to make a decision to relocate, or to anchor a SDT session when the SDT session is initiated in a non-anchor gNB, or when the UE performs cell reselection during the SDT session and moves away from the serving gNB.

Therefore, in some implementations, the node that the message is transmitted to from the UE may be a target node, such as a gNB or other base station. The UE may be configured to transmit the message to the target node when transitioning from a source node to the target node during an ongoing communication session. In this case the target node may make use of the indication to help manage the transfer of the session.

The UE may store data mapping numbers of packets remaining to be transmitted to data tokens and may be configured to select one of the data tokens as content for the field. As discussed above, the mapping data may be a look-up table or it may be stored algorithmically. The mapping data may conveniently map one of the data tokens to zero packets remaining to be transmitted, which can indicate that the session is ending.

The mapping data may map one or more of the data tokens to respective ranges of numbers of packets remaining to be transmitted. This can avoid having too many tokens and thereby reduce the number of bits needed to represent each token. As illustrated in Table 1 above, in one implementation the ranges include (i) less than two, (ii) less than five, (iii) two to five, (iv) six to ten, (v) less than ten, and (vi) an undefined non-zero number of packets.

To provide compatibility with existing architectures, the UE can be configured to transmit the message as an UL RRC message. the UE can be configured to generate the uplink RRC message as an RRC SDT Cell Update message transmitted as part of a small data transmission, SDT, random access channel, RACH, procedure.

To assist in the transfer of the session, the UE can be configured to provide downlink packet data convergence protocol (PDCP) status report data of the communication session for transmission from the target node to the source node. The UE can be configured to continue in an RRC_INACTIVE State and maintain the PDCP sequence numbers for the ongoing communication session for data radio bearers and signal radio bearers.

Therefore, as described above, the UE may provide several occasions/packets to transmit either in the terms of an index to a lookup table or an exact number of packets to be transmitted to the network. This may be applicable for both CG and RACH based schemes. This granular or exact information, in terms of the number of packets to be transmitted, may provide full flexibility to the network to take a decision to either use DG or to use CG for the subsequent transmission in the current RACH based SDT session.

In some implementations, the target node for the UE may be transitioning from a source node to the target node during an ongoing communication session. In this case, the target node may be configured to perform the steps shown in the method flowchart 200 in Figure 2. At step 201, the method comprises receiving a message from the user device comprising a field comprising an indirect indication of the number of packets of the ongoing communication session remaining to be transmitted by the user device as part of the ongoing communication session. At step 202, the method comprises establishing a data forwarding tunnel between the source node and the target node in a manner determined based on the indication of remaining packets.

In dependence on the indication, one or more of the following determinations may be made. The anchor node of the tunnel may be determined, which may help to manage the tunnel. Whether the session is continued using DG or CG may be determined, which may allow efficient ongoing management of the session.

The network device may be configured to determine the manner in dependence on the indication, which may allow the network device to manage the future handling of the session in dependence on the number of remaining packets.

The message (which may be a NAS message) , or another message received by the network from the user device, may comprise a positioning measurement report and the network may comprise a device configured to determine whether to relocate or to anchor the session in dependence on the positioning measurement report. This can allow the management of the session to be dependent on the position of the user device.

The network device may be configured to, in response to the message from the UE, transmit to the user device a downlink message comprising one or more of: (i) configured grant configuration data for the user device, (ii) a temporary radio network identifier for the user device, (iii) a Physical Uplink Control Channel (PUCCH) and/or sounding reference signal (SR) configuration . (iv) a nextHopChainingCount (NCC) (v) Radio Link Monitoring (RLM) and/or Beam Management (BM) configuration for inactive state. This may provide compatibility with existing architectures.

Enhancement of the multi shot SDT procedure can also be achieved via the introduction of a new DL RRC Message between RRC ResumeRequest and RRC Release message, which can act as a RRC Reconfiguration message and can signal any required configuration during the SDT procedure.

The introduction of such a message can signal or change any required configuration during the multi shot SDT procedure. Since the multi shot SDT procedures will be longer compared to the Single Shot SDT procedure, the introduction of this message may also help to resolve existing issues associated with multi shot SDT procedure where no DL message is assumed to be used other than the RRCRelease message that terminates the SDT procedure. The new DL RRC message introduced herein, referred to as the RRC SDT resume message, may be transmitted in response to RRC resume request.

To illustrate this aspect, Figure 3A shows an exemplary communication flow between a user equipment (UE) 300 and a gNodeB (gNB) 301. The gNodeB may be a base station or other network device.

At the start of the communication flow, the UE is in RRC_Inactive mode. Then an SDT procedure begins, for example because the UE wants to transmit data to the GNB.

A message 1 (MSG1) is sent from the UE to the gNB. This is an SDT indication indicating that the UE wishes to commence an SDT session.

Then a message 2 (MSG2) is sent from the gNB to the UE. This is a grant permitting the SDT session to develop.

Then a message 3 (MSG3) is sent from the UE to the gNB. This is an RRC Resume Request with uplink data. This provides information for setting up the SDT session such as BSR and enhanced traffic pattern information.

Then a message 4 is sent from the network device to the UE. This is a message which will be termed RRC SDT Resume Message. The RRC SDT Resume message can carry a range of optional information that can be used by the UE to help set up the session. Some non-limiting examples include contention resolution information, configured grant configuration information, information about control channels, . NCC information and I-RNTI information, and an indication for the device to send a Power Headroom Report (PHR) . Any of this information may later be used by the UE in setting up the session.

Depending on the content of that message 4 and optionally also on the configuration of the UE and the network, the session can continue in dynamic grant (DG) or configured grant (CG) mode.

These options are set out in Figure 3A. For the case of DG, the session proceeds by DCI messages being sent on the downlink and subsequent uplink data being sent on the uplink, as shown in Figure 3A. For the case of CG, the session proceeds by subsequent uplink data being sent on the uplink.

At the end of the session, the gNB sends an RRC release message. The SDT procedure ends and the UE enters RRC Inactive mode.

Figure 3B shows an alternative communication flow between a user equipment (UE) 300 and a gNodeB (gNB) 301. The gNodeB may be a base station or other network device.

At the start of the communication flow the UE is in RRC_Inactive mode. Then an SDT procedure begins, for example because the UE wants to transmit data to the gNB.

The UE sends a message A (MSGA) to the gNB. This is an RRC Resume Request with uplink data. This provides information for setting up the SDT session such as BSR and enhanced traffic pattern information.

Then a message B is sent from the network device to the UE. This is a message which will be termed RRC SDT Resume Message. The RRC SDT Resume message can carry a range of optional information that can be used by the UE to help set up the session. Some non-limiting examples include contention resolution information, configured grant configuration information, information about control channels e.g. NCC information and I-RNTI information. Any of this information may later be used by the UE in setting up the session.

Depending on the content of that message B and optionally also on the configuration of the UE and the network, the session can continue in dynamic grant (DG) or configured grant (CG) mode.

These options are set out in Figure 3B. For the case of DG, the session proceeds by DCI messages being sent on the downlink and subsequent uplink data being sent on the uplink, as shown in figure 2B. For the case of CG, the session proceeds by subsequent uplink data being sent on the uplink.

The UE may be configured to transmit an uplink message to a node during an ongoing communication session, the uplink message comprising a field comprising a direct or indirect indication of the number of packets of the ongoing communication session remaining to be transmitted by the user device, the user device being configured to be responsive to data received in a downlink response message to the uplink message to adopt a subsequent communication mode for the session.

The node may be a target node and the UE may be configured to transmit the message when transitioning from a source node to the target node during the communication session, which can assist in the transitioning of the session.

The UE may be responsive to the downlink response message containing one or more of: (i) configured grant configuration data for the user device, (ii) a temporary radio network identifier for the user device, (iii) a Physical Uplink Control Channel (PUCCH) and/or sounding reference signal configuration (iv) a nextHopChainingCount (NCC) (v) Radio Link Monitoring (RLM) and /or Beam Management (BM) configuration for inactive state, (vi) contention resolution information. This may provide compatibility with existing architectures.

The UE may be configured to, on receiving the downlink message, stop a timer that was started in response to the RRCResumeRequest message or a functional analogue thereof. This can resolve ambiguity in when to stop such a timer. In a preferred embodiment, the timer is a T319 timer.

The UE may be configured to verify a connected network by means of the downlink message and to continue data transmission consequent on the message only if the network is verified, which can avoid continuation with the wrong network.

The UE may be configured to discontinue monitoring of a control channel in response to the downlink message. This can reduce consumption of resources. The control channel may be an L1 control channel PDCCH.

The downlink message may comprise a field to which the UE is responsive to maintain a small data transmission session, which can allow the network to signal whether to continue such a session.

The UE may be responsive to the downlink message not comprising the said field to terminate a small data transmission session, which can allow the network to discontinue such a session.

To provide compatibility with existing architectures, the downlink message may be a Downlink RRC Message.

The UE may trigger sending a power headroom report (PHR) if there is subsequent uplink transmission of data packets after the first packet transmission. (i.e the case where the number of subsequent packets to be transmitted is > 0) .

Some of the advantages of introducing the RRC SDT resume message are described below.

The RRC SDT resume message may be used as the response message to RRC resume request for the multi shot SDT procedure. A T319 timer may be stopped on receiving RRC SDT resume message and the SDT procedure may then be largely dependent only on the number of data packets to be transmitted and the periodicity that is desired.

The RRC SDT resume message may be used for network verification from a UE point of view by receiving the RRC SDT resume message on a dedicated control channel (DCCH) before continuing with a subsequent data transmission.

The RRC SDT resume message may be used for carrying the ConfiguredGrantConfig in case CG is used for subsequent transmission within this SDT session.

The RRC SDT resume message may provide reliable means of delivering contention resolution MAC CE in the new message.

The RRC SDT resume message may be used to signal reserved NCC, I-RNTI to be used if a subsequent RRCResume Request is triggered due to data arrival for non-SDT DRB.

The RRC SDT resume message may be used for the NW to configure INACTIVE SRS for carrier switching between Normal Uplink (NUL) and Supplementary Uplink (SUL) for SDT. The SRS transmission may only be performed during subsequent transmission, i.e only if there is multi shot transmission.

The RRC SDT resume message may be used as an alternative to the RRC cell update confirm message if the RRC resume request is reused for the cell reselection procedure in the target cell. In this message, the new NCC, I-RNTI may be provided in the target cell for subsequent transmissions.

Overall, the RRC SDT resume message may also reduce the specification impact as the procedure may define one new DL RRC message that can be used for multiple purposes.

The RRC SDT resume message, which may be used for multiple purposes, has advantages including the following.

As mentioned above, the message may help to resolve the ambiguity for when to stop the T319 timer. The RRC SDT resume message may be the response message to RRC resume request message for the multi shot SDT procedure. The T319 may be stopped on receiving the RRC SDT resume message and the SDT procedure may then be largely dependent only on the number of data packets to be transmitted and the periodicity that is desired while considering the diverse traffic patterns for the use cases.

The message may also allow for network verification for the UE. The RRC SDT resume message may be used for network verification from a UE point of view by receiving the RRC SDT resume message on DCCH before continuing with a subsequent data transmission.

The RRC SDT resume message may also be used for carrying contention resolution (CR) MAC CE.

The RRC SDT resume message may be used for carrying various configuration parameters for the UE such as (i) ConfiguredGrantConfig in case the CG is used for a subsequent transmission within this SDT session, (ii) reserve NCC, I-RNTI to be used in case a subsequent RRCResume Request is triggered due to data arrival for non-SDT DRB, and (iii) INACTIVE SRS configuration for configuring carrier switching for SDT.

The message may also be used as a response message to RRC Resume Request during Cell Reselection. If the RRC Resume request is reused for the cell reselection procedure, the RRC SDT resume message may serve as a response message to indicate that cell update procedure is successful and can carry a new NCC, I-RNTI for the UE in the target cell.

The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present invention may consist of any such individual feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

A user device (300) configured to transmit a message to a node (301) during an ongoing communication session, the message comprising a field comprising an indirect indication of the number of packets of the ongoing communication session remaining to be transmitted by the user device.
A user device as claimed in claim 1, wherein the session is a small data transmission session.
A user device as claimed in claim 1 or 2, wherein the node is a target node and the user device is configured to transmit the message to the target node when transitioning from a source node to the target node during an ongoing communication session.
A user device as claimed in any preceding claim, wherein the user device stores data mapping numbers of packets remaining to be transmitted to data tokens, the user device being configured to select one of the data tokens as content for the field.
A user device as claimed in claim 4, wherein the mapping data maps one of the data tokens to zero packets remaining to be transmitted.
A user device as claimed in any preceding claim, wherein the mapping data maps one of the data tokens to one packet remaining to be transmitted.
A user device as claimed in any preceding claim, wherein the mapping data maps one of the data tokens only to one packet remaining to be transmitted.
A user device as claimed in any of claims 4 to 7, wherein the mapping data maps one or more of the data tokens to respective ranges of numbers of packets remaining to be transmitted.
A user device as claimed in claim 8, wherein the ranges include one or more of: (i) less than two, (ii) less than five, (iii) two to five, (iv) six to ten, (v) less than ten, and (vi) an undefined non-zero number of packets.
A user device as claimed in any preceding claim, the user device being configured to transmit the message as an uplink radio resource control, RRC, message and the communication session is implemented via a small data transmission, SDT, procedure.
A user device as claimed in claim 10, wherein the user device is configured to generate the uplink RRC message as an RRC SDT Cell Update message transmitted as part of a small data transmission, SDT, random access channel, RACH, procedure.
A user device as claimed in any preceding claim, wherein the user device is configured to provide downlink packet data convergence protocol, PDCP, status report data of the communication session for transmission from the target node to the source node.
A user device as claimed in any preceding claim, wherein the user device is configured to continue in an RRC_INACTIVE State and maintain the PDCP sequence numbers for the ongoing communication session for data radio bearers and signal radio bearers.
A network device (301) configured to operate as a target node for a user device (300) which is transitioning from a source node to the target node during an ongoing communication session in a communications network, the target node configured to:

receive a message from the user device comprising a field comprising an indirect indication of the number of packets of the ongoing communication session remaining to be transmitted by the user device as part of the ongoing communication session; and

establish a data forwarding tunnel between the source node and the target node in a manner determined based on the indication of remaining packets.
A network device as claimed in claim 14, wherein the anchor node of the tunnel is determined in dependence on the indication.
A network device as claimed in claim 14 or 15, wherein whether the session is continued using dynamic grant or configured grant is determined in dependence on the indication.
A network device as claimed in any of claims 14 to 16, wherein the network device is configured to determine the manner in dependence on the indication.
A network device as claimed in any of claims 14 to 17, wherein the message, or another message received by the network from the user device, comprises a positioning measurement report and the network comprises a device configured to determine whether to relocate or to anchor the session in dependence on the positioning measurement report .
A network device as claimed in any of claims 14 to 18, the network device being configured to:

in response to the message from the user device transmit to the user device a downlink message comprising one or more of: (i) configured grant configuration data for the user device, (ii) a temporary radio network identifier for the user device, (iii) a Physical Uplink Control Channel (PUCCH) and/or sounding reference signal (SR) configuration. (iv) a nextHopChainingCount (NCC) (v) Radio Link Monitoring (RLM) and/or Beam Management (BM) configuration for inactive state
A user device (300) configured to transmit an uplink message to a node (301) during an ongoing communication session, the uplink message comprising a field comprising a direct or indirect indication of the number of packets of the ongoing communication session remaining to be transmitted by the user device, the user device being configured to be responsive to data received in a downlink response message to the uplink message to adopt a subsequent communication mode for the session.
A user device as claimed in claim 20, wherein the node is a target node and the user device is configured to transmit the message when transitioning from a source node ot the target node during the communication session.
A user device as claimed in claim 20 or 21, wherein the user device is responsive to the downlink response message containing one or more of: (i) configured grant configuration data for the user device, (ii) a temporary radio network identifier for the user device, (iii) a Physical Uplink Control Channel (PUCCH) and/or sounding reference signalconfiguration (iv) a nextHopChainingCount (NCC) (v) Radio Link Monitoring (RLM) and/or Beam Management (BM) configuration for inactive state, (vi) contention resolution information.
A user device as claimed in any of claims 20 to 22, wherein the device is configured to, on receiving the downlink message, stop a timer that was started in response to an RRCResumeRequest message or a functional analogue thereof.
A user device as claimed in claim 23, wherein the timer is a T319 timer.
A user device as claimed in any of claims 20 to 24, wherein the user device is configured to verify a connected network by means of the downlink message and to continue data transmission consequent on the message only if the network is verified.
A user device as claimed in any of claims 20 to 25, wherein the user device is configured to discontinue monitoring of a control channel in response to the downlink message.
A user device as claimed in claim 26, wherein the control channel is an L1 control channel PDCCH.
A user device as claimed in any of claims 20 to 27, wherein the downlink message comprises a field to which the user device is responsive to maintain a small data transmission session.
A user device as claimed in claim 28, wherein the user device is responsive to the downlink message not comprising the said field to terminate a small data transmission session.
A user device as claimed in claim 28 or 29, wherein the downlink message is a Downlink RRC Message.
A user device as claimed in any of claims 1 to 13 or 20 to 30, the user device being configured to, in response to there being a non-zero number of packets of the ongoing communication session remaining to be transmitted, send a power headroom report to a network node.