8.2.4 Non-MSGin5G UE De-registration
23.5543GPPApplication architecture for MSGin5G ServiceRelease 18Stage 2TS
The Message Gateway performs de-registration with the MSGin5G Server on behalf of the Non-MSGin5G UEs, in order to terminate services from the MSGin5G Server.
NOTE: After the procedure is completed, the Message Gateway may communicate the result to the requesting Non-MSGin5G UE and the procedure is out of scope of this document.
The procedure assumes that the Message Gateway is responsible for initiating the de-registration from the MSGin5G Server on behalf of the Non-MSGin5G UE. The signaling flow for Non-MSGin5G UE de-registration is illustrated in figure 8.2.4-1.
Pre-conditions:
1. The Message Gateway successfully performed registration with the MSGin5G Server on behalf of the Non-MSGin5G UE.
Figure 8.2.4-1: Non-MSGin5G UE de-registration
1. The Message Gateway determines to de-register the Non-MSGin5G UE with the MSGin5G Server.
2. The Message Gateway sends a Non-MSGin5G UE de-registration request to the MSGin5G Server that includes the UE Service ID associated with the Non-MSGin5G UE, as shown in Table 8.2.4-1.
Table 8.2.4-1: Non-MSGin5G UE de-registration request
|
Information element |
Status |
Description |
|
UE Service ID |
M |
UE service identifier assigned to the Non-MSGin5G UE. |
3. Upon receiving the request, the MSGin5G Server may initiate authentication procedures with the Message Gateway on behalf of the Non-MSGin5G Client. The MSGin5G Server deletes any applicable UE Service ID and associated MSGin5G Client Profile information that it has stored.
NOTE: The authentication procedures in step 3 are built on top of the transport layer mechanism specified in Annex Y.2 of 3GPP TS 33.501 [16].
4. The MSGin5G Server replies with a Non-MSGin5G UE de-registration response as shown in table 8.2.4-2.
Table 8.2.4-2: Non-MSGin5G UE De-registration response
|
Information element |
Status |
Description |
|
UE Service ID |
M |
UE service identifier assigned to the Non-MSGin5G UE. |
|
De-registration result |
M |
Indication if the de-registration is success or failure |
|
Failure Cause |
O |
The reason for failure |
8.2.5 Application Server Registration
The signalling flow for Application Server registration is illustrated in figure 8.2.5-1. Application Server may use the procedure in this clause to do registration. The procedure assumes that the Application Server is responsible for triggering registration to the MSGin5G Server in order to establish association with the MSGin5G Server to receive MSGin5G Service.
NOTE: The procedure in this clause is optional for Application Server.
Pre-conditions:
1. The Application Server has connected to the serving network successfully.
2. An AS Service ID has been provisioned.
3. The MSGin5G Server address has been provisioned on the Application Server.
4. Both the Application Server and MSGin5G Server have been configured with the necessary credentials to enable authenticating one another.
Figure 8.2.5-1: Application Server registration
1. The Application Server sends an Application Server registration request to the MSGin5G Server. The request includes security credentials required for the Application Server to register to the MSGin5G Server. The request includes the AS Service ID and Application Server Profile information as detailed in Table 9.1.2.3-1.
2. Upon receiving the request, the MSGin5G Server validates the Application Server registration request and verifies the security credentials.
NOTE: The authentication procedures in step 2 are built on top of the transport layer mechanism specified in Annex Y.4 of 3GPP TS 33.501 [16].
3. The MSGin5G Server sends an Application Server registration response to the Application Server, the response includes the information elements as specified in Table 9.1.2.4-1. If the registration is successful, the MSGin5G Server stores the AS Profile information as detailed in Table 9.1.2.3-1.
8.2.6 Application Server De-registration
By de-registering, the Application Server informs the MSGin5G Server that it wishes to terminate its association with the MSGin5G Server.
The procedure assumes that the Application Server is responsible for triggering the de-registration from the MSGin5G Server. The signalling flow for Application Server de-registration is illustrated in figure 8.2.6-1.
Pre-conditions:
1. The Application Server is registered to the MSGin5G Server.
Figure 8.2.6-1: Application Server de-registration
1. The Application Server determines to de-register from the MSGin5G Server.
2. The Application Server sends an Application Server de-registration request to the MSGin5G Server that includes the AS Service ID, as detailed in Table 9.1.2.5-1.
3. The MSGin5G Server validates the Application Server de-registration request and verifies the security credentials. The MSGin5G Server deletes any applicable AS Profile information that it has stored.
NOTE: The authentication procedures in step 3 are built on top of the transport layer mechanism specified in Annex Y.4 of 3GPP TS 33.501 [16].
4. The MSGin5G Server replies with an Application Server de-registration response as detailed in Table 9.1.2.6-1.