Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.554  Word version:  19.3.0

Top   Top   Up   Prev   Next
1…   4…   5…   5.3…   5.5…   6…   7…   8…   8.2…   8.2.7…   8.2.11   8.3…   8.3.5…   8.4…   8.4.3   8.5…   8.6…   8.7…   8.7.2…   8.7.3…   8.7.4…   8.7.5…   8.7.6…   8.8…   8.9…   8.10…   8.11…   9…   9.2…   10…   11…

 

8.9  Usage of Network Capabilitiesp. 117

8.9.1  Generalp. 117

The present clause specifies the functionality leveraged by the MSGin5G Service via Core Network exposure.

8.9.2  UE reachability status monitoringp. 117

8.9.2.1  Generalp. 117

UE reachability status leverages the 3GPP network monitoring functionality exposed via T8/N33 reference point detailed in TS 23.502 and TS 29.522. The MSGin5G Server may use the UE reachability status monitoring by using the 3GPP Network capabilities based on the information, i.e. whether UE reachability status monitoring is needed to be used for this message, received from the Application Server, i.e. based on Information Elements specified in clause 9.1.2.1 or based on the information received from the MSGin5G Client, i.e. based on Information Elements specified in clause 8.11.4. How (e.g., via request/response or subscription) to monitor the UE reachability using the 3GPP Network capabilities is implementation dependent.
Up

8.9.2.2  Proceduresp. 118

8.9.2.2.1  Request-responsep. 118
Figure 8.9.2.2.1-1 shows the procedure which may be used by the MSGin5G Server to make a request for UE reachability status information.
Pre-conditions:
  1. A UE hosts an MSGin5G Client.
  2. The MSGin5G Client has registered with the MSGin5G Server and has shared UE contact information.
  3. The MSGin5G Server has determined to subscribe for monitoring of UE reachability events in the Core Network, e.g., that the UE is a sleepy node.
Copy of original 3GPP image for 3GPP TS 23.554, Fig. 8.9.2.2.1-1: MSGin5G reachability status request-response.
Up
Step 1.
The MSGin5G Server sends a one-time Monitoring Request to the 3GPP Network using SCEF/NEF capabilities.
The one-time Monitoring Request includes monitoring type set to UE_REACHABILITY, Maximum Number of Reports of 1 and does not include the Monitoring Duration IE.
Step 2.
The 3GPP network processes the monitoring request and determines the reachability status of the UE(s), as described in TS 29.122.
Step 3.
If the Monitoring Request is successfully processed, a monitoring response providing the UE(s) reachability status is sent to the MSGin5G Server. The response may include idle mode information e.g., active time granted to the UE, eDRX cycle length, periodic RAU/TAU timer., depending on the parameters indicated in the request.
Up
8.9.2.2.2  Subscribep. 119
Figure 8.9.2.2.2-1 shows the procedure which may be used by the MSGin5G Server to subscribe for monitoring of UE reachability.
Pre-conditions:
  1. A UE hosts an MSGin5G Client.
  2. The MSGin5G Client has registered with the MSGin5G Server and has shared UE contact information.
  3. The MSGin5G Server subscribes for monitoring of UE reachability events in the Core Network, e.g., that the UE is a sleepy node, based on the information, i.e. whether UE reachability status monitoring is needed to be used for this message, received from the Application Server or MSGin5G Client.
Copy of original 3GPP image for 3GPP TS 23.554, Fig. 8.9.2.2.2-1: MSGin5G reachability status subscribe.
Up
Step 1.
The MSGin5G Server sends a Monitoring Event Subscribe request to the 3GPP Network using existing SCEF/NEF capabilities.
The Monitoring Event Subscribe is a Monitoring Request with monitoring type set to UE_REACHABILITY, and either the Maximum Number of Reports greater than 1 or the Monitoring Duration IE are included.
Step 3.
The 3GPP network processes the Monitoring Event Subscribe request as described in TS 29.122.
Step 4.
If the Monitoring Event Subscribe Request is successfully processed, a response indicating the request was accepted is sent to the MSGin5G Server.
Up
8.9.2.2.3  Notifyp. 119
Figure 8.9.2.2.3-1 shows the procedure which may be for updating MSGin5G reachability status.
Pre-conditions:
  1. The MSGin5G Server has subscribed for reachability status monitoring for a UE or group of UEs.
  2. The monitored UE(s) has transitioned to Connected Mode, Idle Mode or eDRX paging occasion and the 3GPP Network Entities has detected the change in UE reachability status.
Copy of original 3GPP image for 3GPP TS 23.554, Fig. 8.9.2.2.3-1: MSGin5G reachability status notify.
Up
Step 1.
Based on the reachability status change of a monitored UE(s), the 3GPP Network sends a Monitoring Notification message for UE reachability to the MSGin5G Server as specified in TS 29.122.
The notification may include idle mode information e.g., active time granted to the UE, eDRX cycle length, periodic RAU/TAU timer, depending on the subscription.
Step 2.
After receiving a UE Reachability monitoring notification, the MSGin5G Server responds with an acknowledgement of the notification via SCEF/NEF.
Step 3.
The MSGin5G Server uses the information provided in the UE reachability monitoring event report to update its information on the UE's availability, e.g., MSGin5G Client Availability information. The MSGin5G Server may provide additional services based on reachability information, e.g., forward a stored message.
Up
8.9.2.2.4  Unsubscribep. 120
Figure 8.9.2.2.4-1 shows the procedure which may be used by the MSGin5G Server to unsubscribe from monitoring of UE reachability.
Pre-conditions:
  1. The MSGin5G Server has subscribed for reachability status monitoring for a UE or group of UEs.
  2. Later, the MSGin5G Server unsubscribes for monitoring of UE reachability events in the Core Network, based on the information received from the Application Server or MSGin5G Client.
Copy of original 3GPP image for 3GPP TS 23.554, Fig. 8.9.2.2.4-1: MSGin5G reachability status unsubscribe.
Up
Step 1.
The MSGin5G Server sends a Monitoring event unsubscribe request to the 3GPP Network using existing SCEF/NEF capabilities.
Step 2.
The 3GPP network processes the Monitoring event unsubscribe request and deletes the subscription, as described in TS 29.122.
Step 3.
If the Monitoring event unsubscribe request is successfully processed, a response indicating the subscription was deleted is sent to the MSGin5G Server via SCEF/NEF.

8.9.2.3  Flowsp. 121

The following information flows are specified for UE reachability status monitoring:
  • UE Reachability monitoring request and response;
  • UE Reachability monitoring subscribe and unsubscribe
  • UE Reachability monitoring notify
All UE reachability monitoring interactions from MSGin5G Server (acting as SCS/AS) to SCEF/NEF occur over T8/N33 reference points capabilities detailed in TS 23.502 and TS 29.522. As specified in clause 4.4.2 of TS 29.522, all UE Reachability monitoring procedures use APIs specified in clause 5.6.1.4 of TS 23.682 and clause 4.4.2.2 of TS 29.122.
Up

8.9.3  MSGin5G device triggeringp. 121

8.9.3.1  Generalp. 121

MSGin5G device triggering is the means by which an MSGin5G Server leverages the 3GPP network device triggering capabilities, exposed via T8 /N33 reference point, while attempting to deliver an MSGin5G message. For example, when an Application Server initiates an MSGin5G message request, but the target MSGin5G UE is not reachable, the MSGin5G Server may use the 3GPP network device triggering mechanism to wake up the device and then deliver the payload to the destination.

8.9.3.2  Procedurep. 122

Figure 8.9.3.2-1 shows the MSGin5G device triggering procedure.
Pre-conditions:
  1. The target UE is an MSGin5G UE.
  2. The target MSGin5G Client is registered with the MSGin5G Server.
  3. At a later time, after the registration is completed, the MSGin5G UE has become unreachable by the MSGin5G Server.
Copy of original 3GPP image for 3GPP TS 23.554, Fig. 8.9.3.2-1: MSGin5G Triggering Procedure
Figure 8.9.3.2-1: MSGin5G Triggering Procedure
(⇒ copy of original 3GPP image)
Up
Step 1.
The MSGin5G Server receives a request for sending an MSGin5G message, the request includes the IEs as detailed in clause 9.1.2.1.
Step 2.
If the MSGin5G Server determines that the recipient MSGin5G Client is not reachable, it initiates a device trigger request via the SCEF/NEF.
To determine the reachability of the target MSGin5G UE, the MSGin5G Server may use the UE reachability status monitoring procedure in clause 8.9.2. The MSGin5G Server may also use availability information provided by the MSGin5G Client at registration in the MSGin5G Client Communication Availability IE, as detailed in Table 8.2.1-1.
Step 3.
The MSGin5G Server sends a request for Device Triggering via SCEF/NEF and determines the flow as detailed in clause 8.9.3.2. The Device Triggering request uses the UE Identifier, port number(s) and associated protocol information provided by the MSGin5G Client at registration in the MSGin5G Client Triggering Information IE.
The MSGin5G Server may use MSGin5G Client Communication Availability and/or pre-configured information to determine the timing of the Device Triggering request, e.g. the trigger may be sent to ensure that the target UE is reachable prior to resuming MSGin5G communications.
Step 4.
The MSGin5G Server receives a response from SCEF/NEF indicating the success or failure status of the request, as detailed in clause 8.9.3.3.
Step 5.
The device trigger is delivered to the target via SCEF/NEF and the Core Network. The targeted MSGin5G Client or Application Client receives the device trigger request. The targeted MSGin5G Client or Application Client parses the payload of the trigger request and determines the device trigger purpose. The target UE becomes reachable, and the MSGin5G Client or Application Client becomes available for further MSGin5G communications.
Step 6.
The MSGin5G Server receives a Device Triggering delivery status report from SCEF/NEF indicating the success of the delivery, as detailed in clause 8.9.3.3.
Step 7.
The MSGin5G Server send a Device Triggering delivery status report response to SCEF/NEF to acknowledge the delivery status report, as detailed in clause 8.9.3.3.
Based on the trigger purpose derived from the payload, the targeted MSGin5G Client performs the corresponding actions (e.g. establish access network connectivity, contact the Application Server).
Up

8.9.3.3  Flowsp. 123

The following information flows are specified for MSGin5G triggering:
  1. request for device triggering;
  2. response to device triggering;
  3. device triggering delivery report; and
  4. device triggering delivery report response.
All device triggering interactions from MSGin5G Server (acting as SCS/AS) to SCEF/NEF occur over T8/N33 reference points, using capabilities detailed in TS 23.502 and TS 29.522. As specified in clause 4.4.3 of TS 29.522, all device triggering flows use APIs specified in clause 5.17.1 of TS 23.682 and clause 4.4.6 of TS 29.122.
Up

Up   Top   ToC