The Line Information Database (LIDB)
`and Wireless Services
`
`
`
`
`
`Telcordia Technologies, Inc.
`White Paper Analysis
`December 2001
`
`An SAIC Company
`
`Exhibit 1029
`IPR2015-01219
`
`

`
`The LIDB and Wireless Services
`
`
`
`December 2001
`Page ii
`
`
`
`The Line Information Database (LIDB) and Wireless Services
`
`
`
`Prepared for Telcordia Technologies, Inc. by:
`Sherry Zhang
`331 Newman Springs Road, Room 2X-115
`Red Bank, NJ 07701-5699
`E-mail: xzhang@telcordia.com
`Phone: 1-732-758-2379
`
`
`
`Copyright © 2001 Telcordia Technologies, Inc. All rights reserved. This document may not be
`reproduced without the express written permission of Telcordia Technologies, and any reproduction
`without written authorization is an infringement of copyright.
`
`Trademark Acknowledgments
`
`Telcordia is a trademark of Telcordia Technologies, Inc.
`Any other companies and products not mentioned herein are trademarks or service marks of their
`respective trademark and service mark owners.
`
`
`
`
`Copyright © 2001, Telcordia Technologies, Inc.
`All Rights Reserved
`
`

`
`The LIDB and Wireless Services
`
`Table of Content
`
`December 2001
`Page iii
`
` 1
`
` Executive Summary ...............................................................................................................................1
`2 LIDB Capabilities ..................................................................................................................................2
`2.1 Overview.........................................................................................................................................2
`2.1.1 What is LIDB ..........................................................................................................................2
`2.1.2
`Benefits of LIDB .....................................................................................................................2
`2.2 Data Structure .................................................................................................................................3
`2.3 Access Methods ..............................................................................................................................4
`2.3.1
`TCAP/SS7 ...............................................................................................................................4
`2.3.2 ANS-41....................................................................................................................................7
`2.3.3
`LDAP/TCP/IP..........................................................................................................................8
`2.4 Data Administration........................................................................................................................9
`2.5 Number Portability .........................................................................................................................9
`2.6
`Fraud Monitoring..........................................................................................................................14
`3 Use of LIDB for Wireless Services......................................................................................................15
`3.1 Overview.......................................................................................................................................15
`3.2 Calling Name Presentation (CNAP) .............................................................................................15
`3.3 Third Party Charging ....................................................................................................................16
`3.4 User Selective Call Forwarding (USCF) ......................................................................................17
`3.5 Commercial Location Based Services (LBS) ...............................................................................19
`3.6 Others............................................................................................................................................20
`4 Conclusions..........................................................................................................................................21
`4.1
`Summary.......................................................................................................................................21
`4.2 References.....................................................................................................................................21
`Appendix A: LIDB Data Elements .............................................................................................................22
`Appendix B: Acronyms...............................................................................................................................27
`
`
`
`
`Copyright © 2001, Telcordia Technologies, Inc.
`All Rights Reserved
`
`

`
`The LIDB and Wireless Services
`
`
`December 2001
`Page 1
`
`1 Executive Summary
`This non-proprietary white paper is prepared by Telcordia Technologies for the National LIDB Product
`Team. The National LIDB Product Team is an organization of LIDB owners dedicated to providing
`creative data solutions to meet industry needs.
`This paper captures a wide spectrum of capabilities that LIDB could support, including those used by the
`wireline service providers. For example, LIDB supports the validation of calling card, collect and third
`number charged calls, and the data stored in LIDB is used for national services such as Calling Name
`Delivery (CNAM).
`LIDB has evolved in concert with a rapidly changing industry by offering new and creative data solutions
`in response to industry needs. It is the “database of choice” for national services, both wireline and
`wireless. This paper identifies various wireless services that can use LIDB as the data source for wireline
`and wireless subscriber information, such as name, preferred language, charging restrictions, ZIP code,
`home service provider, and preferred inter-exchange carrier. Additionally, with the support of an
`American National Standards (ANS)-41 (also known as Interim Standards [IS]-41) interface, wireless
`service providers could use the LIDB data to offer enhanced services, as well. These services, which
`could be offered on a national basis, include Calling Name Presentation (CNAP), User Selective Call
`Forwarding (USCF), Third Party Charging, and many more.
`This paper provides a subjective review of the LIDB capabilities and its various interfaces, and elaborates
`on how LIDB can be used to support value-added wireless services.
`
`
`
`Copyright © 2001, Telcordia Technologies, Inc.
`All Rights Reserved
`
`

`
`The LIDB and Wireless Services
`
`
`December 2001
`Page 2
`
`2 LIDB Capabilities
`LIDB data and its capabilities have been widely used to support various wireline services. This section
`introduces LIDB and discusses the capabilities that LIDB provides.
`
`2.1 Overview
`
`2.1.1 What is LIDB
`LIDB is the database that contains information associated with a telephone number. It resides on a
`Service Control Point (SCP). LIDB data ranges from the customer’s service provider, his or her name, to
`the preferred language of the customer. Collectively, LIDBs contain information on nearly all working
`telephone numbers in North America, including wireline and wireless.
`LIDB is flexible and has evolved over the past 15 years. It was first introduced to support the validation
`of calling card, collect, and third number charged calls. As industry needs changed, new data and
`capabilities were added to LIDB to meet such needs. Today, LIDB’s data and the services it can support
`have expanded much beyond those for validation. For example, its Account Owner (AO) information has
`proven to be a valuable resource for the needs to identify a customer’s true service provider in the local
`competition environment. Service providers are retrieving data from LIDB for their services, e.g.,
`CNAM, Single Number Service, Customer Care, etc. Nevertheless, LIDB continues to evolve to support
`new data and new interface capabilities (e.g., ANS-41, Lightweight Directory Access Protocol [LDAP]),
`in order to meet the growing needs of the industry.
`
`2.1.2 Benefits of LIDB
`LIDB’s experience and success in providing data solutions have made LIDB the “database of choice” for
`line number information. Service providers are exploiting the benefits of LIDB for many reasons. The
`following are some of the key benefits of using LIDB:
` Central repository for data storage and retrieval – LIDB provides a centralized resource for data
`associated with a telephone number. Its data is used today for a variety of services. It saves service
`providers from the burden of using information from different databases.
` Nationally accessible – LIDBs can be accessed on a national basis. It is not limited to intra-company
`access. For example, its Signaling System Number 7 (SS7) interface connects LIDB to the national
`SS7 network, so that any carrier or service provider can access LIDB via the SS7 network. This
`makes LIDB a potential resource for national services, unlike some proprietary databases.
` Continually audited and updated – LIDB has its own Administrative System (AS), which
`maintains and updates LIDB data. The LIDB AS gathers data from a variety of sources, such as
`service ordering systems and billing systems, and updates LIDB data on a near real-time basis. The
`LIDB AS also audits LIDB data regularly to ensure its accuracy.
` 24x7 and fault tolerant – LIDB was designed to be capable of supporting real-time call-related
`services. It is subjected to stringent availability and fault tolerance requirements by regulation.
`LIDB’s experience in the past 15 years has also proven its high reliability.
` Existing platform – LIDB has the advantage over any new line-level database because of its current
`existence. LIDB offers the flexibility to add new data elements for any new services that need line-
`level information, instead of creating and developing a brand-new platform. It also provides Query
`Originators (QOs) information on telephone numbers that they may not own.
`
`
`Copyright © 2001, Telcordia Technologies, Inc.
`All Rights Reserved
`
`

`
`The LIDB and Wireless Services
`
`
`December 2001
`Page 3
`
` Capable of storing wireless data – LIDB is not just a wireline database. It is storing data for
`wireless line numbers today, such as the name information. Its data definition has also expanded to
`wireless customer data. Therefore, LIDB can provide data solutions for both wireline and wireless
`services.
`
`2.2 Data Structure
`LIDB data records are organized in two levels: group level data and line level data. The NPA-NXX
`group record contains information that is common to all line numbers in the group, such as group
`processing indicators and group status indicators. The group processing indicators are used to enable and
`disable LIDB processing capabilities at the NPA-NXX group level. The group status indicators specify if
`the group is “active”, “vacant”, or “non-participant.” The LIDB line record contains data associated with
`the 10-digit line number (NPA-NXX-XXXX). These data elements are retrieved and used by service
`providers to support a number of services. The following are a few examples of LIDB line-level
`information:
` Account Owner (AO) is the 4-character alphanumeric code representing the customer’s local service
`provider. This code is assigned by the National Exchange Carrier Association (NECA).
` Revenue Accounting Office (RAO) identifies the billing location to which billing records for calling
`card, collect, and third number charged calls are ultimately directed so that a bill may be rendered.
` Service or Equipment Indicator indicates the type of service or equipment for the line, e.g., hospital,
`prison, cellular/mobile, etc.
` Calling Card Information includes a group of data elements that are used to validate a calling card
`call, such as what type of calling card it is and whether or not the card is suspended due to fraud.
` Collect and Third Number Billing Information includes a group of data elements that indicate whether
`or not collect and third number billing are allowed for the line.
` Originating/Billing Service Information refers to a group of data elements that specify the billing
`restrictions associated with the originating line, such as whether or not InterLATA calls are allowed
`from the line.
` Originating Carrier Information includes a group of data elements that specify the carrier preference
`of the customer.
` Foreign Language Identifier specifies the preferred language of the customer. Currently, values for
`51 languages have been defined.
` Generic Name contains the name of the customer and the name presentation status for privacy
`purpose.
` Wireless Services Originating/Terminating Indicators are a group of indicators that specify what
`originating or terminating wireless services the customer prefers and the types of restrictions
`associated with the line. For example, the Wireless Services Terminating Indicator contains an
`indicator that specifies if a wireless customer subscribes to Calling Party Pays (CPP) service, and the
`Wireless Service Originating Indicator contains an indicator that specifies if the customer accepts
`CPP charges for calls to a wireless line.
` Diversion Routing Number (DRN) contains a number to divert calls to, such as a call forwarding
`number.
` ZIP contains the postal ZIP code for the line, which is up to 9 characters long.
`A complete list of LIDB data elements can be found in Attachment A of this paper.
`
`
`Copyright © 2001, Telcordia Technologies, Inc.
`All Rights Reserved
`
`

`
`The LIDB and Wireless Services
`
`2.3 Access Methods
`This section discusses how to retrieve data from LIDB, and the types of interfaces that are available.
`LIDB was originally designed to be accessed via the SS7 protocol, using the Transaction Capabilities
`Application Part (TCAP) messages. Design and development efforts are in plan to allow access to LIDB
`via the ANS-41 and LDAP interfaces.
`
`December 2001
`Page 4
`
`2.3.1 TCAP/SS7
`LIDB can be accessed via the SS7 network, using five types of TCAP messages. These message types
`are also known as “query types.” The five query types are:
` Calling Card (CC)
` Billed Number Screening (BNS)
` Originating Line Number Screening (OLNS)
` Calling Name Delivery (CNAM), and
` GetData.
`LIDB takes different actions based on the query type received. It returns either a pre-defined set of data
`elements (e.g., BNS) or a specifically requested set of data elements (e.g., GetData) to the Query
`Originator (QO).
`
`Calling Card (CC)
`A CC query is used to validate the line number used for a calling card call. It is sent by the Operator
`Services System (OSS) or the service platform that handles the calling card call. The CC query contains
`the calling card number and PIN, as well as the calling and called numbers of the call. LIDB processes
`the CC query and determines whether the call should be allowed. If the call is allowed, a successful
`response is returned to the QO, including the information needed for billing, such as AO and RAO. If the
`call is to be denied, a response with explicit denial indicators or an error message is returned from LIDB.
`Billed Number Screening (BNS)
`A BNS query is used to validate the billing telephone number used for a collect or a third number charged
`call. The query is sent by the OSS handling the call. The BNS query contains the billing, calling, and
`called numbers of the call. LIDB processes the BNS query, determines whether the call should be
`allowed, and sends a BNS response to the QO. The Collect and Third Number Acceptance Indicators
`returned in the BNS response indicate whether the call should be allowed or denied. The BNS response
`also contains information needed for processing and billing of the call, such as Service or Equipment
`Indicator, Treatment Indicator, AO and RAO. Any error condition would cause an error message to be
`returned from LIDB.
`Originating Line Number Screening (OLNS)
`An OLNS query is used to obtain originating and billing restrictions on a telephone number. It is sent by
`an OSS before handling an operator services call. The OLNS query contains the originating line number.
`LIDB processes the OLNS query and returns an OLNS response message to the QO. The OLNS
`response contains a pre-defined set of data elements, including AO, Originating Billing/Service
`Indicators, Originating Carrier Information, Service or Equipment Indicator, Treatment Indicator, Foreign
`Language Identifier, etc. An error condition would cause an error message to be returned from LIDB.
`
`
`
`Copyright © 2001, Telcordia Technologies, Inc.
`All Rights Reserved
`
`

`
`The LIDB and Wireless Services
`
`
`December 2001
`Page 5
`
`Calling Name Delivery (CNAM)
`A CNAM query is used to retrieve the name information associated with a telephone number. The query
`originates from the terminating End Office (EO). The CNAM query contains the calling number. LIDB
`processes the CNAM query and returns a CNAM response to the QO. The CNAM response contains the
`name and the name presentation status. An error message would be returned if an error is encountered
`during LIDB processing.
`GetData
`A GetData query is used to retrieve any LIDB data associated with a telephone number. It could be sent
`by any service platform or network element that needs the information. The query could be launched
`before, during, or after the call, as required by the service. LIDB processes the GetData query and
`returns the requested data elements in the GetData response. An error message would be returned if an
`error is encountered during LIDB processing.
`The remainder of this section shows three examples of call flows for BNS, CNAM, and GetData queries,
`respectively. These examples illustrate how LIDB data is used to support some of the wireline services
`today.
`
`Example 1: BNS Call Flow
`Figure 1 shows the call flow of a collect call.
`
`
`
`
`3
`
`OSS
`
`6
`
`4
`
`SCP
`
`5
`
`LIDB
`
`7
`
`EO
`
`908-758-5678
`
`
`
`2
`
`EO
`
`1
`
`908 - 699 - 1234
`
`Figure 1. BNS Call Flow Example
`
`1. Caller goes off-hook and dials 0+908 758 5678.
`2. EO routes the call to the OSS.
`3. OSS asks the caller for billing option, and the caller chooses to bill the call collect.
`
`
`Copyright © 2001, Telcordia Technologies, Inc.
`All Rights Reserved
`
`

`
`The LIDB and Wireless Services
`
`
`December 2001
`Page 6
`
`4. OSS sends a BNS query to LIDB, including 908 699 1234 as the calling number, and
`908 758 5678 as the billing and called numbers.
`5. LIDB processes the query and encounters no error or service denial.
`6. LIDB sends a successful BNS response to the OSS, indicating “collect call is allowed
`with verification.”
`7. OSS rings the terminating line and asks for acceptance of charges. If the called party
`accepts the charge, the OSS connects the caller to the called party.
`
`
`Example 2: CNAM Call Flow
`Figure 2 shows a call flow when the called party has subscribed to CNAM service.
`
`
`
`
`SCP
`
` 3
`
`LIDB
`
`4
`
`EO
`
`5
`
`Smith, John
`(908) 699 1234
`908-758-5678
`
`
`
`2
`
`EO
`
`1
`
`908 - 699 - 1234
`
`Figure 2. CNAM Call Flow Example
`
`1. Caller goes off-hook and dials 908 758 5678.
`2. Originating EO routes the call to terminating EO.
`3. Terminating EO determines that the called number has CNAM subscription active,
`and sends a CNAM query to LIDB with calling number 908 699 1234.
`4. LIDB processes the CNAM query, encounters no error, and sends the response back to
`the terminating EO, which contains the name and presentation status for 908 699
`1234.
`5. Terminating EO processes the CNAM response and displays the caller’s name on the
`called party’s Customer Premises Equipment (CPE).
`
`
`
`
`Copyright © 2001, Telcordia Technologies, Inc.
`All Rights Reserved
`
`

`
`The LIDB and Wireless Services
`
`
`December 2001
`Page 7
`
`Example 3: Single Number Service (GetData) Call Flow
`Figure 3 shows a call flow of Single Number Service, which connects the caller to the closest pizzeria by
`dialing a special code (e.g., *PIZZA). Today, this service is offered as an Advanced Intelligent Network
`(AIN) service, and uses the LIDB GetData query to retrieve the caller’s ZIP code.
`
`
`
`
`SCP
`
`LIDB
`
`4
`
`5
`
`3
`
`AIN
`SCP
`
`2
`
`6
`
`SSP
`
`1
`
`908-699-1234
`
`Pizza
`
`7
`
`Pizza
`
`908-758- 5678
`
`
`
`Figure 3. Single Number Service (GetData) Call Flow
`
`1. Caller dials *PIZZA.
`2. The Service Switching Point (SSP) encounters an AIN trigger and sends a message to
`the AIN SCP requesting instructions for processing the call.
`3. AIN SCP determines that the caller’s ZIP code is needed for the service.
`4. AIN SCP sends a GetData query to LIDB requesting ZIP associated with 908 699
`1234.
`5. LIDB processes the GetData query, encounters no error, and returns the ZIP data
`element associated with 908 699 1234.
`6. Based on the LIDB response, the AIN SCP determines that the call should be
`terminated to 908 758 5678, and sends a message to the SSP to complete the call
`accordingly.
`7. SSP completes the call to 908 758 5678, which is the closest pizzeria to the caller’s
`home.
`
`
`
`2.3.2 ANS-41
`Wireless service providers use the ANS-41 protocol suite to offer wireless voice and enhanced services in
`North America. Efforts are in plan to define and develop an ANS-41 interface to LIDB. With the LIDB
`support of ANS-41, wireless service providers can use the protocol that they are familiar with to access
`
`Copyright © 2001, Telcordia Technologies, Inc.
`All Rights Reserved
`
`

`
`The LIDB and Wireless Services
`
`
`December 2001
`Page 8
`
`LIDB for wireless and wireline data. The LIDB ANS-41 interface would save wireless service providers
`from having to support multiple protocols for one service. Initially, three ANS-41 messages would be
`considered for the LIDB ANS-41 interface: ServiceRequest, Search, and Modify.
`ServiceRequest
`The ServiceRequest message would be used to retrieve the name associated with the calling number from
`LIDB in order to support CNAP, which displays the caller’s name on the wireless subscriber’s handset.
`The ServiceRequest message would contain the calling number of the call, which could be either a
`wireline or wireless number. The response message would contain the name and name presentation
`information. Depending on the architecture of the wireless service provider’s network, the network entity
`sending the ServiceRequest message could be a Home Location Register (HLR), a Wireless Intelligent
`Network (WIN) Service Control Point (SCP), or a Mobile Switching Center (MSC).
`Search
`The Search message would be used to retrieve any data associated with a line number from LIDB, in
`order to support the enhanced services subscribed by the wireless customer. The Search message would
`contain the line number (either wireless or wireline), and the identifiers of the data elements requested.
`The response message would contain the data elements requested. The Search message could be sent by
`the wireless service platform, such as a WIN SCP.
`Modify
`The Modify message would be used to update data associated with a line number in LIDB when service
`logic requires to add/delete/replace the value of a data element to support the wireless service. The
`Modify message would contain the line number and the data elements to be changed. LIDB processes the
`message and makes changes to its data according to the Modify message. The response message would
`indicate the outcome of the update. The Modify message could be sent by the wireless service platform,
`such as a WIN SCP.
`LIDB’s ANS-41 support may not be limited to these messages. As industry needs change, LIDB could
`evolve to support a broader spectrum of ANS-41 messages to better serve the wireless service providers.
`
`2.3.3 LDAP/TCP/IP
`LDAP over TCP/IP is used widely on the Internet and IP-based networks for information retrieval.
`LIDB’s capabilities need to be enhanced to meet the data needs of the growing IP-based data network.
`Therefore, in 2000, an LDAP/TCP/IP interface was defined for LIDB by Telcordia and its funding clients.
`Efforts are in plan for the development of this interface. Two LDAP messages have been defined to be
`supported by LIDB for this interface: Search and Modify.
`Search
`The LDAP Search message would allow an LDAP Client to retrieve any data associated with a line
`number from LIDB, which would then be used by the LDAP Client for services it provides to the end
`user. The LDAP Search request would contain the telephone number and the names of data elements
`requested. The response from LIDB would contain the values of data elements requested.
`Modify
`The LDAP Modify message would allow an LDAP Client to add/delete/replace data associated with a
`line number in LIDB. The LDAP Modify message would contain the line number and the data elements
`to be modified. LIDB would process the message and make changes to its data according to the Modify
`message. The response message from LIDB would indicate the outcome of the update.
`
`
`
`Copyright © 2001, Telcordia Technologies, Inc.
`All Rights Reserved
`
`

`
`December 2001
`Page 9
`
`The LIDB and Wireless Services
`
`2.4 Data Administration
`The LIDB Administrative System (AS) is responsible for administering and maintaining data in LIDB.
`Its key responsibilities include:
` Updating LIDB data on a near real-time basis – Various data sources feed data into the LIDB AS,
`which then updates the corresponding data in LIDB. An example of a data source is the Service
`Order Systems of the LIDB owner. Whenever there is a change in the service order, it is passed along
`to the LIDB AS. The LIDB AS processes this information and updates the LIDB accordingly. This
`is usually an automated process, so that LIDB data can be updated as quickly as possible.
` Auditing LIDB data regularly to ensure its accuracy – The LIDB AS conducts audits of LIDB
`data on a regular basis. It compares LIDB data to its own copy and eliminates any discrepancies.
`Some LIDB AS also conducts audits against its data sources to ensure that the data is accurate.
` Processing LIDB exception reports to maintain the integrity of data – LIDB may generate reports
`to the LIDB AS when there is exception during processing that could be caused by inconsistency of
`data. Emergency edits to the LIDB are also reported to the LIDB AS. The LIDB AS processes and
`analyzes these reports, then takes proper remedial actions, such as notifying personnel in charge,
`generating alarms, or making corrections.
`The LIDB AS is connected to the LIDB via dedicated X.25 links or secure TCP/IP connections.
`Messages are exchanged over the LIDB AS-LIDB interface for updates, audits, and reports. The LIDB
`AS is the primary method of updating LIDB data. In other words, all data has to go through the LIDB AS
`before being loaded in LIDB, except for emergency edits when the LIDB AS-LIDB interface is not
`available. Reports of these emergency edits are queued in LIDB, and sent to the LIDB AS when the
`interface is back up. The LIDB AS would take proper action to synchronize its data with LIDB.
`It should be noted that for the LIDB owner’s data, the source of data is the Service Order. However, for
`LIDB storage customers, the data is provided by the customer electronically or manually (e.g., via file
`transfer or an interactive user interface). This is how wireless service providers enter their data into
`LIDB.
`
`2.5 Number Portability
`LIDB supports Local Number Portability (LNP), which enables an end user to switch his/her service
`provider without changing the telephone number. As mentioned previously, LIDB data includes the true
`service provider information, i.e., Account Owner (AO), associated with each line number. AO is a
`crucial piece of information used for billing settlements in the number portability and local competition
`environment.
`When an end user switches from one service provider to another, the associated LIDB data may or may
`not move from one LIDB to another. Regardless, network routing would ensure that messages are routed
`to the appropriate LIDB. Therefore, LIDB services should not be affected when a number is ported.
`Nevertheless, when an end user ports from wireline to wireless, or vice versa, the proper data value
`should be loaded for that line number in LIDB based on the service provided by the new wireless or
`wireline provider.1 The following examples (not all-inclusive) illustrate what should be done in LIDB for
`wireless-wireline number portability, especially to prevent Alternate Billing Service (ABS) fraud. Note
`that calling card, collect, and third number charging services are collectively referred to as ABS. The
`LIDB CC and BNS query types are used to support ABS.
`
`
`
`
`1 This statement is also true for wireline-to-wireline portability, since wireline providers may not offer the same suite of services.
`
`Copyright © 2001, Telcordia Technologies, Inc.
`All Rights Reserved
`
`

`
`The LIDB and Wireless Services
`
`
`December 2001
`Page 10
`
`
`Scenario 1: Wireless (CNAM) to Wireline (CNAM)
`In this scenario, depicted by Figure 4, the end user’s telephone number (666-777-8888) is ported from
`wireless company ABC to wireline company XYZ. Both companies, ABC and XYZ, offer CNAM, but
`not ABS.
`
`
`Wireless
`Company
`ABC
`
`CNAM
`
`LIDBABC
`
`Wireline
`Company
`XYZ
`
`CNAM
`
`LIDBXYZ
`
`666-777-8888
`
`Figure 4. Number Portability Scenario 1:
`Wireless (CNAM) to Wireline (CNAM)
`
`
`
`When the number is ported, wireless company ABC needs to delete the 666-777-8888 line record in its
`LIDBABC, and wireline company XYZ needs to create a line record for 666-777-8888 in its LIDBXYZ. The
`LNP databases (not shown in the figure) would be updated to route all CNAM queries for 666-777-8888
`to LIDBXYZ, instead of LIDBABC. Because wireline company XYZ does not offer ABS, it should either
`disable CC and BNS for the 666-777 group, or set the line-level CC and BNS indicators explicitly to
`“denial” in the 666-777-8888 line record.2 The former approach may not be a good choice if company
`XYZ is sharing the LIDB with other data storage customers, since all lines under the 666-777 group
`would be disabled for CC and BNS.
`
`
`2 If routing is done properly, a CC or BNS query should never be routed to XYZ’s LIDB. However, in case of a routing error, this would help to
`prevent ABS fraud.
`
`Copyright © 2001, Telcordia Technologies, Inc.
`All Rights Reserved
`
`

`
`The LIDB and Wireless Services
`
`
`December 2001
`Page 11
`
`
`Scenario 2: Wireless (CNAM) to Wireline (ABS, CNAM)
`In this scenario, depicted by Figure 5, the end user’s telephone number (666-777-8888) is ported from
`wireless company ABC to wireline company XYZ. Wireless company ABC offers CNAM, but wireline
`company XYZ offers both ABS and CNAM.
`
`
`Wireless
`Company
`ABC
`
`CNAM
`
`LIDBABC
`
`Wireline
`Company
`XYZ
`
`ABS
`CNAM
`
`LIDBXYZ
`
`666-777-8888
`
`Figure 5. Number Portability Scenario 2:
`Wireless (CNAM) to Wireline (ABS, CNAM)
`
`
`
`Similar to Scenario 1, when the number is ported, wireless company ABC needs to delete the 666-777-
`8888 line record in its LIDBABC, and wireline company XYZ needs to create a line record for 666-777-
`8888 in its LIDBXYZ. The difference here is that the new 666-777-8888 line record may allow ABS calls
`to be billed to this number. The LNP databases (not shown in the figure) would be updated to route all
`CC, BNS, and CNAM queries for 666-777-8888 to LIDBXYZ, while originally, only the CNAM queries
`were being routed to LIDBABC.
`
`
`Copyright © 2001, Telcordia Technologies, Inc.
`All Rights Reserved
`
`

`
`The LIDB and Wireless Services
`
`
`December 2001
`Page 12
`
`
`Scenario 3: Wireline (ABS, CNAM) to Wireless (CNAM)
`In this scenario, depicted by Figure 6, the end user’s telephone number (555-444-3333) is ported from
`wireline company XYZ to wireless company ABC. Wireline company XYZ offers both ABS and
`CNAM, but wireless company ABC only offers CNAM.
`
`
`Wireless
`Company
`ABC
`
`CNAM
`
`LIDBABC
`
`555-444-3333
`
`Wireline
`Company
`XYZ
`
`ABS
`CNAM
`
`LIDBXYZ
`
`Figure 6. Number Portability Scenario 3:
`Wireline (ABS, CNAM) to Wireless (CNAM)
`
`
`
`When the number is ported, wireline company XYZ needs to delete the 555-444-3333 line record in its
`LIDBXYZ, and wireless company ABC needs to create a line record for 555-444-3333 in its L