Content for TR 23.700-61 Word version: 18.0.0

6.0 Mapping of Solutions to Key Issues 6.1 Solution #1: Usage of MICO mode for UE unavailability period management 6.2 Solution #2: UE provided Unavailability Period
...

6 Solutions p. 8

6.0 Mapping of Solutions to Key Issues p. 8

Table 6.0-1: Mapping of Solutions to Key Issues

Solutions	Key Issues
Solutions	1
1	X
2	X
3	X
4	X
5	X
6	X

6.1 Solution #1: Usage of MICO mode for UE unavailability period management p. 8

6.1.1 Introduction p. 8

This solution addresses Key Issue #1 on Determination of unavailability period in 5GS for a specific UE.

6.1.2 Functional Description p. 8

The solution relies on usage of Mobile Initiated Connection Only (MICO) mode as specified already in TS 23.501 and TS 23.502, with some enhancements.

Once the user or the application in the UE has decided to turn down the UE, the UE:

triggers Mobility Registration Update procedure indicating preference for MICO mode.
provides the network with an estimated time while the UE is going to be unavailable (or an estimated time for MICO mode).
stores its MM context in USIM or in non-volatile memory to avoid a full re-registration and reauthentication after MICO mode is terminated.
provides in the Registration Request message the PDU session status information indicating that all PDU sessions have been torn down, thus avoiding UE and 5G core to keep PDU sessions contexts while the UE is unavailable.

When receiving Registration Request with MICO indication, the AMF determines whether MICO mode is allowed for the UE, and if so, accepts the registration request and provides a periodic registration timer with a value that is at least equal to the estimated unavailability time from the UE. This then avoids that the network considers the UE de-registered while the UE is not in a situation where it could perform periodic registration update (because of the UE being unavailable).

After the unavailability period and when the UE comes back, the UE issues a new Registration Request without MICO mode indication, reusing the stored MM context, and re-establishes PDU sessions that are still required.

6.1.3 Procedures p. 9

The procedure is based on the general registration procedure specific in clause 4.2.2.2.2 of TS 23.502. Details are provided in Figure 6.1.3-1 and steps below.

Copy of original 3GPP image for 3GPP TS 23.700-61, Fig. 6.1.3-1: Registration with indication of UE unavailability

Figure 6.1.3-1: Registration with indication of UE unavailability
(⇒ copy of original 3GPP image)

Step 0.

UE decides to turn down, e.g. for OS upgrade or device reboot. The UE stores its MM context in USIM or non-volatile memory to be able to reuse it after its unavailability period.

Step 1.

The UE sends Registration Request to the AMF (via (R)AN). This step is the same as step 1 from clause 4.2.2.2.2 of TS 23.502. The UE includes MICO mode preference and an estimated time while the UE is going to be unavailable. The UE indicates, via PDU session status, that all PDU sessions are inactive.

Step 2-20.

Same steps as steps 2 to 20 from clause 4.2.2.2.2 of TS 23.502.

Step 21.

AMF sends Registration Accept to the UE. This step is similar to step 21 from clause 4.2.2.2.2 of TS 23.502. The AMF indicates accepted MICO mode. The AMF provides Periodic Registration Update timer greater than the estimated time when the UE is going to be unavailable, as provided by the UE in step 1.

Step 21b-25.

Same steps as steps 21b to 25 from clause 4.2.2.2.2 of TS 23.502.

Step 26.

When the UE is available again, the UE sends a Registration Request to the AMF without MICO mode indication.

Step 27.

The UE re-establishes the PDU sessions that are required.

6.1.4 Impacts on services, entities and interfaces p. 10

UE:

Determination of unavailability period;
Registration with MICO mode when unavailability starts, together with an indication of duration for unavailability (equivalent to a duration for MICO mode);
Storage of MM context in USIM or in non-volatile memory;
Tearing down of PDU sessions.

AMF:

Handling of MICO mode requests from the UE, and configuration of appropriate periodic registration timer taking UE indicated duration for unavailability into account.

6.2 Solution #2: UE provided Unavailability Period p. 10

6.2.1 Introduction p. 10

This solution addresses Key issue #1.

6.2.2 Functional Description p. 10

When the UE is about to become unavailable due to the events as described in Key issue #1, the UE initiates registration procedure indicating unavailability period.

The AMF, may set the periodic registration timer to a value equal or slightly larger than the unavailability period provided by the UE.

During this unavailability period the 5GC maintains the UE context in CM-IDLE, and considers the UE unreachable, in similar approach as MICO mode.

When the UE concludes the event that kept it unavailable, the UE triggers registration procedure and does not provide indication of unavailability period. During that registration procedure, if the AMF had assigned a periodic registration timer based on unavailability period, the AMF provides the UE with a regular value for the periodic registration timer (i.e. not considering unavailability period).

The use of periodic registration timer of similar value of the unavailability period is to make sure the UE resumes normal activity after the unavailability period is concluded.

6.2.3 Procedures p. 10

Figure 6.2.3-1 shows the call flow for this solution.

Copy of original 3GPP image for 3GPP TS 23.700-61, Fig. 6.2.3-1: UE triggered Unavailability Period

Figure 6.2.3-1: UE triggered Unavailability Period
(⇒ copy of original 3GPP image)

Step 1.

During initial Registration procedure, the UE provides indication of support of "Unavailability Period" in Registration Request, and the AMF provides support of "Unavailability Period" in Registration Accept message.

Step 2.

When an event as described in Key issue #1 is to be triggered in the UE, if "Unavailability period" support was indicated by AMF, a supporting UE proceeds with step 3 before executing the event and becoming unavailable.

Step 3.

The UE sends Registration Request message indicating an Unavailability period. The Unavailability period is determined internally in the UE, and implementation dependent, (e.g. may be determined based on type of event and expected event duration).

Step 4.

The AMF responds with Registration Accept. The AMF may set the periodic registration timer to a value equal or slightly larger than the unavailability period provided by the UE. The AMF stores the information that the UE is in unavailability period in UE context, and considers the UE unreachable until the UE performs registration procedure again. In this state, all HLCom solutions apply if supported, e.g. extended data buffering, downlink data buffering status report, etc.

Step 5.

Once the event is executed, the UE triggers registration procedure to resume regular service. The UE does not include Unavailability period in the registration request. Depending of the state the UE ends up after the event, the registration type may be initial registration, "mobility" or "periodic" registration.

Step 6.

The AMF responds with registration accept. If the AMF has stored that the previously assigned periodic registration timer was assigned based on unavailability period, the AMF assigns a new periodic registration timer not considering unavailability period.

6.2.4 Impacts on services, entities and interfaces p. 11

UE:

Support of unavailability period indication in registration procedure.

AMF:

Support of unavailability period indication in registration procedure.
Storing unavailability period in UE context.
Handling of MT data and control plane procedures for UE unreachable (no new procedures compared to CM-IDLE with MICO).