MXPA00006729A - Virtual bearer channel platform for processing service requests received in the form of channel data - Google Patents

Virtual bearer channel platform for processing service requests received in the form of channel data

Info

Publication number
MXPA00006729A
MXPA00006729A MXPA/A/2000/006729A MXPA00006729A MXPA00006729A MX PA00006729 A MXPA00006729 A MX PA00006729A MX PA00006729 A MXPA00006729 A MX PA00006729A MX PA00006729 A MXPA00006729 A MX PA00006729A
Authority
MX
Mexico
Prior art keywords
transaction processing
support channel
platform
network
processing units
Prior art date
Application number
MXPA/A/2000/006729A
Other languages
Spanish (es)
Inventor
Frederick A Sherman
Ranga R Dendi
Timothy A Morgan
Robert Gary Leonard
Duke Bond
Original Assignee
Mci Communications Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mci Communications Corporation filed Critical Mci Communications Corporation
Publication of MXPA00006729A publication Critical patent/MXPA00006729A/en

Links

Abstract

A virtual bearer channel platform (150) includes a plurality of transaction processing units (161-164). Each transaction processing unit processes one or more service requests received as a call on a bearer channel. The call data is distributed to individual transaction processing units using a high-speed network such as a SONET-type network (215). In one embodiment, the standard SONET format is modified to eliminate fields which contain data of no significance to the present environment. In another embodiment, the standard SONET format, itself, is used. The platform includes a resource manager for allocating the newly received calls to individual transaction processing units. The resource manager (560) sets up outbound calls when requested by a transaction processing unit. A gateway interfaces (550) with the resource manager and the external communication network for assisting in call setup in both inbound and outbound directions.

Description

VIRTUAL SUPPORT CHANNEL PLATFORM FOR PROCESSING SERVICE APPLICATIONS RECEIVED IN THE FORM OF CHANNEL DATA Field of the Invention The present invention relates generally to the field of 'telecommunications, and more spically to a system and method for processing service requests. 10 Related Technique Voice or audio platforms (also known as voice or audio response units) are generally used to provide services by using the automated calling process. Commonly known examples of such services include the process of collect calls, operator-assisted calls, and sales transactions. In a typical scenario, the caller places a call to the platform to request a spic service. 20 The platform determines the desired service based on, for example, the number dialed by the caller and the information provided by the caller on a support channel. The platform directs the call to a request that operates in a transaction transactions. The Transaction Transactions executes a request to provide the service. An example of a ^^ - mw- < .-. »» "*, -? ^ *. - -to"-. * ~ * ~ Faa &AéfeüC: transactionaltransactions is a voice response unit. For example, the caller can dial 1-800- COLLECT (TO BE COLLECTED) to make a collect call processed by the platform. On the platform, a voice response unit (transactionaltransactions) is assigned to the incoming call. Once the call is determined to be a 1-800-COLLECT, the voice response unit activates the recorded message for the caller and records the information received from the caller. Information The previous one can include the name of the caller (that is, as articulated by the caller) and the telephone number to which you want to make the call (for example, by entering the necessary digits on the telephone keypad). Then the voice response unit will make a call from the platform to the person being called. Once this outgoing call is established, the voice response unit will activate recorded messages for the person being called to obtain acceptance of the call. The voice response unit will identify the person who is calling for the called party by activating the previously recorded voice of the person calling to identify themselves. The voice response unit will also ask the caller to indicate (through the use of the telephone keypad) or whatever you have available) if you accept the call. Finally, if -i'-áf-tU -2. the called party accepts the call, then somehow they connect the caller with the person they are calling to. Typically, voice response units receive and transmit calls through dedicated connections. Generally, the voice response units are connected to a selection number of bandwidth channels, such as the Tls, in a known manner. As is well known, a Ti channel contains twenty-four channels (DSOs). The dialogue between the caller and the voice response unit, or alternatively between the platform and the person being called, is carried out on one or more of the above channels. The channels can carry the voice or information of the data in a digital format. Unfortunately, on conventional platforms, the Tls are dedicated to the voice response units, and can not share the bandwidth. That is, each of the voice response units is assigned a fixed number of Tls for calls that enter the platform from the network, and also a fixed number of Tls for calls that come out over the network from the platform . Typically, the platform is designed in such a way that each of the voice response units has an equal number of Tls for incoming calls and for outgoing calls. In the previous example, the call 1-800-COLLECT input from the person who . . ,to. .. »l: a» &amp. "Ip" afc. . ^^. - t, », *. < «« & % * A * The "áJ8? FfiEB d¡ &" & ?? . is calling is on a dedicated input Ti, while the call to the called party is on a dedicated output Ti. However, this practice is extremely wasteful of the resources of the circuit. Most platform service requests do not require outbound Tls. The outgoing Tls are dedicated and can not be used for incoming calls. However, in order to provide adequate customer service, it is likely that the service platform provider has no other option than a dedicated connection. The above dedicated assignments of bandwidth can also lead to inefficiencies in the use of other platform resources. For example, the platform may have the power to process, but not the bandwidth required, to process a transaction. As a result, all components of the platform, specifically the voice response units, will not be used optimally. Another problem is related to the provision of signaling. In modern systems, the signaling network is separated from the switched voice network. It uses signaling to handle the arrangement of the call, to dismantle and process the information. This includes monitoring the state of the trunks, which indicate the arrival of an incoming call, the transmission route and destination signals, and so on. The signaling is handled separately from the current voice circuits to minimize the load on the voice circuits and to establish a more efficient network architecture.
COMPENDIUM OF THE INVENTION The present invention is directed to a specialized virtual support channel platform. A virtual support channel platform can control the conduction of the voice and the information of digital data on a support channel. The platform processes a service request received from a telecommunications network. The platform includes a plurality of transaction processing units. The previous one also includes a distribution network. The distribution network is coupled to a plurality of transaction processing units. The platform also includes a transverse connection controller. The transverse connection controller is coupled to the distribution network and the telecommunications network. The latter receives the data corresponding to the service request of the telecommunications network. It also provides the data received in the distribution network to one of the transaction processing units. The bandwidth in the distribution network is shared with the transaction processing units. More specifically, the platform is connected to the telecommunications network with one or more support channels identified by the circuit identification keys of the support channel (CICs). The support channels CICs specify a physical circuit where the data of a support channel will be conducted. The transaction processing units can process or transmit a service request. The distribution network provides communication with the transaction processing units by means of elements of a distribution network. The above elements are byte positions of a signal transmitted through the distribution network. Therefore, the cross connection controller couples one or more support channels to the distribution network. In a preferred embodiment, the platform has a resource manager. The resource manager controls how the transaction processing units gain access to the circuits of the distribution network. The previous administrator includes a state device to maintain a state of both support channels and the elements of the distribution network. For an entry service request, the resource manager retrieves the identity of the support channel (i.e., CIC) of a received signaling message * < ^ * a »¿faith.-" * from the telecommunications network The previous administrator transfers the support channel into elements of the distribution network by means of using the state device, then proceeds to determine which of the units for which the network is based. process will process the entry service request through the elements of the distribution network For an exit service request, the resource manager responds to a request from one of the transaction processing units. the resource manager assigns a support channel for the transmission of an exit service request. The resource manager transmits to the called person the identity of the available support channel by means of a signaling message through the telecommunications network. A Once the acknowledgment of receipt is received that the person being called is connected (from the telecommunications network), the resource manager moves the support channel to a circuit of the distribution network and instructs the detransactionstransactions to process the request for exit service using this distribution network. In a preferred embodiment, the platform has an access door. The gateway is a programmable protocol converter used to provide all signaling functions for the platform. Door access receives signaling messages from the network of . * ~ t * 43e > ±. ? . ^ ae: »r". • HSH *? '' - ^ - ¡t &sxe4 > »USb¡i < ? .'- telecommunication, and also transmits signaling messages to the telecommunications network. The gateway is the interface between the virtual support channel platform and the telecommunications network. For a signaling message received from the telecommunications network, the access door converts it to an internal message, in an internal protocol used by the platform. For example, the signaling message received may be the signaling of a common channel (CCS), which the access door converts to a TCP / IP message. Similarly, for a message in the internal protocol received from the platform (specifically the resource manager), the gateway converts it to a signaling message for transmission through a CCS network. Here, a TCP / IP message from the platform is converted to a CCS message.
CHARACTERISTICS AND ADVANTAGES The present invention provides a number of important features and advantages. The transaction processing units share the bandwidth in the distribution network, which acts as a shared driving bar between the transaction processing units. Since the connection is not dedicated, there is no need to waste support channels on the trunks used to process the service request.
In accordance with the foregoing, the invention allows the amplitude of the available band between the support channel network and the transaction processing units to be optimally utilized. For the same reasons, transaction processing units are not necessarily restricted by the number of channels available to receive or send data. Transaction processing units can be made to optimally process service requests. The separation of the signaling network and the support channels is of great importance to optimize the processing power of the platform. Since the platform is an intelligent device, the resources of the platform, especially the support channels, are used more extensively than in an ordinary voice response platform. The present invention independently handles the allocation and maintenance of the support channels used by the resource manager and the access gate to provide time tracks in a singular distribution network.
BRIEF DESCRIPTION OF THE FIGURES The present invention will be described with reference to the appended figures, wherein: Figure 1 is a block diagram illustrating a typical connection between a telecommunications network and a voice or audio platform. Figure 2 is a block diagram illustrating a telecommunications network used to employ the present invention. Figure 3 is a flow chart illustrating how a caller's call is transmitted to a jumper switch 130. Figures 4A, 4B and 4C are diagrams illustrating a standard SONET format and a modified SONET format used in accordance with the embodiments of the present invention. Figure 5 is a block diagram illustrating the virtual support channel platform of the invention. Figure 6 is a flow chart illustrating how the call of a bridge switch is connected to a transactionaldensactions in the virtual support channel platform. Figures 7A and 7B are flow graphs illustrating how the call of a transaction translator is connected to the person being called. Figure 8 is a flow chart illustrating how the caller is connected to the person they are calling, and the virtual support channel platform is released from the connection. Figure 9 is a block diagram illustrating a «-r *: modality with more than one SONET transverse connection controller and two or more distribution networks assembled in the form of rings. In the figures, reference numbers that are the same generally indicate that they are identical, functionally similar, and / or structurally similar. The figure in which an element appears first is indicated by the digit of the extreme left in the reference number.
DETAILED DESCRIPTION OF THE PREFERRED MODALITIES I. An Exemplary Environment II. One Dedicated Channel Connection A. Telecommunications Network B. Telephone Terminal C. LEC Switch D. Switch E. Bridge Switch F. Voice or Audio Platform 1. Call Processors 2. Transaction Processing Units III. The Present Invention A. Disadvantages of the Connection of the Dedicated Channels B. An Introduction C. Transmission of the Call to the Bridge Switch D. SONET Bar E. The Virtual Support Channel Platform i. SONET Distribution and Interface Network 2. SONET Transverse Connection Controller 3. Access Door 4. Resource Manager a. Maintain state of resources b. Incoming Calls c. Outgoing Calls d. Inaccessible or Failing Resources F. Establish an input support channel with a transaction processing unit. G. Establish an exit support channel with the person called. H. Release the Virtual Support Channel Platform I. Inaccessible or Failing Resources 1. Transaction Processing Units 2. Failure of the Processing Unit Transactions J. A Supplemental Modality IV. Conclusion I. Exemplary Environment The present invention is described in terms of a * s = - £ - i exemplary environment. In the exemplary environment, the originator of the call tries to make a collect call, for example, by dialing 1-800 -COLLECT. The call is routed through a telecommunications network to a voice or audio platform, specifically a virtual support channel platform that can process the digitized voice data. The platform has the transaction processing units, which are for example voice response units. On the platform, a transaction processing unit is assigned to the incoming call. The transaction processing unit, which determines that the call is a 1-800-COLLECT call, will play the recorded messages for the caller, and record the information received from the caller. That information may include the name of the caller (ie, as the caller itself says) and the telephone number to which the caller wishes to call (for example, by entering digits on the telephone keypad). The transaction processing unit will then make an outgoing call from the platform to the called party. Once this outgoing call is established, the transaction processing unit will play the recorded messages for the called party to effect the acceptance of the call. For example, the transaction processing unit can identify the caller by reproducing the previously recorded voice of the caller by identifying themselves. In addition, the transaction processing unit may ask the called party to enter a digit on the telephone keypad to indicate whether or not to accept the call. If the called party accepts the call, a bridge switch, which processes the incoming and outgoing calls from the call to the platform, will bypass the call between the calling party and the called party. When bridging callers together, the bridging switch disconnects the call connections with the platform. In other words, the bridging switch disconnects the incoming and outgoing branches of the call directed to, and from the platform. The description is provided in those terms solely for convenience. The invention is not intended to be limited to this exemplary embodiment. For example, the present invention can be used to support other types of calls that enter the platform (apart from the type calls 1-800 -COLLECT), which require processing by the transaction processing units. In fact, after reading the following description, it will be evident to the persons skilled in the relevant technique (s) how to implement the present invention in alternative modalities.
The present invention can be better understood by first describing the characteristics of a dedicated channel connection, followed by the features of the present invention, which overcomes the significant inconveniences of the dedicated channel.
II. A Dedicated Channel Connection Figure 1 is a block diagram illustrating a typical connection between a telecommunications network and a voice or audio platform. Figure 1 includes telecommunications network 100 and voice or audio platform 150.
A. Telecommunication network The telecommunications network 100 comprises a telephone terminal 110, a LEC switch 115, a switch 120, and a bridging switch 130. A voice or audio platform 150 comprises the call processors 160, 170, 180, and transaction processing units 161-164 (as well as transaction processing units that are shown but not marked). Each transaction processing unit receives 48 channels through two IT logs. The bridging switch 130 is connected to the voice or audio platform 150 by means of a high band amplitude channeling 140. The amplitude channeling of As &A high band 140 comprises numerous individual trunks. The telecommunications network 100 may include a conventional network employing signaling, specifically a CCS network. The telecommunications network 100 can be a private network (for example, telecommunications links, etc. owned and / or operated by private entities such as corporations). On the other hand, the telecommunications network can also be a public network or a combination of private and public networks. Next, the operation of the telecommunications network 100 and the manner in which a service request is processed are explained.
B. Telephone terminal The telephone terminal 110 may be a conventional telephone apparatus, comprising a transmitter and receiver, which invokes communications using DTMF signals, or any other instrument or machine capable of operating in a similar manner. The telephone terminal 110 may also be more sophisticated devices, such as a key telephone system and a private de-branching exchange.
C. LEC Switch The Local Exchange Carrier Switch (LEC) 115 is a switch that puts the telephone terminal 110 in tandem with an internal exchange bearer (IXC). An internal exchange carrier is more commonly known as a long-distance carrier, such as for example the MCI Telecommunications Corp. The telephone terminal 110 is located in a local access and transport area (LATA), which provides local telephone services by means of a local exchange carrier. The local exchange carrier uses one or more LEC switches 115 to route telephone calls locally, i.e., within the LATA. However, for long distance services the local exchange bearer routes the call to a special LEC 115 switch for long distance routing. In this case, the LEC switch 115 is known as a central office (CO) switch.
D. Switch The switch 120 is a IXC switch. The switch 120 tandem (or switches) the calls from the LEC switch 115 to another IXC switch, called a bridging switch 130. The switch 120 can be, for example, a Digital Multiplex Switch 250 (DMS-250 switch) available with the Nortel (Northern Telecom) Corporation.
E. Bridge switch The bridge switch 130, which is another IXC switch, provides a connection between switch 120 and voice or audio platform 150. Bridge switches are used to interconnect to any voice or audio platform. These allow service requests (including collect calls), which require processing through the transaction processing units, to be performed efficiently., located on these platforms. For the example of a collect call, this efficiency results in the ability of the bridging switch 130 to disconnect channels to the voice or audio platform 150, after the collect call is established. This will be explained further below. In addition, the bridging switch 130 can perform other important functions, such as providing billing services. Billing services are used to determine how much to bill for a phone call. A call 1-800, for example, requires special billing services, which handle IXCs in unique ways. Like the switch 120, the bridging switch 130 can be a DMS-250 available with the Nortel Corporation.
F. Voice or audio platform The voice or audio platform 150 comprises the 160, 170, 180 call processors. The call processors have the transaction processing units.
?TO . 161-164, as well as the "transaction processing units that are shown but not marked." In a dedicated channel connection, the number of logs entering and leaving each transaction processing unit is fixed. For example, each transaction processing unit can receive 48 channels through two IT logs, with 24 incoming channels entering each transaction processing unit 161-164, and 24 outgoing channels leaving through each processing unit from transactions 161-164. Incoming channels are used to receive calls that go into each transaction processing unit. Outgoing channels are used to make calls that leave each transaction processing unit. 1. Call processors The call processors 160, 170 and 180 represent systems that can establish the connection in the switching system in a well-known manner. By For example, as recognized by those of ordinary experience, the call processor 160 performs call set-up for calls arriving at the transaction processing units 161-164. 2. Transaction processing units Each of the transaction processing units 161-164 is a system capable of processing one or more types of service requests. Calls receivable are an example of a type of service request. Other examples include, but are not limited to, calls with a credit card, calls with the help of an operator, and calling card calls with charge. More than one transaction processing unit may be able to process the same type of service requests. These transaction processing units of similar function can be located in different call processors. An application can be associated with each of the types of service requests. The application is implemented as a combination of hardware, software, firmware, or the like. The application, when executed, performs the required tasks of the transaction processing unit. Those tasks include playing recorded messages for callers, and receiving data from callers. The recorded messages are transmitted through the logs to the callers. The data received from callers include messages spoken by the caller, and DTMF signals entered by a caller from the telephone keypad. Applications can use the recorded data to make decisions about the call, and to route the call, for example, to a called party. The transaction processing units may include voice or audio response units. As recognized by those of ordinary experience, a voice or audio response unit provides synthesized speech responses to DTMF signal inputs, processes calls based on information derived from computer-based search tables, information received from the callers, and the information that is carried with the incoming call. An example of a transaction processing unit, similar to transaction processing units 161-164, is what is known as a master control framework in the telecommunications industry. An exemplary master control framework is available with the Intervoice Company, 17811 aterview Parkway, Dallas, TX 75252.
G. High Band Amplitude Channeling A high band amplitude channeling is a trunk group comprising a number of individual trunks. Each trunk is a line of communication between two elements of the network. In Figure 1, the high band amplitude channeling 140 is shown by connecting the bridging switch 130 to the voice or audio platform 150. The high band amplitude channeling is distributed in a series of TI logs, with a pair of IT logs connecting to each unit of «& 2 transaction processing 161-164. As shown, each pair of Tls (which connect to a transaction processing unit) can carry enough frequency bandwidth for 48 channels, with each channel carrying data corresponding to a single voice channel. In exemplary mode, there is a dedicated IT for incoming calls to a transaction processing unit (ie, 24 channels), and a dedicated IT for outgoing calls from a transaction processing unit (ie, another 24 channels). As those of ordinary experience recognize, however, this failure is arbitrary and is not significant to the invention.
H. Signaling network A signaling network, such as the CCS network, can be used to provide call establishment and service for calls, these functions include monitoring the status of signaling links in use, indicating the arrival of an arrival incoming, transmit routing and destination signals, and other such important functions. The call setup is performed before the current call data of the telecommunications network 100 is transmitted over the voice channels, through the high band amplitude channeling 140, to the voice or audio platform 150.
Signaling networks are well known in the field of telecommunications, even with respect to voice or audio platforms. For a detailed understanding of an exemplary CCS network, specifically a Signaling System Signaling Network 7 (SS7), the reader is referred to "Signaling System # 7" (Travis Russell, ISBN 0-07- 054991-5, McGraw -Hill, New York, NY 10020), which is incorporated herein in its entirety as a reference. Although the CCS network is not shown in Figure 1, it is described below with respect to the present invention. However, it is important to note that the CCS network described below is used in a manner that is unique to the present invention.
III. The present invention A. Inconveniences of the dedicated channel connection There are a number of inconveniences with the dedicated channel connection. Because the Tls are dedicated to the transaction processing units 161-164, the transaction processing units 161-164 can not share the bandwidth. This is extremely wasteful of circuit resources. Most requests to the 150 voice or audio platform do not require outgoing Tls. Even so, the Telecom service provider may have no other option but to dedicate the same number of inbound and outbound Tls to each transaction processing unit 161-164. This is done to ensure that an incoming call to the voice or audio platform 150 requires an outgoing bypass, then this is available. The dedicated channel connection also wastes resources from the voice or audio platform 150. If the resources of the voice or audio platform 150 have the processing power, but not the bandwidth required, to process a call, then the units Transaction processing 161-164 are not used optimally. Another problem is related to the provision of signaling. Unfortunately, such intelligent devices as the voice or audio platform 150 do not conventionally separate the signaling and voice circuits, where there are dedicated connections between the voice circuits and the transaction processing units 161-164.
B. An Introduction Figure 2 is a block diagram illustrating the telecommunications network that is used to employ the present invention. The telecommunications network comprises the telephone terminal 110, the LEC switch 115, the switch 120, the database 125, the bridging switch 130, and a transfer point pair signaling (STP) 230.
In one embodiment, the database 125 may be the data access point (DAP) of MCI, although the database 125 may be any database recognized by those skilled in the art. The database 125 may be located externally to the switch 120 (i.e., an external database) or instead may be located inside the switch 120 (i.e., an internal database). The STP 230 is part of a CCS 220 network (i.e., in a mode where the CCS 220 network is an SS7 signaling network) which is used to establish a call before the call data is transmitted. Examples of CCS signaling in the CCS 220 network include (1) any ISUP signaling message from the ANSI (American National Standards Institute); (2) any ISUP signaling message from the ITU (International Telecommunications Union); and (3) any ISUP signaling message that is country-specific (ie, any variations of ISUP that vary from country to country). The STP pair 230 is a pair of redundant packet switches that receive packetized signaling information through the CCS network 220. FIG. 2 also includes a virtual support channel platform 250 and an associated database 240. The database 240 may be located externally to the virtual support channel platform 250 (ie, an external database) or instead, it may be located within the channel platform of ap5 * virtual me 250 (it is located within 2s6). say, an internal database).
C. Transmitting the Call to the Bridge Switch Figure 3 is a flow chart illustrating how the call is transmitted to the bridge switch 130. In step 302, an originating caller, using the telephone terminal 110, wishes to establish a collect call, in particular a collect call that will operate the virtual support channel platform 250. For example, the originating caller dials on the keypad of the telephone terminal 110 the number 1-800-COLLECT. A call is then originated from the telephone terminal 110. In step 304, the local exchange bearer transmits the call to the LEC switch 115. In the present embodiment, the LEC switch is a CO, and the call is transmitted therefrom to the same. an internal exchange carrier (not shown) in a well-known way. In step 306, the receiving internal exchange carrier routes the call to an IXC switch. Specifically, the internal exchange bearer routes the call to the switch 120 in a well-known manner. In step 308, the switch 120 accesses the database 125. The database 125 translates the number 1-800-COLLECT to a telephone number associated with the virtual support channel platform 250 (the destination number of the platform of virtual support channel 250). The database 125 also returns the important routing information for the call. The inventive signaling network includes all types of CCS networks recognized by those skilled in the art. In one embodiment, the inventive CCS network is an SS7 signaling network. A brief description of an SS / signaling network, specifically how it is used in the present invention, will facilitate a better understanding of the invention. For this description, SS7 signaling messages are described as having four layers, although layer 4 (user layer) can be divided into two layers. The first layer, Part of Message Transfer - layer 1 (MTP-Ll) defines the physical, electrical, and functional characteristics of the signaling data link, and the element to access it. The second layer (MTP-L2) defines the functions and procedures for, and related to, the transfer of signaling messages through the signaling data links. The functions of the MTP-L2 include the delimitation of signaling messages, the detection and correction of errors, and the detection of signaling link failures. The third layer (MTP-L3) provides the functions of the signaling network, to transfer the messages between the signaling points, which are nodes of the signaling network and are identified by a single point code. The function of handling the signaling message will ensure that the signaling messages that a particular user part originates at a signaling point (origin point) are sent to the same user part at the destination point, indicated by the user part. shipping user. The fourth layer for this area of interest is the User Part (ISUP) of the Integrated Services Digital Network (ISDN). The ISUP defines the protocol that supports the signaling functions that are required to provide voice and non-speech services. The ISUP is used to transport that information as the calling party number, and trunk management information. The first two fields of the ISUP are the Circuit Identification Code (CIC), followed by the Message Type (MT). The circuit identification code identifies the circuit (support channel) selected by the call processing on the originating switch. The MT defines a message from a set of messages that are used to support the establishment, dismantling, and administration of support channels. There are a variety of ISUP messages. The most common ISUP messages are the initial address message (IAM), the complete address message (ACM), the response message (ANM), the disconnection message (REL), and complete disconnection (RLC). There are other messages not listed here. (ANSÍ Tl-111/1995 and Tl-113/1995). In one embodiment, in addition to the destination telephone number of the virtual support channel platform 250, the switch 120 also uses the database 125 to retrieve a circuit identification code (CIC). This CIC identifies a support channel available between the switch 120 and the bridging switch 130. In another embodiment, the switch 120 determines the available support channel without using the database 125. In step 310, the switch 120 establishes a connection to the bridging switch 130. First, the switch 120 generates an initial address message and transmits it to the bridging switch 130, through the signaling network 220, via the STP 230 pair. The initial address message includes the circuit identification code, that is, identifying a support channel that is available between the switches. The initial address message also includes the destination number of the virtual support channel platform 250, and all the required routing information. Specifically, the initial address message has a CIC set to the trunk identifier (i.e., identifying the support channel), a source point code (OPC) set to the point code of the source switch (i.e., the switch 120). ) and a destination point code (DPC) set to the point code of the destination switch (i.e., bridging switch 130). After the call set-up is completed by means of the CCS 220 network, the call is routed to the bridging switch 130 through the available support channel.
D. SONET bus The present invention uses two protocol formats SONET (synchronous optical network) different in a distribution network (SONET bus) on the virtual support channel platform 250. The distribution network connects the transaction processing units in the virtual support channel platform 250. In one first mode, a standard SONET protocol is used. The standard SONET is a protocol for high-speed signals transmitted using circuit-switched synchronous multiplexing. The physical interfaces for SONET include synchronous transport signal frames (STS), and optical carrier (OC) frames. For a detailed understanding of the standard SONET format, the reader is referred to many publicly available sources, including "SONET and TI Architecture for Digital Transport Networks", Ulysses Black and Sharlene Waters, ISBN # 0-13 -447590-9.
A standard SONET framework includes a general transport load field, which comprises a general section load field and a general line load field, a general path load field, fill bytes, and a main portion to transmit data (in the form of virtual tributaries or VTs). In a telecommunications network, the trajectories comprise one or more lines, which in turn comprise one or more sections. A path is an end-to-end logical link between users. A line is a segment between two nodes, which are used to multiplex, synchronize, switch, and cross-connect the SONET signal. A section is a segment typically between regenerators and nodes, which is used to frame and locate communication failures. Therefore, the general path load field, the general line load field, and the general section load field are used to effect communications between their corresponding communications segments, i.e., paths, lines and sections. In this embodiment, a cross-connect controller SONET assigns each data 'of the support channel of the high-band amplitude channeling 215, to specific byte positions in the SONET bus. The SONET bus uses a cell format VT1.5, which operates at a speed OC-3. For operation at OC-3 speed, 28 VT1.5 cells are interleaved in a single STS-1 frame, and 3 STS-1 frames are interleaved in a ^ Sl &STS-3 frame. An STS-3 frame has 84 cells to carry channel data, and an additional 162 bytes that are used for general and filler loading. A single cell VT1.5 is the equivalent of 27 bytes of data. The 162 bytes (the equivalent of 6 cells) are used as follows: 81 bytes for a general transport load field (general section load and general line load fields); 27 bytes for a general trajectory load field; and 54 bytes for additional padding bytes. A single STS-1 has a general transport load field, which comprises a general section load field and a general line load field, which has 27 bytes (that is, equivalent to a single cell). However, since three STS-1 frames are interleaved to form a single STS-3 frame, the general transport load field of the resulting STS-3 frame comprises 81 bytes. The general section and line loading fields of the inventive STS-1 framework (i.e., interleaved in an STS-3 frame) can be better understood with reference to Tables 1 and 2 and Figures 4A and 4B. Figure 4A illustrates the bytes of a general load field of section 420, configured as 3-byte rows. These bytes are explained in Table 1. Similarly, Figure 4B illustrates the bytes of a general line load field 440, configured as 3-byte rows. These bytes are explained in Table 2. In Figure 4A, the first two bytes of the load generated from section 420 are the Al, A2 bytes, which are used for synchronization. Referring to Figure 4B, the first cell position (i.e., the position of the first cell carrying data of the channel) can be determined from the general overhead charge pointer bytes H1, H2. The positions of remaining cells are determined from the well-known intercalation technique.
Table 1. General Section Load Table 2 In the STS-3 framework of the present embodiment, the remaining 84 cells are used to carry data. Each cell has 27 bytes, 24 bytes to carry data from the channel and 3 bytes that act as general charge bytes of Virtual Tributary (VT). Each data byte contains a single support channel, so that a single cell "contains 24 support channels (that is, they correspond to an IT)." Communications through the SONET bus are made through frames successive frames Each successive frame has the same sequence of cells A single cell is designated for any communication on a given support channel Accordingly, a transaction processing unit on the virtual support channel platform 250 can find the channel of correct support of the SONET bus, by finding the appropriate cell In other words, each transaction processing unit will transmit and receive data in one or more assigned cells, corresponding to the support channels. General transport load and general packing load bytes are used for operations, administration and maintenance (OAM), consequently, this modality includes 84 cells which are used to carry support channels, 54 fixed padding bytes that are used as space fillers for the collation operation, and 81 bytes (for the general transport load) plus 27 bytes (for the general trajectory load) used for OAM.
Therefore, the bandwidth used is 155.52 MHZ (8000 frames / second x ((84 cells / frame x 27 bytes / cell) + 81 bytes + 27 bytes + 54 bytes) x 8 bits / byte), ascending to a speed OC-3. Data is transmitted in the SONET bus at speed OC-3, and interpreted as a standard VT1.5 format. A second embodiment of the present invention uses a modified SONET format. In the modified SONET format, it is recognized that because the SONET signal is transmitted in the closed cycle of the inventive SONET bus (distribution network .540), no overhead and fill load bytes are required. Therefore, in each frame the 162 additional bytes that are normally used for the general load and fill bytes are used as cells (that is, 6 cells) that carry data from the channel. Through this modification, this modality allows the use of 90 cells at a speed OC-3 (155.52 MHZ), against 84 cells. By using 90 cells, the mode can support 90 x 24 support channels, or 90 Tls. In addition, not having to deal with the general load fields makes this mode less intensive for the processor. As with the previous mode, frames (ie, 90 cells) are repeated 8000 times / second to support voice applications. Figure 4C illustrates a modified SONET VT1.5 format for this mode. This - modified SONET format is the same for a single cell as the standard format, but differs in the sense that 6 more cells are used in the frame. The SONET 400 frame repeats 8000 times per second. A cell 402 has 27 bytes ("octets"). Of these, 24 bytes 408 correspond to the 24 support channels of an IT pipeline.
Therefore, each cell 402 has 24 bytes to carry data, with each of these bytes carrying a support channel. The remaining three bytes in each cell 402 are bytes of general load VT. As shown, of the remaining three bytes in cell 402, one byte 404 is used for synchronization (it always has the value 7E), the second byte 406 is used as a cell identifier (it has values in the range of 0-89 ), and the third byte is not used. Since ninety cells together form the frame 400, the total bandwidth used is 155.52 MHZ (8000 frames / second x 90 cells / frame x 27 bytes / cell x 8 bits / byte), that is, a speed OC -3. Therefore, the data is transmitted in the SONET bus at an OC-3 speed, but the content is interpreted in accordance with the modifications described herein. Although the virtual support channel platform of the present invention is described with reference to standard and modified SONET formats, it will be apparent from the description provided herein, that alternative modalities can be implemented, using other formats compatible with SONET (for example). example, OC-1, OC-12, OC-48, etc.) with other standards and transmission speeds, depending on the appropriate applications. The manner in which the virtual support channel platform of the present invention uses the standard and modified VT1.5 standard will be made clearer by the description below.
E. The virtual support channel platform Figure 5 is a block diagram illustrating the virtual support channel platform 250 in detail. The virtual support channel platform 250 includes a SONET 510 cross connect controller, call processors 520A and 520B having SONET interfaces 521, 531, transaction processing units 525, 535, a network of distribution 540, a gateway 550, a resource manager 560 and a transmission control protocol / internet protocol (TCP / IP) network 570. For the present invention, the transaction processing units 525, 535 do not are limited to processors such as voice response units. For example, in one embodiment, the transaction processing units are individual modems or modems banks. These modems can function as access switches, providing access to one or more additional networks. By For example, the banks of the modems 525, 535 can provide access to an asynchronous transfer mode (ATM) network or a frame relay network, which in turn provides internal access through an internet service provider ( ISP). 25 The virtual support channel platform 250 is will describe how it operates with the communications network 100 of Figure 2. However, it should be understood that the virtual support channel platform 250 can be adapted to operate with other types of external networks, without departing from the scope and spirit of the present invention. It is also important to note that the inventive virtual support channel platform 250 does not necessarily correspond to what is recognized in the art as a virtual support channel platform, and is provided herein solely to provide ease of understanding. For example, platform resources (e.g., transaction processing units 525, 534, access gate 550, resource manager 560 and SONET 510 cross connect controller) can be located at large geographic distances one of the other, in such a way that the resource would not be considered part of what is commonly understood to be a "platform". In accordance with the above, the virtual support channel platform will be defined by the functional relationships between the resources as provided herein, and not any current concepts of a virtual support channel platform. 1. Distribution Network and SONET Interfaces In a preferred embodiment, the distribution network 540 is a SONET bus. The SONET busbar ', JiSU & aɡ,% ...- T i &t transports support channels between the bridging switch 130 and the transaction processing units 525, 535. In other words, one can think conceptually of the SONET bus as a frame structure for support channel signals arriving at the virtual support channel platform 250 from the high band amplitude channeling 215, and for the support channel signals that exit through the amplitude channelization of 215 high band from the 250 virtual support channel platform. Inside the virtual support channel platform 250, the transaction processing units 525, 535 can add data to, or remove data from the SONET bus, using the SONET interfaces 521, 531, respectively. Therefore, the SONET bus is effectively a SONET cycle that traverses all of the transaction processing units 525, 535 of the virtual support channel platform 250. The signal of the support channels that arrive through the channeling of High bandwidth 215 is multiplexed by time division to form the SONET bus. As noted, a standard SONET format signal or a modified SONET format signal can be used. 2. Transverse connection controller SONET The cross-connect controller SONET 510 is coupled to the Tls of the high band amplitude channeling 215 on one side (outside the virtual support channel platform 250), and to the distribution r 540 on the other side (inside the virtual support channel platform 250). The SONET 510 cross-connect controller is a multiplexer and demultiplexer. For example, the cross connect controller SONET 510 can be an add-on multiplexer (ADM). The cross-connect controller SONET 510 multiplexes by time division the data coming from the high band amplitude channeling 215. It also demultiplexes by time division the data going back through the high band amplitude channeling 215 This provides an interface between the two sides (ie the high band amplitude channeling 215 and the distribution network 540) to transfer the data from the support channel from one side to the other, while conforming to the standards of the interface on the respective sides. 3. Access door Access gate 550 is a programmable protocol converter that handles all signaling functions for the virtual support channel platform 250. The access gate 550 may, for example, be a combination of hardware and software implemented in a computer system that implements an operating system (for example, the Unix Operating System). Although access door 550 is described in this section, it operates as described more fully below in the description of Figures 6-8. The access gate 550 receives the CCS messages arriving through the CCS 235 line. This transforms a received CCS message to the TCP / IP protocol, and generates a corresponding TCP / IP message. This then transmits the generated TCP / IP message, through the TCP / IP network 570, to the resource manager 560. In the preferred embodiment, the TCP / IP network 570 is a type of Ethernet network. In one embodiment, the generated TCP / IP message uses the proprietary MCI Switch Protocol (MSP). However, as recognized by those of ordinary experience, any type of similar protocol can also be used. For example, any byte-oriented protocol, or any protocol defined by the use of abstract syntax notation 1 (ASN.l), can be used. Examples of protocols include, but are not limited to, Enterprise Computer Telephony Forum (ECTF) S.200 X.25, SNA, ITU Q931. The access gate 550 also receives the TCP / IP messages transmitted from the resource manager 560 through the TCP / IP network 570. As illustrated in the description that follows, in response the access gate 550 can generate and transmit then a corresponding CCS message through the CCS line 235. The access gate 550 performs all the timing functions required by the CCS protocol and the TCP / IP protocol. It also handles all CCS flow control, 5 overhead processing, and management activities that require both the CCS network and the 560 resource manager. Those of ordinary experience will notice that the 550 access gate can perform a similar function for 10 protocols apart from any specific CCS protocol and the TCP / IP protocol. The reason is that a primary importance of the access gate 550 is to act as a conduit between the resource manager 560 and the CCS 220 network. 4. Resource Manager Resource manager 560 is a key component of the present invention. In a preferred embodiment, this comprises a combination of hardware and software implemented in a computer system using the System Operative Unix. Although this section describes resource manager 560, its functions are described more fully later in the description of Figures 6-8. '- ^ f ,, a. Maintaining the status of resources A key function of the 560 resource manager is the maintenance of the state information about the elements of the virtual support channel 250 platform. This information is quickly stored in, and retrieved from, a base of 240 internal or external data. For example, that accessible database is a data access point (DAP) of MCI, although the database 240 may be any database that is recognized by those skilled in the art. The resource manager 560 maintains the status of each support channel that enters the virtual support channel platform 250, through the high band amplitude channeling 215. It also maintains the status of each support channel that leaves the channel. the virtual support channel platform 250, through the high band amplitude channeling 215. The resource manager 560 determines the status of the incoming support channel by determining which support channels enter the SONET transverse connection controller 510 (from the high band amplitude channeling 215) are available, and which of these support channels are in use. similarly, the resource manager 560 determines the state of the outgoing support channel by determining which support channels that come out of the SONET 510 transverse connection controller are available, and which of these support channels are in use.
The resource manager 560 maintains the present state and the substantive status of each transaction processing unit 525, 535. For example, resource manager 560 is aware of which transaction processing units are occupied, and which are available. This may also be aware of how long a given transaction processing unit 525, 535 has been in use. In addition, the resource manager maintains knowledge of which transaction processing units 525, 535 can process a call that enters the virtual support channel platform 250. For example, resource manager 560 determines which transaction processing units 525, 535 can process a call 1-800-COLLECT. This includes knowing if a given call requires special processing. For example, if the destination number is a 1-800 number, the number can be moved to different numbers, depending on the time of day, and so on. As with other data, the resource manager 560 obtains this information by accessing an internal or external database, such as the database 240. Other special processing requirements include connecting to an operator as specified by the database. data, or provide additional voice prompts before returning control to the transaction processing unit 525, 535. b. Incoming Calls When a service request enters the platform, through the CCS 235 line, the access door 550 informs resource manager 560 of the service request, .by sending a message. The resource manager 560 determines, by this message, which support channel the data is entering. This then assigns the data to an available transaction processing unit 525, 535 capable of processing the call. By determining which transaction processing unit 525, 535 to direct an incoming call, resource manager 560 performs load balancing (also called load sharing). For example, based on a pre-determined or real-time calculation, the resource manager 560 may distribute the incoming call to the transaction processing units 525, 535, such that the transaction processing units 525, 535 have an equivalent use of the processor, that is, for processing efficiency. In a preferred embodiment, the resource manager performs load balancing by maintaining the path of the 'present charge' in each transaction processing unit 525, 535. The present load is at3 & xA < tt l-üfa a & n - *? Ea «£ .- - *" * "> a * jiz *; it can measure as a function of a number of variables. A variable is the fraction of the available processing energy that is used in a predetermined amount of time in the recent past. The fraction of the processing power can be determined, for example, by using the utilities provided by the operating system that supports the transaction processing units 525, 535. Another variable is the number of service requests assigned to the unit of transaction processing 525, 535. A third variable is the nature of the service requests assigned to transaction processing units 525, 535. c. Outgoing Calls In some cases, the transaction processing units 525, 535 will need to make an outgoing call from the virtual support channel platform 250. For the example of a call 1-800-COLLECT, the transaction processing unit 525 that receives the call will first record the information of the caller, for example, the name of the caller and the telephone number of the party called. Then, the transaction processing unit 525 will need to call the called party, in order to verify the acceptance of the call, and complete the connection between the caller and the part that is called. V 'This call derivation (to the called party) is a call directed outside the virtual support channel platform 250. When the transaction processing unit 525 wishes to make an outgoing call, it reports it to the resource manager 560. The resource manager 560, in turn, selects a support channel available for the outgoing bypass, through the high band amplitude channeling 215. This sends this information to the access gate 550, the which uses the CCS 220 network to connect it to the part that is called. The outgoing derivation of the call is then transmitted through the available support channel, selected by the resource manager 560. d. Unavailability or resource failure The 560 resource manager also handles the unavailability or failure of resources. If none of the transaction processing units 525, 535 are available to process the incoming call, the resource manager 560 can put the call in a linear list, so that it can be processed by the next available transaction processing unit. . Resource manager 560 may also park the call in an alternative transaction processing unit, which reproduces pre-recorded messages indicating a delay to the caller. - If the call is parked, it is also placed in a linear list. until the next appropriate transaction processing unit becomes available. If it is determined that the platform can not support the call, the resource manager 560 may send a disconnect message (eg, REL) to the bridging switch 130, requiring the bridging switch 130 to disconnect the call. The bridge switch 130 will send back a message acknowledging the disconnection. The platform is self-healing by making use of the knowledge about the processing units of failed transactions. In response to that knowledge, the 560 resource manager will update its database. If a transaction processing unit becomes inactive during the processing of a call, it will notify the resource manager 560. In turn, the 560 resource manager will reassign the call to a different transaction processing unit in the virtual support channel platform 250. If any of the circuit identification codes entering (or leaving) through the high band amplitude channeling 215 are lost, the 560 resource manager will update its status in accordance with that . For example, the 560 resource manager will update its database to indicate the condition. Subsequently, the functions of the resource manager are described more fully.
F. Establishing an incoming apo channel with a transaction processing unit Figure 6 is a flow diagram illustrating how the call of a bridging switch 130 is connected to a transaction processing unit 525 on the trading platform. virtual support channel 250. In step 602, the bridging switch 130 examines the initial address message transmitted from the switch 120, and determines that the connection to the virtual support channel 250 platform must be made. The bridging switch 130 locates an available support channel that goes to the virtual support channel platform 250. This is a support channel available along the high band amplitude channeling 215. Concurrently or after the same, in step 604 , the bridge switch 130 also assembles its own IAM for transmission to the virtual support channel platform 250. This IAM includes the designation of the selected support channel (i.e. , the circuit identification code), the code of the destination point of the virtual support channel platform 250, and other important routing information. The initial address message is transmits through the signaling network 220 together with the other signaling information. For example, the initial address message (more correctly the CCS message containing the initial address message of the ISU "*" ") will include the selected support channel (ie, the circuit identification code), an OPC field set to the point code of the bridging switch 130, and a DPC field set to the point code of the virtual support channel platform 250. The signaling message CCS is transmitted to the STP 230 through the signaling trunks 235. From the STP pair 230, the CCS message is transmitted to the virtual support channel platform 250. In step 606, the access gate 550 receives the CCS message (the initial address message) from the STP 230 pair. The gate 550 is a protocol converter, which converts the CCS message of the particular CCS protocol to, for example, a TCP / IP protocol, the TCP / IP message is transmitted over the TCP / IP network 570, which can be a Ethernet network, to the managed r of resources 560. In step 608, the resource manager 560 extracts the circuit identification code from the TCP / IP message. The resource manager 560 then moves the circuit identification code, using an internal or external database 240, to determine where the data in the SONET bus is located.
Specifically, the resource manager 560 determines the identifier of cell 406 (the second byte) and the position of the support channel inside the cell, which is one of the 24 channels of that cell. At step 610, resource manager 560 uses the called party number, extracted from the initial address message, to determine which transaction processing unit 525 (or 535) will receive the call. This number of the called party is the number which returns the database 125, which represents a translated version of the number 1-800-COLLECT. Again, the resource manager can perform a search in the database 240, to determine the correct transaction processing unit 525. 15 By allocating this received service request to an appropriate transaction processing unit 525, 535, the resource manager 560 maintains an active list of which transaction processing units 525, 535 have the capability to process which types of calls.
This active list can be maintained in an internal or external table (for example, database 240), which can be accessed quickly by the 560 resource manager. For example, for calls 1-800-COLLECT, the resource manager 560 must have knowledge of which units of 255 transaction processing 525, 535 can process the calls of the type receivable. The resource manager 560 can also perform load balancing by determining which transaction processing unit 525, 535 will process a call. This is done in such a way that the transaction processing units 525, 535 are not unduly loaded, for the most efficient use of these resources. By achieving load balancing, resource manager 560 maintains the path of 'present load' in each transaction processing unit. The present load can be measured as a function of many variables. A variable is the fraction of the processing power that is available. Another variable is the number of service requests assigned to the transaction processing unit 525, 535. A third variable is the nature of the service requests assigned to the transaction processing unit. In step 612, the resource manager 560 then transmits a call signal offered to the appropriate transaction processing unit 525. As noted, each support channel that enters the virtual support channel platform 250 in the SONET 510 transverse connection controller, enter through a support channel. Resource manager 560 is aware of the availability of all support channels entering and leaving the virtual support channel platform -250, by accessing an external or internal database 240. Each support channel is assigned to a specific bit position within the frame of the SONET bus, which can be referred to as a SONET circuit or a distribution network circuit. Therefore, based on the support channel of the received call, the resource manager 560 designates in the offered call signal, which bit positions (or SONET circuit) the transaction processing unit 525 will use to access the incoming data . Here, the transaction processing unit 525 is one that is available, and is capable of processing a 1-800-COLLECT call. In step 614, the transaction processing unit 525 establishes a connection to the SONET circuit designated by means of the call processor 520A. Determining that the call is a 1-800-COLLECT call, the transaction processing unit 525 then plays one or more messages (or prompts) recorded requesting information from the caller. The recorded message is followed by the activation of the transaction processing unit 525 and the call processor 520A to receive the caller information, which is either spoken or typed within the telephone terminal 110, followed by the recording of the information through the transaction processing unit 525. For example, the caller may be asked for the name of the caller, who records the transaction processing unit 525 when the caller says so. After this, the person in charge is asked to type in the number being called, which records the transaction processing unit 525 as a series of double-tone multi-frequency signals (DTMF). The communication established between the caller in the telephone terminal 110 and the transaction processing unit 525 is through a bidirectional line.
G. Establishing an exit support channel with the called party Figures 7A and 7B are flow charts illustrating how the call is connected from a transaction processing unit 525 to the called party. In step 702, once all the information of the caller is gathered, then the transaction processing unit 525 transmits the information to the resource manager. The resource manager 560 is aware of the availability of all support channels arriving and departing from the virtual support channel platform 250 by means of accessing the database 240. In step 704, the resource manager 560 • ^ ^ á ^ r ^ ii hr- then select a available SONET circuit, that is, an empty cell in the SONET bus, in which to make the outgoing derivation of the call. This is the derivation of the call that leaves the virtual support channel platform tu * 250. In accordance with the above, in step 706, the resource manager 560 sends a call to access gate 550 message. This message is transmitted over the TCP / IP network 570. In step 708, the gateway uses the information transmitted from the call message to generate a corresponding CCS message. Specifically, the access door 550 generates an initial address message, which includes the number of the called party (the number the caller calls) and the available support channel. An IAM message is transmitted to the bridging switch 130, which includes the available support channel (i.e., CIC), an OPC set to the virtual support channel platform 250 point code, and a DPC set to the point code. of the bridging switch 130. In step 710, the bridging switch 130 transmits the message to the called party. As recognized by those of ordinary experience, the party called can be located in many ways. The bridging switch 130, in combination with the CCS network, must transmit the * call to an appropriate LEC switch (specifically a CO switch), which will locate the called party. For example, the call is transmitted to one or more switches, one of which may have a connection to the LEC switch of the part to which it was called. The LEC switch, which operates inside the LATA of the called party, transmits the call to the called party. In step 712, the complete address (ACM) and answer (ANM) messages are sent back to access gate 550 from the network. For example, after the initial address message is received in the LEC switch, an ACM is transmitted back to access gate 550, through the CCS 220 network. Subsequently, when the called party answers the telephone (pick-up), an ANM message (an ISUP message) is transmitted back to the access door 550, through the CCS network 220. In step 714, after the access door 550 receives the message ANM , this sends a message connected, through the TCP / IP network 570, to the resource manager 560. (This informs the resource manager 560 that a connection has been established through an outgoing support channel to the party to the that it's called) . In step 716, the resource manager 560 moves the support channel, using the database 240, to determine where the outgoing messages should be placed in the SONET bus. Specifically, the administrator of i-tfiwioatat .- "* ^ ts 5 # resources 560 determines the identifier of cell 406, and the position of the support channel inside the cell.In addition, the resource manager 560 informs the transaction processing unit 525 the position in the SONET busbar to which the outgoing derivation of the call corresponds.The resource manager updates the status.In step 718, the transaction processing unit establishes a connection to the called party, using the SONET circuit (the designated channel in the SONET bus bar) by means of the call processor 520A. The transaction processing unit 525 then reproduces one or more recorded messages (or indicia) informing the called party about the collect call, and provides the called party the opportunity to accept or decline the call. The recorded message is followed by the activation of the transaction processing unit 525 and the call processor 52OA to receive the caller information, which is either spoken or typed within the telephone terminal 110, followed by the recording of the information through the transaction processing unit 525. For example, the transaction processing unit 525 plays a pre-recorded message, informing the called party: "has a collect call from", followed by the voice recorded from the caller saying in his own voice his name, such as "Timothy". Then the person called is given the opportunity to accept or decline the call by typing a digit, indicating "Yes" or "No". The transaction processing unit 525 will accept the response of the called party to determine whether or not to provide a connection between the callers. The communication established between the transaction processing unit 525 and the called party is through a bidirectional line. If the call is not accepted, the transaction processing unit 525 can also inform the caller of the rejection of the called party to accept the call. In this scenario, the call is disconnected. The transaction processing unit 525 will notify the resource manager 560 of the need to disconnect the call. It will also transmit a message to the access door 550 that the disconnection is required. The access gate 550 will send to the bridging switch 130 REL (disconnection) messages through the CCS 220 network. The bridging switch will send back an RLC message (complete disconnection) to verify the disconnection of the call. The access gate 550 then notifies the resource manager 560 of the disconnection, after which the resource manager 560 will update the database 240, and store the state of the support channels. ? «Í¿ -ZlWt e ^.
Sj? In step 720, when the called party accepts the call, then the transaction processing unit 525 transmits a message indicating this condition to the resource manager 560.
H. Disconnecting the virtual support channel platform Figure 8 is a flow diagram illustrating how the caller is connected to the called party, and the virtual support channel platform is disconnected. 250 of the connection. This occurs if the wing party that is called accepts the call. In step 802, the resource manager 560 sends a bridging message through the TCP / IP network 570, to the access gate 550. The bypass message includes the circuit identification codes of both the incoming connection (ie say, via the support channel) to the transaction processing unit 525 from the caller, as of the outgoing connection (i.e., via the support channel) from the transaction processing unit 525 to the party which is called. The bypass message informs access gate 550 to transmit a FAR bypass message, which identifies the two support channels. In response, the access gate 550 sends the bridging message FAR to the bridging switch 130.
In step 80.4, the bridging switch 130 receives the bridging message FAR, identifying the incoming and outgoing branches of the call. In response, the bridging switch 130 bridges the two branches of the call, that is, between the person who calls and the bridging switch 130, and between the bridging switch 130 and the called party. The bridging switch disconnects the support channels that go to the transaction processing unit 525 from the bridging switch 130, and the support channel that leaves the transaction processing unit 525 that exits to the bridging switch 130. In In step 806, a disconnect message (REL) is transmitted through the CCS network 220. Specifically, the bridging switch 130 transmits a REL message to the access door 550 of the virtual support channel platform 250. In step 808, the access gate 550 informs the resource manager 560 (through the TCP / IP network 570) that the two support channels have been disconnected. In response, the resource manager 560 updates the database 240, to indicate that the two support channels are once again available for further communication. In step 810, resource manager 560 informs access gate 550 of the disconnection (i.e. i ^ fe the receipt of a message indicating the disconnection). In response, the access door 550 transmits a complete disconnect message (RLC) back to the bridging switch 550, indicating that the disconnection has been completed. 5 I. Unavailability or failure of resources 1. Unavailable transaction processing units It is possible that when a request for a transaction is received service (i.e., the initial address message) on the virtual support channel platform 250, no required transaction processing unit 525, 535 is available. As an example, the resource manager 560 determines that none of the processing units of transactions 525, 535 is available. As another example, the resource manager 560 determines that no transaction processing unit 525, 535 capable of handling this particular incoming call is available. As an option, the 560 20 resource manager can linearize the incoming call, and wait for an available transaction processing unit. As another option, resource manager 560 can park the incoming call in another transaction processing unit. This alternative transaction processing unit 25 will provide bit positions in the bar SONET collector, to play a recorded message for the caller. For example, the alternative transaction processing unit can play the message: "Sorry, but all circuits are busy, please wait," or instead a musical greeting. The 560 resource manager will place the service request in a linear list. In previously designated time units, the resource manager 560 will verify the status of the required transaction processing unit 525, i.e., the transaction processing unit that can process the call. When the required transaction processing unit 525 becomes available, resource manager 560 will transfer the call to it for processing, by means of sending a call message offered to it, as with any other call. 2. Failure of the transaction processing unit Transaction processing unit 525, 535 may fail. In this case, the resource manager 560 will change the call to another transaction processing unit on the same virtual support channel platform 250.
J. A complementary modality ^ S & '"* Figure 9 is a block diagram illustrating a complementary mode. This embodiment illustrates (1) how a virtual support channel platform can have more than one SONET transverse connection controller, and (2) how two or more distribution networks can be joined together, in the form of rings. The local exchange carrier 910, the local exchange carrier 912 and the local network MCI 914 provide communications to the SONET network OC-24 970 (ie, a distribution network), by means of support channels in the channeling of high bandwidth 920, 922 and 924, respectively. These support channels are respectively multiplexed over ADMs 930, 931 and 932. Accordingly, the ADMs 930, 931 and 932 serve as SONET transverse connection controllers 15, providing access to the SONET 970 network. An access door is illustrated SS7 940, which provides the protocol conversion function for signaling messages directed between the SS7 960 network and a TCP / IP network 950 of platform. One or more resource managers (not shown) can manage the resources of a virtual support channel platform defined by the access gate SS7 940, the ADMs 930-933, the TCP / IP network 950 and the SONET 970 network. Although an SS7 960 network and the elements of the network using corresponding SS7 940, 942, 946 and 948, is you can use any CCS network and the corresponding elements, as will be recognized by those skilled in the art. Similarly, although the SONET 970, 980 networks are illustrated, any distribution network can be used, as will be recognized by those skilled in the art. The ring interface 942 connects the SONET OC-24 970 network to the much higher speed SONET OC-192 network (ie, another distribution network). The ring interface 942 itself comprises a time division multiplexer (TDM) and a corresponding processor, as well as a SONET interface (not shown). The ring interface 942 accepts the bytes of the data that enters it in an incoming path (ie, from the SONET network 970), and transmits these bytes in an outgoing path (i.e., over the SONET network 980). For the incoming path, a processor will place the data bytes from the SONET interface (interconnecting with the SONET 970 network) on a TDM busbar. For the outgoing path, a processor will place the same data bytes of the TDM busbar over the SONET interface, interconnecting with the SONET network 980. The ring interface 942 performs signaling functions similar to the inventive access gate (as described above). above), to determine the locations of the data bytes in the SONET 970, 980 networks, and therefore connects to the SS7 960 network. The 946 and 948 ring interfaces can perform • £ ß f t * A - a similar function as the ring 942 interface, providing access to additional distribution networks. In addition, each of the 942-948 ring interfaces can provide access to more than one of the other distribution networks, by performing the same function of inward trajectory, outward trajectory in multiple distribution networks, with messages of signaling companions. In the latter case, ring interfaces 942-948 are more appropriately called "central interfaces".
IV. Conclusion Although different embodiments of the present invention have been described above, it should be understood that these have been presented by way of example only, and not by way of limitation. Therefore, the spirit and scope of the present invention should not be limited by any of the exemplary embodiments described above, but should be defined solely in accordance with the following claims and their equivalents. "ÁUTÍ1"! »J * *» * - **. S *? > «í! ß? M0WM? Mií1 -, s * - *. ^« Rf and jggts. ^ J¿. ^

Claims (16)

1. A virtual support channel platform for processing a service request received in a communication network, the above virtual support channel platform comprising: a plurality of transaction processing units; a distribution network coupled to the aforementioned transaction processing units; and a transverse connection controller coupled to the above said distribution network of this communication network, the previous transverse connection controller that receives the data corresponding to the previous service request of the previous communication network and that provides the data received in the above distribution network to one of the above plurality of transaction processing units, wherein the bandwidth of the previous distribution network is shared by a plurality of the above plurality of transaction processing units.
2. The virtual support channel platform according to claim 1, wherein the above distribution network comprises one of: a standard SONET distribution network; Y ^ - ^ ^ ** f ^ - a modified SONET distribution network.
3. The virtual support channel platform according to claim 1, further comprising a resource manager for locating the service request 5 received at one of this plurality of transaction processing units.
4. The virtual support channel platform according to claim 3, further comprising an access door for interconnecting with this network of 10 communications to provide a connection between a support channel in which the previous service request was received and one of the above plurality of transaction processing units to which the previous service request was placed.
5. The virtual support channel platform according to claim 4, wherein the above communication network comprises a common channel signaling network (CCS).
6. The virtual support channel platform of 20 according to claim 4, wherein the above communication network includes a plurality of support channels including said support channel in which this service request is received, wherein said connection controller Transversal sends the received data to the mentioned channel of «Gs. *» ..- * ^ ,. support in which the service request is received from this transaction processing unit. The virtual support channel platform according to claim 6, wherein the above distribution network is implemented by means of using a modified SONET-type protocol, wherein said modified SONET-type protocol is defined by a plurality of frames. , with each of said frames comprising a plurality of bytes, wherein the data corresponding to each of said support channels is dedicated to be transferred to previously determined bytes within each of said frames, and in wherein said transverse connection controller provides the data corresponding to this service request in the bytes dedicated to said support channel in which this service request is received. 8. A method for processing a service request received by a virtual support channel platform in a communication network, the above virtual support channel platform including a plurality of transaction processing units, the above method comprising the steps of: receiving the data corresponding to this service request; sending the data to one of the plurality of transaction processing units that a distribution network uses, where this distribution network is shared with a plurality of this one of transaction processing units; and processing this service request in this plurality of transaction processing units. The method according to claim 8, further comprising the steps of: distributing this service request to one of this plurality of transaction processing units used by a resource manager. The method according to claim 9, wherein this distribution network is implemented by using: a standard SONET distribution network; and a modified SONET distribution network. The method according to claim 10, further comprising the steps of: receiving an indication of arrival of the service request and an identifier of a support channel of an access door, and sending this identifier of the door of access to this resource manager. 12. The method in accordance with the claim ^^^^^ ~ ^^^^^^^ * ^^ ^ ^^^^^^^ J & £ ^ ^^ 11, which also includes the steps of: sending the resource manager to identify the support channel and an indication of the transaction processing unit which processes the service request. 13. A virtual support channel platform connected to a communications network with one or more support channels, the virtual support channel platform comprising: a plurality of transaction processing units for processing or transmitting a service request; a distribution network that provides communication with the transaction processing units within the virtual support channel platform; and a cross connection controller for coupling one or more support channels to the distribution network. 14. A virtual support channel platform, according to claim 13, wherein the service request is an incoming service request received by the virtual support channel platform of the communication network. 15. A virtual support channel platform, according to claim 13, wherein the service request is an exit service request received by the virtual support channel platform of the * communications network. ssae, 16. A platform virtual support channel, according to claim 13, which also comprises: a resource manager to control the access of the transaction processing units to the distribution network and to maintain state of the channels of support and the distribution network. A virtual support channel platform (150) includes a plurality of transaction processing units (161-164). Each transaction processing unit processes one or. more service requests received as an ethical call? a support channel. The call data is distributed to the individual transaction processing units using a high-speed network, such as a SONET-type network (215). In one modality, the standard SONET format is modified to eliminate the fields that contain data of no significance for the present environment. In another mode, the same standard SONET format is used. The platform includes a resource manager to assign newly received calls to the individual transaction processing units. The resource manager (560) establishes external calls when this is requested by a transaction processing unit. A gateway is interconnected (550) with the resource manager and with the external communication network to assist in establishing calls both in the inward and outward direction. '* - f * 0t íí¿iííí? A & gfi? s? s r. rjp ~ -
MXPA/A/2000/006729A 1998-01-07 2000-07-07 Virtual bearer channel platform for processing service requests received in the form of channel data MXPA00006729A (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09004153 1998-01-07

Publications (1)

Publication Number Publication Date
MXPA00006729A true MXPA00006729A (en) 2001-12-04

Family

ID=

Similar Documents

Publication Publication Date Title
US6047005A (en) Virtual bearer channel platform for processing service requests received in the form of channel data
RU2189706C2 (en) System and method ganging up local communication facility
EP0976255B1 (en) Signaling network gateway
RU2210189C2 (en) System and method to guarantee updated services for telecommunication call
EP0815703B1 (en) Device for adapting narrowband voice traffic of a local access network to allow transmission over a broadband asynchronous transfer mode network
US6064653A (en) Internetwork gateway to gateway alternative communication
EP0989771B1 (en) Transit trunk subnetwork system
US6208657B1 (en) Programmable gateway for a virtual bearer channel platform
EP0616478B1 (en) Self-aware communication network with automatic configuration
JPH1051470A (en) Merging of switching function and cross-connecting function in electronic communication network
JP2001504659A (en) Broadband telecommunications system interface
JP2001505735A (en) Broadband telecommunications system interface
CA2325414C (en) System and method for processing ported calls
US6108337A (en) Resource manager for a virtual bearer channel platform
EP0711052B1 (en) Improvements in or relating to telecommunication systems
US6366662B1 (en) System and method for alternative routing of subscriber calls
MXPA00006729A (en) Virtual bearer channel platform for processing service requests received in the form of channel data
US20040213202A1 (en) Method and apparatus for identifying communications in an ATM/circuit-switched communication network
MXPA00006728A (en) Programmable gateway for a virtual bearer channel platform
MXPA00006730A (en) Resource manager for a virtual bearer channel platform
US7366198B2 (en) Method and system for packet and circuit telephony in a distributed telecommunications switching system
MXPA99004664A (en) System and method for transporting a call in a telecommunication network
MXPA99004746A (en) System and method for interfacing a local communication device