CN113348724A

CN113348724A - Uplink communication in an inactive state in a cellular network

Info

Publication number: CN113348724A
Application number: CN201980089140.1A
Authority: CN
Inventors: 吴志祥; 周高鹏
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2018-11-16
Filing date: 2019-11-15
Publication date: 2021-09-03
Also published as: US20220014959A1; WO2020102685A1; EP3881643A1

Abstract

To reduce delay in uplink communications, the user equipment transmits first application data in an uplink direction while the user equipment is in a connected state associated with a protocol for controlling radio resources (1602), transitions to an inactive state associated with the protocol in response to a period of inactivity of the application data (1604), determines a channel configuration for uplink communications while the user equipment is in the inactive state (1606), and transmits further application data in the uplink direction to the base station according to the determined channel configuration while the user equipment is in the inactive state by the processing hardware before transmitting the request to transition to the connected state and after completing a process for synchronizing a radio link between the user equipment and the base station (1608).

Description

Uplink communication in an inactive state in a cellular network

Technical Field

The present disclosure relates to cellular communication, and more particularly, to configuring uplink transmission in a user equipment operating in a certain state.

Background

The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

The 4G-LTE Radio Resource Control (RRC) protocol specifies an RRC _ IDLE state in which a user equipment (commonly referred to as a user equipment or UE) does not have an active radio connection with a base station, and an RRC _ CONNECTED state in which the UE has an active radio connection with the base station. The 5G protocol introduces an intermediate state RRC _ INACTIVE to allow the UE to transition back to the RRC _ CONNECTED state more quickly due to Radio Access Network (RAN) level base station coordination and RAN paging procedures. When the UE is in RRC _ INACTIVE state, the UE must transition to RRC _ CONNECTED state in order to start transmitting data in the uplink direction. To this end, the UE must perform an RRC recovery procedure that requires the UE to send a RRCResumeRequest (RRC recovery request) message to the base station, receive a RRCResume (RRC recovery) command from the base station in response, and send a RRCResumeComplete (RRC recovery complete) message to the base station to confirm the state transition completion. Sending the RRCResumeRequest message in turn requires the UE to first perform a random access procedure (by sending a random access preamble to the base station and receiving a random access response) or otherwise synchronize the radio link between the UE and the base station.

Disclosure of Invention

In general, the UE of the present disclosure reduces delay in uplink transmission of application data in a particular state associated with a protocol for controlling radio resources between the UE and a base station. As used herein, the term "application data" refers to data from a protocol layer above a protocol layer used to control radio resources (e.g., RRC). The application data may comprise, for example, internet traffic data or voice/video call data. The UE may exchange application data with the base station in the first state and transition to a particular (second) state due to a period of inactivity for data transmission. When new application data is available for uplink transmission in the second state, the UE omits a procedure for synchronizing a radio link between the UE and the base station, a procedure for transitioning the UE back to the first state, or both.

The base station may provide the UE with a channel configuration for uplink communications, which may include an indication of what procedures the base station supports when the UE is in the second state. In various implementations of these techniques, the base station notifies the UE when a radio connection is released (e.g., via a rrcreelease (RRC release) message), when radio resources are reconfigured (e.g., via a rrcreeconfiguration (RRC reconfiguration) message), or when information is provided about a cell that the UE has recently selected. In a third case, the UE may transition from the first state to the second state after exchanging application data with the first base station, select a new cell of the second base station, and receive information about the new cell from the second base station (e.g., via a systemlnformationblock element).

To omit the procedure for synchronizing the radio link between the UE and the base station, in some cases, the UE receives a non-orthogonal multiple access (NOMA) configuration, which may include a configured grant, as part of a channel configuration for uplink communications. The UE may then use the NOMA configuration to access the radio channel and either continue sending application data directly or, in some cases, send a message to resume the RRC connection. In another case, the UE receives an uplink grant on a Physical Downlink Control Channel (PDCCH) and transmits a RRCResumeRequest message using the uplink grant.

The base station may receive a NOMA configuration, or more broadly, channel access data that allows the UE to skip the procedure for synchronizing the radio link, from another base station or core network or an operation and maintenance (O & M) server. In another implementation, the base station may be preconfigured with this information.

An example embodiment of these techniques is a method in a user equipment for uplink communication. The method may be run by processing hardware of a user equipment and include transmitting first application data in an uplink direction when the UE is in a first state associated with a protocol for controlling radio resources; in response to a period of inactivity of the application data, transitioning to a second state associated with the protocol; determining a channel configuration for uplink communication when the user equipment is in the second state; and transmitting further application data to the base station in the uplink direction according to the determined channel configuration.

Another example embodiment of these techniques is a non-transitory medium having stored thereon instructions that, when executed by processing hardware of a user equipment, cause the user equipment to perform the above-described method for uplink communication.

Yet another embodiment of the techniques is a method in a base station for reducing delay in uplink communications. The method may be run by processing hardware of a base station and include determining a channel configuration for uplink communications from a user equipment, the user equipment having transitioned from a first state in which the user equipment sent first application data to the base station to a second state in response to a period of application data inactivity, the first state and the second state being associated with a protocol for controlling radio resources; transmitting, to the user equipment, a channel configuration for uplink communication from the user equipment; further application data sent from the user equipment is received according to the channel configuration.

Another example embodiment of these techniques is a non-transitory medium having instructions stored thereon, which when executed by processing hardware of a base station, cause the base station to perform the above-described method for uplink communication.

Drawings

Fig. 1 is a block diagram of an example wireless communication network in which user equipment and base stations of the present disclosure may implement techniques of the present disclosure for reducing delay in uplink transmissions.

Fig. 2 illustrates example processing hardware of the user device of fig. 1.

3-15 illustrate several example scenarios and methods among one or more components shown in FIG. 1, in particular:

fig. 3 is a messaging diagram of an example scenario in which a user equipment receives a channel configuration for uplink transmission in a command to release a radio connection and then transmits uplink application data in an RRC _ INACTIVE state according to the received channel configuration;

fig. 4 is a messaging diagram of an example scenario in which a user equipment receives a channel configuration for uplink transmission in a command to reconfigure a radio connection and then transmits uplink application data in an RRC _ INACTIVE state according to the received channel configuration;

fig. 5 is a messaging diagram of an example scenario in which a user equipment receives a channel configuration for uplink transmission in a system information block for a newly selected or reselected cell and transmits uplink application data in an RRC _ INACTIVE state according to the received channel configuration;

fig. 6 is a messaging diagram of an example scenario in which a user equipment receives a channel configuration for uplink transmission (including a non-orthogonal multiple access (NOMA) configuration) in a command to release a radio connection and then transmits uplink application data or initiates a procedure to recover the radio connection in an RRC _ INACTIVE state according to the received channel configuration;

fig. 7 is a messaging diagram of an example scenario in which a user equipment receives a channel configuration for uplink transmission (including a NOMA configuration) in a command to reconfigure a radio connection, and then transmits uplink application data in an RRC _ INACTIVE state or initiates a procedure for restoring the radio connection according to the received channel configuration;

fig. 8 is a messaging diagram of an example scenario in which a user equipment receives channel configurations (including NOMA configurations) for uplink transmissions in a system information block for a newly selected or reselected cell, omits procedures for synchronizing radio links according to the received channel configurations, and transmits uplink application data in an RRC _ INACTIVE state.

Fig. 9 is a messaging diagram of an example scenario in which a user equipment receives a channel configuration for uplink transmissions (including a NOMA configuration) in a system information block for a newly selected or reselected cell, and initiates a procedure for restoring a radio connection in accordance with the received channel configuration;

fig. 10 is a messaging diagram of an example scenario in which a first base station sends a NOMA configuration to a user equipment, which the user equipment subsequently uses in uplink communications to a second base station that also stores the NOMA configuration;

fig. 11 is a messaging diagram of an example scenario in which a first base station and a second base station receive a NOMA configuration from an operations and maintenance (O & M) server, and the first base station sends the NOMA configuration to a user equipment;

fig. 12 is a messaging diagram of an example scenario in which a first base station sends a NOMA configuration to a user equipment and a second base station;

fig. 13 is a messaging diagram of an example scenario in which a first base station sends a NOMA configuration to a user equipment and to an O & M server, which in turn sends the NOMA configuration to a second base station;

fig. 14 is a flow diagram of an example method in a user equipment for determining a channel configuration for uplink communications and using the channel configuration to omit a procedure for synchronizing a radio link between the user equipment and a base station, a procedure for restoring a radio connection, or both procedures; and

fig. 15 is a flow diagram of an example method in a user equipment for receiving a channel configuration for uplink communication from a first base station and using the channel configuration to omit a procedure for synchronizing a radio link between the user equipment and a second base station, a procedure for restoring a radio connection, or both procedures.

Fig. 16 and 17 illustrate example methods that may be implemented in any suitable user equipment or suitable base station, specifically:

fig. 16 is a flow diagram of an example method in a user equipment for reducing delay in uplink communications; and

fig. 17 is a flow diagram of an example method in a base station for reducing delay in uplink communications.

Detailed Description

As discussed in detail below, the user equipment and base station of the present disclosure implement certain techniques for reducing the delay of transmission of application data in the uplink direction (i.e., from the user equipment to the base station). These techniques allow a user equipment operating in the RRC _ INACTIVE state in some cases to omit: a procedure for synchronizing a radio link between the user equipment and the base station, a procedure for recovering the RRC connection and transitioning to an RRC _ ACTIVE state, or both. Although the following examples refer primarily to 5G NR base stations, components connected to 5G NR base stations, and NR air interfaces, the techniques of this disclosure may be applied generally to other types of networks where user equipment implements certain states of a protocol for controlling radio resources.

Referring to fig. 1, a UE 102 may operate in a wireless communication network 100 including a first 5G NR base station 104 and a second 5G NR base station 106. Each of

base stations

104 and 106 may be implemented as a next generation node b (gnb). The

base stations

104 and 106 may be connected to a 5G core network (5GC)112 and an operations and maintenance (O & M) server 114, and the 5GC 112 may be connected to the internet 118.

Base station 104 covers NR cell 120 and base station 106 covers NR cell 122. Cell 120 and cell 122 may be located in the same radio access network notification area (RNA) or in different RNAs. In general, the wireless communication network 100 may include any number of base stations, and each base station may cover one, two, three, or any other suitable number of cells. UE 102 may support at least a 5G NR (or simply "NR") air interface to communicate with

base stations

104 and 106. Base station 104 and base station 106 may also be interconnected via an interface 126, which interface 126 may be an Xn interface for interconnecting NG radio access network (NG-RAN) nodes (i.e., the gNB).

The base station 104 is equipped with processing hardware 130, which processing hardware 130 may include one or more general-purpose processors (e.g., CPUs), and non-transitory computer-readable memory storing instructions for execution by the one or more general-purpose processors. Additionally or alternatively, the processing hardware 130 may include a dedicated processing unit. In an example implementation, the processing hardware 130 includes a low-latency configuration controller 134, the low-latency configuration controller 134 configured to determine, receive, transmit, etc., a channel configuration for uplink transmissions according to which the UE 102 may transmit application data in the uplink direction under certain scenarios. The processing hardware may also include an RRC controller 136 to implement procedures and messaging at the RRC sublayer of the protocol communication stack. Base station 106 may include substantially similar components.

Next, fig. 2 depicts various components of UE 102. In particular, the UE 102 may be equipped with processing hardware 200, the processing hardware 200 including one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions for execution by the one or more general-purpose processors. Additionally or alternatively, the processing hardware 200 may comprise a dedicated processing unit.

The processing hardware 200 may include an RRC controller 202, a Mobility Management (MM) controller 204, a Session Management (SM) controller 206, an internet application 208, and a Protocol Data Unit (PDU) session controller 210. Each of the

controllers

202, 204, and 206 is responsible for inbound messaging, outbound messaging, and internal processes at the corresponding layer of the protocol stack 250. In addition to supporting messaging external to UE 102,

controllers

202, 204, and 206 may, for example, exchange internal messages with each other and with other components of UE 102 (such as application 208). Each of the

controllers

202, 204, 206, 208, and 210 may be implemented using any suitable combination of hardware, software, and firmware. In one example implementation, the

controllers

202, 204, 206, 208, and 210 are sets of instructions that define various components of the operating system of the UE 102, and one or more CPUs execute these instructions to perform the corresponding functions. In another implementation, some or all of the

controllers

202, 204, 206, 208, and 210 are implemented using firmware that is part of a wireless communication chipset.

The protocol stack 250 includes a physical layer 260 (often abbreviated PHY), a Medium Access Control (MAC) layer 262, a Radio Link Control (RLC) layer 264, a Packet Data Convergence Protocol (PDCP) sublayer 266, a Service Data Adaptation Protocol (SDAP) sublayer 267, and an RRC sublayer 268 that is part of an access layer 270. The sequence of these layers is shown in figure 2. The non-access stratum 280 of the protocol stack 250 includes, among other sub-layers: for example, the MM sublayer 272 for exchanging registration/attachment and location update related messages; and an SM sublayer 274 for exchanging messages related to PDU session establishment, PDU session modification, PDU session authentication, and PDU session release, for example. The MM sublayer may correspond to the 5G MM (5GMM) sublayer of a fifth generation system (5GS) NAS procedure. The protocol stack 250 may also support higher layer protocols for various services and applications including, for example, a TCP/IP and UDP/IP layer 282 and a set of protocols 284 for communicating downlink and uplink application data. The

controllers

202, 204, and 206 generate outbound messages and process inbound messages corresponding to the layers or

sub-layers

268, 272, and 274, respectively, as schematically illustrated in fig. 2.

Controllers

202, 204, 206, 208, and 210 also perform processes internal to UE 102.

After the successful establishment of the PDU session by the SM controller 206, the PDU session controller 210 may send and receive application data packets from various applications and services operating in the UE 102, including the application 208, over TCP/IP, UDP/IP, HTTP/TCP, and so on. For example, the internet application 208 may be a Web (Web) browser, a mail application, a chat application, an audio player application, a video conferencing application, or any other type of internet application, and thus the internet application data at layer 284 may include packets related to mailing services, social networks, audio and video streaming, internet searches, online games, and so forth. In addition, PDU session controller 210 may also support any other type of application data, such as, for example, Session Initiation Protocol (SIP) packets for IP Multimedia Subsystem (IMS) voice calls or IMS video calls.

Next, several example scenarios involving several components of fig. 1 and relating to reducing delay in uplink communications are discussed with reference to fig. 3-15.

Referring first to fig. 3, in this example scenario, UE 102 initially operates 302 in an RRC _ CONNECTED state in cell 120 of gNB 104. In this state, UE 102 transmits 312 application data to gNB104 in the uplink direction and receives 310 application data from gNB104 in the downlink direction. For example, the application data may include PDUs associated with the PDCP sublayer 266 (see fig. 2).

After a certain period of application data inactivity, the gNB104 may determine 320 that the UE 102 has been data inactive. For example, if neither gNB104 nor UE 102 transmit any application data in the downlink or uplink directions, respectively, during a particular time interval, gNB104 may make this determination. After the gNB104 determines that the UE 102 has been data INACTIVE, the gNB may optionally perform a procedure 322 (discussed below) and send 332 a rrcreelease message to the UE 102 and instruct the UE 102 to transition to the RRC _ INACTIVE state. In particular, the rrcreelease message may include a suspendeconfig IE that transitions the UE 102 to an RRC _ INACTIVE (rather than an RRC _ IDLE) state. Accordingly, the UE 102 transitions 334 to the RRC _ INACTIVE state upon receiving the rrcreelease message. The rrcreelease message includes a channel configuration for uplink communications that the UE 102 may use to transmit further application data.

In general, a channel configuration for uplink communications for a cell may indicate what type of message the base station of the cell may receive from a user equipment in an RRC _ INACTIVE state, and in some cases, channel access data that the user equipment may use to send data and/or messages to the base station in the RRC _ INACTIVE state. More specifically, when the user equipment is in RRC _ INACTIVE state, the channel configuration for uplink communication may indicate whether the cell supports uplink transmission of application data (e.g., PDUs): in other words, whether the base station of the cell requires the UE 102 to perform a procedure for transitioning to the RRC _ CONNECTED state (which may include exchanging messages with the base station to restore radio connection) or support omitting the procedure before sending further application data in the uplink direction. Further, the channel configuration for uplink communication may enable (enable) and/or configure the user equipment to use uplink transmission of application data in RRC _ INACTIVE state. The channel configuration for uplink communication may indicate whether the base station requires the user equipment to perform a procedure for synchronizing a radio link between the user equipment and the base station in an RRC _ INACTIVE state or whether the user equipment may omit the procedure. In some cases, when the base station indicates that the user equipment may omit the procedure for synchronizing the radio link, the user equipment may use previously received channel access data (e.g., uplink grant) to send application data or RRC messages to the base station. In some scenarios, the channel configuration for uplink communications includes channel access data.

The gNB104 may indicate to the UE 102, via a channel configuration for uplink communications that may include a particular dedicated field with a particular value (e.g., "1") indicating that the feature is supported and another value (e.g., "0") indicating that the feature is not supported in the cell, whether the cell 120 supports uplink transmission of application data in the RRC _ INACTIVE state. As an alternative, the gNB104 may include this field to indicate that the feature is supported and omit this field to indicate that the feature is not supported. Further, in some implementations, the gNB104 uses one field to indicate whether the cell supports the omitted random access procedure and another field to indicate whether the cell supports the omitted RRC recovery procedure, while in other implementations, the gNB104 uses a single field to indicate support or non-support of these features.

Furthermore, in some cases, gNB104 may provide a channel configuration for uplink communication for a particular RNA rather than an individual cell. For example, cell 120 and cell 122 may be in the same RNA, and gNB104 may indicate support for uplink transmission of application data in an RRC _ INACTIVE state for the RNA in a channel configuration sent in an RRC message or system information block for uplink communication, as discussed in more detail below. The UE 102 may determine that the cell 120 supports uplink transmission of application data in the RRC _ INACTIVE state based on the channel configuration for uplink communication. Further, when the UE 102 selects or reselects the cell 122, the UE 102 may determine that the cell 122 also supports uplink transmission of application data in the RRC _ INACTIVE state based on a previously received channel configuration for uplink communication.

In the example of fig. 3 and the example of fig. 6 discussed below, the gNB104 provides the channel configuration for uplink communications via a rrcreelease message. However, in other scenarios, gNB104 may provide the channel configuration for uplink communication via another RRC message (e.g., rrcreeconfiguration message, see fig. 4 and 7), or gNB 106 may provide the channel configuration for uplink communication for cell 122 in a system information block of the cell (see fig. 5, 8, and 9). In these scenarios, the gNB104 may or may not include the channel configuration for uplink communications in the rrcreelease message. In some cases, the gNB104 may include a portion of the channel configuration for uplink communications in one of the rrcreelease message, rrcreeconfiguration message, or system information block, and the remainder of the channel configuration for communications in another one of the rrcreelease message, rrcreeconfiguration message, or system information block.

In some implementations, the gNB104 performs an optional procedure 322 to determine the capabilities of the UE 102 with respect to uplink communications in the RRC _ INACTIVE state. For example, the gNB104 may send 324 a UE Capability inquiry message to the UE 102 specifying "NR" as a parameter, and the UE 102 may send 326 the UE Capability inquiry message with a UE-NR-Capability Information Element (IE) in response. The IE may include an indication of whether the UE 102 is configured to omit RRC recovery procedures, whether the UE 102 is configured to omit procedures for synchronizing radio links (e.g., random access procedures), and so on. The UE 102 may encode these indications as a single field or separate fields depending on the implementation and in any suitable format (e.g., using the NR RRC asn.1 format). The UE-NR-Capability IE may indicate (signal) support of a feature by including a corresponding field in the IE, and thus may indicate non-support of a feature by not including a corresponding field in the IE. In other implementations, some values of these fields may indicate support, while other values may indicate no support. Further, optional process 322 may include: the gNB104 sends a message to an Access and Management Function (AMF) of the 5GC 112, the message including the UE-NR-Capability IE received from the UE 102 or another IE conveying this information. It should be noted that the gNB104 may alternatively perform the optional procedure 322 at a different time (e.g., when configuring or reconfiguring an RRC connection with the UE 102), e.g., before determining 320 that the UE 102 is data inactive.

Further, in other scenarios, the gNB104 may receive an indication of which procedures the UE 102 supports in the RRC _ INACTIVE state, which procedures the UE 102 may omit in the RRC _ INACTIVE state, etc., from the AMF in the 5GC 112 in a handover request message or an initial context setup request message. Still further, gNB104 may receive the indication from another gNB (such as gNB 106) in a handover request message.

Thus, when the capabilities of UE 102 are known to gNB104, gNB104 may determine a channel configuration for uplink communications of UE 102, either for the capabilities/cell 120 configuration of gNB104 alone, or for both the capabilities/cell 120 configuration of gNB104 and the capabilities of UE 102.

In the example of fig. 3, the channel configuration for uplink communications from the gNB104 configures the UE 102 for uplink application data transmission in the RRC _ INACTIVE state, but does not configure the UE 102 to skip the random access procedure. When the UE 102 initiates 340 an application data transmission in the RRC _ INACTIVE state (e.g., when the internet application 208 determines that there is new application data to send to the host over the internet 118), the UE 102 does so according to the received channel configuration for uplink communications.

In particular, UE 102 transmits 350 a random access preamble to the gNB104 in NR cell 120. The gNB104 responds 352 with a random access response including an uplink grant. UE 102 then omits the RRC recovery procedure and sends 370 further application data to the gNB104 using the received uplink grant while remaining in the RRC _ INACTIVE state. UE 102 may also receive application data transmitted by the gNB104 in the downlink direction in the RRC _ INACTIVE state.

Next, fig. 4 shows an example scenario in which the UE 102 receives the channel configuration for uplink transmission in the rrcreeconfiguration command. Similar to the scenario of fig. 3, the UE 102 initially operates 302 in an RRC _ CONNECTED state in which the UE 102 transmits 412 application data in the uplink direction and receives 410 application data transmitted by the gNB104 in the downlink direction.

The gNB104 determines a channel configuration for uplink communications for the UE 102 based on the capabilities of the gNB104 and, in some cases, the capabilities of the UE 102 (e.g., when the gNB104 performs the optional procedure 322 discussed above, or receives an indication of the NR capabilities of the UE 102 from the 5GC 112, the gNB 106, or another network entity). The gNB104 sends 414 to the UE 102 a rrcconfiguration including a channel configuration for uplink communication, and the UE 102 responds 416 with a rrcconfiguration complete. In this example scenario, gNB 106 configures UE 104 to omit the RRC recovery procedure, but does not omit the random access procedure.

After the gNB104 determines 420 that the UE 102 has been data inactive, the gNB104 sends 432 a rrcreelease message that need not include a channel configuration for uplink communications, unlike the rrcreelease message in fig. 3. Next, similar to the scenario of fig. 3, the UE 102 transitions 434 to the RRC _ INACTIVE state upon receiving the rrcreelease message; initiating 440 an application data transmission in an RRC _ INACTIVE state; sending 450 a random access preamble to the gNB104 and receiving 452 an uplink grant in a random access response; and sending 470 further application data to the gmb 104 while in RRC _ INACTIVE state.

Referring to fig. 3 and 4, the UE 102 may select or reselect a new cell at a later time (i.e., after transmitting 370 or 470 application data). In the present disclosure, "selection" as applied to a cell may refer to selecting a cell in the initial case or reselecting a cell according to cell reselection criteria. For example, UE 102 may select cell 122 of gNB 106.

According to one implementation, UE 102 releases the channel configuration for uplink communications received from the gNB104 upon selection/reselection. Thus, even though the gNB104 has configured the UE 102 to omit the RRC recovery procedure, the UE 102 performs both the random access procedure and the RRC recovery procedure after selecting the cell 122. More specifically, UE 102 transmits a random access preamble to gNB 106 in the newly selected cell, receives a random access response with an uplink grant from gNB 106, and transmits a RRCResumeRequest message to gNB 106. After the gNB 106 responds with the RRCResume command, the UE 102 transitions to the RRC _ CONNECTED state and sends a RRCResumeComplete message to the gNB 106. UE 102 then transmits the application data to gNB 106.

However, according to another implementation, the UE 102 reserves the channel configuration for uplink communications when selecting a new cell. For example, after selecting the cell 122, the UE 102 only performs a random access procedure. More specifically, UE 102 transmits a random access preamble to gNB 106, receives a random access response with an uplink grant from gNB 106, and transmits application data to gNB 106 using the uplink grant without performing an RRC recovery procedure. The UE 102 may remain in the RRC _ INACTIVE state.

As another example, a UE 102 operating in an RRC _ INACTIVE state may receive a paging message from a gNB (e.g., gNB104, gNB 106, or another gNB) that includes a core network identification (e.g., NG-5G-S-TMSI IE) of the UE 102 and transition from the RRC _ INACTIVE state to an RRC _ IDLE state in response (such that, in response to the paging message, the UE 102 subsequently initiates an RRC setup procedure to send a NAS service request message to the gNB). The UE 102 may release a previously received channel configuration for uplink communications upon transitioning to an RRC IDLE state or in response to an RRC establishment procedure. The UE 102 may release other previously received configurations upon transitioning to the RRC IDLE state or in response to an RRC establishment procedure.

In the scenario of fig. 5, the UE 102 receives a channel configuration for uplink transmission in a system information block for a newly selected cell. At the beginning of the scenario, UE 102 operates in cell 120 and exchanges 518 application data with gNB 104. The UE 102 then receives the rrcreelease message. The UE 102 transitions 534 to the RRC _ INACTIVE state and then selects 536 a new 5G NR cell, in particular cell 122 of the gNB 106.

UE 102 receives 538 a systemlnformationblock message from the gNB 106 that includes a channel configuration for uplink transmission. In view of the capabilities of gNB 106 and, in some cases, the NR capabilities of UE 102 (e.g., the capabilities that gNB 106 may receive from 5GC 112 or gNB 104), gNB 106 may determine a channel configuration for uplink transmissions.

For clarity, fig. 5 further shows two different examples, where the UE 102 sends application data in the uplink direction after initiating 540 a data transmission when the UE 102 is in the RRC _ INACTIVE state. In a first example, gNB 106 configures UE 102 to transmit uplink data while maintaining RRC _ ACTIVE state, such that UE 102 omits the RRC recovery procedure; in a second example, gNB 106 configures UE 102 to not transmit uplink data when operating in the RRC _ ACTIVE state, so UE 102 performs an RRC recovery procedure. In both instances, the gNB 106 configures the UE 102 to not omit the random access procedure. Thus, in both instances, the UE 102 first synchronizes the radio link and for this purpose sends 550 a random access preamble and receives 552 a random access response. In one implementation, the UE 102 selects a random access preamble from a plurality of random access preambles configured in the systemlnformationblock or in another systemlnformationblock broadcast by the gNB 106.

In a first example, the UE 102 determines 554 that it does not need to perform an RRC recovery procedure and sends 570 application data in the uplink direction. In one implementation, the UE 102 sends 570 the application data using the uplink grant included in the random access response. In another implementation, the UE 102 uses a previously received channel configuration for uplink transmission to send 570 the application data. In this implementation, the UE 102 may send 570 the application data before or after receiving the random access response. In a second example, the UE 102 determines 556 that it must perform an RRC recovery procedure before transmitting the uplink application data. Thus, the UE 102 sends 560 a RRCResumeRequest message using the uplink grant included in the random access response, receives 562 a rrcreesume command in response, transitions 564 to an RRC _ CONNECTED state, and sends 566 a rrcreesumplete message in response to the rrcreesume command. UE 102 then transmits 590 the application data to the gNB in RRC _ CONNECTED state. Because RRCResume commands to resume operation of a certain Data Radio Bearer (DRB), the UE 102 may use the resumed DRB to send 590 application data. In

steps

370, 470 or 570, the UE 102 may transmit the application data using a control plane or user plane protocol. In one example, UE 102 may include application data in a MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU and send the MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU to gNB 104. In another example, UE 102 can include the application data in an RRC message (e.g., an RRC data request message) or a NAS message (e.g., a NAS data transport message) and send the RRC message or NAS message to gNB 104.

Thus, when the gNB104 or 106 indicates support of uplink transmission in the RRC _ INACTIVE state, the UE 102 omits the RRC recovery procedure but performs the random access procedure in the scenarios of fig. 3-5. Fig. 6-9 next illustrate a case where the UE 102 may omit the random access procedure and the RRC recovery procedure, or omit the random access procedure but perform the RRC recovery procedure in some cases.

Referring first to fig. 6, UE 102 initially operates 602 in an RRC _ CONNECTED state in cell 120 of gNB 104. Similar to the scenario of fig. 3, the UE 102 sends 612 and receives 610 application data, the gNB104 determines 620 at some point that the UE 102 has been data INACTIVE, and sends 632 a rrcreelease message, and the UE 102 transitions 634 to an RRC _ INACTIVE state. The rrcreelease message includes a channel configuration for uplink communication. In some cases, the gNB104 and the UE 102 may also perform the optional procedure 322 discussed above. In this example, the channel configuration for uplink communications includes a NOMA configuration with an uplink grant.

In one example implementation, the NOMA configuration may include one or more Multiple Access (MA) signatures. The NOMA scheme may include one or more MA signatures, wherein each MA signature may include a combination of: channel coding, bit-level scrambling, bit-level interleaving, symbol-level spreading, symbol-level scrambling, symbol-level interleaving without zero padding, power allocation, sparse Resource Element (RE) mapping, and multiplexing with a preamble and demodulation reference signals (DMRS). In another implementation, the NOMA configuration includes configuration resources in the time and frequency domains in addition to one or more MA signatures. For example, the NOMA configuration specifies a position, slot, or subframe of an OFDM symbol and subcarriers, resource elements, or resource blocks for the UE 102 to transmit data using the NOMA transmission scheme. However, according to another example implementation, the NOMA configuration does not include resources in the time and frequency domains. In this case, the gNB104 may send the configured uplink grant to the UE 102 operating in the RRC _ CONNECTED state on the PDCCH.

With one example type of NOMA configuration, the gNB104 configures the UE 102 to omit RRC recovery procedures as well as channel access procedures. After the UE 102 transitions 634 to the RRC _ INACTIVE state, the UE 102 initiates 640 transmission of application data in the uplink direction. In this example, the UE 102 omits the random access procedure (or more generally, the procedure for synchronizing the radio link with the gNB 104) and the RRC recovery procedure according to the received NOMA configuration determination 642. The UE 102 therefore sends 644 application data to the gNB104 using the uplink grant included in the NOMA configuration.

In another example, the UE 102 determines 660 to omit the random access procedure (or more broadly, the procedure for synchronizing the radio link with the gNB 104) instead of the RRC recovery procedure, according to the received NOMA configuration. UE 102 thus sends 662 a RRCResumeRequest message to gNB104 using the NOMA configuration, receives 664 rrcreesume command in response, transitions back 666 to RRC _ CONNECTED state, and sends 668 a RRCResumeComplete message to gNB104 to notify gNB104 of the state transition. UE 102 then sends 670 the application data to the gNB 104.

According to one example, the UE 102 sends 662 a RRCResumeRequest message to the gNB104 using an uplink grant included in the NOMA configuration. In another example, UE 102 sends 662 rrcresumrequest message using an uplink grant sent by the gNB104 on the PDCCH. Similarly, the UE 102 may send 644 or 670 application data using an uplink grant included in the NOMA configuration or received on the PDCCH. In a second example, the UE 102 may send 670 the application data using the DRB resumed by the RRCResume command. In step 644, the UE 102 may transmit the application data using a control plane or user plane protocol. In one example, UE 102 may include application data in a MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU and send the MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU to gNB 104. In another example, UE 102 can include the application data in an RRC message (e.g., an RRC data request message) or a NAS message (e.g., a NAS data transport message) and send the RRC message or NAS message to gNB 104. In step 670, the UE 102 sends the application data using a user plane protocol. In one example, UE 102 may include application data in a MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU and send the MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU to gNB 104.

The scenario of fig. 7 is substantially similar to the scenario of fig. 6, except that here the UE 102 receives the channel configuration for uplink transmission (including NOMA configuration) in the RRCReconfiguration command. Thus, rrcreelease need not include a channel configuration for uplink transmission.

In particular, as shown in fig. 7, the UE 102 initially operates 702 in an RRC _ CONNECTED state; application data is received 710 and transmitted 712 in the uplink direction and the downlink direction, respectively. The gNB104 sends 714 a RRCReconfiguration command with the channel configuration for uplink transmission. In this example, the channel configuration for uplink transmissions comprises a NOMA configuration, which in turn may comprise an uplink grant, similar to the channel configuration for uplink transmissions that the gNB104 sends 632 in a rrcreelease message in the case of fig. 6. UE 102 responds 716 with an RRCConfigurationComplete message. At some point, the gNB104 determines 720 that the UE 102 has been data inactive and sends 732 a rrcreeal message. Similar to the example of fig. 6, the UE 102 transitions 734 to an RRC _ INACTIVE state, initiates 740 transmission of application data in the uplink direction, omits 742RRC recovery along with the random access procedure, and sends 750 the application data in the RRC _ INACTIVE state in one example, and omits 760 the random access procedure only and not the RRC recovery procedure in another example. In the latter example, UE 102 sends a 762 rrcresemequest message, in response to receiving 764 a rrcresemue command, transitions back 768 to an RRC _ CONNECTED state, and sends 766 a rrcresemecomplete message to gNB104 before sending 770 further application data to gNB 104. Also similar to the scenario of fig. 6, the UE 102 may send a RRCResumeRequest message or application data using an uplink grant included in the NOMA configuration or an uplink grant received on the PDCCH. Further, in some cases, the optional procedure 322 may be performed by the gNB104 prior to the rrcreeconfiguration command so that the gNB104 may determine the channel configuration for uplink transmissions in view of the NR capabilities of the UE 102. In step 750, the UE 102 may transmit the application data using a control plane or user plane protocol. In one example, UE 102 may include application data in a MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU and send the MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU to gNB 104. In another example, UE 102 can include the application data in an RRC message (e.g., an RRC data request message) or a NAS message (e.g., a NAS data transport message) and send the RRC message or NAS message to gNB 104. In step 770, the UE 102 transmits the application data using a user plane protocol. In one example, UE 102 may include application data in a MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU and send the MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU to gNB 104.

Referring now to fig. 8, similar to the scenario of fig. 5, in this example scenario UE 102 receives a channel configuration for uplink transmission in the system information block of newly selected cell 122 of gNB 106, but in this case, gNB 106 provides UE 102 with a NOMA configuration that allows UE 102 to omit the random access procedure (and in some cases also the RRC recovery procedure).

At the beginning of the scenario, UE 102 exchanges 818 application data with the gNB104 in cell 120 and receives a rrcreelease message. The UE 102 transitions 834 to an RRC _ INACTIVE state and then selects 836 gbb 106 cell 122. UE 102 then receives 838 a systemlnformationblock message from gNB 106 with the channel configuration (including NOMA configuration) for uplink transmission. The gNB 106 may determine a channel configuration for uplink transmissions in view of capabilities of the gNB 106 and, in some cases, NR capabilities of the UE 102 (e.g., capabilities that the gNB 106 may receive from the 5GC 112 or the gNB 104). The UE 102 then initiates 840 a data transmission while in the RRC _ INACTIVE state.

In a first example, UE 102 determines 854gNB 106 to support application data transmission in the uplink direction in the RRC _ INACTIVE state in cell 122. The UE 102 also determines: the channel configuration for uplink transmission received in the systemlnformationblock message configures the UE 102 to omit both the random access procedure and the RRC recovery procedure. UE 102 sends 870 the application data to the gNB 106 using the NOMA configuration included in the systemlnformationblock message in the first instance.

In a second example, the UE 102 determines 856 based on the channel configuration for uplink transmission received in the systemlnformationblock message: the UE 102 must perform an RRC recovery procedure before transmitting uplink application data and also perform a random access procedure before transmitting the RRC recovery procedure. UE 102 thus transmits 850 a random access preamble to gNB 106, receives 852 a random access response with an uplink grant from gNB 106, transmits 860 a RRCResumeRequest message to gNB 106 using the received uplink grant, receives 862 a RRCResumeRequest command in response, transitions back 864 to an RRC _ CONNECTED state, and transmits 866 a RRCResumeComplete message to gNB 106. The UE 102 then transmits 890 the application data to the gNB in the RRC _ CONNECTED state. Because the rrcreesume command resumes operation of a certain Data Radio Bearer (DRB), the UE 102 can send 890 application data using the resumed DRB. In step 870, the UE 102 may transmit the application data using a control plane or user plane protocol. In one example, UE 102 may include application data in a MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU and send the MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU to gNB 104. In another example, UE 102 can include the application data in an RRC message (e.g., an RRC data request message) or a NAS message (e.g., a NAS data transport message) and send the RRC message or NAS message to gNB 104. In step 890, the UE 102 transmits the application data using a user plane protocol. In one example, UE 102 may include application data in a MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU and send the MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU to gNB 104.

Next, fig. 9 shows another example scenario in which the UE 102 receives a channel configuration for uplink transmission in a system information block for the newly selected cell 122, including a NOMA configuration.

Similar to the scenario of fig. 8, the UE 102 exchanges 918 application data with the gNB104 in the cell 120, receives a rrcreelease message, transitions 934 to an RRC _ INACTIVE state, and then selects 936 the cell 122 of the gNB 106. The UE 102 then receives 938 a systemlnformationblock message from the gNB 106 with the channel configuration (including NOMA configuration) for the uplink transmission. The gNB 106 may determine a channel configuration for uplink transmissions in view of capabilities of the gNB 106 and, in some cases, NR capabilities of the UE 102 (e.g., capabilities that the gNB 106 may receive from the 5GC 112 or the gNB 104). The UE 102 then initiates 940 a data transmission in the RRC _ INACTIVE state.

In a first example, UE 102 determines 954, based on the received channel configuration for uplink transmission: the gNB 106 supports application data transmission in the uplink direction in the RRC _ INACTIVE state. The UE 102 also determines: the channel configuration for uplink transmission received in the systemlnformationblock message configures the UE 102 to omit the random access procedure but not the RRC recovery procedure. The UE 102 sends 960 a RRCResumeRequest message using the uplink grant included in the received configuration in the first instance, receives 962 a rrcreesume command from the gNB 106, transitions 964 back to the RRC _ CONNECTED state, and sends 966 a RRCResumeComplete message to the gNB 106. UE 102 then transmits 970 the application data to gNB 106.

In a second example, the UE 102 determines 956, based on the received channel configuration for uplink transmission: the gNB 106 does not support application data transmission in the uplink direction in the RRC _ INACTIVE state. Thus, the UE 102 determines that it can neither omit the random access procedure nor the RRC recovery procedure. UE 102 thus transmits 950 a random access preamble to gNB 106, receives 952 a random access response with an uplink grant from gNB 106, transmits 980 a rrcresemequest message to gNB 106 using the received uplink grant, receives 982 a rrcresemue command in response, transitions back to 984 to an RRC _ CONNECTED state, and transmits 966 a rrcresemplexate message to gNB 106. The UE 102 then transmits 990 the application data to the gNB in the RRC _ CONNECTED state. Because the rrcreesume command resumes operation of a certain Data Radio Bearer (DRB), the UE 102 can use the resumed DRB to send 990 application data. In

step

970 or 990, the UE 102 transmits the application data using the user plane protocol. In one example, UE 102 may include application data in a MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU and send the MAC PDU, RLC PDU, PDCP PDU, or SDAP PDU to gNB 104.

Referring generally to fig. 3-9, after transitioning 334, 434, 534, 634, 734, 834, 934 to the RRC _ INACTIVE state, the UE may transition from the RRC _ INACTIVE state to the RRC _ IDLE state or the RRC _ CONNECTED state in some cases before the UE 102 initiates 340, 440, 540, 640, 740, 840, 940 transmission of application data in the uplink direction. The UE 102 may release a previously received channel configuration for uplink communications upon transitioning to the RRC _ IDLE state or RRC _ CONNECTED state, or in some scenarios, the UE 102 retains the configuration for subsequent use in transmitting messages or application data in the RRC _ CONNECTED state or RRC _ INACTIVE state.

For example, a UE 102 operating in an RRC _ INACTIVE state may receive a paging message from a gNB (e.g., gNB104, gNB 106, or another gNB) that includes a Radio Network Temporary Identifier (RNTI) Value (e.g., an I-RNTI-Value IE) of the UE 102 and, in response, initiate a process to transition to an RRC _ CONNECTED state by sending a rrcresemerequest message to the gNB. In one implementation, in response to a paging message or procedure, the UE 102 releases a previously received channel configuration for uplink communications. In another implementation, the UE 102 sends the RRCResumeRequest message using a previously received configuration for uplink communications (e.g., a NOMA configuration). In both implementations, the UE 102 receives a rrcreesume message from the gNB in response to the rrcreesureq message and sends or receives application data on a Data Radio Bearer (DRB) configured in the previously received radio bearer configuration. The UE 102 transitions to the RRC _ CONNECTED state in response to the RRCResume message.

Next, fig. 10-13 illustrate a number of example scenarios in which multiple base stations share a channel configuration for uplink communications for a particular UE. In general, these techniques allow a UE to obtain channel access data, such as NOMA configuration and/or configured uplink grants (or simply "configured grants") in a cell of one base station, and to send uplink application data in a cell of another base station.

Referring first to fig. 10,

gnbs

104 and 106 can operate in the same RNA. The gNB104 may store 1002 the configured license/NOMA configuration, and the gNB 106 may store 1004 the same configured license/NOMA configuration. In one implementation, the

gnbs

104 and 106 pre-store the data for use by UEs operating in

cells

120 and 122. As discussed above with respect to fig. 3-9, the gNB104 sends 1010 the configured grant/NOMA configuration to the UE 102 using an RRC message or system block information. UE 102 then communicates with gNB104 and/or gNB 106 using 1012 the configured grant/NOMA configuration. As discussed above with respect to fig. 3-9, process 1012 may include uplink transmission of application data, and may involve omitting a process for synchronizing a radio link with a base station, omitting a process for restoring a radio connection, or omitting both processes.

Fig. 11 illustrates a scenario in which the gNB104 receives 1106 a configured license/NOMA configuration from the 5GC 112 or O & M server 114 or other network entity, and the gNB 106 receives 1108 the same configured license/NOMA configuration from the 5GC 112 or O & M server 114 or other network entity. The configured grant/NOMA configuration is then sent 1110 by the gNB104 to the UE 102, as discussed above with respect to fig. 3-9. UE 102 then communicates with gNB104 and/or gNB 106 using 1112 the configured grant/NOMA configuration. The process 1112 may be similar to the process 1012 discussed above.

Referring now to fig. 12, as discussed above with respect to fig. 3-9, in this example scenario, the gNB104 generates a configured grant/NOMA configuration and sends 1202 the configured grant/NOMA configuration to the UE 102. The gNB104 also sends 1204 the configured permission/NOMA configuration to the gNB 106. The gNB104 may send 1204 this information via the Xn interface 126 (see fig. 1). UE 102 then communicates with gNB104 and/or gNB 106 using 1212 configured grant/NOMA configurations, where process 1212 is similar to

processes

1012, 1112 discussed above.

Fig. 13 shows a scenario in which the gNB104 generates a configured permission/NOMA configuration and sends 1306 the configured permission/NOMA configuration to the 5GC 112 or the O & M server 114. The 5GC 112 or O & M server 114 in turn sends 1308 the configured permission/NOMA configuration to the gNB 106. Meanwhile, the gNB104 also sends 1310 the configured grant/NOMA configuration to the UE 102, as discussed above with respect to fig. 3-9. Similar to the example above, UE 102 then communicates with gNB104 and/or gNB 106 using the configured grant/NOMA configuration received 1312, where process 1312 is similar to

processes

1012, 1112, and 1212 discussed above.

Next, fig. 14 illustrates an example method 1400 for determining and applying a channel configuration for uplink communications, which may be implemented, for example, in UE 102. The methodology 1400 begins at block 1402, where the UE 102 transmits application data (e.g., message 312 of fig. 3, message 412 of fig. 4, message 612 of fig. 6, message 712 of fig. 7) in an RRC _ CONNECTED state at block 1402. At block 1404, the UE 102 receives a rrcr configuration message (e.g., see message 414 of fig. 4, message 714 of fig. 7) with a channel configuration for uplink communications in some cases.

Next, at block 1406, the UE 102 receives a rrcreelease message. In some cases, the rrcreelease message includes the channel configuration for uplink communications (e.g., message 332 of fig. 2, message 632 of fig. 6), while in other cases, including those cases where the UE 102 has received the channel configuration for uplink communications in the rrcreeconfiguration message, the rrcreelease message does not include the channel configuration for uplink communications (e.g., message 432 of fig. 4, message 732 of fig. 7). In any case, at block 1406, the UE 102 may transition to the RRC _ INACTIVE state in response to the rrcreelease message.

At block 1408, the UE 102 obtains the channel configuration for uplink communications from the RRCReconfiguration message or the rrcreelease message. The UE 102 determines whether the UE 102 may omit a procedure for synchronizing a radio link with a base station, such as a random access procedure, based on the received channel configuration (block 1410). If the UE 102 cannot omit the random access procedure, flow proceeds to block 1412 where the UE 102 transmits a random access preamble and receives a random access response (messages 350 and 352 of FIG. 3,

messages

450 and 452 of FIG. 4). Otherwise, if the UE 102 may omit the random access procedure, flow proceeds to block 1414.

At block 1414, the UE 102 determines whether the UE 102 may omit the RRC recovery procedure based on the received channel configuration. If the UE 102 cannot omit the RRC recovery procedure, flow proceeds to block 1416 where the UE 102 sends a RRCResemerRequest message to the base station and receives a RRCReseme command in response (e.g., messages 662 and 664 of FIG. 6, and messages 762 and 764 of FIG. 7) at block 1416. If the UE 102 omits block 1412, the UE 102 may send a rrcresumererequest message using channel access data received as part of the channel configuration for uplink transmission. At block 1418, the UE 102 transitions back to the RRC _ CONNECTED state. Otherwise, the UE 102 may omit the RRC recovery procedure and flow proceeds directly to block 1420.

At block 1420, the UE 102 transmits further application data (e.g., message 370 of fig. 3, message 470 of fig. 4,

messages

644 and 670 of fig. 6,

messages

750 and 770 of fig. 7) in the uplink direction. If the UE 102 omits block 1412, the UE 102 may send further application data using the channel access data received as part of the channel configuration for uplink transmission. If the UE omits

blocks

1416 and 1418, the UE 102 may send further application data in the RRC _ INACTIVE state.

Fig. 15 shows an example method 1500 for receiving a channel configuration for uplink communication from one base station and applying the data to another base station, which may also be implemented in the UE 102.

The methodology 1500 begins at block 1502, in block 1502, the UE 102 transmits application data to a first 5G NR base station, e.g., the gNB104, in an RRC _ CONNECTED state (e.g., message 518 of fig. 5, message 818 of fig. 8, message 918 of fig. 9). Next, at block 1504, the UE 102 receives a rrcreelease message (e.g., message 518 of fig. 5, message 818 of fig. 8, message 918 of fig. 9), and in response transitions to an RRC _ INACTIVE state (block 534 of fig. 5, block 834 of fig. 8, block 934 of fig. 9).

At block 1506, the UE 102 selects a cell of another 5G NR base station, such as the gNB 106 (e.g., block 536 of fig. 5, block 836 of fig. 8, block 936 of fig. 9). As previously mentioned, "selecting" in these scenarios includes both the selection and reselection processes. At block 1508, the UE 102 may receive a system information block element with a channel configuration for uplink communication of the newly selected cell (e.g., block 538 of fig. 5, block 838 of fig. 8, block 938 of fig. 9).

Then, at block 1510, the UE 102 determines whether the UE 102 can omit a procedure for synchronizing a radio link with the base station, e.g., a random access procedure, based on the channel configuration received in the system information block. If the UE 102 cannot omit the random access procedure, flow proceeds to block 1512 where the UE 102 sends a random access preamble to the base station of the newly selected cell and receives a random access response (e.g.,

messages

550 and 552 of fig. 5, messages 854 and 856 of fig. 8,

messages

954 and 956 of fig. 9). Otherwise, if the UE 102 may omit the random access procedure, flow proceeds to block 1514.

At block 1514, the UE 102 determines whether the UE 102 can omit the RRC recovery procedure based on the channel configuration received in the system information block. If the UE 102 cannot omit the RRC recovery procedure, flow proceeds to block 1516, where the UE 102 sends a RRCReseMeasureRequest message to the base station of the newly selected cell, and receives a RRCReseume command in response (e.g., messages 560 and 562 of FIG. 5, messages 860 and 862 of FIG. 8, messages 960/962 and 980/982 of FIG. 9). If the UE 102 omits block 1512, the UE 102 may send a rrcresumererequest message using channel access data received as part of the channel configuration for uplink transmissions. At block 1518, the UE 102 transitions back to the RRC _ CONNECTED state. Otherwise, the UE 102 may omit the RRC recovery procedure and flow proceeds directly to block 1520.

At block 1520, the UE 102 transmits further application data in the uplink direction (e.g., message 570 or 590 of fig. 5,

message

850 or 870 of fig. 8,

message

950 or 970 of fig. 9). If the UE 102 omits block 1512, the UE 102 may send further application data using the channel access data received as part of the channel configuration for uplink transmissions. If the UE omits

blocks

1516 and 1518, the UE 102 may send further application data in the RRC _ INACTIVE state.

For further clarity, fig. 16 illustrates an example method 1600 for reducing delay in uplink communications, which may be implemented in any suitable user equipment. The method 1600 begins at block 1602, where the user equipment transmits first application data in an uplink direction in some state of a protocol for controlling radio resources (e.g., an RRC _ CONNECTED state of an RRC protocol) at block 1602. Examples of block 1602 include

blocks

1402 and 1502 discussed above with reference to fig. 14 and 15, respectively.

At block 1604, the user equipment may transition to a second state of the protocol for controlling radio resources (e.g., RRC _ INACTIVE state of the RRC protocol). Examples of block 1604 include

blocks

1404 and 1504 discussed above with reference to fig. 14 and 15, respectively.

At block 1606, the user equipment may determine a channel configuration for uplink communication when the user equipment is in the second state. For example, the user equipment may determine: whether it may omit a procedure (e.g., block 1410 of fig. 14, block 1510 of fig. 15) for synchronizing a radio link with a first base station to which the user equipment has transmitted the first application data or a second radio base station to which the user equipment has selected or reselected after transmitting the first application data in the uplink direction; and whether it may omit a procedure (e.g., block 1414 of fig. 14, block 1514 of fig. 15) for restoring a radio link with a first base station to which the user equipment transmitted the first application data or a second radio base station to which the user equipment selected or reselected after transmitting the first application data in the uplink direction. Furthermore, when the user equipment determines that it may omit a procedure for synchronizing the radio link (such as a random access procedure), in some cases the user equipment obtains channel access data (e.g., NOMA configuration, uplink grant received on PDCCH) that the user equipment may use to perform a procedure for restoring the radio link or to transmit application data in the uplink direction. At block 1608, the user equipment transmits further application data to the first base station (e.g., block 1420 of fig. 14) or the second base station (e.g., block 1520 of fig. 15) while still in the second state.

Finally, fig. 17 illustrates an example method 1700 for reducing delay in uplink communications that may be implemented in any suitable base station.

The method 1700 begins at block 1702 where a base station determines a channel configuration for uplink communications from a user equipment that has transitioned, or is about to transition, from a first state to a second state in response to a period of inactivity of application data, where the user equipment has transmitted the application data to the base station, at block 1702. As discussed above, the base station may determine the channel configuration for uplink communications based on whether the base station supports omitting procedures for synchronizing radio links and whether the base station supports omitting procedures for resuming radio connections. In some cases, the base station may further determine a channel configuration for uplink communications in view of the capabilities of the user equipment, as previously described with reference to element 322 of fig. 3.

At block 1704, the base station may transmit the determined channel configuration for uplink communications to the user equipment. See element 332 of fig. 3, element 414 of fig. 4, element 538 of fig. 5, element 632 of fig. 6, element 714 of fig. 7, element 838 of fig. 8, element 938 of fig. 9, element 1010 of fig. 10, element 1110 of fig. 11, element 1202 of fig. 12, and element 1310 of fig. 13, and compare with element 1408 of fig. 14 and element 1508 of fig. 15. Next, at block 1706, the base station may receive application data and/or a message for a procedure to resume the radio connection. See element 370 of fig. 3, element 470 of fig. 4, elements 570, 560, 590 of fig. 5,

elements

644, 662, 670 of fig. 6,

elements

750, 762, 770 of fig. 7,

elements

870, 860, 890 of fig. 8,

elements

970, 980, 990 of fig. 9, and compare with element 1420 of fig. 14 and element 1520 of fig. 15. Depending on the channel configuration for uplink communication provided to the user equipment and the configuration of the user equipment, the base station may omit a procedure for synchronizing a radio link (e.g., a random access procedure) and/or a procedure for restoring a radio connection (e.g., an RRC restoration procedure).

The following additional considerations apply to the foregoing discussion.

A user device (e.g., UE 102) in which the techniques of this disclosure may be implemented may be any suitable device capable of wireless communication, such as a smartphone, tablet, laptop, mobile gaming machine, point of sale (POS) terminal, health monitoring device, drone, camera, media streaming dongle (dongle) or another personal media device, wearable device (e.g., smart watch), wireless hotspot, femtocell, or broadband router. Further, in some cases, the user device may be embedded in an electronic system such as a head unit of a vehicle or an Advanced Driver Assistance System (ADAS). Still further, the user device may operate as an internet of things (IoT) device or a Mobile Internet Device (MID). Depending on the type, the user device may include one or more general purpose processors, computer readable memory, a user interface, one or more network interfaces, one or more sensors, and/or the like.

In this disclosure, certain embodiments are described as comprising logic or multiple components or modules. The modules may be software modules (e.g., code stored on a non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module may comprise special purpose circuitry or logic that is permanently configured (e.g., as a special purpose processor, such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as contained in a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. Through cost and time considerations, a decision may be driven as to whether a hardware module is implemented in a dedicated and permanently configured circuit or in a temporarily configured circuit (e.g., configured by software).

When implemented in software, these techniques may be provided as part of an operating system, a library used by multiple applications, a specific software application, or the like. The software may be executed by one or more general-purpose processors or one or more special-purpose processors.

After reading this disclosure, those skilled in the art will understand additional alternative structural and functional designs for reducing delay in uplink communications through the principles disclosed herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. It will be apparent to those of ordinary skill in the art that various modifications, changes, and variations may be made in the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope as defined in the appended claims.

The following aspects are reflective of various embodiments explicitly contemplated by the present disclosure.

Aspect 1 a method in a user equipment for uplink communication, comprising: the first application data is transmitted in an uplink direction by processing hardware of the user equipment while the user equipment is in a connected state associated with a protocol for controlling radio resources. The method further comprises the following steps: in response to a period of inactivity of application data, transitioning, by processing hardware, to an inactive state associated with the protocol; determining, by processing hardware, a channel configuration for uplink communication when the user equipment is in an inactive state; further application data is sent in the uplink direction to the base station according to the determined channel configuration by the processing hardware.

Aspect 2 the method of aspect 1, wherein sending further application data occurs before sending the request to transition to the connected state and after receiving the random access response.

Aspect 3. the method of aspect 1, wherein sending further application data occurs when the user equipment is in an inactive state.

Aspect 4 the method of aspect 1, wherein transmitting further application data in the second state comprises performing a procedure for synchronizing a radio link between the user equipment and the base station.

Aspect 5 the method of aspect 4, wherein performing a procedure for synchronizing radio links comprises: the random access preamble is transmitted to the base station, and the random access response is received from the base station.

The method of aspect 6. the method of aspect 4, wherein determining the channel configuration comprises receiving channel access data associated with a radio link of a synchronization and base station in a downlink direction prior to transitioning to an inactive state; and transmitting the further application data comprises accessing the data using the received channel.

Aspect 7 the method of aspect 1, wherein determining a channel configuration comprises: receiving channel access data relating to synchronization and a radio link of a base station in a downlink direction before transitioning to the second state; and the method further comprises: prior to transmitting further application data, a request to restore the radio connection is transmitted to the base station using the received channel access data, a command to restore the radio connection is received by the processing hardware in response to the transmitted request, and a transition to the first state is made in response to the received command.

Aspect 8 the method of aspect 6 or 7, wherein receiving channel access data comprises: a non-orthogonal multiple access (NOMA) configuration is received.

Aspect 9 the method of aspect 6 or 7, wherein receiving channel access data comprises: an uplink grant is received on a Physical Downlink Control Channel (PDCCH).

The method of aspect 1, wherein the base station is a second base station, and wherein receiving channel access data comprises: receiving channel access data from a first base station different from the second base station.

Aspect 11. the method of any of the preceding aspects, further comprising: receiving, by the processing hardware, a command in a downlink direction to release the radio connection, the command comprising an indication of a channel configuration for uplink communications when the user equipment is in the second state.

Aspect 12. the method of any of aspects 1-10, further comprising: receiving, by the processing hardware, a command to reconfigure the radio connection in the downlink direction, the command comprising an indication of a channel configuration for uplink communications when the user equipment is in the second state.

Aspect 13 the method of any of aspects 1-10, wherein the base station is a second base station, the method further comprising: selecting a cell of a second base station after transmitting the first application data to the first base station in the uplink direction; and receiving a system information block from the second base station, the system information block comprising an indication of a channel configuration for uplink communications when the user equipment is in the second state.

Aspect 14. the method of any of the preceding aspects, further comprising: an indication is sent in an uplink direction by the processing hardware of how the user equipment is configured for uplink communications when the user equipment is in an inactive state.

The aspect 15 the method of any of the preceding aspects, wherein the transition to the second state is in response to a message received in a downlink direction.

Aspect 16 a non-transitory medium having stored thereon instructions that, when executed by processing hardware of a user device, cause the user device to perform a method according to any one of the preceding aspects.

An aspect 17 is a method in a base station for reducing delay in uplink communications, the method comprising: determining, by processing hardware of a base station, a channel configuration for uplink communications for a user equipment, the user equipment having transitioned from a first state in which the user equipment sent first application data to the base station to a second state in response to a period of application data inactivity, the first state and the second state being associated with a protocol for controlling radio resources; transmitting, by the processing hardware, a channel configuration for uplink communications from the user equipment to the user equipment; further application data sent from the user equipment is received by the processing hardware according to the channel configuration.

Aspect 18 the method of aspect 17, wherein transmitting the channel configuration comprises: transmitting, by the processing hardware, a non-orthogonal multiple access (NOMA) configuration to the user equipment, and wherein receiving further application data comprises: further application data is received from the user equipment according to the NOMA configuration.

Aspect 19 the method of aspect 18, further comprising: the NOMA configuration is received by the processing hardware from one of a Core Network (CN) or an operations and maintenance (O & M) server.

Aspect 20. the method of aspect 19, further comprising: the NOMA configuration for the user equipment is stored as part of the configuration of the base station.

The method of aspect 21, wherein the base station is a first base station, the method further comprising: sending, by processing hardware, a NOMA configuration to a second base station operating in the same Radio Access Network (RAN) based notification area (RNA) as the first base station.

Aspect 22. the method of aspect 19, further comprising: the NOMA configuration is sent to one of a Core Network (CN) or an operations and maintenance (O & M) server through the processing hardware.

Aspect 23 the method of aspect 18, wherein transmitting the channel configuration comprises: an uplink grant is sent on the PDCCH to the user equipment.

Aspect 24 the method of aspect 17, wherein receiving further application data comprises: a procedure for synchronizing a radio link between the user equipment and the base station is performed, but a procedure for transitioning the user equipment to the first state is omitted.

Aspect 25 the method of aspect 24, wherein performing a procedure for synchronizing radio links comprises: the method includes receiving a random access preamble from a user equipment and transmitting a random access response to the user equipment.

Aspect 26 the method of aspect 12, wherein receiving further application data comprises: a procedure for synchronizing a radio link between the user equipment and the base station and a procedure for transitioning the user equipment to the first state are omitted.

Aspect 27 the method of aspect 12, wherein receiving further application data comprises: a procedure for synchronizing a radio link between the user equipment and the base station is omitted, but a procedure for transitioning the user equipment to the first state is performed.

Aspect 28. the method of any of aspects 17-27, further comprising: transmitting a command to the user equipment to release the radio connection, the command comprising an indication that the base station supports uplink transmission in the second state.

Aspect 29. the method of any of aspects 17-27, further comprising: transmitting a command to the user equipment to reconfigure the radio connection, the command including an indication that the base station supports uplink data transmission in the second state.

Aspect 30. the method of any of aspects 17-27, further comprising: transmitting a system information block to the user equipment, the system information block including an indication that the base station supports uplink data transmission in the second state.

Aspect 31. a non-transitory medium having stored thereon instructions that, when executed by processing hardware of a base station, cause the base station to perform the method of any of aspects 17-30.

Claims

1. A method in a user equipment for uplink communication, the method comprising:

transmitting, by processing hardware of the user equipment, first application data in an uplink direction while the user equipment is in a connected state associated with a protocol for controlling radio resources;

in response to a period of inactivity of application data, transitioning, by processing hardware, to an inactive state associated with the protocol;

determining, by processing hardware, a channel configuration for uplink communication when the user equipment is in an inactive state;

completing a procedure for synchronizing a radio link between the user equipment and the base station; and

prior to sending the request to transition to the connected state, sending further application data in the uplink direction to the base station by the processing hardware in accordance with the determined channel configuration when the user equipment is in the inactive state.

2. The method of claim 1, wherein completing the procedure for synchronizing the radio link between the user equipment and the base station comprises: the random access response is received in response to transmitting the random access preamble to the base station.

3. The method of claim 1, wherein determining a channel configuration comprises:

channel access data associated with a synchronous radio link with a base station is received in a downlink direction prior to transitioning to an inactive state.

4. The method of claim 3, wherein sending the request to transition to the connected state comprises: a request to resume the radio connection is sent to the base station using the received channel access data.

5. The method of claim 3, wherein the base station is a second base station, and wherein receiving channel access data comprises:

channel access data is received from a first base station different from a second base station.

6. The method of any of the preceding claims, further comprising:

a command to release the radio connection is received in a downlink direction by the processing hardware, the command comprising an indication of a channel configuration for uplink communication when the user equipment is in an inactive state.

7. The method of any of claims 1-5, further comprising:

a command to reconfigure a radio connection is received in a downlink direction by processing hardware, the command including an indication of a channel configuration for uplink communications when the user equipment is in an inactive state.

8. The method of any one of claims 1-5, wherein the base station is a second base station, the method further comprising:

selecting a cell of a second base station after transmitting first application data to a first base station in an uplink direction; and

receiving a system information block from the second base station, the system information block comprising an indication of a channel configuration for uplink communications when the user equipment is in an inactive state.

9. The method of any of the preceding claims, further comprising:

an indication is sent in an uplink direction by the processing hardware of how the user equipment is configured for uplink communications when the user equipment is in an inactive state.

10. The method of any preceding claim, wherein transmitting further application data comprises:

transmitting a Packet Data Convergence Protocol (PDCP) data unit.

11. A non-transitory medium having stored thereon instructions that, when executed by processing hardware of a user device, cause the user device to perform the method of any preceding claim.

12. A method in a base station for reducing delay in uplink communications, the method comprising:

determining, by processing hardware of a base station, a channel configuration for uplink communications for a user equipment, the user equipment having transitioned from a connected state in which the user equipment sent first application data to the base station to an inactive state in response to a period of inactivity of the application data, the connected state and the active state being associated with a protocol for controlling radio resources;

transmitting, by the processing hardware, a channel configuration for uplink communications from the user equipment to the user equipment; and

further application data sent from the user equipment is received by the processing hardware according to the channel configuration.

13. The method of claim 12, wherein transmitting the channel configuration comprises:

transmitting a non-orthogonal multiple access (NOMA) configuration to the user equipment through the processing hardware, an

Wherein receiving further application data comprises:

further application data is received from the user equipment according to the NOMA configuration.

14. The method of claim 13, wherein the base station is a first base station, further comprising:

the NOMA configuration is sent by the processing hardware to a second base station operating in the same Radio Access Network (RAN) based notification area (RNA) as the first base station.

15. The method of claim 12, wherein receiving further application data comprises:

a procedure for synchronizing a radio link between the user equipment and the base station is performed, but a procedure for transferring the user equipment to a connected state is omitted.

16. The method of claim 12, wherein receiving further application data comprises:

omitting at least one of: (i) a procedure for synchronizing a radio link between the user equipment and the base station, and (ii) a procedure for transitioning the user equipment to a connected state.

17. The method of any of claims 12-12, further comprising:

transmitting a command to release the radio connection to the user equipment, the command including an indication that the base station supports uplink data transmission in an inactive state.

18. The method of any of claims 12-16, further comprising:

transmitting a command to reconfigure a radio connection to the user equipment, the command including an indication that the base station supports uplink data transmission in an inactive state.

19. The method of any of claims 12-16, further comprising:

transmitting a system information block to the user equipment, the system information block including an indication that the base station supports uplink data transmission in an inactive state.

20. A non-transitory medium having stored thereon instructions that, when executed by processing hardware of a base station, cause the base station to perform the method of any one of claims 12-19.