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
  • H04Q3/0054—Service creation techniques

Definitions

• 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
• 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.
• 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
• 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;
• 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.
• 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.
• 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;
• 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.
• TCP of the present invention 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 TCP messages used in the present invention refer to specific parts of an object oriented model of the teleservice session
• 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
• 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:
• 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;
• Said teleservice management system may have the following interfaces:
• 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.
• 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.
• 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;
• Said teleservice control protocol messages may refer to specific parts of an object oriented model of a teleservice session.
• Said teleservice control protocol may have four primitives for communication within said teleservice management system.
• 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:
• 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:
• Said teleservice control protocol may have four primitives for communication within said teleservice management system.
• Said teleservice control protocol may have four primitives for communicating with:
• Said teleservice management system may have the following interfaces:
• a fifth interface between a signalling emulator and a network resource manager.
• 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.
• 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 Chandler 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
• 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
• Table 48 gives the meaning of the attributes Operation, Response and Cause in a CS.
• TSMS teleservice management system
• the present invention relates to a teleservice management system employing a teleservice control protocol which implements these functions.
• TCP Teleservice Control Protocol
• the TCP includes messages exchanged between: the terminal part (EMMA) and network part (SIGNE) of the TSMS;
• TRM Terminal Resource Manager
• NVM Network Resource Manager
• Table 1 lists the different information transferred through the different interfaces of the TSMS.
• TCP Transmission Control Protocol
• the creation, modification and termination, of teleservice sessions proceeds using the same message types, but with different contents.
• 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..
• the TCP can also be used in Service Platforms as an extension for Resource Management.
• 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
• NRM/SIGNE interface should have at least one interface toward the user and, optionally, two more interfaces toward the application and the terminal resource manager.
• 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.
• TSP is a family of protocols which sit on top of TCP/IP for Signalling in
• 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 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.
• the terminal When the terminal has processed the Inquiry and allocated ABBs, it gives an answer by sending a Reply to the network.
• 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 .
• 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.
• the terminal 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.
• 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.
• TSPJVISG The size of TSPJVISG, USM_LEG and PARTYJ.EG is variable.
• 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.
• Org Jd is a reference to the address to which messages are to be sent back for this Instance.
• 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 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 terminal Jd is used to identify an object sent in an order when it returns in an inquiry.
• 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.
• 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.
• Table 14 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.
• the attribute for identifying a TCSD is TCSD_HEAD::TCSDJd.
• Table 22 is the table for presence in USM.
• Table 25 is the table for presence in ASM:
• Table 28 gives the table for presence in PARTYj ⁇ LEMENT.
• Table 33 gives the table for presence in PEJ ⁇ LEMENT.
• 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.
• 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
• Table 48 lists the meaning of the attributes /11886 . 3 1 .
• SIGNE will only have one TCP-connection to every terminal for TSP/SIC.
• 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.
• necessary connections e.g. for registration, http, directory, etc., separate connections can be used.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Telephonic Communication Services (AREA)
• Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
• Communication Control (AREA)

Applications Claiming Priority (5)

Publications (1)

Family

ID=26663371

Family Applications (1)

Country Status (5)

Families Citing this family (1)

• 1999
  • 1999-07-13 SE SE9902683A patent/SE9902683L/ not_active Application Discontinuation
  • 1999-08-24 EP EP99944974A patent/EP1108322A2/de not_active Withdrawn
  • 1999-08-24 WO PCT/SE1999/001445 patent/WO2000011886A2/en active Application Filing
  • 1999-08-24 EE EEP200100120A patent/EE200100120A/xx unknown
• 2001
  • 2001-02-22 NO NO20010895A patent/NO20010895L/no not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events