Small data transmission

Abstract

A method, system, and device for small data transmission, where data transmission can occur for a user equipment even when the user equipment is in an inactive state. Small data transmission while in an inactive state can save power and reduce signaling overhead. Small data transmission can be prepared with small data transmission parameters. A small data transmission indication is included in a reply to a user equipment requesting a small data transmission communication.

Description

Technical Field

[0001] This application generally pertains to wireless communication. More specifically, small data transmission may occur even when the user equipment is inactive. Background Technology

[0002] Wireless communication technology is propelling the world towards an increasingly interconnected and networked society. Wireless communication relies 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 (UEs) are becoming increasingly complex, and the amount of data transmitted is constantly increasing. To improve communication and power usage, communication improvements are necessary. Summary of the Invention

[0003] This application relates to methods, systems, and apparatus for small data transmission, enabling small data transmission even when the user equipment is inactive. Small data transmission in an inactive state can save power and reduce signaling overhead. Small data transmission can be prepared using small data transmission parameters. A small data transmission indication is included in the response to the user equipment requesting small data transmission communication.

[0004] In one embodiment, a method for wireless communication includes: receiving a request for small data transmission during an inactive state, providing a small data transmission indication in response to the request, starting a timer, and processing the small data transmission. The small data transmission request may originate from a user equipment terminal in an inactive state. The user equipment terminal receives a small data transmission indication in response to the request. The method includes: configuring small data transmission parameters that configure small data transmission resources, wherein, when the user equipment terminal enters an idle or connected state, the small data transmission resources are released based on the small data transmission parameters. The small data transmission parameters are configured via an RCReleasse having SuspendConfig. Processing the small data transmission includes scheduling downlink data transmission or uplink data transmission and restarting a timer during scheduling. When the timer expires, the user equipment terminal enters a communication-prohibited state. The small data transmission indication includes fields in a radio resource control message. The small data transmission indication includes a MAC control unit. The small data transmission indication includes downlink control information (DCI) or fields that are part of the DCI. The method includes: providing a message for a state change before providing a response.

[0005] In another embodiment, a method for wireless communication includes: providing a request for small data transmission while in an inactive state; after providing the request, starting a first timer; receiving a small data transmission indication in response to the request; after receiving the indication, stopping the first timer and starting a second timer; and processing the small data transmission. The small data transmission request originates from a user equipment terminal in an inactive state. The user equipment terminal receives a small data transmission indication in response to the request. The method includes: configuring small data transmission parameters that configure small data transmission resources, wherein, when the user equipment terminal enters an idle or connected state, the small data transmission resources are released based on the small data transmission parameters. The small data transmission parameters are configured via an RCReleasse with SuspendConfig. Processing the small data transmission includes scheduling downlink data transmission or uplink data transmission and restarting the second timer during scheduling. The method includes: entering a communication-prohibited state when the second timer times out. When the request is provided, the first timer is started, and the timeout of the first timer causes a new small data transmission procedure or a connection recovery procedure to be initiated. The small data transmission indication includes fields in a radio resource control message. The small data transmission indication includes a MAC control unit. The small data transmission indication includes downlink control information (DCI) or fields that are part of the DCI. If no response to the request is received before the first timer expires, the request for the small data transfer is resent.

[0006] In another embodiment, a method for wireless communication includes: establishing a threshold for selecting between conventional random access (RA) resources and RA resources associated with small data transmission (SDT), wherein the SDT-associated RA resource is selected when the reference signal received power (RSRP) of the downlink path loss reference is higher than the threshold, and the conventional RA resource is selected when the RSRP of the downlink path loss reference is lower than the threshold. The method further includes: establishing another threshold for selecting between a two-step RA type and a four-step RA type, and selecting the two-step RA type when the RSRP of the downlink path loss reference is higher than the other threshold.

[0007] In another embodiment, a method for wireless communication includes: establishing a Small Data Transmission (SDT) resource selection priority, wherein the SDT resource selection priority includes first selecting a Configuration Grant (CG) resource associated with the SDT, second selecting a Random Access (RA) resource associated with the SDT, and third selecting a traditional RA resource. The SDT-associated RA resources include two-step RAs and four-step RAs; furthermore, the resource selection priority includes selecting a two-step RA before a four-step RA. The traditional RA resources include two-step RAs and four-step RAs; furthermore, the resource selection priority includes selecting a two-step RA before a four-step RA.

[0008] In another embodiment, a method for wireless communication includes: receiving a request for small data transmission during an inactive state at a first node base station; determining that a second node base station should receive the request; performing data forwarding between the first and second node base stations; receiving a buffer status report (BSR); and, during small data transmission, performing anchor relocation if the BSR is higher than a threshold. This threshold limits the amount of data that can be transmitted.

[0009] In some embodiments, there is a wireless communication device including a processor and a memory, wherein the processor is configured to read code from the memory and implement any of the methods described in any embodiment.

[0010] In some embodiments, a computer program product includes computer-readable program medium code stored thereon, which, when executed by a processor, causes the processor to perform any of the methods described in any embodiment. The above and other aspects and their implementations are described in more detail in the accompanying drawings, description, and claims. Attached Figure Description

[0011] Figure 1 An example base station is shown.

[0012] Figure 2 An example random access (RA) messaging environment is shown.

[0013] Figure 3 An example multistep random access protocol is shown.

[0014] Figure 4 An embodiment of the Small Data Transfer (SDT) process is shown.

[0015] Figure 5 Another embodiment of the SDT process is shown.

[0016] Figure 6 An example flow for configuring SDT parameters is shown.

[0017] Figure 7 An example flow for SDT type selection is shown.

[0018] Figure 8 Examples of SDT instructions based on RACH and RRC are shown.

[0019] Figure 9 Examples of SDT instructions based on RACH and MAC CE are shown.

[0020] Figure 10 Examples of SDT instructions based on RACH and DCI are shown.

[0021] Figure 11 Examples of SDT instructions based on CG and RRC are shown.

[0022] Figure 12 Examples of SDT instructions based on CG and MAC CE are shown.

[0023] Figure 13 Examples of SDT instructions based on CG and DCI are shown.

[0024] Figure 14 A first example procedure for passing exception messages is shown.

[0025] Figure 15 A second example procedure for passing exception messages is shown.

[0026] Figure 16 A third example procedure for passing exception messages is shown.

[0027] Figure 17 A fourth example procedure for passing exception messages is shown.

[0028] Figure 18 The fifth example procedure for passing exception messages is shown.

[0029] Figure 19 An example anchor point relocation communication is shown.

[0030] Figure 20 Another example of anchor point relocation communication is shown. Detailed Implementation

[0031] The present disclosure will now be described in detail below with reference to the accompanying drawings, which form part of the disclosure and illustrate specific examples of embodiments by way of illustration. However, it should be noted that the present disclosure may be embodied in various different forms, and therefore, the subject matter covered or claimed is intended to be construed as not being limited to any of the embodiments set forth below.

[0032] Throughout the specification and claims, terms may have nuanced meanings suggested or implied by the context, in addition to their expressly stated meanings. Similarly, the phrases “in one embodiment” or “in some embodiments” as used herein do not necessarily refer to the same embodiment, and the phrases “in another embodiment” or “in other embodiments” as used herein do not necessarily refer to different embodiments. For example, the claimed subject matter is intended to encompass, in whole or in part, combinations of exemplary embodiments or implementations.

[0033] Generally, terms can be understood, at least in part, from their usage in the context. For example, terms used herein, such as “and,” “or,” or “and / or,” can include a variety of meanings that may depend at least in part on the context in which they are used. Typically, “or,” if used to relate a list such as A, B, or C, is intended to indicate that A, B, and C are used here in an inclusive sense, and that A, B, or C are used here in an exclusive sense. Furthermore, the terms “one or more” or “at least one” (at least in part on the context) as used herein can be used to describe any feature, structure, or characteristic in a singular sense, or can be used to describe a combination of features, structures, and characteristics in a plural sense. Similarly, terms such as “a,” “an,” or “the” can also be understood to express either a singular or a plural usage, at least in part on the context. Moreover, the terms “based on” or “determined by” can be understood not necessarily to express a set of exclusive factors, but can allow for the existence of additional factors that are not necessarily explicitly described, again, at least in part on the context.

[0034] In various telecommunications systems, such as mobile telecommunications environments, User Equipment (UE) can communicate using Small Data Transmission (SDT). Traditionally, user data transmission is not permitted when inactive. Even for very small data transmissions, the device must re-establish a connection, which can negatively impact signaling overhead and device power consumption. As described below, Small Data Payload (SDT) transmission can occur in an inactive state. For New Radio (NR) specifications, a UE can have three states: idle, inactive, and connected. A UE cannot transmit data in idle or inactive states; therefore, when a UE wants to transmit data in an idle or inactive state, it first transitions to the connected state. However, as described herein, for Small Data Transmission (SDT), a UE can transmit small data in an inactive state instead of first transitioning to the connected state. The version where no data can be transmitted in the idle / inactive state, compared to the states presented here that allow small data transmission in inactive or idle states, can be referred to as the traditional state.

[0035] Any device with intermittent small data packets in an inactive state can benefit from enabling Small Data Transmission (SDT) in the inactive state. SDT traffic may have different service requirements compared to conventional or larger data transmission traffic types. SDT communication or data transmission can be performed from or utilized by the UE while in an inactive state. The UE can send an SDT request message to a base station, which can be a Node B (NB, such as an eNB or gNB) in a mobile telecommunications environment. The base station can respond to the UE request message with a reply including an SDT indication. The SDT indication indicates that communication can be performed from the UE even in an inactive state. Small data transmission in an inactive state can save power and reduce signaling overhead.

[0036] The SDT communication described herein can coexist with conventional hybrid traffic on the same carrier while improving the utilization of network resources (power, code, interference, etc.) used for SDT communication. Examples of small, infrequent data traffic conforming to SDT standards include smartphone applications such as 1) traffic from instant messaging services (e.g., WhatsApp, QQ, WeChat, etc.); 2) heartbeat / keep-alive traffic from IM / email clients and other applications; and 3) push notifications from various applications. Furthermore, other SDTs may include traffic from wearable devices (periodic location information, etc.), sensors (e.g., industrial wireless sensor networks that periodically or event-triggeredly transmit temperature and pressure readings), and smart meters or smart meter networks that transmit periodic instrument readings. In one embodiment, small data in SDT may include data with an application packet size of 100 bytes (upload UL or download DL) or less. While the examples and embodiments described herein relate to small data or small data transmissions, the scope of small data can 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 be applicable to any data.

[0037] Radio Resource Control (RRC) is a protocol layer between the UE and the base station at the IP layer (network layer). RRC messages are transmitted via Packet Data Convergence Protocol (PDCP). As mentioned above, the UE can transmit infrequent (periodic and / or non-periodic) data in the RRC_INACTIVE state without transitioning to the RRC_CONECTED state. This saves UE power consumption and signaling overhead. This can be achieved through the Random Access Channel (RACH) protocol scheme or the Configuration Grant (CG) scheme. RACH is a shared channel used by radio terminals to access mobile networks (TDMA / FDMA and CDMA-based networks) for call establishment and data transmission. The UE schedules RACH whenever it wants to initiate an MO (Mobile Origin) call. RACH is a transport layer channel, while the corresponding physical layer channel is PRACH.

[0038] Figure 1 An example base station 102 is shown. A base station may also be referred to as a wireless network node. Base station 102 may be further identified as a Node B (NB, such as eNB or gNB) in a mobile telecommunications environment. The example base station may include wireless Tx / Rx circuitry 113 for receiving and transmitting with user equipment (UE) 104. The base station may also include network interface circuitry 116 for coupling the base station to the core network 110, such as fiber optic or wired interconnect, Ethernet, and / or other data transmission media / protocols.

[0039] The base station may also include system circuitry 122. System circuitry 122 may include one or more processors 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 processors 124 to support base station operation. For example, the operation may process random access transmission requests from multiple UEs. Control parameters 130 may include parameters or support for the execution of operations 128. For example, control parameters may include network protocol settings, random access message format rules, bandwidth parameters, radio frequency mapping allocation, and / or other parameters.

[0040] Figure 2 An example random access message environment 200 is illustrated. In this environment, UE 104 can communicate with base station 102 via random access channel 252. In this example, UE 104 supports one or more User Identity Modules (SIMs) such as SIM1 202. Electrical and physical interfaces 206 connect SIM1 202 to the rest of the user equipment hardware, for example, via system bus 210.

[0041] Mobile device 200 includes a communication interface 212, system logic 214, and user interface 218. System logic 214 may include any combination of hardware, software, firmware, or other logic. System logic 214 may be implemented using, for example, one or more system-on-chip (SoC), application-specific integrated circuit (ASIC), discrete analog and digital circuitry, and other circuitry. System logic 214 is part of an implementation of any desired functionality in UE 104. In this regard, system logic 214 may include logic that facilitates, for example, decoding and playing music and video (e.g., MP3, MP4, MPEG, AVI, FLAC, AC3, or WAV decoding and playback); running applications; accepting user input; saving and retrieving application data; establishing, maintaining, and terminating cellular phone calls or data connections, as an example, for internet connections; establishing, maintaining, and terminating wireless network connections, Bluetooth connections, or other connections; and displaying relevant information on user interface 218. User interface 218 and input 228 may include a graphical user interface, a touch-sensitive display, haptic feedback or other haptic output, voice or facial recognition input, buttons, switches, speakers, and other user interface elements. Other examples of input 228 include microphones, video and still image cameras, temperature sensors, vibration sensors, rotation and orientation sensors, headphone 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] System logic 214 may include one or more processors 216 and memory 220. Memory 220 stores, for example, control instructions 222, which the processors 216 execute to achieve the desired functionality of UE 104. Control parameters 224 provide and specify configuration and operational options for the control instructions 222. Memory 220 may also store any BT, WiFi, 3G, 4G, 5G, or other data 226 that UE 104 will send or has received via communication interface 212. In various embodiments, system power may be supplied by a power storage device such as battery 282.

[0043] In communication interface 212, radio frequency (RF) transmitting (Tx) and receiving (Rx) circuitry 230 processes the transmission and reception of signals via one or more antennas 232. Communication interface 212 may include one or more transceivers. The transceiver may be a wireless transceiver, including modulation / demodulation circuitry, a digital-to-analog converter (DAC), a shaper, an analog-to-digital converter (ADC), filters, waveform shapers, preamplifiers, power amplifiers, and / or other logic for transmission and reception via one or more antennas or (for some devices) via a physical (e.g., wired) medium.

[0044] The transmitted and received signals can follow any of a variety of formats, protocols, modulations (e.g., QPSK, 16-QAM, 64-QAM, or 256-QAM), frequency channels, bit rates, and encodings. As a specific example, communication interface 212 may include a transceiver supporting transmission and reception under 2G, 3G, BT, WiFi, Universal Mobile Telecommunications System (UMTS), High-Speed ​​Packet Access (HSPA)+, and 4G / LTE standards. However, the techniques described below are applicable to other wireless communication technologies, whether originating from the 3rd Generation Partnership Project (3GPP), the GSM Association, 3GPP2, IEEE, or other partners or standards bodies.

[0045] Figure 3Example multistep random access protocols 300 and 350 are illustrated. In various implementations, the UE and base station (gNB) may employ a multistep protocol: (i) the UE sends a preamble (e.g., in Msg1) to the base station (302), (ii) upon receiving the preamble, the BS sends a random access response (RAR) back to the UE (e.g., Msg2) (304), (iii) the UE sends back a third message (e.g., Msg3) on the upload UL authorization indicated in the RAR containing the preamble sent in Msg1 (306), and (iv) after successfully decoding Msg3, a fourth message (e.g., Msg4) is sent from the base station to the UE to perform contention resolution (308). This example four-step random access channel protocol 300 may allow the establishment of an RRC connection and is referred to as 4-step RACH.

[0046] In some implementations, the latency introduced by the 4-step RACH protocol 300 can be reduced by using a two-step random access protocol 350 (e.g., 2-step RACH). The 2-step RACH 350 can combine (i) and (iii) and (ii) and (iv) to compress 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 the physical random access channel and / or a payload transmitted in the physical uplink shared channel, containing at least the same amount of information as Msg3 carried in the 4-step RACH. A second message (e.g., Msg2 in response to Msg1) is sent from the BS to the UE. Thus, the merging of the two UE messages allows for the merging of the two base station messages. Compared to the 4-step RACH, the example 2-step RACH can allow for reduced latency, which can reduce channel occupancy time, increase the amount of data available for payload transmission, or have other technical benefits. Therefore, implementing 2-step RACH is a technical solution to the technical problem of improving data network performance and thus improving the operation of the underlying hardware.

[0047] In various systems implementing the RACH protocol, and in certain cases, particularly in 2-step RACH, the architecture of random access messages (e.g., the message header / body structure and its fields) is crucial. Although the architecture and techniques discussed in this disclosure are used in the context of a 2-step RACH response message (e.g., Msg2), the architecture and techniques discussed herein can be applied to other random access messages where message architecture and content can be used to distinguish message types. RACH is an example protocol for SDT communication during inactive states, as discussed below. In other embodiments, a configuration authorization (CG) scheme can be used for SDT communication during inactive states.

[0048] Figure 4An embodiment of the Small Data Transfer (SDT) process is shown. Figure 4 The communication between the User Equipment (UE) and the Base Station (gNB) is illustrated. For SDT preparation, SDT parameters are configured for the SDT preparation phase (402). Specifically, the network configures the SDT parameters via RRC signaling, as per [reference to...]. Figure 6 Further description. SDT type selection 404 is part of the SDT initiation phase. In the SDT initiation phase, the UE initiates the SDT procedure after first selecting the SDT type, as described below. Figure 7 Further described. In block 406, the UE makes a request for Small Data Transmission (SDT) to the base station gNB. In response, the base station gNB provides a reply including an SDT indication. In this embodiment, a timer is started when the request is made and stopped when a reply with an SDT indication is received. In block 408, the SDT procedure is entered and the SDT timer is started. The SDT procedure includes the UE using CG PUSCH resources or dynamic UL grants to transmit UL data and using dynamic DL allocations to receive DL data. Data transmission is scheduled to UE 410 and from UE 412. For each data transmission schedule, the SDT timer is restarted. Specifically, the SDT timer is restarted when downlink data is received or uplink data is transmitted. In block 414, when the SDT timer times out, the UE can then enter a conventional inactive state (also referred to as a normal inactive state). The conventional inactive state is the traditional inactive state when no data is transmitted; however, as described herein, the modified inactive state now allows SDT even in the inactive state.

[0049] Figure 5 Another embodiment of the SDT process is shown. Although Figure 4 Two timers are shown, but... Figure 5 The embodiment in this example includes only one timer. For SDT preparation, the SDT parameters are configured (502). See reference... Figure 6 SDT parameter configuration 502 is further described. SDT type selection 504 will be referenced below. Figure 7The process is further described. In block 506, a request for Small Data Transmission (SDT) is made from the UE to the base station gNB. In response, the base station gNB provides a reply including an SDT indication. In this embodiment, a unique timer is started when the request is made. In block 508, the SDT procedure is initiated. Data transmission is scheduled to UE 510 and from UE 512. In block 514, when the unique timer expires, the UE can then enter a conventional inactive state. The conventional inactive state is a traditional inactive state in which no data is transmitted, unlike the inactive state where modifications for SDT are now allowed even in the inactive state.

[0050] Figure 6 An example flow for configuring SDT parameters is shown. SDT parameters are used in the SDT process (e.g., Figure 4-5 SDT parameters are data-related and should be configured to favor small data transmission characteristics. SDT parameters are UE-specific and may include: ConfiguredGrantConfig (type 1), PUSCH-Config, PDSCH-Config, ControlResourceSet, SearchSpace, DRX-Config, etc. When configuring SDT parameters, the network considers the traffic characteristics of small data, such as configuring a slightly longer downlink control information (DCI) detection period for SearchSpace instead of a per transmission time interval (TTI) detection period, to save UE power consumption.

[0051] Specifically, Figure 6 SDT parameter configuration 602 with two options is shown. In the first option, there is RRCReconfiguration 604, in which the network can configure SDT parameters via RRCReconfiguration in the CONNECTED state. In block 606, when the UE enters the idle state, the UE releases the SDT resources configured by the SDT parameters. In the second option, there is RCRelease 608 with SuspendConfig. The network can configure SDT parameters via RCRelease with SuspendConfig such that when the UE enters the IDLE or CONNECTED state, the UE releases the SDT resources configured by the SDT parameters in block 610.

[0052] Configurations for random access (RA) resources, including different SDT parameters, may exist. For example, separate configurations may be provided for normal RAs and RAs transmitting data in an inactive state, including resources in the time, frequency, power (e.g., power control-related parameters), and / or code domain. Configurations for unlicensed transmission may include resources for unlicensed transmission in the time, frequency, power (e.g., power control-related parameters), and / or code domain. One or more indicators may indicate whether data transmission in the power-active state is supported and / or permitted. Configurations for area-wide coverage may exist, specifying which areas are allowed to transmit data in the power-active state. Configurations for selecting between data transmission after a state transition and data transmission in the power-active state without a state transition may include 1) for which logical channel and / or logical channel group and / or dedicated radio bearer (DRB) and / or QoS stream and / or Protocol Data Unit (PDU) session, data transmission in the power-active state without a state transition is permitted; and 2) a buffer size threshold.

[0053] Figure 7 An example flow for SDT type selection is shown. In some embodiments, SDT can be initiated using a RACH-based scheme and a CG-based scheme. The RACH-based scheme can use traditional RA resources or random access (RA) resources associated with the SDT. SDT resources can be assigned selection priorities 702. The first priority is to select SDT-associated CG resources in block 704. The second priority is to select SDT-associated RA resources in block 706 (e.g., 2-step RA, then 4-step RA). The third priority is to select traditional RA resources in block 708 (e.g., 2-step RA, then 4-step RA). In block 710, a reference signal received power (RSRP) threshold is 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 may be used. A first threshold is used to select between a Normal Uplink (NUL) carrier and a Supplementary Uplink (SUL) carrier. If the RSRP referenced by the downlink path loss is less than the first threshold, the UE will select the SUL carrier. When both 2-step and 4-step random access type resources are configured in the UL bandwidth portion (BWP), a second threshold is used to select between a 2-step RA type and a 4-step RA type. If the RSRP referenced by the downlink path loss is higher than the second threshold, the UE will select the 2-step RA. A third RSRP threshold is used to select resources to initiate SDT. If the RSRP referenced by the downlink path loss is higher than the third RSRP threshold, the UE will select the RA resource associated with the SDT. Specifically, the third threshold establishes how resources are selected to initiate SDT. In some embodiments, this selection can begin when the UE is configured as NUL and SUL or 2-step RA and 4-step RA.

[0055] In one example embodiment, the UE is configured with both NUL and SUL carriers, and for a BWP, SDT-related CG resources are configured in the SUL, not in the NUL. Furthermore, RA resources are configured in both the NUL and SUL, and the downlink path loss reference RSRP is higher than a first threshold. In this example, if the UE selects a carrier first, it will select the NUL and then the RA resource. In other embodiments, since the SDT-related CG resources are configured in the SUL, the UE can select the SDT-related CG resources first, instead of selecting a carrier first.

[0056] In another example embodiment, the UE is configured with both NUL and SUL carriers, and for a BWP, SDT-related CG resources are configured in the NUL but not in the SUL. RA resources are configured in both the NUL and SUL, and the downlink path loss reference RSRP is less than a first threshold. In this example, if the UE selects a carrier first, it will select the SUL and choose the RA resources. In other embodiments, since the SDT-related CG resources are configured in the NUL, the UE cannot select the SDT-related CG resources because the UE's location is suitable for the SUL carrier.

[0057] Refer again Figure 4-5 The SDT initiation phase (404, 504) includes RACH-based and CG-based schemes, using RRC-based or RRC-free embodiments. The SDT request can be RRC signaling or a Media Access Control (MAC) control unit (CE), and the SDT indication can be RRC signaling, MAC CE, or DCI. Figure 8-13An example of an SDT instruction is shown.

[0058] Figure 8 An example of SDT indication based on RACH and RRC is shown. The communication uses a RACH-based scheme and Radio Resource Control (RRC) signaling. The UE sends a message (802) to the base station gNB that may include an RRC Resume Request. In response 804, the communication is modified to introduce a new field into the RRC message. Specifically, message 804 shows that the RRC Resume Request includes an SDT indication field. This SDT indication is part of a response made by adding a new field to a traditional RRC message.

[0059] Figure 9 Examples of SDT indication based on RACH and MAC control unit (CE) are shown. MAC control unit (CE) communication is at the MAC layer. A MAC structure called MAC CE for carrying control information may exist. The UE sends message 902 to the base station gNB, which may include C-RNTI. In response 904, the communication is modified to introduce a new field into the MAC CE message. Specifically, message 904 shows a PDSCH message including an SDT indication field. This SDT indication is part of a response by adding a new field to the traditional MAC CE message.

[0060] Figure 10 Examples of SDT indications based on RACH and Downlink Control Information (DCI) are shown. The UE sends message 1002 to the base station gNB, which may include C-RNTI. In response 1004, the communication is modified to introduce a new field into the DCI message or to introduce a new DCI message. Specifically, message 1004 shows a DCI message including an SDT indication field. This SDT indication, as part of the response, may be in a new DCI message or may be a new field added to a traditional DCI message.

[0061] Figure 11 Examples of SDT indications based on CG and RRC are shown. This communication is conducted via a configuration grant (CG) scheme and RRC signaling. The UE sends message 1102 to the base station gNB, which may include an RRC Resume Request. In response 1104, the communication is modified to introduce a new field into the RRC message. Specifically, message 1104 shows that the RRC Resume Request includes an SDT indication field. This SDT indication is part of a response that adds a new field to a traditional RRC message.

[0062] Figure 12Examples of SDT indications based on CG and MAC CE are shown. MAC control unit (CE) communication is at the MAC layer. The UE sends message 1202 to the base station gNB, which may include a CG PUSCH. In response 1204, the communication is modified to introduce a new field into the MAC CE message. Specifically, message 1204 shows a new MAC CE message including an SDT indication field. This SDT indication is part of a response made by adding a new field to a traditional MAC CE message.

[0063] Figure 13 Examples of SDT indications based on CG and DCI are shown. The UE sends message 1302 to the base station gNB, which may include CGPUSCH. In response 1304, the communication is modified to introduce a new field into the DCI message or to introduce a new DCI message. Specifically, message 1304 shows a DCI message including an SDT indication field. This SDT indication, as part of the response, may be in a new DCI message or may be a new field added to a traditional DCI message.

[0064] Figure 14 A first example procedure for exception message passing is shown. Besides the SDT request being sent multiple times, Figure 14 The process and Figure 4 This corresponds to the process described in section 1402. This process is called an exception because a reply is not sent until the SDT request has been sent three times. In box 1402, the SDT is initiated, and in box 1404, the request is sent. (As follows...) Figure 14 As shown, the SDT request is sent three times before the SDT instruction is received. When the SDT instruction is received, the timer stops. In box 1406, the SDT procedure is entered, and the SDT timer is started.

[0065] Figure 15 A second example procedure for exception message passing is shown. In addition to the SDT request being sent multiple times, Figure 15 The process and Figure 5 The process corresponds to this. Specifically, Figure 15 A single timer is shown, while Figure 14 This includes two timers. This process is called exception because a reply is not sent until the SDT request has been sent three times. The SDT is initiated in box 1502, and the request is sent in box 1504. As shown in box 1504, the SDT request is sent three times before the SDT indication is received. The SDT process begins in box 1506. Figure 5 As shown, when the timer expires, the SDT process is stopped and enters the traditional inactive state. Figure 15 (Not shown in the image).

[0066] exist Figure 14 and Figure 15 In this context, RACH-based and CG-based schemes have different retransmission methods. For example, a RACH-based scheme may involve the UE retransmitting the SDT request via MSG3 / MSGA. If MSG4 / MSGB (including the SDT indication) is not received, the UE can retransmit MSG3 / MSGA. For a CG-based scheme, the UE can retransmit the SDT request at a subsequent cycle point of the CG PUSCH resource before receiving the SDT indication.

[0067] Figure 16 A third example procedure for passing exception messages is shown. Figure 16 In box 1602, no response with an SDT indication was received. An SDT was initiated in box 1602, and in box 1604, a request was sent, but no response was received. The request was resent in box 1604 until the timer expired in box 1606, resulting in an SDT failure (1608). If the UE does not receive a response message before the timer expires, the UT considers an SDT failure to have occurred. Following the failure in box 1608, the UE can handle it by: 1) re-initiating the SDT procedure after the timer (configured by the network), or 2) initiating a traditional RRC recovery procedure, or 3) initiating an SDT procedure using RA resources (if the UE relies on CG resources).

[0068] Figure 17 A fourth example procedure for abnormal message passing is shown. SDT is initiated in box 1702. In box 1704, communication is abnormal because the base station gNB sent other messages before responding to the SDT request (with an SDT indication). When an SDT request is received from the UE, the network can respond with different messages depending on the current network and UE conditions. Message 1 / Message 2 / Message 3 can be RRC signaling, MAC CE, or DCI. In one example, the UE sends the SDT request via an RRC-based solution, and the network can then respond with an RRC message indicating that the UE has entered an idle, inactive, or connected state. In another example, the UE sends the SDT request via an RRC-free solution, and the network can then respond with a MAC CE indicating that the UE has entered an idle, inactive, or connected state. This may introduce a new MAC CE. In yet another example, the UE sends the SDT request via an RRC-free solution, and the network can then respond with a DCI message indicating that the UE has entered an idle, inactive, or connected state. This may introduce a new DCI or introduce new fields into traditional DCI.

[0069] Figure 18 The fifth example procedure for passing exception messages is shown. Figure 17 This indicates the SDT initiation phase, while Figure 18 This displays SDT processing stage 1802. Similar to... Figure 17 In response to data scheduling 1804, there may be an additional message 1806 from the base station gNB. This message 1806 may be a network message instructing the UE to enter an idle, inactive, or connected state based on the current network and UE conditions. Message 1 / Message 2 / Message 3 may be RRC signaling, MAC CE, or DCI.

[0070] Figure 19 An example of anchor relocation communication is shown. The anchor base station gNB can be referred to as the last serving gNB. The UE is in an inactive state. The UE sends an RRCresumeRequest to the gNB. The gNB obtains the UE context by requesting the last serving gNB (anchor gNB), and the last serving gNB responds by obtaining the UE context. The gNB provides an RRCresume message to the UE. The UE is in a connected state and sends an RRCresumeComplete message to the gNB. After the path switching request / response, the UE context is released.

[0071] For the aforementioned SDT process, when an SDT request is received at a different gNB (i.e., the current serving gNB is not the last serving gNB before entering the inactive state), the network can decide whether to relocate the anchor gNB or not. When the network receives an SDT request at different gNBs, there are several alternative options, including: 1) the serving gNB immediately performs anchor relocation; 2) the serving gNB does not perform anchor relocation and performs data forwarding; and 3) the serving gNB does not perform anchor relocation and first performs data forwarding, but then performs anchor relocation if a larger BSR (Browser Response Rate) greater than a threshold is received during a small data transmission.

[0072] Anchor point relocation can be triggered by an anchor node or a serving node. A serving node can include the node where the UE is camped (e.g., the gNB of the cell where the UE is camped), a node with an RRC connection to the UE (e.g., a gNB), or a node that receives RRC messages from the UE in the air interface. An anchor node can be the node where the UE's SRB1 PDCP resides, or the node where the UE's NG-C and / or NG-U connections reside or have terminated. An anchor node can be the node that stores the UE context, or the node from which user data packets are forwarded to the core network.

[0073] Different implementations exist depending on which node triggers anchor point relocation. Considering that the UE's cache state and radio conditions may change, the serving gNB can determine at any point during the SDT (Send-to-Destination) period to switch the UE from an inactive state to a connected state based on the UE's cache state or radio conditions. Therefore, the serving gNB can initiate anchor point relocation at any point, including during the SDT process.

[0074] In one embodiment, when an anchor node triggers anchor relocation, the anchor node: 1) sends a first message to the serving node to request anchor relocation; 2) receives a second message from the serving node including a container containing RRC messages (e.g., RRC recovery, RRC reconfiguration, or newly defined RRC messages); 3) performs encryption and / or integrity protection on the RRC messages included in the container; and 4) sends a third message to the serving node, including a container containing an SRB PDCP PDU. The first message requesting anchor relocation from the serving node may be an XnAP message. The first message requesting anchor relocation from the serving node may include the UE context, anchor relocation indication, transport address for data forwarding, reason for anchor relocation, and / or security information, which may be used for security key generation in the serving node and / or UE. The security information may include at least one of the following: key-NG-RAN-Star, Ncc, and / or nextHopChainingCount. The second message may be an RRC message including at least the following: keySetChangeIndicator and / or nextHopChainingCount. The SRB PDCP PDU in the third message can contain a security-protected RRC message.

[0075] In an alternative embodiment, for anchor point relocation triggered by the anchor node, the serving node may utilize the following procedure: In a first step, the serving node receives an anchor point relocation request from the anchor node. In a second step, the serving node sends a message to the anchor node, which includes a container containing an RRC message (e.g., an RRC recovery, RRC reconfiguration, or newly defined RRC message). In a third step, the serving node receives an SRB PDCP PDU from the anchor node and sends the SRB PDCP PDU to the UE.

[0076] In another embodiment, when anchor relocation is triggered by the serving node, the serving node: 1) receives security information from the anchor node that can be used to generate a security key in the serving node and / or the UE; 2) sends a message to the anchor node containing a container with an RRC message (e.g., an RRC recovery, RRC reconfiguration, or newly defined RRC message); 3) receives a message from the anchor node containing a container with an SRB PDCP PDU; and 4) sends an SRB PDCP PDU to the UE. In step 1), the security information may be included in a RetrieveUEContextResponse message or a separate message. In step 2), the anchor relocation indication may be included in a message sent from the serving node to the anchor node. In step 3), the RRC message may include at least the following information: 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 anchor relocation triggered by the serving node, the anchor node may utilize the following process: In step 1, the anchor node receives an anchor relocation request message from the serving node, which includes a container with an RRC message. In step 2, the anchor node performs encryption and / or integrity protection on the RRC message included in the RRC container. In step 3, the anchor node sends an encrypted 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. Prior to step 1, if no security information is available in the serving node, the following process may be used to request security information: 1) the serving node sends a first message to the anchor node to request anchor relocation (e.g., an anchor relocation indication may be included in the message); and 2) the serving node receives a second message from the anchor node including security information, which may be used to generate a security key used in the serving node and / or the UE.

[0078] Figure 20 Another example of anchor positioning communication is shown. Specifically, Figure 20 This illustrates the initialization of anchor relocation in New Radio (NR) Small Data Transmission (SDT). For an SDT with anchor relocation, data can be included in the first uplink (UL) message, such as... Figure 20As shown, the RRCresumRequest message includes a MAC PDU containing the data. The target gNB can act as the first buffer for the received data ("buffered Radio Link Control (RLC) Packet Data Unit (PDU) containing the data"), and then perform context acquisition before continuing to process the received UL data in the first UL message. The serving gNB (the new anchor gNB) sends an RRCresum message to the UE to end the SDT procedure. Figure 20 The options for subsequent data transmission (uplink and / or downlink) are shown. For anchor relocation, the serving gNB can become the new anchor gNB, perform the path switching procedure, and forward data packets to the CN after the path switching.

Claims

1. A method for wireless communication, comprising: Receive a request for small data transmission from a user equipment terminal, wherein the user equipment terminal is in an inactive state; In response to the request for small data transmission, a small data transmission indication is sent to the user equipment terminal, wherein the small data transmission indication includes downlink control information (DCI). as well as Process the small data transmission.

2. The method according to claim 1, further comprising: Small data transmission parameters are configured via RRCRelease with SuspendConfig, which configure small data transmission resources. When the user equipment terminal enters an idle state or a connected state, the small data transmission resources are released based on the small data transmission parameters.

3. A method for wireless communication, performed by a user equipment terminal, the method comprising: When the user equipment terminal is in an inactive state, a request for small data transmission is sent; In response to receiving a small data transmission indication, the small data transmission is processed, the small data transmission indication being in response to the request for small data transmission, wherein the small data transmission indication includes downlink control information (DCI); and In response to not receiving the small data transmission instruction, the request for small data transmission is resent.

4. The method according to claim 3, further comprising: When the user equipment terminal enters the connection state, the small data transmission resource is released based on the small data transmission parameters, wherein the small data transmission resource is configured by the small data transmission parameters, which are configured via RRCRelease with SuspendConfig.

5. The method according to claim 3, further comprising: When the user equipment terminal enters an idle state, the small data transmission resource is released based on the small data transmission parameters, wherein the small data transmission resource is configured by the small data transmission parameters, which are configured via RRCRelease with SuspendConfig.

6. The method according to claim 3, wherein, The user equipment terminal is configured with a normal uplink carrier and a supplementary uplink carrier, and the reference signal received power (RSRP) based on the downlink path loss reference is less than a first threshold. The user equipment terminal selects the supplementary uplink carrier.

7. A wireless communication device, comprising: Memory used to store computer-readable instructions; and A processor for reading the computer-readable instructions, wherein the processor is configured to: Receive a request for small data transmission from a user equipment terminal, wherein the user equipment terminal is in an inactive state; In response to the request for small data transmission, a small data transmission indication is sent to the user equipment terminal, wherein the small data transmission indication includes downlink control information (DCI); and Process the small data transmission.

8. The wireless communication device according to claim 7, wherein the processor is further configured to: Small data transfer parameters are configured via an RCRelease with SuspendConfig, wherein the small data transfer parameters configure small data transfer resources, wherein... When the user equipment terminal enters an idle state or a connected state, the small data transmission resources are released based on the small data transmission parameters.

9. A wireless communication device, comprising: Memory used to store computer-readable instructions; and A processor for reading the computer-readable instructions, wherein the processor is configured to: When the wireless communication device is inactive, it sends a request for small data transmission. In response to receiving a small data transmission indication, the small data transmission is processed, the small data transmission indication being in response to the request for small data transmission, wherein the small data transmission indication includes downlink control information (DCI); and In response to not receiving the small data transmission instruction, the request for small data transmission is resent.

10. The wireless communication device according to claim 9, wherein the processor is further configured to: When the wireless communication device enters the connection state, small data transmission resources are released based on small data transmission parameters, wherein, The small data transmission resource is configured by the small data transmission parameters, which are configured via an RCRelease with SuspendConfig.

11. The wireless communication device according to claim 9, wherein the processor is further configured to: When the wireless communication device enters an idle state, small data transmission resources are released based on small data transmission parameters, wherein, The small data transmission resource is configured by the small data transmission parameters, which are configured via an RCRelease with SuspendConfig.

12. The wireless communication device according to claim 9, wherein, The wireless communication device is configured with a normal uplink carrier and a supplementary uplink carrier, and the reference signal received power RSRP based on downlink path loss reference is less than a first threshold. The processor is also configured to select the supplementary uplink carrier.

13. A computer storage medium comprising computer-readable program medium code stored thereon, the code causing the processor to perform the method of any one of claims 1 to 6 when executed by a processor.

Images