WO2000022842A1 - Plate-forme de traitement - Google Patents

Plate-forme de traitement Download PDF

Info

Publication number
WO2000022842A1
WO2000022842A1 PCT/GB1999/003347 GB9903347W WO0022842A1 WO 2000022842 A1 WO2000022842 A1 WO 2000022842A1 GB 9903347 W GB9903347 W GB 9903347W WO 0022842 A1 WO0022842 A1 WO 0022842A1
Authority
WO
WIPO (PCT)
Prior art keywords
subsystems
resource
data
subsystem
broker
Prior art date
Application number
PCT/GB1999/003347
Other languages
English (en)
Inventor
Simon Alexander Beddus
Gary Leslie Bruce
Toby Alexander Harding
Christopher John Fenton
John Andrew Lyle
Original Assignee
British Telecommunications Public Limited Company
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 British Telecommunications Public Limited Company filed Critical British Telecommunications Public Limited Company
Priority to CA002347487A priority Critical patent/CA2347487A1/fr
Priority to JP2000576635A priority patent/JP2002528010A/ja
Priority to AU62172/99A priority patent/AU759043B2/en
Priority to EP99949192A priority patent/EP1121813A1/fr
Publication of WO2000022842A1 publication Critical patent/WO2000022842A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking

Definitions

  • the present invention relates to a processing platform and particularly to telecommunications service platform using a number of loosely coupled subsystems.
  • Platforms used, for example, to implement advanced services in a telecommunications network having an IN (intelligent network) architecture may comprise a number of loosely coupled subsystems linked by a high speed network. This structure enhances the capacity and the resilience of the platform.
  • the resources of the platform are managed by a centralised management system that is responsible for allocating particular resources to given call and for reconfiguring the system, for example, in the event of one of the system components failing.
  • a platform suffers the disadvantages of having a high management overhead and having poor scalability, that is, the platform is not readily adaptable to provide increased capacity.
  • a communications service platform comprising a multiplicity of loosely coupled subsystems, each of the subsystems including respective service processing resources and a respective resource locator, each resource locator including means for communicating to others of the resource locators its identity and the availability of the resources in the respective subsystem, and means for receiving identity data and resource availability data for resource locators in others of the subsystems.
  • This aspect of the invention provides a service platform which maintains the resilience and capacity of a distributed processing architecture while reducing the management overheads and providing greatly improved scalability. This is achieved by providing each subsystem with a resource locator which advertises the resources of the relevant subsystem and also listens to information from other subsystem. In this way the task of resource management and allocation is distributed between the subsystems, and the system as a whole is provided with a mechanism for recognising and responding to the addition of new subsystems.
  • the resource locators may be arranged to communicate directly by peer- to-peer signalling.
  • the platform includes a resource broker and communication between the resource locators is mediated by the resource broker.
  • the resource broker may be located in one of the service processing subsystems, or may be located in a dedicated platform.
  • the resource broker may include a data interface arranged to receive capability data and interface data from respective resource locators, and a registry arranged to store the said capability data and interface data.
  • a resource locator in a subsystem is arranged initially to read capability data and interface data for another subsystem from the resource broker, and subsequently communicates further data directly with the other subsystem using the interface of the subsystem identified in the said interface data.
  • the system developed by the present inventors is not limited to use in communications systems but may also be used in a general computing environment.
  • a computing platform comprising a multiplicity of loosely coupled computing subsystems, each of the said subsystems including respective data processing resources and a respective resource locator arranged to advertise its identity and the loading of the respective resources and to receive resource signalling from others of the resource locators .
  • a method of operating a communications system including a multiplicity of processing subsystems and a network interconnecting the multiplicity of subsystems, the method comprising; a) communicating from a resource locator in a respective one of the multiplicity of subsystems to resource locators in others of the multiplicity of subsystems data indicating the identity of the said one subsystem and the availability of resources in the said one subsystem b) repeating step (a) for each other of the multiplicity of subsystems: c) when one of the multiplicity of subsystems, in the course of processing a call, requires resources not present locally in the said subsystem: i) identifying from the said data communicated to the resource locator of the said one subsystem another subsystem having the said resources; ii) accessing the said subsystem via the network.
  • a communications system comprising: a plurality of call processing subsystems; a network interconnecting the plurality of call processing subsystems; a resource broker connected to the network, the resource broker including a data interface arranged to receive capability data and interface data from respective call processing subsystems, and a registry arranged to store the said capability data and interface data.
  • call processing subsystem is used here broadly to encompass systems ancillary to the processing of a call, such as, e.g., an Email server, a mobility application platform or an interactive voice response (IVR) platform, as well as systems, such as a communications server, which are directly involved in the handling of a call.
  • a call processing subsystem such as, e.g., an Email server, a mobility application platform or an interactive voice response (IVR) platform, as well as systems, such as a communications server, which are directly involved in the handling of a call.
  • FIG. 1 is a schematic of network embodying the invention
  • Figure 2 is a diagram showing the structure of a service control point in Figure 1 ;
  • Figure 3 is a schematic of a network employing peer-to-peer signalling:
  • Figure 4 is a schematic of a network employing a broker
  • Figure 5 is a diagram showing interactions between a broker and components
  • Figure 6 is a schematic showing an architecture implementing the invention
  • Figure 7 is a class diagram for an implementation of the architecture of Figure 6;
  • Figure 8 is a message flow diagram showing a first scenario
  • Figure 9 is a message flow diagram showing a second scenario
  • Figure 10 is a schematic of an implementation of the architecture of Figure 6 across different networks
  • Figure 1 1 is a diagram illustrating different interface types in a system embodying the invention
  • Figure 1 2 is a diagram showing the structure of a resource broker
  • Figure 1 3 shows a system in which components incorporate both type 1 .0 and type 2,0 interfaces
  • Figure 14 shows a personal mobility service implemented using the architecture of Figure 6.
  • a telecommunications network which uses an IN (Intelligent Network) architecture includes a service control point 1 , which is also termed herein the Network Intelligence Platform (NIP).
  • the service control point 1 is connected to trunk digital main switching units (DMSU's) 2 ,3 and to digital local exchanges (DLE's) 4,5. Both the DMSU's and the DLE's function as service switching points (SSP's). At certain points during the progress of a call, the SSP's transfer control of the call to the service control point.
  • the service control point 1 carries out functions such as number translation and provides a gateway to additional resources such as a voice messaging platform.
  • the network also includes a second service control point 6, which in this example runs customer mobility applications. The two service control points are connected to each other and to the other components via a broadband signalling network 7.
  • FIG. 2 shows the structure of the service control point 1 .
  • a service management server is connected via an FDDI optical fibre LAN 21 to an overload control server (OCS) and to transaction servers (TS).
  • OCS overload control server
  • TS transaction servers
  • the overload control server monitors call rates and initiates action to protect the SCP and other elements of the network from overload.
  • the OCS may send a call-gapping instruction to an originating exchange.
  • a call-gapping instruction may be sent to the broker, so that the broker rations the availability, e.g., of switching resources at the originating exchange so as to protect other resources downstream of the originating exchange.
  • the transaction servers implement advanced service control functions such as, for example number translation and call plans.
  • FIG. 3 is a simplified schematic of the network of Figure 1 , illustrating a first implementation of the present invention.
  • the Figure shows a first SCP 31 , a second SCP 32 and a DMSU 33. These components constitute loosely coupled subsystems of a platform which runs one or more IN services.
  • the subsystems are connected by a broadband signalling network 34, for example an FDDI LAN.
  • each subsystem includes call processing resources of different types and also a resource locator 35.
  • the first SCP includes resource types 1 and 2 which might correspond, for example, to a VPN (virtual private network) control function and to a number translation function respectively.
  • the second SCP includes type 1 resources, and the DMSU includes resource type 3, for example a call switching function.
  • Each locator advertises to all other locators, the identity and location of the subsystem, the resources available at that location and, for example, the loading of the resources.
  • the locator in the first SCP 31 when the SCP is initiated, broadcasts to the other resource locators, a message in the form (SCP1 ; addressl ; type 1 , 50%; type 2, 90%) where the first field is the identity, the second field is the address, and the subsequent fields are resource types and include a measure of resource loading.
  • This message is received and stored by the resource locators in the other subsystems, and they in turn broadcast resource messages which are received by the resource locator in the SCP 31 .
  • the step of broadcasting resource messages is repeated periodically, with a frequency chosen to balance the need of the system to re-balance resources after a subsystem failure, or after incremental changes in the proportion of free resources in a subsystem, against the need to minimise signalling overheads.
  • resource locators re- transmit a resource message every 10 seconds. Then, for example, if a call originating at the DMSU is making use of VPN resources in the first SCP, and the first SCP fails, the failure will become apparent within, at most 10 seconds, and the DMSU resource locator may identify alternative resources in the second SCP. The absence of an expected update is interpreted by the resource locators as an indication that the corresponding resources have become unavailable.
  • subsystems may update the resource locators in response to events within that subsystem. For example, a subsystem may be programmed to update the resource locators whenever its loading changes by more than a predetermined threshold, e.g. 20%.
  • Figure 4 is a schematic illustrating a second implementation of the invention.
  • the system also includes a resource broker 40.
  • the resource broker includes, in addition to its own resource locator 41 , a data store 42 which holds a registry of data communicated by other subsystems, and an authentication processor 43 which authenticates data received from the subsystems prior to entering the data in the registry.
  • the broker may be implemented on a commercially available system such as that available from Visigenics as the Visigenics ORB (object request broker) running, for example, on a Digital SPARC Ultra (trademark) workstation.
  • a subsystem here termed a "component” must first authenticate itself with the broker, for example using a password or a digital signature, and agree a security mechanism for further exchanges.
  • the component registers its interfaces with the broker.
  • a communications server might register an INAP communications channel at a specified network address. From this point, the component can discover the interfaces of other components within the system by reference to the registry in the broker. Once the component understands the interfaces of other components it can communicate freely with the other components without further reference to the broker.
  • Figure 1 2 shows in further detail the structure of the resource broker 40.
  • It comprises a resource registry, a service registry, and modules for authentication, registration and discovery.
  • Tables 1 and 2 below show examples of the contents of the resource registry and service registry respectively.
  • Each resource in the resource registry may have linked with it a number of entries in the service registry.
  • Security parameters authentication level signature
  • FIG. 6 shows an overview of an architecture that is implemented using a resource broker as described above with reference to Figures 4 and 5.
  • the broker and the network used by the subsystems to communicate with the broker together provide a brokered environment 60.
  • the subsystems connected to the brokered environment 60 include a PSTN network 61 , a gatekeeper 62 for voice over IP (internet protocol) services, fax resources 63, an Email server 64 and a voice mail server 65 .
  • a number of applications use the resources of the subsystems 61 -65. These applications locate the appropriate resources using the resource broker contained within the brokered environment 60.
  • This implementation is termed by the inventors the "VIPER" architecture.
  • the architecture provides for two types of interfaces, termed by the inventors VIPER 1 .0 and VIPER 2.0.
  • VIPER 2.0 interfaces provide for communication between subsystems via an object bus 1 10.
  • Subsystems using VIPER 2 interfaces request resources from a resource broker on a per call basis and communicate using, e.g., the CORBA protocol.
  • VIPER 1 interfaces bypass the object bus and use specific protocols such as INAP to communicate with other systems.
  • Subsystems with VIPER 1 interfaces register and discover resources and interface details with the resource broker when the subsystem is initialised, but do not communicate with the resource broker for subsequent calls.
  • Such subsystems using VIPER 1 interfaces then communicate with other subsystem using protocols specific to the subsystem, for example INAP in the case of a communications server communicating with a transaction server.
  • a subsystem such as a communications server may initially download copies of service and resource registry data from the resource broker to form a locally cached copy of the resource broker.
  • the communications server CS may optionally include a locally cached broker (LCB), as shown in dashed lines in the Figure.
  • discovery operations may be carried out using the locally cached copy of the resource broker.
  • a VIPER 2.0 interface it is not necessary for signalling to pass between the communications server and the remote broker on every call. Instead, data passes between the remote broker and the communications server only intermittently when it is necessary to refresh the locally cached resource broker.
  • the communications server if it employs a VIPER 2.0 interface, still interrogates the resource broker for each new call, it is in general the locally cached broker that is used for this purpose.
  • Figure 7 is a class diagram showing an implementation of the architecture of Figure 6. This diagram is generated using the Rational ROSE software engineering tool and provides a basis, using that tool, for generating, e.g., Java code implementing the invention.
  • Rational ROSE is available commercially from Rational Software Corporation.
  • the subsystems that interact using the broker are termed "plugins”.
  • FIG. 8 shows a network operator bringing a VIPER broker, a VIPER Cambridge Transaction Server and a VIPER Cambridge Communications Server into service.
  • "Cambridge” is the name given to the SCP illustrated in Figure 2.
  • IDP Intelligent Network Application Protocol
  • the DLE is referenced GPT_SSP in the diagram.
  • the call is cut-through the VIPER middleware. Since the communications server CS and transaction server TS have both registered VIPER 1 .0 interfaces with the resource broker, the CS does not have to ask the broker each time a call is received for the address of a suitable service resource or "plugin". Instead the CS and TS communicate directly using an INAP interface and bypassing the object bus. After location lookup is performed, an INAP connect is also cut-through the VIPER middleware back to the SSP. The following events and messages are shown in Figure 8:
  • VIPER Cambridge Transaction Server requests the address of the PluglN associated with 'name' (in this case, VIPER Cambridge Communications Server).
  • VIPER Cambridge Communications Server requests the address of the PluglN associated with 'name' (in this case, VIPER Cambridge Transaction Server).
  • GPT SSP sends an INAP Initial Detection Point (IDP) to the VIPER Cambridge Communications Server.
  • IDP INAP Initial Detection Point
  • VIPER Cambridge Communications Server sends a INAP IDP to the VIPER Cambridge Transaction Server.
  • VIPER Cambridge Transaction Server does an internal location lookup, then sends an INAP connect to the VIPER Cambridge Communications Server.
  • VIPER Cambridge Communications Server sends an INAP connect to the GPT SSP.
  • Figure 9 shows the message flows involved in a second scenario, with a network operator bringing a VIPER broker, a VIPER Mobility Server and a VIPER Cambridge Communications Server into service.
  • the VIPER mobility server may be, for example, the SCP 6 running a mobility application illustrated in Figure 1 .
  • a communications server CS creates a call model (labelled "INAP call” in Figure 9) and passes control of the service to that call model.
  • the call model communicates with the resource broker to identify an application that is capable and ready to provide the resources required by the service. That application, if not already running, is created.
  • the call model then request the application, in relation to this call, to perform a location look-up for the called party.
  • a mobile address returned by the look-up is passed to the communications server and the VIPER middleware send an INAP connect to the SSP.
  • VIPER broker registers it services with itself if necessary.
  • VIPER Mobility Server registers itself as a PluglN with the VIPER broker.
  • VIPER Mobility Server registers the services it supports with the VIPER broker.
  • VIPER Cambridge Communications Server registers the services it supports with the VIPER broker.
  • GPT SSP sends an INAP Initial Detection Point (IDP) to the VIPER Cambridge Communications Server.
  • IDP INAP Initial Detection Point
  • the VIPER Cambridge Communications Server creates a new call model to handle this service and then initiates the Call Model's constructor.
  • the Call Model requests from the VIPER broker the address of the PluglN (in this case, the VIPER Mobility Server) capable of providing the service described within the service descriptor.
  • the VIPER Mobility Server in this case, the VIPER Mobility Server
  • the Call Model requests from the VIPER Mobility Server the address of the application capable of servicing the request. This causes the VIPER Mobility Server to create a Roaming Application and then initiate the Roaming Application's constructor. Flow 14 is optional depending on whether the Roaming Application is active or not.
  • the Call Model sends a VIPER 2.0 equivalent of an INAP IDP to the Roaming Application.
  • the Roaming Application performs a location lookup.
  • the Roaming Application sends a VIPER 2.0 Connect to the Call Model.
  • the Call Model sends an internal PluglN connect to the VIPER Cambridge Communications Server.
  • the VIPER Cambridge Communications Server send an INAP connect to the GPT SSP.
  • Figure 10 illustrates an implementation of the VIPER architecture which provides a service platform which is distributed over different networks that may be located in different continents.
  • a customer at a customer terminal 100 is registered with a mobility application resident on a first application server connected to a first broadband signalling network e.g. in the UK.
  • the customer terminal is connected via a digital local exchange DLE to a second broadband signalling network, e.g., in the US.
  • the first and second national networks are interconnected via a jointly operated international network 103.
  • Resource brokers (referenced B) are connected to the networks and the resources available on each network are registered with the resource brokers.
  • the resource brokers communicate data to each other via a global broker GB, so that, for example, the broker B connected to network 102 has in its registry details of resources on both network 101 and network 102.
  • the communication between brokers may be implemented, e.g., using CORBA or MOP over IP.
  • the customer at terminal 100 registers their current location with the mobility application on the first application server. To do this, they dial the number associated with the service. This triggers an IDP at the SSP.
  • the SSP requests from a local broker B the address of the application required to service the call.
  • the local broker B communicates with the global broker GB connected to network 103 to obtain interface and address data to allow the SCP to communicate with application server 1 .
  • the mobility application may, for example, require the use of an interactive voice response (IVR) system to accept data from the customer.
  • This resource is provided within network 101 by a first intelligent peripheral IP1 .
  • the second network includes its own IVR resources provided by a second intelligent peripheral IP2.
  • the mobility application requests discovery of IVR resources from the broker B.
  • the broker After communication with the global broker GB, the broker returns detail of the IP2 that is local to the customer at the current customer location.
  • the application server 1 uses this information to return an INAP connect message to the SSP to set up a connection between the customer terminal and

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne une plate-forme utilisée, par exemple, pour mettre en application des services évolués dans un réseau de communication grâce à une architecture de réseau intelligent, cette plate forme étant composée de plusieurs sous-systèmes à couplage lâche. Chaque sous-système comprend un localisateur de ressources qui annonce les propres ressources du sous-système et écoute les données identifiant les ressources disponibles dans d'autres sous-systèmes. La communication entre les sous-systèmes peut passer par un courtier de ressources qui enregistre les données provenant des différents sous-systèmes.
PCT/GB1999/003347 1998-10-14 1999-10-08 Plate-forme de traitement WO2000022842A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CA002347487A CA2347487A1 (fr) 1998-10-14 1999-10-08 Plate-forme de traitement
JP2000576635A JP2002528010A (ja) 1998-10-14 1999-10-08 処理プラットフォーム
AU62172/99A AU759043B2 (en) 1998-10-14 1999-10-08 Processing platform
EP99949192A EP1121813A1 (fr) 1998-10-14 1999-10-08 Plate-forme de traitement

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP98308384 1998-10-14
EP98308384.1 1998-10-14

Publications (1)

Publication Number Publication Date
WO2000022842A1 true WO2000022842A1 (fr) 2000-04-20

Family

ID=8235103

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB1999/003347 WO2000022842A1 (fr) 1998-10-14 1999-10-08 Plate-forme de traitement

Country Status (5)

Country Link
EP (1) EP1121813A1 (fr)
JP (1) JP2002528010A (fr)
AU (1) AU759043B2 (fr)
CA (1) CA2347487A1 (fr)
WO (1) WO2000022842A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1422949A1 (fr) * 2002-11-20 2004-05-26 Alcatel Méthode et système pour fournir des services

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2851870A1 (fr) * 2003-02-28 2004-09-03 France Telecom Organe de mediation multi-domaine multi-fournisseurs entre fournisseur de service applicatif et fournisseur de ressource dans un reseau de telecommunications

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996020448A1 (fr) * 1994-12-23 1996-07-04 Southwestern Bell Technology Resources, Inc. Plateforme de reseau flexible et systeme de traitement d'appel
WO1996042173A1 (fr) * 1995-06-09 1996-12-27 British Telecommunications Public Limited Company Disponibilite des ressources dans des reseaux de telecommunications intelligents

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4800488A (en) * 1985-11-12 1989-01-24 American Telephone And Telegraph Company, At&T Bell Laboratories Method of propagating resource information in a computer network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996020448A1 (fr) * 1994-12-23 1996-07-04 Southwestern Bell Technology Resources, Inc. Plateforme de reseau flexible et systeme de traitement d'appel
WO1996042173A1 (fr) * 1995-06-09 1996-12-27 British Telecommunications Public Limited Company Disponibilite des ressources dans des reseaux de telecommunications intelligents

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1422949A1 (fr) * 2002-11-20 2004-05-26 Alcatel Méthode et système pour fournir des services

Also Published As

Publication number Publication date
AU759043B2 (en) 2003-04-03
EP1121813A1 (fr) 2001-08-08
AU6217299A (en) 2000-05-01
CA2347487A1 (fr) 2000-04-20
JP2002528010A (ja) 2002-08-27

Similar Documents

Publication Publication Date Title
RU2144271C1 (ru) Система для управления телекоммуникационным обслуживанием
EP1741277B1 (fr) Système de traitement d'evenements
US6122363A (en) Multi-protocol interface apparatus at a service control point
USH1837H (en) Generic telecommunications system and associated call processing architecture
USH1921H (en) Generic wireless telecommunications system
EP0873025B1 (fr) Procédé pour fournir au moins un service aux utilisateurs d'un réseau de télécommunication
JPH1145181A (ja) 遠距離通信ネットワークの利用者にサービスを提供する方法、サービス管理ファシリティ及び処理ノード
JP2014090446A (ja) 通信網
US6341162B1 (en) Telecommunications intelligent network
AU759043B2 (en) Processing platform
US5917901A (en) Telecommunications system
US6954523B2 (en) Method for providing a service in a telecommunication network and a corresponding infrastructure manager
US6600751B1 (en) Gateway between a data network and a service network
US6744855B1 (en) Service control platform
EP0998829A2 (fr) Peripherique de service intelligent/peripherique intelligent
KR100372724B1 (ko) 지능망에서의 호 진행에 따른 메시지 트레이스 방법
CA2357440C (fr) Architecture a partage de charge pour un noeud ss7
KR100198957B1 (ko) 분산형 액세스 노드 시스템에서의 응용객체를 이용한 호처리방법
Kubota et al. Distributed processing platform for telecommunication networks
Bhadana Advanced Intelligent Network for Wireless Communications
GB2413030A (en) Event processing system
WO1999001992A2 (fr) Acheminement base sur l'identification automatique du numero (ani)

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU CA JP SG US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

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

Ref document number: 09787198

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 1999949192

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 62172/99

Country of ref document: AU

ENP Entry into the national phase

Ref country code: JP

Ref document number: 2000 576635

Kind code of ref document: A

Format of ref document f/p: F

ENP Entry into the national phase

Ref document number: 2347487

Country of ref document: CA

Ref country code: CA

Ref document number: 2347487

Kind code of ref document: A

Format of ref document f/p: F

WWP Wipo information: published in national office

Ref document number: 1999949192

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 62172/99

Country of ref document: AU