1 / 15

System Design of MTP Level 2 for Next Generation Hardware

System Design of MTP Level 2 for Next Generation Hardware. Author: Pasi Huuppola Supervisor: Professor Raimo Kantola Instructor: M.Sc. Juha Pajuvirta. Contents. Objective and Methodology Introduction to SS7 ATCA Hardware Hardware Board Software Requirements Software Design

gail-lane
Download Presentation

System Design of MTP Level 2 for Next Generation Hardware

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. System Design of MTP Level 2 for Next Generation Hardware Author: Pasi Huuppola Supervisor: Professor Raimo Kantola Instructor: M.Sc. Juha Pajuvirta

  2. Contents • Objective and Methodology • Introduction to SS7 • ATCA Hardware • Hardware Board • Software Requirements • Software Design • Analysis and Testing • Conclusions

  3. Objectives and Methodology • Objective: • To create a software system design of message transfer part (MTP) level 2 for Advanced Telecommunication Computing Architecture (ATCA) based hardware. • The basis for the design is the old software design for IPA2800 hardware. The old design cannot be applied as such due to new hardware platform and operating system change from ChorusOS to Linux. • Methodology: • Literature study of ITU-T Recommendations, basically Q.700-Q.704. • Studying the current design architecture. • Looking into a source code of the current implementation. • Study the real time characteristics of Linux operating system and find the most suitable way for MTP level 2 perspective to utilize them. • Thesis was carried out in Nokia Networks during year 2006 and 2007.

  4. Introduction to SS7 (1/3) TCuser (application entity) MAP (mobile), INAP (IN) OMAP (operation&maintenance) CALL CONTROL • Signalling system nro 7 (SS7) is internationally standardized general-purpose common channel signalling system. • SS7 is a layered architecture which consists of four levels that are Message Transfer Parts (levels 1-3), Signalling Connection and Control Part and User Parts (levels 4). BSSAP, RANAP etc.. ISUP, TUP TCAP Non-circuit related communications Component handling, Dialogue handling SCCP Virtual Connection (Conn.oriented) Connectionless (non-call related communication, Global Title GT) Subsystem availability MTP level 3, Signaling Network Message handling (routing, load sharing) Network Management (network failure handling, congestion) MTP level 2, Signaling Link Message structure and framing, error control MTP level 1, Signaling Data Link Interface, Physical Path

  5. Introduction to SS7 (2/3) Signalling Point (SP) (DPC=destination point code) Signalling Point (SP) (OPC=originating point code) Signalling Link Set (1-16 links) Signalling Link Speech Channels Signalling Route Set (1-8 linksets) Signalling Link 64kbit/s (56kbit/s, 48kbit/s) or n*64 kbit/s (n=1-31) Short Message Service Center (SMSC)

  6. Introduction to SS7 (3/3) • SS7 transfers signalling data in three types of signal units: Fill-In Signal Units (FISU), Link Status Signal Units (LSSU) and Message Signal units (MSU). • FISUs are sent when a signalling link is an idle state. • LSSUs are used to sent link status information. • MSUs are used to sent the actual signalling data from User Parts. F CK SIF SIO LI F I B FSN B I B BSN F First bit transmitted 8 16 8n, n>2 8 2 6 1 7 1 7 8 F – Flag FIB – Forward Indicator Bit CK – Check Bits FSN – Forward Sequence Number SIF – Signalling Information Field BIB – Backward Indicator Bit SIO – Signalling Information Octet BSN – Backward Sequence Number LI – Length Indicator

  7. ATCA Hardware • Advanced Telecommunications Computing Architecture (specified by PICMG) • Standardised modular platform architecture for a large number of telecommunication equipment. • Specifies shelves, boards, mezzanines, rear transition modules etc. • Benefits of ATCA hardware are faster time-to-market and lower development costs.

  8. Hardware Board • The base of the MTP level 2 design is ATCA based Advanced Mezzanine Card (AMC). It has Motorola's PowerQUICC III (MPC 8560) processor and four distinct interfaces for communication purposes. • Used interfaces consist of three Ethernet interfaces (one base interface and two fabric interfaces) and one PCI-Express interface. • Special FPGA is used to map TDM traffic to Ethernet frames using Nokia’s proprietary Flow Level Internal Protocol (FLIP). • Capacity is 128 distinct TDM channels in SS7 signalling use. • Operating system is WindRiver Linux.

  9. Software Requirements • The software design of MTP level 2 comply with ITU-T Recommendation Q.703 including Annex A. • Functional Requirements of the MTP level 2 software are the following: • signal unit delimitation • signal unit alignment • error detection • error correction • initial alignment • signalling link error monitoring • flow control • Interface to MTP level 3 is handled with Nokia’s proprietary DMX-messages. • Interface to device driver is handled using function calls and interface to FPGA is handled via IOCTL interface. • Software shall support 128 distinct signalling channels up to 8 Mbit/s total capacity. Any combination of k x (N x 64 kbit/s) channels can be used, where k=1-4 and N=1-32.

  10. Software Design (1/2) • MTP level 2 software will be divided between kernel space and user space. It contains an user space application to handle communication to MTP level 3 and a kernel space module to implement the actual functionality of MTP level 2. • Design contains a four functional units: • DMX receiver unit: Receives DMX messages from MTP level 3. • DMX sender unit: Sends DMX messages to MTP level 3. • Main unit: Initialises user space application. • MTP level 2 control unit: Implements the operations of MTP level 2.

  11. Software Design (2/2) • User space units are implemented as POSIX threads and the kernel level unit as a kernel module. • Communication between the kernel space module and user space threads are handled using socket interface. In addition, a specific header will be used to distinguish different types of data to be sent. • Communication between the MTP level 2 kernel module and the device driver is handled with functions that are defined in a specific structure. Device driver registers its functions to the structure at a loading time. The design defines also an another structure which includes callback functions for interrupt indications and it is read only by the device driver. • Data passing between device driver and the MTP level 2 kernel module is handled using socket buffers. This makes it easy to use kernel defined networking interface if necessary.

  12. Analysis and Testing • Analysis: • The system design of MTP level 2 tries to be as generic as possible so that the MTP level 2 software would not be dependent on the underlying hardware. • The most important reason for dividing the software between user space and kernel space is the strict real time characteristics that MTP level 2 software has. • There are some open questions regarding the copying between user space and kernel space. • Testing: • First tests that have to be performed are performance tests and capacity tests. The former tests the low level performance of MTP level 2 software and the latter tests that the capacity requirements are met. • There are two types of tests defined by ITU-T. These are validation tests and compatibility tests. Validation tests aims to verify the proper functioning according to specific recommendation (basically Q.703) whereas compatibility tests aims to verify the interworking of two or more protocols. • These tests are carried out as soon as the actual hardware will be ready.

  13. Future Development • There is a lot of work to do, especially related to the implementation and testing of the current design, before the actual future development needs are coming to relevant issues. • One thing to study is the possibility to release the software as GPL to the Linux community. This would bring a new perspective to the implementation and maybe also some suggestions for improvements. • Another thing to study is the possibility to utilize the same design in different types of signalling methods, for example, in SS7 over IP (SIGTRAN) usage.

  14. Conclusion • Using of ATCA hardware brings a lot of new challenges, for example, new operating system and new internal communication methods. • The most demanding phase was to find out how the currently used implementation could be ported on the top of the Linux operating system. • The current driver interface design between MTP level 2 software and device driver makes it possible to replace the device driver with only minor modifications to the driver itself. • Although the overall design process is completed, the open questions related to the copying remains unanswered. However, as soon as the actual hardware will be available, these open questions are studied and a proper action will be taken if necessary.

  15. Thank You!Questions/Comments?

More Related