EP1108322A2

EP1108322A2 - Improvements in, or relating to, teleservice management systems

Info

Publication number: EP1108322A2
Application number: EP99944974A
Authority: EP
Inventors: Nils BJÖRKMAN; Istvan Cseienyi; Jonas Elldin; Christer Gisgard; Alexander Latour-Henner; Torbjörn LUNDBERG; Stefan ÖSUND
Original assignee: Telia AB
Current assignee: Telia Co AB
Priority date: 1998-08-25
Filing date: 1999-08-24
Publication date: 2001-06-20
Also published as: NO20010895L; SE9902683L; WO2000011886A2; EE200100120A; NO20010895D0; WO2000011886A3; SE9902683D0

Abstract

A teleservice management system is adapted to support the provision of a plurality of complex teleservices and has a plurality of intercommunicating subsystems. The teleservice management system negotiates and settles agreements between participants to a service session, resource control architectures within terminals and a resource control architecture in a transmission network. The teleservice management system employs a teleservice control protocol for transmitting messages between said subsystems and thereby controlling a teleservice. The teleservice control protocol is arranged to link a network resource manager, service users and terminal resource managers, into a teleservice control process for facilitating delivery of a teleservice which is optimal, in terms of resource usage, and agreed by a service user. The teleservice control protocol is adapted for use with a plurality of different teleservices including: multiparty, multimedia conference services; tele-game services; tele-shopping services; and tele-education services. The teleservice control protocol messages refer to specific parts of an object oriented model of a teleservice session. The teleservice control protocol includes messages exchanged between: a terminal part and a network part of the teleservice management system; the teleservice management system and a service control graphical user interface; the teleservice management system and an application launcher daemon; and the teleservice management system and network resource managers.

Description

Improvements in, or Relating to, Teleservice Management Systems

The present invention relates to a teleservice management system, a service platform for managing a plurality of complex teleservices, a telecommunications system including a teleservice management system and a method of managing a plurality of complex teleservices

The first worldwide telecommunication system, i.e. the digital telephone network, has been working for years. The allocation of resources with guaranteed service quality requirements, such as low delay and delay variation, for this single- service system was also solved a long time ago. Resource management is much more complicated in the case of broadband integrated services networks which support several multimedia, multi-connection, multi-party services with different requirements.

In the case of normal telephony, the source terminal is allocated first, after lifting the phone-receiver, then the network resources are allocated as the CCSS #7 signalling message proceeds through the network and the destination terminal is finally allocated. If the called user answers within a given waiting time, the call is established. Otherwise the allocated resources are released in a reverse order. This Bearer Service Layer protocol does not require management functions in the

Teleservice Layer.

Because of the complexity and diversity of broadband teleservices, the management functions have to be divided between the Service Management System and the Control Architecture. Since signalling messages in the Teleservice

Layer are not yet supported by the current standards, a new protocol has to be designed. This can be considered as third party, overlay signalling, since it is up to the SMS to translate the Teleservice Layer messages to proper bearer signalling messages during call establishment, operation and release. Basically, two type of Bearer Service Layer protocols can be distinguished, the forward and backward allocation, depending on the direction of resource reservation between the source and destination terminals. In our co-pending patent application, Telia Case 698 (Application No ), the content of which is imported herein by reference, there is described a teleservice management system which solves the following problems:

the TSMS relieves the user from having to provide elaborate and comprehensive technical descriptions in order to invoke the service and to indicate service quality aspects;

the SL⁾ cannot usually express his QoS preference, since the application does not ask him, therefore, the TSMS has an own Service Control interface for interaction with the user;

allocation, and release, of telecommunication applications and resources in terminals and network;

co-ordination and integration of telecommunication applications and resources in terminals and network; and

- controlling of resources from the service point of view, thereby maintaining the required quality of service, e.g. adapting resources, such as, communication bearer capabilities, according to different, or shifting, circumstances.

This TSMS provides a general scheme for constructing new teleservices which facilitates the service definition, in general and, in particular, provides a systematic way of handling the different service options, which might otherwise degenerate into an unmanageably large set of possible service variants.

The invention described and claimed in our co-pending application Telia Case 698 provides a teleservice management system adapted to manage a plurality of complex teleservices. This teleservice management system includes a service control module arranged to provide a user with a graphical interface adapted to enable the user to provide data on a required QoS and other parameters, relating to a teleservice which the user wishes to invoke. Means are also provided for storing information relating to service definitions. The teleservice management unit creates an object oriented teleservice model from a request for service, received from said graphical interface via said service control module, using a default mapping between teleservice layer entities and bearer service layer entities.

The present invention relates, inter alia, to a signalling protocol for transmission of control messages in a teleservice system of the type disclosed in our co-pending patent application Telia Case 698.

Two further related inventions are described in our co-pending patent applications, listed below, the content of the specifications of these patent applications is incorporated into this patent specification by reference. The co- pending patent applications are:

Telia Case 700 (our co-pending patent application ), which relates to a procedure for creating reservation graphs for the resources in terminals and networks using the teleservice description given by the service provider, said procedure being aimed at producing the most complete teleservice configuration consistent with service specific rules; and

Telia Case 701 (our co-pending patent application ), which relates to a service control graphical interface for facilitating communication between a Teleservice Management System and a system user.

The TCP of the present invention is unique. Many protocols exist for directly controlling the bearer network resources, e.g. establishing connections with given parameters. However, the TCP of the present invention controls the teleservice itself, i.e. it operates at a higher level and does not act directly on the resources.

The difference between the TCP of the present invention and other teleservice level protocols is that the TCP herein described involves not only the network resource manager and the user application, but also brings the service user and the terminal resource manager into the control process This results in a teleservice session which is optimal from the resources' perspective and which is also acknowledged by service users

The type of the TCP's protocol primitives, and their order, are unique

The vast majority of teleservice control protocols are applicable to only one, or at most a few, teleservices, while the TCP of the present invention has general validity

The TCP messages used in the present invention refer to specific parts of an object oriented model of the teleservice session

According to a first aspect of the present invention, there is provided a teleservice management system, adapted to support the provision of a plurality of complex teleservices and including a plurality of intercommunicating subsystems, characterised in that said teleservice management system includes negotiation means for settling agreements between participants to a session, resource control architectures within terminals and a resource control architecture in a transmission network, said negotiation means including a teleservice control protocol for transmitting messages between said subsystems and thereby controlling a teleservice

Said teleservice control protocol may be arranged to link a network resource manager, service users and terminal resource managers, into a teleservice control process for facilitating delivery of a teleservice which is optimal, in terms of resource usage, and agreed by a service user

Said teleservice control protocol may be adapted for use with a plurality of different teleservices

Said plurality of different teleservices may include

multiparty, multimedia conference services, tele-game services;

tele-shopping services; and

tele-education services.

Said teleservice control protocol messages may refer to specific parts of an object oriented model of a teleservice session.

Said teleservice control protocol may be implemented in a teleservice layer and is transparently transferred in underlying layers.

Said underlying layers may include network layers and transport layers.

Said teleservice control protocol may include messages exchanged between:

a terminal part and a network part of the teleservice management system;

the teleservice management system and a service control graphical user interface;

- the teleservice management system and an application launcher daemon; and

the teleservice management system and network resource managers.

Said teleservice control protocol may have four primitives for communication within said teleservice management system.

Said teleservice control protocol may have four primitives for communication with: a service control;

a terminal resource manager;

a network resource manager;

and an application daemon.

Said teleservice management system may have the following interfaces:

a first interface, between a terminal part and a signalling emulator;

a second interface, between a terminal and a service control;

a third interface, between a terminal and an application launcher daemon;

- a fourth interface, between a terminal and a terminal resource manager; and

a fifth interface, between a signalling emulator and a network resource manager.

Said teleservice control protocol may be adapted to transfer information relating to a part of a teleservice object model through said first interface.

Said teleservice control protocol may be adapted to transfer information relating to a part of a teleservice object model through said second interface.

Said teleservice control protocol may be adapted to transfer information relating to a name and parameters, associated with an application employed by a teleservice, through said third interface.

Said teleservice control protocol may be adapted to transfer information relating to a specification of terminal resources, required by a teleservice, through said fourth interface.

Said teleservice control protocol may be adapted to transfer information relating to a specification of network resources, required by a teleservice, through said fifth interface.

According to a second aspect of the present invention, there is provided a telecommunications system, logically split between an application layer, a teleservice layer, a bearer service layer and a resource layer, characterised in that said teleservice layer includes a teleservice management system as set forth in any previous paragraph.

According to a third aspect of the present invention, there is provided a service platform adapted to support the provision of a plurality of complex teleservices and including a plurality of intercommunicating subsystems, terminals and a telecommunications network, characterised in that said service platform includes resource management means, and in that a teleservice control protocol is employed for implementing protocol agents both in said terminals and in said network.

Protocol agents may be implemented in said terminals by utilising a resource control application provider interface, forming part of a network control architecture, as an interface between network resource management and a signal emulator.

Said terminals may have at least one interface towards a user.

Said terminals may have an interface towards an application.

Said terminals may have an interface towards a terminal resource manager.

Said teleservice control protocol may be adapted for use with a plurality of different teleservices.

Said plurality of different teleservices may include: multiparty, multimedia conference services;

tele-game services;

tele-shopping services; and

tele-education services.

According to a fourth aspect of the present invention, there is provided a method of managing a plurality of complex teleservices employing a teleservice management system including a plurality of intercommunicating subsystems, characterised by settling agreements between participants to a session by exchanging messages using a teleservice control protocol, said teleservice control protocol linking a network resource manager, service users and terminal resource managers into a teleservice control process for facilitating delivery of a teleservice which is optimal in terms of resource usage and agreed by a service user.

Said teleservice control protocol may operate with a plurality of different teleservices.

Said plurality of different teleservices may include:

- muitiparty, multimedia conference services;

tele-game services;

tele-shopping services; and

tele-education services. Said teleservice control protocol messages may refer to specific parts of an object oriented model of a teleservice session.

Said teleservice control protocol may be implemented in a teleservice layer and transparently transfer teleservice protocol messages in underlying layers.

Said underlying layers may include network layers and transport layers.

Said teleservice control protocol may include messages exchanged between:

a terminal part and a network part of the teleservice management system;

- the teleservice management system and a service control graphical user interface;

the teleservice management system and an application launcher daemon; and

the teleservice management system and network resource managers.

Said teleservice control protocol may have four primitives for communicating with:

- a service control;

a terminal resource manager;

a network resource manager; and an application daemon.

Said teleservice management system may have the following interfaces:

a first interface, between a terminal part and a signalling emulator;

a second interface, between a terminal and a service control;

- a third interface, between a terminal and an application launcher daemon;

a fourth interface, between a terminal and a terminal resource manager; and

Said teleservice control protocol may be used to transfer information relating to a part of a teleservice object model through said first interface.

Said teleservice control protocol may be used to transfer information relating to a part of a teleservice object model through said second interface.

Said teleservice control protocol may be used to transfer information relating to a name and parameters, associated with an application employed by a teleservice, through said third interface.

Said teleservice control protocol may be used to transfer information relating to a specification of terminal resources, required by a teleservice, through said fourth interface.

Said teleservice control protocol may be used to transfer information relating to a specification of network resources, required by a teleservice, through said fifth interface. Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:

Figure 1 illustrates the main messages of the teleservice control protocol of the present invention.

Figures 2 to 8 show the blocks 2 to 8, respectively, of Figure 1 , in greater detail.

Figure 9 illustrates the environment of the teleservice control protocol of the present invention.

Figure 10 illustrates the use of a mux for sharing a TSP/SIC signalling channel.

Figure 11 illustrates mapping between messages.

Figure 12 illustrates the process of implementing different operations on different objects in the same message.

Figure 13 illustrates the process of modifying a LVSI.

Figure 14 illustrates the process of rolling back a LVSI.

Figure 15 illustrates the process of object deletion in a LVSI.

Figure 16 illustrates the process by which the Service Control in a terminal handles service dependent time-outs.

Figure 17 illustrates the process of sending Inquiries to parties who have not sent a Reply.

Figure 18 shows the contents of a Reply.

Figure 19 illustrates the basic flow for setting up a simple bearer service. Figure 20 illustrates the basic flow for terminating a simple bearer service.

Figure 21 illustrates how states in an object in the terminal and the corresponding object in the network change when messages are passed between them.

Figure 22 illustrates the use of id.

Table 1 lists objects of the Telecommunication Service Description Model.

Table 2 lists typical messages for establishing a teleservice session between two parties.

Table 3 contains the structure of a TSP Message.

Table 4 lists attributes in the class TSP_MSG.

Table 5 lists a protocol Descriptor for a TSP Message.

Table 6 contains the structure of a PDU for a TSP/SIC.

Table 7 lists attributes in the class SIC_MSG.

Table 8 is a table of message types.

Table 9 contains the structure of a PDU for a USM Leg.

Table 10 lists attributes in the class USM_LEG.

Table 11 contains the structure of a PDU for a PARTYJ.EG.

Table 12 lists attributes in the class PARTJ.EG.

Table 13 lists attributes in the class ELEMENT_HEAD_IN_LEG. Table 14 is a table of Element Types.

Table 15 is a table of Operations.

Table 16 is a table of Responses.

Table 17 is a table of Causes.

Table 18 contains the structure of a PDU for a SIJHEAD.

Table 19 lists attributes in the class SIJHEAD.

Table 20 contains the structure of a PDU for the USM_„ELEMENT.

Table 21 lists attributes in the class USM_ELEMENT.

Table 22 is a table of presence in USM.

Table 23 contains the structure of a PDU for an ASM_ELEMENT.

Table 24 lists attributes in the class ASM_ELEMENT.

Table 25 is a table of presence in ASM.

Table 26 contains the structure of a PDU for a PARTY_ELEMENT.

Table 27 lists attributes in the class PARTY_ELEMENT.

Table 28 is a table of presence in a PARTY_ELEMENT.

Table 29 contains the structure of a PDU for PARTYJD.

Table 30 lists attributes in the class PARTYJD.

Table 31 contains the structure of a PDU for a PE ELEMENT. Table 32 lists attributes in the class PE_ELEMENT.

Table: 33 is a table of presence in a PE_ELEMENT.

Table 34 contains the structure of a PDU for a PAE_ELEMENT.

Table 35 lists attributes in the class PAE_ELEMENT.

Table 36 is a table of presence in a PAEJΞLEMENT.

Table 37 is a table for direction in a PAE_ELEMENT.

Table 38 contains the structure of a PDU for a SM_ELEMENT.

Table 39 lists attributes in the class SM_ELEMENT.

Table 40 contains the structure of a PDU for an ACE_ELEMENT.

Table 41 list attributes in the class ACE_ELEMENT.

Table 42 contains the structure of a PDU for class TRAFFIC_DESCRIPTOR.

Table 43 lists attributes in the class TRAFFICJDESCRIPTOR.

Table 44 is a table for type in the class TRAFFIC_DESCRIPTOR.

Table 45 gives the meaning of the attributes Operation, Response and

Cause in an Order.

Table 46 gives the meaning of the attributes Operation, Response and Cause in an Inquiry.

Table 47 gives the meaning of the attributes Operation, Response and Cause in a Reply. 0/1

15

Table 48 gives the meaning of the attributes Operation, Response and Cause in a CS.

In order to assist the reader to a better understanding of this patent specification, a glossary of some the abbreviations used herein is set out below:

ABB Application Building Block

ACE

AP Application Provider

API

APLD Application Launcher Daemon

ASM Abstract Service Module

ATM Asynchronous Transfer Mode

CAC Call Admission Control

EMMA Experimental Middleware for ATM

GSMP

IAPI IP/ATM Protocol Interface

IP Internet Protocol

LVSI Local View of Service Instance

MoD Movie on Demand

NAP Network Access Program NAPI Native ATM Protocol Interface

NIC ?

NP Network Provider

NRM Network Resource Manager

PAE Party ASM Edge

PE Party Edge

QoS Quality of Service

RR ?

SC Service Control

SI Service Instance

SIC Service Instance Control

SIGNE Signalling Emulator

SM Service Module

SMS Service Management System

SU Service User

TCSD Telecommunication Service Description

TP Terminal Profile

TRM Terminal Resource Manager /11886

- 17 - TCP TeleService Control Protocol

TSMS TeleService Management System

TSP Telecommunication Service Protocol

UPC Usage Parameter Control

UQL User Quality Level

USM User Service Module

Control of distributed multimedia services requires internal communication between the components of a teleservice management system (TSMS), employed to control provision of these services. Internal communication is needed in order to:

settle agreements between those participating in a session and the resources employed in the provision of the service;

control architectures within terminals accessing a service and the network providing transmission functions for the service;

- control the dynamic behaviour of a teleservice session;

update the state models of the teleservice session, stored in the terminals and in the network.

The present invention relates to a teleservice management system employing a teleservice control protocol which implements these functions.

The Teleservice Control Protocol (TCP) is used by the sub-systems of the

TSMS, of the present invention, for implementing the functions set out above. The TCP includes messages exchanged between: the terminal part (EMMA) and network part (SIGNE) of the TSMS;

the TSMS and the Service Control graphical user interface;

the TSMS and the Application Launcher Daemon; and

the TSMS and the Terminal and Network Resource Managers.

It implies four primitives for communication within the TSMS, see Figures

1 to 8, and four primitives for communication with:

the SC;

the Terminal Resource Manager (TRM);

Network Resource Manager (NRM); and

- the Application Launcher Daemon (APLD).

It should be noted that the blocks labelled 2 to 8 in Figure 1 are illustrated in greater detail in Figures 2 to 8, respectively.

The typical order of messages and description of the primitives are given in Table 2. Table 1 lists the different information transferred through the different interfaces of the TSMS.

The creation, modification and termination, of teleservice sessions proceeds using the same message types, but with different contents. There are several possible orders for TCP messages, depending on the availability of terminal and network resources and the answers of service users and applications. A typical example is given in Table 2, where the notation "10a" and "10b" means that these steps may happen simultaneously, or in any other order in time. The TCP is implemented in the Teleservice Layer and is, therefore, transparently transferred in the underlying layers, e.g. network and transport layers.

The TCP, of the present invention, can be applied within a Telecommunication Service Management System. Due to the general nature of the teleservice modelling approach, the same protocol primitives can be applied to any teleservice, e.g. multiparty multimedia conference, tele-games, tele-shopping, tele- education, etc..

Moreover, the TCP can also be used in Service Platforms as an extension for Resource Management. In this case, protocol agents should be implemented both in the network and in the terminals. The former utilise the resource control

API of the network control architecture, e.g. GSMP, as the NRM/SIGNE interface. The latter should have at least one interface toward the user and, optionally, two more interfaces toward the application and the terminal resource manager. However, some of the functionality of TCP can be kept even if only the NRM and SC are involved in a negotiation.

The invention can be placed on the top of a general network resource control architecture, so called switchlet, which, in this case, replaces the network resource manager.

The operating environment of the present invention is illustrated in Figure 9, which is self explanatory and will be readily understood by those skilled in the art.

TSP is a family of protocols which sit on top of TCP/IP for Signalling in

SIGNE 2. The family includes TSP/HTTP, TSP/REG, TSP/TCSD, TSP/DIR,

TSP/SIC, TSP/MUX. The protocol will now be described, in detail, from the point of view of implementation on the terminal side of TSP/SIC. The way in which

SIGNE 2 is implemented on the network side of TSP/SIC is not described.

TSP/SIC is used for distribution of objects in the Service Instance to terminals. The objects in LVSI have one part that is local and another that is the distributed part of the Service Instance in the network. Only attributes and services needed in the terminal's local view are in LVSI. The local part comprises attributes and services for communicating with the ABBs and the Service Control.

The basic flow is as follows:

1. Order from the initiating terminal to the network.

2. Inquiry from the network to the terminal.

3. Reply from the terminal.

4. Confirmed State from the network to the terminal

The terminal sends an order to the network containing the user's request for a Service Instance. The network processes the order and sends out Inquiries to all parties to the service.

The Inquiry can be a request for the whole Service Instance, or just a part of it. The Inquiry specifies what resources the terminal needs to allocate to participate in the inquired part of the service. Whether the user, at the terminal, needs to be questioned about the inquiry, or not, is service dependent. If needed, the Service Control may modify both the question to the user and the answer from the user, before sending a reply to the network.

When the terminal has processed the Inquiry and allocated ABBs, it gives an answer by sending a Reply to the network. In the Reply, objects from the Inquiry are returned with a status of accept, or reject. The network processes the Inquiry and when the demands for setting up a SI is True, the network sends a Confirmed State to all those who sent a Reply. The Confirmed State tells the terminal about the Confirmed State of the SI. For all objects that are active this mean that a connection is established and the ABBs can start sending and receiving . The network waits for late Replies and sends a new Confirmed State /11886 .

when they are received.

Fig 19 shows a basic flow for setting up a simple bearer service using 2 parties, one USM and one ASM.

Fig 20 shows a basic flow for terminating a simple bearer service.

When the SI is terminated an Inquiry is needed to tell the ABBs to finish the current session and stop sending. In this case the Confirmed State just indicates that termination has been completed in the network. The terminal is not allowed to throw away a LVSI before a Confirmed State says so. For ABBs that do not require precise terminations, the terminal (Service Control) may send a Reply before killing the ABB. Some types of ABB do not need to be killed, e.g. hardware video decoders.

Figure 21 illustrates the way in which states in an object in the terminal and the corresponding object in the network change when messages are past between them. The example, illustrated by Figure 21 , shows the successful creation of an object.

The Order message contains Message head, SIJHEAD, USM legs, and the service part of the Party legs (not SMs and ACEs).

The Inquiry message contains Message head, SIJHEAD, USM legs, the whole Party leg for the receiver of the message and the service part of the other Party legs.

The Reply message contains Message head, SIJHEAD and the sending Party's whole Party leg. The USM leg contains only size_ f_usmjeg and no objects.

The CS message contains Message head, SIJHEAD, USM legs, the whole Party leg for the receiver of the message and the service part of the other Party legs.

The purpose of the messages is to update the other side's service instance. It contains the attributes from the objects in the SI, and in the LVSI, that are needed in the other end.

A SIC message holding one buffer for USM legs and one for Party legs is put into a TSP message. In the USM leg and the PARTY leg the sequence is important, it provides information about relations downwards of the legs for example, which USM an ASM belong to, which Party a PE belong to, and so on.

The structure of messages will now be described.

Sizes of types: char = 1 byte, int = 4 bytes. For enums an int is used. In enum types the first value is always zero and stands for Undefined. It is the recommended default value when the object is created. Unused bytes are set to

Zero.

The size of TSPJVISG, USM_LEG and PARTYJ.EG is variable.

All attributes in the classes are mandatory. Some classes are mandatory in all messages like: TSPJVISG, SIC_MSG, SIJHEAD, USMJ.EG, Party_LEG.

A TSP message is built in an object of class TSPJVISG, see Table 3. Table 4 shows the attributes in class TSPJVISG, Table 5 is the table for protocol descriptors.

The TSPJVISG is mandatory in all TSP messages.

The destjd and orgjd will now be considered.

Destjd is the identity of the destination to which messages are sent. In the 23 - network it is a reference to the SI, in Emma it is a reference to the right LVSI. If the receiving instance doesn't exist then destjd = 0 and the receiver knows that this instance has yet to be created. Destjd=0 is only valid in the first Order creating the SI and in Inquiries to the B-sides.

Org Jd is a reference to the address to which messages are to be sent back for this Instance.

The value 0 for a Orgjd is not valid.

Consider the following example: Order destjd = 0 # Telling this is a new SI. org Jd = 73 # Telling where you want the Inquiry to be

# returned to.

Inquiry to calling destjd = 73 # Network sends back to the right LVSI. orgJd = 112 # Network tells the terminal where it wants

# the Reply.

Inquiry to called destj^'d = 0 # Network asks the other terminal to create a LVSI. orgjd = 114 # Network tells the terminal where it wants

# the Reply.

Reply from calling destjd = 112 # Terminal sends back to the right SI. orgjd = 73 # Terminal tells the network where it wants # the CS.

Reply from called destjd = 114 # Terminal sends back to the right SI. orgjd = 19 # Terminal tells the network where it wants # the CS. CS to calling destjd = 73 # Network sends back to the right LVSI. orgjd = 1 12 # Network tells the terminal where it wants

# new Orders. CS to called destjd = 19 # Network asks the other terminal to create a LVSI. orgjd = 114 # Network tells the terminal where it wants

# new Orders.

The structure of the PDU for TSP/SIC is of class SICJV1SG and is given in Table 6. The attributes in class SIC_MSG are given in Table 7, Table 8 is the table for Message Type.

The SICj SG is mandatory in all TSP/SIC messages.

The structure of the PDU for the USM leg is of class USM J.EG and is given in Table 9. The attributes in class USMJ.EG are given in Table 10.

The USMJ-EG is mandatory in all messages, but there is no requirement for there to be any elements in it. In this case, size_of_usmJeg = sizeof(int) = 4.

In the USMJ-EG the relationship upwards between objects is shown by putting related ASMs after its USM. ASMs under an USM is added in sequence after the USM and before the next USM.

The structure of the PDU for PARTY leg is of class PARTYJ.EG and is given in Table 11. The attributes in class PARTYJ.EG are set out in Table 12.

The PARTY J.EG is mandatory in all messages, but there is no requirement for there to be any elements in it. In this case size_of_partyJeg = sizeof(int) = 4. In the Party leg, the relationship upwards, between objects, is indicated by putting a related PAE after its PE and so on.

The classes for SIJHEAD, USM, ASM, PARTY, PE, PAE, SM and ACE all use the class ELEMENTJHEADJNJ.EG for common parts for all objects in the legs. Table 13 gives the attributes in class ELEMENT JHEADJNJ.EG:

The terminal Jd is used to identify an object sent in an order when it returns in an inquiry. When an object is created in SI, the networkjd is used as reference between LVSI and SI. The terminaljd is not be used after the object has obtained the networkjd. Some objects like SM and ACE are not given any terminaljd because they are not in the Order. The terminaljd is not unique in the SI because different terminals can use the same terminaljd values for different objects.

Only the party who has initiated, i.e. ordered, the operation on the object will receive the terminaljd set. Other parties will receive terminaljd = 0. This can be used when the terminal checks if the inquiry is a result of an own order.

A terminal doesn^'t know the partyjd of the initiator of an Order but it does know if it is an operation which the terminal initiated itself.

Fig 22 illustrates an example of the use of id.

A Table for Element Type is set out in Table 14, a Table for Operations is set out in Table 15, a Table for Responses is set out in Table 16 and a Table for Causes, is set out in Table 17

The structure of the PDU for a SIJHEAD is set out in Table 18 and Table 19 list the attributes in the class SIJHEAD.

The SIJHEAD is used for operations on the SI and LVSI object in the SI and LVSI. For example to remove a whole SI. /11886 26

Service_Utility_ref is a reference to choose a Service Control in the Terminal. This mapping is stored locally in the Terminal.

TCS_ref a reference to the TCSD to be used. In TSP/TCSD the attribute for identifying a TCSD is TCSD_HEAD::TCSDJd. Several versions of the same TCSD are possible, therefore an attribute for version is needed, TCS_version.

The structure of the PDU for USMjΞLEMENT is given in Table 20 and the attributes in class USMjΞLEMENT are listed in Table 21 :

The presence should be set in the Order and not altered in the Reply, Table 22 is the table for presence in USM.

The structure for the PDU for an ASM_ELEMENT is given in Table 23 and the attributes in the class ASMjΞLEMENT are listed in Table 24.

The presence should be set in the Order and not altered in the Reply, Table 25 is the table for presence in ASM:

The structure of the PDU for a PARTY jΞLEMENT is given in Table 26 and the attributes in class PARTYjΞLEMENT are listed in Table 27.

The presence should be set in the Order and not altered in the Reply, Table 28 gives the table for presence in PARTYjΞLEMENT.

The structure of the PDU for a PARTYJD is given inTable 29 and the attributes in the class PARTYJD are listed in Table 30.

The structure of the PDU for PEjΞLEMENT is given inTable 31 and the attributes in class PEjΞLEMENT are listed in Table 32.

The presence should be set in the Order and not altered in the Reply, Table 33 gives the table for presence in PEJΞLEMENT.

The structure of the PDU for a PAEjΞLEMENT is given in Table 34 and the attributes in the class PAEJΞLEMENT are listed in Table 35.

The presence should be set in the Order and not altered in the Reply, Table

36 gives the table for presence in PAEjΞLEMENT and Table 37 is the table for direction in the PAE_ELEMENT.

The structure of the PDU for SMjΞLEMENT is illustrated in Table 38 and the attributes in class SMjΞLEMENT are listed in Table 39.

The structure of the PDU for the ACE JΞLEMENT is given in Table 40 and the attributes in the class ACEjΞLEMENT are listed in Table 41.

The structure of the PDU for the class TRAFFICjOESCRIPTOR is given in Table 42, the attributes in class TRAFFICjDESCRIPTOR are listed in Table 43 and Table 44 is the table for Type in the ciass TRAFFICjDESCRIPTOR.

Attributes for changing state in TSP/SIC are set out below.

Attribute in the message head:

message type: { order, inquiry, reply, CS }

Attributes in the other objects:

operation : { none, create, modify, remove }

response: { none, accept, reject } 0/11886 _ ₂₈

cause: { interger value ( 0 = No cause, 1-max int = Causes) }

The response attribute is only valid for the latest message, cause is used when the response == reject.

To create an object in the other model :

message type = order

and for the object

operation = create

response = none

cause = No cause

When the network asks the terminal:

message type = inquiry

and in the object

operation = create

response = accept

cause = No cause _ ₂₉ .

If the network can not accept something in the order:

message type = inquiry

and in the object

operation = create

response = reject

cause = "Why cause"

When the terminal accepts the inquiry: message type = reply

and in the object

operation = create

response = accept

cause = No cause

or rejects something in the inquiry

message type = reply

and in the object

operation = create response = reject

cause = "Why cause"

When the network is responding to a reply a CS is sent:

message type = CS

and in the object

operation = create

response = accept

cause = No cause

In an Order the attributes Response and Cause have no meaning and the attribute Operation has the following meaning:

Operation = None : The object exist and shall not be affected.

Operation = Create : The Object shall be created.

Operation = Modify : Attributes in the object shall be modified in some way.

Operation = Remove : The object shall be removed.

Table 45 lists the meaning of the attributes Operation, Response and Cause in an Order, Table 46 lists the meaning of the attributes Operation, Response and Cause in a Inquiry, Table 47 lists the meaning of the attributes Operation, Response and Cause in a Reply and Table 48 lists the meaning of the attributes /11886 . 3 1 .

Operation, Response and Cause in a CS:

Due to the limited number of open TCP/IP connections in Vxworks, SIGNE will only have one TCP-connection to every terminal for TSP/SIC. In the terminal the NAP, or the NET object, have to implement a mux for sharing the same

TSP/SIC signalling channel between all local service instances, see Figure 10. For the other necessary connections, e.g. for registration, http, directory, etc., separate connections can be used.

Mapping between messages is illustrated in Figure 11. The process of implementing different operations on different objects in the same message is illustrated in Figure 12. The process of modifying a LVSI is illustrated in Figure 13. The process of rolling back a LVSI is illustrated in Figure 14. The process of object deletion in a LVSI is illustrated in Figure 15. The process by which the Service Control in a terminal Handles service dependent time-outs is illustrated in Figure 16. The process of sending Inquiries to parties who have not sent a Reply about changes in the Si is illustrated in Figure 17. Finally the contents of a Reply are illustrated in Figure 18. Figures 11 to 18 are self explanatory and will be readily understood by those skilled in the art and will not, therefore, be described in further detail.

Claims

1. A teleservice management system, adapted to support the provision of a plurality of complex teleservices and including a plurality of intercommunicating subsystems, characterised in that said teleservice management system includes negotiation means for settling agreements between participants to a session, resource control architectures within terminals and a resource control architecture in a transmission network, said negotiation means including a teleservice control protocol for transmitting messages between said subsystems and thereby controlling a teleservice.

2. A teleservice management system, as claimed in claim 1 , characterised in that said teleservice control protocol is arranged to link a network resource manager, service users and terminal resource managers, into a teleservice control process for facilitating delivery of a teleservice which is optimal, in terms of resource usage, and agreed by a service user.

3. A teleservice management system, as claimed in either claim 1 , or claim

2, characterised in that said teleservice control protocol is adapted for use with a plurality of different teleservices.

4. A teleservice management system, as claimed in claim 3, characterised in that said plurality of different teleservices include:

- multiparty, multimedia conference services;

tele-game services;

tele-shopping services; and

tele-education services. /11886 . 33 .

5. A teleservice management system, as claimed in any previous claim, characterised in that said teleservice control protocol messages refer to specific parts of an object oriented model of a teleservice session.

6. A teleservice management system, as claimed in any previous claim, characterised in that said teleservice control protocol is implemented in a teleservice layer and is transparently transferred in underlying layers.

7. A teleservice management system, as claimed in claim 6, characterised in that said underlying layers include network layers and transport layers.

8. A teleservice management system, as claimed in any previous claim, characterised in that said teleservice control protocol includes messages exchanged between:

a terminal part and a network part of the teleservice management system;

the teleservice management system and an application launcher daemon; and

the teleservice management system and network resource managers.

9. A teleservice management system, as claimed in any previous claim, characterised in that said teleservice control protocol has four primitives for communication within said teleservice management system.

10. A teleservice management system, as claimed in any previous claim, characterised in that said teleservice control protocol has four primitives for communication with:

a service control;

a terminal resource manager;

- a network resource manager;

and an application daemon.

11. A teleservice management system, as claimed in any previous claim, characterised in that said teleservice management system has the following interfaces:

- a first interface, between a terminal part and a signalling emulator;

a second interface, between a terminal and a service control;

a third interface, between a terminal and an application launcher daemon;

a fourth interface, between a terminal and a terminal resource manager; and

12. A teleservice management system, as claimed in claim 11 , characterised in that said teleservice control protocol is adapted to transfer information relating to a part of a teleservice object model through said first interface. /11886 _ ₃₅ _

13. A teleservice management system, as claimed in either claim 11 , or claim 12, characterised in that said teleservice control protocol is adapted to transfer information relating to a part of a teleservice object model through said second interface.

14. A teleservice management system, as claimed in any of claims 11 to 13, characterised in that said teleservice control protocol is adapted to transfer information relating to a name and parameters, associated with an application employed by a teleservice, through said third interface.

15. A teleservice management system, as claimed in any of claims 11 to 14, characterised in that said teleservice control protocol is adapted to transfer information relating to a specification of terminal resources, required by a teleservice, through said fourth interface.

16. A teleservice management system, as claimed in any of claims 11 to 15, characterised in that said teleservice control protocol is adapted to transfer information relating to a specification of network resources, required by a teleservice, through said fifth interface.

17. A service platform adapted to support the provision of a plurality of complex teleservices and including a plurality of intercommunicating subsystems, terminals and a telecommunications network, characterised in that said service platform includes resource management means, and in that a teleservice control protocol is employed for implementing protocol agents both in said terminals and in said network.

18. A service platform, as claimed in claim 17, characterised in that protocol agents are implemented in said terminals by utilising a resource control application provider interface, forming part of a network control architecture, as an interface between network resource management and a signal emulator.

19. A service platform, as claimed in either claim 17, or 18, characterised in that said terminals have at least one interface towards a user.

20. A service platform, as claimed in claim 19, characterised in that said terminals have an interface towards an application.

21. A service platform, as claimed in either claim 19, or 20, characterised in that said terminals have an interface towards a terminal resource manager.

22. A service platform, as claimed in any of claims 17 to 21 , characterised in that said teleservice control protocol is adapted for use with a plurality of different teleservices.

23. A service platform, as claimed in claim 22, characterised in that said plurality of different teleservices include:

multiparty, multimedia conference services;

tele-game services;

tele-shopping services; and

tele-education services.

24. A service platform, as claimed in any of claims 17 to 23, characterised in that said teleservice control protocol messages refer to specific parts of an object oriented model of a teleservice session.

25. A service platform, as claimed in any of claims 17 to 24, characterised in that said teleservice control protocol has four primitives for communication within said teleservice management system.

26. A telecommunications system, logically split between an application layer, a teleservice layer, a bearer service layer and a resource layer, characterised in that said teleservice layer includes a teleservice management system as claimed in any of claims 1 to 16.

27. A method of managing a plurality of complex teleservices employing a teleservice management system including a plurality of intercommunicating subsystems, characterised by settling agreements between participants to a session by exchanging messages using a teleservice control protocol, and by said teleservice control protocol linking a network resource manager, service users and terminal resource managers into a teleservice control process for facilitating delivery of a teleservice which is optimal in terms of resource usage and agreed by a service user.

28. A method as claimed in claim 27, characterised by said teleservice control protocol operating with a plurality of different teleservices.

29. A method, as claimed in claim 28, characterised by said plurality of different teleservices including:

multiparty, multimedia conference services;

tele-game services;

tele-shopping services; and

tele-education services.

30. A method, as claimed in any of claims 27 to 29, characterised by said teleservice control protocol messages referring to specific parts of an object oriented model of a teleservice session.

31. A method, as claimed in any of claims 27 to 30, characterised by implementing said teleservice control protocol in a teleservice layer and by transparently transferring teleservice protocol messages in underlying layers.

32. A method, as claimed in any of claims 27 to 31 , characterised by said underlying layers including network layers and transport layers.

33. A method, as claimed in any of claims 27 to 32, characterised by said teleservice control protocol including messages exchanged between:

a terminal part and a network part of the teleservice management system;

the teleservice management system and an application launcher daemon; and

the teleservice management system and network resource managers.

34. A method, as claimed in any of claims 27 to 33, characterised by said teleservice control protocol having four primitives for communication within said teleservice management system.

35. A method, as claimed in any of claims 27 to 34, characterised by said teleservice control protocol having four primitives for communicating with:

- a service control;

a terminal resource manager; a network resource manager;

and an application daemon.

36. A method, as claimed in any of claims 27 to 35, characterised by said teleservice management system having the following interfaces:

- a first interface, between a terminal part and a signalling emulator;

a second interface, between a terminal and a service control;

a third interface, between a terminal and an application launcher daemon;

a fourth interface, between a terminal and a terminal resource manager; and

36. A method, as claimed in claim 35, characterised by using said teleservice control protocol to transfer information relating to a part of a teleservice object model through said first interface.

37. A method, as claimed in either claim 35 or 36, characterised by using said teleservice control protocol to transfer information relating to a part of a teleservice object model through said second interface.

38. A method, as claimed in either claim 35 or 37, characterised by using said teleservice control protocol to transfer information relating to a name and parameters, associated with an application employed by a teleservice, through said third interface.

39. A method, as claimed in either claim 35 or 38, characterised by using said teleservice control protocol to transfer information relating to a specification of terminal resources, required by a teleservice, through said fourth interface.

40. A method, as claimed in either claim 35 or 38, characterised by using said teleservice control protocol to transfer information relating to a specification of network resources, required by a teleservice, through said fifth interface.