WO2023206260A1

WO2023206260A1 - Initiating mobile-terminated small data transmission with downlink semi-persistent scheduling

Info

Publication number: WO2023206260A1
Application number: PCT/CN2022/089973
Authority: WO
Inventors: Jagdeep Singh Ahluwalia; Haibo Xu; Mengchen ZHANG; Chunhua YOU
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-04-28
Filing date: 2022-04-28
Publication date: 2023-11-02
Anticipated expiration: 2024-10-28
Also published as: CN118592087A

Abstract

Disclosed is a network device (202) in a communications network (200), the network device (202) being configured to communicate with a user device (201) in the communications network (200) in a current mobile-terminated small data transmission communication session, the network device (202) being configured to: provide (901) a downlink semi-persistent scheduling configuration to the user device (201) for a subsequent mobile-terminated small data transmission communication session; activate (902) the downlink semi-persistent scheduling configuration for the user device (201); and send (903) downlink data for the subsequent mobile-terminated small data transmission communication session to the user device (201). A corresponding user device (201) is also disclosed. This may allow for a reduction in the scheduling overhead for subsequent downlink small data transmission, particularly for multi-shot procedures.

Description

INITIATING MOBILE-TERMINATED SMALL DATA TRANSMISSION WITH DOWNLINK SEMI-PERSISTENT SCHEDULING

FIELD OF THE INVENTION

This disclosure relates to data transmission in a communications network, in particular to a small data transmission (SDT) procedure in such a network.

BACKGROUND

A communications network generally comprises multiple nodes. Each node is a connection point in the communications network and can act as an endpoint for data transmission or redistribution. Each node may be, for example, a gNodeB (gNB) .

A network node may communicate with a user equipment device (UE) , such as a mobile phone, in the communications network. The network node may send downlink data to the UE and receive uplink data from the UE.

A solution for SDT was first defined for mobile originated (MO) signaling and data transfer and is planned to be enhanced for mobile terminated (MT) SDT, where the UE is able to receive small data while remaining in the RRC_INACTIVE state. In the RRC_INACTIVE state, a UE in a network, such as a Next Generation Radio Access Network (NG-RAN) , can move within an area configured by the NG-RAN (the RAN-based notification area, RNA) without notifying the NG-RAN.

When a UE is configured with SDT, downlink small data may be sent from the network node to the UE.

Many prior methods have been focused on supporting single-shot (i.e. one packet) transmission during SDT. However, to additionally support multi-shot SDT (i.e. multiple data packets) , there are a number of factors that need to be considered. The multi-shot procedure design is more complex and requires additional information exchange and scheduling of small data transmissions between the UE and the network to efficiently support the multi-shot SDT procedure.

It is desirable to develop an approach for SDT that can assist with such issues, particularly for multi-shot MT SDT.

SUMMARY OF THE INVENTION

According to one aspect, there is provided a network device in a communications network, the network device being configured to communicate with a user device in the communications network in a current mobile-terminated small data transmission communication session, the network device being configured to: provide a downlink semi-persistent scheduling configuration to the user device for a subsequent mobile-terminated small data transmission communication session; activate the downlink semi-persistent scheduling configuration for the user device; and send downlink data for the subsequent mobile-terminated small data transmission communication session to the user device.

According to another aspect, there is provided a user device in a communications network, the user device being configured to communicate with a network device in the communications network in a current mobile-terminated small data transmission communication session, the user device being configured to: receive a downlink semi-persistent scheduling configuration from the network device for a subsequent mobile-terminated small data transmission communication session; receive a notification of activation of the downlink semi-persistent scheduling configuration; and receive downlink data for the subsequent mobile-terminated small data transmission communication session from the network device.

This may allow for a reduction in the scheduling overhead for subsequent downlink data transmission from the network device to the user device, particularly for multi-shot procedures.

The downlink semi-persistent scheduling configuration may comprise an indication of resources (semi-persistent scheduling resources) assigned in a physical layer of a radio interface protocol stack and a periodicity of the resources. This may allow the user device to effectively operate under downlink semi-persistent scheduling for a mobile-terminated SDT communication session. The indication of the periodicity of the resources may indicate that the scheduling configuration applies to every nth subframe of a transmission. Hence, control signaling may only be used once, which may reduce the signaling overhead. Here, n is the periodicity of semi-persistently scheduled transmissions.

The network device may be configured for the current mobile-terminated small data transmission communication session according to a random access channel based small data transmission scheme. This may allow for compatibility with existing processes.

The network device may be configured for the current mobile-terminated small data transmission communication session according to a configured grant based small data transmission scheme. This may allow for compatibility with alternative existing processes.

The network device may be configured to provide the downlink semi-persistent scheduling configuration to the user device in a downlink radio resource control message in the current mobile-terminated small data transmission communication session to be used in the subsequent mobile-terminated small data transmission communication session. This may allow the user device to use downlink semi-persistent scheduling configured resources in the subsequent mobile-terminated SDT session.

The network device may be configured to provide the downlink semi-persistent scheduling configuration (which can be a full configuration or a delta configuration with respect to a previous configuration) to the user device in an RRCRelease message. This may provide compatibility with existing architectures and cater for future extensions.

The RRCRelease message may further comprise a configured scheduling radio network temporary identifier for the subsequent mobile-terminated small data transmission session. This may allow the network device to identify the user device.

The network device may be configured to provide the downlink semi-persistent scheduling configuration (which can be the full configuration or the delta configuration, with respect to the previous configuration) to the user device in a downlink radio resource control (RRC) message, such as RRCSDTReconfiguration (or other downlink RRC message) , in the current mobile-terminated small data transmission session. This message may allow the user device to be provided with the the downlink semi-persistent scheduling configuration when the user device is being reconfigured for SDT.

The network device may be a receiving node. The network device may be configured to provide a downlink semi-persistent scheduling configuration to the user device for the current mobile-terminated downlink small data transmission communication session using a downlink radio resource control message after user device context information is relocated to the receiving node from a last serving node. The receiving node may operate as a new serving node for the user device in the SDT session once context information from the user device has been transferred from the last serving node to the receiving node. This may assist in the initiation or transfer of an SDT session between nodes in a communications network.

The receiving node may be configured to receive the downlink semi-persistent scheduling configuration from the last serving node during relocation of the user device context information. The downlink semi-persistent scheduling configuration may be reused at the receiving node. This may be an efficient implementation during when a user device moves between nodes in the network.

The network device may be further configured to provide a configured grant configuration to the user device for subsequent mobile-terminated downlink small data transmission communication session (for example, for transmission of uplink data packets or signaling during the subsequent mobile-terminated small data communication session) . This may also allow the user device to be configured for a configured grant scheme.

A user device may be either in RRC_CONNECTED state/mode or in RRC_INACTIVE state/mode when an RRC connection has been established. If this is not the case, i.e. no RRC connection is established, the UE is in RRC_IDLE state/mode. In the RRC_INACTIVE state, a UE in a network, such as a Next Generation Radio Access Network (NG-RAN) , can move within an area configured by the NG-RAN (the RAN-based notification area, RNA) without notifying the NG-RAN. After being configured for downlink semi-persistent scheduling, the user device may be able to transmit or receive small data to or from the network device while remaining in RRC_INACTIVE mode.

The network device may be configured to activate the downlink semi-persistent scheduling configuration in dependence on a ResumeCause field in an RRCResume message and send downlink data for the current mobile-terminated small data transmission session to the user device in RRC_INACTIVE mode. This may allow the user device to receive small data while remaining in RRC_INACTIVE mode.

The network device may be configured to activate the downlink semi-persistent scheduling configuration for the user device via a physical downlink control channel. This may be a convenient implementation for activating the downlink semi-persistent scheduling configuration for the communication session.

The network device may be configured to activate the downlink semi-persistent scheduling configuration for the user device via a paging message sent to the user device. This may be a convenient implementation for activating the downlink semi-persistent scheduling configuration for the communication session.

The network device may be configured to activate the downlink semi-persistent scheduling configuration for the user device during a random access channel based small data transmission procedure in a message comprising a signal carrying a contention resolution acknowledgement. This may be a convenient implementation for activating the downlink semi-persistent scheduling configuration in a random access channel based SDT procedure.

The network device may be configured to activate the downlink semi-persistent scheduling configuration for the user device during a configured grant based small data transmission procedure in a message comprising a signal carrying an acknowledgement of an initial transmission on configured grant resources. This may be a convenient implementation for activating the downlink semi-persistent scheduling configuration in a configured grant based SDT session.

The network device may be configured to send a further RRCRelease message to the user device, the further RRCRelease message including a new downlink semi-persistent scheduling configuration for a further mobile-terminated small data transmission communication session (which may be a full configuration or a delta configuration for downlink semi-persistent scheduling, with respect to the previous configuration) or an indication to reuse the downlink semi-persistent scheduling configuration for the further mobile-terminated small data transmission communication session along with the configured scheduling radio network temporary identifier or a different configured scheduling radio network temporary identifier. This may allow further communication sessions to use downlink semi-persistent scheduling configured resources.

The network device may be configured to deactivate the downlink semi-persistent scheduling configuration upon receiving the further RRCRelease message. This may be a convenient implementation for deactivating the downlink semi-persistent scheduling configuration.

The downlink data may comprise multiple data packets. Use of the network device for multi-shot downlink data transmission may result in reduced scheduling overhead and downlink control signaling.

The downlink data may comprise positioning information. This may be useful for network-initiated positioning for receiving periodic positioning information/data. Downlink semi-persistent scheduling can also be useful for receiving acknowledgement of periodic positioning reports or data packets transmitted in the uplink using a configured grant SDT procedure.

The network device may be configured to send one or more of the downlink data and an acknowledgement of uplink data to the device periodically. This may allow the user device to receive data from the network device periodically and acknowledge the data.

The network device may be a base station. The network device may be a gNodeB. This may allow the network device to be used in a telecommunications network.

The gNodeB may comprise a centralised unit, one or more distributed units and an interface connecting the centralised unit with the one or more distributed units. The network device may be configured to include the downlink semi-persistent scheduling configuration for the user device for the subsequent mobile-terminated downlink small data transmission communication session in a UE MODIFICATION RESPONSE message or a UE CONTEXT RELEASE COMMAND message sent on the interface. Modification of existing procedures on this interface may allow for use of downlink semi-persistent scheduling for mobile-terminated SDT so that the scheduling overhead can be reduced for multi-packet downlink data transmission.

The downlink semi-persistent scheduling configuration may be a full configuration or a delta configuration with respect to a previous downlink semi-persistent scheduling configuration. The delta configuration may comprise fewer parameters than the full configuration. For example, the delta configuration may comprise only parameters that have changed relative to the previously used downlink semi-persistent scheduling configuration. Providing a delta configuration may be more efficient where only certain parameters have changed relative to the previous configuration.

According to a further aspect, there is provided a method for implementation at a network device in a communications network, the network device being configured to communicate with a user device in the communications network in a current mobile-terminated small data transmission communication session, the method comprising: providing a downlink semi-persistent scheduling configuration to the user device for a subsequent mobile-terminated small data transmission communication session; activating the downlink semi-persistent scheduling configuration for the user device; and sending downlink data for the subsequent mobile-terminated small data transmission communication session to the user device.

According to a further aspect, there is provided a method for implementation at a user device in a communications network, the user device being configured to communicate with a network device in the communications network in a current mobile-terminated small data transmission communication session, the method comprising: receiving a downlink semi-persistent scheduling configuration from the network device for a subsequent mobile-terminated small data transmission communication session; receiving a notification of activation of the downlink semi-persistent scheduling configuration from the network device; and receiving downlink data for the subsequent mobile-terminated small data transmission communication session from the network device.

This may allow for a reduction in the scheduling overhead for subsequent downlink data transmission, particularly for multi-shot procedures.

According to a further aspect, there is provided a computer-readable storage medium having stored thereon computer-readable instructions that, when executed at a computer system, cause the computer system to perform the method set out above. The computer system may comprise one or more processors. The computer-readable storage medium may be a non-transitory computer-readable storage medium.

BRIEF DESCRIPTION OF THE FIGURES

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

Figure 1 schematically illustrates some of the components in a Next Generation Radio Access Network (NG-RAN) .

Figure 2 shows an exemplary communication flow between the devices in a network where downlink semi-persistent scheduling is configured using an RRCRelease message in the previous session, with random access-based initiation.

Figure 3 shows an exemplary communication flow between the devices in a network where downlink semi-persistent scheduling is configured using an RRCRelease message in the previous session, with configured grant-based initiation.

Figure 4 shows an exemplary communication flow between the devices in a network where downlink semi-persistent scheduling for the subsequent SDT session is configured using an RRCSDTReconfiguration message in the current SDT session.

Figure 5 shows an exemplary communication flow between the devices in a network where downlink semi-persistent scheduling is configured using an RRCSDTReconfiguration message after UE Context relocation from a last serving node to a receiving node.

Figure 6 shows an exemplary communication flow between the devices in a network where downlink semi-persistent scheduling is configured for the subsequent SDT session together with configured grant.

Figure 7 shows an example of some alternative methods of activation of downlink semi-persistent scheduling.

Figure 8 shows some examples of modification of messages sent on the F1 interface connecting a Centralised Unit and a Distributed Unit of a gNodeB.

Figure 9 shows a flow chart of the steps of an example of a method for implementation at a network device in accordance with embodiments of the present invention.

Figure 10 shows a flow chart of the steps of an example of a method for implementation at a user device in accordance with embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Described herein are solutions for introducing downlink semi-persistent scheduling (DL SPS) for mobile-terminated small data transmission (MT SDT) procedures.

In MT SDT, the small data transmission ends (i.e. is terminated) at the UE device. In DL SPS, the UE is provided with a scheduling configuration, together with an indication that this applies to every n ^th subframe. Hence, control signaling can only be used once and the overhead is reduced. The periodicity of the SPS transmissions is equal to the value of n.

The exemplary solutions described below detail how the configuration, activation and deactivation of DL SPS may be performed for MT SDT sessions, along with Random-Access Channel (RACH) -based Small Data Transmission (RA-SDT) and Configured Grant-based Small Data Transmission (CG-SDT) procedures when the UE responds to paging for the MT-SDT, either in the same cell in which it had the previous SDT session/connection or in a different cell within the same or a different gNB after the UE Context is relocated.

The described solutions aim at addressing issues with the signaling involved while initiating MT SDT with DL SPS that involves activation through a physical downlink control channel or through other means. The implementations can also include the introduction of new procedures and/or the modification for existing procedures over the Uu, F1 and Xn interfaces, as defined below, to support multi-shot MT SDT with DL SPS.

As schematically illustrated in Figure 1, a Next Generation Radio Access Network (NG-RAN) 100 may comprise multiple nodes. In this example, the network 100 comprises gNodeBs (gNBs) 101, 102. Each

gNB

101, 102 may comprise multiple computing entities, such as a Centralised Unit (CU) 103 and multiple Distributed Units (DU) 104. The CU may communicate with a DU via an F1 interface 105, which is an interface that connects a gNB CU to a gNB DU.

The two

gNBs

101, 102 may be interconnected with each other by means of an Xn network interface 106, which is a network interface between the NG-

RAN nodes

101, 102 of the NG-RAN 100. Information may be transferred between the nodes on the Xn interface. Information may then be transferred on the control plane of the F1 interface (F1-C) , on the user plane of the F1 interface (F1-U) and on an E1 (transmission) interface between a control plane and user plane of the CU.

In this example, the Xn interface 106 is an Xn-Control plane interface (Xn-C) . The gNBs are also connected by means of Next Generation (NG) network interfaces 107 to the 5G Core Network (5GC) 108, more specifically to the Access and Mobility Management Function (AMF) by means of a control plane interface (NG-C) between the NG-RAN 100 and the 5GC 108 and to the User Plane Function (UPF) by means of a user plane interface (NG-U) between the NG-RAN 100 and the 5GC 108.

A Uu interface (not shown in Figure 1) connects a gNB with a UE.

Each node may comprise at least one processor and at least one memory. The memory stores in a non-transient way code that is executable by the processor (s) to implement the node in the manner described herein. The nodes may also comprise a transceiver for transmitting and receiving data. The communications network is preferably a wireless network.

SDT aims at creating a solution where a UE is able to transmit or receive small data to or from a network node while remaining in RRC_INACTIVE mode/state. As defined above, a user device may be either in RRC_CONNECTED state or in RRC_INACTIVE state when an RRC connection has been established. If this is not the case, i.e. no RRC connection is established, the UE is in RRC_IDLE state. In the RRC_INACTIVE state, a UE in a network, such as a NG-RAN, can move within an area configured by the NG-RAN (the RAN-based notification area, RNA) without notifying the NG-RAN.

The main advantage of the solutions described herein is to utilize DL SPS scheduling for an MT SDT session to reduce the scheduling overhead during MT SDT, particularly when multiple downlink packets with a known traffic pattern are to be delivered to the UE.

To achieve this, the network can provide the DL SPS configuration to the UE for DL SDT, which may include the resources assigned in the physical layer of the radio interface protocol stack and the periodicity of the allocated resources, through the RRC layer message. The DL SPS can then be activated for the UE at an appropriate instant when the DL data has arrived at the network node for the UE.

Multiple exemplary methods of providing the configuration and activating the DL SPS for the SDT procedure are described below.

Figure 2 shows an exemplary communication flow between the devices in a network 200 where DL SPS is configured using an RRCRelease message in the previous session, with random access (RA) -based initiation. The devices in the network include a UE 201,

gNBs

202 and 203, AMF 204 and UPF 205. The gNBs 202 may a base stations or other network device.

An RRCRelease message is a message used by the network to initiate the RRC connection release procedure to transit a UE in the RRC_CONNECTED state to RRC_IDLE, or to transit a UE in the RRC_CONNECTED state to the RRC_INACTIVE state.

At the start of the communication flow, as shown at 205, the UE 201 is in the RRC_CONNECTED state and data transfer is ongoing.

At 206, the gNB 202 decides to put the UE in the RRC_INACTIVE state and configure the UE with DL SPS for the next MT SDT session. At 207, the gNB 202 starts an RRC release procedure and sends an RRCRelease message to the UE 201.

The RRCRelease message includes the DL SPS configuration and a configured scheduling radio network temporary identifier (CS-RNTI) for the next MT SDT session.

At 208, the UE stores the DL SPS configuration and the CS-RNTI in the UE InActive Context. The UE Context may generally include information such as the Security Key, UE Radio Capability, UE Security Capabilities and configuration parameters for configuring the radio interface protocol layers. The UE InActive Context comprises elements of the UE Context used when the UE is in the RRC_INACTIVE state, including parameters for configuring the radio interface protocol stack layers.

When downlink MT SDT data for the UE arrives at the gNB 202, as shown at 209, the gNB pages the UE and includes an MT-SDT indication in the Paging Message 210.

For random-access channel (RACH) -based SDT, the UE in the RRC_INACTIVE mode can initiate a RACH procedure and request resumption of the connection using an RRCResumeRequest message, together with uplink SDT data/signaling. An RRCResume message is a message used by the network to resume the RRC connection to transit a UE in the RRC_INACTIVE state to RRC_CONNECTED. The RRCResumeRequest message is sent from the UE to the network node to request resumption of the connection.

As shown in Figure 2, a four-step RACH procedure then starts. The four steps are as below:

· MSG1: Random Access Preamble

· MSG2: Random Access Response (RAR)

· MSG3: Radio Resource Control (RRC) RRCResumeRequest

· MSG4: Contention Resolution

MSG1, shown at 211, is a preamble transmission of the RACH procedure. MSG2, shown at 212, is a RAR message.

MSG3, shown at 213, is the first scheduled transmission of the RACH procedure. The UE resumes SDT data radio bearer (DRB) /signaling radio bearer (SRB) and does not perform any uplink (UL) data volume threshold checking. The UE sends the RRCResumeRequest message with a new ResumeCause field set to MT SDT access without any UL data. The ResumeCause field indicates the reason why the connection is being resumed. In this case, it is set to a new cause value for MT SDT access.

MSG4, shown at 214, includes a contention resolution Medium Access Control (MAC) Control Element (CE) .

The gNB 202 can use the new ResumeCause field in MSG3 to distinguish that the DL data can be transferred using an MT SDT session in the RRC_INACTIVE state and there is no need to move the UE to the RRC_CONNECTED state.

At 215, the gNB 202 decides to activate the configured DL SPS resources for MT SDT for the next session.

At 216, the UE starts monitoring the physical downlink control channel (PDCCH) with a cell radio network temporary identifier (C-RNTI) for dynamic scheduling and the CS-RNTI for DL SPS.

If the DL SPS activation is carried out using the PDCCH, the UE receives the initial and the subsequent DL data transmission using DL SPS configured resources.

At 217, the gNB activates SPS through PDCCH (using the previously allocated CS-RNTI) . The initial downlink MT SDT data 209 is sent on SPS resources at 218.

Subsequent DL MT SDT data is sent to the gNB at 219 and sent to the UE on SPS resources at 220. Further DL data is sent at 221 and 222.

At 223, the gNB sends an RRCRelease message to the UE. The RRC message optionally includes a new DL SPS configuration (full or delta) or an indication to reuse the existing DL SPS configuration and optionally a new CS-RNTI for the next MT SDT session.

At 224, the UE implicitly de-activates the DL SPS on receiving the RRCRelease message 223. The UE may also store the new DL SPS configuration in the Access Stratum Context (AS Context) if provided.

Figure 3 shows an implementation where DL SPS is configured using an RRCRelease message in the previous session, with configured grant (CG) -based initiation.

The solution shown in Figure 3 is similar to solution shown in Figure 2, but in this implementation, the gNB configures the UE with a CG configuration. The UE has a valid CG configuration and responds to the paging by sending an RRCResumeRequest message on a valid CG resource with the new ResumeCause set to MT-SDT access.

At the start of the communication flow, as shown at 301, the UE 201 is in the RRC_CONNECTED state. Data transfer is ongoing.

At 302, the gNB 202 decides to put the UE in the RRC_INACTIVE state and configure the UE with DL SPS for the next MT SDT session. At 303, the gNB 202 starts an RRC release procedure and sends an RRCRelease message to the UE 201. The RRCRelease message includes a CG configuration for the next SDT session, the DL SPS configuration and a CS-RNTI for the next MT SDT session.

At 304, the UE stores the DL SPS configuration and the CS-RNTI in the UE InActive Context.

When downlink MT SDT data for the UE arrives at the gNB 202, as shown at 305, the gNB pages the UE and includes an MT-SDT indication in the Paging Message 306.

The UE 201, which has a valid CG configuration, responds to the paging by sending an RRCResumeRequest message on a valid CG resource with the new ResumeCause set to MT SDT access to the gNB 202 at 307.

At 308, the UE starts monitoring the PDCCH with a C-RNTI for dynamic scheduling and the CS-RNTI for DL SPS.

At 309, the gNB 202 decides to activate the configured DL SPS resources for MT SDT for the next session.

At 310, the gNB activates SPS through PDCCH (using the previously allocated CS-RNTI) . The initial downlink MT SDT data 305 is sent on SPS resources at 311.

Subsequent DL MT SDT data is sent to the gNB at 312 and sent to the UE on SPS resources at 313. Further DL data is sent at 314 and 315.

At 316, the gNB 202 sends an RRCRelease message to the UE 201. The RRC message optionally includes a new DL SPS configuration (afull configuration or a delta configuration with respect to the previously used configuration) or an indication to reuse the existing DL SPS configuration and optionally a new CS-RNTI for the next MT SDT session.

At 317, the UE implicitly de-activates the DL SPS on receiving the RRCRelease message 223. The UE may also store the new DL SPS configuration in the AS Context if provided.

Figure 4 shows an alternative implementation where DL SPS for the subsequent SDT session is configured using a downlink RRC message for reconfiguring SDT (referred to herein as an RRCSDTReconfiguration message) in the current SDT session. This can be any RRC downlink message other than an RRCRelease message.

When the DL MT SDT Data arrives at the gNB 202, as shown at 401, the gNB pages the UE 201 and includes an MT-SDT indication in the Paging Message, as shown at 402.

A 4-step RACH procedure then starts. MSG1, shown at 403, is a preamble transmission of the RACH procedure. MSG2, shown at 404, is a RAR message.

MSG3, shown at 405, is the first scheduled transmission of the RACH procedure. The UE resumes SDT DRB/SRB and does not perform any UL data volume threshold checking. The UE sends the RRCResumeRequest message with a new ResumeCause field set to MT SDT access without any UL data. The gNB 202 can use the new ResumeCause field to distinguish that the DL data can be transferred using an MT SDT session in the RRC_INACTIVE state and there is no need to move the UE to the RRC_CONNECTED state.

MSG4, shown at 406, includes a contention resolution MAC CE) .

At 407, the gNB 202 decides to use DL SPS for MT SDT.

At 408, the gNB 202 configures the UE with DL SPS configuration for the session using an RRCSDTReconfiguration Message

At 409, the UE starts monitoring the PDCCH with CS-RNTI.

At 410, the gNB 202 decides to activate the DL SPS resources for MT SDT.

At 411, the gNB 202 performs DL SPS activation through the PDCCH, and in this example also sends a newly allocated CS-RNTI.

At 412, the gNB sends the initial DL data transmission 401 using DL SPS configured resources.

Subsequent DL MT SDT data is sent to the gNB at 413 and sent to the UE on SPS resources at 414. Further DL data is sent at 415 and 416.

At 417, the gNB 202 sends an RRCRelease message to the UE 201. The RRC message optionally includes a new DL SPS configuration or an indication to reuse the existing DL SPS configuration and optionally a new CS-RNTI for the next MT SDT session.

At 418, the UE implicitly de-activates the DL SPS on receiving the RRCRelease message 223. The UE may also store the new DL SPS configuration in the AS Context if provided.

Therefore, in this example, the UE is provided with the DL SPS configuration through a downlink radio resource control message (e.g. a RRCSDTReconfiguration message) during the current session. When comparing the example shown in Figure 4 with the example in Figure 3, the implementation in Figure 4 does not have the limitation compared to providing the DL SPS configuration through RRCRelease, which is valid only in the same cell in which it is provided.

As a further example, Figure 5 illustrates configuring DL SPS using an RRCSDTReconfiguration message after UE context relocation from a last serving node to a receiving node (which becomes a new serving node once the UE context has been relocated from the last serving node to the receiving node) . The RRCSDTReconfiguration message is a term used herein for a message sent between the receiving gNB 206 and the UE 201 to reconfigure the UE for SDT when relocating the session.

In this example, the network comprises a last serving gNB 205 and a receiving gNB 206.

In this example, known UE Context retrieval procedures can be used to transfer the UE Context from the last serving gNB 205 to the receiving gNB 206. The UE Context may generally include information such as the Security Key, UE Radio Capability, UE Security Capabilities and configuration parameters for configuring the radio interface protocol layers.

However, the DL SPS configuration is not transferred from the last serving gNB 205 to the receiving gNB 206. The receiving gNB 206 configures the UE 201 with a new DL SPS configuration using an RRCSDTReconfiguration message after the UE Context is relocated from the last serving gNB 205 to the receiving gNB 206.

Another possibility is that the DL SPS configuration can be transferred from the last serving node 205 to the receiving node 206 during the relocation of UE context and can be reused at the receiving node. In this case, an RRCSDTReconfiguration message sent during the current SDT session or an RRCRelease message for the next SDT session may include either the full DL SPS configuration or the delta configuration with respect to the DL SPS configuration received from the last serving node.

When the DL MT SDT data arrives at the gNB 202 from the UPF 204, as shown at 501, the last serving gNB 205 pages the receiving gNB 206 and includes an MT-SDT indication or MT SDT data size in the Paging Message, as shown at 502. The receiving gNB 206 the pages the UE 201 and includes an MT SDT indication, as shown at 503.

A 4-step RACH procedure then starts. MSG1, shown at 504, is a preamble transmission of the RACH procedure. MSG2, shown at 505, is a RAR message.

MSG3, shown at 506, is the first scheduled transmission of the RACH procedure. The UE resumes SDT DRB/SRB and does not perform any UL data volume threshold checking. The UE sends the RRCResumeRequest message with a new ResumeCause field (which indicates to the network the reason why the connection is being resumed) set to MT SDT access without any UL data. The receiving gNB 206 can use the new ResumeCause field to distinguish that the DL data can be transferred using an MT SDT session in the RRC_INACTIVE state and there is no need to move the UE to the RRC_CONNECTED state.

The receiving gNB 206 then sends a Retrieve UE Context Request to the last serving gNB 205, as shown at 507, along with the ResumeCause set to MT SDT Access.

MSG4, shown at 508, includes a contention resolution MAC CE.

At 509, the last serving gNB 205 sends a Retrieve UE Context Response message to the receiving gNB 206 containing the UE Context.

At 510, the receiving gNB 206 decides to use DL SPS for MT SDT.

At 511, the receiving gNB 206 configures the UE 201 with a DL SPS configuration for the session using an RRCSDTReconfiguration Message.

At 512, the receiving gNB 206 sends an Xn-U address indication to the last serving gNB 205. For the procedure involving the retrieval of the UE Context, the Xn-U address indication procedure is used to provide forwarding addresses from the last serving node to the receiving node for all session resources successfully established at the receiving node for which forwarding was requested.

At 513, DL data is forwarded from the last serving gNB 205 to the receiving gNB 206. At 514, the gNB 206 decides to activate the DL SPS resources for MT SDT and performs DL SPS activation through the PDCCH, and in this example also sends a newly allocated CS-RNTI.

At 515, the gNB 206 sends the initial DL data transmission 501 using DL SPS configured resources.

At 516, the gNB 206 sends a Next Generation Application Protocol (NGAP) path switch request to the UPF 204 and the patch switch with the UPF is performed at 517. The UPF sends a NGAP path switch response to the gNB 206 at 518.

Subsequent DL MT SDT data is sent from the UPF 204 to the receiving gNB 206 at 519 and sent to the UE on SPS resources at 520. Further DL data is sent at 521 and 522.

At 523, the gNB 206 sends an RRCRelease message to the UE 201. The RRC message optionally includes a new DL SPS configuration or an indication to reuse the existing DL SPS configuration and optionally a new CS-RNTI for the next MT SDT session.

At 524, the receiving gNB 206 send an Xn Application Protocol (XnAP) UE Context Release message on the Xn interface between the

gNBs

205 and 206. The last serving gNB 205 then releases the UE Context.

At 525, the UE implicitly de-activates the DL SPS on receiving the RRCRelease message 523. The UE may also store the new DL SPS configuration in the AS Context if provided.

Figure 6 illustrates a further example where DL SPS is configured for the subsequent SDT session together with CG. DL SPS can be useful for receiving acknowledgement of periodic positioning reports or data packets transmitted in the UL using a CG SDT procedure (i.e. DL SPS can be activated along with CG SDT) .

At the start of the communication flow, as shown at 601, the UE 201 is in the RRC_CONNECTED state. Data transfer is ongoing.

At 602, the gNB 202 decides to put the UE in the RRC_INACTIVE state and configure the UE with DL SPS for the next MT SDT session. At 603, the gNB 202 starts an RRC release procedure and sends an RRCRelease message to the UE 201. The RRCRelease message includes a CG configuration for the next SDT session, the DL SPS configuration and a CS-RNTI for the next MT SDT session.

At 604, the UE stores the DL SPS configuration and the CS-RNTI in the UE InActive Context.

At 605, the UE 201, sends an RRC Resume Request and UL data to the gNB 202 as an initial CG transmission.

At 606, the UE starts monitoring the PDCCH with a C-RNTI for dynamic scheduling and the CS-RNTI for DL SPS.

At 607, the gNB 202 decides to activate the configured DL SPS resources for MT SDT for the next session.

At 608, the gNB activates SPS through PDCCH (using the previously allocated CS-RNTI) .

At 609, subsequent DL MT SDT data is sent to the gNB and on to the UE, along with an acknowledgement for the UL data sent at 605, on DL SPS resources.

At 610, the gNB 202 sends an RRCRelease message to the UE 201. The RRC message optionally includes a new DL SPS configuration or an indication to reuse the existing DL SPS configuration and optionally a new CS-RNTI for the next MT SDT session.

At 611, the UE implicitly de-activates the DL SPS on receiving the RRCRelease message 223. The UE may also store the new DL SPS configuration in the AS Context if provided.

As described in the above examples, DL SPS can be activated via the PDCCH.

Figure 7 shows some examples of additional methods of activation of DL SPS.

When the DL SPS configuration for MT SDT is provided in a first RRCRelease message of the previous session, for example as show in Figure 2 at 207, there are multiple exemplary methods of activating the DL SPS.

For example, the DL SPS can be activated using the paging message itself, i.e. when the UE is paged, for example at 210 in Figure 2. Further examples are shown in Figures 7 (a) and 7 (b) , at 701.

Alternatively, DL SPS can be activated using MSG4/MSGB for RA-based SDT. An example of this is shown in Figure 7 (a) , at 702.

In a further example, the DL SPS can be activated in the confirmation message for an initial CG-SDT transmission. This message may be a common control channel (CCCH) message. An example is shown in Figure 7 (b) , at 703.

In all of the above examples, the UE may be configured to store the DL SPS configuration for the subsequent MT SDT communication session in the active UE Context for the UE.

As well as using the procedures described above on the Uu interface, which links a gNB with a UE, existing procedures on the F1 interface may also be modified for using DL-SPS for MT-SDT, so that the scheduling overhead can be reduced for multi-shot /multi-packet DL data transmission.

Implementations using an RRCRelease message for configuring DL SPS may use the modifications shown in Figure 8. In this example, the UE 801 communicate with the gNB-DU 802 over a Uu interface using an RRCRelease procedure to provide the DL SPS configuration to the UE for the subsequent session. The gNB-DU 802 communicates with the gNB-CU-CP 803 over an F1-C interface.

As show in Figure 8, the following F1-C interface messages can be sent between the

components

801, 802, 803 according to an F1 Application Protocol (F1AP) :

1. F1AP: UE CONTEXT MODIFICATION REQUEST –this is a message sent from the gNB-CU-CP 803 to the gNB-DU 802 to request modification of the UE context stored at the gNB. A DL SPS-SDT Query can be included in this message.

2. F1AP: UE CONTEXT MODIFICATION RESPONSE –this is a response to the above message sent from the gNB-DU 802 to the gNB-CU-CP 803. The DL SPS configuration can be included in this message.

3. F1AP: UE CONTEXT MODIFICATION REQUEST or UE CONTEXT RELEASE COMMAND –a further UE CONTEXT MODIFICATION REQUEST message can be sent from the gNB-CU-CP 803 to the gNB-DU 802. Alternatively, a UE CONTEXT RELEASE COMMAND message can be sent, which is a message sent from the gNB-CU-CP 803 to the gNB-DU 802 to command release of the UE Context. In these messages, an SDT Indication to keep the DL SPS configuration may be included.

4. RRCRelease –this message is sent between the gNB-DU 802 and the UE 803 on the Uu interface to provide and activate the DL SPS configuration for the UE, as described in the previous embodiments.

After this, the UE is in the RRC_INACTIVE state, as indicated at 5.

6. F1AP: UE CONTEXT MODIFICATION RESPONSE or UE CONTEXT RELEASE COMPLETE -a further UE CONTEXT MODIFICATION RESPONSE message can be sent from the gNB-DU 802 to the gNB-CU-CP 803. Alternatively, a UE CONTEXT RELEASE COMMAND message can be sent, which is a message sent from the gNB-DU 802 to the gNB-CU-CP 803 to indicate that the UE Context release has been completed.

The downlink semi-persistent scheduling configuration for the user device for the subsequent MT SDT communication session may therefore be included in the messages above sent on an F1 interface to support multi-shot MT-SDT with DL SPS

The downlink data may comprise periodic packets for network-initiated positioning for receiving periodic positioning information/data. The gNB may be configured to receive an acknowledgement of the periodic positioning reports or data packets transmitted in the UL using CG SDT procedure.

The downlink data may have a known traffic pattern. The gNB may be configured to receive acknowledgement of the downlink data.

Figure 9 shows a flowchart summarising an example of a method for implementation at a network device in accordance with embodiments of the present invention. The network device is configured to communicate with a user device in the communications network in a current mobile-terminated small data transmission communication session. At step 901, the method comprises providing a downlink semi-persistent scheduling configuration to the user device for a subsequent mobile-terminated small data transmission communication session. At step 902, the method comprises activating the downlink semi-persistent scheduling configuration for the user device. At step 903, the method comprises sending downlink data for the subsequent mobile-terminated small data transmission communication session to the user device.

Figure 10 shows a flowchart summarising an example of a method for implementation at a user device in accordance with embodiments of the present invention. The user device is configured to communicate with a network device in the communications network in a current mobile-terminated small data transmission communication session. At step 1001, the method comprises receiving a downlink semi-persistent scheduling configuration from the network device for a subsequent mobile-terminated small data transmission communication session. At step, 1002, the method comprises receiving a notification of activation of the downlink semi-persistent scheduling configuration from the network device. At step 1003, the method comprises receiving downlink data for the subsequent mobile-terminated small data transmission communication session from the network device.

A main motivation to introduce DL SPS for MT-SDT is that the scheduling overhead can be reduced for subsequent multi-shot DL data transmission.

DL control signaling can be reduced if the DL SPS is performed when multiple packets need to be transmitted from the network to the UE in the case of MT SDT.

DL SPS may be useful where periodic packets may be needed to be transmitted to the UE for example for network initiated positioning for receiving periodic positioning information/data. DL SPS can also be used for receiving acknowledgement of the periodic positioning reports or data packets transmitted in the UL using CG SDT procedure i.e. DL SPS can be activated along with CG SDT.

The present approach can address issues involved with the signaling while initiating MT SDT with DL SPS that involves activation through PDCCH or through other means, such as paging or during the RACH procedure with MSG4/MSGB, or alternatively along with the signaling carrying acknowledgement of an initial transmission on CG resources.

The user device may be configured to operate in RRC_INACTIVE mode throughout the above process.

Embodiments of the present invention may therefore be used in MT SDT sessions along with RACH-based SDT (RA-SDT) and CG-based SDT (CG-SDT) procedures when the UE responds to paging for the MT SDT, either in the same cell with which it had the previous SDT session/connection or in a different cell within the same or a different gNB after the UE Context is relocated.

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 network device (202) in a communications network (200) , the network device (202) being configured to communicate with a user device (201) in the communications network (200) in a current mobile-terminated small data transmission communication session, the network device being configured to:

provide (901) a downlink semi-persistent scheduling configuration to the user device (201) for a subsequent mobile-terminated small data transmission communication session;

activate (902) the downlink semi-persistent scheduling configuration for the user device (201) ; and

send (903) downlink data for the subsequent mobile-terminated small data transmission communication session to the user device (201) .
The network device (202) as claimed in claim 1, wherein the downlink semi-persistent scheduling configuration comprises an indication of resources assigned in a physical layer of a radio interface protocol stack and a periodicity of the resources.
The network device (202) as claimed in claim 1 or claim 2, wherein the network device (202) is configured for the current mobile-terminated small data transmission communication session according to a random access channel based small data transmission scheme.
The network device (202) as claimed in claim 1 or claim 2, wherein the network device (202) is configured for the current mobile-terminated small data transmission communication session according to a configured grant based small data transmission scheme.
The network device (202) as claimed in any preceding claim, wherein the network device (202) is configured to provide the downlink semi-persistent scheduling configuration to the user device in a downlink radio resource control message in the current mobile-terminated small data transmission communication session to be used in the subsequent mobile-terminated small data transmission communication session.
The network device (202) as claimed in claim 5, wherein the network device (202) is configured to provide the downlink semi-persistent scheduling configuration to the user device in an RRCRelease message.
The network device (202) as claimed in claim 6, wherein the RRCRelease message further comprises a configured scheduling radio network temporary identifier for the subsequent mobile-terminated small data transmission session.
The network device (202) as claimed in any of claims 1 to 5, wherein the network device (202) is configured to provide the downlink semi-persistent scheduling configuration to the user device (201) in an RRCSDTReconfiguration message in the current mobile-terminated small data transmission session.
The network device as claimed in any preceding claim, wherein the network device is a receiving node and wherein the network device is configured to provide a downlink semi-persistent scheduling configuration to the user device (201) for the current mobile-terminated downlink small data transmission communication session using a downlink radio resource control message after user device context information is relocated to the receiving node from a last serving node.
The network device as claimed in claim 9, wherein the receiving node is configured to receive the downlink semi-persistent scheduling configuration from the last serving node during relocation of the user device context information and wherein the downlink semi-persistent scheduling configuration is reused at the receiving node.
The network device (202) as claimed in any preceding claim, wherein the network device (202) is further configured to provide a configured grant configuration to the user device (201) for the subsequent mobile-terminated downlink small data transmission communication session.
The network device (202) as claimed in any preceding claim, wherein the network device (202) is configured to activate the downlink semi-persistent scheduling configuration in dependence on a ResumeCause field in an RRCResume message and send downlink data for the current mobile-terminated small data transmission session to the user device in RRC_INACTIVE mode.
The network device (202) as claimed in any preceding claim, wherein the network device (202) is configured to activate the downlink semi-persistent scheduling configuration for the user device (201) via a physical downlink control channel.
The network device (202) as claimed in any of claims 1 to 12, wherein the network device (202) is configured to activate the downlink semi-persistent scheduling configuration for the user device (201) via a paging message sent to the user device.
The network device (202) as claimed in any of claims 1 to 12, wherein the network device (202) is configured to activate the downlink semi-persistent scheduling configuration for the user device (201) during a random access channel based small data transmission procedure in a message comprising a signal carrying a contention resolution acknowledgement.
The network device (202) as claimed in any of claims 1 to 12, wherein the network device (202) is configured to activate the downlink semi-persistent scheduling configuration for the user device (201) during a configured grant based small data transmission procedure in a message comprising a signal carrying an acknowledgement of an initial transmission on configured grant resources.
The network device (202) as claimed in claim 7, wherein the network device (202) is configured to send a further RRCRelease message to the user device, the further RRCRelease message including a new downlink semi-persistent scheduling configuration for a further mobile-terminated small data transmission communication session or an indication to reuse the downlink semi-persistent scheduling configuration for the further mobile-terminated small data transmission communication session along with the configured scheduling radio network temporary identifier or a different configured scheduling radio network temporary identifier.
The network device (202) as claimed in claim 17, wherein the network device (202) is configured to deactivate the downlink semi-persistent scheduling configuration upon receiving the further RRCRelease message.
The network device (202) as claimed in any preceding claim, wherein the downlink data comprises multiple data packets.
The network device (202) as claimed in any preceding claim, wherein the downlink data comprises positioning information.
The network device (202) as claimed in any preceding claim, wherein the network device (202) is configured to send one or more of the downlink data and an acknowledgement of uplink data to the device periodically.
The network device (202) as claimed in any preceding claim, wherein the network device is a gNodeB (102) .
The network device (202) as claimed in claim 22, wherein the gNodeB (102) comprises a centralised unit, one or more distributed units and an interface connecting the centralised unit with the one or more distributed units, the network device being configured to include the downlink semi-persistent scheduling configuration for the user device for the subsequent mobile-terminated downlink small data transmission communication session in a UE MODIFICATION RESPONSE message or a UE CONTEXT RELEASE COMMAND message sent on the interface.
The network device (202) as claimed in any preceding claim, wherein the downlink semi-persistent scheduling configuration is a full configuration or a delta configuration with respect to a previous downlink semi-persistent scheduling configuration.
A method (900) for implementation at a network device (202) in a communications network (200) , the network device (202) being configured to communicate with a user device (201) in the communications network (200) in a current mobile-terminated small data transmission communication session, the method comprising:

providing (901) a downlink semi-persistent scheduling configuration to the user device (201) for a subsequent mobile-terminated small data transmission communication session;

activating (902) the downlink semi-persistent scheduling configuration for the user device (201) ; and

sending (903) downlink data for the subsequent mobile-terminated small data transmission communication session to the user device (201) .
A user device (201) in a communications network (200) , the user device (201) being configured to communicate with a network device (202) in the communications network (200) in a current mobile-terminated small data transmission communication session, the user device (201) being configured to:

receive (1001) a downlink semi-persistent scheduling configuration from the network device (202) for a subsequent mobile-terminated small data transmission communication session;

receive (1002) a notification of activation of the downlink semi-persistent scheduling configuration; and

receive (1003) downlink data for the subsequent mobile-terminated small data transmission communication session from the network device (202) .
A method (1000) for implementation at a user device (201) in a communications network (200) , the user device (201) being configured to communicate with a network device (202) in the communications network (200) in a current mobile-terminated small data transmission communication session, the method comprising:

receiving (1001) a downlink semi-persistent scheduling configuration from the network device (202) for a subsequent mobile-terminated small data transmission communication session;

receiving (1002) a notification of activation of the downlink semi-persistent scheduling configuration from the network device (202) ; and

receiving (1003) data for the subsequent mobile-terminated small data transmission communication session from the network device (202) .
A computer-readable storage medium having stored thereon computer-readable instructions that, when executed at a computer system, cause the computer system to perform the method of claim 25 or claim 27.