Intermediate Switch Service Management System Architecture and Method

1. Field of the Invention

The present invention relates to telephone systems in general and to Intelligent Network (IN), Advanced Intelligent Network (AIN) systems and Computer Telephony Integration (CTI) in particular. More particularly still, it relates to telephone number portability, also known as local number portability (LNP) within such systems. More particularly yet, it relates to an intermediate service management system (SMS) architecture advantageous for LNP.

2. Prior Art of the Invention

North American Numbering Plan defines a telephone number as NPA-NXX-XXXX, (a glossary of abbreviations is found in the Appendix attached to this specification), where NPA are three digits which define the area code of the telephone subscriber, NXX indicates the switching exchange or switch where the subscriber is served. N represents a digit from 2 to 9 and X represents a digit from 0 to 9. The NPA has the NXX format.

A set of requirements has been defined for local Number Portability that defines the functionality for SSP (switches) STPs, SCPs, NPACs and L-SMS as well as the interfaces between these elements. These requirements describe how the LRN method uses AIN to a central LNP database (e.g. SCP) to access routing information for telephone numbers in areas where Number Portability occurs. A typical call flow in conformance with such requirements runs as follows:

1. Line A (708-224-1111) dials Line B (708-713-2222).

2. The Originating Switch performs digit analysis on the dialed digits to determine how to route the call. The switch determines that B is in a portable NPA-NXX (708-713) and the line does not reside on the switch.

3. The switch sends an AIN (info.sub.-- Analyzed) or IN (InstructionStart) query based on the dialed digits to the LNP-SCP.

4. The LNP-SCP sends an AIN (Analyze.sub.-- Route) or IN (ControlConnect) response containing the LRN of the Recipient Switch.

5. The Originating Switch receives the LNP-SCP response and analyzes the data. The LRN is translated in the LNP Routing Tables and an ISUP route out of the switch is determined. The LRN is stored in the CdPN parameter and the dialed digits are stored in the GAP parameter of the ISUP IAM message. The FCI Translated Called Number Indicator is set to indicate a query has been done (set to "translated number").

6. The call is routed to the Recipient Switch based on the LRN.

7. The Recipient Switch receives and processes the contents of the IAM message. The switch determines than an LRN is received and that it is the switch's LRN, and the switch replaces the CdPN parameter's contents with the dialed digits stored in the GAP parameter. The switch does digit analysis on the dialed digits and finds the subscriber on the switch.

8. The Recipient Switch completes the call to the subscriber.

This implementation relies heavily on the IN or AIN technology and is not efficient, since it is a complex protocol that must communicate across network elements while a call is in active progress.

U.S. Pat. No. 5,625,681 to Stratus "Method and Apparatus for Telephone Number Portability" relies on the AINs SCP, although it is somewhat short on implementation detail.

The present intermediate switch service management system architecture endeavours to lower switch realtime utilization for LNP (increasing the maximum number of lines a switch can support and relies on SS7 network utilization with less reliance on an SCP for LNP.

An advantage of the present intermediate architecture is that it utilizes the existing industry standard NPAC and merely adds an intermediate layer of software between the NPAC and at the switch, whether local or AT of a LATA.

Accordingly, an intermediate switch service management system (S-SMS) for improving local number portability (LNP) in telephony and the like switched communications system, includes:

(a) a plurality of databases at said S-SMS intermediate, a number portability administration center (NPAC) and a switching office;

(b) means at said S-SMS for downloading ported telephone numbers from said NPAC into said databases; and

(c) means at said S-SMS for downloading selected ones from said ported telephone members into an LNP-database in said switching office.

A method of operating an intermediate switch service management system (S-SMS) for improving local number portability (LNP) includes the steps of:

(a) maintaining a plurality of databases at said S-SMS intermediate, a number portability administration center (NPAC) and a switching office;

(b) downloading ported telephone numbers from said NPAC into said databases;

(c) selecting telephone numbers that have been ported from said switching office from said ported telephone numbers; and

(d) storing the telephone numbers selected in step (c) for storage in an LNP database in said switching office.

The preferred embodiment of the present invention will now be described in conjunction with the annexed drawing figures, in which:

FIG. 1 is a very high-level block diagram illustrating the position of the intermediate S-SMS layer accordingly to the present invention;

FIG. 2 is a very high-level block diagram illustrating an alternate position to that shown in figure of the intermediate S-SMS layer;

FIG. 3 is a flow-chart showing the operation of initializing the intermediate S-SMS layer of FIGS. 1 and 2;

FIG. 4 is a flow-chart showing how the intermediate S-SMS layer downloads ported NPA-NXXs to switches after initialization in FIG. 4;

FIG. 5 is a flow-chart similar to that of FIG. 4 but for the system architecture shown in FIG. 2; and

FIG. 6 is a flow-chart showing the call routing procedure of a switch once the intermediate S-SMS layer architecture shown in FIGS. 1 to 5 has been implemented in an in-switch dB.

Referring to FIG. 1 of the drawings, it illustrates the hierarchical structure of present day LNP architecture to which is added the intermediate S-SMS layer 10, while still incorporating the usual L-SMS 11 functions, both of which are intermediate to the NPAC 12 and switches (that is switching offices) 13, 14 and 15, and STP 16. In particular, the S-SMS 10 function is to manage switches 13, 14 and 15 databases (dB) in order to facilitate and render more efficient LNP.

In FIG. 2, the S-SMS 10 function is identical to that in FIG. 1 except that the S-SMS 10 manages the databases in ATs 16, 17 and 18, and each of the subtending switches the AT serves, which belong to LATAs 111, 112 and LATA X, respectively.

Prior to describing the processes shown in FIGS. 3, 4, 5 and 6, by which the S-SMS 10 operates on the switch database (dB), it is necessary to discuss the preferred structures of such databases. In general, a "value" in dB can be read or can be stored. The operation GET is used to read, and the operation STORE is used to store, a value in the dB. The names of variables (i.e. values) are shown in italics in the flow charts of FIGS. 3, 4, 5 and 6. Following are six database formats and descriptions of their parameters as required for operation of the S-SMS software.

1. PORTED.sub.-- TN.sub.-- LRN Database

This database associates ported telephone number with their Location Routing Number. The version id is used to identify the current version of the TN record. In this case a versionid is generated based on the calendar date & time at which this TN became active. This database is downloaded from the NPAC. How it is downloaded is defined in the existing NPAC specification document.

Parameter Glossary:

tn: ported telephone number--in this database the tn is the key used to index to the database

lrn: location routing number

version.sub.-- id: date & time that this record was written giving this record a unique version number

dpc: destination point code. Used by the SS7 network as addresses for SS7 components such as SSPs (switches), STPs or SCPs etc.

2. PORTED.sub.-- NXX Database

This database provides a list of office codes, i.e. NPA-NXX that are portable. The NXXs listed in this database are downloaded from the NPAC. The lata.sub.-- ids will need to be loaded by the operators of the S-SMS. Other groupings may be used other than LATAs if appropriate such as state, city, etc.

Parameter Glossary:

N.sub.-- Index: integer key used to index the database

nxx: A ported NPA-NXX. NPA-NXX are the first six digits of a ten digit telephone number. The NPA identifies the area code and the NXX identifies the office exchange.

3. PORTED.sub.-- TN.sub.-- NXX Database

This is a series of indexed databases. Each database is identified by a ported office code (see PORTED.sub.-- NXX Database). There is one database associated with each ported NPA-NXX. Each database identifies the ported telephone numbers associated with that office code. Each database is sorted in increasing order of Ported TNs.

Parameter Glossary:

TN--Key: integer key used to index the database

tn: ported telephone number

4. RANGE Database

This database is used to store ranges of ported numbers. The start of the telephone range and the end of a telephone range are provided. Note that this database only stores the start of a range and the end of a range that belong to the same NPA-NXX. A range with only a single TN is represented by having the start and end ranges have the same TN value.

Parameter Glossary:

Rng.sub.-- key: integer key used to index the database

start.sub.-- range: first telephone number in the range

end.sub.-- range: last telephone number in the range

lrn: location routing number

versionid: date & time that this record was written giving this record a unique version number

dpc: destination point code. Used by the SS7 network as addresses for SS7 components such as SSPs (switches), STPs or SCPs etc.

5. LATA Database

This database is a list of LATAs associated with the coverage area of the In-Switch Database. A LATA is a Local Access Transport Area as defined by Bellcore's LERG but any geographic area can be chosen to implement the database.

6. SWITCH.sub.-- LATA Database

SWITCH.sub.-- LATA[L.sub.--

This is an indexed database that identifies the switch addresses in each LATA that are affected by Local Number Portability and have an In-Switch Database. Each database is identified by a LATA (see LATA database). The switch address in this case is an IP address (Internet Protocol address) but other machine addresses that can be used for exchanging data between machines are also suitable

Parameter Glossary:

S.sub.-- Key: integer key used to index the database

switch.sub.-- address: machine address of the switch used by the S-SMS to exchange data with the switch. In this example, an Internet Protocol address format is used.

The term "indexed database" means a dB that may be used to store a set of related databases, as opposed to a single database. For example, with reference to FIG. 2, which shows how the S-SMS 10 can be organized to handle multiple LATAs (or other collection) switches, OSSs, ATS, STPs categorized by a LATA identifier), the LATAs are defined by a "LATA Database" (5, above), while switches in a LATA are defined by a "SWITCH-LATA Database" (6, above), the NPA-NXX download to a LATA are defined by a "PORTED-NXX Database" (2, above), etc.

Referring now to FIG. 3, it shows the flow-chart for initializing the S-SMS 10 by creating the "RANGE Databases" (4, above) from the ported NPA-NXX and the association of TNs with LRNs which have been downloaded from the NPAC 12. After initialization the following procedure continually updates the RANGE Database (4) by checking for updates from the NPAC 12. The procedure detects a change in Version ID (Database 1, above) when "version.sub.-- id" in "PORTED.sub.-- TN.sub.-- LRN Database" (1) is greater than the largest "versionid" in the RANGE Database (4) and, if so, the S-SMS 10 performs the following procedure to update the RANGE Database (4):

Temporarily generate a new RANGE Database called RANGE.sub.-- CHANGE Database (same format as RANGE) using the Range Algorithm for each Ported.sub.-- TN that has changed its version ID.

For each new range generated in the RANGE.sub.-- CHANGE Database identify the set of Rng.sub.-- Keys affected in RANGE Database.

Starting with the lowest range key affected, change its start and end values to reflect changes in range. This will require setting up new ranges with new Rng.sub.-- Keys if a current range is being split up. This will also require the range keys to be re-ordered into consecutive order.

Continue until all of the changes in RANGE.sub.-- CHANGE Database have been incorporated into the RANGE Database.

Delete the RANGE.sub.-- CHANGE Database when finished.

End.

End.

The flow-chart of FIG. 4 is the process which is used to download to switches the list of ported NPA-NXXs. The coverage area, i.e. the set of ported NPA-NXXs downloaded to individual switches can be changed by redefining the lata.sub.-- id associated with ported NPA-NXXs in the PORTED.sub.-- NXX Database (2). The list of switches that belong to a LATA is defined by the SWITCH.sub.-- LATA database (6).

The flow-chart of FIG. 5, which is similar to that of FIG. 4, is the process which is used to download to switches the ported TN information from the RANGE Database (4). The coverage area, i.e. the set of ported NPA-NXXs downloaded to individual switches can be changed by redefining the lata.sub.-- id associated with ported NPA-NXXs in the PORTED.sub.-- NXX Database (2). The list of switches that belong to a LATA is defined by the SWITCH.sub.-- LATA Database (6). Only TNs that match a ported NPA-NXX supported by a switch will be downloaded to that switch (e.g. if a switch is defined only to have a ported NPA-NXX of 613-232 by the Databases 2 and 6, then its in-switch dB will only receive ported TNs from 613-232).

We now to turn to the database dB at the switch itself and its routing procedures.

A SWITCH.sub.-- TN Database has the simple structure illustrated below (this is the dB part of 13, 14, 15 in FIG. 1).

This database is essentially the In-Switch LNP database. It appears in each switch that has an In-Switch LNP database. Against all of the ported NPA-NXXs in the LATA area of a switch are stored either: its LRN, if its is a ported number; a NULL character, if the TN is not ported and belongs to another switch or IN, signifying that this TN is resident on this switch.

Parameter Glossary:

tn: ported telephone number--in this table the tn is the key used to index to the table

lrn: location routing number

dpc: destination point code. Used by the SS7 network as addresses for SS7 components such as SSPs (switches), STPs or SCPs etc.

The switch runs the following process to initialize LNP database and downloaded newly ported NPA-NXXs:

Start.

For every new ported NPA-NXX received from the S-SMS via the Update.sub.-- NXX command, assign NULL against every tn in those ported NPA-NXXs in the Switch's SWITCH.sub.-- TN database.

Search inventory of TNs served by the switch. Assign IN to every TN that is resident on this switch in SWITCH.sub.-- TN database in the lrn parameter. This will overwrite the previous NULL value.

Wait for changes.

The switch runs the following routine to keep the SWITCH.sub.-- TN Database up-to-date. It accepts changes in ported TN status from the S-SMS, additions or deletions of TNs that are not ported but are resident on the switch:

Start.

For every ported TN received from S-SMS via the Update.sub.-- TN command, store the corresponding LRN value against those TNs in the Switch's SWITCH.sub.-- TN database. If a switch receives its own LRN as a value in the Update.sub.-- TN command, the value in the lrn field of the SWITCH.sub.-- TN database is set to IN.

If a TN is removed from service (i.e. no service from any service provider) store NULL against the value of the TN.

If a TN is added to service and is not ported and resident on this switch, store the value of IN against the TN in SWITCH.sub.-- TNs lrn parameter.

Wait for changes.

Once the LNP dB has been initialized and set up, the switch uses it to route calls according to the process shown in FIG. 6. If the value of a dialed TN is IN: the switch will complete the call directly intra-switch since that TN is also resident on that switch. If the value is NULL: the switch will use GR-2936-CORE (post-query) procedures to route the call as if it were a non-ported TN. If the value has an LRN: the switch will use GR-2936-CORE (post-query) procedures to route the call as if it were a ported TN. If the call is a long distance call carried by a different IXC--route call to that IXC. They will determine its LRN routing. This algorithm also applies to tandems, OSS etc.

The attached Appendix (pages A1-A4) forms and constitutes an integral part of this specification.