Patent Description:
The <NUM>rd Generation Partnership Project (3GPP) technical report numbered <NPL> (hereinafter referred to as TR <NUM>), represents one approach to the design of a system architecture for next generation mobile networks, also referred to as <NUM>th generation (<NUM>) networks. Section <NUM> of this document considers potential solutions to the key issue of providing a mobility framework. Within this section is a description of a Mobile Originating (MO) only mode for a User Equipment (UE) <NUM> (<FIG>) that does not require mobile terminated service (i.e., the UE <NUM> does not have or expect downlink (DL) traffic) or that wants to limit its reachability.

A UE mode, referred alternatively to as the Mobile Initiated Connection Only (MICO), or the Mobile Initiated Communication Only (MICO) mode, is described in Section <NUM>. <NUM> of the <NUM>rd Generation Partnership Project (3GPP) technical specification numbered <NPL> (hereinafter referred to as TS <NUM>). However, the system would benefit from certain improvements related to the MICO mode.

For purposes of this disclosure, MO-only mode and MICO mode can be considered substantially equivalent and used interchangeably. In some instances, the term MO/MICO or MO-only / MICO is used to emphasize this applicability to either mode.

Therefore, there is a need for a method and apparatus serving mobile wireless communication devices in wireless communication networks such as proposed <NUM> networks, for providing MO-only / MICO mode, that obviates or mitigates one or more limitations of the prior art.

Document <NPL>; provides a high level description on connection and mobility <NUM> management feature.

Document <NPL> <NUM> proposes a registration procedure.

It is an object of the present invention to obviate or mitigate at least one disadvantage of the prior art.

According to a first aspect, there is disclosed a method for managing a connection of a UE to a network, the method comprising actions at an access node of: receiving a registration request from the UE comprising a MICO mode preference and a suggested duration for the MICO preference; and transmitting the registration request to an AMF for a determination of whether the MICO mode is allowed for the UE based on a communication pattern, the AMF transmitting the determination and a periodic registration update timer value for the MICO mode to the UE; wherein the UE performs a registration update when the periodic registration update timer expires.

In an embodiment, the communication pattern can suggest the absence of network-initiated communications with the UE and the determination can be to allow MICO mode with a large MICO periodic registration update timer value.

In an embodiment, the communication pattern can suggest scheduled network-initiated communications with the UE at a future time and the determination can be to allow MICO mode with a periodic registration update timer value that will expire before the future time occurs.

In an embodiment, the communication pattern can suggest uncertainty about a schedule of network-initiated communications with the UE and the determination can be to not allow MICO mode.

In an embodiment, the UE can reset a periodic registration update timer with the periodic registration update timer value when it enters a connected state.

In an embodiment, the AMF can provide a non-stoppable timer indication together with the determination to the UE and the UE can refrain from resetting the periodic update timer before the periodic registration update timer expires, even if the UE enters the connected state, until the non-stoppable timer indication is removed.

In an embodiment, the AMF can transmit an active timer value to the UE with the determination and the UE can set an active timer with the active timer value upon receipt thereof, reset the active timer with the active timer value when it has MO data to send, reset the active timer with the active timer value when it receives MT data and leave the connected state only upon expiry of the active timer.

According to a second aspect, there is disclosed an access node comprising a radio interface, a network interface, a process or and a machine-readable memory. The radio interface is for communicating with a UE. The network interface is for communicating with nodes within a (R)AN and a network. The machine-readable memory is for storing instructions that, when executed by the processor, causes the access node to carry out the method of the first aspect and/or any embodiments thereof.

According to a third aspect, there is disclosed a method for managing a connection of a UE to a network, comprising actions at the UE of: transitioning into a state of connection with the network and starting a timer having a duration obtained from an AMF in the network; transmitting MICO data to an access node in communication therewith while in the state of connection; and remaining in the state of connection after ceasing to transmit MICO data until at least after expiry of the timer.

In an embodiment, upon expiry of the timer, the UE can transition into a state of idleness if no longer transmitting MICO data. In an embodiment, the action of transitioning into a state of idleness can comprise being released from the network by the access node.

In an embodiment, the AMF can determine the duration based on a communication pattern derived from user subscription data, a communication pattern and/or a mobility pattern. In an embodiment, the communication pattern can indicate that the MICO data will not trigger MT data and the duration can be a default value. In an embodiment, the communication pattern can indicate that the MICO data will trigger MT data after a time interval and the duration can exceed the time interval and a round trip delay of a packet.

According to a fourth aspect there is disclosed a UE comprising a processor and a machine-readable memory. The machine-readable memory is for storing instructions that, when executed by the processor, cause the UE to carry out the method of the third aspect and/or any embodiments thereof.

According to a fifth aspect there is disclosed a method for managing a connection of a UE to a network, comprising actions at the UE of: receiving MT data from an access node while in a state of connection with the network in response to transmitting MICO data; requesting a transition from the state of connection to a state of idleness to an AMF; and transitioning to the state of idleness upon obtaining a release from the network by the AMF.

In an embodiment, the action of requesting can comprise sending the request to the access node.

According to a sixth aspect, there is disclosed a UE comprising a processor and a machine-readable memory. The machine-readable memory is for storing instructions that, when executed by the processor, cause the UE to carry out the method of the fifth aspect and/or any embodiments thereof.

It should be understood that embodiments of an aspect may be used in isolation or in conjunction with other embodiments. In some cases, embodiments of one aspect may also be applied to other aspects.

As used herein, the term "User Equipment" (UE) <NUM> is used for purposes of clarity. However, the UE <NUM> may refer to one of a variety of devices, generally referred to herein by the term "mobile devices" and including mobile stations, terminals or nodes, fixed or stationary devices, stations, terminals, or nodes, human-type communication devices, machine-type communication (MTC) devices, Internet of Things (IoT) devices, other wireless end nodes, which communicate with a radio access node via wireless communication. Another term used synonymously with UE <NUM> and mobile device is "electronic device". One skilled in the art will appreciate that the term "mobile device" is used to refer to a device designed to connect to a mobile network. This connection typically makes use of a wireless connection to an access node. Although the mobile network is designed to support mobility, it is not necessary that the mobile device itself be mobile. Some mobile devices, such as metering devices (e.g., smart meters) may not be capable of mobility, but still make use of the mobile network.

As used herein, an Access Node (AN) <NUM> (<FIG>) can be a 3GPP AN, referred to as a RAN, or a non-3GPP AN. The term (R)AN can be used to emphasize that an AN can be a RAN or non-3GPP AN. In some situations, the term RAN may also refer to the radio access network, but those of skill in the art will be able to differentiate between these uses.

The present application uses a number of acronyms that are based on current terminology used in the 3GPP standards process. Terms are subject to change as the process progresses, but current terms used by persons of skill in the art include:.

Embodiments of the present invention comprise operations automatically provided by one or more nodes and/or functions forming part of a wireless communication network <NUM> (<FIG>). Each node and/or function may be associated with enabling components such as a microprocessor <NUM> (<FIG>), electronic memory <NUM>, <NUM> (<FIG>), and communication interface or interfaces <NUM>, <NUM>, <NUM> (<FIG>). The microprocessor <NUM> may execute program instructions stored in memory <NUM>, <NUM> in order to implement the desired functionality of the node and/or function as described herein. The microprocessor <NUM> and memory <NUM>, <NUM> may be at least partially replaced with equivalent electronic components such as digital logic components in some embodiments. Nodes and/or functions may be operated on dedicated hardware or they may be virtualized, that is made to operate on generic hardware platforms in accordance with a network function virtualization (NFV) framework.

Section <NUM> of TR <NUM>, referred to above, provides an agreement for UE reachability and for support for an MO-only / MICO mode. In particular, according to the agreement, based on UE indicated preferences, UE subscription data and network policies, or any combination of them, the Next Generation (NG) Core Network (CN) <NUM> can determine whether MO-only mode can be applied for the UE <NUM>. An indication of the result of this determination is sent to the UE <NUM> during registration signalling. The UE <NUM> and core network <NUM> can then re-initiate (or exit) the MO-only mode with subsequent registration signalling.

Furthermore, a UE <NUM> in MO-only/ MICO mode is characterized by the UE <NUM> performing a registration upon the expiration of a registration timer (with potentially a very long periodic registration timer and/or periodic registration update timer (which terms may be used interchangeably) value), but not necessarily listening to (or responding to) paging between registrations. In case the UE <NUM> is in MO-only / MICO mode, the CN <NUM> can inform the (R)AN <NUM> that the UE <NUM> will not be listening to paging (e.g., a (R)AN <NUM> can decide to never keep an inactive MO-only mode UE <NUM> in a radio resource control (RRC) Inactive state). By transmitting an indication to the (R)AN <NUM>, the CN <NUM> node is able to allow the (R)AN <NUM> to reduce the signalling associated with a node in MO-only / MICO mode.

Finally, the agreement states that for a UE <NUM> in MO-only / MICO mode the CN <NUM> determines the frequency of periodic registration.

The present application provides a method and apparatus for updating a general UE registration procedure to meet the requirements of the above agreement.

For any embodiment, any scheduled communication time may be restricted at a UE <NUM>, by a UE parameter to DL, UL, or bidirectional.

<FIG> provides a signalling diagram summarizing the steps of a method for general registration of the UE <NUM> in a communications network.

In step <NUM>, UE <NUM> communicates an (R)AN registration request to (R)AN <NUM>. The registration request message can include (R)AN parameters along with a registration request. The registration request may include the following details: Registration type, Subscriber Permanent Identifier (SUPI) or <NUM> Globally Unique Temporary Identifier (<NUM>-GUTI), Security parameters, network slice selection assistance information (NSSAI), UE <NUM> CN Capability, protocol data unit (PDU) session status, and MO-only / MICO mode preference indicator. The MO-only / MICO mode preference indicator can indicate whether MO-only / MICO mode is preferred by the UE <NUM>, and if preferred, it may also indicate a suggested duration.

In case of <NUM>-(R)AN, the (R)AN parameters may include, for example a SUPI or the <NUM>-GUTI, and/or the selected NSSAI.

The Registration type field can indicate whether the UE <NUM> wants to perform an "initial registration" (i.e., when the UE <NUM> is in non-registered state), a "mobility registration" or "mobility registration update" (i.e., when the UE <NUM> is in a registered state and initiates a new or updated registration (i.e. a registration procedure) due to mobility) or a "periodic registration" or "periodic registration update" (i.e., when the UE <NUM> is in a registered state and initiates a new or updated registration (i.e. a registration procedure) due to expiration of a periodic update timer). See e.g. Section <NUM>. <NUM> of TS <NUM>. If included in the registration request, the <NUM>-GUTI can be used to indicate the last serving access and mobility management function (AMF) <NUM>, <NUM> (<FIG>). In some embodiments, if the UE <NUM> is already registered via a non-3GPP access in a public land mobile network (PLMN) different from the PLMN of the 3GPP access, the UE <NUM> is configured to refrain from providing the UE Temporary ID allocated by the AMF <NUM>, <NUM> during the registration procedure over the non-3GPP access. Security parameters transmitted in this message may be used for Authentication and integrity protection. NSSAI indicates the Network Slice Selection Assistance Information (as defined in TS <NUM> (e.g. Section <NUM>). The PDU session status indicates the available (e.g. previously established) PDU sessions in the UE <NUM>. In the following figures, dashed lines have been used to indicate steps that may be performed as either optional steps or conditional steps.

Step <NUM> can be performed when a SUPI is included or when the <NUM>-GUTI does not indicate a valid AMF <NUM>, <NUM>. In this optional step <NUM>, the (R)AN <NUM>, based on Access Technology (AT) (or more specifically a Radio AT (RAT)) and NSSAI, if available, selects an AMF <NUM>, <NUM>. The AN <NUM> can use any of a number of different techniques to select an AMF <NUM>, <NUM>, such as those described in TS <NUM>.

In some embodiments, if the (R)AN <NUM> cannot select an AMF <NUM>, <NUM>, it forwards the Registration Request to a default AMF <NUM>, <NUM>. The default AMF <NUM>, <NUM> is responsible for selecting an appropriate AMF <NUM>, <NUM> for the UE. The relocation between the default AMF <NUM>, <NUM> and selected AMF <NUM>, <NUM> is described in Section <NUM>. <NUM> of TS <NUM>, where the initial AMF <NUM>, <NUM> refers to the default AMF <NUM>, <NUM>, and the target AMF <NUM>, <NUM> refers to the selected AMF <NUM>, <NUM>.

In step <NUM> (R)AN <NUM> transmits a registration request message to AMF <NUM>. In some embodiments, this registration request takes the form of an N2 message. The N2 message can comprise N2 parameters and a Registration Request (which may include Registration type, and/or Permanent User ID (e.g. a SUPI) or <NUM>-GUTI, Security parameters, and/or NSSAI)). When <NUM>-(R)AN is used, the N2 parameters can include the Location Information, Cell Identity and/or the RAT type related to the cell in which the UE <NUM> is camping. In some embodiments, if the Registration type indicated by the UE <NUM> corresponds to the periodic registration update case, then subsequent steps up to and including UE context establishment <NUM> and/or <NUM> can be omitted.

Optionally, in step <NUM>, new AMF <NUM> can transmit an information request to an old AMF <NUM> (such as one indicated in (or determined in accordance with) the registration request <NUM>) to complete the Registration Request. For example, if the UE's <NUM>-GUTI was included in the Registration Request and the serving AMF <NUM>, <NUM> has changed since last registration, the new AMF <NUM> may send the Information Request to the old AMF <NUM> including the complete Registration Request IE to request the UE's SUPI and MM Context.

If step <NUM> is performed, then, at step <NUM>, old AMF <NUM> transmits an Information Response (including, for example, UE's SUPI, MM Context, and/or SMF information) to the new AMF <NUM>. If the old AMF <NUM> holds information about active PDU Sessions, the old AMF <NUM> can include, in the Information Response SMF <NUM>, information including SMF identities and/or PDU session identities.

Optionally, in step <NUM>, new AMF <NUM> transmits an Identity Request to the UE <NUM>. In particular, when the SUPI is not provided by the UE <NUM> nor is it retrieved from the old AMF <NUM>, the Identity Request procedure can be initiated by the new AMF <NUM> by sending an Identity Request message to the UE <NUM>.

If step <NUM> is performed, then, in step <NUM>, the UE <NUM> transmits an Identity Response to the new AMF <NUM>. The UE <NUM> responds to the Identity Request sent in step <NUM> with an Identity Response message including the SUPI.

In step <NUM>, the new AMF <NUM> may decide to invoke an authentication server function (AUSF) <NUM>. In that case, the new AMF <NUM>, can select an Authentication Server Function (AUSF) <NUM>. This selection may be made in accordance with the SUPI, as described in TS <NUM>.

In step <NUM>, the AUSF <NUM> selected in step <NUM> initiates authentication of the UE <NUM> and non-access stratum (NAS) security functions. The authentication and security can be performed using any number of different techniques. The particulars of the implementation of the authentication and security processes may be based on generally accepted processes such as those described in other 3GPP documents including TS <NUM>. It is noted that, the AMF <NUM>, <NUM> selection may be performed after this step <NUM>, for example, due to requirements imposed based on the implementation of network slicing. Accordingly, the methods used may vary and may be similar to those provided in TS <NUM>.

In step <NUM>, if the AMF <NUM>, <NUM> has changed the new AMF <NUM> acknowledges the transfer of UE <NUM> MM context to the old AMF <NUM>. If the authentication/security procedure fails, then the Registration can be rejected, and the new AMF <NUM> can send a reject indication to the old AMF <NUM>. If this occurs, then the old AMF <NUM> can continue as the AMF <NUM>, <NUM> associated with the UE <NUM> as if the Information Request was never received.

If the permanent equipment identifier (PEI) was neither provided by the UE <NUM> nor retrieved from the old AMF <NUM>, then, in step <NUM>, an Identity Request procedure can be initiated by the AMF <NUM> sending an Identity Request message to the UE <NUM> to retrieve the PEI.

In optional step <NUM>, the AMF <NUM> initiates a Mobile Equipment (ME) identity check with the Equipment Identity Registry (EIR) <NUM>. The PEI check may be performed as described in clause <NUM> of TS <NUM>.

If step <NUM> is to be performed, then, at step <NUM>, the AMF <NUM> first selects a Unified Data Management (UDM) <NUM> function based on the SUPI, for example, as described in TS <NUM>.

In step <NUM>, if the AMF <NUM> has changed since the last registration, or if there is no valid subscription context for the UE <NUM> in the AMF <NUM>, or if the UE <NUM> provides a SUPI which doesn't refer to a valid context in the AMF <NUM>, the AMF <NUM> initiates the update location procedure. The update location procedure of step <NUM> includes the UDM initiating a Cancel Location to the old AMF <NUM>, if any. The old AMF <NUM> can remove the MM context and can notify all possibly associated session management function(s) (SMF(s)) <NUM>, and the new AMF <NUM> creates an MM context for the UE <NUM> after getting the AMF related subscription data from the UDM <NUM>. The AMF related subscription data may include a DL communications schedule, if any exists, of the UE <NUM>. The AMF related subscription data may include communication pattern parameters of the UE <NUM>, which may include a periodic communication indicator, scheduled communication time(s), an indication of whether communication is mobile initiated or network-initiated, an indication of whether communication of MT data is expected to be triggered by communication of MO data, and/or an expected time interval between MT data and MO data communication events, etc..

In one embodiment, at step <NUM>, the AMF <NUM> can obtain a DL or network-initiated communication activity schedule from the UDM <NUM>, if any, in order to determine whether to apply the MO-only mode to the UE <NUM> and the periodic registration update timer.

If no DL or network-initiated communication activity is expected, the UE <NUM> can be assigned the MO-only mode and the timer can be set to a large value. However, if DL or network-initiated communication activity is expected to occur, the UE <NUM> can be assigned with the non-MO-only mode.

If DL or network-initiated communication activity is expected, but is not going to occur soon, the UE <NUM> can be assigned to the MO-only mode and the timer can be set to a value such that the UE <NUM> will perform its periodic registration before the expected communication activity takes place. This allows the UE <NUM> to be in MO-only mode but to exit the mode in advance of expected DL transmissions. If DL communication activity is uncertain, the UE <NUM> can be assigned non-MO-only mode.

If the communication pattern parameters include an indication of whether communication of MT data is expected to be triggered by communication of MO data, and/or an expected time interval between MT data and MO data communication events, when the AMF <NUM> detects that the UE <NUM> has entered the CM_CONNECTED state for MO data transmission in the UL direction (by way of non-limiting example, when the UE <NUM> performs a service request rather than a registration, the AMF <NUM> may conclude that the UE <NUM> wants to transmit MO data in the UL direction), the AMF <NUM> may trigger the UE <NUM> to perform a registration update in order to renegotiate the MICO mode so that the UE <NUM> can exit the MICO mode and receive MT data in the DL direction that is triggered by the MO data In the UL direction. In some examples, in such a scenario, the AMF <NUM> may directly inform the UE <NUM> to exit/deactivate the MICO mode, by way of non-limiting example, through a UE configuration update procedure. If the communication pattern information includes an indication of whether communication of MT data is expected to be triggered by communication of MO data, and/or an expected time interval between MT data and MO data communication events, the AMF <NUM> may disallow and/or deactivate the MICO mode for the UE <NUM> and reports that this has occurred to the UE <NUM>, by way of non-limiting example, during registration and/or a registration update.

The update location procedure may be performed as described in TS <NUM>. During the update location procedure of step <NUM>, the PEI is provided to the UDM <NUM>.

Optionally, in step <NUM>, the AMF <NUM>, based on the SUPI, selects a Policy Control function (PCF) <NUM>. The AMF <NUM> can select a PCF <NUM> using any of a number of different procedures, such as those described in TS <NUM>.

If PCF <NUM> is selected (and in some embodiments when the AMF <NUM>, <NUM> has not been able to obtain or has not yet obtained an AMF -related operator policy, and/or if the local AMF policy is not considered appropriate and/or valid), then in step <NUM>, the AMF <NUM> transmits a UE Context Establishment Request to the PCF <NUM>, requesting the PCF <NUM>, for example, to apply operator policies for the UE <NUM>. In some embodiments, this Context Establishment Request can be related to the SUPI. The UE Context Establishment request may optionally include a UE identifier such as a SUPI. In various embodiments, if the AMF <NUM> has not yet obtained AMF-related operator policies for the UE <NUM> and/or if the operator policies in the AMF <NUM> are no longer valid, the AMF <NUM> requests the PCF <NUM> to apply operator policies for the UE <NUM>.

In some embodiments, the PCF <NUM> can determine that the UE <NUM> should be in MO-only mode, and in others it can determine the MO-only mode parameters for the UE <NUM>. In such cases, the PCF <NUM> can transmit an indication of the decision and/or the parameters to the AMF <NUM>. This indication can be included in the acknowledgement message of step <NUM>. In some embodiments, the PCF <NUM> can provide the AMF-related operator policies for the UE <NUM> to the AMF <NUM>. When the acknowledgement message includes this indication, the PCF <NUM> may need to interact with the UDM <NUM> to obtain a DL or network-initiated communication activity schedule in order to make such a decision. In such an embodiment, it is the PCF <NUM>, not the AMF <NUM> that obtains DL or network-initiated communication schedule from the UDM <NUM> and determines the MO-only mode selection by itself, in contrast to embodiments discussed above. It should be understood that other variations discussed above with respect to the method can also be implemented in this embodiment.

In step <NUM> the PCF <NUM> communicates with the AMF <NUM> to respond to and/or acknowledge the UE Context Establishment Request message. In some embodiments, the response message can include operator policy, such as AMF-related operator policy, e.g. for the UE <NUM> to the AMF <NUM>.

In some embodiments, the AMF <NUM> at this point determines or updates the expected UE behaviour or Mobility Pattern for the UE <NUM> as described in Section <NUM>. <NUM> of TS <NUM>. According to the expected UE behaviour or Mobility Pattern, the AMF <NUM> determines whether to apply the MICO mode to the UE <NUM> and the periodic registration update timer value for the UE <NUM>, as described in Section <NUM>. <NUM> in TS <NUM>.

If the AMF <NUM>, <NUM> is changed, then, in step <NUM> the new AMF <NUM> communicates with each SMF <NUM> to notify each SMF <NUM> of the new AMF <NUM> serving the UE <NUM>. The AMF <NUM> verifies the PDU session status from the UE <NUM> with the available SMF <NUM> information. In case the AMF <NUM>, <NUM> has changed the available SMF <NUM> information has been received from the old AMF <NUM>. The AMF <NUM> requests the SMF <NUM> to release any network resources related to PDU sessions that are not active in the UE <NUM>.

If step <NUM> is performed then, in step <NUM>, the SMF <NUM> communicates a response to the AMF <NUM>. The SMF <NUM> may decide to trigger this step, for example, in the case of user-plane (UP) function (UPF) <NUM> (<FIG>) relocation as described in TS <NUM>. If the Registration type indicated by the UE <NUM> is a periodic registration update, then the subsequent steps <NUM> and <NUM> may be omitted.

If the old AMF <NUM> previously requested a UE context to be established in the PCF <NUM>, then, in step <NUM>, the old AMF <NUM> can terminate the UE context in the PCF <NUM>. In step <NUM> the PCF <NUM> transmits a UE Context Termination Acknowledgement to the old AMF <NUM>. In some embodiments if MO-only / MICO mode is selected for the UE <NUM>, the AMF <NUM>, <NUM> informs indicates it to the (R)AN <NUM>.

In step <NUM>, AMF <NUM> informs the (R)AN <NUM> whether the MO-only / MICO mode is selected for the UE <NUM> and, in step <NUM>, MO-only mode notification is acknowledged by the (R)AN <NUM> to the new AMF <NUM>. In some embodiments, the step <NUM> is optional if the MO-only mode selection decision has not changed for the UE <NUM>.

In step <NUM>, the AMF <NUM> sends a Registration Accept message to the UE <NUM> indicating that the registration has been accepted. The Registration Accept message may include <NUM>-GUTI, Registration area. Mobility restrictions, PDU session status, NSSAI, MO-only / MICO mode indicator, and/or periodic registration update timer. A <NUM>-GUTI is included if the AMF <NUM> allocates a new <NUM>-GUTI. Mobility restrictions can be included in case mobility restrictions apply for the UE <NUM>. The AMF <NUM> can indicate the PDU session status to the UE <NUM>. The UE <NUM> can remove any internal resources related to PDU sessions that are not marked active in the received PDU session status. If the PDU session status information was in the Registration Request, the AMF <NUM> can indicate the PDU session status to the UE <NUM>. The NSSAI includes the accepted Single NSSAIs (S-NSSAIs).

Optionally, in step <NUM> the UE <NUM> sends a Registration Complete message to the AMF <NUM> to acknowledge that a new <NUM>-GUTI was assigned.

<FIG> provides a signalling diagram summarizing the steps of a method for general registration of a UE <NUM> in a communications network. As shown in <FIG>, steps <NUM> - <NUM> are similar to steps <NUM> - <NUM> of the procedure summarized in <FIG>.

In step <NUM>, if the AMF <NUM> has not yet obtained AMF-related operator policies for the UE <NUM> or if the operator policies in the AMF <NUM> are no longer valid, the AMF <NUM> transmits a context establishment request to the PCF <NUM> to apply operator policies for the UE <NUM>. The request can include a UE identifier such as the SUPI. In step <NUM>, the PCF <NUM> transmits a context establishment response to the AMF <NUM>. For example, the PCF <NUM> acknowledges the UE Context Establishment Request message and transmits related operator polices for the UE <NUM> to the AMF <NUM>.

In optional step <NUM>, the AMF <NUM> determines whether to assign the MO-only mode to the UE <NUM> and the periodic registration update timer value for the UE <NUM> according to the subscription data, operator polices, and UE preference. In one embodiment, where the subscription data indicates no DL communication activity for the UE <NUM>, the MO-only mode may be selected for the UE <NUM> and the periodic registration update timer may be set to a large value. In another embodiment, where the subscription data indicates DL communication activity is about to happen, the MO-only mode may not be selected for the UE <NUM>. Alternatively, if the subscription data indicates DL communication activity is not going to happen soon, the MO-only mode may be selected for the UE <NUM> and the periodic registration update timer may be set with a value so that the timer will expire before the DL activity takes place. Finally, if the subscription data indicates uncertainty about DL communication activity and/or its schedule, the MO-only mode may not be selected for the UE <NUM>.

If the AMF <NUM> is changed, then, in step <NUM> the new AMF <NUM> communicates with each SMF <NUM> to notify each SMF <NUM> of the new AMF <NUM> serving the UE <NUM>. The AMF <NUM> verifies the PDU session status from the UE <NUM> with the available SMF <NUM> information. In case the AMF <NUM> has changed the available SMF information has been received from the old AMF <NUM>. The new AMF <NUM> requests the SMF <NUM> to release any network resources related to PDU sessions that are not active in the UE <NUM>.

If step <NUM> is performed then, in step <NUM>, the SMF <NUM> communicates a response to new AMF <NUM>. The SMF <NUM> may decide to trigger this step, for example, in the case of UPF <NUM> relocation as described in TS <NUM>.

If the old AMF <NUM> previously requested a UE context to be established in the PCF <NUM>, then, in step <NUM>, the old AMF <NUM> can terminate the UE context in the PCF <NUM>. In step <NUM> the PCF <NUM> transmits a UE Context Termination Acknowledgement to the old AMF <NUM>.

In the case where the registration is the initial registration of the UE <NUM> or if the UE <NUM>'s MO-only mode configuration changes, the new AMF <NUM> notifies the (R)AN <NUM> whether the MO-only mode is selected for the UE <NUM>. The notification may include the MO-only mode indicator. If there is no MO-only mode Indicator in the notification then, in some embodiments it can be considered an implied indication that the MO-only mode is not selected for the UE <NUM>. The notification may also include the periodic registration update timer in the case the MO-only mode is selected for the UE <NUM>.

In step <NUM>, the MO-only mode Selection Notification is acknowledged by the (R)AN <NUM> to the new AMF <NUM>.

In step <NUM>, the new AMF <NUM> sends a Registration Accept message to the UE <NUM> indicating that the registration has been accepted. The Registration Accept message may include <NUM>-GUTI, Registration area, Mobility restrictions, PDU session status, NSSAI, MO-only mode Indicator, and/or periodic registration update timer. A <NUM>-GUTI is included if the new AMF <NUM> allocates a new <NUM>-GUTI. Mobility restrictions can be included in case mobility restrictions apply for the UE <NUM>. The new AMF <NUM> can indicate the PDU session status to the UE <NUM>. The UE <NUM> can remove any internal resources related to PDU sessions that are not marked active in the received PDU session status. If the PDU session status information was in the Registration Request, the new AMF <NUM> can indicate the PDU session status to the UE <NUM>. The NSSAI includes the accepted S-NSSAIs.

Optionally, in step <NUM> the UE <NUM> sends a Registration Complete message to the new AMF <NUM> to acknowledge that a new <NUM>-GUTI was assigned.

Embodiments of the present disclosure relate to a variation and update with respect to the general registration procedure and the service request procedure described in TS <NUM>. In particular, the update reflects the MICO mode description as described in Section <NUM>. <NUM> thereof. Further details are given below.

<FIG>, <FIG> and <FIG> illustrate registration procedures and service request procedures provided in accordance with embodiments of the present invention. More specifically, <FIG>, <FIG> and <FIG> provide signalling diagrams summarizing the steps of methods for general registration of a UE <NUM> in a communications network. It should be noted that the procedures in <FIG> and <FIG>, <FIG> and <FIG> bear several similarities. As such, for purposes of clarity, only additional details particularly relevant to <FIG>, <FIG> and <FIG> are provided in the description below. Other steps and details can be readily understood by referring to the above description with respect to <FIG>.

In more detail, <FIG> further includes a MICO mode selection step <NUM> following UE context establishment steps <NUM>, <NUM> and before N11 messages <NUM>, <NUM>. The AMF <NUM>, based on local configuration and expected UE behaviour or Mobility Pattern, determines whether the MICO mode is allowed for the UE.

In step <NUM>, the AMF <NUM> indicates, using the MO-only / MICO mode indicator, whether MICO mode is allowed for the UE <NUM>, to the (R)AN <NUM> and/or the UE <NUM>. The AMF <NUM> provides the periodic registration update timer value determined by it using the periodic registration update timer parameter.

In more detail, while <FIG> includes the MO-only mode notification <NUM> and MO-only mode notification acknowledgement <NUM>, these operations are omitted in <FIG>.

With respect to <FIG>, in the registration request step <NUM>, a MICO mode preference indicator is provided in the registration request. The MICO mode preference indicator indicates whether MICO mode is preferred or not. A UE <NUM> may indicate a preference for MICO mode during initial registration or a registration update. It may also indicate a preferred MICO mode duration. The registration request may include a communication duration value requested by the UE <NUM>.

In addition, with respect to <FIG>, this embodiment is similar to that as discussed above with respect to <FIG>. However, the embodiment illustrated in <FIG> further includes two further optional steps <NUM> and <NUM> after UE Context Termination steps <NUM>, <NUM> and before Registration steps <NUM>, <NUM>. Step <NUM> defines a pending data indication that is transmitted from the AMF <NUM> to the (R)AN <NUM>. The (R)AN <NUM> may take this information into account when determining user inactivity. The AMF <NUM> can determine the Pending Data Indication message, as described in clause <NUM>. <NUM>, TS <NUM>. In Step <NUM> the (R)AN <NUM> can optionally send an Acknowledgment of receipt of the pending data indication to the AMF <NUM>.

<FIG>, <FIG> and <FIG> can be understood with reference to <FIG>, with terms such as "MO-only" replaced with "MICO".

Operations supporting a UE-triggered service request in the connection management (CM)_IDLE state will now be described. These operations can include aspects supporting network slicing operations.

The Service Request procedure can be used by a UE <NUM> in the CM_IDLE state to request the establishment of a secure connection to an AMF <NUM>. The UE <NUM> in the CM_IDLE state initiates the Service Request procedure in order to send uplink signalling messages, user data, and/or response to a network paging request. After receiving the Service Request message, the AMF <NUM> may perform authentication, and the AMF <NUM> may (e.g. if required for standards compliance) perform the security procedure. After the establishment of a secure signalling connection to an AMF <NUM>, the UE <NUM> or network <NUM> may send signalling messages, e.g. PDU session establishment from UE <NUM> to the network <NUM>. Alternatively, the SMF <NUM>, via the AMF <NUM>, may start the user plane resource establishment for the PDU sessions requested by the network <NUM> and/or indicated in the Service Request message.

For any Service Request, the AMF <NUM> may respond with a Service Response message to synchronize PDU session status between the UE <NUM> and the network <NUM>. The AMF <NUM> may also respond with a Service Reject message to the UE <NUM>, if the Service Request cannot be accepted by the network <NUM>.

For a Service Request initiated due to the presence of user data, the network <NUM> may take further actions if user plane resource establishment is not successful.

It is noted that the procedure described here is not necessarily applicable for an access network <NUM> (once the UE <NUM> is registered in the network <NUM>) in which the UE <NUM> is always considered to be in the CM_CONNECTED state and in which the user plane resource is always considered established for an active PDU session.

<FIG> illustrates a UE-triggered service request procedure provided in accordance with an embodiment of the present invention, which is described below.

In step <NUM> the UE <NUM> transmits a MM NAS Service Request to the (R)AN <NUM>. The NAS Service request may indicate PDU session ID(s), security parameters, and/or PDU session status. The UE <NUM> sends the NAS message Service Request towards the AMF <NUM> encapsulated in an RRC message to the (R)AN <NUM>. The RRC message(s) that can be used to carry the <NUM>-GUTI and this NAS message are described in 3GPP TS <NUM> and 3GPP TS <NUM>.

If the Service Request is triggered for user data, the UE <NUM> includes the PDU session ID(s) in the NAS Service Request message to indicate the PDU session(s) that the UE <NUM> is to use. If the Service Request is triggered for signalling only, the UE <NUM> does not necessarily include any PDU session ID. When this procedure is triggered for paging response, if the UE <NUM> needs to use some PDU session(s), the UE <NUM> includes the PDU session ID(s) in the MM NAS Service Request message to indicate the PDU session(s) that the UE <NUM> needs to use. Otherwise the UE <NUM> does not necessarily include any PDU session ID.

It is noted that the PDU session status indicates the PDU sessions available in the UE <NUM>.

In step <NUM>, the (R)AN <NUM> transmits an N2 Message to the AMF <NUM>. The N2 message includes an MM NAS Service Request, <NUM>-GUTI, Location information, RAT type, and/or RRC establishment cause. Details of this step are described in 3GPP TS <NUM>. If the AMF <NUM> can't handle the Service Request it will reject it. The <NUM>-GUTI is obtained in RRC procedure in 3GPP TS <NUM>. The (R)AN <NUM> selects the AMF <NUM> according to the <NUM>-GUTI. The Location Information and RAT type relates to the cell in which the UE <NUM> is camping. Based on the PDU session status, the AMF <NUM> may initiate PDU session release procedure if the PDU session is not available in the UE <NUM>.

In step <NUM>, if the Service Request was not sent integrity protected or integrity protection is indicated as failed, the AMF <NUM> initiates NAS authentication/security procedure as defined in clause <NUM> of TS23. If the UE <NUM> triggered the Service Request to establish a signalling connection only, after the security exchange the UE <NUM> and the network <NUM> can send signalling and the remaining steps illustrated in <FIG> are skipped.

In step 424a, which is a conditional step, the AMF <NUM> sends an N11 Message to the SMF <NUM>. The message may include PDU session ID(s). If the MM NAS Service Request message includes PDU session ID(s), or this procedure is triggered by the SMF <NUM> but PDU session IDs from the UE <NUM> correlates to other SMFs <NUM> than the one triggering the procedure, the AMF <NUM> sends an N11 message to the SMF(s) <NUM> associated with the PDU session ID(s).

In step 424b, which is a conditional step, the SMF <NUM> sends an N11 Message to the AMF <NUM>. The message may include N2 SM information such as quality of service (QoS) profile, and/or CN N3 Tunnel Info)). After receiving the N11 Message in step 424b, each SMF <NUM> sends an N11 Message to the AMF <NUM> to establish the user plane(s) for the PDU sessions. The N2 SM information contains information that the AMF <NUM> is to provide to the (R)AN <NUM>.

In step <NUM>, the AMF <NUM> sends an N2 Request to the AN <NUM>. The N2 request indicates some or all of: an MT data indicator, N2 SM information received from SMF <NUM>, security context, AMF Signalling Connection ID, a Handover Restriction List, and/or a MM NAS Service Accept message. The MT data indicator indicates that MT data will be triggered by MO data, and/or indicates that there is pending MT data or signalling in the network <NUM>, as described in Section <NUM>. <NUM> in TS <NUM>. In some embodiments, the MT data indicator includes an indication of a state transition timer or expected inactivity period.

In some embodiments, the state transition timer or the expected inactivity period are configured such that they are substantially infinite in time. This configuration of the state transition timer or the expected inactivity period can provide a means to inhibit the AN <NUM> from triggering an RRC release or N2 release.

The (R)AN <NUM> stores the Security Context, AMF Signalling Connection ID, QoS Information for the QoS Flows of the PDU Sessions that are activated, and/or N3 Tunnel IDs in the UE (R)AN context. Handover Restriction List is described in TS <NUM> [<NUM>] clause <NUM>. <NUM> "Mobility Restrictions".

The MM NAS Service Accept includes PDU session status in the AMF <NUM>. The AMF <NUM> may be required to include at least one N2 SM information from the SMF <NUM>, if the procedure is triggered for PDU session user plane setup. The AMF <NUM> may send additional N2 SM information from SMFs <NUM> in separate N2 message(s) (e.g. N2 tunnel setup request), if there is any Alternatively, if multiple SMFs <NUM> are involved, the AMF <NUM> may send one N2 Request message to the (R)AN <NUM> after all the N11 messages from SMFs <NUM> are received. In such case, the N2 Request message includes the N2 SM information received in each of the N11 messages and information to enable the AMF <NUM> to associate responses to the relevant SMF <NUM>.

In step <NUM>, the (R)AN <NUM> and the UE <NUM> interact to performs an RRC Connection Reconfiguration operation involving the UE <NUM>. This operation depends on the QoS Information for all the QoS Flows of the PDU Sessions activated and Data Radio Bearers. The user plane security is established at this step, which is described in detail in 3GPP TS <NUM> and 3GPP TS <NUM>. The (R)AN <NUM> forwards the MM NAS Service Accept message to the UE <NUM>. The UE <NUM> locally deletes the context of PDU sessions that are not available in <NUM> CN.

In step <NUM>, after the user plane radio resources are setup, the uplink data from the UE <NUM> can now be forwarded to the (R)AN <NUM>. The <NUM> (R)AN sends the uplink data to the UPF address and Tunnel ID provided in step <NUM>.

In conditional step <NUM>, the (R)AN <NUM> sends a N2 Request Acknowledgement message to the AMF <NUM>. This message includes N2 SM information (e.g. (R)AN Tunnel info, List of accepted QoS Flows for the PDU Sessions activated, List of rejected QoS Flows for the PDU Sessions activated).

The message in step <NUM> may include N2 SM information(s), e.g. (R)AN tunnel information. The (R)AN <NUM> may respond N2 SM information with a separate N2 message (e.g. N2 tunnel setup response) if the AMF <NUM> sends a separate N2 message in step <NUM>. If multiple N2 SM information is included in the N2 Request message in step <NUM>, the N2 Request Acknowledgement in step <NUM> can include multiple N2 SM messages and information to enable the AMF <NUM> to associate the responses to relevant SMFs <NUM>.

In conditional step <NUM>, the AMF <NUM> sends an N11 Message to the SMF <NUM>, per accepted PDU Session to the SMF <NUM>. This message can include N2 SM information ((R)AN Tunnel info), and RAT Type. If the AMF <NUM> received N2 SM information (one or multiple) in step <NUM>, then the AMF <NUM> may be configured to forward the N2 SM information to the relevant SMF <NUM>. If the UE Time Zone has changed compared to the last reported UE Time Zone then the AMF <NUM> may include the UE Time Zone IE in this message.

In optional step <NUM>, the SMF <NUM> interacts with the PCF <NUM> as follows. If dynamic PCC is deployed, the SMF <NUM> may initiate IP-CAN Session Modification and provides new location information to the PCF <NUM>.

In conditional step 431a, the SMF <NUM> sends an N4 Session Update Request (indicating (R)AN tunnel info) to the UPF <NUM>. If a user plane is to be setup or modified the SMF <NUM> initiates a N4 Session Modification procedure and provides (R)AN Tunnel Info.

In conditional step 431b, the UPF400 sends an N4 Session Update Response to the SMF <NUM>.

In conditional step <NUM>, the SMF <NUM> sends an N11 Message Acknowledgement to the AMF <NUM>.

Embodiments of the present disclosure relate to UE mobility, for example as it pertains to UE registration and connection management. A expected UE behaviour or mobility pattern is used to characterize and optimize the UE mobility. Aspects of the expected UE behaviour or mobility pattern that can be used according to various embodiments of the present disclosure are described below.

In some embodiments, MICO mode selection can be determined according to the UE expected UE behaviour or Mobility Pattern of the UE <NUM>, as the expected UE behaviour or Mobility Pattern is described herein.

The expected UE behaviour or Mobility Pattern is a concept that may be used, for example by a <NUM> system CN or comparable system, to characterize and optimise the UE mobility. It describes the historical and/or expected mobility and network access activities of the UE <NUM>. The CN can determine the expected UE behaviour or Mobility Pattern of the UE <NUM> based on subscription information for the UE <NUM>, statistics of the UE mobility, network local policy, (R)AN assisted information, the UE assisted information, or a combination thereof. In some embodiments, a non-3GPP (R)AN <NUM> can provide information assisting in expected UE behaviour or Mobility Pattern determination.

The statistics of the UE mobility can include a historical or expected UE <NUM> moving trajectory. The statistics and/or trajectory can be provided from the application function (AF) to the AMF <NUM> via the PCF <NUM> or via the PCF <NUM> and the network exposure function (NEF). The (R)AN <NUM> provides information on serving access nodes of the UE <NUM> as (R)AN assisted information to the AMF <NUM>. The UE <NUM> provides the UE type, UE location, stationary or not indication, MO-only mode preference as UE assisted information to the AMF <NUM>. The subscription data in the UDM <NUM> includes communication pattern parameters. These may include, for example, whether periodic communication is performed or not, an indication of scheduled communication time(s), whether MICO is being employed or not, whether or not MT data is triggered by MO data, an expected time interval between MO data and MT data, and an indication of scheduled mobility location information. The AMF <NUM> may update the expected UE behaviour or Mobility Pattern if the (R)AN assisted information, the UE assisted information and/or the subscription data in the UDM <NUM> changes.

In various embodiments, the expected UE behaviour or mobility pattern can be used by the (e.g. <NUM>) system CN as an input to optimize mobility support provided to the UE <NUM>. The mobility support can include some or all of the following: registration area list allocation; paging area management including limits paging to a sub area of the registration area; UE connection state management; MICO mode and periodic registration update timer management; UPF selection; and Handover (HO) and path switching management.

Embodiments of the present disclosure provide for a method and system for determining (e.g. by the AMF) whether MICO mode is allowed for a UE <NUM>. The AMF <NUM> determines whether MICO mode is allowed for the UE <NUM> according to the expected UE behaviour or Mobility Pattern, which describes expected communication behaviour/activity of the UE <NUM>. If the expected UE behaviour or Mobility Pattern indicates that there is no network-initiated communication for the UE <NUM>, the MICO mode may be selected for the UE <NUM> and the periodic registration update timer can be set to have a large value. If the expected UE behaviour or Mobility Pattern indicates a scheduled network-initiated communication time, the MICO mode may be selected for the UE <NUM> and the periodic registration update timer may be set to have such a value that the timer will expire before the network-initiated communication takes place. If the expected UE behaviour or Mobility Pattern indicates uncertainty about network-initiated communication and/or its for the UE <NUM>, the MICO mode may be refrained from being selected for the UE <NUM>.

As used herein, the expected UE behaviour or Mobility Pattern potentially reflects to one or more of a variety of factors, including but not limited to geographic device mobility. The expected UE behaviour or mobility pattern can incorporate, for example, temporal communication patterns, temporal and geo-spatial communication patterns, relevant operator policy, UE <NUM> preferences, data volumes, or a combination thereof. The expected UE behaviour or mobility pattern may indicate the times and/or locations at which the UE is active. The expected UE behaviour or mobility pattern can reflect past and/or expected future behaviours of the UE <NUM>. In some embodiments, certain selected parts of an overall expected UE behaviour or mobility pattern (e.g. the UE's communication pattern) can be used to determine or anticipate the UE's MICO mode selection and periodic registration update timer values.

When an MICO UE <NUM> is in the CM_CONNECTED state after it has sent MO Data, the UE <NUM> is kept in the CM_CONNECTED state until a state transition timer expires. Further, the network infrastructure may be configured to move the UE <NUM> into the CM_IDLE state sufficiently slowly that MT data can be delivered. If the expected UE behaviour or communication pattern or Mobility Pattern of an MICO UE <NUM> indicates that MT data is to be triggered by MO data, or that there is data or signalling pending in the network, the AMF <NUM> may indicate this to the (R)AN <NUM>, for example, during a Service Request procedure. According to the indication, the (R)AN <NUM> determines whether and when to trigger RRC release or N2 release when lack of data activity is observed for the UE <NUM>. In some embodiments, the UE <NUM> may notify the AMF <NUM> of the end of communication operations through an NAS message when it is in the CM_CONNECTED state, after it has finished communication.

In some embodiments, upon, for example as a result of, an end of communication notification from the UE <NUM>, the AMF <NUM> triggers N2 release to move the UE <NUM> into the CM_IDLE state. The state transition timer is determined by the AMF <NUM> and indicated to the (R)AN <NUM> during the Service Request procedure message <NUM>. The (R)AN <NUM> does not initiate RRC release after the UE <NUM> has sent MO data until the state transition timer expires.

According to various embodiments, operation with respect to the MICO mode, for example as previously described in TS <NUM> (Section <NUM>. <NUM>) is described as follows.

A UE <NUM> may indicate preference for MICO mode during initial registration or during a registration update. The AMF <NUM>, based on local confirmation and the expected UE behaviour or Mobility Pattern, determines whether MICO mode is allowed for the UE <NUM> and indicates it to the UE <NUM>, together with the accordingly determined periodic registration update timer value, during the registration procedure.

If the expected UE behaviour or Mobility Pattern, as described in the subscription information, indicates that there is no non-MICO mode or no network-initiated communication for the UE <NUM>, the MICO mode may be selected for the UE <NUM> and the periodic registration update timer can be set to have a large value. If the expected UE behaviour or Mobility Pattern, as described in the subscription information indicates Scheduled non-MICO activity and/or network-initiated communication time, the MICO mode may be selected for the UE <NUM> and the periodic registration update timer may be set to have such a value that the timer will expire before the network-initiated communication takes place. If the expected UE behaviour or Mobility Pattern, as described in the subscription information, indicates uncertainty about non-MICO activities and/or network-initiated communication and/or their schedule for the UE <NUM>, the MICO mode may be refrained from being selected for the UE <NUM>.

The UE <NUM> and CN can re-initiate or exit the MICO mode at subsequent registration signalling. If the MICO mode is not indicated explicitly in Registration, then both the UE <NUM> and the AMF <NUM> may be configured to refrain from using the MICO mode. The AMF <NUM> may provide a non-stoppable timer indication to a UE <NUM> in the MICO mode when providing the periodic registration update timer value to the UE <NUM>. For example, the periodic registration update timer value and the non-stoppable timer indication may be sent to the UE <NUM> as part of the Registration Accept message <NUM> in the Registration procedure. If the non-stoppable timer indication is provided, the UE <NUM> keeps its periodic registration update timer running while in the CM_CONNECTED state and performs a periodic registration update when the timer expires, in order to re-negotiate the MICO mode and the periodic registration update timer value.

Thus, when the UE <NUM> receives the non-stoppable timer indication, the UE <NUM> does not reset the periodic registration update timer. Instead, upon receipt it sets the periodic registration update timer with the periodic registration update timer value and keeps the periodic registration update timer running until the non-stoppable timer indication is removed. Thus, if the UE <NUM> enters the CM_CONNECTED state, by way of non-limiting example to send data in the UL direction, the UE <NUM> will not restart the periodic registration update timer because of the non-stoppable timer indication. When the periodic registration update timer expires, the UE <NUM> performs a registration update. In the context of such registration update, the MICO mode and periodic registration update timer value negotiation may be repeated.

In some examples, as an alternative to the non-stoppable timer solution, the AMF <NUM> may update the periodic registration update timer value provided to the UE <NUM> through a UE configuration update procedure, such as is described in 3GPP TS <NUM>, clause <NUM>. <NUM>, when the UE is in the CM_CONNECTED state. During the update procedure, the AMF <NUM> sends the updated timer value to the UE <NUM> as one of the mobility management related parameters. When the UE <NUM> enters the CM_IDLE state, the UE <NUM> sets the periodic registration update timer using such updated timer value and performs a periodic registration update when the timer expires.

The AMF <NUM> can assign a registration area to the UE <NUM> during the registration procedure. When the AMF <NUM> indicates MICO mode to a UE <NUM>, the registration area is not constrained by paging area size. The network, based on local policy, and subscription information, may decide to provide an "all PLMN" registration area indication to the UE <NUM>. In that case, re-registration to the same PLMN due to mobility does not apply.

In one embodiment, the AMF <NUM> provides a registration area to the UE <NUM> in MICO mode. The registration area size may be bound to Mobility restrictions (i.e. the registration may be contained by the allowed area) and by requirements to perform tracking for the UE <NUM>.

When the AMF <NUM> indicates MICO mode to a UE <NUM>, the AMF <NUM> considers the UE <NUM> as always unreachable while in the CM_IDLE state. The CN rejects requests for downlink data delivery for an MICO UE <NUM> in the CM_IDLE state. The CN also defers downlink transport over NAS for SMS, location services, etc. The UE <NUM> in MICO mode is reachable for mobile terminated data or signalling when the UE <NUM> is in the CM_CONNECTED state for the PDU sessions that are resumed.

If the expected UE behaviour or communication pattern or Mobility Pattern of a MICO UE100 indicates that MT data is to be triggered by MO data, the AMF <NUM> can indicate this to the (R)AN <NUM> using an MT data indicator during the procedures, such as Service Request procedure that moves the UE <NUM> from the CM_IDLE state into the CM_CONNECTED state. According to the MT data indicator, the (R)AN <NUM> decides whether and when to trigger RRC release or N2 release when lack of data activity is observed for the UE <NUM>.

It is noted that the MT data indicator may include a state transition timer or an expected inactivity period indicative that the (R)AN <NUM> should not trigger RRC release or N2 release until the timer expires or the expected inactivity period is over. The MT data indicator may potentially include such a state transition timer or an expected inactivity period and the AMF <NUM> may determine the value of the state transition timer or the expected inactivity period.

In some examples, the AMF <NUM> may determine the value of the state transition timer and/or the expected inactivity period based on the expected UE behaviour, communication pattern and/or Mobility Pattern of the MICO UE <NUM>. By way of non-limiting example, the timer value may be computed as a function of the time interval between sending MO data and receipt of MT data triggered by such MO data (which may be part of the communication pattern parameters) and/or the maximum MT or MO data transport delay, which may be obtained from a third party, including without limitation, an application server and/or application function. In some embodiments, the maximum MT or MO data transport delay is included in the time interval between sending MO data and the receipt of MT data triggered by MO data.

When the AMF <NUM> indicates MICO mode to a UE <NUM>, the AMF <NUM> may allocate and provide an active timer value to the UE <NUM>. The active timer value may be determined by the AMF <NUM> according to the expected UE behaviour, communication pattern and/or Mobility Pattern of the MICO UE <NUM>, in a way that is similar and/or identical to the way the AMF <NUM> determines the state transition timer described above.

In some examples, the AMF <NUM> may provide the (updated) active timer value to the UE <NUM> when it enters the CM-CONNECTED state, by way of non-limiting example, during a service request procedure triggered by the UE <NUM>. In the present disclosure, the concepts of UL and MO communications are used interchangeably as are the concepts of DL and MT communications.

In some examples, the communication pattern information, the expected UE behaviour information and/or the Mobility Pattern information may be provided by a third party, by way of non-limiting example, by an AF.

The active timer value may in some examples be equal to the state transition timer value. In some examples, the active timer value is a function of the state transition timer value. In some examples, the state transition timer value is a function of the active timer value.

The UE <NUM> may request an active timer value from the AMF <NUM>, by way of non-limiting example, when the UE <NUM> indicates a MICO mode preference to the AMF <NUM>. If an active timer value is requested by the UE <NUM>, the AMF <NUM> may take the requested active timer value into account when determining the active timer value actually allocated to the UE <NUM>. The AMF <NUM> may also take the requested active timer value into account when determining a value for the state transition timer. In some examples, when an active timer value is requested by the UE <NUM>, it implicitly indicates that MICO mode is preferred by the UE <NUM>, and in that case, the MICO preference indication from the UE <NUM> may be omitted.

Before the UE <NUM> transitions to the CM_IDLE state, the UE <NUM> may set an active timer using the active timer value and only enter the CM_IDLE state only after expiration of the active timer. During the period before expiry of the active timer, the UE <NUM> remains in the CM_CONNECTED state, and the UE <NUM> may stop and/or reset the active timer if it has MO data to send and/or if it receives MT data.

In some examples, the (R)AN <NUM> may determine a data inactivity timer value and set a data inactivity timer using such value. The data inactivity timer is used to detect data inactivity at the UE <NUM>. If no data activity is detected before the expiry of the data inactivity timer, the (R)AN <NUM> may consider that the UE <NUM> has no data activity and then starts to set the state transition timer. Upon expiry of the state transition timer, the (R)AN <NUM> may trigger RRC release and/or N2 release. The (R)AN <NUM> may stop the data inactivity timer and the state transition timer at any time if it detects data activity for the UE <NUM>.

The (R)AN <NUM> may notify the UE <NUM> of the data inactivity timer value, including, without limitation, during RRC procedures. The UE <NUM> may use the data inactivity timer value to set a local data inactivity timer to determine data inactivity for itself in a manner similar and/or identical to the way that the (R)AN <NUM> determines the data inactivity of the UE <NUM> described above. Upon expiry of the data inactivity timer, the UE <NUM> may decide to transition to the CM_IDLE state. Before entering the CM_IDLE state, the UE <NUM> may use the active timer value received from the AMF <NUM> to set the active timer.

A UE <NUM> in MICO mode may notify the AMF <NUM> to indicate the end of communication through NAS message when it is in the CM_CONNECTED state, after it has finished communication. Upon end of communication notification from the UE <NUM>, the AMF triggers N2 release to move the UE into the CM_IDLE state.

In various embodiments, a UE <NUM> in MICO mode performs periodic registration at the expiration of the periodic registration update timer.

In various embodiments, a UE <NUM> in MICO mode need not listen to paging while in the CM_IDLE state. A UE <NUM> in MICO mode may stop any access stratum procedures in the CM_IDLE state, until the UE <NUM> initiates CM_IDLE to CM_CONNECTED state transition procedures due to one or more of the following triggers: a change in the UE <NUM> (e.g. change in configuration) requires an update its registration with the network; a periodic registration update timer expires; MO data is pending; and/or MO signalling is pending (e.g. a SM procedure is initiated).

In various embodiments, if a registration area that is not the " all PLMN" registration area is allocated to a UE <NUM> in MICO mode, then the UE <NUM> determines if it is within the registration area or not when it has MO data or MO signalling.

In some embodiments, the AMF <NUM> indicates to the (R)AN <NUM> that the UE <NUM> is in MICO mode.

In one embodiment, for indicating the state transition timer or the expected inactivity period to the (R)AN <NUM>, the AMF <NUM> may inform the (R)AN <NUM> of the state transition timer or the expected inactivity period during a registration procedure, for example at the same time that it indicates the UE's MICO mode to the (R)AN <NUM>, or by way of a separate step. Later, during the service request procedure, the AMF <NUM> updates the (R)AN <NUM> with the timer value or the inactivity period value (e.g. only) when the timer value or the inactivity period value changes, for example, due to UE's communication pattern change.

Continuing with the above embodiment, the AMF <NUM> determines the state transition timer or the expected inactivity period for a MICO UE <NUM> according to the communication pattern indicated by the user subscription data or the UE's expected UE behaviour or mobility pattern. If the communication pattern indicates that MO data will not trigger MT data, the timer or the period may be assigned a pre-configured default value. If the communication pattern indicates that MO data will trigger MT data and the expected time interval between MT data and MO data, the timer or the period may be set to have a value not smaller than the sum of that time interval and the estimated round trip delay of a packet. The estimated round trip delay may be configured in the AMF <NUM> or retrieved by the AMF <NUM> from an external data storage. If the information of that time interval is not available, a configured default value will be applied in the timer or period value determination.

Continuing with the above embodiment, if the AMF <NUM> does not inform the (R)AN <NUM> of the state transition timer or the expected inactivity period, the (R)AN <NUM> may not initiate or may be configured to avoid initiating RRC release and/or avoid requesting for N2 release. As such, the state transition timer can be enforced even if the (R)AN <NUM> is unaware of it. The (R)AN <NUM> may notify or may however be configured to notify the AMF <NUM> regarding the end of MO data activity so that the AMF <NUM> can determine when to trigger N2 release (thus moving the UE from the CM_CONNECTED state to the CM_IDLE state).

<FIG> describes the AMF-centric state transition procedure, according to an embodiment of the present invention.

In step <NUM>, the UE <NUM> performs registration with the network. During the registration procedure, the UE <NUM> is notified about its MICO mode assignment and periodic registration update timer, as described in clause <NUM>. <NUM> in TS23. At this step, the (R)AN <NUM> may also be notified about the UE's MICO mode assignment. At this step a PDU session can be activated and upon completion of this step the UE <NUM> may enter the CM_CONNECTED state.

In some embodiments, in step <NUM>, when the UE <NUM> has MO data in the CM_IDLE state, it initiates the service request procedure to enter the CM_CONNECTED state, as described in clause <NUM>. <NUM> in TS23. A PDU session can be activated at this step. It would be understood that step <NUM> can be optional as this transition of the UE <NUM> to the CM_CONNECTED state may occur automatically upon completion of step <NUM> as noted above.

In step <NUM>, the UE <NUM> requests to establish a PDU session for the MO data, as described in clause <NUM>. <NUM> in TS23. <NUM>, if no PDU session is activated at step <NUM> or step <NUM>.

In step <NUM>, the (R)AN <NUM> notifies the AMF <NUM> that MO activity finished using N2 message. If MT activity also finished, the (R)AN <NUM> notifies the AMF <NUM> at the same time.

In step <NUM>, the AMF <NUM> determines whether and/or when to move the UE <NUM> into the CM_IDLE state and sets up the state transition timer or the expected inactivity period, as described in clause <NUM>. <NUM> in TS23.

In step <NUM>, the (R)AN <NUM> notifies the AMF <NUM> about the end of MT activity using N2 message.

In step <NUM>, when the AMF <NUM> is notified about end of MT activity (step <NUM>) or when the state transition timer expires or when the expected inactivity period is over, the AMF <NUM> initiates the N2 release procedure to move the UE <NUM> into the CM_IDLE state and at the same time deactivates PDU sessions.

A MICO UE <NUM> in the CM_CONNECTED state may request a transition to the CM_IDLE state, for example, after the UE <NUM> finishes receiving MT data. To support same, the UE <NUM> may send an NAS message to the AMF <NUM> to indicate the intention of going idle, which then triggers N2 release. The UE <NUM> may also interact with the (R)AN <NUM> to release RRC, which will result in the (R)AN <NUM> requesting the AMF <NUM> to perform N2 release and thus move the UE <NUM> from the CM_CONNECTED state into the CM_IDLE state. When N2 is released, the UE <NUM> enters the CM_IDLE state.

<FIG> illustrates uplink-triggered downlink transmission for a UE <NUM> in MICO mode, according to another embodiment of the present disclosure. Location tracking of a device (UE) may be performed for a short or limited period of time after the device sends uplink (UL) data so that DL packets can be delivered to the UE <NUM>. The DL packets may be triggered by transmission of the UL packets. This can be referred to as on-demand location tracking (LT).

With reference to <FIG>, triggering of a CN state transition from a CM_IDLE state (where LT is not performed for the UE <NUM>) to a CM_CONNECTED state (where LT is performed for the UE <NUM>) may be based on the occurrence of UL data being transmitted by a UE <NUM> and/or an associated NAS service request. Triggering of the CN state transition from the CM_CONNECTED state to the CM_IDLE state may be device-triggered or network-triggered. A device-triggered transition may be based on an occurrence of number of DL packets or DL application messages (pre-configured or on-line configured to device), or based on a time window (pre-configured or on-line configured to device). The trigger may be pre-configured for the device or configured through an on-line configuration operation involving the device. The time window may reflect the (e.g. expected) duration of DL activity, for example. The duration of this time window can be referred to as the window open width. A network-triggered transition may be a NAS-triggered transition (for example in which the AMF <NUM> obtains the pre-configuration of the device's window open width), or a (R)AN-triggered transition (for example in which the (R)AN <NUM> obtains the pre-configuration of the device's window open width).

Pre-configuration can refer to UE configuration by a management function or UE configuration during manufacture, for example. On-line configuration can refer to over-the-air programming, setting of configuration register information by management signaling, receiving configuration information from the AMF <NUM>, etc..

CN-assisted (R)AN parameter tuning aids the (R)AN <NUM> to minimize the UE state transitions and to achieve optimum network behaviour. CN assistance information may be derived by the AMF <NUM>, per UE <NUM> in the AMF <NUM>, based on a collection of UE behaviour statistics, UE assistance information (as described below), or other available information about the communication pattern or expected UE behaviour (such as a subscribed data network name (DNN), international mobile subscriber identity (IMSI) ranges, or other subscription information). If the communication pattern parameters of the UE <NUM> are available, the AMF <NUM> may use this information when selecting the CN-assisted (R)AN parameter values. If the AMF <NUM> is able to derive the communication pattern or expected UE behaviour or Mobility Pattern of the UE <NUM> (as described in clause <NUM>. <NUM> of TS <NUM>), the AMF <NUM> may take the communication pattern or expected UE behaviour or Mobility Pattern information into account when selecting the CN-assisted (R)AN parameter values.

The communication pattern parameters and the expected UE behaviour or Mobility Pattern information may be used by the AMF <NUM> as input to derive the CN-assisted (R)AN parameter values. In the case of statistics-based CN assistance information collection, this may be enabled based on a local configuration (e.g. a subscribed DNN, IMSI ranges or other subscription information). The CN assistance information provides the (R)AN <NUM> with a way to understand the UE behaviour for "Expected UE activity behaviour" and for "Expected HO behaviour". "Expected UE activity behaviour" may include the expected pattern of the UE's changes between the CM_CONNECTED and CM_IDLE states. This may be derived, for example, from the communication pattern parameters of the UE <NUM>. The (R)AN <NUM> may use this information, together with other information such as a Pending Data Indication from the AMF <NUM>, to determine user inactivity. "Expected HO behaviour", may include the expected target (R)AN <NUM> nodes within a certain time window, and the expected interval between inter-(R)AN handovers. This may be derived, for example, from the communication pattern or expected UE behaviour or Mobility Pattern information of the UE <NUM>. The (R)AN <NUM> may use this information to perform a "make before break" during a hand over procedure, which allows the UE <NUM> to be connected to both the source (R)AN node and the target (R)AN node at the same and achieves zero handover delay.

The AMF <NUM> determines when to send this information to the (R)AN <NUM> as "Expected UE behaviour" carried in N2 signalling over the N2 interface. The information is sent to the (R)AN <NUM> during Registration or Service Request procedures. It should be noted that the calculation of the CN assistance information (i.e. the algorithms used and the related criteria), and the decision when it is considered suitable and stable to send the information to the (R)AN <NUM>, may be implementation-specific. Unreliable information should not be provided to the (R)AN <NUM> as it may drive undesirable system effects.

A UE-assisted connection management may complement the CN-assisted (R)AN parameter tuning approach. The AMF <NUM> may use UE assistance information when selecting CN-assisted (R)AN parameter values, especially when the UE's communication pattern parameters are not available (e.g. when it is not provided as part of subscription information). For example, the UE <NUM> may provide an communication duration value, which indicates the expected duration of UE communication activity to the AMF <NUM>. The AMF <NUM> determines the "Expected UE activity behaviour" accordingly and informs the relevant CN-assisted (R)AN parameter values to the (R)AN <NUM>. If the communication duration was over-estimated by the UE100, the UE <NUM> may send an "End of communication" notification to the AMF <NUM> for correction after the UE <NUM> finishes its activity. The AMF <NUM> takes this information into account when determining a network-triggered UE context release, i.e. to transition the UE <NUM> from the CM_CONNECTED state to the CM_IDLE state.

UE-assisted connection management aids the CN to minimize the UE state transitions and to achieve optimum network behaviour. A UE <NUM> may request a communication duration value during Registration or Service Request procedures. The UE request communication duration value may be included in the Registration Request message <NUM> or in the Service Request message <NUM> (or NAS message <NUM>). The UE requested value indicates the expected duration of communication activity from the UE's perspective. The AMF <NUM> determines the communication duration value that is allocated to the UE <NUM>.

When determining the communication duration value that is allocated to the UE <NUM>, the AMF <NUM> may receive as input the UE requested communication duration value and a collection of UE behaviour statistics, or other available information about the communication pattern or expected UE behaviour (such as subscribed DNN, IMSI ranges, communication pattern parameters, or other subscription information). If the AMF <NUM> determines to allocate a communication duration value to the UE <NUM>, the AMF <NUM> may provide the communication duration value to the UE <NUM> through Registration signalling (e.g., as part of the Registration Accept message <NUM>), Service Request signalling (e.g., as part of a Service Request Accept message <NUM> or <NUM>), or UE Configuration Update signalling (e.g., as part of the UE configuration to be updated). A UE <NUM> may change the communication duration value to a new value, e.g. when the conditions are changed in the UE <NUM>, by requesting the new value in Registration or Service Request procedures (through the Registration Request message <NUM> or the Service Request message <NUM> (or NAS message <NUM>), respectively). If a communication duration value is allocated to the UE100, the AMF <NUM> may take the communication duration value into account when determining the "Expected UE activity behaviour" as CN-assisted (R)AN parameter values (as described above), and the UE <NUM> may start a communication activity timer with the communication duration value when transitioning from the CM_IDLE state to the CM_CONNECTED state. If the communication activity timer has not expired when the UE <NUM> completes its communication activity, the UE <NUM> may send an "End of communication" notification to the AMF <NUM>. The AMF <NUM> may take this information as input when determining a network-triggered UE context release in the (R)AN <NUM>, i.e. to transition the UE <NUM> from the CM_CONNECTED state to the CM_IDLE state. The UE <NUM> may stop the communication activity timer, if running, when a transition to the CM_IDLE state is made.

<FIG> illustrates operation in relation to a known short DL transmission schedule, according to another embodiment of the present invention. This may facilitate location tracking of a device being performed before the DL transmission schedule and lasting until the completion of the short DL data transmission.

According to embodiments and with reference to <FIG>, a device is assumed to be switched to Non-MICO mode and in CM_CONNECTED state for DL data reception. After the data reception, the device is switched back to MICO CM_IDLE state.

To provide for a MICO to Non-MICO transition, the device is triggered by sending a location update NAS message at a time that is pre-configured according to a time schedule. The time schedule can be set off-line or online. The device may be triggered by sending de-MICO mode registration (e.g. via NAS).

To provide for a non-MICO to MICO transition and/or to provide for a CM_CONNECTED to CM_IDLE state transition for a MICO mode device (see e.g. <FIG>), for device triggering, the device may be triggered by occurrence of a predetermined number of DL application packets. The number may be pre-configured or configured by an on-line interaction with the device. Alternatively, the device may be triggered in accordance with a time window, which is pre-configured or configured by an on-line interaction with the device.

To provide for a non-MICO to MICO transition, for network triggering, NAS triggered or (R)AN triggering can be used. NAS triggering can be pre-configured for example using operations involving the AMF <NUM>. For (R)AN <NUM> triggering, the (R)AN <NUM> may obtain pre-configuration information indicative of the device's window open width. As previously noted, the window open width can refer to the duration of a time window during which the device can receive DL packets, e.g. following an UL transmission. This may be the duration in which the device remains in Non-MICO mode following an UL transmission, for example.

According to embodiments, the transition between MICO mode and non-MICO mode is based on whether there are network-initiated communication operations pending for the UE <NUM>. The transition can be based on the schedule of network-initiated communication operations, for example, it is desired that the UE <NUM> enters non-MICO mode before a network-initiated communication activity happens, since the data will not be delivered to the UE <NUM> if it is in MICO mode as the UE <NUM> is not tracked when it is in MICO mode. According to embodiments, upon completion of the network-initiated communication, the UE <NUM> returns to MICO mode again. As such, according to embodiments, two types of windows are provided, namely a first window where no network-initiated communication is expected and a second window where network-initiated communication is expected. It will be understood that the size of the first and second window can vary over time, for example window size can be based on the communication schedule or schedule update or other aspect.

Those skilled in the art will appreciate that at times nodes or functions are described as communicating with each other. It should be understood that this term can comprise both uni- and bi-directional communication. As such, communication should be understood to include at least one of transmitting and receiving messages or communications from another node. It should also be understood that in the above description there has been reference to individual steps. In an alternate explanation, each step may be understood as transmitting or receiving a message, or carrying out an internal process. Thus, for example, where reference is made to, for example, step <NUM>, it could alternately be understood as the UE <NUM> transmitting a registration request <NUM> to (R)AN <NUM>.

<FIG> is a block diagram of a computing system <NUM> that may be used for implementing the devices and methods disclosed herein. Specific devices may utilize all of the components shown or only a subset of the components, and levels of integration may vary from device to device. Furthermore, a device may contain multiple instances of a component, such as multiple processing units, processors, memories, transmitters, receivers, etc. The computing system <NUM> typically includes a processor, such as a central processing unit (CPU) <NUM>, a bus and a memory <NUM>, and may optionally also include a mass storage device <NUM>, a video adapter <NUM>, and an I/O interface <NUM> (shown in dashed lines).

The processor <NUM> may comprise any type of electronic data processor. The bus may be one or more of any type of several bus architectures including a memory bus or memory controller, a peripheral bus, or a video bus.

The mass storage <NUM> may comprise any type of non-transitory storage device configured to store data, programs, and other information and to make the data, programs, and other information accessible via the bus. In some embodiments, mass storage <NUM> may be external to the computing system <NUM> and accessed through either I/O interface <NUM> or network interface <NUM>.

The video adapter <NUM> and the I/O interface <NUM> provide optional interfaces to couple external input and output devices to the computing system <NUM>. Examples of input and output devices include a display <NUM> coupled to the video adapter <NUM> and an I/O device <NUM> such as a touch-screen coupled to the I/O interface <NUM>. Other devices may be coupled to the computing system <NUM>, and additional or fewer interfaces may be utilized. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to provide an interface for an external device.

The computing system <NUM> may also include one or more network interfaces <NUM>, which may comprise wired links, such as an Ethernet cable, and/or wireless links to access one or more networks <NUM>. The network interfaces <NUM> allow the computing system <NUM> to communicate with remote entities via the networks <NUM>. For example, the network interfaces <NUM> may provide wireless communication via one or more transmitters/transmit antennas and one or more receivers/receive antennas. In an embodiment, the computing system <NUM> is coupled to a local-area network or a wide-area network for data processing and communications with remote devices, such as other processing units, the Internet, or remote storage facilities. In another embodiment, computing system <NUM> is hosted within a data center, and network interface <NUM> can be used to communicate over a high speed external bus to other data center functions including storage functions.

When embodied as a node within a data center, computing system <NUM> may be a virtual entity created using resources within the data center. In such a case, the elements described above, may be virtualized entities created to represent a physical analog to the virtualized computing system.

When discussed in the context of a data center, it should also be understood that optional elements such as a video adapter <NUM> and I/O interface <NUM> may not be present (thus being indicated as optional). Within a data center it is common for servers to be installed in a so-called headless configuration where they do not have standard I/O interfaces <NUM> or the ability to connect a display directly to a video adapter <NUM>. In such embodiments, operation and configuration of the computing system is often done through a remote access functionality routed through the network interface <NUM>.

Embodiments of the present invention may be implemented using computing, communication and/or memory devices. Computing devices used to implement method operations may include a processor operatively coupled to memory, the memory providing instructions for execution by the processor to perform the method as described herein. Embodiments of the present invention may be implemented at least in part using computing devices such as Application Specific Integrated Circuits, microcontrollers, and digital logic circuits. Embodiments of the present invention may be directed to improving internal operations of the communication network.

Through the descriptions of the preceding embodiments, the present invention may be implemented by using hardware only or by using software and a necessary universal hardware platform. Based on such understandings, the technical solution of the present invention may be embodied in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), USB flash disk, or a removable hard disk. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided in the embodiments of the present invention. For example, such an execution may correspond to a simulation of the logical operations as described herein. The software product may additionally or alternatively include number of instructions that enable a computer device to execute operations for configuring or programming a digital logic apparatus in accordance with embodiments of the present invention.

Claim 1:
A method for managing a connection of a user equipment, UE, (<NUM>) to a network, the method comprising actions at an access node, AN, (<NUM>) of:
receiving a registration request from the UE (<NUM>) comprising a mobile initiated connected only, MICO, mode preference; and
transmitting the registration request to an access and mobility management function, AMF, (<NUM>);
forwarding a response to the UE (<NUM>), wherein the response includes the AMF's (<NUM>) determination indicating that the MICO mode is allowed for the UE (<NUM>), a value of a periodic registration update timer, and an indication for disabling the UE's (<NUM>) reset of the periodic registration update timer before the periodic registration update timer expires.