SS7 & Wireless: Walking Into the Sunset?

SS7 is suited for carrying signaling traffic in many ways. There is probably no other protocol that is as bullet proof. Its closest competitor, TCP/IP, has many advantages, but real-time responsiveness, robustness and reliability are not among them. SS7 is continuing to evolve, but slowly and without much wireless industry involvement. Consequently, new SS7 developments represent both opportunities and barriers.

LARGE MESSAGESOne of today's SS7 limitations is that the size of a single data packet must be less than 250bytes (the exact limit varies). This was not a problem for the first few revisions of IS-41, but as the profile for each subscriber gets more complex, and more services such as short messaging are added, this limit comes closer. SS7 provides several future options.

The first solution is segmentation and re-assembly. A message center that needs to send a longer message can, theoretically, break it up into pieces, each of which is less than the 250byte limit, and send them separately. Unfortunately, the 1988 and 1992 versions that all wireless SS7 carriers use do not support this capability. Segmentation requires a new signaling connection control part (SCCP) message and extended unit data, which the SCCP layer of any non-compliant SS7 network node will discard. Luckily, intermediate signal transfer points (STPs) do not always look at the SCCP layer, but often can route on the message- transfer-point layer information. STPs do need to look at the SCCP layer if global title translation is being used. Consequently, if the SS7 network is not upgraded, it is difficult to determine whether segmentation is a viable option.

Another solution is to allow messages to be longer. However, longer messages would cause unacceptable delays on standard 64kb/s links (a 1kbyte message would take more than one eighth of a second to transmit). Future SS7 releases will allow 1.5Mb/s links (a full T1) and messages up to about 3kbytes in length. It will be a long time before TIA/EIA-41 messages get to be that long.

This solution also has limitations. Assuming that the internal signaling links between STPs are upgraded to the higher speeds, a message that starts out segmented cannot be unsegmented part way through. This is because intermediate STPs are not guaranteed to have all segments. In addition, they are not designed to do the segment buffering and timing required to accumulate segments and retransmit them back together again.

Although a message that starts as segments cannot be put back together until it reaches the final destination, an STP that encounters a transition from a 1.5Mb/s link to a 64kb/s link can segment a message that starts out as a large message.

High-speed SS7 links are a good long-term solution to the message-size problem, but will not really help until all STPs and the majority of end nodes in the SS7 network are upgraded to support them.

Another consideration is to allow SS7 links to be carried over TCP/IP. However, this has the same limitations as the high-speed SS7 solution: The network cannot use the large packet capabilities of TCP/IP and its addressing methodologies unless there is true SS7 and TCP/IP integration.

RELEASE TO PIVOTRelease to Pivot, and its cousin, Facility Request to Pivot, are new capabilities with unique wireless applications. Release to Pivot was designed for wireline services such as directory-assistance call completion in which a call is routed from an originating switch to a directory-assistance service. Then, instead of forwarding the call from that service, a signaling message is sent back to the original switch. This allows the first switch to forward the call, eliminating at least one trunk from the call.

The wireless application optimizes call routing to roamers. For example, if two Americans in Tokyo try to call each other, first the Tokyo MSC handles the call, routing it across the Pacific Ocean to the destination mobile's home system in the United States. Then, it is routed back across the Pacific to possibly the same MSC, which handles both ends of the call.

The MSC does not realize these two mobiles are in the same call because it is virtually impossible to recognize that dialed digits belong to a mobile. If it could recognize the digits, the MSC could query the HLR directly and terminate to the mobile without setting up one international trunk, let alone two. With number portability looming in the next few years, it will be impossible to recognize mobile numbers by examining the dialed digits even for national calls.

The solution is to allow the call to be set up to the United States, have the home system determine where the mobile is, then send the temporary local directory number (TLDN) to the originating switch, which could work even if the switch were not wireless. For example, the TLDN would be an internationally formatted number belonging to a Tokyo MSC.

In the future, SS7 will allow two solutions. The preferred solution in ANSI SS7 is to extend the existing initial address message (IAM) to indicate that Release to Pivot is possible, and then to extend the release (REL) message to include the TLDN. When this is received, the originating MSC drops the single trans-Pacific trunk and routes the call to the TLDN-specified destination. The MSC will know when it is being pivoted to one of its own numbers and can page the mobile.

The second solution, which the ITU-T also is standardizing for international SS7, is Facility Request to Pivot. This method sends a new message instead of REL, allowing the originating switch to perform the release. This method is less efficient, but arguably more robust.

There are some billing issues with this new capability, but they are not insurmountable. Although the home wireless system is not trunked into the call, as typical for mobile terminations, the serving system will have to send billing records to the home system. You could bill this type of call much like today's roamer originations (based on the serving MSC record, not the home system).

COMPATIBILITYCompatibility between revisions also is a concern. Older protocol versions cannot handle new and unforeseen messages properly and new parameters within existing messages. Even default actions such as ignoring the new information or, at an intermediate network element, passing it through unchanged, cannot be guaranteed problem free.

Designing a standard solution for the oversize message problem has stalled largely because of compatibility problems. Future SS7 versions may include a more pro-active method, where a response message indicates that it has reached a network incompatibility. For oversize messages, the originating system could take alternate action. For short messages, it would hold until later, split into multiple separate messages or generate an error to the message sender. But these solutions aren't ideal because they require separate designs for each application.

INTERNATIONAL LIMITATIONSOne problem with SS7 is the lack of seamless international operation, unlike the TCP/IP protocol used on the Internet. There is, for example, no clue in the domain name cnp-wireless.com that it is located in Canada and not the United States. Although it is possible to determine the virtual location of any domain on the Internet, it makes little difference to message routing.

SS7 is a different story, largely because it is a telecom protocol. Because telecom is controlled rigidly on a national basis, many countries have their own signaling systems. Although all SS7 variants share common features, being a little bit compatible is the same as not being compatible at all.

SS7's biggest limitation is that the basic addressing method, the point code, stops at a country boundary (except with the integrated networks of the United States and Canada). For international signaling, an alternate address method known as global title translation is necessary. But this is more complex than point codes and requires managing distinct routing tables in every STP for each global title type.

Unfortunately, barring a single world government, it is unlikely that interconnecting national SS7 networks will become easier any time soon. The wireless industry will have to implement global titles to gain seamless international roaming.

GLOBAL TITLE TRANSLATIONGlobal title translation is the use of a non-SS7 identifier as a routing address. Examples include an international phone number (ITU-T Recommendation E.164), a calling card or a wireless phone identifier (either MIN or ITU-T Recommendation E.212 IMSI). Global title translation is necessary when the point code of the destination network node is not known, or when the destination is in another country. Global title analysis may occur at several STPs or international gateways in the signaling path, until it is finally possible to convert the global title into the destination point code.

Global title translation has played little role in wireless because of the amount of information that has to be maintained between roaming partners. So adding a point code to the list has little impact. However, a global title is a necessity with international roaming. Global title routing also is required for many database transactions.

Without a global title solution today, SS7 carriers are extending the ANSI SS7 network into other countries. For political and technical reasons, this is a short-term solution. The long-term solution, which the TIA standards committee TR-45.2 is developing, is to use a mixture of mobile identifiers (E.212 IMSI) and mobile phone numbers (E.164) as global titles. This will take time to implement, because the industry has to develop international gateway support and update each national SS7 variant, as well as all SS7 network nodes that are used for wireless signaling.

MANDATESMSCs must provide the location of mobiles making E-911 to within 125 meters (400 feet). Most carriers will use the modified SS7 ISUP IAM defined in T1.628 to send initial location to the public service answering point (PSAP). But so far they have been reluctant to fully commit to an SS7 ISUP-only solution, although this would be possible by modifying other ISUP messages available for mid-call signaling. Instead, carriers are maintaining a non-call-associated data communications path (perhaps TCP/IP) that will allow location updates, and also will allow MSCs not supporting ISUP to transmit initial location.

The industry recently received some relief from another mandate. The LNP mandate was pushed back to November 2002. However, the requirement for MSCs to route to ported wireline numbers has not changed. This requirement will push mandated carriers to implement ISUP. Without ISUP support there is no way to indicate that a number-portability query has been performed.

Number portability significantly complicates global title translations that are based on phone numbers. In most cases, each global title has to be duplicated to indicate whether the global title has been through a number portability query or not. This ensures that each global title results in one number portability query while it is being routed and eliminates the possibility of message looping.

COMPETITIVE ADVANTAGET1S1 standards committees are discussing geographic portability. However, given the increasing aversion to number portability in the wireless industry, it is unlikely carriers will rush to implement this capability even when it is standardized. In the distant future, however, carriers might consider it after they implement LNP fully. The incremental cost of portability over a larger region might be worth the competitive advantage it provides.

Many carriers also would like to see calling party pays (CPP). LNP drove a stake through the heart of existing CPP systems that rely on recognizable number blocks. Furthermore, a CTIA-sponsored study group determined that terminating wireless carriers should be in control of the service, rather than the originating carrier (often wireline). It only takes minor SS7 ISUP modifications to allow the originating calling line and carrier to be identified for billing purposes and to allow wireline carriers to block CPP calls from individual lines. Currently, an ISUP modification proposal is in development.

ONGOING EVOLUTIONOverall, SS7 will remain a critical component of wireless networks for years to come. Although this protocol has some significant limitations, it is evolving, and smart carriers will use those as competitive advantages.