MGCF Principles and Flows

HUAWEI TECHNOLOGIES CO., LTD.

www.huawei.com

HUAWEI Confidential

Security Level:

MGCF Principles and Flows

HUAWEI TECHNOLOGIES CO., LTD. HUAWEI Confidential Page 2

The MGCF is a network entity for

interworking between the IMS domain

and the circuit switched domain (CS).

The logical functional entities (FEs) of

the MGCF are developed based on the

MSOFTX3000.


After studying this course, you will be able to:

Master the networking of the MGCF.

Master the typical service flows in MGCF

networking.


1. Overview of MGCF Networking1. Overview of MGCF Networking

2. MGCF Interworking Model2. MGCF Interworking Model

3. Basic Service Flows of the MGCF3. Basic Service Flows of the MGCF


1. Overview of MGCF Networking1. Overview of MGCF Networking

1.1 Networking of the MGCF

1.2 MGCF

1.3 IM-MGW

1.4 SGW


1.1 Networking of the MGCF

GGSN/MRFP/AS

CSCF

CS network

IM- MGW

MGCF SGW

Mb CS channels

e.g. PCM

BICC/ISUP

ov er MTP Mn

User plane Control plane

BICC/ISUP ov er

SCTP/IP

Mg

BGCF Mj

BICC ov er SCTP/IP


1.2 MGCF

According to 3GPP TS 23.002, the functions of the MGCF are as follows:

The MGCF implements interworking between the control plane in the IMS domain

and the control plane in the CS domain.

The MGCF controls the terminals and media streams carried by the IM-MGW

based on the extended H.248 protocol of 3GPP.

The MGCF and the CS implement intra-MSC call control through ISUP/BICC

signaling.

The MGCF supports the registration and fault recovery of the IM-MGW and can

require the IM-MGW to report the terminal features actively.

The MGCF interworks with the network entities such as the I-CSCF, S-CSCF, and

BGCF in the IMS domain based on the extended SIP protocol of 3GPP.


1.3 IM-MGW

The network entity IM-MGW is interworking equipment between the bearer plane (user plane) in the IMS domain and the bearer plane (user plane) in the CS domain.

The IM-MGW is not responsible for processing any service logic. The IM-MGW supports media conversion, bearer control, and service switching, such as

various voice codecs and ECs. The IM-MGW can accept a resource control command issued by the MGCF through H.248

signaling. The IM-MGW supports AAL2/ATM, TDM, and IP bearer in the CS domain and IP bearer in

the IMS domain.


1.4 SGW

The network entity SGW completes bidirectional conversion (SIGTRAN

M3UA /SCTP/IP <=> SS7 MTP3/2/1) of the signaling protocol stack of the

MTP3 user at the transmission layer between the TDM-based

narrowband SS7 network and the IP-based broadband signaling network.

The SGW performs adaptation for the conversion between broadband

bearer and narrowband bearer for the MTP3-based ISUP messages

related to calls.

Physically, the SGW can be combined with the MGCF or IM-MGW.


Summary

What are the functions of the MGCF?

What are the functions of the IM-MGW?

What are the functions of the SGW?


2. MGCF Interworking Model2. MGCF Interworking Model

2.1 Important Interfaces2.1 Important Interfaces

2.2 Interworking Between SIP and ISUP/BICC2.2 Interworking Between SIP and ISUP/BICC

2.3 Supplementary Services Supported by the 2.3 Supplementary Services Supported by the

MGCFMGCF


2.1.1 Mn Interface

The Mn interface is a standard interface between the MGCF and the IM-

MGW. It is in compliance with the H.248 protocol formulated by ITU-T and

IETF and the definitions of the H.248 extension transaction and package

according to special 3GPP requirements.

The Mn interface provides static and dynamic resource capabilities

(including the terminal attribute, terminal connection and switching

relation, and carried media streams) for the MGCF to control various

transmission modes (IP, ATM, and TDM) of the IM-MGW in the call

processing.

The Mn interface provides the IM-MGW state maintenance and

management capability that is independent of calls.

The protocol message code of the Mn interface adopts the ASN.1 BER or

text mode. The bottom-layer transmission mechanism adopts MTP3B

(ATM-based signaling transmission) or SCTP (IP-based signaling

transmission) to provide protocol bearer.


The Mj interface is a standard interface between the MGCF and the

BGCF. It adopts the SIP protocol extended in 3GPP.

A call originated from the IMS domain is routed to the CS domain through

the Mj interface.

The Mg interface is a standard interface between the MGCF and the I-

CSCF. It adopts the SIP protocol extended in 3GPP.

A call originated from the CS is routed to the IMS domain through the Mg

interface.

2.1.2 Mj and Mg Interfaces


2.1.3 Mb Interface

The Mb interface is an interface between the IM-MGW and the user plane

in the IMS domain. If the IMS is based on the GPRS, the peer entity is the

GGSN.

The Mb interface is based on IP rather than UP. It supports multiple

codec types.


2.2.1 Interworking Between SIP and ISUP

SS7 signaling function

Signaling gateway function

Media gateway control function

SS7

SIP signaling function

SIP

IP IP

SCTP

M3UA

ISUP

TCP / UDP / SCTP

IP L1

SCTP

M3UA

MTP2

MTP3

IP

TCP / UDP / SCTP

SIP

L1

MTP2

MTP3

ISUP

IP IP

ISUP SIP

Control plane interworking between CS networks supporting ISUPand the IM CN subsystem


Scenario for sending an IAM message:

If the ISUP network supports continuity check, the I-MGCF sends an IAM

message immediately after receiving an INVITE message.

If the ISUP network does not support continuity check, the I-MGCF should

postpone sending an IAM message.

2.2.1.1 I-MGCF

INVITE IAM

I-MGCF I-MGCF

INVITE

SDP indicating preconditions met

IAM

Receipt of an INVITE request

(Continuity procedure supported on the ISUP network)

Receipt of an INVITE request

(Continuity procedure not supported on the ISUP network)


2.2.1.1 I-MGCF

The SIP preconditions of the IMS are met.


COT

I-MGCF

Sending of COT


Scenario for sending a 180 ringing message

The I-MGCF receives an ACM message indicating that the callee is idle.

The I-MGCF receives a CPG message carrying the event indicator

Alerting.

2.2.1.1 I-MGCF

180 Ringing

ACM (Subscriber Free)

I-MGCF

CPG (Alerting) 180 (Ringing)

I-MGCF

Receipt of ACM Receipt of CPG (Alerting)


Scenario for sending a 200 OK message:

The I-MGCF receives an ANM message.

The I-MGCF receives a CON message.

2.2.1.1 I-MGCF

ANM 200 OK (INVITE)

I-MGCF

I-MGCF

CON 200 OK (INVITE)

Receipt of ANM

Receipt of CON


Scenario for sending an REL message

The I-MGCF receives a BYE message on the IMS side.

The I-MGCF receives a CANCEL message on the IMS side.

The I-MGCF initiates call release during a call.

2.2.1.1 I-MGCF

BYE REL

I-MGCF I-MGCF

CANCEL REL

Receipt of the Bye method Receipt of Cancel method


Scenario for sending an INVITE message

The O-MGCF receives an IAM message.

The digits of the called number carried in the IAM message are incomplete.

The O-MGCF receives an SAM message subsequently.

2.2.1.2 O-MGCF

IAM

INVITE

O-MGCF

COT (NOTE)

IAM

SAM INVITE

O-MGCF

Receipt of an IAM

(En bloc signaling on the CS network)

Receipt of an IAM

(Overlap signaling on the CS network)


In the case of overlap sending, the digits of a number are incomplete.

2.2.1.2 O-MGCF

IAM

SAM

INVITE

O-MGCF

SAM

INVITE

INVITE

404/484

404/484

Receipt of an IAM (Overlap signaling in CS and IMS network)


Processing after receiving a CONTINUITY message (applicable to only the

case that the COT does not send an INVITE message)

2.2.1.2 O-MGCF


COT(success) ‚9

O-MGCF

Receipt of COT (success)


Scenario for sending an ACM message

The O-MGCF waits until the SAM timer T i/w1 expires on the ISUP side.

The O-MGCF receives a 180 message on the SIP side.

The O-MGCF waits for a 180 message or 200 for INVITE message on the

SIP side, and the timer Ti/w2 expires.

2.2.1.2 O-MGCF


Ring tone

IAM

ACM (no indication)

O-MGCF

T i/w1 running

T i/w1 running

T i/w1 elapses

SAM

SAM

INVITE

180 Ringing ACM (Subscriber Free)

Ring tone

O-MGCF

IAM INVITE

T i/w 2 ACM (no indication)

Ring tone

O-MGCF

2.2.1.2 O-MGCF

Sending of ACM T i/w1 elapses Sending of ACM (Receipt of first 180 ringing)

Sending of ACM (Ti/w2 elapses)


Scenario for sending a CPG message

After sending an Early ACM message, the O-MGCF receives a 180

message and converts it into a CPG message carrying Alerting.

2.2.1.2 O-MGCF

180 Ringing CPG (Alerting)

O-MGCF

Sending of CPG (Alerting)


Scenario for sending an ANM message

After receiving the first 200 for INVITE message, the O-MGCF sends an

ANM message (if an ACM message has been sent) or a CON message (if

an ACM message has not been sent) in the CS domain.

2.2.1.2 O-MGCF

200 OK (INVITE) ANM

O-MGCF

200 OK (INVITE) CON

O-MGCF

Sending of ANM Sending of CON


2.2.2 Interworking Between SIP and BICC




SS7


IP L1

SCTP

M3UA

MTP2

MTP3

IP

TCP/ UDP/ SCTP

SIP

IP IP L1

MTP2

MTP3

BICC

STC SIP

IP IP

SCTP

M3UA TCP/ UDP/ SCTP

BICC

STC

BICC SIP

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






AAL5


IP SSCOP

SCTP

M3UA

SSCF

MTP3B

IP

TCP/ UDP/ SCTP

SIP

IP IP SSCOP

SSCF

MTP3B

BICC

STC SIP

IP IP

SCTP

M3UA TCP/ UDP/ SCTP

BICC

STC

BICC SIP

AAL5 AAL5

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





IP

TCP/ UDP/ SCTP

SIP

IP IP IP

SCTP

M3UA

BICC

STCMTP SIP

IP IP

SCTP

M3UA TCP/ UDP/ SCTP

BICC

STCMTP

BICC SIP


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


2.2.3 Architecture of Interworking Between SIP and R2

SIPSL

CCB

SIPAPP

R2

UMG8900

UMG8900

R2signaling

C&C08

RTP stream

H.248/megaco H.248/megaco

CRO

MGRA

UGC3200

Incoming trunk side

Outgoing trunk side

R2 signaling

CRO

SIP signaling


2.2.3.1 Architecture Flow Chart of Interworking Between SIP and R2

IP network connection

IP network connection

IUALNKIUALNK

30B+D

SX3K

UMG UMGTransmission over E1

UGC3200


2.2.4 Interworking Between SIP and PRA – PRA Primary rate adaptation (PRA): It is a network-user interface on the ISDN network.

Currently, PRA is considered as an inter-MSC trunk that carries inter-MSC calls. PRA

signaling belongs to common channel signaling. PRA signaling has two modes, namely,

the "30B+D" mode and the "23B+D" mode. The difference between the two modes lies in

the transmission media. One is 32-mode E1 transmission and the other is T1

transmission. A group of network-user interface protocols in the ISDN network are DSS1.

PRA is one of the two interface protocols defined by DSS1. The other interface protocol is

basic rate adaptation (BRA). PRA is similar to the A interface, except that the A interface

is an interface between the MSC and the BSC. PRA is an interface between the MSC and

the PBX or another network terminal.

B channel: It is a logical data "pipe" in the ISDN line. It provides the transparent channel of

64 kbit/s. "Transparent channel" means that the bandwidth of the entire B channel is used

to transmit data. The typical application of the B channel is circuit switching. The B

channel can be used to transmit any two-layer or high-layer protocols. Generally, the B

channel of the CSOFTX3000 is used for call connection. It also provides the half-

permanent connection in dedicated line mode.

D channel: It is used to transmit call control signaling and maintenance management

signaling. Compared with the B channel that functions as only a simple "pipe", the D

channel is used to transmit the protocols at layers 2 and 3 in the ISO-OSI model.


2.2.4.1 Interworking Between SIP and the PRA – Overview

The PRA interface specifications include a series of protocols. Corresponding to the

ISO-OSI model, the PRA interface specifications cover the physical layer, data link

layer, and network layer. The following table describes the details.

Protocol Layer

Protocol and Standard Description

Layers 4–7 ITU-T Q.932/Q.950–957 Protocol suite at the application layer

Layer 3 ITU-T Q.931/Q.930 Basic call control protocol

Layer 2 ITU-T Q.921/Q.920 Protocol at the link layer

Layer 1 ITU-T I.431 Protocol at the physical layer


2.2.4.2 Interworking Between SIP and PRA – Position of the PRA Module in the UGC3200

CCB

DOPRA

PRA Module Scope

SIP H.323 ESL ISUP V5 R2

Q931 STACK

ISDN APP

IUA

MGCMGRA CRO DB

TRACE

ALARM

BACK

LOG

MT

MS

LAYER MANAGE


2.2.5 Interworking Between SIP and PRA – Functions of the PRA Module (1) Q931 protocol stack

Responsibilities of the Q931 protocol stack: Completing various functions defined in the Q931 protocol, such as interworking with the IUA

module, event processing at the data link layer, and processing of incorrect conditions Maintaining the state machine for basic call control Implementing restart Implementing state query Exchanging standard Q931 messages at the ISDN application layer

(2) ISDN application layerThe ISDN application layer is responsible for implementing all supplementary services. That is,

Interworking with the CCB through Q931 messages Interworking with the MGW through the CRO Interworking with the DB by processing instant messages Maintaining the state machine for bearer control Maintaining the state machine for supplementary service control Implementing the supplementary services of the PRA moduleIn addition, the ISDN application layer needs to cooperate with ISDN layer management.

(3) ISDN layer managementISDN layer management is responsible for implementing all the maintenance and management functions of the PRA module. That is,

Maintaining the MGW state based on the events reported by the MGC Maintaining the state of PRA trunk circuits Interworking with the MT module Executing maintenance commands and implementing the software debugging function Interworking with ALARM, BACK UP, MS, LOG, and TRACE


CLIP/CLIR: calling line identification presentation/restriction

COLP/COLR: connected line presentation and restriction

Call Hold

CFU/CFB/CFNR: The MGCF supports the interworking of call forwarding

(CF) services in a limited range. (The 3GPP 29163 standard does not

define the interworking of the CF services between the IMS domain and

the CS domain. The CF services are self-defined services.)

Call Barring: The MGCF supports the interworking of the call barring

service with limitations. (The 3GPP 29163 standard does not define the

interworking of the call barring service between the IMS domain and the

CS. The call barring service is a self-defined service. The MGCF supports

only the scenario in which a call is originated by the CS domain to the

IMS domain and the IMS domain instructs call barring.)

2.3 Supplementary Services Supported by the MGCF


2.3.1 Call Hold

MGCF

2. BICC/ISUP: CPG (Hold)

3. SIP: 200 OK [SDP]

1. SIP: UPDATE [SDP, a=sendonly/inactive]

4. SIP: UPDATE [SDP, a=sendrecv/recvonly]

5. BICC/ISUP: CPG (Retrieve)


Session hold/resume initiated from the IM CN subsystem side


2.3.1 Call Hold MGCF

1. BICC/ISUP: CPG (Hold)


2. SIP: UPDATE [SDP, a=sendonly/inactive]

5. SIP: UPDATE [SDP, a=sendrecv/recvonly]

4. BICC/ISUP: CPG (Retrieve)


Session hold/resume initiated from the CS network side


CF services include CFNRy, CFNRc, CFB, and CFU.

2.3.2 CF

MGCF

IAM

Start the CFNRc timer

INVITE

181

Judge the CF type

ACM (CFU/CFNRc)

A call originated from the CS domain to the IMS domain is forwarded unconditionally.

A call originated from the CS domain to the IMS domain is

forwarded because the callee does not answer the call.

MGCF

IAM

Start the CFNRc timer

INVITE

183/PRACK/200 OK

ACM180/PRACK/200 OK

181

If a 181 message is received after an 18X message is received, the

CF service is CFNR.

CPG (CFNR)


2.3.2 CF

MGCF

INVITE

ACM

181

CPG (CFB/CFNR)

A call originated from the IMS domain to the CS domain is forwarded because the

callee does not answer the call or the callee is busy.

MGCF

INVITE

IAM

ACM(CFU)181

A call originated from the IMS domain to the CS domain is forwarded

unconditionally.


2.3.3 Call Barring

MGCF

IAM

INVITE

603REL(Call Reject)

A call is originated from the CS domain to the IMS domain, and the IMS domain

instructs call barring.


3. Basic Service Flows of the MGCF3. Basic Service Flows of the MGCF

3.1 Voice Interworking Between the IMS 3.1 Voice Interworking Between the IMS

Domain and the CS Domain Supported by Domain and the CS Domain Supported by

the MGCFthe MGCF

3.2 Fallback of Video Calls to Voice Between 3.2 Fallback of Video Calls to Voice Between

the IMS Domain and the CS Domain the IMS Domain and the CS Domain

Supported by the MGCFSupported by the MGCF


3.1 Voice Interworking Between the IMS Domain and the CS Domain Supported by the MGCF

MGCF I-CSCF S-CSCF P-CSCF

Add.req/Rsp(C1, T1)

IAM

INVITE(SDP1)

PLMN/PSTN IMS-UE

IM-MGW

Add.req/Rsp(C1, T2)

INVITE(SDP1) INVITE

(SDP1) INVITE(SDP1)

183(SDP2)183

(SDP2)183(SDP2)183

(SDP2)

PRACKPRACK

PRACK

200 for PRACK200 for PRACK

200 for PRACK

Mod.req/Rsp(C1, T2)

180180

180180

PRACKPRACK

PRACK200 for PRACK


ACMMod.req/Rsp

(C1, T1)

200 for INVITE200 for INVITE

200 for INVITE

ACK for 200ACK for 200

ACK for 200

ANMMod.req/Rsp

(C1, T1)


3.2 Fallback of Video Calls to Voice Between the IMS Domain and the CS Domain Supported by the MGCF

P-CSCF S-CSCF BGCF MGCF

Add.req/Rsp(C1, T1)

INVITE(ASDP1,VSDP1)

IMS-UE PLMN/PSTN

IM-MGW

Add.req/Rsp(C1, T2)

INVITE(ASDP1,VSDP1) INVITE

(ASDP1,VSDP1) INVITE(ASDP1,VSDP1)

IAM183

(ASDP2,VSDP2=0)183(ASDP2,VSDP2=0)183

(ASDP2,VSDP2=0)183(ASDP2,VSDP2=0)

PRACKPRACK

PRACK


200 for PRACKACM

180180

180180

PRACKPRACK

PRACK


200 for PRACK ANM200

200200

200



Thank youwww.huawei.com

Documents

MGCF Principles and Flows