6 Communication between ICS UE and SCC AS via I1 interface

24.2943GPPIP Multimedia Subsystem (IMS) Centralized Services (ICS) protocol via I1 interfaceRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 Introduction

The ICS UE and SCC AS use the I1 interface to setup, control, maintain and release an I1 session control channel and associated media over the CS bearer.

If an ICS US capable of using the I1 interface registers with the IM CN Subsystem (IMS), it shall associated keys with public user identities in the format of a SIP URI in accordance with annex A. A public user identity can be derived if a key is associated with the public user identity.

6.2 Session control procedures

6.2.1 Session setup

6.2.1.1 General

The ICS UE setups the I1 session with CS media and the service control signalling via the I1 reference point. I1 is used to control services in the IM CN subsystem.

The I1 sessions can be created by I1 session setup messages. The I1 Invite message is an I1 session setup message. The I1 sessions can be torn down by I1 session release messages. The I1 Bye message is an I1 session release message.

The following subclauses describe the procedures of the ICS UE and the SCC AS for I1 session setup:

– subclause 6.2.1.2.1 describes the procedures of ICS UE I1 session origination;

– subclause 6.2.1.2.2 describes the procedures of ICS UE I1 session termination without UE assisted T-ADS function;

– subclause 6.2.1.2.3 describes the procedures of ICS UE I1 session termination with UE assisted T-ADS function;

– subclause 6.2.1.2.4 describes the procedures of ICS UE when the I1 session fails;

– subclause 6.2.1.3.1 describes the procedures of SCC AS I1 session origination;

– subclause 6.2.1.3.2 describes the procedures of SCC AS I1 session termination without UE assisted T-ADS function;

– subclause 6.2.1.3.3 describes the procedures of SCC AS I1session termination with UE assisted T-ADS function; and

– subclause 6.2.1.3.4 describes the procedures of SCC AS when the I1 session fails.

6.2.1.2 Detailed behaviour of ICS UE

6.2.1.2.1 ICS UE CS Session Origination

6.2.1.2.1.1 General

The following subclauses describe the procedures at the ICS UE for session origination.

6.2.1.2.1.2 Sending an I1 Invite message

When the ICS UE originates an I1 session using the protocol at the I1reference point, the UE shall:

1) generate an I1 Invite message that includes:

a) a Message Type and a Reason set to indicate the message is a Mobile Originated I1 Invite message, accordance with table 7.3.1;

b) a new value in the Call-Identifier field (Part-1), as specified in subclause 7.2.2.1.4. The Call-Identifier will uniquely identify this I1 session between the ICS UE and the SCC AS;

c) an allocated Sequence-ID;

d) a From-id information element that

– if the UE has previously SIP registered and the public user identity is to be a SIP URI and the public user identity can be derived (see annex A) then:

i) if the public identity indicates the default public user identity, the Code specific field of the From-id information element is set to "Unspecified" (see table 7.4.2.3.1-2) and the length field is set to 0;

ii) if the public identity is not the default public user identity and the public user identity indicated can be derived (see annex A), the Code specific field of the From-id information element is set to "Identifier" (see table 7.4.2.3.1-2) and the length field is set to 4.

– otherwise the Code specific field of the From-id Information information element is set to:

i) a "SIP URI" (see table 7.4.2.3.1-2) if the public user identity is a SIP URI and the Information body (see table 7.3.2.2) containing the SIP URI;

ii) an "International number" (see table 7.4.2.3.1-2), if the public user identity is a Tel URI or SIP URI with URI parameter user=phone and the Information body (see table 7.3.2.2) containing the digit string contained in the URI.

e) a To-id information element that includes either a SIP URI or an E.164 number, and will be used by the SCC AS to determine the identity of the called user;

f) a Privacy information element that indicates the ICS UE’s privacy preferences. The SCC AS will apply these preferences to the SIP session that the SCC AS will establish on behalf of the UE;

g) optionally include any feature tags in the:

i) Accept-Contact information element, as specified in subclause 7.3.2.5 if the parameter tag "explicit" or "require" as specified in RFC 3841 [14] are not required;

ii) ERAccept Contact information element, as specified in subclause 7.3.2.6 if the parameter tag "explicit" or "require" as specified in RFC 3841 [14] are required; and

iii) Reject Contact information element as specified in subclause 7.3.2.7; and

h) if using a transport layer protocol that is not a real-time transport layer protocol, a Timestamp information element that includes current local time measured in seconds. The element will be used by the SCC AS to determine the staleness of the message.

2) select the transport-layer protocol (see subclause 4.2.3) depending on the access network type, and forward the I1 Invite message toward the SCC AS.

6.2.1.2.1.3 Receipt of I1 Progress message with Reason Call Progress

When the UE receives an I1 Progress message with Reason set to 183 (Call Progress), the UE shall:

1) save the received Call-Identifier field value and use it for further reference to this session;

2) verify if the message is in sequence according to the value of the Sequence-ID, Timer(s) as specified in subclause 7.5.3.2.1 have not expired, and save the received Sequence-ID;

3) store the SCC AS PSI DN value (i.e. the E.164 number) received in the SCC-AS-id information element; and

4) store the STI value (i.e. the E.164 number) if received in the Session-identifier information element.

NOTE 1: The STI value uniquely identifies the I1 session being established, and it may be subsequently used to refer to this I1 session, e.g. the SCC AS uses the STI to correlate the access transfer request received via the PS access with the active session established via the I1 interface.

NOTE 2: The UE may indicate the Reason value to the user.

Upon receiving the SCC AS PSI DN (i.e. the E.164 number) conveyed in the I1 Progress message with Reason set to 183 (Call Progress) from the SCC AS, the ICS UE shall initiates the call over the CS domain by sending a CC SETUP message to the MSC Server as specified in 3GPP TS 24.008 [3] as follows:

1) the Called Party BCD Number information element is set to the SCC AS PSI DN (i.e. the E.164 number) received in the I1 Progress message with Reason set to 183 (Call Progress); and

2) Type Of Number is set to "International" and Numbering Plan Indicator set to "E.164".in the Called Party BCD Number information element.

6.2.1.2.1.4 Receipt of I1 Progress message with Reason set to 180

When the ICE UE received an I1 Progress message with Reason set to 180 the UE shall:

1) provide an alerting indication to the user; and

2) verify Timer(s) as specified in subclause 7.5.3.2.1 have not expired.

6.2.1.2.1.5 Receipt of I1 Success message

When the ICS UE receives an I1 Success message, the UE shall:

1) verify if a I1 session exists for the received Call-Identifier field value and Timer(s) as specified in subclause 7.5.3.2.1 have not expired;

2) verify if the message is in sequence according to the value of the Sequence-ID;

2A) verify that a CC CONNECT message as specified in 3GPP TS 24.008 [3] has been received in response to the SETUP message that was sent containing the SCC AS PSI DN; and

3) consider the I1 session to be established, if the above verification was successful.

6.2.1.2.2 ICS UE CS Session Termination without UE assisted T-ADS

If the ICS UE receives an I1 Invite message from the SCC AS, and the UE determines that no I1 session exists for the received Call-Identifier field value, the ICS UE shall:

0) if using a transport layer protocol that is not a real-time transport layer protocol, retrieve the SCC AS local time value from the Timestamp information element of the I1 Invite message, and validate the staleness of the message by applying the following equation:

SCC_AS_time_in_the_I1_Invite_message – SCC_AS_time as specified in subclause 6.4.1 item 5)

(ICS_UE_local_time – ICS_UE_time as specified in subclause 6.4.3.1 item 1)e) – Deviation

NOTE: Deviation parameter is 64*T1 seconds.

If the equation is true the message is not stale and it shall processed by the following sections. Otherwise, the messages is discarded and no response is generated to the I1 Invite message; and

1) store the information contained in the I1 Invite message, including the called party identity included in the To-id information element, the calling user’s public user identity included in the From-id information element, the SCC AS PSI DN (i.e., the E.164 number) included in the SCC-AS-id information element, the Sequence-ID, the Call-Identifier field (Part-2), the STI value (i.e. the E.164 number) if received in the Session-identifier information element, Accept-Contact information element, ERAccept-Contact information element and Reject-Contact information element and transport layer information identifying the transport connection over which the I1 Invite message was received; and

1A) if the To-id information element in the I1 Invite message contains a:

i) Code Specific Information element set to "Unspecified" (see table 7.4.2.3A.1) and a length field set to 0 then the Public user identity shall be set to the default public user identity.

ii) Code Specific Information element set to "Identifier" (see table 7.4.2.3A.1-2) and a length field set to 4, then the public user identity can be derived (see Annex A) and shall be set to the identifier value received in the information element body of the To-id information element.

iii) Code Specific Information element set to "International number" (see table 7.4.2.3A.1-2) or "SIP URI" (see table 7.4.2.3.1-2), then the public user identity of the UE shall be set to the Identity in the Information element body of the To-id information element.

NOTE 1: The UE may indicate the public user identity used to address the UE in the incoming session to the user.

2) initiate a call over CS bearer by sending a CC SETUP message to the MSC Server as specified in 3GPP TS 24.008 [3] as follows:

i) the Called Party BCD Number information element is set to the received SCC AS PSI DN (i.e., the E.164 number) received in the I1 Invite message

ii) Type Of Number set to "International" and Numbering Plan Indicator set to "E.164".in the Called Party BCD Number information element.

NOTE 2: When the ICS UE receives an I1 Invite message, the UE may send an I1 Progress message with Reason set to 180 (Call Progress). The I1 Progress message with Reason set to 180 (Call Progress) is identical to the I1 Progress message with Reason set to 180 (Ringing) described below, except the Reason field will be set to Call Progress.

When the ICS UE receives an indication from the CS domain that the media resources are available (i.e. the UE receives a CC ALERTING message as specified in 3GPP TS 24.008 [3]) and Timer(s) as specified in subclause 7.5.3.2.2.1 have not expired, the UE shall:

1) generate an I1 Progress message with Reason set to 180 (Ringing) containing the following information:

a) a Message Type and a Reason set to that indicate the message is an I1 Progress message, accordance with table 7.3.1;

b) a new value in the Call-Identifier field (Part-1), as specified in subclause 7.2.2. The resulting Call-Identifier value uniquely identifies this I1 session between the UE and SCC AS;

NOTE 3: A new value in the Call-Identifier field (Part-1) is inserted only if this is the first I1 message sent to the SCC AS. Otherwise the previously set Call-Identifier value is used.

c) increment the stored message sequence value, store it, and include it in the Sequence-ID;

d) set the Reason field (per figure 7.3.1) to 180; and

2) send the I1 Progress message with Reason set to 180 (Ringing) towards the SCC AS over the transport layer connection over which the I1 Invite message was received.

If the user accepts the request and Timer(s) as specified in subclause 7.5.3.2.2.1 have not expired, the ICS UE shall:

1) generate an I1 Success message containing the following information:

a) a Message Type and a Reason set to indicate the message is an I1 Success message, accordance with table 7.3.1;

b) the stored Call-Identifier value that uniquely identifies this I1 session between the UE and SCC AS;

c) increment the stored message sequence value, store it, and include it in the Sequence-ID; and

2) send the I1 Success message towards the SCC AS over the transport layer connection over which the I1 Invite message was received.

6.2.1.2.3 ICS UE CS Session Termination with UE assisted T-ADS

If the ICS UE receives an I1 Invite (Augmentation) message with a Replaces information element and it is determined that there is a SIP session being established for the Replaces information element value (e.g., the Replaces information element is set to a value identical to (or deduced from) the SIP session identifier in a previously received SIP INVITE), the ICS UE:

1) shall interpret it as session control fallback from Gm to I1; and

2) shall use the Replaces information element value to correlate the I1 Invite message with the SIP INVITE request prevously received, to get SCC AS PSI DN, the called party identity and the calling party identity.

3) shall indicate that the public user identity, the To-id information element, and the SCC AS PSI DN are in the correlated SIP INVITE request, by setting the Code specific field of the To-id information element to "Unspecified" (see table 7.4.2.3A.1) and the length field is set to 1 and octet 3 is set to all "0"s, respectively.

NOTE: In this case, some information element (e.g. Privacy information element) can be omitted from the I1 Invite message, for the information can be obtained by the ICS UE from the correlated SIP INVITE request.

Afterwards, the ICS UE shall behave as specified in subclause 6.2.1.2.2.

6.2.1.2.4 Failure

6.2.1.2.4.1 Receipt of I1 failure from SCC AS

The ICS UE may receive an I1 Failure message at any time. If the ICS UE receives an I1 Failure message, the ICS UE shall:

1) save the received Call-Identifier field value and use it for further reference to this session;

2) verify if the message is in sequence according to the value of the Sequence-ID, and save the received Sequence-ID;

3) extract the Reason Value as defined in subclause 7.2.2.1.3 from the message;

4) act in accordance with corresponding equivalent response code value as defined in subclauses 21.3 to 21.6 of RFC 3261[6];

4a) optionally display the Reason Phrase if received; and

5) release the session as defined in subclause 6.2.3

6.2.1.2.4.2 Sending I1 failure to SCC AS

The ICS UE may generate an I1 failure message at any time. If an I1 failure message is generated, the ICS UE shall create an I1 Failure message that includes:

a) a Message Type set to the value that indicates that this is an I1 Failure message;

b) generate a Call-Identifier value that identifies the transaction between the ICS UE and SCC AS. Include the Call-Identifier value in the Call-Identifier field in the I1 Failure message;

c) add one to the stored message sequence value. Include the Sequence-ID in the I1 Failure Message;

d) optionally include To-id including alternative address that the UE may be contacted at. It is the same as the contact header field that is defined in sections 21.3 of RFC 3261 [6];

e) a reason value as defined in subclause 7.2.2.1.3 set to:

1) timed out set the reason value to 800;

2) was out of sequence set the reason value to 801;

3) badly formatted set the reason value to 400; or

4) no session exists set the reason value to 481; and

The UE shall then release the session as defined in subclause 6.2.3.

6.2.1.3 Detailed behaviour of SCC AS

6.2.1.3.1 SCC AS CS Session Origination

6.2.1.3.1.1 General

The following subclauses describe the procedures at the SCC AS for I1 session origination. In this scenario, the SCC AS serves the originating user.

6.2.1.3.1.2 Receipt of I1 Invite message

Upon receiving an initial I1 Invite message from the ICS UE via the I1 reference point, the SCC AS shall:

0) if using a transport layer protocol that is not a real-time transport layer protocol, retrieve the ICS UE local time value from the Timestamp information element of the I1 Invite message, and validate the staleness of the message by applying the following equation:

ICS_UE_time_in_the_I1_Invite_message – ICS_UE_time_ as specified in subclause 6.4.4.1 item 1)

(SCC_AS_local_time – SCC_AS_time_ as specified in subclause 6.4.4.1 item 3)d) – Deviation

NOTE: Deviation parameter is 64*T1 seconds.

If the equation is true the message is not stale and it shall processed by the following sections. Otherwise, the messages is discarded and no response is generated to the I1 Invite message; and

1) store the information received in the I1 Invite message, including the called party identity included in the To-id information element, From-id information element, the requested privacy type included in the Privacy information element, the Sequence-ID, Accept-Contact information element, ERAccept-Contact information element and Reject-Contact information element, Call-Identifier field (Part-1) (as specified in subclause 7.2.2.1.4), and transport layer information identifying the transport connection over which the I1 Invite message was received; against the IMS private identity of the originating user’s UE. The IMS private identity to store the information against is determined by comparing the C-MSISDN associated with the IMS private identity against the:

i) MAP service ISDN-Address-String as specificed in 3GPP TS 29.002 [14] if USSD is used as the transport layer protocol for the message,

1A) dynamically allocate a STI and bind it to the information stored in step 1. The STI is specified as an E.164 number;

1B) If the From-id information element in the I1 Invite message is

i) included and the Code Specific information element is set to "Unspecified" (see table 7.4.2.3.1-2) and the length field is set to 0 the default public user identity shall be stored against the I1 Invite message.

ii) included and the Code Specific information element is set to "Identifier" (see table 7.4.2.3.1-2) and the length field is set to 1, the received identifier as derived in Annex A shall be stored against the I1 Invite message.

iii) included and the Code Specific information element is set to set to "International number" or "SIP URI" the Identity contained in the information element body of the To information element value shall be stored against the I1 Invite message.

2) Void

6.2.1.3.1.3 Sending an I1 Progress message in response to I1 Invite message

If Timer(s) as specified in subclause 7.5.3.2.1.2 have not expired, the SCC AS shall:

1) generate an I1 Progress message containing the following information:

a) a Message Type set to indicate the message is an I1 Progress message, accordance with table 7.3.1;

b) a Call-Identifier field, that was constructed by appending the allocated Call-Identifier (Part-2) subfield to the stored Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2.1.4. The Call-Identifier value uniquely identifies this I1 session between the ICS UE and SCC AS;

c) add one to the stored message sequence value. Store and include in the Sequence-ID;

d) include the allocated SCC AS PSI DN (i.e., the E.164 number) in the SCC-AS-id information element;

e) set the Reason field to 183 (as defined in per table 7.3.1); and

f) include the allocated STI (i.e., the E.164 number) in the Session-identifier information element; and

2) send the I1 Progress message towards the originating ICS UE over the transport layer connection over which the I1 Invite message was received.

6.2.1.3.1.4 Sending an I1 Progress message with reason set to 180

If Timer(s) as specified in subclause 7.5.3.2.1.2 have not expired, when sending an I1 Progress message with Progress reason set to 180 towards the originating UE, the SCC AS shall:

1) generate an I1 Progress message containing the following information:

a) the Message Type set to indicate the message is an I1 Progress message, accordance with table 7.3.1;

a1) set the Reason field to 180 (as defined in table 7.3.1);

b) the stored Call-Identifier field (as specified in subclause 7.2.2.1.4) that uniquely identifies this I1 session between the ICS UE and SCC AS ; and

c) add one to the stored message sequence value. Store and include in the Sequence-ID; and

2) send the I1 Progress message towards the originating ICS UE over the transport layer connection over which the I1 Invite message was received.

6.2.1.3.1.5 Sending an I1 Success message

If Timer(s) as specified in subclause 7.5.3.2.1.2 have not expired, when sending an I1 Success message towards the orginating ICS UE, the SCC AS shall:

1) generate an I1 Success message containing the following information:

a) a Message Type set to indicate the message is an I1 Success message, accordance with table 7.3.1;

a1) set the Reason field to 200 (as defined in table 7.3.1); and

b) a Call-Identifier field containing the Call-Identifier value that uniquely identifies this I1 session between the ICS UE and SCC AS;

2) add one to the stored message sequence value. Store and include in the Sequence-ID; and

3) send the I1 Success message towards the originating ICS UE over the transport layer connection over which the I1 Invite message was received.

6.2.1.3.2 SCC AS CS Session Termination without ICS UE assisted T-ADS

6.2.1.3.2.1 Sending an Initial I1 Invite message

When sending an I1 Invite message towards the ICS UE, the SCC AS shall:

1) perform the procedures per 3GPP TS 24.292 subclause 10.4.4 item 1;

1A) dynamically allocate a STI. The STI is specified as an E.164 number;

2) create an I1 Invite message that includes:

a) a Message Type and a Reason set to indicate the message is a Mobile Terminated I1 Invite message, accordance with table 7.3.1;

b) a Call-Identifier field, that includes an allocated Call-Identifier (Part-2) subfield, (see subclause 7.2.2.1.4). The Call-Identifier field in spite of containing only the Part-2 value uniquely identifies this I1session between the ICS UE and SCC AS;

c) a Sequence-ID;

d) a From-id information element that identifies the remote calling party (i.e. obtained from the P-Asserted-Identity header field in the SIP INVITE request received from the calling party), if available and if privacy was not requested by the calling party as specified in RFC 3323 [8] and RFC 3325 [9]. If either the E.164 number that identifies the remote calling party is not available or privacy was requested, then the From-id information element shall not be included in the I1 Invite message;

NOTE 2: The SCC AS will include in the From-id information element the remote calling party only if it is an E.164 number and if privacy was not requested.

e) a To-id information element that;

– if the UE has previously SIP registered as specified in 3GPP TS 23.218 [17] and the R-URI is a SIP URI and the R-URI can be derived (see annex A) then if the R-URI in the received SIP INVITE request is;

i) the default public user identity as derived in Annex A for the terminating UE then the Code specific field of the To-id information element is set to "Unspecified" (see table 7.4.2.3A.1-2) and the length field is set to 0.

ii) is not the default public user identity for terminating UE but matches one of the public user identities then the Code specific field of the Identity Information information element is set to "Identifier" (see table 7.4.2.3A.1-2) and the length field is set to 1 and the Information Element body of the To-id information element information element shall be the identifier value that was derived (see annex A) and maps to the Public User Identity that was received in the R-URI in the SIP INVITE request.

– otherwise Code specific field of the To-id information element is set to

i) a "SIP URI" (see table 7.4.2.3A.1-2) if the public user identity is a SIP URI and the Information body (see table 7.3.2.2) containing the SIP URI.

ii) an "International number" (see table 7.4.2.3A.1-2), if the public user identity is a Tel URI or SIP URI with URI parameter user=phone and the Information body (see table 7.3.2.2) containing the digit string contained in the URI.

f) a Privacy information element set to the value requested by the remote calling party, if available;

g) a SCC-AS-id information element that contains an SCC AS PSI DN set to the E.164 number allocated by the SCC AS itself as per procedures per 3GPP TS 24.292 subclause 10.4.8 item 2;

h) a Session-identifier information element that contains the allocated STI; and

i) if using a transport layer protocol that is not a real-time transport layer protocol, a Timestamp information element that includes current local time measured in seconds. The element will be used by the ICS UE to determine the staleness of the message.

3) store the information sent in the I1 Invite message against the allocated SCC AS PSI DN; and

4) select the transport layer protocol (see subclause 4.2.3) depending on the access network type, and forward the I1 Invite message toward the ICS UE.

Subsequently the SCC AS may receive either an I1 Success message or an I1 Progress message (with Reason field set either to Ringing or Call Progress) from the ICS UE.

6.2.1.3.2.2 Receipt of an I1 Progress message

If Timer(s) as specified in subclause 7.5.3.2.2.2 have not expired, when the SCC AS receives either an I1 Progress message (with Reason field set either to Ringing or Call progressing), the SCC AS shall:

1) verify if a I1 session exists for the received Call-Identifier field value;

2) verify if the message is in sequence according to the Sequence-ID; and

3) store the I1 Progress with reason.

NOTE 5: The SCC AS will use the information received in the I1 Progress message (with Reason field set either to Ringing or Call Progress) and the information saved in step 2 when handling a SIP session with the remote party.

6.2.1.3.3 SCC AS CS Session Termination with ICS UE assisted T-ADS

The SCC AS shall generate an I1 Invite message to the terminating ICS UE as specified in subclause 6.2.1.3.2.1 with the following addition:

1) Include a Replaces information element in the I1 (Augmentation) Invite message, which is set to a value identical to (or deduced from) the SIP session identifier in the previous SIP INVITE request, to indicate that it is session control fallback from Gm to I1;

2) Indicate that the public user identity, the To-id information element value and the SCC AS PSI DN are in the correlated SIP INVITE request, by setting the Code specific field of the To-id information element to "Unspecified" (see table 7.4.2.3A.1) and the length field is set to 1 and octet 3 is set to all "0"s.

NOTE: In this case, some information elements (e.g., Privacy information element) can be omitted from the I1 Invite message, for the information can be get by the ICS UE from the correlated SIP INVITE request.

6.2.1.3.4 Failure

6.2.1.3.4.1 General

SCC AS shall generate an I1 Failure message if the SCC AS receives:

1) an I1 message that is in error, in such circumstances and I1 Failure message shall be returned with an indication describing the error. Error types supported by this specification include:

– No session exists for the incoming message;

– Message is badly formatted; or

– Message is out of sequence; and

2) a SIP error response that needs to sent as an I1 Failure.

If the SCC AS receives an I1 Failure message, it shall send an appropriate SIP error message to the remote UE.

6.2.1.3.4.2 Sending Failure message to ICS UE

The SCC AS may generate an I1 Failure at any time. The SCC AS shall:

1) create an I1 Failure message that includes:

a) a Message Type set to the value that indicates that this is an I1 Failure message;

b) generate a Call-Identifier value that identifies the transaction between the ICS UE and SCC AS. Include the Call-Identifier value in the Call-Identifier field in the I1 Failure message;

c) add one to the stored message sequence value. Include the Sequence-ID in the I1 Failure Message;

d) a reason value set to:

I) If a SIP error was received from the remote UE, set the reason value (see table 7.3.1) to the same value as received in the status code as specified in subclauses 21.3 to 21.6 of RFC 3261 [6]; or

II) If the received I1 message from the UE message:

1) timed out set the reason value to 800;

2) was out of sequence set the reason value to 801;

3) badly formatted set the reason value to 400; or

4) no session exists set the reason value to 481; and

e) if a contact header value as specified in subclause 21.3 of RFC 3261 [6] was received in the SIP error response include individual To-id information elements containing the URI contents of each contact header field; and

f) if reason-phrase header as specified in subclauses 21.3 to 21.6 of RFC 3261[6] was received, insert the contents of the reason-phrase header into the Reason field (see table 7.3.8.1).

The SCC AS shall then release the session as defined in subclause 6.2.3.

6.2.1.3.4.3 Receipt of failure message from ICS UE

The SCC AS may receive an I1 failure message at any time. If the SCC AS receives an I1 Failure message, the SCC AS shall:

1) send a SIP response to the remote end UE with a status code as specified in subclauses 21.3 to 21.6 of RFC 3261 [6] with the same value as received in the I1 Failure reason value (see table 7.3.1); and

2) release the session as defined in subclause 6.2.3.

6.2.2 Void

6.2.3 Session release

6.2.3.1 General

I1 sessions can be torn down by the I1 session release requests and by receipt of a CC DISCONNECT message as specified in 3GPP TS 24.008 [3]. An I1 Bye message is an I1 session release request.

6.2.3.2 Detailed behaviour of ICS UE

6.2.3.2.1 Sending an I1 BYE

When the ICS UE releases an I1 session using the I1 session control channel by sending an I1 Bye message, it shall:

1) set the Call-Identifier field to a value that identifies the I1 session between the ICS UE and SCC AS. Include the Call-ID field in the I1 Bye message;

2) set the Sequence-ID. Include the Sequence-ID in the I1 Bye message;

3) a From-id information element that includes either a SIP URI or an E.164 number, and it will be used by the SCC AS to identify the ICS UE;

4) a To-id information element that includes either a SIP URI or an E.164 number, and will be used by the SCC AS to determine the identity of the called user;

5) a Privacy information element that indicates the ICS UE’s privacy preferences. The SCC AS will apply these preferences to the SIP session that the SCC AS will establish on behalf of the UE; and

6) if there are no more I1 service control sessions using the CS bearer, set the CS bearer release timer value.

If the CS bearer release timer expires, the ICS UE shall send a CC DISCONNECT message to the MSC Server as specified in 3GPP TS 24.008 [3], if needed.

Subsequently, if the ICS UE receives an I1 Success message from the SCC AS, it shall:

1) verify if a I1 session exists for the received Call-Identifier field value;

2) verify if a the message is in sequence according to the value of the Sequence-ID; and

3) consider the I1 session to be released, if verification was successful and clear the CS bearer release timer value.

6.2.3.2.2 Receiving an I1 BYE

When the ICS UE releases a I1 session using the I1 session control channel by receiving an I1 Bye message, it shall:

1) if there are no more I1 service control sessions using the CS bearer, the ICS UE shall send a CC DISCONNECT message to the MSC Server as specified in 3GPP TS 24.008 [3], if there are no more I1 service control sessions using the CS bearer;

2) if there are more I1 service control sessions using the CS bearer, the ICS UE shall transmit a I1 Success message, containing the following information:

a) a Message Type set to the value that indicates that is an I1 Success message;

b) a Call-Identifier field with the stored Call-Identifier value that uniquely identifies this I1 session between the ICS UE and SCC AS; and

c) increment the stored message sequence value, store it, and include it in the Sequence-ID.

When the ICS UE receives a CC DISCONNECT message to release the CS bearer as specified in 3GPP TS 24.008 [3]:

– the CS bearer release timer expires shall be cleared, if needed;

– if the ICS UE has a SIP REGISTER request associated with the ongoing CS call, the UE shall send a SIP reINVITE request requesting the media over the CS bearer to be deleted.

If the ICS UE receives a SIP reINVITE request requesting the media over the CS bearer to be deleted and a DISCONNECT message for the CS bearer was already received, the ICS UE shall accept the request to delete the media over the CS bearer.

6.2.3.3 Detailed behaviour of SCC AS

6.2.3.3.1 Sending an I1 Bye message to the UE

The SCC AS enhanced for I1 releases a session by generating and sending an I1 Bye message, containing the information:

0) a Message Type and a Reason set to indicate the message is an I1 Bye message, accordance with table 7.3.1;

1) set the Call-Identifier to a value that identifies the I1 session between the ICS UE and SCC AS. Include the Call-Identifier value in the Call-Identifier field in the I1 Bye message;

2) set the Sequence-ID. Include the Sequence-ID in the I1 Invite message.

3) include a From-id information element that identifies the remote calling party, if available;

4) include a To-id information element that includes the E.164 number of the ICS UE;

5) include a Privacy information element set to the value requested by the remote calling party, if available;

6) include a SCC-AS-id information element that contains an SCC AS DN set to the E.164 number allocated by the SCC AS itself; and

7) store the information sent in the I1 Bye message against the allocated SCC AS PSI DN.

6.2.3.3.2 Receipt of I1 Success message from the UE

If the SCC AS receives an I1 Success message from the ICS UE, it shall:

1) verify if a I1 session exists for the received Call-Identifier field value;

2) verify if a the message is in sequence according to the value of the Sequence-ID; and

3) consider the I1 session to be released, if verification was successful.

If any of the operations in 1) or 2) fail the I1 Success message shall be discarded.

6.2.3.3.3 Receipt of I1 Bye message from the UE

The SCC AS shall transmit an I1 Success message using the I1 session control channel, it shall containing the following information:

a) a Message Type and a Reason set to indicate the message is an I1 Success message, accordance with table 7.3.1;

b) a Call-Identifier field set to the stored Call-Identifier value that uniquely identifies this I1 session between the ICS UE and SCC AS; and

c) increment the stored message sequence value, store it, and include it in the Sequence-ID.

6.2.3A I1 session setup when invoking mid-call supplementary service

6.2.3A.1 General

If the ICS UE and SCC AS want to use the I1 protocol that apply to a CS call that was previously established without using the I1 interfaces (e.g. the call was set as specified in 3GPP TS 24.292 [5] subclause 10.4.7 or subclause 7.4.3), the ICS UE and SCC AS may avoid the explicit exchange of the I1 messages to create an I1 session to bind it to the respective CS call (as specified in subclause 6.2.4). In this case, it is assumed that a reserved Call-Identifier value (i.e. all bits set to values "1") will be used to exchange the initial I1 messages (e.g. mid-call I1 messages). Hence, the I1 control of an established CS call is acquired (i.e. an I1 session is automatically created and bound to the respective CS call), upon setting up a transport-layer connection between the ICS UE and the SCC AS, and subsequently the ICS UE and the SCC AS successfully exchanging the I1 messages (e.g. the I1 Mid Call Request message and the I1 Success messages) that use the reserved Call-Identifier value. The ICS UE or SCC AS shall add the I1 control that uses the that a reserved Call-Identifier value to an existing CS call as specified in this subclause only when there is a single CS call (i.e. a CS call that was set up without using the I1) between the ICS UE and the SCC AS over the CS domain. In this case, the information that is already known to the ICS UE and the SCC AS from the existing CS call (e.g. To-id, From-id, Privacy) will be also bound to this I1 session that use the reserved Call-Identifier value and the associated CS call (i.e. a CS call that was set up without using the I1 interfaces). Any I1 session that is subsequently created shall not use the reserved Call-Identifier value.

The automatically established I1 session that uses the reserved Call-Identifier value and associated CS call may be to control the CS call, e.g. to invoke the mid-call supplementary services or to cleared an CS call that is on hold.

6.2.3A.2 Detailed behaviour of ICS UE

6.2.3A.2.1 Mid-call service initiated by ICS UE

If the ICS UE wants to add the I1 control to an existing end-to-end CS call that was previously established without using the I1 protocol, and invoke a mid-call supplementary service to this call, the ICS UE shall send an I1 message to the SCC AS. The ICS UE shall populate the I1 message, as specified in subclause 6.2.1.2.1.2 and subclause 6.3 with the following additions:

1) insert a new value in the Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2.1.4. When inserting a new value in the Call-Identifier (Part-1) subfield, the UE shall set all bits in the Part-1 subfield to values "1" (i.e. "11111111"); and

NOTE 1: In this case some information is already known to the ISC UE from the existing end-to-end call (e.g. To-id, From-id, Privacy)

2) send the I1 message to the SCC AS.

Upon receiving an I1 Success message from the SCC AS with all bits in the Call-Identifier (Part-1 and Part-2) subfield set to values "1", the ICS UE shall treat the I1 session as established and the requested supplementary service (as specified in the subclause 6.3), as applied to the existing end-to-end call (that was set up without using the I1 protocol). The established I1 session may be subsequently used either by the ICS UE or the SCC AS, to exchange the I1 messages that pertain to this end-to-end call (e.g. send an I1 Mid Call Request message to resume the call, if the call was previously placed on hold, as specified in subclause 6.3).

NOTE 2: The Call-Identifier (Part-1 and Part-2) subfield with all bits set to values "1" is a reserved value that identifies the I1 session that was automatically created upon invocation of the mid-call supplementary service.

NOTE 3: The allocated STI is always included in the first I1 message sent by the SCC AS to the ICS UE. If the CS-to-PS access transfer is performed prior to the ICS UE obtaining the allocated STI from the SCC AS, the static STI is used for the CS-to-PS access transfer, as described in 3GPP TS 24.237 [13].

6.2.3A.2.2 Mid-call service initiated by SCC AS

If the ICS UE receives an I1 message from the SCC AS that contains the Call-Identifier field with all bits in the Part-2 subfield set to the values "1", the ICS UE shall identify the call that was previously set without using the I1 protocol.

If the ICS UE identifies an existing end-to-end call (that was previously established without using the I1 protocol), the ICS UE shall generate an I1 Success message containing the information as specified in subclause 6.2.1.2.2 and subclause 6.3 with the following additions:

1) insert a new value in the Call-Identifier (Part-1) subfield with all bits in the Part-1 subfield set to values "1"; and

2) treat the indicated mid-call supplementary service (specified in subclause 6.3) as applied to the existing call, and the I1 session as established.

NOTE: The allocated STI is always included in the first I1 message sent by the SCC AS to the ICS UE. If the CS-to-PS access transfer is performed prior to the ICS UE obtaining the allocated STI from the SCC AS, the static STI is used for the CS-to-PS access transfer, as described in 3GPP TS 24.237 [13].

6.2.3A.3 Detailed behaviour of SCC AS

6.2.3A.3.1 Mid-call service initiated by ICS UE

If the SCC AS receives an I1message from the ICS UE that contains the Call-Identifier field with all bits in the Part-1 subfield set to values "1", the SCC AS shall determine if this I1 message is for an existing end-to-end call (that was previously established without using the I1 protocol) by using the CS domain number (e.g., MSISDN) obtained from the transport layer. If the SCC AS identifies an existing end-to-end call (that was previously established without using the I1 protocol), the SCC AS shall:

1) perform the steps specified in subclause 6.2.1.3.1.2 and subclause 6.3, and invoke the requested supplementary service, as specified in subclause 6.3 (e.g. perform the standard SIP procedures toward the far end and the MGCF).

NOTE 1: In this case, some information elements that are already known to the SCC AS from the existing CS end-to-end call (e.g. To-id, From-id, Privacy) will be bound to the existing (permanent) I1 session and the associated single end-to-end call.

Upon successfully performing the requested supplementary service, the SCC AS shall generate an I1 Success message containing the information as specified in subclause 6.2.1.3.1.3 and subclause 6.3 with the following additions:

1) insert a new value in the Call-Identifier (Part-2) subfield, the UE shall set all bits in the Part-2 subfield to values "1";

2) send the I1 Success message towards the ICS UE; and

3) treat the indicated mid-call supplementary service (specified in subclause 6.3) as applied to the existing end-to-end call, and the I1 session as established.

NOTE 2: The allocated STI is always included in the first I1 message sent by the SCC AS to the ICS UE. If the CS-to-PS access transfer is performed prior to the ICS UE obtaining the allocated STI from the SCC AS, the static STI is used for the CS-to-PS access transfer, as described in 3GPP TS 24.237 [13].

6.2.3A.3.2 Mid-call service initiated by SCC AS

If the SCC AS wants to add the I1 control to an existing end-to-end call that was previously established without using the I1 protocol, and invoke a mid-call supplementary service to this call, the SCC AS shall:

1) invoke the supplementary service, as specified in subclause 6.3 (e.g. perform the standard SIP procedures toward the far end and the MGCF); and

2) send an I1 message to the ICS UE specifying the invoked supplementary service, as specified in subclause 6.3. The SCC AS shall populate this I1 message as specified in subclause 6.2.1.3.2.1 and subclause 6.3 with the following additions:

a) insert a new value in the Call-Identifier (Part-2) subfield, as specified in subclause 7.2.2.1.4. When inserting a new value in the Call-Identifier (Part-2) subfield, the UE shall set all bits in the Part-2 subfield to values "1"; and

b) not include the SCC-AS-id information element (that includes the SCC AS PSI DN ) in the I1 message.

NOTE 1: In this case some information is already known to the SCC AS from the existing end-to-end call (e.g. To-id, From-id, Privacy).

NOTE 2: The allocated STI is always included in the first I1 message sent by the SCC AS to the ICS UE. If the CS-to-PS access transfer is performed prior to the ICS UE obtaining the allocated STI from the SCC ASI, the static STI is used for the CS-to-PS access transfer, as described in 3GPP TS 24.237 [13].

Upon receiving an I1 Success message from the ICS UE with all bits in the Call-Identifier (Part-1 and Part-2) subfield set to values "1", the SCC AS shall treat the I1 session as established and the requested supplementary service (as specified in the subclause 6.3), as applied to the existing end-to-end call (that was set up without using the I1 protocol). The established I1 session may be subsequently used either by the ICS UE or the SCC AS, to exchange the I1 messages that pertain to this end-to-end call.

6.2.4 Adding I1 control to existing CS session (I1 Augmentation)

6.2.4.1 General

Standard CS procedures can be used to deliver the incoming session to the ICS UE as specified in 3GPP TS 24.292 [5] subclause 10.4.7 (SCC AS for call termination over CS to non-ICS UE) or originate a session as specified in 3GPP TS 24.292 [5] subclause 7.4.3 (ICS UE using CS). Additional IMS parameters or service control can be optionally communicated to the ICS UE using I1 after the call has been setup. The ICS UE or SCC AS shall add I1 control to an existing call only when there is a single session over CS.

6.2.4.2 Detailed behaviour of ICS UE

6.2.4.2.1 Augmentation initiated by ICS UE

If the ICS UE wants to add I1 control to an existing call that was previously established without using either the I1 or the Gm interfaces, the ICS UE shall send an I1 Invite message over I1interface. The ICS UE shall populate the I1 Invite message as specified in subclause 6.2.1.2.1.2 with the following additions:

1) set the Reason field in the I1 Invite message to value hex "002", as specified in Table 7.3.1. This value indicates that augmentation is requested;

NOTE: In this case, some information elements (e.g. From, Privacy) can be omitted from the I1 Invite message, for the information is already known for the ongoing session.

Upon receiving an I1 Success message from the SCC AS, the ICS UE shall treat the ongoing I1 session as established and the existing call being controlled by the respective I1 session.

6.2.4.2.2 Augmentation initiated by SCC AS

If the ICS UE receives a new I1 Invite message from the SCC AS containing the Reason field set to value hex of "002", as specified in Table 7.3.1, the ICS UE shall determine if this I1 Invite message is for an ongoing call that was established without I1 and Gm. If there is an ongoing call, the ICS UE shall:

1) respond to the I1 Invite message with an I1 Success message; and

2) treat the ongoing I1 session as established and the existing call being controlled by the respective I1 session.

6.2.4.3 Detailed behaviour of SCC AS

6.2.4.3.1 Augmentation initiated by ICS UE

If the SCC AS receives an I1 Invite message from the ICS UE containing the Reason field set to value hex "002", as specified in table 7.3.1, the SCC AS shall determine if this I1 Invite message is for an ongoing call using the CS domain number (e.g., MSISDN)obtained from the transport layer. If there is an ongoing call, the SCC AS shall:

1) respond to the I1 Invite message with an I1 Success message; and

2) treat the ongoing I1 session as established and the existing call being controlled by the respective I1 session.

6.2.4.3.2 Augmentation initiated by SCC AS

If the SCC AS wants to add I1 control to an existing call that was previously established without using either the Gm or the I1 interfaces, the SCC AS shall send a new I1 Invite message over the I1 interface. The SCC AS shall populate the I1 Invite message as specified in subclause 6.2.1.3.2.1 with the following addition:

1) set the Reason field in the I1 Invite message to value hex of "002", as specified in Table 7.3.1. This value indicates that augmentation is requested.

NOTE: In this case, some information elements (e.g. From-id, To-id, Privacy) can be omitted from the I1 Invite message, for the information is already known for the ongoing session.

Upon receiving an I1 Success message, the SCC AS shall treat the ongoing I1 session as established and the existing call being controlled by the respective I1 session.

6.2.5 Service control transfer (Gm fallback to I1)

6.2.5.1 General

When the Gm reference point is used for service control signalling, a change of access network due to handover (e.g. as described in 3GPP TS 23.009 [10] and 3GPP TS 25.413 [11]) may result in an inability to use the PS access for the Gm reference point. In this case, if the I1 interface in the target access network is available and supported, the service continuity may be maintained by switching the service control signalling from the Gm reference point to the I1 interface.

If the ICS UE discovers that the Gm reference point is not available for an ongoing session that is using a CS bearer which was established over the respective Gm reference point, the ICS UE can transfer the service control signalling from the Gm reference point to the I1 interface, if the I1 interface is available, while retaining the existing CS bearer (i.e. the existing CS bearer is left intact). However, if prior to the change of the access network, the UE was not attached to the CS domain and a PS bearer was used for either the voice media or voice and video media of the IMS session, then the service continuity may be maintained by switching the service control signalling from the Gm reference point to the I1 interface and transferring the voice media or voice and video media from the PS bearer to the newly-established CS bearer.

6.2.5.2 Service continuity while retaining the use of CS access for media

6.2.5.2.1 Detailed behaviour of ICS UE

When the ICS UE, that has an established IMS session that is using the CS media, originates a service control transfer from the Gm reference point to the I1 reference point while retaining the existing CS bearer and associated media intact, the ICS UE shall behavemessage as specified in the subclause 6.2.1.2.1 with the following additions:

1) include a Replaces information element in the I1 Invite (Augmentation) message that contains a STI. The STI identifies the SIP dialog that was previously established over the Gm reference point on the Source Access Leg and will be transferred to this I1 session on the Target Access Leg.

2) if the To-id information element is included, and the public user identity inserted in the To-id information element is not an E.164 number, then indicate that the public user identity and the To-id information element are in the correlated SIP INVITE request, by setting the To-id Information IE (see table 7.3.2.2) Code Specific Information element to "Unspecified" (see table 7.4.2.3A.1) and the length IE is set to 1 and octet 3 is set to all "0"s.

NOTE 1: In this case, some I1 information elements (e.g. Privacy) can be omitted from the I1 Invite message, since this information is already known to the SCC AS from the ongoing SIP dialog that was previously established over the Gm reference point on the Source Access Leg. For example, the inclusion of SIP URI into the To-id and From-id information elements is not needed since these information elements may be omitted from the I1 Invite message.

NOTE 2: It is assumed that when the SIP dialog was established over the Gm reference point, the respective STI was used to identify this SIP dialog.

Upon receiving the I1 Progress message from the SCC AS, the UE shall not initiates the call setup over the CS domain by sending a CC SETUP message to the MSC Server, since the I1 session will inherit the existing CS media (i.e. the existing CS bearer is left intact).

When the ICS UE receives an I1 Success message from the SCC AS, the UE shall consider the service control signalling as being transferred from the Gm reference point to the I1interface and the associated CS media as being transferred to the I1 session (i.e. the I1 session is now controlling the inherited CS media). Furthermore, the UE shall considered the SIP dialog on the Source Access Leg that was originally set using the Gm reference point and all remaining PS media associated with this SIP dialog (i.e. the PS media that were not transferred), if any, as terminated.

NOTE 3: If the UE is incapable of simultaneously communicating over the Gm reference point on the Source Access Leg and the I1 interface over the Target Access Leg, the UE will not receive a SIP BYE request from the ICS AS sent over the Gm reference point on the Source Access Leg.

NOTE 4: Irrespective whether the UE receives a SIP BYE request over Gm reference point on the Source Access Leg or not, the UE will consider the SIP dialog on the Source Access Leg and all remaining PS media associated with this SIP dialog (i.e. the PS media that were not transferred), if any, as terminated.

6.2.5.2.2 Detailed behaviour of SCC AS

If the SCC AS, that supports the I1 protocol, receives an initial I1 Invite message with a Replaces information element that contains a STI, the SCC AS shall use the STI to identify an existing SIP dialog that was previously established using the Gm reference point on the Source Access Leg, and will be replaced with the I1 session on the Target Access Leg. If the identified SIP dialog on the Source Access Leg is currently using a CS bearer, the SCC AS shall behave as specified in subclause 6.2.1.3.1 with the following addition:

1) interpret the received I1 Invite message containing the Replaces information element as request for service control transfer from Gm reference point on the Source Access Leg to the I1 interface on the Target Access Leg;

2) correlate the I1 Invite message with the existing SIP dialog that is using a CS bearer, based on the STI included in the Replaces information element;

NOTE 1: In this case, some information elements (e.g. To-id, From-id, Privacy) may not be included in the I1 Invite message. The omitted I1 information elements are already known to the SCC AS from the ongoing SIP dialog that was previously established over the Gm reference point on the Source Access Leg.

3) send the I1 Progress message towards the originating UE that does not include an allocated SCC AS PSI DN;

NOTE 2: Upon sending the I1 Progress message towards the originating UE, the SCC AS will not receive an initial SIP INVITE request from the CS domain, since the existing CS media will be left intact and only the control will be transferred from the SIP dialog identified by the STI in the received Replaces information element to the I1 session being established.

4) examine whether the SIP dialog on the Source Access Leg has a single CS bearer (i.e. no PS bearers) associated with this SIP dialog, or there are additional PS bearers (in addition to the CS bearer) associated with this SIP dialog.

a) if there is a single CS bearer and no PS bearers associated with this SIP dialog, the SCC AS proceeds with the steps below, starting with the step 5; or

NOTE 3: In spite of the service control being transferred from the Gm reference point to the I1 interface, there is no need to update the remote UE by sending a new SDP offer since the CS media has been left intact.

b) if, in addition to a CS bearer, there are additional PS bearers associated with this SIP dialog, the SCC AS shall proceed as follows:

i) send a SIP re-INVITE request toward the CS domain (e.g. MGCF) that does not contain an SDP offer;

ii) upon receiving an SDP offer from the CS domain (in the response to the SIP re-INVITE request), the SCC AS update the remote UE by sending a SIP re-INVITE request toward the the remote UE. The SDP offer included in the SIP re-INVITE request sent toward the the remote UE contains the information received in the SDP offer from the CS domain and terminates all the PS bearers, as per standard SIP procedures;

iii) upon receiving the SDP answer in the response to the SIP re-INVITE request from the remote UE, the SCC AS sends an SIP ACK toward the CS domain (e.g. MGCF) that contains an SDP anwer. The SDP answer contains the information obtained from the SDP answer conveyed in the response to the SIP re-INVITE request received from the remote UE. In addition, the SCC AS sends a SIP ACK toward the remote UE;

iv) proceeds with the steps below;

5) release the SIP dialog on the Source Access Leg by sending a SIP BYE request via the SIP dialog over the Gm reference point on the Source Access Leg, if the SIP dialog is still active; and

NOTE 4: The SIP dialog may have been released by the IMS core network as specified in 3GPP TS 24.229 [12], subclause 5.2.8.1.2.

NOTE 5: If the UE is incapable of simultaneously communicating over the Gm reference point on the Source Access Leg and the I1 interface over the Target Access Leg, the SCC AS will not receive a 200 (OK) response to a SIP BYE request.

NOTE 6: Irrespective whether the SCC AS receives a 200 (OK) response to the SIP BYE request over the Gm reference point on the Source Access Leg or not, the SCC AS will consider the dialog on the Source Access Leg and all remaining PS media associated with this dialog (i.e. the PS media that were not transferred), if any, as terminated.

6) send an I1 Success message to the UE over the I1 interface. Upon sending the I1 Success message to the UE, the SCC AS shall consider the service control signalling as being transferred from the Gm reference point to the I1 interface and the associated CS media as being transferred to the I1 session (i.e. the I1 protocol is now controlling the inherited CS media).

6.2.5.3 Service continuity when transferring from PS access to CS access

When an UE, that has an established SIP dialog that is using only the PS media (i.e. no CS media) and the Gm reference point for service control signalling (e.g. the UE is not attached to the CS domain), determines that the Gm reference point is not anymore available, the UE may maintain service continuity by switching the service control signalling from the Gm reference point to the I1 reference point and an associated PS bearer to the CS bearer.

The I1 protocol is used to transfer either a single PS voice media or a single PS voice and PS video media session to a single CS bearer. If there are more then one active PS voice media or PS voice media and PS video media associated with the SIP dialog being transferred, then the last-established active PS voice media or PS voice and PS video media will be transferred from the PS domain to the CS domain. If there are only inactive PS voice media or PS voice and PS video media associated with the SIP dialog, then the last-established inactive PS voice media or PS voice and PS video media will be transferred from the PS domain to the CS domain. In either case, the SIP dialog and all associated PS media that were not transferred are terminated.

If the transferred media was active prior to the transfer, it shall stay active upon the completion of the transfer procedure. Likewise, if the transferred media was inactive prior to the transfer, it shall stay inactive upon the completion of the transfer procedure.

6.2.5.3.1 Detailed behaviour of UE

When the UE, that has an established SIP dialog that is using only the PS media (i.e. no CS media), transfers the service control signalling from the Gm reference point to the I1interface and either the voice media or the voice and video media from the PS access to the CS access, the UE behave as specified in subclause 6.2.1.2.1 with the following additions:

1) include a Replaces information element in the I1 Invite message that contains the STI. The STI identifies the SIP dialog that was previously established over the Gm reference point on the Source Access Leg and will be transferred to the I1 session on the Target Access Leg.

NOTE 1: In this case, some I1 information elements (e.g. To-id, From-id, Privacy) can be omitted from the I1 Invite message, since this information is already known to the SCC AS from the ongoing SIP dialog that was previously established over the Gm reference point on the Source Access Leg. For example, the inclusion of SIP URI into the To-id and From-id information elements is not needed since these information elements may be omitted from the I1 Invite message.

NOTE 2: It is assumed that when the SIP dialog was established over the Gm reference point, the respective STI was used to identify this SIP dialog.

When the UE receives an I1 Progress message from the SCC AS that contains an IUA PSI DN, the UE shall initiates a call over the CS domain using the received IUA PSI DN, as specified in subclause 6.2.1.2.1.

When the UE receives an I1 Success message from the SCC AS, the UE shall consider the service control signalling as being transferred from the Gm reference point to the I1interface and the associated voice media or voice and video media as been transferred from the PS domain to the CS domain. Furthermore, the UE shall considered the SIP dialog on the Source Access Leg that was originally set using the Gm interface and all remaining PS media (i.e. the PS media that were not transferred), if any, associated with this SIP dialog as terminated.

NOTE 4: Irrespective whether the UE receives a SIP BYE request over the Gm reference on the Source Access Leg or not, the UE will consider the dialog on the Source Access Leg and all remaining PS media associated with this SIP dialog that were not transferred, if any, as terminated.

6.2.5.3.2 Detailed behaviour of SCC AS

If the SCC AS that supports the I1 protocol receives an initial I1 Invite message with a Replaces information element that contains a STI, the SCC AS shall use the STI to identify an existing SIP dialog that was previously established using the Gm reference point on the Source Access Leg and will be replaced with the I1 session on the Target Access Leg. If the identified SIP dialog on the Source Access Leg is currently using only PS media, the SCC AS shall behave as specified in subclause 6.2.1.3.1 with the following addition:

2) correlate the I1 Invite message to an existing SIP dialog (and is using only PS bearers), based on the STI received in the Replaces information element, and select a PS bearer that is using either a voice media or voice and video media and that will be transferred to the CS bearer;

NOTE 1: If there are more then one active PS voice media or PS voice media and video media associated with the SIP dialog, the SCC AS selects the last-established active PS voice media or PS voice and video media. If there are only inactive PS voice media or PS voice and video media associated with the SIP dialog, then the SCC AS selects the last-established inactive PS voice media or PS voice and video media.

3) send the I1 Progress message towards the originating UE that includes an allocated SCC AS PSI DN, as specified in subclause 6.2.1.3.1;

Upon receiving the initial SIP INVITE request from the CS domain, the SCC AS shall updates the Remote Leg by sending an SIP re-INVITE request toward the remote UE that include an SDP offer. The SDP offer included in the SIP re-INVITE request sent toward the the remote UE specifies which media is being transferred to the CS domain, and which PS media, if any, are being terminated. When generating the SDP offer towards the remote UE, the SCC AS shall use the information received in the SDP offer in the SIP INVITE request received from the CS domain and terminates all the PS bearers that have not been transferred to the CS domain, as per standard SIP procedures.

Upon receiving a SIP 200 (OK) response from the remote UE that contains an SDP answer, the SCC AS shall send the SIP 200 (OK) response towards the CS domain that includes a SDP answer. The SDP answer sent towards the CS domain contains the media information that pertains to the voice media or voice and video that has been received in the SDP answer from the remote UE and is being transferred to the CS domain.

Upon receving a SIP ACK request from the CS domain, the SCC AS shall send a SIP ACK tovard the remote UE, and:

– release the SIP dialog on the Source Access Leg by sending a SIP BYE request via the SIP dialog over the Gm reference point on the Source Access Leg, if the SIP dialog is still active; and

– send an I1 Success message toward the UE over the I1 interface.

NOTE 2: The SIP dialog may have been released by the IMS core network as specified in 3GPP TS 24.229 [12], subclause 5.2.8.1.2.

Upon sending the I1 Success message to the UE, the SCC AS shall consider the service control signalling as being transferred from the Gm interface to the I1interface and the associated CS media as being transferred to the I1 session (i.e. the I1 protocol is now controlling the transferred CS media).

NOTE 3: If the UE is incapable of simultaneously communicating over the Gm reference point on the Source Access Leg and the I1 interface over the Target Access Leg, the SCC AS will not receive a 200 (OK) response to the SIP BYE request from the UE.

NOTE 4: Irrespective whether the SCC AS receives a 200 (OK) response to the SIP BYE request over the Gm reference point on the Source Access Leg or not, the SCC AS will consider the dialog on the Source Access Leg and all non-transferred PS media associated with this dialog, if any, as terminated.

6.2.5.3.3 P-CSCF releasing the source access leg during transferring from PS access to CS access

When SCC AS receives a SIP BYE request on the Source Access Leg with the Reason header field containing a SIP 503 (Service Unavailable) response code then:

– if the SCC AS receives an I1 Invite message within a time defined by the operator policy after the SIP BYE request reception, then the SCC AS shall not initiate release of the dialog toward the the remote UE; and

– if the SCC AS does not receive a I1 Invite message within a time defined by the operator policy after the SIP BYE request reception then the SCC AS shall initiate release of the dialog toward the the remote UE.

NOTE: 8 seconds is an appropriate value for the operator policy.

6.2.5.5 Service continuity after transferring multiple calls from PS access to CS access using SRVCC

6.2.5.5.1 General

The ICS UE, that has previously used the Gm reference point to establish multiple active or held calls that are currently using a single CS bearer as a result of completion of SRVCC procedure, shall transfer the service control signalling from the Gm reference point to the I1 interface for each call while retaining the existing single CS bearer.

6.2.5.5.2 Detailed behaviour of ICS UE

The ICS UE shall follow the procedures as specified in subclause 6.2.5.2.1 for each call.

6.2.5.5.3 Detailed behaviour of SCC AS

The SCC AS shall follow the procedures as specified in subclause 6.2.5.2.2 for each call.

6.2.6 Assignment of single CS bearer to I1 sessions

6.2.6.1 General

When the ICS UE wants to set up a new call using the I1 protocol, and if there is an existing CS bearer leg (i.e. between the ICS UE the MSC/MGCF) that has been previously establish either by the ICS UE or the SCC AS, and there are no active I1 sessions using the existing CS bearer leg (all I1 sessions using the existing CS bearer leg are on hold), the ICS UE can use the existing CS bearer leg for the new call. Likewise, for the incoming call destined for the serving ICS UE, the SCC AS can indicate to the ICS UE to use an existing CS bearer leg for the ICS UE terminated call, if there are no active I1 sessions using the existing CS bearer leg (all I1 sessions associated with the existing CS bearer leg are on hold). In either case, once the new I1 session is set up, the existing CS bearer leg (i.e. between the ICS UE the MSC/MGCF) will be concatenated with a new IP bearer leg to form an end-to-end connection for media for the new call between the ISC ICS UE and the remote endpoint.

When either ICS UE or the SCC AS initiate the set up of an I1 session that will use an existing CS bearer leg (i.e. between the ICS UE the MSC/MGCF) for media, it is assumed that there is a single existing CS bearer leg between the ICS UE and the MSC/MGCF. Hence, neither the ICS UE nor the SCC AS will have to explicitly specify which existing CS bearer leg will be used for the call. The ICS UE and the SCC AS implicitly assume that the single existing CS bearer leg is used for the new call being set up. When a call that was on hold is resumed, the SCC AS ensure that the respective end-to-end connection for media associated with the resumed call is also restored, i.e. the existing CS bearer leg is re-allocated to the resumed call and re-concatenated to the IP leg associated with the resumed call.

6.2.6.2 Originating call behaviour

6.2.6.2.1 Detailed behaviour of ICS UE

Prior to initiating the establishment of a new I1 session as described in this subclause, the ICS UE ensures that there is only one existing CS bearer leg between the ICS UE and the MSC/MGCF. If there is either none or more than one existing CS bearer leg between the ICS UE and the MSC/MGCF, the ICS UE shall not initiate the establishment of an I1 session as described in this subclause.

When the ICS UE wants to establish a new I1 session that uses an existing CS bearer leg between the ICS UE and the MSC/MGCF, the ICS UE shall send an I1 Invite message toward the SCC AS, and populate the I1 Invite message as specified in subclause 6.2.1.2.1.2 with the following additions:

1) set the Reason in the I1 Invite message to value hex "003", as specified in table 7.3.1. This value indicates to the SCC AS that the existing CS bearer leg will be used for this call.

If the ICS UE receiving an I1 Progress message with Progress reason set to Call progressing from the SCC AS, the ICS UE shall behave as specified in subclause 6.2.1.2.1.3 with the following addition:

1) ignore the SCC AS PSI DN, if included in the I1 Progress message with Progress reason set to Call progressing received from the SCC AS, i.e. the ICS UE shall not initiate a call toward the CS domain.

NOTE 1: The ICS UE will not initiates the call setup over the CS domain for the purpose of setting up a new CS bearer leg, since the existing CS bearer leg will be used for the call being established.

When the ICS UE receives an I1 Progress message with Progress reason set to 180 the ICS UE shall:

1) provide an alerting indication to the user.

NOTE 2: If in-band alerting is not provided via the CS bearer, the ICS UE will provide local alerting.

When the ICS UE receives an I1 Success message from the SCC AS, the ICS UE shall behave as specified in subclause 6.2.1.2.1.5 with the following addition:

1) the ICS UE shall not expect to receive a CONNECT message from the CS domain as specified in 3GPP TS 24.008 [3] since it did not send a SETUP message toward the CS domain; and

2) consider the I1 session as being established and the existing CS call leg as being assigned to this I1 session.

6.2.6.2.2 Detailed behaviour of SCC AS

Prior to initiating the establishment of an I1 session as described in this subclause, the SCC AS shall insure that there is only one existing CS bearer leg between the ICS UE and the MSC/MGCF. If the SCC AS receives an I1 Invite message from the ICS UE that includes a Bearer information element that contains a Reason field set to value hex "003", as specified in table 7.3.1, and if there is either none or more than one existing CS bearer leg between the ICS UE and the MSC/MGCF, the SCC AS shall reject the request for the I1 session establishment.

If a new call request destined for the ICS UE arrives at the SCC AS during the establishment of an I1 session as described in this subclause, the SCC AS shall reject this request by immediately responding with a busy indication to the new incoming call.

If the SCC AS receives an initial I1 Invite message with the Reason set to value hex "003", as specified in table 7.3.1 that indicates to the SCC AS that the existing CS bearer leg will be used for this call, and there is only one existing CS bearer leg between the ICS UE and the MSC/MGCF, the SCC AS shall behave as specified in subclause 6.2.1.3.1.2 with the following addition:

1) interpret the received I1 Invite message with the Reason set to value hex "003" as a request to use the existing CS bearer leg when setting up an end-to-end connection for media toward the called user.

The SCC AS may send the I1 Progress message with Progress reason set to Call progressing towards the originating ICS UE. If the SCC AS sends the I1 progress message toward the originating ICS UE, the SCC AS shall populate the I1 Progress message with Progress reason set to Call progressing as specified in subclause 6.2.1.3.1.3 with the following addition:

1) the SCC AS shall not include the SCC-AS-id information element that contains an allocated SCC AS PSI DN in the I1 Progress message with Progress reason set to Call progressing.

NOTE 1: The reason for sending the I1 Progress message with Progress reason set to Call progressing, is to increase the retransmissions timer at the ICS UE, if an unreliable transport-layer connection is used (see subclause 7.5.3.2.1.1.2).

Subsequently, the SCC AS shall:

1) send a SIP re-INVITE request toward the CS domain (i.e. the MGCF) that does not contain an SDP offer; and

2) upon receiving a SDP offer from the CS domain (in the response to the SIP re-INVITE request), send an initial SIP INVITE request toward the the remote UE. The SDP offer included in the SIP INVITE request sent toward the the remote UE contains the information in the SDP offer received from the CS domain.

Upon receiving the SIP 180 (Ringing) response from the remote UE, the SCC AS shall send an I1 Progress message with Progress reason set to 180 towards the originating UE, as specified in subclause 6.2.1.3.1.4 with the following addition:

1) if this is the first I1 Progress message (i.e. the SCC AS did not previously sent an I1 Progress message with Progress reason set to Call progressing), the SCC AS shall also include (in the I1 Progress message with Progress reason set to 180) all information elements as specified in subclause 6.2.1.3.1.3, except the SCC AS PSI DN.

Upon receiving a SIP 200 (OK) response from the remote UE, the SCC AS shall:

1) send the SIP ACK request towards the CS domain that includes a SDP answer received from the remote UE. The SDP answer sent towards the CS domain contains the media information that has been received in the SDP answer from the remote UE; and

2) send an I1 Success message toward the ICS UE over the I1 interface as specified in the subclause 6.2.1.3.1.5, and a SIP ACK toward the remote UE.

6.2.6.3 Terminating call behaviour

6.2.6.3.1 Detailed behaviour of ICS UE

Prior to accepting a request for an I1 session as described in this subclause, the ICS UE ensures that there is only one existing CS bearer leg between the ICS UE and the MSC/MGCF. If there is either none or more than one existing CS bearer leg between the ICS UE and the MSC/MGCF, the ICS UE shall reject the request for the I1 session establishment.

If the ICS UE receives an initial I1 Invite message with the Reason set to value hex "003", as specified in table 7.3.1 that indicates to the ICS UE that the existing CS bearer leg will be used for this call, and there is only one existing CS bearer leg between the ICS UE and the MSC/MGCF, the ICS UE shall behave as specified in subclause 6.2.1.2.2 with the following addition:

1) interpret the received I1 Invite message with the Reason set to value hex "003" as a request to use the existing CS bearer leg for this call; and

2) ignore the SCC AS PSI DN, if included in the I1 Invite message received from the SCC AS, i.e. the ICS UE shall not initiate a call toward the CS domain.

NOTE 1: The ICS UE will not initiates the call setup toward the CS domain for the purpose of setting up a new CS bearer leg, since the existing CS bearer leg will be used for the call being established.

Subsequently, the ICS UE shall allert the user and generate an I1 Progress message with Progress reason set to 180 and send it towards the SCC AS, as specified in subclause 6.2.1.2.2.

If the user accepts the call, the ICS UE shall generate an I1 Success message and send it towards the SCC AS, as specified in subclause 6.2.1.2.2.

6.2.6.3.2 Detailed behaviour of SCC AS

Prior to initiating the establishment of an I1 session toward the ICS UE as described in this subclause, the SCC AS ensures that there is only one existing CS bearer leg between the ICS UE and the MSC/MGCF. If there is either none or more than one existing CS bearer leg between the ICS UE and the MSC/MGCF, the SCC AS shall not initiate the establishment of an I1 session toward the ICS UE as described in this subclause.

When the SCC AS, upon receiving an initial SIP INVITE request from the remote UE destined for the served ICS UE, wants to establish a new I1 session toward the ICS UE that uses an existing CS bearer leg between the ICS UE and the MSC/MGCF, the SCC AS shall send an I1 Invite message toward the ICS UE. The SCC AS shall populate the I1 Invite message as specified in subclause 6.2.1.2.23.2.1 with the following additions:

1) set the Reason in the I1 Invite message to value hex "003", as specified in table 7.3.1. This value indicates to the ICS UE that the existing CS bearer leg will be used for this call;

2) not include the SCC-AS-id information element that contains an allocated SCC AS PSI DN in the I1 Invite message; and

3) send a SIP re-INVITE request toward the CS domain (i.e. MSC/MGCF) that contains an SDP offer received in a SIP INVITE request from remote UE.

When the SCC AS received an I1 Progress with Progress reason set to 180 from the UE, the SCC AS shall send a SIP 180 (Ringing) response to the remote UE.

When the SCC AS receives SIP 200 (OK) response from the CS domain that contains an SDP answer and an I1 Success message from the ICS UE, the SCC AS shall send a SIP 200 (OK) response to the remote UE that contains an SDP answer received from the CS domain. At this stage the SCC AS considers the I1 session as being established and an end-to-end bearer being set up (i.e. the CS call leg as being assigned to this I1 session).

6.3 Supplementary services control procedures

6.3.0 Introduction

The I1 protocol provides a method for a UE and SCC AS to control supplementary services the following ways:

1) Once the UE invokes a mid-call supplementary service from the MSC (via the CS bearer leg) using existing the CS procedures for a call that was previously established without using either the Gm or the I1 interfaces, then for all subsequent calls the UE and SCC AS shall invoke the mid-call supplementary services from the MSC (via the bearer leg) using existing the CS procedures, until all calls have been cleared.

2) Once the UE and the SCC AS invoke a mid-call supplementary service using the I1 protocol for a call that was previously established via the CS bearer leg without using either the Gm or the I1 interfaces, and the I1 call control is maintained (the control is not transferred to Gm interface), then for all subsequent calls that are established without using either the Gm or the I1 interfaces, the UE and SCC AS shall invoke the mid-call supplementary services using the I1 protocol, until all calls have been cleared.

3) If an existing call was previously established via the CS bearer leg using the I1 interface and call control is via the I1 interface, the UE and SCC AS shall then mid-call supplementary service shall be invoked using I1 protocol.

4) If the UE and the SCC AS invoke a mid-call supplementary service for a call that was established via the CS bearer leg using the Gm reference point, and if (due to service continuity procedures) the call control is transferred to the I1 control, then the I1 protocol may be used to provide subsequent mid-call supplementary services for this call (e.g. a voice call that was placed on hold using Gm interface may be resumed using the I1 interface).

5) If the UE and the SCC AS invoke a mid-call supplementary service using the I1 protocol, and if (due to service continuity procedures) the call control is transferred to the Gm interface, then the Gm interface may be used to provide subsequent mid-call supplementary services for this call (e.g. a voice call that was placed on hold using the I1 protocol may be resumed using the I1 interface).

6.3.1 Line ID Services (OIP, OIR, TIP, TIR)

6.3.1.1 Originating Identity Presentation (OIP)

The procedures in subclause 6.2.1.2.1 apply. The From-id information element is used to present the originating identity.

6.3.1.2 Originating Identity Restriction (OIR)

The procedures in subclause 6.2.1.2.1 apply with following addition:

1) a Privacy information element that indicates the ICS UE wants to restrict the presentation of the originating identity.

6.3.1.3 Terminating Identity Presentation (TIP)

The procedures of sending an I1 Success message towards the orginating UE in subclause 6.2.1.3.1 apply with following addition:

1) a To-id information element that includes either a SIP URI or an E.164 number, and will be used to present the terminating identity.

6.3.1.4 Terminating Identity Restriction (TIP)

The procedures of sending an I1 Success message towards the orginating UE in subclause 6.2.1.3.1 apply without a To-id information element.

6.3.2 Communication diversion services (CDIV)

6.3.2.1 Communication Forwarding Unconditional (CFU)

No specific I1 related messages.

6.3.2.2 Communication Forwarding on Not Logged-in (CFNL)

No specific I1 related messages.

6.3.2.3 Communication Forwarding Busy (CFB)

If the ICS UE receives an I1 Invite message from the SCC AS, and the UE determines that the user is busy, the ICS UE shall:

1) generate an I1 Failure message that includes:

a) a Message Type set to indicate that this is an I1 Failure message;

b) a new value in the Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2. The Call-Identifier will uniquely identify this I1 session between the ICS UE and the SCC AS;

NOTE 1: A new value in the Call-Identifier (Part-1) subfield is inserted only if this is the first I1 message sent to the SCC AS. Otherwise the previously set Call-Identifier value is used.

c) increment the stored message sequence value, store it, and include it in the Sequence-ID; and

d) set the Error-Code information element to 486; and

2) send the I1 Failure message towards the SCC AS over the transport layer connection over which the I1 Invite message was received.

6.3.2.4 Communication Forwarding No Reply (CFNR)

No specific I1 related messages.

6.3.2.5 Communication Forwarding on Subscriber Not Reachable (CFNRc)

If the ICS UE receives an I1 Invite message from the SCC AS, and the UE determines that the user is busy, the ICS UE shall:

1) generate an I1 Failure message that includes:

a) a Message Type set to indicate that this is an I1 Failure message;

b) a new value in the Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2. The Call-Identifier will uniquely identify this I1 session between the ICS UE and the SCC AS;

NOTE 1: A new value in the Call-Identifier (Part-1) subfield is inserted only if this is the first I1 message sent to the SCC AS. Otherwise the previously set Call-Identifier value is used.

c) increment the stored message sequence value, store it, and include it in the Sequence-ID; and

d) set the Error-Code information element to 480; and

2) send the I1 Failure message towards the SCC AS over the transport layer connection over which the I1 Invite message was received.

6.3.2.6 Communication Deflection (CD)

If the ICS UE receives an I1 Invite message from the SCC AS, and the UE determines that deflect the call, the ICS UE shall:

1) generate an I1 Redirection message that includes:

a) a Message Type set to indicate that this is an I1 Failure message;

b) a new value in the Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2. The Call-Identifier will uniquely identify this I1 session between the ICS UE and the SCC AS;

NOTE 1: A new value in the Call-Identifier (Part-1) subfield is inserted only if this is the first I1 message sent to the SCC AS. Otherwise the previously set Call-Identifier value is used.

c) increment the stored message sequence value, store it, and include it in the Sequence-ID; and

d) To-id information element set to either a SIP URI or an E.164 of the C-party identity; and

2) send the I1 Redirection message towards the SCC AS over the transport layer connection over which the I1 Invite message was received.

6.3.2.7 Communication Diversion Notification (CDIVN)

If the SCC AS wants to notify the ICS UE that the call was diverted, the SCC AS shall:

1) generate an I1 Notify message that includes:

a) a Message Type set to indicate that this is an I1 Notify message;

b) increment the stored message sequence value, store it, and include it in the Sequence-ID; and

c) a Mid-call information element that indicates that the call was diverted; and

2) send the I1 Notity message towards the ICS UE over the transport layer connection over which other I1 message was received.

6.3.3 Communication Barring

No specific I1 related messages.

6.3.4 Communication Hold (HOLD)/Resume

6.3.4.1 Actions at the ICS UE

When the ICS UE wants to hold/resume an I1 session using an I1reference point, the UE shall:

1) generate an I1 Mid call Request message that includes:

a) a Message Type set to the value that indicates that this is an I1 Mid call Request message, as specified in table 7.3.1;

b) increment the stored message sequence value, store it, and include it in the Sequence-ID field; and

c) set the Mid-call information element that indicates the ICS UE wants to either hold or resume the I1 session as specified in table 7.4.2.12.1; and

2) forward the I1 Mid call Request message toward the SCC AS.

Upon receiving an I1 Success message from the SCC AS, the ICS UE shall consider that the I1 session has been either placed on hold or resumed, as requested.

If the ICS UE receiving an I1Mid call Request message with the Mid-call infromation element, that indicates that the I1 session was either placed on hold or resumed, the ICS UE shall:

1) store the information received in the I1 Mid call Request message;

2) generate an I1 Success message containing the following information:

a) a Message type field set to the value that indicates that is an I1 Success message;

b) the stored Call-ID header value;

c) add one to the stored Sequence-ID field value. Store it, and include it in the Sequence-ID header value; and

3) send the I1 Success message towards the SCC AS over the transport layer connection over which the I1 Mid Call Request message was received.

6.3.4.2 Actions at the SCC AS

Upon receiving an I1Mid call Request message with a Mid-call infromation element, that indicates the I1 session to be either held or resumed, from the ICS UE via the I1 reference point, the SCC AS shall:

1) store the information received in the I1 Mid call Request message;

2) perform the standard SIP procedures toward the far end and the MGCF in order to either inactive or active the RTP media.

Upon remote UE accepting the inactivation or activation of the RTP media, the SCC AS shall:

1) generate an I1 Success message containing the following information:

a) a Message type field set to the value that indicates that is an I1 Success message;

b) the stored Call-ID header value;

c) add one to the stored Sequence-ID field value. Store it, and include it in the Sequence-ID header value; and

2) send the I1 Success message towards the originating ICS UE over the transport layer connection over which the I1 Mid Call Request message was received.

When the SCC AS wants to hold/resume an I1 session using an I1reference point, the SCC AS shall:

1) inactivating or activating the RTP media by performing the standard SIP procedures toward the far end and the MGCF);

2) generate an I1 Mid call Request message that includes:

a) a Message Type set to the value that indicates that this is an I1 Mid call Request message, as specified in table 7.3.1;

b) increment the stored message sequence value, store it, and include it in the Sequence-ID field; and

c) set the Mid-call information element that indicates the I1 session was either placed on hold or resumed;

3) forward the I1 Mid call Request message toward the ICS UE.

Upon receiving an I1 Success message from the ICS UE, the SCC AS shall consider that the I1 session has been either placed on hold or resumed, as requested.

6.3.5 Consultative Explicit Communication Transfer

6.3.5.1 Actions at the ICS UE

When ICS UE A is playing the role of transfer, the ICS UE shall:

1) generate an I1 Refer message that includes:

a) a Message Type set to indicates that this is an I1 Refer message;

b) increment the stored message sequence value, store it, and include it in the Sequence-ID; and

c) a Refer-to information element that includes either a SIP URI or an E.164 number that contains the identity of the transferred to party; and

2) forward the I1 Refer message toward the SCC AS.

When the ICS UE receives an I1 Success message, the UE shall:

1) verify if a I1 session exists for the received Call-Identifier value;

2) verify if a the message is in sequence according to the message sequence number value contained in the Sequence-ID information element; and

3) consider the Refer request as successful.

When the ICS UE receives an I1 BYE message, the UE shall:

1) verify if a I1 session exists for the received Call-Identifier value;

2) verify if a the message is in sequence according to the message sequence number value contained in the Sequence-ID information element; and

3) release the session as defined in subclause 6.2.3.2.

6.3.5.2 Actions at the SCC AS

Upon receiving an I1Refer request message with a Refer-to informtion element indicating this is a refer invitation from the ICS UE via the I1 reference point, the SCC AS shall continue session establishment towards the referred to party as identified in the Refer-to information element as specified in 3GPP TS 24.173 [18].

Upon receiving a SIP 200 OK response from the referred to party, the SCC AS shall:

1). generate an I1 Success message containing the following information:

a) a Message Type set to indicate that is an I1 Success message; and

b) a Call-Identifier field containing the Call-Identifier value that uniquely identifies this I1 session between the UE and SCC AS;

2) add one to the stored message sequence value. Store and include the Sequence-ID; and

3) send the I1 Success message towards the originating UE over the transport layer connection over which the I1 Refer request message was received; and

4) send an I1 Bye message to the ICS UE on the respective I1 session for purposes of completing the transfer, the SCC AS shall follow the procedures in subclause 6.2.3.3.3 of this document for session release.

6.3.6 Conference calling (CONF)

6.3.6.0 General

The conference calling (CONF) service consists of conference creation, joining a conference, inviting others to join a conference and leaving a conference, as described in 3GPP TS 24.147 [21] and 3GPP TS 24.605 [22].

6.3.6.1 Actions at the ICS UE

6.3.6.1.1 Conference creation with a conference factory URI

When the ICS UE is creating a conference, the ICS UE shall send an I1 Invite message as described in subclause 6.2.1.1 with the following differences:

a) To-id information that includes the E.164 identity that corresponds to the Conference factory URI.

Upon receipt of the I1 Success message, as described in subclause 6.2.1.2.1.4 with the following differences:

1) a Conference-id element that includes the SIP URI or an E.164 identity that corresponds to the identity of the conference focus.

the ICS UE is considered to have joined the conference, in the same manner as receipt of a SIP 200 (OK) response is treated in the procedures described in 3GPP TS 24.147 [21].

6.3.6.1.2 Inviting other users to a conference

When ICS UE is inviting others to join a conference, the ICS UE shall:

1) generate an I1 Refer message that includes:

a) a Message type set to indicate that this is an I1 Refer message;

a1) a new value in the Call-Identifier field (Part-1), as specified in subclause 7.2.2.1.4. The Call-Identifier will uniquely identify this I1 session between the ICS UE and the SCC AS;

b) a Sequence-ID information element, that includes a message sequence value, having first added one to the stored value, and stored it again;

c) a To-id information element that includes the SIP URI or an E.164 identity of the party to be invited to the conference;

c1) a From-id information element that:

– if the UE has previously SIP registered and the public user identity is to be a SIP URI and the public user identity can be derived (see annex A) then:

– otherwise the Code specific field of the From-id Information information element is set to:

i) a "SIP URI" (see table 7.4.2.3.1-2) if the public user identity is a SIP URI and the Information body (see table 7.3.2.2) containing the SIP URI;

c2) a Refer-to information element that contains the the SIP URI or an E.164 identity that corresponds to the identity of the conference focus.and

d) a Replaces information element is optionally included, as described for the equivalent usage of the Replaces header field in subclause 4.5.2.1.2 of 3GPP TS 24.605 [22]; and

2) forward the I1 Refer message toward the SCC AS.

When the ICS UE receives an I1 Success message, the UE shall:

1) verify if a I1 session exists for the received Call-Identifier value;

2) verify if a the message is in sequence according to the message sequence number value contained in the Sequence-ID information element; and

3) consider the invitation for another party to join the conference as successful.

6.3.6.1.3 User joining a conference by using a conference URI

The ICS UE shall send an I1 Invite message as described in subclause 6.2.1.1 with the following differences:

a) To-id information that includes the SIP URI or E.164 identity that corresponds to the conference URI.

NOTE: The conference participants can get the conference URI as described in subclause 5.3.1.4.2. Other mechanisms can also be used by the conference participant to become aware of the conference URI, but they are out of scope of this specification..

Upon receipt of the I1 Success message as described in subclause 6.2.1.2.1.4 with the following differences:

1) a Conference-id element that includes the SIP URI or an E.164 identity that corresponds to the identity of the conference focus.

the ICS UE is considered to have joined the conference, in the same manner as receipt of a SIP 200 (OK) response is treated in the procedures described in 3GPP TS 24.147 [21].

6.3.6.1.4 Conference participant leaving a conference

When the ICS user would like to leave the conference, the ICS UE shall generate an I1 Bye message as described in subclause 6.2.3.2.1 with the following exceptions:

a) set the Call-Identifier field to a value that identifies the I1 session between the ICS UE and SCC AS that was used to create or join the conference.

6.3.6.1.5 Conference focus removes conference participant from a conference

Upon receiving an I1 BYE from the SCC AS, where the Call-Identifier field identifies the I1 session between the ICS UE and SCC AS that was used to create or join the conference, the conference participant shall

a) perform the actions as described in subclause 6.2.3.2.2; and

assume the conference to be terminated.

6.3.6.2 Actions at the SCC AS

6.3.6.2.1 Conference creation with a conference factory URI

Upon receiving an I1 Invite message from the ICS UE on the respective I1 session for the purposes of conference creation, the SCC AS shall follow the procedures in subclause 6.2.1.3.1of this document for session origination with the following additions:

a) If the SCC AS receives a 200 (OK) response to the INVITE request with the "isfocus" feature parameter indicated in Contact header, the contents of the" isfocus" feature parameter shall be include in a Conference-id element sent to the ICS UE as described in subclause 6.2.1.3.1.5.

NOTE: The conference focus AS will provide the conference creation functions described in subclause 5.3.2.3 of 3GPP TS 24.147 [21].

6.3.6.2.2 Inviting other users to a conference

Upon receiving an I1Refer message from the ICS UE on the respective I1 session, the SCC AS shall:

1) generate a SIP REFER request towards the address received in the I1 Refer Refer-to information element as specified in subclause 6.3.5.2.

6.3.6.2.3 Conference participant leaving a conference

Upon receipt of an I1 Bye message from the ICS UE via on the respective I1 session for purposes of leaving a conference, the SCC AS shall follow the procedures in subclause 6.2.3.3.3 of this document for session release.

6.3.7 Communication Waiting

6.3.7.1 Actions at the ICS UE

Upon receipt of an I1 Invite with a Reason Value set to 0x005 (CW), the ICS UE shall follow the procedure described in subclause 4.5.5.3.2 of 3GPP TS 24.615 [23], treating the I1 Invite with a Reason value of 0x005 (CW) in the same way as receipt of a SIP INVITE request with an XML body and a Content-Type header field set to "application/vnd.3gpp.cw+xml".

For Case A of subclause 4.5.5.3.3 of 3GPP TS 24.615 [23], the ICS UE shall send a I1 Success message to indicate an answer of the waiting communication. The ICS UE shall follow explicit procedures to hold or release the active session while doing so. For Case B, of subclause 4.5.5.3.3 of 3GPP TS 24.615 [23], the ICS UE shall send an I1 Failure message with the Error-Code information element set to the equivalent of 480 to indicate that the user has not answered the waiting communication.

6.3.7.2 Actions at the SCC AS

Upon receipt of a SIP INVITE request destined for an ICS UE with an XML body and a Content-Type header field set to "application/vnd.3gpp.cw+xml" as described in subclause 4.5.5.2 of 3GPP TS 24.615 [23], the SCC AS shall send the I1 Invite message as specified in subclause 6.2.1.3.2 or subclause 6.2.1.3.3 of this document with an I1 Invite Reason value set to 0x005 (CW).

6.4 SCC AS and ICS UE Time Synchronization

6.4.1 General

In order to detect stale I1 messages transmitted when non-real time transport layer protocols are used, the ICS UE and SCC AS must be synchronized in time. The staleness of the I1 messages can be determined by the following two steps:

1) The ICS UE originates initial time synchronization procedure with the SCC AS. During this procedure both ICS UE and SCC AS receive an initial time of the peer. The time value is measured in seconds. The initial time value is not important as long as the subsequent time measurements are increased accordingly; and

2) An I1 message receiver (ICS UE or SCC AS) compares the time received in an I1 message i.e. the current time of the peer with the initial time established in step 1, and based on the time difference between the current and initial time it makes a decision about the staleness of the message. If the message is stale it shall be discarded and no response generated to the I1 message.

6.4.2 Generating Time

The initial time value can be initialized using one of the following methods:

i) a local time of the machine or terminal;

ii) a randomly generated time; and

ii) zero.

6.4.3 Detailed behaviour of ICS UE

If time synchronization is supported by the UE (i.e. when the I1 messages are transmitted over non-real time transports) the time synchronization procedure shall be initiated by the ICS UE after the non-real time transport layer connection is established. The time synchronization procedure with the SCC AS may be repeated by the ICS UE, if required and supported.

6.4.3.1 ICS UE Synchronization Origination

When the ICS UE initiates the synchronization procedure using an I1reference point, the UE shall:

1) generate an I1 Notify message that includes:

a) a Message Type set to indicate that this is an I1 Notify message and Reason field in the I1 Notify message set to value hex "001", that indicates that the I1 Notify message is used for synchronization, as specified in table 7.3.1;

b) a new value in the Call-Identifier field (Part-1), as specified in subclause 7.2.2. The Call-Identifier value will uniquely identify this I1 session between the ICS UE and the SCC AS;

c) an allocated Sequence-ID;

d) a From-id information element that includes either a SIP URI or an E.164 number, and it will be used by the SCC AS to identify the ICS UE; and

e) a Timestamp information element that includes the initial time generated according to the subclause 6.4.2. The element will be used by the SCC AS to validate the ICS UE I1 messages. The Timestamp value is stored by the ICS UE.

2) select the transport layer protocol (see subclause 4.2.3) depending on the access network type, and forward the I1 Notify message toward the SCC AS.

When the ICS UE receives an I1 Success message, the UE shall:

3) verify if a I1 session exists for the received Call-Identifier field value;

4) verify if a the message is in sequence according to the value of the Sequence-ID; and

5) retrieve and store the Timestamp information element value received in the response.

If the ICS UE does not receive an I1 Success message or an I1 Failure message within 64*T1 seconds, the UE shall consider the I1 Notify message as failed and it may attempt to perform the synchronization procedure again after an interval of time. However, if the ICS UE receives an I1 Failure message (with Reason valus set to 488, as specified in table 7.3.1) indicateing the the SCC AS does not support the synchronization procedure, the ICS UE shall not attempt to perform the synchronization procedure again.

6.4.4 Detailed behaviour of SCC AS

6.4.4.1 SCC AS Synchronization Termination

Upon receiving an I1 Notify message with Reason field in the I1Notify message set to value hex "001", as specified in table 7.3.1, from the ICS UE via the I1 reference point, the SCC AS shall either:

A) respond with an I1 Failure message (with Reason valus set to 488, as specified in table 7.3.1), if the SCC AS does not support the synchronization procedure; or

B) if the SCC AS supports the synchronization procedure:

1) retrieve the ICS UE time value from the Timestamp information element of the I1 Notify message, and store the value;

2) save the received Call-Identifier field value and Sequence-ID values and use them for further reference to this session;

3) generate an I1 Success message containing the following information:

a) a Message Type set to indicate that is an I1 Success message;

b) a Call-Identifier field with the stored Call-ID field value;

c) add one to the stored message sequence value. Store and include the Sequence-ID;

d) include the Timestamp information element that is generated according to the subclause 6.4.2. The element will be used by the ICS UE to validate the SCC AS I1 messages. The Timestamp value is stored by the SCC AS.

4) send the I1 Success message towards the originating UE over the transport layer connection over which the I1 Notify message was received.