WO2005041037A2

WO2005041037A2 - Software framework interfacing applications and redundant resources

Info

Publication number: WO2005041037A2
Application number: PCT/EP2004/011900
Authority: WO
Inventors: Stephen Lorusso; Sushil Kulkarni; Pradeep Kumar
Original assignee: Siemens Aktiengesellschaft
Priority date: 2003-10-23
Filing date: 2004-10-21
Publication date: 2005-05-06
Also published as: WO2005041037A3

Abstract

To implement a method of handling resources in a communications system, a software framework is provided that interfaces at least one application and a variety of redundant resources, wherein each resource has an active state and an inactive state, and wherein the software framework includes an input and output module assigned to the resources to provide for communications to and from the resources. The application requests sending a message to a first resource assigned to the application to reserve its resources. A second resource is determined that is active and currently serving the application. The method determines if the second resource has a valid session. If the session is valid, the method sends the message to the second resource. If the session is not valid, the method sends an error indication to the application.

Description

ALIAS FREE PROGRAMMING OF CALL PROCESSING APPLICATIONS

Cross Reference to Related Applications The present application claims priority to provisional patent application serial number 60/513,637 filed on October 23, 2003, which is herein incorporated by reference.

Background of the Invention The embodiments described herein generally relate to the field of developing software for complex applications. More particularly, the embodiments relate to a communications systems and methods that provide an environment for implementing such software. Developing software and systems for complex applications is a time consuming task and requires experts that are skilled in developing software. Software engineering has attempted to overcome the limitations of traditional techniques by using alternative and more efficient approaches. One approach is directed towards developing and using new programming techniques, such as object-oriented programming in combination with particular prograrnming languages, such as C ^{" "}. Another approach is directed towards splitting complex applications into smaller tasks to be solved by task-specific software modules that are later assembled to and introduced in a complex software application. These approaches, alone or in combination, allow for a more rapid development, implementation, and customization of new software programs. Certain systems involve a particular high degree of complexity so that developing software for these systems remains a time consuming task that still requires experts. The need for improved methods of developing software is particularly apparent, for example, in telecommunications voice switching products that employ redundancy. Circuit-switched and packet-switched networks include switches, for example, EWSD switch systems available from Siemens Corporation. Each switch directs the incoming data from any of multiple input ports to a specific output port that forwards the data toward its intended destination. For example, in a local area network (LAN), each switch determines from the physical device address in each incoming message frame the specific output port and internally channels the data to that specific output port. In a wide area network (WAN) such as the Internet, each switch determines from the IP address within each packet the specific output port to use for the next part of the packet's trip to the intended destination. In the Open Systems Interconnection (OSI) communications model, a switch performs the layer 2 or data link layer function. A router or, in some cases, software in a computer, may be a part of a switch. A router determines the next network point the switch should forward, for example, a packet. The router is connected to at least two networks and decides which way to send each information packet based on its current understanding of the state of the networks it is connected to. A router may be located at any gateway, i.e., where one network meets another network. A router may create or maintain a table of the available routes and their conditions and use this information along with distance and cost algorithms to determine the best route for a given packet. Typically, a packet may travel through a number of network points with routers before arriving at its destination. In the OSI model, routing is a function of the network layer (layer 3). For example, a layer-3 switch is a switch that can perform routing functions.

Summary of Certain Inventive Aspects Despite of these approaches, software development for complex applications remains a time consuming task and requires experts that are skilled in developing software. Hence, a need for improved methods of developing software exists for complex applications, such as a switch or gateway of a communications network. Accordingly, the inventive aspects described herein involve a system and a method that employ hardware and software redundancy. More particularly, one aspect involves a method of handling resources in a communications system. A software framework is provided that interfaces at least one application and a variety of redundant resources, wherein each resource has an active state and an inactive state, and wherein the software framework includes an input and output module assigned to the resources to provide for communications to and from the resources. The application requests sending a message to a first resource assigned to the application to reserve its resources. A second resource is determined that is active and currently serving the application. The method determines if the second resource has a valid session. If the session is valid, the method sends the message to the second resource. If the session is not valid, the method sends an error indication to the application. Another aspect involves a communications system having a variety of redundant resources, wherein each resource has an active state and an inactive state, at least one application configured to request sending a message to a first resource assigned to the application to reserve its resources, and a software framework. The software framework interfaces the at least one application and the redundant resources, and includes an input and output module assigned to the resources to provide for communications to and from the resources. The input and output module is configured to determine a second resource that is active and currently serving the application, to determine if the second resource has a valid session, to send the message to the second resource if the session is valid, and to send an error indication to the application if the session is not valid. The various embodiments described herein obviate the need for complex application layer programming that would otherwise be required for interaction with redundant line cards. This substantially lowers the programming complexity and opens the software development environment to programmers without expert skills. As such, the embodiments obviate the need for expert-only programmers and lower the entry barriers so that programmers without expert skills in the particular software development can be effective. Further, redundancy programming does not have to be applied feature-by-feature, which would be a time consuming task and would carry with it significant software maintenance issues. The described embodiments relieve telephony applications from dealing with message distribution to different line cards depending on which is card is a so-called primary or standby, reclaiming messages transmitted into a primary card that has failed, and then transmitting these messages to the newly elected primary card, and keeping track of the relationships between physical and virtual slot positions of redundant cards.

Brief Description of the Several Views of the Drawings These and other aspects, advantages and novel features of the embodiments described herein will become apparent upon reading the following detailed description of certain inventive embodiments and upon reference to the accompanying drawings. In the drawings, same elements have the same reference numerals. Figure 1 shows a schematic illustration of one embodiment of a communications network, Figure 2 shows one embodiment of a computer system suitable for providing a programming environment, Figure 3 is a schematic illustration of functional blocks available within the programming environment, Figure 4 is a more detailed illustration of the functional blocks of Figure 3, Figure 5 is a flow chart illustrating a procedure implementing a first method of alias free programming; and Figure 6 is a flow chart illustrating a procedure implementing a second method of alias free programming. Detailed Description of Certain Inventive Embodiments The following description and attached drawings describe certain inventive embodiments with reference to an exemplary use and application within a communications network. However, those of ordinary skill in the art will appreciate that these inventive embodiments are not limited to uses and applications in a communications network, but are, in fact, equally suitable for any software based system and for developing software for any complex system employing redundancy. With reference to the exemplary use and application, it is contemplated that the communications network may be based on one of several communications technologies such as circuit-switched ISDN, packet-switched IP or ATM networks, or voice-enabled data Next- Generation Networks (NGN) that support both existing voice services and evolving applications such as integrated access, Virtual Private Network (VPN), Internet call waiting, click to dial, unified messaging, enhanced roaming, or the like. Furthermore, the communications network may be based on a technology that converges, for example, a TDM network and a packet network. However, it is contemplated that the following description of certain inventive embodiments is not limited to a certain network technology.

General Overview The various inventive embodiments described herein are based on a software environment that is layered and has a modular layout. At the center of the software environment is a zone where software development occurs without regard to redundancy. This zone is referred to as an alias-free zone. In the alias-free zone of one embodiment, for example, related to a communications application, the software development does not have to account for the alteration of slot numbers resulting from line card fail over events.

Additionally, the software development does not have to be aware of various redundancy modes, which may have implications on slot number usage after a fail over event occurs. The alias-free zone is realized by implementing slot number translation at software layers below the application space. With this, all messages that enter and exit the application space have been translated to appear as though they come from non-redundant systems. Hence, the application software is simplified. Furthermore, the software environment supports line card redundancy thereby freeing applications from the burden of redundancy programming. In addition, the software environment manages resource capacities, utilizations, and allocation algorithms internally. For example, the number of media channels available on a line card is kept internally. This enables applications to be written without the burden of keeping track of how many resources are available on line card X, Y, or Z. This insulation lowers the complexity of applications, enabling more programmers to focus on feature insertion rather than internal procedures relating to telephony resource allocation. Generally, these features substantially lower the complexity of applications and open the software development environment to programmers that would otherwise be locked out due to high learning curves. In one embodiment, the software environment is made up of approximately 60 software modules built in object-oriented style. The object-oriented nature provides an environment well-suited to evolution and extension while retaining stability in previously validated areas. Further, since applications are written against the application programming interface of the system, internal functions are not accessible to applications. This prevents circumvention of procedures necessary, for example, for telephony resource allocation within a communications network.

System and Hardware Environment Figure 1 shows a schematic illustration of one embodiment of a communications network 1. The network 1 includes network elements, for example, switches 6, 8 and subscriber terminals 2, 4, 5. In the illustrated embodiment, the terminal 2 is located at the premises of a subscriber A and coupled via an exemplary line card 10 to the switch 6, the terminal 4 is located at the premises of a subscriber B and coupled via an exemplary line card to the switch 8, and the terminal 5 is located at the premise of a subscriber C and coupled via the line card 10 to the switch 6. A dotted line between the switches 6, 8 indicates that the network 1 may comprise additional switches and/or other network elements, such as gateways, to enable communications between the subscribers A, B. The terminals 2, 4, 5 may be directly coupled to the switches 6, 8, as shown in Figure 1. However, it is contemplated that the terminals 2, 4, 5 may be coupled to the switches 6, 8 via other network elements, such as class 4 switches or transport switches for ATM. The terminals 2, 4, 5 maybe conventional telephones, wireless phones, computers, modems, fax machines, video phones, multimedia devices, or other voice and/or data communications devices. In one embodiment, the switches 6, 8 are based on conventional switching technology that is known by those of ordinary skill in the art. Briefly, each switch 6, 8 has a plurality of input ports coupled to incoming links and a plurality of output ports coupled to outgoing links. The input ports and the output ports are implemented on line cards 10 that act as interfaces between the physical lines and the switch fabric. Incoming signals, for example, packets, are in one embodiment first stored in input buffers to give the processor enough time to process the signals. For routing purposes, the processing includes obtaining and reading the packet's destination address. The processor fetches the packets from the input buffers, analyzes the destination addresses, and forwards the packets to the appropriate output buffers. It is contemplated that the operation of a switch 6, 8 is mainly controlled by various software applications. In one embodiment, these software applications are developed using a computer system 20, as shown in Figure 2. The exemplary computer system 20 includes a processor 22, a random access memory (RAM) 24 and one or more storage devices 28 that may be internal or external devices. The storage devices may include a floppy disc drive, hard disc drive, CD-ROM drive, DVD drive, cartridge drive, memory stick, etc., or any combination of these devices. In a typical application, the computer is coupled to at least one of a monitor 29, a keyboard, a mouse device, a printer, etc., and is equipped to provide for access to a LAN or WAN. The monitor 29 displays characters, text, and graphics so that the user can view the operations the computer system 20 is performing. The computer system 20 operates under control of an operating system, for example, stored in the RAM 24. In one embodiment, the computer system includes a programming tool that provides for the environment available to a software programmer. The programming tool is described below in more detail. In Figure 2, a software module 26 represents for illustrative purposes the software functionality of the computer system 20. The operating system and the programming tool are comprised of instructions which, when read and executed by the computer, cause the computer to perform the steps necessary to implement and/or use the various embodiments described herein.

General Overview of the Software Environment Figure 3 is a schematic illustration of functional blocks 30, 32, 34 available within the programming environment of the computer system 20. The functional block 30 represents an application programming interface (API) layer, the functional block 32 represents an internal core processing layer, and the functional block 34 represents a layer for input and output (I/O). These layers provide for application development, for example, for a family of gateway products in a communications network, and services and databases that enable applications to systematically access telephony resources without having to know line-card specific procedures. The telephony resources govern call control signaling on DSO links (DSO level of 64 Kb/s), and media processing channels that cross-connect the DSO links. Further, these layers provide a uniform way of access to these resources, across all board types, for example, used in a gateway product family. The functional blocks 34 represent a variety of remote resources to be handled by certain applications within a complex system. In a communications network, the remote resources are line cards of a gateway or a switch that contain resources for processing incoming or outgoing calls. The functional block 30 represents the platform software developers use to write applications. At this level, the software developers may use one or more of several available programming techniques, such as a prograrnming language or computer aided software engineering (CASE) tools. The functional block 32 represents a software framework that interfaces the functional blocks 30, 34. In object-oriented systems, the software framework is a set of classes that embodies an abstract design for solutions to a number of related problems. In the illustrated embodiment, the software framework shields the application programming in block 30 from the particulars of the resources represented by blocks 34. That is, the software framework provides that a software developer does not have to have particular knowledge about the resource particulars, such as line card redundancy in the field of communications. In one embodiment, the software framework provides translation functionality for the resources that can exist in space and time. In redundant telecommunications systems, per-call resources involved in signaling and talk-path formulation exist in two places. That is, for the same phone call. If a line card is pulled out of a chassis, another line card has to take over the functionality of the pulled out line card. Various types of line cards may exits in a system, for example, ATM line cards, IP line cards and TDM line cards. Exemplary resources implemented on a line card include voice compressors, echo cancellers, voice activity detectors, tone detectors and generators.

Detailed Overview of the Software Environment Figure 4 is a more detailed illustration of the functional blocks 30 and 32 shown in

Figure 3. In the illustrated embodiment, the functional block 30 represents the software development of a generic telephony application 34. The functional block 30 includes a database 42, a stack 36, an application program interface (API) 38 and a software application 40. The functional block 32 include in the illustrated embodiment a variety of functional sub blocks: A block 44 represents a general function with associated API. The general function is used to initialize the software framework.

TELEPHONY SERVICES APPLICATION ENGINE A block 46 represents the functionality of a telephony services application (TSA) engine with associated API. The TSA engine powers the application and is used by the application to create a services engine that binds the execution of both application and framework functions. The TSA engine provides a way to serialize the execution of functions whose definitions are geographically separated across object-oriented software modules. During runtime, the TSA Engine ensures that all data pertaining to an individual call will be stable and unchanging while a function executes. This provides a basis for mirroring data structures so that stable data is guaranteed throughout mirror operations. Each application employs a TSA engine. At initialization, a TSA message queue is created and installed for each service of the framework. Next, the TSA Engine is created, which marks the start of execution. The TSA engine is initialized by the software framework at card initialization time. In one embodiment, this is done with the following API: int tsalnit( void ). Next, the application creates a TSA queue. For example: int tsaCreateQueue(unsigned

*hQ, int nQueueSize). Next, the application creates a binding between an application ID and a framework service ID. This is referred to as "Installing the queue." For example: int tsalnstallQueue (unsigned hQ, int appld, int svcld); Next, the application creates an engine that represents the task that processes messages from the installed queue. For example: int tsaCreateEngine(unsigned hQ, FUNCPTR appEventHndlr, unsigned int nPriority, unsigned int appTaskStackSize, char *appName). The procedure creates a linkage between the elements application ID, TSA Queue Handle, TSA Engine, and Task Function. The framework services utilize this linkage to determine what queue to post messages to.

MEDIA CONTROL SERVICE A block 48 represents the functionality of a media control service (MCS) with associated API. The media control service is used by the application to create a bearer (talk) path. The media control service provides in one embodiment a connection management for a gateway. It exposes an API that gives applications a uniform programming model for TDM and IP bearer path connections. Internally, the media control service is aware of what board types are installed in the gateway. Further, it knows the board-specific procedures for allocating and de-allocating telephony resources, all of which is hidden from the application. The programming model employed by the media control service includes an endpoint and a connection context. A connection context represents the attributes of a connection, and endpoints are added to a connection context. Two endpoints of any type (TDM, IP, etc.) can be added to a connection context thereby providing a way to interconnect them. In one embodiment, the actions available to the application include ADD, CONNECT,

MODIFY, DISCONNECT, and REMOVE. An exemplary procedure for connecting two endpoints includes: 1. Get Connection Context; 2. Set Connection Context Descriptor; 3. Add Endpoint (TDM) to Connection Context; 4. Add Endpoint (IP) to Connection Context; 5. Connect Two Endpoints; 6. Modify Endpoint; 7. Disconnect; 8. Remove Endpoint (IP) from Connection Context; 9. Remove Endpoint (TDM) from Connection Context; 10. Release Connection Context.

CALL ADMISSION CONTROL SERVICE In one embodiment, the media control service uses a call admission control service embedded within the software framework and configured to protect against over-subscribing bandwidth in an IP network. As such, this service is not directly accessible to applications. In one embodiment, this service is provided to all applications that make use of Voice Over IP network calls, i.e., without special application programming. Internally, the call admission control service keeps the aggregate bandwidth utilization per IP-circuit. An IP-circuit is an abstraction that defines a path through the IP network to a set of destination IP addresses. IP circuits define the bandwidth capacity of the path. The call admission control service monitors the difference between the capacity and the actual utilization, and makes a logic decision on whether to admit the current call to the network. For example, if the utilization exceeds the capacity, the call will not be admitted. When an application uses the media control service API to add an IP endpoint, media control service asks the call admission control service to reserve the bandwidth required by the call. The call admission control service checks if the IP circuit can accommodate this call, and returns an ADMIT or REJECT decision to MCS. If the call admission control does not admit the call, the media control service returns an error response to the application. Thereafter, the application applies this response to whatever interworking is appropriate. CALL CONTROL SERVICE A block 50 represents the functionality of a call control service with associated API. The call control service is used by the application to signal a new call. Further, the call control service exposes an API and gives applications a uniform programming model, for example, ISDN call control. Internally, the call control service is aware of what board types are installed in the gateway. Further, the service has access to provisioning databases, initialized by the operator, that define what signaling is allowed on designated facilities. In one embodiment, the programming model employed by the call control service is modeled after ISDN. The service's abstraction includes port and call contexts. For example, on a TDM facility, a port context relates to a DSO level (64 Kb/s). The call context relates to the call (or calls) transacted on that port. This abstraction provides a way to accommodate multiple calls on the same port in order to support advanced private branch exchange (PBX) calling features. An exemplary procedure for placing a call includes: 1. Get Port Context; 2. Set Port Descriptor; 3. Setup Call; 4. Send Information During Call; 5. Release Call; 6. Release Port Context.

A block 52 represents the functionality of a database with associated API and management application. In one embodiment, the database contains slot and line-card specific information managed by a slot manager. The application and the framework use the database to obtain status information on line cards. Further, the database keeps track of what is installed in the system. A block 54 represents the functionality of an OMAP handler (Operations, Maintenance and Administration Part). The OMAP handler is an internal function that processes events and commands from an external shelf controller. It is a running process on the software platform. For example, it provides a reliable signaling channel to the switch or gateway. A block 56 represents the functionality of a provisioning handler dispatcher (PHD) associated with a dynamic register. In one embodiment, the PHD implements the functionality of a message dispatcher. A block 58 represents the functionality of an input/output (IO) module. In one embodiment, the module is a line card IO module (LCIO). The line card I/O module provides for "alias" mapping between redundant line cards. The line card I/O module includes logic to support the line card redundancy modes. Generally, the LCIO module provides slot number aliasing for messages that traverse this layer. For example, if a message comes in and a slot controller switches the message from slot 5 to slot 9, internal tables have to be updated to note that slot 9 is the alias of slot 5. The application, however, is not aware of this switch. With slot aliasing performed at the LCIO layer, applications exist in the alias-free zone. This avoids applications from being drawn into line card redundancy procedures, and helps keep application development focused on feature insertion. The messaging that occurs at the I/O layer is hidden from applications. This messaging is based on OMAP messages that are common across line cards. A block 60 represents the functionality of a basic message service (BMS). The basic message service handles sending and receiving messages to and from the line cards 10. Figure 5 is a flow chart illustrating a procedure implementing a first method that provides for alias free programming. In one embodiment, the first method is provided by the line card I/O module 58 shown in Figure 4. The illustrated embodiment is described with reference to an exemplary scenario where slots 5 and 9 are a redundant pair, and slot 9 is active (i.e., 9 is the alias of 5). However, slot 5 is the slot the application sees all the time. One parameter is the slot number chosen by the application. The procedure starts at a step SI . Proceeding to a step S2, the application tries to send a message to a line card in slot 5 using the line card I/O module 58 to reserve resources on the line card. Proceeding to a step S3, the line card I/O module 58 along with the slot database 52 determine the active slot, i.e., slot 9. Proceeding to a step S4, the line card I/O module 58 accesses internal tables to determine if the active slot, i.e., slot 9, has a valid session. A valid session is a session that has a required context. If the session is valid, the procedure proceeds along the YES branch to a step S5. In step S5, the line card I/O module 58 uses the services of basic message service 60 to send the message to the line card on slot 9. In step S4, if the session is not valid, the procedure proceeds along the NO branch to a step S6. In step S6, the line card I/O module 58 reports an error by sending an error indication back to the application. The YES and NO branches end in a step S7. Figure 6 is a flow chart illustrating a procedure implementing a second method that provides for alias free prograrnming. In one embodiment, the second method is provided by the OMAP handler 54 shown in Figure 4. The illustrated embodiment is described with reference to the following scenarios: Scenario 1 : Slots 5 and 9 are a redundant pair. Slot 5 is active and slot 9 is in standby (i.e., ready to take over). A state change notification for slot 5 going out of service is received. Scenario 2: Slots 5 and 9 are a redundant pair. Slot 5 is active and slot 9 is in standby (i.e., ready to take over). A state change notification for slot 9 corning in service is received. Scenario 3: Slots 5 and 9 are a redundant pair. However, slot 5 is not available and slot 9 is active. A state change notification for slot 9 going out of service is received. The procedure starts at a step S10. Proceeding to a step SI 1, the handler 54 receives the slot state change notification. Proceeding to a step S12, the procedure determines that a backup slot is in service

(Scenario 1). In this case (i.e. slot 9 is ready to take over), the procedure proceeds along the YES branch to a step SI 6. In step SI 6, the procedure updates the slot database 52 about slot 5, i.e., slot 5 is out of service. Sub facilities are not marked as out of service. Proceeding to a step SI 7, the procedure refrains from notifying the application about the state notification. If the procedure determines in step S12 that a backup slot is not in service, it proceeds along the NO branch to a step S13 (Scenario 2). In step S13, the procedure determines if it is a line card slot switchover. If it is, the procedure proceeds along the YES branch to a step SI 6. In step SI 6, the procedure updates the slot database 52, marking that the slot 9 is active. Proceeding to a step SI 7, the procedure refrains from notifying the application about the state notification. If the procedure determines in step S13 that it is not a line card slot switchover, the procedure proceeds along the NO branch to a step S14 (Scenario 3). In step SI 4, the procedure updates the slot database 52. Sub facilities are not marked as out of service. The procedure changes the notification slot from slot 9 to slot 5. Proceeding to a step SI 5, the notification is passed on to the application. That is, the application learns that slot 5 is not available, but does not know about slot 9. This provides for the alias free prograrnming against slot 5, i.e., the redundancy aspects are hidden from the application. The procedure ends at a step SI 8. It is apparent that there have been disclosed certain inventive embodiments that fully satisfies the objects, means, and advantages set forth hereinbefore. While specific embodiments of the apparatus and method have been described, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art in light of the foregoing description.

Claims

We claim:

1. A method of handling resources in a communications system, comprising: providing a software framework (32) interfacing at least one application (30) and a variety of redundant resources (34), each resource (34) having an active state and an inactive state, and the software framework (32) comprising an input and output module (58) assigned to the resources (34) to provide for communications to and from the resources (34); requesting by the application (30) to send a message to a first resource (34) assigned to the application (30) to reserve its resources; determining a second resource (34) that is active and currently serving the application (30); determining if the second resource (34) has a valid session; sending the message to the second resource (34) if the session is valid; and sending an error indication to the application (30) if the session is not valid.

2. The method of Claim 1 , further comprising accessing a resource database (52) to determine the second resource (34).

3. The method of Claim 1 , further comprising accessing tables within the input and output module (58) to determine if the second resource (34) has a valid session.

4. A communications system, comprising: a variety of redundant resources (34), each resource having an active state and an inactive state; at least one application (30) configured to request sending a message to a first resource assigned to the application (30) to reserve its resources; and a software framework (32) interfacing the at least one application (30) and the redundant resources (34), the software framework (32) comprising an input and output module (58) assigned to the resources to provide for communications to and from the resources, wherein the input and output module (58) determines a second resource (34) that is active and currently serving the application (30), determines if the second resource has a valid session, sends the message to the second resource if the session is valid, and sends an error indication to the application if the session is not valid.

5. The system of Claim 4, wherein the resources are line cards (10).

6. The system of Claim' 4, wherein the application (30) is a telephony application.

7. The system of Claim 5, wherein the software framework (32) further comprises a database for maintaining status information of the line cards (10).