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