In this section:


This section outlines the implementation of SCCP routing within the DSC Platform.

MTP3 Routing Label

The MTP3 Routing Label parameter (SCCP-ROUTING-LABEL), although not present in various SS7 standards as part of the SCCP primitives, is essential to the DSC Platform because this primitive provides a means for a user to generate SS7 messages from a point code other than the local point code of the DSC Platform. This additional point code is also referred to as a virtual point code (VPC) and is also used when the SCCP user application is sending a global-routed message directly to the end point or to a transit STP.

Destination Point Code (DPC)

When the SCCP user application sends a message to the DSC Platform destined to the SS7 network, this system sends the message to the specified destination point code (DPC). If the DPC is unspecified, in other words the DPC Point Code Format is set to 255, the message is routed using the Local Point Code (LPC).

If the routing of a message fails when using destination point code routing, the DSC Platform responds with a N-PCSTATE to the SCCP user application.

Origination Point Code (OPC)

The DSC Platform uses the originating point code (OPC) specified in the routing label parameter unless the OPC is unspecified. If the OPC Point Code Format is set to 255, then the LPC of the DSC Platform is used.

Signaling Link Selection (SLS)

The SLS field contains either a 4-bit, 5-bit, or 8-bit number that indicates to the MTP3 which SS7 link to use for message transmission. MTP3 allocates all possible SLS values over all available links in an even distribution to ensure load balancing. MTP3 also guaranties in-sequence delivery of messages on a per SLS basis. SLS values are only important for outgoing messages.

For SCCP protocol class 0 (connectionless, no guarantied sequence), the DSC Platform SCCP can assign an incremental SLS value to ensure an equal distribution, or use the SLS value provided by the user. To use the SLS incrementally, enable the attribute in the SCCP Web user interface (UI).

For SCCP protocol class 1 (connectionless, guarantied sequence), the SCCP relies on the SCCP user application to supply the SLS value, allowing for guarantied sequence on a per SLS basis. It is the responsibility of the SCCP user application to ensure proper link load balancing by assigning all possible SLS values as evenly as possible.

For SCCP protocol class 2 (basic connection-oriented), the SCCP relies on the SCCP user application to supply the SLS value.

Called Party Address

When routing is based on SCCP Called Party address instead of DPC by setting the attribute in the SCCP web interface, the content of the called party address is examined. If the address indicator specifies routing on PC/SSN (bit 7of the AI octet), the supplied PC becomes the MTP3 destination point code (DPC) of the message.

If routing is based on global title (GT), the global title translation (GTT) within the DSC Platform is invoked, and routing is determined by the result of this translation.

If the routing of a message using SCCP procedures fails, an N-NOTICE indication is sent to the SCCP user application for class 0 and class 1 (N-UNITDATA) protocol class if the return on error bit is set.

Managing SCCP Connections (Connection-Oriented)

For protocol class 2 connections, it is important for the SCCP user application to properly manage the connection identifiers, also referred as the local reference numbers.

In general, the SCCP user application is responsible for generating a unique local reference number for a given DSC Platform cluster (point code). This system keeps a list of all active connections, and rejects any user requests that conflict with active connections.

This unique local reference number may contain any three-octet value (from 0x000000 to 0xfffffe, 0xffffff is reserved), and may be divided into sub-fields. It is only important to the SCCP that this number be unique throughout the duration of the connection.

Incoming SCCP Connections

For incoming SCCP connections from the SS7 network, a reference number is pre-assigned by the remote SCCP user application, but a local reference number still has to be assigned by the local SCCP user application.

When receiving a N-CONNECT indication message from the DSC Platform, the source reference number indicates the local reference number of the connection at the remote SCCP. The destination reference number is unspecified.

When responding with a N-CONNECT response message accepting the connection, the SCCP user application populates the destination reference number with the incoming source reference number and also populates the source reference number with a new unique local reference number. All subsequent messages use the same arrangement.

When responding with a N-DISCONNECT request message, refusing the connection, the SCCP user application populates the destination reference number with the incoming source reference number. The SCCP user application does not have to supply a local reference number, and, therefore, sets this number to undefined.

Outgoing SCCP Connections

For outgoing SCCP connections to the SS7 network, the SCCP user application sends a N-CONNECT request to the DSC Platform, populates the source reference number with a new unique local reference number, and sets the destination reference number to undefined.

If the SCCP user application receives a N-DISCONNECT, the connection has been refused. Otherwise, the SCCP user application receives a N-CONNECT confirmation with valid destination and source reference numbers. As with incoming SCCP connections, the SCCP user application populates the destination reference number with the incoming source reference number and also populates the source reference number with the local reference number for all subsequent messages for this connection.

  • No labels