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
Source: TSG CT WG4
Name: Zhao yuyi
Tel. Number: +86 13901009967
E-mail Address: firstname.lastname@example.org
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
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.
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