SI23819A - Service broker interconnection and the procedure for the support of centrex internal calls - Google Patents

Abstract

The subject of the invention is connecting a service broker and a procedure for supporting Centrex internal calls, whereby Centrex represents the functionality of a private switchboard or a private network within a public switchboard or a public network. The service broker, which contains the appropriate translation tables, for connection to the application layer and to the network layer, where the application layer and the network layer are based on TDM/NGN or IMS elements or functionalities, is connected via the INAP protocol to the module (1) intended for conversion to TDM/NGN of the application layer and via the SIP protocol with module (2) IMS of the application layer, which is intended for conversion to IMS of the application layer; that the SCP in module (2) of the IMS application layer consists of a part dedicated to services and a database; that for the portability of the number on the SCP, in module (2) of the IMS application layer there is a part for the implementation of the terminal portability (NP) service, as well as the appropriate database for the NP; that SCP can also perform intelligent network services such as VPN, FPH, MAS, PRM and others within the framework of Centrex internal calls using a public number; that within the framework of the IMS application layer, there can be various application servers based on IMS or SIP or SDP service platforms; that the service broker is connected to the TDM/NGN network (3) via the SS7 protocol, and in the case of a combination of TDM and IP via the SIGTRAN protocol and MGCP/H248, and in the case of only IP connection, the SIP-T protocol in these cases the service broker is connected to public switchboards, private switchboards (PABX) and mobile switchboards (MSC) and for cases of using the number portability (NP) service within the TDM/NGN network (3) there is also a database for NP and the end users in these cases can be SIP terminals, ISDN /POTS terminals or GSM terminals; that the service broker connects to the IMS network (4) via SIP and Diameter protocol to the HSS database, as well as S-CSCF, l-CSCF and P-CSCF elements, and IMS terminals can be used within the IMS network (4).

Description

CONNECTING THE SERVICE INTERMEDIARY AND PROCEDURE FOR

INTERNAL CALL CENTERKS SUPPORT

The object of the invention is to link a service broker and a process for supporting centrex internal calls, wherein the centrex represents the functionality of a private switchboard or private network within a public switchboard or public network. With the described procedure, it is possible to make calls between existing Centrex subscribers from TDM / NGN network with Centrex subscribers in IMS. A new technology problem, that is, connecting TDM-based protocols and networks with fully IP-based protocols and networks, is solved using the described method within a standard network element called a Service Broker, with standard protocols ( SIP, ISUP) and standard messages and methods (IAM, INVITE).

is The technical problem that the procedure presented successfully solves is the problem of interactions between services, protocols, and networks, for example, when we have a centrex network. If centrex has been well defined in the TDM world, the question remains how to provide centrex and centrex internal calls when connecting a TDM / NGN network on the one hand to an IMS network on the other. There are no standards and guidelines on how to connect IMS and classic networks to the centrex case, or these guidelines are general and not completed. An example of a general standard is ETSI TS 182 024.

Previous telecommunication networks were based on TDM. We had separate networks, such as PSTN (ISDN, SS7, PLMN (eg GSM), and also NGN (SIP, H323, ..), which is already partly based on IP. Classic networks are considered vertically integrated networks. This means that the networks are independent of each other, each network having access, the core of the network, and the services already provided within individual networks (eg in the core of the network), and some also offline (eg AND network). Classical networks (SS7, IN, GSM, INAP) are typically closed and routed to network elements.

An IMS network based on SIP is coming and is built on a purely IP basis. In addition to existing TDM networks, it also includes other networks, such as. cable and computer. It is a horizontally structured network consisting of accesses (eg WiMAX, LTE, PSTN, NGN, ADSL, ...), an IMS kernel, and a service layer made up of Service Enablers and servers.

The basic problem is how to connect classic networks to the IMS network.

This question is relevant for a transitional time when, in addition to the IMS network, the classic TDM network will coexist, which can take quite some time. For all such cases, an element called a Service Broker is provided in the IMS for the purpose of interaction between services, protocols, and networks. Its role is defined in 3GPP TS 23.002, Figure 1. The first definition referred to SCIM (Service Capability Interaction Manager), and defined only connection to SIP AS.

Subsequent definitions also cover other ASs (eg to Parlay X and to INAP or CAMEL AS). Figure 2 shows the most general definition of a service agent where the service agent is located between the core of the IMS network 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 be able to connect between different networks and for different services.

The standards do not specify how the interconnections between services, protocols and networks should be ensured. This is an open problem. Several patents have already been applied to this topic. Problems in the service broker segment can be said that there is no standardized solution, that manufacturers have different approaches and solutions, that solutions are non-standard, and that many dilemmas remain open and unclear. The solutions are very different, potential solutions and patent applications for the standard element Service Broker focus mostly either on general solutions or focused solutions for individual segments.

In our specific case, which is the subject of the application, we solve the problem of interaction of services, protocols and networks for the case when we have a centrex network. The Centreks system represents the functionality of a private switchboard or private network implemented with software within a public switchboard or public network. Centrex functionality enables subscribers to connect to groups either within a single switchboard or across the entire public network and within these groups,

the use of various complementary services similar to the supplementary services for ΡΒΧ. If centrex has been well defined in the TDM world, the question remains how to provide centrex and centrex internal calls when connecting a TDM / NGN network on the one hand to an IMS network on the other. There are no standards and guidelines on how to connect IMS and classic networks to the centrex case, or these guidelines are general and not completed. An example of a general standard is ETSI TS 182 024.

So far, the service broker has not been defined other than in TS 23.002. Additional studies were made in 3GPP TR 23.810, Study on io Architecture Impacts of Service Brokering. Studies show that the service broker may be located on the S-CSCF, on an individual AS, or stand alone. It also connects to the HSS database. Application servers can be SIP AS (for SIP protocol-based services), OSA SCS (when using open interfaces) or IM-SSF (to connect with is IN / CAMEL). It can be centralized (on one server only), distributed (on multiple servers), or hybrid (partly on one server and partly on multiple servers). IMS standards define a detailed architecture for the transport and control layer, but leave many questions open as to how the application layer should be structured.

The problem in the service broker segment has not been solved so far.

This is a new problem that has arisen with the advent of IMS. This is a technological leap that has not yet been solved and has not been fully explored. The problem arose because the transition to IMS is not possible overnight, but at the same time, both classic telecommunications networks and the IMS network will coexist. On the one hand, the problem is related to a completely different network architecture (vertical vs. horizontal), and on the other, the problem is related to protocols that are different in IMS than they were in TDM / NGN so far.

The solution in this segment is left to the market and the products. One such solution is a service broker, as defined by the Service Broker Forum (www.servicebrokerforum.org) · In this case, it is a stand-alone element that connects existing networks (NGNs, TDMs) to new networks (IMS), and previous services and service layers (within the network, within IN, ..) with the future service layer mode (SDP, SIP AS, ..).

Several patent claims have been filed on the topic of service broker. The requirements relate to the various options of service broker methods, and are e.g. the following:

is - EP 2053782 A1 (A Communication Network System and Method for Provisioning a Service Broker Function): The request provides a description of the communication system and method for providing the function of a service broker. The description of the elements to which the service broker relates and how the element of the service broker operates;

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 Β2 (Method and Network for Provisioning Service Blending to a Subscriber): A method and communication network are provided to provide the subscriber with blending services of a communications network that is provided to the subscriber via telephone and TV system. The request describes the change of data and signals that the system performs in the case of connecting the TV delivery system and telephone;

US 2006/0104431 A1 (Method for Providing Feature Interaction Management and Service Blending); the request describes a service io agent for the use of the telephone in the case of a parallel ring. The role of the service agent is to end the call between the telephone and the parallel ring unit;

US 2007/0088836 A1 (Application Service Invocation Based on is Filter Criteria): The method applies to the IMS system and trigger point management;

VV0 / 2010/127626 A1 (Gali Connection Method of Relation Call Betvveen Netvorks and Service Broker System): The request relates to a call connection method for a call to network relationship

2o and the elements of the service broker;

US 7720049 (Semantic Service Broker for Telecommunications Netvorks): a method is provided for a service broker for the case where we have a subscriber and a set of services to perform services and to use programming languages for this purpose;

- EP 2053782 Α1 (A4) in WO 2008/025211 (A Communication Network System and Method for Providing a Service Broker

Function and a Service Broker Device): The request contains a description of the network system and methods for the service broker function; US 2009/0193131 A1 (Communication Netvork System and Method for Providing Service Broker Function, and Service Broker Apparatus): A method for the function of a service broker io function is specified in the case of a subscriber connection.

In classic networks (ISDN, PSTN, PLMN, NGN), the centrex solution is well known. The solution was based on the use of SS7, and more specifically on the use of ISUP. This was true of both the classic TDM network and the NGN, where we could also use ISUP under SIP-T. is In fact, the ISUP protocol was transmitted over the SIP, which was called the SIP-T protocol for such cases. I used a parameter within the ISUP session

Generic Parameter, as well as BGID, CgPN and CdPN. In addition to the parameters, appropriate methods and mechanisms for the operation of centrex in such networks were defined. The necessary translation information could be saved

2o within the centers themselves, or in external databases (eg for WACWide Area Centrex, ie centrex in the case of multiple centers in a network). The procedure provided consists of a service agent that provides:

- 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), and bundling ) service between NGN / TDM and

IMS network;

- linking the service broker element to other network elements;

- conversion of TDM / NGN messages into IMS messages and vice versa for centrex internal call cases using messages

ISUP and SIP protocols already standardized;

- use of data tables for the needs of centrex calls;

- support for centrex internal calls between NGN / TDM and IMS (both ways);

- the service broker can connect to non-IMS sites with classic TDM (eg SS7) or SIP-based (eg SIP-T within NGN);

- service broker is a standalone element. It can also be distributed, located on the AS, or on the S-CSCF;

- the first call message (IAM message for SS7 in TDM / NGN) in the direction from

TDM / NGN against IMS has the Client's B (CdPN) number in the format

ERN + NSN (or dicon + NSN);

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

- the method consists of using standard networks (IMS, TDM, ..) and elements (SIP, SS7, centrex ...) of the network. This adds standard logic to the service broker, which is a non-standard element;

- External control panels must have an ERN or a dicon entered for the direction from TDM / NGN to IMS;

- the service broker does not fire (it could be on an external database) but all the logic in the element itself is a service broker.

The essential features of the proposed procedure are the following:

- all centrex services are available at all terminals in the entire is network;

-Centrex support is also available for Number Portability use cases, i.e. Service Portability defined within Number Portability;

- The specified method allows a centrex internal call (short dial). Still, a public call can be made (dialing numbers in national format);

- With the described method, it is possible to connect subscribers from TDM, GSM, PLMN, NGN and others to the IMS network in the centrex network;

-centrex subscribers maintain the NSN (National Subscriber Numer) number. In addition to maintaining the NSN number, it is also possible to maintain centrex internal numbering;

- using the demand-based local portability function in the DB DB using the ACQ (AII Call Query) method (in the source control panel), or QoR (Query on Release), it is possible to make centrex internal calls even for subscribers transferred from TDM / NGN to IMS;

- use of service broker as a transition from TDM / NGN to IMS and vice versa;

- it is possible to present numbers in such a way that internal calls are always presented with a short number. In doing so, public calls are always presented with a public number;

the service broker as a transition from TDM / NGN to IMS maps ISUP's parameters (CdPN, CgPN, GN, BGID, ...) to SIP parameters (To,

From, P-Asserted ldentity / PAI, phone-context, otg) and vice versa;

- routing centrex (ERN) prefixes of relocated centrex numbers do not refer to the transient service broker central, but to the IMS system. ERN cuts off in a service broker ;.

- for internal calls generated on TDM / NGN systems directed towards

The IMS is usually added to the ERN number (which means the IMS system number), which is obtained from the NP DB. The ERN number is cut off in the service broker;

- for internal calls generated on IMS systems and directed to TDM / NGN, the conversion of numbers from an internal centrex number to a public one is performed on the basis of a translation table. The location code (LC) may also be added to the internal centrex number. The translation table is for each centrex group;

- a public number (NSN1, NSN2) is transmitted in both directions;

- if we move a number (use of NP) from TDM / NGN to IMS, this means that the subscriber retains the same number, thereby increasing the range of possible services (from TDM / NGN to IMS), e.g. gets some new ones (like Web Browsing, Presence, IM, ..). The service broker allows parameters to be converted for such calls;

-In TDM / NGN, centrex services and internal calls are made within the centers where the calls are located;

- in the case of TDM and NGN interconnection, ISUP is always used. When transmitted over SIP, this is a SIP-T protocol (or SIPI), that is, a SIP that has ISUP messages packed. In the proposed method and system, the element service broker is the actual conversion of ISUP messages to SIPs and vice versa;

- the method described is capable of converting for centrex from TDM / NGN to

2o IMS without additional signals, methods and parameters, of course, following certain programming logic. Those defined in the standards (ITU-T, ETSI), RFCs (IETF) or whose support is provided by the manufacturers are used;

• · · · · · · ·

- in addition to internal calls, support is also provided for supplementary services, e.g. for services as we know them in TDM / NGN, such as redirects (CFUs, CFBs, ..), CTs, DNDs, etc., ... Support for services is provided to the extent described by the method described. For some services or parts of services, an additional method not described within the specified method is required for the full operation of the service;

- the service broker actually mediates for Centrex calls and for Centrex itself;

- in the case of a call between the subscriber to TDM / NGN and IMS, the set of services is a cross section of all services. In a call to the same switchboard, the set is the same; in the case of two switchboards, the set is a cross section of the set of services of the first and second switchboard. Similarly, when the client is relocated or is located on an IMS service platform;

is - public calls remain as they are;

- Centrex subscriber information is located in the NGN / TDM, in the 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 more detail on the basis of an embodiment and accompanying drawings, of which:

Fig. 1 service broker as defined by the standard;

Figure 2: network service agent as defined by the standard;

Figure 3 service broker as defined by the Service Broker Forum Figure 4 connecting a convergence network service agent for the method of the invention described;

Fig. 5 is an implementation process in a service agent element in the direction from TDM / NGN to IMS;

Figure 6 is an implementation process in a service agent element in the direction from IMS to TDM / NGN;

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

io Connecting a service broker allows you to connect the TDM and NGN environments on the one hand, with the IMS environment on the other.

The SIP protocol is the basis for the IMS protocol. For IMS, the SIP protocol is upgraded. SIP is used to control multimedia sessions that combine speech and data. IMS provides several common features, such as AAA is (authentication, authorization), tariffing, HSS database and others.

The role of the service agent element is to enable more complex service interaction scenarios. They can be accessed through certain filters. This element may determine the intelligence and ability to integrate information from the network. Or to be implemented

2o services based on more complex sequences. Service Broker uses SIP and ISC interface.

Service interaction refers to the management process between network entities that request and use network services. The mediation of protocols and networks refers to conversion and conversion

messages from one protocol to another. Mediation also means defining whether a particular service or subscriber is entitled or not to access a particular service or application and also to process those authorizations.

The main task of a service broker is to select, start and arrange services after receiving a SIP or TDM message. Interactions with remote servers may occur. The function of a service agent is also that the user profile and application profile are similar to the trigger points in iFC. Tasks are also a concern for connecting within the application layer and between the application layer and the network.

The service broker supports standard protocols for connecting to TDM and NGN. These protocols can be:

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

is - for connecting to the network layer: USSD, SIP, SIP-T, SIP-I,

ISUP, H323, Diameter, SIGTRAN, MGCP, H248 and the like;

- for database connection and administration: SNMP, XCAP, HSS and the like. In this case, connection is possible using http, via ODBC, RPC, via SIP or via Diameter.

- Service Provider can connect to various network elements such as HLR, SCP, MSC, TDM svvitch, NGN softsvvitch, USSB gateway, Media Gateway, MGCF, SIP AS, IMS AS, S-CSCF, HSS, billing center, and similar.

In the framework of the described method, the described connection of a service intermediary in the convergence network is presented in Figure 4, which shows the connection of a service agent for placement within the described method for connecting in the NGN / TDM / IMS network.

The service broker itself consists of a module 1 that is designed to convert to TDM / NGN, a module 2 that is designed to convert to IMS, and the corresponding translation tables. From the point of view of the IMS network architecture, the service element network element can connect to the application layer and to the network layer. The application layer and the network layer can be based on io TDM / NGN or IMS elements or functionalities.

For the TDM / NGNG example, on the application layer, the service broker connects to SCP (Service Control Point) in Module 1. The connection between the service broker and SCP is INAP. SCP consists of a dedicated service part and a database. is Number portability can also be performed on SCP, not just in

TDM / NGN network. In this case, the SCP has a Terminal Portability (NP) service part, as well as an appropriate NP database. Additionally, we can also perform IN on SCP in the context of centrex internal calls using a public number (Intelligent Netvvorks, Intelligent Network Services, such as VPN (Virtual Private Network),

FPH (Free Phone, Free Call), MAS (Mobile Assistant), PRM (Premium Rate, Premium Service) and others. The link to the IMS application layer is the SIP protocol. Within the IMS application layer there can be different application servers (AS, Application Servers) that are either IMS or SIP based. It can also be a Service Delivery Platform (SDP). In case of connection to TDM / NGN network 3 SS7 protocol is used. If we have a combination of TDM and IP, SIGTRAN protocols (eg M3UA, M2UA, M2PA, ..) and MGCP / H248 are used. In the case of IP only connection, this is the SIP-T protocol. In all these cases, the service broker can liaise with public, private (eg ΡΑΒΧ) and mobile (MSC) exchanges. For use of the Number Portability (NP) service, a database (intended for NPs) is also located within io Network 3 (TDM / NGN Networks). End users in all these cases can be SIP terminals, ISDN / POTS terminals or GSM terminals. The service broker connects to the IMS network 4 using SIP and Diameter protocol. In this case, the service broker connects to the HSS (Home Subscriber is Server) database, as well as the S-CSCF, l-CSCF, and P-CSCF elements. Within the IMS network, IMS terminals or others may be used.

The Centreks system represents the functionality of a private switchboard or private network implemented with software within a public switchboard or public network. Centrex functionality is a comprehensive set of user signage, network signage, ancillary services and other telecommunication services that enables contracting authorities to connect into groups either within one central or across the entire public network and within these groups, using different complementary services that are similar to supplementary services for ΡΒΧ.

Centrex is already known within TDM as well as NGN. There, solutions are provided under SS7. In the case of the SIP-T protocol, this is a transmission

ISUP messages via SIP. Therefore, the ISG protocol-based solution is also an NGN solution. In our case, we first encounter a direct connection between SS7 and the SIP protocol for IMS and the parameter conversion between these two protocols and the corresponding networks.

Centreks can administer Centreks Subscriber, Centreks Group, Business Group and other data. We also have centrex numbering. It is possible to make internal calls (internal call), which can be of different types (remote, qusi-remote, ...). Internal numbering is used for internal calls (within the centrex group). Calls within an is group are billed in the manner specified for the group (free calls, reduced rates, ...). In addition to centrex internal calls, public calls can be made, as in a public telephone network.

A Centrex Client is a contracting authority that is a member of a Centrex Group. Each Centrex subscriber has its own public and its internal subscriber number. Each Centrex subscriber has exactly one extension number. Centrex subscribers maintain the NSN (National Subscriber Number) number. The Centrex subscriber has at its disposal the full range of basic services, the full range of complementary services provided by the contracting authority and the additional complementary services and / or modifications offered by the membership of the centrex group. The set of basic and complementary services is unique to the public (NSNCd, NSNCg) and the internal number (CxDNCd, CxDNCg). The service set is tied to a public number.

A centrex group is a subscriber group that is configured to allow most of the functionality of a private switchboard (ΡΒΧ). In addition to subscribers, the centrex group may include ΡΒΧ systems (nik subscriber). The centrex group is determined by its CGID identity. CGID is uniquely defined within a single call server or a single PBX. In a network, the same CGID can be used for different centrex groups, even if centrex groups with the same CGID are connected to one business group. The business group is identified by BGID. A business group can extend across multiple headquarters. The Centrex group can be assigned its public centrex number. This is part of a public numbering and is assigned according to the same criteria as the subscriber numbers and must not be assigned to any call server subscriber. If a centrex group is assigned a public centrex number, it is up to the group to determine whether it is allowed to receive group centrex calls from the entire network or only from its own business group.

2o In the context of centrex integration, the following concepts are important in general:

centrex call, that is, a call where a short (CxDN) centrex number is dialed;

• · »·· routing number (RN) - a number that allows you to route a call to a relocated (transferred) subscriber; specifies a receiving network or receiving center or interconnection point or network termination point;

CGID (cgid) (Centreks Group ldentity) - identity of the centrex group in the central office;

ERN (Exchange Routing Number) - the routing number that identifies the recipient's PBX;

- LC (local code) - local code (eg IMS networks);

BGID (Business Group ID) - Business group identity;

NDC (National Destination Code);

NSN (National Significant Number) - A national number defined as NDC + SN (e.g. 4-5561010);

SN (Subscriber Number) - Subscriber Number (ex. 5561010); CdPN (Called Number) - Called Public Number (Calling Number B);

CgPN (Calling Number) - public subscriber number, caller (subscriber A number);

NP DB (Number Portability Data Base).

«·

Within the numbers, we can have a called number (eg NSNCd, xDNCd), that is, the subscriber's B number, and a calling number (e.g., NSNCg, xDNCg), that is, the subscriber A.

In IMS, subscribers are added to a specific AS, e.g. centrex AS, where 5 will be provided services. New Centrex subscribers can be integrated into the IMS in several ways. The first way is to move an existing subscriber from TDM / NGN to IMS. This can be a very topical solution, as the client gets new services that he did not previously have in TDM / NGN, retains numbering, and is physically located in the IMS control panel in this case. Another option is virtual

NP, which is a similar solution. Suitable for example, to add a brand new subscriber to IMS and add the numbering to TDM / NGN and move it from NP to IMS. Virtual means because such a subscriber to TDM / NGN is only virtual, and has not been there so far. The third option is a completely new subscriber to the IMS, in which case the TDM / NGN is added with the information that such subscriber is located on the IMS and therefore a certain prefix (prefix) is introduced.

The described method supports connection for centrex calls for all described options. The first and second options require calls from the TDM / NGN in the number also to the ERN. The third option usually does not have this information, but it can be a dicon (prefix, prefix).

The calls that can be made under this method are internal calls between centrex subscribers. These are calls using a short number.

Within the given method, it is also possible to make calls where the client has moved, e.g. from TDM / NGN environment in IMS. In this case, the subscriber may also use the services provided on the IMS SIP ASs. The set can be much larger than it was in NGN / TDM. Certain Web services may also be used. In the case of a contracting authority, part of the NP solution is used. This part is about using Service Portability, which is defined under the N P standards. Service Portability is the ability for a user to maintain an existing TDM / NGN number while changing the set and scope of services.

The described method allows conversion of centrex from TDM / NGN to IMS without additional parameters. Of course, with some programming logic in mind. ISUP data and SIP parameters such as From, To, PAI (P-Asserted-ldentity) and methods such as INVITE, 200, 302 and ΒΥΕ are used.

The call to the exchange can come from different networks. This may be SS7, is or SIP-T. SIP-T also transmits ISUP information under the SIP Protocol. In both cases, the information we receive is contained in the messages

ISUP. A public number is transmitted in both directions.

In the TDM / NGN network, an ERN must be added to the number, also in the NGN / TDM network routing tables. ERN is obtained from NP DB. The routing number prefixes (ERN) of the centrex numbers do not refer to the gateway service broker, but to the IMS system. The ERN thus points to the IMS network where the centrex subscribers (actual or downloaded) are located. The ERN is cut off in the service broker.

From the TDM / NGN network, information for CxDNCg, CxDNCd, ERN and NSNCd, BGID, and optionally NSNCg, is sent in the ISUP of the ISUP protocol. If the latter is not present, it is obtained by the Service Broker. Data is transmitted in the ISUP protocol and parameters BGID, CgPN, CdPN and Generic

Parameter.In the case of a centrex call from TDM / NGN in the IMS, the SIV protocol of the INVITE message (method) to the IMS network transmits the number information in the To, From and PAI parameters. SIP messages contain the CxDNCd parameter in the To and phone-context parameter, the From NSNCg parameter, and the P-Asserted-ld (PAI) CxDNCg parameter. All messages, methods and parameters are defined in existing standards (ITU-T, ETSI, IETF RFC).

The implementation method in the service agent element with the conversion description is given in Figure 5.

The described method also enables centrex internal calls from IMS to is TDM / NGN. Of course, with some programming logic in mind. The ISUP parameters are Generic Number, CdPN, CgPN, BGID, as well as SIP parameters such as From, To, PAI, and methods such as INVITE.

The call to the control panel comes from the IMS network in the SIP protocol and the INVITE (message) method. In the service broker, the To and phone-context parameter contains the CxDNCd parameter, the From LC + CxDnCg parameter with the otg parameter with BGID, and the PAI parameter that does not contain the otg parameter LC + CxDNCg. LC may or may not be present in both cases. The service broker processes this information.

Centrex subscribers are listed in the centrex tables, where a Public Number (NSN) is read based on Business Group Value (BGID) and Internal Centrex Number (CxDN). Because the table is uniform, both dialed and dialed numbers are read. The service broker has a translation table for each BGID (centrex group). Based on the translational table, and taking into account the BGID and CxDN data, the NSN data is read. The information is then converted from SIP to ISUP messages. An ISUP message is encoded against the TDM / NGN, sending BGID, NSNCd, NSNCg, and Generic Number (CxDNCg and CxDNCd data). All messages, methods and parameters are defined in existing standards (ITUT, ETSI, IETF RFC). The exception is an otg parameter that is not standardized within the IETF RFC. Although not standardized, it is nevertheless used by many telecommunications equipment manufacturers.

The implementation method in the service broker element is given in Figure 6. is Figure 7 shows how the translation table works. The table is valid for each BGID.

The described method allows to make internal centrex calls also for cases of transferred subscribers using NP (Number Portability).

The use of NP is known from the standards for SS7. It is t.i. Service

Portability defined within the NP standards. The Centrex client is locally transferred from TMD / NGN to IMS. This gives the IMS subscriber a larger range of services.

• · · ·

The locally transferred subscriber is recorded in the NP database (DB NP) in the form known from interoperability portability. So NSN (National Subscriber Numer) is translated to ERN (Exchange Routing Number) + NSN.

In the source control panel (TDM / NGN), the ACQ (meaningful for a large number of ported numbers) method is triggered, which triggers a query into the NP database based on digit analyse. The depth before analyzing the numbers (prefix only or whole dialed number) is set administratively based on the number of locally transferred subscribers. If the locally ported numbers are more in a collapsed block, then the query is activated according to the block, but if the ported numbers are scattered, it is more justified to query the DB NP relative to the integer.

In addition to the ACQ method, there is the QoR method (more burdensome, therefore useful for, for example, a smaller number of ported numbers), is This method sends a message to the source that the subscriber has been transferred (SS7 REL message with cause # 14). The query in the DB DB is performed in the source control panel. Since this method is used for inter-operator portability, additional network design is required to avoid interaction between the inter-operator and locally transmitted subscribers.

In the case of a public call, a request is made to the NP database (NP DB) in the case of a local contracting authority transmission, in the case of a local transmission only a few centrex numbers or in the case of a whole centrex group transfer.

Inquiry into the NP database can also be made directly from the service agent element. In this case, the NP database can be located in SCP, the connection is INAP.

The transition from a service agent to an IMS is possible directly or through 5 databases (eg HSS or quasi-IMS). In the case of a direct connection, an INVITE message is sent against the IMS.

Access to the database is possible using standard DIAMETER LIA and LIR messages. In this case, this is direct access to the HMS IMS database.

Access to the database is also possible using classic SIP messages, e.g. unless we have direct DIAMETER access to the HSS. In this case, access to the IMS database is performed in the location database (LDB) itself. In the database itself, however, the data is converted, e.g. for data from HSS. In this case the first INVITE comes are LDB. LDB returns 302 with the cause is “Temporary moved”. The service broker acknowledges the reception of 302 ACK to LDB signals. In Contact, the IP address for the first and second IMS PBX (IP1 and IP2). Depending on the result, the service broker sends INVITE to CSCF1 (IP1) or CSCF2 (IP2). This is given in Figure 9. It is also possible to select and use an additional base (eg LDB2), e.g. in case the LDB does not respond or is overwhelmed. The location database can also be located in the service agent element itself.

In addition to supporting the operation of internal centrex calls, support for additional services is provided within the described method. These are services • »as we know them in TDM / NGN. Support for services is provided to the extent described by the method described. For some services or parts of services, an additional method that is not described within the specified method is required for the full operation of the service

This method provides support for services such as Call Completion Supplementary Services such as Call Intrusion Protection (CINT, Call Intrusion Protection - CINTP, Champ On Busy - CHAMP, ...), Call Offering Services Services such as Call Transfer Controlled - CTC, Night Service (Individual, Group) - NS,

NSG, Call Pick Up, Single - CPUS, Call Pickup, Group - CPUG, Multilevel Priority Service and Pickup Prefix - MLPP ...). Support is also provided for Special Centrex Complementary Services (such as Abbreviated Dialing, Group List - ABDG Call Forwarding For External Call Only, Emergency Call For Centrex Users, CTX Presentation Number is Interception Of Calls For CTX - IOC, Announcement Service For CTX, First Dial Tone For CTX) and others. Support for the aforementioned supplementary services is provided in whole or in part within the described method.

With the described solution of the service broker, we enable connection of classic TDM / NGN networks (PLMN, GSM, PSTN, ISDN, SS7, ...) with the new

IMS Network for Centrex Internal Call Cases. This applies both when one of the centrex subscribers is in TDM / NGN and the other is in IMS, as well as when the subscriber in IMS is transferred from TDM / NGN. With the solution described · it is possible to extend the private centrex network from TDM / NGN to IMS.

The advantages of the described method can be summarized in the following points:

this is a solution that uses standard solutions throughout the segment, that is, parameters for centrex already known in SS7 (ISUP) and parameters known and used in the SIP protocol (for IMS);

the solution uses already known components (IMS elements, TDM network elements, ISUP, SIP, Service Broker, NGN, IMS,

...);

the service broker element, defined in the standards as a "black box" and subject to various research, solutions and patents, has been expanded to support the Centrex network; it is not necessary to modify any of the existing protocols or parts of the network (eg SIP, ISUP, TDM central, ..) and there is no need for any additional database (eg special external databases for internal centrex calls);

conversion from NGN / TDM to IMS and vice versa is performed in one element of the network through the described method (program code, use of translation tables);

support for the centrex solution also in the case of using the standard Number Portability procedure for cases of moving subscribers within the centrex from TDM / NGN to IMS, thereby using the "Service portability" option as possible under Number Portability;

In addition to regular internal calls, the described method can fully or partially provide support for centrex supplementary services such as call forwarding (CFU, CFB, ..), conference (CONF), call-in (CINT), call forwarding (CT) , Do Not Disturb (DND), Sequential Ringing (LH), Anonymous Call Rejection (ACR), Number Presentation (CLIR, CLIP, ..) and more; in one element of the network, that is, in the element service broker, all the logic for the interaction between different networks and between services is combined. This logic connects to different parts of the network, such as interfaces for H248 / MGCP, SIGTRAN, SIP, to SIP-T, SIP and others. With the described method it is possible to migrate existing TDM / NGNs and subscribers to IMS in a simple way and thus ensure that existing TDM / NGN Centrex subscribers get new IMS functionality located e.g. to Centrex AS within the IMS network;

The service broker does not need to call for centrex internal calls, e.g. via INAP to external SCP, in case the client is moved from TDM / NGN to IMS. This does not make the service broker a bottleneck in terms of traffic (additional traffic between the service broker to SCP and back for each call to

relocated number). In this case, the information provided by the TDM / NGN centers is already coming to the service broker.

Claims (4)

PATENT APPLICATIONS 1. Service Provider Liaison and Centrex Internal Call Support Process, 5, characterized in that the service broker containing the corresponding translation tables for connection to the application layer and to the network layer, wherein the application layer and the network layer are based on TDM / NGN or IMS elements or functionalities, is connected to the module via INAP (1) io intended for conversion to TDM / NGN application layer and via SIP protocol with module (2) IMS application layer intended for conversion to IMS application layer; that the SCP in the IMS module (2) of the application layer consists of a service-oriented part and a database; that for portability of the number on the SCP, the terminal portability service (NP) is located in the module (2) of the application layer IMS, as well as the corresponding database for the NP; that SCP can also use intelligent network services such as VPNs, FPHs, MASs, PRMs and others in the context of call center calls; that there may be different application servers based on the IMS application layer based on IMS or 2o SIP respectively. SDP service platforms; that the service intermediary is connected to the TDM / NGN network (3) via SS7 protocol, and in the combination of TDM and IP via SIGTRAN protocol and MGCP / H248, in the case of IP connection only, the SIP-T protocol in these cases is the public service intermediary central, private (inΑΒΧ) and mobile (MSC) centers, and where the use of number portability service (NP) within the TDM / NGN network (3) also contains a database for NPs and end users in these cases may be SIP terminals, 5 ISDN / POTS terminals or GSM terminals; that the service broker connects to the IMS network (4) via the SIP and Diameter protocol to the HSS database, as well as the S-CSCF, l-CSCF and P-CSCF elements and that IMS terminals can be used within the IMS network (4). io 2. Service Provider Connection and Centrex Internal Call Support Process as claimed in claim 1, characterized in that the process of connecting to the TDM / NGN application layer module (1) comprises the following steps: is - receiving ISUP data from TDM / NGN from IAM message, dialed number: ERN + NSNCd, other data: BGID, NSNCg (optional), CxDNCg, CxDNCd; the parameters BGID, CxDNCd, CxDNCg, NSNCg (if present), NSNCd are read, ERN is cut off; 20 - if NSNCg is not present, it is added; prepare an SIP message (method) INVITE, define the following values: To = CxDNCd, phone-context From = NSNCg, PAI = CxDNCg; an SIP INVITE message is sent against the IMS. 3. Service Provider Liaison and Centrex Internal Call Support Process as claimed in claim 1, 5, characterized in that the process of connecting to the IMS module (2) of the application layer comprises the following steps: receiving SIP data from IMS from message (method) INVITE (LC may or may not be present): dialed number: io To = CxDNCd, phone-context, other data: from = LC + CxDNCg, otg = BGID, PAI = LC + CxDNCg; the To, From, PAI parameters are read, LC is cut off (if present); NSN is obtained from the translation table from BGID and CxDN; is - an ISUP IAM message is prepared with parameters: Generic Number (CxDNCg, CxDNCd), BGID, CdPN (NSNCd), CgPN (NSNCg); sends ISUP an IAM message against TDM / NGN.