 |
|
|
When I was a young child growing up in England, there was an old, large ‘wireless’ in our house. One day, when nobody was looking, I moved it out from the wall and, just as I had suspected, there was a wire coming out of the back and into the wall. From that day on, I never trusted an adult again (although I felt better when I saw my first battery-operated transistor radio)!
In a recent speech, FCC Chairman William Kennard had some fun at the expense of a journalist who, in 1907, predicted “that there would never be a wireless connection between New York and San Francisco.” Somebody should tell Mr. Kennard that, unless you are talking on a satellite phone, that is still true today. If you pick up a cellphone in New York and call a colleague in San Francisco on their PCS phone, only the first and last mile are wireless. And, when I last checked my atlas, there were a lot more than two miles between those two cities!
Most cellphone users have probably figured out by now that their calls really only go to the closest cellsite, before being routed over wires to the destination cellsite. However, most users probably do not realize that before the call is routed to the destination, the system has to figure out where the mobile is, and arrange for the call to be delivered. This process is performed largely with the assistance of two protocols. TIA/EIA-41 (formerly IS-41) provides the application messages for mobile registration and call delivery, and SS7, the subject of this article, gets TIA/EIA-41 messages from Point A to Point B through a responsive, robust, reliable, network.
SS7 has four different parts that are all of interest to wireless systems (see Figure 1). MTP (Message Transfer Part, defined in T1.111) is the basic level of the protocol, and is used to reliably transmit messages between any two locations in a national signaling network. The optional SCCP layer (defined in T1.112) provides extended routing capabilities, such as global title support (required for international signaling) and segmentation of oversize messages. ISUP (Integrated Services User Part, defined in T1.113) is an application layer for call setup signaling, and TCAP (defined in T1.114) is an application sub-layer that is used to structure many applications, most notably the TIA/EIA-41 mobility management application used in many wireless networks.
|
Wireline signaling networks are active mostly when a phone is setting up a call. Wireless signaling network requirements are much greater because signaling traffic is required when mobiles are idle, and when they are in the middle of a call. Every time a mobile finds itself in a new system, for example, it has to register, which requires the current serving location to communicate with the Home Location Register (HLR). At any time, a short text message may be sent to a mobile from an email gateway, or a mobile may be in a call with signal strength dropping, and neighboring systems have to communicate to determine the best system to pick up the mobile after a handoff.
SS7 is ideally suited for carrying wireless 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 surely realtime responsiveness, robustness and reliability are not among them. SS7 is continuing to evolve, but slowly, and without as much wireless industry involvement as there should be. Consequently, new developments in the SS7 protocol represent both opportunities and barriers for wireless.
One of the current limitations of SS7 is that the size of a single data packet must be less than about 250 bytes (the exact limit varies). For the first few revisions of IS-41 this was not a problem, but as the profile for each subscriber gets more complex, and more services like “short” messaging are added, this limit comes closer. SS7 provides a number of future options.
The first solution to the large message problem provided by SS7 is known as Segmentation & Reassembly. A message center that needs to send a long short message (there’s an oxymoron for you) can, theoretically, break it up into pieces, each of which is less than the 250 byte limit, and send them separately. Unfortunately, there is a fly in this ointment. This capability is not supported by the 1988 and 1992 versions of SS7 that are in use by all wireless SS7 network providers. Segmentation requires a new SCCP message (XUDT, Extended Unit Data), which will be discarded by the SCCP layer of any non-compliant SS7 network node. Luckily, intermediate STPs do not always look at the SCCP layer, but can often route on the MTP layer information. STPs do need to look at the SCCP layer if global title translation is being used (more on that later). Consequently, if the SS7 network is not upgraded, it is difficult (although not impossible) to determine whether segmentation is a viable option.
Another solution to the long message problem is to simply allow messages to be longer. However, longer messages would cause unacceptable delays on standard 64 kbps links (a 1 kbyte message would take more than 1/8th of a second to transmit). Future releases of SS7 will allow 1.5 Mbps links (a full T1), and messages up to about 3 kbytes in length. It will be a long time before TIA/EIA-41 messages get to be that long (at least until Calling Face Identification is available).
However, this solution is not without its limitations. Assuming that the internal signaling links between STPs are most likely to be upgraded to the higher speeds, Figure 2 shows that a message that starts out segmented cannot be un-segmented part way through. This is because intermediate STPs are not guaranteed to have all segments, and even if they were, are not designed to do the segment buffering and timing that would be required to accumulate segments and then retransmit them once Humpty Dumpty is back together again.
|
While a message that starts as segments cannot be put back together until it reaches the final destination, a message that starts as a large message can be segmented by an STP that encounters a transition from a 1.5 Mbps link to a 64 kbps link (see Figure 3).
High speed SS7 links are a good long-term solution to the message size problem, but will not help until the majority of STPs are upgraded to support them.
|
Another advance being considered is to allow SS7 links to be carried over TCP/IP. However, this has the same limitations as the high-speed SS7 solution in that the large packet capabilities of TCP/IP and its addressing methodologies cannot be used unless there is true integration of SS7 and TCP/IP, which has not yet been considered.
Release to Pivot, and its cousin Facility Request to Pivot, are exciting new capabilities with unique applications in wireless communications. Release to Pivot was designed for wireline services like Directory Assistance Call Completion in which a call is routed from an originating switch to a directory assistance service and then, instead of forwarding the call from that service, a signaling message is sent back to the original switch. This allows the call to be forwarded from the first switch, eliminating at least one trunk from the call.
The application in wireless communications is to optimize call routing to roamers. Consider, for example, two Americans in Tokyo trying to call each other on their wireless phones. The call is first handled by an MSC in Tokyo, routed across the Pacific Ocean to the destination mobile’s home system in the U.S., and then back across the Pacific to possibly the same MSC which handles both ends of the call without even realizing it.
The reason why the MSC does not realize that these two mobiles are in the same call is because it is virtually impossible to recognize that dialed digits belong to a mobile (if that was the case, the MSC could query the HLR directly, and terminate to the mobile without ever setting up one international trunk, let alone two). And, 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 U.S., have the home system determine the mobile’s location (i.e. Tokyo), and then send the temporary routing digits (known as a TLDN – Temporary Local Directory Number) to the originating switch (which could work even if the switch was not wireless). In our example, the TLDN would be an internationally-formatted dialable number belonging to an MSC in Tokyo.
SS7 will, in future, allow two solutions to the problem. The preferred solution in ANSI SS7 (illustrated in Figure 4) 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 (in our example), the originating MSC drops the single trans-Pacific trunk being used, and routes the call to the destination specified by the TLDN. Hopefully the MSC will recognize when it is being pivoted to one of its own numbers, and can simply page the mobile.
|
The second solution, which is also being standardized by the ITU-T for international SS7 is the “Facility Request to Pivot” method. This method adds a new message that is sent 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 it almost always is for mobile terminations nowadays, the serving system will have to send billing records to the home system. This type of call would then be billed much like roamer originations are today (i.e. based on a record generated by the serving MSC, and not by the home system).
Compatibility between revisions is a concern for all protocol enhancers. Obviously, older protocol versions cannot properly handle new and unforeseen messages and new parameters within existing messages (and new fields within existing parameters, and new values in those new fields, and so on ad infinitum). Even default actions such as simply ignoring the new information or, at an intermediate network element, passing it through unchanged, cannot be guaranteed to be problem free.
The design of a standard solution to the oversize message problem, noted above, has stalled largely because of the compatibility problem. Future versions of SS7 may include a more proactive method, where a response message indicates that a network incompatibility has been reached. In the case of oversize messages, for example, the originating system could take alternate action. In the case of a short message, this could be to hold it until later, to split it into multiple separate messages or to generate an error to the sender of the message. However, these solutions have to be designed separately for each application, so are hardly ideal.
One of the problems with SS7 that I have whined about before is the lack of seamless international operation, unlike the TCP/IP protocol used on the internet. There is, for example, no clue in my company’s 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 the routing of messages. SS7 is a different story, largely because it is a telecommunications protocol. Because telecommunications is very rigidly controlled on a national basis, many countries have their own signaling system, and SS7 is not any different. While all variants of SS7 share many common features, being a little bit compatible is the opposite of being a little bit pregnant (i.e. being a little bit compatible is to be not compatible at all, whereas being a little bit pregnant is, well, just wait a few more months and you will see).
The biggest limitation of SS7 is that the basic addressing method, the point code, stops at a country boundary (with the integrated networks of the U.S. and Canada being one of the few exceptions). For international signaling, an alternate address method known as global title translation is necessary. But, this is more complex than point codes, and requires management of 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 is just going to have to bite the bullet and implement global titles to gain seamless international roaming.
Global title translation is the use of a non-SS7 identifier as a routing address. Examples are 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. Analysis of the global title 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, when international roaming is considered, a global title becomes a necessity. Global title routing is also required for many database transactions, and global titles based on phone numbers are significantly complicated by local number portability.
In the absence of a global title solution today, SS7 network providers are extending the ANSI SS7 network into other countries, for wireless communications only. For political and technical reasons, this is only a short-term solution. The long-term solution (being developed by TIA standards committee TR-45.2) is to use a mixture of mobile identifiers (E.212 IMSI, to be exact) and mobile phone numbers (E.164) as global titles. This will take some time to implement, because international gateway support has to be developed, and each national SS7 variant has to be updated, as well as all SS7 network nodes that are used for wireless signaling.
Wireless switches (MSCs) are under a mandate to provide the location of mobiles making emergency calls to within 125 meters (400 feet). The location will be expressed as latitude and longitude (with altitude possible in future). It is likely that most wireless carriers will choose to use the modified SS7 ISUP IAM (Initial Address Message) defined in T1.628 to send initial location to the PSAP (Public Service Answering Point), but they have so far been reluctant to fully commit to an SS7 ISUP-only solution, although this would certainly be possible through modifications to other ISUP messages available for mid-call signaling. Instead, wireless carriers are intent on maintaining a non-call-associated data communications path (perhaps TCP/IP) that will allow location updates, and also will allow MSCs that do not support ISUP to transmit initial location.
The wireless industry has recently received some relief from the local number portability mandate, with the ability for wireless phones to be ported getting pushed out until November, 2002. However, the requirement for MSCs to route to ported wireline numbers has not changed. This requirement will push carriers within the number portability mandate (the larger urban areas in the U.S.) to implement ISUP, because without ISUP support there is no way to indicate that a number portability query has been performed, which could lead to additional (costly and time-consuming) database queries and, far worse, endless call setup looping which could bring switches to their knees.
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 or not the global title has been through a number portability query. This ensures that each global title results in at most one number portability query while it is being routed, and eliminates the possibility of message looping.
The T1S1 standards committees are discussing geographic portability, which allows porting of numbers outside individual rate centers, although probably not across State boundaries. There is no mandate for this service, but some carriers may see it as a competitive advantage. However, given the increasing aversion to number portability in the wireless industry, it is unlikely that wireless carriers will rush to implement this capability even when it is standardized. In the distant future, however, it might be considered after LNP has been fully implemented by wireless carriers, and the incremental cost of portability over a larger region might be less than the competitive advantage that can be gained.
Calling Party Pays reverses the normal charging for mobile calls in North America. Currently, the mobile pays airtime charges for a call whether it originated the call, or is receiving it. CPP would make the originator pay for calls to mobiles, and mobiles would only pay for calls they originate. Local Number Portability drove a stake through the heart of existing CPP systems that rely on recognizable number blocks. Furthermore, a study group sponsored by the CTIA determined that terminating wireless carriers should be in control of the service, rather than the originating, often wireline, carrier. This requires relatively minor modifications to SS7 ISUP 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. A proposal for ISUP modifications is currently being developed.
SS7 will remain a critical component of wireless networks for many years to come. While this protocol has some significant limitations, it is evolving, and smart wireless carriers will use those as competitive advantages. Anybody who wants to fully understand the capabilities and limitations of wireless signaling networks needs a basic understanding of SS7 (as well as TIA/EIA-41 or GSM MAP).
I would like to thank Wesley Downum of Bellcore (chairman of T1S1.3), Jeff Copley of Alcatel USA (T1S1.3 SCCP convenor) and Stewart Patch of Bell Canada (T1S1.3 ISUP convenor) for their assistance with this article.
© – Copyright