RRC-based user data transmission in inactive state

Abstract

While in an inactive state, the User Equipment (UE) device transmits a message to the base station. The message indicates the UE device's intention to perform transmission and / or reception of user data with the network during the inactive state. The message may include a portion of the user data and / or a buffer status report. The UE device receives a response message that induces a state transition at the UE device. Different state transitions (e.g., to idle, inactive, legacy inactive, or connected) may be induced by different types of response messages (e.g., release, release with interrupt configuration, resume, or setup). One specific type of response message causes the UE to remain in an inactive state and enables subsequent transmission / reception of user data while inactive. The response message may implicitly (or explicitly) indicate that the forwarding of user data to the core network was successful.

Description

Technology Field

[0001] The present disclosure relates to the field of wireless communication, and more specifically, to mechanisms that enable user equipment (UE) devices to perform transmission and / or reception of user data (particularly small data parcels) while being maintained in an inactive state. Background Technology

[0002] A wireless UE device in an inactive state (e.g., RRC INACTIVE state) may not be able to transmit and / or receive user data without first transitioning to a connected state. The time required for this transition is not trivial. (RRC stands for Radio Resource Control.)

[0003] In some embodiments, a method for operating a user equipment (UE) device may include one or more of the following operations. While the UE device is in an inactive state, the UE device may transmit information to a network, wherein the information includes a radio resource control (RRC) message. The RRC message may include an indication of the UE device's intention to transmit and / or receive user data with the network while in the inactive state.

[0004] In some embodiments, the RRC message may be an RRC resumption request message, and the information may include at least a portion of user data; and / or a buffer status report.

[0005] In some embodiments, the RRC message may include a cause indicator field indicating the cause for which the RRC message is being transmitted. The cause indicator field may be set to a value indicating data transmission (or small data transmission) as the cause.

[0006] In some embodiments, information transmitted by the UE device may be a Medium Access Control Protocol Data Unit (MAC PDU) (or may be included therein).

[0007] In some embodiments, while in an inactive state, the UE device may receive a response message from the network. The response message may induce a state transition in the UE device. Different state transmissions may be induced by different types of response messages.

[0008] In some embodiments, the response message may be a release message and may induce a state transition to an idle state.

[0009] In some embodiments, the response message may be a release message having a suspension configuration and may induce a state transition to a legacy inactive state.

[0010] In some embodiments, the response message may be a resumption message and may induce a state transition to a connected state.

[0011] In some embodiments, the response message may be a setup message and may induce a state transition to a connected state.

[0012] In some embodiments, the response message may cause the UE device to remain in an inactive state and enter a subsequent user data transmission mode. In the subsequent user data transmission mode, the UE device may transmit and / or receive additional user data (to / from the base station) while remaining in an inactive state.

[0013] In some embodiments, the response message may implicitly indicate that the forwarding of user data to the core network was successful.

[0014] In some embodiments, the response message may explicitly indicate whether the forwarding of user data to the core network was successful.

[0015] In some embodiments, a non-transient memory medium may store program instructions. When executed by a processing circuit, the program instructions may cause the processing circuit to perform any of the aforementioned method embodiments.

[0016] In some embodiments, the user equipment (UE) device may include a wireless subsystem; a processing circuit coupled to the wireless subsystem; and a memory for storing program instructions. When executed by the processing circuit, the program instructions may cause the UE device to perform any of the aforementioned method embodiments.

[0017] In some embodiments, a method for operating a base station (BS) may include one or more of the following operations. While a user equipment (UE) device is inactive, the base station may receive information from the UE device, wherein the information includes a radio resource control (RRC) message. The RRC message may include an indication of the UE device's intention to transmit and / or receive user data with the network while inactive.

[0018] In some embodiments, the RRC message may be an RRC resumption request message. Additionally, the information may include at least a portion of user data; and / or a buffer status report.

[0019] In some embodiments, the RRC message may include a cause indicator field indicating the cause of the RRC message. The cause indicator field may be set to a value indicating data transmission (or small data transmission) as the cause.

[0020] In some embodiments, the message may be a Media Access Control Protocol Data Unit (MAC PDU) (or may be contained therein).

[0021] In some embodiments, the method may also include the step of transmitting a response message to the UE device while the UE device is in an inactive state. The response message may induce a state transition in the UE device. Different state transmissions may be induced by different types of response messages.

[0022] In some embodiments, the response message may be a release message and may induce a state transition to an idle state.

[0023] In some embodiments, the response message may be a release message having a suspension configuration and may induce a state transition to a legacy inactive state.

[0024] In some embodiments, the response message may be a resumption message and may induce a state transition to a connected state.

[0025] In some embodiments, the response message may be a setup message and may induce a state transition to a connected state.

[0026] In some embodiments, the response message may cause the UE device to remain in an inactive state and enter a subsequent user data transmission mode. While the UE device remains in an inactive state and in the subsequent user data transmission mode, the base station may transmit and / or receive additional user data to and from the UE device.

[0027] In some embodiments, the response message may implicitly indicate that the forwarding of user data to the core network was successful.

[0028] In some embodiments, the response message may explicitly indicate whether the forwarding of user data to the core network was successful.

[0029] In some embodiments, a non-transient memory medium may store program instructions. When executed by a processing circuit, the program instructions may cause the processing circuit to perform any of the aforementioned method embodiments.

[0030] In some embodiments, the base station may include a wireless subsystem; a processing circuit coupled to the wireless subsystem; and a memory for storing program instructions. When executed by the processing circuit, the program instructions may cause the base station to perform any of the aforementioned method embodiments. Brief explanation of the drawing

[0031] A better understanding of the gist of the invention can be obtained when the following detailed description of a preferred embodiment is considered in conjunction with the following drawings. FIGS. 1 and FIGS. 2 illustrate examples of wireless communication systems according to some embodiments. FIG. 3 illustrates an example of a base station communicating with a user equipment device according to some embodiments. FIG. 4 illustrates an example of a block diagram of a user equipment device according to some embodiments. FIG. 5 illustrates an example of a block diagram of a base station according to some embodiments. FIG. 6 illustrates an example of user equipment (600) according to some embodiments. FIG. 7 illustrates an example of a base station (700) according to some embodiments. The base station (700) can be used to communicate with the user equipment (600) of FIG. 6. FIG. 8 illustrates an example of a procedure for causing a transition of user equipment (UE) from an inactive state to a connected state according to some embodiments. FIGS. 9a through 9e illustrate five different behavioral patterns when user equipment in an INACTIVE state transmits a resumption request, according to some embodiments. Figure 10a illustrates the difficulties encountered when an INACTIVE UE needs to transmit user data to a network in a legacy manner. FIG. 10b illustrates an example of a solution to the problem shown in FIG. 10a according to some embodiments. FIG. 11 illustrates an example of a procedure that a user device may employ to initiate small data transmission according to some embodiments. FIG. 12 illustrates one possible structure for a protocol data unit (PDU) for initiating user data transmission and / or reception with a network according to some embodiments. FIGS. 13a through 13c illustrate three different ways of indicating the success or failure of network data forwarding when an RRCRelease message is used to cause a transition to an idle state, according to some embodiments. FIGS. 14a through 14c illustrate three different ways of indicating the success or failure of network data forwarding when an RRCRelease message having a interruption configuration according to some embodiments is used to cause a transition to a legacy inactive state. FIGS. 15a through 15c illustrate three different ways of indicating the success or failure of network data forwarding when an RRCResume message is used to cause a transition to a connection state, according to some embodiments. FIGS. 16a and 16b illustrate two different ways of implicitly indicating a failure of user data transmission when an RRCSetup message is used to cause a transition to a connection state, according to some embodiments. FIGS. 17a and 17b illustrate two different ways of implicitly indicating a failure of user data transmission when an RRCReject message is used to cause a transition to a legacy inactive state, according to some embodiments. FIGS. 18 to 22 illustrate various methods for enabling subsequent user data transmission and / or reception while the user equipment is maintained in an inactive state, according to some embodiments. FIG. 18 illustrates a procedure for transmitting a resumption message having an explicit status indication to a user device, according to some embodiments. FIG. 19 illustrates a procedure in which a resumption message having an explicit status indication and an explicit data forwarding success indication is transmitted to a user device according to some embodiments. FIG. 20 illustrates a procedure for transmitting a release message having a subsequent transmission configuration to a user device, according to some embodiments. FIG. 21 illustrates a procedure for transmitting a release message having interruption to a user device, including a subsequent transmission configuration and an explicit data forwarding success indication, according to some embodiments. FIG. 22 illustrates a procedure used to enable subsequent user data transmission to user equipment in an inactive state, according to some embodiments, for L1 and / or L2 messages. FIG. 23 illustrates a method for operating a UE device to enable the UE device to transmit and / or receive user data while in an inactive state (e.g., RRC inactive state). FIG. 24 illustrates a method for operating a base station to enable the base station to perform data transmission and / or reception with a UE device while the UE device is in an inactive state (e.g., RRC inactive state). While various modifications and alternative forms are permitted for the features described herein, specific embodiments of the invention are illustrated by way of example in the drawings and described in detail herein. However, it should be understood that the drawings and the detailed description therein are not intended to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives within the spirit and scope of the subject matter as defined by the appended claims. Specific details for implementing the invention

[0032] Abbreviations

[0033] The following abbreviations are used in this disclosure.

[0034] 3GPP: Third Generation Partnership Project

[0035] 3GPP2: Third Generation Partnership Project 2

[0036] 5G NR: 5 th Generation New Radio

[0037] BW: Bandwidth

[0038] BWP: Bandwidth Part

[0039] CRC: Cyclic Redundancy Check

[0040] CSI: Channel State Information

[0041] CSI-RS: CSI Reference Signal

[0042] DCI: Downlink Control Information

[0043] DL: Downlink

[0044] eNB (or eNodeB): Evolved Node B, i.e., a 3GPP LTE base station

[0045] gNB (or gNodeB): Next Generation NodeB, i.e., a 5G NR base station

[0046] GSM: Global System for Mobile Communications

[0047] HARQ: Hybrid ARQ

[0048] LTE: Long Term Evolution

[0049] LTE-A: LTE-Advanced

[0050] MAC: Media Access Control

[0051] MAC-CE: MAC Control Element

[0052] NR: New Radio

[0053] NR-DC: NR Dual Connectivity

[0054] NW: Network

[0055] PDCCH: Physical Downlink Control Channel

[0056] RAT: Radio Access Technology

[0057] RNTI: Radio Network Temporary Identifier

[0058] RRC: Radio Resource Control

[0059] RRM: Radio Resource Management

[0060] RS: Reference Signal

[0061] SR: Scheduling Request

[0062] SSB: Synchronization Signal Block

[0063] TCI: Transmission Configuration Indication

[0064] UE: User Equipment

[0065] UL: Uplink

[0066] UMTS: Universal Mobile Telecommunications System

[0067] Terms

[0068] The following is an explanation of the terms used in this disclosure:

[0069] memory media- Any of various types of memory devices or storage devices. The term “memory medium” is intended to include installation media, e.g., CD-ROMs, floppy disks, or tape devices; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash, magnetic media, e.g., hard drives, or optical storage; registers, or other similar types of memory elements, etc. The memory medium may also include other types of memory or combinations thereof. Additionally, the memory medium may be located in a first computer system where programs are executed, or in a different second computer system connected to the first computer system via a network such as the Internet. In the latter case, the second computer system may provide program instructions to the first computer for execution. The term “memory medium” may include two or more memory media residing in different locations, e.g., different computer systems connected via a network. A memory medium can store program instructions that can be executed by one or more processors (e.g., implemented as computer programs).

[0070] Carrier media - In addition to memory media as described above, physical transmission media such as buses and networks, and / or other physical transmission media that transmit signals such as electric, electromagnetic, or digital signals.

[0071] Programmable hardware elements- Includes various hardware devices comprising multiple programmable function blocks connected via programmable interconnects. Examples include Field Programmable Gate Arrays (FPGAs), Programmable Logic Devices (PLDs), Field Programmable Object Arrays (FPOAs), and Complex PLDs (CPLDs). The programmable function blocks can range from fine-grained (combinational logic or lookup tables) to coarse-grained (arithmetic logic units or processor cores). Programmable hardware elements may also be referred to as "reconfigurable logic".

[0072] computer system Any of the various types of computing or processing systems, including personal computer systems (PCs), mainframe computer systems, workstations, network appliances, internet appliances, personal digital assistants (PDAs), personal communication devices, smartphones, television systems, grid computing systems, or other devices or combinations of devices. Generally, the term "computer system" may be broadly defined to include any device (or combination of devices) having at least one processor that executes instructions from a memory medium.

[0073] User Equipment (UE) (or "UE Device")- Any of the various types of computer system devices that are mobile or portable and perform wireless communications. Examples of UE devices include mobile telephones or smartphones (e.g., iPhone™, Android™-based phones), portable gaming devices (e.g., Nintendo DS™, PlayStation Portable™, Gameboy Advance™, iPhone™), wearable devices (e.g., smartwatches, smart glasses), laptops, PDAs, portable internet devices, music players, data storage devices, or other handheld devices. Generally, the term “UE” or “UE device” may be broadly defined to include any electronic, computing, and / or communication device (or combination of devices) that is easily moved by a user and capable of wireless communication.

[0074] base station - The term "base station" encompasses the full range of its general meaning and, at a minimum, includes a wireless communication station installed at a fixed location and used to communicate as part of a wireless telephone system or a wireless system.

[0075] Processing Element - Refers to any of the various elements or combinations of elements. Processing elements include, for example, circuits such as Application Specific Integrated Circuits (ASICs), parts or circuits of individual processor cores, entire processor cores, individual processors, programmable hardware devices such as Field Programmable Gate Arrays (FPGAs), and / or larger parts of systems comprising multiple processors.

[0076] automatically- Refers to an action or operation being performed by a computer system (e.g., software executed by the computer system) or a device (e.g., circuits, programmable hardware elements, ASICs, etc.) without user input directly specifying or performing the action or operation. Therefore, the term "automatically" is contrasted with an operation that is performed or specified manually by the user, where the user provides input that directly performs the operation. While an automatic procedure may be initiated by input provided by the user, subsequent actions performed "automatically" are not specified by the user; that is, they are not performed "manually" by the user specifying each action to be performed. For example, filling out an electronic form by a user selecting each field and providing input that specifies information (e.g., typing information, selecting checkboxes, selecting wireless communication devices, etc.) constitutes filling out the form manually, even if the computer system is required to update the form in response to user actions. A form may be automatically filled out by a computer system, wherein the computer system (e.g., software running on the computer system) analyzes the fields of the form and fills them out without any user input specifying responses to the fields. As indicated above, the user may call for the automatic filling of the form but does not participate in the actual filling of the form (e.g., the user does not manually specify responses to the fields, but rather they are completed automatically). This specification provides various examples of actions that are automatically performed in response to actions taken by the user.

[0077] FIGS. 1 to 3: Communication system

[0078] FIGS. 1 and 2 illustrate exemplary (and simplified) wireless communication systems. It should be noted that the systems of FIGS. 1 and 2 are merely examples of certain possible systems, and various embodiments can be implemented in any various ways as desired.

[0079] The wireless communication system of FIG. 1 includes a base station (102A) that communicates with one or more user equipment (UE) devices (106A, 106B, etc. to 106N) via a transmission medium. Each of the user equipment devices may be referred to as "user equipment (UE)" in this specification. In the wireless communication system of FIG. 2, in addition to the base station (102A), the base station (102B) also communicates with the UE devices (106A, 106B, etc. to 106N) via a transmission medium (e.g., simultaneously or concurrently).

[0080] Base stations (102A, 102B) may be base transceiver stations (BTS) or cell sites and may include hardware that enables wireless communication with user devices (106A to 106N). Each base station (102) may also be equipped to communicate with a core network (100), which may be a core network of a cellular service provider (e.g., base station (102A) may be coupled to a core network (100A), while base station (102B) may be coupled to a core network (100B)). Each core network (100) may be coupled to one or more external networks (such as an external network (108)), which may include the Internet, a Public Switched Telephone Network (PSTN), or any other network. Thus, base station (102A) can facilitate communication between user devices and / or between user devices and the network (100A); In the system of FIG. 2, the base station (102B) can facilitate communication between user devices and / or between user devices and the network (100B).

[0081] Base stations (102A, 102B) and user devices may be configured to communicate through a transmission medium using any of the various radio access technologies (RATs) also referred to as wireless communication technologies or telecommunication standards, such as GSM, UMTS (WCDMA), LTE, LTE-A (LTE-Advanced), 3GPP2 CDMA2000 (e.g. 1xRTT, 1xEV-DO, HRPD, eHRPD), Wi-Fi, WiMAX, etc.

[0082] For example, the base station (102A) and the core network (100A) may operate according to a first cellular communication standard (e.g., LTE), while the base station (102B) and the core network (100B) operate according to a second (e.g., different) cellular communication standard (e.g., GSM, UMTS, and / or one or more CDMA2000 cellular communication standards). The two networks may be controlled by the same network operator (e.g., a cellular service provider or "carrier") or by different network operators. Additionally, the two networks may operate independently of each other (e.g., if the two networks operate according to different cellular communication standards), or may operate in a somewhat coupled or closely coupled manner.

[0083] Additionally, it should be noted that while two different networks may be used to support two different cellular communication technologies as exemplified in the network configuration illustrated in FIG. 2, other network configurations implementing multiple cellular communication technologies are also possible. For example, base stations (102A, 102B) may operate according to different cellular communication standards but may be coupled to the same core network. As another example, multi-mode base stations capable of simultaneously supporting different cellular communication technologies (e.g., LTE and CDMA 1xRTT, GSM, and UMTS, or any other combination of cellular communication technologies) may be coupled to a core network that also supports different cellular communication technologies. Any of the various other network deployment scenarios is also possible.

[0084] As an additional possibility, it is also possible for base station (102A) and base station (102B) to operate according to the same wireless communication technology (or an overlapping set of wireless communication technologies). For example, base station (102A) and core network (100A) may be operated by a single cellular service provider independently of base station (102B) and core network (100B), which may be operated by different (e.g., competing) cellular service providers. Thus, in this case, despite using similar and possibly compatible cellular communication technologies, UE devices (106A to 106N) may communicate independently of base stations (102A, 102B) by using distinct subscriber identities to communicate with networks of possibly different carriers.

[0085] The UE (106) may be capable of communicating using multiple wireless communication standards. For example, the UE (106) may be configured to communicate using either or both of a 3GPP cellular communication standard (such as LTE) or a 3GPP2 cellular communication standard (such as a cellular communication standard of the CDMA2000 family of cellular communication standards). As another example, the UE (106) may be configured to communicate using different 3GPP cellular communication standards (such as two or more of GSM, UMTS, LTE, or LTE-A). Accordingly, as mentioned above, the UE (106) may be configured to communicate with a base station (102A) (and / or other base stations) according to a first cellular communication standard (e.g., LTE), and may also be configured to communicate with a base station (102B) (and / or other base stations) according to a second cellular communication standard (e.g., one or more CDMA2000 cellular communication standards, UMTS, GSM, etc.).

[0086] Accordingly, base stations (102A, 102B) and other base stations operating according to the same or different cellular communication standards may be provided as one or more networks of cells, and these may provide continuous or nearly continuous overlapping services to UEs (106A to 106N) and similar devices over a wide geographical area through one or more cellular communication standards.

[0087] The UE (106) may also be configured to communicate using WLAN, Bluetooth, one or more GNSS (global navigational satellite systems, e.g., GPS or GLONASS), one and / or more mobile television broadcasting standards (e.g., ATSC-M / H or DVB-H), etc. Other combinations of wireless communication standards (including more than two wireless communication standards) are also possible.

[0088] FIG. 3 illustrates a user device (106) (e.g., one of the devices (106A to 106N)) communicating with a base station (102) (e.g., one of the base stations (102A or 102B)). The UE (106) may be a device having wireless network connectivity, such as a mobile phone, a handheld device, a computer or tablet, a wearable device, or virtually any type of wireless device.

[0089] The UE may include a processor configured to execute program instructions stored in memory. The UE may perform any of the method embodiments described herein by executing such stored instructions. Alternatively or additionally, the UE may include a programmable hardware element, such as an FPGA, configured to perform any of the method embodiments described herein, or any part of any of the method embodiments described herein.

[0090] The UE (106) may be configured to communicate using any of a number of wireless communication protocols. For example, the UE (106) may be configured to communicate using two or more of GSM, UMTS (W-CDMA, TD-SCDMA, etc.), CDMA2000 (1xRTT, 1xEV-DO, HRPD, eHRPD, etc.), LTE, LTE-A, WLAN, or GNSS. Other combinations of wireless communication standards are also possible.

[0091] The UE (106) may include one or more antennas for communicating using one or more wireless communication protocols. Within the UE (106), one or more parts of the receive and / or transmit chain may be shared among multiple wireless communication standards; for example, the UE (106) may be configured to communicate using either GSM or LTE (or both) using a single shared wireless device. To perform wireless communications, the shared wireless device may include a single antenna or multiple antennas (e.g., for MIMO or beamforming). MIMO is an acronym for Multiple Input Multiple Output.

[0092] Fig. 4 - Example of a block diagram of a UE

[0093] FIG. 4 illustrates an example of a block diagram of a UE (106). As illustrated, the UE (106) may include a system on chip (SOC) (300) that may include parts for various purposes. For example, as illustrated, the SOC (300) may include a processor(s) (302) capable of executing program instructions for the UE (106), and a display circuit (304) capable of performing graphics processing and providing display signals to a display (345). The processor(s) (302) may also be coupled to a memory management unit (MMU) (340) and / or other circuits or devices such as a display circuit (304), a wireless communication device (330), a connector I / F (320), and / or a display (345), which may be configured to receive addresses from the processor(s) (302) and translate these addresses into locations within memory (e.g., memory (306), read-only memory (ROM) (350), NAND flash memory (310)). The MMU (340) may be configured to perform memory protection and page table translation or setup. In some embodiments, the MMU (340) may be included as part of the processor(s) (302).

[0094] As described, the SOC (300) can be coupled to various other circuits of the UE (106). For example, the UE (106) may include various types of memory (e.g., flash memory (310)), a connector interface (320) (e.g. for coupling to a computer system, dock, charging station, etc.), a display (345), and a wireless communication device (330).

[0095] The wireless communication device (330) may include one or more RF chains. Each RF chain may include a transmitting chain, a receiving chain, or both. For example, the wireless communication device (330) may include two RF chains to support dual connectivity with two base stations (or two cells). The wireless communication device may be configured to support wireless communication according to one or more wireless communication standards, such as GSM, UMTS, LTE, LTE-A, WCDMA, CDMA2000, Bluetooth, Wi-Fi, GPS, etc.

[0096] A wireless communication device (330) is coupled to an antenna subsystem (335) comprising one or more antennas. For example, the antenna subsystem (335) may include multiple antennas to support applications such as dual connectivity, MIMO, or beamforming. The antenna subsystem (335) transmits and receives wireless signals to and from one or more base stations or devices through a wireless radio medium, typically an atmosphere.

[0097] In some embodiments, the processor(s) (302) may include a baseband processor for generating uplink baseband signals and / or processing downlink baseband signals. The processor(s) (302) may be configured to perform data processing according to one or more wireless telecommunications standards, such as GSM, UMTS, LTE, LTE-A, WCDMA, CDMA2000, Bluetooth, Wi-Fi, GPS, etc.

[0098] The UE (106) may also include one or more user interface elements. The user interface elements may include any of various elements, such as a display (345) (which may be a touchscreen display), a keyboard (which may be a separate keyboard or implemented as part of a touchscreen display), a mouse, a microphone and / or speakers, one or more cameras, one or more sensors, one or more buttons, sliders, and / or dials, and / or any of various other elements capable of providing information to the user and / or receiving / interpreting user input.

[0099] As illustrated, the UE (106) may also include one or more subscriber identification modules (SIMs) (360). Each of the one or more SIMs may be implemented as an embedded SIM (eSIM), in which case the SIM may be implemented in device hardware and / or software. For example, in some embodiments, the UE (106) may include an embedded Universal Integrated Circuit Card (eUICC), for example, a device built into the UE (106) and not removable. The eUICC may be programmable so that one or more eSIMs can be implemented on the eUICC. In other embodiments, the eSIM may be installed in the UE (106) software as program instructions stored on a memory medium (such as memory (306) or flash (310)) that are executed on a processor (such as processor (302)) within the UE (106). For example, the SIM (360) may be an application running on a universal integrated circuit card (UICC). Alternatively or additionally, one or more of the SIMs (360) may be implemented as removable SIM cards.

[0100] The processor (302) of the UE device (106) may be configured to implement some or all of the methods described herein by executing program instructions stored in a memory medium (e.g., a non-transient computer-readable memory medium). In other embodiments, the processor (302) may include a programmable hardware element such as an FPGA; or an ASIC; or a combination thereof.

[0101] Fig. 5 - Example of a base station

[0102] FIG. 5 illustrates a block diagram of a base station (102). Note that the base station of FIG. 5 is merely an example of a possible base station. As illustrated, the base station (102) may include processor(s) (404) capable of executing program instructions for the base station (102). The processor(s) (404) may also be coupled to a memory management unit (MMU) (440) or other circuits or devices that may be configured to receive addresses from the processor(s) (404) and convert these addresses into locations within memory (e.g., memory (460) and read-only memory (ROM) (450)).

[0103] The base station (102) may include at least one network port (470). As described in FIGS. 1 and FIGS. 2 above, the network port (470) may be coupled to a telephone network and configured to provide access to the telephone network (for a plurality of devices such as UE devices (106)).

[0104] The network port (470) (or additional network port) may also, or alternatively, be configured to be coupled to a cellular network, for example, a core network of a cellular service provider. The core network may provide mobility-related services and / or other services to multiple devices, such as UE devices (106). In some cases, the network port (470) may be coupled to a telephone network through the core network, and / or the core network may provide a telephone network (for example, between other UE devices serviced by a cellular service provider).

[0105] A base station (102) may include a wireless communication device (430) having one or more RF chains. Each RF chain may include a transmitting chain, a receiving chain, or both. (For example, the base station (102) may include at least one RF chain per sector or cell.) The wireless communication device (430) is coupled to an antenna subsystem (434) comprising one or more antennas. For example, multiple antennas may be required to support applications such as MIMO or beamforming. The antenna subsystem (434) transmits and receives wireless signals to and from UEs via a radio medium (typically the atmosphere).

[0106] In some embodiments, the processor(s) (404) may include a baseband processor for generating downlink baseband signals and / or processing uplink baseband signals. The baseband processor (430) may be configured to operate according to one or more wireless telecommunications standards, including but not limited to GSM, LTE, WCDMA, CDMA2000, etc.

[0107] The processor(s) (404) of the base station (102) may be configured to implement some or all of the methods described herein by executing program instructions stored, for example, in a memory medium (e.g., a non-transient computer-readable memory medium). In some embodiments, the processor(s) (404) may include a programmable hardware element such as an FPGA; or an ASIC; or a combination thereof.

[0108] In some embodiments, a wireless user equipment (UE) device (600) may be configured as illustrated in FIG. 6. The UE device (600) may include a wireless subsystem (605) for performing wireless communication; and a processing element (610) operably coupled to the wireless subsystem. (The UE device (600) may also include any subset of the UE features described above, for example in relation to FIGS. 1 through 4.)

[0109] The wireless subsystem (605) may include one or more RF chains, for example, as described above. Each RF chain may be configured to receive signals from a radio channel and / or transmit signals over a radio channel. Thus, each RF chain may include a transmitting chain and / or a receiving chain. The wireless subsystem (605) may be coupled to one or more antennas (or one or more antenna arrays) to facilitate signal transmission and reception. Each RF chain (or part of the RF chains) may be tuned to a desired frequency, thereby allowing the RF chain to receive or transmit at different frequencies at different times.

[0110] The processing element (610) can be coupled to the wireless subsystem and configured as described above. (For example, the processing element can be realized by the processor(s) (302).) The processing element can be configured to control the state of each RF chain in the wireless subsystem.

[0111] In some embodiments, the processing element may include one or more baseband processors for (a) generating baseband signals to be transmitted by the wireless subsystem and / or (b) processing baseband signals provided by the wireless subsystem.

[0112] In a dual-access operation mode, the processing element may instruct a first RF chain to communicate with a first base station using a first radio access technology and may instruct a second RF chain to communicate with a second base station using a second radio access technology. For example, the first RF chain may communicate with an LTE eNB, and the second RF chain may communicate with a 5G New Radio (NR) gNB. A link with an LTE eNB may be referred to as an LTE branch. A link with a gNB may be referred to as an NR branch. In some embodiments, the processing element may include a first subcircuit for baseband processing for an LTE branch and a second subcircuit for baseband processing for an NR branch.

[0113] The processing element (610) may be additionally configured as described in various sections below.

[0114] In some embodiments, a wireless base station (700) of a wireless network (not shown) may be configured as illustrated in FIG. 7. The wireless base station may include a wireless subsystem (705) for performing wireless communication over a wireless radio channel; and a processing element (710) operably coupled to the wireless subsystem. (The wireless base station may also include any subset of the base station features described above, for example, in relation to FIG. 5.)

[0115] The wireless subsystem (710) may include one or more RF chains. Each RF chain may be tuned to a desired frequency, thereby allowing the RF chain to receive or transmit at different frequencies at different times. The wireless subsystem (710) may be coupled to an antenna subsystem comprising one or more antennas, such as an array of antennas, or a plurality of antenna arrays. The wireless subsystem may utilize the antenna subsystem to transmit and receive wireless signals to and from a radio wave propagation medium.

[0116] The processing element (710) may be realized as described above in various ways. For example, in one embodiment, the processing element (710) may be realized by processor(s) (404). In some embodiments, the processing element may include one or more baseband processors for (a) generating baseband signals to be transmitted by the wireless subsystem and / or (b) processing baseband signals provided by the wireless subsystem.

[0117] The processing element (710) may be configured to perform any of the base station method embodiments described in this specification.

[0118] Wireless Resource Control (RRC) Inactive State

[0119] In some embodiments, the behavior of a User Equipment (UE) in the INACTIVE state can be described in terms of its behaviors in the control plane and the user plane. In the control plane, the INACTIVE UE has a network access stratum (NAS) connection to the core network and does not have any access stratum (AS) resources. Additionally, the UE may possess a radio resource control (RRC) configuration that it had before entering the INACTIVE state. In the user plane, the UE may not be able to perform any private data transmission / reception. If private data transmission / reception is required to be performed, the UE needs to enter the CONNECTED state. For DL ​​data transmission, the gNB may page the UE through a RAN paging mechanism to trigger the UE's transition to the CONNECTED state. (RAN is an abbreviation for radio access network.) For UL data transmission, the UE may trigger a random access (RACH) procedure to enter the CONNECTED state. In relation to mobility, the INACTIVE UE can move within the RAN notification area (RNA) without notifying the next-generation RAN (NG-RAN). Cell selection and reselection can be performed in the same manner as in the RRC IDLE state.

[0120] In some embodiments, the UE may perform different state transitions under different circumstances. For example, the gNB may cause the UE to transition from the CONNECTED state to the INACTIVE state using an RRC release containing interruption information. As another example, the gNB may cause the UE to transition from the INACTIVE state to the CONNECTED state as part of an RRC resumption procedure. As yet another example, the UE may transition from the INACTIVE state to the IDLE state either (1) in response to an RRC release or (2) when the UE cannot find a cell for camping.

[0121] UE transition from INACTIVE state to CONNECTED state

[0122] In some embodiments, the UE may transition from an INACTIVE state to a CONNECTED state as illustrated in FIG. 8. We begin the discussion of FIG. 8 where the UE is in the RRC-INACTIVE CM-CONNECTED state. (CM stands for Connection Management.) To initiate the transition to the connected state, the UE may send a resume request (e.g., RRCResumeRequest) to the current gNB. In response to receiving the resume request, the gNB may send a context lookup request (i.e., a request for the lookup of the UE context) to the last serving gNB. The UE context may include the UE access layer (AS) configuration and variable(s) of the previous connected state. The UE context may be used by the current gNB to determine the RRC configuration within the newly accessed serving cell. In response to receiving the context lookup request, the last serving gNB may send a context lookup response containing the requested UE context to the current gNB.

[0123] In response to receiving a context search response, the current gNB may send a resumption message (e.g., an RRCResume message) to the UE. In response to receiving the resumption message, the UE may transition to the RRC-CONNECTED or CM-CONNECTED state. In such a state, the UE may send a resumption completion message (e.g., an RRCResumeComplete message) to the current gNB. In response to receiving the resumption completion message, the current gNB may send a data forwarding address indication to the last serving gNB and send a route switch request to the Access & Mobility Management Function (AMF). In response to receiving the route switch request, the AMF may pass a response to the route switch request to the current gNB. In response to receiving this response, the current gNB may send a context release message to the last serving gNB, which indicates that the UE context may be released from the last serving gNB.

[0124] Behavioral patterns when the UE is in an inactive state

[0125] FIGS. 9a through 9e illustrate five different behavioral patterns when a UE in the INACTIVE state sends a resumption request (or attempts to resume a suspended RRC connection). In FIGS. 9a, 9c, and 9d, the attempt to resume can be interpreted as successful. FIG. 9b illustrates the case of a resumption with a fallback for setup. In FIG. 9e, the attempt to resume is rejected by the network.

[0126] FIG. 9a illustrates a procedure for a UE to transition from an INACTIVE state to a CONNECTED state according to some embodiments. This procedure may be followed when the network can fetch the UE context. From the INACTIVE state, the UE may initiate an attempt to resume a suspended RRC connection by sending a resumption request (e.g., RRCResumeRequest or RRCResumeRequest1 as defined in 3GPP TS 38.331, Release 15). In response to receiving the resumption request, the network may respond to the UE with a resumption message (e.g., an RRCResume message). In response to receiving the resumption message, the UE transitions to a CONNECTED state; and may send a resumption completion message (e.g., an RRCResumeComplete message) to the network indicating that the process of resuming the connection is complete.

[0127] FIG. 9b illustrates a procedure for a UE to transition from an INACTIVE state to a CONNECTED state according to some embodiments. This procedure may be followed when the network is unable to fetch the UE context. From the INACTIVE state, the UE may initiate an attempt to resume the interrupted RRC connection by sending a resumption request. In response to receiving the resumption request, the network may respond to the UE with a connection setup message (e.g., an RRCSetup message). In response to receiving the connection setup message, the UE transitions to the CONNECTED state; and may send a setup completion message (e.g., an RRCSetupComplete message) to the network indicating that the process of setting up the connection is complete.

[0128] FIG. 9c illustrates a procedure for a UE to transition from an INACTIVE state to an IDLE state according to some embodiments. This procedure may be followed when the network can fetch the UE context. From the INACTIVE state, the UE may initiate an attempt to resume the interrupted RRC connection by sending a resumption request. In response to receiving the resumption request, the network may respond to the UE with a release message (e.g., an RRCRelease message). In response to receiving the release message, the UE may transition to the IDLE state.

[0129] FIG. 9d illustrates a procedure for a UE to perform a null transition from an INACTIVE state to an INACTIVE state according to some embodiments. This procedure may be followed when the network can fetch the UE context. From the INACTIVE state, the UE may initiate an attempt to resume the interrupted RRC connection by sending a resumption request. In response to receiving the resumption request, the network may respond to the UE by sending a release message (e.g., an RRCR release message) having a interrupt configuration. In response to receiving the release message having an interrupt configuration, the UE may remain in the INACTIVE state.

[0130] FIG. 9e illustrates a procedure for a UE to perform a null transition from the INACTIVE state to the INACTIVE state. This procedure may be followed when the network is unable to fetch the UE context. From the INACTIVE state, the UE may initiate an attempt to resume the interrupted RRC connection by sending a resumption request. In response to receiving the resumption request, the network may respond to the UE by sending a rejection message (e.g., an RRCReject message). In response to receiving the rejection message, the UE may remain in the INACTIVE state.

[0131] FIG. 10a illustrates the difficulties encountered when an INACTIVE UE needs to perform user data transmission to the network in a legacy manner. While in the INACTIVE state, UE detection data is available for uplink transmission. For example, the UE may detect the arrival of data in the uplink transmission buffer. In response to the arrival of data, the UE may trigger an RRC resumption procedure. The resumption procedure may result in the UE transitioning to the CONNECTED state, the IDLE state, or the INACTIVE state. During the RRC resumption procedure, no user data transmission is permitted. As illustrated in FIG. 10a, if the resumption procedure concludes with a successful transition to the CONNECTED state, the UE may perform uplink data transmission to service pending uplink data. The time delay between the data arrival event and the uplink transmission may not be trivial. Unfortunately, the UE needs to wait for the resumption procedure to complete before transmitting, especially when the amount of data to be transmitted is small.

[0132] FIG. 10b illustrates a solution to the aforementioned difficulties according to some embodiments. A network and a UE may be provided with a mechanism that enables the UE to perform user data transmission(s)—uplink and / or downlink—during an RRC resumption procedure while the UE remains in an inactive state.

[0133] In some embodiments, the UE and the network may support mechanisms that enable the UE to perform small data transmission(s) while in the inactive state. While in the inactive state, the UE may perform small data transmissions, for example, using one or more messages of a random access procedure. A base station (e.g., a gNB in ​​3GPP NR) may fetch the UE context and forward the UE's user data to the core network, for example, using anchor relocation or without using it.

[0134] In some embodiments, the INACTIVE UE may transmit uplink user data over pre-configured PUSCH resources. (PUSCH is an abbreviation for a physical uplink shared channel.)

[0135] RRC-based small data transmission in INACTIVE state

[0136] In some embodiments, the network (NW) may configure the UE to support a Small Data Transmission (SDT) procedure in the INACTIVE state. The UE may initiate the SDT procedure by transmitting, for example, a release message having a suspended configuration (e.g., RRCRelease with SuspendConfig). The suspended configuration may be interpreted as a configuration to be used by the UE for transmission during the INACTIVE state. The serving cell (or base station) may or may not support SDT features. The serving cell (or base station) may indicate that it supports SDT features, for example, through a broadcast message. The UE may decode the broadcast message to determine that the serving cell (or base station) supports SDT features. Alternatively, the UE may determine that the serving cell (or base station) supports SDT features based on a prior dedicated configuration. (In the dedicated configuration approach, the network can set the UE to an INACTIVE state by pre-transmitting an RRCRelease with a suspension configuration. In this message, the network can enable SDT features and indicate a list of applicable cells.)

[0137] In some embodiments, the UE may trigger an SDT procedure in response to one or more conditions (e.g., configurable conditions) being satisfied. The action that triggers the SDT procedure may include performing an uplink transmission that includes a resumption request message (e.g., an RRCResumeRequest message). The resumption request message may include: a UE identity in the INACTIVE state (e.g., I-RNTI); a UE Media Access Control identity (MAC-I for security checks); and an indication of the cause of access. (RNTI is an abbreviation for Radio Network Temporary Identifier). The resumption request message may include an indication of the cause for which the UE is making the request. The indication of the cause may be set to an SDT state, i.e., a state indicating that a small data transmission is requested.

[0138] In some embodiments, in response to receiving a resumption request message having the same cause as the SDT, the network may perform access control, security checks, and UE identification in a legacy manner and send a response message to the UE. The network may set the UE state to one of the following based on the type of response message it sends to the UE: (1) CONNECTED; (2) INACTIVE; (3) IDLE; (4) INACTIVE with subsequent transmission. Legacy response messages may be used to set the UE state to any of states (1), (2), and (3). However, for state (4), a new type of RRC response message and procedure may be required.

[0139] UE actions to trigger SDT procedures

[0140] As illustrated in FIG. 11, upon arrival of UL data, the UE may first evaluate whether to trigger an SDT procedure or a legacy resumption procedure. The UE may trigger an SDT procedure when one or more conditions (e.g., network configurable conditions) are met. The conditions may include one or more of the following: According to the first condition, the UE may determine whether the associated Local Channel (LCH) or Data Radio Bearer (DRB) is configured for SDT operation. According to the second condition, the UE may determine whether the amount of available data is less than a configured threshold. According to the third condition, the UE may determine whether the radio signal quality exceeds a quality threshold. If one or more desired (or configured) conditions are not met, the UE may trigger a legacy resumption procedure. However, if the UE is configured with SDT features and one or more desired (or configured) conditions are met, the UE may trigger an SDT procedure by generating a resumption message (e.g., an RRC resumption message) and set the resumption cause = SDT. The UE can select an SDT resource (PRACH, a pre-configured PUSCH) for transmission and assemble a MAC PDU according to the transmission block size (TBSize). (MAC PDU is an abbreviation for Medium Access Control - Protocol Data Unit.) If the selected resource is not large enough to accommodate all user data to be transmitted, the UE may include at least an RRC message within the MAC PDU and additionally include some of the user data and / or a buffer status report (BSR).

[0141] Network behavior upon receiving the first UL message

[0142] In some embodiments, when receiving an RRCResumeRequest having a cause value = SDT, the network (NW) may determine from the cause value that initial access is triggered by a request from the UE to perform a small data transmission (SDT). The network (e.g., a base station such as a gNB) may decide to transmit a response to the UE based on any of the following cases. Different types of responses may cause different results in the UE.

[0143] Case 1: The network can send RRCRelease to instruct the UE to transition to the IDLE state.

[0144] Case 2: The network can send an RRCRelease with a suspension configuration to instruct the UE to transition to a legacy INACTIVE state.

[0145] Case 3: The network can send RRCResume to instruct the UE to transition to the CONNECTED state.

[0146] Case 4: The network can send an RRCSetup message to instruct the UE to transition from the IDLE state to the CONNECTED state.

[0147] Case 5: The network can send an RRCReject message to instruct the UE to remain in the legacy INACTIVE state.

[0148] Case 6: The network may send a new type of response message to instruct the UE to transition to an INACTIVE state with subsequent data transmission.

[0149] In some embodiments, the network may indicate to the UE whether the portion of user data transmitted with the RRCResumeRequest was successfully handled by the NW or not. Such indication may be provided in the following ways. In the first option, the NW may explicitly indicate the result of data processing (SUCCESS or FAILURE) in the response message. In the second option, the success or failure result may be implicitly indicated by the transmission or non-transmission of a special RRC response message. (Transmission of a special RRC response message may indicate success.)

[0150] As illustrated in FIG. 12, a Media Access Control Protocol Data Unit (MAC PDU) (1210) may include one or more sub-PDUs. Each sub-PDU may include a corresponding header (MAC-H) and a corresponding payload. A first sub-PDU may include a header having a logical channel number (LCH) equal to 0, and a payload containing an RRC resumption request. A second sub-PDU may include a header having a logical channel number X different from 0, for example, and a payload containing user data (or a portion of user data).

[0151] Upon receiving an acknowledgment message, the UE may operate on the data portion as follows. When the acknowledgment indicates success, the UE may regard the transmission of the acknowledgment as a Wireless Link Control Acknowledgment (RLC ACK) and discard the data portion. When the acknowledgment indicates failure, different options exist for handling the data portion.

[0152] In the first option, the UE may regard the failure as an RLC NACK (negative acknowledgment) and wait for the next time to retransmit an RLC protocol data unit (PDU).

[0153] In the second option, the UE may discard the RLC PDU and wait for the next time to retransmit the PDCP PDU. (PDCP is an acronym for Packet Data Convergence Protocol.)

[0154] In the third option, the UE may discard the RLC PDU and PDCP PDU and wait for the next time to retransmit the PDCP SDU. (SDU is an abbreviation for Service Data Unit.)

[0155] Case 1: Induce transition to IDLE state using RRCRelease

[0156] FIGS. 13a through 13c relate to case 1 (wherein the RRCRelease message is used to cause the UE to enter an IDLE state) and illustrate three different ways for the network to indicate to the UE the success or failure of handling user data according to some embodiments.

[0157] As illustrated in FIG. 13a, after the current base station (e.g., a gNB in ​​3GPP NR) receives an RRCResume along with user data, the current base station may send a context fetch and a data forwarding request (including user data) to the last serving base station. The context fetch indicates a request for the last serving base station to provide the UE context. In response, the last serving base station may attempt to forward the user data to the core network (CN). Assuming the UE context is available and the forwarding attempt is successful, the last serving base station may send the requested UE context and an indication of successful data forwarding to the current base station. In response to receiving the UE context and the indication of successful data forwarding, the current base station may then decide to release the UE by sending a release message (e.g., an RRCRelease message) to the UE that includes an explicit indication of successful data forwarding, and in this case, the UE may transition to an IDLE state.

[0158] Alternatively, as illustrated in FIG. 13b, when the last serving base station receives a context fetch and data forwarding request, the last serving base station may decide not to forward user data to the core network (or decide that an attempt to forward user data to the core network has failed). In such a case, the last serving base station may transmit the UE context and an indication of data forwarding failure to the current base station. In response, the current base station may decide to release the UE, for example, by sending an RRCRelease message to the UE containing an explicit indication of data forwarding failure. In response to receiving an RRCRelease message containing an explicit indication of data forwarding failure, the UE may consider the transmission of its user data to have failed and transition to an IDLE state.

[0159] FIG. 13c illustrates an embodiment in which the success of data forwarding may be implicitly indicated by the action of the current base station transmitting an RRCRelease message. In response to receiving the RRCRelease message, the UE may consider the transmission of its user data to be successful and transition to an IDLE state. If the UE does not receive the RRCRelease message within a predetermined time, the UE may assume that the transmission of its user data has failed.

[0160] Case 2: Induce transition to legacy INACTIVE state using RRCRelease with a suspension configuration

[0161] FIGS. 14a through 14c relate to case 2 (wherein an RRCRelease message having a suspension configuration is used to cause the UE to enter a legacy INACTIVE state) and illustrate three different ways for the network to indicate to the UE the success or failure of handling user data according to some embodiments. In some embodiments, the legacy INACTIVE state may be interpreted as an INACTIVE state in which user data transmission is not permitted, such as the INACTIVE state defined by existing 3GPP 5GNR specifications.

[0162] As illustrated in FIG. 14a, the last serving base station may transmit the UE context and an indication of successful data forwarding to the current base station. In response, the current base station may transmit an RRCRelease message with a break configuration and an explicit indication of successful data forwarding to the UE. In response to receiving the RRCRelease message with a break configuration and the explicit indication of successful data forwarding, the UE may consider the transmission of its user data to be successful and transition to the legacy INACTIVE state.

[0163] Alternatively, as illustrated in FIG. 14b, when the last serving base station receives a context fetch and a data forwarding request (including user data to be forwarded to the core network), the last serving base station may decide not to forward the user data to the core network (or decide that the attempt to forward the user data to the core network has failed). In such a case, the last serving base station may transmit the UE context and an indication of data forwarding failure to the current base station. In response, the current base station may decide to release the UE by transmitting an RRCRelease message with a suspension configuration and an explicit indication of data forwarding failure. In response to receiving an RRCRelease message with a suspension configuration and an explicit indication of data forwarding failure, the UE may consider the transmission of its user data to be successful and transition to the legacy INACTIVE state.

[0164] FIG. 14c illustrates an embodiment in which the success of data forwarding may be implicitly indicated by the action of the current base station transmitting an RRCRelease message having a interruption configuration. In response to receiving an RRCRelease message having an interruption configuration, the UE may consider the transmission of its user data to be successful and transition to a legacy INACTIVE state. If the UE does not receive an RRCRelease message having an interruption configuration within a predetermined time, the UE may consider the transmission of its user data to be a failure.

[0165] Case 3: Induce a transition to the CONNECTED state using the RRCResume message.

[0166] FIGS. 15a through 15c relate to case 3 (wherein the RRCResume message is used to cause the UE to enter the CONNECTED state) and illustrate three different ways for the network to indicate to the UE the success or failure of handling user data according to some embodiments.

[0167] As illustrated in FIG. 15a, after the current base station (e.g., a gNB in ​​3GPP NR) receives an RRCResume message along with user data, the current base station may send a context fetch and a data forwarding request (including user data) to the last serving base station. The context fetch represents a request to the last serving base station to provide UE context. In response, the last serving base station may attempt to forward the user data to the core network (CN). Assuming the UE context is available and the forwarding attempt is successful, the last serving base station may send the requested UE context and an indication of successful data forwarding to the current base station. In response to receiving the UE context and the indication of successful data forwarding, the current base station may then decide to release the UE by sending an RRCResume message to the UE containing an explicit indication of successful data forwarding. In response to receiving an RRCResume message containing an explicit indication of successful data forwarding, the UE considers the transmission of its user data to be successful and can transition to the CONNECTED state.

[0168] Alternatively, as illustrated in FIG. 15b, when the last serving base station receives a context fetch and data forwarding request, the last serving base station may decide not to forward user data to the core network (or decide that an attempt to forward user data to the core network has failed). In such a case, the last serving base station may transmit the UE context and an indication of data forwarding failure to the current base station. In response to receiving the UE context and the indication of data forwarding failure, the current base station may decide to perform a UE transition to the CONNECTED state, for example, by sending an RRCResume message to the UE containing an explicit indication of data forwarding failure. In response to receiving an RRCResume message containing an explicit indication of data forwarding failure, the UE may consider the transmission of its user data to have failed and transition to the CONNECTED state.

[0169] FIG. 15c illustrates an embodiment in which the success of data forwarding may be implicitly indicated by the action of the current base station transmitting an RRCResume message. In response to receiving an RRCRelease message, the UE may consider the transmission of its user data to be successful and transition to the CONNECTED state. If the UE does not receive an RRCRelease within a predetermined time, the UE may consider the transmission of its user data to be a failure.

[0170] Case 4: Induce transition to CONNECTED state using RRCSetup

[0171] FIGS. 16a and FIGS. 16b relate to case 4, where the RRCSetup message is used to implicitly indicate a failure of the UE's user data transmission and to cause the UE to enter the CONNECTED state.

[0172] As illustrated in FIG. 16a, when the last serving base station receives a context fetch and data forwarding request (including user data), the last serving base station may determine that it cannot (or will not) provide the UE context and may respond by sending an indication to the current base station that the request for the UE context has failed. In response to receiving an indication of a context fetch failure, the current base station may determine that the UE should transition to the CONNECTED state. The UE may trigger this transition by sending a setup message (e.g., an RRCSetup message) to the UE. The RRCSetup message implicitly indicates to the UE that the transmission of its user data has failed. In response to receiving the RRCSetup message, the UE may consider the transmission of user data to have failed and transition to the CONNECTED state.

[0173] As illustrated in FIG. 16b, in response to receiving a resumption request (e.g., RRCResumeReq) along with user data, the current base station may decide to transition the UE to the CONNECTED state without any attempt, for example, to fetch the UE context or to forward the user data to the last serving base station or core network. The current base station may implicitly indicate the failure of the UE's user data transmission by sending a setup message (e.g., RRCSetup message) to the UE. In response to receiving the setup message, the UE may consider its user data transmission to have failed and transition to the CONNECTED state.

[0174] Case 5: Allow the UE to remain in the legacy inactive state using RRCReject

[0175] FIGS. 17a and FIGS. 17b relate to case 5, where the RRCReject message is used to implicitly indicate the failure of the UE's user data transmission and to keep the UE in a legacy INACTIVE state.

[0176] As illustrated in FIG. 17a, when the last serving base station receives a context fetch and data forwarding request (including user data), the last serving base station may respond by: determining that it cannot (or will not) fetch the UE context; determining not to forward the user data to the core network (or determining that an attempt to forward the user data to the core network has failed); and sending an indication to the current base station that the request for the UE context has failed. In response to receiving an indication of a context fetch failure, the current base station may determine that the UE's request to resume the connection should be rejected, for example, due to congestion. Accordingly, the UE may be caused to transition to the legacy INACTIVE state by sending an RRCReject message to the UE. The RRCReject message implicitly indicates to the UE that the transmission of its user data has failed. In response to receiving the RRCReject message, the UE may consider its user data transmission to have failed and transition to the legacy INACTIVE state.

[0177] As illustrated in FIG. 17b, in response to receiving a resumption request (e.g., RRCResumeReq) along with user data, the current base station may decide to transition the UE to a legacy INACTIVE state without making any attempt, for example, to fetch the UE context or to forward the user data to the last serving base station or core network. In this case, the current base station may implicitly indicate the failure of the UE's user data transmission by sending a rejection message (e.g., RRCReject message) to the UE. In response to receiving the rejection message, the UE may consider its user data transmission a failure and transition to a legacy INACTIVE state.

[0178] Case 6: Network control of subsequent data transmission

[0179] In some embodiments, upon receiving a first UL transmission from an INACTIVE UE, the network may decide to keep the UE in an INACTIVE state and enable subsequent data transmission through dedicated scheduling / transmission. The network may trigger the UE to enter a subsequent data transmission mode, for example, via an L2 or L3 command.

[0180] In the first option, the current base station may transmit an RRCResume message having an explicit status indication (status = INACTIVE). FIG. 18 illustrates an embodiment of this first option. In response to receiving a MAC PDU containing a resumption request and a user data portion, the current base station may decide to have the UE remain in the INACTIVE state and transition to a subsequent data transmission mode. In response to making this decision, the current base station may transmit an RRCResume message having an explicit indication of the INACTIVE state. Configuration for subsequent transmission may be provided in the RRCResume message. The RRCResume message may implicitly indicate to the UE that user data has been successfully forwarded to the core network. In response to receiving an RRCResume message having an explicit indication, the UE may consider the user data transmission successful and enter a subsequent transmission mode. In the subsequent transmission mode, the UE may perform subsequent user data transmission while remaining in the INACTIVE state. For example, the UE sends an RRCResume completion message to the current base station; and then may engage in subsequent user data transmission and / or reception using a dedicated configuration. After subsequent user data transmission and / or reception is completed, the current base station may send an RRCRlease message with a suspension configuration.

[0181] Similar to Option 1, in Option 1B, the current base station may transmit an RRCResume message having an explicit indication of the INACTIVE state as the state in which the UE is maintained. However, in Option 1B, the RRCResume message may also include an explicit indication of whether user data has been successfully forwarded to the core network, for example, as illustrated in FIG. 19. In response to receiving the RRCResume message, the UE may determine whether its user data transmission was successful based on the explicit indication. If the user data transmission was successful, the UE may clear the corresponding user data from its buffer and proceed to transmit the next portion of user data while in the INACTIVE state. If the user data transmission was unsuccessful, the UE may attempt to retransmit the user data.

[0182] In the second option, the current base station may transmit an RRCRelease message having a subsequent transmit configuration. FIG. 20 illustrates one embodiment of this second option. In response to receiving a MAC PDU containing a resume request and a user data portion, the current base station may decide to have the UE remain in an INACTIVE state and transition to a subsequent data transmit mode. In response to making this decision, the current base station may transmit an RRCRelease message having a interruption containing (or indicating) a subsequent transmit configuration. In response to receiving an RRCRelease message having an interruption and a subsequent transmit configuration, the UE may remain in an INACTIVE state and enter a subsequent transmit mode. In the subsequent transmit mode, the UE may perform subsequent user data transmit / receive while remaining in an INACTIVE state. For example, the UE may transmit a MAC CE / L1 ACK to the current base station; and then engage in subsequent user data transmit and / or receive using a dedicated configuration (e.g., the dedicated configuration provided in the RRCRelease message). After subsequent user data transmission and / or reception is completed, the current base station may transmit an RRCRelease message having interruption for subsequent transmission configuration.

[0183] Similar to the second option above, in option 2B, the current base station may transmit an RRCRelease message containing a subsequent transmit configuration. However, in option 2B, the RRCRelease may also include an explicit indication of whether user data has been successfully forwarded to the core network or not, for example, as illustrated in FIG. 21. In response to receiving the RRCRelease message, the UE may determine whether its user data transmission was successful based on the explicit indication. If the user data transmission was successful, the UE may clear the corresponding user data from its buffer and proceed to transmit the next portion of user data while in the INACTIVE state. If the user data transmission was unsuccessful, the UE may attempt to retransmit the user data.

[0184] In the third option, the current base station may employ L1 / L2 commands. FIG. 22 illustrates an embodiment of this third option. In response to receiving a message (2210) (e.g., MAC PDU) containing a resumption request and a user data portion, the current base station may decide to have the UE remain in an INACTIVE state and transition to a subsequent data transmission mode. (The message (2210) may be, for example, MSG3 of a random access procedure.) In response to making this decision, the current base station may transmit a message (2220) (e.g., L1 and / or L2 message) to enable subsequent user data transmission. (The message (2220) may be, for example, MSG4 of a random access procedure.) The message (2220) may include a CR MAC CE and an indication that the UE must enter a subsequent transmission mode while remaining in an INACTIVE state. (CR is an abbreviation for Contention Resolution.) In response to receiving a message (2220), the UE enters a subsequent transmit mode and can perform subsequent user data transmit and / or receive using a subsequent transmit configuration provided in the previous access mode or via broadcast(s) from the network (e.g., from the current base station). In response to receiving an L1 acknowledgment or UE uplink data via the configuration from the UE, the network may consider the transmit successful.

[0185] FIG. 23 - Method for operating a User Equipment (UE) device

[0186] In one set of embodiments, a method (2300) for operating a user equipment (UE) device may include the operations illustrated in FIG. 23. (The method (2300) may also include any subset of the aforementioned features, elements, or operations). The method (2300) may be performed by a processing circuit of the UE device, for example by a processing element (610) of the user equipment (600).

[0187] As illustrated in 2310, while the UE device is in an inactive state, the processing circuit may transmit information to the network, wherein the information includes a radio resource control (RRC) message. The RRC message may include an indication of the UE device's intention to transmit and / or receive user data with the network while in an inactive state. The action of transmitting information to the network may include transmitting the information to the network's current base station, for example, to the current gNB in ​​the context of 3GPP 5GNR.

[0188] In some embodiments, the RRC message may be an RRC resumption request message. Additionally, the information transmitted in 2310 may include at least a portion of user data; and / or a buffer status report. (The buffer status report may indicate the amount of data currently present in the uplink transmit buffer.) For example, if the amount of user data to be transmitted exceeds a threshold, a buffer status report may be included.

[0189] In some embodiments, the information (or RRC message) transmitted from 2310 may include identity information that enables the network to identify the UE device and / or fetch context information associated with the UE device, for example, as described above.

[0190] In some embodiments, the RRC message may include a cause indicator field indicating the cause for which the RRC message is being transmitted. The cause indicator field may be set to a value indicating data transmission (or small data transmission) as the cause.

[0191] In some embodiments, the information transmitted in 2310 is a Media Access Control Protocol Data Unit (MAC PDU) (or is part thereof), for example, as described in various ways. A MAC PDU may include one or more sub-PDUs. One of the sub-PDUs of the MAC PDU (e.g., a first sub-PDU of the sub-PDUs) may include an RRC message. Another sub-PDU of the sub-PDUs (e.g., a second sub-PDU of the sub-PDUs) may include at least a portion of the user data.

[0192] In some embodiments, the method (2300) may also include the step of receiving a response message from a network while in an inactive state, and the response message induces a state transition in the UE device.

[0193] In some embodiments, the response message may be a release message (e.g., an RRCR release message) and may induce a state transition to an idle state.

[0194] In some embodiments, the response message may be a release message having a suspension configuration and may induce a state transition to a legacy inactive state.

[0195] In some embodiments, the response message may be a resumption message and may induce a state transition to a connected state.

[0196] In some embodiments, the response message may be a setup message and may induce a state transition to a connected state.

[0197] In some embodiments, the response message may cause the UE device to remain in an inactive state and enter a subsequent user data transmission mode. In the subsequent user data transmission mode, the UE device may transmit and / or receive additional user data (or additional user data of a portion of the user data mentioned in 2310) while remaining in an inactive state, for example, as described in the context of FIGS. 18 to 22.

[0198] In some embodiments, the response message may implicitly indicate that the forwarding of user data to the core network was successful.

[0199] In some embodiments, the response message may explicitly indicate whether the forwarding of user data to the core network was successful.

[0200] In some embodiments, the non-transient memory medium may store program instructions. When executed by the processing circuit, the program instructions may cause the processing circuit to perform the methods of the aforementioned embodiments and any combination of such embodiments. The memory medium may be integrated as part of a user equipment device.

[0201] Fig. 24 - Method for operating a base station

[0202] In one set of embodiments, a method (2400) for operating a base station (BS) may include the operations shown in FIG. 24 (the method (2400) may also include any subset of the aforementioned features, elements or operations). The method may be performed by a processing circuit of the base station, for example by a processing element (710) of the base station (700).

[0203] As illustrated in 2410, while the User Equipment (UE) device is inactive, the processing circuit may receive information from the UE device, wherein the information includes a Radio Resource Control (RRC) message. The RRC message may include an indication of the UE device's intention to transmit and / or receive user data with the network during the inactive state. (For example, user data may originate from the UE device, such as from an application running on the UE device. Alternatively, user data may originate from the network and may be received by the UE device.)

[0204] In some embodiments, the RRC message may be an RRC resumption request message. Additionally, the information received at 2410 may include at least a portion of user data; and / or a buffer status report. (The buffer status report may indicate the amount of data currently present in the uplink transmit buffer of the UE device.) For example, a buffer status report may be included if the amount of user data to be transmitted by the UE device exceeds a threshold value.

[0205] In some embodiments, the information (or RRC message) received at 2410 may include identity information that enables the network to identify the UE device and / or fetch context information associated with the UE device, for example, as described above. The base station may utilize the identity information to request, for example, a fetch of the UE context from the last serving base station.

[0206] In some embodiments, the RRC message may include a cause indicator field indicating the cause of the RRC message. The cause indicator field is set to a value indicating data transmission (or small data transmission) as the cause.

[0207] In some embodiments, the message is a Media Access Control Protocol Data Unit (MAC PDU) (or is contained therein), for example, as described above.

[0208] In some embodiments, the method (2400) may also include the step of sending a response message to the UE device while the UE device is in an inactive state. The response message may induce a state transition in the UE device, for example, as described above.

[0209] In some embodiments, the response message may be a release message (e.g., an RRCR release message) and may induce a state transition to an idle state.

[0210] In some embodiments, the response message may be a release message having a suspension configuration (e.g., an RRCR release message) and may induce a state transition to a legacy inactive state.

[0211] In some embodiments, the response message may be a resumption message (e.g., an RRCResume message) and may induce a state transition to a connected state.

[0212] In some embodiments, the response message may be a setup message (e.g., an RRCSetup message) and may induce a state transition to a connected state.

[0213] In some embodiments, the response message may cause the UE device to remain in an inactive state and enter a subsequent user data transmission mode. While the UE device remains in an inactive state and in the subsequent user data transmission mode, the base station may transmit and / or receive additional user data (or additional portions of the user data mentioned in 2410) to and from the UE device.

[0214] In some embodiments, the response message may implicitly indicate that the forwarding of user data to the core network was successful, for example, as described above.

[0215] In some embodiments, the response message may explicitly indicate whether the forwarding of user data to the core network was successful, for example, as described above.

[0216] In some embodiments, the base station can act as a gNB in ​​the network according to the 3GPP 5GNR standard.

[0217] In some embodiments, the non-transient memory medium may store program instructions. When executed by the processing circuit, the program instructions may cause the processing circuit to perform any of the method embodiments described above and any combination of these embodiments. The memory medium may be integrated as part of a base station.

[0218] Embodiments of the present disclosure may be realized in any of various forms. For example, some embodiments may be realized as a computer implementation method, a computer-readable memory medium, or a computer system. Other embodiments may be realized using one or more custom-designed hardware devices, such as ASICs. Still other embodiments may be realized using one or more programmable hardware elements, such as FPGAs.

[0219] In some embodiments, a non-transient computer-readable memory medium may be configured to store program instructions and / or data, wherein the program instructions, when executed by a computer system, cause the computer system to perform a method, for example, any of the method embodiments described herein, or any combination of the method embodiments described herein, or any subset of any of the method embodiments described herein, or any combination of such subsets.

[0220] In some embodiments, the computer system may be configured to include a processor (or a set of processors) and a memory medium, wherein the memory medium stores program instructions, and the processor is configured to read and execute program instructions from the memory medium, and the program instructions are executable to implement any of the various method embodiments described herein (or any combination of the method embodiments described herein, or any subset of any of the method embodiments described herein, or any combination of such subsets). The computer system may be realized in any of the various forms. For example, the computer system may be a personal computer, a workstation, a computer on a card, an application-specific computer in a box, a server computer, a client computer, a handheld device, a user equipment (UE) device, a tablet computer, a wearable computer, etc. (in any of the various realizations thereof).

[0221] Any of the methods described herein for operating user equipment (UE) communicating with a base station (or transmitting-receiving point) may be the basis of a corresponding method for operating a base station (or transmitting-receiving point) by interpreting each message / signal X received by the UE in the downlink as a message / signal X transmitted by the base station (or transmitting-receiving point) and each message / signal Y transmitted by the UE in the uplink as a message / signal Y received by the base station (or transmitting-receiving point).

[0222] It is well understood that the use of personally identifiable information must follow privacy policies and practices that are generally recognized as meeting or exceeding industry or government requirements for maintaining users' privacy. In particular, personally identifiable information data must be managed and handled to minimize the risks of unintended or unauthorized access or use, and the nature of authorized use must be clearly indicated to users.

[0223] Although the above embodiments have been described in considerable detail, once the above disclosure is sufficiently recognized, many variations and modifications will be obvious to those skilled in the art. The following claims are intended to be interpreted as encompassing all such variations and modifications.

Claims

Claim 1 A method for operating a user equipment (UE) device, comprising: entering an inactive state; encoding a transmission to a network while in the inactive state, wherein the transmission includes a Radio Resource Control (RRC) resumption request message and first user data; receiving an acknowledgment of the transmission from the network; exchanging subsequent user data with the network while in the inactive state; receiving an RRC release message having a interruption indication from the network; and receiving an acknowledgment message from the network while in the inactive state, wherein the acknowledgment message induces a state transition in the UE device, and the acknowledgment message causes the UE device to remain in the inactive state and enter a subsequent user data transmission mode. Claim 2 A method according to claim 1, wherein the transmission includes a buffer status report. Claim 3 A method according to claim 1, wherein the RRC resumption request message includes a cause indicator field indicating the cause for which the RRC resumption request message is being transmitted, and the cause indicator field is set to a value indicating data transmission as the cause. Claim 4 In paragraph 1, the transmission is directed toward the current base station of the network. Claim 5 delete Claim 6 A method according to claim 1, wherein the response message is a release message having a suspension configuration and induces a state transition to a legacy inactive state. Claim 7 In claim 1, the above response message is a setup message, and a method for inducing a state transition to a connected state. Claim 8 delete Claim 9 delete Claim 10 A method according to claim 1, wherein the response message implicitly indicates that the forwarding of the user data to the core network was successful. Claim 11 A method according to claim 1, wherein the response message explicitly indicates whether the forwarding of the user data to the core network was successful. Claim 12 A device comprising a processor configured to enable a user equipment (UE) device to perform any one of the methods of claims 1 through 4, 6, 7, 10 and 11. Claim 13 A device according to claim 12, further comprising a wireless communication device (radio) operably coupled to the processor. Claim 14 A method for operating a base station (BS), comprising: receiving, by the BS, a transmission including a radio resource control (RRC) resumption request message and first user data from a UE device while the UE device is in an inactive state; determining by the BS to maintain the UE in the inactive state; exchanging subsequent user data with the UE while the UE is in the inactive state; transmitting an RRC release message having a interruption indication to the UE; and transmitting a response message to the UE device while the UE device is in the inactive state, wherein the response message induces a state transition in the UE device. Claim 15 In paragraph 14, the above transmission includes a buffer status report, a method. Claim 16 A method according to claim 14, wherein the RRC resumption request message includes a cause indicator field indicating the cause for the RRC resumption request message, and the cause indicator field is set to a value indicating data transmission as the cause. Claim 17 delete Claim 18 A method according to claim 14, wherein the response message is a release message and induces a transition to an idle state; or the response message is a release message having a suspension configuration and induces a transition to a legacy inactive state; or the response message is a resumption message and induces a transition to a connected state; or the response message is a setup message and induces a transition to a connected state. Claim 19 In claim 14, the response message instructs the UE device to remain in the inactive state and enter a subsequent user data transmission mode, and while the UE device is maintained in the inactive state and the subsequent user data transmission mode, the base station transmits and / or receives additional user data to / from the UE device. Claim 20 In paragraph 14, the method wherein the response message implicitly indicates that the forwarding of the user data to the core network was successful. Claim 21 In paragraph 14, the method wherein the response message explicitly indicates whether the forwarding of the user data to the core network was successful. Claim 22 A non-transient memory medium storing program instructions, wherein the program instructions, when executed by a processing circuit, cause the processing circuit to perform the method of any one of claims 14 to 16 and claims 18 to 21. Claim 23 A base station comprising: a wireless subsystem; a processing circuit coupled to the wireless subsystem; and a memory storing program instructions, wherein the program instructions, when executed by the processing circuit, cause the base station to perform the method of any one of claims 14 to 16 and claims 18 to 21. Claim 24 A non-transient memory medium storing program instructions, wherein the program instructions, when executed by a processing circuit, cause the processing circuit to perform the method of any one of claims 1 to 4, 6, 7, 10, and 11.

Images