5 Extensions within the present document

24.3903GPPRelease 17Stage 3TSUnstructured Supplementary Service Data (USSD) using IP Multimedia (IM) Core Network (CN) subsystem IMS

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

5.1 INFO Package for transport of USSD information

5.1.1 Scope

This subclause contains the information required for the IANA registration of info package g.3gpp.ussd in accordance with IETF RFC 6086 [2].

5.1.2 g.3gpp.ussd info package

5.1.2.1 Overall description

3GPP TS 24.390 describes the procedures for using Unstructured Supplementary Service Data (USSD) (3GPP TS 24.090 [3] and 3GPP2 X. S0065 [4]) operations in the IP Multimedia Core Network Subsystem (IMS). SIP INFO requests are used to carry information associated with USSD, using the g.3gpp.ussd info package.

Every SIP INFO request associated with the g.3gpp.ussd info package carries a single application/vnd.3gpp.ussd+xml MIME body associated with the info package according to IETF RFC 6086 [2].

NOTE: According to the procedures in IETF RFC 6086 [2], the SIP INFO response will not contain a MIME body. A message associated with a USSD operation is always sent in SIP INFO request.

In a given dialog, when a UA sends an INFO request associated with the g.3gpp.ussd info package, then until receiving an INFO request associated with the g.3gpp.ussd info package, the UA does not send another INFO request associated with the g.3gpp.ussd info package.

5.1.2.2 Applicability

A number of solutions were discussed for the transportation of USSD information between the UE and the USSD AS. The solutions were:

1) use of subscription to the USSD event package as specified in IETF RFC 4575;

2) use of the session related methods (e.g. SIP 200 (OK) response to the SIP INVITE request);

3) use of the SIP MESSAGE method;

4) use of media plane mechanisms; and

5) use of the SIP INFO method as described in IETF RFC 6086, by defining a new info package.

Furthermore, each of the solutions 1), 2), 3), 4) and 5) were evaluated.

The use of a USSD event package was discounted as the usage of subscribe/notify mechanism for two-way communication is not appropriate since subscribe/notify mechanism is to provide one-way communication consisting of notifications from notifier to subscriber indicating that certain events in notifier have occurred.

The use of session related methods for USSD messages other than the initial USSD message and last USSD message was discounted as it was concluded that usage of UPDATE method for transport of USSD message would have side effect of impacting dialog configuration (e.g. possibly changing the remote contact URI).

Use of the SIP MESSAGE method was discounted since USSD is dialog based and all information exchange has to be part of the related session.

Use of the media plane mechanisms was discounted because the amount of USSD messages in a dialog is normally very small (normally only 2) and overhead caused by user plane setup (e.g. if MSRP is used as transport) would be disproportionately big in comparion to the actual USSD message size.

Based on the above analyses, the SIP INFO method was chosen to transport the USSD information between the UE and the USSD AS.

5.1.2.3 Info package name

g.3gpp.ussd

5.1.2.4 Info package parameters

None defined.

5.1.2.5 SIP options tags

None defined.

5.1.2.6 INFO message body parts

The MIME type of the message body carrying the information associated with USSD is application/vnd.3gpp.ussd+xml. application/vnd.3gpp.ussd+xml MIME type is defined in 3GPP TS 24.390.

When associated with the g.3gpp.ussd info package, the Content-Disposition value of the message body carrying the information associated with USSD is "info-package".

5.1.2.7 Info package usage restrictions

None defined.

5.1.2.8 Rate of INFO Requests

No maximum rate or minimum rate is defined for sending INFO requests associated with the g.3gpp.ussd info package.

For most USSD usages, normally zero, one, or a few, SIP INFO requests are generated in the SIP session by each participating user agent.

5.1.2.9 Info package security considerations

The security is based on the generic security mechanism provided for the underlying SIP signalling. No additional security mechanism is defined.

5.1.2.10 Implementation details and examples

UAC generation of INFO requests: See 3GPP TS 24.390:" Unstructured Supplementary Service Data (USSD) using IP Multimedia (IM) Core Network (CN) subsystem IMS; Stage 3"

Examples: See 3GPP TS 24.390: " Unstructured Supplementary Service Data (USSD) using IP Multimedia (IM) Core Network (CN) subsystem IMS; Stage 3"

5.1.3 application/vnd.3gpp.ussd+xml MIME type

5.1.3.1 Scope

This subclause contains the information required for the IANA registration of the application/vnd.3gpp.ussd+xml MIME type in accordance with IANA registration procedures.

5.1.3.2 application/vnd.3gpp.ussd+xml

The MIME type is used to carry USSD related information between the UE and the network. It is coded as an XML document and contains one or more of the following information:

– USSD language

– USSD string

– USSD error code as defined in subclause 5.1.3.3 of this specification

– alerting pattern

NOTE: The information elements cannot be present twice in the XML body.

An instance of the XML document is shown below:

<?xml version="1.0" encoding="UTF-8"?>

<ussd-data>

<ussd-string>*135#</ussd-string>

</ussd-data>

5.1.3.3 Data semantics

<language> is coded as defined in IETF RFC 5646 [12] and shall contain exactly one subtag.

<ussd-string> is coded as a string.

<error-code> is an integer. The following values are defined. If the received value is not listed below, it must be treated as 1.

1 error – unspecified

2 language/alphabet not supported

3 unexpected data value

4 USSD-busy

<anyExt> contains optional extension elements.

<UnstructuredSS-Request> element indicates the network initiated unstructured supplementary service data request.

<UnstructuredSS-Notify> element indicates the network initiated unstructured supplementary service data notify.

<alertingPattern> element contains alerting pattern coded as defined for AlertingPattern in 3GPP TS 29.002 [15]. This element is used by the USSD application in the UE to alert the user in a specific manner in the case of the network initiated USSD request and the network initiated USSD notification.

Entity receiving the XML body ignores any unknown XML element and any unknown XML attribute.

NOTE 1: "unexpected data value" is used in case of interworking with the MAP protocol (i.e. in case such an error is received from the MAP interface). It is not used for the case where the string sent by the UE in response to a query from the network does not match any expected response. Procedures covering such cases are part of the USSD application handling. The application will usually send back another USSD string to the UE asking for a new input from the user or indicating that the transaction cannot be completed.

NOTE 2: Alerting pattern is application level information which can be present in any network initiated USSI message, including both the initial network initiated USSI message and any later network initiated USSI message, sent in the same USSD dialog as the initial network initiated USSI message. The Alert-Info header field cannot be used as it is not allowed in SIP INFO request.

5.1.3.4 XML schema

Implementations in compliance with the present document shall implement the XML schema defined below.

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified"

attributeFormDefault="unqualified">

<xs:element name="ussd-data">

<xs:annotation>

<xs:documentation>

Unstructured Supplementary Services Data

</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:element name="language" type="xs:string" minOccurs="0" maxOccurs="1"/>

<xs:element name="ussd-string" type="xs:string" minOccurs="0" maxOccurs="1"/>

<xs:element name="error-code" type="xs:int" minOccurs="0" maxOccurs="1"/>

<xs:element name="anyExt" type="anyExtType" minOccurs="0"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute namespace="##any" processContents="lax"/>

</xs:complexType>

</xs:element>

<xs:complexType name="anyExtType">

<xs:sequence>

<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:element name="UnstructuredSS-Request" type="emptyType"/>

<xs:element name="UnstructuredSS-Notify" type="emptyType"/>

<xs:element name="alertingPattern" type="xs:unsignedByte"/>

<xs:complexType name="emptyType"/>

</xs:schema>

NOTE: The USSI AS can take the information received in the MIME body, formulate a MAP USSD message and route the message over SS7 to the USSD server via the HSS. Alternatively, the USSI AS can extract the USSD information from the received MIME body, and communicate with USSD server using other protocol.

5.1.3.4A Further syntax rules of MIME bodies of application/vnd.3gpp.ussd+xml MIME type

If:

– an <UnstructuredSS-Request> element;

– an <UnstructuredSS-Notify> element; or

– an <alertingPattern> element;

is included in a MIME body of the application/vnd.3gpp.ussd+xml MIME type, the XML element is included in the <anyExt> element included in the <ussd-data> root element.

NOTE: The XML elements are validated by the <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> particle of the <anyExt> element.

5.1.3.5 IANA registration

NOTE: RFC 4288 [9], subclause 9, states the process that applies in case of changes to the registry of media types. Any changes to the format or to subclause 5.1.3.5 after the registration with IANA would invoke this procedure.

5.1.3.5.1 Name

Frederic Firmin

5.1.3.5.2 Email

frederic.firmin@etsi.org

5.1.3.5.3 MIME media type name

Application

5.1.3.5.4 MIME subtype name

Vendor Tree – vnd.3gpp.ussd+xml

5.1.3.5.5 Required parameters

None

5.1.3.5.6 Optional parameters

None

5.1.3.5.7 Encoding considerations

Binary.

5.1.3.5.8 Security considerations

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [10]. In addition, this content type provides a format for exchanging information in SIP, so the security considerations from IETF RFC 3261 [11] apply.

The information transported in this MIME media type does not include active or executable content.

Mechanisms for privacy and intregrity protection of protocol parameters exist. Those mechanisms as well as authentication and further security mechanisms are described in 3GPP TS 24.229 [6].

5.1.3.5.9 Interoperability considerations

The MIME type allows interoperability of USSD information between mobile networks and other systems.

5.1.3.5.10 Published specification

3GPP TS 24.390

(http://www.3gpp.org/ftp/Specs/html-info/24390.htm)

5.1.3.5.11 Applications which use this media

n/a

5.1.3.5.12 Applications that manipulate MIME typed objects (messaging, download etc.)

n/a

5.1.3.5.13 Additional information

1. Magic number(s): n/a

2. File extension(s): n/a

3. Macintosh file type code: n/a

4. Object Identifiers: n/a

5.1.3.5.14 Intended usage

Common.

The USSD is a very common service available on most mobile networks. The registration of the associated MIME type allows the USSD service to be incorporated in messages from other messaging systems.

5.1.3.5.15 Other information/general comment

n/a

5.1.3.5.16 Person to contact for further information

1. Name: Frederic Firmin

2. Email: frederic.firmin@etsi.org

3. Author/Change controller: Frederic Firmin

Annex A (informative):
Signalling flows