datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Liaison Statement: LS on Clarification of M3UA usage in 3GPP networks

Submission Date: 2008-02-07
From: 3GPP (Susanna Kooistra)
To: IETF (gonzalo.camarillo@ericsson.com)
Cc:
Response Contact: zhaoyuyi@chinamobile.com
Technical Contact: zhaoyuyi@chinamobile.com
Purpose: For action
Deadline: 2008-04-11 Action Taken
Attachments: (none)
Body:
3GPP TSG CT WG4 Meeting #38 	C4-080568
Puerto Vallarta, MEXICO, 28th Jan ¨C 1st Feb 2008


Title:	LS on Clarification of M3UA usage in 3GPP networks
Response to:	
Release:	Rel-8
Work Item:	

Source:	TSG CT WG4
To:	IETF
Cc:	None

Contact Person:	
Name:	Zhao yuyi
Tel. Number:	+86 13901009967
E-mail Address:	zhaoyuyi@chinamobile.com

Attachments:	None.


1. Overall Description:
3GPP defines an IP based SS7 signalling network using M3UA/SCTP/IP as
transport layer, SPs such as HLR, MSC can communicate with each other
directly by accessing to this IP based signalling network.. Address
translation, GTT management, SCTP Association configuration are handled
separately from the basic signalling transport. 

According to 3GPP TR29.801, when deploying a large scale signalling
network based on IP, it is better to separate the network into several
sections, keep the number of SPs in each section in an appropriate
degree. SGs are needed between different sections to simplify the GT
data and converge the SCTP association data. And it is recommended that
M3UA should be used on the SG-SP interface, while M2PA may be used on
the SG- SG interface.

As same as the traditional TDM based  SS7 signalling network, an  IP
based SS7 signalling network also provides signalling network
management functions, such as  signalling traffic management,
signalling link management , and signalling route management, to insure
the availability and traffic transport capacity of a signalling network
 in case of failures and congestion. 

For a large scale signalling network based on IP with SGs , the usage
of  M2PA on  SG- SG interface can help to realize the signalling
network management between  different sections.  But M3UA can not
fulfil the signalling network management within a section completely at
present, the extension of it for this application is needed. The reason
and the proposal for the extension will be discussed in this paper.

 
Figure1: M3UA used within a signalling section


2 The scenarios of M3UA usage in 3GPP networks

Within a section of a large scale signalling network based on IP with
SGs, the normal signalling transport route between two SPs will transit
a SG. When  the destination SP is  not available£¨Scenario 1£©, the SG
must notify the source SP to choose another route. And when the user
part of the  destination SP is  not available £¨Scenario 2£©, the SG
must also notify the source SP to stop the signalling  traffic.

M3UA is designed for SP-(TDM)-SG-(IP)-IP SP and IP SP-(IP)-IP SP
applications, so the network level management function isn¡¯t required.
SSNM(SS7 Signalling Network Management) messages defined in M3UA are
only used for interworking with SS7. M3UA specification doesn¡¯t define
signalling network management function for the IP SP-(IP)-SG-(IP)-IP SP
application.

Scenarios 1: the destination SP is not available

In Scenario 1, when SG1 find   the destination SP (AS,SP2) in IP domain
is  not available, and there is no connection between SG1 and SG2 or
the connection is not available. Assuming there is no signalling
available towards SG2, it is a matter of M3UA spec interpretation
whether SG1 sends or not a DUNA (M3UA) message to SP1 upon failure of
signalling towards SP2. M3UA spec does not prohibit this, but it seems
there is a bit of unclarity on whether SSNM msg can be sent by the SG
in the context of a AS->SG-AS interworking, while it is very clear that
SG can send such message in the context of SEP -> SG -> AS. In result,
the source SP (AS,SP1)  doesn¡¯t  know the route is unavailable  and 
still sends traffic to SG1, which makes  the  signalling  transport
failure.

 
Figure2: Scenario 1 ¨C the destination SP is not available
	

Scenarios 2: the user part of the destination SP is not available

 In Scenario 2, if multiple user parts are associated with single AS in
SP2, M3UA does not allow SP2 to send DUPU to SG1 when the user part of
the destination SP(AS, SP2 ) is  not available, In result, the source
SP (AS,SP1)  doesn¡¯t  know the user part of SP2 is unavailable  and 
still sends traffic to SP2 , which makes  the  signalling  transport
failure.

One solution is to associate a single user part to an AS . So when user
part is unavailable, AS announces that it is unavailable too by sending
DUNA to SG1. SG1 gets aware that AS of SP2 is not available /
inactivated. And then afterwards still a matter of interpretation on
whether SG1 sends or not a DUNA/DUPU to SP1.

In addition ,  DUPU contains no DPC field  to indicate the address of 
the source SP(AS, SP1)  which is the originator of the message( DATA)
that triggered the DUPU.
 

Figure3: Scenario 2 ¨C the user part of the destination SP is not
available

IETF is kindly asked to see if it is necessary to clarify in M3UA RFC
that SSNM messages are sent not only for an interworking between MTP3
to M3UA (SP ¨C > SG -> AS), but also for signalling from M3UA to M3UA
(AS -> SG -> AS), and provide feedbacks to CT4 about this issue.

3. Actions:
To IETF:	1) IETF is kindly asked to see if it is necessary to clarify
in M3UA RFC that SSNM messages are sent not only for an interworking
between MTP3 to M3UA (SP ¨C > SG -> AS), but also for signalling from
M3UA to M3UA (AS -> SG -> AS), and provide feedbacks to CT4 about this
issue.
2) what is IETF¡¯s recommendation to solve the mentioned problem?

4. Date of Next CT4 Meetings:
CT4#38bis (Rel-8)	7th ¨C 11th April 2008	South Korea
CT4#39	5th ¨C 9th May 2008		Cape Town, SOUTH AFRICA