1. What is SS7? Common Channel Signaling System No. 7 (i.e.

, SS7 or C7) is a global standard for telecommunications defined by the International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T). The standard defines the procedures and protocol by which network elements in the public switched telephone network (PSTN) exchange information over a digital signaling network to effect wireless (cellular) and wireline call setup, routing and control. 2. What standards does the SS7 stack confirm to ? The HSS SS7 stack allows for national variants such as the American National Standards Institute (ANSI) and Bell Communications Research (Bellcore) standards used in North America and the European Telecommunications Standards Institute (ETSI) standard used in Europe. Spanish and British Variants are also supported

3. What can the SS7 network and protocol be used for? The SS7 network and protocol can be used for:

basic call setup, management, and tear down wireless services such as personal communications services (PCS), wireless roaming, and mobile subscriber authentication local number portability (LNP) toll-free (800/888) and toll (900) wireline services enhanced call features such as call forwarding, calling party name/number display, and threeway calling efficient and secure worldwide telecommunications

4. What does the SS7 signaling architecture look like ? SS7 messages are exchanged between network elements over 56 or 64 kilobit per second (kbps) bidirectional channels called signaling links. Signaling occurs out-of-band on dedicated channels rather than in-band on voice channels. The Network consist of three types of Network Elements

SSP: Signal Switching Points are telephone exchanges equipped with SS7 capable software. They are responsible for originating, terminating or switching calls STP: Signal Transfer Points are packet switches that receive and route signaling messages to their proper destination SCP: Signaling Control Point is a database that provides information necessary for advanced callprocessing capabilities

5. What are the layers in a SS7 stack? The SS7 protocol stack has the following underlying layers Message Transfer Part The Message Transfer Part (MTP) is divided into three levels. The lowest level, MTP Level 1, is equivalent to the OSI Physical Layer. MTP Level 1 defines the physical, electrical, and functional characteristics of the digital signaling link. Physical interfaces defined include E-1 (2048 kb/s; 32 64 kb/s channels), DS-1 (1544 kb/s; 24 64kb/s channels), V.35 (64 kb/s), DS-0 (64 kb/s), and DS-0A (56 kb/s). MTP Level 2 ensures accurate end-to-end transmission of a message across a signaling link. Level 2 implements flow control, message sequence validation, and error checking. When an error occurs on a signaling link, the message (or set of messages) is retransmitted. MTP Level 2 is equivalent to the OSI Data Link Layer. MTP Level 3 provides message routing between signaling points in the SS7 network. MTP Level 3 reroutes traffic away from failed links and signaling points and controls traffic when congestion occurs. MTP Level 3 is equivalent to the OSI Network Layer. ISDN User Part (ISUP) The ISDN User Part (ISUP) defines the protocol used to set-up, manage, and release trunk circuits that carry voice and data between terminating line exchanges (e.g., between a calling party and a called party). ISUP is used for both ISDN and non-ISDN calls. However, calls that originate and terminate at the same switch do not use ISUP signaling. Telephone User Part (TUP) In some parts of the world (e.g., China, Brazil), the Telephone User Part (TUP) is used to support basic call setup and tear-down. TUP handles analog circuits only. In many countries, ISUP has replaced TUP for call management. Signaling Connection Control Part (SCCP) SCCP provides connectionless and connection-oriented network services and global title translation (GTT) capabilities above MTP Level 3. SCCP is used as the transport layer for TCAP-based services.

Transaction Capabilities Applications Part (TCAP) TCAP supports the exchange of non-circuit related data between applications across the SS7 network using the SCCP connectionless service. Queries and responses sent between SSPs and SCPs are carried in TCAP messages. For example, an SSP sends a TCAP query to determine the routing number associated with a dialed 800/888 number and to to check the personal identification number (PIN) of a calling card user. In mobile networks (IS-41 and GSM), TCAP carries Mobile Application Part (MAP) messages sent between mobile switches and databases to support user authentication, equipment identification, and roaming.

6. What is Global title translation? A global title is an address (e.g., a dialed 800 number, calling card number, or mobile subscriber identification number) which is translated by SCCP into a destination point code and subsystem number. A subsystem number uniquely identifies an application at the destination signaling point. 7. What is meant by the statement - "SS7 Stack can work in both single-threaded and multi-threaded systems"? The SS7 Stack entities (MTP2, MTP3, ISUP SCCP& TCAP) can be compiled and run as a single thread. This is possible because of the coding guidelines which ensure uniqueness of function names and global variables.

In addition, each SS7 Stack Entity can execute as a separate thread. This is possible because each stack entity is independent and does not share any data structures with other stack entities. Communication between two stack entities is through a message based interface. 8. What does porting the stack onto a system involve? Porting the stack onto a system involves the following :

Porting the OS calls Porting error handler & printing of trace messages Porting System Management Entity Porting redundancy

Porting the OS calls is dependent on the Operating System & involves :

Memory management Timer management IPC mechanism between stack entities / stack entity & service user

Porting error handler is dependent on the Users System & is based on how the errors are to be reported. Porting the printing is dependent on the Users System & is based on how / where the trace messages are to be displayed. Porting System Management Entity involves developing an User Interface (GUI / other) for managing the stack entities using the Layer Management APIs (Provisioning, Statistics, Controlling Error Reporting and Traces etc.). SS7 stack can be ported unto any customer platform

9. What can I configure using the Layer Management Entity Interface ? Given below are some examples of parameters configurable from LME Linksets configuration Link configuration Route configuration Timer configuration Trace Levels E1/T1 card configuration Congestion levels Other parameters e.g. Call Control configuration parameters, CICs provisioning / unprovisioning etc can be included as per the customer's requirements

10. What is the functionality of the client code? The client codes parses all the APIs coming to the stack. It forms an interface between the stack and the user / service layer.

11. How does MTP2 handle multiple links? MTP2 has a well-defined interface (in the form of functional calls) with the hardware, which is to be ported. This is explained in detail, in the MTP2 Porting Guide. The multiple SS7 links are handled by the hardware in any fashion (polling in round robin or any other manner/ interrupt driven) MTP2 places no restriction on this. MTP2hardware interface consists of a set of functions, which are invoked by the hardware as needed:

Whenever the hardware is ready to transmit, it will invoke a well-defined MTP2 function. Whenever the hardware has received a signaling unit, it will invoke another MTP2 function.

12. Can multiple instances of the same stack entity run on one processor? This depends upon the operating system. In OS like Solaris, Windows NT etc., where each instance / execution of the stack entity has its own data area, this is possible. In RTOS like VxWorks etc., the global variables are mapped to a fixed location in memory (flat memory structure). Hence, multiple instances of the stack entity access the same data area for globals, leading to clash.

13. What compiler do we use for SS7? The SS7 development environment is Solaris, with GNU C (gcc) compiler. We also compile our source code using the following compilers, before a release :

Microtek MCC68K compiler Borland C compiler

If a customer is planning to use a different compiler than the above, the source code can be compiled using that compiler before the release.

14. Is any global data referenced by the stack entity? What are the implications ?

The database and a few other variables maintained by each stack entity are defined as global definitions. This has no implication in OS like Unix, which do not share memory across tasks. However, in case of RTOS (like Vxworks, PSOS) which have a flat memory space, there is only one copy of this data irrespective of number of tasks or processes started. e.g. if two instances of ISUP are running on the same board they will be referring to the same copy of data. This will be fixed in future releases of stack the solution will be as decided in the Protocol Development framework, which would be one of the following :

Keep global database indexed by the instance number of the module. Define the database as local to the stack entity and pass the reference to it with each call of stack and down to all levels. All the database references will be done with respect to this reference.

15. Do you require virtual memory ? There is no assumption in the stack with respect to type of memory - it can be virtual or physical. But as explained in previous question, there is a problem when multiple instances of a stack entity are executing and accessing the same copy of data in case of flat memory systems. So if we assume that virtual memory models will keep the stack global space along with the stack task(process) context, we can support multiple instances of each entity on the same board. 16. On a 64bit Processor, do checksums and CRCs calculation in the stack get impacted ? All the checksums calculated in SS7 (i.e. CRC in MTP2) are 16-bit CRC. They will not be affected by a 64bit processor. All the stack entities operates on following basic types :

U8bit U16bit U32bit S8bit S16bit S32bit

(where U is for unsigned and S for Signed) These definitions are defined in a header file & can be changed if needed. 17. Is any system requirement functionality assumed from an external DB? Database maintained by each stack entity is local to it and has got no external dependency. The database maintained by each entity has got a static part (which is initialized by provisioning) and a dynamic part (which is updat5ed at run-time by the stack entity).

The interface of each stack entity with its database module is a well defined functional interface (read/write/access/modify). If there is a need to use an external database, this functional interface has to be ported. 18. What is the performance requirements that the HSS SS7stack has been designed to meet?

The protocol stack (and each constituent entity) will be so designed so as to allow porting on the target platform with minimal real-time overload on the clients thread of control (calling application). This implies that whenever possible, the stack code should be executed in the stacks thread of control. Keeping in mind the strong time and memory constraints in telecom systems, the stack design and code will be developed for maximum time and memory efficiency. Wherever messages need to be exchanged across entities, stack architecture will be so designed so as to minimize the bandwidth requirement.

19. How is error handling implemented? All errors are indicated through an uniform interface. Handling of errors is the responsibility of the system management entity. All possible errors that might occur in processing (including SS7 protocol procedural errors) is numbered and globally defined. All the SS7 protocol processing entity modules maintain a global error flag (global to a module) which reflects last error encountered in the processing.

20. What is the functionality of the System Management Entity? The SS7 stack includes a primitive System Management entity. The functionality of system management entity consists of the following: 1. 2. 3. 4. Provisioning, initialization and maintenance of SS7 stack entities. Debug and trace management of SS7 stack entities. Solicited and periodic statistics collection/reporting. Redundancy management of SS7 stack entities.

21. What is meant by 'Redundancy Management' Redundancy management if implemented shall mean the following
o o o o o

SS7 stack shall have two operating states ONLINE and STANDBY. An interface shall be provided for redundancy data updation. A mechanism shall be provided to indicate to the system management entity for triggering the redundancy data updation to all the redundant components. System management entity shall have the control for changing the state of the SS7 stack. Compile time flag to control the inclusion/exclusion of redundancy features shall be provided.