WO2005039142A1 - A basic message service for redundant devices - Google Patents

Abstract

A Basic Message Service (BMS) handles message transport between two redundant devices in a telecommunications voice switching system that employ distributed resources. A basic message service instance is created. A basic BMS session is then created. A BMS session as a TCP connection Server is initiated. The TCP client session is connected to a server session and an OMAP message is posted to the TCP session.

Description

TITLE OF THE INVENTION

A Basic Message Service for Redundant Devices

Description

Background tield Of The Invention.

This invention defines a Basic Message Service (BMS) that handles message transport between two redundant devices, such as a call processor / client and line card /server, or vice versa. It provides message retransmission for unacknowledged messages during fail over events, configurable sessions for various types of connections, and independent Transmit and Receive channels for non-blockmg bi-directional communication .

Related Infoi ation.

Tn a telecommunications voice switch, a call processing system may be communicating with a line card. In redundant systems, when the line card fails, a second, or redundant line card takes over. For systems that employ redundant elements, the structural make-up of mLernal rommum ration pathways can create a burdensome complexity for software applications. This can complicate feature insertion and/or prevent the software from being added on to in any substantial way.

Further, when a fail over event occurs, communication connections are broken and some messages are lost. Software applications have to provide a re-connect and re-transmit procedure .

Another problem is when an application makes direct use of a transport protocol, such as 1CP/IP, it is often difficult to migrate to an improved proLocυl, such as SCTP, because I e new software interface requires too extensive of a change.

The only manner in which these problems have been dealt with thus far is through message duplication. However, duplicating messages is inefficient and complicates the software .

There are no other known commercially available abstractions that solve these problems.

OBJECTS & SUMMARY OF THE INVENTION

ihis invention defines a Basic Message Service (BMS) that handles message transport between two redundant devices. It provides message retransmission for unacknowledged messages during fail over events, configurable sessions for various types of connections, and independent Transmit and Receive channels for non-blocking bi-directional communication.

The invention solves the foregoing problems by employing logic that maintains a list of unacknowledged messages. In another aspect, the invention retries unacknowledged messages. It also redirects message flows. It may also throttle message rates. In another aspect, the invention avoids application-layer blocking during fail over and enables continuous messaging throughout fail over. The present invention is described in terms of software, however, the invention may also be practiced n terms of a hardware-based redundancy solution such as an Error Correction and Recovery (ECR) scheme.

The main elements of this invention include a Session abstraction that is configurable by application software. There are 5 session types to support various communication models. The session contains an input message queue, a link list of unacknowledged messages, and two tasks for bidirectional transmit and receive communication. The BMS session abstracts the underlying transport protocol thereby simplifying incorporation of newer protocols.

Thus, with the present invention systems that employ redundant elements are greatly simplified. The structural make-up of internal communication pathways can create a burdensome complexity for software applications. This can complicate feature insertion and/or prevent the software from being added on to in any substantial way. This invention solves this problem with the introduction of the BMS Session.

When a fa l over event occurs, communication connections get broken and some messages get lost. Software applications have to provide a re-connect and re-transmit procedures . This invention solves this problem by providing this logic thereby freeing the applications from this responsibility.

When an application makes direct use of a transport protocol, such as TCP/IP, it is often difficult to migrate to an improved protocol, such as SCTP, because the new software interface requires too extensive of a change. This invention solves this problem by providing an API interface to the BMS Session thereby abstracting the application from the protocol-specific details of the underlying protocol.

DETAILED DESCRIPTION

This invention defines a Basic Message Service (BMS) that handles message transport between two redundant devices . In the embodiment provided here the invention provides a set of contingencies for various scenarios that may occur in communication between redundant devices. In a first contingency, the invention provides a message retransmission for unacknowledged messages during fail over events. In another contingency, there are provided configurable sessions for various types of connections . There may be provided, for example, independent Transmit and Receive channels for non- blocking bi-directional communication.

In a specific implementation, the invention describes an API (application programming interface) for the Basic Messaging Service (BMS) . The BMS API could be, for example, a programming layer above TCP/IP network layer . This arrangement would provide an efficient way of implementing the TCP/UDP/IP socket functionality whilst avoiding the complexity associated with it. These API's will allow for the effective programming of the TCP/IP socket functionality, without the application having to worry about the lower level details .

The present invention provides functions to carry out BMS. A detailed description of each API, m terms of usage and functionality will be described. First, the invention sets up a BMS application. The starting point of BMS programming is to create a BMS rnstance. The next step is to create a basic BMS session, for all purpose (TCP client/server, UDP service, etc) . In one embodiment, and in order to create a basic BMS session, which is used for all purposes, (TCP client/server, UDP service, etc) , the invention creates an OMAP message queue, RxTask queue and TxTask queue. The invention adds the session to the instance and then sets a trace level.

Once this is accomplished, the invention creates a BMS session as a TCP connection Server. This is done, for example, by creating a TCP listen Server BMS session. Then, the invention creates a server task control queue. Then the invention completes a TCP socket creation routine. Next, a TCP Server task is started which accomplishes 4 objectives. First, it monitors the server socket. Second, it creates the basic BMS handling session if necessary. It also spawns Rx and Tx task to handle bi-d rection packet transmitting. And, finally, it monitors the server task control queue to shut down the server.

The invention connects the TCP client session to a server session and posts an OMAP message to a TCP session. First, a TCP client socket creation routine to connect to server is completed. Next, an Rx task is spawned, which monitors the client socket. It also, passes the received packet to Rx Callback function. Next, the Event packet is passed to the Event Callback function. The error condition and Rx control queue are monitored. Finally, the shut down command to Tx task is initialized. After the Rx task is spawned, the Tx task is spawned, which the OMAP queue is monitored. It also sends out the out-going packet to socket. It also monitors the Tx control queue for shutting down the task.

Then, the invention creates a BMS session as a datagram service, such as UDP, and posts a generic message to a datagram session. This is done by first completing a UDP service socket creation routine. In order to do this, an Rx UDP task is spawned, which monitors the UDP service socket. It further passes the received packet to Rx Callback function. It also passes the event packet to event callback function. The routine also monitors the error condition and Rx control queue. Finally, it initializes the shut down command to Tx task. Second, a Tx UDP task is spawned. This has the effect of monitoring the OMAP queue. It also sends out the out-going packet to socket . And, the Tx control queue for shutting down the task is monitored.

When the BMS session is, thus, set up, an omap message may then be posted to the TCP session. For that matter, a generic message to a datagram session, like UDP, may be posted.

At some point in the future the invention will shut down the BMS instance. This is done by first disconnecting a BMS client session from a TCP server. Next, the invention causes the BMS session to be destroyed, either a TCP client or a server A BMS datagram service is then initiated and the invention shuts down the BMS instance.

The following BMS functions are provided to support the session connection. ihere is provided, for example, the ability to flush the remaining messages in the session's retransmit queue. This is done by shutting down the Tx Task. Next, all the packets from Omap queue are read and tossed out. Finally, the Tx Task is restarted.

Another function that may be useful is the ability to register a new Rx callback function or register a new Tx callback function. It may also be desired to reset a BMS TCP client session or reset a BMS instance. It may also be desirable to Set/Reset destination IP address, such as when a new soft switch takes over. There is also provided the option to set a destination port. It would also be desirable to set a BMS trace level, as Error, Warning, Info, Detail, Msg Flow, etc. Similarly, it would be desirable to set a BMS trace type, as cnι_pπntf, us_prmtf, or printf, for example. The details of these supporting functions will be readily understood by the skilled TCP/IP artisan.

BMS statistical functions are also provided by the invention. For example, a BMS session profile retrieval function retrieves the session profile from a BMS session. The BMS Get Transport Statistics function retrieves the transport statistics from a BMS session. The BMS Print Profile function prints BMS TCP session profile. lhe BMS Print Statistics function prints BMS TCP session statistics. The BMS Print Udp Profile function prints a BMS UDP session profile. A BMS Print Udp Statistics function prints BMS UDP session statistics. A BMS Reset Transport Statistics function resets the transport statistics values of a BMS session. As with the supporting functions, the skilled artisan will readily understand how to implement these functions .

Now that the present invention has been sufficiently described, a concrete example shall now be gi ven in terms of TCP socket programming. In this example, a BMS API for TCP socket programming is utilized for the implementation of CPE lpmio and IPM cpeio. CPE is the server side, with lpmio as the TCP server socket. IPM is the client side, with cpeio as the TCP client socket.

The CPE lpmio takes the following steps. First, it imtilizes an lpmio TCP server session. This is done by creating the TCP listen server session. Then a connection session s created. Next, a set trace leveL function is initiated. Finally, a trace type is set. Next, the CPE lpmio shuts down the server session. This is done by resetting an instance to drop all connections. Next, the client session is destroyed followed by destroying the server session. Finally, the server is shut down.

CPE lpmio then calls back an event m order to pass that event to an upper layer application. Next, it receives a messaqe call back function to pass the event to the upper layer application. An input function for upper layer post outgoing message to the Tx socket .

The IPM cpeio takes the following steps. First it imtilizes the cpeio TCP client session. This is done by creating the TCP client session. Then a trace level is set. Next, a trace type is set. Then, when the session is over the TPM cpeio shuts down the client session and resets instance to drop all connections. The session is then destroyed and the server is shut down.

The it connects to the CPE lpmio server. When finished with the server it disconnects the CPE lpmio server. It sends a received message call back function to pass to the upper layer application. it then initiates an event call back function to pass event to the upper layer application.

Finally, it provides an input function for posting upper layer message outgoing to the Tx socket.

The skilled practitioner will readily understand how to implement socket programming. However, the invention further provides the following source code to assist in the implementation of the invention. In the following examples, the C language format, however any format or language could be used. 1. The following code is provided here to implement a Subsystem Type Enumerate: typedef enum _BMS_SUBSYSTEM_TYPE { BMS_CPE = 1, /* CPE sub-system */ BMS_SCE /* SCE sub-system */

} BMS_SS;

2. The following code is provided here to implement a Session Type Enumerate: typedef enum _BMS_SESSION_TYPE { BMS_CLIENT_CONNECTION = 1, /* TCP connection on client side */ BMS_SERVER_CONNECTION, /* TCP connection on server side, BMS internal value, NOT used by upper layer application */ BMS_DATAGRAM_SERVICE, /* Datagram, like UDP, service */ BMS_LISTEN_SERVER /* TCP Listen server, BMS internal value, NOT used by upper layer application */ } BMS_ST;

3. The following code is provided here to implement a Transport Protocol Enumerate: typedef enum _BMS_TRANSPORT_PROTOCOL { BMS_TCP = 1, /* TCP */ BMS__UDP, /* UDP */ BMS_SCTP /* SCTP, not currently supported */

} BMS_TP ; 4 The following code is provided here to implement a Server Type Enumerate: typedef enum _BMS_SERVER_TYPE { BMS_MATCHED_SESSIONS = 0, /* sessions are matched according to client src IP address BMS_INDEPENDENT_SESSIONS /* sessions are independent */

}BMS_SRT;

5. The following code is provided here to implement a Retry Mode Enumerate: typedef enum _BMS_RETRY_MODE { BMS_NO_RETRY = 1, /* no msg retransmission */ BMS_ACK_BASED_RETRY, /* msg retransmission for originating endpomts */ BMS_RELAY_BASED_RETRY /* msg retransmission for relay (non-origmatmg) endpoints */ } BMS_RETRY;

6. The following code is provided here to implement a Message Priority Enumerate: typedef enum _BMS_MSG_PRIORITY { BMS_MSG_PRIORITY_NORMAL = 0, /* FIFO delivery */ BMS_MSG_PRIORITY_URGENT /* Go to the head of the queue delivery */ }BMS_MSG_PRIORITY;

7. The following code is provided here to implement a BMS Event structure: typedef struct _BMS_EVENT { BMS_INST hlnst; /* instance handle */ BMS_HD hid; /* session handle */ unsigned event; /* event id */ unsigned cause; /* cause code */ unsigned remoteAddr; /* lp address (in hex) of remote */ char* pBuf; /* attached buffer */

}BMS_EVENT;

8. The following code is piovided here to implement a BMS session Parameter structure: typedef struct _BMS_PARAMETERS { int nMaxMsgSize; / * max size of omap messages */ mt nMaxInputQueueSizc; /* size of omap input queue */ mt nMaxRetransmitQueueSize; /* max size of retransmit queue */ int nRxTxSkewlnterval; /* skew between Rx and Tx task startup ( n seconds ) */ mt nTxThrottlelntcrval; /* msg rate throttle (in milliseconds), 0 = no throttle */ unsigned remoteAddr; /* IP address of remote */

} BMS_PARM;

9. The following code is provided here to implement a BMS Profile structure: typedef enum _BMS_TRACE_TYPE { BMS_PRINTF = 0, /* basic printf */ BMS_CNI_PRINTF , /* cnι_pπntf */ BMS US PRINTF /* us_pπntf for SCE */

} BMS_TT ;

10. The following code is provided here to implement a BMS Profile structure: typedef struct _BMS_PROFILE { int RxTaskld; /* Read Task ID */ int TxTaskld; /* Write Task ID A int sFdPrimary; /* Socket number (primary) */ int sFdSecondary; /* Socket number (secondary) */ BMS_SS dcstSubSys; /* Cpe or See */ BMS_TP type; /* Transport type */ BMS_RE RY mode; /* Retry mode */ BMS_PARM parm; /* Session parameters Char name [BMS_MAX_NAME_SIZE] ; /* Session name V short localPort; /* local port number */ unsigned localAddr; /* local IP address */ short remotePort; /* remote port number */ unsigned remoteAddr; /* IP address of remote */

} BMS_PROFILE;

11. The following code is provided here to implement a BMS Statistics structure: typedef struct _BMS_STATISTICS { unsigned nTxMsgs; /* transmitted Msg count */ unsigned nTxErrors; /* transmit error count * unsigned nTxDropped; /* tranmit dropped Msg count * unsigned nRxMsgs; /* received Msg count */ unsigned nRxErrors; /* received Msg error count ^A / unsigned nRxDropped; /* received Msg dropped count */ unsigned nRxSocketErrors; /* ERROR on Read function */ unsigned nRxSocketEOFs ; /* received EOF, remotely shutting down */ unsigned nResetSession; /* cumulative number of session resets unsigned nOnRetryList ; /* current num msgs on retry link list */ unsigned nOnOmapQueue ; /* current num msgs in Omap msg queue */ unsigned nOnRetryListMaxBacklog; /* max list backlog since session create */ unsigned nOnOmapQueueMaxBacklog; /* max queue backlog since session connect */ unsigned nRxReqMsgs; /* received REQ count */ unsigned nRxAckMsgs; /* received ACK count */ unsigned nRxNakMsgs; /* received NAK count */ unsigned nTxReqMsgs; /* transmitted REQ count */ unsigned nTxAckMsgs; /* transmitted ACK count */ unsigned nTxNakMsgs; /* transmitted NAK count */ unsigned nFlush; /* number of Flush function completed */ unsigned nMsgsLstFlushed; /* number of msgs of last flushed */

} BMS_STAT;

Another example shall be provided using BMS API for Datagram Service (UDP) socket programming by implementing an SCE MGCP RELAY, which creates a UDP service on both SRX interface and CPE interface. In this case, the MGCP packet received from SRX will be relayed to CPE, and vice versa.

The CPE ipmio first initializes the Mgcp Relay instance. Then, it creates an SRX side UDP session. It then sets a trace level on the SRX side. Next, it starts the SRX side UDP service session. A CPE side UDP session is then created. After this, a trace level for the SRX side is set. Finally, the CPE side UDP service session is started.

The CPE ipmio shutdown procedure initiates a stop of the SRX side Mgcp Relay UDP service session. The CPE side Mgcp Relay UDP service session is stopped. Next, the SRX side UDP session is destroyed. Then, the CPE side UDP session is destroyed. Finally, the Mgcp Relay instance is shut down.

Although the present invention has been described in terms of specific embodiments, it shall be appreciated that the invention broadly encompasses variations and modifications thereto.

Claims

Claims

1. A method for a Basic Message Service (BMS) that handles message transport between two redundant devices in a telecommunications voice switching system that employ distributed resources, the method comprising the steps of:

creating a basic message service instance;

creating a basic BMS session;

creating a BMS session as a TCP connection Server;

connecting the TCP client session to a server session; and

posts an omap message to a TCP session.

2. The method of claim 1, further comprising the step of creating a BMS session as a datagram service and posting a generic message to a datagram session.

3. The method of claim 1, further comprising the step of posting an omap message to the TCP session.

4. The method of claim 1, further comprising the step of create a basic BMS session creates an OMAP message queue, RxTas queue and TxTask queue .

5. The method of claim 4, further comprising the step of adding the session to the instance and then sets a trace level .

6. The method of claim 1, further comprising the step of creating a BMS session as a TCP connection Server by creating a TCP listen Server BMS session. Then, the invention creates a server task control queue .

7. The method of claim 6, further comprising the step of completing a TCP socket creation routine.

8. The method of claim 7, further comprising the step of starting a TCP Server task is started which accomplishes 4 objectives. First, it monitors the server socket.

9. The method of claim 6, further comprising the step of creating the basic BMS handling session if necessary.

10. The method of claim 9, further comprising the step of spawning Rx and Tx task to handle bi-direction packet transmitting.

11. The method of claim 10, further comprising the step of monitoring the server task control queue to shut down the server.

12. The method of claim 1, further comprising the step of connecting the TCP client session to a server session and posts an omap message to a TCP session. First, a TCP client socket creation routine to connect to server is completed.

13. The method of claim 12, further comprising the step of spawning an Rx task which monitors the client socket.

14. The method of claim 13, further comprising the step of passing the received packet to Rx Callback function.

15. The method of claim 14, further comprising the step of passing an event packet to the Event Callback function.

16. The method of claim 15, further comprising the step of monitoring an error condition and Rx control queue.

17. The method of claim 16, further comprising the step of shutting down command to Tx task

18. The method of claim 1, further comprising the step of creating a BMS session as a datagram service, such as UDP, and posting a generic message to a datagram session.

19. The method of claim 18, further comprising the step of creating a BMS session as a datagram service is performed by spawning an Rx UDP task.

20. The method of claim 19, further comprising the step of passing the received packet to Rx Callback function.

21. The method of claim 20, further comprising the step of passing the event packet to event callback function.

22. The method of claim 21, further comprising the step of monitoring an error condition and Rx control queue.

23. The method of claim 22, further comprising the step of initializing the shut down command to Tx task.

24. The method of claim 19, further comprising the step of spawning a second, a Tx UDP task is spawned. This has the effect of monitoring the OMAP queue. It also sends out the out-going packet to socket. And, the Tx control queue for shutting down the task is monitored.

25. The method of claim 1, further comprising the step of At some point in the future the invention will shut down the BMS instance .

26. The method of claim 25, further comprising the step of disconnecting a BMS client session from a TCP server.

27. The method of claim 26, further comprising the step of destroying the BMS session to be destroyed.

28. The method of claim 27, further comprising the step of initiating a BMS datagram service and shutting down the BMS instance .