Service deployment architecture

Details Service deployment architecture Service deployment architecture

2001-03-28

2004-09-07

Tran, CongVan (Department: 2681)

Telecommunications

Radiotelephone system

Zoned or cellular telephone system

C455S435200, C455S405000

Reexamination Certificate

active

06788939

ABSTRACT:

FIELD OF THE INVENTION
The invention relates to a method of making communication or information services via a telecommunication network available to service users. More particularly it relates to a method of providing interprocess communication between service providers and service users via a notification and synchronization entity that has access to service nodes via which service agents are executable.
BACKGROUND OF THE INVENTION
A service can be implemented in a telecommunications network either directly in the switches or via a so-called intelligent-network architecture.
A direct implementation in the switches is in principle only suitable for networks with a small number of switches, because to be ubiquitous any new service logic has to be put into all of the switches of the network. For a network with a large number of switches such a task is time-consuming and inefficient. If the switches are from different vendors, this may even become impossible to realize.
The intelligent-network architecture was designed for a rapid deployment of services. The service logic therefore resides not in the switches but in so-called service control points (SCPs), which also contain service-specific data that allows the service providers to customize services. Switches enhanced with the capability of recognizing when it is necessary to communicate with an SCP in order to get instructions on how to proceed further with a call, are called service-switching points (SSPs).
The service logics are hence moved to a few centralized SCPs, thereby accelerating the deployment of new services because less network components are involved than in the case of direct implementation. It however requires new operation and management systems in order to introduce the service logics into the SCPs, to manage and customize them, and sometimes to set the required service triggers in the SSPs, such as recognizing the prefix of a service.
In the intelligent-network architecture only the communication between the SCPs and the SSPs is standardized but not the required operation and management systems. This lack of standardization leads to incompatible and vendor-specific SCP/SSP platforms. A rapid deployment of services is only possible within a single-vendor environment. Furthermore it is not possible to port a service logic written for a specific platform to another one, thus making it almost impossible to deploy and manage a service across multiple platforms.
In IP telephony the architecture does not require any voice switches, which is besides the use of IP as communication means for both signaling control information and voice signals the most important difference to legacy telephone networks like PSTN or ISDN. Voice signals are sent directly between the terminals, reusing the same IP routers infrastructure as for the exchange of signaling information. The most widespread IP telephony architecture is based on the ITU-T recommendation H.
323
. In this case the terminals are connected additionally to gatekeepers which only perform call control functions such as registration, access and admission control, address translation, etc. The gatekeepers have no voice-switching capabilities and hence can be implemented by means of conventional software servers. The signaling information may be either exchanged directly, i.e. the signaling information needed for the control of a telephony call is exchanged directly between the involved terminals, or with the gatekeeper-routed method in which case the terminals talk to their gatekeeper which has the control over the telephone call. The gatekeeper-routed method provides to a service provider a point via which it can access and control an IP telephone call. The gatekeeper thus enables the service provider to offer not only PSTN-like supplementary services like call forwarding or call completion, but also more advanced services by combining telephony with other information services, e.g. a stock alert service where the service user is alerted via a telephone call if the price of a certain stock crosses a certain limit. The architecture described above also applies for other protocols like IETF-SIP or -MGCP.
The IN architecture can also be applied to IP telephony. The gatekeepers are considered as SSPs, which means that they intercept the telephone calls and recognize when it is necessary to contact an SCP for further instructions on how to proceed with a call from an IN-point of view. The only difference between a gatekeeper and an authentic SSP is that the gatekeeper performs only call control whereas an authentic SSP performs both call control and voice switching. This IN-based architecture allows for telecommunication service providers to reuse their expensive SCP-based service infrastructure to offer supplementary services to IP telephony users. However it exhibits the disadvantage of the vendor-specific aspect of SCP platforms which hinder the rapid deployment and the portability of services. It also reduces the range of offerable supplementary services to the capability of the existing SCPs.
SUMMARY OF THE INVENTION
It is an object of the invention to provide an architecture for service deployment that is scalable in number of service users, service executions, services and service providers.
It is another object of the invention to provide an architecture for service deployment that circumvents the problem of vendor-specific implementation which restricts the implementation of new services and the deployment and portability of services and reduces the range of offerable supplementary services to the capabilities of existing service-control points.
It is another object of the invention to provide an architecture for service deployment that provides to a service provider an easy and efficient means for supplying new services into the network and modifying them.
It is another object of the invention to provide an architecture for service deployment that allows service subscribers to directly customize their service profiles.
It is another object of the invention to provide an architecture for service deployment that permits the addition and removal of service nodes to distribute load over multiple such nodes, requiring only a minimum configuration therefor.
It is another object of the invention to provide an architecture for service deployment that is more reliable because a failing service node can be easily replaced by another one.
The invention is directed to a method of making communication or information services via a telecommunication network available to service users. In accordance with the method, registrations for service offer references are received from agent initiators. These agent initiators may reside in service nodes where they have been preprogrammed to register for certain services under the respective service offer references. For these references even a wild card approach may be used which refers to more than one service at once.
Also from a service provider for a service a service offer notification comprising a service offer reference is received. This is done via a provider module that provides its input to a notification and subscription service entity, also called NaSS entity, where the service offer references are received. The NaSS entity is performing the function of a repository of information where the information is collected and may be accessed by other entities. It may also be seen as sort of marketplace where the service providers present their services which may be then accessed by others. There may be several service providers offering several services, each of which corresponds to a service offer notification.
Then, to those agent initiators who have registered themselves under the received service offer reference, the service offer notification can be forwarded, i.e. if there is a match between an offered service and a desired service, information about the service, being contained in the service offer notification, is delivered to the agent initiator who asked for that service. The service offer notification is usable for obtain

Affiliated with

Also associated with

Rating

Service deployment architecture does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Service deployment architecture, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Service deployment architecture will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3199748