Patent Application
20050190743
The present invention relates generally to the field of telecommunications and, in particular, to systems and methods for managing data transmissions over telecommunications networks.
In many telecommunications systems, data is transmitted over telecommunications networks in accordance with predetermined standards, or protocols. Each protocol typically includes a unique command set, as well as a set of rules or conventions for segmenting and transmitting data. In some circumstances, it can be desirable to transmit data between telecommunications systems having different protocols. In these circumstances, it is often necessary to convert commands and data from one protocol to another.
This protocol conversion process can be carried out by a telecommunications gateway, which provides an interface between customer equipment devices and service provider equipment devices. Existing protocol conversion schemes are unnecessarily complex and non-intuitive. Accordingly, there is a need for a simpler, more efficient approach to the protocol conversion process within telecommunications gateways.
The above-mentioned drawbacks associated with traditional protocol conversion systems and methods are addressed by embodiments of the present invention and will be understood by reading and studying the following specification.
In one embodiment, a method for converting telecommunications data from a first protocol to a second protocol comprises receiving input signals in conformance with the first protocol and mapping the input signals to an abstract, protocol-independent information format. The method further comprises converting information from the abstract, protocol-independent information format to protocol-specific output signals, and transmitting the output signals in conformance with the second protocol.
In another embodiment, a telecommunications gateway is in communication with a plurality of costumer equipment devices having different customer protocols and with a plurality of service provider equipment devices having different service provider protocols. The telecommunications gateway comprises a plurality of protocol handlers. Each protocol handler is associated with a given customer protocol or service provider protocol. The telecommunications gateway further comprises a plurality of operation modules in communication with each of the protocol handlers. Each of the protocol handlers is configured to convert input signals in conformance with the associated protocol to a generic information format. Each of the protocol handlers is further configured to convert information from the generic information format to output signals in conformance with the associated protocol. In addition, each of the operation modules is configured to perform a telecommunications operation using information in the generic information format.
Other embodiments are described and claimed.
In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific illustrative embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that logical, mechanical, and electrical changes may be made without departing from the spirit and scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense.
The gateway 110 is also in communication with service provider equipment 130 through one or more telecommunications networks 140, such as, for example, an IP network or a public switched telephone network (PSTN). The service provider equipment 130 may also comprise a wide variety of devices, depending on the associated telecommunications network 140. For example, if a first telecommunications network 140 comprises a PSTN, then the service provider equipment 130 in communication with the gateway 110 through the first telecommunications network 140 may comprise a central office (CO), a PBX, and the like. If a second telecommunications network 140 comprises an IP network such as the Internet, then the service provider equipment 130 in communication with the gateway 110 through the second telecommunications network 140 may comprise a voice over IP (VoIP) controller, a PBX with IP trunks, and the like.
In operation, data is typically transmitted over the telecommunications system 100 by forming communication links between pairs of customer equipment 120 and service provider equipment 130 through the gateway 110 and the appropriate telecommunications network 140. Each communication link typically has an associated gateway interface, signaling protocol, and voice format. For example, in one embodiment, the selected customer equipment 120 comprises a POTS or a PBX, the selected service provider equipment 130 comprises a CO, and the corresponding communication link comprises an analog interface, loop start signal protocol, and analog voice format. In another embodiment, the selected customer equipment 120 comprises an ISDN phone or a PBX, and the corresponding communication link comprises an ISDN basic/primary rate access interface (BRI/PRI), Q.931 signaling protocol, and pulse code modulation (PCM) voice format. In another embodiment, the selected customer equipment 120 comprises a PBX, the selected service provider equipment 130 comprises a CO or a PBX, and the corresponding communication link comprises an ISDN PRI interface, QSIG signaling protocol, and PCM voice format. In another embodiment, the selected customer equipment 120 comprises an IAD, and the corresponding communication link comprises a digital subscriber line (xDSL) interface, voice over asynchronous transfer mode (VoATM) protocol, and ATM adaptation layer 2 (AAL2) voice format. In another embodiment, the selected customer equipment 120 comprises an IP phone, the selected service provider equipment 130 comprises a PBX with IP trunks, and the corresponding communication link comprises an IP interface, VoIP signaling protocol, and real-time transport protocol (RTP) voice format. In another embodiment, the selected service provider equipment 130 comprises a CO, and the corresponding communication link comprises an E1 interface, V5.x signaling protocol, and PCM voice format. In another embodiment, the selected customer equipment 120 comprises a PBX, the selected service provider equipment 130 comprises a CO or a PBX, and the corresponding communication link comprises an E1 interface, MFC/R2 signaling protocol, and PCM voice format. Other exemplary embodiments will become apparent to those of ordinary skill in the art in view of the present disclosure. For example other common customer protocols include POTS, loop start, ground start, E&M, VoATM, Megaco, MGCP, H.323 and SIP. Moreover other common service provider protocols include V5.x, Megaco, MGCP, Q.931, QSIG, H.323, SIP, and MFC/R2.
In some cases, the gateway 110 forms communication links between customer equipment 120 with one associated signaling protocol and service provider equipment 130 with a different associated signaling protocol. In these cases, the gateway 110 typically must perform protocol conversions to create the appropriate communication links.
For example, in one specific illustrative embodiment, the gateway 210 supports customer equipment comprising POTS, VoATM terminals, and supports service provider equipment implementing the V5.x and media gateway control (Megaco) protocols. In this particular embodiment, the gateway 210 comprises a V5.x-to-POTS conversion module 2401,1, a Megaco-to-POTS conversion module 2401,2, a V5.x-to-VoATM conversion module 2402,1, and a Megaco-to-VoATM conversion module 2402,2. The following table summarizes the operation of each conversion module 240 when an incoming call is received.
This bilateral approach to the protocol conversion process presents a number of disadvantages. For example, using this approach, the gateway 210 is typically required to operate with different terminal identifier types, open separate conversion modules 240 (e.g., state machines) for each conversion type, and duplicate common operations, such as, for example, internal resource allocation, among the different processes. In addition, because management support is often based on dividing the gateway 210 into blocks according to protocols 220, 230 and implementing protocol-specific actions, support for protocol-independent, application-level operations is relatively difficult and non-intuitive.
The gateway 310 also comprises a number of operation modules 350, such as, for example, state machines, that perform many common telecommunications operations using the data contained in the abstract information format. For example, one operation module 350 may handle incoming calls, whereas another operation module 350 may handle a management operation, such as, for example, service state management, active call clearing, or out of service report to EMS, to name a few.
In some embodiments, the abstract information format comprises a super-set of signaling information conveyed by all of the supported protocols 320, 330. Functionally equivalent information preferably appears only once in the abstract information format. For example, a pulse-dialed digit, a dual tone multi-frequency (DTMF) digit, or a digit extracted from a Q.931 message can all be represented in the same way (e.g., “digit n”) in the abstract information format. Moreover, a ringback tone and a Q.931 ALERTING message, which may both be applied on an ISDN line, can be represented in the same way (e.g., “far-end is alerting”) in the abstract information format.
The abstract information format also preferably comprises a series of generic management parameters which are abstractions of particular protocol concepts and can be used to perform many common management operations. For example, in some embodiments, the abstract information format comprises a mapping of physical addresses of analog lines, IP addresses of IP phones, behind-IAD terminal identifiers (characterized by an ATM connection and an identifier within the connection), and the like to unique values within a selected range of numbers. These values uniquely identify each subscriber, and can be used to perform management operations, such as, for example, service state management actions.
In some embodiments, each subscriber is identified on the network interface with a unique Terminal ID. This generic parameter preferably corresponds to a subscriber identifier in a variety of protocols, such as, for example, an L3 address in a V5.x protocol, an Endpoint ID in a media gateway control protocol (MGCP), a Termination ID in a Megaco/H.248 protocol, and the like. By providing unified handling of common management operations, such as, for example, configuration operations, the abstract information format advantageously provides a uniform view of the telecommunications system 100 and the served subscribers.
In one specific illustrative embodiment, the gateway 310 supports customer equipment comprising POTS, VoATM terminals, and supports service provider equipment implementing the V5.x and Megaco protocols. In this particular embodiment, the gateway 310 comprises a POTS handler 3401C, a VoATM handler 3402C, a V5.x handler 3401SP, and a Megaco handler 3402SP. The following tables summarize the operation of each handler 340 when an incoming call is received.
As indicated in Table 2, when an incoming call having a V5.x protocol is received, the V5.x handler 3401SP converts the ESTABLISH command to a generic Incoming Call command of the abstract information format, and passes this command to the basic call operation module 3501. The V5.x handler 3401SP also converts the L3 Address data to a generic Terminal ID, which is also passed to the basic call operation module 3501, along with the cadenced ringing signal. In some embodiments, the mapping of the L3 Address to the Terminal ID is carried out by referencing a provisioning database within the gateway 310.
When an incoming call having a Megaco protocol is received, the Megaco handler 3402SP converts the ADD command to a generic Incoming Call command of the abstract information format, and passes this command to the basic call operation module 3501. The Megaco handler 3402SP also converts the Termination ID data to a generic Terminal ID, which is also passed to the basic call operation module 3501, along with the ri-cad signal. As discussed above, in some embodiments, the mapping of the Termination ID to the generic Terminal ID is carried out by referencing a provisioning database within the gateway 310.
Once the input signal information has been mapped to the abstract information format, the information is converted from the abstract information format to the protocol-specific format required by the output signaling protocol, as indicated in Table 3. For example, if the incoming call is directed to a POTS terminal, then the POTS handler 3401C converts the Incoming Call command, the Terminal ID signal, and the cadenced ringing signal to successive Ring on, Ring off commands at the appropriate POTS terminal. If the incoming call is directed to a VoATM terminal, then the ISDN handler 3402C converts the Incoming Call command, the Terminal ID signal, and the cadenced ringing signal to a sequence to ring on, ring off commands at the appropriate terminal.
The protocol conversion process described above presents a number of distinct advantages over traditional approaches. For example, by performing an intermediate conversion to an abstract information format, the gateway 310 advantageously needs only a relatively small number (e.g., m+n) of protocol handlers 340 for the supported protocols 320, 330, rather than a relatively large number of bilateral conversion modules 240. In addition, by providing unified handling of common management operations, the gateway 310 advantageously provides a simplified, more intuitive interface for managing protocol-independent, application-level operations. These and other advantages will become apparent to those of ordinary skill in the art in view of the present disclosure.
Although this invention has been described in terms of certain preferred embodiments, other embodiments that are apparent to those of ordinary skill in the art, including embodiments that do not provide all of the features and advantages set forth herein, are also within the scope of this invention. Accordingly, the scope of the present invention is defined only by reference to the appended claims and equivalents thereof.
