Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.228  Word version:  18.6.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.2.4…   4.3…   4.4…   4.13…   4.16…   5…   5.2…   5.3…   5.4…   5.4.7…   5.4.8…   5.4a…   5.5…   5.5.3…   5.6…   5.6.3…   5.7…   5.7.3…   5.7.5…   5.7.8…   5.8…   5.10…   5.11…   5.11.3…   5.11.3.3   5.11.3.4   5.11.4…   5.11.5…   5.11.5.3…   5.11.6…   5.12…   5.16…   5.16.2…   5.19…   5.20…   A…   E…   E.2.2…   G…   G.5…   H   I…   J…   K…   L…   M…   M.3…   N…   P…   Q…   Q.2.5…   R…   S…   T…   U…   U.2…   V…   W…   X…   Y…   Z…   AA…   AA.3…   AB…   AC…   AC.7…   AC.7.2…   AC.7.2.2   AC.7.2.3…   AC.7.4…   AC.9…

 

5.3  Application level de-registration proceduresp. 83

5.3.1  Mobile initiated de-registrationp. 83

When the UE wants to de-register from the IMS then the UE shall perform application level de-registration. De-registration is accomplished by a registration with an expiration time of zero seconds. De-registration follows the same path as defined in clause 5.2.2.3 "Registration Information Flow - User not registered".
Reproduction of 3GPP TS 23.228, Fig. 5.3: De-registration - user currently registered
Up
Step 1.
The UE decides to initiate de-registration. To de-register, the UE sends a new REGISTER request with an expiration value of zero seconds. The UE sends the REGISTER information flow to the proxy (Public User Identity, Private User Identity, home network domain name, UE IP address).
Step 2.
Upon receipt of the register information flow, it shall examine the "home domain name" to discover the entry point to the home network (i.e. the I-CSCF). The proxy does not use the entry point cached from prior registrations. The proxy shall send the Register information flow to the I-CSCF (P-CSCF address/name, Public User Identity, Private User Identity, P-CSCF network identifier, UE IP address). A name-address resolution mechanism is utilised in order to determine the address of the home network from the home domain name. The P-CSCF network identifier is a string that identifies at the home network, the network where the P-CSCF is located (e.g. the P-CSCF network identifier may be the domain name of the P-CSCF network).
Step 3.
The I-CSCF shall send the Cx-Query information flow to the HSS (Public User Identity, Private User Identity, P-CSCF network identifier).
Step 4.
The HSS shall determine that the Public User Identity is currently registered. The Cx-Query Resp (indication of entry point, e.g. S-CSCF) is sent from the HSS to the I-CSCF.
Step 5.
The I-CSCF, using the name of the S-CSCF, shall determine the address of the S-CSCF through a name-address resolution mechanism and then shall send the de-register information flow (P-CSCF address/name, Public User Identity, Private User Identity, UE IP address) to the S-CSCF.
Step 6.
Based on the filter criteria, the S-CSCF shall send de-registration information to the service control platform and perform whatever service control procedures are appropriate. Service control platform removes all subscription information related to this specific Public User Identity.
Step 7.
Based on operator choice the S-CSCF can send either Cx-Put (Public User Identity, Private User Identity, clear S-CSCF name) or Cx-Put (Public User Identity, Private User Identity, keep S-CSCF name), and the Public User Identity is no longer considered registered in the S-CSCF. If the user has (originating - see 5.6.5, or terminating - see 5.12) services related to unregistered state, the S-CSCF sends Cx-Put (Public User Identity, Private User Identity, keep S-CSCF name) in order to keep the S-CSCF name in the HSS for these services.
The HSS then either clears or keeps the S-CSCF name for that Public User Identity according to the Cx-Put request. If the S-CSCF name is kept, then the HSS shall be able to clear the serving S-CSCF name at any time.
Step 8.
The HSS shall send Cx-Put Resp to the S-CSCF to acknowledge the sending of Cx-Put.
Step 9.
The S-CSCF shall return the 200 OK information flow to the I-CSCF. The S-CSCF may release all registration information regarding this specific registration of the Public User Identity after sending information flow 200 OK.
Step 10.
The I-CSCF shall send information flow 200 OK to the P-CSCF.
Step 11.
The P-CSCF shall send information flow 200 OK to the UE. The P-CSCF releases all registration information regarding this specific registration of the Public User Identity after sending information flow 200 OK. If the P-CSCF has an active subscription to notifications of the status of the IMS Signalling connectivity, the P-CSCF shall cancel the subscription (see TS 23.203 and TS 23.503 for more details).
Up

5.3.2  Network initiated de-registrationp. 84

5.3.2.0  General |R6|p. 84

If an ungraceful session termination occurs (e.g. flat battery or mobile leaves coverage), when a stateful proxy server (such as the S-CSCF) is involved in a session, memory leaks and eventually server failure can occur due to hanging state machines. To ensure stable S-CSCF operation and carrier grade service, a mechanism to handle the ungraceful session termination issue is required. This mechanism should be at the SIP protocol level in order to guarantee access independence for the IM CN subsystem.
The IM CN subsystem can initiate a Network Initiated De-Registration procedures for the following reasons:
  • Network Maintenance.
    Forced re-registrations from users, e.g. in the case of data inconsistency at node failure, in the case of UICC lost, etc. Cancelling the current contexts of the user spread among the IM CN Subsystem network nodes at registration, and imposing a new IM registration solves this condition.
  • Network/traffic determined.
    The IM CN subsystem must support a mechanism to avoid duplicate registrations or inconsistent information storage. This case will occur when a user roams to a different network without de-registering the previous one. This case may occur at the change of the roaming agreement parameters between two operators, imposing new service conditions to roamers.
  • Application Layer determined.
    The service capability offered by the IM CN Subsystem to the Application Layers may have parameters specifying whether all IM CN subsystem registrations are to be removed, or only those from one or a group of terminals from the user, etc.
  • Subscription Management
    The operator must be able to restrict user access to the IM CN subsystem upon detection of contract expiration, removal of IM subscription, fraud detection, etc. In the case of changes in service profile of the user, e.g. the user subscribes to new services, it may possible that new S-CSCF capabilities, which are required from the S-CSCF, are not supported by the current S-CSCF which has been assigned to the user. In this case, it shall be possible to actively change the S-CSCF by using the network initiated de-registration by HSS procedure.
The following clauses provide scenarios showing SIP application de-registration. Note that these flows have avoided the strict use of specific SIP protocol message names. This is in an attempt to focus on the architectural aspects rather than the protocol.
Two types of network-initiated de-registration procedures are required:
  • To deal with registrations expirations.
  • To allow the network to force de-registrations following any of the approved possible causes for this to occur.
Up

5.3.2.1  Network Initiated Application (SIP) De-registration, Registration Timeoutp. 85

The following flow shows a network initiated IM CN subsystem terminal application (SIP) de-registration based on a registration timeout. A timer value is provided at initial registration and is refreshed by subsequent re-registrations. The flow assumes that the timer has expired. The locations (home or visited network) of the P-CSCF and S-CSCF are not indicated as the scenario remains the same for all cases.
Reproduction of 3GPP TS 23.228, Fig. 5.4: Network initiated application de-registration, registration timeout
Up
Step 1.
The registration timers in the P-CSCF and in the S-CSCF expire. The timers are assumed to be close enough that no external synchronisation is required. The P-CSCF updates its internal databases to remove the Public User Identity from being registered. It is assumed that any cleanup of IP-Connectivity Access Network resources will be handled by independent means. If the P-CSCF has an active subscription to notifications of the status of the IMS Signalling connectivity, the P-CSCF shall cancel the subscription (see TS 23.203 and TS 23.503 for more details).
Step 2.
Based on the filter criteria, the S-CSCF shall send de-registration information to the service control platform and perform whatever service control procedures are appropriate. Service control platform removes all subscription information related to this specific Public User Identity.
Step 3.
Based on operator choice the S-CSCF can send either Cx-Put (Public User Identity, Private User Identity, clear S-CSCF name) or Cx-Put (Public User Identity, Private User Identity, keep S-CSCF name), and the Public User Identity is no longer considered registered in the S-CSCF. If the user has (originating - see 5.6.5, or terminating - see 5.12) services related to unregistered state, the S-CSCF sends Cx-Put (Public User Identity, Private User Identity, keep S-CSCF name) in order to keep the S-CSCF name in the HSS for these services.
The HSS then either clears or keeps S-CSCF name for that Public User Identity according to Cx-Put the request. If the S-CSCF name is kept, then the HSS shall be able to clear the serving S-CSCF name at any time.
Step 4.
The HSS shall send Cx-Put Resp to the S-CSCF to acknowledge the sending of Cx-Put.
Up

5.3.2.2  Network Initiated Application (SIP) De-registration, Administrativep. 85

5.3.2.2.0  General |R6|p. 85
For different reasons (e.g. subscription termination, lost terminal, etc.) a home network administrative function may determine a need to clear a user's SIP registration. This function initiates the de-registration procedure and may reside in various elements depending on the exact reason for initiating the de-registration.
One such home network element is the HSS, which already knows the S-CSCF serving the user and that for this purpose makes use of the Cx-Deregister. Another home network element that could initiate the de-registration is the S-CSCF, in which case it makes use of the Cx-Put to inform the HSS. Other trusted/secured parties may also initiate de-registration to the S-CSCF.
The following flow shows a network initiated IM CN subsystem terminal application (SIP) de-registration based on an administrative action for example. The IP transport infrastructure is not notified. If complete packet access is to be denied, a transport layer administrative mechanism would be used. This scenario does not address the administrative mechanisms used for updating any subscriber records, EIR records, access authorization, etc. This scenario only addresses the specific action of clearing the SIP application registration that is currently in effect.
As determined by the operator, on-going sessions may be released by using network initiated session release procedures in clause 5.10.3.
Up
5.3.2.2.1  Network Initiated De-registration by HSS, administrativep. 86
Reproduction of 3GPP TS 23.228, Fig. 5.5: Network initiated application de-registration by HSS, administrative
Up
Step 1.
HSS initiates the de-registration, sending a Cx-Deregister (user identity) which may include the reason for the de-registration.
Step 2.
Based on the filter criteria, the S-CSCF shall send de-registration information to the service control platform and perform whatever service control procedures are appropriate.
Step 3.
The S-CSCF issues a de-registration towards the P-CSCF for this user and updates its internal database to remove the user from being registered. The reason for the de-registration received from the HSS shall be included if available.
Step 4.
The P-CSCF informs the UE of the de-registration and without modification forwards the reason for the de-registration, if available. Due to loss of contact with the mobile, it might be possible that the UE does not receive the information of the de-registration.
Step 5.
The P-CSCF sends a response to the S-CSCF and updates its internal database to remove the user from being registered. If the P-CSCF has an active subscription to notifications of the status of the IMS Signalling connectivity, the P-CSCF shall cancel the subscription (see TS 23.203 for more details).
Step 6.
When possible, the UE sends a response to the P-CSCF to acknowledge the de-registration. A misbehaving UE or a UE that is out of P-CSCF coverage could not answer properly to the de-registration request. The P-CSCF should perform the de-registration in any case, e.g. after the timer for this request expires.
If the UE does not perform automatic re-registration due to the de-registration the user shall be informed about the de-registration and of the reason, if available.
Step 7.
The S-CSCF returns a response to the entity that initiated the process.
Up
5.3.2.2.2  Network Initiated De-registration by Service Platformp. 87
A service platform may determine a need to clear a user's SIP registration. This function initiates the de-registration procedure and resides in a service platform.
The following flow shows a service control initiated IMS terminal application (SIP) de-registration.
Reproduction of 3GPP TS 23.228, Fig. 5.5a: Network initiated application de-registration, service platform
Up
Step 1.
The S-CSCF receives de-registration information from the service platform and invokes whatever service logic procedures are appropriate. This information may include the reason for the de-registration.
Step 2.
The S-CSCF issues a de-registration towards the P-CSCF for this user and updates its internal database to remove the user from being registered. The reason for the de-registration shall be included, if available.
Step 3.
The P-CSCF informs the UE of the de-registration, and without modification forwards the reason for the de-registration, if available. Due to loss of contact with the mobile, it might be possible that the UE does not receive the information of the de registration.
Step 4.
The P-CSCF sends a response to the S-CSCF and updates its internal database to remove the user from being registered. If the P-CSCF has an active subscription to notifications of the status of the IMS Signalling connectivity, the P-CSCF shall cancel the subscription (see TS 23.203 for more details).
Step 5.
When possible, the UE sends a response to the P-CSCF to acknowledge the de-registration. A misbehaving UE or a UE that is out of P-CSCF coverage could not answer properly to the de-registration request. The P-CSCF should perform the de-registration in any case, e.g. after the timer for this request expires.
If the UE does not perform automatic re-registration due to the de-registration the user shall be informed about the de-registration and of the reason, if available.
Step 6.
Based on operator choice the S-CSCF can send either Cx-Put (Public User Identity, Private User Identity, clear S-CSCF name) or Cx-Put (Public User Identity, Private User Identity, keep S-CSCF name). In both cases the Public User Identity is no longer considered registered in the S-CSCF. If the user has (originating - see 5.6.5, or terminating - see 5.12) services related to unregistered state, the S-CSCF may send Cx-Put (Public User Identity, Private User Identity, keep S-CSCF name) in order to keep the S-CSCF name in the HSS for these services.
The HSS then either clears or keeps S-CSCF name for that Public User Identity according to Cx-Put the request.
Step 7.
The HSS shall send Cx-Put Resp to the S-CSCF to acknowledge the sending of Cx-Put.
Up

Up   Top   ToC