CA2185376A1 - Method of using dynamic database to improve telephone number portability - Google Patents
Method of using dynamic database to improve telephone number portabilityInfo
- Publication number
- CA2185376A1 CA2185376A1 CA002185376A CA2185376A CA2185376A1 CA 2185376 A1 CA2185376 A1 CA 2185376A1 CA 002185376 A CA002185376 A CA 002185376A CA 2185376 A CA2185376 A CA 2185376A CA 2185376 A1 CA2185376 A1 CA 2185376A1
- Authority
- CA
- Canada
- Prior art keywords
- database
- telephone number
- switch
- call
- ported
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0029—Provisions for intelligent networking
- H04Q3/005—Personal communication services, e.g. provisions for portability of subscriber numbers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/4228—Systems providing special services or facilities to subscribers in networks
- H04M3/42297—Systems providing special services or facilities to subscribers in networks with number portability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13097—Numbering, addressing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13102—Common translator
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13103—Memory
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13513—UPT - personal as opposed to terminal mobility, inc. number portability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13547—Indexing scheme relating to selecting arrangements in general and for multiplex systems subscriber, e.g. profile, database, database access
Abstract
Improved system for providing telephone number portability within a structurally distributed telephone system by means of a dynamic database for storing new routing information corresponding to a ported telephone number; switching means for accessing said dynamic database every time said ported telephone number is processed by said switching means; and means for replacing least used new routing information by routing information corresponding to a newly processed ported number.
Description
2 1 ~5376 METHOD OF USING DYNAMIC DATABASE TO IMPROVE TELEPHONE
NUMBER PORTABILITY
CROSS-REFERENCE TO RELATED APPLICATION
5 The present application is related to commonly assigned, concurrently filed application by Martinez et al. titled ENHANCED EFFICIENT TELEPHONE NUMBER
PORTABILITY, which is incorporated herein by reference.
BACKGROUND OF THE INVENTION
1. Field of the Invention 10 The present invention relates to telephony systems in general, and to telephone number portability, also known as local number portability (LNP), within such systems. More particularly still, it relates to an improvement whereby the recurrent cost and delay in executing number portability is reduced. An address capture database (ACDB) is provided, for example, at the access tandem (AT~ switch to avoid 15 repeating the full LNP procedure after first occurrence. The ACDB captured addresses can be aged and discarded to make room for new entries in the order of their use frequency.
2 1 ~ 7 6 2. Related Art Today, most services are resident in the software in each central office switch. While this has allowed providers to deliver a vast array of features, it also means that providers must depend on vendors to develop new features and then must often 5 coordinate the development of these features among the several switch vendors that they buy equipment from. When the features are available, they must then be loaded into each individual switch in the network, a complex task for networks that may contain hundreds of central offices.
As competition intensifies between providers of telephony services, providers are 10 looking for three key competitive advantages:
They want to be able to rapidly develop customized features to differentiate their offering in the marketplace.
They want to be able to quickly deploy new features ubiquitously throughout their serving areas as cost-effectively as possible.
They want to put certain processing-intensive or network-based (as opposed to switch-based) services such as local number portability and ~ 1 85~7~
PCS (Personal Communications Services) into centralized databases that all network switches can access.
Advanced Intelligent Networking (AIN - also known, especially outside of North America, as Intelligent Networking (IN)) is currently being deployed across the 5 United States and Canada to provide these key advantages.
AIN places the intelligence to deliver key features in a centralized network database -called a service control point (SCP) instead of in each individual switch. "Triggers"
in the software of individual service switching points (SSPs - central office switches with AIN software) momentarily interrupt call processing and generate queries of the 10 SCP for instructions on how to process features for individual calls.
AIN also provides a standardized service creation environment (SCE) that lets any vendor, including the service provider, develop software for the SCP. Providers can then quickly create (or have other specialized companies create) custom features and load them into the SCP, where they can be immediately accessed and used by any SSP
15 in the network.
New market entrants can either install their own AIN infrastructure, or purchase AIN
capabilities from established providers.
2 1 ~5376 Initial AIN features include:
For the Residential Subscriber - Sophisticated Call Screening and Management Features that allow users to determine who can reach them and when - a caller could, for instance, decide to take only long distance calls, or calls from immediate family, during dinner time, or that 900 calls could only be made during the times of the day when the parents are typically at home.
- Enhanced Voice Mail and Messaging Services over the public network.
- Personal Communications Services (PCS) that allow users to receive fully-featured calls any place in the network, wherever they happen to be.
For the Business Subscriber - Private Virtual Networks that give users cost-effective customized networks using any combination of public and 2 1 ~S376 private facilities.
- Virtual Offices that allow users to port business features to a home or cellular telephone as they move about the network.
- Area Number Calling that allows a business to advertise one number throughout an area, but automatically receive calls at the branch nearest to the caller.
- Network and Nodal Automatic Call Distribution available from any central office.
As may be seen from the above discussion, one of the most desirable network capabilities generally is telephone number portability; but at least local number portability (LNP), that is, number portability within a "local access and transport area" (LATA). Other desirable features involve number portability as applied to personal communications services (PCS); for example, as for cellular telephones.
LNP can encompass service portability, service provider portability, and location portability; the latter two being current goals and imply decoupling the originally dialled directory number (DN) for its "donor" switch.
It has generally been assumed that local number portability would best be provisioned through the use of some type of external database, perhaps similar to that employed for 800 service.
Regarding the point during the call at which the database is queried, it has been 5 suggested that three basic alternatives are present. One alternative is to route the call to the termin~ting switch to which the NPA/NXX of the dialled number was assigned, the TerTnin~ting Access Provider (TAP) - usually the incumbent provider, performing the database query at that point, and based upon the response received back, routing the call to the actual terrnin~ting switch of the (new) Termin~ting Local Service 10 Providers (TLSP). This would require that all calls to ported numbers be routed through the incumbent provider's (TAPs) facilities.
A second alternative is to have the Origin~ting Service Provider (OSP) always perform the database query at the switch from which the call is originated, and based upon the information received back in the response, route the call direct, if possible, 15 to the TLSP.
A third alternative is the so-called "N - 1 Alternative", which states ~hat the point at which the database query is launched (and who is responsible for launching it) is determined by the number of carriers involved in the call. If the call is local (or intra-LATA) and involves only two carriers, it is the origin~ting carrier (i.e., OSP) that is responsible for performing the database query. If, however, the call is inter-LATA, involving an Interexchange Carrier (IC), then the intermediate carrier (i.e., IC) must perform the query to obtain final routing instructions. This assumes that the OSP can determine from the dialled NPA/NXX whether the call is local, intra-LATA5 or inter-LATA. This allows LNP to begin in bounded areas, and limits the need for OSPs to perform database queries on every call.
There has been discussion regarding the composition and format of the database response message which contains the routing information. It has been suggested that a new sign~lling parameter, Service Providers Identification (SPID) be established to 10 merely identify which TLSP now serves the dialled number, so that the call can be routed to that provider's nearest point-of-presence (POP). Alternatively, it has been suggested that to gain peak network efficiency, the actual tertnin~ting switch needs to be identified.
One solution proposes that the bond between customer telephone numbers and network 15 termination addresses be completely broken and interspersed. Under their suggestion, a number dialled to reach a ported number customer (the customer number address -CNA) would first be sent to a database for replacement with a network node address (the NNA), which would be used to route the call to the correct termin~ting switch/
Since the NNA is in the same format at the CNA (10-digit) and its first six digits 20 uniquely identify the termin~ting switch (as is the case today) NANP-based routing 2 1 ~5~76 remains unchanged, yet customers can retain their numbers whenever they move or change providers - the CNA is simply mapped to a new NNA in the database. Since both sets of numbers use the same format, they can be interspersed, i.e., a CNA for one customer can be a NNA for another, and vice versa. It has suggested that the 5 database populate the CNA in the Generic Address Parameter (GAP), and the NNA
in the Called Party (CdPN) parameter in its response message. It was also proposed to use a new Origin~ting Line Info (OLI) parameter value to indicate whether a database dip has already been performed in a previous node, to prevent mix-ups of CNAs with NNAs in networks where database queries may be launched at multiple 10 points.
Another solution proposes that rather than substituting NNAs for CNAs, the database merely populates one of the assigned six-digit NPA/NXXs of the actual termin~ting switch in the CdPN parameter, and moves the actual dialled number to the GAP.
Since all network nodes route on the first six digits of the CdPN anyway, the call will 15 progress to the actual termin~ting switch, which would look at the GAP address, where the dialled number is now located, rather than the CdPN, to determine the actual called line. Although no new sign~lling parameters are identified with this proposal, switching software modifications, to allow a change in their treatment, are probably required.
20 Of significant concern with some of the portability solutions identified thus far is the need to perform database queries on all or most origin~ting calls. The additional load on the SS7 sign~lling network may be such that database deployment options may be severely limited, and/or service degradations such as post dial delay, loss of tr~n~mi~sion quality or call blocking may be experienced. One suggestion has been 5 to limit the number of queries needed by nationally "registering" those NPA/NXXs for which numbers have become portable. This would allow carriers to launch database queries only when those prefixes are dialled. Although feasible in the near-term, many feel that once number portability begins to expand, the amount of work required in each switch to trigger on each newly-portable NPA/NXX combination will 10 become overly burdensome. Furthermore, this methodology necessitates a waiting period to ensure that all carriers have sufficient time to implement the necessary translations in each end office for each newly-portable prefix.
Absent some methodology to limit the number of queries launched to the portability database(s), the load on the SS7 ~ign~lling network may be significant. Although the 15 existing links between the end offices and sign~lling hub (STP) were sufficient to handle the additional traffic, the number of new links and databases (SCPs) beyond the hub would be substantial. Therefore, if portability was widely offered, a provider's network would only be able to handle the data queries that were generated locally, not those coming in from other areas. The significance of this finding was 20 that calls to ported numbers that originate from outside the ported number area may need to access databases separate from those h~n-lling traffic that originates within the 21~5376 area. This implies that unlike the LIDB (calling card database) model, multiple sets of databases, each cont~ining data on the same numbers, may need to be deployed in different areas of the country and state.
SUMMARY OF THE INVENTION
5 The present invention provides an improved method of providing telephone number portability within a structurally distributed telephone system, and the like, comprising the steps of:
(a) accessing a remote database to retrieve a new (physical) number (NN), if any, for a dialled number (DN);
(b) storing said NN in a local database; and (c) checking said local database for a match every time said DN is dialled and establishing a connection with said NN upon finding said match without access to said remote database.
According to the present invention, an improved system for providing telephone 15 number portability within a structurally distributed telephone system, and the like, comprises: a dynamic database for storing new routing information corresponding to 2 1 ~537~
a ported telephone number; switching means for accessing said dynamic database every time said ported telephone number is processed by said switching means; and means for replacing least used new routing information by routing information corresponding to a newly processed ported number S BRIEF DESCRIPTION OF THE DRAWINGS
The preferred embodiments of the present invention will now be described in detail in conjunction with the drawings, in which:
Figure 1 is an illustration of the telephone system environment within which address capture databases (ACDB) are utilized according to the present invention; and 10 Figure 2 illustrates call flow procedures implementing the method of the present invention within the system shown in Figure 1.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Referring now to Figure 1 of the drawings, the system environment within which the method of the present invention operates will be described.
15 Local Carriers' Carrier (LCC) 10, would offer services to other carriers in a local telephone serving area. This area, covered by a local exchange carrier (LEC) 11 LEC
and possibly several independent operating companies (IOCs), is likely to host more than one competitive local service providers (LSP1 to LSP4), which may be competitive access providers (CAPs), cable companies, cellular carriers, personal 5 communication service (PCS) operators, and others. There may also be several interexchange carriers (IXC) 12 serving end users in this area. A service control point (SCP) 13, which is a node in a CCS7 sign~lling network supports application databases, such as LNP information, and is normally separated from most LSPs and LECs.
10 As a traffic aggregator, the LCC 10 has trunks into each of the participating LSPs and IXC 12, as well as one trunk group into the LEC 11. It essentially serves as a multi-carrier interconnection provider to the LSPs and IXCs, with additional service offerings based on the LCC switch capability and customers needs.
The LCC 10 provides the following services to its carrier customers:
Tandeming traffic among LSPs, including local number portability service to LSPs and their customers that ported numbers between LSPs.
Providing LEC interconnection to LSPs. With a single trunk route to -- 2 1 8537~
the LEC, the LCC aggregates and routes intraLATA traffic between the LSPs and the LEC.
Operating local number portability functions for customers ported between the LEC and LSPs, provided that local number portability protocols are established.
Providing LSPs with equal access connectivity to IXCs. The LCC
aggregates and routes incoming and outgoing interLATA traffic of the LSPs to and from IXCs.
Providing E911 (Emergency) connectivity to the LSPs.
Providing operator services and other enh~nred services to the LSPs.
LNP is, in effect, the decoupling of the dialable subscriber number from the network address that is indicated by that number. Today, these two uses of the dialled number significantly restrict the ability of the network to provide some services to the subscriber. One such service is geographic relocation of the number. The most 15 important one is the ability to distinguish between competing service providers in the emerging competitive local telephone market. To implement LNP, a database is most likely to be used to map the dialled number into a future network address. The -- 2 1 ~53~6 present invention lowers the costs associated with implementing these databases in the public switched network by reducing LD query costs and delay from origination toconnection of a call.
By providing an address capture database (ACDB) 14 at the access tandem (AT) 5 switch 15 of the LEC 11, or at an LSP such as LSP 3, the dynamic, self-learning captures data from previous call queries, that had to access the SCP 13, for reuse on subsequent calls. Thus call setup times are shortened on subsequent calls and the aggregate costs of making queries to the LNP database at the SCP 13 are lowered.
It also lowers the maintenance and ~rnini.~trative costs associated with implementing 10 a public (shared) database.
Preferably, the ACDB would be similar to the calling card databases used today, where entries are aged and dropped if they are not used regularly. The actual format of the address as stored may take several forms, including, a 10 digit North American Numbering Plan (NANP) number, a termin~ting switch ID and trunk group/route 15 ID/Port #, or other routing information. The data does not have to take the same form in the capture database as is received from whatever source (be it an LNP
database or another switch). Thus any manipulation can take place once (for the first call) and the result stored for reuse in the ACDB. Further, the captured data does not have to exist on the switch itself, but can be stored in an adjunct processor, or in 20 another node in the network, provided there is a high-speed access between the switch ~ 1 85376 and the data location. The ACDB is different from on-switch data tables in that it is updated by the process of delivering calls, and not from some manual or automatic service order system. Various scenarios for the acquisition of the routing NP data by the ACDB are discussed below.
5 Each switch requires access to the latest address in the master LNP database at the SCP 13 (a generic requirement for LNP capable switches). By of example, this master database could be m~int~in~d by a neutral third party charging for access, probably on a per query basis.
Once LNP is implemented in a design~ted portability area (defined by the switches 10 that understand LNP and their NPA-NXX office codes), no call into this area would be failed due to a vacant DN (dialled number) condition until after the dialled DN has been checked against he master database to see if the customer has moved.
Four procedures may be used to identify if a telephone subscriber has moved. They are:
(a) The procedure disclosed in the cross-referenced, concurrently filed application.
(b) Regular Synchronization checks to verify the integrity of local data ~185376 against the master database.
(c) Verification "Pings" against the known location of the subscriber. This can be done in several ways, including, but not limited to, the use of existing CLASS feature mPss~ging intended for DN validation.
(d) Update information based on queries made by other switches in the operator's network, i.e. data sharing. (The network here is a group of interconn~ctecl switches owned by one entity.) The implementation of the present ACDB will be described with reference to Figure 2 in conjunction with the first procedure (a) of the cross-referenced application.
10 In this example, the access tandem (AT) 15 is the switch performing the task. The steps it takes are as follows:
1. Receive the incoming address message (IAM), then compare the dialled digits with the ACDB 14 for a match ((A) in Figure 2). This check can be filtered with a 3 or 6 digit flag in the translation tables to save work. If there is no value, i.e. no match, route on the original dialled digits to the donor switch.
If there is a match, jump to point (B) (in Figure 2) and route on the contents of the ACDB to new switch.
~ ~ ~53 76 -2. Old SSP switch checks line and tennin~tes call normally if subscriber is present. Otherwise it returns an SS7 Release message with a cause value of "Vacant DN".
NUMBER PORTABILITY
CROSS-REFERENCE TO RELATED APPLICATION
5 The present application is related to commonly assigned, concurrently filed application by Martinez et al. titled ENHANCED EFFICIENT TELEPHONE NUMBER
PORTABILITY, which is incorporated herein by reference.
BACKGROUND OF THE INVENTION
1. Field of the Invention 10 The present invention relates to telephony systems in general, and to telephone number portability, also known as local number portability (LNP), within such systems. More particularly still, it relates to an improvement whereby the recurrent cost and delay in executing number portability is reduced. An address capture database (ACDB) is provided, for example, at the access tandem (AT~ switch to avoid 15 repeating the full LNP procedure after first occurrence. The ACDB captured addresses can be aged and discarded to make room for new entries in the order of their use frequency.
2 1 ~ 7 6 2. Related Art Today, most services are resident in the software in each central office switch. While this has allowed providers to deliver a vast array of features, it also means that providers must depend on vendors to develop new features and then must often 5 coordinate the development of these features among the several switch vendors that they buy equipment from. When the features are available, they must then be loaded into each individual switch in the network, a complex task for networks that may contain hundreds of central offices.
As competition intensifies between providers of telephony services, providers are 10 looking for three key competitive advantages:
They want to be able to rapidly develop customized features to differentiate their offering in the marketplace.
They want to be able to quickly deploy new features ubiquitously throughout their serving areas as cost-effectively as possible.
They want to put certain processing-intensive or network-based (as opposed to switch-based) services such as local number portability and ~ 1 85~7~
PCS (Personal Communications Services) into centralized databases that all network switches can access.
Advanced Intelligent Networking (AIN - also known, especially outside of North America, as Intelligent Networking (IN)) is currently being deployed across the 5 United States and Canada to provide these key advantages.
AIN places the intelligence to deliver key features in a centralized network database -called a service control point (SCP) instead of in each individual switch. "Triggers"
in the software of individual service switching points (SSPs - central office switches with AIN software) momentarily interrupt call processing and generate queries of the 10 SCP for instructions on how to process features for individual calls.
AIN also provides a standardized service creation environment (SCE) that lets any vendor, including the service provider, develop software for the SCP. Providers can then quickly create (or have other specialized companies create) custom features and load them into the SCP, where they can be immediately accessed and used by any SSP
15 in the network.
New market entrants can either install their own AIN infrastructure, or purchase AIN
capabilities from established providers.
2 1 ~5376 Initial AIN features include:
For the Residential Subscriber - Sophisticated Call Screening and Management Features that allow users to determine who can reach them and when - a caller could, for instance, decide to take only long distance calls, or calls from immediate family, during dinner time, or that 900 calls could only be made during the times of the day when the parents are typically at home.
- Enhanced Voice Mail and Messaging Services over the public network.
- Personal Communications Services (PCS) that allow users to receive fully-featured calls any place in the network, wherever they happen to be.
For the Business Subscriber - Private Virtual Networks that give users cost-effective customized networks using any combination of public and 2 1 ~S376 private facilities.
- Virtual Offices that allow users to port business features to a home or cellular telephone as they move about the network.
- Area Number Calling that allows a business to advertise one number throughout an area, but automatically receive calls at the branch nearest to the caller.
- Network and Nodal Automatic Call Distribution available from any central office.
As may be seen from the above discussion, one of the most desirable network capabilities generally is telephone number portability; but at least local number portability (LNP), that is, number portability within a "local access and transport area" (LATA). Other desirable features involve number portability as applied to personal communications services (PCS); for example, as for cellular telephones.
LNP can encompass service portability, service provider portability, and location portability; the latter two being current goals and imply decoupling the originally dialled directory number (DN) for its "donor" switch.
It has generally been assumed that local number portability would best be provisioned through the use of some type of external database, perhaps similar to that employed for 800 service.
Regarding the point during the call at which the database is queried, it has been 5 suggested that three basic alternatives are present. One alternative is to route the call to the termin~ting switch to which the NPA/NXX of the dialled number was assigned, the TerTnin~ting Access Provider (TAP) - usually the incumbent provider, performing the database query at that point, and based upon the response received back, routing the call to the actual terrnin~ting switch of the (new) Termin~ting Local Service 10 Providers (TLSP). This would require that all calls to ported numbers be routed through the incumbent provider's (TAPs) facilities.
A second alternative is to have the Origin~ting Service Provider (OSP) always perform the database query at the switch from which the call is originated, and based upon the information received back in the response, route the call direct, if possible, 15 to the TLSP.
A third alternative is the so-called "N - 1 Alternative", which states ~hat the point at which the database query is launched (and who is responsible for launching it) is determined by the number of carriers involved in the call. If the call is local (or intra-LATA) and involves only two carriers, it is the origin~ting carrier (i.e., OSP) that is responsible for performing the database query. If, however, the call is inter-LATA, involving an Interexchange Carrier (IC), then the intermediate carrier (i.e., IC) must perform the query to obtain final routing instructions. This assumes that the OSP can determine from the dialled NPA/NXX whether the call is local, intra-LATA5 or inter-LATA. This allows LNP to begin in bounded areas, and limits the need for OSPs to perform database queries on every call.
There has been discussion regarding the composition and format of the database response message which contains the routing information. It has been suggested that a new sign~lling parameter, Service Providers Identification (SPID) be established to 10 merely identify which TLSP now serves the dialled number, so that the call can be routed to that provider's nearest point-of-presence (POP). Alternatively, it has been suggested that to gain peak network efficiency, the actual tertnin~ting switch needs to be identified.
One solution proposes that the bond between customer telephone numbers and network 15 termination addresses be completely broken and interspersed. Under their suggestion, a number dialled to reach a ported number customer (the customer number address -CNA) would first be sent to a database for replacement with a network node address (the NNA), which would be used to route the call to the correct termin~ting switch/
Since the NNA is in the same format at the CNA (10-digit) and its first six digits 20 uniquely identify the termin~ting switch (as is the case today) NANP-based routing 2 1 ~5~76 remains unchanged, yet customers can retain their numbers whenever they move or change providers - the CNA is simply mapped to a new NNA in the database. Since both sets of numbers use the same format, they can be interspersed, i.e., a CNA for one customer can be a NNA for another, and vice versa. It has suggested that the 5 database populate the CNA in the Generic Address Parameter (GAP), and the NNA
in the Called Party (CdPN) parameter in its response message. It was also proposed to use a new Origin~ting Line Info (OLI) parameter value to indicate whether a database dip has already been performed in a previous node, to prevent mix-ups of CNAs with NNAs in networks where database queries may be launched at multiple 10 points.
Another solution proposes that rather than substituting NNAs for CNAs, the database merely populates one of the assigned six-digit NPA/NXXs of the actual termin~ting switch in the CdPN parameter, and moves the actual dialled number to the GAP.
Since all network nodes route on the first six digits of the CdPN anyway, the call will 15 progress to the actual termin~ting switch, which would look at the GAP address, where the dialled number is now located, rather than the CdPN, to determine the actual called line. Although no new sign~lling parameters are identified with this proposal, switching software modifications, to allow a change in their treatment, are probably required.
20 Of significant concern with some of the portability solutions identified thus far is the need to perform database queries on all or most origin~ting calls. The additional load on the SS7 sign~lling network may be such that database deployment options may be severely limited, and/or service degradations such as post dial delay, loss of tr~n~mi~sion quality or call blocking may be experienced. One suggestion has been 5 to limit the number of queries needed by nationally "registering" those NPA/NXXs for which numbers have become portable. This would allow carriers to launch database queries only when those prefixes are dialled. Although feasible in the near-term, many feel that once number portability begins to expand, the amount of work required in each switch to trigger on each newly-portable NPA/NXX combination will 10 become overly burdensome. Furthermore, this methodology necessitates a waiting period to ensure that all carriers have sufficient time to implement the necessary translations in each end office for each newly-portable prefix.
Absent some methodology to limit the number of queries launched to the portability database(s), the load on the SS7 ~ign~lling network may be significant. Although the 15 existing links between the end offices and sign~lling hub (STP) were sufficient to handle the additional traffic, the number of new links and databases (SCPs) beyond the hub would be substantial. Therefore, if portability was widely offered, a provider's network would only be able to handle the data queries that were generated locally, not those coming in from other areas. The significance of this finding was 20 that calls to ported numbers that originate from outside the ported number area may need to access databases separate from those h~n-lling traffic that originates within the 21~5376 area. This implies that unlike the LIDB (calling card database) model, multiple sets of databases, each cont~ining data on the same numbers, may need to be deployed in different areas of the country and state.
SUMMARY OF THE INVENTION
5 The present invention provides an improved method of providing telephone number portability within a structurally distributed telephone system, and the like, comprising the steps of:
(a) accessing a remote database to retrieve a new (physical) number (NN), if any, for a dialled number (DN);
(b) storing said NN in a local database; and (c) checking said local database for a match every time said DN is dialled and establishing a connection with said NN upon finding said match without access to said remote database.
According to the present invention, an improved system for providing telephone 15 number portability within a structurally distributed telephone system, and the like, comprises: a dynamic database for storing new routing information corresponding to 2 1 ~537~
a ported telephone number; switching means for accessing said dynamic database every time said ported telephone number is processed by said switching means; and means for replacing least used new routing information by routing information corresponding to a newly processed ported number S BRIEF DESCRIPTION OF THE DRAWINGS
The preferred embodiments of the present invention will now be described in detail in conjunction with the drawings, in which:
Figure 1 is an illustration of the telephone system environment within which address capture databases (ACDB) are utilized according to the present invention; and 10 Figure 2 illustrates call flow procedures implementing the method of the present invention within the system shown in Figure 1.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Referring now to Figure 1 of the drawings, the system environment within which the method of the present invention operates will be described.
15 Local Carriers' Carrier (LCC) 10, would offer services to other carriers in a local telephone serving area. This area, covered by a local exchange carrier (LEC) 11 LEC
and possibly several independent operating companies (IOCs), is likely to host more than one competitive local service providers (LSP1 to LSP4), which may be competitive access providers (CAPs), cable companies, cellular carriers, personal 5 communication service (PCS) operators, and others. There may also be several interexchange carriers (IXC) 12 serving end users in this area. A service control point (SCP) 13, which is a node in a CCS7 sign~lling network supports application databases, such as LNP information, and is normally separated from most LSPs and LECs.
10 As a traffic aggregator, the LCC 10 has trunks into each of the participating LSPs and IXC 12, as well as one trunk group into the LEC 11. It essentially serves as a multi-carrier interconnection provider to the LSPs and IXCs, with additional service offerings based on the LCC switch capability and customers needs.
The LCC 10 provides the following services to its carrier customers:
Tandeming traffic among LSPs, including local number portability service to LSPs and their customers that ported numbers between LSPs.
Providing LEC interconnection to LSPs. With a single trunk route to -- 2 1 8537~
the LEC, the LCC aggregates and routes intraLATA traffic between the LSPs and the LEC.
Operating local number portability functions for customers ported between the LEC and LSPs, provided that local number portability protocols are established.
Providing LSPs with equal access connectivity to IXCs. The LCC
aggregates and routes incoming and outgoing interLATA traffic of the LSPs to and from IXCs.
Providing E911 (Emergency) connectivity to the LSPs.
Providing operator services and other enh~nred services to the LSPs.
LNP is, in effect, the decoupling of the dialable subscriber number from the network address that is indicated by that number. Today, these two uses of the dialled number significantly restrict the ability of the network to provide some services to the subscriber. One such service is geographic relocation of the number. The most 15 important one is the ability to distinguish between competing service providers in the emerging competitive local telephone market. To implement LNP, a database is most likely to be used to map the dialled number into a future network address. The -- 2 1 ~53~6 present invention lowers the costs associated with implementing these databases in the public switched network by reducing LD query costs and delay from origination toconnection of a call.
By providing an address capture database (ACDB) 14 at the access tandem (AT) 5 switch 15 of the LEC 11, or at an LSP such as LSP 3, the dynamic, self-learning captures data from previous call queries, that had to access the SCP 13, for reuse on subsequent calls. Thus call setup times are shortened on subsequent calls and the aggregate costs of making queries to the LNP database at the SCP 13 are lowered.
It also lowers the maintenance and ~rnini.~trative costs associated with implementing 10 a public (shared) database.
Preferably, the ACDB would be similar to the calling card databases used today, where entries are aged and dropped if they are not used regularly. The actual format of the address as stored may take several forms, including, a 10 digit North American Numbering Plan (NANP) number, a termin~ting switch ID and trunk group/route 15 ID/Port #, or other routing information. The data does not have to take the same form in the capture database as is received from whatever source (be it an LNP
database or another switch). Thus any manipulation can take place once (for the first call) and the result stored for reuse in the ACDB. Further, the captured data does not have to exist on the switch itself, but can be stored in an adjunct processor, or in 20 another node in the network, provided there is a high-speed access between the switch ~ 1 85376 and the data location. The ACDB is different from on-switch data tables in that it is updated by the process of delivering calls, and not from some manual or automatic service order system. Various scenarios for the acquisition of the routing NP data by the ACDB are discussed below.
5 Each switch requires access to the latest address in the master LNP database at the SCP 13 (a generic requirement for LNP capable switches). By of example, this master database could be m~int~in~d by a neutral third party charging for access, probably on a per query basis.
Once LNP is implemented in a design~ted portability area (defined by the switches 10 that understand LNP and their NPA-NXX office codes), no call into this area would be failed due to a vacant DN (dialled number) condition until after the dialled DN has been checked against he master database to see if the customer has moved.
Four procedures may be used to identify if a telephone subscriber has moved. They are:
(a) The procedure disclosed in the cross-referenced, concurrently filed application.
(b) Regular Synchronization checks to verify the integrity of local data ~185376 against the master database.
(c) Verification "Pings" against the known location of the subscriber. This can be done in several ways, including, but not limited to, the use of existing CLASS feature mPss~ging intended for DN validation.
(d) Update information based on queries made by other switches in the operator's network, i.e. data sharing. (The network here is a group of interconn~ctecl switches owned by one entity.) The implementation of the present ACDB will be described with reference to Figure 2 in conjunction with the first procedure (a) of the cross-referenced application.
10 In this example, the access tandem (AT) 15 is the switch performing the task. The steps it takes are as follows:
1. Receive the incoming address message (IAM), then compare the dialled digits with the ACDB 14 for a match ((A) in Figure 2). This check can be filtered with a 3 or 6 digit flag in the translation tables to save work. If there is no value, i.e. no match, route on the original dialled digits to the donor switch.
If there is a match, jump to point (B) (in Figure 2) and route on the contents of the ACDB to new switch.
~ ~ ~53 76 -2. Old SSP switch checks line and tennin~tes call normally if subscriber is present. Otherwise it returns an SS7 Release message with a cause value of "Vacant DN".
3. When the AT sees the SS7 Release (VacantDN) message (B), the call is routed S to a query mechanism that initi~tes a query to the LNP master database with one of several messages. The AIN 0.1 NetworkBusy message is shown here, others are possible.
4. The database returns the current address in an AIN 0.1 AnalyzeRoute message. Again, this is only one of several possibilities.
10 5. The AT routes the call using the returned information (3), and saves the new routing information in the Address Capture Database. This is best done by sending the required information to a lower priority software task on the switch and allowing it to format the data correctly as processor capacity allows.
One alternative implementation to steps 3 & 4 is to have the switch broadcast a locator request to other switches in the area that may have received the ported subscriber. Only one will provide a positive acknowledgement, and the call is routed to that switch.
2~8537~
Another alternative implementation is for the donor switch to provide forwarding information to the tandem as additional information in the SS7 Release message (this makes use of the Release-To-Pivot functionality that has been defined by Bellcore).
In this case, the provided information is processed, stored, and the call is routed to 5 the new recipient switch.
An additional feature that can be added to the addressing concept is to provide a switch the ability to broadcast the change of a line's actual address to other switches or databases in the operator's network. This allows other switches to capture the data in an optimal time frame. This requires non-call associated sign~lling and some new 10 messaging, along with the required switch software. A variety of known mech~ni~m~
can be used to improve the efficiency of this process, and to be sure that various copies of the data are kept in synchronization.
If the Look-Ahead algorithm (or any other Release message based algorithm) is not used as the normal LNP mech~ni.~m, then one of the other mech~ni.~m.~ will have to lS be used to implement the address capture database update process. As mentioned above, these include regular syncllronizalion, validation "pings", and subscription to the update notifications from the master LNP database.
This same process of address or routing information caching can be applied to AIN
application is some contexts. Many services can be developed where the redirection information is relatively static with respect to a particular switching node in the network. These kinds of services are amenable to address caching in the same manner as has been described here for LNP addressing.
10 5. The AT routes the call using the returned information (3), and saves the new routing information in the Address Capture Database. This is best done by sending the required information to a lower priority software task on the switch and allowing it to format the data correctly as processor capacity allows.
One alternative implementation to steps 3 & 4 is to have the switch broadcast a locator request to other switches in the area that may have received the ported subscriber. Only one will provide a positive acknowledgement, and the call is routed to that switch.
2~8537~
Another alternative implementation is for the donor switch to provide forwarding information to the tandem as additional information in the SS7 Release message (this makes use of the Release-To-Pivot functionality that has been defined by Bellcore).
In this case, the provided information is processed, stored, and the call is routed to 5 the new recipient switch.
An additional feature that can be added to the addressing concept is to provide a switch the ability to broadcast the change of a line's actual address to other switches or databases in the operator's network. This allows other switches to capture the data in an optimal time frame. This requires non-call associated sign~lling and some new 10 messaging, along with the required switch software. A variety of known mech~ni~m~
can be used to improve the efficiency of this process, and to be sure that various copies of the data are kept in synchronization.
If the Look-Ahead algorithm (or any other Release message based algorithm) is not used as the normal LNP mech~ni.~m, then one of the other mech~ni.~m.~ will have to lS be used to implement the address capture database update process. As mentioned above, these include regular syncllronizalion, validation "pings", and subscription to the update notifications from the master LNP database.
This same process of address or routing information caching can be applied to AIN
application is some contexts. Many services can be developed where the redirection information is relatively static with respect to a particular switching node in the network. These kinds of services are amenable to address caching in the same manner as has been described here for LNP addressing.
Claims (2)
1. An improved method of providing telephone number portability within a structurally distributed telephone system, and the like, comprising the steps of:
(a) accessing a remote database to retrieve a new (physical) number (NN), if any, for a dialled number (DN);
(b) storing said NN in a local database; and (c) checking said local database for a match every time said DN is dialled and establishing a connection with said NN upon finding said match without access to said remote database.
(a) accessing a remote database to retrieve a new (physical) number (NN), if any, for a dialled number (DN);
(b) storing said NN in a local database; and (c) checking said local database for a match every time said DN is dialled and establishing a connection with said NN upon finding said match without access to said remote database.
2. An improved system for providing telephone number portability within a structurally distributed telephone system, and the like, comprising: a dynamic database for storing new routing information corresponding to a ported telephone number;
switching means for accessing said dynamic database every time said ported telephone number is processed by said switching means; and means for replacing least used new routing information by routing information corresponding to a newly processed ported number.
switching means for accessing said dynamic database every time said ported telephone number is processed by said switching means; and means for replacing least used new routing information by routing information corresponding to a newly processed ported number.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/534,290 | 1995-09-27 | ||
US08/534,290 US5793857A (en) | 1995-09-27 | 1995-09-27 | Method of using dynamic database to improve telephone number portability |
Publications (1)
Publication Number | Publication Date |
---|---|
CA2185376A1 true CA2185376A1 (en) | 1997-03-28 |
Family
ID=24129460
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002185376A Abandoned CA2185376A1 (en) | 1995-09-27 | 1996-09-12 | Method of using dynamic database to improve telephone number portability |
Country Status (4)
Country | Link |
---|---|
US (1) | US5793857A (en) |
AU (1) | AU694055B2 (en) |
CA (1) | CA2185376A1 (en) |
GB (1) | GB2305815B (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6161017A (en) * | 1997-10-07 | 2000-12-12 | Telefonaktiebolaget Lm Ericsson | Method of routing calls to portable numbers in a radio telecommunications network |
Families Citing this family (54)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5920562A (en) * | 1996-11-22 | 1999-07-06 | Sprint Communications Co. L.P. | Systems and methods for providing enhanced services for telecommunication call |
US6031840A (en) * | 1995-12-07 | 2000-02-29 | Sprint Communications Co. L.P. | Telecommunications system |
US6009160A (en) * | 1995-06-30 | 1999-12-28 | Siemens Information And Communication Networks, Inc. | Method for routing a call |
US5748724A (en) * | 1995-06-30 | 1998-05-05 | Siemens Stomberg-Carlson | Method for transferring a subscriber to a new local service provider |
US5887056A (en) * | 1995-06-30 | 1999-03-23 | Siemens Information And Communication Networks | Method for routing telephone calls to subscribers of different service providers within a common numbering plan area |
US5978464A (en) * | 1995-06-30 | 1999-11-02 | Siemens Information And Communications Networks, Inc. | Method for updating a local switch internal database in system having different service providers within a common numbering plan area |
US5970131A (en) * | 1995-06-30 | 1999-10-19 | Siemens Information And Communication Networks, Inc. | Method for providing location/geographic portability in a system having different service providers within a common numbering plan area |
US5991388A (en) * | 1995-06-30 | 1999-11-23 | Siemens Information And Communication Networks, Inc. | Method and system for routing calls to a party |
US6445785B1 (en) * | 1995-11-21 | 2002-09-03 | Verizon Laboratories Inc. | Methods and apparatus for local number portability in telecommunication systems |
FI2405U1 (en) * | 1995-12-20 | 1996-04-23 | Finland Telecom Oy | A system for making specially priced calls on a telecommunications network |
CA2165856C (en) * | 1995-12-21 | 2001-09-18 | R. William Carkner | Number portability with database query |
CA2165857C (en) * | 1995-12-21 | 2000-07-25 | L. Lloyd Williams | Number portability using isup message option |
AU2257097A (en) * | 1996-02-02 | 1997-08-22 | Sprint Communications Company, L.P. | Atm gateway system |
DE19621717A1 (en) * | 1996-05-30 | 1997-12-04 | Sel Alcatel Ag | Connection establishment procedure as well as switching centers and service control unit |
US5881145A (en) * | 1996-07-29 | 1999-03-09 | Northern Telecom Limited | Redirection of calls to ported directory numbers in telephone networks |
EP0854656A3 (en) * | 1996-09-27 | 2000-07-12 | Siemens Aktiengesellschaft | Method for switching calls to moved subscribers which preserve their subscriber number |
US6002689A (en) * | 1996-11-22 | 1999-12-14 | Sprint Communications Co. L.P. | System and method for interfacing a local communication device |
US6014378A (en) * | 1996-11-22 | 2000-01-11 | Sprint Communications Company, L.P. | Telecommunications tandem system for circuit-based traffic |
US5995605A (en) * | 1996-12-06 | 1999-11-30 | Ameritech Corporation | Method and network for providing access to an information network |
US5995609A (en) * | 1996-12-27 | 1999-11-30 | Nortel Networks Corporation | Number portability for a cluster of switches |
US7031442B1 (en) | 1997-02-10 | 2006-04-18 | Genesys Telecommunications Laboratories, Inc. | Methods and apparatus for personal routing in computer-simulated telephony |
US6104802A (en) | 1997-02-10 | 2000-08-15 | Genesys Telecommunications Laboratories, Inc. | In-band signaling for routing |
US6480600B1 (en) | 1997-02-10 | 2002-11-12 | Genesys Telecommunications Laboratories, Inc. | Call and data correspondence in a call-in center employing virtual restructuring for computer telephony integrated functionality |
US5898769A (en) * | 1997-03-12 | 1999-04-27 | At&T Corp | Call routing based on prior telephone calls |
US6178170B1 (en) | 1997-05-13 | 2001-01-23 | Sprint Communications Company, L. P. | System and method for transporting a call |
US6058313A (en) * | 1997-05-22 | 2000-05-02 | At&T Corp | Method of enhancing call processing in a number portability environment |
US6078657A (en) * | 1997-05-30 | 2000-06-20 | Telcordia Technologies, Inc. | Method and system for providing local telephone number portability using geographic unit building blocks |
US6985943B2 (en) | 1998-09-11 | 2006-01-10 | Genesys Telecommunications Laboratories, Inc. | Method and apparatus for extended management of state and interaction of a remote knowledge worker from a contact center |
US6711611B2 (en) | 1998-09-11 | 2004-03-23 | Genesis Telecommunications Laboratories, Inc. | Method and apparatus for data-linking a mobile knowledge worker to home communication-center infrastructure |
NL1007335C2 (en) * | 1997-10-23 | 1999-04-27 | Koninkl Kpn Nv | Network system. |
US6047056A (en) * | 1997-10-31 | 2000-04-04 | Ericsson Inc. | Method to suppress number portability database queries for calls routed on non-ported numbers |
USRE46528E1 (en) | 1997-11-14 | 2017-08-29 | Genesys Telecommunications Laboratories, Inc. | Implementation of call-center outbound dialing capability at a telephony network level |
US5966435A (en) * | 1997-12-16 | 1999-10-12 | Pino; Locillo G. | Intermediate switch service management system architecture and method |
FI105983B (en) * | 1998-01-20 | 2000-10-31 | Nokia Networks Oy | Procedure and system for redirecting a call |
US6427010B1 (en) * | 1998-01-23 | 2002-07-30 | Robert D. Farris | Systems and methods for providing voice mail services to ported numbers by supplying routing information via signaling network |
US7907598B2 (en) | 1998-02-17 | 2011-03-15 | Genesys Telecommunication Laboratories, Inc. | Method for implementing and executing communication center routing strategies represented in extensible markup language |
US6332154B2 (en) | 1998-09-11 | 2001-12-18 | Genesys Telecommunications Laboratories, Inc. | Method and apparatus for providing media-independent self-help modules within a multimedia communication-center customer interface |
USRE46153E1 (en) | 1998-09-11 | 2016-09-20 | Genesys Telecommunications Laboratories, Inc. | Method and apparatus enabling voice-based management of state and interaction of a remote knowledge worker in a contact center environment |
US6714217B2 (en) | 1998-12-18 | 2004-03-30 | Sprint Communication Company, L.P. | System and method for providing a graphical user interface to, for building, and/or for monitoring a telecommunication network |
US6888833B1 (en) * | 1998-12-22 | 2005-05-03 | Sprint Communications Company L.P. | System and method for processing call signaling |
US7079530B1 (en) | 1999-02-25 | 2006-07-18 | Sprint Communications Company L.P. | System and method for caching toll free number information |
US7103068B1 (en) * | 1999-05-04 | 2006-09-05 | Sprint Communication Company L.P. | System and method for configuring bandwidth transmission rates for call connections |
US6895088B1 (en) | 1999-05-21 | 2005-05-17 | Sprint Communications Company L.P. | System and method for controlling a call processing system |
US6898274B1 (en) | 1999-09-21 | 2005-05-24 | Nortel Networks Limited | Method and apparatus for adaptive time-based call routing in a communications system |
US6535599B1 (en) * | 1999-11-08 | 2003-03-18 | Sprint Communications Company, L.P. | System and method for processing ported calls |
US6421442B2 (en) | 1999-12-01 | 2002-07-16 | At&T Corp. | Method of enhancing call processing in a number portability environment |
US6529595B1 (en) * | 1999-12-01 | 2003-03-04 | Sprint Communications Company, L.P. | Method and apparatus to process number portability data for a call |
US7929978B2 (en) | 1999-12-01 | 2011-04-19 | Genesys Telecommunications Laboratories, Inc. | Method and apparatus for providing enhanced communication capability for mobile devices on a virtual private network |
US6625273B1 (en) | 2000-03-28 | 2003-09-23 | Sevis Systems, Inc. | System and method for a local number portability cache |
US6611831B1 (en) * | 2000-08-07 | 2003-08-26 | Lucent Technologies Inc. | Method for worldwide administration of advanced number portability numbers |
US20050259807A1 (en) * | 2003-02-28 | 2005-11-24 | Pita Madoch | Method and network for providing access to an information network |
US9008075B2 (en) | 2005-12-22 | 2015-04-14 | Genesys Telecommunications Laboratories, Inc. | System and methods for improving interaction routing performance |
US7751549B1 (en) * | 2006-03-14 | 2010-07-06 | Sprint Communications Company L.P. | Tandem switch migration method |
US8693653B1 (en) | 2007-10-09 | 2014-04-08 | Jeffrey David Mullen | Advanced dating websites |
Family Cites Families (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4191860A (en) * | 1978-07-13 | 1980-03-04 | Bell Telephone Laboratories, Incorporated | Data base communication call processing method |
US4162377A (en) * | 1978-07-13 | 1979-07-24 | Bell Telephone Laboratories, Incorporated | Data base auto bill calling using CCIS direct signaling |
US4565903A (en) * | 1983-08-03 | 1986-01-21 | At&T Bell Laboratories | Telephone interexchange carrier selection |
US4754479A (en) * | 1986-09-17 | 1988-06-28 | American Telephone And Telegraph Company | Station number portability |
US5270701A (en) * | 1988-03-08 | 1993-12-14 | Kokusai Denshin Denwa Co., Ltd. | Service processing system with distributed data bases |
US4866763A (en) * | 1988-08-17 | 1989-09-12 | American Telephone And Telegraph Company, At&T Bell Laboratories | Interexchange carrier automatic route selection system |
US5333185A (en) * | 1991-06-03 | 1994-07-26 | At&T Bell Laboratories | System for processing calling party information for international communications services |
US5237604A (en) * | 1991-06-28 | 1993-08-17 | At&T Bell Laboratories | Arrangement for serving a telephone office code from two switching systems |
US5311572A (en) * | 1991-10-03 | 1994-05-10 | At&T Bell Laboratories | Cooperative databases call processing system |
US5259026A (en) * | 1991-12-18 | 1993-11-02 | Bell Communications Research, Inc. | Method for speed calling automatic update |
US5333184A (en) * | 1992-05-06 | 1994-07-26 | At&T Bell Laboratories | Call message recording for telephone systems |
US5329578A (en) * | 1992-05-26 | 1994-07-12 | Northern Telecom Limited | Personal communication service with mobility manager |
US5386467A (en) * | 1992-07-31 | 1995-01-31 | At&T Corp. | Intelligent network communication system |
CA2078045C (en) * | 1992-09-11 | 1999-11-16 | Mark R. Sestak | Global management of telephone directory |
CA2081125C (en) * | 1992-10-22 | 1997-03-04 | Deborah L. Pinard | Portable telephone user profiles |
US5473681A (en) * | 1993-07-02 | 1995-12-05 | At&T Corp. | Method for use in completing telephone calls |
US5481603A (en) * | 1993-09-28 | 1996-01-02 | At&T Corp. | Intelligent call processing based upon complete identification of calling station |
US5475749A (en) * | 1994-02-28 | 1995-12-12 | At&T Corp. | Connections between a toll network and multiple local networks |
US5550912A (en) * | 1994-02-28 | 1996-08-27 | At&T Corp. | Connections between a toll network and multiple local networks |
US5515427A (en) * | 1994-07-19 | 1996-05-07 | At&T Corp. | Completion of intelligent network telephone calls |
US5509062A (en) * | 1994-08-03 | 1996-04-16 | At&T Corp. | Intelligent terminal based selective call forwarding |
EP0710042A2 (en) * | 1994-10-26 | 1996-05-01 | AT&T Corp. | Means and method for providing local telephone number portability |
US5550910A (en) * | 1994-11-18 | 1996-08-27 | Lucent Technologies Inc. | End-User communications device with automatic carrier selection capability for intraLATA toll calls |
US5559877A (en) * | 1995-03-21 | 1996-09-24 | At&T | Automatic provisioning of trunking and routing parameters in a telecommunications network |
US5598464A (en) * | 1995-06-20 | 1997-01-28 | Dsc Communications Comporation | Method and apparatus for providing local number portability |
US5748724A (en) * | 1995-06-30 | 1998-05-05 | Siemens Stomberg-Carlson | Method for transferring a subscriber to a new local service provider |
US5689555A (en) * | 1995-06-30 | 1997-11-18 | Siemens Stromberg-Carlson | Method for transferring a subscriber to a new local service provider |
US5625681A (en) * | 1995-08-11 | 1997-04-29 | Stratus Computer, Inc. | Method and apparatus for telephone number portability |
-
1995
- 1995-09-27 US US08/534,290 patent/US5793857A/en not_active Expired - Lifetime
-
1996
- 1996-09-12 CA CA002185376A patent/CA2185376A1/en not_active Abandoned
- 1996-09-19 AU AU65746/96A patent/AU694055B2/en not_active Ceased
- 1996-09-26 GB GB9620111A patent/GB2305815B/en not_active Expired - Fee Related
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6161017A (en) * | 1997-10-07 | 2000-12-12 | Telefonaktiebolaget Lm Ericsson | Method of routing calls to portable numbers in a radio telecommunications network |
Also Published As
Publication number | Publication date |
---|---|
AU6574696A (en) | 1997-04-10 |
GB2305815A (en) | 1997-04-16 |
AU694055B2 (en) | 1998-07-09 |
GB2305815B (en) | 2000-07-26 |
US5793857A (en) | 1998-08-11 |
GB9620111D0 (en) | 1996-11-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US5793857A (en) | Method of using dynamic database to improve telephone number portability | |
US5539817A (en) | Wide area centrex toll service with novel translation | |
US5917899A (en) | Method of connecting a plurality of virtual networks | |
EP0932984B1 (en) | Telecommunications network with relocateability of subscriber number | |
US5892821A (en) | Virtual wide area centrex | |
US6014379A (en) | Telecommunications custom calling services | |
US6438223B1 (en) | System and method for local number portability for telecommunication networks | |
US7068771B2 (en) | Method and network for routing a communication through an alternate carrier | |
CA2178860C (en) | Number portability using enhanced routing table | |
US7356138B2 (en) | Method of operating a virtual private network | |
US6377674B1 (en) | Method for global title translation processing | |
US6141409A (en) | Method of operating a virtual private network | |
US7106846B2 (en) | System and method for caller control of a distinctive ring | |
AU709864B2 (en) | Enhanced efficient telephone number portability | |
EP0898430A1 (en) | Communications system | |
US20070019624A1 (en) | Trunk and switch architecture for providing switched-circuit connections to on-line data services | |
US6487412B1 (en) | Method and system for routing calls to wireless directory numbers in a network | |
GB2315953A (en) | Number portability | |
EP1522196B1 (en) | Centralized service control for a telecommunication system | |
US5949870A (en) | System and method for providing local number portability service | |
US20070140158A1 (en) | Method, apparatus and network arrangement for establishing calls in a communications network | |
US20030123637A1 (en) | Local exchange carrier escape list for local number portability | |
US6421428B1 (en) | Flexible ANI | |
US7394897B1 (en) | Method and system for routing service calls made from resold lines | |
US6411703B1 (en) | Geographically distributed telephony |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FZDE | Discontinued |
Effective date: 20040913 |