WO2018184227A1

WO2018184227A1 - Communication methods, devices and system

Info

Publication number: WO2018184227A1
Application number: PCT/CN2017/079779
Authority: WO
Inventors: Jianhua Liu
Original assignee: Guangdong Oppo Mobile Telecommunications Corp., Ltd.
Priority date: 2017-04-07
Filing date: 2017-04-07
Publication date: 2018-10-11
Also published as: CN109845336B; TW201838472A; CN109845336A; TWI683592B

Abstract

Methods, devices, systems, a message, computer programs and carriers thereof for state transition of a UE are provided.

Description

COMMUNICATION METHODS, DEVICES AND SYSTEM

Technical Field

The present invention relates to state transition of user equipment in a mobile communication network.

Background

The statements in this section merely provide background information related to the present disclosure and may not constitute prior art. Further, the content in this section may be used to define a concept related to the invention.

In a mobile communication network, a user equipment (UE) , sometimes also called as a mobile terminal, a mobile node, etc., has normally two states: connect-ed state and idle state.

In the connected state, or called as RRC_CONNECTED state, a radio resource control (RRC) connection is established and maintained between the UE and the network side such as a radio access network (RAN) . Further, the Access Stratum (AS) context of the UE is stored in both of the UE and the network side. Thus, the UE can transmit uplink data and receive downlink data with a small delay. Howev-er, the power consumption of the UE in the connected state is high.

In the idle state, or called as RRC_IDLE state, no RRC connection is established between the UE and the network side, and no AS context of the UE is stored in any one of the UE and the network side. The UE in the idle state has a low power consumption. However, to transmit and/or receive data, an RRC connection has to be first established between the UE and the network side, which introduces a large delay.

Along with the evolution of the mobile communication network, some new services are to be included, e.g., Internet of Things (IoT) , raising new requirements to the communication latency and the power consumption of the UEs. With this respect, New Radio (NR) Access Technology for the RAN has been proposed and being discussed, e.g., under the 3^rd Generation Partnership Project (3GPP) . In 3GPP TR 38.804, a new state for the UE is introduced, i.e., inactive state, or called as RRC_INACTIVE state. This inactive state may also be introduced for the UEs in the Long Term Evolution (LTE) system.

In the inactive state, a UE should incur minimum signaling to fulfil the control la-tency requirement of the services and minimize power consumption comparable to the idle state and resource costs in the RAN/CN (core network) , so as to make it possible to maximize the number of UEs utilizing and benefiting from this state. In the inactive state, a connection between the NR RAN and the CN may have been established for a UE, and the AS context of the UE may be stored in at least one of the UE and the RAN, e.g., stored in an eNodeB (E-UTRAN Node B or evolved Node B in the LTE) or an gNB (5G Node B or NR Node B) in an RAN.

Summary

Brief Description of the Drawings

The drawings are merely for illustration purposes but not for limiting the invention.

Fig. 1: state transitions of a UE.

Fig. 2: a flow chart of state transition.

Fig. 3: a flow chart of state transition.

Fig. 4: a flow chart of state transition.

Detailed Description

In the context of the above mentioned UE states, the state transitions of a UE be-tween the states of idle, connected and inactive are shown in Fig. 1. It is needed for a UE to transit from the inactive state to the idle state.

When the network side decides that a UE should transit from the inactive state to the idle state, the network side may simply release the AS context of the UE with-out informing the UE to switch to the idle state. As a result, the network side re-gards the UE as in the idle state while the UE still maintains itself in the inactive state. In other words, the network side and the UE are not synchronized with re-spect to the state of the UE.

In this non-synchronized situation, if downlink data arrives for the UE, the network side will page the UE, triggering the UE to contact the network side which will then trigger a Non-Access Stratum (NAS) recovery since the AS context of the UE has been released； if uplink data arrives, the UE will try to resume the AS context of the UE, i.e. perform a transition to the connected state, which will invoke an NAS recovery since the AS context of the UE cannot be resumed. In this respect, this non-synchronized situation does not consume much more resources compared to a synchronized situation in which the UE transit to the idle state and the network side knows it.

However, in the non-synchronized situation, if the UE remained in the inactive state reaches the boundary of the RAN area, it will try to make RAN area update which will obviously fail since the network side has released the AS context of the UE and regards the UE as in the idle state. This will generate unnecessary signal-ing traffic and load to the network since it is no longer needed to make the update and the network side needs to release the UE from the inactive state to the idle state after RAN area update has been failed.

As shown in Fig. 2, when the network side decides to move a UE from the inactive state to the idle state, an RAN may send a message to the UE, e.g., a paging message in Step S202. This message may be sent by a base station, e.g., an eNodeB or a gNB, in the RAN. In response to this message, the UE may send an RRC Connection Resume Request message to the base station in Step S204. Then, the base station sends an RRC Connection Release message to the UE in Step S206. Upon receiving the RRC Connection Release message, the UE re-leases the just established RRC connection and transits from the inactive state to the idle state. That is, a plurality of RRC messages is exchanged between the base station and the UE merely for moving the UE from the inactive state to idle state. Further, the method of Fig. 2 has to be performed once for each UE that should transit from the inactive state to idle state. Thus, if the states of a plurality of UEs are to be transited, the method of Fig. 2 has to be performed a plurality of times, consuming a large amount of RRC resources.

As shown in Fig. 3, when the network side decides to move a UE from the inactive state to the idle state, an RAN may send a message to the UE, e.g., a paging message in Step S302. This message may be sent by a base station, e.g., an eNodeB or a gNB, in the RAN. In the message, an RRC Connection Release Flag may be added, so that the UE can immediately transit from the inactive state to the idle state, and responds an RRC Connection Resume Request message to the base station in Step S304 as an acknowledgement. Compared to the method of Fig. 2, the method of Fig. 3 saves one message. However, just the same as the method of Fig. 2, the method of Fig. 3 still has to be performed once for each UE that should transit from the inactive state to idle state.

When the network side decides to move a plurality of UEs from the inactive state to the idle state, there are several scenarios.

In the first scenario, if the network side decides to move all the UEs in the inactive state within an RAN area to the idle state, each of the base stations, e.g., eNodeBs or a gNBs, in that RAN area sends a message, e.g., a paging message in Step S402 of Fig. 4. This paging message is not the same as the paging mes-sage shown in Fig. 2 or Fig. 3 that can page only one UE. The paging message in Step S402 is a message similar to a broadcast message and can page all the UEs in the inactive state within the area of the base station and indicate these UEs to transit from the inactive state to the idle state.

In the second scenario, if the network side decides to move all the UEs in the inac-tive state within the area of a base station, e.g., an eNodeB or a gNB, the base station sends a message, e.g., a paging message in Step S402 of Fig. 4. This paging message is a message similar to a broadcast message and can page all the UEs in the inactive state within the area of that base station and indicate these UEs to transit from the inactive state to the idle state.

In the third scenario, if the network side decides to move a plurality of UEs but not all the UEs in the inactive state within the area of a base station, e.g., an eNodeB or a gNB, the base station sends a message, e.g., a paging message in Step S402 of Fig. 4. This paging message is a message similar to a multicast message and can page said plurality of UEs within the area of that base station and indicate these UEs to transit from the inactive state to the idle state. This message may include one or more lists of the identities of said plurality of UEs and indication in-formation indicating that all the listed UEs should transit to the idle state. Thus, if a UE that receives this paging message is one of the plurality of UEs listed in this paging message, the UE transits from the inactive state to the idle state.

In any of the first, second and third scenarios, unlike the method of Fig. 3, a UE that receives the message in Step S402 does not send any response to the base station as acknowledgement.

As a result, the network side can instruct a plurality of UEs to transit from the inac-tive state to the idle state at the same time using a common indication, which saves a lot of resources, such as paging message and RRC messages, compared to the case when each UE needs to be paged separately.

Since the paging message in Step S402 is similar to a broadcast or a multicast message, it cannot be ensured that all the UEs, which should transit from the inac-tive state to the idle state, do receive the paging message. Therefore, the base station may send this paging message a plurality of times to reduce the possibility that a UE does not receive the paging message. The number of times of sending the paging message may be changed based on the number of UEs that should transit from the inactive state to the idle state.

Further, a UE in the inactive state may belong to several groups. Therefore, a pag-ing message in Step S402 may be sent to each of the groups by listing the identi-ties of all the UEs in the group, so that for the UEs belonging to multiple groups the possibility of missing the paging message is reduced.

Nevertheless, the possibility of missing the paging message cannot be reduced to zero due to the nature of the broadcast and multicast. However, in the methods of Figs. 2 and 3, if the RAN does not receive an acknowledgement from a paged UE, it will try to page again. If no acknowledgement is received after a certain times of retries, the RAN stops trying. That is, even the methods of Figs. 2 and 3 cannot ensure that all the addressed UEs can receive the paging message. The differ-ence lies in that in the methods of Figs. 2 and 3 the RAN knows who does not re-ceive the paging message while in the method of Fig. 4 the RAN does not know who misses the paging message.

For the UE that should transit from the inactive state to the idle state but does not receive any paging message sent by the network side, the aforementioned non-synchronized situation occurs. That is, the method of Fig. 4 largely reduces the signaling needed when the network side decides to move a plurality UEs from the inactive state to the idle state with the cost that there is small possibility that the non-synchronized situation may occur for one or more of the UEs.

In addition, there are different possible ways to indicate a plurality of UEs to transit from the inactive state to the idle state for each of the first, second and third sce-narios, as long as the UEs can receive the message and obtain a clear indication from the message about who needs to transit to the idle state. In the following, a unified way is provided, which may be used for all the scenarios. As the example shown in Fig. 4, the base station may send a paging message to page a plurality of UEs and indicate the plurality of UEs to transit from the inactive state to the idle state. This may be realized by adding an information element (IE) into the conven-tional paging message, e.g., the paging message defined in 3GPP TS 36.331.

For example, the IE to be added into the paging message may be called as "inactiveRelease" to indicate the UEs to release from the inactive state, i.e., transit from the inactive state to the idle state. Further, a list may be added into the pag-ing message, e.g., called as "inactiveReleaseList" . In the first scenario, the list in-cludes the identity of the RAN area, so that the UE knows that all the UEs in the inactive state within the whole RAN area should be released to the idle state. In the second scenario, the list includes the identity of the base station, so that the UE knows that all the UEs in the inactive state within the area of the base station should be released to the idle state. In the third scenario, the list includes the iden-tities of the plurality of UEs that should be released from the inactive state, so that a UE that receives the message can check if it itself is one of the listed UEs.

An exemplary paging message with the above mentioned new IE and list is as fol-lows, wherein the newly added IE and list is emphasized.

In view of the above, it is provided the followings:

A method, comprising sending, by a network side device, a message, said mes-sage indicating a plurality of user equipments to transit from an inactive state to an idle state.

A method, comprising: receiving, by a user equipment, a message, said message indicating a plurality of UEs to transit from an inactive state to an idle state； transit- ing, by said UE, from said inactive state to said idle state if said UE is one of said plurality of UEs indicated in said message.

A method, comprising: sending, by a network side device, a message, said mes-sage indicating a plurality of user equipments to transit from an inactive state to an idle state； receiving, by a UE, said message； transiting, by said UE, from said inac-tive state to said idle state if said UE is one of said plurality of UEs indicated in said message.

In the above methods, said network side device may be a base station in a Radio Access Network of a mobile communication network, preferably an eNodeB or a gNB.

In the above methods, said message may be a paging message.

In the above methods, said message indicating a plurality of UEs to transit from an inactive state to an idle state may be a message indicating each UE that is in said inactive state and receives said message to transit from said inactive state to said idle state.

In the above methods, said message may include one or more lists, listing the identifies of said plurality of UEs for indicating each of the listed plurality of UEs to transit from said inactive state to said idle state.

The above methods may comprise: sending, by said network side device, said message a plurality of times.

A network side device, adapted to carry out a corresponding method as mentioned above.

A user equipment, adapted to carry out a corresponding method as mentioned above.

A network side device, comprising: sending means, a sending module, a sending unit or a sending device, adapted to send a message, said message indicating a plurality of user equipments to transit from an inactive state to an idle state.

A further user equipment comprising: receiving means, a receiving module, a re-ceiving unit or a receiving device, adapted to receive a message, said message indicating a plurality of UEs to transit from an inactive state to an idle state； con-trolling means, a controlling module, a controlling unit, or a controlling device, adapted to transit from said inactive state to said idle state if said UE is one of said plurality of UEs indicated in said message.

A system, comprising one of the above network side devices and one of the above user equipments.

A message, sent by a network side device, indicating a plurality of user equipments to transit from an inactive state to an idle state.

A computer program or a computer program product, containing program instruc-tions which, when executed in a network side device, cause said network side de-vice to carry out a corresponding method mentioned above.

A computer program or a computer program product, containing program instruc-tions which, when executed in a user equipment, cause said UE to carry out a cor-responding method mentioned above.

A carrier for carrying a computer program, a computer program product, or a mes-sage mentioned above.

It is apparent to those skilled in the art that the function, means, module, unit, de-vice or system described above may be implemented using hardware, software, or a combination thereof. For a hardware implementation, they may be implemented within one or more application specific integrated circuits (ASICs) , digital signal processors (DSPs) , digital signal processing devices (DSPDs) , programmable log-ic devices (PLDs) , field programmable gate arrays (FPGAs) , processors, control-lers, micro-controllers, microprocessors, other suitable electronic units, or a selec-tive combination thereof. For a software implementation, a computer program and/or codes may be written in any suitable programming language, carried by a carrier such as a suitable computer-readable media, and executed by a controller or processor. The computer-readable media may be one or more of ROM, RAM, CD-ROM, magnetic tape, floppy disc, optical data storage device, and the like. In addition, the message described above may be a message with a technical struc-ture including the corresponding information. The message may be an electronic message in analog form or digital form which can be sent or received by an elec-tronic device. The message may be carried by a carrier, for example by a comput-er-readable media as mentioned above, or by a communication channel, such as a wireless communication channel or a wired communication channel, in the form of electric signal, electromagnetic wave or any other suitable form.

It should be understood that the invention is not limited by any of the details of the foregoing description, but rather should be construed broadly based on the princi-ple as defined in the appended claims. Therefore, all changes and modifications that fall within the scope of the claims, or equivalences thereof are intended to be embraced by the scope of protection.

Claims

A method, comprising:

sending, by a network side device, a message, said message indicating a plurality of user equipments (UEs) , to transit from an inactive state to an idle state.
A method, comprising:

receiving, by a user equipment (UE) , a message, said message indicating a plurality of UEs to transit from an inactive state to an idle state；

transiting, by said UE, from said inactive state to said idle state if said UE is one of said plurality of UEs indicated in said message.
A method, comprising:

sending, by a network side device, a message, said message indicating a plurality of user equipments (UEs) to transit from an inactive state to an idle state；

receiving, by a UE, said message；

transiting, by said UE, from said inactive state to said idle state if said UE is one of said plurality of UEs indicated in said message.
The method of claims 1 or 3, wherein said network side device is a base station in a Radio Access Network (RAN) of a mobile communication network, preferably an eNodeB or a gNB.
The method of any one of claims 1 to 4, wherein said message is a paging message.
The method of any one of claims 1 to 5, wherein said message indicating a plurality of UEs to transit from an inactive state to an idle state means said mes-sage indicating each UE that is in said inactive state and receives said message to transit from said inactive state to said idle state.
The method of any one of claims 1 to 5, wherein said message includes one or more lists, listing the identifies of said plurality of UEs for indicating each of the listed plurality of UEs to transit from said inactive state to said idle state.
The method of any one of claims 1 and 3-7, comprising:

sending, by said network side device, said message a plurality of times.
A network side device, adapted to carry out the method steps of any one of claims 1 and 4-8.
A user equipment (UE) adapted to carry out the method steps of any one of claims 2 and 5-7.
A system, comprising the network side device of claim 9 and the user equipment of claim 10.
A network side device, comprising:

sending means adapted to send a message, said message indicating a plu-rality of user equipments (UEs) to transit from an inactive state to an idle state.
A user equipment (UE) , comprising:

receiving means, adapted to receive a message, said message indicating a plurality of UEs to transit from an inactive state to an idle state；

controlling means, adapted to transit from said inactive state to said idle state if said UE is one of said plurality of UEs indicated in said message.
A system, comprising the network side device of claim 12 and the user equipment of claim 13.
A message, sent by a network side device, indicating a plurality of user equipments (UEs) to transit from an inactive state to an idle state.
A computer program, containing program instructions which, when execut-ed in a network side device, cause said network side device to carry out the meth-od steps of any one of claims 1 and 4-8.
A computer program, containing program instructions which, when execut-ed in a user equipment (UE) , cause said UE to carry out the method steps of any one of claims 2 and 5-7.
A carrier for carrying the computer program of claim 16 or 17 or for carrying the message of claim 15.