RRC-based user data transmission in inactive state

Abstract

The invention relates to RRC-based user data transmission in an inactive state. When in an inactive state, a user equipment (UE) device transmits a message to a base station. The message indicates an intention of the UE device to perform user data transmission and / or reception with a network during the inactive state. The message can include a portion of the user data and / or a buffer status report. The UE device receives a response message causing a state transition in the UE device. Different state transitions (e.g., to idle, inactive, legacy inactive, connected) can be caused by different types of response messages (e.g., release, release, resume, setup with a pause configuration). A particular type of response message causes the UE to stay in the inactive state and enables subsequent user data transmission / reception in the inactive state. The response message can implicitly (or explicitly) indicate that forwarding of the user data to the core network is successful.

Description

[0001] This application is a divisional application of an invention patent application with an application date of October 22, 2020, application number 202080106521.9, and titled “RRC-based user data transmission in inactive state”. Technical Field

[0002] The present disclosure relates to the field of wireless communications, and more particularly to a mechanism that enables a User Equipment (UE) device to perform user data transmission and / or reception, particularly transmission and / or reception of small data packets, while remaining in an inactive state. Background Art

[0003] A wireless UE device in an inactive state (e.g., an 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 such a transition is nontrivial. (RRC is an acronym for Radio Resource Control.) Summary of the invention

[0004] In some embodiments, a method for operating a user equipment (UE) device may include one or more of the following operations. When 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 intent to perform user data transmission and / or reception with the network during the inactive state.

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

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

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

[0008] In some embodiments, when in the inactive state, the UE device may receive a response message from the network. The response message may cause a state transition in the UE device. Different state transfers may be caused by different types of response messages.

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

[0010] In some embodiments, the response message may be a release message with a pause configuration and may cause a state transition to a traditional inactive state.

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

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

[0013] In some embodiments, the response message may cause the UE device to remain in the 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 the inactive state.

[0014] In some implementation schemes, the response message may implicitly indicate that the forwarding of the user data to the core network is successful.

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

[0016] In some embodiments, the non-transitory 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 above method embodiments.

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

[0018] In some embodiments, a method for operating a base station (BS) may include one or more of the following operations. When a user equipment (UE) device is in an inactive state, 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 intent to perform user data transmission and / or reception with the network during the inactive state.

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

[0020] 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 a data transmission (or small data transmission) as the cause.

[0021] In some embodiments, the message may be (or may be contained in) a Medium Access Control Protocol Data Unit (MAC PDU).

[0022] In some embodiments, the method may further include transmitting a response message to the UE device when the UE device is in the inactive state. The response message may cause a state transition in the UE device. Different state transfers may be caused by different types of response messages.

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

[0024] In some embodiments, the response message may be a release message with a pause configuration and may cause a state transition to a traditional inactive state.

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

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

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

[0028] In some implementation schemes, the response message may implicitly indicate that the forwarding of the user data to the core network is successful.

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

[0030] In some embodiments, the non-transitory 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 above method embodiments.

[0031] In some embodiments, a base station may include a radio subsystem; a processing circuit coupled to the radio subsystem; and a memory storing program instructions. The program instructions, when executed by the processing circuit, may cause the base station to perform any of the above method embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] A better understanding of the present subject matter may be obtained when the following detailed description of the preferred embodiments is considered in conjunction with the following drawings.

[0033] Figure 1 to Figure 2 An example of a wireless communication system according to some embodiments is shown.

[0034] Figure 3 An example of a base station in communication with a user equipment device is shown according to some embodiments.

[0035] Figure 4 An exemplary block diagram of a user equipment device is shown according to some embodiments.

[0036] Figure 5 An exemplary block diagram of a base station according to some embodiments is shown.

[0037] Figure 6 An exemplary user equipment 600 is shown according to some embodiments.

[0038] Figure 7 An example of a base station 700 according to some embodiments is shown. The base station 700 may be used to communicate with Figure 6 The user equipment 600 communicates with the user equipment 600.

[0039] Figure 8 An example of a process for transitioning a user equipment (UE) from an inactive state to a connected state is shown according to some embodiments.

[0040] 9A to 9E Five different behavior patterns are shown when a user equipment in an inactive state transmits a resume request according to some embodiments.

[0041] Fig. 10A It shows the difficulties encountered when an inactive UE needs to perform user data transmission to the network in a conventional manner.

[0042] Fig. 10B According to some embodiments, Fig. 10A An example of a solution to the problem shown.

[0043] Fig.11 An example of a process by which user equipment may initiate a small data transfer is shown according to some embodiments.

[0044] Fig.12 One possible structure of a protocol data unit (PDU) for initiating transmission and / or reception of user data with a network is shown according to some embodiments.

[0045] FIG. 13A to FIG. 13C Three different ways of indicating the success or failure of network data forwarding when the RRCRelease message is used to cause a transition to the idle state according to some embodiments are shown.

[0046] FIG. 14A to FIG. 14C Three different ways of indicating the success or failure of network data forwarding are shown in accordance with some embodiments when an RRCRelease message with a pause configuration is used to cause a transition to a traditional inactive state.

[0047] FIG. 15A to FIG. 15C Three different ways of indicating the success or failure of network data forwarding when the RRCResume message is used to cause a transition to a connected state are shown according to some embodiments.

[0048] FIG. 16A to FIG. 16B Two different ways of implicitly indicating a failure of user data transmission where an RRCSetup message is used to cause a transition to the connected state are shown according to some embodiments.

[0049] FIG. 17A to FIG. 17B Two different ways of implicitly indicating a failure of a user data transmission where an RRCReject message is used to cause a transition to a legacy inactive state are shown according to some embodiments.

[0050] Figures 18 to 22 Various ways of enabling subsequent user data transmission and / or reception while the user equipment remains in an inactive state are shown according to some embodiments.

[0051] Fig.18 A process is shown in which a recovery message with an explicit status indication is transmitted to a user equipment according to some embodiments.

[0052] Fig.19 A process is shown in which a resume message having an explicit status indication and an explicit data forwarding success indication is transmitted to a user equipment according to some embodiments.

[0053] Fig. 20 A process is shown in which a release message with a subsequent transmission configuration is transmitted to a user equipment according to some embodiments.

[0054] Fig.21 A process is shown in which a release message with a pause (including subsequent transmission configuration and an explicit data forwarding success indication) is transmitted to a user equipment according to some embodiments.

[0055] Fig. 22A process is shown in which L1 and / or L2 messages are used to enable subsequent user data transmission to user equipment in an inactive state according to some embodiments.

[0056] Fig.23 A method for operating a user equipment (UE) device to enable the UE device to perform user data transmission and / or reception during an inactive state (eg, an RRC inactive state) is shown.

[0057] Fig.24 A method for operating a base station to enable the base station to perform data transmission and / or reception with a user equipment (UE) device when the UE device is in an inactive state (eg, an RRC inactive state) is shown.

[0058] Although the features described herein are susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and described in detail herein. However, it should be understood that the drawings and detailed description thereof are not intended to limit this document to the specific forms disclosed, but on the contrary, their purpose is to cover all modifications, equivalents and alternatives that fall within the spirit and scope of the subject matter as defined by the appended claims. DETAILED DESCRIPTION

[0059] Acronyms

[0060] The following acronyms are used in this disclosure:

[0061] 3GPP: Third Generation Partnership Project

[0062] 3GPP2: Third Generation Partnership Project 2

[0063] 5G NR: Fifth Generation New Radio

[0064] BW: Bandwidth

[0065] BWP: Bandwidth Part

[0066] CRC: Cyclic Redundancy Check

[0067] CSI: Channel State Information

[0068] CSI-RS: CSI Reference Signal

[0069] DCI: Downlink Control Information

[0070] DL: Downlink

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

[0072] gNB (or gNodeB): Next-generation Node B, i.e., the base station of 5G NR

[0073] GSM: Global System for Mobile Communications

[0074] HARQ: Hybrid ARQ

[0075] LTE: Long Term Evolution

[0076] LTE-A: LTE Advanced

[0077] MAC: Media Access Control

[0078] MAC-CE: MAC Control Element

[0079] NR: New Radio

[0080] NR-DC: NR Dual Connectivity

[0081] NW: Network

[0082] PDCCH: Physical Downlink Control Channel

[0083] RAT: Radio Access Technology

[0084] RNTI: Radio Network Temporary Identifier

[0085] RRC: Radio Resource Control

[0086] RRM: Radio Resource Management

[0087] RS: Reference signal

[0088] SR: Scheduling Request

[0089] SSB: Synchronization Signal Block

[0090] TCI: Transmission Configuration Indicator

[0091] UE: User Equipment

[0092] UL: Uplink

[0093] UMTS: Universal Mobile Telecommunications System

[0094] the term

[0095] The following is a glossary of terms used in this disclosure:

[0096] Memory medium - any of the various types of memory devices or storage devices. The term "memory medium" is intended to include installation media, such as CD-ROM, floppy disk, 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 memory, magnetic media, for example, hard disk drives or optical storage devices; registers, or other similar types of memory elements, etc. The memory medium may also include other types of memory, or a combination thereof. In addition, the memory medium may be located in a first computer system executing a program, or may be located 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 that may reside in different locations in different computer systems connected, for example, via a network. The memory medium may store program instructions (e.g., in the form of a computer program) that may be executed by one or more processors.

[0097] Carrier Media—storage media as described above, and physical transmission media such as a bus, network, and / or other physical transmission media that transport signals such as electrical, electromagnetic, or digital signals.

[0098] Programmable hardware elements - include various hardware devices that include multiple programmable function blocks connected via programmable interconnects. Examples include FPGAs (field programmable gate arrays), PLDs (programmable logic devices), FPOAs (field programmable object arrays), and CPLDs (complex PLDs). Programmable function blocks can vary from fine-grained (combinational logic units or lookup tables) to coarse-grained (arithmetic logic units or processor cores). Programmable hardware elements may also be referred to as "configurable logic units."

[0099] Computer System—Any of various types of computing or processing systems, including a personal computer system (PC), a mainframe computer system, a workstation, a network appliance, an Internet appliance, a personal digital assistant (PDA), a personal communication device, a smart phone, a television system, a grid computing system, or other devices or combinations of devices. In general, the term "computer system" may be broadly defined to encompass any device (or combination of devices) having at least one processor that executes instructions from a memory medium.

[0100] User Equipment (UE) (or "UE device") - any of various types of computer system devices that are mobile or portable and that perform wireless communications. Examples of UE devices include mobile phones or smart phones (e.g., iPhone TM, based on Android TM phones), portable gaming devices (e.g., Nintendo DS TM , PlayStation Portable TM 、Gameboy Advance TM , iPhone TM ), wearable devices (e.g., smart watches, smart glasses), laptops, PDAs, portable network devices, music players, data storage devices, or other handheld devices, etc. In general, the term "UE" or "UE device" can be broadly defined to include any electronic, computing, and / or telecommunication device (or combination of devices) that is easily transportable by a user and capable of wireless communication.

[0101] Base Station—The term “base station” has the full breadth of its ordinary meaning and includes at least a wireless communication station that is installed at a fixed location and used to communicate as part of a wireless telephone system or radio system.

[0102] Processing Element—refers to any of various elements or combinations of elements. Processing elements include, for example, circuits such as ASICs (application specific integrated circuits), portions or circuits of individual processor cores, entire processor cores, individual processors, programmable hardware devices such as field programmable gate arrays (FPGAs), and / or larger portions of systems including multiple processors.

[0103] Automatic—refers to an action or operation being performed by a computer system (e.g., software executed by a computer system) or a device (e.g., a circuit, a programmable hardware element, an ASIC, etc.) without the need for the action or operation to be directly specified or performed by a user input. Thus, the term "automatic" is in contrast to a user manually performing or specifying an action, wherein the user provides input to directly perform the action. An automatic process may be initiated by input provided by a user, but subsequent actions performed "automatically" are not specified by the user, i.e., are not performed "manually," wherein the user specifies each action to be performed. For example, a user filling out an electronic form by selecting each field and providing input specifying information (e.g., by typing in information, selecting checkboxes, radio selections, etc.) is manually filling out the form, even though the computer system must update the form in response to the user action. The form may be automatically filled out by a computer system, wherein the computer system (e.g., software executed on the computer system) analyzes the fields of the form and fills out the form without requiring any user input to specify the answers to the fields. As indicated above, a user may invoke automatic filling out of a form, but not participate in the actual filling out of the form (e.g., the user does not manually specify the answers to the fields but rather they are automatically completed). This specification provides various examples of operations that are automatically performed in response to actions taken by a user.

[0104] Figures 1 to 3 -Communication system

[0105] Figure 1 and Figure 2 An exemplary (and simplified) wireless communication system is shown. Note that Figure 1 and Figure 2 The systems are merely examples of some possible systems, and various embodiments may be implemented in any of a variety of ways as desired.

[0106] Figure 1 The wireless communication system of 102 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 herein as a "user equipment" (UE). Figure 2 In the wireless communication system, in addition to the base station 102A, the base station 102B also communicates with the UE devices 106A, 106B, etc. to 106N through the transmission medium (for example, simultaneously or concurrently).

[0107] Base stations 102A and 102B may be base transceiver stations (BTS) or cell sites, and may include hardware to enable wireless communications with user devices 106A through 106N. Each base station 102 may also be equipped to communicate with a core network 100 (e.g., base station 102A may be coupled to core network 100A, while base station 102B may be coupled to core network 100B), which may be a core network of a cellular service provider. Each core network 100 may also be coupled to one or more external networks (such as external network 108), which may include the Internet, a public switched telephone network (PSTN), or any other network. Thus, base station 102A may facilitate communications between user devices and / or between user devices and network 100A; in Figure 2 In a system, base station 102B may facilitate communications between user devices and / or between user devices and network 100B.

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

[0109] For example, base station 102A and core network 100A may operate according to a first cellular communication standard (e.g., LTE), while base station 102B and core network 100B may 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., cellular service provider or "operator") or different network operators. In addition, the two networks may operate independently of each other (e.g., if they operate according to different cellular communication standards), or may operate in a somewhat coupled or tightly coupled manner.

[0110] It should also be noted that although Figure 2 The illustrated network configuration may use two different networks to support two different cellular communication technologies, but other network configurations implementing multiple cellular communication technologies are possible. As an example, base stations 102A and 102B may operate according to different cellular communication standards, but are coupled to the same core network. As another example, a multi-mode base station 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 other various network deployment scenarios are also possible.

[0111] As another possibility, base station 102A and base station 102B may also operate according to the same wireless communication technology (or a set of overlapping wireless communication technologies). For example, base station 102A and core network 100A may be operated by one 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-106N may independently communicate with base stations 102A-102B, possibly by utilizing separate subscriber identities to communicate with different operator networks.

[0112] UE 106 can communicate using multiple wireless communication standards. For example, UE 106 can be configured to communicate using any one or two cellular communication standards in a 3GPP cellular communication standard (such as LTE) and / or a 3GPP2 cellular communication standard (such as a cellular communication standard in the CDMA2000 series of cellular communication standards). As another example, UE 106 can be configured to communicate using different 3GPP cellular communication standards (such as two or more of GSM, UMTS, LTE, or LTE-A). Therefore, as described above, UE 106 can be configured to communicate with base station 102A (and / or other base stations) according to a first cellular communication standard (e.g., LTE) and can also be configured to communicate with 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.).

[0113] Base stations 102A and 102B and other base stations operating according to the same or different cellular communication standards may thus be provided as one or more cell networks that can provide continuous or nearly continuous overlapping service to UEs 106A-106N and similar devices over a wide geographic area via one or more cellular communication standards.

[0114] The UE 106 may also or alternatively be configured to communicate using WLAN, Bluetooth, one or more global navigation satellite systems (GNSS, such as GPS or GLONASS), one and / or more mobile television broadcast 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.

[0115] Figure 3 A user equipment 106 (e.g., one of devices 106A through 106N) is shown communicating with a base station 102 (e.g., one of base stations 102A or 102B). UE 106 may be a device with wireless network connectivity, such as a mobile phone, a handheld device, a computer or tablet, a wearable device, or substantially any type of wireless device.

[0116] The UE may include a processor configured to execute program instructions stored in a memory. The UE may perform any of the method implementations described herein by executing such stored instructions. Alternatively or in addition, the UE may include a programmable hardware element such as an FPGA (field programmable gate array) configured to perform any of the method implementations described herein, or any part of any of the method implementations described herein.

[0117] UE 106 may be configured to communicate using any of a number of wireless communication protocols. For example, UE 106 may be configured to communicate using two or more of GSM, UMTS (W-DCMA, 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.

[0118] UE 106 may include one or more antennas for communicating using one or more wireless communication protocols. Within UE 106, one or more portions of the receive and / or transmit chains may be shared between multiple wireless communication standards; for example, UE 106 may be configured to communicate using a single shared radio using one (or both) of GSM or LTE. The shared radio may include a single antenna, or may include multiple antennas for performing wireless communication (e.g., for MIMO or beamforming). MIMO is an acronym for Multiple Input Multiple Output.

[0119] Figure 4 -Exemplary block diagram of UE

[0120] Figure 4 An exemplary block diagram of UE 106 is shown. As shown, UE 106 may include a system on chip (SOC) 300, which may include parts for various purposes. For example, as shown, SOC 300 may include a processor 302 that can execute program instructions for UE 106 and a display circuit 304 that can perform graphics processing and provide display signals to a display 345. Processor 302 may also be coupled to a memory management unit (MMU) 340 and / or other circuits or devices (such as display circuit 304, radio component 330, connector I / F 320 and / or display 345), which may be configured to receive addresses from processor 302 and convert those addresses to locations in memory (e.g., memory 306, read-only memory (ROM) 350, NAND flash memory 310). MMU 340 may be configured to perform memory protection and page table conversion or setup. In some embodiments, MMU 340 may be included as part of processor 302.

[0121] As shown, SOC 300 may be coupled to various other circuits of UE 106. For example, UE 106 may include various types of memory (e.g., including flash memory 310), a connector interface 320 (e.g., for coupling to a computer system, a docking station, a charging station, etc.), a display 345, and a radio 330.

[0122] The radio component 330 may include one or more RF chains. Each RF chain may include a transmission chain, a reception chain, or both. For example, the radio component 330 may include two RF chains to support dual connectivity with two base stations (or two cells). The radio component may be configured to support wireless communications according to one or more wireless communication standards (e.g., one or more of GSM, UMTS, LTE, LTE-A, WCDMA, CDMA2000, Bluetooth, Wi-Fi, GPS, etc.).

[0123] The radio component 330 is coupled to an antenna subsystem 335 including one or more antennas. For example, the antenna subsystem 335 may include multiple antennas to support applications such as dual connectivity or MIMO or beamforming. The antenna subsystem 335 transmits and receives radio signals to / from one or more base stations or devices through a radio propagation medium (usually the atmosphere).

[0124] In some embodiments, the processor 302 may include a baseband processor to generate uplink baseband signals and / or process downlink baseband signals. The processor 302 may be configured to perform data processing according to one or more wireless communication standards (e.g., one or more of GSM, UMTS, LTE, LTE-A, WCDMA, CDMA2000, Bluetooth, Wi-Fi, GPS, etc.).

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

[0126] As shown, the UE 106 may also include one or more user identity 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 UICC (eUICC), for example, a device that is built into the UE 106 and is not removable. The eUICC may be programmable so that one or more eSIMs may be implemented on the eUICC. In other embodiments, the eSIM may be installed in the UE 106 software, for example, as program instructions stored on a storage medium (such as memory 306 or Flash 310) executed on a processor (such as processor 302) in the UE 106. As an example, the SIM 360 may be an application executed on a universal integrated circuit card (UICC). Alternatively or in addition, one or more of the SIMs 360 may be implemented as a removable SIM card.

[0127] The processor 302 of the UE device 106 may be configured to implement some or all of the methods described herein, for example, by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). In other embodiments, the processor 302 may be configured as or include: a programmable hardware element such as an FPGA (field programmable gate array); or an ASIC (application-specific integrated circuit); or a combination thereof.

[0128] Figure 5 - Base station example

[0129] Figure 5 1 shows a block diagram of a base station 102. Note that Figure 5 The base station of is only one example of a possible base station. As shown, the base station 102 may include a processor 404 that may execute program instructions for the base station 102. The processor 404 may also be coupled to a memory management unit (MMU) 440 or other circuit or device, which may be configured to receive addresses from the processor 404 and convert these addresses to locations in memory (e.g., memory 460 and read-only memory (ROM) 450).

[0130] The base station 102 may include at least one network port 470. The network port 470 may be configured to couple to a telephone network and provide (to multiple devices such as the UE device 106) services such as those described above in Figure 1 and Figure 2 Access to the telephone network as described in.

[0131] The network port 470 (or an additional network port) may also or alternatively be configured to couple to a cellular network, such as 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 the UE device 106. In some cases, the network port 470 may be coupled to a telephone network via the core network, and / or the core network may provide a telephone network (e.g., in other UE devices served by the cellular service provider).

[0132] The base station 102 may include a radio component 430 having one or more RF chains. Each RF chain may include a transmit chain, a receive chain, or both. (For example, the base station 102 may include at least one RF chain per sector or cell). The radio 430 is coupled to an antenna subsystem 434 including 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 radio signals to / from the UE through a radio propagation medium (typically the atmosphere).

[0133] In some embodiments, processor 404 may include a baseband processor to generate downlink baseband signals and / or process uplink baseband signals. Baseband processor 430 may be configured to operate according to one or more wireless telecommunication standards, including but not limited to GSM, LTE, WCDMA, CDMA2000, etc.

[0134] The processor 404 of the base station 102 may be configured to implement part or all of the methods described herein, for example, by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). In some embodiments, the processor 404 may include: a programmable hardware element, such as an FPGA (field programmable gate array); or an ASIC (application-specific integrated circuit); or a combination thereof.

[0135] In some embodiments, the wireless user equipment (UE) device 600 may be configured as follows: Figure 6 UE device 600 may include: a radio subsystem 605 for performing wireless communications; and a processing element 610, which is operatively coupled to the radio subsystem. (UE device 600 may also include any subset of the UE features described above, for example, in combination with Figures 1 to 4 ).

[0136] The radio 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 propagation channel and / or transmit these signals to a radio propagation channel. Therefore, each RF chain may include a transmission chain and / or a reception chain. The radio 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 some RF chains) may be tuned to a desired frequency, thereby allowing the RF chain to receive or transmit at different frequencies at different times.

[0137] Processing element 610 may be coupled to the radio subsystem and may be configured as described in various ways above. (For example, the processing element may be implemented by processor 302.) The processing element may be configured to control the state of each RF chain in the radio subsystem.

[0138] In some embodiments, the processing element may include one or more baseband processors to (a) generate baseband signals to be transmitted by the radio subsystem and / or (b) process baseband signals provided by the radio subsystem.

[0139] In a dual-connection operating mode, the processing element may instruct the first RF chain to communicate with the first base station using the first radio access technology, and instruct the second RF chain to communicate with the second base station using the 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 gNB of a 5G New Radio (NR). 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 that implements baseband processing relative to the LTE branch and a second subcircuit that implements baseband processing relative to the NR branch.

[0140] Processing element 610 may be further configured as variously described in the following sections.

[0141] In some embodiments, a wireless base station 700 of a wireless network (not shown) may be configured as follows: Figure 7 The wireless base station may include: a radio subsystem 705 for performing wireless communications over a radio propagation channel; and a processing element 710, which is operatively coupled to the radio subsystem. (The wireless base station may also include any subset of the above-mentioned base station features, for example, the above-mentioned combination Figure 5 described features).

[0142] The radio 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 radio subsystem 710 may be coupled to an antenna subsystem that includes one or more antennas, such as an antenna array or multiple antenna arrays. The radio subsystem may employ the antenna subsystem to transmit radio signals to and receive radio signals from a radio wave propagation medium.

[0143] Processing element 710 may be implemented as described in various ways above. For example, in one embodiment, processing element 710 may be implemented by processor 404. In some embodiments, the processing element may include one or more baseband processors to: (a) generate baseband signals to be transmitted by the radio subsystem, and / or (b) process baseband signals provided by the radio subsystem.

[0144] Processing element 710 may be configured to perform any of the base station method implementations described herein.

[0145] Radio Resource Control (RRC) Inactive State

[0146] In some embodiments, the behavior of a user equipment (UE) in an inactive state may be described in terms of its behavior in the control plane and the user plane. In the control plane, an inactive UE may: have a network access stratum (NAS) connection to the core network and no dedicated access stratum (AS) resources. In addition, the UE may retain the radio resource control (RRC) configuration it had before entering the inactive state. In the user plane, the UE may not be able to perform any dedicated data transmission / reception. If dedicated data transmission / reception needs to be performed, the UE needs to enter the connected state. For DL ​​data transmission, the gNB may page the UE via the RAN paging mechanism to trigger the UE's transition to the connected state. (RAN is an acronym for Radio Access Network.) For UL data transmission, the UE may trigger a random access (RACH) procedure to enter the connected state. Regarding mobility, an inactive UE may move within a RAN notification area (RNA) without notifying the next generation RAN (NG-RAN). Cell selection and reselection may be performed in the same manner as in the RRC idle state.

[0147] In some embodiments, the UE may make different state transitions in different situations. For example, the gNB may use an RRC release with suspend information to cause the UE to transition from a connected state to an inactive state. For another example, as part of an RRC recovery procedure, the gNB may cause the UE to transition from an inactive state to a connected state. For another example, the UE may transition from an inactive state to an idle state (1) in response to an RRC release or (2) when the UE cannot find a cell to camp on.

[0148] UE transitions from inactive state to connected state

[0149] In some embodiments, the UE may transition from an inactive state to a connected state, such as Figure 8 As shown. We start Figure 8 , wherein the UE is in an RRC inactive CM connected state. (CM is an acronym for connection management.) To initiate a transition to the connected state, the UE may transmit a resume request (e.g., RRCResumeRequest) to the current gNB. In response to receiving the resume request, the gNB may transmit a context retrieval request (i.e., a request for retrieval of the UE context) to the last serving gNB. The UE context may include variables of the UE access stratum (AS) configuration and the previous connected state. The current gNB may use the UE context to determine the RRC configuration in the newly accessed serving cell. In response to receiving the context retrieval request, the last serving gNB may transmit a context retrieval response containing the requested UE context to the current gNB.

[0150] In response to receiving the context retrieval response, the current gNB may transmit a resume message (e.g., an RRCResume message) to the UE. In response to receiving the resume message, the UE may transition to the RRC connected CM connected state. In this state, the UE may transmit a resume complete message (e.g., an RRCResumeComplete message) to the current gNB. In response to receiving the resume complete message, the current gNB may transmit a data forwarding address indication to the last serving gNB and transmit a path switch request to an access and mobility management function (AMF). In response to receiving the path switch request, the AMF may transmit a response to the path switch request to the current gNB. In response to receiving the response, the current gNB may transmit a context release message to the last serving gNB, indicating that the UE context may be released in the last serving gNB.

[0151] Behavior when the UE is inactive

[0152] 9A to 9E Five different behavior modes are shown when a UE in an inactive state transmits a resume request (or attempts to resume a suspended RRC connection). Fig.9A , Fig. 9C and Fig.9D In the example above, the attempt to recover can be interpreted as successful. Fig. 9B A recovery scenario with fallback to establishment is shown. Fig.9E The attempt to recover was rejected by the network.

[0153] Fig.9AA process is shown in which a UE transitions from an inactive state to a connected state according to some embodiments. The process may be followed when the network is able to extract the UE context. From the inactive state, the UE may initiate an attempt to resume a suspended RRC connection by sending a resume request (such as RRCResumeRequest or RRCResumeRequest1, for example, as defined in 3GPP TS 38.331), version 15. In response to receiving the resume request, the network may reply to the UE with a resume message (e.g., an RRCResume message). In response to receiving the resume message, the UE may transition to a connected state; and send a resume complete message (e.g., an RRCResumeComplete message) to the network, indicating that the process of resuming the connection is complete.

[0154] Fig. 9B A process is shown in which a UE transitions from an inactive state to a connected state according to some embodiments. The process may be followed when the network cannot extract the UE context. From the inactive state, the UE may initiate an attempt to resume a suspended RRC connection by sending a resume request. In response to receiving the resume request, the network may reply to the UE with a connection establishment message (e.g., an RRCSetup message). In response to receiving the connection establishment message, the UE may transition to a connected state; and send a setup complete message (e.g., an RRCSetupComplete message) to the network, indicating that the process of establishing the connection is complete.

[0155] Fig. 9C A process in which a UE transitions from an inactive state to an idle state according to some embodiments is shown. The process may be followed when the network is able to extract the UE context. From the inactive state, the UE may initiate an attempt to resume a suspended RRC connection by sending a resume request. In response to receiving the resume request, the network may reply to the UE with a release message (e.g., an RRCRelease message). In response to receiving the release message, the UE may transition to an idle state.

[0156] Fig.9D A process in which a UE performs an empty transition from an inactive state to an inactive state according to some embodiments is shown. The process may be followed when the network is able to extract the UE context. From the inactive state, the UE may initiate an attempt to resume a suspended RRC connection by sending a resume request. In response to receiving the resume request, the network may reply to the UE by sending a release message (e.g., an RRCRelease message) with a suspended configuration. In response to receiving a release message with a suspended configuration, the UE may remain in the inactive state.

[0157] Fig.9EA process is shown in which the UE makes a null transition from an inactive state to an inactive state. This process may be followed when the network may be unable to extract the UE context. From the inactive state, the UE may initiate an attempt to resume the suspended RRC connection by sending a resume request. In response to receiving the resume request, the network may reply 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.

[0158] Fig. 10A The difficulty encountered when an inactive UE needs to perform user data transmission to the network in a conventional manner is shown. While in the inactive state, the UE senses that data is available for uplink transmission. For example, the UE may sense the arrival of data in an uplink transmission buffer. In response to the arrival of data, the UE may trigger an RRC recovery procedure. The recovery procedure may cause the UE to transition to a connected state or an idle state or an inactive state. User data transmission is not allowed during the RRC recovery procedure. If the recovery procedure ends with a successful transition to the connected state, such as Fig. 10A As shown, the UE can then perform an uplink data transmission to serve the waiting uplink data. The time delay between the data arrival event and the uplink transmission may be significant. Unfortunately, the UE needs to wait for the recovery process to complete before transmitting, especially when the amount of data to be transmitted is small.

[0159] Fig. 10B Solutions to the above difficulties according to some embodiments are shown.The network and the UE may be provided with mechanisms that enable the UE to perform uplink and / or downlink user data transmission during the RRC recovery procedure while the UE remains in an inactive state.

[0160] In some embodiments, the UE and the network may support a mechanism that enables the UE to perform a small data transfer in an inactive state. When in an inactive state, the UE may perform a small data transfer, for example, using one or more messages of a random access procedure. A base station (e.g., a gNB for 3GPP NR) may extract the UE context and forward the UE's user data to the core network, for example, with or without anchor relocation.

[0161] In some implementations, inactive UEs may transmit uplink user data on pre-configured PUSCH resources. (PUSCH is an acronym for Physical Uplink Shared Channel.)

[0162] RRC-based small data transmission in inactive state

[0163] In some embodiments, the network (NW) may configure the UE to support a small data transfer (SDT) process in an inactive state. The UE may initiate the SDT process, for example, by transmitting a release message with a suspension configuration (e.g., RRCRelease with SuspendConfig). The suspension configuration may be interpreted as a configuration to be used by the UE for transmission during an inactive state. The serving cell (or base station) may or may not support the SDT feature. The serving cell (or base station) may indicate, for example, via a broadcast message that it supports the SDT feature. The UE may decode the broadcast message to determine that the serving cell (or base station) supports the SDT feature. Alternatively, the UE may determine that the serving cell (or base station) supports the SDT feature based on a previous dedicated configuration. (In the dedicated configuration method, the network may pre-send an RRCRelease with a suspension configuration to set the UE to an inactive state. In this message, the network may implement the SDT feature and indicate a list of applicable cells.)

[0164] In some embodiments, the UE may trigger an SDT process in response to one or more conditions (e.g., configurable conditions) being met. The action of triggering the SDT process may include performing an uplink transmission including a recovery request message (e.g., an RRCResumeRequest message). The recovery request message may include: an inactive UE identifier (e.g., I-RNTI); a UE medium access control identifier (MAC-I, used for security checks); and an indication of the cause of the access. (RNTI is an acronym for Radio Network Temporary Identifier.) The recovery request message may include an indication of the reason for the request to the UE. The cause indication may be set to an SDT state, i.e., a state indicating a request for a small data transmission.

[0165] In some embodiments, in response to receiving a resume request message with a cause equal to SDT, the network may perform access control, security checks, and UE identification in a conventional manner and transmit 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 transmits to the UE: (1) connected; (2) inactive; (3) idle; (4) inactive with subsequent transmission. Conventional 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 process may be required.

[0166] UE operations that trigger the SDT process

[0167] like Fig.11As shown, when UL data arrives, the UE may first evaluate whether to trigger an SDT process or a traditional recovery process. When one or more conditions (e.g., network configurable conditions) are met, the UE may trigger the SDT process. These 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 the 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 the configured threshold. According to the third condition, the UE may determine whether the radio signal quality is greater than the quality threshold. If one or more desired (or configured) conditions are not met, the UE may trigger a traditional recovery process. However, if the UE is configured with an SDT feature and one or more desired (or configured) conditions are met, the UE may trigger the SDT process by generating a recovery message (e.g., an RRC recovery message) and set the recovery cause = SDT. The UE may select an SDT resource (PRACH, pre-configured PUSCH) for transmission and assemble the MAC PDU according to the transport block size (TBSize). (MAC PDU is an acronym for Medium Access Control - Protocol Data Unit.) If the selected resources are not large enough to accommodate all the user data to be transmitted, the UE may include at least the RRC message within the MAC PDU and additionally include a portion of the user data and / or a buffer status report (BSR).

[0168] Network behavior upon receiving the first UL message

[0169] In some embodiments, when receiving a RRCResumeRequest with a cause value = SDT, the network (NW) may determine from the cause value that the initial access is triggered by the UE's desire to perform a small data transfer (SDT). The network (e.g., a base station such as a gNB) may decide to send a response to the UE based on any of the following situations. Different types of responses may lead to different results at the UE.

[0170] Case 1: The network may transmit RRCRelease to instruct the UE to transition to the idle state.

[0171] Case 2: The network may transmit RRCRelease with a suspend configuration to instruct the UE to transition to the legacy inactive state.

[0172] Case 3: The network may transmit RRCResume to instruct the UE to transition to the connected state.

[0173] Case 4: The network may transmit an RRCSetup message to instruct the UE to transition from the idle state to the connected state.

[0174] Case 5: The network may transmit an RRCReject message to instruct the UE to stay in the legacy inactive state.

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

[0176] In some embodiments, the network may indicate to the UE whether the user data portion transmitted with the RRCResumeRequest has been successfully processed by the NW. The indication may be provided in the following manner. In a first option, the NW may explicitly indicate the data processing result (success or failure) in the response message. In a second option, the success or failure result may be implicitly indicated by the transmission or non-transmission of a special RRC response message. (The transmission of a special RRC response message may indicate success.)

[0177] like Fig.12 As shown, a medium 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 zero and a payload including an RRC recovery request. A second sub-PDU may include a header having a logical channel number X, for example, different from zero, and a payload including user data (or a portion of user data).

[0178] When receiving the response message, the UE may operate on the data portion as follows. When the response indicates success, the UE may treat the response transmission as a radio link control acknowledgement (RLC ACK) and discard the data portion. When the response indicates failure, there are different options for handling the data portion.

[0179] In a first option, the UE may treat the failure as an RLC NACK (Negative Acknowledgement) and wait for the next RLC Protocol Data Unit (PDU) retransmission.

[0180] In the second option, the UE may discard the RLC PDU and wait for the next PDCP PDU retransmission. (PDCP is the acronym for Packet Data Convergence Protocol.)

[0181] In the third option, the UE may discard the RLC PDU and PDCP PDU and wait for the next PDCP SDU retransmission. (SDU is the acronym for Service Data Unit.)

[0182] Case 1: Using RRCRelease to cause a transition to the idle state

[0183] FIG. 13A to FIG. 13CIt relates to scenario 1 (where the RRCRelease message is used to cause the UE to enter an idle state), and illustrates three different ways of indicating to the UE the success or failure of the network's processing of user data according to some embodiments.

[0184] like Fig.13A As shown, after the current base station (such as the gNB of 3GPP NR) receives the RRCResume with user data, a context extraction and data forwarding request (including user data) may be sent to the last serving base station. Context extraction represents 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 that 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 an indication of successful data forwarding, the current base station may then decide to release the UE, for example, by transmitting a release message (e.g., an RRCRelease message) to the UE including an explicit indication of successful data forwarding, in which case the UE may transition to an idle state.

[0185] Alternatively, if Fig. 13B As shown, when the last serving base station receives the context extraction and data forwarding request, the last serving base station may decide not to forward the user data to the core network (or determine that the attempt to forward the user data to the core network has failed). In this case, the last serving base station may send the UE context and an indication of the data forwarding failure to the current base station. In response, the current base station may decide to release the UE, for example, by transmitting an RRCRelease message including an explicit indication of the data forwarding failure to the UE. In response to receiving the RRCRelease message including an explicit indication of the data forwarding failure, the UE may regard its transmission of the user data as a failure and transition to an idle state.

[0186] Fig. 13C An embodiment in which the success of data forwarding can be implicitly indicated by the action of the current base station transmitting an RRCRelease message is shown. In response to receiving the RRCRelease message, the UE can regard its transmission of user data as successful and transition to an idle state. If the UE does not receive the RRCRelease message within a predetermined amount of time, the UE can assume that its transmission of user data has failed.

[0187] Case 2: Using RRCRelease with a suspend configuration to cause a transition to the legacy inactive state

[0188] FIG. 14A to FIG. 14CThe present invention relates to scenario 2 (wherein an RRCRelease message with a pause configuration is used to cause the UE to enter a legacy inactive state), and shows three different ways of indicating to the UE the success or failure of the network's processing of 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 allowed, for example, as defined by the existing 3GPP 5GNR specification.

[0189] like Fig.14A As shown, the last serving base station may send 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 pause configuration and an explicit indication of successful data forwarding to the UE. In response to receiving the RRCRelease message with a pause configuration and an explicit indication of successful data forwarding, the UE may regard its transmission of user data as successful and transition to a traditional inactive state.

[0190] Alternatively, if Fig. 14B As shown, when the last serving base station receives a context extraction and 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 determine that the attempt to forward the user data to the core network has failed). In this case, the last serving base station may send the UE context and an indication of the data forwarding failure to the current base station. In response, the current base station may decide to release the UE by transmitting an RRCRelease with a pause configuration and an explicit indication of the data forwarding failure to the UE. In response to receiving the RRCRelease with a pause configuration and an explicit indication of the data forwarding failure, the UE may regard its transmission of the user data as successful and may be converted to a traditional inactive state.

[0191] Fig. 14C An implementation scheme is shown in which the success of data forwarding can be implicitly indicated by the action of the current base station transmitting an RRCRelease message with a pause configuration. In response to receiving the RRCRelease message with a pause configuration, the UE can regard its transmission of user data as successful and transition to a traditional inactive state. If the UE does not receive the RRCRelease with a pause configuration within a predetermined amount of time, the UE can regard its transmission of user data as a failure.

[0192] Case 3: Using the RRCResume message to cause a transition to the connected state

[0193] FIG. 15A to FIG. 15CIt relates to scenario 3 (where the RRCResume message is used to cause the UE to enter a connected state), and illustrates three different ways of indicating to the UE the success or failure of the network's processing of user data according to some embodiments.

[0194] like Fig.15A As shown, after the current base station (such as the gNB of 3GPP NR) receives the RRCResume message with user data, a context extraction and data forwarding request (including user data) may be sent to the last serving base station. Context extraction represents 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 that 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 transmitting an RRCResume message including an explicit indication of successful data forwarding to the UE. In response to receiving the RRCResume message including an explicit indication of successful data forwarding, the UE may regard its transmission of user data as successful and transition to a connected state.

[0195] Alternatively, if Fig. 15B As shown, when the last serving base station receives the context extraction and data forwarding request, the last serving base station may decide not to forward the user data to the core network (or determine that the attempt to forward the user data to the core network has failed). In this case, the last serving base station may send the UE context and an indication of the data forwarding failure to the current base station. In response to receiving the UE context and the indication of the data forwarding failure, the current base station may decide to transition the UE to a connected state, for example, by transmitting an RRCResume message including an explicit indication of the data forwarding failure to the UE. In response to receiving the RRCResume message including an explicit indication of the data forwarding failure, the UE may regard its transmission of the user data as a failure and transition to a connected state.

[0196] Fig. 15C An embodiment is shown in which the success of data forwarding can be implicitly indicated by the action of the current base station transmitting the RRCResume message. In response to receiving the RRCRelease message, the UE can regard its transmission of user data as successful and transition to the connected state. If the UE does not receive the RRCRelease within a predetermined amount of time, the UE can regard its transmission of user data as failed.

[0197] Case 4: Using RRCSetup to cause a transition to the connected state

[0198] Fig.16A and Fig. 16B This relates to scenario 4, where the RRCSetup message is used to implicitly indicate the failure of the UE's user data transmission and cause the UE to enter a connected state.

[0199] like Fig.16A As shown, when the last serving base station receives a context extraction 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 the indication of the failure of context extraction, the current base station may decide that the UE should transition to a connected state. The UE may cause the transition by transmitting a setup message (e.g., an RRCSetup message) to the UE. The RRCSetup message implicitly indicates to the UE that its transmission of user data has failed. In response to receiving the RRCSetup message, the UE may regard the user data transmission as a failure and transition to a connected state.

[0200] like Fig. 16B As shown, in response to receiving a resume request with user data (e.g., RRCResumeReq), the current base station may decide to transition the UE to a connected state, for example, without attempting to extract the UE context or forwarding 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 transmitting a setup message (e.g., an RRCSetup message) to the UE. In response to receiving the setup message, the UE may regard its user data transmission as a failure and transition to a connected state.

[0201] Case 5: Using RRCReject to keep the UE in the legacy inactive state

[0202] Fig.17A and Fig. 17B This relates to scenario 5, where the RRCReject message is used to implicitly indicate the failure of the UE's user data transmission and cause the UE to remain in the legacy inactive state.

[0203] like Fig.17AAs shown, when the last serving base station receives a context extraction and data forwarding request (including user data), the last serving base station may: determine that it cannot (or will not) provide UE context; decide not to forward user data to the core network (or determine that an attempt to forward user data to the core network has failed); and respond by sending an indication to the current base station that the request for UE context has failed. In response to receiving an indication of a failure in context extraction, the current base station may decide that the UE's request to resume the connection should be rejected, for example, due to congestion. Therefore, the UE may cause the UE to transition to a traditional inactive state by transmitting an RRCReject message to the UE. The RRCReject message implicitly indicates to the UE that its transmission of user data has failed. In response to receiving the RRCReject message, the UE may regard its user data transmission as a failure and transition to a traditional inactive state.

[0204] like Fig. 17B As shown, in response to receiving a resume request with user data (e.g., RRCResumeReq), the current base station may decide to transition the UE to a traditional inactive state, for example, without attempting to extract the UE context or forwarding 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 transmitting a rejection message (e.g., an RRCReject message) to the UE. In response to receiving the rejection message, the UE may regard its user data transmission as a failure and transition to a traditional inactive state.

[0205] Scenario 6: Network control of subsequent data transmission

[0206] 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 via dedicated scheduling / transmission. The network may trigger the UE to enter a subsequent data transmission mode, for example, via an L2 or L3 command.

[0207] In a first option, the current base station may transmit an RRCResume message with an explicit status indication (status = inactive). Fig.18An implementation scheme of the first option is shown. In response to receiving a MAC PDU including a recovery request and a user data portion, the current base station may decide to keep the UE in an inactive state and switch to a subsequent data transmission mode. In response to making this decision, the current base station may transmit an RRCResume message with 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 the user data is successfully forwarded to the core network. In response to receiving the RRCResume message with an explicit indication, the UE may regard the user data transmission as successful and enter a subsequent transmission mode. In the subsequent transmission mode, the UE may perform subsequent user data transmission while remaining in an inactive state. For example, the UE may transmit an RRCResume completion message to the current base station; and then use a dedicated configuration for subsequent user data transmission and / or reception. After the subsequent user data transmission and / or reception is completed, the current base station may send an RRCRelease message with a pause configuration.

[0208] Similar to the first option, in option 1B, the current base station may transmit an RRCResume message with an explicit indication of the inactive state as the state that the UE is to maintain. However, in option 1B, the RRCResume message may also include an explicit indication of whether the user data is successfully forwarded to the core network, such as Fig.19 In response to receiving the RRCResume message, the UE may determine whether its user data transmission is successful based on the explicit indication. If the user data transmission is successful, the UE may clear the corresponding user data from its buffer and continue to transmit the next part of the user data when in an inactive state. If the user data transmission is unsuccessful, the UE may attempt to retransmit the user data.

[0209] In a second option, the current base station may transmit a RRCRelease message with a subsequent transmission configuration. Fig. 20An implementation scheme of this second option is shown. In response to receiving a MAC PDU including a recovery request and a user data portion, the current base station may decide to keep the UE in an inactive state and switch to a subsequent data transmission mode. In response to making this decision, the current base station may transmit an RRCRelease message with a suspension including (or indicating) a subsequent transmission configuration. In response to receiving an RRCRelease message with a suspension and subsequent transmission configuration, the UE may remain in an inactive state and enter a subsequent transmission mode. In the subsequent transmission mode, the UE may perform subsequent user data transmission / reception while remaining in an inactive state. For example, the UE may transmit a MAC CE / L1 ACK to the current base station; and then use a dedicated configuration (e.g., a dedicated configuration provided together with the RRCRelease message) for subsequent user data transmission and / or reception. After the subsequent user data transmission and / or reception is completed, the current base station may send an RRCRelease with a suspension of subsequent transmission configuration.

[0210] Similar to the second option described above, in option 2B, the current base station may transmit an RRCRelease message including a subsequent transmission configuration. However, in option 2B, the RRCRelease message may also include an explicit indication of whether the user data is successfully forwarded to the core network, such as Fig.21 In response to receiving the RRCRelease message, the UE may determine whether its user data transmission is successful based on the explicit indication. If the user data transmission is successful, the UE may clear the corresponding user data from its buffer and continue to transmit the next part of the user data when in an inactive state. If the user data transmission is unsuccessful, the UE may attempt to retransmit the user data.

[0211] In a third option, the current base station may employ L1 / L2 commands. Fig. 22An implementation scheme of this third option is shown. In response to receiving a message 2210 (e.g., a MAC PDU) including a recovery request and a user data portion, the current base station may decide to keep the UE in an inactive state and transition to a subsequent data transmission mode. (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., an L1 and / or L2 message) to enable subsequent user data transmission. (Message 2220 may be, for example, MSG4 of a random access procedure.) Message 2220 may include a CR MACCE and an indication that the UE should enter a subsequent transmission mode while remaining in an inactive state. (CR is an acronym for contention resolution.) In response to receiving message 2220, the UE may enter a subsequent transmission mode and perform subsequent user data transmission and / or reception using a subsequent transmission configuration that was provided in a previous connection mode or provided via a broadcast from the network (e.g., from the current base station). In response to receiving an L1 confirmation or UE uplink data from the UE via the configuration, the network may deem the transmission successful.

[0212] Fig.23 - Method for operating a user equipment (UE) device

[0213] In one set of embodiments, a method 2300 for operating a user equipment (UE) device may include: Fig.23 (The method 2300 may also include any subset of the above features, elements, or operations.) The method 2300 may be performed by a processing circuit of a UE device (eg, by a processing element 610 of the user equipment 600).

[0214] As shown at 2310, when 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 intent to perform user data transmission and / or reception with the network during the inactive state. The act of transmitting information to the network may include transmitting information to a current base station of the network (e.g., to a current gNB in ​​the context of 3GPP 5GNR).

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

[0216] In some embodiments, the information (or RRC message) transmitted at 2310 may include identification information that enables the network to identify the UE device and / or extract context information associated with the UE device, such as described in various ways above.

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

[0218] In some embodiments, the information transmitted at 2310 is a medium access control protocol data unit (MAC PDU) (or a portion of the MAC PDU), for example, as described above in various ways. The MAC PDU may include one or more sub-PDUs. One of the sub-PDUs of the MAC PDU (e.g., a first sub-PDU in the sub-PDU) may include an RRC message. Another sub-PDU in the sub-PDU (e.g., a second sub-PDU in the sub-PDU) may include the at least a portion of the user data.

[0219] In some embodiments, method 2300 may also include receiving a response message from the network while in the inactive state, wherein the response message causes a state transition in the UE device.

[0220] In some embodiments, the response message may be a release message (eg, a RRCRelease message) and may cause a state transition to an idle state.

[0221] In some embodiments, the response message may be a release message with a pause configuration and may cause a state transition to a traditional inactive state.

[0222] In some embodiments, the response message may be a resume message and may cause a state transition to a connected state.

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

[0224] In some embodiments, the response message may cause the UE device to remain in the 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, an addition to a portion of the user data mentioned at 2310) while remaining in the inactive state, for example, as described above in Figures 18 to 22 as described in the context of.

[0225] In some implementation schemes, the response message may implicitly indicate that the forwarding of the user data to the core network is successful.

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

[0227] In some embodiments, the non-transitory memory medium may store program instructions. The program instructions, when executed by the processing circuit, may cause the processing circuit to perform the method of the above method embodiments and any combination of those embodiments. The memory medium may be incorporated as part of a user equipment device.

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

[0229] In one set of embodiments, a method 2400 for operating a base station (BS) may include: Fig.24 (Method 2400 may also include any subset of the above features, elements, or operations.) The method may be executed by a processing circuit of a base station (eg, by processing element 710 of base station 700).

[0230] As shown at 2410, when a user equipment (UE) device is in an inactive state, 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 intent to perform user data transmission and / or reception with the network during the inactive state. (For example, the user data may originate from the UE device, for example, from an application executed on the UE device. Alternatively, the user data may originate from the network and it will be received by the UE device.)

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

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

[0233] 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 a data transmission (or small data transmission) as the cause.

[0234] In some embodiments, the message is (or is contained within) a Medium Access Control Protocol Data Unit (MAC PDU), eg, as variously described above.

[0235] In some embodiments, method 2400 may further include transmitting a response message to the UE device when the UE device is in the inactive state. The response message may cause a state transition in the UE device, for example, as described above.

[0236] In some embodiments, the response message may be a release message (eg, a RRCRelease message) and may cause a state transition to an idle state.

[0237] In some embodiments, the response message may be a release message (eg, a RRCRelease message) with a pause configuration and may cause a state transition to a legacy inactive state.

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

[0239] In some embodiments, the response message may be a setup message (eg, an RRCSetup message) and may cause a state transition to a connected state.

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

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

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

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

[0244] In some embodiments, the non-transitory 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 above method embodiments and any combination of those embodiments. The memory medium may be incorporated as part of a base station.

[0245] The embodiments of the present disclosure may be implemented in any of a variety of forms. For example, some embodiments may be implemented as computer-implemented methods, computer-readable storage media, or computer systems. Other embodiments may be implemented using one or more custom-designed hardware devices such as ASICs. Other embodiments may be implemented using one or more programmable hardware elements such as FPGAs.

[0246] In some embodiments, a non-transitory computer-readable storage medium may be configured such that it stores program instructions and / or data, wherein if the program instructions are executed by a computer system, the computer system is caused to perform a method, such as any one of the method embodiments described herein, or any combination of the method embodiments described herein, or any subset of any method embodiments described herein, or any combination of such subsets.

[0247] In some embodiments, the computer system may be configured to include a processor (or a group of processors) and a memory medium, wherein the memory medium stores program instructions, wherein the processor is configured to read and execute program instructions from the memory medium, wherein the executable program instructions are to implement any of the various method embodiments described herein (or any combination of the method embodiments described herein, or any subset of any method embodiments described herein, or any combination of such subsets). The computer system may be implemented in any of various forms. For example, the computer system may be a personal computer (in any of its various implementations), a workstation, a computer on a card, a dedicated 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.

[0248] By interpreting each message / signal X received in the downlink by a user equipment (UE) communicating with a base station (or transmission-reception point) as a message / signal X transmitted by the base station (or transmission-reception point), and interpreting each message / signal Y transmitted in the uplink by the UE as a message / signal Y received by the base station (or transmission-reception point), any of the methods for operating a UE described herein may become the basis for a corresponding method for operating a base station (or transmission-reception point).

[0249] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of the authorized use should be clearly stated to users.

[0250] Although the above embodiments have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to encompass all such variations and modifications.

Claims

1. A method comprising: encoding a first transmission to a network in a radio resource control (RRC) inactive state, the first transmission comprising an RRC recovery request message and first user data; performing subsequent user data exchange with the network while in the RRC inactive state; as well as An RRC release message with a suspend indication is received from the network.

2. The method according to claim 1, further comprising: In response to the first transmission, a message is received from the network enabling the subsequent exchange of user data with the network.

3. The method of claim 2, wherein the message used to enable the subsequent user data exchange with the network is msg 4 of a random access procedure.

4. The method of claim 1, wherein the first transmission is msg 3 of a random access procedure. The method of claim 1 , wherein the encoding the first transmission is triggered in response to a small data transmission (SDT) procedure. 6 . The method of claim 5 , wherein the SDT process is triggered in response to a condition being met, wherein the condition includes an amount of data available for transmission being less than a configured threshold.

7. The method of claim 5, wherein the SDT process comprises selecting a physical random access channel (PRACH) resource for transmission.

8. The method of claim 5, wherein the SDT process comprises selecting a pre-configured Physical Uplink Shared Channel (PUSCH) resource for transmission.

9. The method of claim 5, wherein said performing a subsequent user data exchange with said network while in said inactive state uses a subsequent transmission configuration provided from said network in a previous connection mode.

10. The method of claim 1, wherein the first transmission comprises: Buffer status report.

11. A device, comprising: A processor configured to, when executing instructions stored in the memory, perform operations including: encoding a first transmission to a network in a radio resource control (RRC) inactive state, the first transmission comprising an RRC recovery request message and first user data; performing subsequent user data exchange with the network while in the RRC inactive state; as well as An RRC release message with a suspend indication is received from the network.

12. The apparatus of claim 11, wherein the operations further comprise: In response to the first transmission, a message is received from the network enabling the subsequent exchange of user data with the network.

13. The apparatus of claim 12, wherein the message for enabling the subsequent user data exchange with the network is msg 4 of a random access procedure.

14. The apparatus of claim 13, wherein the first transmission is msg 3 of a random access procedure.

15. The apparatus of claim 11, wherein the encoding of the first transmission is triggered in response to a small data transmission (SDT) procedure.

16. A method comprising: receiving a first transmission from a user equipment UE in a radio resource control, RRC, inactive state, the first transmission comprising an RRC resume request message and first user data; performing subsequent user data exchange with the UE while the UE is in the RRC inactive state; as well as An RRC release message with a suspend indication is transmitted to the UE.

17. The method according to claim 16, further comprising: In response to the first transmission, a message is transmitted to the UE to enable the subsequent exchange of user data with the network.

18. The method of claim 17, wherein the message used to enable the subsequent user data exchange with the network is msg 4 of a random access procedure.

19. The method of claim 16, wherein the first transmission is msg 3 of a random access procedure.

20. The method of claim 16, wherein the first transmission is triggered in response to a small data transmission (SDT) procedure.

Images