(Page 1 of 1 in this chapter) Version

Chapter 2

Programming Model

2.1 Introduction
2.2 Signaling Point Types
2.3 MTP 3 Message Handling
2.3.1 Inbound Messages
2.3.2 Outbound Message Routing
2.3.3 Routing Masks
2.3.4 Congestion Priorities
2.4 Signaling Network Management
2.4.1 Changeover/Changeback
2.4.2 Forced/Controlled Rerouting
2.4.3 MTP Restart
2.4.4 Signaling Link Management
2.4.5 Signaling Link Test
2.4.6 Signaling Route Management
2.5 Operating System Specific Considerations
2.5.1 Receiving Confirmations and Indications
2.5.2 UnixWare and Solaris Systems
2.5.3 Windows NT
2.6 MTP Layer 3 Service Users
2.7 Entity and Instance IDs
2.8 API Primitives
2.9 Initialization and Binding
2.10 Data Transfer
2.11 Status Indications
2.12 Extended Status Indications
2.13 Flow Control

2.1 Introduction

The SS7 MTP layer 3 has two primary functions.

Message routing and distribution includes both the routing of outgoing messages to their specified destinations and the distribution of incoming messages to the appropriate user part or application. The SS7 MTP implementation uses a flexible configuration capability to support a wide variety of network routing and addressing requirements.

Signaling network management's job is to reconfigure the signaling network as needed to maintain signaling capability in the case of failures or congestion. This includes redirecting traffic away from failed links and/or signaling points (SPs), restoring traffic to restored links/SPs, and exchanging route status with adjacent SPs. The MTP 3 layer supports all required ANSI and ITU-T network management procedures without intervention from the user parts/applications. It does, however, notify user parts and applications of significant network events that might impact their operation, such as changes in the accessibility status of destination signaling points, the onset and abatement of congestion, and signaling point restarts.

The primary objects represented by MTP layer 3 are Network Service Access Points (NSAPs), signaling links, linksets, combined linksets, and routes.

Network service access points (NSAPs) define the SS7 user parts, or applications, that are users of the MTP service. Each NSAP is associated with one user part or application (as identified by the service indicator field of a message) and one protocol variant (ITU-T or ANSI). Figure 2 illustrates the concept of NSAPs.

Figure 2. Network Service Access Points (NSAPs)



If multiple protocol variants are configured on the same MTP 3 instance (same board) then two NSAPs are required for each user part: one for ANSI, one for ITU-T. In this case, a single user part/application may associate itself with both NSAPs for that service, or separate user part/applications may be used for each protocol variant.



Links define physical signaling links between the TX board and the adjacent signaling points. One link configuration must be performed for each physical signaling link. The attributes of a link include the point code of the adjacent signaling point, protocol variant employed on the link (ITU-T or ANSI), point code length, maximum packet length, various timer values, membership in a linkset (see below) and others. 



Linksets are groups of from one to 16 links that directly connect two signaling points. Although a linkset usually contains all parallel signaling links between 2 SPs, it is possible to define parallel linksets. Each signaling link defined is assigned membership in exactly one linkset.



A combined linkset is a group of all linksets that can be used to reach a particular destination or group of destinations (routes). Each linkset may be associated with up to 16 combined linksets. For each combined linkset that a linkset is a member of, it may be assigned a priority relative to other linksets belonging to that combined linkset.



Routes specify the destination signaling points (or subnetworks - e.g., clusters - when route masks are employed) that are accessible from the target node. Each route is assigned a direction - up or down. One up route is required for the actual point code assigned to the signaling point being configured and for each point code that is to be emulated. Up routes are used to identify incoming messages that are to be routed up to the applications/user parts. One down route is required for each remote signaling point/network/cluster that is to be accessible from the SP being configured. 



Down routes are used to route outgoing messages to the appropriate signaling links. Each down route is assigned to one combined linkset, which in turn identifies all linksets which may be used to reach that destination. Each linkset within the route's associated combined linkset may have an optional priority assigned, such that MTP routing will choose the highest priority available linkset when routing an outgoing packet to a particular destination. Any number of routes may be assigned to a combined linkset.



Figure  3 illustrates the relationship between links, linksets, combined linksets, and routes.





Figure 3.	 Links, Linksets, and Routes







2.2	 Signaling Point Types





The MTP 3 layer can be configured as either a signal transfer point (STP) or as a signaling endpoint, referred to simply as an SP. The primary difference between STP operation and SP operation is in the handling of messages received from signaling links by the MTP 3 layer but addressed to other destinations. 



When configured as an STP, MTP 3 searches for an outbound route to the message's destination and, if found, routes the message over an outbound link. When configured as an SP, the MTP 3 layer discards such messages.



When configured as an STP, the MTP 3 layer also performs the additional signaling route management procedures required of an STP. These primarily involve notifying adjacent SPs when they must no longer route messages to a particular destination through that STP due to failures or congestion (transfer prohibited/restricted), and notifying them again when normal communication with the concerned destination is restored (transfer allowed).






2.3	 MTP 3 Message Handling





The following subsections describe how the MTP 3 layer handles inbound messages, outbound messages, and routing masks, as well as the congestion priorities supported.






2.3.1	 Inbound Messages





When an inbound message is received, the MTP 3 layer searches its routing tables for a route that matches the destination point code in the message. If a matching UP route is found for the message, it is distributed to the appropriate user part/application based on the service indicator value in the incoming message and the link type (protocol variant) attribute of the link that the message was received on. This is illustrated in Figure  4. 


Note:  Only the link type of the incoming link and the service indicator portion of the SIO octet in the incoming message are used to choose the NSAP to receive the incoming message; the sub-service field of the SIO octet (i.e., national/international indicator and optional message priority) is not used.




Figure 4.	 Inbound Message Distribution




If a matching DOWN route is found for the message instead, the message is either routed as an outbound message (if the MTP 3 layer is configured as an STP) or the message is discarded. If no matching route is found, the message is always discarded.






2.3.2	 Outbound Message Routing





For outbound messages originated by local user parts/applications (or received messages being routed outbound when in STP mode), message routing is based on the destination point code and signaling link selection (SLS) field associated with the message. 



When an outbound message is ready for routing, the MTP 3 layer searches its routing tables for a route that matches the destination point code specified for the message. If a matching DOWN route is found for the message, message routing depends on the value specified for the SLS field, as follows:






2.3.3	 Routing Masks





The MTP 3 layer allows for the use of routing masks to help decrease the size of the routing tables that must be configured. Routing masks are bit masks that specify a subset of a destination point code to be matched against the routing table when searching for a route for either an inbound or outbound message. 



Routing masks may be used to implement network and cluster routing in ANSI networks. For example, consider the following network diagram (Figure  5). Rather than specifying explicit routes to each of the seven remote SPs, the following routing masks and routes can be used (note that all point codes and routing masks, regardless of point code length, are stored internally as 32 bit unsigned integers). 





 Routing Mask



 Comment




 0xFFFFFFFF



 Always specify exact match as first mask.




 0xFFFF00



 Match on network ID + cluster ID next.




 0xFF0000



 Match on just network ID last.















 





 Routes 



 Comment




 1.1.100, UP



 Always specify an UP route to self.




 1.1.1, DOWN, Linkset 1



 Explicit route to STP for network 1, cluster 1.




 1.1.0, DOWN, Linkset 1



 Cluster route to network 1, cluster 1.




 1.2.1, DOWN, Linkset 2



 Explicit route to STP for network 1, cluster 2.




 1.2.0, DOWN, Linkset 2



 Cluster route to network 1, cluster 2.




 2.1.1, DOWN, Linkset 3



 Explicit route to STP for network 2.




 2.0.0, DOWN, Linkset 3



 Network route to network 2.
















Note:  Routing masks are global to all links, linksets, and user parts, and are applied to both incoming and outgoing messages. Although the previous example is specific to ANSI networks, routing masks can be applied equally to other networks (ITU-T based networks with 14- or 24-bit point codes) to reduce the size of routing tables.




Figure 5.	 Network/Cluster Routing






2.3.4	 Congestion Priorities





The MTP 3 layer supports four congestion priorities (numbered 0 - 3) for both incoming and outgoing messages. Congestion level zero is the least severe level of congestion and level 3 is the most severe level. Each link and each NSAP has associated with it the following attributes:




Whenever the number of messages queued to a link/NSAP exceeds congestion threshold n (where 0 £ n £ 3), the current congestion level is set to n. When a subsequent message is to be queued to that link/NSAP, the priority of the message is compared to the current congestion level and the discard priority of the link/NSAP. If the priority of the message is less than the current congestion level AND the discard priority assigned to the link/NSAP, the message is discarded; otherwise the message is queued, potentially escalating the current congestion level of the target link/NSAP. If the message is an outbound message and the node is configured as an STP, or if the message is an inbound message, the message priority is also compared with the current congestion level of the link/NSAP. If the message priority is less than the current congestion level, the originator of the message may be notified with a transfer controlled message.



As the number of messages queued to a link/NSAP decreases, the MTP 3 layer checks for congestion level abatement. In order for the congestion level of a link/NSAP to drop from level n to level n-1, the size of the queue must drop below the abatement threshold for level n. The congestion abatement levels are defined below their corresponding congestion onset levels to prevent continuous toggling between congestion levels during recovery from congestion.


Note:  The NSAP congestion thresholds are only in effect if the user part has requested flow control.





2.4	 Signaling Network Management





Signaling network management provides the functions necessary to maintain signaling service during failures and congestion and restore normal signaling service after recovery from these conditions. The MTP 3 layer supports all required ANSI and ITU-T network management procedures without intervention from the user parts/applications. It does, however, notify user parts and applications of significant network events that might impact their operation, such as changes in the accessibility status of remote signaling points, the onset and abatement of congestion, and signaling point restarts.






2.4.1	 Changeover/Changeback





The MTP 3 layer automatically initiates changeover procedures whenever a link fails, is deactivated, is remotely blocked, or is inhibited. No user part/application action is required nor is the user part/application notified when the changeover occurs.



Likewise, when a signaling link is restored, unblocked, or uninhibited, the MTP 3 layer automatically performs the changeback function, again without interaction with the user parts/applications.






2.4.2	 Forced/Controlled Rerouting





The MTP 3 layer also handles forced and controlled rerouting upon receipt of the transfer prohibited and transfer allowed/transfer restricted messages. On receipt of a transfer prohibited message (TFP), the MTP 3 layer attempts to redirect all traffic for the prohibited destination to an alternate route. If no alternate routes are available, the destination is declared inaccessible and each user part/application is notified with a StatPaused status indication for the concerned destination. Note that destinations may also be declared inaccessible for other reasons, such as signaling link or signaling point failures, which result in similar StatPaused status indications to the user parts.



Traffic routing over an unavailable or restricted route is automatically restored upon receipt of the transfer allowed (TFA) or transfer restricted (TFR) message for that route. If the TFA/TFR causes a previously inaccessible destination to become accessible, each user part is notified with a StatResumed status indication for that destination. 






2.4.3	 MTP Restart





The MTP 3 layer may be configured with or without the MTP restart capability. The MTP restart function allows a signaling point just becoming available (such as after a failure) to bring up sufficient links to handle the expected traffic load before receiving new traffic. 



If configured to do so, the MTP 3 layer will perform the restart function whenever the first signaling link becomes active (such as at system startup or after a total failure affecting all links), or on command from a management primitive. At the beginning of an MTP restart, each user part/application is notified with a StatRestart status indication. User parts should not generate new traffic requests during the restart. When the restart is complete and the MTP 3 layer is ready for traffic, each user part/application receives a StatRestartEnds status indication. 






2.4.4	 Signaling Link Management





The MTP 3 layer provides the basic link management functions and, optionally, the signaling link management procedures based on automatic allocation of signaling terminals described in the ANSI and ITU-T MTP standards.



Each link set has a minNmbActLnk attribute which determines the normal number of active links in the linkset. Typically this number will include all links in the linkset, but it is possible to configure extra alternate links that are activated only in the presence of failures of other links.



Whenever a linkset is activated (such as at system startup time), the MTP 3 layer will attempt to activate the minNmbActLnk highest priority links in that linkset. If a link fails, or cannot be aligned successfully, the MTP layer will periodically attempt to restore the link until successful or until the link is manually disabled via a management primitive.



If the current number of active links in a linkset drops below the minNmbActLnk threshold, the MTP 3 layer will attempt to activate the highest priority inactive link that is not currently inhibited, remotely blocked, or manually disabled. If no other links in the linkset meet this criteria, the MTP 3 layer will attempt to uninhibit the highest priority inhibited link in the linkset, if any.



If the current number of active links in a linkset goes above the minNmbActLnk threshold due to a link restoration, the MTP 3 layer will attempt to deactivate the lowest priority active link to return the number of active links in the linkset to its normal condition.



This automatic activation/deactivation of links is normally performed without interaction with the user parts/applications, unless it results in one or more destinations becoming accessible/inaccessible, in which case the user parts are notified with a StatResumed or StatPaused status indication, as described earlier.



If no automatic activation/deactivation of links is desired, then minNmbActLnk threshold can be set to the actual number of links in the linkset (or greater).






2.4.5	 Signaling Link Test





The MTP 3 layer requires a successful signaling link test (SLTM generated and SLTA response expected) as part of link activation before considering a signaling link active. Thereafter the signaling link test is performed periodically on each active signaling link, at a configurable period (link timer T34 - corresponds to ANSI T1.111.7/ITU-T Q.707 timer T2). Signaling link testing is performed with no user part/application interaction.






2.4.6	 Signaling Route Management





When configured as an STP, the MTP 3 layer implements the signaling route management procedures - transfer prohibited, transfer allowed, transfer restricted, signaling route set test, and signaling route set congestion test - described in the ANSI and ITU-T MTP standards. These procedures are performed without interaction with the user parts/applications.






2.5	 Operating System Specific Considerations





The following subsections address specific concerns depending on which operating system the MTP 3 software is run.






2.5.1	 Receiving Confirmations and Indications





Applications receive indications of received data or status changes by periodically calling the MTP3RetrieveMessage primitive. This primitive checks for an incoming message and returns an indication of whether or not a message is available. When an incoming message is available, MTP3RetrieveMessage copies the message to the buffer provided by the caller, performs any necessary byte-order translation between network byte order and host byte order, and fills in the length. The application must periodically call this primitive to receive messages from the MTP 3 layer.



To allow applications more flexibility in handling multiple devices, the MTP 3 API makes the device file descriptor (or handle) used to access the TX board available to the application (see the MTP3SyncObj routine description). Use of this file descriptor is operating system dependent, but is generally intended to allow the application to utilize operating system facilities to determine when a message from the MTP 3 layer is available rather than periodically calling MTP3RetrieveMessage to "poll" the TX driver.






2.5.2	 UnixWare and Solaris Systems





The MTP 3 API makes the device file descriptor (or handle) used to access the TX board device driver available to the application via the MTP3SyncObj primitive. On UnixWare and Solaris systems, this is a file descriptor for an open streams device. 



The application may use this file descriptor with the poll or select system calls to determine when a message from the MTP 3 layer is available. Once poll or select has indicated that a pending I/O operation has completed on the MTP 3 API file descriptor, the application should then call MTP3RetrieveMessage to read and decode the message.






2.5.3	 Windows NT





On Windows NT systems, an application can obtain a handle (via the MTP3SyncObj primitive) which can be used with the WIN32 WaitForSingleObject or WaitForMultipleObjects system calls to efficiently perform asynchronous, or non-blocking, I/O. This allows an application to determine when a message from a single TX board or from any TX board in a multiple board installation is available without having to periodically call MTP3RetrieveMessage to "poll" each TX device. 



To access this "synchronization handle" the application performs the following steps:


    


  1. After calling MTP3Bind, the application calls MTP3SyncObj, passing the board number from the call to MTP3Bind, to obtain the synchronization handle.
    

    

  2. The application uses the synchronization handle with WaitForSingleObject or WaitForMultipleObjects to check or wait for a message. 
    

    

  3. When WaitForSingleObject or WaitForMultipleObjects indicates an event completion on the corresponding TX synchronization handle, the application then calls MTP3RetrieveMessage (passing the original handle from MTP3Bind, not the synchronization handle) to retrieve and decode the packet.
    







2.6	 MTP Layer 3 Service Users





The MTP Layer 3 data application interface supports one or more user applications by way of Service Access Points, or SAPs. One SAP is defined for each application that may use the MTP layer 3 service. A user application binds to a particular SAP at initialization time, specifying the SAP ID that it wishes to bind to. Each SAP is associated with a Service Information Octet (SIO) value, which in turn identifies the upper layer protocol in use on that SAP (for example ISUP, TUP, SCCP). Therefore, there may be at most one application process handling incoming messages for a particular upper layer protocol (i.e., at most one process receiving incoming ISUP messages).



The number of SAPs (MTP Layer 3 users - MAX_USERS) and the characteristics of each SAP are specified in the MTP 3 configuration file. See Mtp3InitNSapCfg and the Signaling System 7 (SS7) Installation and Configuration Manual for details.






2.7	 Entity and Instance IDs





Each user application must also have a unique entity and instance number, which is used to route messages among the various processes in the system. Entity IDs are single byte values in the range 0x00-0xFF, assigned as desired by the application developer. Entity IDs are reserved as follows: 





 ------



 0x00-0x13



 Reserved




 ISUP



 0x14



 ISDN User Part Protocol Handler




 MTP 3



 0x15



 Message Transfer Part Layer 3




 MTP 2



 0x16



 Message Transfer Part Layer 2




 TCAP



 0x17



 TCAP Protocol Handler




 ------



 0x18 - 0x1B



 Reserved




 MTP 1



 0x1C



 Message Transfer Part Layer 1




 TUP



 0x1D



 Telephone User Part




 SCCP



 0x1E



 SCCP Protocol Handler




 ------



 0x1F



 Reserved




 ------



 0x20 - 0x3F



 Available for applications
















Instance IDs identify the processor that the entity executes on. The host is always processor 0 (zero), so for all host-resident MTP 3 user applications this value should be coded to zero. All tasks on TX board number 1 receive an instance ID of 1, all tasks on TX board number 2 receive an instance ID of 2, and so on.






2.8	 API Primitives





The MTP Layer 3 data API consists of the following primitives: 





 Primitive



 Direction



 Description




 Bind Request



 Application -> MTP 3



 Establishes the application as the user of the SAP and registers for a particular SIO value. Performs initialization the first time called.




 Bind Confirm



 MTP 3 -> Application



 Confirms a previous bind request.




 Unbind Request



 Application -> MTP 3



 Deregisters the application as a user of the SAP and performs cleanup.




 Data Request



 Application -> MTP 3



 Requests MTP 3 to transfer a data packet




 Extended Status Request



 Application -> MTP 3



 Registers/Deregisters the application to receive extended status indications.




 Data Indication



 MTP 3 -> Application



 Notifies the application of an incoming data packet




 Status Indication



 MTP 3 -> Application



 Notifies the application of change in status of SS7 network




 Extended Status Indication



 MTP 3 -> Application



 Notifies the application of a change in the status of MTP layer components




 Flow Request



 Application -> MTP 3



 Requests MTP 3 to start or stop flow control on a network SAP.



















2.9	 Initialization and Binding





Before calling any other API primitives, the application must first call the MTP3Bind primitive to establish the application as a user of MTP 3, specifying a particular SAP. In addition, the first time MTP3Bind is called it opens the TX driver and allocates/initializes other resources needed by the API. When an application has completed communication with the MTP 3 task, it should unbind to free up resources for other applications.



If an application attempts to bind to a SAP for which an application was previously bound, the older binding is removed and the new binding is established.






2.10	 Data Transfer





MTP 3 is a connectionless protocol. Therefore, once an application has bound to the MTP 3 layer, it may begin sending data. This is accomplished via the MTP3SendData primitive. This call may succeed or fail immediately. If the call succeeds there may be a future status indication denoting that the message could not be delivered. Refer to Section  2.11, Status Indications, for more information. There is no future indication that the message was transferred successfully.





Figure 6.	 Sending data




Asynchronous notification and polling are two methods for an application to receive incoming data and/or status indications. Status indications are covered in the next section but the following information applies to both data and status indications.



Asynchronous notification uses the MTP3SyncObj primitive and operating system specific mechanisms to notify an application when, and only when, a message is available. Refer to Section  2.5, Operating System Specific Considerations and MTP3SyncObj for more information. This method is preferable because it does not incur the overhead of repeated polling. When the application receives notification that data is available, it should call MTP3RetrieveMessage to obtain the received message.



Polling requires the application to continually check for incoming messages by periodically calling MTP3RetrieveMessage. The application must make sure to call this function regularly to avoid excessive queuing of messages in the TX driver or the MTP 3 layer task. MTP3RetrieveMessage will return MTP3_NO_MSG until a message is available. It will return MTP3_SUCCESS when a message is available.



The following diagram shows the asynchronous notification method of receiving data:





Figure 7.	 Receiving Data (async notification)






2.11	 Status Indications





Status indications may be received by an application through one of the receiving mechanisms described in the previous section. A status indication is sent to all applications when the corresponding network status changes. The possible status indications are described in the following table: 





 Status Indication



 Description




 StatPaused 



 Indicates that delivery to the specified destination point code is not currently possible. It can mean that there is no route configured for the destination point code or that all routes to that point code are currently unavailable. The StatPaused indication does not specify which of the above was the case.




 StatResumed



 Occurs after a StatPaused indication if one or more routes to a particular destination point code become available.




 StatCongested



 Indicates that delivery to the destination SP failed due to network congestion at some point along the route. This implies that the user part/application should reduce traffic to that destination.




 StatCongestionEnds



 Occurs after a StatCongested indication when network congestion has abated.




 StatUsrUnavail



 Indicates that the message was delivered to the remote MTP 3 layer but that no application was registered to receive data with the service information octet (SIO) contained in the message. For example, data was sent with an SIO indicating an ISUP message, but there was no ISUP application running at the destination. The remote MTP 3 layer has discarded the message.




 StatRestart



 Indicates that the local MTP 3 layer is going through a restart. This will be followed at some point by a StatRestartEnds. The application should not send any data messages after receiving this indication.




 StatRestartEnds



 Indicates that the local MTP 3 layer has completed its restart. The application may resume sending data messages.




 StatPrimary



 Indicates the local MTP 3 is the primary in a redundant configuration.




 StatBackup



 Indicates the local MTP 3 is the backup in a redundant configuration.




 StatStandAlone



 Indicates MTP is not in a redundant configuration.



















2.12	 Extended Status Indications





Extended status indications may be received by an application through one of the receiving mechanisms described in Section  2.10, Data Transfer. An extended status indication is sent to all applications registered to receive extended status indications when certain components of the MTP layer change state. Currently, MTP 2 links are the only components that support this feature. The possible extended status indications are described in the following table: 





 Ext. Status Indication



 Description




 XStatLinkUp



 Indicates a link has finished aligning and is now available to the MTP 3 layer. This means traffic can now be carried over the available link.




 XStatLinkDown



 Indicates a link has gone out of service. The MTP 3 layer will now use other links, if available, to carry traffic.




 XStatLinkInh



 Indicates a link has become inhibited. Links become inhibited by management requests. The network (MTP layer) will never inhibit a link by itself, although it may uninhibit the link. An inhibited link is no longer used by the MTP 3 layer to carry traffic.




 XStatLinkInhDen



 Indicates an MTP 3 management entity attempted to inhibit a link, but the inhibition was denied. A possible cause would be that inhibiting the link would cause a destination to become inaccessible.




 XStatLinkUninh



 Indicates that a link has become uninhibited and is now available to the MTP 3 layer for carrying traffic. Links may be uninhibited by MTP 3 management entities or by the MTP 3 layer automatically.




 XStatLinkUninhDen



 Indicates the uninhibition of a link has been denied. This usually happens when the local MTP 3 layer is not able to negotiate the uninhibition of the link with the remote MTP layer. The link is still unavailable to the MTP 3 layer to carry traffic.




 XStatLinkRemBlock



 Indicates a link has become remotely blocked. This is a result of a processor outage on the remote side of the link. The link is no longer available to carry traffic.




 XStatLinkRemUnblock



 Indicates the link is no longer remotely blocked. The link is now available to carry traffic unless inhibited or locally blocked.




 XStatLinkLocBlock



 Indicates a link has become locally blocked. This is a result of a local processor outage. The link is no longer available to carry traffic.




 XStatLinkLocUnblock



 Indicates the link is no longer locally blocked. The link is now available to carry traffic unless inhibited or remotely blocked.



















2.13	 Flow Control





An application that cannot keep up with incoming messages may use flow control to force queuing of messages in the lower layers until it can again accept incoming data. The use of the MTP3Flow primitive is used as shown in the following diagram:





Figure 8.	 Flow control




When flow control is in effect, the congestion priorities become active, as described in Section  2.3.4, Congestion Priorities.











 
    (Page 1 of 1 in this chapter)  Version




 




tech_support@nmss.com



Copyright © 2000, Natural MicroSystems, Inc.   All rights
reserved.