JP2002528010A - Processing platform - Google Patents

Abstract

(57) Summary The platform used to perform advanced services in a communication network using, for example, an IN (Intelligent Network) structure is formed from a number of loosely coupled subsystems. Each subsystem includes a resource locator that advertises its own resources and listens for data identifying resources available in other subsystems. Communication between subsystems may be mediated by resource brokers registering data from different subsystems.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001] The present invention relates to a telecommunications service using a processing platform, in particular a number of loosely coupled subsystems.

[0002] Platforms used to perform advanced services in telecommunications networks with the IN (Intelligent Network) architecture are:
Includes a number of loosely coupled subsystems linked by a high speed network. This structure increases the capacity and resilience of the platform. The resources of the platform are managed by a central management system, which is responsible for allocating specific resources to a given call and reconfiguring the system, for example, if one of the system components fails. As conventionally configured, such platforms have the disadvantage of high management overhead and low scalability, and thus the platform cannot easily adapt to the increased capacity.

According to a first aspect of the present invention, there is provided a communication service platform including a number of loosely coupled subsystems, each of which includes a respective service processing resource and a respective resource locator. Wherein each resource locator comprises means for communicating its identifier and resource availability in each subsystem to other resource locators, and means for receiving identification data and resource availability data for resource locators in other subsystems. Provide communication service platform including:

[0004] This aspect of the invention provides a service platform that maintains the resiliency and capacity of a distributed processing architecture, while reducing management overhead and significantly improving scalability. This is accomplished by providing each subsystem with a resource locator that advertises the resources of the associated subsystem and also listens for information from other subsystems. In this manner, resource management and allocation tasks are distributed among the subsystems, and the system as a whole is equipped to recognize and respond to the addition of new subsystems.

[0005] Resource locators may be adapted to communicate directly via peer-to-peer signaling. However, the platform preferably includes a resource broker, and communication between the resource locators is preferably mediated by the resource broker. The resource broker may be located in one of the service processing subsystems or in a dedicated platform. The resource broker may include a data interface adapted to receive capability data and interface data from each resource locator, and a registry adapted to store the capability data and interface data. The resource locator in the subsystem first reads capability and interface data for the other subsystem from the resource broker and then directly communicates with the other subsystem using the subsystem's interface identified in the interface data. Preferably, another data is communicated.

[0006] The system developed and developed by the inventor of the present invention is not limited for use in a communication system and can be used in a general computer processing environment.

In accordance with a second aspect of the present invention, a computer processing platform including a number of loosely coupled computer processing subsystems, each of the subsystems including a respective data processing resource and a respective resource locator; A computer processing system is provided that advertises resource identifiers and loading and is adapted to receive signaling resources from other resource locators.

According to a third aspect of the present invention, there is provided a method of operating a communication system including a number of processing subsystems and a network interconnecting a number of subsystems, comprising: a) each of the number of subsystems; Communicating data indicative of the availability of one identifier of said subsystem and one resource of said subsystem from a resource locator in one subsystem to a resource locator in another subsystem of a number of subsystems; b. C.) Repeating step (a) for each of a number of subsystems; c) one of the number of subsystems requests a resource that is not locally present in said subsystems during processing of a call. I) relocating another subsystem having the resource from the data communicated to the resource locator of the one subsystem. And another, the method comprising accessing a said subsystem via ii) network.

In accordance with a fourth aspect of the invention, a plurality of call processing subsystems; a network interconnecting the plurality of call processing subsystems; and connected to the network, the capability data and There is provided a communication system including a resource broker having a data interface adapted to receive interface data, and a registry adapted to store the capability data and the interface data.

The term “call processing subsystem” as used herein is broad,
Includes systems that assist in processing calls, such as e-mail servers, mobile application platforms, or interactive voice response (IVR) platforms, and systems such as communication servers that are directly involved in processing calls.

The system implementing the invention will now be described in more detail, exemplarily, with reference to the accompanying drawings.

DETAILED DESCRIPTION OF THE INVENTION A telecommunications network using an IN (Intelligent Network) architecture includes a service control point 1, where the service control point 1 is a network intelligence platform (Ne).
Also known as twork Intelligence Platform (NIP). The service control point (SCP) 1 is a trunk digital main switching point (digital main switch).
tching units (DMSU) 2,3 and digital local exchange (digital loca)
l exchange, DLE) 4,5. Both DMSU and DLE function as service switching points (SSP). At certain points during a call, the SSP transfers control of the call to a service control point. The service control point 1 performs functions such as number conversion and provides a gateway to additional resources such as a voice messaging platform. The network also runs a second service control point (SCP2) 6, in this example a customer mobility application. The two service control points are connected to each other and other components via a broadband signaling network 7.

FIG. 2 shows the structure of the service control point 1. Service management server is FDDI
Overload control server via optical fiber LAN 21
ver, OCS) and a transaction server (TS). The overload control server monitors the call rate and checks the network
Initiate an action to protect the CP and other elements from overload. For example, OC
S can send a call gapping command to the originating exchange. Additionally or alternatively, the call gapping command is sent to the broker to protect the downstream of other resources of the source exchange, for example, by indicating the availability of switching resources in the source exchange in a ratio. The transaction server performs advanced service control functions such as, for example, number translation and call planning. The OCS and the transaction server communicate via the second FDDI LAN 22 with the communication server (
communications servers (CS), which are connected to SS7 (ITU Signalling S)
system no.7 7th ITU signaling system) Connected to the signaling network. A global data server (GDS) is also connected to this second LAN. The GDS records call statistics and may be used to operate the overload control function.

FIG. 3 is a simplified schematic diagram of the network of FIG. 1, showing a first configuration of the present invention. FIG. 3 shows a first SCP 31, a second SCP 32, and a DMSU 33. These components make up the loosely coupled subsystem of the platform that performs the IN service. The subsystems are connected by a broadband signaling network 34, for example, an FDDI LAN. As indicated by the keys to FIG. 3, each subsystem includes different types of call processing resources and resource locators 35. The first SCP indicates resource types 1 and 2, which may correspond, for example, to a VPN (virtual private network) control function and a number translation function, respectively. The second SCP includes Type 1 resources, and the DMSU includes resource type 3, eg, call switching functionality. Each locator advertises to all other locators the subsystem identifier and location, the resources available at that location, and, for example, the loading of the resources. For example, the first SCP31
The locators in the form (SC) are sent to other resource locators when the SCP is activated.
P1; address 1; type 1, 50%; type 2, 90%) (where the first field is an identifier, the second field is an address, the subsequent fields are resource types, Broadcast (including loading measures). This message is received and stored by resources in other subsystems, and the resource locator then broadcasts the resource message,
Received by the resource locator in P31. The step of broadcasting resource messages is repeated periodically, the frequency of which is chosen to balance the needs of the system, after a subsystem failure or in unused (free) resources in a subsystem. After a stepwise change proportional to, the resources are again selected to balance the need for minimizing signaling overhead. In this example, the resource locator retransmits the resource message every 10 seconds. Therefore, for example, DMSU
Call originating from the first SCP uses the VPN resources in the first SCP, and if the first SCP fails, this failure will become apparent within at most 10 seconds and the DMSU resource locator will Resources can be identified. If the expected update does not occur, the resource locator interprets it as indicating that the corresponding resource is no longer available. Additionally, the subsystem may update the resource locator within the subsystem in response to an event. For example, the resource locator may be programmed to update whenever the loading changes by more than a predetermined threshold, eg, 20%.

FIG. 4 is a schematic diagram showing a second configuration of the present invention. In this example, in addition to the first and second SCPs and DMSUs described with reference to FIG. 3, the system also includes a resource broker 40. The resource broker has, in addition to its own resource locator 41, a data memory that holds a registry of data communicated by other subsystems.
42, and an authentication processor 43 that authenticates data received from the subsystem prior to entering data into the registry. Broker, for example, Digital SPARC
V like Visigenics ORB running on Ultra ™ workstation
It can be configured on a commercially available system, such as the system obtained from isigenics. As shown in FIG. 5, in this specification, "component"
The sub-system must first authenticate itself with the broker using, for example, a password or digital signature, and then approve another exchange's security mechanism. The component then registers an interface with the broker. For example, a communication server may register an INAP communication channel at a particular network address. Thus, a component can refer to the registry in the broker to find the interface of another component in the system.
Once a component understands the interface of the other component, it can freely communicate with the other component without further reference to the broker.

FIG. 16 shows the structure of the resource broker 40 in more detail. Resource broker 40
Includes a resource registry, a service registry, an authentication module, a registration module, and a discovery module. Tables 1 and 2 below show examples of the contents of the resource registry and the service registry, respectively. Each resource in the resource registry may be linked to multiple entries in the service registry.

Table 1 Name: Athena Processor: Digital SPARC Ultra Address: 132.14.32.71 Function: Call control server Table 2 Call control: INAP no. RANGE 64XXXX-67XXXX Network operator: BT Capacity: 100 characters / sec Security parameters: Authentication Level Signature Interface: VIPER 1.0 FIG. 6 shows a schematic diagram of an architecture configured using the resource broker described above with reference to FIGS. The broker, and the network used by the subsystem to communicate with the broker, provide for a brokered environment 60 that is brokered. In this example, the subsystems connected to the brokered environment 60 are the PSTN network 61, the IP
(Internet Protocol) Service Gatekeeper for Voice in Services 62
, A fax resource 63, an e-mail server 64, and a voice mail server 65.
Many applications use the resources of subsystems 61-65. These applications use the resource broker contained within the broker environment 60 to locate the appropriate resources. This configuration is called “VIPER” by the inventor.
Called architecture. This architecture provides for two types of interfaces, interfaces referred to by the inventors as VIPER 1.0 and VIPER 2.0. As shown in FIG.
The ER2.0 interface provides communication between subsystems via the object bus 110. Subsystems that use the VIPER2 interface
Each call requests resources from a resource broker and communicates using, for example, the CORBA protocol. The VIPER1 interface bypasses the object bus and uses a specific protocol such as INAP to communicate with other systems. V
The subsystem with IPER1 interfaces with the resources to register and discover and interfaces with the details about the resource broker when the subsystem is activated, but does not communicate with the resource broker for the next call. Such a subsystem, which in turn uses the VIPER1 interface, is an INAP for a communication server that communicates with other subsystems using a subsystem specific protocol, for example, a transaction server.

In operation, a subsystem such as a communication server first downloads a copy of the service and resource registry from the resource broker, forming a locally cached copy of the resource broker. For example, in FIG.
S is a locally cached broker (LC) as indicated by the dotted line in FIG.
B) may be optionally included. A discovery operation is then performed using the locally cached copy of the resource broker. In this case, it is not necessary to send signaling between the communication server and the remote broker in each call, even if the VIPER 2.0 interface is used. Instead, when it is necessary to refresh the locally cached resource broker, data is intermittently sent only between the remote broker and the communication server. The communication server is VIPER2
. When using 0, the communication server still interrogates the resource broker for each new call, but may be a locally cached broker typically used for this purpose.

FIGS. 7 and 8 are class diagrams showing the configuration of the architecture of FIG. This diagram is generated using the Rational ROSE software engineering tool, which provides the basis for generating, for example, the Java code that constitutes the present invention. Rational ROSE, Rational Software Corpo
sold by ration. In this configuration, the subsystems that interact using the broker are called "plugins".

FIGS. 9 and 10 show that the network operator is a VIPER broker, VIPE
R Indicates that the services of the Cambridge transaction server and the VIPER Cambridge communication server are executed. "Cambridge" is the name given to the SCP shown in FIG. After registration and discovery are complete, the incoming call is
NAP (Intelligent Network Application Protocol) IDP (initial detection point, 1st)
Trigger the detection point). DLE is the GPT in the diagram Refer to SSP. The call goes through the VIPER middleware. Since both the communication server CS and the transaction server TS have registered with the VIPER 1.0 interface with the resource broker, there is no need to interrogate the broker each time a call is received at the appropriate service resource or "plug-in" address. Instead, CS and TS use the INAP interface and communicate directly, bypassing the object bus. After performing a location search, the INAP connection returns further to the SSP through the VIPER middleware. The following events and messages are shown in FIGS. 9 and 10: 1: The network operator puts the VIPER broker into service. 2: The VIPER broker registers that it will service itself if necessary. 3: Network operator puts the VIPER Cambridge transaction server in service. 4: VIPER Cambridge Transaction Server sends P to broker
Register itself as lugIN. 5: The VIPER Cambridge transaction server registers the services it supports with the VIPER broker. 6: The network operator puts the VIPER Cambridge communication server in service. 7: VIPER Cambridge communication server uses itself as PlugIN for VIP
Register with the ER broker. 8: The VIPER Cambridge communication server provides the services it supports
Register with the PER broker. 9: VIPER Cambridge transaction server is 'name' (in this case V
Request the address of the PlugIN associated with the IPER Cambridge Communication Server). 10: The VIPER Cambridge communication server requests the address of the PlugIN associated with the 'name' (in this case, the VIPER Cambridge transaction server). 11: The GPT SSP sends the INAP first detection point (IDP) to the VIPER Cambridge communication server. 12: The VIPER Cambridge communication server sends the INAP IDP to the VIPER Cambridge transaction server. 13: The VIPER Cambridge transaction server performs an initial location search and then sends an INAP connection to the VIPER Cambridge communication server. 14: The VIPER Cambridge communication server sends an INAP connection to the GPT SSP.

FIGS. 11, 12, and 13 show the message flows involved in the second scenario, where the network operator places the VIPER broker, the VIPER mobile server, and the VIPER Cambridge communication server in service. VIP
The ER mobile server is, for example, an SCP that executes the mobile application shown in FIG.
It may be 6. When the registration is completed, the incoming call will be sent to the VIPER middleware IN
Trigger AP IDP. The communication server CS generates a call model (denoted as "INAP Call" in FIGS. 11, 12, and 13) and sends service control to the call model. The call model communicates with the resource broker to identify applications that are ready to provide the resources requested by the service. This application is created when it is not already running. The call model then requests an application in connection with the call to perform a location search for the called party. When the search is completed, the mobile address returned by the search is sent to the communication server, and the VIPER middleware sends an INAP connection to the SSP. 1: Network operator puts the VIPER broker into service. 2: The VIPER broker registers that it will service itself if necessary. 3: The network operator puts the VIPER mobile server into service. 4: The VIPER mobile server registers itself as PlugIN with the VIPER broker. 5: The VIPER mobile server registers the services it supports with the VIPER broker. 6: The network operator puts the VIPER Cambridge communication server into service. 7: VIPER Cambridge communication server VIP itself as PlugIN
Register with the ER broker. 8: The VIPER Cambridge communication server provides the services it supports
Register with the PER broker. 9: The GPT SSP sends the INAP first detection point (IDP) to the VIPER Cambridge communication server. 10, 11: The VIPER Cambridge communication server creates a new call model,
It processes this service and activates the constructor of the call model. 12: The call model requests from the VIPER broker the address of the PlugIN (in this case, the VIPER mobile server) that can provide the service described in the service descriptor. 13, 14, 15: The call model request requests the address of an application that can service the request from the VIPER mobile server. Therefore VIPE
The R mobile server generates a roaming application and runs the components of the roaming application. FIG. 18 can be selected depending on whether or not the roaming application is running. 16: The call model sends VIPER 2.0 equivalent to the INAP IDP to the roaming application. 17: The roaming application performs a location search. 18: The roaming application sends a VIPER 2.0 connection to the call model. 19: The call model sends the internal PlugIN connection to the VIPER Cambridge communication server. 20: The VIPER Cambridge communication server sends an INAP connection to the GPT SSP.

FIG. 14 shows the configuration of the VIPER architecture, with different continents (cont
4 illustrates a configuration of a VIPER architecture in which service platforms distributed on different networks located in the same network are provided. In this example, the customer of the customer terminal 100 is registered with a mobile application resident on a first application server connected to a first broadband signaling network in the United Kingdom, for example. The customer terminal is connected via a digital local exchange DLE to a second broadband signaling network, for example in the United States. The first and second national networks are interconnected via a cooperating international network 103. The resource broker (reference B) is connected to the networks and resources available on each network are registered with the resource broker. The resource brokers communicate data with each other via the global broker GB,
Thus, for example, broker B connected to network 102 is registering details of resources on network 101 and network 102. Communication between communication brokers may be performed over IP, for example, using CORBA or IIOP.

In operation, a customer at terminal 100 registers their current location with a mobility application on a first application server. To register,
The customer dials the number associated with the service. This allows the ID to be
P is triggered. The SSP requests the address of the application requested to service the call from local broker B. When the local broker B communicates with the global broker GB connected to the network 103 and obtains the interface and address data, the SCP can communicate with the application server 1. The mobile application may request to receive data from a customer, for example, using an interactive voice response (IVR) system. This resource is provided in the network 101 by the first intelligent peripheral device IP1.
However, the second network includes its own IVR resources provided by the second intelligent peripheral IP2. The mobile application requests discovery of IVR resources from broker B. After communicating with the global broker GB, the broker returns IP2 details local to the customer at the current customer location. The application server 1 uses this information to return an INAP connection message to the SSP to set up a connection between the customer terminal and IP2.

[Brief description of the drawings]

FIG. 1 is a schematic diagram of a network for realizing the present invention.

FIG. 2 is a diagram illustrating a structure of a service control point of FIG. 1;

FIG. 3 is a schematic diagram of a network employing peer-to-peer signaling.

FIG. 4 is a schematic diagram of a network employing a broker.

FIG. 5 is a diagram illustrating the interaction between a broker and a component.

FIG. 6 is a schematic diagram showing an architecture for implementing the present invention.

FIG. 7 is a class diagram in the configuration of the architecture of FIG. 6;

FIG. 8 is a class diagram in the configuration of the architecture of FIG. 6;

FIG. 9 is a message flow diagram showing a first scenario.

FIG. 10 is a message flow diagram showing a first scenario.

FIG. 11 is a message flow diagram showing a second scenario.

FIG. 12 is a message flow diagram showing a second scenario.

FIG. 13 is a message flow diagram showing a second scenario.

FIG. 14 is a schematic diagram showing the configuration of the architecture of FIG. 6 in different networks.

FIG. 15 is a diagram showing different interface types in a system implementing the present invention.

FIG. 16 is a diagram showing the structure of a resource broker.

FIG. 17 illustrates a system in which components cooperate with both type 1.0 and type 2.0 interfaces.

FIG. 18 illustrates a personal mobility service configured using the architecture of FIG.

────────────────────────────────────────────────── ─── Continued on the front page (72) Inventor Bruce, Gary Leslie UK, IP 12.1 Elcu, Suffolk, Ipswich, Woodbridge, Hogate Crow 34 (72) Inventor Harding, Toby Alexander UK Country, C.O.4.5 Geddy, Essex, Colchester, Titus Way 42 (72) Inventor Fenton, Christopher John United Kingdom, IP 4.2 Tee, Suffolk, Ipswich, Berg Rave Close 1 (72) Inventor Lyle, John Andrew UK, IP4.5 Erkuw, Suffolk, Ipswich, Rushmere St.・ Andrew, Kervedon drive 48 F term (reference) 5K024 AA01 BB04 CC01 CC07 CC11 DD05 FF06 5K051 AA04 AA08 BB01 CC01 CC04 CC07 DD01 EE01 EE02 EE04 FF06 FF07 HH02 HH17 HH26 JJ04

Claims (21)

[Claims] 1. A communication service platform including a number of loosely coupled subsystems, each of the subsystems including a respective service processing resource and a respective resource locator; each resource locator indicating an identifier of the subsystem. A communication service platform comprising: means for communicating data and data indicative of resource availability in each subsystem to another resource locator; and means for receiving resource locator identification data and resource availability data in other subsystems. 2. The platform of claim 1, wherein the resource locators are adapted to communicate directly with each other by peer-to-peer signaling. 3. The platform of claim 1, further comprising a resource broker, wherein at least some communications between the resource locators are mediated by the resource broker. 4. The platform of claim 3, wherein a resource broker is located within one of said subsystems. 5. The resource broker comprises: a data interface adapted to receive capability data and interface data from each resource locator; and a registry adapted to store the capability data and interface data. Or the data interface of 4. 6. The resource locator in a subsystem is first adapted to read capability data and interface data of another subsystem from a resource broker, and then to the interface of the subsystem identified in the interface data. 6. A platform according to any one of claims 3 to 5 for communicating data directly with said other subsystems using a. 7. At least one of the subsystems is adapted to communicate directly with the selected other subsystem via each particular data interface, wherein the other subsystem is selected via the object bus. A platform according to any one of claims 3 to 6, adapted to communicate with other subsystems. 8. The system according to claim 1, wherein said or each said subsystem adapted to communicate directly via each particular data interface comprises another subsystem selected from a resource broker during installation of said subsystem. The platform of claim 7, wherein the platform is adapted to read data about and communicate directly with other selected subsystems without reference to a resource broker in response to a call after the installation of the subsystem. 9. The platform of claim 7, wherein said subsystem adapted to communicate via an object bus is adapted to read resource data from a resource broker in response to each new call. . 10. A plurality of call processing subsystems; a network interconnecting the plurality of call processing subsystems; and connected to the network to receive capability data and interface data from each call processing subsystem. A communication system comprising: a resource broker having a data interface and a registry adapted to store the capability data and interface data. 11. The communication system according to claim 10, further comprising an object bus interconnecting at least some of the call processing subsystems. 12. The communication system according to claim 11, wherein a communication path between the other subsystems bypasses the object bus. 13. A computer processing platform including a number of loosely coupled computer processing subsystems, each of said subsystems including a respective data processing resource and a respective resource locator, advertising the identifier and loading of each resource. , A computer processing system adapted to receive signaling resources from another resource locator. 14. A method of operating a communication system including a number of processing subsystems and a network interconnecting a number of subsystems, comprising: a) from a resource locator within each subsystem of the number of subsystems; Communicating an identifier of one of the subsystems and data indicative of the availability of one of the subsystems to a resource locator in another of the multiple subsystems; b) for each of the multiple subsystems Repeating step (a) for each; c) when one of a number of subsystems requests a resource that is not locally present in said subsystem during processing of a call; Identifying another subsystem having the resource from the data communicated to the resource locator of the subsystem; ii) via a network Method comprising accessing a serial subsystem. 15. The method of claim 14, wherein in each of the number of subsystems, step (a) is repeated periodically. 16. The method of claim 15, wherein the repetition period of step (a) is small compared to the average period of a call handled by the communication system. 17. In at least one of the number of subsystems, the step (a)
) Is repeated in each subsystem in response to an event.
7. The method according to claim 6. 18. The method of claim 17, wherein in the event, a change in resource availability in a subsystem exceeds a predetermined threshold. 19. The method according to claim 1, wherein the communication of the resource data between the subsystems is mediated by a resource broker. 20. The method of claim 19, wherein data is communicated between at least some of the subsystems and the resource broker via an object bus. 21. The method of claim 20, wherein data is communicated directly between other subsystems, bypassing an object bus.