07a FYI LIDB_WhitePaper[Telcordia]

8/13/2019 07a FYI LIDB_WhitePaper[Telcordia]

1/31

An SAIC Company

The Line Information Database (LIDB)

and Wireless Services

Telcordia Technologies, Inc.White Paper Analysis

December 2001


2/31

The LIDB and Wireless Services December 2001Page ii

Copyright 2001, Telcordia Technologies, Inc.All Rights Reserved

The Line Information Database (LIDB) and Wireless Services

Prepared for Telcordia Technologies, Inc. by:

Sherry Zhang

331 Newman Springs Road, Room 2X-115Red Bank, NJ 07701-5699E-mail: [email protected]: 1-732-758-2379

Copyright 2001 Telcordia Technologies, Inc. All rights reserved. This document may not bereproduced without the express written permission of Telcordia Technologies, and any reproductionwithout written authorization is an infringement of copyright.

Trademark AcknowledgmentsTelcordia is a trademark of Telcordia Technologies, Inc.

Any other companies and products not mentioned herein are trademarks or service marks of theirrespective trademark and service mark owners.


3/31

The LIDB and Wireless Services December 2001Page iii


Table of Content

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) ...............................................................................193.6 Others............................................................................................................................................20

4 Conclusions..........................................................................................................................................21

4.1 Summary.......................................................................................................................................21

4.2 References.....................................................................................................................................21

Appendix A: LIDB Data Elements .............................................................................................................22

Appendix B: Acronyms...............................................................................................................................27


4/31

The LIDB and Wireless Services December 2001Page 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 providingcreative data solutions to meet industry needs.

This paper captures a wide spectrum of capabilities that LIDB could support, including those used by thewireline service providers. For example, LIDB supports the validation of calling card, collect and thirdnumber 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 andwireless. This paper identifies various wireless services that can use LIDB as the data source for wirelineand 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 anAmerican 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 CallForwarding (USCF), Third Party Charging, and many more.

This paper provides a subjective review of the LIDB capabilities and its various interfaces, and elaborateson how LIDB can be used to support value-added wireless services.


5/31



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 customers service provider, his or her name, tothe preferred language of the customer. Collectively, LIDBs contain information on nearly all workingtelephone 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 validationof 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, LIDBs data and the services it can supporthave 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 customers true service provider in the localcompetition 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

LIDBs 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. Thefollowing 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 serviceproviders 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-companyaccess. 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. Thismakes LIDB a potential resource for national services, unlike some proprietary databases.

Continually audited and updated LIDB has its own Administrative System (AS), whichmaintains and updates LIDB data. The LIDB AS gathers data from a variety of sources, such asservice 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.LIDBs 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.


6/31



Capable of storing wireless data LIDB is not just a wireline database. It is storing data forwireless 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 wirelessservices.

2.2 Data Structure

LIDB data records are organized in two levels: group level data and line level data. The NPA-NXXgroup 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 ifthe 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 serviceproviders to support a number of services. The following are a few examples of LIDB line-levelinformation:

Account Owner (AO)is the 4-character alphanumeric code representing the customers local serviceprovider. This code is assigned by the National Exchange Carrier Association (NECA).

Revenue Accounting Office (RAO)identifies the billing location to which billing records for callingcard, collect, and third number charged calls are ultimately directed so that a bill may be rendered.

Service or Equipment Indicatorindicates the type of service or equipment for the line, e.g., hospital,prison, cellular/mobile, etc.

Calling Card Informationincludes a group of data elements that are used to validate a calling cardcall, 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 Informationincludes a group of data elements that indicate whetheror not collect and third number billing are allowed for the line.

Originating/Billing Service Informationrefers to a group of data elements that specify the billingrestrictions associated with the originating line, such as whether or not InterLATA calls are allowed

from the line.

Originating Carrier Informationincludes a group of data elements that specify the carrier preference

of the customer.

Foreign Language Identifierspecifies the preferred language of the customer. Currently, values for51 languages have been defined.

Generic Namecontains the name of the customer and the name presentation status for privacypurpose.

Wireless Services Originating/Terminating Indicatorsare a group of indicators that specify whatoriginating or terminating wireless services the customer prefers and the types of restrictionsassociated 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 acceptsCPP charges for calls to a wireless line.

Diversion Routing Number (DRN)contains a number to divert calls to, such as a call forwardingnumber.

ZIPcontains 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.


7/31



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 CapabilitiesApplication Part (TCAP) messages. Design and development efforts are in plan to allow access to LIDBvia the ANS-41 and LDAP interfaces.

2.3.1 TCAP/SS7

LIDB can be accessed via the SS7 network, using five types of TCAP messages. These message typesare 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 dataelements (e.g., BNS) or a specifically requested set of data elements (e.g., GetData) to the QueryOriginator (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 OperatorServices System (OSS) or the service platform that handles the calling card call. The CC query containsthe calling card number and PIN, as well as the calling and called numbers of the call. LIDB processesthe CC query and determines whether the call should be allowed. If the call is allowed, a successfulresponse 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, andcalled numbers of the call. LIDB processes the BNS query, determines whether the call should beallowed, and sends a BNS response to the QO. The Collect and Third Number Acceptance Indicatorsreturned in the BNS response indicate whether the call should be allowed or denied. The BNS responsealso 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 bereturned 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 byan 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 OLNSresponse contains a pre-defined set of data elements, including AO, Originating Billing/Service

Indicators, Originating Carrier Information, Service or Equipment Indicator, Treatment Indicator, ForeignLanguage Identifier, etc. An error condition would cause an error message to be returned from LIDB.


8/31



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. LIDBprocesses the CNAM query and returns a CNAM response to the QO. The CNAM response contains thename 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 sentby 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 andreturns the requested data elements in the GetData response. An error message would be returned if anerror 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.

LIDB

OSS

EO EO

SCP

1

2

3

45

6

7

908-758-5678908-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.


9/31



4. OSS sends a BNS query to LIDB, including 908 699 1234 as the calling number, and908 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 partyaccepts 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.

LIDB

EO EO

SCP

1

2

4

5

908-758-5678908-699-1234

Smith, John(908) 699 1234

3

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 tothe terminating EO, which contains the name and presentation status for 908 699

1234.

5. Terminating EO processes the CNAM response and displays the callers name on thecalled partys Customer Premises Equipment (CPE).


10/31



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 callers ZIP code.

Pizza

Pizza

SSP

LIDB

SCPAIN

SCP

1

2

3

4

5

6

7

908-699-1234

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 tothe AIN SCP requesting instructions for processing the call.

3. AIN SCP determines that the callers ZIP code is needed for the service.

4. AIN SCP sends a GetData query to LIDB requesting ZIP associated with 908 6991234.

5. LIDB processes the GetData query, encounters no error, and returns the ZIP dataelement associated with 908 699 1234.

6. Based on the LIDB response, the AIN SCP determines that the call should beterminated to 908 758 5678, and sends a message to the SSP to complete the callaccordingly.

7. SSP completes the call to 908 758 5678, which is the closest pizzeria to the callershome.

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 LIDBsupport of ANS-41, wireless service providers can use the protocol that they are familiar with to access


11/31



LIDB for wireless and wireline data. The LIDB ANS-41 interface would save wireless service providersfrom 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 callers name on the wireless subscribers 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 presentationinformation. Depending on the architecture of the wireless service providers network, the network entity

sending the ServiceRequest message could be a Home Location Register (HLR), a Wireless IntelligentNetwork (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, inorder 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. TheModify 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 wouldindicate the outcome of the update. The Modify message could be sent by the wireless service platform,such as a WIN SCP.

LIDBs ANS-41 support may not be limited to these messages. As industry needs change, LIDB couldevolve 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.LIDBs 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 besupported 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 linenumber 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 aline 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 Modifymessage. The response message from LIDB would indicate the outcome of the update.


12/31



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 alongto the LIDB AS. The LIDB AS processes this information and updates the LIDB accordingly. Thisis 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 LIDBdata 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 reportsto 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 andanalyzes 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 LIDBAS 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 theinterface is back up. The LIDB AS would take proper action to synchronize its data with LIDB.

It should be noted that for the LIDB owners data, the source of data is the Service Order. However, forLIDB storage customers, the data is provided by the customer electronically or manually (e.g., via filetransfer or an interactive user interface). This is how wireless service providers enter their data intoLIDB.

2.5 Number PortabilityLIDB 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 trueservice provider information, i.e., Account Owner (AO), associated with each line number. AO is acrucial 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 maynot move from one LIDB to another. Regardless, network routing would ensure that messages are routedto 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 forwireless-wireline number portability, especially to prevent Alternate Billing Service (ABS) fraud. Notethat calling card, collect, and third number charging services are collectively referred to as ABS. TheLIDB CC and BNS query types are used to support ABS.

1This statement is also true for wireline-to-wireline portability, since wireline providers may not offer the same suite of services.


13/31



Scenario 1: Wireless (CNAM) to Wireline (CNAM)

In this scenario, depicted by Figure 4, the end users telephone number (666-777-8888) is ported fromwireless company ABC to wireline company XYZ. Both companies, ABC and XYZ, offer CNAM, but

not ABS.

666-777-8888

Wireless

Company

ABC

LIDBABC

CNAM

Wireline

Company

XYZ

LIDBXYZ

CNAM

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. TheLNP databases (not shown in the figure) would be updated to route all CNAM queries for 666-777-8888to LIDBXYZ, instead of LIDBABC. Because wireline company XYZ does not offer ABS, it should eitherdisable CC and BNS for the 666-777 group, or set the line-level CC and BNS indicators explicitly todenial 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 groupwould be disabled for CC and BNS.

2If routing is done properly, a CC or BNS query should never be routed to XYZs LIDB. However, in case of a routing error, this would help toprevent ABS fraud.


14/31



Scenario 2: Wireless (CNAM) to Wireline (ABS, CNAM)

In this scenario, depicted by Figure 5, the end users telephone number (666-777-8888) is ported fromwireless company ABC to wireline company XYZ. Wireless company ABC offers CNAM, but wireline

company XYZ offers both ABS and CNAM.

666-777-8888

Wireless

Company

ABC

LIDBABC

CNAM

Wireline

Company

XYZ

LIDBXYZ

ABS

CNAM


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 callsto be billed to this number. The LNP databases (not shown in the figure) would be updated to route allCC, BNS, and CNAM queries for 666-777-8888 to LIDBXYZ, while originally, only the CNAM querieswere being routed to LIDBABC.


15/31



Scenario 3: Wireline (ABS, CNAM) to Wireless (CNAM)

In this scenario, depicted by Figure 6, the end users telephone number (555-444-3333) is ported fromwireline company XYZ to wireless company ABC. Wireline company XYZ offers both ABS and

CNAM, but wireless company ABC only offers CNAM.

555-444-3333

Wireless

Company

ABC

LIDBABC

CNAM

Wireline

Company

XYZ

LIDBXYZ

ABS

CNAM


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 LIDBABC. TheLNP databases (not shown in the figure) would be updated to route all CNAM queries for 555-444-3333to LIDBABC, instead of LIDBXYZ. Because wireless company ABC does not offer ABS, it should eitherdisable CC and BNS for the 555-444 group, or set the CC and BNS indicators explicitly to denial in the555-444-333 line record.3 The former approach may not be a good choice if company ABC is sharing the

LIDB with other data storage customers, since all lines under the 555-444 group would be disabled forCC and BNS.

3If routing is done properly, a CC or BNS query should never be routed to ABCs LIDB. However, in case of a routing error, this would help toprevent ABS fraud.


16/31



Scenario 4: Wireline (ABS, CNAM) to Wireless (ABS, CNAM)

In this scenario, depicted by Figure 7, the end users telephone number (555-444-3333) is ported fromwireline company XYZ to wireless company ABC. Both companies offer ABS and CNAM.

555-444-3333

Wireless

Company

ABC

LIDBABC

ABSCNAM

Wireline

Company

XYZ

LIDBXYZ

ABS

CNAM


Wireline (ABS, CNAM) to Wireless (ABS, CNAM)

Similar to Scenario 3, 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 LIDBABC. The LNP databases (not shown in the figure) would be updated to route all CC,BNS, and CNAM queries for 555-444-3333 to LIDBABC, instead of LIDBXYZ. Note that for this scenario,the group processing indicators for CC, BNS should be enabled for the 555-444 group in LIDBABC.


17/31



2.6 Fraud Monitoring

In addition to validation, LIDB supports fraud monitoring capabilities for calling card, collect, and thirdnumber charged calls. A Fraud Monitoring System is attached to LIDB via the Enhanced Expanded

Measurements (EEM) interface. For each CC or BNS query received, LIDB records detailed informationon the query, including:

the date and time the query was processed

the calling, called, and billing numbers of the call

the type of response that is returned (e.g., denied or allowed)

the reason that the call is to be denied

the information that is returned in the response, and

other.

LIDB passes the above information to the Fraud Monitoring System over the EEM interface in almostreal-time (with a maximum delay of up to 2 minutes). The Fraud Monitoring System analyzes these dataand alerts the responsible personnel or systems if suspected fraud is detected.


18/31



3 Use of LIDB for Wireless Services

3.1 Overview

LIDB has evolved to provide data solutions for a multitude of services, both wireline and wireless. LIDB

can store data for not only wireline customers, but also for wireless customers. For example, today,wireless service providers are storing their customers name information in LIDB, in order to support thewireline CNAM service. As the industry changes, LIDB can accommodate such changes by adding newdata elements as needed, including those desired by the emerging wireless services. By storing thewireless customers data in LIDB, wireless service providers can take the advantage of LIDB and save the

HLR/VLR/MSC from heavy storage and processing load.

Both wireline and wireless service providers can access LIDB for their services. By supporting ANS-41,

LIDB would save the wireless network entities from having to be multi-lingual. One set of protocolwould be able to be used to support services, regardless of the information needed or whether theinformation is associated with a wire- or wireless line.

In Section 2, examples were provided to illustrate how LIDB has been used to support wireline services.

This section will focus on the retrieval of LIDB data via an ANS-41 interface to support wireless services.

3.2 Calling Name Presentation (CNAP)

Similar to the CNAM service in the wireline world, CNAP refers to the terminating wireless service thatdisplays the name of the caller on the called wireless handset along with the callers telephone number.In order to provide CNAP service, the wireless network serving the customer needs to retrieve the name

from a network database, if this information is not available locally. If the callers name is stored in aLIDB, the serving wireless network could use the ANS-41 ServiceRequest message to get it from LIDB.

Depending on the architecture of the serving network, the wireless network element that initiates theServiceRequest message could be an HLR, an MSC or a WIN SCP. The following example in Figure 8shows a WIN SCP accessing LIDB for the name information.

CallerLIDB WIN

SCP

1

2

3

4

7

8

9

5

11

VLR

6

LECEO

Home

MSC

HLR

Serving

MSC

10

12

908-699-1234

9086991234Smith, John

Figure 8. CNAP Call Flow Example


19/31



1. Caller dials the wireless customers mobile phone number.

2. LEC EO routes the call to the wireless customers Home MSC.

3. Home MSC sends a LOCREQ to the mobiles HLR.

4. HLR sends a ROUTREQ to the VLR where the mobile is registered.

5. VLR sends a routreq to the HLR including the Temporary Location DirectoryNumber (TLDN) assigned to the mobile.

6. HLR sends a locreq to the Home MSC including information to route the call.

7. Home MSC sets up a connection to the Serving MSC.

8. Serving MSC detects a Terminating_Resource_Available trigger and sends aFAVAIL to the WIN SCP including the mobiles identity and the calling numberinformation.

9. WIN SCP determines that the customer has CNAP active, and that it needs to retrievethe callers name from an external database. It sends a SERVREQ to the LIDB that

stores the callers name information.

10. LIDB sends a servreq to the WIN SCP containing the callers name information.

11. WIN SCP sends a favail to the Serving MSC including the text to present to themobile in the DISPTEXT parameter.

12. The mobile is alerted. Included in the alert is the text in the DISPTEXT parameter,

e.g., the callers number and name.

3.3 Third Party Charging

Third Party Charging allows the charges for a call to or from a wireless customer to be billed to a thirdparty. Similar to a third number charged call in the wireline world, the billing information needs to bevalidated before allowing the call to go through. LIDB supports the Third Number Charging service forwireline today. It could also be used to support the wireless Third Party Charging service. The followingcall flow example in Figure 9 shows a WIN SCP accessing LIDB to retrieve the Third Party Charging

information for the line via the Search message.


20/31



LIDB

WINSCP

1

8

2,4

6

3,7

LEC

EO

HLR

5

908-699-1234

Home

MSC

9087585678Accept

555-444-3333

Figure 9. Third Party Charging Call Flow Example

1. The wireless customer has Third Party Charging active and dials the called partysnumber (e.g., 908-699-1234).

2. Home MSC detects an Origination_Attempt trigger and sends a ORREQ to the

mobiles WIN SCP.

3. WIN SCP determines appropriate treatment based on the information received andsends this in a featreq, instructing the Home MSC to collect billing information from

the caller.

4. Home MSC collects billing information from the caller and send an ANLYZD to theWIN SCP including the billing number (e.g., 908-758-5678) for the call.

5. WIN SCP determines that the billing number needs to be validated and sends aSEARCH to LIDB, which stores the Third Party Charging information for 908-758-5678.

6. LIDB sends a search to the WIN SCP including the Third Party Charging information

for 908-758-5678.

7. WIN SCP determines the call is allowed based on information received from LIDB,

and sends an anlyzd to the Home MSC. (For simplicity, this example assumes thethird party accepts charges without verification.)

8. Home MSC routes the call to the called party (e.g., 908-699-1234).

3.4 User Selective Call Forwarding (USCF)

USCF provides the capability to selectively redirect unanswered calls to alternate destinations, such as the

wireless customers voice mail or another telephone number. The USCF service discussed in this sectionis also known as Network Fixed or Network Variable USCF, which stores the forwarding information in


21/31



the network, as opposed to in the wireless handset. As a nationally accessible database, LIDB can storethis call forwarding information. The serving wireless network could query LIDB for the forward-to

number. Two ANS-41 messages could be used for LIDB to support this service. The Search messagecould be used to retrieve the forward-to number; the Modify message could be used to change the

forward-to number when requested by the customer. Figure 10 shows an example of a WIN SCPaccessing LIDB for the forward-to number.

LIDB

1

2

9

3

7

4

VLR

LECEO

Home

MSC

HLRServing

MSC

6

LEC

EO10

908-699-1234

5

8

Figure 10. USCF Call Flow Example

1. Caller dials the wireless customers mobile phone number.2. LEC EO routes the call to the mobiles Home MSC.

3. Home MSC sets up a connection to the Serving MSC (for simplicity, messages

exchanged to obtain the routing information about the mobile are omitted).

4. Serving MSC alerts the mobile but there is no answer. Serving MSC determines thatthe wireless customer has USCF active, and sends a REDREQ to Home MSC.

5. Home MSC sends a TRANUMREQ to HLR.

6. HLR determines that the forward-to number is needed and sends a SEARCH to LIDB

that stores the forward-to number (e.g., 908 699-1234).

7. LIDB sends a search to the HLR including the forward-to number.

8. HLR sends a tranumreq to the Home MSC including the number to redirect the callto.

9. Home MSC sends a redreq to Serving MSC and releases the connection.

10. Home MSC routes the call to the forward-to number (908 699-1234).


22/31



3.5 Commercial Location Based Services (LBS)

With the support of Location Services, the position of a wireless customer would be available from theMobile Position Center (MPC). This position information can be used not only for emergency services,e.g., E911, but also for commercial LBS that provide customized services to the wireless customer basedon his/her location. For example, whether or not a customer is entitled to enhanced Directory Assistant

(DA) services would be based on whether or not he or she is in New York City. For these types ofservices, LIDB can be used to store the customers service information or profile. The ANS-41 Searchand Modify messages could also be used for LIDB to support this service. Figure 11 shows an exampleof LIDB being accessed for the location based enhanced DA service profile.

LIDB

1

2

34

ThirdPartyOSS

VLR

Serving

MSC

MPC

6

5

7

Figure 11. Commercial LBS Call Flow Example

1. Wireless customer dials 411.

2. Serving MSC connects the caller to Third Party OSS that provides enhanced DA service.

3. Third Party OSS sends a SEARCH to LIDB that stores the wireless customers enhanced DA

service information.

4. LIDB sends a search to the Third Party OSS with the customers enhanced DA information.

5. Third Party OSS determines that the mobiles current location is needed to provideappropriate treatment based on information received from LIDB. It sends an ISPOSREP to

the MPC.

6. MPC obtains the mobile position information and includes it in an isposreq to the Third PartyOSS.

7. Third Party OSS applies proper treatment to the call based on information received fromLIDB and MPC.


23/31



3.6 Other

Roaming Database Verification (RDV) refers to the capability to verify whether the wireless customershome and serving systems have a business agreement before services are provided to the customer.Currently, Roaming Agreement Tables are maintained at the MSCs to ensure that roamers are givenservice only if they are entitled to it. These tables have grown enormously as competitions intensify.

Processing these tables has increased the load on the MSCs. Maintaining these tables is anotheradministrative disaster. A centralized repository of this information is becoming more desirable.

LIDB supports a capability called ABS Denial, which has many similarities to the RDV feature. ABS

Denial allows LIDB to deny an ABS call based on whether or not the company serving the call and thecompany owning the line have a business agreement. The ABS Denial capability could be enhanced tosupport RDV. Detailed implications of supporting RDV in LIDB are under investigation.


24/31


25/31



Appendix A: LIDB Data Elements

Account Owner

Additional Originating Third Number Billing Indicator

Additional Originating Credit Card Indicator

Additional Originating Special BNS Indicator

Additional Originating Sent-Paid Indicator

Additional Originating Billing/Services Spare Indicator

Alphanumeric String

Automatic Code Gapping Indicators

Billing Service Provider

Calling Card Account Number Service Denial Indicator

Calling Card Subaccount NumberCalled Number Exclusion

Collect Acceptance Indicator

1. Verify all Collect calls to this number

2. No Collect calls should be billed to this number at customers request

3. No Collect calls should be billed to this number

4. Accept all Collect calls to this number without verification

5. Accept all intraLATA Collect calls to this number without verification; reject interLATA Collect

6. Accept all intraLATA Collect calls to this number without verification; verify interLATA Collect

7. Verify all Collect calls to this number - with operator

8. Accept all intraLATA Collect Calls to this number without verification; verify interLATA Collect

calls - with operator

Company ID

Disallowed Card Issuer Codes

Diversion Routing Number


26/31



Foreign Language Indicator

Spanish

French

Italian

Mandarin

Tagalog

Polish

Korean

Vietnamese

Portuguese

Japanese

Greek

ArabicHindi (Urdu)

Russian

Yiddish

Thai (Laotian)

Persian

French Creole

Armenian

Navajo

Hungarian

Hebrew

Dutch

Mon-Khmer

Ukranian

Czech

Pennsylvania Dutch

Miao (Hmong)

NorwegianSlovak

Swedish

Serbo-Croatian

Kru

Rumanian

Lithuanian

Finnish

Panjabi

Formosan

Croatian

Turkish

Ilocano

Bengali

Danish

Syriac

Samoan

MalaysianCajun

Amharic

Cantonese

Generic Name

Generic Name Privacy Indicator

Intercept Indicator

LIDB-Specific Called Number Blocking Indicator

N-Number Card Called Number Masks

Originating Collect Billing Indicator

1. Allowed from this line

2. Allowed from this line for domestic calls only

3. Not allowed from this line

Originating Third Number Billing Indicator




4. Allowed from this line with operator verification

5. Allowed from this line with operator or automated verification


27/31



Originating Local, Non-Toll Call Indicator



Originating Credit Card Indicator




4. Card Issuer restrictions associated with line for local calls only

5. Card Issuer restrictions associated with line for intraLATA, non-local calls only

6. Card Issuer restrictions associated with this line

7. Non-domestic calls not allowed from this line and Card Issuer restrictions for local calls only

8. Non-domestic calls not allowed from this line and Card Issuer restrictions for intraLATA, non-

local calls only

9. Non-domestic calls not allowed from this line and Card Issuer restrictions associated with thisline

Originating Free DA Indicator



Originating Special BNS Indicator



Originating Sent-Paid Indicator



3. Allowed from this line for intraLATA calls only, due to non-payment

4. Allowed from this line for intraLATA calls only, at customer request


Originating DACC Indicator

1. Allowed from this line (for toll and non-toll calls)

2. Not allowed from this line (for toll and non-toll calls)3. Allowed from this line with billing restrictions (for toll and non-toll class)

4. Allowed from this line for local, non-toll calls only

5. Allowed with alternate billing restrictions only/no sent-paid allowed

Originating Billing/Services Spare Indicator

Originating IC


28/31



Originating INC

Originating IC Indicators

PIN

PIN Restriction Indicator

PIN Service Denial Indicator

PIN Usage Category

RAO

Record Status Indicator

Referral Number

Service Or Equipment Indicator

POTS Line

LEC Public Standard Interface Postpay

Overtime

POTS Line Residential Message Rate 1

POTS Line Residential Message Rate 2

LEC Semi-Public

POTS Line Business flat rate

POTS Line Business Message Rate 1

Coinless (non-Independent Payphone

Provider [IPP])

Coinless (IPP)

LEC Prepaid Telecommunication CardStation

POTS Line Business Message Rate 2

LEC Public Standard Interface PrepayOvertime

LEC Public Alternate Interface

POTS Line Residential flat rate

Voice Quote w/o tax

Voice Quote with tax

IPP Standard Interface

IPP Alternate Interface

Hospital

Prison (non-IPP)

Auto quote w/o tax

Auto quote with tax

Dormitory Line

Centrex Line

PBX LinePrison (IPP)

WATS Line

Cellular

Pager

Personal Communications System (PCS)

Feature Group A

Mobile

LEC Public Special Billing Postpay

Overtime

LEC Public Special Billing PrepayOvertime

Public Incompatible Network Interface

Cellular Rate 1

Cellular Rate 2

POTS Line Business Single Line

POTS Line Business Multi-Line

Public - Postpay


29/31



Third Number Acceptance Indicator

1. Always accept Third Number Billing to this number

2. Verify Third Number Billing to this number

3. Always accept IntraLATA Third Number Billing to this number; reject InterLATA

4. Verify all IntraLATA Third Number Billing to this number; reject InterLATA

5. No Third Number Billing should be billed to this number at customers request

6. No Third Number Billing should be billed to this number

7. Verify Third Number Billing to this number - with operator

8. Verify all IntraLATA Third Number Billing to this number - with operator; reject InterLATA

Treatment Indicator

True Billing Number

Wireless Services Originating Indicator (WSOI)

Wireless Services Terminating Indicator (WSTI)ZIP


30/31



Appendix B: Acronyms

ABS Alternate Billing Services

AIN Advanced Intelligent Network

ANS American National Standards

AO Account OwnerAS Administrative System

BNS Billed Number Screening

BSP Billing Service Provider

CC Calling Card

CCS Common Channel Signaling

CCSAN Calling Card Subaccount Number

CCSNIS Common Channel Signaling Network Interface Specification

CIC Carrier Identification Code

CNAM Calling Name Delivery Service

CNAP Calling Name Presentation

CPE Customer Premises Equipment

CPN Calling Party Number

CPP Calling Party Pays

CSDI Calling Card Account Number (CCAN) Service Denial Indicator

DA Directory Assistance

DACC Directory Assistance Call Completion

DPC Destination Point Code

DRN Diversion Routing Number

EEM Enhanced Expanded Measurements

EO End Office

GIF Geographic Information Function

GN Generic Name

GR Generic RequirementsGTT Global Title Translation

HLR Home Location Register

IC Interexchange Carrier

ILP IntraLATA Toll Presubscription

IN Intelligent Network

INC International Carrier

IP Internet Protocol

IPP Independent Pay Phone Provider

IS Interim Standards

ISDN Integrated Services Digital Network

ISP Internet Service Provider

ISUP ISDN User PartITU International Telecommunications Union

LATA Local Access and Transport Area

LBS Location Based Services

LDAP Lightweight Directory Access Protocol

LEC Local Exchange Carrier

LIDB Line Information Database

LIDB AS LIDB Administrative System


31/31


LNP Local Number Portability

LSP Local Service Provider

MPC Mobile Position Center

MSC Mobile Switching Center

MTP Message Transfer Part

NPA Numbering Plan Area

NPAC Number Portability Administration Center

NPDB Network Portability Database

OLNS Originating Line Number Screening

OPC Originating Point Code

OSS Operator Services System

OSSGR Operator Services Systems Generic Requirements

PDE Position Determining Element

PIN Personal Identification Number

PRI PIN Restriction Indicator

PSDI PIN Service Denial Indicator

QO Query Originator

RAO Revenue Accounting OfficeRDV Roaming Database Verification

SCCP Signaling Connection Control Part

SCP Service Control Point

SOE Service or Equipment Indicator

SOP Service Order Process

SS7 Signaling System Number 7

SSN Subsystem Number

SSP Service Switching Point

STP Signaling Transfer Point

TCAP Transaction Capabilities Application Part

TCP/IP Transmission Control Protocol / Internet Protocol

TLDN Temporary Location Directory NumberTNA Third Number Acceptance Indicator

TT Translation Type

USCF User Selective Call Forwarding

VLR Visitor Location Register

WSI Wireless Subscriber Information

WSOI Wireless Services Originating Indicator

WSTI Wireless Services Terminating Indicator

Documents

07a FYI LIDB_WhitePaper[Telcordia]