Patent Description:
The following abbreviations are herewith defined, at least some of which are referred to within the following description: Third Generation Partnership Project ("3GPP"), UE (User Entity/Equipment (Mobile Terminal)), AS (Access Stratum), RRC (Radio Resource Control), RAN (Radio Access Network), DL (downlink), UL (uplink), gNB (Next Generation Node B or <NUM> Node Base), RNAU (RAN notification area update), AMF (Core Access and Mobility Management Function), UPF (User plane Function), NR (New Radio), CN (Core Network), SRB (signaling radio bearer), Xn-AP (Xn-Access Point, in which Xn is an interface), Evolved Node B ("eNB"), and Long Term Evolution ("LTE").

In the New Radio (NR) system, a remote unit can be configured into a RRC_INACTIVE state by a gNB. The RRC_INACTIVE state is a new RRC (Radio Resource Control) state in NR. The following behaviors/procedures related to the remote unit in a RRC_INACTIVE state are allowed: cell re-selection mobility; CN (Core Network) - NR-RAN connection (both C/U-planes) has been established for a remote unit; the remote unit AS (Access Stratum) context is stored in at least one of the base unit and the remote unit; paging is initiated by NR-RAN; RAN-based notification area is managed by NR-RAN; NR-RAN knows the RAN-based notification area which the remote unit belongs to.

In particular, the RRC_INACTIVE state is a state where a remote unit remains connected with the core network and can move within an area configured by NG-RAN without notifying NG-RAN. In the RRC_INACTIVE state, the last serving NG-RAN node keeps the remote unit context and NG connection with the serving AMF and UPF. The remote unit notifies the network if it moves out of the configured RNA. The remote unit in the RRC_INACTIVE state can be configured with the NG-RAN, where the NG-RAN can cover a single or multiple cells, and can be smaller than CN (Core Network) area; and a RAN notification area update (RNAU) is periodically sent by the remote unit and is also sent when the cell reselection procedure of the remote unit selects a cell that does not belong to the configured NG-RAN. There are several different alternatives on how the RNA can be configured. A remote unit may be provided with a list of one or more cells that constitute the NG-RAN, i.e. list of cells. Alternatively, a remote unit may be provided with at least one RAN area ID, in which a RAN area is a subset of a CN Tracking Area. Alternatively, a cell broadcasts at least one RAN area ID in the system information so that a remote unit knows which area the cell belongs to.

If the last serving base unit receives DL data from the UPF or DL signaling from the AMF while the remote unit is in the RRC_INACTIVE state, it pages in the cells corresponding to the RNA and may send Xn-AP RAN Paging to neighboring base units if the RNA includes cells of neighboring base units. Steps <NUM>-<NUM> of <FIG> show a network triggered transition from RRC_INACTIVE state to RRC_CONNECTED state.

If the remote unit accesses a base unit (current base unit) other than the last serving base unit, the receiving base unit triggers the Xn-AP Retrieve UE Context procedure to get the remote unit context from the last serving base unit and may also trigger a Data Forwarding procedure including tunnel information for potential recovery of data from the last serving base unit. Upon successful context retrieval, the receiving base unit becomes the serving base unit and further triggers the NG-AP Path Switch Request procedure. After the path switch procedure, the serving base unit triggers release of the UE context at the last serving base unit by means of the Xn-AP UE Context Release procedure. Steps <NUM>-<NUM> of <FIG> show the resume request procedure as described above.

After the completion of the above procedure, the current base unit will become the serving base unit, and therefore, if the above procedure is performed again, the current base unit will become the last serving base unit. In at least the following four cases the remote unit will be triggered to perform the resume request procedure as shown in <FIG>: (<NUM>) Periodic RAN notification area update; (<NUM>) Event-triggered RAN notification area update, such as the remote unit leaving the configured area; (<NUM>) UL data arrival; and (<NUM>) DL data arrival. In the case of a Periodic RAN notification area update, it is not necessary to perform a path switch or retrieve UE context. Specifically, a Periodic RAN notification area update is performed periodically so that the base unit knows that remote unit operates appropriately in the RRC_INACTIVE state. In this case, there is no need for the current base unit to retrieve the UE context request from the last serving base unit, and there is no need for the current base unit to become the last serving base unit.

R3-<NUM> is a 3GPP discussion document titled "<NPL>. This document discusses the RAN3 impact to support periodic RAN notification are update.

R2-<NUM> is a 3GPP discussion document titled "<NPL>. This document discusses how the UE will perform the RAN area updates and CN Tracking are updates.

R2-<NUM> is a 3GPP discussion document titled "<NPL>. This document discusses details in respect of RAN area update procedure.

R3-<NUM> is a 3GPP discussion document titled "<NPL>. This document discusses mechanisms for periodic RAN location area update.

R2-<NUM> is a 3GPP discussion document titled "<NPL>. This document discusses how the UE will perform periodic RAN area updates in RRC-INACTIVE that is similar to periodic TAU in RRC-IDLE.

R2-<NUM> is a 3GPP discussion document titled "<NPL>, and proposes that the RAN area update procedure should be optimized so the UE does have to first enter RRC_CONNECTED to then be moved again to RRC_INACTIVE.

<CIT> describes a state transition of a user equipment in inactive state whereby the user equipment is turned from the inactive state to the idle state, and wherein the inactive state is the intermediateness being located between connected state and the Idle state.

<CIT> describes a terminal device arranged to operate in a connection mode and set up a datum plane connection between the terminal device and a network equipment under the connection mod; and when the datum plane is inactive an inactive mode is converted thereto from connection mode.

<CIT> describes a base station which upon receiving a request for establishing a communication connection from a communication device, obtains information indicating from where a context associated with a previously established communication connection can be retrieved; retrieves the context associated with the previously established communication connection based on the obtained information; and resumes the previously established communication connection with the communication device using the retrieved context.

<CIT> describes a first network node that is arranged to, upon an occurrence of a triggering event, transmit, to a second network node, a second message that requests that the connection between the wireless device and the wireless network be resumed, the second message comprising a resume identifier and the resume identifier.

Claim <NUM> defines a method performable by a base unit, claim <NUM> defines a base unit, claim <NUM> defines a system itself comprising a base unit and a remote unit, and claim <NUM> defines a method performable by a system comprising a base unit and a remote unit.

These drawings depict some examples and are not therefore to be considered to be limiting of scope, the examples will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:.

Accordingly, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit" "module" or "system". Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices storing machine readable code, computer-readable code, and/or program code, referred hereafter to as code.

Certain functional units described in this specification may be labeled as modules, in order to more particularly emphasize their implementation independence.

The operational data may be collected as a single data set, or may be distributed over different locations including over different computer-readable storage devices. Where a module or portions of a module are implemented in software, the software portions are stored on one or more computer-readable storage devices.

Any combination of one or more computer-readable medium may be utilized. The computer-readable medium may be a computer-readable storage medium. The computer-readable storage medium may be a storage device storing the code. The storage device may be, for example, but is not limited to being, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

A non-exhaustive list of more specific examples of the storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, random access memory ("RAM"), read-only memory ("ROM"), erasable programmable read-only memory ("EPROM" or flash memory), a portable compact disc read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

Code for carrying out operations for embodiments may be any number of lines and may be written in any combination of one or more programming languages including an object-oriented programming language such as Python, Ruby, Java, Smalltalk, C++, or the like, and conventional procedural programming languages, such as the "C" programming language, or the like, and/or machine languages such as assembly languages.

Reference throughout this specification to "one embodiment", "an embodiment" or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The terms "including", "comprising", "having" and variations thereof mean "including but not limited to" unless expressly specified otherwise. The terms "a", "an", and "the" also refer to "one or more" unless expressly specified otherwise.

The code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed via the processor of the computer or other programmable data processing apparatus, create a means for implementing the functions/acts specified in the schematic flowchart diagrams and/or schematic block diagrams block or blocks.

For example, two blocks shown in succession may in fact be substantially executed in concurrence, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

Although various arrow types and line types may be employed in the flowchart and/or block diagrams, they are understood as not limiting the scope of the corresponding embodiments.

<FIG> depicts an embodiment of a wireless communication system <NUM> for performing a resume request procedure. In one embodiment, the wireless communication system <NUM> includes remote units <NUM>, <NUM>, <NUM> and base units <NUM>, <NUM>. Even though a specific number of remote units and base units are depicted in <FIG>, one skilled in the art will recognize that any number of remote units and base units may be included in the wireless communication system <NUM>.

In one embodiment, the remote units may include computing devices, such as desktop computers, laptop computers, personal digital assistants ("PDAs"), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle on-board computers, network devices (e.g., routers, switches, modems), or the like. In some embodiments, the remote units include wearable devices, such as smart watches, fitness bands, optical head-mounted displays, or the like. Moreover, the remote units may be referred to as subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, UE, user terminals, a device, or by other terminology used in the art.

The base units may be distributed over a geographic region. In certain embodiments, a base unit may also be referred to as an access point, an access terminal, a base, a base station, a Node-B, an eNB, a gNB, a Home Node-B, a relay node, a device, or by any other terminology used in the art. The base units are generally part of a radio access network (RAN) that includes one or more controllers communicably coupled to one or more corresponding base units. The radio access network is generally communicably coupled to one or more core networks, which may be coupled to other networks, like the Internet or public switched telephone networks, among other networks.

The base units may serve a number of remote units within a serving area, for example, a cell or a cell sector via a wireless communication link. Any of the remote units can move from a serving area of one base unit to a serving area of another base unit. <FIG> shows that that the base unit <NUM> serves the remote units <NUM> and <NUM>, while the base unit <NUM> serves the remote units <NUM> and <NUM>. The remote unit <NUM> moves from the serving area of the base unit <NUM> to the serving area of the base unit <NUM>. In some embodiments, the base unit <NUM>, which previously served the remote unit <NUM>, may be referred to as the last serving base unit or the anchor base unit.

<FIG> depicts an apparatus <NUM> that may be used for performing a resume request procedure. The apparatus <NUM> includes the remote unit <NUM>. Furthermore, the remote unit <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, a display <NUM>, a transmitter <NUM>, and a receiver <NUM>. In some embodiments, the input device <NUM> and the display <NUM> are combined into a single device, such as a touch screen. In certain embodiments, the remote unit <NUM> may not include any input device <NUM> and/or display <NUM>. In various embodiments, the remote unit <NUM> may include one or more of the processor <NUM>, the memory <NUM>, the transmitter <NUM>, and the receiver <NUM>, and may not include the input device <NUM> and/or the display <NUM>.

In various embodiments, the processor <NUM> may determine that a resume request procedure should be initiated. For example, the base unit would initiate a resume procedure in at least the following four cases: (<NUM>) Periodic RAN notification area update; (<NUM>) Even-triggered RAN notification area update, such as leaving the configured area; (<NUM>) UL data arrival; and (<NUM>) DL data arrival.

The memory <NUM>, in one embodiment, is a computer-readable storage medium. For example, the memory <NUM> may include RAM, including dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and/or static RAM ("SRAM"). In some embodiments, the memory <NUM> stores data relating to random access procedures.

In some embodiments, the input device <NUM> may be integrated with the display <NUM>, for example, as a touch screen or similar touch-sensitive display. In some embodiments, the input device <NUM> includes a touch screen such that text may be input using a virtual keyboard displayed on the touch screen and/or by handwriting on the touch screen.

For example, the input device <NUM> and display <NUM> may form a touch screen or similar touch-sensitive display.

The transmitter <NUM> is used to provide UL communication signals to the base unit <NUM> and the receiver <NUM> is used to receive DL communication signals from the base unit <NUM>.

<FIG> depicts an apparatus <NUM> that may be used for performing a resume request procedure. The apparatus <NUM> includes the base unit <NUM>. Furthermore, the base unit <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, a display <NUM>, a transmitter <NUM>, and a receiver <NUM>. As may be appreciated, the processor <NUM>, the memory <NUM>, the input device <NUM>, the display <NUM>, the transmitter <NUM>, and the receiver <NUM> may be substantially similar to the processor <NUM>, the memory <NUM>, the input device <NUM>, the display <NUM>, the transmitter <NUM>, and the receiver <NUM> of the remote unit <NUM>, respectively.

The receiver <NUM> may be used to receive resume request from the transmitter <NUM> of the remote unit <NUM>. Although only one transmitter <NUM> and one receiver <NUM> are illustrated, the base unit <NUM> may have any suitable number of transmitters <NUM> and receivers <NUM>. The transmitter <NUM> and the receiver <NUM> may be part of a transceiver.

<FIG> is a schematic diagram illustrating a method for performing a resume request procedure.

The remote unit <NUM> is in a RRC-INACTIVE state. As described above, in four cases, the remote unit would initiate a resume procedure: (<NUM>) Periodic RAN notification area update; (<NUM>) Event-triggered RAN notification area update, such as leaving configured area; (<NUM>) UL data arrival; and (<NUM>) DL data arrival. The remote unit <NUM> sends, for example, by the transmitter <NUM>, a RRC Connection Resume Request message to the base unit <NUM> (step <NUM>). The resume request message includes a resume ID. The resume ID was previously allocated by the last serving base unit <NUM>. The resume ID includes at least the UE ID of the remote unit <NUM> and the ID of the last serving base unit <NUM>.

Preferably, a cause is included in the resume request message. The cause informs the base unit <NUM> of the reason why the remote unit <NUM> initiates the resume request. The cause includes but not limited to the aforementioned four cases. For example, the resume request message may include a cause that a periodic RAN notification area update is performed.

Upon receiving the resume request message for example by the receiver <NUM>, the base unit <NUM> sends for example by the transmitter <NUM> a message to the last serving base unit <NUM> (step <NUM>). Preferably, the message is an indicator including at least the UE ID or the resume ID. The UE ID or the resume ID can be used by the last serving base unit <NUM> to determine which remote unit is performing the resume request. The last serving base unit <NUM> receives the indicator and sends an acknowledgement response to the base unit <NUM> (step <NUM>).

Upon receiving the acknowledgement response from the last serving base unit <NUM> for example by the receiver <NUM>, the base unit <NUM> sends for example by the transmitter <NUM> a RRC Connection Release response to the remote unit <NUM> (step <NUM>). Unlike the RRC Connection Resume response shown in step <NUM> of <FIG> which will change the remote unit <NUM> to the RRC_CONNECTED state, the RRC Connection Release response will keep the remote unit <NUM> in the RRC-INACTIVE state. The resume ID is preferably included in the RRC Connection Release response. As described above, the resume ID includes at least the UE ID of the remote unit <NUM> and the ID of the last serving base unit <NUM>. The RRC Connection Release response is sent to the remote unit <NUM> over SRB0. SRB0 is a signaling radio bearer that means the signal being sent in plain text without encryption. The RRC Connection Release response is just an example for keeping the remote unit <NUM> in the RRC-INACTIVE state. Other RRC messages may be alternatively used for the same purpose of keeping the remote unit <NUM> in the RRC-INACTIVE state.

After receiving the RRC Connection Release response, the remote unit <NUM> will stay in the inactive state.

A comparison between <FIG> and <FIG> indicates that the remote unit <NUM> is in a different state. In <FIG>, after the RRC Connection Resume Request initiated by the remote unit at step <NUM>, the remote unit will finally change into the connected state. Furthermore, <FIG> implies that the current base unit will become the last serving base unit, which means a path switch. That is to say, after the remote unit initiates the RRC Connection Resume Request, the anchor base unit of the remote unit will switch from the last serving base unit to the current base unit. In addition, the remote unit will change from the inactive state to the connected state.

On the other hand, according to <FIG>, the current base unit <NUM> sends a RRC Connection Release to the remote unit <NUM> to keep the remote unit <NUM> stay in the inactive state. Moreover, the last serving base unit <NUM> remains as the anchor base unit of the remote unit <NUM>. Preferably, the resume ID including at least the UE ID of the remote unit <NUM> and the ID of the last serving base unit <NUM> is sent from the current base unit <NUM> to the remote unit <NUM>. The inclusion of the ID of the last serving base unit <NUM> in the resume ID sent to the remote unit <NUM> indicates that the last serving base unit <NUM> remains as the last serving base unit (anchor base unit). Therefore, in the condition of for example the periodic RAN notification area update, no path switch occurs for the remote unit in the inactive state.

Step <NUM> is the same as step <NUM> of <FIG>. The remote unit <NUM> in the RRC-INACTIVE state sends a RRC Connection Resume Request message to the base unit <NUM>. The resume request message includes the resume ID and preferably the cause.

Upon receiving the resume request message, the base unit <NUM> sends a Retrieve UE Context Request to the last serving base unit <NUM> (step <NUM>).

The last serving base unit <NUM>, upon receiving the Retrieve UE Context Request, sends a Retrieve UE Context Response to the base unit <NUM> (step <NUM>). The Response includes the UE context of the remote unit <NUM>.

After receiving the UE context of the remote unit <NUM> from the last serving base unit <NUM>, the base unit <NUM> sends the RRC Connection Release response to the remote unit <NUM> over SRB1 (step <NUM>). SRB1 is a signaling radio bearer that means the signal being sent with encryption. The encryption is made by using the UE context of the remote unit <NUM>. An integrity protection is also preferably made over SRB1.

<FIG> is a schematic diagram illustrating an embodiment of a method for performing a resume request procedure.

Steps <NUM>, <NUM> and <NUM> are the same as steps <NUM>, <NUM> and <NUM> of <FIG>. The detailed description of the steps <NUM>, <NUM> and <NUM> are herein omitted.

The embodiment of <FIG> differs from <FIG> in the step <NUM>. In step <NUM>, the base unit <NUM> sends a Retrieve UE Context Request to the last serving base unit <NUM>. In step <NUM>, the Retrieve UE Context Request further includes an assistant indicator. The assistant indicator instructs the last serving base unit <NUM> to store the UE Context of the remote unit <NUM>.

In <FIG>, the last serving base unit <NUM> does not receive, from the base unit <NUM>, an instruction on whether the UE context of the remote <NUM> should be still stored in the last serving base unit <NUM>. In absence of an instruction for releasing or deleting the UE context, the last serving base unit <NUM> stores the UE context of the remote unit. The last serving base unit <NUM> releases or deletes the UE context of the remote unit only if it receives a UE CONTEXT RELEASE message, e. g, from the current base unit shown in step <NUM> of <FIG>.

In the step <NUM>, the last serving base unit <NUM> receives the indicator including the UE ID or resume ID of the remote unit <NUM>. Therefore, the last serving base unit <NUM> knows that a periodic RAN notification area update is performed by the remote unit <NUM>. Because no instruction for releasing (deleting) the UE context of the remote unit <NUM> is received by the last serving base unit <NUM>, the last serving base unit <NUM> continues storing the UE context of the remote unit <NUM> and continues serving as the last serving base unit (anchor base unit) for the remote unit <NUM>.

Similarly, in the step <NUM>, the last serving base unit <NUM> receives the Retrieve UE Context Request from the base unit <NUM>. Therefore, the last serving base unit <NUM> knows that a periodic RAN notification area update is performed by the remote unit <NUM>. Because no instruction for releasing (deleting) the UE context of the remote unit <NUM> is received by the last serving base unit <NUM>, the last serving base unit <NUM> continues storing the UE context of the remote unit <NUM> and continues serving as the last serving base unit (anchor base unit) for the remote unit <NUM>.

In the step <NUM>, the last serving base unit <NUM> receives the assistant indicator included in the Retrieve UE Context Request from the base unit <NUM>. The assistant indicator instructs the last serving base unit <NUM> to continue storing the UE context of the remote unit <NUM>. Therefore, the last serving base unit <NUM> continues storing the UE context of the remote unit <NUM> and continues serving as the last serving base unit (anchor base unit) for the remote unit <NUM>.

Claim 1:
A method performable by a base unit (<NUM>), the method comprising:
receiving (<NUM>) a resume request from a remote unit (<NUM>) in an inactive state;
sending (<NUM>) a Retrieve UE Context Request to a last serving base unit (<NUM>), the Retrieve UE Context Request including an assistant indicator which instructs the last serving base unit (<NUM>) to continue storing the UE context of the remote unit (<NUM>);
in response to receiving (<NUM>) a UE Context from the last serving base unit (<NUM>), sending (<NUM>) a configuration message over SRB1 to the remote unit (<NUM>) to maintain the remote unit (<NUM>) in the inactive state.