System Design of MTP Level
2 for Next Generation
Hardware
Author:
Pasi Huuppola
Supervisor:
Professor Raimo Kantola
Instructor:
M.Sc. Juha Pajuvirta
© NOKIA
1
pasi.huuppola@nokia.com
11.01.2007
Contents
•
Objective and Methodology
•
Introduction to SS7
•
ATCA Hardware
•
Hardware Board
•
Software Requirements
•
Software Design
•
Analysis and Testing
•
Conclusions
© NOKIA
2
pasi.huuppola@nokia.com
11.01.2007
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.
© NOKIA
3
pasi.huuppola@nokia.com
11.01.2007
Introduction to SS7 (1/3)
•
•
Signalling system nro 7
(SS7) is internationally
standardized generalpurpose common
channel signalling
system.
SS7 is a layered
architecture which
consists of four levels
that are Message
Transfer Parts (levels 13), Signalling
Connection and Control
Part and User Parts
(levels 4).
TC user (application entity)
MAP (mobile), INAP (IN)
OMAP (operation&maintenance)
TCAP
Non-circuit related communications
Component handling, Dialogue handling
CALL CONTROL
BSSAP,
RANAP
etc..
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
© NOKIA
4
ISUP,
TUP
pasi.huuppola@nokia.com
11.01.2007
Introduction to SS7 (2/3)
Signalling Point
(SP)
(OPC=originating
point code)
Signalling Link Set (1-16 links)
Signalling Link
Signalling Route Set
(1-8 linksets)
Signalling Link
64kbit/s (56kbit/s, 48kbit/s)
or n*64 kbit/s (n=1-31)
© NOKIA
5
Signalling Point
(SP)
(DPC=destination
point code)
pasi.huuppola@nokia.com
Speech Channels
Short Message Service
Center (SMSC)
11.01.2007
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
8
16
SIF
8n, n>2
SIO
8
2
LI
F
B
I FSN I BSN
B
B
6
1
7
1
7
F
8
First bit
transmitted
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
© NOKIA
6
pasi.huuppola@nokia.com
11.01.2007
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.
© NOKIA
7
pasi.huuppola@nokia.com
11.01.2007
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.
© NOKIA
8
pasi.huuppola@nokia.com
11.01.2007
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 DMXmessages.
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.
© NOKIA
9
pasi.huuppola@nokia.com
11.01.2007
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:
•
•
•
•
© NOKIA
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.
10
pasi.huuppola@nokia.com
11.01.2007
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.
© NOKIA
11
pasi.huuppola@nokia.com
11.01.2007
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.
© NOKIA
12
pasi.huuppola@nokia.com
11.01.2007
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.
© NOKIA
13
pasi.huuppola@nokia.com
11.01.2007
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.
© NOKIA
14
pasi.huuppola@nokia.com
11.01.2007
Thank You!
Questions/Comments?
© NOKIA
15
pasi.huuppola@nokia.com
11.01.2007