Content for  TS 24.229  Word version:  19.0.0

Authentication and re-authentication is performed by the registration procedures as described in subclause 5.4.1.2.

For any registered public user identity, the S-CSCF can deregister:

• all contact addresses bound to the indicated public user identity (i.e. deregister the respective public user identity);
• some contact addresses bound to the indicated public user identity;
• a particular contact address bound to the indicated public user identity; or
• one or more registration flows and the associated contact address bound to the indicated public user identity, when the UE supports multiple registration procedure;

by sending a single NOTIFY request. Prior to initiating the network-initiated deregistration for the only currently registered public user identity and its associated set of implicitly registered public user identities and wildcarded public user identities that have been registered either with the same contact address of the UE or the same registration flow and the associated contact address (if the multiple registration mechanism is used), i.e. there are no other public user identities registered either with this contact address or with this registration flow and the associated contact address (if the multiple registration mechanism is used), and there are still active multimedia sessions belonging either to this contact address or to this registration flow and the associated contact address (if the multiple registration mechanism is used), the S-CSCF shall release only multimedia sessions belonging to this contact address or to this registration flow and the associated contact address (if the multiple registration mechanism is used) as described in the following paragraph. The multimedia sessions for the same public user identity, if registered either with another contact address or another registration flow and the associated contact address (if the multiple registration mechanism is used) remain unchanged. Prior to initiating the network-initiated deregistration while there are still active multimedia sessions that are associated with this user and contact, the S-CSCF shall release none, some or all of these multimedia sessions by applying the steps listed in subclause 5.4.5.1.2 under the following conditions:

• when the S-CSCF does not expect the UE to reregister a given public user identity and its associated set of implicitly registered public user identities that have been registered with respective contact address (i.e. S-CSCF will set the event attribute within the respective <contact> element to "rejected" for the NOTIFY request, as described below), the S-CSCF shall release all sessions that are associated with the registered contact address for the public user identities using the contact address that is being deregistered, which includes the implicitly registered public user identities.
• when the S-CSCF expects the UE to reregister a given public user identity and its associated set of implicitly registered public user identities that have been registered with respective contact address (i.e. S-CSCF will set the event attribute within the respective <contact> element to "deactivated" for the NOTIFY request, as described below), the S-CSCF shall only release sessions that currently include the user's contact address, where the session was initiated by or terminated towards the user with the contact address registered to one of the public user identities using the contact address that is being deregistered, which includes the implicitly registered public user identities.

When a network-initiated deregistration event occurs for one or more public user identities that are bound either to one or more contact addresses or registration flows and the associated contact addresses (if the multiple registration mechanism is used), the S-CSCF shall send a NOTIFY request to all subscribers that have subscribed to the respective reg event package. For each NOTIFY request, the S-CSCF shall:

1. set the Request-URI and Route header field to the saved route information during subscription;
2. set the Event header field to the "reg" value;
3. in the body of the NOTIFY request, include as many <registration> elements as many public user identities the S-CSCF is aware of the user owns;
4. set the aor attribute within each <registration> element to one public user identity:
   1. set the <uri> sub-element inside each <contact> sub-element of each <registration> element to the respective contact address provided by the UE;
   2. if the public user identity:
      1. has been deregistered (i.e. all contact addresses and all registration flows and associated contact addresses bound to the indicated public user identity are removed) then:
         • set the state attribute within the <registration> element to "terminated";
         • set the state attribute within each <contact> element belonging to this UE to "terminated"; and
         • set the event attribute within each <contact> element belonging to this UE to either "unregistered", or "deactivated" if the S-CSCF expects the UE to reregister or "rejected" if the S-CSCF does not expect the UE to reregister; or
      2. has been kept registered then:
         1. set the state attribute within the <registration> element to "active";
         2. set the state attribute within each <contact> element to:
            • for the binding between the public user identity and either the contact address or a registration flow and associated contact addresses (if the multiple registration mechanism is used) to be removed set the state attribute within the <contact> element to "terminated", and event attribute element to either "unregistered", or "deactivated" if the S-CSCF expects the UE to reregister or "rejected" if the S-CSCF does not expect the UE to reregister; or
            • for the binding between the public user identity and either the contact address or the registration flow and associated contact addresses (if the multiple registration mechanism is used) which remain unchanged, if any, leave the <contact> element unmodified, and if the contact has been assigned GRUUs and the Contact URI did not contain a "bnc" SIP URI parameter then set the <pub-gruu> and <temp-gruu> sub-elements of the <contact> element as specified in RFC 5628 and include the <unknown-param> sub-element within each <contact> to any additional header field parameters contained in the Contact header field of the REGISTER request according to RFC 3680; and
5. add a P-Charging-Vector header field with the "icid-value" header field parameter set to the value populated in the initial request for the dialog and a type 1 "orig-ioi" header field parameter. The S-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The S-CSCF shall not include the type 1 "term-ioi" header field parameter.

The S-CSCF shall only include the non-barred public user identities in the NOTIFY request. When sending a final NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" (i.e. all public user identities have been deregistered or expired), the S-CSCF shall also terminate the subscription to the registration event package by setting the Subscription-State header field to the value of "terminated". Also, for all service profiles in the implicit registration set the S-CSCF shall send a third-party REGISTER request, as described in subclause 5.4.1.7, to each AS that matches the Filter Criteria of the service profile from the HSS as if a equivalent REGISTER request had been received from the user deregistering that public user identity, or combination of public user identities. On completion of the above procedures for one or more public user identities linked to the same private user identity, the S-CSCF shall consider those public user identities and the associated implicitly registered public user identities which have no contact address or a registration flow and associated contact addresses (if the multiple registration mechanism is used) bound to them as deregistered. On completion of the S-CSCF Registration/deregistration notification procedure with the HSS, as described in TS 29.228, the S-CSCF shall:

1. update or remove those public user identities linked to the same private user identity, their registration state and the associated service profiles from the local data (based on operators' policy the S-CSCF can request of the HSS to either be kept or cleared as the S-CSCF allocated to this subscriber); and
2. if all the contacts bound to the public user identities have been deregistered and there is no ongoing session due to the public user identities, then remove all the stored AS IP addresses which are associated with those public user identities.

On the completion of the network-initiated de-registration by the HSS procedure, as described in TS 29.228, the S-CSCF shall remove:

1. those public user identities, their registration state and the associated service profiles from the local data; and
2. if all the contacts bound to the public user identities have been deregistered and there is no ongoing session due to the public user identities, then remove all the stored AS IP addresses which are associated with those public user identities.

The S-CSCF may request a subscriber to re-authenticate at any time, based on a number of possible operator settable triggers. If the S-CSCF is informed that a private user identity needs to be re-authenticated, the S-CSCF shall generate a NOTIFY request on all dialogs which have been established due to subscription to the reg event package of that user. For each NOTIFY request the S-CSCF shall:

1. set the Request-URI and Route header field to the saved route information during subscription;
2. set the Event header field to the "reg" value;
3. in the body of the NOTIFY request, include as many <registration> elements as many public user identities the S-CSCF is aware of the user owns:
   1. set the <uri> sub-element inside the <contact> sub-element of each <registration> element to the contact address provided by the UE;
   2. set the aor attribute within each <registration> element to one public user identity;
   3. set the state attribute within each <registration> element to "active";
   4. set the state attribute within each <contact> element to "active";
   5. set the event attribute within each <contact> element that was registered by this UE to "shortened";
   6. set the expiry attribute within each <contact> element that was registered by this UE to an operator defined value; and
   7. if the Contact URI did not contain a "bnc" SIP URI parameter then set the <pub-gruu> and <temp-gruu> sub-elements within each <contact> element as specified in subclause 5.4.2.1.2; and
4. set a P-Charging-Vector header field with the "icid-value" header field parameter set to the value populated in the initial request for the dialog and a type 1 "orig-ioi" header field parameter. The S-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The S-CSCF shall not include the type 1 "term-ioi" header field parameter.

Afterwards the S-CSCF shall wait for the user to re-authenticate (see subclause 5.4.1.2). The S-CSCF shall only include the non-barred public user identities in the NOTIFY request. When generating the NOTIFY request, the S-CSCF shall shorten the validity of all registration lifetimes associated with this private user identity to an operator defined value that will allow the user to be re-authenticated.

During registration, the S-CSCF shall include the P-Access-Network-Info header fields (as received in the REGISTER request from the UE and the P-CSCF) and a P-Visited-Network-ID header field (as received in the REGISTER request from the UE) in the third-party REGISTER request sent towards the ASs, if the AS is part of the trust domain. If the AS is not part of the trust domain, the S-CSCF shall not include any P-Access-Network-Info header field or P-Visited-Network-ID header field. The S-CSCF shall not include a P-Access-Network-Info header field in any responses to the REGISTER request. If the registration procedure described in subclauses 5.4.1.2, 5.4.1.4 or 5.4.1.5 (as appropriate) was successful, the S-CSCF shall send a third-party REGISTER request to each AS with the following information: For third-party REGISTER upon user-initiated reregistration, user-initiated deregistration or network-initiated deregistration, the S-CSCF shall send SIP REGISTER request towards the IP address associated with the corresponding registered public user identity stored as described in subclause 5.4.0. When the S-CSCF receives any response to a third-party REGISTER request, the S-CSCF shall store the value of the "term-ioi" header field parameter received in the P-Charging-Vector header field, if present. If the S-CSCF fails to receive a SIP response or receives a 408 (Request Timeout) response or a 5xx response to a third-party REGISTER, the S-CSCF shall:

• if the default handling defined in the filter criteria indicates the value "SESSION_CONTINUED" as specified in TS 29.228 or no default handling is indicated, no further action is needed; and
• if the default handling defined in the filter criteria indicates the value "SESSION_TERMINATED" as specified in TS 29.228, initiate the network-initiated deregistration as described in subclause 5.4.1.5 for the currently registered public user identity and its associated set of implicitly registered non-barred public user identities bound to the contact(s) registered in the REGISTER request causing the third-party REGISTER request.

If there is a service information XML element provided in the HSS Filter Criteria for an AS (see TS 29.228), then in the third-party REGISTER request the S-CSCF shall:

• include in the message body the service information within the <service-info> XML which is a child XML element of an <ims-3gpp> element with the "version" attribute set to "1" element as described in subclause 7.6; and
• set the value of the content type to the MIME type specified in subclause 7.6.

If there is an Include Register Request XML element provided in the HSS Filter Criteria for an AS (see TS 29.228), then in the third-party REGISTER request the S-CSCF shall:

• include in the message body the incoming SIP REGISTER request within a "message/sip" MIME body as defined in RFC 3261; and
• set the value of the content type to "message/sip".

If there is an Include Register Response XML element provided in the HSS Filter Criteria for an AS (see TS 29.228), then in the third-party REGISTER request, the S-CSCF shall:

• include in the message body the 200 (OK) response to the incoming SIP REGISTER request within a "message/sip" MIME body as defined in RFC 3261; and
• set the value of the content type to "message/sip".

If there is more than one message body to be included in the third-party REGISTER request then in the third-party REGISTER request the S-CSCF shall:

• include a multipart message body and set the value of the Content-Type header field to "multipart/mixed" as specified in RFC 2046 and RFC 5621; and
• set the Content-Type of the elements of the MIME body to the content type specified for the body.

If there is only one message body to be included in the third-party REGISTER request then the S-CSCF sets the Content-Type header field to the content type specified for the body.

When receiving a Push-Profile-Request (PPR) from the HSS (as described in TS 29.228), modifying the service profile of served public user identities, the S-CSCF shall:

1. if the modification consists in the addition of a new non-barred public user identity to an implicit set, or in the change of status from barred to non-barred for a public user identity already in the implicit set, add the public user identity to the list of registered, non-barred public user identities;
2. if the modification consists in the deletion of a public user identity while there are no active multimedia session belonging to this public user identity, or in the change of status from non-barred to barred of a public user identity in an implicit set, remove the public user identity from the list of registered, non-barred public user identities;
3. if the modification consists of deletion of a public user identity from an implicit registration set while there are active multimedia session belonging to this public user identity and contact, release these multimedia sessions as described in subclause 5.4.5.1.2 and after all multimedia sessions are released, remove the public user identity from the list of registered, non-barred public user identities; and
4. synchronize with the UE and IM CN entities, by either:
   • performing the procedures for notification of the reg-event subscribers about registration state, as described in subclause 5.4.2.1.2; or
   • triggering the UE to reregister, by:
     1. depending on operator configuration, rejecting a request from the UE using a 504 (Server Time-out) response and indicating in the response that S-CSCF restoration procedures are supported, in accordance with subclause 5.4.3.2; or
     2. shortening the life time of the current registration, as described in subclause 5.4.1.6, e.g. when a new trigger point of Register method is added in the iFCs.