B (Normative)  IP-Connectivity Access Network specific concepts when using GPRS to access IM CN subsystem |R6|  Word‑p. 785

B.1  Scope

The present annex defines IP-CAN specific requirements for a call control protocol for use in the IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP), and the associated Session Description Protocol (SDP), where the IP-CAN is General Packet Radio Service (GPRS). The GPRS IP-CAN has a core network:

• with SGSN connected to GGSN providing a UE with a PDP context for the IM CN subsystem-related signalling and media; or
• with SGSN connected to S-GW and S-GW connected to P-GW providing the UE with a PDP context for the IM CN subsystem-related signalling and media.

The core network can be supported by GERAN and UTRAN radio access networks.

The present annex also defines procedures for invoking CS domain services.

B.2  GPRS aspects when connected to the IM CN subsystem

B.2.1  Introduction

A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by the core network to provide packet-mode communication between the UE and the IM CN subsystem.

Requirements for the UE on the use of these packet-mode services are specified in this clause. Requirements for the core network in support of this communication are specified in TS 29.061, TS 29.207 and TS 29.212.

When using the GPRS IP-CAN, each IP-CAN bearer is provided by a PDP context.

B.2.2  Procedures at the UE

B.2.2.1  PDP context activation and P-CSCF discovery

Prior to communication with the IM CN subsystem, the UE shall:

a)

if not attached for GPRS services yet, perform a GPRS attach procedure as specified in TS 24.008;

b)

ensure that a PDP context used for SIP signalling according to the APN and GGSN or P-GW selection criteria described in TS 23.060 and TS 27.060 is available. This PDP context shall remain active throughout the period the UE is connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration. As a result, the PDP context provides the UE with information that makes the UE able to construct an IPv4 or an IPv6 address;

When the bearer establishment is controlled by the UE, the UE shall choose one of the following options when performing establishment of this PDP context:

1. A dedicated PDP context for SIP signalling:
   The UE shall indicate to the core network that this is a PDP context intended to carry IM CN subsystem-related signalling only by setting the IM CN Subsystem Signalling Flag. The UE may also use this PDP context for DNS and DHCP signalling according to the static packet filters as described in TS 29.061. The UE can also set the Signalling Indication attribute within the QoS information element;
2. A general-purpose PDP context:
   The UE may decide to use a general-purpose PDP Context to carry IM CN subsystem-related signalling. The UE shall indicate to the core network that this is a general-purpose PDP context by not setting the IM CN Subsystem Signalling Flag. The UE may carry both signalling and media on the general-purpose PDP context. The UE can also set the Signalling Indication attribute within the QoS information element.

If the UE supports the optional configuration parameter "Access_Point_Name_Parameter_Reading_Rule", as defined in TS 24.167 and has been configured with this parameter, then the UE shall use it to retrieve the access point name to use in the PDP context activation procedure.

The UE indicates the IM CN Subsystem Signalling Flag within the Protocol Configuration Options information element of the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP CONTEXT REQUEST message. Upon successful signalling PDP context establishment the UE receives an indication in the form of IM CN Subsystem Signalling Flag within the Protocol Configuration Options information element. If the flag is not received, the UE shall consider the PDP context as a general-purpose PDP context.

The encoding of the IM CN Subsystem Signalling Flag within the Protocol Configuration Options information element is described in TS 24.008.

The UE can indicate a request for prioritised handling over the radio interface by setting the Signalling Indication attribute (see TS 23.107). The general QoS negotiation mechanism and the encoding of the Signalling Indication attribute within the QoS information element are described in TS 24.008; and

c)

acquire a P-CSCF address(es).

The methods for P-CSCF discovery are:

1. When using IPv4, employ the Dynamic Host Configuration Protocol (DHCP) RFC 2132, the DHCPv4 options for SIP servers RFC 3361, and RFC 3263 as described in subclause 9.2.1. When using IPv6, employ Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3315, the DHCPv6 options for SIP servers RFC 3319 and DHCPv6 options for Domain Name Servers (DNS) RFC 3646 as described in subclause 9.2.1.
2. Transfer P-CSCF address(es) within the PDP context activation procedure.
   The UE shall indicate the request for a P-CSCF address within the Protocol Configuration Options information element of the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP CONTEXT REQUEST message.
   If the UE is provided with a list of P-CSCF IPv4 or IPv6 addresses in the ACTIVATE PDP CONTEXT ACCEPT message or ACTIVATE SECONDARY PDP CONTEXT ACCEPT message, the UE shall assume that the list is ordered top-down with the first P-CSCF address within the Protocol Configuration Options information element as the P-CSCF address having the highest preference and the last P-CSCF address within the Protocol Configuration Options information element as the P-CSCF address having the lowest preference.
3. The UE selects a P-CSCF from the list (see TS 31.103) stored in the ISIM.
4. The UE selects a P-CSCF from the list in IMS management object.

The UE shall use method IV to select a P-CSCF, if:

• a P-CSCF is to be discovered in the home network;
• the UE is roaming; and
• the IMS management object contains the P-CSCF list.

The UE shall use method III to select the P-CSCF, if:

• a P-CSCF is to be discovered in the home network;
• the UE is roaming;
• either the UE does not contain the IMS management object, or the UE contains the IMS management object, but the IMS management object does not contain the P-CSCF list; and
• the ISIM residing in the UICC supports the P-CSCF list.

The UE can freely select method I or II for P-CSCF discovery, if:

• the UE is in the home network; or
• the UE is roaming and the P-CSCF is to be discovered in the visited network.

The UE can select method IV, if:

• the UE is in the home network; and
• the IMS management object contains the P-CSCF list.

In case method I is selected and several P-CSCF addresses or FQDNs are provided to the UE, the selection of P-CSCF address or FQDN shall be performed as indicated in RFC 3361 when using IPv4 or RFC 3319 when using IPv6. If sufficient information for P-CSCF address selection is not available, selection of the P-CSCF address by the UE is implementation specific.

If the UE is designed to use I above, but receives P-CSCF address(es) according to II, then the UE shall either ignore the received address(es), or use the address(es) in accordance with II, and not proceed with the DHCP request according to I.

If the UE is configured to use Option II above and detects that all P-CSCFs known by the UE have been used when the UE selects a different P-CSCF as a result of:

• receiving 305 (Use Proxy) to the REGISTER request;
• receiving 504 (Server Time-out); or
• expiration of the timer F at the UE,

then the UE should:

• release IP-CAN bearer that is used only for the transport of SIP signalling and that are not used for other non-IMS applications, except emergency IP-CAN bearers;
• perform a new P-CSCF discovery procedure as described in subslause 9.2.1; and
• perform the procedures for initial registration as described in subclause 5.1.1.2.

When using IPv4, the UE may request a DNS Server IPv4 address(es) via RFC 2132 or by the Protocol Configuration Options information element when activating a PDP context according to TS 27.060.

When using IPv6, the UE may request a DNS Server IPv6 address(es) via RFC 3315 and RFC 3646 or by the Protocol Configuration Options information element when activating a PDP context according to TS 27.060.

The encoding of the request and response for IPv4 or IPv6 address(es) for DNS server(s) and list of P-CSCF address(es) within the Protocol Configuration Options information element is described in TS 24.008.

When:

• the UE obtains a PDP context used for SIP signalling by performing handover of the connection from another IP-CAN;
• the IP address of the UE is not changed during the handover; and
• the UE already communicates with the IM CN subsystem via the connection with the other IP-CAN, e.g. the UE determines that its contact with host portion set to the UE IP address (or FQDN of the UE) associated with the connection with the other IP-CAN has been bound to a public user identity;

the UE shall continue using the P-CSCF address(es) acquired in the other IP-CAN.

B.2.2.1A  Modification of a PDP context used for SIP signalling  Word‑p. 788

The PDP context shall not be modified from a dedicated PDP context for SIP signalling to a general-purpose PDP context or vice versa. The IM CN Subsystem Signalling Flag shall not be set in the Protocol Configuration Options information element of the MODIFY PDP CONTEXT REQUEST message.

The UE shall not indicate the request for a P-CSCF address within the Protocol Configuration Options information element of the MODIFY PDP CONTEXT REQUEST message. The UE shall ignore P-CSCF address(es) if received in the Protocol Configuration Options information element of the MODIFY PDP CONTEXT RESPONSE message.

B.2.2.1B  Re-establishment of the PDP context for SIP signalling

If the UE registered a public user identity with an IP address allocated for the APN of the PDP context used for SIP signalling, the PDP context used for SIP signalling is deactivated as result of signalling from the core network (e.g. no longer available as a result of a successful GPRS routeing area update procedure) and:

1. if the signalling from the core network results in requiring the UE to initiate activation of the PDP context used for SIP signalling; or
2. if the UE needs to continue having a public user identity registered with an IP address allocated for the APN;

and the UE is allowed to send:

• ACTIVATE PDP CONTEXT REQUEST message; or
• ACTIVATE SECONDARY PDP CONTEXT REQUEST message,

to activate the PDP context for SIP signalling, the UE shall:

1. if the non-access stratum is performing the PDP context activation procedure for the APN triggered as result of the signalling from the core network, wait until the PDP context activation procedure for the APN finishes; and
2. perform the procedures in subclause B.2.2.1, bullets a), b) and c).

If:

• none of the bullets i) and ii) of this subclause evaluate to true;
• the UE is not allowed to send the ACTIVATE (SECONDARY) PDP CONTEXT REQUEST message;
• the procedures in bullet B) of this subclause were unable to ensure that the PDP context used for SIP signalling is available; or
• the procedures in bullet B) of this subclause were unable to acquire any P-CSCF address(es);

and if the PDP context used for SIP signalling was a dedicated PDP context for SIP signalling as described in subclause B.2.2.1, the UE shall deactivate all PDP contexts established as a result of SIP signalling according to the TS 24.008.

If all PDP contexts for the APN were deactivated at the start of this subclause and the procedures in bullet B) of this subclause ensured that the PDP context used for SIP signalling is available and acquired the P-CSCF address(es), the UE shall perform a new initial registration according to subclause 5.1.1.2.

B.2.2.1C  P-CSCF restoration procedure |R9|  Word‑p. 789

A UE supporting the P-CSCF restoration procedure performs one of the following procedures:

A)

if the UE used method II for P-CSCF discovery and if the UE receives one or more P-CSCF address(es) in the Protocol Configuration Options information element of a MODIFY PDP CONTEXT REQUEST message and the one or more P-CSCF addresse(s) do not include the address of the currently used P-CSCF, then the UE shall acquire a different P-CSCF address from the one or more P-CSCF addresse(s) in the MODIFY PDP CONTEXT REQUEST message. If more than one P-CSCF address with the same container identifier (i.e. "P-CSCF IPv6 Address" or "P-CSCF IPv4 Address") are included, then the UE shall assume that the more than one P-CSCF addresses with the same container identifier are prioritised with the first P-CSCF address with the same container identifier within the Protocol Configuration Options information element as the P-CSCF address with the highest priority.

If the UE used method II for P-CSCF discovery and if the UE has previously sent the "P-CSCF Re-selection support" PCO indicator at PDP Context Activation and if the UE receives one or more P-CSCF address(es) in the Protocol Configuration Options information element of a MODIFY PDP CONTEXT REQUEST message, then the UE shall acquire a P-CSCF address from the one or more P-CSCF addresse(s) in the MODIFY PDP CONTEXT REQUEST message. If more than one P-CSCF address with the same container identifier (i.e. "P-CSCF IPv6 Address" or "P-CSCF IPv4 Address") are included, then the UE shall assume that the more than one P-CSCF addresses with the same container identifier are prioritised with the first P-CSCF address with the same container identifier within the Protocol Configuration Options information element as the P-CSCF address with the highest priority;

B)

if the UE uses RFC 6223 as part of P-CSCF restoration procedures, and if the P-CSCF fails to respond to a keep-alive request, then the UE shall acquire a different P-CSCF address using one of the methods I, III and IV for P-CSCF discovery described in the subclause B.2.2.1.

If the UE has an ongoing session and acquired the new P-CSCF address by using procedure A described above, the UE may wait until the UE has detected that the ongoing session has ended before performing an initial registration as specified in subclause 5.1.

In all other cases, when the UE has acquired the P-CSCF address, the UE not having an ongoing session shall perform an initial registration as specified in subclause 5.1.

B.2.2.2  Session management procedures  Word‑p. 790

The existing procedures for session management as described in TS 24.008 shall apply while the UE is connected to the IM CN subsystem.

B.2.2.3  Mobility management procedures

The existing procedures for mobility management as described in TS 24.008 shall apply while the UE is connected to the IM CN subsystem.

B.2.2.4  Cell selection and lack of coverage

The existing mechanisms and criteria for cell selection as described in TS 25.304 and TS 44.018 shall apply while the UE is connected to the IM CN subsystem.

B.2.2.5  PDP contexts for media

B.2.2.5.1  General requirements

The UE can establish media streams that belong to different SIP sessions on the same PDP context.

During establishment of a session, the UE establishes data streams(s) for media related to the session. Such data stream(s) may result in activation of additional PDP context(s). Such additional PDP context(s) shall be established as secondary PDP contexts associated to the PDP context used for signalling. Such secondary PDP contexts for media can be established either by the UE or the core network.

If the bearer establishment is controlled by the UE, the UE starts reserving its local resources whenever it has sufficient information about the media streams, media authorization and used codecs available as specified in TS 24.008.

B.2.2.5.1A  Activation or modification of PDP contexts for media by the UE

If the UE is configured not to initiate resource allocation for media according to TS 24.167 and both UE and the core network are allowed to establish the secondary PDP contents, then the UE shall refrain from establishing the secondary PDP context(s) for media and from modifying existing PDP contexts for media until the UE considers that the network did not initiate resource allocation for the media.

If the UE receives indication within the SDP according to RFC 3524 that media stream(s) belong to group(s), the media stream(s) shall be set up on separate PDP contexts according to the indication of grouping of media streams. The UE may freely group media streams to PDP context(s) in case no indication of grouping of media streams is received from the P-CSCF.

If the capabilities of the originating UE prevents it from establishment of additional PDP contexts according to the media grouping attributes given by the P-CSCF in accordance with RFC 3524, the UE will not establish such grouping of media streams. Instead, the originating UE shall negotiate media parameters for the session according to RFC 3264.

If the capabilities of the terminating UE prevents it from establishment of additional PDP contexts according to the media grouping attributes given by the P-CSCF in accordance with RFC 3524, the UE will not establish such grouping of media streams. Instead, the terminating UE shall the UE shall handle such SDP offers in accordance with RFC 3388.

The UE can receive a media authorization token in the P-Media-Authorization header field from the P-CSCF according to RFC 3313. If a media authorization token is received in the P-Media-Authorization header field when a SIP session is initiated, the UE shall:

• either use existing PDP context(s) where another media authorization token is already in use and no indication of grouping of media streams is required; or
• establish separate PDP context(s) for the media; or
• use an existing PDP context where media authorization token is not in use and no indication of grouping of media streams is required.

When a UE modifies a PDP context to indicate a new media authorization token:

• either as a result of establishment of an additional SIP session; or
• modification of media streams for an ongoing SIP session;

the UE shall include all media authorization tokens and all flow identifiers for all ongoing SIP sessions that use this particular PDP context.

If a media authorization token is received in subsequent messages for the same SIP session, the UE shall:

• use the existing PDP context(s) for media;
• modify the existing PDP context(s) for media; or
• establish additional PDP context(s) for media.

If either background or interactive QoS class is needed for the media, then the UE does not need to use the authorization token even if it receives one. In this case the UE may reuse an existing PDP context and it does not need to request PDP context modification unless it needs to modify the QoS.

If existing PDP context(s) where another media authorization token is already in use is re-used for the media, or separate PDP context(s) is established for the media, the UE shall proceed as follows:

• when a SIP session is terminated, the media authorization token is no longer valid and the UE shall not include it in future GPRS session management messages. The UE shall send a MODIFY PDP CONTEXT REQUEST message updating the binding information by deleting the media authorization token and the corresponding flow identifiers that are no longer valid. If a SIP session is terminated and no other SIP sessions are using the PDP context, the UE shall either update the binding information as described above or deactivate the PDP context;
• the UE shall transparently pass the media authorization token received from the P-CSCF in a response to an INVITE request at originating setup or in the INVITE request at terminating setup to the core network. The UE shall signal it by inserting it within the Traffic Flow Template information element in the ACTIVATE SECONDARY PDP CONTEXT REQUEST message or the MODIFY PDP CONTEXT REQUEST message;
• to identify to the core network which flow(s) (identified by m-lines within the SDP) that are transferred within a particular PDP context, the UE shall set the flow identifier(s) within the Traffic Flow Template information element in the ACTIVATE SECONDARY PDP CONTEXT REQUEST message or the MODIFY PDP CONTEXT REQUEST message. Detailed description of how the flow identifiers are constructed is provided in TS 29.207;
• if the UE receives several media authorization tokens from the P-CSCF within the same SIP request or response, the first instance of the media authorization token shall be sent to the core network, and subsequent instances are discarded by the UE; and
• the UE shall not include the IM CN Subsystem Signalling Flag when a PDP context for media is established or modified.

The encoding of the media authorization token and the flow identifiers within the Traffic Flow Template information element is described in TS 24.008.

B.2.2.5.1B  Activation or modification of PDP contexts for media by the core network |R7|  Word‑p. 792

If the UE receives an activation request for a PDP context which is associated with the PDP context used for signalling, the UE shall, based on the information contained in the Traffic Flow Template information element, correlate the media PDP context with a currently ongoing SIP session establishment or SIP session modification.

If the UE receives a modification request for a PDP context that is used for one or more media streams in an ongoing SIP session, the UE shall:

1. modify the related PDP context in accordance with the received modification request.

B.2.2.5.1C  Deactivation of PDP context for media |R11|

When a data stream for media related to a session is released, if the PDP context transporting the data stream is no longer needed and if the PDP context has been activated by the UE, then the UE deactivates the PDP context.

B.2.2.5.2  Special requirements applying to forked responses

Since the UE does not know that forking has occurred until a second, provisional response arrives, the UE sets up the PDP context(s) as required by the initial response received. If a subsequent provisional response is received, different alternative actions may be performed depending on the requirements in the SDP answer:

1. the bearer requirements of the subsequent SDP can be accommodated by the existing PDP context(s). The UE performs no activation or modification of PDP contexts.
2. the subsequent SDP introduces different QoS requirements or additional IP flows. The UE modifies the existing PDP context(s), if necessary, according to subclause B.2.2.5.1A.
3. the subsequent SDP introduces one or more additional IP flows. The UE establishes additional PDP context(s) according to subclause B.2.2.5.1A.

When a final answer is received for one of the early dialogs, the UE proceeds to set up the SIP session. The UE shall release all the unneeded radio/bearer resources. Therefore, upon the reception of the first final 200 (OK) response for the INVITE request (in addition to the procedures defined in RFC 3261 subclause 13.2.2.4), the UE shall:

1. in case PDP context(s) were established or modified as a consequence of the INVITE request and forked provisional responses that are not related to the accepted 200 (OK) response, delete the PDP context(s) or modify the delete the PDP context(s) back to their original state.

B.2.2.5.3  Unsuccessful situations

One of the Go, Gq, Rx and Gx interface related error codes can be received by the UE in the ACTIVATE SECONDARY PDP CONTEXT REJECT message or the MODIFY PDP CONTEXT REJECT message. If the UE receives a Go, Gq, Rx and Gx interface related error code, the UE shall either handle the resource reservation failure as described in subclause 6.1.1 or retransmit the message up to three times. The Go, Gq, Rx and Gx interface related error codes are further specified in TS 29.207, TS 29.209, TS 29.214 and TS 29.212.

B.2.2.6  Emergency service |R7|  Word‑p. 793

B.2.2.6.1  General |R14|

Emergency bearers are defined for use in emergency calls in GPRS IP-CAN and core network support of these bearers is indicated to the UE in NAS signalling. Where the UE recognises that a call request is an emergency call and the core network supports emergency bearers, the UE shall use these bearers for both signalling and media on emergency calls made using the IM CN subsystem.

Some jurisdictions allow emergency calls to be made when the UE does not contain an ISIM or USIM, or where the credentials are not accepted. Additionally, where the UE is in state GMM-REGISTERED.LIMITED-SERVICE and GMM-REGISTERED.PLMN-SEARCH, a normal ATTACH has been attempted but it can also be assumed that a registration in the IM CN subsystem will also fail. In such cases, subject to the lower layers indicating that the network does support emergency bearer services in limited service state (see TS 25.331), the procedures for emergency calls without registration can be applied, as defined in subclause 5.1.6.8.2. If the GPRS authentication procedure has already succeeded during the latest normal or emergency ATTACH procedure, the UE shall perform an initial emergency registration, as described in subclause 5.1.6.2 before attempting an emergency call as described in subclause 5.1.6.8.3.

When activating a PDP context to perform emergency registration, the UE shall request a PDP context for emergency bearer services as defined in TS 24.008. The procedures for PDP context activation and P-CSCF discovery, as described in subclause B.2.2.1 of this specification apply accordingly.

In order to find out whether the UE is attached to the home PLMN or to the visited PLMN, the UE shall compare the MCC and MNC values derived from its IMSI with the MCC and MNC of the PLMN the UE is attached to. If the MCC and MNC of the PLMN the UE is attached to donot match with the MCC and MNC derived from the IMSI, then for the purpose of emergency calls in the IM CN subsystem the UE shall consider to be attached to a VPLMN.

If the dialled number is equal to an emergency number stored in the ME, in the USIM or in the Local Emergency Number List (as defined in TS 24.008), then the UE shall recognize a number as for an emergency call and performs the procedures in subclause B.2.2.6.1A.

Upon reception of a 380 (Alternative Service) response to an INVITE request as defined in subclause 5.1.2A.1.1 and subclause 5.1.3.1, if:

• the 380 (Alternate Service) response contains a Contact header field;
• the value of the Contact header field is a service URN; and
• the service URN has a top-level service type of "sos";

then the UE determines that "emergency service information is included" as described TS 23.167.

Upon reception of a 380 (Alternative Service) response to an INVITE request as defined in subclause 5.1.3.1 if the 380 (Alternate Service) response does not contain a Contact header field with service URN that has a top-level service type of "sos", then the UE determines that "no emergency service information is included" as described TS 23.167.

If the "emergency service information is included" as described TS 23.167:

1. if the URN in the Contact header field matches an emergency service URN in table B.2.2.6.1, then the type of emergency service is the value corresponding to the matching entry in table B.2.2.6.1; and
2. if the URN in the Contact header field does not match any emergency service URN in table B.2.2.6.1, then the type of emergency service is not identified.

When the emergency registration expires, the UE should disconnect the PDP context for emergency bearer services as defined in TS 24.008.

Upon receiving a 3xx other than 380 (Alternative service), 4xx, 5xx or 6xx response to an INVITE request for a UE detectable emergency call, the UE shall perform domain selection as specified in TS 23.167 annex H, to re-attempt the emergency call.

B.2.2.6.1A  Type of emergency service derived from emergency service category value |R15|  Word‑p. 794

The type of emergency service for an emergency number is derived from the settings of the emergency service category value (bits 1 to 5 of the emergency service category value as specified in subclause 10.5.4.33 of TS 24.008). Table B.2.2.6.1 below specifies mappings between a type of emergency service and an emergency service URN. The UE shall use the mapping to match an emergency service URN and a type of emergency service. If a dialled number is an emergency number but does not map to a type of emergency service the service URN shall be "urn:service:sos".

Table B.2.2.6.1: Mapping between type of emergency service and emergency service URN

Type of emergency service

Emergency service URN

---

Police

urn:service:sos.police

Ambulance

urn:service:sos.ambulance

Fire Brigade

urn:service:sos.fire

Marine Guard

urn:service:sos.marine

Mountain Rescue

urn:service:sos.mountain

---

If an IP-CAN, capable of providing local emergency numbers, did not provide a local emergency number that matches the dialled number (see subclause 5.1.6.1) and multiple types of emergency service can be derived for a dialled number from the information configured on the USIM then:

• if the UE is in the HPLMN, the UE shall map any one of these types of emergency service to an emergency service URN as specified in table B.2.2.6.1; and
• if the UE is in the VPLMN, the UE shall select "urn:service:sos".

If an IP-CAN, capable of providing local emergency numbers, provided a local emergency number that matches the dialled number (see subclause 5.1.6.1), and:

• if the UE can derive one or more types of emergency service from the information received from the IP-CAN for the dialled number and the UE cannot derive types of emergency service from the information configured on the USIM for the dialled number; or
• if the UE is able to derive identical types of emergency service from both the information received from the IP-CAN for the dialled number and from the information configured on the USIM for the dialled number,

then the UE shall map any one of these emergency service types to an emergency service URN as specified in table B.2.2.6.1.

B.2.2.6.1B  Type of emergency service derived from extended local emergency number list |R15|  Word‑p. 795

Void

B.2.2.6.2  eCall type of emergency service |R14|

The UE shall not send an INVITE request with Request-URI set to "urn:service:sos.ecall.manual" or "urn:service:sos.ecall.automatic".

B.2.2.6.3  Current location discovery during an emergency call |R14|

Void.

B.2A  Usage of SDP |R7|

B.2A.0  General |R9|

B.2A.1  Impact on SDP offer / answer of activation or modification of PDP contexts for media by the core network

If due to the activation of PDP context from the core network the related SDP media description needs to be changed the UE shall update the related SDP information by sending, within a SIP request, a new SDP offer for each of the existing SIP dialogs,

If the UE receives a modification request from the core network for a PDP context that is used for one or more media streams in an ongoing SIP session, the UE shall:

1. if, due to the modification of the PDP context, the related SDP media description need to be changed, update the related SDP information by sending, with in a SIP request, a new SDP offer for each of the existing SIP dialogs , and respond to the PDP context modification request.

B.2A.2  Handling of SDP at the terminating UE when originating UE has resources available and IP-CAN performs network-initiated resource reservation for terminating UE  Word‑p. 796

If the UE receives an SDP offer where the SDP offer includes all media streams for which the originating side indicated its local preconditions as met, if the precondition mechanism is supported by the terminating UE and the IP-CAN performs network-initiated resource reservation for the terminating UE and the available resources are not sufficient for the received offer the terminating UE shall indicate its local preconditions and provide the SDP answer to the originating side without waiting for resource reservation.

B.2A.3  Emergency service |R11|

B.3  Application usage of SIP

B.3.1  Procedures at the UE

B.3.1.0  Registration and authentication |R13|

The UE shall perform reregistration of a previously registered public user identity bound to any one of its contact addresses when changing to an IP-CAN for which usage is specified in annex R. The reregistration is performed using the new IP-CAN.

If the UE supports the 3GPP PS data off, then the UE shall in all REGISTER requests include the "+g.3gpp.ps-data-off" header field parameter defined in subclause 7.9.8 set to a value indicating the 3GPP PS data off status.

When the UE sends a REGISTER request, if the 3GPP PS data off status is "active", then the UE shall only include media feature tags associated with services that are 3GPP PS data off exempt services in the g.3gpp.icsi-ref media feature tag, as defined in subclause 7.9.2 and RFC 3840, for the IMS communication services it intends to use.

If the UE is registered, and the 3GPP PS data off status is changed or the UE is provided by the network with a new list of 3GPP PS data off exempt services while the 3GPP PS data off status is "active", then the UE shall perform a reregistration of the previously registered public user identity.

B.3.1.0a  IMS_Registration_handling policy |R15|

The IMS_Registration_handling policy indicates whether the UE deregisters from IMS after a configured amount of time after receiving an indication that the IMS Voice over PS Session is not supported.

The UE may support the IMS_Registration_handling policy.

If the UE supports the IMS_Registration_handling policy, the UE may support being configured with the IMS_Registration_handling policy using one or more of the following methods:

1. the IMS_Registration_Policy node of the EFIMSConfigData file described in TS 31.102;
2. the IMS_Registration_Policy node of the EFIMSConfigData file described in TS 31.103; and
3. the IMS_Registration_Policy node of TS 24.167.

If the UE is configured with both the IMS_Registration_Policy node of TS 24.167 and the IMS_Registration_Policy node of the EFIMSConfigData file described in TS 31.102 or TS 31.103, then the IMS_Registration_Policy node of the EFIMSConfigData file shall take precedence.

If the UE is registered with IMS and the IMSVoPS indicator, provided by the lower layers (see TS 24.301), indicates voice is not supported, the UE shall:

1. if the Stay_Registered_When_VoPS_Not_Supported leaf indicates requirement to stay registered, the UE needs not to deregister and maintains the registration as required for IMS services; or
2. if the Stay_Registered_When_VoPS_Not_Supported leaf indicates requirement to deregister and the Deregistration_Timer leaf used to configure the NoVoPS-dereg timer defined in table 7.8.1 contains a timer value for the time to wait before deregistrerting from IMS, start a timer with the value indicated in the policy and:
   1. if the timer expires before the UE receives an indication from the lower layers that IMS voice is supported:
      1. if there is no ongoing IMS session, either performs reregistration as specified in subclause 5.1.1.4 and shall only include feature tags associated with services that are independent of the IMSVoPS indicator or deregister from the IMS following the procedures specified in subclause 5.1.1.6; or
      2. if there is ongoing IMS session, and
         1. if the UE does not receive indication from the lower layer that the IMS voice is supported before the ongoing IMS session is terminated, either performs reregistration as specified in subclause 5.1.1.4 and shall only include feature tags associated with services that are independent of IMSVoPS indicator or deregister from the IMS following the procedures specified in subclause 5.1.1.6 as soon as the ongoing IMS based service is terminated ; or
         2. if the UE receives indication from the lower layer that the IMS voice is supported before the ongoing IMS session is terminated, cancel the timer; or
   2. if the UE receives an indication from the lower layers that IMS voice is supported before the timer expires, cancel the timer.

If the IMS_Registration_handling policy is not configured, the UE behaviour is implementation specific.

B.3.1.1  P-Access-Network-Info header field |R7|  Word‑p. 797

The UE shall always include the P-Access-Network-Info header field where indicated in subclause 5.1.

B.3.1.1A  Cellular-Network-Info header field |R13|

Not applicable.

B.3.1.2  Availability for calls |R8|

The UE indicates to the non-access stratum the status of being available for voice over PS when:

1. the UE is capable of receiving any (but not necessarily all) of the media types which the CS domain supports, such that the media type can also be used when accessing the IM CN subsystem using the current IP-CAN;
2. if the media type of item 1 is an "audio" media type, the UE supports codecs suitable for (conversational) speech, the "audio" media type is not restricted from inclusion in an SDP message according to the media type restriction policy as specified in subclause 6.1.1, and:
   1. 3GPP PS data off status is "inactive";
   2. 3GPP PS data off status is "active", the UE is in the HPLMN or the EHPLMN, and MMTEL voice is a 3GPP PS data off exempt service; or
   3. 3GPP PS data off status is "active", the UE is in the VPLMN, the UE is configured with an indication that MMTEL voice is a 3GPP PS data off exempt service in a VPLMN, and MMTEL voice is a 3GPP PS data off roaming exempt service; and
3. the UE determines a contact has been bound to a public user identity using the IP-CAN, such that this contact is expected to be used for the delivery of incoming requests in the IM CN subsystem relating to such media.

The UE indicates to the non-access stratum the status of being not available for voice over PS when these conditions are no longer met.

B.3.1.2A  Availability for SMS |R11|  Word‑p. 798

The UE determines that the UE is able to use SMS using IMS if the UE:

1. is capable of using the MIME type "application/vnd.3gpp.sms" (see TS 24.341), such that the MIME type can also be used when accessing the IM CN subsystem using the current IP-CAN;
2. supports the role of an SM-over-IP sender (see TS 24.341);
3. determines the PDP context used for SIP signalling exists;
4. determines a contact has been bound to a public user identity using the IP-CAN, such that this contact is expected to be used for the delivery of incoming requests in the IM CN subsystem relating to such media;
5. the UE does not determine that SMS over IP is restricted in TS 24.341 subclause 5.2.1.3; and
6. the 3GPP PS data off status is:
   • "inactive";
   • "active", the UE is in the HPLMN or the EHPLMN, and SMS over IMS is a 3GPP PS data off exempt service; or
   • "active", the UE is in the VPLMN, the UE is configured with an indication that SMS over IMS is a 3GPP PS data off exempt service in a VPLMN, and SMS over IMS is a 3GPP PS data off roaming exempt service.

When above criteria are not matched, the UE determines that SMS using IMS is unavailable.

B.3.1.3  Authorization header field |R10|

Void.

B.3.1.4  SIP handling at the terminating UE when precondition is not supported in the received INVITE request, the terminating UE does not have resources available and IP-CAN performs network-initiated resource reservation for the terminating UE |R10|  Word‑p. 799

Upon receiving an INVITE request not including the "precondition" option-tag in the Supported header field and not including the "precondition" option-tag in the Require header field, and the IP-CAN performs network-initiated resource reservation for the UE, the UE:

1. if the INVITE request contains an SDP offer and the local resources required at the terminating UE for the received SDP offer are not available:
   1. shall not alert the user; and
   2. shall send 183 (Session Progress) response to the INVITE request without waiting for resource reservation and without alerting the user. If the INVITE request includes a Supported header field indicating support of reliable provisional responses, the UE shall send the 183 (Session Progress) response reliably. In the 183 (Session Progres) response, the UE shall include an SDP answer; and
2. if the INVITE request does not contain an SDP offer and the INVITE request includes a Supported header field indicating support of reliable provisional responses:
   1. shall generate an SDP offer; and
   2. if the local resources required at the terminating UE for the generated SDP offer are not available:
      1. shall not alert the user; and
      2. shall reliably send 183 (Session Progress) response to the INVITE request without waiting for resource reservation and without alerting the user. In the 183 (Session Progres) response, the UE shall include the generated SDP offer.

Upon successful reservation of local resources, if the precondition mechanism is not used by the terminating UE, the UE can send 180 (Ringing) response to the INVITE request and can alert the user.

B.3.1.5  3GPP PS data off |R14|

If the 3GPP PS data off status is "active" the UE shall only send initial requests that:

1. are associated with a 3GPP IMS service which enforces 3GPP PS data off;
2. are associated with an emergency service; or
3. are associated with 3GPP PS data off exempt services configured in the UE using one or more of the following methods:
   • the non_3GPP_ICSIs_exempt node specified in TS 24.167, if the UE is in the HPLMN or the EHPLMN, or if the UE is in the VPLMN and the non_3GPP_ICSIs_roaming_exempt node specified in TS 24.167 is not configured;
   • the non_3GPP_ICSIs_roaming_exempt node specified in TS 24.167, if the UE is in the VPLMN;
   • the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, if the UE is in the HPLMN or the EHPLMN, or if the UE is in the VPLMN and the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 is not configured; or
   • the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, if the UE is in the VPLMN.
   If the UE is configured with both the non_3GPP_ICSIs_exempt node of TS 24.167 and the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 shall take precedence.
   If the UE is configured with both the non_3GPP_ICSIs_roaming_exempt node of TS 24.167 and the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 shall take precedence.

If the 3GPP PS data off status changes from "inactive" to "active" the UE shall release all dialogs that

1. are not associated with a 3GPP IMS service which enforces 3GPP PS data off;
2. are not associated with an emergency service; and
3. are not associated with 3GPP data off exempt services configured in the UE using one or more of the following methods:
   • the non_3GPP_ICSIs_exempt node specified in TS 24.167, if the UE is in the HPLMN or the EHPLMN, or if the UE is in the VPLMN and the non_3GPP_ICSIs_roaming_exempt node specified in TS 24.167 is not configured;
   • the non_3GPP_ICSIs_roaming_exempt node specified in TS 24.167, if the UE is in the VPLMN;- the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, if the UE is in the HPLMN or the EHPLMN, or if the UE is in the VPLMN and the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 is not configured; or
   • the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, if the UE is in the VPLMN.
   If the UE is configured with both the non_3GPP_ICSIs_exempt node of TS 24.167 and the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 shall take precedence.
   If the UE is configured with both the non_3GPP_ICSIs_roaming_exempt node of TS 24.167 and the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102, then the non_3GPP_ICSIs_roaming_exempt node in the EF3GPPPSDATAOFFservicelist file described in TS 31.102 shall take precedence.

B.3.1.6  Transport mechanisms |R15|  Word‑p. 800

No additional requirements are defined.

B.3.1.7  RLOS |R16|

Not applicable.

B.3.2  Procedures at the P-CSCF |R7|

B.3.2.0  Registration and authentication |R12|

Void.

B.3.2.1  Determining network to which the originating user is attached  Word‑p. 801

In order to determine from which network the request was originated the P-CSCF shall check the MCC and MNC fields received in the P-Access-Network-Info header field.

B.3.2.2  Location information handling

Void.

B.3.2.3  Prohibited usage of PDN connection for emergency bearer services |R9|

If the P-CSCF detects that a UE uses a PDN connection for emergency bearer services for a non-emergency REGISTER request, the P-CSCF shall reject that request by a 403 (Forbidden) response.

B.3.2.5  Void

B.3.2.6  Resource sharing |R13|

If P-CSCF supports resource sharing, PCC is supported for this access technology and if according to local policy, the P-CSCF shall apply the procedures in subclause L.3.2.6.

B.3.2.7  Priority sharing |R13|

If P-CSCF supports priority sharing, PCC is supported for this access technology and if according to operator policy, the P-CSCF shall apply the procedures in subclause L.3.2.7.

B.3.2.8  RLOS |R16|

Not applicable.

B.3.3  Procedures at the S-CSCF |R8|

B.3.3.1  Notification of AS about registration status

Not applicable

B.3.3.2  RLOS |R16|

Not applicable.

B.4  3GPP specific encoding for SIP header field extensions  Word‑p. 802

B.4.1  Void

B.5  Use of circuit-switched domain |R8|

When an emergency call is to be set up over the CS domain, the UE shall attempt it according to the procedures described in TS 24.008.

---