draft-ietf-sigtran-m3ua-06.txt   draft-ietf-sigtran-m3ua-07.txt 
Network Working Group Greg Sidebottom (Editor) Network Working Group Greg Sidebottom
INTERNET-DRAFT Guy Mousseau INTERNET-DRAFT Guy Mousseau
Nortel Networks Nortel Networks
Lyndon Ong Lyndon Ong
Point Reyes Networks Ciena
Ian Rytina Ian Rytina
Ericsson Ericsson
Hanns-Juergen Schwarzbauer Hanns Juergen Schwarzbauer
Klaus Gradischnig
Siemens Siemens
Klaus Gradischnig
NeuStar
Ken Morneault Ken Morneault
Cisco Cisco
Mallesh Kalla Mallesh Kalla
Telcordia Telcordia
Normand Glaude Normand Glaude
Performance Technologies Performance Technologies
Expires in six months Feb 2001 Expires in six months Jul 2001
SS7 MTP3-User Adaptation Layer (M3UA) SS7 MTP3-User Adaptation Layer (M3UA)
<draft-ietf-sigtran-m3ua-06.txt> <draft-ietf-sigtran-m3ua-07.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as 'work in progress.' or to cite them other than as 'work in progress.'
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet- Drafts Shadow '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract Abstract
This Internet Draft defines a protocol for supporting the transport of This Internet Draft defines a protocol for supporting the transport of
any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP
using the services of the Stream Control Transmission Protocol. Also, using the services of the Stream Control Transmission Protocol. Also,
provision is made for protocol elements that enable a seamless provision is made for protocol elements that enable a seamless
operation of the MTP3-User peers in the SS7 and IP domains. This
operation of the MTP3-User peers in the SS7 and IP domains. This
protocol would be used between a Signalling Gateway (SG) and a Media protocol would be used between a Signalling Gateway (SG) and a Media
Gateway Controller (MGC) or IP-resident Database. It is assumed that Gateway Controller (MGC) or IP-resident Database. It is assumed that
the SG receives SS7 signalling over a standard SS7 interface using the the SG receives SS7 signalling over a standard SS7 interface using the
SS7 Message Transfer Part (MTP) to provide transport. SS7 Message Transfer Part (MTP) to provide transport.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction.......................................................4 1. Introduction.......................................................4
1.1 Scope.........................................................4 1.1 Scope.........................................................4
1.2 Terminology...................................................4 1.2 Terminology...................................................4
1.3 M3UA Overview.................................................6 1.3 M3UA Overview.................................................6
1.4 Functional Areas.............................................12 1.4 Functional Areas.............................................12
1.5 Sample Configurations........................................23 1.5 Sample Configurations........................................21
1.6 Definition of M3UA Boundaries................................26 1.6 Definition of M3UA Boundaries................................24
2. Conventions.......................................................29 2. Conventions.......................................................28
3. M3UA Protocol Elements............................................29 3. M3UA Protocol Elements............................................28
3.1 Common Message Header........................................29 3.1 Common Message Header........................................28
3.2 Variable-Length Parameter....................................32 3.2 Variable-Length Parameter....................................31
3.3 Transfer Messages............................................33 3.3 Transfer Messages............................................32
3.4 SS7 Signalling Network management (SSNM) Messages............36 3.4 SS7 Signalling Network management (SSNM) Messages............35
3.5 Application Server Process Maintenance (ASPM) Messages.......44 3.5 ASP State Maintenance (ASPM) Messages........................43
3.6 Management Messages..........................................60 3.6 Routing Key Management (RKM) Messages........................46
4. Procedures........................................................63 3.7 ASP Traffic Maintenance (ASPTM) Messages.....................55
4.1 Procedures to Support the Services of the M3UA Layer.........63 3.8 Management(MGMT) Messages....................................60
4.2 Receipt of M3UA Peer Management Messages.....................65 4. Procedures........................................................64
4.3 Procedures to support the M3UA Management services...........66 4.1 Procedures to Support the M3UA-User and Layer Management
4.4 Procedures to Support the M3UA Services......................78 Layers.......................................................64
5. Examples of M3UA Procedures.......................................81 4.2 Procedures to Support the Management of SCTP Associations
with M3UA Peers..............................................67
4.3 Procedures to support the Unavailability or Congestion
Status of SS7 Destinations...................................81
4.4 MTP3 Restart.................................................83
5. Examples of M3UA Procedures.......................................84
5.1 Establishment of Association and Traffic 5.1 Establishment of Association and Traffic
Between SGs and ASPs.........................................81 Between SGs and ASPs.........................................84
5.2 ASP traffic Fail-over Examples...............................86 5.2 ASP traffic Fail-over Examples...............................89
5.3 M3UA/MTP3-User Boundary Examples.............................87 5.3 Normal Withdrawal of an ASP from an Application Server
6. Security..........................................................91 and Tear-down of an Association..............................90
6.1 Introduction.................................................91 5.4.M3UA/MTP3-User Boundary Examples.............................91
6.2 Threats......................................................91 6. Security..........................................................95
6.3 Protecting Confidentiality...................................91 6.1 Introduction.................................................95
7. IANA Considerations...............................................92 6.2 Threats......................................................95
7.1 SCTP Payload Protocol Identifier.............................92 6.3 Protecting Confidentiality...................................95
7.2 M3UA Protocol Extensions.....................................92 7. IANA Considerations...............................................96
8. Acknowledgements..................................................93 7.1 SCTP Payload Protocol Identifier.............................96
9. References........................................................93 7.2 M3UA Protocol Extensions.....................................96
10. Author's Addresses...............................................95 8. Acknowledgements..................................................97
9. References........................................................97
10. Bibliography....................................................99
11. Author's Addresses..............................................99
1. Introduction 1. Introduction
1.1 Scope 1.1 Scope
There is a need for Switched Circuit Network (SCN) signalling protocol There is a need for Switched Circuit Network (SCN) signalling protocol
delivery from an SS7 Signalling Gateway (SG) to a Media Gateway delivery from an SS7 Signalling Gateway (SG) to a Media Gateway
Controller (MGC) or IP-resident Database as described in the Framework Controller (MGC) or IP-resident Database as described in the Framework
Architecture for Signalling Transport [1]. The delivery mechanism Architecture for Signalling Transport [1]. The delivery mechanism
SHOULD meet the following criteria: SHOULD meet the following criteria:
skipping to change at page 4, line 36 skipping to change at page 4, line 36
protocol layers and deliver ISUP, SCCP and/or any other MTP3-User protocol layers and deliver ISUP, SCCP and/or any other MTP3-User
protocol messages, as well as certain MTP network management events, protocol messages, as well as certain MTP network management events,
over SCTP transport associations to MTP3-User peers in MGCs or IP- over SCTP transport associations to MTP3-User peers in MGCs or IP-
resident Databases. resident Databases.
1.2 Terminology 1.2 Terminology
Application Server (AS) - A logical entity serving a specific Routing Application Server (AS) - A logical entity serving a specific Routing
Key. An example of an Application Server is a virtual switch element Key. An example of an Application Server is a virtual switch element
handling all call processing for a unique range of PSTN trunks, handling all call processing for a unique range of PSTN trunks,
identified by an SS7 DPC/OPC/CIC_range. Another example is a virtual identified by an SS7 SIO/DPC/OPC/CIC_range. Another example is a
database element, handling all HLR transactions for a particular SS7 virtual database element, handling all HLR transactions for a
DPC/OPC/SCCP_SSN combination. The AS contains a set of one or more particular SS7 DPC/OPC/SCCP_SSN combination. The AS contains a set of
unique Application Server Processes, of which one or more is normally one or more unique Application Server Processes, of which one or more
actively processing traffic. is normally actively processing traffic. An AS is contained within a
single Network Appearance. Note that there is a 1:1 relationship
between an AS and a Routing Key.
Application Server Process (ASP) - A process instance of an Application Application Server Process (ASP) - A process instance of an Application
Server. An Application Server Process serves as an active or standby Server. An Application Server Process serves as an active or back-up
process of an Application Server (e.g., part of a distributed virtual process of an Application Server (e.g., part of a distributed virtual
switch or database). Examples of ASPs are processes (or process switch or database). Examples of ASPs are processes (or process
instances) of MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP end- instances) of MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP end-
point and may be configured to process signalling traffic within more point and may be configured to process signalling traffic within more
than one Application Server. than one Application Server.
Association - An association refers to an SCTP association. The Association - An association refers to an SCTP association. The
association provides the transport for the delivery of MTP3-User association provides the transport for the delivery of MTP3-User
protocol data units and M3UA adaptation layer peer messages. protocol data units and M3UA adaptation layer peer messages.
IP Server Process (IPSP) - A process instance of an IP-based IP Server Process (IPSP) - A process instance of an IP-based
application. An IPSP is essentially the same as an ASP, except that it application. An IPSP is essentially the same as an ASP, except that it
uses M3UA in a point-to-point fashion. Conceptually, an IPSP does not uses M3UA in a point-to-point fashion. Conceptually, an IPSP does not
use the services of a Signalling Gateway. use the services of a Signalling Gateway.
Signalling Gateway Process (SGP) - A process instance of a Signalling Signalling Gateway Process (SGP) - A process instance of a Signalling
Gateway. It serves as an active, standby or load-sharing process of a Gateway. It serves as an active, back-up or load-sharing process of a
Signalling Gateway. Signalling Gateway.
Signalling Gateway - An SG is a signaling agent that receives/sends SCN
native signaling at the edge of the IP network [1]. An SG appears to
the SS7 network as an SS7 Signalling Point. An SG contains a set of one
or more unique Signalling Gateway Processes, of which one or more is
normally actively processing traffic. Where an SG contains more than
one SGP, the SG is a logical entity and the contained SGPs must be
coordinated into a single management view to the SS7 network and to the
supported Application Servers.
Signalling Process - A process instance that uses M3UA to communicate Signalling Process - A process instance that uses M3UA to communicate
with other signalling process. An ASP, a signalling gateway process with other signalling process. An ASP, an SGP and an IPSP are all
and an IPSP are all signalling processes. signalling processes.
Routing Key: A Routing Key describes a set of SS7 parameters and Routing Key: A Routing Key describes a set of SS7 parameters and
parameter values that uniquely define the range of signalling traffic parameter values that uniquely define the range of signalling traffic
to be handled by a particular Application Server. Parameters within the to be handled by a particular Application Server. Parameters within the
Routing Key cannot extend across more than a single SS7 Destination Routing Key cannot extend across more than a single SS7 Destination
Point Code. Point Code.
Routing Context - A value that uniquely identifies a Routing Key. Routing Context - A value that uniquely identifies a Routing Key.
Routing Context values are either configured using a configuration Routing Context values are either configured using a configuration
management interface, or by using the routing key management procedures management interface, or by using the routing key management procedures
skipping to change at page 5, line 53 skipping to change at page 6, line 16
the SG availability / congestion / User_Part status must also be taken the SG availability / congestion / User_Part status must also be taken
into account when considering any supporting MTP3 management actions. into account when considering any supporting MTP3 management actions.
MTP - The Message Transfer Part of the SS7 protocol. MTP - The Message Transfer Part of the SS7 protocol.
MTP3 - MTP Level 3, the signalling network layer of SS7 MTP3 - MTP Level 3, the signalling network layer of SS7
MTP3-User - Any protocol normally using the services of the SS7 MTP3 MTP3-User - Any protocol normally using the services of the SS7 MTP3
(e.g., ISUP, SCCP, TUP, etc.). (e.g., ISUP, SCCP, TUP, etc.).
Network Appearance - The Network Appearance identifies an SS7 network Network Appearance The Network Appearance uniquely identifies an SS7
context for the purposes of logically separating the signalling traffic entity (Point Code) into an SS7 network, as presented by the SG. It is
used for the purposes of logically separating the signalling traffic
between the SG and the Application Server Processes over a common SCTP between the SG and the Application Server Processes over a common SCTP
Association. An example is where an SG is logically partitioned to association. This partitioning is necessary where an SG is logically
appear as an element in four separate national SS7 networks. A Network partitioned to appear as end node elements in multiple separate SS7
Appearance implicitly defines the SS7 Point Code(s), Network Indicator networks, in which case there is a separate network appearance for each
and MTP3 protocol type/variant/version used within a specific SS7 point code in the SS7 networks. It is also necessary when an SG is
network partition. A physical SS7 route-set or link-set at an SG can configured as an STP hosting multiple point codes, or when configured
appear in only one network appearance. The Network Appearance is not as multiple end nodes within the same network, in which case each point
globally significant and requires coordination only between the SG and code is a separate network appearance.between the SG and the
the ASP. Therefore, in the case where an ASP is connected to more than Application Server Processes over a common SCTP Association. An
one SG, the same SS7 network context may be identified by different example is where an SG is logically partitioned to appear as an element
Network Appearances depending over which SG a message is being in four separate national SS7 networks. A Network Appearance
transmitted/received. implicitly defines the SS7 Point Code(s), Network Indicator and MTP3
protocol type/variant/version used within a specific SS7 network
partition.
Network Byte Order: Most significant byte first, a.k.a Big Endian. Network Byte Order: Most significant byte first, a.k.a Big Endian.
Layer Management - Layer Management is a nodal function that handles Layer Management - Layer Management is a nodal function that handles
the inputs and outputs between the M3UA layer and a local management the inputs and outputs between the M3UA layer and a local management
entity. entity.
Host - The computing platform that the ASP process is running on. Host - The computing platform that the ASP process is running on.
Stream - A stream refers to an SCTP stream; a uni-directional logical Stream - A stream refers to an SCTP stream; a uni-directional logical
skipping to change at page 6, line 48 skipping to change at page 7, line 15
services expected by a particular SCN signalling protocol from its services expected by a particular SCN signalling protocol from its
underlying protocol layer. underlying protocol layer.
Within the framework architecture, this document defines an MTP3-User Within the framework architecture, this document defines an MTP3-User
adaptation module suitable for supporting the transfer of messages of adaptation module suitable for supporting the transfer of messages of
any protocol layer that is identified to the MTP Level 3 layer, in SS7 any protocol layer that is identified to the MTP Level 3 layer, in SS7
terms, as a user part. The list of these protocol layers include, but terms, as a user part. The list of these protocol layers include, but
is not limited to, ISDN User Part (ISUP) [2,3,4], Signalling Connection is not limited to, ISDN User Part (ISUP) [2,3,4], Signalling Connection
Control Part (SCCP) [5,6,7] and Telephone User Part (TUP) [8]. TCAP Control Part (SCCP) [5,6,7] and Telephone User Part (TUP) [8]. TCAP
[9,10,11] or RANAP [12] messages are transferred transparently by the [9,10,11] or RANAP [12] messages are transferred transparently by the
M3UA as SCCP payload, as they are SCCP-User protocols. M3UA protocol as SCCP payload, as they are SCCP-User protocols.
It is recommended that the M3UA use the services of the Stream Control It is recommended that M3UA use the services of the Stream Control
Transmission Protocol (SCTP) [13] as the underlying reliable common Transmission Protocol (SCTP) [13] as the underlying reliable common
signalling transport protocol. This is to take advantage of various signalling transport protocol. This is to take advantage of various
SCTP features such as: SCTP features such as:
- Explicit packet-oriented delivery (not stream-oriented); - Explicit packet-oriented delivery (not stream-oriented),
- Sequenced delivery of user messages within multiple streams, - Sequenced delivery of user messages within multiple streams,
with an option for order-of-arrival delivery of individual with an option for order-of-arrival delivery of individual
user messages, user messages,
- Optional multiplexing of user messages into SCTP datagrams; - Optional multiplexing of user messages into SCTP datagrams,
- Network-level fault tolerance through support of multi-homing - Network-level fault tolerance through support of multi-homing
at either or both ends of an association; at either or both ends of an association,
- Resistance to flooding and masquerade attacks; and - Resistance to flooding and masquerade attacks, and
- Data segmentation to conform to discovered path MTU size. - Data segmentation to conform to discovered path MTU size.
Under certain scenarios, such as back-to-back connections without Under certain scenarios, such as back-to-back connections without
redundancy requirements, the SCTP functions above MAY NOT be a redundancy requirements, the SCTP functions above MAY NOT be a
requirement and TCP can be used as the underlying common transport requirement and TCP can be used as the underlying common transport
protocol. protocol.
1.3.2 Services Provided by the M3UA Layer 1.3.2 Services Provided by the M3UA Layer
The M3UA Layer at an ASP or IPSP provides the equivalent set of The M3UA Layer at an ASP or IPSP provides the equivalent set of
primitives at its upper layer to the MTP3-Users as provided by the MTP primitives at its upper layer to the MTP3-Users as provided by the MTP
Level 3 to its local MTP3-Users at an SS7 SEP. In this way, the ISUP Level 3 to its local MTP3-Users at an SS7 SEP. In this way, the ISUP
and/or SCCP layer at an ASP or IPSP is unaware that the expected MTP3 and/or SCCP layer at an ASP or IPSP is unaware that the expected MTP3
services are offered remotely from an MTP3 Layer at an SG, and not by a services are offered remotely from an MTP3 Layer at an SGP, and not by
local MTP3 layer. The MTP3 layer at an SG may also be unaware that its a local MTP3 layer. The MTP3 layer at an SGP may also be unaware that
local users are actually remote user parts over M3UA. In effect, the its local users are actually remote user parts over M3UA. In effect,
M3UA extends access to the MTP3 layer services to a remote IP-based the M3UA extends access to the MTP3 layer services to a remote IP-based
application. The M3UA does not itself provide the MTP3 services. application. The M3UA layer does not itself provide the MTP3 services.
However, in the case where an ASP is connected to more than one SG, the However, in the case where an ASP is connected to more than one SGP,
M3UA Layer at an ASP must maintain the status of configured SS7 the
destinations and route messages according to the availability / M3UA layer at an ASP must maintain the status of configured SS7
congestion status of the routes to these destinations via each SG. destinations and route messages according to the availability and
congestion status of the routes to these destinations via each SGP.
The M3UA Layer may also be used for point-to-point signalling between The M3UA layer may also be used for point-to-point signalling between
two IP Server Processes (IPSPs). In this case, the M3UA provides the two IP Server Processes (IPSPs). In this case, the M3UA layer provides
same set of primitives and services at its upper layer as the MTP3. the same set of primitives and services at its upper layer as the MTP3.
However, in this case the expected MTP3 services are not offered However, in this case the expected MTP3 services are not offered
remotely from an SG. The MTP3 services are provided but the procedures remotely from an SGP. The MTP3 services are provided but the
to support these services are a subset of the MTP3 procedures due to procedures to support these services are a subset of the MTP3
the simplified point-to-point nature of the IPSP to IPSP relationship. procedures due to the simplified point-to-point nature of the IPSP to
IPSP relationship.
1.3.2.1 Support for the transport of MTP3-User Messages 1.3.2.1 Support for the Transport of MTP3-User Messages
The M3UA provides the transport of MTP-TRANSFER primitives across an The M3UA layer provides the transport of MTP-TRANSFER primitives across
established SCTP association between an SG and an ASP or between IPSPs. an established SCTP association between an SGP and an ASP or between
IPSPs.
The MTP-TRANSFER primitive information is encoded as in MTP3-User The MTP-TRANSFER primitive information is encoded as in MTP3-User
messages. In this way, the SCCP and ISUP messages received from the messages. In this way, the SCCP and ISUP messages received from the
SS7 network by the SG are not re-encoded into a different format for SS7 network by the SGP are not re-encoded into a different format for
transport between the M3UA peers. The MTP3 Service Information Octet transport between the M3UA peers. The MTP3 Service Information Octet
(SIO) and Routing Label (OPC, DPC, and SLS) are included, encoded as (SIO) and Routing Label (OPC, DPC, and SLS) are included, encoded as
expected by the MTP3 and MTP3-User protocol layer. expected by the MTP3 and MTP3-User protocol layer.
At an ASP, in the case where a destination is reachable via multiple At an ASP, in the case where a destination is reachable via multiple
SGs, the M3UA must also choose via which SG the message is to be routed SGPs, the M3UA layer must also choose via which SGP the message is to
or support load balancing across the SGs, ensuring that no mis- be routed or support load balancing across the SGPs, ensuring that no
sequencing occurs. missequencing occurs.
The M3UA does not impose a 272-octet signaling information field (SIF) The M3UA layer does not impose a 272-octet signalling information field
length limit as specified by the SS7 MTP Level 2 protocol [14] [15] (SIF) length limit as specified by the SS7 MTP Level 2 protocol [14]
[16]. Larger information blocks can be accommodated directly by [15] [16]. Larger information blocks can be accommodated directly by
M3UA/SCTP, without the need for an upper layer segmentation/re-assembly M3UA/SCTP, without the need for an upper layer segmentation/re-assembly
procedure as specified in recent SCCP or ISUP versions. However, in procedure as specified in recent SCCP or ISUP versions. However, in
the context of an SG, the maximum 272-octet block size must be followed the context of an SG, the maximum 272-octet block size must be followed
when inter-working to a SS7 network that does not support the transfer when inter-working to a SS7 network that does not support the transfer
of larger information blocks to the final destination. This avoids of larger information blocks to the final destination. This avoids
potential ISUP or SCCP fragmentation requirements at the SG. However, potential ISUP or SCCP fragmentation requirements at the SGPs.
if the SS7 network is provisioned to support the Broadband MTP [20] to However, if the SS7 network is provisioned to support the Broadband MTP
the final SS7 destination, the information block size limit may be [20] to the final SS7 destination, the information block size limit may
increased past 272 octets. be increased past 272 octets.
1.3.2.2 Native Management Functions 1.3.2.2 Native Management Functions
The M3UA provides management of the underlying SCTP transport protocol The M3UA layer provides management of the underlying SCTP transport
to ensure that SG-ASP and IPSP-IPSP transport is available to the protocol to ensure that SGP-ASP and IPSP-IPSP transport is available to
degree called for by the MTP3-User signalling applications. the degree called for by the MTP3-User signalling applications.
The M3UA provides the capability to indicate errors associated with The M3UA layer provides the capability to indicate errors associated
received M3UA messages and to notify, as appropriate, local management with received M3UA messages and to notify, as appropriate, local
and/or the peer M3UA. management and/or the peer M3UA.
1.3.2.3 Inter-working with MTP3 Network Management Functions 1.3.2.3 Inter-working with MTP3 Network Management Functions
At the SG, the M3UA must also provide inter-working with MTP3 At the SGP, the M3UA layer must also provide inter-working with MTP3
management functions to support seamless operation of the user SCN management functions to support seamless operation of the user SCN
signalling applications in the SS7 and IP domains. This includes: signalling applications in the SS7 and IP domains. This includes:
- Providing an indication to MTP3-Users at an ASP that a remote - Providing an indication to MTP3-Users at an ASP that a remote
destination in the SS7 network is not reachable. destination in the SS7 network is not reachable.
- Providing an indication to MTP3-Users at an ASP that a remote - Providing an indication to MTP3-Users at an ASP that a remote
destination in the SS7 network is now reachable. destination in the SS7 network is now reachable.
- Providing an indication to MTP3-Users at an ASP that messages to a - Providing an indication to MTP3-Users at an ASP that messages to a
remote MTP3-User peer in the SS7 network are experiencing SS7 remote destination in the SS7 network are experiencing SS7
congestion. congestion.
- Providing an indication to MTP3-Users at an ASP that the routes to - Providing an indication to the M3UA layer at an ASP that the routes
a remote MTP3-User peer in the SS7 network are restricted. to a remote destination in the SS7 network are restricted.
- Providing an indication to MTP3-Users at an ASP that a remote MTP3- - Providing an indication to MTP3-Users at an ASP that a remote MTP3-
User peer is unavailable. User peer is unavailable.
The M3UA layer at an ASP may initiate an audit of the availability, the The M3UA layer at an ASP may initiate an audit of the availability, the
restricted or the congested state of remote SS7 destinations. This restricted or the congested state of remote SS7 destinations. This
information is requested from the M3UA at the SG. information is requested from the M3UA layer at the SGP.
The M3UA layer at an ASP may also indicate to the SG that the M3UA The M3UA layer at an ASP may also indicate to the SG that the M3UA
itself or the ASP or the ASP's Host is congested. layer itself or the ASP or the ASP's Host is congested.
1.3.2.4 Support for the management of SCTP associations between the SG 1.3.2.4 Support for the Management of SCTP Associations between the SGP
and ASPs. and ASPs.
The M3UA layer at the SG maintains the availability state of all The M3UA layer at the SGP maintains the availability state of all
configured remote ASPs, in order to manage the SCTP Associations and configured remote ASPs, in order to manage the SCTP Associations and
the traffic between the M3UA peers. As well, the active/inactive and the traffic between the M3UA peers. As well, the active/inactive and
congestion state of remote ASPs is maintained. congestion state of remote ASPs is maintained.
The M3UA layer MAY be instructed by local management to establish an The M3UA layer MAY be instructed by local management to establish an
SCTP association to a peer M3UA node. This can be achieved using the SCTP association to a peer M3UA node. This can be achieved using the
M-SCTP ESTABLISH primitive to request, indicate and confirm the M-SCTP_ESTABLISH primitives to request, indicate and confirm the
establishment of an SCTP association with a peer M3UA node. In order establishment of an SCTP association with a peer M3UA node. In order
to avoid redundant SCTP associations between two M3UA peers, one side to avoid redundant SCTP associations between two M3UA peers, one side
(client) must be designated to establish the SCTP association, or M3UA (client) SHOULD be designated to establish the SCTP association, or
configuration knowledge maintained to detect redundant associations M3UA configuration knowledge maintained to detect redundant
(e.g., via knowledge of the expected local and remote SCTP endpoint associations (e.g., via knowledge of the expected local and remote SCTP
addresses). endpoint addresses).
The M3UA layer MAY also need to inform local management of the status Local management MAY request from the M3UA layer the status of the
of the underlying SCTP associations using the M-SCTP STATUS request and underlying SCTP associations using the M-SCTP_STATUS request and
indication primitive. For example, the M3UA MAY inform local management
of the reason for the release of an SCTP association, determined either
locally within the M3UA layer or by a primitive from the SCTP.
Also the M3UA layer may need to inform the local management of the confirm primitives. Also, the M3UA MAY autonomously inform local
change in status of an ASP or AS. This may be achieved using the M-ASP management of the reason for the release of an SCTP association,
STATUS request or M-AS STATUS request primitives. determined either locally within the M3UA layer or by a primitive from
the SCTP.
1.3.2.5 Support for the management of connections to multiple SGs Also the M3UA layer MAY inform the local management of the change in
status of an ASP or AS. This may be achieved using the M-ASP_request
or M-AS_STATUS request primitives.
As shown in Figure 1 an ASP may be connected to multiple SGs. In such a 1.3.2.5 Support for the Management of Connections to Multiple SGPs
case a particular SS7 destination may be reachable via more than SG,
i.e., via more than one route. As MTP3 users only maintain status on a As shown in Figure 1 an ASP may be connected to multiple SGPs. In such
destination and not on a route basis, M3UA must maintain the status a case a particular SS7 destination may be reachable via more than one
(availability, restriction, and/or congestion of route to destination) SGP, i.e., via more than one route. As MTP3 users only maintain status
of the individual routes, derive the overall availability or congestion on a destination and not on a route basis, the M3UA layer must maintain
status of the destination from the status of the individual routes, and the status (availability, restriction, and/or congestion of route to
inform the MTP3 users of this derived status whenever it changes. destination) of the individual routes, derive the overall availability
or congestion status of the destination from the status of the
individual routes, and inform the MTP3 users of this derived status
whenever it changes.
1.3.3 Signalling Network Architecture 1.3.3 Signalling Network Architecture
A Signalling Gateway is used to support the transport of MTP3-User A Signalling Gateway is used to support the transport of MTP3-User
signalling traffic received from the SS7 network to multiple signalling traffic received from the SS7 network to multiple
distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA
protocol is not designed to meet the performance and reliability protocol is not designed to meet the performance and reliability
requirements for such transport by itself. However, the conjunction of requirements for such transport by itself. However, the conjunction of
distributed architecture and redundant networks does allow for a distributed architecture and redundant networks does allow for a
sufficiently reliable transport of signalling traffic over IP. The sufficiently reliable transport of signalling traffic over IP. The
M3UA protocol is flexible enough to allow its operation and management M3UA protocol is flexible enough to allow its operation and management
in a variety of physical configurations, enabling Network Operators to in a variety of physical configurations, enabling Network Operators to
meet their performance and reliability requirements. meet their performance and reliability requirements.
To meet the stringent SS7 signalling reliability and performance To meet the stringent SS7 signalling reliability and performance
skipping to change at page 10, line 18 skipping to change at page 10, line 43
distributed architecture and redundant networks does allow for a distributed architecture and redundant networks does allow for a
sufficiently reliable transport of signalling traffic over IP. The sufficiently reliable transport of signalling traffic over IP. The
M3UA protocol is flexible enough to allow its operation and management M3UA protocol is flexible enough to allow its operation and management
in a variety of physical configurations, enabling Network Operators to in a variety of physical configurations, enabling Network Operators to
meet their performance and reliability requirements. meet their performance and reliability requirements.
To meet the stringent SS7 signalling reliability and performance To meet the stringent SS7 signalling reliability and performance
requirements for carrier grade networks, Network Operators SHOULD requirements for carrier grade networks, Network Operators SHOULD
ensure that no single point of failure is present in the end-to-end ensure that no single point of failure is present in the end-to-end
network architecture between an SS7 node and an IP-based application. network architecture between an SS7 node and an IP-based application.
This can typically be achieved through the use of redundant SGs, This can typically be achieved through the use of redundant SGPs or
redundant hosts, and the provision of redundant QOS-bounded IP network SGs, redundant hosts, and the provision of redundant QOS-bounded IP
paths for SCTP Associations between SCTP End Points. Obviously, the network paths for SCTP Associations between SCTP End Points. Obviously,
reliability of the SG, the MGC and other IP-based functional elements the reliability of the SG, the MGC and other IP-based functional
also needs to be taken into account. The distribution of ASPs within elements also needs to be taken into account. The distribution of ASPs
the available Hosts must also be considered. As an example, for a and SGPs within the available Hosts SHOULD also be considered. As an
particular Application Server, the related ASPs should be distributed example, for a particular Application Server, the related ASPs SHOULD
over at least two Hosts. be distributed over at least two Hosts.
One example of a physical network architecture relevant to SS7 carrier- One example of a physical network architecture relevant to SS7 carrier-
grade operation in the IP network domain is shown in Figure 1 below: grade operation in the IP network domain is shown in Figure 1 below:
SG MGC SG MGC
Host#1 ************** ************** Host#1 Host#1 ************** ************** Host#3
= * ********__*__________________________*__******** * = = * ********__*__________________________*__******** * =
SG1 * * SGP1 *__*_____ _______________*__* ASP1 * * MGC1 * * SGP1 *__*_____ _______________*__* ASP1 * * MGC1
* ******** * \ / * ******** * * ******** * \ / * ******** *
* ********__*______\__/________________*__******** * * ********__*______\__/________________*__******** *
* * SGP2 *__*_______\/______ _____*__* ASP2 * * * * SGP2 *__*_______\/______ _____*__* ASP2 * *
* ******** * /\ | | * ******** * * ******** * /\ | | * ******** *
* : * / \ | | * : * * : * / \ | | * : *
* ******** * / \ | | * ******** * * ******** * / \ | | * ******** *
* * SGPn * * | | | | * * ASPn * * * * SGPn * * | | | | * * ASPn * *
* ******** * | | | | * ******** * * ******** * | | | | * ******** *
************** | | | | ************** ************** | | | | **************
| | \ / | | \ /
Host#2 ************** | | \ / ************** Host#2 Host#2 ************** | | \ / ************** Host#4
= * ********__*_____| |______\/_______*__******** * = = * ********__*_____| |______\/_______*__******** * =
SG2 * * SGP1 *__*_________________/\_______*__* ASP1 * * MGC2 * * SGP1 *__*_________________/\_______*__* ASP1 * * MGC2
* ******** * / \ * ******** * * ******** * / \ * ******** *
* ********__*_______________/ \_____*__******** * * ********__*_______________/ \_____*__******** *
* * SGP2 *__*__________________________*__* ASP2 * * * * SGP2 *__*__________________________*__* ASP2 * *
* ******** * * ******** * * ******** * * ******** *
* : * SCTP Associations * : * * : * SCTP Associations * : *
* ******** * * ******** * * ******** * * ******** *
* * SGPn * * * * ASPn * * * * SGPn * * * * ASPn * *
* ******** * * ******** * * ******** * * ******** *
************** ************** ************** **************
Figure 1 - Physical Model Figure 1 - Physical Model
In this model, each host has many application processes. In the case In this model, each host has many application processes. In the case
of the MGC, an ASP may provide service to one or more application of the MGC, an ASP may provide service to one or more Application
server, and is identified as an SCTP end point. In the case of the SG, Servers, and is identified as an SCTP end point. A pair of signalling
a pair of signalling gateway processes may represent, as an example, a gateway processes may represent, as an example, a single Signalling
single network appearance, serving a signalling point management Gateway, serving a signalling point management cluster.
cluster.
This example model can also be applied to IPSP-IPSP signalling. In This example model can also be applied to IPSP-IPSP signalling. In
this case, each IPSP would have its services distributed across 2 hosts this case, each IPSP would have its services distributed across 2 hosts
or more, and may have multiple server processes on each host. or more, and may have multiple server processes on each host.
In the example above, each signalling process (SGP, ASP or IPSP) is the In the example above, each signalling process (SGP, ASP or IPSP) is the
end point to more than one SCTP association, leading to many other end point to more than one SCTP association, leading to many other
signalling processes. To support this, a signalling process must be signalling processes. To support this, a signalling process must be
able to support distribution of M3UA messages to many simultaneous able to support distribution of M3UA messages to many simultaneous
active associations. This message distribution function is based on active associations. This message distribution function is based on
skipping to change at page 12, line 26 skipping to change at page 12, line 26
the exact layout of the network elements, the message distribution the exact layout of the network elements, the message distribution
algorithms and the distribution of the signalling processes. Instead, algorithms and the distribution of the signalling processes. Instead,
it provides a framework and a set of messages that allow for a flexible it provides a framework and a set of messages that allow for a flexible
and scalable signalling network architecture, aiming to provide and scalable signalling network architecture, aiming to provide
reliability and performance. reliability and performance.
1.4 Functional Areas 1.4 Functional Areas
1.4.1 Signalling Point Code Representation 1.4.1 Signalling Point Code Representation
Within an SS7 network, a Signalling Gateway is charged with For example, within an SS7 network, a Signalling Gateway might be
representing a set of nodes in the IP domain into the SS7 network for charged with representing a set of nodes in the IP domain into the SS7
routing purposes. The SG itself, as a physical node in the SS7 network for routing purposes. The SG itself, as a signalling point in
network, must be addressable with an SS7 Point Code for MTP3 Management the SS7 network, might also be addressable with an SS7 Point Code for
purposes. The SG Point Code is also used for addressing any local MTP3- MTP3 Management purposes. The SG Point Code might also used for
Users at the SG such as an SG-resident SCCP function. addressing any local MTP3-Users at the SG such as an SG-resident SCCP
function.
An SG may be logically partitioned to operate in multiple SS7 network An SG may be logically partitioned to operate in multiple SS7 network
Appearances. In such a case, the SG must be addressable with a Point appearances. In such a case, the SG must be addressable with a Point
Code in each network appearance, and represents a set of nodes in the Code in each network appearance, and represents a set of nodes in the
IP domain into each SS7 network. Alias Point Codes [15] may also be IP domain into each SS7 network. Alias Point Codes [15] may also be
used within an SG network appearance. used within an SG network appearance.
Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
remote AS/ASP states of each SGP SHOULD be coordinated across all the
SGPs. Re-routing of traffic between the SGPs SHOULD also be supported
The M3UA places no restrictions on the SS7 Point Code representation of The M3UA places no restrictions on the SS7 Point Code representation of
an AS. Application Servers can be represented under the same Point an AS. Application Servers can be represented under the same Point
Code of the SG, their own individual Point Codes or grouped with other Code of the SG, their own individual Point Codes or grouped with other
Application Servers for Point Code preservation purposes. A single Application Servers for Point Code preservation purposes. A single
Point Code may be used to represent the SG and all the Application Point Code may be used to represent the SG and all the Application
Servers together, if desired. Servers together, if desired.
Where Application Servers are grouped under a Point Code address, an
SPMC will include more than one AS. If full advantage of SS7 management
procedures is to be taken (as is advisable in carrier grade networks)
care must be taken that, if one AS of an SPMC becomes unavailable, all
Application Servers of the SPMC become unavailable from the SG.
Otherwise, usage of SS7 transfer prohibited procedures by the SG
becomes problematic as either traffic to the unavailable AS cannot be
stopped/diverted or traffic to a still available AS will be
unnecessarily stopped/diverted. (Depending on the network configuration
it may even be necessary to assign an individual SS7 point code to each
AS.)
Observing this principle is of particular importance if alternative
routing possibilities exist on the SS7 level (e.g. via mated SGs) or
application level (e.g. via another MGC/MG).
If an ASP or group of ASPs is available to the SS7 network via more If an ASP or group of ASPs is available to the SS7 network via more
than one SG, each with its own Point Code, the ASP(s) should be than one SG, each with its own Point Code, the ASP(s) should be
represented by a Point Code that is separate from any SG Point Code. represented by a Point Code that is separate from any SG Point Code.
This allows these SGs to be viewed from the SS7 network as "STPs", each This allows these SGs to be viewed from the SS7 network as "STPs", each
having an ongoing "route" to the same ASP(s). Under failure
conditions where the ASP(s) become(s) unavailable from one of the SGs,
this approach enables MTP3 route management messaging between the SG
and SS7 network, allowing simple SS7 re-routing through an alternate SG
without changing the Destination Point Code Address of SS7 traffic to
the ASP(s).
Where an AS can be reached via more than one SG it is equally important having an ongoing "route" to the same ASP(s). Under failure conditions
that the corresponding Routing Keys in the involved SGs are identical. where the ASP(s) become(s) unavailable from one of the SGs, this
(Note: It is possible for the Routing Key configuration data to be approach enables MTP3 route management messaging between the SG and SS7
temporarily out-of-synch during configuration updates). network, allowing simple SS7 re-routing through an alternate SG without
changing the Destination Point Code Address of SS7 traffic to the
ASP(s).
Where an AS can be reached via more than one SGP it is equally
important that the corresponding Routing Keys in the involved SGPs are
identical. (Note: It is possible for the SGP Routing Key configuration
data to be temporarily out-of-synch during configuration updates).
+--------+ +--------+
| | | |
+------------+ SG 1 +--------------+ +------------+ SG 1 +--------------+
+-------+ | SS7 links | "STP" | IP network | ---- +-------+ | SS7 links | "STP" | IP network | ----
| SEP +---+ +--------+ +---/ \ | SEP +---+ +--------+ +---/ \
| or | | ASPs | | or | * | ASPs |
| STP +---+ +--------+ +---\ / | STP +---+ +--------+ +---\ /
+-------+ | | | | ---- +-------+ | | | | ----
+------------+ SG 2 +--------------+ +------------+ SG 2 +--------------+
| "STP" | | "STP" |
+--------+ +--------+
Note: there is no SG-to-SG communication shown, so each SG can be * Note:. SG-to SG communication is recommended for carrier grade
reached only via the direct linkset from the SS7 network. networks, using an MTP3 linkset or an equivalent, to allow re-routing
between the SGs in the event of route failures. Where SGPs are used,
inter-SGP communication is recommended. Inter-SGP protocol is outside
of the scope of this document.
The following example shows a signalling gateway partitioned into two The following example shows a signalling gateway partitioned into two
network appearances. network appearances.
SG SG
+-------+ +---------------+ +-------+ +---------------+
| SEP +--------------| SS7 Ntwk |M3UA| ---- | SEP +--------------| SS7 Ntwk |M3UA| ----
+-------+ SS7 links | "A" | | / \ +-------+ SS7 links | "A" | | / \
|__________| +-----------+ ASPs | |__________| +-----------+ ASPs |
| | | \ / | | | \ /
+-------+ | SS7 Ntwk | | ---- +-------+ | SS7 Ntwk | | ----
| SEP +--------------+ "B" | | | SEP +--------------+ "B" | |
+-------+ +---------------+ +-------+ +---------------+
1.4.2 Routing Contexts and Routing Keys 1.4.2 Routing Contexts and Routing Keys
1.4.2.1 Overview 1.4.2.1 Overview
The distribution of SS7 messages between the SG and the Application The distribution of SS7 messages between the SGP and the Application
Servers is determined by the Routing Keys and their associated Routing Servers is determined by the Routing Keys and their associated Routing
Contexts. A Routing Key is essentially a set of SS7 parameters used to Contexts. A Routing Key is essentially a set of SS7 parameters used to
filter SS7 messages, whereas the Routing Context parameter is a 4-byte filter SS7 messages, whereas the Routing Context parameter is a 4-byte
value (integer) that is associated to that Routing Key in a 1:1 value (integer) that is associated to that Routing Key in a 1:1
relationship. The Routing Context therefore can be viewed as an index relationship. The Routing Context therefore can be viewed as an index
into a sending node's Message Distribution Table containing the Routing into a sending node's Message Distribution Table containing the Routing
Key entries. Key entries.
Possible SS7 address/routing information that comprise a Routing Key Possible SS7 address/routing information that comprise a Routing Key
entry includes, for example, the OPC, DPC, SIO found in the MTP3 entry includes, for example, the OPC, DPC, SIO found in the MTP3
routing label, or other MTP3-User specific fields such as the ISUP CIC, routing label, or MTP3-User specific fields such as the ISUP CIC, SCCP
SCCP subsystem number, or TCAP transaction ID. Some example Routing subsystem number, or TCAP transaction ID. Some example Routing Keys
Keys are: the DPC alone, the DPC/OPC combination, the DPC/OPC/CIC are: the DPC alone, the DPC/OPC combination, the DPC/OPC/CIC
combination, or the DPC/SSN combination. The particular information combination, or the DPC/SSN combination. The particular information
used to define an M3UA Routing Key is application and network used to define an M3UA Routing Key is application and network
dependent, and none of the above examples are mandated. dependent, and none of the above examples are mandated.
An Application Server Process may be configured to process signalling An Application Server Process may be configured to process signalling
traffic related to more than one Application Server, over a single SCTP traffic related to more than one Application Server, over a single SCTP
Association. In ASP Active and Inactive management messages, the Association. In ASP Active and ASP Inactive management messages, the
signalling traffic to be started or stopped is discriminated by the signalling traffic to be started or stopped is discriminated by the
Routing Context parameter. At an ASP, the Routing Context parameter Routing Context parameter. At an ASP, the Routing Context parameter
uniquely identifies the range of signalling traffic associated with uniquely identifies the range of signalling traffic associated with
each Application Server that the ASP is each Application Server that the ASP is
configured to receive. configured to receive.
1.4.2.2 Routing Key Limitiations 1.4.2.2 Routing Key Limitations
>From an SS7 network perspective, a Routing Key is limited to within a
single SS7 Destination Point Code. This is important, as the SG must be
able to present this point code to the SS7 network, without
compromising the integrity of the Signaling Point Management Cluster.
Some SS7 networks may require the SG to generate UPU messages in
failure conditions. In this case, the AS and SG may optionally limit a
Routing Key to a single Service Indicator (ISUP, TUP, SCCP, etc.). The
SG generation of a UPU message into the SS7 network is implementation
dependent, therefore no specific procedures are outlined in this
document.
Routing Keys MUST be unique in the sense that a received SS7 signalling
message cannot be matched to more than one Routing Key. It is not
necessary for the parameter range values within a particular Routing
Key to be contiguous. For example, an AS could be configured to
support call processing for multiple ranges of PSTN trunks that are not Routing Keys SHOULD be unique in the sense that each received SS7
represented by contiguous CIC values. signalling message SHOULD have a single routing result to an
Application Server. It is not necessary for the parameter range values
within a particular Routing Key to be contiguous. For example, an AS
could be configured to support call processing for multiple ranges of
PSTN trunks that are not represented by contiguous CIC values.
1.4.2.3 Managing Routing Contexts and Routing Keys 1.4.2.3 Managing Routing Contexts and Routing Keys
There are two ways to ways to provision a Routing Key at an SG. A There are two ways to provision a Routing Key at an SGP. A
Routing Key may be configured using an implementation dependent Routing Key may be configured statically using an implementation
management interface, statically or dynamically in full accordance to dependent management interface, or dynamically using the M3UA Routing
the M3UA specifications. A Routing Key may also be configured using the Key registration procedure. A Routing Key may also be configured using
M3UA dynamic registration/deregistration procedures defined in this the M3UA dynamic registration/deregistration procedures defined in this
document. An M3UA element must implement at least one method of document. An M3UA element must implement at least one method of
Routing Key provisioning. Routing Key provisioning.
When using a management interface to configure Routing Keys, the When using a management interface to configure Routing Keys, the
message distribution function within the SG is not limited to the set message distribution function within the SGP is not limited to the set
of parameters defined in this document. Other implementation dependent of parameters defined in this document. Other implementation dependent
distribution algorithms may be used. distribution algorithms may be used.
1.4.2.4 Message Distribution the SG 1.4.2.4 Message Distribution at the SGP
In order to direct messages received from the SS7 MTP3 network to the In order to direct messages received from the SS7 MTP3 network to the
appropriate IP destination, the SG must perform a message distribution appropriate IP destination, the SGP must perform a message distribution
function using information from the received MTP3-User message. function using information from the received MTP3-User message.
To support this message distribution, the SG must maintain the To support this message distribution, the SGP must maintain the
equivalent of a network address translation table, mapping incoming SS7 equivalent of a network address translation table, mapping incoming SS7
message information to an Application Server for a particular message information to an Application Server for a particular
application and range of traffic. This is accomplished by comparing application and range of traffic. This is accomplished by comparing
elements of the incoming SS7 message to provisioned Routing Keys in the elements of the incoming SS7 message to currently defined Routing Keys
SG. These Routing Keys in turn make reference to an Application Server in the SGP. These Routing Keys in turn make reference to an
that is enabled by one or more ASPs. These ASPs provide dynamic status Application Server that is enabled by one or more ASPs. These ASPs
information on their availability, traffic handling capability and provide dynamic status information on their availability, traffic
congestion to the SG using various management messages defined in the handling capability and congestion to the SGP using various management
M3UA protocol. messages defined in the M3UA protocol.
The list of ASPs in an AS is assumed to be dynamic, taking into account The list of ASPs in an AS is assumed to be dynamic, taking into account
the availability, traffic handling capability and congestion status of the availability, traffic handling capability and congestion status of
the individual ASPs in the list, as well as configuration changes and the individual ASPs in the list, as well as configuration changes and
possible fail-over mechanisms. possible fail-over mechanisms.
Normally, one or more ASPs are active in the AS (i.e., currently Normally, one or more ASPs are active in the AS (i.e., currently
processing traffic) but in certain failure and transition cases it is processing traffic) but in certain failure and transition cases it is
possible that there may be active ASP available. Both load-sharing and possible that there may be no active ASP available. Both load-sharing
backup scenarios are supported. and backup scenarios are supported.
When there is no Routing Key match, or only a partial match, for an When there is no matching Routing Key entry for an incoming SS7
incoming SS7 message, a default treatment MUST be specified. Possible message, a default treatment SHOULD be specified. Possible solutions
solutions are to provide a default Application Server at the SG that are to provide a default Application Server at the SGP that directs all
directs all unallocated traffic to a (set of) default ASP(s), or to unallocated traffic to a (set of) default ASP(s), or to drop the
drop the message and provide a notification to management. The message and provide a notification to layer management. The treatment
treatment of unallocated traffic is implementation dependent. of unallocated traffic is implementation dependent.
1.4.2.5 Message Distribution at the ASP 1.4.2.5 Message Distribution at the ASP
In order to direct messages to the SS7 network, the ASP must also In order to direct messages to the SS7 network, the ASP must also
perform a message distribution function in order to choose the proper perform a message distribution function in order to choose the proper
SG or SGP for a given message. This is accomplished by observing the SGP for a given message. This is accomplished by observing the
Destination Point Code (and possibly other elements of the outgoing Destination Point Code (and possibly other elements of the outgoing
message such as the SLS value), together with the SS7 destination message such as the SLS value).Where more than one route (or SGP) is
availability/restricted/congestion status via the SG(s) and the possible for routing to the SS7 network, the ASP SHOULD maintain a
availability of the SG and SGPs themselves. dynamic table of available SGP routes for the SS7 destinations, taking
into account the SS7 destination availability/restricted/congestion
status received from the SGP(s), the availability status of the
individual SGPs and configuration changes and fail-over mechanisms.
There is, however, no M3UA messaging to manage the status of an SGP
(e.g., SGP-Up/Down/Active/Inactive messaging). Whenever an SCTP
A remote Signalling Gateway may be composed of one or more SGPs that association to an SGP exists, the SGP is assumed to be ready for the
are capable of routing SS7 traffic. As is the case with ASPs, a purposes of responding to M3UA ASPSM messages.
dynamic list of SGPs in an SG can be maintained, taking into account
the availability status of the individual SGPs, configuration changes Every SGP of one SG ASP regarding one AS provides identical SS7
and fail-over mechanisms. There is, however, no M3UA messaging to
manage the status of an SGP. Whenever an SCTP association to an SGP
exists, it is assumed to be available. Also, every SGP of one SG
communicating with one ASP regarding one AS provides identical SS7
connectivity to this ASP. connectivity to this ASP.
1.4.3 SS7 and M3UA Interworking 1.4.3 SS7 and M3UA Interworking
In the case of SS7 and M3UA inter-working, the M3UA adaptation layer is In the case of SS7 and M3UA inter-working, the M3UA adaptation layer is
designed to provide an extension of the MTP3 defined user primitives. designed to provide an extension of the MTP3 defined user primitives.
1.4.3.1 Signalling Gateway SS7 Layers 1.4.3.1 Signalling Gateway SS7 Layers
The SG is responsible for terminating MTP Level 3 of the SS7 protocol, The SG is responsible for terminating MTP Level 3 of the SS7 protocol,
and offering an IP-based extension to its users. and offering an IP-based extension to its users.
>From an SS7 perspective, it is expected that the Signalling Gateway >From an SS7 perspective, it is expected that the Signalling Gateway
(SG) transmits and receives SS7 Message Signalling Units (MSUs) to and transmits and receives SS7 Message Signalling Units (MSUs) to and
from the PSTN over a standard SS7 network interface, using the SS7 from the PSTN over a standard SS7 network interface, using the SS7
Message Transfer Part (MTP) [14,15,16] to provide reliable transport of Message Transfer Part (MTP) [14,15,16] to provide reliable transport of
the messages. the messages.
As a standard SS7 network interface, the use of MTP Level 2 signalling As a standard SS7 network interface, the use of MTP Level 2 signalling
links is not the only possibility. ATM-based High Speed Links can also links is not the only possibility. ATM-based High Speed Links can also
be used with the services of the Signalling ATM Adaptation Layer (SAAL) be used with the services of the Signalling ATM Adaptation Layer (SAAL)
[17,18]. It is possible for IP-based links to be present, using the [17,18].
services of the MTP2-User Adaptation Layer (M2UA) [19]. These SS7
datalinks may be terminated at a Signalling Transfer Point (STP) or at Note: It is also possible for IP-based interfaces to be present, using
a Signalling End Point (SEP). Using the services of MTP3, the SG may the services of the MTP2-User Adaptation Layer (M2UA) [23] or M2PA [].
be capable of communicating with remote SS7 SEPs in a quasi-associated These may be terminated at a Signalling Transfer Point (STP) or
Signalling End Point (SEP). Using the services of MTP3, the SG may be
capable of communicating with remote SS7 SEPs in a quasi-associated
fashion, where STPs may be present in the SS7 path between the SEP and fashion, where STPs may be present in the SS7 path between the SEP and
the SG. the SG.
Where ATM-based High Speed Links are used in the SS7 network, it is
possible for the SG to use the services of the MTP-3b [20] for reliable
transport to and from an SS7 SEP or STP. The maximum SIF length
supported by the MTP-3b is 4095 octets compared to the 272-octet
maximum of the MTP3. However, for MTP3-Users to take advantage of the
larger SDU between MTP3-User peers, network architects should ensure
that MTP3-b is used end-to-end between the SG and the SS7-resident
peer.
1.4.3.2 SS7 and M3UA Inter-Working at the SG 1.4.3.2 SS7 and M3UA Inter-Working at the SG
The SG provides a functional inter-working of transport functions The SGP provides a functional inter-working of transport functions
between the SS7 network and the IP network by also supporting the M3UA between the SS7 network and the IP network by also supporting the M3UA
adaptation layer. It allows the transfer of MTP3-User signalling adaptation layer. It allows the transfer of MTP3-User signalling
messages to and from an IP-based Application Server Process where the messages to and from an IP-based Application Server Process where the
peer MTP3-User protocol layer exists. peer MTP3-User protocol layer exists.
The Signalling Gateway must maintain knowledge of SS7 node and The Signalling Gateway must maintain knowledge of relevant SS7 node and
Signalling Point Management Cluster (SPMC) status in their respective Signalling Point Management Cluster (SPMC) status in their respective
domains in order to perform a seamless inter-working of the IP-based domains in order to perform a seamless inter-working of the IP-based
signalling and the SS7 domains. For example, SG knowledge of the signalling and the SS7 domains. For example, SG knowledge of the
availability and/or congestion status of the SPMC and SS7 nodes must be availability and/or congestion status of the SPMC and SS7 nodes must be
maintained and disseminated in the respective networks, in order to maintained and disseminated in the respective networks, in order to
ensure that end-to-end operation is transparent to the communicating ensure that end-to-end operation is transparent to the communicating
SCN protocol peers at the SS7 node and ASP. SCN protocol peers at the SS7 node and ASP. Where more than one SGP
When the SG determines that the transport of SS7 messages to an SPMC
(or possibly to parts of an SPMC) is encountering congestion, the SG
should inform the MTP3 route management function (by an implementation-
dependent mechanism). This information is used by the MTP3 to mark the
"route" to the affected destination as congested and to trigger MTP
Transfer Controlled (TFC) messages to any SS7 SEPs generating traffic
to the congested DPC, as per current MTP3 procedures.
When the SG determines that the transport of SS7 messages to all ASPs
in a particular SPMC is interrupted, then it should similarly inform
the MTP3 route management function. This information is used by the
MTP3 to mark the "route" to the affected destination as unavailable,
and in the case of the SG acting as a signalling transfer point (i.e.,
the Point Code of the SG is different from that of the SPMC), to send
MTP Transfer Prohibited (TFP) messages to the relevant adjacent SS7
nodes, according to the local SS7 network procedures.
When the SG determines that the transport of SS7 messages to an ASP in constitutes an SG, the knowledge of the SGPs must be coordinated into
a particular SPMC can be resumed, the SG should similarly inform the an overall SG view.
MTP3 route management function. This information is used by the MTP3
to mark the route to the affected destination as available, and in the
case of a signalling transfer point, to send MTP Transfer Allowed (TFA)
messages to the relevant adjacent SS7 nodes, according to the local SS7
network procedures.
For SS7 user part management, it is required that the MTP3-User For SS7 user part management, it is required that the MTP3-User
protocols at ASPs receive indications of SS7 signalling point protocols at ASPs receive indications of SS7 signalling point
availability, SS7 network congestion, and remote User Part availability, SS7 network congestion, and remote User Part
unavailability as would be expected in an SS7 SEP node. To accomplish unavailability as would be expected in an SS7 SEP node. To accomplish
this, the MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives this, the MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives
received at the MTP3 upper layer interface at the SG need to be received at the MTP3 upper layer interface at the SG need to be
propagated to the remote MTP3-User lower layer interface at the ASP. propagated to the remote MTP3-User lower layer interface at the ASP.
(These indication primitives are, of course, also made available to any (These indication primitives are also made available to any existing
existing local MTP3-Users at the SG, if present.) local MTP3-Users at the SG, if present.)
It is important to clarify that MTP3 management messages such as TFPs
or TFAs received from the SS7 network are not "encapsulated" and sent
blindly to the ASPs. Rather, the existing MTP3 management procedures
are followed within the MTP3 function of the SG to re-calculate the
MTP3 route set status and to initiate any required signalling-route-
set-test procedures into the SS7 network. Only when an SS7 destination
status changes are MTP-PAUSE or MTP-RESUME primitives invoked. These
primitives can also be invoked due to local SS7 link set conditions as
per existing MTP3 procedures.
In the case where the MTP in the SG undergoes an MTP restart, event
communication to the concerned ASPs should be handled as follows:
When the SG discovers SS7 network isolation, the SG sends an indication MTP3 management messages (such as TFPs or TFAs received from the SS7
to all concerned available ASPs (i.e., ASPs in the "active" or network) MUST NOT be encapsulated as Data message Payload Data and sent
"inactive" state), using a DUNA message. For the purposes of MTP either from SG to ASP or from ASP to SG. The SG MUST terminate these
Restart, all SPMCs with point codes different from that of the SG with messages and generate M3UA messages as appropriate.
at least one ASP that is active or that has sent an ASPAC message to
the SG during the first part of the restart procedure should be
considered as available. If the M3UA at the SG receives any ASPAC
messages during the restart procedure, it delays the ASPAC-ACK messages
until the end of the restart procedure. During the second part of the
restart procedure the M3UA at the SG informs all concerned ASPs in the
"active" or "inactive" state of any unavailable SS7 destinations. At
the end of the restart procedure the M3UA sends an ASPAC-ACK message to
all ASPs in the "active" state.
1.4.3.3 Application Server 1.4.3.3 Application Server
A cluster of application servers is responsible for providing the A cluster of application servers is responsible for providing the
overall support for one or more SS7 upper layers. From an SS7 overall support for one or more SS7 upper layers. From an SS7
standpoint, a Signalling Point Management Cluster (SPMC) provides standpoint, a Signalling Point Management Cluster (SPMC) provides
complete support for the upper layer service for a given point code. complete support for the upper layer service for a given point code.
As an example, an SPMC providing MGC capabilities must provide complete As an example, an SPMC providing MGC capabilities must provide complete
support for ISUP (and any other MTP3 user located at the point code of support for ISUP (and any other MTP3 user located at the point code of
the SPMC) for a given point code, according to the local SS7 network the SPMC) for a given point code, according to the local SS7 network
specifications. specifications.
This measure is necessary to allow the SG to accurately represent the This measure is necessary to allow the SG to accurately represent the
signalling point on the local SS7 network. signalling point on the local SS7 network.
In the case where an ASP is connected to more than one SG, the M3UA In the case where an ASP is connected to more than one SGP, the M3UA
must maintain the status of configured SS7 destinations and route layer must maintain the status of configured SS7 destinations and route
messages according to availability/congestion/restricted status of the messages according to availability/congestion/restricted status of the
routes to these destinations. routes to these SS7 destinations.
When an ASP enters the "Inactive" state towards an SG the M3UA must
mark all SS7 destinations configured to be reachable via this SG as
available.
When the M3UA at an ASP receives a DUNA message indicating SS7 network
isolation at an SG, it will stop any affected traffic via this SG and
clear any unavailability state of SS7 destinations via this SG. When
the M3UA subsequently receives any DUNA messages from an SG it will
mark the effected SS7 destinations as unavailable via that SG. When
the M3UA receives an ASPAC-ACK message it can resume traffic to
available SS7 destinations via this SG, provided the ASP is in the
active state towards this SG.
1.4.3.3 IPSP Considerations 1.4.3.4 IPSP Considerations
Since IPSPs use M3UA in a point-to-point fashion, there is no concept Since IPSPs use M3UA in a point-to-point fashion, there is no concept
of routing of messages beyond the remote end. Therefore, SS7 and M3UA of routing of messages beyond the remote end. Therefore, SS7 and M3UA
inter-working is not necessary for this model. inter-working is not necessary for this model.
1.4.4 Redundancy Models 1.4.4 Redundancy Models
The network address translation and mapping function of the M3UA layer The network address translation and mapping function of the M3UA layer
supports signalling process fail-over functions in order to support a supports signalling process fail-over functions in order to support a
high availability of call and transaction processing capability. high availability of call and transaction processing capability.
skipping to change at page 19, line 51 skipping to change at page 18, line 21
The Application Server is, in practical terms, a list of all ASPs The Application Server is, in practical terms, a list of all ASPs
configured to process a range of MTP3-User traffic defined by one configured to process a range of MTP3-User traffic defined by one
Routing Key. One or more ASPs in the list are normally active (i.e., Routing Key. One or more ASPs in the list are normally active (i.e.,
handling traffic) while any others may be unavailable or inactive, to handling traffic) while any others may be unavailable or inactive, to
be possibly used in the event of failure or unavailability of the be possibly used in the event of failure or unavailability of the
active ASP(s). active ASP(s).
The fail-over model supports an "n+k" redundancy model, where "n" ASPs The fail-over model supports an "n+k" redundancy model, where "n" ASPs
is the minimum number of redundant ASPs required to handle traffic and is the minimum number of redundant ASPs required to handle traffic and
"k" ASPs are available to take over for a failed or unavailable ASP. A "k" ASPs are available to take over for a failed or unavailable ASP. A
"1+1" active/standby redundancy is a subset of this model. A simplex "1+1" active/back-up redundancy is a subset of this model. A simplex
"1+0" model is also supported as a subset, with no ASP redundancy. "1+0" model is also supported as a subset, with no ASP redundancy.
At the SG, an Application Server list contains active and inactive ASPs At the SGP, an Application Server list contains active and inactive
to support ASP load-sharing and fail-over procedures. The list of ASPs ASPs to support ASP load-sharing and fail-over procedures. The list of
within a logical Application Server is kept updated in the SG to ASPs within a logical Application Server is kept updated in the SGP to
reflect the active Application Server Process(es). reflect the active Application Server Process(es).
To avoid a single point of failure, it is recommended that a minimum of To avoid a single point of failure, it is recommended that a minimum of
two ASPs be in the list, resident in separate hosts and therefore two ASPs be in the list, resident in separate hosts and therefore
available over different SCTP Associations. For example, in the available over different SCTP Associations. For example, in the
network shown in Figure 1, all messages to DPC x could be sent to ASP1 network shown in Figure 1, all messages to DPC x could be sent to ASP1
in Host1 or ASP1 in Host2. The AS list at SG1 might look like the in Host3 or ASP1 in Host4. The AS list at SGP1 in Host 1 might look
following: like the following:
Routing Key {DPC=x) - "Application Server #1" Routing Key {DPC=x) - "Application Server #1"
ASP1/Host1 - State=Up, Active ASP1/Host3 - State = Active
ASP1/Host2 - State=Up, Inactive ASP1/Host3 - State = Inactive
In this "1+1" redundancy case, ASP1 in Host1 would be sent any incoming In this "1+1" redundancy case, ASP1 in Host3 would be sent any incoming
message with DPC=x. ASP1 in Host2 would normally be brought to the message with DPC=x. ASP1 in Host4 would normally be brought to the
active state upon failure of, or loss of connectivity to, ASP1/Host1. "active" state upon failure of, or loss of connectivity to, ASP1/Host1.
In this example, both ASPs are Up, meaning that the related SCTP
association and far-end M3UA peer is ready.
The AS List at SG1 might also be set up in load-share mode: The AS List at SGP1 in Host1 might also be set up in load-share mode:
Routing Key {DPC=x) - "Application Server #1" Routing Key {DPC=x) - "Application Server #1"
ASP1/Host1 - State = Up, Active ASP1/Host3 - State = Active
ASP1/Host2 - State = Up, Active ASP1/Host4 - State = Active
In this case, both the ASPs would be sent a portion of the traffic. In this case, both the ASPs would be sent a portion of the traffic.
For example the two ASPs could together form a database, where incoming For example the two ASPs could together form a database, where incoming
queries may be sent to any active ASP. queries may be sent to any active ASP.
Care must be exercised by a Network Operator in the selection of the Care must be exercised by a Network Operator in the selection of the
routing information to be used as the Routing Key for a particular AS. routing information to be used as the Routing Key for a particular AS.
For example, where Application Servers are defined using ranges of ISUP For example, where Application Servers are defined using ranges of ISUP
CIC values, the Operator is implicitly splitting up control of the CIC values, the Operator is implicitly splitting up control of the
related circuit groups. Some CIC value range assignments may interfere related circuit groups. Some CIC value range assignments may interfere
with ISUP circuit group management procedures. with ISUP circuit group management procedures.
In the process of fail-over, it is recommended that in the case of ASPs In the process of fail-over, it is recommended that in the case of ASPs
supporting call processing, stable calls do not fail. It is possible supporting call processing, stable calls do not fail. It is possible
that calls in "transition" MAY fail, although measures of communication that calls in "transition" MAY fail, although measures of communication
between the ASPs involved can be used to mitigate this. For example, between the ASPs involved can be used to mitigate this. For example,
the two ASPs MAY share call state via shared memory, or MAY use an ASP the two ASPs MAY share call state via shared memory, or MAY use an ASP
skipping to change at page 20, line 50 skipping to change at page 19, line 16
CIC values, the Operator is implicitly splitting up control of the CIC values, the Operator is implicitly splitting up control of the
related circuit groups. Some CIC value range assignments may interfere related circuit groups. Some CIC value range assignments may interfere
with ISUP circuit group management procedures. with ISUP circuit group management procedures.
In the process of fail-over, it is recommended that in the case of ASPs In the process of fail-over, it is recommended that in the case of ASPs
supporting call processing, stable calls do not fail. It is possible supporting call processing, stable calls do not fail. It is possible
that calls in "transition" MAY fail, although measures of communication that calls in "transition" MAY fail, although measures of communication
between the ASPs involved can be used to mitigate this. For example, between the ASPs involved can be used to mitigate this. For example,
the two ASPs MAY share call state via shared memory, or MAY use an ASP the two ASPs MAY share call state via shared memory, or MAY use an ASP
to ASP protocol to pass call state information. Any ASP-to-ASP to ASP protocol to pass call state information. Any ASP-to-ASP
protocol is outside the scope of this document. protocol to support this function is outside the scope of this
document.
1.4.4.2 Signalling Gateway Redundancy 1.4.4.2 Signalling Gateway Redundancy
Signalling Gateways MAY also be distributed over multiple hosts. Much Signalling Gateways MAY also be distributed over multiple hosts. Much
like the AS model, SGs may be comprised of one or more SG Processes like the AS model, SGs may comprise one or more SG Processes (SGPs),
(SGPs), distributed over one or more hosts, using an active/standby or distributed over one or more hosts, using an active/back-up or a load-
a load-sharing model. An SGP is viewed as a remote SCTP end-point from sharing model. Also, every SGP within an SG communicating with an ASP
an ASP perspective. There is, however, no M3UA protocol to manage the provides identical SS7 connectivity to this ASP. Should an SGP lose all
status of an SGP. Whenever an SCTP association to an SGP exists, the or partial SS7 connectivity and other SGPs exist, the SGP SHOULD
SGP is assumed to be available. Also, every SGP within an SG terminate the SCTP associations to the concerned ASPs.
communicating with an ASP provides identical SS7 connectivity to this
ASP. Should an SGP lose all or partial SS7 connectivity and other SGPs
exist, the SGP must terminate the SCTP associations to the concerned
ASPs.
It is therefore possible for an ASP to route signalling messages It is therefore possible for an ASP to route signalling messages
destined to the SS7 network using more than one SGP. In this model, a destined to the SS7 network using more than one SGP. In this model, a
Signalling Gateway is deployed as a cluster of hosts acting as a single Signalling Gateway is deployed as a cluster of hosts acting as a single
SG. A primary/back-up redundancy model is possible, where the SG. A primary/back-up redundancy model is possible, where the
unavailability of the SCTP association to a primary SGP could be used unavailability of the SCTP association to a primary SGP could be used
to reroute affected traffic to an alternate SGP. A load-sharing model to reroute affected traffic to an alternate SGP. A load-sharing model
is possible, where the signalling messages are load-shared between is possible, where the signalling messages are load-shared between
multiple SGPs. multiple SGPs. The distribution of the MTP3-user messages over the
SGPs should be done in such a way to minimize message mis-sequencing,
as required by the SS7 User Parts.
It may also be possible for an ASP to use more than one SG to access a It may also be possible for an ASP to use more than one SG to access a
specific SS7 end point, in a model that resembles an SS7 STP mated specific SS7 end point, in a model that resembles an SS7 STP mated
pair. Typically, SS7 STPs are deployed in mated pairs, with traffic pair. Typically, SS7 STPs are deployed in mated pairs, with traffic
load-shared between them. Other models are also possible, subject to load-shared between them. Other models are also possible, subject to
the limitations of the local SS7 network provisioning guidelines. the limitations of the local SS7 network provisioning guidelines.
>From the perspective of the M3UA at an ASP, a particular SG is capable >From the perspective of the M3UA layer at an ASP, a particular SG is
of transferring traffic to an SS7 destination if an SCTP association capable of transferring traffic to an SS7 destination if an SCTP
with at least one SGP of the SG is established, the SGP has returned an association with at least one SGP of the SG is established, the SGP has
ASPAC Ack message acknowledging to the ASP M3UA that the ASP is returned an acknowledgement to the ASP to indicate that the ASP is
actively handling traffic for that destination, and the SG has not actively handling traffic for that destination, and the SGP has not
indicated that the destination is inaccessible. When an ASP is indicated that the destination is inaccessible. When an ASP is
configured to use multiple SGs for transferring traffic to the SS7 configured to use multiple SGPs for transferring traffic to the SS7
network, the ASP must maintain knowledge of the current capability of network, the ASP must maintain knowledge of the current capability of
the SGs to handle traffic to destinations of interest. This the SGPs to handle traffic to destinations of interest. This
information is crucial to the overall reliability of the service, for information is crucial to the overall reliability of the service, for
both active/standby and load-sharing model, in the event of failures,
both active/back-up and load-sharing model, in the event of failures,
recovery and maintenance activities. The ASP M3UA may also use this recovery and maintenance activities. The ASP M3UA may also use this
information for congestion avoidance purposes. The distribution of the information for congestion avoidance purposes. The distribution of the
MTP3-user messages over the SGs should be done in such a way to MTP3-user messages over the SGPs should be done in such a way to
minimize message mis-sequencing, as required by the SS7 User Parts. minimize message mis-sequencing, as required by the SS7 User Parts.
1.4.5 Flow Control 1.4.5 Flow Control
Local Management at an ASP may wish to stop traffic across an SCTP Local Management at an ASP may wish to stop traffic across an SCTP
association in order to temporarily remove the association from service association in order to temporarily remove the association from service
or to perform testing and maintenance activity. The function could or to perform testing and maintenance activity. The function could
optionally be used to control the start of traffic on to a newly optionally be used to control the start of traffic on to a newly
available SCTP association. available SCTP association.
1.4.6 Congestion Management 1.4.6 Congestion Management
The M3UA Layer is informed of local and IP network congestion by means The M3UA layer is informed of local and IP network congestion by means
of an implementation-dependent function (e.g., an implementation- of an implementation-dependent function (e.g., an implementation-
dependent indication from the SCTP of IP network congestion). dependent indication from the SCTP of IP network congestion).
At an ASP or IPSP, the M3UA indicates congestion to local MTP3-Users by At an ASP or IPSP, the M3UA layer indicates congestion to local MTP3-
means of an MTP-Status primitive, as per current MTP3 procedures, to Users by means of an MTP-STATUS primitive, as per current MTP3
invoke appropriate upper layer responses. procedures, to invoke appropriate upper layer responses.
When an SG determines that the transport of SS7 messages to a When an SG determines that the transport of SS7 messages to a
Signalling Point Management Cluster (SPMC) is encountering congestion, Signalling Point Management Cluster (SPMC) is encountering congestion,
the SG should trigger SS7 MTP3 Transfer Controlled management messages the SG MAY trigger SS7 MTP3 Transfer Controlled management messages
to originating SS7 nodes, as per current MTP3 procedures. The to originating SS7 nodes, per the congestion procedures of the relevant
triggering of SS7 MTP3 Management messages from an SG is an MTP3 standard. The triggering of SS7 MTP3 Management messages from an
implementation-dependent function. SG is an implementation-dependent function.
The M3UA at an ASP or IPSP should indicate local congestion to an M3UA The M3UA layer at an ASP or IPSP should indicate local congestion to an
peer with an SCON message. When an SG M3UA receives an SCON message M3UA peer with an SCON message. When an SG receives a congestion
from an ASP, and the SG determines that an SPMC is now encountering message (SCON) from an ASP, and the SG determines that an SPMC is now
congestion, it should trigger SS7 MTP3 Transfer Controlled management encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled
messages to concerned SS7 destinations according to current MTP management messages to concerned SS7 destinations according to
procedures. congestion procedures of the relevant MTP3 standard.
1.4.7 SCTP Stream Mapping. 1.4.7 SCTP Stream Mapping.
The M3UA at both the SG and ASP also supports the assignment of The M3UA layer at both the SGP and ASP also supports the assignment of
signalling traffic into streams within an SCTP association. Traffic signalling traffic into streams within an SCTP association. Traffic
that requires sequencing must be assigned to the same stream. To that requires sequencing must be assigned to the same stream. To
accomplish this, MTP3-User traffic may be assigned to individual accomplish this, MTP3-User traffic may be assigned to individual
streams based on, for example, the SLS value in the MTP3 Routing Label streams based on, for example, the SLS value in the MTP3 Routing Label
or the ISUP CIC assignment, subject of course to the maximum number of or the ISUP CIC assignment, subject of course to the maximum number of
streams supported by the underlying SCTP association. streams supported by the underlying SCTP association.
The use of SCTP streams within M3UA is recommended in order to minimize The use of SCTP streams within M3UA is recommended in order to minimize
transmission and buffering delays, therefore improving the overall transmission and buffering delays, therefore improving the overall
performance and reliability of the signalling elements. The performance and reliability of the signalling elements. The
skipping to change at page 22, line 43 skipping to change at page 21, line 4
that requires sequencing must be assigned to the same stream. To that requires sequencing must be assigned to the same stream. To
accomplish this, MTP3-User traffic may be assigned to individual accomplish this, MTP3-User traffic may be assigned to individual
streams based on, for example, the SLS value in the MTP3 Routing Label streams based on, for example, the SLS value in the MTP3 Routing Label
or the ISUP CIC assignment, subject of course to the maximum number of or the ISUP CIC assignment, subject of course to the maximum number of
streams supported by the underlying SCTP association. streams supported by the underlying SCTP association.
The use of SCTP streams within M3UA is recommended in order to minimize The use of SCTP streams within M3UA is recommended in order to minimize
transmission and buffering delays, therefore improving the overall transmission and buffering delays, therefore improving the overall
performance and reliability of the signalling elements. The performance and reliability of the signalling elements. The
distribution of the MTP3 user messages over the various streams should distribution of the MTP3 user messages over the various streams should
be done in such a way to minimize message mis-sequencing, as required be done in such a way to minimize message mis-sequencing, as required
by the SS7 User Parts. by the SS7 User Parts.
1.4.8 Client/Server Model 1.4.8 Client/Server Model
The SG takes on the role of server while the ASP is the client. ASPs It is recommended that the SGP and ASP be able to support both client and server
MUST initiate the SCTP association to the SG. operation. The peer endpoints using M3UA SHOULD be configured so that one always
takes on the role of client and the other the role of server for initiating SCTP
associations. The default orientation would be for the SGP to take on the role
of server while the ASP is the client. In this case, ASPs SHOULD initiate the
SCTP association to the SGP
In the case of IPSP to IPSP communication, the peer endpoints using In the case of IPSP to IPSP communication, the peer endpoints using
M3UA SHOULD be configured so that one always takes on the role of M3UA SHOULD be configured so that one always takes on the role of
client and the other the role of server for initiating SCTP client and the other the role of server for initiating SCTP
associations and M3UA messaging. associations.
The SCTP (and UDP/TCP) Registered User Port Number Assignment for M3UA The SCTP Registered User Port Number Assignment for M3UA is 2905.
is 2905.
1.5 Sample Configurations 1.5 Sample Configurations
1.5.1 Example 1: ISUP message transport 1.5.1 Example 1: ISUP Message Transport
******** SS7 ***************** IP ******** ******** SS7 ***************** IP ********
* SEP *---------* SG *--------* ASP * * SEP *---------* SGP *--------* ASP *
******** ***************** ******** ******** ***************** ********
+------+ +------+ +------+ +------+
| ISUP | (NIF) | ISUP | | ISUP | (NIF) | ISUP |
+------+ +------+-+------+ +------+ +------+ +------+-+------+ +------+
| MTP3 | | MTP3 | | M3UA | | M3UA | | MTP3 | | MTP3 | | M3UA | | M3UA |
+------| +------+ +------+ +------+ +------| +------+ +------+ +------+
| MTP2 | | MTP2 | | SCTP | | SCTP | | MTP2 | | MTP2 | | SCTP | | SCTP |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| L1 | | L1 | | IP | | IP | | L1 | | L1 | | IP | | IP |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
|_______________| |______________| |_______________| |______________|
SEP - SS7 Signalling End Point SEP - SS7 Signalling End Point
SCTP - Stream Control Transmission Protocol SCTP - Stream Control Transmission Protocol
NIF - Nodal Inter-working Function NIF - Nodal Inter-working Function
In this example, the SG provides an implementation-dependent nodal In this example, the SGP provides an implementation-dependent nodal
inter-working function (NIF) that allows the MGC to exchange SS7 inter-working function (NIF) that allows the MGC to exchange SS7
signalling messages with the SS7-based SEP. The NIF within the SG signalling messages with the SS7-based SEP. The NIF within the SGP
serves as the interface within the SG between the MTP3 and M3UA. This serves as the interface within the SGP between the MTP3 and M3UA. This
nodal inter-working function has no visible peer protocol with either nodal inter-working function has no visible peer protocol with either
the MGC or SEP. It also provides network status information to one or the MGC or SEP. It also provides network status information to one or
both sides of the network. both sides of the network.
For internal SG modeling purposes, at the NIF level, SS7 signalling For internal SGP modeling purposes, at the NIF level, SS7 signalling
messages that are destined to the MGC are received as MTP-TRANSFER messages that are destined to the MGC are received as MTP-TRANSFER
indication primitives from the MTP Level 3 upper layer interface and indication primitives from the MTP Level 3 upper layer interface,
are sent to the local M3UA-resident message distribution function for translated to MTP-TRANSFER request primitives, and sent to the local
ongoing routing to the final IP destination. MTP-TRANSFER primitives M3UA-resident message distribution function for ongoing routing to the
received from the local M3UA network address translation and mapping final IP destination. Messages received from the local M3UA network
function are sent to the MTP Level 3 upper layer interface as MTP- address translation and mapping function as MTP-TRANSFER indication
primitives are sent to the MTP Level 3 upper layer interface as MTP-
TRANSFER request primitives for on-going MTP Level 3 routing to an SS7 TRANSFER request primitives for on-going MTP Level 3 routing to an SS7
SEP. For the purposes of providing SS7 network status information the SEP. For the purposes of providing SS7 network status information the
NIF also delivers MTP-PAUSE, MTP-RESUME and MTP-STATUS indication NIF also delivers MTP-PAUSE, MTP-RESUME and MTP-STATUS indication
primitives received from the MTP Level 3 upper layer interface to the primitives received from the MTP Level 3 upper layer interface to the
local M3UA-resident management function. In addition, as an local M3UA-resident management function. In addition, as an
implementation and network option, restricted destinations are implementation and network option, restricted destinations are
communicated from MTP network management to the local M3UA-resident communicated from MTP network management to the local M3UA-resident
management function. management function.
1.5.2 Example 2: SCCP Transport between IPSPs 1.5.2 Example 2: SCCP Transport between IPSPs
skipping to change at page 24, line 30 skipping to change at page 22, line 47
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
|________________| |________________|
This example shows an architecture where no Signalling Gateway is used. This example shows an architecture where no Signalling Gateway is used.
In this example, SCCP messages are exchanged directly between two IP- In this example, SCCP messages are exchanged directly between two IP-
resident IPSPs with resident SCCP-User protocol instances, such as resident IPSPs with resident SCCP-User protocol instances, such as
RANAP or TCAP. SS7 network inter-working is not required, therefore RANAP or TCAP. SS7 network inter-working is not required, therefore
there is no MTP3 network management status information for the SCCP and there is no MTP3 network management status information for the SCCP and
SCCP-User protocols to consider. Any MTP-PAUSE, -RESUME or -STATUS SCCP-User protocols to consider. Any MTP-PAUSE, MTP-RESUME or MTP-
indications from the M3UA to the SCCP should consider the status of the STATUS indications from the M3UA layer to the SCCP layer should
SCTP Association and underlying IP network and any congestion consider the status of the SCTP Association and underlying IP network
information received from the remote site. and any congestion information received from the remote site.
1.5.3 Example 3: SG resident SCCP layer, with remote ASP 1.5.3 Example 3: SGP Resident SCCP Layer, with Remote ASP
******** SS7 ***************** IP ******** ******** SS7 ***************** IP ********
* SEP *---------* *--------* * * SEP *---------* *--------* *
* or * * SG * * ASP * * or * * SGP * * ASP *
* STP * * * * * * STP * * * * *
******** ***************** ******** ******** ***************** ********
+------+ +---------------+ +------+ +------+ +---------------+ +------+
| SCCP-| | SCCP | | SCCP-| | SCCP-| | SCCP | | SCCP-|
| User | +---------------+ | User | | User | +---------------+ | User |
+------+ | _____ | +------+ +------+ | _____ | +------+
| SCCP | | | | | | SCCP | | SCCP | | | | | | SCCP |
+------+ +------+-+------+ +------+ +------+ +------+-+------+ +------+
| MTP3 | | MTP3 | | M3UA | | M3UA | | MTP3 | | MTP3 | | M3UA | | M3UA |
+------| +------+ +------+ +------+ +------| +------+ +------+ +------+
| MTP2 | | MTP2 | | SCTP | | SCTP | | MTP2 | | MTP2 | | SCTP | | SCTP |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| L1 | | L1 | | IP | | IP | | L1 | | L1 | | IP | | IP |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
|_______________| |______________| |_______________| |______________|
STP - SS7 Signalling Transfer Point STP - SS7 Signalling Transfer Point
In this example, the SG contains an instance of the SS7 SCCP protocol In this example, the SGP contains an instance of the SS7 SCCP protocol
layer that may, for example, perform the SCCP Global Title Translation layer that may, for example, perform the SCCP Global Title Translation
(GTT) function for messages logically addressed to the SG SCCP. If the (GTT) function for messages logically addressed to the SG SCCP. If the
result of a GTT for an SCCP message yields an SS7 DPC or DPC/SSN result of a GTT for an SCCP message yields an SS7 DPC or DPC/SSN
address an SCCP peer located in the IP domain, the resulting MTP- address of an SCCP peer located in the IP domain, the resulting MTP-
TRANSFER request primitive is sent to the local M3UA-resident network TRANSFER request primitive is sent to the local M3UA-resident network
address translation and mapping function for ongoing routing to the address translation and mapping function for ongoing routing to the
final IP destination. final IP destination.
Similarly, the SCCP instance in an SG can perform the SCCP GTT service Similarly, the SCCP instance in an SGP can perform the SCCP GTT service
for messages logically addressed to it from SCCP peers in the IP for messages logically addressed to it from SCCP peers in the IP
domain. In this case, MTP-TRANSFER messages are sent from the local domain. In this case, MTP-TRANSFER indication primitives are sent from
M3UA-resident network address translation and mapping function to the the local M3UA-resident network address translation and mapping
SCCP for GTT. If the result of the GTT yields the address of an SCCP function to the SCCP for GTT. If the result of the GTT yields the
peer in the SS7 network then the resulting MTP-TRANSFER request is address of an SCCP peer in the SS7 network then the resulting MTP-
given to the MTP3 for delivery to an SS7-resident node. TRANSFER request primitive is given to the MTP3 for delivery to an SS7-
resident node.
It is possible that the above SCCP GTT at the SG could yield the It is possible that the above SCCP GTT at the SGP could yield the
address of an SCCP peer in the IP domain and the resulting MTP-TRANSFER address of an SCCP peer in the IP domain and the resulting MTP-TRANSFER
primitive would be sent back to the M3UA for delivery to an IP request primitive would be sent back to the M3UA layer for delivery to
destination. an IP destination.
For internal SG modeling purposes, this may be accomplished with the For internal SGP modeling purposes, this may be accomplished with the
use of an implementation-dependent nodal inter-working function within use of an implementation-dependent nodal inter-working function within
the SG that effectively sits below the SCCP and routes MTP-TRANSFER the SGP that effectively sits below the SCCP and routes MTP-TRANSFER
messages to/from both the MTP3 and the M3UA, based on the SS7 DPC or
DPC/SSN
address information. This nodal inter-working function has no visible request/indication messages to/from both the MTP3 and the M3UA layer,
peer protocol with either the ASP or SEP. based on the SS7 DPC or DPC/SSN address information. This nodal inter-
working function has no visible peer protocol with either the ASP or
SEP.
Note that the services and interface provided by the M3UA are the same Note that the services and interface provided by the M3UA layer are the
as in Example 1 and the functions taking place in the SCCP entity are same as in Example 1 and the functions taking place in the SCCP entity
transparent to M3UA. The SCCP protocol functions are not reproduced in are transparent to the M3UA layer. The SCCP protocol functions are not
the M3UA protocol. reproduced in the M3UA protocol.
1.6 Definition of M3UA Boundaries 1.6 Definition of M3UA Boundaries
1.6.1 Definition of the boundary between M3UA and an MTP3-User. 1.6.1 Definition of the Boundary between M3UA and an MTP3-User.
>From ITU Q.701 [14]: >From ITU Q.701 [14]:
MTP-TRANSFER request MTP-TRANSFER request
MTP-TRANSFER indication MTP-TRANSFER indication
MTP-PAUSE indication MTP-PAUSE indication
MTP-RESUME indication MTP-RESUME indication
MTP-STATUS indication MTP-STATUS indication
1.6.2 Definition of the boundary between M3UA and SCTP 1.6.2 Definition of the Boundary between M3UA and SCTP
An example of the upper layer primitives provided by the SCTP are An example of the upper layer primitives provided by the SCTP are
provided in Reference [13] Section 10. provided in Reference [13] Section 10.
1.6.3 Definition of the Boundary between M3UA and Layer Management 1.6.3 Definition of the Boundary between M3UA and Layer Management
M-SCTP ESTABLISH request M-SCTP_ESTABLISH request
Direction: LM -> M3UA Direction: LM -> M3UA
Purpose: LM requests ASP to establish an SCTP association with an Purpose: LM requests ASP to establish an SCTP association with its
SG. peer.
M-STCP ESTABLISH confirm M-STCP_ESTABLISH confirm
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: ASP confirms to LM that it has established an SCTP Purpose: ASP confirms to LM that it has established an SCTP
association with an SG. association with its peer.
M-SCTP ESTABLISH indication M-SCTP_ESTABLISH indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: M3UA informs LM that a remote ASP has established an SCTP Purpose: M3UA informs LM that a remote ASP has established an SCTP
association. association.
M-SCTP RELEASE request M-SCTP_RELEASE request
Direction: LM -> M3UA Direction: LM -> M3UA
Purpose: LM requests ASP to release an SCTP association with SG. Purpose: LM requests ASP to release an SCTP association with its
peer.
M-SCTP RELEASE confirm M-SCTP_RELEASE confirm
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: ASP confirms to LM that it has released SCTP association Purpose: ASP confirms to LM that it has released SCTP association
with SG. with its peer.
M-SCTP RELEASE indication M-SCTP_RELEASE indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: M3UA informs LM that a remote ASP has released an SCTP Purpose: M3UA informs LM that a remote ASP has released an SCTP
Association or the SCTP association has failed. Association or the SCTP association has failed.
M-SCTP STATUS request M-SCTP_STATUS request
Direction: LM -> M3UA Direction: LM -> M3UA
Purpose: LM requests M3UA to report the status of an SCTP Purpose: LM requests M3UA to report the status of an SCTP
association. association.
M-SCTP STATUS confirm M-SCTP_STATUS confirm
Direction: M3UA -> LM
Purpose: M3UA responds with the status of an SCTP association.
M-SCTP STATUS indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: M3UA reports the status of an SCTP association. Purpose: M3UA reports the status of an SCTP association.
M-ASP STATUS request M-ASP_STATUS request
Direction: LM -> M3UA Direction: LM -> M3UA
Purpose: LM requests M3UA to report the status of a local or remote Purpose: LM requests M3UA to report the status of a local or remote
ASP. ASP.
M-ASP STATUS confirm M-ASP_STATUS confirm
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: M3UA reports status of local or remote ASP. Purpose: M3UA reports status of local or remote ASP.
M-AS STATUS request M-AS_STATUS request
Direction: LM -> M3UA Direction: LM -> M3UA
Purpose: LM requests M3UA to report the status of an AS. Purpose: LM requests M3UA to report the status of an AS.
M-AS STATUS confirm M-AS_STATUS confirm
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: M3UA reports the status of an AS. Purpose: M3UA reports the status of an AS.
M-NOTIFY indication M-NOTIFY indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: M3UA reports that it has received a NOTIFY message Purpose: M3UA reports that it has received a Notify message
from its peer. from its peer.
M-ERROR indication M-ERROR indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: M3UA reports that it has received an ERROR message from Purpose: M3UA reports that it has received an Error message from
its peer or that a local operation has been unsuccessful. its peer or that a local operation has been unsuccessful.
M-ASP UP request M-ASP_UP request
Direction: LM -> M3UA Direction: LM -> M3UA
Purpose: LM requests ASP to start its operation and send an ASP-UP Purpose: LM requests ASP to start its operation and send an ASP Up
Message to its peer. message to its peer.
M-ASP_UP confirm
M-ASP UP confirm
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: ASP reports that is has received an ASP UP Acknowledgement Purpose: ASP reports that is has received an ASP UP Ack message from
message from the SG. its peer.
M-ASP UP indication M-ASP_UP indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: M3UA reports it has successfully processed an incoming ASP- Purpose: M3UA reports it has successfully processed an incoming ASP
UP request from its peer. Up message from its peer.
M-ASP DOWN request M-ASP_DOWN request
Direction: LM -> M3UA Direction: LM -> M3UA
Purpose: LM requests ASP to stop its operation and send an ASP-DOWN Purpose: LM requests ASP to stop its operation and send an ASP-Down
Message to its peer. message to its peer.
M-ASP DOWN confirm M-ASP_DOWN confirm
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: ASP reports that is has received an ASP DOWN Purpose: ASP reports that is has received an ASP Down
Acknowledgement message from the SG. Ack message from its peer.
M-ASP DOWN indication M-ASP_DOWN indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: M3UA reports it has successfully processed an incoming ASP- Purpose: M3UA reports it has successfully processed an incoming ASP
DOWN request from its peer. Down message from its peer, or the SCTP association has
been lost/reset.
M-ASP-ACTIVE request M-ASP_ACTIVE request
Direction: LM -> M3UA Direction: LM -> M3UA
Purpose: LM requests ASP to send an ASP-ACTIVE message to its peer. Purpose: LM requests ASP to send an ASP Active message to its peer.
M-ASP ACTIVE confirm M-ASP_ACTIVE confirm
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: ASP reports that is has received an ASP ACTIVE Purpose: ASP reports that is has received an ASP Active
Acknowledgement message from the SG. Ack message from its peer.
M-ASP ACTIVE indication M-ASP_ACTIVE indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: LM reports it has successfully processed an incoming ASP- Purpose: M3UA reports it has successfully processed an incoming ASP
ACTIVE request from its peer. Active message from its peer.
M-ASP-INACTIVE request M-ASP_INACTIVE request
Direction: LM -> M3UA Direction: LM -> M3UA
Purpose: LM requests ASP to send an ASP- Inactive message to the SG. Purpose: LM requests ASP to send an ASP Inactive message to its
peer.
M-ASP INACTIVE confirm M-ASP_INACTIVE confirm
Direction: LM -> M3UA Direction: LM -> M3UA
Purpose: ASP reports that is has received an ASP INACTIVE Purpose: ASP reports that is has received an ASP Inactive
Acknowledgement message from the SG. Ack message from its peer.
M-ASP INACTIVE indication M-ASP_INACTIVE indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: LM reports it has successfully processed an incoming ASP- Purpose: M3UA reports it has successfully processed an incoming ASP
INACTIVE request from its peer. Inactive message from its peer.
M-AS ACTIVE indication M-AS_ACTIVE indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: LM reports that an AS has moved to the ACTIVE state. Purpose: M3UA reports that an AS has moved to the AS-ACTIVE state.
M-AS INACTIVE indication M-AS_INACTIVE indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: LM reports that an AS has moved to the INACTIVE state. Purpose: M3UA reports that an AS has moved to the AS-INACTIVE state.
M-AS DOWN indication M-AS_DOWN indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: LM reports that an AS has moved to the DOWN state. Purpose: M3UA reports that an AS has moved to the AS-DOWN state.
If dynamic registration of RK is supported by the M3UA layer, the layer
MAY support the following additional primitives:
M-RK_REG request
Direction: LM -> M3UA
Purpose: LM requests ASP to register RK(s) with its peer by sending
REG REQ message
M-RK_REG confirm
Direction: M3UA -> LM
Purpose: ASP reports that it has received REG RSP message with
registration status as successful from its peer.
M-RK_REG indication
Direction: M3UA -> LM
Purpose: M3UA informs LM that it has successfully processed an
incoming REG REQ message.
M-RK_DEREG request
Direction: LM -> M3UA
Purpose: LM requests ASP to de-register RK(s) with its peer by
sending DEREG REQ message.
M-RK_DEREG confirm
Direction: M3UA -> LM
Purpose: ASP reports that it has received DEREG REQ message with de-
registration status as successful from its peer.
M-RK_DEREG indication
Direction: M3UA -> LM
Purpose: M3UA informs LM that it has successfully processed an
incoming DEREG REQ from its peer.
2.0 Conventions 2.0 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD
NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear
in this document, are to be interpreted as described in [RFC2119]. in this document, are to be interpreted as described in [RFC2119].
3.0 M3UA Protocol Elements 3. M3UA Protocol Elements
The general M3UA message format includes a Common Message Header The general M3UA message format includes a Common Message Header
followed by zero or more parameters as defined by the Message Type. followed by zero or more parameters as defined by the Message Type.
For forward compatibility, all Message Types may have attached For forward compatibility, all Message Types may have attached
parameters even if none are specified in this version. parameters even if none are specified in this version.
3.1 Common Message Header 3.1 Common Message Header
The protocol messages for MTP3-User Adaptation require a message header The protocol messages for MTP3-User Adaptation require a message header
which contains the adaptation layer version, the message type, and which contains the adaptation layer version, the message type, and
skipping to change at page 30, line 24 skipping to change at page 29, line 13
1 Release 1.0 1 Release 1.0
3.1.2 Message Classes and Types 3.1.2 Message Classes and Types
The following list contains the valid Message Classes: The following list contains the valid Message Classes:
Message Class: 8 bits (unsigned integer) Message Class: 8 bits (unsigned integer)
The following list contains the valid Message Type Classes: The following list contains the valid Message Type Classes:
0 Management (MGMT) Message [IUA/M2UA/M3UA/SUA] 0 Management (MGMT) Message
1 Transfer Messages [M3UA] 1 Transfer Messages
2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA] 2 SS7 Signalling Network Management (SSNM) Messages
3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA] 3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA] 4 ASP Traffic Maintenance (ASPTM) Messages
5 Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages 5 Reserved for Other Sigtran Adaptation Layers
[IUA] 6 Reserved for Other Sigtran Adaptation Layers
6 MTP2 User Adaptation (MAUP) Messages [M2UA] 7 Reserved for Other Sigtran Adaptation Layers
7 Connectionless Messages [SUA] 8 Reserved for Other Sigtran Adaptation Layers
8 Connection-Oriented Messages [SUA] 9 Routing Key Management (RKM) Messages
9 Routing Key Management (RKM) Messages (M3UA)
10 to 127 Reserved by the IETF 10 to 127 Reserved by the IETF
28 to 255 Reserved for IETF-Defined Message Class extensions 128 to 255 Reserved for IETF-Defined Message Class extensions
Message Type: 8 bits (unsigned integer) Message Type: 8 bits (unsigned integer)
The following list contains the message types for the defined The following list contains the message types for the defined
messages. messages.
Management (MGMT) Message Management (MGMT) Messages (See Section 3.6)
0 Error (ERR) 0 Error (ERR)
1 Notify (NTFY) 1 Notify (NTFY)
2 to 127 Reserved by the IETF 2 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MGMT extensions 128 to 255 Reserved for IETF-Defined MGMT extensions
Transfer Messages Transfer Messages (See Section 3.3)
0 Reserved 0 Reserved
1 Payload Data (DATA) 1 Payload Data (DATA)
2 to 127 Reserved by the IETF 2 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined Transfer extensions 128 to 255 Reserved for IETF-Defined Transfer extensions
SS7 Signalling Network Management (SSNM) Messages
SS7 Signalling Network Management (SSNM) Messages (See Section
3.4)
0 Reserved 0 Reserved
1 Destination Unavailable (DUNA) 1 Destination Unavailable (DUNA)
2 Destination Available (DAVA) 2 Destination Available (DAVA)
3 Destination State Audit (DAUD) 3 Destination State Audit (DAUD)
4 SS7 Network Congestion State (SCON) 4 SS7 Network Congestion (SCON)
5 Destination User Part Unavailable (DUPU) 5 Destination User Part Unavailable (DUPU)
6 Destination Restricted (DRST) 6 Destination Restricted (DRST)
7 to 127 Reserved by the IETF 7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined SSNM extensions 128 to 255 Reserved for IETF-Defined SSNM extensions
ASP State Maintenance (ASPSM) Messages (See Section 3.5)
ASP State Maintenance (ASPSM) Messages
0 Reserved 0 Reserved
1 ASP Up (UP) 1 ASP Up (ASPUP)
2 ASP Down (DOWN) 2 ASP Down (ASPDN)
3 Heartbeat (BEAT) 3 Heartbeat (BEAT)
4 ASP Up Ack (UP ACK) 4 ASP Up Acknowledgement (ASPUP ACK)
5 ASP Down Ack (DOWN ACK) 5 ASP Down Acknowledgement (ASPDN ACK)
6 Heatbeat Ack (BEAT ACK) 6 Heatbeat Acknowledgement (BEAT ACK)
7 to 127 Reserved by the IETF 7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPSM extensions 128 to 255 Reserved for IETF-Defined ASPSM extensions
ASP Traffic Maintenance (ASPTM) Messages ASP Traffic Maintenance (ASPTM) Messages (See Section 3.5)
0 Reserved 0 Reserved
1 ASP Active (ACTIVE) 1 ASP Active (ASPAC)
2 ASP Inactive (INACTIVE) 2 ASP Inactive (ASPIA)
3 ASP Active Ack (ACTIVE ACK) 3 ASP Active Acknowledgement (ASPAC ACK)
4 ASP Inactive Ack (INACTIVE ACK) 4 ASP Inactive Acknowledgement (ASPIA ACK)
5 to 127 Reserved by the IETF 5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPTM extensions 128 to 255 Reserved for IETF-Defined ASPTM extensions
Routing Key Management (RKM) Messages Routing Key Management (RKM) Messages (See Section 3.7)
0 Reserved 0 Reserved
1 Registration Request (REG REQ) 1 Registration Request (REG REQ)
2 Registration Response (REG RSP) 2 Registration Response (REG RSP)
3 Deregistration Request (DEREG REQ) 3 Deregistration Request (DEREG REQ)
4 Deregistration Response (DEREG RSP) 4 Deregistration Response (DEREG RSP)
5 to 127 Reserved by the IETF 5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPTM extensions 128 to 255 Reserved for IETF-Defined RKM extensions
3.1.3 Reserved: 8 bits 3.1.3 Reserved: 8 bits
The Reserved field SHOULD be set to all '0's and ignored by the The Reserved field SHOULD be set to all '0's and ignored by the
receiver. receiver.
3.1.4 Message Length: 32-bits (unsigned integer) 3.1.4 Message Length: 32-bits (unsigned integer)
The Message Length defines the length of the message in octets, The Message Length defines the length of the message in octets,
including the Common Header. For messages with a final parameter including the Common Header. For messages with a final parameter
skipping to change at page 32, line 39 skipping to change at page 31, line 29
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where more than one parameter is included in a message, the parameters Where more than one parameter is included in a message, the parameters
may be in any order, except where explicitly mandated. A receiver may be in any order, except where explicitly mandated. A receiver
SHOULD accept the parameters in any order. SHOULD accept the parameters in any order.
Parameter Tag: 16 bits (unsigned integer) Parameter Tag: 16 bits (unsigned integer)
The Tag field is a 16-bit identifier of the type of parameter. It The Tag field is a 16-bit identifier of the type of parameter. It
takes a value of 0 to 65534. The parameter Tags defined are as takes a value of 0 to 65534. Common parameters used by adaptation
follows: layers are in the range of 0x00 to 0xff. M3UA-specific parameters
have Tags in the range 0x80 to 0xbf. The parameter Tags defined are
as follows:
0 Reserved 0x00 Reserved
1 Network Appearance 0x80 Network Appearance
2 Protocol Data 1 0x81 Protocol Data 1
3 Protocol Data 2 0x82 Protocol Data 2
4 Info String 0x04 INFO String
5 Affected Destinations 0x83 Affected Destinations
6 Routing Context 0x06 Routing Context
7 Diagnostic Information 0x07 Diagnostic Information
8 Heartbeat Data 0x09 Heartbeat Data
9 User/Cause 0x84 User/Cause
10 Reason 0x0a Reason
11 Traffic Mode Type 0x0b Traffic Mode Type
12 Error Code 0x0c Error Code
13 Status Type/ID 0x0d Status
14 Congestion Indications 0x85 Congestion Indications
15 Concerned Destination 0x86 Concerned Destination
16 Routing Key 0x87 Routing Key
17 Registration Result 0x88 Registration Result
18 De-registration Result 0x89 De-registration Result
19 Local_Routing Key Identifier 0x8a Local_Routing Key Identifier
20 Destination Point Code 0x8b Destination Point Code
21 Service Indicators 0x8c Service Indicators
22 Subsystem Numbers 0x8d Subsystem Numbers
23 Originating Point Code List 0x8e Originating Point Code List
24 Circuit Range 0x8f Circuit Range
25 Registration Results 0x90 Registration Results
26 De-Registration Results 0x91 De-Registration Results
27 to 65534 Reserved by the IETF 0x92 to ffff...Reserved by the IETF
The value of 65535 is reserved for IETF-defined extensions. Values The value of 65535 is reserved for IETF-defined extensions. Values
other than those defined in specific parameter description are other than those defined in specific parameter description are
reserved for use by the IETF. reserved for use by the IETF.
Parameter Length: 16 bits (unsigned integer) Parameter Length: 16 bits (unsigned integer)
The Parameter Length field contains the size of the parameter in The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Tag, Parameter Length, and Parameter bytes, including the Parameter Tag, Parameter Length, and Parameter
Value fields. The Parameter Length does not include any padding Value fields. The Parameter Length does not include any padding
skipping to change at page 33, line 42 skipping to change at page 32, line 32
Parameter Value: variable-length. Parameter Value: variable-length.
The Parameter Value field contains the actual information to be The Parameter Value field contains the actual information to be
transferred in the parameter. transferred in the parameter.
The total length of a parameter (including Tag, Parameter Length and The total length of a parameter (including Tag, Parameter Length and
Value fields) MUST be a multiple of 4 bytes. If the length of the Value fields) MUST be a multiple of 4 bytes. If the length of the
parameter is not a multiple of 4 bytes, the sender pads the parameter is not a multiple of 4 bytes, the sender pads the
Parameter at the end (i.e., after the Parameter Value field) with Parameter at the end (i.e., after the Parameter Value field) with
all zero bytes. The length of the padding is NOT included in the all zero bytes. The length of the padding is NOT included in the
parameter length field. A sender SHOULD NEVER pad with more than 3 parameter length field. A sender SHOULD NOT pad with more than 3
bytes. The receiver MUST ignore the padding bytes. bytes. The receiver MUST ignore the padding bytes.
3.3 Transfer Messages 3.3 Transfer Messages
The following section describes the Transfer messages and parameter The following section describes the Transfer messages and parameter
contents. contents.
3.3.1 Payload Data Message (DATA) 3.3.1 Payload Data Message (DATA)
The DATA message contains the SS7 MTP3-User protocol data, which is an The DATA message contains the SS7 MTP3-User protocol data, which is an
MTP-TRANSFER primitive, including the complete MTP3 Routing Label. The MTP-TRANSFER primitive, including the complete MTP3 Routing Label. The
Data message contains the following variable length parameters: DATA message contains the following variable length parameters:
Network Appearance Optional Network Appearance Optional
Protocol Data 1 or 2 Mandatory Protocol Data 1 or 2 Mandatory
The following format MUST be used for the Data Message: The following format MUST be used for the Data Message:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 1 | Length = 8 | | Tag = 0x80 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance* | | Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 3 | Length | | Tag = 0x81 or 0x82 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Protocol Data / / Protocol Data /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance: 32-bits (unsigned integer) Network Appearance: 32-bits (unsigned integer)
The optional Network Appearance parameter identifies the SS7 network The optional Network Appearance parameter identifies the SS7 network
context for the message, for the purposes of logically separating context for the message, for the purposes of logically separating
the signalling traffic between the SG and the Application Server the signalling traffic between the SGP and the ASP over a common
Process over a common SCTP Association. An example is where an SG SCTP association. An example is where an SG is logically
is logically partitioned to appear as an element in four different partitioned to appear as an element in four different national SS7
national SS7 networks. networks.
In a Data message, the Network Appearance implicitly defines the SS7 In a DATA message, the Network Appearance implicitly defines the SS7
Point Code format used, the SS7 Network Indicator value, and the Point Code format used, the SS7 Network Indicator value, and the
MTP3 and possibly the MTP3-User protocol type/variant/version used MTP3 and possibly the MTP3-User protocol type/variant/version used
within the SS7 network partition. Where an SG operates in the within the SS7 network partition. Where an SG operates in the
context of a single SS7 network, or individual SCTP associations are context of a single SS7 network, or individual SCTP associations are
dedicated to each SS7 network context, the Network Appearance dedicated to each SS7 network context, the Network Appearance
parameter is not required. parameter is not required. In other cases the parameter MUST be
included.
The Network Appearance parameter value is of local significance The Network Appearance parameter value is of local significance
only, coordinated between the SG and ASP. Therefore, in the case only, coordinated between the SGP and ASP. Therefore, in the case
where an ASP is connected to more than one SG, the same SS7 network where an ASP is connected to more than one SGP, the same SS7 network
context may be identified by different Network Appearances depending context may be identified by different Network Appearance values
over which SG a message is being transmitted/received. depending over which SGP a message is being transmitted/received.
Where the optional Network Appearance parameter is present, it must Where the optional Network Appearance parameter is present, it must
be the first parameter in the message as it defines the format of be the first parameter in the message as it defines the format of
the Protocol Data field. the Protocol Data field
Protocol Data 1 or 2: variable length
One of two possible Protocol Data parameters are included in a DATA One of two possible Protocol Data parameters are included in a DATA
message: Protocol Data 1 or Protocol Data 2. message: Protocol Data 1 or Protocol Data 2.
Protocol Data 1 or 2: variable length
The Protocol Data 1 parameter contains the original SS7 MTP3 The Protocol Data 1 parameter contains the original SS7 MTP3
message, including the Service Information Octet and Routing Label. message, including the Service Information Octet and Routing Label.
The Protocol Data 1 parameter contains the following fields: The Protocol Data 1 parameter contains the following fields:
Service Information Octet. Includes: Service Information Octet. Includes:
Service Indicator, Service Indicator,
Network Indicator, Network Indicator,
and Spare/Priority codes and Spare/Priority codes.
Routing Label. Includes: Routing Label. Includes:
Destination Point Code, Destination Point Code,
Originating Point Code, Originating Point Code,
And Signalling Link Selection Code (SLS) And Signalling Link Selection Code (SLS).
User Protocol Data. Includes: User Protocol Data. Includes:
MTP3-User protocol elements (e.g., ISUP, SCCP, or TUP MTP3-User protocol elements (e.g., ISUP, SCCP, or TUP
parameters) parameters).
The Protocol Data 2 parameter contains all the information in The Protocol Data 2 parameter contains all the information in
Protocol Data 1 as described above, plus the MTP2 Length Indicator Protocol Data 1 as described above, plus the MTP2 Length Indicator
octet. The MTP2 Length Indicator (LI) octet appears before the SIO octet. The MTP2 Length Indicator (LI) octet appears before the SIO
and Routing Label information. The MTP2 Length Indicator octet is and Routing Label information. The MTP2 Length Indicator octet is
required for some national MTP variants that use the spare bits in required for some national MTP variants that use the spare bits in
the LI to carry additional information of interest to the MTP3 and the LI to carry additional information of interest to the MTP3 and
MTP3-User (e.g., the Japan TTC standard use of LI spare bits to MTP3-User (e.g., the Japan TTC standard use of LI spare bits to
indicate message priority) indicate message priority)
The Payload Data format is as defined in the relevant MTP standards The Payload Data format is as defined in the relevant MTP standards
for the SS7 protocol being transported. The format is either for the SS7 protocol being transported. The format is either
implicitly known or identified by the Network Appearance parameter. implicitly known or identified by the Network Appearance parameter.
Note: In the SS7 Recommendations, the format of the messages and Note: In the SS7 Recommendations, the format of the messages and
fields within the messages are based on bit transmission order. In fields within the messages are based on bit transmission order. In
these recommendations the Least Significant Bit (LSB) of each field these recommendations the Least Significant Bit (LSB) of each field
is positioned to the right. For this document the received SS7 is positioned to the right. The received SS7 fields are populated
fields are populated octet by octet as received into the 4-octet octet by octet as received into the 4-octet word as shown in the two
word as shown in the examples below. examples below.
For the ANSI protocol example, the Protocol Data field format is For the ANSI protocol example, the Protocol Data 1 field format is
shown below: shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIO | DPC Member | DPC Cluster | DPC Network | | SIO | DPC Member | DPC Cluster | DPC Network |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPC Member | OPC Cluster | OPC Network | SLS | | OPC Member | OPC Cluster | OPC Network | SLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Protocol Data / / Protocol Data /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSB---------------------------------------------------------LSB| |MSB---------------------------------------------------------LSB|
Within each octet the Least Significant Bit (LSB) per the SS7 Within each octet the Least Significant Bit (LSB) per the SS7
Recommendations is to the right (e.g., bit 7 of SIO is the LSB). Recommendations is to the right (e.g., bit 7 of SIO is the LSB).
For the ITU international protocol example, the Protocol Data field For the ITU international protocol example (with the 3/8/3 Point
is shown below. Code format), the Protocol Data 1 field is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIO | DPC | DPC |OPC| DPC | DPC | OPC |@| | SIO | DPC | DPC |OPC| DPC | DPC | OPC |@|
| | Region *| SP *|SP*|Zone*| reg.| Region *| | | | Region *| SP *|SP*|Zone*| reg.| Region *| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLS | OPC |$| Protocol | | SLS | OPC |$| Protocol |
| *| SP *| | Data | | *|Zone*| | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* marks LSB of each field; @ = OPC SP MSB; $ = OPC region MSB * marks LSB of each field; @ = OPC SP MSB; $ = OPC region MSB
3.4 SS7 Signalling Network Management (SSNM) Messages 3.4 SS7 Signalling Network Management (SSNM) Messages
3.4.1 Destination Unavailable (DUNA) 3.4.1 Destination Unavailable (DUNA)
The DUNA message is sent from the SG to all concerned ASPs to indicate The DUNA message is sent from all SGPs in an SG to all concerned ASPs
that the SG has determined that one or more SS7 destinations are to indicate that the SG has determined that one or more SS7
unreachable. It is also sent in response to a message from the ASP to destinations are unreachable. It is also sent by an SGP in response to
an unreachable SS7 destination. As an implementation option the SG may a message from the ASP to an unreachable SS7 destination. As an
suppress the sending of subsequent "response" DUNAs regarding a certain implementation option the SG may suppress the sending of subsequent
unreachable SS7 destination for a certain period in order to give the "response" DUNA messages regarding a certain unreachable SS7
remote side time to react. The MTP3-User at the ASP is expected to stop destination for a certain period in order to give the remote side time
traffic to the affected destination through the SG initiating the DUNA to react. The MTP3-User at the ASP is expected to stop traffic to the
as per the defined MTP3-User procedures. affected destination through the SGPs initiating the DUNA message as
per the defined MTP3-User procedures.
The DUNA message contains the following parameters: The DUNA message contains the following parameters:
Network Appearance Optional Network Appearance Optional
Affected Destinations Mandatory Affected Destinations Mandatory
Info String Optional INFO String Optional
The format for DUNA Message parameters is as follows: The format for DUNA Message parameters is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 1 | Length =8 | | Tag = 0x80 | Length =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance* | | Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 5 | Length | | Tag = 0x83 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected DPC 1 | | Mask | Affected DPC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ ... / / ... /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected DPC n | | Mask | Affected DPC n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 4 | Length | | Tag = 0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String* / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance: 32-bit unsigned integer Network Appearance: 32-bit unsigned integer
See Section 3.3.1 See Section 3.3.1
Affected Destinations: n x 32-bits Affected Destinations: n x 32-bits
The Affected Destinations parameter contains up to sixteen Affected The Affected Destinations parameter contains up to sixteen Affected
skipping to change at page 39, line 8 skipping to change at page 38, line 8
"wildcarded". For example, a mask of "8" indicates that the least "wildcarded". For example, a mask of "8" indicates that the least
significant eight bits of the DPC is "wildcarded". For an ANSI 24- significant eight bits of the DPC is "wildcarded". For an ANSI 24-
bit Affected DPC, this is equivalent to signalling that all DPCs in bit Affected DPC, this is equivalent to signalling that all DPCs in
an ANSI Cluster are unavailable. A mask of "3" indicates that the an ANSI Cluster are unavailable. A mask of "3" indicates that the
least significant three bits of the DPC is "wildcarded". For a 14- least significant three bits of the DPC is "wildcarded". For a 14-
bit ITU Affected DPC, this is equivalent to signaling that an ITU bit ITU Affected DPC, this is equivalent to signaling that an ITU
Region is unavailable. A mask value equal to the number of bits in Region is unavailable. A mask value equal to the number of bits in
the DPC indicates that the entire network appearance is affected the DPC indicates that the entire network appearance is affected
this is used to indicate network isolation to the ASP. this is used to indicate network isolation to the ASP.
Info String: variable length INFO String: variable length
The optional INFO String parameter can carry any 8-bit ASCII The optional INFO String parameter can carry any 8-bit ASCII
character string along with the message. Length of the INFO character string along with the message. Length of the INFO
String parameter is from 0 to 255 characters. No procedures are String parameter is from 0 to 255 characters. No procedures are
presently identified for its use but the INFO String MAY be used by presently identified for its use but the INFO String MAY be used by
Operators to identify in text form the location reflected by the Operators to identify in text form the location reflected by the
Affected DPC for debugging purposes. Affected DPC for debugging purposes.
3.4.2 Destination Available (DAVA) 3.4.2 Destination Available (DAVA)
The DAVA message is sent from the SG to all concerned ASPs to indicate The DAVA message is sent from the SGP to all concerned ASPs to indicate
that the SG has determined that one or more SS7 destinations are now that the SG has determined that one or more SS7 destinations are now
reachable (and not restricted), or in response to a DAUD message if reachable (and not restricted), or in response to a DAUD message if
appropriate. The ASP MTP3-User protocol is allowed to resume traffic to appropriate. The ASP MTP3-User protocol is informed and may now resume
the affected destination through the SG initiating the DUNA. traffic to the affected destination. The ASP M3UA layer routes the
MTP3_user traffic through the SGP(s) initiating the DAVA message.
The DAVA message contains the following parameters: The DAVA message contains the following parameters:
Network Appearance Optional Network Appearance Optional
Affected Destinations Mandatory Affected Destinations Mandatory
Info String Optional INFO String Optional
The format and description of the Network Appearance, Affected The format and description of the Network Appearance, Affected
Destinations and Info String parameters is the same as for the DUNA Destinations and INFO String parameters is the same as for the DUNA
message (See Section 3.4.1.) message (See Section 3.4.1).
3.4.3 Destination State Audit (DAUD) 3.4.3 Destination State Audit (DAUD)
The DAUD message can be sent from the ASP to the SG to audit the The DAUD message MAY be sent from the ASP to the SGP to audit the
availability/congestion state of SS7 routes to one or more affected availability/congestion state of SS7 routes to one or more affected
destinations. destinations.
The DAUD message contains the following parameters: The DAUD message contains the following parameters:
Network Appearance Optional Network Appearance Optional
Affected Destinations Mandatory Affected Destinations Mandatory
Info String Optional INFO String Optional
The format and description of DAUD Message parameters is the same as The format and description of DAUD Message parameters is the same as
for the DUNA message (See Section 3.4.1.) for the DUNA message (See Section 3.4.1).
3.4.4 SS7 Network Congestion (SCON) 3.4.4 SS7 Network Congestion (SCON)
The SCON message can be sent from the SG to all concerned ASPs to The SCON message can be sent from the SGP to all concerned ASPs to
indicate congestion in the SS7 network to one or more destinations, or indicate congestion in the SS7 network to one or more destinations, or
to an ASP in response to a DATA or DAUD message as appropriate. For to an ASP in response to a DATA or DAUD message as appropriate. For
some MTP protocol variants (e.g., ANSI MTP) the SCON may be sent when some MTP protocol variants (e.g., ANSI MTP) the SCON message may be
the SS7 congestion level changes. The SCON message MAY also be sent sent when the SS7 congestion level changes. The SCON message MAY also
from the M3UA of an ASP to an M3UA peer indicating that the M3UA or the be sent from the M3UA layer of an ASP to an M3UA peer indicating that
ASP is congested. the M3UA layer or the ASP is congested.
The SCON message contains the following parameters: The SCON message contains the following parameters:
Network Appearance Optional Network Appearance Optional
Affected Destinations Mandatory Affected Destinations Mandatory
Concerned Destination Optional Congestion Indications Concerned Destination Optional
Optional Congestion Indications Optional
Info String Optional INFO String Optional
The format for SCON Message parameters is as follows: The format for SCON Message parameters is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 1 | Length =8 | | Tag = 0x80 | Length =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance* | | Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 5 | Length | | Tag = 0x83 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected DPC 1 | | Mask | Affected DPC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ ... / / ... /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected DPC n | | Mask | Affected DPC n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 15 | Length | | Tag = 0x86 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Concerned DPC | | reserved | Concerned DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 14 | Length | | Tag = 0x85 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Cong. Level* | | Reserved | Cong. Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 4 | Length | | Tag = 0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String* / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the Network Appearance, Affected The format and description of the Network Appearance, Affected
Destinations, and Info String parameters is the same as for the DUNA Destinations, and INFO String parameters is the same as for the DUNA
message (See Section 3.4.1.) message (See Section 3.4.1).
The Affected Destinations parameter can be used to indicate congestion The Affected Destinations parameter can be used to indicate congestion
of multiple destinations or ranges of destinations. However, an SCON of multiple destinations or ranges of destinations. However, an SCON
MUST not be delayed in order to "collect" individual congested message MUST not be delayed in order to "collect" individual congested
destinations into a single SCON as any delay might affect the timing of destinations into a single SCON message as any delay might affect the
congestion indications to the M3UA Users. One use for including a timing of congestion indications to the M3UA Users. One use for
range of Congested DPCs is when the SG supports an ANSI cluster route including a range of Congested DPCs is when the SG supports an ANSI
set to the SS7 network that becomes congested due to outgoing link set cluster route set to the SS7 network that becomes congested due to
congestion. outgoing link set congestion.
Concerned Destination: 32-bits Concerned Destination: 32-bits
The optional Concerned Destination parameter is only used if the The optional Concerned Destination parameter is only used if the
SCON is sent from an ASP to the SG. It contains the point code of SCON message is sent from an ASP to the SGP. It contains the point
the originator of the message that triggered the SCON. The Concerned code of the originator of the message that triggered the SCON
Destination parameter contains one Concerned Destination Point Code message. The Concerned Destination parameter contains one Concerned
field, a three-octet parameter to allow for 14-, 16- and 24-bit Destination Point Code field, a three-octet parameter to allow for
binary formatted SS7 Point Codes. A Concerned Point Code that is 14-, 16- and 24-bit binary formatted SS7 Point Codes. A Concerned
less than 24-bits, is padded on the left to the 24-bit boundary. The Point Code that is less than 24-bits is padded on the left to the
SG sends a Transfer Controlled Message to the Concerned Point Code 24-bit boundary. Any resulting Transfer Controlled (TFC) message
using the single Affected DPC contained in the SCON to populate the from the SG is sent to the Concerned Point Code using the single
(affected) Destination field of the TFC message. Normally the Affected DPC contained in the SCON message to populate the
Affected DPC will be equal to the point code of the ASP. (affected) Destination field of the TFC message
Congested Indications: 32-bits Congested Indications: 32-bits
The optional Congestion Indications parameter contains a Congestion The optional Congestion Indications parameter contains a Congestion
Level field. This optional parameter is used to communicate Level field. This optional parameter is used to communicate
congestion levels in national MTP networks with multiple congestion congestion levels in national MTP networks with multiple congestion
thresholds, such as in ANSI MTP3. For MTP congestion methods thresholds, such as in ANSI MTP3. For MTP congestion methods
without multiple congestion levels (e.g., the ITU international without multiple congestion levels (e.g., the ITU international
method) the parameter is not included. method) the parameter is not included.
skipping to change at page 42, line 7 skipping to change at page 40, line 53
0 No Congestion or Undefined 0 No Congestion or Undefined
1 Congestion Level 1 1 Congestion Level 1
2 Congestion Level 2 2 Congestion Level 2
3 Congestion Level 3 3 Congestion Level 3
The congestion levels are defined in the congestion method in the The congestion levels are defined in the congestion method in the
appropriate national MTP recommendations [14,15]. appropriate national MTP recommendations [14,15].
3.4.5 Destination User Part Unavailable (DUPU) 3.4.5 Destination User Part Unavailable (DUPU)
The DUPU message is used by an SG to inform an ASP that a remote peer The DUPU message is used by an SGP to inform an ASP that a remote peer
MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable. MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable.
The DUPU message contains the following parameters: The DUPU message contains the following parameters:
Network Appearance Optional Network Appearance Optional
Affected Destinations Mandatory Affected Destinations Mandatory
User/Cause Mandatory User/Cause Mandatory
Info String Optional INFO String Optional
The format for DUPU Message parameters is as follows: The format for DUPU message parameters is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 1 | Length | | Tag = 0x80 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance* | | Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 5 | Length = 8 | | Tag = 0x83 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Affected DPC | | Mask = 0 | Affected DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 9 | Length = 8 | | Tag = 0x84 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause | User | | Cause | User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 4 | Length | | Tag = 0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String* / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
User/Cause: 32-bits User/Cause: 32-bits
The Unavailability Cause and MTP3-User Identity fields, associated The Unavailability Cause and MTP3-User Identity fields, associated
with the Affected DPC in the Affected Destinations parameter, are with the Affected DPC in the Affected Destinations parameter, are
encoded as follows: encoded as follows:
Unavailability Cause field: 16-bits (unsigned integer) Unavailability Cause field: 16-bits (unsigned integer)
The Unavailability Cause parameter provides the reason for the The Unavailability Cause parameter provides the reason for the
unavailability of the MTP3-User. The valid values for the unavailability of the MTP3-User. The valid values for the
Unavailability Cause parameter are shown in the following table. Unavailability Cause parameter are shown in the following table.
The values agree with those provided in the SS7 MTP3 User Part The values agree with those provided in the SS7 MTP3 User Part
Unavailable message. Depending on the MTP3 protocol used in the Unavailable message. Depending on the MTP3 protocol used in the
network appearance, additional values may be used - the Network Appearance, additional values may be used - the
specification of the relevant MTP3 protocol variant/version specification of the relevant MTP3 protocol variant/version
recommendation is definitive. recommendation is definitive.
0 Unknown 0 Unknown
1 Unequipped Remote User 1 Unequipped Remote User
2 Inaccessible Remote User 2 Inaccessible Remote User
MTP3-User Identity field: 16-bits (unsigned integer) MTP3-User Identity field: 16-bits (unsigned integer)
The MTP3-User Identity describes the specific MTP3-User that is The MTP3-User Identity describes the specific MTP3-User that is
unavailable (e.g., ISUP, SCCP, ...). Some of the valid values for unavailable (e.g., ISUP, SCCP, ...). Some of the valid values for
the MTP3-User Identity are shown below. The values agree with those the MTP3-User Identity are shown below. The values align with those
provided in the SS7 MTP3 User Part Unavailable message and Service provided in the SS7 MTP3 User Part Unavailable message and Service
Indicator. Depending on the MTP3 protocol variant/version used in Indicator. Depending on the MTP3 protocol variant/version used in
the network appearance, additional values may be used. The relevant the network appearance, additional values may be used. The relevant
MTP3 protocol variant/version recommendation is definitive. MTP3 protocol variant/version recommendation is definitive.
0 to 2 Reserved 0 to 2 Reserved
3 SCCP 3 SCCP
4 TUP 4 TUP
5 ISUP 5 ISUP
6 to 8 Reserved 6 to 8 Reserved
9 Broadband ISUP 9 Broadband ISUP
10 Satellite ISUP 10 Satellite ISUP
11 Reserved
12 AAL type 2 Signalling
13 Bearer Independent Call Control (BICC)
14 Gateway Control Protocol
15 Reserved
The format and description of the Affected Destinations parameter is The format and description of the Affected Destinations parameter is
the same as for the DUNA message (See Section 3.4.1.) except that the the same as for the DUNA message (See Section 3.4.1.) except that the
Mask field is not used and only a single Affected DPC is included. Mask field is not used and only a single Affected DPC is included.
Ranges and lists of Affected DPCs cannot be signaled in a DUPU, but Ranges and lists of Affected DPCs cannot be signalled in a DUPU
this is consistent with UPU operation in the SS7 network. The Affected message, but this is consistent with UPU operation in the SS7 network.
Destinations parameter in an MTP3 User Part Unavailable message (UPU) The Affected Destinations parameter in an MTP3 User Part Unavailable
received by an SG from the SS7 network contains only one destination. message (UPU) received by an SGP from the SS7 network contains only one
destination.
The format and description of the Network Appearance and Info String The format and description of the Network Appearance and INFO String
parameters is the same as for the DUNA message (See Section 3.4.1.). parameters is the same as for the DUNA message (See Section 3.4.1).
3.4.6 Destination Restricted (DRST) 3.4.6 Destination Restricted (DRST)
The DRST message is optionally sent from the SG to all concerned ASPs The DRST message is optionally sent from the SGP to all concerned ASPs
to indicate that the SG has determined that one or more SS7 to indicate that the SG has determined that one or more SS7
destinations are now restricted, or in response to a DAUD message if destinations are now restricted from the point of view of the SGP, or
appropriate. The M3UA at the ASP is expected to send traffic to the in response to a DAUD message if appropriate. The M3UA layer at the ASP
affected destination via an alternate SG of equal priority, but only if is expected to send traffic to the affected destination via an
such an alternate route exists and is available. If the affected alternate SGP of equal priority, but only if such an alternate route
destination is currently considered unavailable by the ASP, traffic to exists and is available. If the affected destination is currently
the affected destination through the SG initiating the DRST should be considered unavailable by the ASP, The MTP3-User should be informed
resumed. that traffic to the affected destination can be resumed. In this case,
the M3UA layer should route the traffic through the SGP initiating the
DRST message.
This message is optional for the SG to send and optional for the ASP to This message is optional for the SGP to send and it is optional for the
process. It is for use in the "STP" case described in Section 1.4.2. ASP to act on any information received in the message. It is for use in
the "STP" case described in Section 1.4.1.
The DRST message contains the following parameters: The DRST message contains the following parameters:
Network Appearance Optional Network Appearance Optional
Affected Destinations Mandatory Affected Destinations Mandatory
Info String Optional INFO String Optional
The format and description of the Network Appearance, Affected The format and description of the Network Appearance, Affected
Destinations and Info String parameters is the same as for the DUNA Destinations and INFO String parameters is the same as for the DUNA
message (See Section 3.4.1.) message (See Section 3.4.1).
3.5 Application Server Process Maintenance (ASPM) Messages 3.5 ASP State Maintenance (ASPSM) Messages
3.5.1 ASP Up (ASPUP) 3.5.1 ASP Up
The ASP UP (ASPUP) message is used to indicate to a remote M3UA peer The ASP Up message is used to indicate to a remote M3UA peer that the
that the Adaptation layer is ready to receive SSNM or ASPM management adaptation layer is ready to receive any SSNM or ASPSM/ASPTM messages
messages for all Routing Keys that the ASP is configured to serve. for all Routing Keys that the ASP is configured to serve.
The ASPUP message contains the following parameters: The ASP Up message contains the following parameters:
INFO String Optional INFO String Optional
The format for ASPUP Message parameters is as follows: The format for ASP Up message parameters is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 4 | Length | | Tag = 0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String* / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the The format and description of the optional INFO String parameter is the
same as for the DUNA message (See Section 3.4.1.) same as for the DUNA message (See Section 3.4.1).
3.5.2 ASP Up Ack 3.5.2 ASP Up Acknowledgement (ASP Up Ack)
The ASP UP Ack message is used to acknowledge an ASP-Up message The ASP UP Ack message is used to acknowledge an ASP Up message
received from a remote M3UA peer. received from a remote M3UA peer.
The ASPUP Ack message contains the following parameters: The ASP Up Ack message contains the following parameters:
INFO String (optional) INFO String (optional)
The format for ASPUP Ack Message parameters is as follows: The format for ASP Up Ack message parameters is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =4 | Length | | Tag =0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String* / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the The format and description of the optional INFO String parameter is the
same as for the DUNA message (See Section 3.4.1.) same as for the DUNA message (See Section 3.4.1). The INFO String in
an ASP Up Ack message is independent from the INFO String in the ASP Up
message (i.e., it does not have to echo back the INFO String received).
3.5.3 ASP Down (ASPDN) 3.5.3 ASP Down
The ASP Down (ASPDN) message is used to indicate to a remote M3UA peer The ASP Down message is used to indicate to a remote M3UA peer that the
that the adaptation layer is NOT ready to receive traffic or adaptation layer is NOT ready to receive DATA, SSNM or ASPTM messages.
maintenance messages.
The ASPDN message contains the following parameters: The ASP Down message contains the following parameters:
Reason Mandatory Reason Mandatory
INFO String Optional INFO String Optional
The format for the ASPDN message parameters is as follows: The format for the ASP Down message parameters is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 10 | Length | | Tag = 0x0a | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =4 | Length | | Tag =0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String* / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the The format and description of the optional INFO String parameter is the
same as for the DUNA message (See Section 3.4.1.) same as for the DUNA message (See Section 3.4.1).
Reason: 32-bit (unsigned integer) Reason: 32-bit (unsigned integer)
The Reason parameter indicates the reason that the remote M3UA The Reason parameter indicates the reason that the remote M3UA
adaptation layer is unavailable. The valid values for Reason are adaptation layer is unavailable. The valid values for Reason are
shown in the following table. shown in the following table.
0 Unspecified 0 Unspecified
1 User Unavailable 1 User Unavailable
2 Management Blocking 2 Management Blocking
3.5.4 ASP Down Ack 3.5.4 ASP Down Acknowledgement (ASP Down Ack)
The ASP Down Ack message is used to acknowledge an ASP-Down message The ASP Down Ack message is used to acknowledge an ASP Down message
received from a remote M3UA peer, or to reply to an ASPM message from received from a remote M3UA peer.
an ASP which is locked out for management reasons.
The ASP Down Ack message contains the following parameters: The ASP Down Ack message contains the following parameters:
Reason Mandatory Reason Mandatory
INFO String Optional INFO String Optional
The format for the ASPDN Ack message parameters is as follows: The format for the ASP Down Ack message parameters is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 10 | Length | | Tag = 0x0a | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 4 | Length | | Tag = 0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String* / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the The format and description of the optional INFO String parameter is the
same as for the DUNA message (See Section 3.4.1.) same as for the DUNA message (See Section 3.4.1).
The INFO String in an ASP Down Ack message is independent from the INFO
String in the ASP Down message (i.e., it does not have to echo back the
INFO String received).
The format of the Reason parameter is the same as for the ASP-Down The format of the Reason parameter is the same as for the ASP-Down
message. (See Section 3.4.3) message. (See Section 3.5.3).
3.5.5 Registration Request (REG REQ) 3.5.5 Heartbeat (BEAT)
The REG REQ message is sent by an ASP to indicate to a remote M3UA peer The BEAT message is optionally used to ensure that the M3UA peers
that it wishes to register one or more given Routing Key with the are still available to each other. It is recommended for use when the
M3UA runs over a transport layer other than the SCTP, which has its own
heartbeat.
The BEAT message contains the following parameters:
Heatbeat Data Optional
The format for the BEAT message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x09 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Heartbeat Data parameter contents are defined by the sending node.
The Heartbeat Data could include, for example, a Heartbeat Sequence
Number and/or Timestamp. The receiver of a BEAT message does not
process this field as it is only of significance to the sender. The
receiver MUST respond with a BEAT Ack message.
3.5.6 Heartbeat Acknowledgement (BEAT Ack)
The BEAT Ack message is sent in response to a received BEAT
message. It includes all the parameters of the received BEAT
message, without any change.
3.6 Routing Key Management (RKM) Messages
3.6.1 Registration Request (REG REQ)
The REG REQ message is sent by an ASP to indicate to a remote M3UA peer
that it wishes to register one or more given Routing Keys with the
remote peer. Typically, an ASP would send this message to an SGP, and remote peer. Typically, an ASP would send this message to an SGP, and
expects to receive a REG RSP in return with an associated Routing expects to receive a REG RSP message in return with an associated
Context value. Routing Context value.
The REG REQ message contains the following parameters: The REG REQ message contains the following parameters:
Routing Key Mandatory Routing Key Mandatory
The format for the REG REQ message is as follows: The format for the REG REQ message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 16 | Length | | Tag = 0x87 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Key 1 / / Routing Key 1 /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ ... / / ... /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 16 | Length | | Tag = 0x87 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Key n / / Routing Key n /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Key: variable length Routing Key: variable length
The Routing Key parameter is mandatory. The sender of this message The Routing Key parameter is mandatory. The sender of this message
expects that the receiver of this message will create a Routing expects that the receiver of this message will create a Routing
skipping to change at page 48, line 12 skipping to change at page 48, line 12
message. This is used to allow the registration of multiple Routing message. This is used to allow the registration of multiple Routing
Keys in a single message. Keys in a single message.
The format of the Routing Key parameter is as follows. The format of the Routing Key parameter is as follows.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier | | Local-RK-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code | | Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance (optional) | | Network Appearance (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI (optional) | | SI (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSN (optional) | | SSN (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origination Point Code List (optional) | | Origination Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Range List (optional) | | Circuit Range List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local-RK-Identifier: 32-bit integer Local-RK-Identifier: 32-bit integer
The mandatory Local-RK-Identifier field is used to uniquely identify The mandatory Local-RK-Identifier field is used to uniquely identify
the registration request. The Identifier value is assigned by the the registration request. The Identifier value is assigned by the
ASP, and is used to correlate the response in an REG RSP message ASP, and is used to correlate the response in an REG RSP message
with the original registration request. The Identifier value must with the original registration request. The Identifier value must
remain unique until the REG RSP is received. remain unique until the REG RSP message is received.
The format of the Local-RK-Identifier field is as follows: The format of the Local-RK-Identifier field is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 19 | Length = 8 | | ag = 0x8a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier value | | Local-RK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Traffic Mode Type: 32-bit (unsigned integer)
The Traffic Mode Type parameter is mandatory and identifies the
traffic mode of operation of the ASP(s) within an Application
Server. The valid values for Traffic Mode Type are shown in the
following table:
1 Over-ride
2 Load-share
If the receiver of the REG REQ creates a new Routing Key entry, then
the Traffic Mode Type sets the traffic mode for the new Application
Server. If the receiver of the REG REQ determines that a matching
Routing Key already exists, the Traffic Mode Type MUST match the
existing traffic mode for the AS.
Destination Point Code: Destination Point Code:
The Destination Point Code parameter is mandatory, and identifies The Destination Point Code parameter is mandatory, and identifies
the Destination Point Code of incoming SS7 traffic for which the ASP the Destination Point Code of incoming SS7 traffic for which the ASP
is registering. The format is the same as described for the is registering. The format is the same as described for the
Affected Destination parameter in the DUNA Message (See Section Affected Destination parameter in the DUNA message (See Section
3.4.1). Its format is: 3.4.1). Its format is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 20 | Length = 8 | | Tag = 0x8b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Destination Point Code | | Mask = 0 | Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance: Network Appearance:
The optional Network Appearance parameter field identifies the SS7 The optional Network Appearance parameter field identifies the SS7
Network context for the Routing Key, and has the same format as in network context for the Routing Key, and has the same format as in
the Data message (See Section 3.3.1). Its format is: the DATA message (See Section 3.3.1). The absence of the Network
Appearance parameter in the Routing Key indicates the use
of any Network Appearance value, Its format is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 1 | Length = 8 | | Tag = 0x80 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance | | Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Indicators (SI): n X 8-bit integers Service Indicators (SI): n X 8-bit integers
The SI field contains one or more Service Indicators from the values The optional SI field contains one or more Service Indicators from
as described in the MTP3-User Identity field of the DUPU Message. the values as described in the MTP3-User Identity field of the DUPU
The absence of the SI parameter in the Routing Key indicates the use message. The absence of the SI parameter in the Routing Key
of any SI values, excluding of course MTP management. Where an SI indicates the use of any SI value, excluding of course MTP
parameter does not contain a multiple of four SIs, the parameter is management. Where an SI parameter does not contain a multiple of
padded out to 32-byte alignment. An SI value of zero is not valid four SIs, the parameter is padded out to 32-byte alignment. An
in M3UA. The SI format is: SI value of zero is not valid in M3UA. The SI format is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 21 | Length = var. | | Tag = 0x8c | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI #1 | SI #2 | SI #3 | SI #4 | | SI #1 | SI #2 | SI #3 | SI #4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... / / ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI #n | 0 Padding, if necessary | | SI #n | 0 Padding, if necessary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subsystem Numbers (SSN): n X 8-bit integers Subsystem Numbers (SSN): n X 8-bit integers
The optional SSN field contains one or more SCCP subsystem numbers, The optional SSN field contains one or more SCCP subsystem numbers,
and is used in conjunction with an SI values of 3 (i.e., SCCP) only. and is used in conjunction with an SI values of 3 (i.e., SCCP) only.
Where an SSN parameter does not contain a multiple of four SSNs, the The absence of the SSN parameter in the Routing Key indicates the
parameter is padded out to 32-byte alignment. The subsystem number use of any SSN value, in the case of SCCP traffic. Where an SSN
values associated are defined by the local network operator, and parameter does not contain a multiple of four SSNs, the parameter is
typically follow ITU-T Recommendation Q.713. An SSN value of zero padded out to 32-byte alignment. The subsystem number values
is not valid in M3UA. The format of this field is as follows: associated are defined by the local network operator, and typically
follow ITU-T Recommendation Q.713 [5]. An SSN value of zero is not
valid in M3UA. The format of this field is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 22 | Length = var. | | Tag = 0x8d | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSN #1 | SSN #2 | SSN #3 | SSN #4 | | SSN #1 | SSN #2 | SSN #3 | SSN #4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... / / ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSN #n | 0 Padding, if necessary | | SSN #n | 0 Padding, if necessary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OPC List: OPC List:
The Originating Point Code List parameter contains one or more SS7 The Originating Point Code List parameter contains one or more SS7
OPC entries, and its format is the same as the Destination Point OPC entries, and its format is the same as the Destination Point
Code parameter. Code parameter. The absence of the OPC List parameter in the
Routing Key indicates the use of any OPC value,
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 23 | Length = var. | | Tag = 0x8e | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #1 | | Mask = 0 | Origination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #2 | | Mask = 0 | Origination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... / / ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #n | | Mask = 0 | Origination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Circuit Range: Circuit Range:
An ISUP controlled circuit is uniquely identified by the SS7 OPC, An ISUP controlled circuit is uniquely identified by the SS7 OPC,
DPC and CIC value. For the purposes of identifying Circuit Ranges DPC and CIC value. For the purposes of identifying Circuit Ranges
in an M3UA Routing Key, the optional Circuit Range parameter in an M3UA Routing Key, the optional Circuit Range parameter
includes one or more circuit ranges, each identified by an OPC and includes one or more circuit ranges, each identified by an OPC and
Upper/Lower CIC value. The DPC is implicit as it is mandatory and Upper/Lower CIC value. The DPC is implicit as it is mandatory and
already included in the DPC parameter of the Routing Key. The already included in the DPC parameter of the Routing Key. The
Origination Point Code is encoded the same as the Destination Point absence of the Circuit Range parameter in the Routing Key indicates
Code parameter, while the CIC values are 16-bit integers. the use of any Circuit Range values, in the case of ISUP/TUP
traffic. The Origination Point Code is encoded the same as the
Destination Point Code parameter, while the CIC values are 16-bit
integers.
The Circuit Range format is as follows: The Circuit Range format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 24 | Length = var. | | Tag = 0x8f | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #1 | | Mask = 0 | Origination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower CIC Value #1 | Upper CIC Value #1 | | Lower CIC Value #1 | Upper CIC Value #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #2 | | Mask = 0 | Origination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower CIC Value #2 | Upper CIC Value #2 | | Lower CIC Value #2 | Upper CIC Value #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... / / ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #n | | Mask = 0 | Origination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower CIC Value #n | Upper CIC Value #n | | Lower CIC Value #n | Upper CIC Value #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.5.6 Registration Response (REG RSP) 3.6 2 Registration Response (REG RSP)
The REG RSP message is used as a response to the REG REQ message from a The REG RSP message is used as a response to the REG REQ message from a
remote M3UA peer. It contains indications of success/failure for remote M3UA peer. It contains indications of success/failure for
registration requests and returns a unique Routing Context value for registration requests and returns a unique Routing Context value for
successful registration requests, to be used in subsequent M3UA Traffic successful registration requests, to be used in subsequent M3UA Traffic
Management protocol. Management protocol.
The REG RSP message contains the following parameters: The REG RSP message contains the following parameters:
Registration Results Mandatory Registration Results Mandatory
The format for the REG RSP message is as follows: The format for the REG RSP message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 25 | Length = var. | | Tag = 0x90 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result 1 | | Registration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... / / ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result n | | Registration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Registration Results: Registration Results:
skipping to change at page 52, line 27 skipping to change at page 52, line 53
| Local-RK-Identifier value | | Local-RK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Status | | Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context | | Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local-RK-Identifier: 32-bit integer Local-RK-Identifier: 32-bit integer
The Local-RK-Identifier contains the same value as found in the The Local-RK-Identifier contains the same value as found in the
matching Routing Key parameter found in the REG Req message. matching Routing Key parameter found in the REG REQ message (See
Section 3.5.5.1).
Registration Status: 32-bit integer Registration Status: 32-bit integer
The Registration Result Status field indicates the success or the The Registration Result Status field indicates the success or the
reason for failure of a registration request. reason for failure of a registration request.
Its values may be: Its values may be:
0 Successfully Registered 0 Successfully Registered
1 Error - Unknown 1 Error - Unknown
2 Error - Invalid DPC 2 Error - Invalid DPC
3 Error - Invalid Network Appearance 3 Error - Invalid Network Appearance
4 Error - Invalid Routing Key 4 Error - Invalid Routing Key
5 Error - Permission Denied 5 Error - Permission Denied
6 Error - Overlapping (Non-unique) Routing Key 6 Error - Cannot Support Unique Routing
7 Error - Routing Key not Provisioned 7 Error - Routing Key not Currently Provisioned
8 Error - Insufficient Resources 8 Error - Insufficient Resources
9 Error - Unsupported RK parameter Field
10 Error Unsupported/Invalid Traffic Handling Mode
Routing Context: 32-bit integer Routing Context: 32-bit integer
The Routing Context field contains the Routing Context value for the The Routing Context field contains the Routing Context value for the
associated Routing Key if the registration was successful. It is set associated Routing Key if the registration was successful. It is set
to "0" if the registration was not successful. to "0" if the registration was not successful.
3.5.7 De-Registration Request (DEREG REQ) 3.6.3 De-Registration Request (DEREG REQ)
The DEREG REQ message is sent by an ASP to indicate to a remote M3UA The DEREG REQ message is sent by an ASP to indicate to a remote M3UA
peer that it wishes to de-register a given Routing Key. Typically, an peer that it wishes to de-register a given Routing Key. Typically, an
ASP would send this message to an SGP, and expects to receive a DEREG ASP would send this message to an SGP, and expects to receive a DEREG
RSP in return with the associated Routing Context value. RSP message in return with the associated Routing Context value.
The DEREG REQ message contains the following parameters: The DEREG REQ message contains the following parameters:
Routing Context Mandatory Routing Context Mandatory
The format for the DEREG REQ message is as follows: The format for the DEREG REQ message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 6 | Length | | Tag = 0x06 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Context / / Routing Context /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Context: n X 32-bit integers Routing Context: n X 32-bit integers
The Routing Context parameter contains (a list of) integers indexing The Routing Context parameter contains (a list of) integers indexing
the Application Server traffic that the sending ASP is currently the Application Server traffic that the sending ASP is currently
registered to receive from the SG but now wishes to deregister. registered to receive from the SGP but now wishes to deregister.
3.5.8 De-Registration Response (DEREG RSP) 3.6.4 De-Registration Response (DEREG RSP)
The DEREG RSP message is used as a response to the DEREG REQ message The DEREG RSP message is used as a response to the DEREG REQ message
from a remote M3UA peer. from a remote M3UA peer.
The DEREG RSP message contains the following parameters: The DEREG RSP message contains the following parameters:
De-registration Results Mandatory De-registration Results Mandatory
The format for the DEREG RSP message is as follows: The format for the DEREG RSP message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 18 | Length = var | | Tag = 0x89 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| De-Registration Result 1 | | De-Registration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... / / ... /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| De-Registration Result n | | De-Registration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
De-Registration Results: De-Registration Results:
skipping to change at page 54, line 38 skipping to change at page 55, line 8
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context | | Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| De-Registration Status | | De-Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Context: 32-bit integer Routing Context: 32-bit integer
The Routing Context field contains the Routing Context value of the The Routing Context field contains the Routing Context value of the
matching Routing Key to deregister, as found in the DEREG Req. matching Routing Key to deregister, as found in the DEREG REQ
message.
De-Registration Status: 32-bit integer De-Registration Status: 32-bit integer
The De-Registration Result Status field indicates the success or the The De-Registration Result Status field indicates the success or the
reason for failure of the de-registration. reason for failure of the de-registration.
Its values may be: Its values may be:
0 Successfully De-registered 0 Successfully De-registered
1 Error - Unknown 1 Error - Unknown
2 Error - Invalid Routing Context 2 Error - Invalid Routing Context
3 Error - Permission Denied 3 Error - Permission Denied
4 Error - Not Registered 4 Error - Not Registered
5 Error ASP Currently Active for Routing Context
3.5.5 ASP Active (ASPAC) 3.7 ASP Traffic Maintenance (ASPTM) Messages
The ASPAC message is sent by an ASP to indicate to a remote M3UA peer 3.7.1 ASP Active
that it is Active and ready to process signalling traffic for a
particular Application Server. The ASPAC affects only the ASP state
for the routing keys identified by the Routing Contexts, if present.
The ASPAC message contains the following parameters: The ASP Active message is sent by an ASP to indicate to a remote M3UA
peer that it is ready to process signalling traffic for a particular
Application Server. The ASP Active message affects only the ASP state
for the Routing Keys identified by the Routing Contexts, if present.
The ASP Active message contains the following parameters:
Traffic Mode Type Mandatory Traffic Mode Type Mandatory
Routing Context Optional Routing Context Optional
INFO String Optional INFO String Optional
The format for the ASPAC message is as follows: The format for the ASP Active message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 11 | Length | | Tag = 0x0b | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 6 | Length | | Tag = 0x06 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Context* / / Routing Context /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 4 | Length | | Tag = 0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String* / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Traffic Mode Type: 32-bit (unsigned integer) Traffic Mode Type: 32-bit (unsigned integer)
The Traffic Mode Type parameter identifies the traffic mode of The Traffic Mode Type parameter identifies the traffic mode of
operation of the ASP within an AS. The valid values for Type are operation of the ASP within an AS. The valid values for Traffic Mode
shown in the following table. Type are shown in the following table:
1 Over-ride 1 Over-ride
2 Load-share 2 Load-share
3 Over-ride (Standby) 3 Over-ride (Standby)
4 Load-share (Standby) 4 Load-share (Standby)
Within a particular Routing Context, only one Traffic Mode Type
can be used. The Over-ride value indicates that the ASP is Within a particular Routing Context, Over-ride and Load-share,
operating in Over-ride mode, and the ASP takes over all either active or standby, MUST NOT be mixed. The Over-ride value
traffic in an Application Server (i.e., primary/back-up operation), indicates that the ASP is operating in Over-ride mode, and the ASP
over-riding any currently active ASPs in the AS. In Load-share takes over all traffic in an Application Server (i.e., primary/back-
mode, the ASP will share in the traffic distribution with any other up operation), over-riding any currently active ASPs in the AS. In
currently active ASPs. The Standby versions of the Over-ride and Load-share mode, the ASP will share in the traffic distribution with
Load-share Types indicate that the ASP is declaring itself ready to any other currently active ASPs. The Standby versions of the Over-
accept traffic but leaves it up to the sender as to when the traffic ride and Load-share Types indicate that the ASP is declaring itself
is started. Over-ride (Standby) indicates that the traffic sender ready to accept traffic but leaves it up to the sender as to when
continues to use the currently active ASP until it can no longer the traffic is started. Over-ride (Standby) indicates that the
send/receive traffic (i.e., the currently active ASP transitions to traffic sender continues to use the currently active ASP until it
Down or Inactive). At this point the sender MUST move the standby can no longer send/receive traffic (i.e., the currently active ASP
ASP to Active and commence traffic. Load-share (Standby) is similar transitions to state ASP-DOWN or ASP-ACTIVE). At this point the
- the sender continues to load-share to the current ASPs until it is sender MUST move the standby ASP to the ASP-ACTIVE state and
determined that there is insufficient resources in commence traffic. Load-share (Standby) is similar - the sender
the Load-share group. When there are insufficient ASPs, the sender continues to load-share to the current ASPs until it is determined
MUST move the ASP to Active. that there is insufficient resources in the Load-share group. When
there are insufficient ASPs, the sender MUST move the ASP to state
ASP-ACTIVE.
Routing Context: n X 32-bit integers Routing Context: n X 32-bit integers
The optional Routing Context parameter contains (a list of) integers The optional Routing Context parameter contains (a list of) integers
indexing the Application Server traffic that the sending ASP is indexing the Application Server traffic that the sending ASP is
configured/registered to receive. configured/registered to receive.
There is one-to-one relationship between an index entry and an SG There is one-to-one relationship between an index entry and an SGP
Routing Key or AS Name. Because an AS can only appear in one Routing Key or AS Name. Because an AS can only appear in one
Network Appearance, the Network Appearance parameter is not required Network Appearance, the Network Appearance parameter is not required
in the ASPAC message. in the ASP Active message.
An Application Server Process may be configured to process traffic An Application Server Process may be configured to process traffic
for more than one logical Application Server. From the perspective for more than one logical Application Server. From the perspective
of an ASP, a Routing Context defines a range of signalling traffic of an ASP, a Routing Context defines a range of signalling traffic
that the ASP is currently configured to receive from the SG. For that the ASP is currently configured to receive from the SGP. For
example, an ASP could be configured to support call processing for example, an ASP could be configured to support call processing for
multiple ranges of PSTN trunks and therefore receive related multiple ranges of PSTN trunks and therefore receive related
signalling traffic, identified by separate SS7 DPC/OPC/CIC_ranges. signalling traffic, identified by separate SS7 DPC/OPC/CIC ranges.
The format and description of the optional Info String parameter is the The format and description of the optional INFO String parameter is the
same as for the DUNA message (See Section 3.4.1.) same as for the DUNA message (See Section 3.4.1).
3.5.6 ASP Active Ack 3.7.2 ASP Active Acknowledgement (ASP Active Ack)
The ASPAC Ack message is used to acknowledge an ASP-Active message The ASP Active Ack message is used to acknowledge an ASP Active message
received from a remote M3UA peer. In the case where an ASPAC (Over- received from a remote M3UA peer. In the case where an ASP Active
ride (standby)) or ASPAC (load-share (standby) is received, a second (Over-ride (standby)) or ASP Active (Load-share (standby)) message is
ASPACK Ack is sent when the ASP is moved to the "Active" state from received, a second ASP Active Ack message is sent when the ASP is moved
"Active (Standby)". from the ASP-STANDBY to the ASP-ACTIVE state.
The ASPAC Ack message contains the following parameters: The ASP Active Ack message contains the following parameters:
Traffic Mode Type Mandatory Traffic Mode Type Mandatory
Routing Context Optional Routing Context Optional
INFO String Optional INFO String Optional
The format for the ASPAC Ack message is as follows: The format for the ASP Active Ack message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 11 | Length | | Tag = 0x0b | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 6 | Length | | Tag = 0x06 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Context* / / Routing Context /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 4 | Length | | Tag = 0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String* / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the The format and description of the optional INFO String parameter is the
same as for the DUNA message (See Section 3.3.2.1.) same as for the DUNA message (See Section 3.4.1).
The INFO String in an ASP Active Ack message is independent from the
INFO String in the ASP Active message (i.e., it does not have to echo
back the INFO String received).
The format of the Traffic Mode Type and Routing Context parameters is The format of the Traffic Mode Type and Routing Context parameters is
the same as for the ASP-Active message. (See Section 3.4.5). the same as for the ASP Active message. (See Section 3.5.5).
3.5.7 ASP Inactive (ASPIA) 3.7.3 ASP Inactive
The ASPIA message is sent by an ASP to indicate to a remote M3UA peer The ASP Inactive message is sent by an ASP to indicate to a remote M3UA
peer
that it is no longer an active ASP to be used from within a list of that it is no longer an active ASP to be used from within a list of
ASPs. The ASPIA affects only the ASP state in the Routing Keys ASPs. The ASP Inactive message affects only the ASP state in the
identified by the Routing Contexts, if present. Routing Keys identified by the Routing Contexts, if present.
The ASPIA message contains the following parameters: The ASP Inactive message contains the following parameters:
Routing Context Optional Routing Context Optional
INFO String Optional INFO String Optional
The format for the ASPIA message parameters is as follows: The format for the ASP Inactive message parameters is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 6 | Length | | Tag = 0x06 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Context* / / Routing Context /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 4 | Length | | Tag = 0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String* / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Routing Context and Info The format and description of the optional Routing Context and INFO
String parameters is the same as for the ASPAC message (See Section String parameters is the same as for the ASP Active message (See
3.5.5.) Section 3.5.5.)
3.5.8 ASP Inactive Ack 3.7.4 ASP Inactive Acknowledgement (ASP Inactive Ack)
The ASPIA Ack message is used to acknowledge an ASP-Inactive message The ASP Inactive Ack message is used to acknowledge an ASP Inactive
message
received from a remote M3UA peer. received from a remote M3UA peer.
The ASPIA Ack message contains the following parameters: The ASP Inactive Ack message contains the following parameters:
Routing Context Optional Routing Context Optional
INFO String Optional INFO String Optional
The format for the ASPIA Ack message is as follows: The format for the ASP Inactive Ack message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 6 | Length | | Tag = 0x06 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Context* / / Routing Context* /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 4 | Length | | Tag = 0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String* / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the The format and description of the optional INFO String parameter is the
same as for the DUNA message (See Section 3.4.1.) same as for the DUNA message (See Section 3.4.1.)
The format of the Routing Context parameter is the same as for the ASP- The INFO String in an ASP Inactive Ack message is independent from the
Inactive message. (See Section 3.5.7). INFO String in the ASP Inactive message (i.e., it does not have to echo
back the INFO String received).
3.5.9 Heartbeat (BEAT)
The Heartbeat message is optionally used to ensure that the M3UA peers
are still available to each other. It is recommended for use when the
M3UA runs over a transport layer other than the SCTP, which has its own
heartbeat.
The BEAT message contains the following parameters:
Heatbeat Data Optional
The format for the BEAT message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 8 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Data * /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Heartbeat Data parameter contents are defined by the sending node.
The Heartbeat Data could include, for example, a Heartbeat Sequence
Number and/or Timestamp. The receiver of a Heartbeat message does not
process this field as it is only of significance to the sender. The
receiver MUST respond with a BEAT-Ack message.
3.5.10 Heartbeat Ack (Beat-Ack)
The Heartbeat Ack message is sent in response to a received Heartbeat The format of the Routing Context parameter is the same as for the ASP
message. It includes all the parameters of the received Heartbeat Inactive message. (See Section 3.5.7).
message, without any change.
3.6 Management Messages 3.8 Management (MGMT) Messages
3.6.1 Error (ERR) 3.8.1 Error
The Error message is used to notify a peer of an error event associated The Error message is used to notify a peer of an error event associated
with an incoming message. For example, the message type might be with an incoming message. For example, the message type might be
unexpected given the current state, or a parameter value might be unexpected given the current state, or a parameter value might be
invalid. invalid.
The ERR message contains the following parameters: The Error message contains the following parameters:
Error Code Mandatory Error Code Mandatory
Diagnostic Information Optional Diagnostic Information Optional
The format for the ERR message is as follows: The format for the Error message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 12 | Length | | Tag = 0x0c | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 7 | Length | | Tag = 0x07 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Diagnostic Information* / / Diagnostic Information /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Code: 32-bits (unsigned integer) Error Code: 32-bits (unsigned integer)
The Error Code parameter indicates the reason for the Error Message. The Error Code parameter indicates the reason for the Error Message.
The Error parameter value can be one of the following values: The Error parameter value can be one of the following values:
1 Invalid Version 1 Invalid Version
2 Invalid Network Appearance 2 Invalid Network Appearance
3 Unsupported Message Class 3 Unsupported Message Class
4 Unsupported Message Type 4 Unsupported Message Type
5 Unsupported/Invalid Traffic Handling Mode 5 Unsupported/Invalid Traffic Handling Mode
6 Unexpected Message 6 Unexpected Message
7 Protocol Error 7 Protocol Error
8 Invalid Routing Context 8 Invalid Routing Context
9 Invalid Stream Identifier 9 Invalid Stream Identifier
10 Invalid Parameter Value 10 Invalid Parameter Value
11 Refused - Management Blocking
12 Unknown Routing Context
The "Invalid Version" error is sent if a message was received with an The "Invalid Version" error is sent if a message was received with an
invalid or unsupported version. The Error message contains the invalid or unsupported version. The Error message contains the
supported version in the Common header. The Error message could supported version in the Common header. The Error message could
optionally provide the supported version in the Diagnostic Information optionally provide the supported version in the Diagnostic Information
area. area.
The "Invalid Network Appearance" error is sent by a SG if an ASP sends The "Invalid Network Appearance" error is sent by a SGP if an ASP sends
a message with an invalid (unconfigured) Network Appearance value. a message with an invalid (unconfigured) Network Appearance value.
The "Unsupported Message Class" error is sent if a message with an The "Unsupported Message Class" error is sent if a message with an
unexpected or unsupported Message Class is received. unexpected or unsupported Message Class is received.
The "Unsupported Message Type" error is sent if a message with an The "Unsupported Message Type" error is sent if a message with an
unexpected or unsupported Message Type is received. unexpected or unsupported Message Type is received.
The "Unsupported/Invalid Traffic Handling Mode" error is sent by a SG The "Unsupported/Invalid Traffic Handling Mode" error is sent by a SGP
if an ASP sends an ASP Active with an unsupported Traffic Handling Mode if an ASP sends an ASP Active message with an unsupported Traffic Mode
or a Traffic Handling mode that is inconsistent with the presently Type or a Traffic Mode Type that is inconsistent with the presently
configured mode for the Application Server. An example would be a case configured mode for the Application Server. An example would be a case
in which the SG did not support load-sharing. in which the SGP did not support load-sharing.
The "Unexpected Message" error MAY be sent if a defined and recognized The "Unexpected Message" error MAY be sent if a defined and recognized
message is received that is not expected in the current state( in some message is received that is not expected in the current state( in some
cases the ASP may optionally silently discard the message and not send cases the ASP may optionally silently discard the message and not send
an Error). For example, silent discard is used by an ASP if it an Error message). For example, silent discard is used by an ASP if it
received a Transfer message from an SG while it was in the Inactive received a DATA message from an SGP while it was in the ASP-INACTIVE
state. state.
The "Protocol Error" error is sent for any protocol anomaly(i.e., The "Protocol Error" error is sent for any protocol anomaly(i.e.,
reception of a parameter that is syntactically correct but unexpected reception of a parameter that is syntactically correct but unexpected
in the current situation. in the current situation.
The "Invalid Routing Context" error is sent by an SG if an Asp sends a The "Invalid Routing Context" error is sent if a message is received
message with an invalid (unconfigured) Routing Context value. from a peer with an invalid (unconfigured) Routing Context value.
The "Invalid Stream Identifier" error is sent if a message was received The "Invalid Stream Identifier" error is sent if a message is received
on an unexpected SCTP stream (e.g., a MGMT message was received on a on an unexpected SCTP stream (e.g., a Management message was received
stream other than "0"). on a stream other than "0").
The " Invalid Parameter Value " error is sent if a message was received The " Invalid Parameter Value " error is sent if a message is received
with an invalid parameter value (e.g., a DUPU message was received with with an invalid parameter value (e.g., a DUPU message was received with
a Mask value other than "0"). a Mask value other than "0").
The "Refused - Management Blocking" error is sent when an ASP-Up or
ASP-Active message is received and the request is refused for
management reasons (e.g., management lock-out").
The "Unknown Routing Context" Error is sent if a message is received
from a peer without a Routing Context parameter and it is not known by
configuration data which Application Servers are referenced.
Diagnostic Information: variable length Diagnostic Information: variable length
When included, the optional Diagnostic information can be any When included, the optional Diagnostic information can be any
information germane to the error condition, to assist in information germane to the error condition, to assist in
identification of the error condition. In the case of an Invalid identification of the error condition. In the case of an Invalid
Network Appearance, Traffic Handling Mode, Routing Context or Network Appearance, Traffic Handling Mode, Routing Context or
Parameter Value, the Diagnostic information includes the received Parameter Value, the Diagnostic information parameter MUST be added
parameter. In the other cases, the Diagnostic information may be and include the offending parameter. In the other cases, the
the first 40 bytes of the offending message. Diagnostic information MAY be the first 40 bytes of the offending
message.
Error messages are not generated in response to other Error messages. Error messages MUST NOT be generated in response to other Error
messages.
3.6.2 Notify (NTFY) 3.8.2 Notify
The Notify message used to provide an autonomous indication of M3UA The Notify message used to provide an autonomous indication of M3UA
events to an M3UA peer. events to an M3UA peer.
The NTFY message contains the following parameters: The Notify message contains the following parameters:
Status Type/ID Mandatory Status Mandatory
Routing Context Optional Routing Context Optional
INFO String Optional INFO String Optional
The format for the NTFY message is as follows: The format for the Notify message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 13 | Length | | Tag = 0x0d | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification | | Status Type | Status Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 6 | Length | | Tag = 0x06 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Context* / / Routing Context /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 4 | Length | | Tag = 0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String* / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status Type: 16-bits (unsigned integer) Status Type: 16-bits (unsigned integer)
The Status Type parameter identifies the type of the Notify message. The Status Type parameter identifies the type of the Notify message.
The following are the valid Status Type values: The following are the valid Status Type values:
1 Application Server State Change (AS-StateChange) 1 Application Server State Change (AS-State_Change)
2 Other 2 Other
Status Information: 16-bits (unsigned integer) Status Information: 16-bits (unsigned integer)
The Status Information parameter contains more detailed information The Status Information parameter contains more detailed information
for the notification, based on the value of the Status Type. for the notification, based on the value of the Status Type.
If the Status Type is AS_State_Change the following Status If the Status Type is AS-State_Change the following Status
Information values are used: Information values are used:
1 reserved 1 reserved
2 Application Server Inactive (AS-Inactive) 2 Application Server Inactive (AS-INACTIVE)
3 Application Server Active (AS-Active) 3 Application Server Active (AS-ACTIVE)
4 Application Server Pending (AS-Pending) 4 Application Server Pending (AS-PENDING)
These notifications are sent from an SG to an ASP upon a change in These notifications are sent from an SGP to an ASP upon a change in
status of a particular Application Server. The value reflects the status of a particular Application Server. The value reflects the
new state of the Application Server. new state of the Application Server.
If the Status Type is Other, then the following Status Information If the Status Type is Other, then the following Status Information
values are defined: values are defined:
1 Insufficient ASP resources active in AS 1 Insufficient ASP Resources Active in AS
2 Alternate ASP Active 2 Alternate ASP Active
These notifications are not based on the SG reporting the state change These notifications are not based on the SGP reporting the state change
of an ASP or AS. In the Insufficent ASP Resources case, the SG is of an ASP or AS. In the Insufficent ASP Resources case, the SGP is
indicating to an "Inactive" ASP(s) in the AS that another ASP is indicating to an ASP_INACTIVE ASP in the AS that another ASP is
required in order to handle the load of the AS (Load-sharing mode). required in order to handle the load of the AS (Load-sharing mode).
For the Alternate ASP Active case, an ASP is informed when an alternate For the Alternate ASP Active case, an ASP is informed when an alternate
ASP transitions to the ASP-Active state in Over-ride mode. ASP transitions to the ASP-ACTIVE state in Over-ride mode.
The format and description of the optional Routing Context and Info The format and description of the optional Routing Context and Info
String parameters is the same as for the ASPAC message (See Section String parameters is the same as for the ASP Active message (See
3.4.6.) Section
3.5.5.)
4.0 Procedures 4. Procedures
The M3UA layer needs to respond to various local primitives it receives The M3UA layer needs to respond to various local primitives it receives
from other layers as well as the messages that it receives from the from other layers as well as the messages that it receives from the
peer M3UA layer. This section describes the M3UA procedures in peer M3UA layer. This section describes the M3UA procedures in
response to these events. response to these events.
4.1 Procedures to support the services of the M3UA layer 4.1 Procedures to Support the M3UA-User and Layer Management Layers
4.1.1 Receipt of primitives from the M3UA-User 4.1.1 Receipt of Primitives from the M3UA-User
On receiving an MTP-Transfer request primitive from an upper layer, or On receiving an MTP-TRANSFER request primitive from an upper layer at
the nodal inter-working function at an SG, the M3UA layer sends a an ASP/IPSP, or the nodal inter-working function at an SGP, the M3UA
corresponding DATA message (see Section 3) to its M3UA peer. The M3UA layer sends a corresponding DATA message (see Section 3) to its M3UA
peer receiving the Data message sends an MTP-Transfer indication peer. The M3UA peer receiving the DATA message sends an MTP-TRANSFER
primitive to the upper layer. indication primitive to the upper layer.
The M3UA message distribution function (see Section 1.4.2.1) determines The M3UA message distribution function (see Section 1.4.2.1) determines
the Application Server (AS) based on comparing the information in the the Application Server (AS) based on comparing the information in the
MTP-Transfer request primitive with a provisioned Routing Key. MTP-TRANSFER request primitive with a provisioned Routing Key.
>From the list of ASPs within the AS table, an Active ASP is selected >From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE
and a DATA message is constructed and issued on the corresponding SCTP state is selected and a DATA message is constructed and issued on the
Association. If more than one ASP is active (i.e., traffic is to be corresponding SCTP association. If more than one ASP is in the ASP-
load-shared across all the active ASPs), one of the active ASPs from ACTIVE state (i.e., traffic is to be load-shared across more than one
the list is selected. The selection algorithm is implementation ASP), one of the ASPs in the ASP_ACTIVE state is selected from the
dependent but could, for example, be round-robin or based on, for list. The selection algorithm is implementation dependent but could,
example, the SLS or ISUP CIC. The appropriate selection algorithm must for example, be round-robin or based on, for example, the SLS or ISUP
be chosen carefully as it is dependent on application assumptions and CIC. The appropriate selection algorithm must be chosen carefully as
understanding of the degree of state coordination between the active it is dependent on application assumptions and understanding of the
ASPs in the AS. degree of state coordination between the ASP_ACTIVE ASPs in the AS.
In addition, the message needs to be sent on the appropriate SCTP In addition, the message needs to be sent on the appropriate SCTP
stream, again taking care to meet the message sequencing needs of the stream, again taking care to meet the message sequencing needs of the
signalling application. signalling application.
When there is no Routing Key match, or only a partial match, for an When there is no Routing Key match, or only a partial match, for an
incoming SS7 message, a default treatment must be specified. Possible incoming SS7 message, a default treatment MUST be specified. Possible
solutions are to provide a default Application Server at the SG that solutions are to provide a default Application Server at the SGP that
directs all unallocated traffic to a (set of) default ASP(s), or to directs all unallocated traffic to a (set of) default ASP(s), or to
drop the message and provide a notification to management in an M-Error drop the message and provide a notification to Layer Management in an
indication primitive. The treatment of unallocated traffic is M-ERROR indication primitive. The treatment of unallocated traffic is
implementation dependent. implementation dependent.
4.1.2 Receipt of primitives from the Layer Management 4.1.2 Receipt of Primitives from the Layer Management
On receiving primitives from the local Layer Management, the M3UA layer On receiving primitives from the local Layer Management, the M3UA layer
will take the requested action and provide an appropriate response will take the requested action and provide an appropriate response
primitive to Layer Management. primitive to Layer Management.
An M-SCTP ESTABLISH request from Layer Management at an ASP or IPSP An M-SCTP_ESTABLISH request primitive from Layer Management at an ASP
will initiate the establishment of an SCTP association. The M3UA layer or IPSP will initiate the establishment of an SCTP association. The
will attempt to establish an SCTP association with the remote M3UA peer M3UA layer will attempt to establish an SCTP association with the
at by sending an SCTP-Associate primitive to the local SCTP layer. remote M3UA peer by sending an SCTP-ASSOCIATE primitive to the local
SCTP layer.
When an SCTP association has been successfully established, the SCTP When an SCTP association has been successfully established, the SCTP
will send an SCTP-Communication Up notification to the local M3UA will send an SCTP-COMMUNICATION_UP notification primitive to the local
layer. At the SG or IPSP that initiated the request, the M3UA will M3UA layer. At the SGP or IPSP that initiated the request, the M3UA
send an M-SCTP ESTABLISH confirm to Layer Management when the layer will send an M-SCTP_ESTABLISH confirm primitive to Layer
association set-up is complete. At the peer M3UA layer, an M-SCTP Management when the association set-up is complete. At the peer M3UA
ESTABLISH indication is sent to Layer Management upon successful layer, an M-SCTP_ESTABLISH indication primitive is sent to Layer
completion of an incoming SCTP association set-up. Management upon successful completion of an incoming SCTP association
set-up.
An M-SCTP RELEASE request from Layer Management initates the tear-down An M-SCTP_RELEASE request primitive from Layer Management initates the
of an SCTP association. M3UA accomplishes a graceful shutdown of the tear-down of an SCTP association. The M3UA layer accomplishes a
SCTP association by sending a SHUTDOWN primitive to the SCTP layer. graceful shutdown of the SCTP association by sending an SCTP-SHUTDOWN
primitive to the SCTP layer.
When the graceful shutdown of the SCTP association has been When the graceful shutdown of the SCTP association has been
accomplished, the SCTP layer returns a SHUTDOWN COMPLETE notification accomplished, the SCTP layer returns an SCTP-SHUTDOWN_COMPLETE
notification primitive to the local M3UA layer. At the M3UA Layer that
initiated the request, the M3UA layer will send an M-SCTP_RELEASE
confirm primitive to Layer Management when the association teardown is
complete. At the peer M3UA Layer, an M-SCTP_RELEASE indication
primitive is sent to Layer Management upon successful tear-down of an
SCTP association.
to the local M3UA Layer. At the M3UA Layer that initiated the request, An M-SCTP_STATUS request primitive supports a Layer Management query of
the M3UA will send an M-SCTP RELEASE confirm to Layer Management when the local status of a particular SCTP association. The M3UA layer
the association teardown is complete. At the peer M3UA Layer, an M- simply maps the M-SCTP_STATUS request primitive to an SCTP-STATUS
SCTP RELEASE indication is sent to Layer Management upon successful
tear-down of an SCTP association.
An M-SCTP STATUS request supports a Layer Management query of the local primitive to the SCTP layer. When the SCTP responds, the M3UA layer
status of a particular SCTP association. The M3UA simply maps the M- maps the association status information to an M-SCTP_STATUS confirm
SCTP STATUS request to a STATUS primitive to the SCTP. When the SCTP primitive. No peer protocol is invoked.
responds, the M3UA maps the association status information to an M-SCTP
STATUS confirm. No peer protocol is invoked.
Similar LM-to-M3UA-to-SCTP and/or SCTP-to-M3UA-LM mappings can be Similar LM-to-M3UA-to-SCTP and/or SCTP-to-M3UA-to-LM primitive mappings
described for the various other SCTP Upper layer primitives in RFC2960 can be described for the various other SCTP Upper Layer primitives in
such as Initialize, Set Primary, Change Heartbeat, Request Heartbeat, RFC2960 [13] such as INITIALIZE, SET PRIMARY, CHANGE HEARTBEAT,
Get SRTT Report, Set Failure Threshold, Set Protocol parameters, REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, SET PROTOCOL
Destroy SCTP Instance, Send Failure, and Network Status Change. PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, AND NETWORK STATUS
Alternatively, these SCTP Upper Layer primitives (and Status as well) CHANGE. Alternatively, these SCTP Upper Layer primitives (and Status
can be considered for modeling purposes as a Layer Management as well) can be considered for modeling purposes as a Layer Management
interaction directly with the SCTP Layer. interaction directly with the SCTP Layer.
M-NOTIFY indication and M-ERROR indication primitives indicate to Layer M-NOTIFY indication and M-ERROR indication primitives indicate to Layer
Management the notification or error information contained in a Management the notification or error information contained in a
received M3UA Notify or Error message respectively. These indications received M3UA Notify or Error message respectively. These indications
can also be generated based on local M3UA events. can also be generated based on local M3UA events.
An M-ASP STATUS request supports a Layer Management query of the status An M-ASP_STATUS request primitive supports a Layer Management query of
of a particular local or remote ASP. The M3UA responds with the status the status of a particular local or remote ASP. The M3UA layer
in an M-ASP STATUS confirm. No M3UA peer protocol is invoked. responds with the status in an M-ASP_STATUS confirm primitive. No M3UA
peer protocol is invoked.
An M-AS STATUS request supports a Layer Management query of the status An M-AS_STATUS request supports a Layer Management query of the status
of a particular AS. The M3UA responds with an M-AS STATUS confirm. No of a particular AS. The M3UA responds with an M-AS_STATUS confirm
M3UA peer protocol is invoked. primitive. No M3UA peer protocol is invoked.
M-ASP-UP request, M-ASP-DOWN request, M-ASP-ACTIVE request and M-ASP- M-ASP_UP request, M-ASP_DOWN request, M-ASP_ACTIVE request and M-ASP_
INACTIVE request primitives allow Layer Management at an ASP to INACTIVE request primitives allow Layer Management at an ASP to
initiate state changes. Upon successful completion, a corresponding initiate state changes. Upon successful completion, a corresponding
confirm is provided by the M3UA to Layer Management. If an invocation confirm primitive is provided by the M3UA layer to Layer Management.
is unsuccessful, an Error indication is provided. If an invocation is unsuccessful, an Error indication primitive is
provided in the primitive.
These requests result in outgoing M3UA ASP-UP, ASP-DOWN, ASP-ACTIVE and
ASP-INACTIVE messages to the remote M3UA peer at an SG or IPSP.
4.2 Receipt of M3UA Peer Management messages These requests result in outgoing ASP Up, ASP Down, ASP Active and
ASP Inactive messages to the remote M3UA peer at an SGP or IPSP.
Upon successful state changes resulting from reception of M3UA ASP-UP, 4.1.3 Receipt of M3UA Peer Management Messages
ASP-DOWN, ASP-ACTIVE and ASP-INACTIVE messages from a peer M3UA, the
M3UA layer MUST invoke corresponding M-ASP UP, M-ASP DOWN, M-ASP ACTIVE Upon successful state changes resulting from reception of ASP Up,
and M-ASP INACTIVE, M-AS ACTIVE, M-AS INACTIVE, and M-AS DOWN ASP Down, ASP Active and ASP Inactive messages from a peer M3UA, the
indications to the local Layer Management. M3UA layer SHOULD invoke corresponding M-ASP_UP, M-ASP_DOWN, M-
ASP_ACTIVE and M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M-
AS_DOWN indication primitives to the local Layer Management.
M-NOTIFY indication and M-ERROR indication indicate to Layer Management M-NOTIFY indication and M-ERROR indication primitives indicate to Layer
the notification or error information contained in a received M3UA Management the notification or error information contained in a
Notify or Error message. These indications can also be generated based received M3UA Notify or Error message. These indications can also be
on local M3UA events. generated based on local M3UA events.
4.3 Procedures to support the M3UA Management services 4.2 Procedures to Support the Management of SCTP Associations with M3UA
Peers
These procedures support the M3UA management of SCTP Associations These procedures support the M3UA management of SCTP Associations
between SGs and ASPs. between SGPs and ASPs or between IPSPs.
4.3.1 AS and ASP State Maintenance 4.2.1 AS and ASP State Maintenance
The M3UA layer on the SG maintains the state of each remote ASP, in The M3UA layer on the SGP maintains the state of each remote ASP, in
each Application Server that the ASP is configured to receive traffic, each Application Server that the ASP is configured to receive traffic,
as input to the M3UA message distribution function. Similarly, where as input to the M3UA message distribution function. Similarly, where
IPSPs use M3UA in a point-to-point fashion, the M3UA layer in an IPSP IPSPs use M3UA in a point-to-point fashion, the M3UA layer in an IPSP
maintains the state of remote IPSPs. For the purposes of the following maintains the state of remote IPSPs. For the purposes of the following
procedures, only the SG/ASP case is described but the SG side of the procedures, only the SGP/ASP case is described but the SGP side of the
procedures also apply to an IPSP sending traffic to an AS consisting of procedures also apply to an IPSP sending traffic to an AS consisting of
a set of remote IPSPs. a set of remote IPSPs.
4.3.1.1 ASP States 4.2.1.1 ASP States
The state of each remote ASP, in each AS that it is configured to The state of each remote ASP, in each AS that it is configured to
operate, is maintained in the M3UA layer in the SG. The state of a operate, is maintained in the M3UA layer in the SGP. The state of a
particular ASP in a particular AS changes due to events. The events particular ASP in a particular AS changes due to events. The events
include: include:
* Reception of messages from the peer M3UA layer at the ASP; * Reception of messages from the peer M3UA layer at the ASP;
* Reception of some messages from the peer M3UA layer at other ASPs * Reception of some messages from the peer M3UA layer at other ASPs
in the AS (e.g., ASPAC Take-over); in the AS (e.g., ASP Active message indicating "Over-ride");
* Reception of indications from the SCTP layer; or * Reception of indications from the SCTP layer; or
* Local Management intervention. * Local Management intervention.
The ASP state transition diagram is shown in Figure 4. The possible The ASP state transition diagram is shown in Figure 4. The possible
states of an ASP are: states of an ASP are:
ASP-DOWN: The remote M3UA peer at the ASP is unavailable and/or the ASP-DOWN: The remote M3UA peer at the ASP is unavailable and/or the
related SCTP association is down. Initially all ASPs will be in this related SCTP association is down. Initially all ASPs will be in this
state. An ASP in this state should not be sent any M3UA messages. state. An ASP in this state SHOULD NOT be sent any M3UA messages.
ASP-INACTIVE: The remote M3UA peer at the ASP is available (and the ASP-INACTIVE: The remote M3UA peer at the ASP is available (and the
related SCTP association is up) but application traffic is stopped. In related SCTP association is up) but application traffic is stopped. In
this state the ASP can be sent any non-Data M3UA messages. this state the ASP MAY be sent any non-DATA M3UA messages.
ASP-ACTIVE: The remote M3UA peer at the ASP is available and ASP-ACTIVE: The remote M3UA peer at the ASP is available and
application traffic is active (for a particular Routing Context or set application traffic is active (for a particular Routing Context or set
of Routing Contexts). of Routing Contexts).
ASP-STANDBY: The remote M3UA peer at the ASP is available and ready to ASP-STANDBY: The remote M3UA peer at the ASP is available and ready to
receive application traffic at any time (for a particular Routing receive application traffic at any time (for a particular Routing
Context or set of Routing Contexts). In this state the ASP can be sent Context or set of Routing Contexts). In this state the ASP MAY be sent
any non-Data M3UA messages. any non-Data M3UA messages.
Figure 4: ASP State Transition Diagram Figure 4: ASP State Transition Diagram
+--------------+ +--------------+
| ASP-ACTIVE | | ASP-ACTIVE |
+----------------------| or | +----------------------| or |
| Alternate +-------| ASP-STANDBY* | | Other +-------| ASP-STANDBY* |
| ASP | +--------------+ | ASP in AS | +--------------+
| Takeover | ^ | | Overrides | ^ |
| | ASP | | ASP | | ASP | | ASP
| | Active | | Inact | | Active | | Inactive
| | | v | | | v
| | +--------------+ | | +--------------+
| | | | | | | |
| +------>| ASP-INACTIVE | | +------>| ASP-INACTIVE |
| +--------------+ | +--------------+
| ^ | | ^ |
ASP Down/ | ASP | | ASP Down / ASP Down/ | ASP | | ASP Down /
SCTP CDI | Up | | SCTP CDI SCTP CDI | Up | | SCTP CDI
| | v | | v
| +--------------+ | +--------------+
| | | | | |
+--------------------->| ASP-DOWN | +--------------------->| ASP-DOWN |
| | | |
+--------------+ +--------------+
*Note: ASP-ACTIVE and ASP-STANDBY differ only in whether the ASP is *Note: ASP-ACTIVE and ASP-STANDBY differ only in whether the ASP is
currently receiving Data traffic within the AS. currently receiving Data traffic within the AS.
SCTP CDI: The local SCTP layer's Communication Down Indication to the SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication
Upper Layer Protocol (M3UA) on an SG. The local SCTP will send this Down Indication to the Upper Layer Protocol (M3UA) on an SGP. The local
indication when it detects the loss of connectivity to the ASP's peer SCTP layer will send this indication when it detects the loss of
SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE connectivity to the ASP's peer SCTP layer. SCTP CDI is understood as
notification or COMMUNICATION LOST notification from the SCTP. either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST
notification from the SCTP layer.
4.3.1.2 AS States
The state of the AS is maintained in the M3UA layer on the SG. 4.2.1.2 AS States
The state of an AS changes due to events. These events include: The state of the AS is maintained in the M3UA layer on the SGP. The
state of an AS changes due to events. These events include:
* ASP state transitions * ASP state transitions
* Recovery timer triggers * Recovery timer triggers
The possible states of an AS are: The possible states of an AS are:
AS-DOWN: The Application Server is unavailable. This state implies AS-DOWN: The Application Server is unavailable. This state implies
that all related ASPs are in the ASP-DOWN state for this AS. Initially that all related ASPs are in the ASP-DOWN state for this AS. Initially
the AS will be in this state. the AS will be in this state. An Application Server MUST be in the AS-
DOWN state before it can be removed from a configuration.
AS-INACTIVE: The Application Server is available but no application AS-INACTIVE: The Application Server is available but no application
traffic is active (i.e., one or more related ASPs are in the ASP- traffic is active (i.e., one or more related ASPs are in the ASP-
Inactive state, but none in the ASP-Active state). The recovery timer INACTIVE state, but none in the ASP-ACTIVE or ASP-STANDBY states). The
recovery timer
T(r) is not running or has expired. T(r) is not running or has expired.
AS-ACTIVE: The Application Server is available and application traffic AS-ACTIVE: The Application Server is available and application traffic
is active. This state implies that at least one ASP is in the ASP- is active. This state implies that at least one ASP is in the ASP-
ACTIVE state. ACTIVE state.
AS-PENDING: An active ASP has transitioned to inactive and it was the AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP-DOWN
last remaining active ASP in the AS (and no STANDBY ASPs are available. and it was the last remaining active ASP in the AS (and no ASPs in the
A recovery timer T(r) will be started and all incoming SCN messages ASP-STANDBY state are available. A recovery timer T(r) SHOULD be
will be queued by the SG. If an ASP becomes active before T(r) expires, started and all incoming signalling messages SHOULD be queued by the
the AS will move to AS-ACTIVE state and all the queued messages will be SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, the AS is moved
sent to the active ASP. to the AS-ACTIVE state and all the queued messages will be
sent to the ASP.
If T(r) expires before an ASP becomes active, the SG stops queuing If T(r) expires before an ASP becomes ASP-ACTIVE, the SGP stops queuing
messages and discards all previously queued messages. The AS will move messages and discards all previously queued messages. The AS will move
to AS-INACTIVE if at least one ASP is in ASP-INACTIVE state, otherwise to the AS-INACTIVE state if at least one ASP is in ASP-INACTIVE state,
it will move to AS-DOWN state. otherwise it will move to AS-DOWN state.
Figure 5 shows an example AS state machine for the case where the
AS/ASP data is pre-configured. For other cases where the AS/ASP
configuration data is created dynamically, there would be differences
in the state machine, especially at creation of the AS.
For example, where the AS/ASP configuration data is not created until
Registration of the first ASP, the AS-INACTIVE state is entered
directly upon the first successful REG REQ from an ASP. Another
example is where the AS/ASP configuration data is not created until the
first ASP successfully enters the ASP-ACTIVE state. In this case the
AS-ACTIVE state is entered directly.
Figure 5: AS State Transition Diagram Figure 5: AS State Transition Diagram
+----------+ one ASP trans to ACTIVE +-------------+ +----------+ one ASP trans to ACTIVE +-------------+
| |---------------------------->| | | AS- |---------------------------->| AS- |
| AS-INACT | | AS-ACTIVE | | INACTIVE | | ACTIVE |
| |<--- | | | |<--- | |
+----------+ \ +-------------+ +----------+ \ +-------------+
^ | \ Tr Expiry, ^ | ^ | \ Tr Expiry, ^ |
| | \ at least one | | | | \ at least one | |
| | \ ASP in INACT | | | | \ ASP in ASP-INACTIVE | |
| | \ | |
| | \ | | | | \ | |
| | \ | | | | \ | |
one ASP | | all ASP \ one ASP | | Last ACT ASP
trans | | trans to \ trans to | | trans to
INACT
to INACT| | DOWN -------\ ACTIVE | | or DOWN
| | \ | |
| | \ | | | | \ | |
one ASP | | all ASP \ one ASP | | Last ACTIVE
trans | | trans to \ trans to | | ASP trans to
to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE
ASP- | | \ ACTIVE | | or ASP-DOWN
INACTIVE| | \ | |
| | \ | | | | \ | |
| | \ | | | | \ | |
| v \ | v | v \ | v
+----------+ \ +-------------+ +----------+ \ +-------------+
| | --| | | | --| |
| AS-DOWN | | AS-PENDING | | AS-DOWN | | AS-PENDING |
| | | (queueing) | | | | (queueing) |
| |<----------------------------| | | |<----------------------------| |
+----------+ Tr Expiry no ASP +-------------+ +----------+ Tr Expiry (no ASP +-------------+
in INACT state in ASP-INACTIVE state)
Tr = Recovery Timer Tr = Recovery Timer
4.3.2 M3UA Management procedures for primitives 4.2.2 M3UA Management Procedures for Primitives
Before the establishment of an SCTP association the ASP state at both Before the establishment of an SCTP association the ASP state at both
the SG and ASP is assumed to be "Down". the SGP and ASP is assumed to be in the state ASP-DOWN.
Once the SCTP association is established (See Section 4.1.2) and Once the SCTP association is established (see Section 4.1.2) and
assuming that the local M3UA-User is ready, the local ASP M3UA assuming that the local M3UA-User is ready, the local M3UA ASP
Application Server Process Maintenance (ASPM) function will initiate Maintenance (ASPM) function will initiate the relevant procedures,
the ASPM procedures, using the ASP-Up/-Down/-Active/-Inactive messages using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey
to convey the ASP-state to the SG - see Section 4.3.3. the ASP state to the SGP (see Section 4.3.3).
If the M3UA layer subsequently receives an SCTP-Communication Down If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN
indication from the underlying SCTP layer, it will inform the Layer or SCTP-RESTART indication primitive from the underlying SCTP layer, it
Management by invoking the M-SCTP STATUS indication primitive. The will inform the Layer Management by invoking the M-SCTP_STATUS
state of the remote ASP will be moved to "Down". At an ASP, the MTP3- indication primitive. The state of the ASP will be moved to ASP-DOWN
User at an ASP will be informed of the unavailability of any affected At an ASP, the MTP3-User will be informed of the unavailability of any
SS7 destinations through the use of MTP-PAUSE primitives. In the case affected SS7 destinations through the use of MTP-PAUSE indication
primitives. In the case
of SS7 network isolation, the local MTP3-Users may be informed by of SS7 network isolation, the local MTP3-Users MAY be informed by
implementation-dependent means as there is currently no primitive implementation-dependent means, as there is currently no primitive
defined for conveying this information. defined for conveying this information.
At an ASP, the Layer Management may try to re-establish the SCTP In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to re-
association using M-SCTP ESTABLISH request primitive. establish the SCTP Association. This MAY be done by the M3UA layer
automatically, or Layer Management MAY re-establish using the M-
SCTP_ESTABLISH request primitive.
4.3.3 M3UA Management procedures for peer-to-peer messages In the case of an SCTP-RESTART indication at an ASP, the ASP is now
considered by its M3UA peer to be in the ASP-DOWN state. The ASP, if
it is to recover, must begin any recovery with the ASP-Up procedure.
All M3UA MGMT and ASP Maintenance messages are sent on a sequenced 4.2.3 M3UA Management Procedures for Peer-to-Peer Messages
All M3UA Management and ASP State and Traffic Maintenance messages are
sent on a sequenced
stream to ensure ordering. SCTP stream '0' is used. stream to ensure ordering. SCTP stream '0' is used.
4.3.3.1 ASP-Up 4.2.3.1 ASP Up Procedures
After an ASP has successfully established an SCTP association to an SG, After an ASP has successfully established an SCTP association to an
the SG waits for the ASP to send an ASP-Up message, indicating that the SGP, the SGP waits for the ASP to send an ASP Up message, indicating
ASP M3UA peer is available. The ASP is always the initiator of the that the ASP M3UA peer is available. The ASP is always the initiator
ASP-Up exchange. This action MAY be initiated at the ASP by an M-ASP of the ASP Up message. This action MAY be initiated at the ASP by an
UP request primitive from Layer Management or may be initiated M-ASP_UP request primitive from Layer Management or MAY be initiated
automatically by an M3UA management function. automatically by an M3UA management function.
When an ASP-Up message is received at an SG and internally the remote When an ASP Up message is received at an SGP and internally the remote
ASP is in the "Down" state and not considered locked-out for local ASP is in the ASP-DOWN state and not considered locked-out for local
management reasons, the SG marks the remote ASP as "Inactive" and management reasons, the SGP marks the remote ASP in the state ASP-
informs Layer Management with an M-ASP-Up indication primitive. If the INACTIVE and informs Layer Management with an M-ASP_Up indication
SG knows, via current configuration data, which Application Servers the primitive. If the SGP is aware, via current configuration data, which
ASP is configured to operate in, it can update the ASP status to Application Servers the ASP is configured to operate in, the SGP
"Inactive" in each AS that it is a member. Alternatively, the SG may updates the ASP state to ASP-INACTIVE in each AS that it is a member.
move the ASP into a pool of Inactive ASPs available for future Alternatively, the SGP may move the ASP into a pool of Inactive ASPs
activation in Application Server(s) denoted in the subsequent ASP- available for future configuration within Application Server(s),
Active Routing Contexts. The SG responds with an ASP-Up Ack message in determined in a subsequent Registration Request or ASP Active
acknowledgement. The SG sends an ASP-Up Ack message in response to a procedure. The SGP responds with an ASP Up Ack message in
received ASP-Up message even if the ASP is already marked as "Inactive" acknowledgement. The SGP sends an ASP Up Ack message in response to a
at the SG. received ASP Up message even if the ASP is already marked as ASP-
INACTIVE at the SGP.
If for any local reason (e.g., management lock-out) the SG cannot If for any local reason (e.g., management lock-out) the SGP cannot
respond with an ASP-Up Ack, the SG responds to an ASP-Up with an ASP- respond with an ASP Up Ack message, the SGP responds to an ASP Up
Down Ack message with Reason "Management Blocking". message with an Error message with Reason "Refused - Management
Blocking".
At the ASP, the ASP-Up Ack message received is not acknowledged. Layer At the ASP, the ASP Up Ack message received is not acknowledged. Layer
Management is informed with an M-ASP UP confirm primitive . Management is informed with an M-ASP_UP confirm primitive. When an ASP
When the ASP sends an ASP-Up message it starts timer T(ack). If the enters the ASP-Inactive state from the ASP_Down state towards an SGP
ASP does not receive a response to an ASP-Up within T(ack), the ASP MAY the M3UA MUST mark all SS7 destinations configured to be reachable via
restart T(ack) and resend ASP-Up messages until it receives an ASP-Up this SGP as available.
Ack message. T(ack) is provisionable, with a default of 2 seconds.
Alternatively, retransmission of ASP-Up messages may be put under
control of Layer Management. In this method, expiry of T(ack) results
in a M-ASP-Up confirmation carrying a negative indication.
The ASP must wait for the ASP-Up Ack message before sending any other When the ASP sends an ASP Up message it starts timer T(ack). If the
M3UA messages (e.g., ASPAC, REG REQ). If the SG receives any other ASP does not receive a response to an ASP Up message within T(ack), the
M3UA messages before an ASP Up is received, the SG should discard them. ASP MAY restart T(ack) and resend ASP-Up messages until it receives an
ASP Up Ack message. T(ack) is provisionable, with a default of 2
seconds. Alternatively, retransmission of ASP Up messages MAY be put
under control of Layer Management. In this method, expiry of T(ack)
results in an M-ASP_UP confirm primitive carrying a negative
indication.
If an ASP-Up is received and internally the remote ASP is in the The ASP must wait for the ASP Up Ack message before sending any other
"Active" or "Standby" state, an Error ("Unexpected Message) is returned M3UA messages (e.g., ASP Active or REG REQ). If the SGP receives any
and the remote ASP state is not changed. other M3UA messages before an ASP Up message is received, the SGP
SHOULD discard them.
If an ASP-Up is received and internally the remote ASP is already in If an ASP Up message is received and internally the remote ASP is in
the "Inactive" state, and ASP-Up Ack is returned and no action is the ASP-ACTIVE or ASP-STANDBY state, an ASP-Up Ack message is returned,
taken. as well as an Error message ("Unexpected Message), and the remote ASP
state is changed to ASP-INACTIVE in all relevant Application Servers.
4.3.3.2 ASP-Down If an ASP Up message is received and internally the remote ASP is
already in the ASP-INACTIVE state, an ASP Up Ack message is returned
and no further action is taken.
The ASP will send an ASP-Down to an SG when the ASP wishes to be 4.2.3.1.1 M3UA Version Control
removed from service in all Application Servers that it is a member and
no longer receive any M3UA traffic or management messages. This action
MAY be initiated at the ASP by an M-ASP DOWN request primitive from
Layer Management or may be initiated automatically by an M3UA
management function.
Whether the ASP is permanently removed from any AS is a function of If an ASP Up message with an unsupported version is received, the
configuration management. receiving end responds with an Error message, indicating the version
the receiving node supports and notifies Layer Management.
The SG marks the ASP as "Down", informs Layer Management with an M-ASP- This is useful when protocol version upgrades are being performed in a
Down indication primitive, and returns an ASP-Down Ack message to the network. A node upgraded to a newer version should support the older
ASP if one of the following events occur: versions used on other nodes it is communicating with. Because ASPs
initiate the ASP Up procedure it is assumed that the Error message
would normally come from the SGP.
- an ASP-Down message is received from the ASP, 4.2.3.1.2 IPSP Considerations
- another ASPM message is received from the ASP and the SG has
locked out the ASP for management reasons.
The SG sends an ASP-Down Ack message in response to a received ASP-Down In the case of peer-to-peer IPSPs, either of the IPSPs (IPSP_A) may
message from the ASP even if the ASP is already marked as "Down" at the start operations by sending an ASP Up message to the remote peer
SG. (IPSP_B). When the ASP Up message is received at IPSP_B and internally
the remote IPSP_A is in the ASP-DOWN state and not considered locked-
out for local management reasons, IPSP_B marks the remote IPSP_A in the
state ASP-INACTIVE and informs Layer Management with an M-ASP_Up
indication primitive. IPSP_B returns an ASP-Up Ack message to IPSP_A.
IPSP_A moves IPSP_B to the ASP-INACTIVE state upon reception of an ASP
Up Ack message, if is not already in the ASP_INACTIVE state, and
informs Layer Management with an M-ASP_UP confirmation primitive.
At the ASP, the ASP-Down Ack message received is not acknowledged. If for any local reason (e.g., management lock-out) the IPSP_B cannot
Layer Management is informed with an M-ASP Down confirm primitive. respond with an ASP Up Ack message, it responds to an ASP Up message
with an Error message with Reason "Refused - Management Blocking" and
leaves IPSP_A in the ASP-DOWN state.
When the ASP sends an ASP-Down it starts timer T(ack). If the ASP does 4.2.3.2 ASP-Down Procedures
not receive a response to an ASP-Down within T(ack), the ASP MAY
restart T(ack) and resend ASP-Down messages until it receives an ASP-
Down Ack message. T(ack) is provisionable, with a default of 2
seconds. Alternatively, retransmission of ASP-Down messages may be put
under control of Layer Management. In this method, expiry of T(ack)
results in a M-ASP-Down confirmation carrying a negative indication.
4.3.3.3 M3UA Version Control The ASP will send an ASP Down message to an SGP when the ASP wishes to
be
removed from service in all Application Servers that it is a member and
no longer receive any DATA, SSNM or ASPTM messages. This action MAY be
initiated at the ASP by an M-ASP_DOWN request primitive from Layer
Management or MAY be initiated automatically by an M3UA management
function.
If an ASP-Up message with an unsupported version is received, the Whether the ASP is permanently removed from any AS is a function of
receiving end responds with an Error message, indicating the version configuration management. In the case where the ASP previously used
the receiving node supports and notifies Layer Management. the Registration procedures (see Section 3.5.5) to register within
Application Servers but has not deregistered from all of them prior to
sending the ASP Down message, the SGP SHOULD consider the ASP as
Deregistered in all Application Servers that it is still a member.
This is useful when protocol version upgrades are being performed in a The SGP marks the ASP as ASP-DOWN, informs Layer Management with an M-
network. A node upgraded to a newer version should support the older ASP_Down indication primitive, and returns an ASP Down Ack message to
versions used on other nodes it is communicating with. Because ASPs the ASP. has locked out the ASP for management reasons.
initiate the ASP-Up procedure it is assumed that the Error message
would normally come from the SG.
4.3.3.4 ASP-Active The SGP sends an ASP Down Ack message in response to a received ASP-
Down message from the ASP even if the ASP is already marked as ASP-DOWN
at the SGP. The SGP sends an ASP Down Ack message even if the reason
in the received ASP Down message is considered invalid.
Anytime after the ASP has received an ASP-Up Ack from the SG or IPSP, At the ASP, the ASP Down Ack message received is not acknowledged.
the ASP sends an ASP-Active (ASPAC) to the SG indicating that the ASP Layer Management is informed with an M-ASP_DOWN confirm primitive. If
is ready to start processing traffic. This action MAY be initiated at the ASP receives an ASP Down Ack without having sent an ASP Down
the ASP by an M-ASP Active request primitive from Layer Management or message, the ASP should now consider itself as in the ASP-DOWN state.
may be initiated automatically by an M3UA management function. In the If the ASP was previously in the ASP-ACTIVE or ASP_INACTIVE state, the
case where an ASP wishes to process the traffic for more than one ASP should then initiate procedures to return itself to its previous
Application Server across a common SCTP association, the ASPAC contains state.
a list of one or more Routing Contexts to indicate for which
Application Servers the ASPAC applies. It is not necessary for the ASP
to include all Routing Contexts of interest in the initial ASPAC
message, thus becoming active in all Routing Contexts at the same time.
Multiple ASPAC messages MAY be used to activate within the Application
Servers independently. In the case where an ASP-Active message does
not contain a Routing Context parameter, the receiver must know, via
configuration data, which Application Server(s) the ASP is a member.
When an ASP Active (ASPAC) message is received, the SG or IPSP responds When the ASP sends an ASP Down message it starts timer T(ack). If the
with an ASPAC Ack message(with the same Type value contained in the ASP does not receive a response to an ASP Down message within T(ack),
received APAC), acknowledging that the ASPAC was received and, the ASP MAY restart T(ack) and resend ASP Down messages until it
depending on the ASPAC Type value, moves the ASP to the "Active" or receives an ASP Down Ack message. T(ack) is provisionable, with a
"Standby" state within the associated Application Server(s). Layer default of 2 seconds. Alternatively, retransmission of ASP Down
Management is informed with an ASP-Active indication primitive. If the messages MAY be put under control of Layer Management. In this method,
SG or IPSP receives any Data messages before an ASPAC is received, the expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a
SG or IPSP should discard them. By sending an ASPAC Ack, the SG or negative indication.
IPSP is now ready to receive and send traffic for the related Routing
Contexts. The ASP MUST not send Data messages before receiving an
ASPAC Ack.
Multiple ASPAC Ack messages MAY be used in response to an ASPAC 4.2.3.4 ASP-Active Procedures
containing multiple Routing Contexts, allowing the SG or IPSP to
independently Ack for different (sets of) Routing Contexts. The SG or
IPSP sends an Error ("Invalid Routing Context") message for each
invalid or un-configured Routing Context value in a received ASPAC
message.
The SG MUST send an ASP-Active Ack message in response to a received Anytime after the ASP has received an ASP Up Ack message from the SGP
ASP-Active message from the ASP and the ASP is already marked as or IPSP, the ASP sends an ASP Active message to the SGP indicating that
"Active" at the SG. the ASP is ready to start processing traffic. This action MAY be
initiated at the ASP by an M-ASP_ACTIVE request primitive from Layer
Management or MAY be initiated automatically by an M3UA management
function. In the case where an ASP wishes to process the traffic for
more than one Application Server across a common SCTP association, the
ASP Active message(s) SHOULD contain a list of one or more Routing
Contexts to indicate for which Application Servers the ASP Active
message applies. It is not necessary for the ASP to include all Routing
Contexts of interest in a single ASP Active message, thus requesting to
become active in all Routing Contexts at the same time. Multiple ASP
Active messages MAY be used to activate within the Application Servers
independently, or in sets. In the case where an ASP Active message
does not contain a Routing Context parameter, the receiver must know,
via configuration data, which Application Server(s) the ASP is a
member.
At the ASP, the ASP-Active Ack message received is not acknowledged. For the Application Servers that the ASP can be successfully activated,
Layer Management is informed with an M-ASP Active confirm primitive. he SGP or IPSP responds
with one or more ASP Active Ack messages, including the associated
Routing Context and Traffic Mode Type values. The Routing Context
parameter MUST be included in the Asp Active Ack message if the
received ASP Active message contained any Routing Contexts. Depending
on the ASP Active Message Traffic Mode Type request, the SGP moves the
ASP to the correct ASP traffic state within the associated Application
Server(s). Layer Management is informed with an M-ASP_Active
indication. If the SGP or IPSP receives any Data messages before an ASP
Active message is received, the SGP or IPSP MAY discard them. By
sending an ASP Active Ack message, the SGP or IPSP is now ready to
receive and send traffic for the related Routing Context(s). The ASP
SHOULD NOT send Data messages for the related Routing Context(s) before
receiving an ASP Active Ack message, or it will risk message loss.
When the ASP sends an ASP-Active it starts timer T(ack). If the ASP Multiple ASP Active Ack messages MAY be used in response to an ASP
does not receive a response to an ASP-Active within T(ack), the ASP MAY Active message containing multiple Routing Contexts, allowing the SGP
restart T(ack) and resend ASP-Active messages until it receives an ASP- or IPSP to independently acknowledge the ASP Active message for
Active Ack message. T(ack) is provisionable, with a default of 2 different (sets of) Routing Contexts. The SGP or IPSP sends an Error
seconds. Alternatively, retransmission of ASP-Active messages may be message ("Invalid Routing Context") for each Routing Context value that
put under control of Layer Management. In this method, expiry of the ASP cannot be successfully activated .
T(ack) results in a M-ASP-Active confirmation carrying a negative
indication.
There are four modes of Application Server traffic handling in the SG In the case where an "out-of-the-blue" ASP Active message is received
M3UA - Over-ride, Over-ride (Standby), Loadshare and Load-share (i.e., the ASP has not registered with the SG or the SG has no static
(Standby). The Traffic Mode Type parameter in the ASPAC message configuration data for the ASP), the message may be silently discarded.
The SGP MUST send an ASP Active Ack message in response to a received
ASP Active message from the ASP, if the ASP is already marked in the
ASP-ACTIVE state at the SGP.
At the ASP, the ASP Active Ack message received is not acknowledged.
Layer Management is informed with an M-ASP_ACTIVE confirm primitive.
It is possible for the ASP to receive Data message(s) before the ASP
Active Ack message as the ASP Active Ack and Data messages from an SG
or IPSP may be sent on different SCTP streams. Message loss is
possible as the ASP does not consider itself in the ASP-ACTIVE state
until reception of the ASP Active Ack message.
When the ASP sends an ASP Active message it starts timer T(ack). If
the ASP does not receive a response to an ASP Active message within
T(ack), the ASP MAY restart T(ack) and resend ASP Active messages until
it receives an ASP Active Ack message. T(ack) is provisionable, with a
default of 2 seconds. Alternatively, retransmission of ASP Active
messages MAY be put under control of Layer Management. In this method,
expiry of T(ack) results in an M-ASP_ACTIVE confirm primitive carrying
a negative indication.
There are four modes of Application Server traffic handling in the SGP
M3UA layer - Over-ride, Over-ride (Standby), Load-share and Load-share
(Standby). The Traffic Mode Type parameter in the ASP Active message
indicates the traffic handling mode used in a particular Application indicates the traffic handling mode used in a particular Application
Server. If the SG determines that the mode indicated in an ASPAC is Server. If the SGP determines that the mode indicated in an ASP Active
unsupported or incompatible with the mode currently configured for the message is unsupported or incompatible with the mode currently
AS, the SG responds with an Error message indicating "Unsupported / configured for the AS, the SGP responds with an Error message
Invalid Traffic Handling Mode". If the Traffic Handling mode of the ("Unsupported / Invalid Traffic Handling Mode"). If the Traffic
Application Server is not already known via configuration data, then Handling mode of the Application Server is not already known via
the Traffic handling mode indicated in the first ASPAC message causing configuration data, then the Traffic Handling mode indicated in the
the transition of the Application Server state to "Active" MAY be used first ASP Active message causing the transition of the Application
to set the mode. Server state to AS-ACTIVE MAY be used to set the mode.
In the case of an Over-ride mode AS, reception of an ASPAC message at In the case of an Over-ride mode AS, reception of an ASP Active message
an SG causes the redirection of all traffic for the AS to the ASP that at an SGP causes the (re)direction of all traffic for the AS to the ASP
sent the ASPAC. Any previously active ASP in the AS is now considered that sent the ASP Active message. Any previously active ASP in the AS
Inactive and will no longer receive traffic from the SG within the AS. is now considered to be in state ASP-INACTIVE and SHOULD no longer
The SG or IPSP sends a Notify (Alternate ASP-Active) to the previously receive traffic from the SGP within the AS. The SGP or IPSP then MUST
active ASP in the AS, after stopping all traffic to that ASP. send a Notify message ("Alternate ASP-Active") to the previously active
ASP in the AS, and SHOULD stop traffic to/from that ASP. The ASP
receiving this Notify MUST consider itself now in the ASP-INACTIVE
state, if it is not already aware of this via inter-ASP communication
with the Over-riding ASP.
In the case of Over-ride (Standby) mode the traffic is not started to In the case of Over-ride (Standby) mode the traffic is not started to
the ASP until the previously active ASP transitions to "Inactive or the ASP until the currently active ASP transitions to the ASP-INACTIVE
"Down" state. At this point the ASP that sent the Over-Ride (Standby) or ASP-DOWN state. At this point the ASP that sent the ASP Active
ASPAC is moved to the Active state and the traffic is redirected. A message ("Over-Ride (Standby)") is moved to the ASP-ACTIVE state and
second ASP-Active Ack message with a new Traffic Mode Type ("Over- the traffic is redirected. A second ASP Active Ack message with a new
ride", previously "Over-ride(Standby)") is sent to the ASP. A Notify Traffic Mode Type ("Over-ride", previously "Over-ride(Standby)") is
(Alternate ASP-Active) message is not sent in this case. sent to the ASP. A Notify message ("Alternate ASP-Active") is not sent
in this case.
In the case of a Load-share mode AS, reception of an ASPAC message at If there is no currently active ASP, an ASP Active Ack message ("Over-
an SG or IPSP causes the direction of traffic to the ASP sending the ride") is returned right away and the traffic is directed to the ASP.
ASPAC, in addition to all the other ASPs that are currently active in
the AS. The algorithm at the SG for load-sharing traffic within an AS
to all the active ASPs is implementation dependent. The algorithm In the case of a Load-share mode AS, reception of an ASP Active message
could, for example be round-robin or based on information in the Data at an SGP or IPSP causes the direction of traffic to the ASP sending
message (e.g., such as the SLS, SCCP SSN, ISUP CIC value). the ASP Active message, in addition to all the other ASPs that are
currently active in the AS. The algorithm at the SGP for load-sharing
traffic within an AS to all the active ASPs is implementation
dependent. The algorithm could, for example, be round-robin or based
on information in the Data message (e.g., the SLS, SCCP SSN, ISUP CIC
value).
An SG or IPSP, upon reception of an ASPAC for the first ASP in a An SGP or IPSP, upon reception of an ASP Active message for the first
Loadshare AS, MAY choose not to direct traffic to a newly active ASP ASP in a Loadshare AS, MAY choose not to direct traffic to a newly
until it determines that there are sufficient resources to handle the active ASP until it determines that there are sufficient resources to
expected load (e.g., until there are sufficient ASPs "Active" in the handle the expected load (e.g., until there are "n" ASPs in state ASP-
AS). ACTIVE in the AS).
In the case of Load-share (Standby) mode, the traffic is not started to In the case of a Load-share (Standby) mode AS, the traffic is not
the ASP until the SG or IPSP determines that there are insufficient started to the ASP until the SGP or IPSP determines that there are
resources available in the AS. This is likely when one of the active insufficient resources available in the AS. This is likely when one of
load-sharing ASPs transitions to the "Inactive" or "Down" state. At the active load-sharing ASPs transitions to either the ASP-INACTIVE or
this point the ASP that sent the Load-share (Standby) ASPAC is moved to ASP-DOWN state. At this point the ASP that sent the ASP Active message
the Active state and traffic is started. A second ASP-Active Ack ("Load-share (Standby)") is moved to the ASP_ACTIVE state and traffic
message with a new Traffic Mode Type ("Load-share" - previously is started. A second ASP Active Ack message with a new Traffic Mode
"Loadshare(Standby)") is sent to the ASP. A Notify ("Insufficient ASP Type ("Load-share" - previously "Loadshare(Standby)") is sent to the
resources active in AS ") message is not sent in this case. ASP. A Notify message ("Insufficient ASP resources active in AS ") is
not sent in this case.
All ASPs within a load-sharing mode AS must be able to handle any If there is no currently active ASP, an ASP Active Ack message
traffic within the AS, in order to accommodate any potential fail-over ("Loadshare") is returned right away and the traffic is directed to the
or rebalancing of the offered load. ASP.
4.3.3.5 ASP Inactive All ASPs within a load-sharing mode AS must be able to process any
Data message received for the AS, in order to accommodate any potential
fail-over or rebalancing of the offered load.
4.2.3.5 ASP Inactive Procedures
When an ASP wishes to withdraw from receiving traffic within an AS, the When an ASP wishes to withdraw from receiving traffic within an AS, the
ASP sends an ASP Inactive (ASPIA) to the SG or IPSP. This action MAY ASP sends an ASP Inactive message to the SGP or IPSP. This action MAY
be initiated at the ASP by an M-ASP INACTIVE request primitive from be initiated at the ASP by an M-ASP_INACTIVE request primitive from
Layer Management or may be initiated automatically by an M3UA Layer Management or MAY be initiated automatically by an M3UA
management function. In the case where an ASP is processing the management function. In the case where an ASP is processing the
traffic for more than one Application Server across a common SCTP traffic for more than one Application Server across a common SCTP
association, the ASPIA contains one or more Routing Contexts to association, the ASP Inactive message contains one or more Routing
indicate for which Application Servers the ASPIA applies. In the case Contexts to indicate for which Application Servers the ASP Inactive
where an ASP-Inactive message does not contain a Routing Context message applies. In the case where an ASP Inactive message does not
parameter, the receiver must know, via configuration data, which contain a Routing Context parameter, the receiver must know, via
Application Servers the ASP is a member and move the ASP to the
"Inactive" state in each AS.
configuration data, which Application Servers the ASP is a member and
move the ASP to the ASP-INACTIVE state in each all Application Servers.
In the case of an Over-ride mode AS, where another ASP has already In the case of an Over-ride mode AS, where another ASP has already
taken over the traffic within the AS with an Over-ride ASPAC, the ASP taken over the traffic within the AS with an ASP Active ("Over-ride")
that sends the ASPIA is already considered by the SG to be "Inactive". message, the ASP that sends the ASP Inactive message is already
An ASPIA Ack message is sent to the ASP, after ensuring that all considered by the SGP to be in state ASP-INACTIVE. .An ASP Inactive Ack
traffic is stopped to the ASP. message is sent to the ASP, after ensuring that all traffic is stopped
to the ASP.
In the case of a Load-share mode AS, the SG moves the ASP to the In the case of a Load-share mode AS, the SGP moves the ASP to the ASP-
"Inactive" state and the AS traffic is re-allocated across the INACTIVE state and the AS traffic is re-allocated across the remaining
remaining "active" ASPs per the load-sharing algorithm currently used ASPs in the state ASP-ACTIVE, as per the load-sharing algorithm
within the AS. A NTFY(Insufficient ASP resources active in AS) may be currently used within the AS. A Notify message("Insufficient ASP
sent to all inactive ASPs, if required. However, if a Loadshare resources active in AS") MAY be sent to all inactive ASPs, if required.
However, if a Loadshare ("Standby") ASP is available, it may be now
immediately included in the loadshare group and a Notify message is not
sent. An ASP Inactive Ack message is sent to the ASP after all traffic
is halted and Layer Management is informed with an M-ASP_INACTIVE
indication primitive.
(Standby) ASP is available, it may be now immediately included in the Multiple ASP Inactive Ack messages MAY be used in response to an ASP
loadshare group and a Notify message is not sent. An ASPIA Ack message Inactive message containing multiple Routing Contexts, allowing the SGP
is sent to the ASP after all traffic is halted and Layer Management is or IPSP to independently acknowledge for different (sets of) Routing
informed with an ASP-INACTIVE indication primitive. Contexts. The SGP or IPSP sends an Error message ("Invalid Routing
Context") message for each invalid or un-configured Routing Context
value in a received ASP Inactive message message.
Multiple ASPIA Ack messages MAY be used in response to an ASPIA The SGP MUST send an ASP Inactive Ack message in response to a received
containing multiple Routing Contexts, allowing the SG or IPSP to ASP Inactive message from the ASP and the ASP is already marked as ASP-
independently Ack for different (sets of) Routing Contexts. The SG or INACTIVE at the SGP.
IPSP sends an Error ("Invalid Routing Context") message for each
invalid or un-configured Routing Context value in a received ASPIA
message.
The SG MUST send an ASP-Inactive Ack message in response to a received At the ASP, the ASP-Inactive Ack message received is not acknowledged.
ASP-Inactive message from the ASP and the ASP is already marked as Layer Management is informed with an M-ASP_INACTIVE confirm primitive.
"Inactive" at the SG. When the ASP sends an ASP Inactive message it starts timer T(ack). If
the ASP does not receive a response to an ASP Inactive message within
T(ack), the ASP MAY restart T(ack) and resend ASP Inactive messages
until it receives an ASP Inactive Ack message. T(ack) is
provisionable, with a default of 2 seconds. Alternatively,
retransmission of ASP Inactive messages MAY be put under control of
Layer Management. In this method, expiry of T(ack) results in a M-
ASP_Inactive confirm primitive carrying a negative indication.
At the ASP, the ASP-INACTIVE Ack message received is not acknowledged. If no other ASPs in the Application Server are in the state ASP-ACTIVE
Layer Management is informed with an M-ASP INACTIVE confirm primitive. or ASP-STANDBY, the SGP MUST send a Notify message ("AS-Pending") to
When the ASP sends an ASP-Inactive it starts timer T(ack). If the ASP all of the ASPs in the AS which are in the state ASP-INACTIVE. The SGP
does not receive a response to an ASP-Inactive within T(ack), the ASP SHOULD start buffering the incoming messages for T(r)seconds, after
MAY restart T(ack) and resend ASP-Inactive messages until it receives which messages MAY be discarded. T(r) is configurable by the network
an ASP-Inactive Ack message. T(ack) is provisionable, with a default operator. If the SGP receives an ASP Active message from an ASP in the
of 2 seconds. Alternatively, retransmission of ASP-Inactive messages AS before expiry of T(r), the buffered traffic is directed to that ASP
may be put under control of Layer Management. In this method, expiry and the timer is cancelled. If T(r) expires, the AS is moved to the
of T(ack) results in a M-ASP-Inactive confirmation carrying a negative AS-INACTIVE state.
indication.
If no other ASPs are "Active" or "Standby" in the Application Server, 4.2.3.6 Notify Procedures
the SG sends a NTFY(AS-Pending) to all inactive ASPs of the AS and
either discards all incoming messages for the AS or starts buffering
the incoming messages for T(r)seconds, after which messages will be
discarded. T(r) is configurable by the network operator. If the SG
receives an ASPAC from an ASP in the AS before expiry of T(r), the
buffered traffic is directed to the ASP and the timer is cancelled. If
T(r) expires, the AS is moved to the "Inactive" state.
4.3.3.6 Notify A Notify message reflecting a change in the AS state SHOULD be sent to
all ASPs in the AS, except those in the ASP-DOWN state, with
appropriate Status Information. The Notify message MUST be sent after
any ASP State or Traffic Management acknowledgement messages (e.g., ASP
Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack). At the
ASP, Layer Management is informed with an M-NOTIFY indication
primitive.
A Notify message reflecting a change in the AS state is sent to all In the case where a Notify message("AS-Pending") message is sent by an
ASPs in the AS, except those in the "Down" state, with appropriate SGP that now has no ASPs active to service the traffic, or where a
Status Identification. At the ASP, Layer Management is informed with Notify message("Insufficient ASP resources active in AS") is sent in
an M-NOTIFY indication primitive. the Loadshare mode, the Notify message does not explicitly compel the
ASP(s) receiving the message to become active. The ASPs remain in
control of what (and when) traffic action is taken.
In the case where a Notify (AS-Pending) message is sent by an SG that In the case where a Notify message does not contain a Routing Context
now has no ASPs active to service the traffic, or a NTFY(Insufficient parameter, the receiver must know, via configuration data, of which
ASP resources active in AS) is sent in the Loadshare mode, the Notify Application Servers the ASP is a member and take the appropriate action for
does not explicitly compel the ASP(s) receiving the message to become the ASP in each AS.
active. The ASPs remain in control of what (and when) traffic action is
taken.
4.3.3.7 Heartbeat 4.2.3.7 Heartbeat Procedures
The optional Heartbeat procedures may be used when operating over The optional Heartbeat procedures MAY be used when operating over
transport layers that do not have their own heartbeat mechanism for transport layers that do not have their own heartbeat mechanism for
detecting loss of the transport association (i.e., other than the detecting loss of the transport association (i.e., other than SCTP).
SCTP).
After receiving an ASP-Up Ack message from an M3UA peer in response to After receiving an ASP Up Ack message from an M3UA peer in response to
an ASP-Up message, an ASP may optionally send Beat messages an ASP Up message, an ASP may optionally send Heartbeat messages
periodically, subject to a provisionable timer T(beat). Upon receiving periodically, subject to a provisionable timer T(beat). Upon receiving
a BEAT message, the M3UA peer MUST respond with a BEAT ACK message. If a Heartbeat message, the M3UA peer MUST respond with a Heartbeat ACK
no BEAT ACK message (or any other M3UA message), is received by the ASP message.
within the timer 2*T(beat), the ASP will consider the remote M3UA peer
as "Down".
At the ASP, if no BEAT ACK message (or any other M3UA message) is At the ASP, if no Heartbeat Ack message (or any other M3UA message) is
received from the M3UA peer within 2*T(beat), the remote M3UA peer is received from the M3UA peer within 2*T(beat), the remote M3UA peer is
considered unavailable. Transmission of BEAT messages is stopped and considered unavailable. Transmission of Heartbeat messages is stopped
ASP-Up procedures are used to re-establish communication with the SG and the ASP SHOULD attempt to re-establish communication with the SGP
M3UA peer. M3UA peer.
The BEAT message may optionally contain an opaque Heartbeat Data The Heartbeat message may optionally contain an opaque Heartbeat Data
parameter that MUST be echoed back unchanged in the related Beat Ack parameter that MUST be echoed back unchanged in the related Heartbeat
message. The ASP upon examining the contents of the returned BEAT Ack Ack message. The ASP, upon examining the contents of the returned
message MAY choose to consider the remote ASP as unavailable. The Heartbeat Ack message, MAY choose to consider the remote M3UA peer as
contents/format of the Heartbeat Data parameter is implementation- unavailable. The contents/format of the Heartbeat Data parameter is
dependent and only of local interest to the original sender. The implementation-dependent and only of local interest to the original
contents may be used, for example, to support a Heartbeat sequence sender. The contents may be used, for example, to support a Heartbeat
algorithm (to detect missing Heartbeats), and/or a timestamp mechanism sequence algorithm (to detect missing Heartbeats), and/or a timestamp
(to evaluate delays). mechanism (to evaluate delays).
Note: Heartbeat related events are not shown in Figure 4 "ASP state Note: Heartbeat related events are not shown in Figure 4 "ASP state
transition diagram". transition diagram".
4.3.4 Routing Key Management procedures 4.2.4 Routing Key Management Procedures
4.3.4.1 Registration 4.2.4.1 Registration
An ASP MAY dynamically register with an SG as an ASP within an An ASP MAY dynamically register with an SGP as an ASP within an
Application Server using the REG REQ message. A Routing Key parameter Application Server using the REG REQ message. A Routing Key parameter
in the REG REQ specifies the parameters associated with the Routing in the REG REQ message specifies the parameters associated with the
Key. Routing Key.
The SG examines the contents of the received Routing Key parameter and The SGP examines the contents of the received Routing Key parameter and
compares it with the currently provisioned Routing Keys. If the compares it with the currently provisioned Routing Keys. If the
received Routing Key matches an existing SG Routing Key entry, and the received Routing Key matches an existing SGP Routing Key entry, and the
ASP is not currently included in the list of ASPs for the related ASP is not currently included in the list of ASPs for the related
Application Server, the ASP MAY authorize the ASP to be added to the Application Server, the SGP MAY authorize the ASP to be added to the
AS. Or, if the Routing Key does not currently exist and the received AS. Or, if the Routing Key does not currently exist and the received
Routing Key data is valid and unique, an SG supporting dynamic Routing Key data is valid and unique, an SGP supporting dynamic
configuration MAY authorize the creation of a new Routing Key and configuration MAY authorize the creation of a new Routing Key and
related Application Server and add the ASP to the new AS. In either related Application Server and add the ASP to the new AS. In either
case, the SG returns a Registration Response message to the ASP, case, the SGP returns a Registration Response message to the ASP,
containing the same Local-RK-Identifier as provided in the initial containing the same Local-RK-Identifier as provided in the initial
request, and a Registration Result "Successfully Registered". A unique request, and a Registration Result "Successfully Registered". A unique
Routing Context value assigned to the SG Routing Key is included. The Routing Context value assigned to the SGP Routing Key is included. The
method of Routing Context value assignment at the SG/SGP is method of Routing Context value assignment at the SG/SGP is
implementation dependent but must be guaranteed to be unique across all implementation dependent but must be guaranteed to be unique across all
SGPs in an SG. SGPs in an SG.
If the SG determines that the received Routing Key data is invalid, or If the SGP determines that the received Routing Key data is invalid, or
contains invalid parameter values, the SG returns a Registration contains invalid parameter values, the SGP returns a Registration
Response message to the ASP, containing a Registration Result "Error - Response message to the ASP, containing a Registration Result "Error -
Invalid Routing Key", "Error - Invalid DPC, "Error - Invalid Network Invalid Routing Key", "Error - Invalid DPC", "Error - Invalid Network
Appearance" as appropriate. Appearance" as appropriate.
If the SG determines that the Routing Key parameter overlaps with an If the SGP determines that a unique Routing Key cannot be created, the
existing Routing Key entry, the SG returns a Registration Response SGP returns a Registration Response message to the ASP, with a
message to the ASP, with a Registration Status of "Error - Overlapping Registration Status of "Error - "Cannot Support Unique Routing" An
(Non-Unique) Routing Key". An incoming signalling message received at incoming signalling message received at an SGP should not match against
an SG cannot match against more than one Routing Key. more than one Routing Key.
If the SG does not authorize the registration request, the SG returns a If the SGP does not authorize the registration request, the SGP returns
REG RSP message to the ASP containing the Registration Result "Error a REG RSP message to the ASP containing the Registration Result "Error
Permission Denied". Permission Denied".
If an SG determines that a received Routing Key does not currently If an SGP determines that a received Routing Key does not currently
exist and the SG does not support dynamic configuration, the SG returns exist and the SGP does not support dynamic configuration, the SGP
a Registration Response message to the ASP, containing a Registration returns a Registration Response message to the ASP, containing a
Result "Error - Routing Key not Provisioned". Registration Result "Error - Routing Key not Currently Provisioned".
If an SG determines that a received Routing Key does not currently If an SGP determines that a received Routing Key does not currently
exist and the SG supports dynamic configuration but does not have the exist and the SGP supports dynamic configuration but does not have the
capacity to add new Routing Key and Application Server entries, the SG capacity to add new Routing Key and Application Server entries, the SGP
returns a Registration Response message to the ASP, containing a returns a Registration Response message to the ASP, containing a
Registration Result "Error - Insufficient Resources". Registration Result "Error - Insufficient Resources".
If an SGP determines that one or more of the Routing Key parameters are
not supported for the purpose of creating new Routing Key entries, the
SGP returns a Registration Response message to the ASP, containing a
Registration Result "Error Unsupported RK parameter field". This
result MAY be used if, for example, the SGP does not support RK Circuit
Range Lists in a Routing Key because the SGP does not support ISUP
traffic, or does not provide CIC range granularity.
A Registration Response "Error Unsupported Traffic Handling Mode" is
returned if the Routing Key in the REG REQ contains an Traffic Handling
Mode that is inconsistent with the presently configured mode for the
matching Application Server.
An ASP MAY register multiple Routing Keys at once by including a number An ASP MAY register multiple Routing Keys at once by including a number
of Routing Key parameters in a single REG REQ message. The SG MAY of Routing Key parameters in a single REG REQ message. The SGP MAY
respond to each registration request in a single REG RSP message, respond to each registration request in a single REG RSP message,
indicating the success or failure result for each Routing Key in a indicating the success or failure result for each Routing Key in a
separate Registration Result parameter. Alternatively the SG MAY separate Registration Result parameter. Alternatively the SGP MAY
respond with multiple REG RSP messages, each with one or more respond with multiple REG RSP messages, each with one or more
Registration Result parameters. The ASP uses the Local-RK-Identifier Registration Result parameters. The ASP uses the Local-RK-Identifier
parameter to correlate the requests with the responses. parameter to correlate the requests with the responses.
Upon successful registration of an ASP in an AS, the SG can now send Upon successful registration of an ASP in an AS, the SGP can now send
related SSNM messaging, if this did not previously start upon the ASP related SS7 Signalling Network Management messaging, if this did not
transitioning to "Inactive". previously start upon the ASP transitioning to state ASP-INACTIVE
4.3.4.2 Deregistration 4.2.4.2 Deregistration
An ASP MAY dynamically deregister with an SG as an ASP within an An ASP MAY dynamically deregister with an SGP as an ASP within an
Application Server using the DEREG REQ message. A Routing Context Application Server using the DEREG REQ message. A Routing Context
parameter in the DEREG REQ specifies which Routing Key to de-register. parameter in the DEREG REQ message specifies which Routing Keys to de-
register. An ASP SHOULD move to the ASP-INACTIVE state for an
Application Server before attempting to deregister the Routing Key
(i.e., deregister after receiving an ASP Inactive Ack). Also, an ASP
SHOULD deregister from all Application Servers that it is a member
before attempting to move to the ASP-Down state.
The SG examines the contents of the received Routing Context parameter The SGP examines the contents of the received Routing Context parameter
and validates that the ASP is currently registered in the Application and validates that the ASP is currently registered in the Application
Server(s) related to the included Routing Context(s). If validated, Server(s) related to the included Routing Context(s). If validated,
the ASP is de-registered as an ASP in the related Application Server. the ASP is de-registered as an ASP in the related Application Server.
The deregistration procedure does not necessarily imply the deletion of The deregistration procedure does not necessarily imply the deletion of
Routing Key and Application Server configuration data at the SG. Other Routing Key and Application Server configuration data at the SGP. Other
ASPs may continue to be associated with the Application Server, in ASPs may continue to be associated with the Application Server, in
which case the Routing Key data CANNOT be deleted. If a Deregistration which case the Routing Key data MUST NOT be deleted. If a
results in no more ASPs in an Application Server, an SG MAY delete the Deregistration results in no more ASPs in an Application Server, an SGP
Routing Key data. MAY delete the Routing Key data.
The SG acknowledges the de-registration request by returning a DEREG The SGP acknowledges the deregistration request by returning a DEREG
RSP to the requesting ASP. The result of the de-registration is found RSP message to the requesting ASP. The result of the deregistration is
in the Deregistration Result parameter, indicating success or failure found in the Deregistration Result parameter, indicating success or
with cause. failure with cause.
An ASP MAY deregister multiple Routing Contexts at once by including a An ASP MAY deregister multiple Routing Contexts at once by including a
number of Routing Contexts in a single DEREG REQ message. The SG MUST number of Routing Contexts in a single DEREG REQ message. The SGP MAY
respond to each deregistration request in a single DEREG RSP message, respond to each deregistration request in a single DEREG RSP message,
indicating the success or failure result for each Routing Context in a indicating the success or failure result for each Routing Context in a
separate Deregistration Result parameter. separate Deregistration Result parameter.
4.4 Procedures to support the M3UA services 4.3 Procedures to Support the Availability or Congestion Status of SS7
Destination
4.4.1 At an SG 4.3.1 At an SGP
On receiving an MTP-PAUSE, MTP-RESUME, or MTP-STATUS indication On receiving an MTP-PAUSE, MTP-RESUME or MTP-STATUS indication
primitive from the nodal inter-working function at an SG, the SG M3UA primitive from the nodal inter-working function at an SGP, the SGP M3UA
layer will send a corresponding SSNM DUNA, DAVA, SCON, or DUPU message layer will send a corresponding SS7 Signalling Network Management
(see Section 2) to the M3UA peers at concerned ASPs. The M3UA layer (SSNM) DUNA, DAVA, SCON, or DUPU message (see Section 3.4) to the M3UA
must fill in various fields of the SSNM messages consistently with the peers at concerned ASPs. The M3UA layer must fill in various fields of
information received in the primitives. the SSNM messages consistently with the information received in the
primitives.
The SG M3UA determines the set of concerned ASPs to be informed based The SGP M3UA layer determines the set of concerned ASPs to be informed
on the SS7 network partition for which the primitive indication is based on the SS7 network partition for which the primitive indication
relevant. In this way, all ASPs configured to send/receive traffic is relevant. In this way, all ASPs configured to send/receive traffic
within a particular network appearance are informed. If the SG within a particular network appearance are informed. If the SGP
operates within a single SS7 network appearance, then all ASPs are operates within a single SS7 network appearance, then all ASPs are
informed. informed.
Optionally, the SG M3UA may filter further based on the Affected Point The SG M3UA MAY filter further based on the Affected Point Code in the
Code in the MTP-PAUSE, MTP-Resume, or MTP-Status indication primitives. MTP-PAUSE, MTP-RESUME or MTP-STATUS indication primitives. In this way
In this way ASPs can be informed only of affected destinations to which ASPs can be informed only of affected destinations to which they
they actually communicate. The SG M3UA may also suppress DUPU messages actually communicate. The SGP M3UA layer MAY also suppress DUPU
to ASPs that do not implement an MTP3-User protocol peer for the messages to ASPs that do not implement an MTP3-User protocol peer for
affected MTP3-User. the affected MTP3-User.
DUNA, DAVA, SCON messages must be sent on a sequenced stream as these DUNA, DAVA, SCON, and DRST messages MUST be sent sequentially and processed at
primitives should arrive in order. Stream 0 is used. Sequencing is the receiver in the order sent. SCTP stream "0" is used to provide the
not required for the DUPU or DAUD message, which may optionally be sent sequencing. . The only exception to this is if the international congestion
un-sequenced. The same applies for the SCON message if the method (see Q.704) is used. If so, the Unordered bit in the SCTP DATA chunk MAY
international congestion method (see Q.704) is used. be used for the SCON message.
4.4.2 At an ASP Sequencing is not required for the DUPU or DAUD messages, which MAY
be sent un-sequenced. Again, SCTP stream 0 is used, with optional use
of the Unordered bit in the SCTP DATA chunk.
4.4.2.1 Single SG configurations 4.3.2 At an ASP
At an ASP, upon receiving an SSNM message from the remote M3UA Peer, 4.3.2.1 Single SGP Configurations
the M3UA layer invokes the appropriate primitive indications to the
resident M3UA-Users. Local management is informed. At an ASP, upon receiving an SS7 Signalling Network Management (SSNM)
message from the remote M3UA Peer, the M3UA layer invokes the
appropriate primitive indications to the resident M3UA-Users. Local
management is informed.
In the case where a local event has caused the unavailability or In the case where a local event has caused the unavailability or
congestion status of SS7 destinations, the M3UA at the ASP should pass congestion status of SS7 destinations, the M3UA layer at the ASP MUST
up appropriate indications n the primitives to the M3UA User, as though pass up appropriate indications in the primitives to the M3UA User, as
equivalent SSNM messages were received. For example, the loss of an though equivalent SSNM messages were received. For example, the loss
SCTP association to an SG may cause the unavailability of a set of SS7 of an SCTP association to an SGP may cause the unavailability of a set
destinations. MTP-Pause indications to the M3UA User is appropriate. of SS7 destinations. MTP-PAUSE indication primitives to the M3UA User
To accomplish this, the M3UA layer at an ASP maintains the status of are appropriate. To accomplish this, the M3UA layer at an ASP
routes via the SG, much like an MTP3 layer maintains route-set status. maintains the status of routes via the SG(P), much like an MTP3 layer
maintains route-set status.
4.4.2.2 Multiple SG configurations 4.3.2.2 Multiple SGP Configurations
At an ASP, upon receiving an SSNM message from the remote M3UA Peer, At an ASP, upon receiving a Signalling Network Management message from
the M3UA layer updates the status of the affected route(s) via the the remote M3UA Peer, the M3UA layer updates the status of the affected
originating SG and determines, whether or not the overall availability route(s) via the originating SGP and determines, whether or not the
or congestion status of the effected destination(s) has changed. In overall availability or congestion status of the effected
this case the M3UA layer invokes the appropriate primitive indications destination(s) has changed. If so, the M3UA layer invokes the
to the resident M3UA-Users. Local management is informed