SMALL DATA TRANSMISSION

Abstract

Method, systems and devices for small data transmissions 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.

Claims

1. A method for wireless communication, comprising: receiving a request for a small data transmission during an inactive state; providing a small data transmission indication in response to the request; and processing the small data transmission.

2. The method of claim 1, wherein the small data transmission request is from a user equipment device that is in the inactive state.

3. The method of claim 2, wherein the user equipment device receives the small data transmission indication in response to the request.

4. The method of claim 2, further comprising: configure small data transmission parameters which configure small data transmission resources, wherein the small data transmission resources are released based on the small data transmission parameters upon entry of an idle or connected state for the user equipment device.

5. The method of claim 4, wherein the small data transmission parameters are configured via RRCReleasse with SuspendConfig.

6. The method of claim 2, wherein the processing the small data transmission further comprises: starting an SDT timer; scheduling a downlink data transmission or an uplink data transmission; restarting the SDT timer upon the scheduling.

7. The method of claim 6, wherein, upon expiration of the SDT timer, the user equipment device enters a state in which communication is prohibited.

8. The method of claim 1, wherein the small data transmission indication comprises a field in a radio resource control message.

9. The method of claim 1, wherein the small data transmission indication comprises a MAC control element.

10. The method of claim 1, wherein the small data transmission indication comprises a downlink control information (DCI) or a field as part of a DCI.

11. The method of claim 1, further comprising: providing a message for a change in state before the response provide.

12. A method for wireless communication, comprising: providing, while in an inactive state, a request for a data transmission; receiving a data transmission indication in response to the request; and processing the data transmission.

13. The method of claim 12, wherein the data transmission request is from a user equipment device that is in the inactive state.

14. (canceled)

15. The method of claim 13, further comprising: configure data transmission parameters, which configure data transmission resources, wherein the data transmission resources are released based on the data transmission parameters upon entry of an idle or connected state for the user equipment device.

16. (canceled)

17. The method of claim 12, further comprising: starting a first timer after providing the request; stopping the first timer after receiving the data transmission indication; and starting a second timer after receiving the data transmission indication.

18. The method of claim 17, wherein the processing the data transmission further comprises: scheduling a downlink data transmission or an uplink data transmission; and restarting the second timer upon the scheduling.

19. The method of claim 18, further comprising: entering, upon expiration of the second timer, a legacy inactive state in which communication is prohibited.

20. The method of claim 18, wherein the first timer is started when the request is provided and an expiration of the first timer before receiving the response to the request results in initiating a new data transmission procedure or a resume procedure.

21. (canceled)

22. (canceled)

23. (canceled)

24. The method of claim 12, wherein the request for the data transmission is resubmitted if the response to the request is not received.

25. (canceled)

26. (canceled)

27. (canceled)

28. (canceled)

29. (canceled)

30. A method for wireless communication, comprising: receiving a request for a data transmission during an inactive state at a first node basestation; determining that a second node basestation should receive the request; performing data forwarding between the first node basestation and the second node basestation; receiving a buffer status report (BSR); and performing anchor relocation when the BSR is above a threshold during data transmission.

31. (canceled)

32. (canceled)

33. (canceled)

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 shows an example basestation.

[0012] FIG. 2 shows an example random access (RA) messaging environment.

[0013] FIG. 3 shows example multiple step random access protocols.

[0014] FIG. 4 shows one embodiment of a small data transmission (SDT) procedure.

[0015] FIG. 5 shows another embodiment of a SDT procedure.

[0016] FIG. 6 shows an example flow for SDT parameter configuration.

[0017] FIG. 7 shows an example flow for SDT type selection.

[0018] FIG. 8 shows an example of a RACH-based and RRC-based SDT indication.

[0019] FIG. 9 shows an example of a RACH-based and MAC CE-based SDT indication.

[0020] FIG. 10 shows an example of a RACH-based and DCI-based SDT indication.

[0021] FIG. 11 shows an example of a CG-based and RRC-based SDT indication.

[0022] FIG. 12 shows an example of a CG-based and MAC CE-based SDT indication.

[0023] FIG. 13 shows an example of a CG-based and DCI-based SDT indication.

[0024] FIG. 14 shows a first example procedure for abnormal messaging.

[0025] FIG. 15 shows a second example procedure for abnormal messaging.

[0026] FIG. 16 shows a third example procedure for abnormal messaging.

[0027] FIG. 17 shows a fourth example procedure for abnormal messaging.

[0028] FIG. 18 shows a fifth example procedure for abnormal messaging.

[0029] FIG. 19 shows an example anchor relocation communication.

[0030] FIG. 20 shows another example anchor relocation communications.

DETAILED DESCRIPTION

[0031] 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. Please note that the present disclosure may, however, be embodied in a variety of different forms and, therefore, the covered or claimed subject matter is intended to be construed as not being limited to any of the embodiments to be set forth below.

[0032] 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.

[0033] In general, terminology may be understood at least in part from usage in context. 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.

[0034] 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.

[0035] 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.

[0036] 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 1) traffic from Instant Messaging services (e.g. WHATSAPP, QQ, WECHAT, etc.); 2) heart-beat/keep-alive traffic from IM/email clients and other apps; and 3) 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 100 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.

[0037] 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.

[0038] FIG. 1 shows an example basestation 102. The basestation may also be referred to as a wireless network node. The basestation 102 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 113 to receive and transmit with user equipment (UEs) 104. The basestation may also include network interface circuitry 116 to couple the basestation to the core network 110, e.g., optical or wireline interconnects, Ethernet, and/or other data transmission mediums/protocols.

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

[0040] FIG. 2 shows an example random access messaging environment 200. In the random access messaging environment a UE 104 may communicate with a basestation 102 over a random access channel 252. In this example, the UE 104 supports one or more Subscriber Identity Modules (SIMs), such as the SIM1 202. Electrical and physical interface 206 connects SIM1 202 to the rest of the user equipment hardware, for example, through the system bus 210.

[0041] The mobile device 200 includes communication interfaces 212, system logic 214, and a user interface 218. The system logic 214 may include any combination of hardware, software, firmware, or other logic. The system logic 214 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 214 is part of the implementation of any desired functionality in the UE 104. In that regard, the system logic 214 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 218. The user interface 218 and the inputs 228 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 228 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.

[0042] The system logic 214 may include one or more processors 216 and memories 220. The memory 220 stores, for example, control instructions 222 that the processor 216 executes to carry out desired functionality for the UE 104. The control parameters 224 provide and specify configuration and operating options for the control instructions 222. The memory 220 may also store any BT, WiFi, 3G, 4G, 5G or other data 226 that the UE 104 will send, or has received, through the communication interfaces 212. In various implementations, the system power may be supplied by a power storage device, such as a battery 282

[0043] In the communication interfaces 212, Radio Frequency (RF) transmit (Tx) and receive (Rx) circuitry 230 handles transmission and reception of signals through one or more antennas 232. The communication interface 212 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.

[0044] The transmitted and received signals may adhere to any of a diverse array of formats, protocols, modulations (e.g., QPSK, 16-QAM, 64-QAM, or 256-QAM), frequency channels, bit rates, and encodings. As one specific example, the communication interfaces 212 may include transceivers that support transmission and reception under the 2G, 3G, BT, WiFi, Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA)+, and 4G/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.

[0045] FIG. 3 shows example multiple step random access protocols 300, 350. 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 (302), (ii) after reception of preamble, BS sends back a random access response (RAR)s (e.g., Msg2) to UE (304), (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 (306), and (iv) after successfully decoding Msg3, a fourth message (e.g., Msg4) is transmitted from the basestation to the UE for performing contention resolution (308). This example four-step random access channel protocol 300 may allow for establishment of RRC connections and be referred to as 4-step RACH.

[0046] In some implementations, the latency created through the 4-step RACH protocol 300 may be decreased by using a two-step random access protocol 350 (e.g., 2-step RACH). The 2-step RACH 350 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 4-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 2-step RACH may allow for reduced latency compared to the 4-step RACH, which may reduce channel occupancy times increase data available for payload transmission or have other technical benefits. Accordingly, implementing a 2-step RACH is a technical solution to a technical problem of increasing data network performance thereby improving the operation of the underlying hardware.

[0047] In various systems to implement a RACH protocol, and in some cases specifically a 2-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 2-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.

[0048] FIG. 4 shows one embodiment of a small data transmission (SDT) procedure. FIG. 4 illustrates communications between the user equipment (UE) and a basestation (gNB). For SDT preparation, SDT parameters are configured 402 for the SDT preparation phase. Specifically, the network configures SDT parameters via RRC signaling as further described with respect to FIG. 6. SDT type selection 404 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. 7. In block 406 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 408, 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 410 and is schedule from the UE 412. 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 414, 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.

[0049] FIG. 5 shows another embodiment of a SDT procedure. While FIG. 4 illustrated two timers, the embodiment in FIG. 5 includes only one timer. For SDT preparation, SDT parameters are configured 502. The SDT parameter configuration 502 is further described with respect to FIG. 6. SDT type selection 504 is further described below with respect to FIG. 7. In block 506 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 508, the SDT process is entered. Data transmission is scheduled to the UE 510 and is schedule from the UE 512. In block 514, 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.

[0050] FIG. 6 shows an example flow for SDT parameter configuration. SDT parameters are used in the SDT procedure (e.g. FIGS. 4a-4b). 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.

[0051] Specifically, FIG. 6 shows the SDT parameter configuration 602 with two options. In a first option, there would be a RRCReconfiguration 604 in which the network can configure SDT parameters via RRCReconfiguration in a CONNECTED state. In block 606, 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 608 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 610.

[0052] 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 1) 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 2) the buffer size threshold.

[0053] FIG. 7 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 702. First priority is the selection of SDT related CG resources in block 704. Second priority is the selection of SDT related RA resources (e.g. 2-step RA, then 4-step RA) in block 706. Third priority is selecting legacy RA resources (e.g. 2-step RA, then 4-step RA) in block 708. In block 710, reference signals received power (RSRP) thresholds are configured.

[0054] In one embodiment, there may be three RSRP thresholds 710. 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 2-step RA type and 4-step RA type when both 2-step and 4-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 2-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 2-step RA and 4-step RA.

[0055] 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.

[0056] 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.

[0057] Referring back to FIGS. 4-5, the SDT initiation phase (404, 504) 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. FIGS. 8-13 illustrate SDT indication examples.

[0058] FIG. 8 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 802 that may include an RRCResumeRequest to the basestation gNB. In response 804, the communication is modified to introduce a new field to the RRC message. Specifically, message 804 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.

[0059] FIG. 9 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 902 that may include C-RNTI to the basestation gNB. In response 904, the communication is modified to introduce a new field to the MAC CE message. Specifically, message 904 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.

[0060] FIG. 10 shows an example of a RACH-based and downlink control information (DCI)-based SDT indication. The UE issues a message 1002 that may include C-RNTI to the basestation gNB. In response 1004, the communication is modified to introduce a new field to a DCI message or to introduce a new DCI message. Specifically, message 1004 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.

[0061] FIG. 11 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 1102 that may include an RRCResumeRequest to the basestation gNB. In response 1104, the communication is modified to introduce a new field to the RRC message. Specifically, message 1104 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.

[0062] FIG. 12 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 1202 that may include CG PUSCH to the basestation gNB. In response 1204, the communication is modified to introduce a new field to the MAC CE message. Specifically, message 1204 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.

[0063] FIG. 13 shows an example of a CG-based and DCI-based SDT indication. The UE issues a message 1302 that may include CG PUSCH to the basestation gNB. In response 1304, the communication is modified to introduce a new field to the DCI message or to introduce a new DCI message. Specifically, message 1304 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.

[0064] FIG. 14 shows a first example procedure for abnormal messaging. The procedure in FIG. 14 corresponds with the procedure in FIG. 4, 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 1402 and in block 1404, the requests are sent. As shown in FIG. 14, 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 1406.

[0065] FIG. 15 shows a second example procedure for abnormal messaging. The procedure in FIG. 15 corresponds with the procedure in FIG. 5, except the SDT request is sent multiple times. Specifically, FIG. 15 illustrates a single timer, while FIG. 14 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 1502 and in block 1504, the requests are sent. As shown in block 1504, the SDT request is send three times before receiving the SDT indication. The SDT process is entered in block 1506. As in FIG. 5, when the timer expires, the SDT process is stopped and the legacy inactive state is entered (not shown in FIG. 15).

[0066] In both FIG. 14 and FIG. 15, 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.

[0067] FIG. 16 shows a third example procedure for abnormal messaging. In FIG. 16, the reply with the SDT indication is not received. The SDT is initiated in block 1602 and in block 1604, the requests are sent, but the reply is not received. The requests are resent in block 1604 until the timer expires in block 1606, which results in an SDT failure 1608. 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 1608, the UE can process by 1) re-initiating SDT procedure after the timer (configure by the network), or 2) initiating legacy RRC resume procedure, or 3) initiate SDT procedure using RA resources (if the UE relied on CG resources).

[0068] FIG. 17 shows a fourth example procedure for abnormal messaging. The SDT is initiated in block 1502. In block 1504, 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.

[0069] FIG. 18 shows a fifth example procedure for abnormal messaging. FIG. 17 shows the SDT initiation phase while FIG. 18 shows the SDT process phase 1802. Similar to FIG. 17, there may be additional messages 1806 from the basestation gNB in response to the scheduling of data 1604. The messages 1606 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.

[0070] FIG. 19 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.

[0071] 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: 1) the service gNB performs anchor relocation immediately; 2) the service gNB does not perform anchor relocation, and performs data forwarding; and 3) 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.

[0072] 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.

[0073] 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.

[0074] In one embodiment, when anchor relocation is triggered by the anchor node, the anchor node: 1) sends a first message to the serving node to request the anchor relocation; 2) 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); 3) performs ciphering and/or integrity protection for the RRC message included in the container; and 4) 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.

[0075] 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.

[0076] In another embodiment, when anchor relocation is triggered by the serving node, the serving node: 1) receives the security information from the anchor node that can be used for security key generation in serving node and/or UE; 2) 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); 3) receives a message from the anchor node including a container with a SRB PDCP PDU; and 4) sends the SRB PDCP PDU to UE. In step 1), the security information can be included in RetrieveUEContextResponse message, or a separate message. In step 2), an anchor relocation indication can be included in the message sent from serving node to anchor node. In step 3), 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.

[0077] 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 1, the anchor node receives an anchor relocation request message from serving node that includes a container with a RRC message. In step 2, the anchor node performs ciphering and/or integrity protection for the RRC message included in the RRC container. In step 3, the anchor node sends the ciphered and/or integrity protected SRB PDCP PDU to the serving node. In step 3, the SRB PDCP PDU contains the RRC message received in Step 2. Before step 1, if there is no available security information in the serving node, the following procedure may be used to request the security information: 1) 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 2) 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.

[0078] FIG. 20 shows another example anchor relocation communications. Specifically, FIG. 20 illustrates an initialization of anchor relocation in new radio (NR) small data transmission (SDT). For SDT with anchor relocation, data may be included in the first uplink (UL) message as shown in FIG. 20 with the RRCResumeRequest message include MACPDU containing data. The target gNB may act as a first buffer (“buffer the radio link control (RLC) packet data unit (PDU) containing data”) for the received data and then performs context fetch before proceeding to process the received UL data in the first UL message. Serving gNB (new anchor gNB) sends an RRCRelease message to the UE to end the SDT procedure. FIG. 20 illustrates optional subsequent data transmission (uplink and/or downlink). For anchor relocation, the serving gNB may become the new anchor gNB, perform a path switch procedure, and forward the data packet to CN after the path switch.