7.3 Interworking between CS networks supporting BICC and the IM CN subsystem

29.1633GPPInterworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networksTS

The control plane between CS networks supporting BICC and the IM CN subsystem supporting SIP, where the underlying network is SS7 and IP respectively is as shown in figures 25, 26 and 27.

Figure 25: Control Plane interworking between CS networks supporting BICC over MTP3 and the IM CN subsystem

Figure 26: Control Plane interworking between CS networks supporting BICC over MTP3B over AAL5 and the IM CN subsystem

Figure 27: Control Plane interworking between CS networks supporting BICC
over STC and M3UA and the IM CN subsystem

7.3.1 Services performed by network entities in the control plane

Services offered by the network entities in the control plane are as detailed in clause 7.2.1.

If ATM transport is applied between the SS7 Signalling function and the Signalling Gateway Function, they shall apply MTP3B (ITU-T Recommendation Q.2210 [46]) over SSCF (ITU-T Recommendation Q.2140 [45]) over SSCOP (ITU-T Recommendation Q.2110 [44]) over AAL5 (ITU-T Recommendation I.363.5 [43]) as depicted in figure 26.

If IP transport is applied between the SS7 Signalling function and the MGCF, they shall support and apply M3UA, SCTP and IP (either Ipv4, see RFC 791 [16], or Ipv6, see RFC 2460 [39]), as depicted in figure 27.

7.3.2 Signalling interactions between network entities in the control plane

7.3.2.1 Signalling between the SS7 signalling function and MGCF

See clause 7.2.2.1.

7.3.2.1.1 Signalling from MGCF to SS7 signalling function

See clause 7.2.2.1.1.

7.3.2.1.2 Signalling from SS7 signalling function to MGCF

See clause 7.2.2.1.2.

7.3.2.1.3 Services offered by STC, SCTP and M3UA

See clause 7.2.2.1.3.

7.3.2.1.3.1 Services offer by SCTP

See clause 7.2.2.1.3.1.

7.3.2.1.3.2 Services offered by M3UA

See clause 7.2.2.1.3.2.

7.3.2.1.3.3 Services offered by STC

STC provides the services for the transparent transfer of STC user information, e.g. BICC, between STC users, i.e. the SS7 signalling function and the MGCF (see 3GPP TS 29.205 [14]).

STC performs the functions of data transfer service availability reporting and congestion reporting to the STC user and User part availability control. See ITU-T Recommendation Q.2150.1 [29].

7.3.2.2 Signalling between the MGCF and SIP signalling function

See clause 7.2.2.2.

7.3.3 SIP-BICC protocol interworking

7.3.3.1 Incoming call interworking from SIP to BICC at I-MGCF

7.3.3.1.1 Sending of IAM

Clause 7.2.3.1.1 is applicable with the clarification that the Continuity Check procedure applies.

Figure 28: Void

7.3.3.1.2 Coding of IAM

The description of the following ISDN user part parameters can be found in ITU-T Recommendation Q.763 [4].

7.3.3.1.2.1 Called party number

See clause 7.2.3.1.2.1.

7.3.3.1.2.2 Nature of connection indicators

bits BA Satellite indicator

0 0 no satellite circuit in the connection

bits DC Continuity indicator (BICC)

0 0 no COT to be expected, if the received SDP does not contain precondition information or indicates that all preconditions are fulfilled, and all local resource reservation is completed.

1 0 COT to be expected, if the received SDP indicates that precondition is not fulfilled or any local resource reservation is not completed.

Bit E Echo control device indicator

1 outgoing echo control device included

7.3.3.1.2.3 Forward call indicators

See clause 7.2.3.1.2.3.

7.3.3.1.2.4 Calling party’s category

See clause 7.2.3.1.2.4.

7.3.3.1.2.4A Originating Line Information

See clause 7.2.3.1.2.4A

7.3.3.1.2.5 Transmission medium requirement

See clause 7.2.3.1.2.5.

7.3.3.1.2.6 Calling party number

See clause 7.2.3.1.2.6.

7.3.3.1.2.7 Generic number

See clause 7.2.3.1.2.7.

7.3.3.1.2.8 User service information

See clause 7.2.3.1.2.8.

7.3.3.1.2.9 Hop counter (National option)

See clause 7.2.3.1.2.9.

7.3.3.1.2.10 Location Number

See clause 7.2.3.1.2.11.

7.3.3.1.2.11 Support of ICS call

See clause 7.2.3.1.2.12.

7.3.3.1.2.12 UID capability indicators (National option)

See clause 7.2.3.1.2.13.

7.3.3.1.2A Coding of the IAM when Number Portability is supported

See clause 7.2.3.1.2A.

7.3.3.1.2B Coding of the IAM for Carrier Routeing

See clause 7.2.3.1.2B.

7.3.3.1.2.13 Called IN number and original called IN number (optional)

See clause 7.2.3.1.2.14.

7.3.3.1.3 Sending of COT

Figure 29: Sending of COT

If the IAM has already been sent, then the Continuity message shall be sent indicating "continuity check successful", when all of the following conditions have been met.

– When the requested remote preconditions (if any) in the IMS have been met.

– The media stream previously set to inactive mode is set to active (as specified in IETF RFC 4566 [56]).

– Local preconditions have been fulfilled.

7.3.3.1.3A Sending of SAM

See clause 7.2.3.1.3A.

7.3.3.1.4 Sending of 180 Ringing

See clause 7.2.3.1.4.

7.3.3.1.4A Sending of 183 Session Progress for early media scenarios

See clause 7.2.3.1.4A.

7.3.3.1.4B Sending of 181 Call is being forwarded

See clause 7.2.3.1.4B.

7.3.3.1.4C Sending of 183 Session Progress for overlap signalling using the in-dialog method

See clause 7.2.3.1.4C.

NOTE: If the network option of overlap signalling using the in-dialog method is applied at the I-MGCF in combination with the optional codec negotiation interworking with BICC in clause B.2., in order to meet the requirement in clause B.2.1 that the I-MGCF suspends the SDP answer procedure until it receives backward codec information from BICC, the 183 session progress response will not contain the SDP answer.

7.3.3.1.4D Sending of 183 Session Progress to carry ISUP Cause

See clause 7.2.3.1.4D.

7.3.3.1.4E Sending of 183 Session Progress for ICS call

See clause 7.2.3.1.4E.

7.3.3.1.5 Sending of the 200 OK (INVITE)

See clause 7.2.3.1.5.

7.3.3.1.6 Sending of the Release message (REL)

See clause 7.2.3.1.6.

7.3.3.1.7 Coding of the REL

See clause 7.2.3.1.7.

7.3.3.1.8 Receipt of the Release Message

See clause 7.2.3.1.8.

7.3.3.1.9 Receipt of RSC, GRS or CGB (H/W oriented)

See clause 7.2.3.1.9.

7.3.3.1.9a Receipt of REFER

See clause 7.2.3.1.9a.

7.3.3.1.9b Autonomous Release at I-MGCF

See clause 7.2.3.1.10.

7.3.3.1.10 Internal through connection of the bearer path

The through connection procedure is described in clauses 9.2.2.1.5 and 9.2.2.2.5.

7.3.3.1.11 Out of Band DTMF

If a SIP UA sends DTMF tones to the IM-MGW, the IM-MGW may report this information via the Mn interface to the MGCF. The MGCF shall send to the BICC network the APM message with the following values for the different parameters:

– Action indicator in accordance with the requested DTMF transport function;

– Signal in accordance with which DTMF digit to send;

– Duration in accordance with the required duration of the DTMF digit.

If the BICC network sends an APM message with DTMF signal, duration and action indicator to the MGCF, the MGCF may send this information to the IM-MGW via the Mn interface. The IM-MGW shall send the corresponding DTMF signal and duration information on the user plane of the IM CN subsystem according to RFC 4733 [105].

The interactions with the IM-MGW are shown in clause 9.2.8.

7.3.3.2 Outgoing Call Interworking from BICC to SIP at O-MGCF

7.3.3.2.1 Sending of INVITE

The following particularities apply for a BICC IAM received case, with regard to the already specified in clause 7.2.3.2.1.

The O-MGCF should defer sending the INVITE request until the BICC bearer setup and any local resource reservation is completed.

NOTE: If the O-MGCF sends the INVITE request before the BICC bearer setup and any local resource reservation is completed, the following considerations apply: If the receiving terminal is not supporting the SIP precondition, clipping may occur. Furthermore, if the MGCF sets the SDP "inactive" attribute in the initial INVITE request and the receiving terminal is not supporting the SIP precondition and the SIP UPDATE method, the interworking procedures within the present specification do not describe all necessary signalling interactions required to set up a call, in particular with respect to the sending of the re-INVITE that may also cause additional delay in the call setup. In addition, the interworking of the ringing indication might not be possible if the peer sends the ringing indication only as response to a re-INVITE.

The BICC bearer setup is completed when one of the following conditions is met:

– The event Bearer Set-up indication – for the forward bearer set-up case where the incoming Connect Type is "notification not required", which indicate successful completion of bearer set-up, is received by the Incoming bearer set-up procedure (ITU-T Recommendation Q.1902.4 [30] clause 7.5);

– Bearer Set-up Connect indication for the backward call set-up case, which indicate successful completion of bearer set-up, is received by the Incoming bearer set-up procedure (ITU-T Recommendation Q.1902.4 [30] clause 7.5);

– BNC set-up success indication for cases using bearer control tunnelling which indicate successful completion of bearer set-up, is received by the Incoming bearer set-up procedure (ITU-T Recommendation Q.1902.4 [30] clause 7.5).

7.3.3.2.1a Sending of INVITE without determining the end of address signalling

See clause 7.2.3.2.1a.

7.3.3.2.2 Coding of the INVITE
7.3.3.2.2.1 Request-URI and To header field

See clause 7.2.3.2.2.1

7.3.3.2.2.2 SDP Media Description

If the O-MGCF sends the INVITE request without waiting for the BICC bearer setup and any local resource reservation to complete, (which is not recommended according to clause 7.3.3.2.1) it shall indicate that SIP preconditions are not met when the initial INVITE request indicates support of the SIP preconditions.

The O-MGCF shall include the AMR codec transported according to IETF RFC 4867 [23] with the options listed in clause 12.3.1of 3GPP TS 26.114 [104] in the SDP offer. Within the SDP offer, the O-MGCF should also provide SDP RR and RS bandwidth modifiers specified in IETF RFC 3556 [59] as detailed in clause 7.3.1 of 3GPP TS 26.114 [104].

7.3.3.2.2.3 P-Asserted-Identity and privacy header fields

See clause 7.2.3.2.2.3

7.3.3.2.2.3A "cpc" URI Parameter in P-Asserted-Identity Header

See clause 7.2.3.2.2.3A.

7.3.3.2.2.3B "oli" URI Parameter in P-Asserted-Identity Header

See clause 7.2.3.2.2.3B.

7.3.3.2.2.4 Max Forwards header

See clause 7.2.3.2.2.4

7.3.3.2.2.5 IMS Communication Service Identifier

For speech and video calls, the O-MGCF shall insert an IMS Communication Service Identifier, indicating the IMS Multimedia Telephony Communication Service.

The IMS Communication Service Identifier for the IMS Multimedia Telephony Communication Service is defined in 3GPP TS 24.173 [88].

7.3.3.2.2.6 P-Access-Network-Info

See clause 7.2.3.2.2.9.

7.3.3.2.2A Coding of the INVITE when number portability is supported

See clause 7.2.3.2.2A.

7.3.3.2.2B Coding of the INVITE for Carrier Routeing

See clause 7.2.3.2.2B.

7.3.3.2.2C Coding of INVITE with instance-id in form of IMEI URN

See clause 7.2.3.2.2C.

7.3.3.2.2.7 PSAP Call-back indication

See clause 7.2.3.2.2.10.

7.3.3.2.2.8 History-Info header field (optional)

See clause 7.2.3.2.2.11.

7.3.3.2.3 Sending of UPDATE

This clause only applies if the O-MGCF sends the INVITE request before SIP preconditions are met (see clause 7.3.3.2.1).

Figure 30: Receipt of COT (success)

The UPDATE request with a new SDP offer shall be sent for each early SIP dialogue for which the received provisional response indicated support of preconditions confirming that all the required local preconditions have been met when all the following conditions are met.

1. A Continuity message, with the Continuity Indicators parameter set to "continuity check successful" shall be received.

2. The reservation of requested local resources has been completed.

In addition, depending on which bearer set-up procedure used for the call one of the following condition shall be met:

– The event Bearer Set-up indication – for the forward bearer set-up case where the incoming Connect Type is "notification not required", which indicate successful completion of bearer set-up, is received by the Incoming bearer set-up procedure (ITU-T Recommendation Q.1902.4 [30] clause 7.5);

– Bearer Set-up Connect indication for the backward call set-up case, which indicate successful completion of bearer set-up, is received by the Incoming bearer set-up procedure (ITU-T Recommendation Q.1902.4 [30] clause 7.5);

– BNC set-up success indication for cases using bearer control tunnelling which indicate successful completion of bearer set-up, is received by the Incoming bearer set-up procedure, (ITU-T Recommendation Q.1902.4 [30] clause 7.5).

NOTE: This procedure applies regardless of whether the early SIP dialog existed prior to the preconditions being fulfilled or is subsequently created.

7.3.3.2.4 Sending of ACM and Awaiting Answer indication

See clause 7.2.3.2.4

The sending of an awaiting answer indication is described in clause 9.2.3.1. and clause 9.2.3.2.

7.3.3.2.5 Coding of the ACM
7.3.3.2.5.1 Backward call indicators

See clause 7.2.3.2.5.1

7.3.3.2.6 Sending of the Call Progress message (CPG)

See clause 7.2.3.2.6.

7.3.3.2.7 Coding of the CPG
7.3.3.2.7.1 Event information

See clause 7.2.3.2.7.1.

7.3.3.2.7.2 Optional Backward call indicators

See clause 7.2.3.2.7.5.

7.3.3.2.7a Receipt of 200 OK (INVITE)

See clause 7.2.3.2.7a.

7.3.3.2.7b Internal through connection of the bearer path

The through connection procedure is described in clauses 9.2.3.1.7 and 9.2.3.2.7.

7.3.3.2.8 Sending of the Answer Message (ANM)

See clause 7.2.3.2.8.

7.3.3.2.9 Coding of the ANM

See clause 7.2.3.2.9.

7.3.3.2.10 Sending of the Connect message (CON)

See clause 7.2.3.2.10.

7.3.3.2.11 Coding of the CON

See clause 7.2.3.2.11.

7.3.3.2.11.1 Void
7.3.3.2.11A Receipt of re-INVITE requests

See clause 7.2.3.2.11A.

7.3.3.2.12 Receipt of Status Codes 4xx, 5xx or 6xx

See clause 7.2.3.2.12.

7.3 3.2.13 Receipt of a BYE

See clause 7.2.3.2.13.

7.3.3.2.14 Receipt of the Release Message

See clause 7.2.3.2.14.

7.3.3.2.15 Receipt of RSC, GRS or CGB (H/W oriented)

See clause 7.2.3.2.15.

7.3.3.2.16 Out of Band DTMF

If a SIP UA sends DTMF tones to the IM-MGW, the IM-MGW may report this information via the Mn interface to the MGCF. The MGCF shall send to the BICC network the APM message with the following values for the different parameters:

– Action indicator in accordance with the requested DTMF transport function;

– Signal in accordance with which DTMF digit to send;

– Duration in accordance with the required duration of the DTMF digit.

If the BICC network sends an APM message with DTMF signal, duration and action indicator to the MGCF, the MGCF may send this information to the IM-MGW via the Mn interface. The IM-MGW shall send the corresponding DTMF signal and duration information on the user plane of the IM CN subsystem according to 4733 [105].

The interaction with the IM-MGW is shown in clause 9.2.8.

7.3.3.2.17 Sending of CANCEL

See clause 7.2.3.2.18.

7.3.3.2.18 Autonomous Release at O-MGCF

See clause 7.2.3.2.16.

7.3.3.2.19 Special handling of 580 precondition failure received in response to either an INVITE or UPDATE

See clause 7.2.3.2.17.

7.3.3.2.20 Receipt of SIP redirect (3xx) response

See clause 7.2.3.2.19.

7.3.3.2.21 Sending of INFO for overlap signalling using the in-dialog method

See clause 7.2.3.2.20.

7.3.3.3 Timers

See clause 7.2.3.3.