Upon receiving the initial registration request from the served user, the S-CSCF shall authenticate the served user and upon receiving a subsequent registration request containing valid authentication credentials, request the HSS to send the relevant service profile(s) for the served user's subscription. More than one service profile may be sent, depending on configuration options for identifying implicitly registered public user identities. For further detailed information on registration, profile download and authentication procedures see TS 24.229, TS 33.203, and TS 33.328. The registration request can contain a list of ICSI values and a list of IARI values supported by the UE. The initial filter criteria (subset of the profile) is stored locally at the S-CSCF, as specified in TS 24.229. The S-CSCF shall verify if the triggers match, from the highest to the lowest priority (see subclause 5.2). After a successfully authenticated registration, the S-CSCF shall download from the HSS all the implicitly registered public user identities associated with the registered public user identity. The S-CSCF shall then verify, in their order of priority, if the triggers downloaded from the HSS match. For each service profile in the implicit registration set, if the registration request from the served user matches a trigger, the S-CSCF performs a third party registration to the application servers which are interested to be informed about the user registration event of these public user identities. This may trigger services to be executed by an Application Server. The important information carried in the third party REGISTER request is the public user identity of the served user, the S-CSCF address and the expiration time. It shall be possible based on operator configuration to use one of the implicitly registered public user identities as the public user identity in the To header of the third party REGISTER request sent to the Application Server. Additional application server specific data, which is associated with the Filter Criteria and obtained from the HSS, is added to the REGISTER request body. This data should include the IMSI for an Application Server that supports CAMEL services or the private user identity for other Application Servers as received from the HSS. If indicated by the Filter Criteria the incoming REGISTER request is added to the REGISTER request body. If indicated by the Filter Criteria the final response to the incoming REGISTER request is added to the REGISTER request body. This third party registration will include an expiration time that is equal to the expiration time sent to the UE by the S-CSCF in the 200 (OK) response to the incoming REGISTER request On receiving a failure response to one of the REGISTER requests, the S-CSCF shall apply the "default handling" related with the initial Filter Criteria's trigger used (see subclauses 5.2.2, 6.9.2.2). See Figure 6.3.1:

Application Servers can in addition subscribe to the S-CSCF reg event package. This provides a mechanism for the Application Server to discover all the implicitly registered public user identities without requiring multiple Register requests to be sent to the Application Server and to obtain the current capabilities of the UE as well as be notified about refresh registrations and de-registrations. The S-CSCF will send NOTIFY requests to the Application Server that has subscribed to the reg event package for the registered public user identity. The reg event package also provides a mechanism for the Application Server to obtain the associated parameters (e.g GRUUs, ICSIs and IARIs) for each contact of every registered public identity. More information on these procedures is contained in TS 24.229.

The S-CSCF supports subscription to and notification of the reg event package by the UE, P-CSCFs and Application Servers. The subscribing entity may subscribe to the registration state of individual public user identities for the purpose of discovering the implicitly registered public user identities and associated parameters (e.g. GRUUs, ICSIs, IARIs) for each registered contact. When notifying a subscribing entity of a change in the registration state of a subscribed to public user identity the S-CSCF shall include in the notification all the implicitly registered public user identities associated with the registered public user identity in addition to the registered public user identity along with the associated parameters of every contact of each registered public user identity.

In registration processing, a S-CSCF may send a third party REGISTER to an application server, where the ICID, IOI and charging function addresses are included in the message. During a session, the S-CSCF shall generate the CDR for charging purposes. In a session originating case, when receiving an incoming initial request, this request will carry the ICID generated by the upstream P-CSCF, which is serving the originating user; the S-CSCF shall store the ICID for this session and handle this request based on filter criteria. After processing this request the S-CSCF shall include the ICID and the charging function addresses received from the HSS in the outgoing message. The charging function addresses identify on-line, and off-line charging entities in the home network. It is implementation dependent how IMS related entities such as P-CSCF in the visited network get the local CCF or AAA addresses in the case that the P-CSCF is located in the visited network. Charging function addresses may be allocated as locally preconfigured addresses. If this message is sent outside the home network, S-CSCF shall include Inter Operator Identifier (IOI) that identifies the home network into the message. IOI is globally unique identifier for using inter operator accounting purposes. The response to the outgoing message may contain a separate IOI that identifies the home network of the called party. The S-CSCF shall retain either IOI in the message when contacting the Application Servers. The S-CSCF will receive access network (IP-CAN) charging information from subsequent requests and responses, the S-CSCF shall store these parameters and shall remove them from the outgoing message if this message is sent to the terminating UE's home network or the originating UE's visited network. The access network (IP-CAN) charging information may be sent to application servers. In a session terminating case, when receiving an incoming initial request, this request will carry the ICID generated by the originating UE's P-CSCF; the S-CSCF shall store the ICID for this session and handle this request based on filter criteria. After processing this request the S-CSCF shall include the ICID and the charging function addresses received from the HSS in the outgoing message. The charging function addresses identify on-line and off-line charging entities in the home network. IOI may be received from another network or is inserted by the MGCF to identify the originating PSTN/PLMN. If IOI is received at the S-CSCF, the S-CSCF shall store the IOI value for the network that sent the request. The response to the incoming message may contain a separate IOI that identifies the home network of the S-CSCF. The S-CSCF shall retain either IOI in the message when contacting the Application Servers. Afterwards, the S-CSCF shall remove the IOI of the requesting network from the message before sending the message further within the network. The S-CSCF will receive access network (IP-CAN) charging information from subsequent requests and responses, the S-CSCF shall store these parameters and removes them from the outgoing message if this message is sent to the terminating UE's visited network or the originating UE's home network. The access network (IP-CAN) charging information may be sent to application servers. For detailed information on transporting charging parameters between IMS entities using SIP, see TS 24.229.

During a session, the Transit Function shall generate a CDR for charging purposes. Charging function addresses are configured in the Transit Function. Incoming initial SIP requests or a stand-alone SIP requests will carry an ICID generated by an upstream functional entity and an Inter Operator Identifier (IOI) identifying the network sending the request (the home network serving a user or a visited network where the user is connected). The Transit Function shall store the ICID and the IOI for this session. Incoming SIP requests within an existing dialog will carry the ICID received in the initial SIP request and an IOI identifying the network sending the request (the home network serving a user or a visited network where a user is connected). When sending SIP requests to Application Servers the Transit Function shall:

• include the ICID received in the incoming initial SIP request or stand-alone SIP request;
• remove the IOI received in the request; and
• include an IOI value identifying the network where the Transit Function resides.

When forwarding the incoming initial request, the stand-alone request or the request received within the existing dialog to a down stream functional entity, i.e. an functional entity that is not an Application Server, the Transit Function shall include the ICID and the IOI received in the incoming request. Responses to the initial SIP request, the stand-alone SIP request or the SIP request received within the existing dialog will contain the ICID received in the incoming request and an IOI value included by an down stream entity. When sending responses to Application Servers the Transit Function shall:

• include the ICID value received in the response;
• remove the IOI value received in the response; and
• include an IOI value identifying the network where the Transit Function resides.

The Transit Function shall store any IOI received from an Application Server in requests or responses. For detailed information on transporting charging parameters between IMS entities using SIP, see TS 24.229.