D.5 XML schema for access transfer events

24.2373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuityRelease 17Stage 3TS

D.5.1 General

This subclause defines XML schema and MIME type for transport of events related to access transfer of a session.

D.5.2 XML schema

<?xml version="1.0"?>

<xs:schema

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

elementFormDefault="qualified"

attributeFormDefault="unqualified">

<xs:element name="events" type="eventsType"/>

<xs:complexType name="eventsType">

<xs:sequence>

<xs:element name="event" type="eventType" maxOccurs="unbounded"/>

</xs:sequence>

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

</xs:complexType>

<xs:complexType name="eventType">

<xs:sequence>

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

</xs:sequence>

<xs:attribute name="event-type" type="xs:unsignedInt"/>

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

</xs:complexType>

<xs:element name="STNResp-params" type="STNResp-paramsType"/>

<xs:complexType name="STNResp-paramsType">

<xs:sequence>

<xs:element name="transfer-details" type="xs:base64Binary"/>

<xs:element name="redirect-speech" type="xs:boolean"/>

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

</xs:sequence>

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

</xs:complexType>

</xs:schema>

D.5.3 Semantic

D.5.3.1 General

The <events> element is the root element of the XML document and contains one or more <event> elements.

Each <event> element describes one event occuring in session and:

1) contains the "event-type" attribute which indicates the event type; and

2) can contain subelements related to the event type indicated by the "event-type" attribute.

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

The following applies for the "event-type" attribute of the <event> element:

– sender of the XML does not set the "event-type" attribute to any value other than those described in this section; and

– recipient of the XML ignores the <event> element with "event-type" attribute containing a value other than those described in this section.

Recipient of the XML ignores any unknown element and any unknown attribute.

D.5.3.2 Requirements for individual events

If the "event-type" attribute of the <event> element is 1, then the <event> element indicates the session transfer notification request.

If the "event-type" attribute of the <event> element is 2, then the <event> element indicates the session transfer notification response and the <event> element contains the <STNResp-params> element. The <STNResp-params> element contains <transfer-details> element and the <redirect-speech> element. The <transfer-details> element contains the content according to subclause D.5.3.3. The <redirect-speech> element indicates whether the ATCF requires the MSC server to redirect the speech media component of the session transferred by the CS to PS SRVCC access transfer.

NOTE 1: Binary data are encoded according to the XML type base64Binary.

NOTE 2: MIME body with the "event-type" attribute of the <event> element equal to 2 is provided after receiving the MIME body with the "event-type" attribute of the <event> element equal to 1.

If the "event-type" attribute of the <event> element is 3, then the <event> element indicates the session transfer preparation.

NOTE 3: MIME body with the "event-type" attribute of the <event> element equal to 3 is provided after receiving the MIME body with the "event-type" attribute of the <event> element equal to 2.

If the "event-type" attribute of the <event> element is 4, then the <event> element indicates the session transfer cancellation.

NOTE 4: MIME body with the "event-type" attribute of the <event> element equal to 4 is provided either after receiving the MIME body with the "event-type" attribute of the <event> element equal to 2 or after providing the MIME body with the "event-type" attribute of the <event> element equal to 3.

D.5.3.3 ATGW transfer details

The ATGW transfer details indicate the ATGW media configuration to be used by SC UE when sending the speech media of the session transferred by the CS to PS SRVCC access transfer.

The ATGW transfer details are encoded in the structure shown in the figure D.5.3.3-1 and table D.5.3.3-1.

8

7

6

5

4

3

2

1

Reserved

Reserved

Reserved

Reserved

Reserved

Reserved

ATGW transfer details content type

octet 1

ATGW transfer details content

octet 2
octet v

Figure D.5.3.3-1: ATGW transfer details structure

Table D.5.3.3-1: ATGW transfer details structure

In this version of specification, the sender sets the Reserved field to zero and the recipient ignores the Reserved field.

The ATGW transfer details content type field indicates type of the ATGW transfer details content. Bit 2 of the ATGW transfer details content type field contains the most significant bit.

In this version of the specification, the following ATGW transfer details content type values are specified:

– 0 (ATGW-IPv4-address-and-port);

– 1 (ATGW-IPv6-address-and-port).

– 2 (ATGW-not-available).

When the ATGW transfer details content type field indicates value other than those specified in this version of the specification, the ATGW Transfer details content field is ignored by the recipient. The sender sets the ATGW transfer details content type field only to a value specified in this version of the specification.

When the ATGW transfer details content type field indicates ATGW-IPv4-address-and-port, the ATGW Transfer details content field is structured as in figure D.5.3.3-2 and table D.5.3.3-2.

When the ATGW transfer details content type field indicates ATGW-IPv6-address-and-port, the ATGW Transfer details content field is structured as in figure D.5.3.3-3 and table D.5.3.3-3.

When the ATGW transfer details content type field indicates ATGW-not-available, the ATGW Transfer details content field is not included.

8

7

6

5

4

3

2

1

ATGW UDP port

octet 2
octet 3

ATGW IPv4 address

octet 4

:
octet 7

Extensions

octet 8
:
octet v

Figure D.5.3.3-2: ATGW transfer details content structure when the ATGW transfer details content type field indicates ATGW-IPv4-address-and-port

Table D.5.3.3-2: ATGW transfer details content structure when the ATGW transfer details content type field indicates ATGW-IPv4-address-and-port

The ATGW UDP port field indicates the ATGW UDP port to be used by SC UE to send the speech media of the session transferred by the CS to PS SRVCC access transfer. Bit 8 of the first octet of the ATGW UDP port field contains the most significant bit and bit 1 of the second octet of the ATGW UDP port field contains the least significant bit.

The ATGW IPv4 address field indicates the ATGW IPv4 address to be used by SC UE to send the speech media of the session transferred by the CS to PS SRVCC access transfer. Bit 8 of the first octet of the ATGW IPv4 address field contains the most significant bit and bit 1 of the fourth octet of the ATGW IPv4 address field contains the least significant bit.

In this version of specification, the sender does not include the Extensions field and the recipient ignores the Extensions field. See NOTE.

NOTE: Inclusion of Extensions field enlarges the access stratum handover command, which can result in longer duration of handover procedure and in message being larger than maximum size of the access stratum messages. Thus, inclusion of Extensions field is not recommended.

8

7

6

5

4

3

2

1

ATGW UDP port

octet 2
octet 3

ATGW IPv6 address

octet 4

:
octet 19

Extensions

octet 20
:
octet v

Figure D.5.3.3-3: ATGW transfer details content structure when the ATGW transfer details content type field indicates ATGW-IPv6-address-and-port

Table D.5.3.3-3: ATGW transfer details content structure when the ATGW transfer details content type field indicates ATGW-IPv6-address-and-port

The ATGW UDP port field indicates the ATGW UDP port to be used by SC UE to send the speech media of the session transferred by the CS to PS SRVCC access transfer. Bit 8 of the first octet of the ATGW UDP port field contains the most significant bit and bit 1 of the second octet of the ATGW UDP port field contains the least significant bit.

The ATGW IPv6 address field indicates the ATGW IPv6 address to be used by SC UE to send the speech media of the session transferred by the CS to PS SRVCC access transfer. Bit 8 of the first octet of the ATGW IPv6 address field contains the most significant bit and bit 1 of the sixteenth octet of the ATGW IPv6 address field contains the least significant bit.

In this version of specification, the sender does not include the Extensions field and the recipient ignores the Extensions field. See NOTE.

NOTE: Inclusion of Extensions field enlarges the access stratum handover command, which can result in longer duration of handover procedure and in message being larger than maximum size of the access stratum messages. Thus, inclusion of Extensions field is not recommended.

D.5.4 IANA registration template

Your Name:

<MCC name>

Your Email Address:

<MCC email address>

Media Type Name:

Application

Subtype name:

vnd.3gpp.access-transfer-events+xml

Required parameters:

None

Optional parameters:

"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in section 9.1 of IETF RFC 7303.

"et" when the MIME type is included in the Accept header field, the "et" parameter value is a comma delimited list of the values of the "event-type" attribute of the <event> element of the <events> root element which the sender of the Accept header field is able to receive. The <events> root element is defined by XML schema described in the Published specification.

Encoding considerations:

binary.

Security considerations:

Same as general security considerations for application/xml media type as specified in section 9.1 of IETF RFC 7303. In addition, this media type provides a format for exchanging information in SIP, so the security considerations from IETF RFC 3261apply.

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

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

This media type does not include provisions for directives that institute actions on a recipient’s files or other resources.

This media type does not include provisions for directives that institute actions that, while not directly harmful to the recipient, may result in disclosure of information that either facilitates a subsequent attack or else violates a recipient’s privacy in any way.

This media type does not employ compression.

Interoperability considerations:

Same as general interoperability considerations for application/xml media type as specified in section 9.1 of IETF RFC 7303. Any unknown XML elements and any unknown XML attributes are to be ignored by recipient of the MIME body.

Published specification:

3GPP TS 24.237 "IP Multimedia Subsystem (IMS) Service Continuity", version 13.1.0, available via http://www.3gpp.org/specs/numbering.htm.

Applications which use this media type:

Applications supporting the service continuity as described in the published specification.

Fragment identifier considerations:

The handling in section 5 of IETF RFC 7303 applies.

Restrictions on usage:

None

Provisional registration? (standards tree only):

N/A

Additional information:

1. Deprecated alias names for this type: none

2. Magic number(s): none

3. File extension(s): none

4. Macintosh File Type Code(s): none

5. Object Identifier(s) or OID(s): none

Intended usage:

Common

Person to contact for further information:

– Name: <MCC name>

– Email: <MCC email address>

– Author/Change controller:

i) Author: 3GPP CT1 Working Group/3GPP_TSG_CT_WG1@LIST.ETSI.ORG

ii) Change controller: <MCC name>/<MCC email address>