WO2013009266A1 - Service broker interconnection and method for the support of internal centrex calls - Google Patents

Abstract

The subject matter of the invention is a service broker interconnection and the procedure for the support of Centrex internal calls, whereby Centrex is a functionality of a private exchange or private network within a public exchange or public network. The service broker, which contains the relevant translation tables for connection to the application layer and the network layer and is connected using the INAP protocol with the module (1), intended for mediation to the TDM/NGN application layer and using SIP with module (2) of the IMS application layer intended for mediation to the IMS application layer. Within Centrex internal calls, it can also execute intelligent network services. End users can be SIP terminals, ISDN/POTS terminals or GSM terminals.

Description

CE BROKER INTERCONNECTION AND METHOD FOR THE SUPPORT OF INTERNAL CENTREX

The subject matter of the invention is service broker interconnection and the procedure for the support of Centrex internal calls, whereby Centrex represents a functionality of a private exchange or private network within a public exchange or public network. With the described procedure it is possible to make calls between existing Centrex subscribers from the TDM/NGN network with Centrex subscribers in IMS. The technological problem that has appeared recently, i.e., interconnection of TDM-based protocols and networks with all-IP based protocols and networks, can be solved with the described method within the framework of a standard network element known as the Service Broker, with standard protocols (SIP, ISUP), and with standard messages and methods (IAM, INVITE).

The technical problem, being successfully solved by the presented procedure, is a problem of interactions between services, protocols and networks in case we have a Centrex network. If Centrex was well-defined in the TDM world, the question remains how to provide Centrex and Centrex internal calls in case of interconnecting a TDM/NGN network on one side with an IMS network on the other side. There are no standards and instructions on how IMS and conventional networks should be interconnected in case of Centrex, or these instructions are general and incomplete. An example of a general standard is ETSI TS 182 024. Legacy telecommunications networks were based on TDM. We had separated networks such as PSTN (ISDN, SS7, etc.), PLMN (e.g., GSM) and also NGN (SIP, H323, etc.), partially based on an IP platform. Conventional networks are generally considered to be vertically integrated networks. This means that networks are independent of one another. Each such network has access, a network core and services. Services were provided already within individual networks (e.g., in the network core), some even outside the network (e.g., an IN network). Conventional networks (SS7, IN, GSM, INAP) are typically closed and oriented toward network elements.

Here comes an IMS network based on Session Initiation Protocol (SIP), and built on an IP platform. In addition to legacy TDM networks, it also supports other networks such as cable and computer networks. It is a horizontally structured network that consists of accesses (e.g., WiMAX, LTE, PSTN, NGN, ADSL, etc.), an IMS core and a service layer consisting of service enablers and servers.

The basic problem is how to connect conventional networks to the IMS network. This is a topical issue for the period of transition when the conventional TDM network will coexist with the IMS network, which can extend over a long time-frame. For all these cases there is an element provided in IMS called a service broker intended for interaction between services, protocols and networks. Its role is defined in the standard 3GPP TS 23.002, figure 1. The first definition described the SCIM (Service Capability Interaction Manager), and only explained connection to a SIP AS. Later definitions also cover other ASs (e.g., Parlay X and INAP or CAMEL AS). Figure 2 shows the most general definition of a service broker, where the service broker resides between the IMS network core and the application layer (SIP AS, OSA SCS AS, IM-SSF AS). The service broker also connects to the HSS database. The service broker must enable interconnection between different networks, and for different services.

Standards do not define how interconnection between services, protocols and networks should be provided. This is an open issue. Several patents have been filed on this subject matter. As regards problems in the service broker segment it can be said that there is no standardized solution, that manufacturers have different approaches and solutions, that solutions are non-standard, and that there are many dilemmas still open and unclear. Solutions are very different, any solutions and patents filed for the service broker standard element are mainly focused on general solutions or solutions focused on individual segments.

In our concrete case, which is the subject matter of the claim, we are solving the problem of interactions between services, protocols and networks in case we have a Centrex network. The Centrex system represents the functionality of a private exchange or private network that is implemented with software as part of a public exchange or public network. Centrex functionality makes it possible for public subscribers to create groups either inside a single exchange or across the entire public network; inside these groups it allows the use of various supplementary services similar to PBX supplementary services. If Centrex was well-defined in the TDM world, the question remains how to provide Centrex and Centrex internal calls in case of interconnecting the TDM/NGN network on one side with the IMS network on the other side. There are no standards and instructions on how IMS networks and conventional networks should interconnect in case of Centrex, or these instructions are general and incomplete. An example of a general standard is ETSI TS 182 024.

Up until now the service broker has not been defined differently than in standard TS 23.002. Additional studies were conducted in 3GPP TR 23.810, Study on Architecture Impacts of Service Brokering. The studies show that the service broker can reside on an S-CSCF, on each individual AS, or is standing alone. It is also connected to the HSS database. The application servers can be SIP ASs (for services based on SIP), OSA SCS (in the event of using open interfaces), or IM-SSF (for connection to IN/CAMEL). It can be centralized (on one of the servers only), distributed (on a larger number of servers), or hybrid (partially on one server and partially on a larger number of servers). The IMS standards define a detailed architecture for the transport and control layer; however, many questions still remain open as to how the application layer should be structured. The problem in the segment of service broker has not been addressed yet. It is a new problem that appeared with the introduction of IMS. It is a technology leapfrog that has not yet been solved and has not been fully explored. The problem occurred because transition to IMS is not possible overnight - conventional telecommunication networks as well as the IMS network will coexist simultaneously. On the one hand the problem is related to a completely different network architecture (vertical vs horizontal), and on the other hand the problem is related to protocols which are different in IMS than they were in legacy TDM/NGN. The solution in this segment is left to the market and products. One such possible solution is also the service broker, as defined by the » Service Broker Forum« (www.servicebrokerforum.org). In this case the solution is a stand-alone element that interconnects legacy networks (NGN, TDM) to new networks (IMS), and the existing services and service layers (inside the network, within IN, etc.) to the future service layer method (SDP, SIP AS, etc.).

Several patent applications have been filed on the subject matter of the service broker. The claims refer to the various options of service broker methods such as the following:

EP 2053782 A1 (A Communication Network System and Method for Providing a Service Broker Function and a Service Broker Device): the claim provides a description of a communication system and methods for the provision of the service broker function. A description of elements to which the service broker refers and the method of the service broker element operation is also provided;

WO 2007/098155 A2 (Method and Network for Providing Service Blending to a Subscriber), US 2007/0140150 A1 (Method and

Network for Providing Service Blending to a Subscriber), US 7693270 B2 (Method and Network for Providing Service Blending to a Subscriber): the method and communications network for providing a subscriber with blended services delivered by phone and TV system. The claim describes data and signal changes made by the system in case of connecting a TV delivery system and a phone;

US 2006/0104431 A1 (Method for Providing Feature Interaction Management and Service Blending): the claim describes the service broker when using a phone and a unit of the simultaneous ring set. The role of the service broker is to complete the call between the phone and the unit of the simultaneous ring set;

US 2007/0088836 A1 (Application Service Invocation Based on Filter Criteria): the method refers to the IMS system and management of trigger points;

WO/20 0/ 27626 A1 (Call Connection Method of Relation Call Between Networks and Service Broker System): the claim refers to the call connection method of a relation call between a network and the service broker element;

US 7720049 (Semantic Service Broker for Telecommunications Networks): the claim provides a service broker method when we have a subscriber and a range services, for the execution of services and the use of programming languages for that purpose; - EP 2053782 A1 (A4) and WO 2008/025211 (A Communication Network System and Method for Providing a Service Broker Function and a Service Broker Device): the claim describes a network system and methods for providing the service broker function;

US 2009/0193131 A1 (Communication Network System and Method for Providing Service Broker Function, and Service Broker Apparatus): the method for the service broker function in the event of connecting a subscriber is defined.

In conventional networks (ISDN, PSTN, PLMN, NGN) the solution for Centrex is known. The solution was based on the use of the SS7 protocol, specifically on the use of the ISUP protocol. The solution applied to the conventional TDM network as well as NGN, where within SIP-T we could use ISUP as well. It was actually about the transfer of the ISUP protocol using SIP, which was named SIP-T for such cases. The Generic Parameter was used within ISUP, and also BGID, CgPN and CdPN. In addition to the parameters, appropriate methods and mechanisms for Centrex operation in such networks were also defined. The necessary data for the translation was stored inside the exchanges themselves or in external databases (e.g., for WAC-Wide Area Centrex - this is Centrex when there are several exchanges in a network).

The described procedure consists of the service broker providing:

- mediation between networks (such as TDM and NGN on the one hand and IMS on the other), service interaction,

protocol conversion (ISUP on the one hand and SIP IMS on the other), service bundling between an NGN/TDM and IMS network;

- interconnecting the service broker element with other network elements;

- the conversion of TDM/NGN messages into IMS messages, and vice versa, for cases of Centrex internal calls, using ISUP and SIP messages, which are already standardized;

- the use of data tables for the purposes of Centrex calls;

- support for Centrex internal calls between NGN/TDM and IMS (in both directions);

- the service broker on the non-IMS side can interconnect to conventional TDM exchanges (e.g., using SS7), or to exchanges based on SIP (e.g., SIP-T, within NGN exchanges);

- the service broker is a stand-alone element. It can also be distributed, or reside in AS or in S-CSCF; - the first call message (1AM message for SS7 in TDM/NGN) from TDM/NGN to IMS contains the B subscriber number (CdPN) in the format ERN+NSN (or dicon+NSN);

- the first call message (INVITE message or method for SIP in IMS) in the direction from IMS to TDM/NGN contains the B subscriber number (CdPN) in CxDN format (CxDNCd), to which LC can be added;

- the method consists of using standard networks (IMS, TDM, etc.) and network elements (SIP, SS7, Centrex, etc.). In this way, standard logic is added to the service broker element (which is a non-standard element);

- external exchanges must have ERN or dicon entered for the direction from TDM/NGN to IMS;

- the service broker does not trigger services (it could, to an external database), but the entire logic is in the service broker element itself.

The main characteristics of the proposed procedure are the following:

- all Centrex services on all terminals across the entire network are enabled;

- support for Centrex is provided, even for cases when using Number Portability, i.e., the so called Service Portability, which is defined within Number Portability; - the described method provides a Centrex internal call (short number dialing). It is still possible to make a call to a public network (national number dialing);

- the described method makes it possible to connect subscribers from TDM, GSM, PLMN, NGN and other networks with subscribers of the IMS network in case of Centrex;

- Centrex subscribers retain their National significant Number (NSN). In addition to keeping NSN, Centrex internal numbering can be retained as well;

- with the use of the local portability function based on queries in NP DB according to the ACQ (All Call Query) method (in the originating exchange), or the QoR (Query on Release) method (use during the period of transition), it is also possible for subscribers that were migrated from TDM/NGN to IMS to make Centrex internal calls;

- use of a service broker as a mediator between TDM/NGN to IMS, and vice versa;

- the presentation of numbers is enabled in a way that internal calls are always presented with the short number. Public calls are always presented with NSN^';

- as a mediator between TDM/NGN and IMS, the service broker maps ISUP parameters (CdPN, CgPN, GN, BGID, etc.) to SIP parameters (To, From, P-Asserted Identity/PAI, phone-context, otg), and vice versa; - Exchange Routing Numbers (ERNs) of ported Centrex numbers do not refer to the mediation exchange - the service broker, but to IMS. ERN is cut off in the service broker;

- for internal calls generated in TDM/NGN systems and routed to IMS, ERN (which denotes a number inside IMS), and is obtained from NP DB, is usually added to the number. ERN is cut off in the service broker;

- for internal calls generated in IMS systems and routed to TDM/NGN, the translation of numbers from Centrex internal numbers to NSNs is performed based on a translation table. A location code (LC) can be added to the Centrex internal number. There is a translation table for each individual Centrex group;

- a national significant number (NSN1 , NSN2) is transferred in both directions;

- in case the number is ported (using NP) from TDM/NGN to IMS, the subscriber retains the same number, and can thus increase the range of possible services (from TDM/NGN to IMS), e.g., the subscriber gets some new services (such as Web browsing, Presence, IM, etc.). The service broker enables the mediation of parameters for such calls;

- in TDM/NGN, Centrex services and internal calls are executed within exchanges where the calls are located;

- when TDM and NGN are connecting, the ISUP protocol is always used. If it is transferred using SIP, it is called the SIP-T (or SIP-I) protocol - a SIP that has encapsulated ISUP messages. In the described method and system, the actual mediation of ISUP messages to SIP, and vice versa, is carried out in the service broker element;

- with the described method, Centrex mediation from TDM/NGN to IMS is possible without additional signals, methods and parameters, obviously, by taking into account certain programming logic. Used are those that are defined in the standards (ITU-T, ETSI), RFCs (IETF), or for which support is provided by the manufacturers;

- in addition to internal calls, support for supplementary services is also ensured, e.g., for services known in TDM/NGN such as call forwarding (CFU, CFB, etc.), CT, DND, and others. Service support is provided to an extent as made possible by the described method. For certain services or parts of services an additional method, which is not explained within the described method, is required for the full operation of the service;

- the service broker actually performs mediation for Centrex calls and for Centrex itself;

- in the case of a call between a TDM/NGN subscriber and an IMS subscriber the range of services is an intersection of all services. In the case of a call to the same exchange the range is the same, in the case of two exchanges the range is the intersection of the range of the services of the first and the second exchange. Similar applies to cases when a subscriber is migrated or resides on an IMS service platform;

- public calls remain the same;

- information about Centrex subscribers resides in NGN/TDM, in IMS and also in the service broker element;

- subscribers can be SIP, ISDN, GSM, H323 POTS, IMS and others.

The invention will be explained in greater detail on the basis of an

Implementation example] and pertaining figures, which show:

Figure 1 the service broker as defined by the standard;

Figure 2 the service broker in the network as defined by the standard; Figure 3 the service broker as defined by the Service Broker Forum Figure 4 interconnecting a service broker in a converging

network for the described invention method;

Figure 5 implementation procedure in the service broker element in the direction from TDM/NGN to IMS;

Figure 6 implementation procedure in the service broker element in the direction from IMS to TDM/NGN;

Figure 7 translation table between CxDN and NSN in the direction from IMS to TDM/NGN (for each BGID);

Interconnection of the service broker enables the connection of the TDM and NGN environment on one side with the IMS environment on the other. SIP is the basis for the IMS protocol. SIP was upgraded for IMS. SIP is used to control multimedia sessions that combine audio and data. IMS enables several common functions, such as AAA (authentication, authorization), charging, the HSS database, and others.

The role of the service broker element is to enable more complex service interaction scenarios. These can be accessed through certain filters. This element may contain specific intelligence and capabilities to integrate information from the network; or to execute services that are based on more complex sequences. The service broker uses the SIP interface and the ISC interface.

Interaction between services refers to the process of managing network entities that require and use network services. The mediation of protocols and networks refers to the conversion and translation of messages from one protocol to another. Mediation also indicates defining whether a certain service or subscriber is authorized or not to access certain services or applications, and also to process such authorizations.

The main task of the service broker is the selection, start and composition of services after the receipt of a SIP or TDM message. Interactions with remote servers may occur. A function of the service broker is also that the user profile and the applications profile are similar to trigger points in iFC. The service broker's task is also to provide connection within the application layer, and between the application layer and the network. The service broker also supports standard protocols for connecting to TDM and NGN. These protocols can be used for:

- connection to the application layer: INAP, MAP, CAP, WIN, SIP, SIP Simple, SCCP, TCAP, SMPP, SIGTRAN, Radius, and similar;

- connection to the network layer: USSD, SIP, SIP-T, SIP-I, ISUP, H323, Diameter, SIGTRAN, MGCP, H248, and similar;

- connection to the database and administration: SNMP, XCAP, HSS and similar. In this case connection is possible with the use of http, via ODBC, RPC, via SIP or via Diameter.

- the service broker can connect to various network elements such as HLR, SCP, MSC, TDM switch, NGN Softswitch, USSB gateway, Media Gateway, MGCF, SIP AS, IMS AS, S-CSCF, HSS, a charging system, and similar.

Within the framework of the suggested method the described interconnection of the service broker in a converging network is presented in Figure 4, which shows the interconnection of the service broker for deployment within the framework of the described method, for interconnection in the NGN/TDM/IMS network.

The service broker itself consists of module 1 , which is intended for mediation to TDM/NGN; module 2, which is intended for mediation to IMS, and the relevant translation tables. From the standpoint of the IMS network architecture, the service broker network element can connect to the application layer and to the network layer. The application layer and the network layer can be based on TDM/NGN or IMS elements, or functionalities, respectively.

In case of TDM/NGN the service broker at the application layer connects to SCP (Service Control Point) in module 1. Connection between the service broker and SCP is via the INAP protocol. SCP consists of the part intended for services, and of a database. Number portability can also be carried out in SCP, and not only in the TDM/NGN network. In that case the part for the number portability service (NP) execution and the relevant NP database reside in SCP. Additionally, in SCP, within Centrex internal calls using NSN, it is also possible to execute IN (Intelligent Networks) services such as VPN (Virtual Private Network), FPH (Free Phone), MAS (Mobile Assistant), PRM (Premium Rate) and others. Connection to the IMS application layer is via SIP. There can be various IMS-based or SIP- based application servers (ASs) within the IMS application layer. Or it can be a service delivery platform (SDP). In case of connecting to the TDM/NGN network 3, the SS7 protocol is used. If we have a combination of TDM and IP, SIGTRAN protocols are used (e.g. M3UA, M2UA, M2PA, etc.), and MGCP/H248. In case of an IP connection the SIP-T protocol is used. In all these cases the service broker can connect to public exchanges, private exchanges (e.g., PBX) and Mobile Switching Centers (MSCs). For cases of using the number portability (NP) service, a database (intended for NP) also resides within network 3 (TDM/NGN network). In all these cases end-users can be SIP terminals, ISDN/POTS terminals or GSM terminals. The service broker connects to the IMS network 4 using SIP and the Diameter protocol. In this case, the service broker connects to the HSS (Home Subscriber Server) database and the S-CSCF, l-CSCF and P-CSCF elements. IMS terminals or other terminals can be used within the IMS network.

The Centrex system is a functionality of a private exchange or private network that is implemented with software within a public exchange or public network. The Centrex functionality is a complete set of user and network signaling, supplementary services and other telecommunications services that make it possible for public subscribers to form groups either inside a single exchange or across the entire public network; inside these groups, it allows the use of various supplementary services similar to PBX supplementary services.

Centrex is known already within the framework of TDM and also NGN. There, solutions are provided within the SS7 protocol. In the case of the SIP-T protocol, ISUP messages are transmitted via SIP. This is why the solution for NGN is based on the ISUP protocol. In our case, we are dealing for the first time with a direct connection between the SS7 protocol and SIP for IMS, and the conversion of parameters between these two protocols and the relevant networks.

Centrex allows the administration of a Centrex subscriber, a Centrex group, a Business Group, and other data. There is also Centrex numbering, through which we can make internal calls of various types (remote, quasi-remote, etc.). Internal numbering is used for internal calls (within a Centrex group). Calls within the group are charged in the way defined for a group (free-of-charge calls, reduced tariff, etc.). In addition to Centrex internal calls, public calls can also be made, as in a public telephone network.

The Centrex subscriber is a public subscriber who is a member of a Centrex group. Each Centrex subscriber has its own public (NSN) and internal subscriber number. Each Centrex subscriber has exactly one internal number. Centrex subscribers keep their national significant numbers (NSNs). The entire range of basic public subscriber supplementary services and additional supplementary services and/or their modifications that are offered by the membership in a Centrex group are available to the Centrex subscriber. The range of basic and supplementary services is uniform for the national significant number (NSNCd, NSNCg) and the internal number (CxDNCd, CxDNCg). The range of services is associated with the NSN.

A Centrex group is a group of subscribers that is configured in a way to provide most of the PBX features. Apart from subscribers, a Centrex group may also comprise PBX systems (PBX subscriber). The Centrex group is determined by its CGID identity. CGID is unambiguously defined within a single call server or a single exchange. The same CGID can be used for different Centrex groups in the network, even if the Centrex groups with the same CGID are connected into a single business group. A business group is identified by BGID. A business group can extend across several exchanges. A Centrex group can be assigned its own public Centrex number. This number is part of the public numbering and is assigned according to the same criteria as subscriber numbers and must not be assigned to any subscriber of the call server. If a public Centrex number is assigned to a Centrex group, then it should be defined if the group is allowed to accept group Centrex calls from the entire network or just from its own business group.

The following terms are important for Centrex connections:

Centrex call - this is a call where the short Centrex number

(CxDN) is dialed;

routing number (RN) - a number that enables call routing to a migrated (ported) subscriber; it defines the receiving network or the receiving exchange, or an interconnection point or a network termination point;

CGID (Centrex Group Identity) - identity of a Centrex group in an exchange;

ERN (Exchange Routing Number) - a routing number that defines an exchange with a ported number (recipient);

- LC - local code (e.g., of an IMS network);

BGID - Business Group ID;

NDC - National Destination Code; NSN - National Significant Number, defined as NDC+SN (e.g., 4-5561010);

SN - Subscriber Number (e.g., 556 010);

CdPN - Called Public Number (NSN) (B subscriber number); CgPN - Calling Public Number (NSN) (A subscriber number); NP DB - Number Portability Data Base

Numbers can be: called numbers (e.g., NSNCd, xDNCd), i.e., B subscriber number, and calling numbers (e.g. NSNCg, xDNCg), i.e., A subscriber number.

In IMS, subscribers are assigned to a certain AS, e.g., a Centrex AS, where services will be executed. New Centrex subscribers can be included in IMS in several ways. The first option is to migrate an existing subscriber from TDM/NGN to IMS. This can be a very contemporary solution, since the subscriber can thus get new services which they did not have in TDM/NGN. In addition, the subscriber retains their numbering which in this case physically resides in the IMS exchange. The second option is virtual NP, which is a similar solution. It is suitable for cases where a completely new subscriber is added to IMS, numbering is added in TDM/NGN, and by using NP, the subscriber is then ported to IMS. Virtual NP indicates that the subscriber in TDM/NGN is virtual, and was not present there until then. The third option is a completely new subscriber in IMS; in that case information that such a subscriber resides in IMS is added in TDM/NGN, and therefore a certain prefix is introduced.

The described method supports interconnection for Centrex calls for all the described options. The first and the second option also require ERN for calls from TDM/NGN. The third option usually does not contain this information, but can use dicon (prefix).

Calls that are possible within the described method are internal calls between Centrex subscribers. These are calls using a short number.

It is also possible to make calls within the described method when subscriber migration took place, e.g., from the TDM/NGN environment to the IMS environment. In that case the subscriber can also use services that are available in IMS SIP ASs. The range of services can be much larger than in NGN/TDM. Certain web services can be used as well. In case of subscriber migration, a part of the solution for NP is used. This part involves the use of Service Portability, which is defined within the framework of NP standards. Service Portability is an option for the user to retain their existing TDM/NGN number, while changing the range and scope of the services.

With the described method, Centrex conversion from TDM/NGN to IMS without additional parameters is possible, however, taking into account certain programming logic. Data for ISUP and parameters for SIP are used such as: From, To, PAI (P-Asserted-ldentity), and methods such as INVITE, 200, 302 and BYE. A call to the exchange can come from different networks. It can be the SS7 or SIP-T protocol. SIP-T also carries, within the SIP protocol, information about ISUP. In both cases the information received is contained in ISUP messages. NSN is transferred in both directions.

In the TDM/NGN network as well as in the NGN/TDM network routing tables it is necessary to add ERN to the number. ERN is obtained from NP DB. ERNs of Centrex numbers do not refer to the mediation exchange - the service broker, but to the IMS system Thus, ERN points to the IMS network where the Centrex subscribers (actual or ported) reside. ERN is cut off in the service broker.

From the TDM/NGN network, information for CxDNCg, CxDNCd, ERN and NSNCd, BGID and optionally also for NSNCg, is sent in the 1AM message of the ISUP protocol. If NSNCg is not present, it is obtained by the service broker. Data is transmitted by the ISUP protocol, the BGID, CgPN, CdPN parameters and the Generic Parameter. In case of a Centrex call from TDM/NGN to IMS, information about the number contained in the SIP protocol of the INVITE message (method) is transmitted to the IMS network by the To, From and PAI parameters. In SIP messages, within the INVITE method, the CxDNCd information is contained in the To and phone-context parameter, the NSNCg information is contained in the From parameter, and the CxDNCg information is contained in P-Asserted-ld (PAI). All messages, methods and parameters are defined in existing standards (ITU-T, ETSI, IETF RFC). The implementation method in the service broker element with a description of mediation is illustrated in figure 5.

With the described method Centrex internal calls from IMS to TDM/NGN are also possible; however, taking into account certain programming logic. The ISUP parameters Generic Number, CdPN, CgPN, BGID are used to make a call; parameters such as From, To, PAI, and methods such as INVITE, are used within the SIP parameters.

A call to the exchange comes from the IMS network using SIP and the INVITE method (message). In the service broker, the CxDNCd information is contained in the To and the phone-context parameter, the LC+CxDnCg information with the otg parameter and the BGID value is contained in the From parameter, and the LC+CxDNCg information is contained in the PAI parameter, which does not contain the otg parameter. LC can be present in both cases, or not. The service broker processes this information. Centrex subscribers are entered in Centrex tables where NSN is read based on the Business Group ID (BGID) and the Centrex internal number (CxDN). Because the table is uniform, both called and calling numbers are read. The service broker has a translation table for each BGID (Centrex group). On the basis of the translation table, and taking into account the BGID and CxDN information, data for NSN is read. The information is then translated from SIP to ISUP messages. An ISUP 1AM message is coded toward TDM/NGN - BGID, NSNCd, NSNCg, and Generic Number information is sent (CxDNCg and CxDNCd data). All messages, methods and parameters are defined in existing standards (ITU-T, ETSI, IETF RFC). An exception is the otg parameter, which is not standardized in IETF RFC. Even though the parameter is not standardized, it is used by a number of telecommunications equipment manufacturers.

The implementation method in the service broker element is illustrated in Figure 6. Figure 7 shows how the translation table works. The table applies to each individual BGID.

The described method allows the set-up of Centrex calls even in cases of subscribers ported with the use of NP (Number Portability).

The use of NP is known from the SS7 standards. This is the so called Service Portability, which is defined in the NP standards. A Centrex subscriber is locally ported from TMD/NGN to IMS. The subscriber in IMS thus obtains a wider range of services.

A locally ported subscriber is entered in the NP database (DB NP) in the form that is known from inter-operator portability. Thus, the NSN (National significant Number) is translated into ERN (Exchange Routing Number)+NSN.

The ACQ method (reasonable for a larger number of ported numbers) is activated in the originating exchange (TDM/NGN), and triggers a query in the NP database based on a digit analysis. The depth of the digit analysis (only the prefix or the entire called number) is set administratively depending on the number of locally ported subscribers. If there are several locally ported numbers in a compact block, then a query is activated according to a block; however, if the ported numbers are scattered, then it is more reasonable to make a query in NP DB according to the entire number.

In addition to the ACQ method there is also the QoR method (it generates more traffic, so it is used for a smaller number of ported numbers). With the QoR method, a message about a ported subscriber (SS7 REL message, cause #14) is transmitted to the originating exchange. A query in NP DB is made in the originating exchange. Since this method is used for inter-operator portability, additional network planning is required to prevent interaction between the inter-operator and locally ported subscribers.

In the case of a public call, a query is made in the NP database (NP DB) if a public subscriber has been locally ported, if only a few Centrex numbers have been locally ported or if an entire Centrex group has been ported.

Queries in the NP database can also be made directly from the service broker element. In this case the NP database can reside in SCP; connection is via INAP.

Mediation from the service broker to IMS is possible directly or through a database (e.g., HSS or quasi-IMS). In case of a direct connection, an INVITE message is sent to IMS. Access to the database is possible with the use of standard LIA and LIR messages of the DIAMETER protocol. This is direct access to the IMS HSS database.

Access to the database is also possible with the use of conventional SIP messages, e.g., if direct DIAMETER access to HSS is not available. In that case, the IMS database may be accessed in the location database (LDB) itself. And in this database data conversion is carried out, e.g., for data from HSS. In this case, the first INVITE arrives to LDB. LDB returns 302 with the cause "Temporarily moved". The service broker confirms the receipt of the 302 signal to LDB with ACK. Contact contains the IP address for the first and the second IMS exchange (IP1 and IP2). Based on the result, the service broker sends an INVITE message to CSCF1 (with the IP1 address), or to CSCF2 (with the IP2 address). This is shown in Figure 9. It is also possible to select and use an additional database (e.g. LDB2) in case LDB does not respond or is overloaded. The location database can also be placed in the service broker element itself.

In addition to support for the operation of Centrex internal calls, the described method also provides support for supplementary services. These are services as known in TDM /NGN. Support is provided to such an extent as made possible by the described method. An additional method, which is not described within the suggested method, is necessary for the complete operation of certain services or parts of services. Within the described method, support is ensured for Call Completion Supplementary Services, such as Call Intrusion - CINT, Call Intrusion Protection - CINTP, Camp On Busy - CAMP, etc.; for Call Offering Services, such as Call Transfer Controlled - CTC, Night Service (Individual, Group) - NS, NSG, Call Pick Up, Single - CPUS, Call Pick Up, Group - CPUG, Multi-level Precedence and Preemption Service - MLPP, etc.). Support is also ensured for special Centrex supplementary services (such as Abbreviated Dialing, Group List - ABDG Call Forwarding for External Call Only, Emergency Call for Centrex Users, CTX Presentation Number, Interception of Calls for CTX - IOC, Announcement Service For CTX, First Dial Tone for CTX), and others. Support for the abovementioned supplementary services within the described method is ensured in part or in whole.

The described service broker solution allows the interconnection of conventional TDM/NGN networks (PLMN, GSM, PSTN, ISDN, SS7, etc.) to new IMS networks in cases of Centrex internal calls. This is applicable if one of the Centrex subscribers is in TDM/NGN and the other is in IMS and also in a subscriber in IMS is migrated to TDM/NGN. With the described solution it is possible to extend a private Centrex network from TDM/NGN to IMS.

The advantages of the described method are summarized in the following points: it is a solution that uses standard solutions in the entire segment, namely, parameters for Centrex that are already known in SS7 (ISUP), and parameters that are known and used in SIP (for IMS);

in this solution we use components already known (IMS elements, TDM network elements, ISUP, SIP, service broker, NGN, IMS, etc.);

the service broker element, which is defined in the standards as a »black box« and which is the subject of various researches, solutions and patents, has been extended to support a Centrex network;

there is no need to change any of the existing protocols or parts of the network (e.g., SIP, ISUP, TDM exchanges, etc.), and there is no need for an additional database (e.g., a special external database for Centrex internal calls);

mediation from NGN/TDM to IMS, and vice versa, is carried out in a single network element using the described method

(program code, use of translation tables);

support for the Centrex solution also when using the standard

Number Portability procedure when Centrex subscribers are ported from TDM/NGN to IMS, and the use of the »service portability« option as viable within the Number Portability; with the described method it is also possible to ensure, in part or in whole, apart from regular internal calls, support for Centrex supplementary services such as call forwarding (CFU, CFB, etc.), conference calls (CONF), call intrusion (CINT), call transfer (CT), do not disturb (DND), line hunting (LH), anonymous call rejection (ACR), number presentation (CLIR, CLIP, etc.) and others;

the entire logic for interworking between various networks and services resides in a single network element, i.e., the service broker element. The above-mentioned logic connects to various parts of the network such as interfaces for H248/MGCP, SIGTRAN, SIP, SIP-T, and others,

with the described method it is possible to migrate existing TDM/NGN subscribers to IMS in a simple manner and thus ensure that the existing TDM/NGN Centrex subscribers get a new IMS functionality that resides, for example, in a Centrex AS inside the IMS network;

It is not necessary for the service broker to trigger services for Centrex internal calls, e.g., via INAP to external SCPs in case when a subscriber is migrated from TDM/NGN to IMS. Thus, the service broker does not become a traffic bottleneck (additional traffic from the service broker to SCP and back for each call to the ported number). In this case, information as prepared within the TDM/NGN exchanges, reaches the service broker.

Claims

Service broker interconnection and the procedure for the support of Centrex internal calls,

characterized that,

the service broker containing the relevant translation tables for ion to the application layer and the network layer, whereby the application layer and the network layer are based on TDM/NGN or IMS elements or functionalities, is connected using the INAP protocol with the module (1), intended for mediation to the TDM/NGN application layer and using SIP with module (2) of the IMS application layer intended for mediation to the IMS application layer; that SCP in the module (2) of the IMS application layer consists of the part intended for services and a database; that for number portability, SCP in the module (2) of the IMS application layer contains the part for the execution of the number portability (NP) service, together with the relevant NP database; that within Centrex internal calls, SCP can also execute intelligent network services such as VPN, FPH, MAS, PRM and others by using NSN; that different applications servers based on the IMS or SIP or SDP service platform may reside within the IMS application layers; that the service broker is connected to the TDM/NGN network (3) via the SS7 protocol, and in a combination of TDM and IP via the SIGTRAN and MGCP/H248 protocol; in the case of all-IP connection the service broker is connected using the SIP-T protocol with public exchanges, private exchanges (PBXs) and Mobile Switching Centers (MSCs), and in cases of the use of number portability (NP) services a NP database resides within the TDM/NGN network (3), and in these cases end users can be SIP terminals, ISDN/POTS terminals or GSM terminals; that the service broker connects to the IMS network (4) via SIP and the Diameter protocol to the HSS database and the S-CSCF, l-CSCF and P-CSCF elements, and IMS terminals can be used within the IMS network (4).

Service broker interconnection and the procedure for the support of

Centrex internal calls, according to claim 1 ,

characterized that,

the procedure of connecting to module (1) of the TDM/NGN application layer comprises the following steps:

receiving ISUP data from TDM/NGN from the IAM message, called party number: ERN+NSNCd, other data: BGID, NSNCg (optional), CxDNCg, CxDNCd;

reading the BGID, CxDNCd, CxDNCg, NSNCg (if present), NSNCd parameters, cutting off ERN;

adding NSNCg, unless present; preparing an INVITE SIP message (method), defining the following values: To= CxDNCd, phone-context From= NSNCg, PAI= CxDNCg;

sending the INVITE SIP message to IMS.

Service broker interconnection and the procedure for the support of Centrex internal calls, according to claim 1 ,

characterized that,

the procedure of connecting to module (2) of the IMS application layer comprises the following steps:

receiving SIP data from IMS from the INVITE message

(method) (LC can be present or not): called party number.

To=CxDNCd, phone-context, other data: from=LC+CxDNCg, otg=BGID, PAI=LC+CxDNCg;

reading the To, From, PAI parameters, cutting off LC (if present);

obtaining NSN from the translation table, based on BGID and CxDN;

preparing an IAM ISUP message with the following parameters: Generic Number (CxDNCg, CxDNCd), BGID, CdPN (NSNCd), CgPN (NSNCg);

sending the IAM ISUP message to TDM/NGN.