WO2000033214A1 - Procede et dispositif concernant la gestion de ressources dans un reseau de telecommunications - Google Patents

Procede et dispositif concernant la gestion de ressources dans un reseau de telecommunications Download PDF

Info

Publication number
WO2000033214A1
WO2000033214A1 PCT/SE1999/002247 SE9902247W WO0033214A1 WO 2000033214 A1 WO2000033214 A1 WO 2000033214A1 SE 9902247 W SE9902247 W SE 9902247W WO 0033214 A1 WO0033214 A1 WO 0033214A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
resource
network
client
service
Prior art date
Application number
PCT/SE1999/002247
Other languages
English (en)
Inventor
Jan Bornstein
Original Assignee
Telefonaktiebolaget Lm Ericsson
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 Telefonaktiebolaget Lm Ericsson filed Critical Telefonaktiebolaget Lm Ericsson
Priority to AU21314/00A priority Critical patent/AU2131400A/en
Publication of WO2000033214A1 publication Critical patent/WO2000033214A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
    • H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
    • H04Q11/0435—Details
    • H04Q11/0442—Exchange access circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1014—Server selection for load balancing based on the content of a request
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1029—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers using data related to the state of servers by a load balancer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the present invention relates to a method and an arrangement in a communications network, specially in a computer network including one or more client stations and one or more servers, arranged to provide services and/or resources, when the client station accesses at least one server for obtaining a service or resource.
  • a network including communication apparatuses such as computer networks or telecommunication networks
  • clients e.g. workstations, subscribers etc.
  • service provider stations servers, base stations etc.
  • the client sends messages to obtain resources.
  • the resource can be a specific resource, preferably identified by a Globally Unique IDentifier (GUID) without a reference to any specific server.
  • GUID Globally Unique IDentifier
  • a resource may be any kind of software or hardware resource, such as procedures or functions controlling specific routines, switching functions etc. belonging to the first category, and print services, network facsimile services, CD-ROM racks/Jukeboxes, communication ports/boards/paths etc. belonging to the second category.
  • a Resource Manager which is a global resource, is arranged to keep track of all resources included in the system. Moreover, the RM determines which server contains a specific resource.
  • the RM will become a bottle neck in the system when the number of the resources and servers increases; and the system will slow down when simultaneous multiple accesses are made to determine resources and corresponding servers.
  • Japanese Patent Application No. 195972 describes a single client/single server system including a resource management server, which has a first internal memory. Said memory stores the name of a server which outputs a Resource Output Request and the resource name. There is also included a resource updating unit. The updating unit searches the contents of the first internal memory during an update period and an updating notice is sent to the resource server. Access to the free resources is then managed by the server.
  • a client resource request message is sent to an arbitrary server. If said server dose not own or has access to the resource, the message is sent to next the server. The message transmission is continued until a server owing the resource is found. Hence, this solution will generate a large amount of messages, which eventually will slow down the system.
  • Japanese Patent Application No. 164837 describes a distributed type info ⁇ nation processing method, e.g. for a computer system involving executing job demanded by a client through a server based on information related to hardware and software resources.
  • the method involves referring a program module when the execution of a specific job is demanded by a client.
  • Information related to hardware resources is collected by an agent.
  • information related to software resources is also collected.
  • a server is arranged to execute the demanded job based on the colleted information.
  • US 5,548,723 relates to object-oriented client-server facility (CSF) and networking service facility (NSF) interfaces, which implement communication between application programs residing in client and server nodes of a distributed services network.
  • CSF interface includes remote procedure call (RPC) objects for invoking and responding to service requests at the nodes, and application programming interface (API) objects for transporting those requests between the nodes.
  • RPC remote procedure call
  • API application programming interface
  • the API and RPC objects interact with dynamically-configurable protocol stacks within the NSF interfaces to complete the transport mechanism needed by an application program on the client node when accessing services on a remote server node.
  • each network node can maintain its own list of network resources in a topology database.
  • TDU topology database update
  • Each adjacent node updates its own topology database and rebroadcasts the message.
  • each node assigns flow reduction sequence numbers (FRSNs) to TDU messages and keeps a record of the FRSN for the last TDU message sent to an adjacent node.
  • FRSNs flow reduction sequence numbers
  • the node also records, for each resource in its database, the FRSN of the last TDU message including that resource.
  • the sending node includes in the TDU message only those resources having a FRSN greater than the FRSN assigned to the last TDU sent to the adjacent node to which the TDU message is directed.
  • Non of above documents relates to an arrangement includes a client API part arranged for controlling communications between the client and a server, which part includes an updateble database for storing information about a resource/service and to said resource/service corresponding server .
  • the API objects (not client API) only provide communication transports within a node.
  • the main object of the present invention is to provide an arrangement that when a client in a network sends a request for some specific action the arrangement will through a user interface will rout the client messages to an appropriate server in the network.
  • One object of the present invention is to provide a rigid communication system which manages the resource distribution between included devices in a simple and less complex way known through prior art.
  • Still another object of the present invention is to provide a network arrangement that will provide resources for a client without the client having any specific knowledge of the resource providing elements (servers).
  • the arrangement according to the beginning includes a part arranged for controlling communication between the client and the server, said unit including an updatable database for storing information at least about said resource/service and corresponding server.
  • said part is a client API or implemented as a distributed, asynchronous, telegram-based client API.
  • said part is arranged to distribute client resource/service requests to said servers by managing the database and to achieve a safe system.
  • said part also includes server configuration, allowing multi- node switching, load-sharing and error handling, and a robust network is obtained since said error handling is based on the "graceful degradation" paradigm, where an error just affects the functionality close to the failure.
  • said resource or service is a specified and identified with a Globally Unique
  • Identifier and the database contains information about all resources used by all clients and also their location.
  • the invention also refers to a communications network, which further comprises networking arrangement connecting client stations and server units.
  • the client stations are arranged to generate messages for requesting services and/or resources from the server units.
  • At least each server unit handles a resource/service.
  • the interfacing means is a service access-point among others including server unit configurations and resource/service states.
  • said interfacing means allows multi-node switching, load-sharing and error handling and it is implemented as a distributed, asynchronous, telegram-based client API.
  • the server unit is also arranged to handle interface means as a resource/service.
  • the network architecture is substantially a decentralized distributed system and based on a varying number of server units connected to each other via a Local Area Network (LAN), for example via an IP network such as an ethernet LAN.
  • LAN Local Area Network
  • the server units are also connected to each other via a network to achieve switching between the server units.
  • the network is configured using one server unit with a varying number of clients. It may also be configured as a distributed multi-server system providing a varying number of clients, to be connected to a varying number of server units.
  • HW network Hardware
  • the resource modules include at least one of ISDN Resource module, for handling ISDN (Integrated Services Digital Network) protocol, S-Connect Resource module, for handling an analogue operator interface (S-connect), DSP Resource module, for handling DSP (Digital Signal Processing) handling for signalling and messaging, and Conference Resource module, for handling conference devices for conference switching.
  • ISDN Integrated Services Digital Network
  • S-Connect Resource module for handling an analogue operator interface (S-connect)
  • DSP Resource module for handling DSP (Digital Signal Processing) handling for signalling and messaging
  • Conference Resource module for handling conference devices for conference switching.
  • XSRMU Request Manager Unit
  • XSSM Switch Manager unit
  • XSRM Resource Manager Unit
  • XSMM Main Manager
  • resource connection XSRM provides functionality to manage, synchronise and co-ordinate HW resources
  • XSSM handles the resources in a logical level and manages the relations between the resources and uses the XSRM to access them
  • XSMM contains main application and initiates and synchronises other units in the system
  • XSRMU provides functionality to handle the communication in the distributed environment.
  • the network is an Exchange System based on computers, preferably Personal Computers (PCs).
  • PCs Personal Computers
  • the method according to the present invention comprises the steps of: providing means for controlling communication between the client and the server, said means including an updateble table (XSCU Context) for storing information at least about said resource/service and corresponding server, controlling said table when sending a request for said resource/service, and based on information retrieved from said table, routing said request to a server suited to handle the request.
  • XSCU Context updateble table
  • the client requests are received by a Request Manager, which handles the server communication part, and depending on the type of the request, the Request Manager distributes the requests to a Switching manager or Resource Manager via a main queue.
  • the switching is multi-node and provided in several stages, including: (a) allocation of a connection means resource and sending a Message (XSMSG) to other servers requesting an execution of a service and all information needed by the other server to fulfill its part of the switching, (b) when another server receives the Message (XSMSG), connecting the input from the connection means to an output on a relevant connection point, (c) sending an XSMSG containing a service execution message and all information needed by the originating server to fulfill stage (b), and (d) when the originating server receives a Service Execution Message, connecting the input connection point to an output on the connection means.
  • XSMSG Message
  • the switching is multi-node and provided in several stages, including: (a) allocation of a connection means resource and sending a Message (XSMSG) to other servers requesting an execution of a service and all information needed by the other server to fulfill its part of the switching, (b) when another server receives the Message (XSMSG), connecting the input
  • the client request creates new resources, which are arranged in an arbitrary server queue to distribute the workload over the servers and if this request contains a pointer, transferring the request to a server pointed out by the pointer.
  • Fig. 1 is a very schematic block diagram showing the main elements of a network involving an arrangement according to the invention
  • Fig. 2 illustrates schematically a network embodiment including the invention
  • Fig. 3 is a more detailed but still schematic illustration of the elements of the network arrangement according to fig. 2.
  • a client (station) 11 requiring a specific resource 13 sends a message referring to said specific resource, which is identified with a Globally Unique IDentifier (GUTD).
  • GUITD Globally Unique IDentifier
  • the request does not refer to any specific servers 12 in the network. Consequently, the client does not need to have any special knowledge about the servers in the network.
  • the messages are queued in message queue systems 14. The queue systems 14 will be described later.
  • an information database or a context table is created, which is linked to a client API (Application Programmers Interface).
  • the database or resource context is arranged to include information about and keep track of substantially all resources in the network.
  • the resources may be of the type that can be created and/or destroyed.
  • API by definition is, a set of routines that an application uses to request and carry out lower-level services performed by a computer's operating system.
  • the embodiment schematically shown in fig. 2, relates to an Exchange System (XS) 20, which is a computer based communications platform providing distributed and redundant functionality for switching, control and coordination of different communication protocols interfacing external (or internal) networks 21.
  • XS Exchange System
  • the external et works can for example be any of PLMN (Private Land Mobile Network), PSDN (Public Switched Data Network), PSTN(Public Switched Telephone Network) etc.
  • the XS architecture is substantially a decentralized distributed system and can be based on a varying number of XS servers 12 connected to each other, for example via an IP network such as an ethernet LAN (Local Area Network) 22. &
  • the XS severs 12 may also be connected to each other via a network 23, for example through MCI bus, to achieve switching between the servers.
  • the XS 20 can be configured using one XS server with a varying number of clients 11, or as a distributed multi-server system, that provides a varying number of clients, to be connected to a varying number of XS servers.
  • the Hardware (HW) interfaces are handled as resources, and can be encapsulated under a generic resource interface XS Resource Manager within a XS server 12.
  • XS Resource Manager within a XS server 12.
  • different, e.g. protocol specific, resource modules are encapsulated and handled as subsystems under the resource interface.
  • the XS is therefore extendable to handle new types of resources, e.g. communication protocols and networks in future versions, e.g. IP-telephony and different radio system protocols.
  • the XS has the following functions:
  • Resource handling which handles resource allocation, e.g. conference allocation.
  • - Status notification which handles asynchronous XS and external network status information to the clients.
  • the XS is based on implementation of a number of resource modules, such as: - ISDN Resource module, which handles the ISDN (Integrated Services Digital Network) protocol. - S-Connect Resource module, which handles the analogue operator interface (S-connect). DSP Resource module, which handles the DSP (Digital Signal Processing) handling for signalling and messaging.
  • ISDN Integrated Services Digital Network
  • S-Connect Resource module which handles the analogue operator interface (S-connect).
  • DSP Resource module which handles the DSP (Digital Signal Processing) handling for signalling and messaging.
  • a DSP is a resource that can be allocated/deallocated and used for tone and message sending/receiving.
  • a conference resource provides functionality to set up a set of participants represented as seats into a forum, where the participants are connected.
  • the connection to a conference seat can be a simplex or a duplex connection represented.
  • the XS Communication Unit (XSCU) API 24 is the name of the XS service access-point. Preferably, it is implemented as a distributed, asynchronous, telegram-based client API.
  • the XSCU API includes among others the XS server configuration and allows multi-node switching, load-sharing and error handling, for example based on the "graceful degradation” paradigm, i.e. degradation of the system in such a manner that it continues to operate, but provides a reduced level of service rather than failing completely and an error just affects the functionality close to the failure.
  • "graceful degradation” paradigm i.e. degradation of the system in such a manner that it continues to operate, but provides a reduced level of service rather than failing completely and an error just affects the functionality close to the failure.
  • the Client Logic (CL) Interface to the XS is the XSCU API, which is included in the client application.
  • the XSCU handles the communication between the client and the XS and includes functionality to distribute client requests to the XS servers, by managing client context information.
  • the XS server 12 mainly includes a XS Request Manager Unit (XSRMU) 30, XS Switch Manager (XSSM) 31, XS Resource Manager XSRM 32, XS Main Manager (XSMM) 33 and resource connection 34.
  • XSRMU XS Request Manager Unit
  • XSSM XS Switch Manager
  • XSRM XS Resource Manager
  • XSMM XS Main Manager
  • resource connection 34 connects resources, such as ISDN Resource, DSP Resource, S-connect Resource, Conference Resources etc.
  • the XSRM 32 functional block provides functionality to manage, synchronise and co-ordinate HW resources. It provides a generic high level interface to the HW resources. Preferably, it abstracts the handling and configuration of HW boards, which interfaces the communications networks. Asynchronous events from the HW interfaces are passed by to the XSRMU 30 via the XSMM 33 synchronized main queue. It has for example mechanisms for allocating, deallocating and translation of switching information related to HW resources.
  • XSRM 32 also provides a high level interface to the HW and is a single service access point to the external communications network interfaces. The XSRM 32 handles the physical switching and the coordination of the HW.
  • the XSSM 31 handles the resources in a logical level. It manages the relations between the resources and uses the XSRM 32 to access them. It also uses the XSRMU 30 to pass requests to other XS servers in the system, regarding handling of resources outside a local machine. The single node switching is solved only by using the local XSRM.
  • XSMM 33 is the main functional block in the XS. It contains the main application and it initiates and synchronises other units in the system, for example by managing a multi thread based architecture. It provides functionality to send and receive messages between the different functional blocks, e.g. by controlling a thread secure synchronised queue, and invokes each functional block's Request in the order the queue items are received.
  • XSSM 31 The main functions of XSSM 31, among others, are to:
  • the XSSM uses resource tables for executing its tasks. Requests from the XSRMU 30 are sent to XSSM through a queue managed by the XSMM. In order to perform a task for example making a connection, the XSSM 31 and the XSRM work very intimately. The tasks are divided so that the XSSM 31 handles the logical part of the switching, which means the part where information about resources, such as Bus tables, Connection Tables and Conference Tables (mainly but not exclusively arranged in XSSM), must be updated in order to provide correct information about the actual physical connections.
  • resources such as Bus tables, Connection Tables and Conference Tables
  • XSSM 31 logically connects two connection points, which represents an access point to a call, a conference, a DSP or a Logical Address, to each other (through a connection table) and sends commands to XSRM 32 in order to accomplish the physical connection.
  • the distributed switching uses the MCI bus for transferring media streams between the XS servers.
  • the XSRMU 32 function block provides functionality to handle the communication in the distributed environment.
  • the communication paths are: • XSCU (Client) to XS server communication;
  • the multi-node switching is provided in a three stage process: - the first stage includes allocation of a MCI bus resource and sending a XS Server
  • the XSMSG is the XS server to server interface message which contains request and notification data from one XS server to another.
  • the second stage is when another server receives an XSMSG. Upon reception it will connect the input from the MCI -bus to the output on the relevant connection point via the internal telephony bus. When this is completed, it will send an XSMSG containing a service execution message and all information needed by the originating server to fulfill the second part of the switching.
  • the third stage is when the originating server receives the Service Execution
  • XS further consists of a set of message queues and queue managers.
  • XSCU is the part that exposes the XS API to the clients and communicates with the XS Servers.
  • Each CL 35 communicates with the XS through the XSCU interface using the XS API 24.
  • each instance of XSCU has information substantially about all the resources used by all CL and also their location (connection to a certain XS Server(s)).
  • XSCU receives information from each XS Server when a resource is initiated or deleted. Based on said information, the requests can be routed to the XS Server best suited to handle a request. The information is also useful when a XS Server is out of order or not reachable. In the following, this information is called the XSCU System Context (XSSC).
  • XSSC XSCU System Context
  • Requests that create new resources are arranged in an arbitrary server queue to distribute the workload over the XS Servers. If this request contains a "pointer", the request will be transferred to a server pointed out by the pointer.
  • the requests that relate to the entire XS e.g. commands such as Logout, Reset, Shutdown) are sent to all servers.
  • the XS Server sends notifications to the XSCU entity that sent the request. If a resource is created or deleted, a Resource Info Notification will be sent to all other XSCUs, to update their XSSC. Some notifications can also be sent to the CLs.
  • the XSCU will send the request to one of them, and fill in the logical address of the other resource from its XSSC (if it is represented by a GUID and not a logical address already).
  • the logical address identifies a low level connection point within the XS server, which allows one input connection and several output connections.
  • each XSCU entity includes information about essentially all the resources and to which XS Server they are associated to.
  • the information includes all calls, connections, conferences, DSPs created by any CL and their identity (GUID), which implicitly points out in which location they reside.
  • GUID GUID
  • Each XS XSCU has interfaces towards its client and towards the XS Servers. Some messages travel transparently through the XSCU and some are XS Server/XSCU internal messages not reaching CLs.
  • Client requests for a resource in the form of a XS Message are sent from CL to XSCU.
  • the XS Messages do not contain any information about the server the message is supposed to be sent to. This is actually handled by the API.
  • the client sends a message the XSCU will look up any resource reference in the message in XSSC to determine in which server the resources are located. If the request involves resources in different servers, information will be added in the XS Message, helping the receiving server to handle the request.
  • the Messages to XSCU received from XS Server are analysed and the XSSC is updated accordingly.
  • the XSSC contains tables for all resources and methods for adding, deleting and finding resources.
  • the XSCU provides functions to handle the interface to the XS server system through a distributed API. This functionality is based on handling of instances of messages, XS Message, which is, as described above, the XSCU API message containing request data from CL to XS or notification data from XS to CL.
  • XS Message contains substantially all APIs.
  • This handling includes instantiation, sending and receiving XS Message instances.
  • the XSCU can be the complete API and the single service access point to the XS.
  • the general concept of the API is an asynchronous telegram based solution.
  • the physical HW configuration of the server is hidden from the client.
  • the Microsoft ® MessageQueue system (MSMQ) is for example used for network communication. Obviously, other systems for network communication can be used.
  • the XSCU API structure is divided into several logical parts, for example: - Server Connection: handles system related functionality, e.g. the connection between CL and the XS Server system;
  • - Switching handles connections between XS connection points within the XS Servers;
  • - Resource handles allocation and deallocation of specified resources within the
  • - Call Control manages call control functions within the XS Servers.
  • - Messaging for example playing and recording messages using a DSP. Messages can be read, deleted and also be shared between concurrent CLs.
  • the XS also includes an interface 36 to external networks, e.g. PSTN, which for example uses the ISDN protocol.
  • the ISDN interface is implemented in the ISDN resource module within the XS server.
  • the system may also include interfaces to telephony operators based on an analogue telephone interface. This interface is also called S-Connect, and it is implemented in the S- Connect resource module within the XS server.
  • the XS provides basic client/server connection via login/logout, where every client has there own specified ID (CLID).
  • CLID specified ID
  • the client server communication which is based on the transaction of XS Messages, is divided into requests and notification, where the requests represent the messages from the CL to the XS and the notifications represent the messages from the XS to the CLs.
  • the CL must make an instance of the XSCU API, which handles the asynchronous communication between the client and the XS server locally or over a network, e.g. the LAN.
  • a login request will result in retrieving notifications for all incoming calls retrieved by the XS, and it will enable the client to send requests to XS. If the login fails, a negative status notification message will be received.
  • the XSCU is able to inform the clients about which resources that were lost.
  • the XS provides functionality to allocate and deallocate defined XS resources: for example Conference and DSP.
  • the "pointer" mechanism is implemented, which means that the resource can be allocated in the same XS Server and the same interface board as the XS Connection Point which it will be connected to, if the optional XS Connection Point is set in a resource allocation message.
  • a conference resource can be allocated with a guaranteed (fixed or varying) number of participants.
  • a conference participant is represented by a XS Connection Point, which can be a resource connected with a simplex or duplex connection.
  • a DSP can only be either a receiver or a transmitter at the same time.
  • a connection to a DSP can be duplex, but you can only use the DSP in one direction at the time.
  • the XS provides functionality to handle the events of one or many system components going down.
  • the basis for this functionality is a completely distributed and decentralised architecture.
  • the system is able to handle the event of one XS Server that goes down or is not reachable. This situation will result in loss of resources and possibly loss of unserviced requests. The loss will be limited to the resources directly connected to the failing node.
  • XS informs the clients about which resources that were lost.
  • XSSM 30 also handles conference allocation. If the XS server does not have any free conference resources available, it will pass the request further to the next XS server in the system. The "next" server is selected by the one that has not read the message from its queue. This process will end when any XS server takes care of the request or if there is no XS server left to send to (that has not read the message from its queue). If there are no conference resources available in the entire system, the last XS server will send a "failed" notification to the requesting CL
  • - CL makes a XS Connect request to the XSCU, which distributes it to a proper XS server.
  • the XS server makes a local allocation of a resource, and transfer the request including an INPUT address and resource address to the next affected XS server.
  • the latter XS server makes the local switching and transfers the request in a notification, including an OUTPUT address, back to the first XS server.
  • the first XS server now makes the local switching and sends a notification to the CL via XSCU and the resource (connection) is allocated.
  • a Message Queue Handler provides functionality to send and receive messages to/from message queues and to locate, create and destroy message queues.
  • a Message Queue Handler has its own queue where all incoming messages are read. All outgoing messages are sent to other queues, associated with other Message Queue Handlers.
  • Handler can be used by a client or a server in the XS.
  • the client users are then the XSCUs and server users are XS Request Managers.
  • the queues 14 are divided into two categories, server queues and client queues, thus providing a straightforward way to identify if the queues are associated with a server or with a client.
  • the invention is not limited to the above-described network arrangement but any kind of computer network, such as computer networks, (cellular) telecommunication networks etc., can use the benefits of the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé et un dispositif faisant partie d'un réseau de télécommunications comprenant un ou plusieurs clients (11) et un ou plusieurs serveurs (12) fournissant des services et/ou des ressources (13). Le client (11) accède à au moins un serveur afin d'obtenir lesdites ressources ou services (13). Ledit dispositif comprend une partie (XSCU) (24) disposée de manière à contrôler la communication entre le client et le serveur (12). Cette partie (24) comprend une base de données actualisable (XSCU Context) permettant de stocker des informations au moins sur lesdites ressources ou services et le serveur correspondant (12).
PCT/SE1999/002247 1998-12-01 1999-12-01 Procede et dispositif concernant la gestion de ressources dans un reseau de telecommunications WO2000033214A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU21314/00A AU2131400A (en) 1998-12-01 1999-12-01 Method and arrangement relating to resource handling in communications networks

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SE9804188A SE523204C2 (sv) 1998-12-01 1998-12-01 Arrangemang, kommunikationsnätverk och metod där en anordning hos klienter innefattandes en databas med information om resurser hos servrar, styr kommunikationen mellan klienter och servrar
SE9804188-2 1998-12-01

Publications (1)

Publication Number Publication Date
WO2000033214A1 true WO2000033214A1 (fr) 2000-06-08

Family

ID=20413536

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE1999/002247 WO2000033214A1 (fr) 1998-12-01 1999-12-01 Procede et dispositif concernant la gestion de ressources dans un reseau de telecommunications

Country Status (3)

Country Link
AU (1) AU2131400A (fr)
SE (1) SE523204C2 (fr)
WO (1) WO2000033214A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6973643B2 (en) 2001-08-17 2005-12-06 International Business Machines Corporation Method, system and program for handling errors occurring in function calls
WO2016074759A1 (fr) * 2014-11-11 2016-05-19 Unify Gmbh & Co. Kg Procédé et système de contrôle de consommation de ressources en temps réel dans un environnement informatique distribué

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5101348A (en) * 1988-06-23 1992-03-31 International Business Machines Corporation Method of reducing the amount of information included in topology database update messages in a data communications network
US5475819A (en) * 1990-10-02 1995-12-12 Digital Equipment Corporation Distributed configuration profile for computing system
US5548723A (en) * 1993-12-17 1996-08-20 Taligent, Inc. Object-oriented network protocol configuration system utilizing a dynamically configurable protocol stack
US5574904A (en) * 1990-01-19 1996-11-12 Fujitsu Limited Database management system in an intelligent network using a common request data format
US5796952A (en) * 1997-03-21 1998-08-18 Dot Com Development, Inc. Method and apparatus for tracking client interaction with a network resource and creating client profiles and resource database

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5101348A (en) * 1988-06-23 1992-03-31 International Business Machines Corporation Method of reducing the amount of information included in topology database update messages in a data communications network
US5574904A (en) * 1990-01-19 1996-11-12 Fujitsu Limited Database management system in an intelligent network using a common request data format
US5475819A (en) * 1990-10-02 1995-12-12 Digital Equipment Corporation Distributed configuration profile for computing system
US5548723A (en) * 1993-12-17 1996-08-20 Taligent, Inc. Object-oriented network protocol configuration system utilizing a dynamically configurable protocol stack
US5796952A (en) * 1997-03-21 1998-08-18 Dot Com Development, Inc. Method and apparatus for tracking client interaction with a network resource and creating client profiles and resource database

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6973643B2 (en) 2001-08-17 2005-12-06 International Business Machines Corporation Method, system and program for handling errors occurring in function calls
WO2016074759A1 (fr) * 2014-11-11 2016-05-19 Unify Gmbh & Co. Kg Procédé et système de contrôle de consommation de ressources en temps réel dans un environnement informatique distribué
CN107111520A (zh) * 2014-11-11 2017-08-29 统有限责任两合公司 用于分布式计算环境中的实时资源消耗控制的方法和系统
US10334070B2 (en) 2014-11-11 2019-06-25 Unify Gmbh & Co. Kg Method and system for real-time resource consumption control in a distributed computing environment
US10609176B2 (en) 2014-11-11 2020-03-31 Unify Gmbh & Co. Kg Method and system for real-time resource consumption control in a distributed computing environment

Also Published As

Publication number Publication date
SE9804188L (sv) 2000-06-02
SE9804188D0 (sv) 1998-12-01
SE523204C2 (sv) 2004-04-06
AU2131400A (en) 2000-06-19

Similar Documents

Publication Publication Date Title
US5719942A (en) System and method for establishing a communication channel over a heterogeneous network between a source node and a destination node
US6510478B1 (en) Method and apparatus for coordination of a shared object in a distributed system
US5191651A (en) Apparatus and method for making of interconnected processors act like a single node in a multinode communication system
US6393581B1 (en) Reliable time delay-constrained cluster computing
US5539886A (en) Call management in a collaborative working network
US4713806A (en) Communication system control arrangement
US7774403B2 (en) System and method for concentration and load-balancing of requests
US7379540B1 (en) Server with backup capability for distributed IP telephony systems
EP1509032A2 (fr) Gestion des files d'attente dans des centres d'appels
CA2197517C (fr) Serveur d'acces a des bases de donnees pour pbx
Schmidt A family of design patterns for applications-level gateways
JPH10116193A (ja) 通話制御装置および通話を制御する方法
JPH08511889A (ja) 拡張プログラム間通信サーバ
JPH07503569A (ja) ネットワークにおける協調作業用ワークステーション及び協調作業方法
EP1008056A1 (fr) Livraison et mise en attente certifiees de messages dans des communications a diffusion/abonnement multipoint
WO2000033214A1 (fr) Procede et dispositif concernant la gestion de ressources dans un reseau de telecommunications
EP0464352A2 (fr) Architecture d'interface de sous-point d'entrée pour la gestion de modifications dans un réseau d'ordinateurs
CA2331212C (fr) Programmation d'applications de traitement d'appels dans un systeme de commutation
CN112468466B (zh) 一种关于超大规模ims as技术的实现系统
US20020021774A1 (en) Dispatcher configurable linking of software elements
WO2000033154A1 (fr) Procede et dispositif de gestion de messages pour reseaux de communication
EP1161843B1 (fr) Services supplémentaires apportés par l'exécution d'une application de la couche de services supplémentaires ssl dans un noeud de commutation d'un système de télécommunications extensible
US20050198022A1 (en) Apparatus and method using proxy objects for application resource management in a communication network
US7492882B1 (en) C2P provisioning late-breaking scenarios
Want Reliable management of voice in a distributed system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
REF Corresponds to

Ref document number: 10083447

Country of ref document: DE

Date of ref document: 20021205

Format of ref document f/p: P