8.8 Other MSGin5G messaging related procedures
23.5543GPPApplication architecture for MSGin5G ServiceRelease 18Stage 2TS
8.8.1 Messaging Topic Subscription
An MSGin5G Client or an Application Server can subscribe one or more Messaging Topic(s) on the MSGin5G Server. The Messaging Topic IE will be populated by the Application Client or the Application Server and the content of this IE is out of scope.
When an MSGin5G Client or an Application Server is subscribed to a Messaging Topic, then the MSGin5G Server will deliver messages that contains the same Messaging Topic to the subscribers.
Figure 8.8.1-1 shows the MSGin5G Client/Application Server subscribing to Messaging Topic(s) on the MSGin5G Server.
Pre-conditions:
1. The MSGin5G Client or Application Server has registered to the MSGin5G Server.
Figure 8.8.1-1: MSGin5G Service endpoint subscribes to Messaging topic(s)
1. The MSGin5G Client or Application Server sends a Messaging Topic subscription request to the MSGin5G Server. The request includes the information elements listed in Table 8.8.1-1.
Table 8.8.1-1: Messaging Topic subscription request
|
Information element |
Status |
Description |
|
Originating UE Service ID/AS Service ID |
M |
The service identity of the sending MSGin5G Client or the sending Application Server. |
|
Messaging Topic |
M |
A list of Messaging Topic(s) that is to be subscribed. The number of Messaging Topic(s) included in this IE can be one or more. |
|
Expiration |
O |
The date and time when the subscription expires. This date and time apply to all Messaging Topic(s) subscribed in this request. If this IE is included, the value of it should be larger than 0. If this IE is not included, the expiration time is subject to operator policy. |
|
NOTE: The content of the Messaging Topic is out of scope of the present document. |
||
2. The MSGin5G Server validates the Messaging Topic subscription request and checks the local stored Messaging Topic(s).
a) If the subscribed Messaging Topic has already been created, the MSGin5G Server checks whether the UE Service ID/AS Service ID of the subscriber is already included in the subscribers list of this Messaging Topic.
1. If not, the MSGin5G Server adds the UE Service ID/AS Service ID of the subscriber to the subscribers list of this Messaging Topic. The MSGin5G Server sets the validity time of this subscription to the value of the Expire IE or to a default value according to the service policy.
2. Else, the MSGin5G Server updates the validity time of this subscription.
b) If the subscribed Messaging Topic has not been already created, the MSGin5G Server creates this Messaging Topic, and adds the UE Service ID/AS Service ID of the subscriber to the subscribers list of this Messaging Topic. The MSGin5G Server sets the validity time of this subscription to the value of the Expire IE or to a default value according to the service policy.
3. The MSGin5G Server sends a Messaging Topic Subscription response to the originator of the request. The response includes the information listed in Table 8.8.1-2.
Table 8.8.1-2: Messaging Topic Subscription response
|
Information element |
Status |
Description |
|
Subscription status |
M |
Indicates whether the subscription was successfully added or deleted on the MSGin5G Server. |
|
Expiration |
O |
The validity date and time of this subscription set by the MSGin5G Server. |
8.8.2 Message delivery based on Messaging Topic
If an MSGin5G Client or an Application Server is in the subscribers list of a Messaging Topic, the MSGin5G Server delivers messages that contain this Messaging Topic to it.
Figure 8.8.2-1 shows the Message delivery to a subscribing service endpoint based on Messaging Topic.
Pre-conditions:
1. The MSGin5G Client or Application Server subscribed to a Messaging Topic with the MSGin5G Server. A Messaging Topic with the UE Service ID/AS Service ID of the subscriber has been created.
Figure 8.8.2-1: Message delivery to subscribing service endpoint based on Messaging Topic
1. The MSGin5G Server receives an MSGin5G message request or an API message request corresponding to step 2 in figures 8.3.2-1 or 8.3.2-2 which includes the IEs as listed in table 8.3.2-1. The MSGin5G message request or API message request contains a Messaging Topic IE corresponding to the Messaging Topic for which subscription(s) exist.
2. The MSGin5G Server uses the procedure described in clause 8.3.3 to deliver the message to all subscriber(s) of this Messaging Topic. In each outbound message, the UE Service ID/AS Service ID of subscriber should be added as the Recipient UE Service ID/AS Service ID IE specified in table 8.3.3-1.
8.8.3 Messaging Topic Unsubscription
Corresponding to message topic subscription, an MSGin5G Client or an Application Server can unsubscribe from one or more Messaging Topic(s) on the MSGin5G Server.
Figure 8.8.3-1 shows the MSGin5G Client/Application Server unsubscribing to Messaging Topic(s) on the MSGin5G Server.
Pre-conditions:
1. The MSGin5G Client or Application Server has subscribed one or more message topic(s) on the MSGin5G Server.
Figure 8.8.3-1: MSGin5G Service endpoint unsubscribes to Messaging topic(s)
1. The MSGin5G Client or Application Server sends a Messaging Topic unsubscription request to the MSGin5G Server. The request includes the information listed in Table 8.8.3-1.
Table 8.8.3-1: Messaging Topic unsubscription request
|
Information element |
Status |
Description |
|
Originating UE Service ID/AS Service ID |
M |
The service identity of the sending MSGin5G Client or the sending Application Server. |
|
Messaging Topic(s) |
M |
A list of Messaging Topic(s) that is to be subscribed. The number of Messaging Topic(s) included in this IE can be one or more. |
2. The MSGin5G Server validates the Messaging Topic unsubscription request and checks the local stored Messaging Topic(s). If the subscribed Messaging Topic has already been created and if the UE Service ID/AS Service ID of the subscriber is already included in the subscribers list of this Messaging Topic, the MSGin5G Server removes the UE Service ID/AS Service ID from the subscribers list of this Messaging Topic.
3. The MSGin5G Server sends a Messaging Topic Unsubscription response to the originator of the request. The response includes the information listed in Table 8.8.3-2.
Table 8.8.3-2: Messaging Topic Unsubscription response
|
Information element |
Status |
Description |
|
subscription status |
M |
Indicates whether the subscription was successfully deleted on the MSGin5G Server |
8.8.4 Messaging Topic handling between different MSGin5G Servers
8.8.4.1 General
When Messaging Topic(s) is handled between different MSGin5G Servers, the MSGin5G Server 1 may work in the following models:
a. Mod.A: the MSGin5G UE/Application Server served by MSGin5G Server 1 subscribes Messaging Topic(s) on MSGin5G Server 2 directly. In this case, the MSGin5G Server 1 forwards Messaging Topic subscription request from the MSGin5G UE/Application Server served by it to MSGin5G Server 2 or
b. Mod.B: the MSGin5G Server 1 subscribes the Messaging Topic(s) on behalf of all MSGin5G UE/Application Server served by it.
The MSGin5G Server may work in one model based on the service policy. The MSGin5G Server 1 and MSGin5G Server 2 can be located in the same PLMN or different PLMNs.
8.8.4.2 Messaging Topic list subscription
Before the subscribing of Messaging Topic(s), the MSGin5G Server 1 should obtain the available Messaging Topic list on the MSGin5G Server 2 to determine whether forwards the Messaging Topic subscription request to MSGin5G 2, or subscribes Messaging Topic on behalf of all MSGin5G UE/Application Server served by it on MSGin5G Server 2.
Figure 8.8.4.2-1 shows the MSGin5G Server 1 subscribing to Messaging Topic list on the MSGin5G Server 2.
NOTE 1: If the MSGin5G Server 1 and MSGin5G Server 2 are located in the same PLMN, the synchronization of Messaging Topic list between MSGin5G Servers may also be
implementation specific.
Pre-conditions:
1. MSGin5G Server 1 and MSGin5G Server 2 have established a secured connection.
Editor’s Note: How a secure connection between two MSGin5G Servers is to be established is FFS.
Figure 8.8.4.2-1: MSGin5G Server 1 subscribes to Messaging Topic list on the MSGin5G Server 2
1. The MSGin5G Server 1 sends a Messaging Topic list subscription request to the MSGin5G Server 2. The request includes the information elements listed in Table 8.8.4.2-1.
Table 8.8.4.2-1: Messaging Topic list subscription request
|
Information element |
Status |
Description |
|
MSGin5G Server address |
M |
The MSGin5G Server which subscribes the Messaging Topic list. |
|
Security credentials |
O |
Security information required by the MSGin5G Server 2. If the MSGin5G Server 1 and MSGin5G Server 2 are located in the same PLMN, this information element is not mandatory. This is a placeholder for SA3 security information. |
|
Expiration |
O |
The date and time when the subscription expires. If this IE is included, the value of it should be larger than 0. If this IE is not included, the expiration time is subject to operator policy. |
2. Upon receiving the Messaging Topic list subscription request, the MSGin5G Server 2 validates this request and verifies the security credentials.
NOTE 2: If the MSGin5G Server 1 and MSGin5G Server 2 are located in the same PLMN, the step 2 can be skipped.
3. The MSGin5G Server 2 checks the locally stored Messaging Topic list subscription(s).
a) If the MSGin5G Server 1’s subscription has already been created, the MSGin5G Server 2 updates the validity time of this subscription.
b) If the MSGin5G Server 1’s subscription has not been created, the MSGin5G Server 2 creates the subscription.
4. The MSGin5G Server 2 sends a Messaging Topic list Subscription response to MSGin5G Server 1. The response includes the information listed in Table 8.8.4.2-2.
Table 8.8.4.2-2: Messaging Topic list Subscription response
|
Information element |
Status |
Description |
|
Subscription status |
M |
Indicates whether the subscription was successfully added or deleted on the MSGin5G Server 2. |
|
Expiration |
O |
The validity date and time of this Messaging Topic list subscription set by the MSGin5G Server 2. |
5. The MSGin5G Server 2 checks whether Messaging Topic list notification is needed, e.g. whether the MSGin5G Server 1 subscribes the Messaging Topic list on MSGin5G Server 2 for the first time, or the local Messaging Topic(s) on the MSGin5G Server 2 are updated, e.g. new Messaging Topic(s) has been created or existing Messaging Topic(s) has been deleted.
NOTE 3: If the MSGin5G Server 1 has unsubscribed the Messaging Topic list on MSGin5G 2, the MSGin5G Server 2 should consider that the MSGin5G Server 1 subscribes the Messaging Topic list on MSGin5G Server 2 for the first time when the MSGin5G Server 1 subscribes the Messaging Topic list again.
6. If Messaging Topic list notification is needed, the MSGin5G Server 2 sends a Messaging Topic list notification request to MSGin5G Server 1. The request includes the information listed in Table 8.8.4.2-3.
Table 8.8.4.2-3: Messaging Topic list notification
|
Information element |
Status |
Description |
|
Expiration |
O |
The new validity date and time of this subscription set by the MSGin5G Server 2. |
|
>Messaging Topic list |
M |
A list of Messaging Topic(s) that is(are) existing on the MSGin5G Server 2. If the MSGin5G Server 1 subscribes the Messaging Topic list on MSGin5G Server 2 for the first time, the MSGin5G Server 2 should include all Messaging Topic(s) that is(are) existing on the MSGin5G Server 2 in this Messaging Topic list notification, else the MSGin5G Server 2 includes the deviation of Messaging Topic(s) since the last notification, Each element in this list contains information as specified in Table 8.8.4.2-4. Based on the service, the MSGin5G Server 2 may only choose a part of Messaging Topic(s) which are allowed to be subscribe by MSGin5G Server 1 in the notification. |
Table 8.8.4.2-4: Individual Messaging Topic
|
Information element |
Status |
Description |
|
Messaging Topic |
M |
Unique identifier of this Messaging Topic. |
|
Update status |
M |
Identifies the Messaging Topic is newly created on the MSGin5G Server 2, or newly deleted on the MSGin5G Server 2 |
7. Upon receiving the Messaging Topic list notification, the MSGin5G Server 1 updates the local stored Messaging Topic list:
a) if the Update status of a Messaging Topic is Created, the MSGin5G Server 1 adds the Messaging Topic to the locally stored Messaging Topic list; and
b) if the Update status of a Messaging Topic is Deleted,
i) if the Messaging Topic exists on MSGin5G Server 1, the MSGin5G Server 1 removes the Messaging Topic from the locally stored Messaging Topic list; and
ii) if the Messaging Topic does not exist on MSGin5G Server 1, the MSGin5G Server 1 ignores this Messaging Topic update.
NOTE 4: The MSGin5G Server should not send Messaging Topic list notification to other MSGin5G Servers if its locally stored Messaging Topic list is updated by receiving a Messaging Topic list notification.
8.8.4.3 Messaging Topic Subscription between different MSGin5G Servers
If the MSGin5G Server 1 works in Mod.A (see clause 8.8.4.1), upon receiving a Messaging Topic subscription request from MSGin5G Client or Application Server, if the Messaging Topic is included in the Messaging Topic list of MSGin5G Server 2, the MSGin5G Server 1 forwards the Messaging Topic subscription request to MSGin5G Server 2. Otherwise the MSGin5G Server 1 handles the Messaging Topic subscription request as specified in clause 8.8.1.
If the MSGin5G Server 1 works in Mod.B (see clause 8.8.4.1), upon receiving a Messaging Topic subscription request from MSGin5G Client or Application Server, if the Messaging Topic is not included in the Messaging Topic list of MSGin5G Server 2, the MSGin5G Server 1 handles the Messaging Topic subscription request as specified in clause 8.8.1. Otherwise, it may subscribe one or more Messaging Topic(s) from the Messaging Topic list by using the procedure specified in clause 8.8.1 with the clarification listed below:
1. The MSGin5G Server 1 includes the information elements listed in Table 8.8.4.3-1 instead of the information elements listed in Table 8.8.1-1.
Table 8.8.4.3-1: Messaging Topic subscription request
|
Information element |
Status |
Description |
|
Originating UE Service ID/AS Service ID (see NOTE 1) |
O |
The service identity of the sending MSGin5G Client or the sending Application Server. This IE should be included if MSGin5G Server 1 forwards Messaging Topic subscription request from the MSGin5G UE/Application Server served by it to MSGin5G Server 2. |
|
MSGin5G Server address (see NOTE 1) |
O |
The MSGin5G Server which subscribes the Messaging Topic(s). This IE should be included if MSGin5G Server 1 subscribe the Messaging Topic on behalf of all MSGin5G UE/Application Server served by it. |
|
Security credentials |
O |
Security information required by the MSGin5G Server 2. If the MSGin5G Server 1 and MSGin5G Server 2 are located in the same PLMN, this information element is not mandatory. This is a placeholder for SA3 security information. |
|
Messaging Topic (see NOTE 2) |
M |
A list of Messaging Topic(s) that is to be subscribed. The number of Messaging Topic(s) included in this IE can be one or more. |
|
Expiration |
O |
The date and time when the subscription expires. This date and time apply to all Messaging Topic(s) subscribed in this request. If this IE is included, the value of it should be larger than 0. If this IE is not included, the expiration time is subject to operator policy. |
|
NOTE 1: Only one of these IEs shall be included. NOTE 2: The content of the Messaging Topic is out of scope of the present document. |
||
2. Upon receiving the Messaging Topic subscription request, the MSGin5G Server 2 validates this request.
3. The MSGin5G Server 2 handles the Originating UE Service ID/AS Service ID or MSGin5G Server address included in the Messaging Topic subscription request as the UE Service ID/AS Service ID included in Table 8.8.1-1.
8.8.4.4 Messaging Topic Unsubscription between different MSGin5G Servers
If the MSGin5G Server 1 works in Mod.A (see clause 8.8.4.1), upon receiving a Messaging Topic unsubscription request from MSGin5G Client or Application Server, if the Messaging Topic is included in the Messaging Topic list of MSGin5G Server 2, the MSGin5G Server 1 forwards the Messaging Topic unsubscription request to MSGin5G Server 2, Otherwise the MSGin5G Server 1 handles the Messaging Topic unsubscription request as specified in clause 8.8.1.
If the MSGin5G Server 1 works in Mod.B (see clause 8.8.4.1), it may also unsubscribe one or more Messaging Topic(s) from the Messaging Topic list by using the procedure specified in clause 8.8.3 with the clarification listed below:
1. The MSGin5G Server 1 includes the information elements listed in Table 8.8.4.4-1 instead of the information elements listed in Table 8.8.3-1.
Table 8.8.4.4-1: Messaging Topic unsubscription request
|
Information element |
Status |
Description |
|
Originating UE Service ID/AS Service ID (see NOTE 1) |
O |
The service identity of the sending MSGin5G Client or the sending Application Server. This IE should be included if MSGin5G Server 1 forwards Messaging Topic unsubscription request from the MSGin5G UE/Application Server served by it to MSGin5G Server 2. |
|
MSGin5G Server address (see NOTE 1) |
O |
The MSGin5G Server which unsubscribes the Messaging Topic(s). This IE should be included if MSGin5G Server 1 subscribe the Messaging Topic on behalf of all MSGin5G UE/Application Server served by it. |
|
Security credentials |
O |
Security information required by the MSGin5G Server 2. If the MSGin5G Server 1 and MSGin5G Server 2 are located in the same PLMN, this information element is not mandatory. This is a placeholder for SA3 security information. |
|
Messaging Topic |
M |
A list of Messaging Topic(s) that is to be unsubscribed. The number of Messaging Topic(s) included in this IE can be one or more. |
|
NOTE 1: Only one of these IEs shall be included. |
||
2. Upon receiving the Messaging Topic unsubscription request, the MSGin5G Server 2 validates this request.
3. The MSGin5G Server 2 handles the Originating UE Service ID/AS Service ID or MSGin5G Server address included in the Messaging Topic unsubscription request as the UE Service ID/AS Service ID included in Table 8.8.3-1.
8.9 Usage of Network Capabilities
8.9.1 General
The present clause specifies the functionality leveraged by the MSGin5G Service via Core Network exposure.
8.9.2 UE reachability status monitoring
8.9.2.1 General
UE reachability status leverages the 3GPP network monitoring functionality exposed via T8/N33 reference point detailed in 3GPP TS 23.502 [7] and TS 29.522[10]. How the MSGin5G Server determines whether and how (e.g., via request/response or subscription) to monitor the UE reachability using the 3GPP Network capabilities is implementation dependent.
NOTE 1: Use of the UE reachability status monitoring procedure in the application layer has no impact to how the Core Network delivers the message to the UE.
NOTE 2: MSGin5G Service provider policies may indicate whether the UE reachability status monitoring feature is enabled or not.
8.9.2.2 Procedures
8.9.2.2.1 Request-response
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 registers with the MSGin5G Server and shares UE contact information.
3. The MSGin5G Server determines to subscribe for monitoring of UE reachability events in the Core Network, e.g., that the UE is a sleepy node.
NOTE: How the MSGin5G Server determines to subscribe for monitoring of UE reachability events in the Core Network is implementation dependent.
Figure 8.9.2.2.1-1: MSGin5G reachability status request-response.
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.
2. The 3GPP network processes the monitoring request and determines the reachability status of the UE(s), as described in 3GPP TS 29.122 [9].
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, etc., depending on the parameters indicated in the request.
8.9.2.2.2 Subscribe
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 registers with the MSGin5G Server and shares UE contact information.
3. The MSGin5G Server determines to subscribe for monitoring of UE reachability events in the Core Network, e.g., that the UE is a sleepy node.
NOTE: How the MSGin5G Server determines to subscribe for monitoring of UE reachability events in the Core Network is implementation dependent.
Figure 8.9.2.2.2-1: MSGin5G reachability status subscribe.
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.
3. The 3GPP network processes the Monitoring Event Subscribe request as described in 3GPP TS 29.122 [9].
4. If the Monitoring Event Subscribe Request is successfully processed, a response indicating the request was accepted is sent to the MSGin5G Server.
8.9.2.2.3 Notify
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) transitions to Connected Mode, Idle Mode or eDRX paging occasion and the 3GPP Network Entities detects the change in UE reachability status.
Figure 8.9.2.2.3-1: MSGin5G reachability status notify.
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 3GPP TS 29.122 [9].
The notification may include idle mode information e.g., active time granted to the UE, eDRX cycle length, periodic RAU/TAU timer, etc., depending on the subscription.
2. After receiving a UE Reachability monitoring notification, the MSGin5G Server responds with an acknowledgement of the notification via SCEF/NEF.
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, etc.
8.9.2.2.4 Unsubscribe
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 determines to unsubscribe for monitoring of UE reachability events in the Core Network,
NOTE 1: How the MSGin5G Server determines to subscribe or unsubscribe for monitoring of UE reachability events in the Core Network is implementation dependent.
NOTE 2: If the initial MSGin5G Server subscription for reachability status monitoring reaches the Maximum Number of Reports or Monitoring Duration indicated in the request, the 3GPP Network automatically deletes the subscription and an explicit MSGin5G reachability status unsubscribe is not necessary.
Figure 8.9.2.2.4-1: MSGin5G reachability status unsubscribe.
1. The MSGin5G Server sends a Monitoring event unsubscribe request to the 3GPP Network using existing SCEF/NEF capabilities.
2. The 3GPP network processes the Monitoring event unsubscribe request and deletes the subscription, as described in 3GPP TS 29.122 [9].
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 Flows
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 3GPP TS 23.502 [7] and TS 29.522[10]. As specified in TS 29.522[10] clause 4.4.2, all UE Reachability monitoring procedures use APIs specified in TS 23.682 [8] clause 5.6.1.4 and 3GPP TS 29.122 [9] clause 4.4.2.2.
8.9.3 MSGin5G device triggering
8.9.3.1 General
MSGin5G device triggering is the means by which an Application Server sends an MSGin5G message and the 3GPP network device triggering capabilities exposed via T8 /N33 reference point are leveraged. For example, when an Application Server initiates an MSGin5G message request, but the target UE is not reachable, the MSGin5G Server may use the 3GPP network device triggering mechanism to wake up the device and provide the payload to the destination.
8.9.3.2 Procedure
Figure8.9.3.2-1 shows the MSGin5G device triggering procedure.
Pre-conditions:
1. A UE hosts an MSGin5G Client and/or Application Client which are supported by the MSGin5G Service.
2. The MSGin5G Client registers with the MSGin5G Server.
3. At a later time, the UE becomes unreachable by the MSGin5G Server.
Figure 8.9.3.2-1: MSGin5G Triggering Procedure
1. The Application Server sends an API request to the MSGin5G Server for sending an MSGin5G message, the API request includes the IEs as detailed in clause 9.1.2.1.
2. If the MSGin5G Server determines that the recipient MSGin5G Client is not reachable, it initiates a device trigger request via the SCEF/NEF as a result of the step 1 request.
To determine the reachability of the target 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.
NOTE 1: How the MSGin5G Server uses the MSGin5G Client Communication Availability IE, the UE reachability status monitoring procedure, or a combination thereof to make this determination is implementation specific.
NOTE 2: If the recipient MSGin5G Client is reachable then the trigger request is not required, the MSGin5G Server sends the MSGin5G message as detailed in clause 8.3.3 and the rest of the steps in this procedure are skipped.
3. The MSGin5G Server sends a request for Device Triggering via SCEF/NEF and determines the flow as detailed in clause 8.9.3.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.
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.
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.
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.
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.
8. The MSGin5G Server responds to the request received in step 1.
Based on the trigger purpose derived from the payload, the targeted MSGin5G Client or Application Client performs the corresponding actions (e.g. establish access network connectivity, contact the Application Server etc).
8.9.3.3 Flows
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 3GPP TS 23.502 [7] and TS 29.522[10]. As specified in TS 29.522[10] clause 4.4.3, all device triggering flows use APIs specified in TS 23.682 [8] clause 5.17.1 and 3GPP TS 29.122 [9] clause 4.4.6.
8.10 Usage of SEAL
8.10.1 General
The MSGin5G Service functional entities MSGin5G Client and MSGin5G Server utilize the SEAL services. All SEAL services specified in 3GPP TS 23.434 [5] are available to MSGin5G Service. In this clause, only the details of the information flows, procedures and APIs whose utilization by MSGin5G Service are well-known are described.
8.10.2 Configuration management service
8.10.2.1 General
The MSGin5G Service functional entities MSGin5G Client and MSGin5G Server utilize configuration management service procedures of SEAL to support MSGin5G Service.
8.10.2.2 Information flows
The following information flows of Configuration Management service are applicable for the MSGin5G Service:
– Get VAL UE configuration request specified in subclause 11.3.2.1 of 3GPP TS 23.434 [5];
– Besides the IEs specified in subclause 11.3.2.1 of 3GPP TS 23.434 [5], the information in table 8.10.2.2-1 is also included in the Get VAL UE configuration request.
Table 8.10.2.2-1: Additional information in the Get VAL UE configuration request
|
Information element |
Status |
Description |
|
MSGin5G UE information |
O |
Other information needed by the configuration procedure. (NOTE) |
|
NOTE: The information can be the device type, device Vendor, etc. It is specified by application provider or MSGin5G Service provider and is out of scope of this document. The MSGin5G Service provider can configure the MSGin5G UE with different configuration data based on this IE. E.g. all sensors can be configured to a same MSGin5G Server. |
||
– Get VAL UE configuration response specified in subclause 11.3.2.2 of 3GPP TS 23.434 [5];
– Besides the IEs specified in subclause 11.3.2.2 of 3GPP TS 23.434 [5], the information in table 8.10.2.2-2 is also included in the Get VAL UE configuration response.
Table 8.10.2.2-2: Additional information in the Get VAL UE configuration response
|
Information element |
Status |
Description |
|
UE service ID |
M |
MSGin5G Service ID assigned to the requesting MSGin5G UE. |
|
MSGin5G Server address |
M |
The MSGin5G Server which serves this MSGin5G UE. |
|
MSGin5G Service specified information |
O |
The specific information of the MSGin5G Service specified by the MSGin5G Service provider. (NOTE) |
|
NOTE: E.g. the segment size of MSGin5G message in this service provider, the detailed definition is out of scope of this document. |
||
The usage of the above information flows is clarified as below:
– The VAL UE ID is the MSGin5G UE ID;
– VAL service ID is the service identifier of the MSGin5G Service; and
– VAL UE configuration data is the MSGin5G UE configuration data.
8.10.2.3 Procedures
The following procedures of configuration management service are applicable for the MSGin5G Service:
– VAL UE configuration data specified in subclause 11.3.3 of 3GPP TS 23.434 [5].
8.10.3 Group management service
8.10.3.1 General
The MSGin5G Service functional entities MSGin5G Client and MSGin5G Server utilize SEAL Client and SEAL Server for the group management service (e.g. creation, join, leave) on the group configuration information (e.g. group join policy, group leader) provided by the MSGin5G Server. The decisions and corresponding triggers (e.g. group creation, join, leave and deletion) for group management are responsibility of the application leveraging MSGin5G Service. The group management service of SEAL provides support for creating group for MSGin5G Service for applications leveraging MSGin5G Service.
8.10.3.2 Information flows
Editor’s note: The reference to information flows of group management procedures as specified in 3GPP TS 23.434 [5] are FFS.
8.10.3.3 Procedures
The following procedures of group management service of SEAL as specified in 3GPP TS 23.434 [5] are applicable for the MSGin5G Service:
– Group creation specified in clause 10.3.3;
— Subsequent to Step 3, when the identity list with the list of VAL user IDs or VAL UE IDs that are part of the created group contain the list of VAL user IDs or VAL UE IDs which does not have group management client (e.g. Legacy 3GPP UEs, Non-3GPP UEs or Application Server), it is responsibility of the VAL server (MSGin5G Server) to initiate the group creation notification towards those UEs.
– Group configuration management specified in clause 10.3.6;
– Group membership update specified in clause 10.3.5.2.
– Group deletion specified in clause 10.3.13.
Editor’s note: Whether MSGin5G Service endpoints can dynamically join and leave group is FFS.
8.10.3.4 APIs
The following APIs of group management service of SEAL as specified in 3GPP TS 23.434 [5] are applicable for the MSGin5G Service:
– SS_GroupManagement API specified in clause 10.4.2;
– SS_Group_Management_Event API specified in clause 10.4.5.