In one of my previous posts, I was asked to share my knowledge about SCCP routing. This article is my attempt to do that.
First of all, please tale a look on below picture (all SS7 books and articles have it, so I also don’t want to be exclusion):
Now take a look on ISUP. Nice protocol, perfectly working without SCCP (there are some cases, where SCCP is required, but I’ve never seen them). So the question is – why SCCP was developed?
This is because of different tasks. ISUP is designed to establish voice channel between 2 predefined network nodes. These nodes might be inside 1 network (2 MSC), but also in different networks (2 GMSCs of competitive networks). Also this protocol is initially developed to solve only one problem – establish a voice channel.
But what to do if you don’t know exact location of network nodes and also you need to create request, which has no relation to voice? SCCP was designed exactly for this purpose.
In order to use SCCP, each node is given an additional address - Global Title (in addition to MTP3 layer address – Point Code). A global title is an address, such as dialed-digits, which does not explicitly contain information that would allow routing in the SS7 network.
Together with MTP3, SCCP forms third layer of OSI reference model. So it’s like Internet Protocol (IP), which gives the ability to correctly route messages in network. This happens in such a way:
This is because of different tasks. ISUP is designed to establish voice channel between 2 predefined network nodes. These nodes might be inside 1 network (2 MSC), but also in different networks (2 GMSCs of competitive networks). Also this protocol is initially developed to solve only one problem – establish a voice channel.
But what to do if you don’t know exact location of network nodes and also you need to create request, which has no relation to voice? SCCP was designed exactly for this purpose.
In order to use SCCP, each node is given an additional address - Global Title (in addition to MTP3 layer address – Point Code). A global title is an address, such as dialed-digits, which does not explicitly contain information that would allow routing in the SS7 network.
Together with MTP3, SCCP forms third layer of OSI reference model. So it’s like Internet Protocol (IP), which gives the ability to correctly route messages in network. This happens in such a way:
1. Application on Node A sends message to node B.
2. Node A checks routing table and:
2.1. Finds the route. Actually, GTT happens (more about GTT is below) – Point Code and Subsystem number (if required) of Node B is determined. This means, that message can be sent using MTP3 routing: Node A puts Point Code of node B into DPC filed (Destination Point Code) and checking for suitable route (SS7 linkset).
2.2. Doesn’t find “strict” route. If routing table has default route, then message is sent using it (to Node C). It is expected that Node C knows what to do with this message.
2.3. Doesn’t find any route. Application might be informed about routing error, like “Message type:UDTS, Return cause:No translation for this specific address”
Options 2.1 and 2.3 aren’t interesting for us, because we’re talking about SCCP routing. So let’s assume that message came to node C.
3. Node C performs the same procedure as Node A did. 3 options available again. There is a reason to discuss option 1, which is GTT.
Node C got the message and started analysis of SCCP Called Party Address (CdPA). I’m not going to describe whole structure of this address (Internet is full of such details), but some fields should be mentioned:
3. Node C performs the same procedure as Node A did. 3 options available again. There is a reason to discuss option 1, which is GTT.
Node C got the message and started analysis of SCCP Called Party Address (CdPA). I’m not going to describe whole structure of this address (Internet is full of such details), but some fields should be mentioned:
- Routing Indicator (as a part of Address Indicator). Points to routing type – GT-based or PC+SSN-based.
- Translation Type. Usually it’s 0. ITU-T has defined some possible values and how they should be interpreted, but in practice all such values might be used for own routing purpose (check examples below).
- Numbering Plan (see details in GSM numbering plans article)
- Address Information. Number itself.
Node C is starting to analyse received message. RI has “Route on GT” value, because it’s our node is going to perform final translation. TT value can be used to choose destination node. E.g., Node B if TT=0, or Node D if TT=10.
Routing also might depend on Numbering Plan value. E.g., route all messages with NP=E.214 (like MAP Update Location) to roaming platform, which performs decision allow/disallow subscriber’s registration in particular network. Roaming platform might return the message back to network without any modifications (just OPC and DPC will be swapped). But this means that Node C might again send this message back to roaming platform (since it has routing rule – route all messages with NP=E.214 there). In order to not create loop of messages, roaming platform can set TT value, which differs from 0. Routing table on Node C can be modified to not send messages with TT != 0 to roaming platform even if NP=E.214. Modern STPs can additionally analyze source direction of message (linkset or some internal identifier), so even if TT=0 they won’t send message again to roaming platform. If all previous checks passed, but routing decision wasn’t done, the Address Information filed is analyzed. Node C uses this information to decide that message is for node B with subsystem XX (if subsystem wasn’t mentioned in original message). Point code of node B is already defined, message is sent via corresponding linkset. Routing is dome, GTT performed.
Routing also might depend on Numbering Plan value. E.g., route all messages with NP=E.214 (like MAP Update Location) to roaming platform, which performs decision allow/disallow subscriber’s registration in particular network. Roaming platform might return the message back to network without any modifications (just OPC and DPC will be swapped). But this means that Node C might again send this message back to roaming platform (since it has routing rule – route all messages with NP=E.214 there). In order to not create loop of messages, roaming platform can set TT value, which differs from 0. Routing table on Node C can be modified to not send messages with TT != 0 to roaming platform even if NP=E.214. Modern STPs can additionally analyze source direction of message (linkset or some internal identifier), so even if TT=0 they won’t send message again to roaming platform. If all previous checks passed, but routing decision wasn’t done, the Address Information filed is analyzed. Node C uses this information to decide that message is for node B with subsystem XX (if subsystem wasn’t mentioned in original message). Point code of node B is already defined, message is sent via corresponding linkset. Routing is dome, GTT performed.
