4 General description

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

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

4.1 General

For the current version of the specification the application layer protocol is run over Unstructured Supplementary Service Data (USSD) transport as defined in 3GPP TS 24.090 [4], however the application layer protocol is not restricted to USSD transport.

4.2 Structure of the protocol

4.2.1 Introduction

The I1 protocol is a message based point to point protocol. The I1 protocol messages are transported within a point-to-point transport-layer protocol and are exchanged between the ICS UE and SCC AS.

The I1 protocol is a transport-independent protocol, i.e. the I1 session control entities can exchange the I1 protocol messages over any transport-layer protocol that connects the ICS UE and the SCC AS.

The I1protocol’s notation maintains a format of two parts, i.e. I1 message common part and I1 information elements. The I1 message common part is included in every I1 message. The I1 information elements those are included in an I1 message depend on a type of I1 message being sent.

4.2.2 Application level protocol

Overall descriptions with application level protocol are specified as following:

1) it is used to access IMS services (e.g., IMS session origination);

2) it is a point to point protocol between the ICS UE and the SCC AS;

3) its protocol does not support authentication;

4) it does not support segmentation of messages;

5) its messages are self-identifying; and

6) it runs over any point-to-point transport-layer protocol (e.g. USSD).

4.2.3 Transport-layer protocols

4.2.3.1 General

The transport-layer protocol that is used to transfer the I1 protocol messages is a bi-directional point-to-point connection between the ICS UE and the SCC AS. This transport-layer protocol is a symmetric connection, i.e. the source-point on the transport-layer protocol that is used to send the I1 protocol messages is also a destination-point for the incoming I1 protocol messages.

An I1 message shall be contained in one transport protocol message and shall not be segmented across transport message protocol data units. The combination of the length of the information elements in an I1 message shall not exceed the length of the transport protocol message payload.

4.2.3.2 USSD as transport-layer protocol

The USSD provides a point-to-point transport layer connection between the I1 protocol entities. USSD is specified in 3GPP TS 24.090 [4]. When USSD is used for transporting the I1 protocol, the ICS UE and the SCC AS shall set the ussd-DataCodingScheme to "1101", as defined in 3GPP TS 23.038 [19]. For the purposes of this document, USSD is regarded as a real-time reliable transport protocol.

The USSD supports a two-way alternative interactive communication (i.e.semi-duplex communication). At any given time, only one I1 protocol entity (either the ICS UE or the SCC AS) with its turn may send the I1 messages, while at the same time its peer is permitted only to receive the I1 messages. To allow the I1 protocol entity (either the ICS UE or the SCC AS) to send an I1 message to its peer when needed, the initiating entity shall send an I1 message exchange in a single invoke and return result transaction. That is, after the I1 protocol entities have exchanged I1 message(s) in a USSD invoke component and a USSD return result component, the USSD connection are released.

When the USSD is used as the transport layer connection, overall descriptions are specified as following:

1) the initiating entity (either the ICS UE or the SCC AS) shall send a single USSD invoke and the responding entity (either the SCC AS or the ICS UE) shall send a return result;

2) if the responding entity (either the SCC AS or the ICS UE) does not need to send an I1 response in the return result, the responding entity shall send an I1-Dummy message to the peer; and

3) if the I1 session is established, the USSD connection will be released.

For mobile initiated requests, the ICS UE shall use the Process Unstructured SS Request invoke component defined in 3GPP TS 24.090 [4]. The SCC AS shall identify the UE by matching the MSISDN received with the I1 message with the C-MSISDN of the UE. The SCC AS shall send either an I1 response to the I1 message or an I1 Dummy message (if no I1 response is required) in the Process Unstructured SS Request return result.

NOTE: When forwarding the I1 message from the UE to the SCC AS, the HSS includes the optional MSISDN information element along with the mandatory IMSI information element in the Process Unstructured SS Request, as defined in 3GPP TS 23.078 [20].

For network initated requests, the SCC AS shall use either the Unstructured SS Request or the Unstructured SS Notify, as defined in 3GPP TS 23.078 [20] to send an I1 message to the HSS for delivery to the UE. When sending the I1 message to the HSS, the SCC AS shall include within the selected invoke component the MSISDN information element populated with the C-MSISDN for the UE. When the Unstructured SS Notify invoke component is used, no I1 message is included in the return reply because the Unstructured SS Notify return result does not include any information elements. The ICS UE shall include either an I1 response to the I1 message or an I1 Dummy (if no I1 response is required) in the Unstructured SS Request return result.

The I1 Dummy in sent in the USSD return result in response to the following I1 messages in the USSD invoke: I1 Progress, I1 Success, and I1 Failure.