Patent Description:
Wireless communication technologies are moving the world toward an increasingly connected and networked society. Wireless communications rely on efficient network resource management and allocation between user mobile stations and wireless access network nodes (including but not limited to wireless base stations). User mobile stations or user equipment (UE) are becoming more complex and the amount of data communicated continually increases. In order to improve communications and power usage, communication improvements should be made.

This document relates to methods for small data transmissions which can occur with user equipment even when the user equipment is in an inactive state. Small data transmissions while in an inactive state can save power and reduce signaling overhead. The small data transmissions may be prepared with small data transmission parameters. A small data transmission indication is included in a reply to user equipment that requests small data transmission communication. <NPL>), <NPL>), <NPL>), and <NPL>) are related prior art.

Any embodiment, example, aspect or implementation not claimed, is only presented as information.

The present disclosure will now be described in detail hereinafter with reference to the accompanied drawings, which form a part of the present disclosure, and which show, by way of illustration, specific examples of embodiments.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase "in one embodiment" or "in some embodiments" as used herein does not necessarily refer to the same embodiment and the phrase "in another embodiment" or "in other embodiments" as used herein does not necessarily refer to a different embodiment. The phrase "in one implementation" or "in some implementations" as used herein does not necessarily refer to the same implementation and the phrase "in another implementation" or "in other implementations" as used herein does not necessarily refer to a different implementation. It is intended, for example, that claimed subject matter includes combinations of exemplary embodiments or implementations in whole or in part.

For example, terms, such as "and", "or", or "and/or," as used herein may include a variety of meanings that may depend at least in part upon the context in which such terms are used. Typically, "or" if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term "one or more" or "at least one" as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as "a", "an", or "the", again, may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term "based on" or "determined by" may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

In various telecommunications systems, such as a mobile telecommunications context, user equipment (UE) may communicate with a small data transmission (SDT). Traditionally, the transmission of user data is not allowed when in an inactive state. Even for the transmission of a very small amount of data the device has to resume the connection, which may have a negative impact on signaling overhead as well as device energy consumption. As described below, the transmission of small data payloads (i.e. SDT) may be made in an inactive state. For new radio (NR) specifications the UE may have three states: idle, inactive and connected. The UE cannot transmit data in idle and inactive, so when UE wants to transmit data in idle or inactive, the UE first transfers to connected. However, as described herein, for small data transmission (SDT), the UE can transmit small data in an inactive state, rather than transferring to connected first. The version of idle/inactive in which no data can be transferred may be referred to as the legacy state as compared with the states presented here that allow for small data transmission in inactive or idle states.

Any device that has intermittent small data packets in an inactive state can benefit from enabling small data transmission (SDT) while in an inactive state. SDT traffic may have different service requirements as compared to conventional or larger data transmission traffic types. SDT communication or data transfer may be made from/with the UE while in an inactive state. The UE may send an SDT request message to a basestation, which may be a nodeB (NB, e.g., an eNB or gNB) in a mobile telecommunications context. The basestation may respond to the UE request message with a reply that includes an SDT indication. The SDT indication signals that communication may be made from the UE even in an inactive state. Small data transmissions while in an inactive state can save power and reduce signaling overhead.

The SDT communications described herein can coexist with legacy mixed traffic on the same carrier, while improving usage of network resources (power, codes, interference, etc.) for the SDT communications. Examples of small and infrequent data traffic that would qualify for SDT include smartphone applications, such as <NUM>) traffic from Instant Messaging services (e.g. WHATSAPP, QQ, WECHAT, etc.); <NUM>) heart-beat/keep-alive traffic from IM/email clients and other apps; and <NUM>) push notifications from various applications. In addition, other SDT may include traffic from wearables (periodic positioning information etc.), sensors (e.g. Industrial Wireless Sensor Networks transmitting temperature, pressure readings periodically or in an event triggered manner), and smart meters or smart meter networks sending periodic meter readings. In one embodiment, small data in SDT may include data with an application packets size of <NUM> bytes (upload UL or download DL) or lower. Although the examples and embodiments described herein refer to small data or small data transmission, the scope of small data may vary and may include data other than small data, such as normal data or large data. Specifically, the size of small data can vary and the embodiments/examples will apply to any data.

Radio resource control (RRC) is a protocol layer between UE and the basestation at the IP level (Network Layer). RRC messages are transported via the Packet Data Convergence Protocol (PDCP). As described, UE can transmit infrequent (periodic and/or non-periodic) data in RRC_INACTIVE state without moving to an RRC_CONECTED state. This can save the UE power consumption and signaling overhead. This can be through a Random Access Channel (RACH) protocol scheme or Configured Grant (CG) scheme. RACH is a shared channel used by wireless terminals to access the mobile network (TDMA/FDMA, and CDMA based network) for call set-up and data transmission. Whenever a UE wants to make a MO (Mobile Originating) call it schedules the RACH. RACH is a transport-layer channel, while the corresponding physical-layer channel is PRACH.

<FIG> shows an example basestation <NUM>. The basestation may also be referred to as a wireless network node. The basestation <NUM> may be further identified to as a nodeB (NB, e.g., an eNB or gNB) in a mobile telecommunications context. The example basestation may include radio Tx/Rx circuitry <NUM> to receive and transmit with user equipment (UEs) <NUM>. The basestation may also include network interface circuitry <NUM> to couple the basestation to the core network <NUM>, e.g., optical or wireline interconnects, Ethernet, and/or other data transmission mediums/protocols.

The basestation may also include system circuitry <NUM>. System circuitry <NUM> may include processor(s) <NUM> and/or memory <NUM>. Memory <NUM> may include operations <NUM> and control parameters <NUM>. Operations <NUM> may include instructions for execution on one or more of the processors <NUM> to support the functioning the basestation. For example, the operations may handle random access transmission requests from multiple UEs. The control parameters <NUM> may include parameters or support execution of the operations <NUM>. For example, control parameters may include network protocol settings, random access messaging format rules, bandwidth parameters, radio frequency mapping assignments, and/or other parameters.

<FIG> shows an example random access messaging environment <NUM>. In the random access messaging environment a UE <NUM> may communicate with a basestation <NUM> over a random access channel <NUM>. In this example, the UE <NUM> supports one or more Subscriber Identity Modules (SIMs), such as the SIM1 <NUM>. Electrical and physical interface <NUM> connects SIM1 <NUM> to the rest of the user equipment hardware, for example, through the system bus <NUM>.

The mobile device <NUM> includes communication interfaces <NUM>, system logic <NUM>, and a user interface <NUM>. The system logic <NUM> may include any combination of hardware, software, firmware, or other logic. The system logic <NUM> may be implemented, for example, with one or more systems on a chip (SoC), application specific integrated circuits (ASIC), discrete analog and digital circuits, and other circuitry. The system logic <NUM> is part of the implementation of any desired functionality in the UE <NUM>. In that regard, the system logic <NUM> may include logic that facilitates, as examples, decoding and playing music and video, e.g., MP3, MP4, MPEG, AVI, FLAC, AC3, or WAV decoding and playback; running applications; accepting user inputs; saving and retrieving application data; establishing, maintaining, and terminating cellular phone calls or data connections for, as one example, Internet connectivity; establishing, maintaining, and terminating wireless network connections, Bluetooth connections, or other connections; and displaying relevant information on the user interface <NUM>. The user interface <NUM> and the inputs <NUM> may include a graphical user interface, touch sensitive display, haptic feedback or other haptic output, voice or facial recognition inputs, buttons, switches, speakers and other user interface elements. Additional examples of the inputs <NUM> include microphones, video and still image cameras, temperature sensors, vibration sensors, rotation and orientation sensors, headset and microphone input / output jacks, Universal Serial Bus (USB) connectors, memory card slots, radiation sensors (e.g., IR sensors), and other types of inputs.

The system logic <NUM> may include one or more processors <NUM> and memories <NUM>. The memory <NUM> stores, for example, control instructions <NUM> that the processor <NUM> executes to carry out desired functionality for the UE <NUM>. The control parameters <NUM> provide and specify configuration and operating options for the control instructions <NUM>. The memory <NUM> may also store any BT, WiFi, <NUM>, <NUM>, <NUM> or other data <NUM> that the UE <NUM> will send, or has received, through the communication interfaces <NUM>. In various implementations, the system power may be supplied by a power storage device, such as a battery <NUM>.

In the communication interfaces <NUM>, Radio Frequency (RF) transmit (Tx) and receive (Rx) circuitry <NUM> handles transmission and reception of signals through one or more antennas <NUM>. The communication interface <NUM> may include one or more transceivers. The transceivers may be wireless transceivers that include modulation / demodulation circuitry, digital to analog converters (DACs), shaping tables, analog to digital converters (ADCs), filters, waveform shapers, filters, pre-amplifiers, power amplifiers and/or other logic for transmitting and receiving through one or more antennas, or (for some devices) through a physical (e.g., wireline) medium.

The transmitted and received signals may adhere to any of a diverse array of formats, protocols, modulations (e.g., QPSK, <NUM>-QAM, <NUM>-QAM, or <NUM>-QAM), frequency channels, bit rates, and encodings. As one specific example, the communication interfaces <NUM> may include transceivers that support transmission and reception under the <NUM>, <NUM>, BT, WiFi, Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA)+, and <NUM> / Long Term Evolution (LTE) standards. The techniques described below, however, are applicable to other wireless communications technologies whether arising from the 3rd Generation Partnership Project (3GPP), GSM Association, 3GPP2, IEEE, or other partnerships or standards bodies.

<FIG> shows example multiple step random access protocols <NUM>, <NUM>. In various implementations, a UE and basestation (gNB) may engage in a multiple step protocol to: (i) UE send a preamble (e.g., in Msg1) to the base station (<NUM>), (ii) after reception of preamble, BS sends back a random access response (RAR)s (e.g., Msg2) to UE (<NUM>), (iii) UE sends back a third message (e.g., Msg3) on the upload UL grant indicated in the RAR containing the preamble transmitted in Msg1 (<NUM>), and (iv) after successfully decoding Msg3, a fourth message (e.g., Msg4) is transmitted from the basestation to the UE for performing contention resolution (<NUM>). This example four-step random access channel protocol <NUM> may allow for establishment of RRC connections and be referred to as <NUM>-step RACH.

In some implementations, the latency created through the <NUM>-step RACH protocol <NUM> may be decreased by using a two-step random access protocol <NUM> (e.g., <NUM>-step RACH). The <NUM>-step RACH <NUM> may combine (i) and (iii) and combine (ii) and (iv) to condense the RACH protocol into two steps. The first step is to send a first message, e.g. Msg1. In some examples the first message contains a preamble transmitted in physical random access channel and/or payload transmitted in physical uplink shared channel, which contains at least the same amount of information that is carried in Msg3 of <NUM>-step RACH. A second message, e.g. Msg2 in respond to Msg1 is transmitted from BS to UE. Thus, the combination of the two UE messages allows for the combination of the two basestation messages. The example <NUM>-step RACH may allow for reduced latency compared to the <NUM>-step RACH, which may reduce channel occupancy times increase data available for payload transmission or have other technical benefits. Accordingly, implementing a <NUM>-step RACH is a technical solution to a technical problem of increasing data network performance thereby improving the operation of the underlying hardware.

In various systems to implement a RACH protocol, and in some cases specifically a <NUM>-step RACH, the architecture (e.g., the header/body structure of the messages and the fields therein) of the random access messages. Although in the examples discussed in this disclosure the architectures and techniques are used in the context of a reply message (e.g., Msg2) of a <NUM>-step RACH, the architectures and techniques discussed herein may be applied to other random access messages where message architecture and content may be used to distinguish among message types. RACH is one example protocol for the communications discussed below for SDT during an inactive state. In other embodiments a Configured Grant (CG) scheme may be used for the SDT communications during the inactive state.

<FIG> shows one embodiment of a small data transmission (SDT) procedure. <FIG> illustrates communications between the user equipment (UE) and a basestation (gNB). For SDT preparation, SDT parameters are configured <NUM> for the SDT preparation phase. Specifically, the network configures SDT parameters via RRC signaling as further described with respect to <FIG>. SDT type selection <NUM> is part of the SDT initiation phase in which the UE initiates the SDT procedure after first selecting the SDT type as further described below with respect to <FIG>. In block <NUM> a request for small data transmission (SDT) is made from the UE to the basestation gNB. In response, the basestation gNB provides a reply that includes an SDT indication. In this embodiment, a timer is started when the request is made and the timer is stopped when the reply with the SDT indication is received. In block <NUM>, the SDT process is entered and an SDT timer is started. The SDT process includes the UE transmitting UL data using CG PUSCH resource or dynamic UL grant, and can receive DL data using dynamic DL assignment. Data transmission is scheduled to the UE <NUM> and is schedule from the UE <NUM>. For each of the data transmission scheduling, the SDT timer is restarted. Specifically, the SDT timer is restarted when receiving downlink data or sending uplink data. In block <NUM>, the UE can then enter the legacy inactive state (also referred to as normal inactive state) when the SDT timer expires. The legacy inactive state is the traditional inactive state when no data is transferred, however, as described herein, the modified inactive state can now allow for SDT even in the inactive state.

<FIG> shows another embodiment of a SDT procedure. While <FIG> illustrated two timers, the embodiment in <FIG> includes only one timer. For SDT preparation, SDT parameters are configured <NUM>. The SDT parameter configuration <NUM> is further described with respect to <FIG>. SDT type selection <NUM> is further described below with respect to <FIG>. In block <NUM> a request for small data transmission (SDT) is made from the UE to the basestation gNB. In response, the basestation gNB provides a reply that includes an SDT indication. In this embodiment, the only timer is started when the request is made. In block <NUM>, the SDT process is entered. Data transmission is scheduled to the UE <NUM> and is schedule from the UE <NUM>. In block <NUM>, the UE can then enter the legacy inactive state when the only timer expires. The legacy inactive state is the traditional inactive state where no data is transferred as compared with the modified inactive state that can now allow for SDT even in the inactive state.

<FIG> shows an example flow for SDT parameter configuration. SDT parameters are used in the SDT procedure (e.g. Figs. SDT parameters are about data and should be configured to be conducive to the characteristics of small data transmission. SDT parameters are UE specific and may include: ConfiguredGrantConfig(type1), PUSCH-Config, PDSCH-Config, ControlResourceSet, SearchSpace, DRX-config, etc. Networks take traffic characteristics of small data into account during configuring SDT parameters, such as configuring a little long Downlink Control Information (DCI) detection period for SearchSpace instead of per Transmission Time Interval (TTI) detection period, so as to save UE power consumption.

Specifically, <FIG> shows the SDT parameter configuration <NUM> with two options. In a first option, there would be a RRCReconfiguration <NUM> in which the network can configure SDT parameters via RRCReconfiguration in a CONNECTED state. In block <NUM>, when the UE enters an IDLE state, the UE releases SDT resources configured by SDT parameters. In a second option, there would be a RRCRelease <NUM> with SuspendConfig. The network can configure SDT parameters via RRCRelease with SuspendConfig such that when UE enters IDLE or CONNECTED state, UE releases SDT resources configured by SDT parameters in block <NUM>.

There may be a configuration for random access (RA) resources that includes different SDT parameters. For example, a separate configuration can be provided for normal RA and RA for data transmission in an inactive state, including the resource in time, frequency, power (e.g. parameters related to power control), and/or code domain. Configuration for grant free transmission may include the resource for grant free transmission in time, frequency, power (e.g. parameters related to power control), and/or code domain. Indicator(s) can indicate whether the data transmission in power efficient state is supported and/or allowed. There may be configurations for the area scope that in which area the data transmission in power efficient state is allowed. The configurations for the selection between the data transmission after state transition and the data transmission in power efficient state without state transition, may include <NUM>) for which logical channel and/or logical channel group and/or Dedicated Radio Bearer (DRB) and/or quality of service QoS flow and/or Protocol Data Unit (PDU) session, the data transmission in power efficient state without state transition is allowed; and <NUM>) the buffer size threshold.

<FIG> shows an example flow for SDT type selection. In some embodiments, the SDT may be initiated with a RACH-based scheme and CG-based scheme. A RACH-based scheme can use legacy RA resources, or use SDT related random access (RA) resources. SDT resources may be assigned a selection priority <NUM>. First priority is the selection of SDT related CG resources in block <NUM>. Second priority is the selection of SDT related RA resources (e.g. <NUM>-step RA, then <NUM>-step RA) in block <NUM>. Third priority is selecting legacy RA resources (e.g. <NUM>-step RA, then <NUM>-step RA) in block <NUM>. In block <NUM>, reference signals received power (RSRP) thresholds are configured.

In one embodiment, there may be three RSRP thresholds <NUM>. In other embodiments there may be more or fewer thresholds and any subset or all of the thresholds can be used. A first threshold is for the selection between the normal uplink (NUL) carrier and the supplementary uplink (SUL) carrier. If the RSRP of the downlink pathloss reference is less than the first threshold, the UE will select the SUL carrier. A second threshold is for selection between <NUM>-step RA type and <NUM>-step RA type when both <NUM>-step and <NUM>-step Random Access type resources are configured in the UL bandwidth part (BWP). If the RSRP of the downlink pathloss reference is above the second threshold, the UE will select <NUM>-step RA. A third RSRP threshold is used for selecting resources to initiate SDT. If the RSRP of the downlink pathloss reference is above the third RSRP threshold, the UE will select SDT related RA resources. Specifically, the third threshold establishes how to select resources to initiate SDT. In some embodiments, that selection may follow from when UE is configured NUL and SUL, or <NUM>-step RA and <NUM>-step RA.

In one example embodiment, the UE is configured NUL and SUL carrier and for one BWP, SDT related CG resources are configured in SUL, and not configured in NUL. Further, RA resources are configured in NUL and SUL, and the RSRP of the downlink pathloss reference is above the first threshold. In this example, if the UE selects the carrier first, the UE would select NUL and select RA resources. In other embodiments, due to SDT related CG resources being configured in SUL, UE can select SDT related CG resources first instead of selecting carrier first.

In another example embodiment, the UE is configured NUL and SUL carrier and for one BWP, SDT related CG resources are configured in NUL, and not configured in SUL. RA resources are configured in NUL and SUL, and the RSRP of the downlink pathloss reference is less than the first threshold. In this example, if the UE selects the carrier first, the UE would select SUL and select RA resources. In other embodiments, due to SDT related CG resources are configured in NUL, the UE can not select SDT related CG resources, because the UE's position is applicable to SUL carrier.

Referring back to <FIG>, the SDT initiation phase (<NUM>, <NUM>) includes RACH-based and CG-based schemes, using either RRC-based or RRC-less embodiments. The SDT request can be RRC signaling or medium access control (MAC) control element (CE), and the SDT indication can be RRC signaling or MAC CE or DCI. <FIG> illustrate SDT indication examples.

<FIG> shows an example of a RACH-based and RRC-based SDT indication. The communication is with a RACH-based scheme and radio resource control (RRC) signaling. The UE issues a message <NUM> that may include an RRCResumeRequest to the basestation gNB. In response <NUM>, the communication is modified to introduce a new field to the RRC message. Specifically, message <NUM> illustrates that RRCRelease includes an SDT indication field. This SDT indication is part of the reply by adding a new field to a legacy RRC message.

<FIG> shows an example of a RACH-based and MAC control element (CE)-based SDT indication. The MAC control element (CE) communications are at the MAC layer. There may be a MAC structure for carrying the control information that is referred to as MAC CE. The UE issues a message <NUM> that may include C-RNTI to the basestation gNB. In response <NUM>, the communication is modified to introduce a new field to the MAC CE message. Specifically, message <NUM> illustrates a PDSCH message that includes an SDT indication field. This SDT indication is part of the reply by adding a new field to a legacy MAC CE message.

<FIG> shows an example of a RACH-based and downlink control information (DCI)-based SDT indication. The UE issues a message <NUM> that may include C-RNTI to the basestation gNB. In response <NUM>, the communication is modified to introduce a new field to a DCI message or to introduce a new DCI message. Specifically, message <NUM> illustrates a DCI message that includes an SDT indication field. This SDT indication that is part of the reply may be in a new DCI message or may be a new field added to a legacy DCI message.

<FIG> shows an example of a CG-based and RRC-based SDT indication. The communication is through a configured grant (CG) scheme with RRC signaling. The UE issues a message <NUM> that may include an RRCResumeRequest to the basestation gNB. In response <NUM>, the communication is modified to introduce a new field to the RRC message. Specifically, message <NUM> illustrates that RRCRelease includes an SDT indication field. This SDT indication is part of the reply by adding a new field to a legacy RRC message.

<FIG> shows an example of a CG-based and MAC CE-based SDT indication. The MAC control element (CE) communications are at the MAC layer. The UE issues a message <NUM> that may include CG PUSCH to the basestation gNB. In response <NUM>, the communication is modified to introduce a new field to the MAC CE message. Specifically, message <NUM> illustrates a new MAC CE message that includes an SDT indication field. This SDT indication is part of the reply by adding a new field to a legacy MAC CE message.

<FIG> shows an example of a CG-based and DCI-based SDT indication. The UE issues a message <NUM> that may include CG PUSCH to the basestation gNB. In response <NUM>, the communication is modified to introduce a new field to the DCI message or to introduce a new DCI message. Specifically, message <NUM> illustrates a DCI message that includes an SDT indication field. This SDT indication that is part of the reply may be in a new DCI message or may be a new field added to a legacy DCI message.

<FIG> shows a first example procedure for abnormal messaging. The procedure in <FIG> corresponds with the procedure in <FIG>, except the SDT request is sent multiple times. This procedure is referred to as abnormal because the reply is not sent until after the SDT request is sent three times. The SDT is initiated in block <NUM> and in block <NUM>, the requests are sent. As shown in <FIG>, the SDT request is send three times before receiving the SDT indication. When the SDT indication is received the timer is stopped. The SDT process is entered and the SDT timer is started in block <NUM>.

<FIG> shows a second example procedure for abnormal messaging. The procedure in <FIG> corresponds with the procedure in <FIG>, except the SDT request is sent multiple times. Specifically, <FIG> illustrates a single timer, while <FIG> included two timers. This procedure is referred to as abnormal because the reply is not sent until after the SDT request is sent three times. The SDT is initiated in block <NUM> and in block <NUM>, the requests are sent. As shown in block <NUM>, the SDT request is send three times before receiving the SDT indication. The SDT process is entered in block <NUM>. As in <FIG>, when the timer expires, the SDT process is stopped and the legacy inactive state is entered (not shown in <FIG>).

In both <FIG> and <FIG>, there are different resending approaches for RACH-based and CG-based schemes. For example, the RACH-based scheme may include the UE resending the SDT request via MSG3/MSGA. UE can resend MSG3/MSGA if not receiving MSG4/MSGB (including the SDT indication). For the CG-based scheme, the UE can resend the SDT request at a subsequent periodic point of CG PUSCH resources before receiving the SDT indication.

<FIG> shows a third example procedure for abnormal messaging. In <FIG>, the reply with the SDT indication is not received. The SDT is initiated in block <NUM> and in block <NUM>, the requests are sent, but the reply is not received. The requests are resent in block <NUM> until the timer expires in block <NUM>, which results in an SDT failure <NUM>. If UE can not receive a reply message before the timer expires, the UT thinks there is a SDT failure. After the failure in block <NUM>, the UE can process by <NUM>) re-initiating SDT procedure after the timer (configure by the network), or <NUM>) initiating legacy RRC resume procedure, or <NUM>) initiate SDT procedure using RA resources (if the UE relied on CG resources).

<FIG> shows a fourth example procedure for abnormal messaging. The SDT is initiated in block <NUM>. In block <NUM>, the communications are abnormal because the basestation gNB sends other messages before the response (with the SDT indication) to the SDT request. The network can reply with different messages according to current network and UE conditions when receiving SDT request from UE. Message1/message2/message3 can be RRC signaling, MAC CE, or DCI. In one example, the UE sends SDT request via RRC-based solution, then network can reply with an RRC message to indicate UE to enter the idle state, the inactive state, or the connected state. In another example, the UE sends SDT request via RRC-less solution, then network can reply with a MAC CE to indicate UE to enter the idle state, the inactive state, or the connected state. This may introduce a new MAC CE. In yet another example, the UE sends an SDT request via RRC-less solution, then the network can reply with a DCI message to indicate UE to enter the idle state, the inactive state, or the connected state. This may introduce a new DCI, or introduce a new field to a legacy DCI.

<FIG> shows a fifth example procedure for abnormal messaging. <FIG> shows the SDT initiation phase while <FIG> shows the SDT process phase <NUM>. Similar to <FIG>, there may be additional messages <NUM> from the basestation gNB in response to the scheduling of data <NUM>. The messages <NUM> may be the network sending a message to indicate UE to enter idle, inactive, or connected state according to current network and UE conditions. Message1/message2/message3 can be RRC signaling, MAC CE, or DCI.

<FIG> shows an example anchor relocation communications. An anchor basestation gNB may be referred to as the last serving gNB. The UE is in an inactive state. The UE issues a RRCResumeRequest to the gNB. The gNB retrieves UE context through a request to the last serving gNB (anchor gNB), which retrieves the UE context response. An RRCResume message is provided by the gNB to the UE. The UE is in a connected state and issues a RRCResumeComplete message to gNB. After path switch requests/responses, the UE context is released.

For the SDT procedure described above, the network can decide to relocate the anchor gNB or not relocate the anchor gNB when the SDT request is received at a different gNB (i.e. the current service gNB is not the last service gNB before entering an inactive state). When the network receives the SDT request in a different gNB, there are several alternatives, including: <NUM>) the service gNB performs anchor relocation immediately; <NUM>) the service gNB does not perform anchor relocation, and performs data forwarding; and <NUM>) the service gNB does not perform anchor relocation, and performs data forwarding first, but then the service gNB performs anchor relocation when receiving a larger BSR above a threshold during small data transmission.

Anchor relocation can be triggered by the anchor node or the serving node. Serving node may include a node where the UE camped (e.g. the gNB of the cell where the UE camped) or the node (e.g. gNB) which has the RRC connection with UE, or the node in which the RRC message is received from UE in air interface. The anchor node may be the node where UE's SRB1 PDCP are located, or the node where UE's NG-C and/or NG-U connection is located or terminated. The anchor node may be the node where the UE context stored or the node from which the user data packet is forwarded to the core network.

There are different embodiments depending on which of the nodes triggers the anchor relocation. Considering the buffer status and radio condition of the UE can change, the serving gNB may determine to switch the UE from inactive state to connected state at any point of time during the SDT, based on the buffer status and radio condition on the UE side. Accordingly, the serving gNB can initiate the anchor relocation at any point of time including during the SDT procedure.

In one embodiment, when anchor relocation is triggered by the anchor node, the anchor node: <NUM>) sends a first message to the serving node to request the anchor relocation; <NUM>) receives a second message from the serving node that includes a container, which contains a RRC message (e.g. RRC resume or RRC reconfiguration or a newly defined RRC message); <NUM>) performs ciphering and/or integrity protection for the RRC message included in the container; and <NUM>) sends a third message to the serving node, in which a container is included which contains SRB PDCP PDU. The first message to the serving node to request the anchor relocation may be an XnAP message. The first message to the serving node to request the anchor relocation may include UE context, an anchor relocation indication, a transport address for data forwarding, a cause for anchor relocation, and/or security information, which can be used for security key generation in serving node and/or UE. The security information may include at least one of the following information: key-NG-RAN-Star, Ncc, and/or nextHopChainingCount. The second message may be an RRC message that includes at least the following information: keySetChangeIndicator and/or nextHopChainingCount. The SRB PDCP PDU in the third message may contain the security protected RRC message.

In an alternative embodiment, for the anchor relocation triggered by the anchor node, the following procedure may be utilized by the serving node. In a first step, the serving node receive the anchor relocation request from anchor node. In a second step, the serving node sends a message to the anchor node that includes a container with a RRC message (e.g. RRC resume or RRC reconfiguration or newly defined RRC message). In a third step, the serving node receives SRB PDCP PDU from the anchor node, and the serving node sends the SRB PDCP PDU to UE.

In another embodiment, when anchor relocation is triggered by the serving node, the serving node: <NUM>) receives the security information from the anchor node that can be used for security key generation in serving node and/or UE; <NUM>) sends a message to the anchor node that includes a container with a RRC message (e.g. RRC resume or RRC reconfiguration or newly defined RRC message); <NUM>) receives a message from the anchor node including a container with a SRB PDCP PDU; and <NUM>) sends the SRB PDCP PDU to UE. In step <NUM>), the security information can be included in RetrieveUEContextResponse message, or a separate message. In step <NUM>), an anchor relocation indication can be included in the message sent from serving node to anchor node. In step <NUM>), in the RRC message, at least the following information may be included: keySetChangeIndicator and/or nextHopChainingCount. The security information may include at least one of key-NG-RAN-Star, Ncc, and/or nextHopChainingCount.

In an alternative embodiment, for the anchor relocation triggered by the serving node, the following procedure may be utilized by the anchor node. In step <NUM>, the anchor node receives an anchor relocation request message from serving node that includes a container with a RRC message. In step <NUM>, the anchor node performs ciphering and/or integrity protection for the RRC message included in the RRC container. In step <NUM>, the anchor node sends the ciphered and/or integrity protected SRB PDCP PDU to the serving node. In step <NUM>, the SRB PDCP PDU contains the RRC message received in Step <NUM>. Before step <NUM>, if there is no available security information in the serving node, the following procedure may be used to request the security information: <NUM>) the serving node sends a first message to anchor node to request the anchor relocation (e.g. an anchor relocation indication can be included in the message); and <NUM>) the serving node receives a second message from anchor node including the security information, which can be used to generate the security key used in serving node and/or UE.

Claim 1:
A method for wireless communication, performed by a base station (<NUM>),
comprising:
receiving, from a user equipment device (<NUM>), a request for a small data transmission, the user equipment device (<NUM>) being in an inactive state;
sending, to the user equipment device (<NUM>), a small data transmission indication in response to the request for the small data transmission, wherein the small data transmission indication comprises a downlink control information, DCI; and
processing the small data transmission.