Telecom-Oriented Embedded Software Support Platform

Telecom equipment such as a digital switching system is a highly reliable and stable real-time embedded system that asks for a perfect architecture to integrate hardware and software. Its hardware is required to provide large switching capacity, high reliability and reasonable power consumption. Due to the complexity of software modules and layers, its software design aims at encapsulation and inheritance besides perfect functionality, low defect ratio and high operation efficiency. At present, background software of a telecom system such as network management and OAM (Operation, Administration and Maintenance) has adopted the object-oriented languages (C++ and Java), so it has good encapsulation and inheritance. However, foreground software generally uses the C and assembly languages. Although its codes have good execution efficiency, its bad encapsulation and inheritance make the telecom system difficult to debug and trace exception. The emergence of telecom-oriented embedded software support platform solves the problems of foreground software.

  An embedded software support platform usually comprises an integrated real-time operating system, integrated development environment and service support software. The development of software platform has become a popular trend. At present, main telecom equipment providers have adopted unified system software platforms. For example, Cisco has IOS Platform based on routing protocols and Nokia has SYMBIAN Platform for handset software development. However, most available platforms are based on protocols, which cannot provide integrated solutions to both operating systems and service applications. Therefore, here a tailorable and configurable embedded software support platform for both operating systems and upper-layer applications is recommended, which allows quick launch of new systems and products, and can greatly improve the stability of the whole communication system.

1 Overview
As shown in Figure 1, a typical telecom system is comprised of the Board Support Package (BSP) subsystem, operating system and its support subsystem, database subsystem, protocol subsystem, signal subsystem, service subsystem, OAM and network management subsystem and system control subsystem.

  The telecom-oriented software platform is embedded at the layer of the operating system and its support subsystem. On one hand, it screens the differences of hardware architectures and various operating systems at the bottom layer, on the other hand, it provides the universal Application Programming Interfaces (API) and inheritable functional modules to upper protocols and applications, confining and standardizing the programming model of application software. Its functionality and layers are depicted in Figure 2.

The Virtual Operating System (VOS) layer at the bottom screens the differences of general operating systems and provides a universal system call interface. The operating systems include current embedded real-time operating systems such as VxWorks and pSOS[1], embedded Linux with wide application[2] and Windows with an excellent integrated environment for development and debug. VOS adopts a one-way invocation mode to improve system invocation and avoid recursive invocation. Upper systems invoke a specific operating system via the VOS layer. With VOS, an application program can be used in different operating systems, which saves a lot of time for program development and debug. For example, a programmer can write and debug a program in Windows before a hardware environment is prepared, and then transplant it to VxWorks or Linux to work in an actual single board environment. VOS greatly improves the efficiency of product development.
   The core layer consists of the process-based scheduling, distributed process communication, effective message memory management and reliable timing management modules. It can meet communication requirements for high reliability, good performance and real-time processing.
The protection layer provides some software exception handling and debugging means. The exception-handling module is responsible for exception capture, store and output. The print control module grades print information and output it or redirect it to different target terminals. The system monitor module administrates the system objects such as memory, timer, message and so on. In addition, it can capture the process deadlock and dead loop exception. The memory protection module provides the protection of all variables and memory, checks memory leak and stack overflow by virtue of the protection feature of Memory Management Unit. The message trace module provides the trace of message according to the message identity or message type. As we know, telecom software is very large and complex, but these tracing and debugging means can greatly quicken the exception capture and error recovery to ensure the high reliability of telecom systems.

  The module layer provides functional modules including the virtual file system, command line interface, embedded database, communication protocols such as TCP, RUDP and HDLC, software version loading and so on. These modules can be easily integrated into the platform system.

2 Scheduling Management and  Process

   Communication Model
The scheduling management and process communication model is the core of an embedded software support platform. It plans the application software architecture and programming model of the whole software system based on the platform. The instance scheduling management module organizes and schedules upper-layer services. The process communication module implements the distributed process communication by the system software bus of message stream. As shown in Figure 3, the whole application operation data are organized and administrated in a mode of process, fulfilling the processing of protocols, signals and services.

2.1 Instance Scheduling Model
The basic schedule unit of traditional embedded systems is the "task". System software works on the basis of real-time multiple task scheduling. However, the task scheduling mechanism has some disadvantages. The resource consumption of task is too large for an embedded telecom system. The synchronization operation between tasks also has a negative influence on system performance. In addition, the application logic becomes complex when the task number increases. Thus, it is hard to fulfill tremendous calls in SPC (Stored Program Controlled) switches and mobile communication systems. An instance scheduling mechanism is a solution.

  The instance represents a program segment and its executing context. It is the basic scheduling unit of this carrier-grade embedded software platform. A process is the static data aggregation of instances, and the instance is the instantiation of a process. The instance is driven by messages. Each instance has its own message queue to receive and handle messages, own data region to save current call information, own stack to save current code contexts, and own timer to timing the operation.
On this embedded software platform, each task can support one or more instances. In this case, task scheduling is managed by the operating system, and instance scheduling is managed by the platform under its task. This is so-called two-level scheduling.

  As shown in Figure 4, a scheduling task first picks a ready instance to run from the ready process queue, and hand over the control to the running instance. Then the instance enters its own process context to handle the message according to the Finite State Machine model. After the instance finishes its own process, it makes a state transition, and hands over the control back to the scheduling task. If the instance has no messages in its message queue anymore, it will be put into the block process queue, otherwise it will be put into the ready process queue. At last, when the ready queue is empty, the scheduling task will receive messages from its task message queue, and dispatch the messages to the instance process message queue. By the two-level scheduling strategy, the platform accomplishes the running context protection and operation space isolation of telecom data.

2.2 Distributed Process Communication
There are multiple communication ways in a complex telecom system, such as the master-slave communication between the master board and slave board, the board communication between main control board and user board, the foreground-background communication between foreground devices and the network administration center, and inner communication of a processor. These communication modes have different media and mechanisms. Therefore, the process communication module has to layout a universal architecture-independent addressing way and unified message structure, besides screening differences of the communication mechanisms. The module can further provides an open communication model and unified asynchronous and synchronous interfaces. Thus, design of telecom application software is greatly simplified and the software transplant is convenient.
Process Identity (PID) provides a universal addressing model. Its structure is described as follows in the C language:

Typedef struct tagPID
{
    Unsigned long   pno;
    Unsigned char   module;
    Unsigned char   unit;
    Unsigned char   loc;
    Unsigned char   reserve;
}T_PID;

  The module number, unit number and CPU number of PID help the system position a specific processor on a board of a rack. The pno of PID decides a process running on this processor. When a process communicates with another, the system will first judge whether the object process is local or remote. For a local process, inner task and inter task communications have different sending interfaces, while for a remote process, the system will look up the global map table to find the destination and communicate with corresponding protocols such as the IP protocol for routers, HDLC protocol for switches and HIRS protocol for CDMA base stations. The flow chart of distributed process communication is shown in Figure 5.

3 Conclusion
The embedded software support platform provides an effective programming model for telecom systems, and quickens the development of application software. It also offers some means of debugging and exception tracing and functional modules, which contributes to improving the stability and inheritance of the systems. At present, it has been validated and used in the devices of CDMA, routers and ADSL (Asymmetrical Digital Subscriber Line) of ZTE Corporation. With the development of telecom technologies and embedded systems, the telecom-oriented embedded software support platform will undoubtedly have a splendid future and wide applications.

References
[1] Kong Xiangying, Bai Guizhi. The Embedded Real Time Operating System Vxworks and Its Developing Environment Tornado [M]. Beijing: China Electric Power Press, 2002.
[2] Daniel P. Bovet, Marco Cesati. Inside the Linux Kernel [M]. Beijing: China Electric Power Press, 2001.

Manuscript received: 2004-03-19