CIBER X2 Migration

Document Sample
CIBER X2 Migration Powered By Docstoc
					         X0 to X2 CIBER Record Type Migration

1   Introduction

1.1 Purpose
This document describes and discusses the migration from the X0 Records to the
X2 Records. This document also discusses the population of the MDN and MSID
fields in the CIBER Record protocol when the MDN and the MSID are the same and
when they are split.

1.2 Referenced Documents
CIBER Protocol

1.3 Acronyms and Abbreviations
 Term                                    Meaning
MDN      Mobile Directory Number
MIN      Mobile Identifier Number
MSID     Mobile Station Identification
MBI      MIN Block Identifier
IMSI     International Mobile Subscriber Identity
CIBER    CIBER’s current version.
ESN      Electronic Serial Number
IMEI     International Mobile Equipment Identifier
MEID     Mobile Equipment IDentifier
MSISDN   Mobile Station International Subscriber Directory Number

1.4 Contributors
Cibernet Corporation, KDDI, Syniverse Technologies, Verisign, Verizon Wireless,
and Qualcomm.

2   Migration from X0 Records to X2 Records
Within this document the reference of the XO Records indicates the usage of the
Type 10, 20, 30, or 50 Records, and the X2 Records indicates the usage of the
Type 22, 32, 42, and 52 Records. There are a number of benefits to migrate from
the X0 Records to the X2 Records. The X2 Records are able to capture more
information than the X0 Records, such as the Caller ID, ESN/IMEI/MEID, Called

                                                                         Page 1 of 6
Country, Serving Country, etc. Also, using the X2 Records reduces the need for
utilizing two separate CIBER records to capture all the necessary call detail. For
example, if an operator used to use a Type 10 and a Type 20 for one call, this
information can now be captured in one Type 22 Record.

In utilizing the X2 Records, an operator can reduce the number of calls to
Customer Care. The information that is captured in the X2 Records can assist
Customer Care with inquiries such as features that were used during the call,
length of the call, the called number, the called place, etc. The X2 Records also
ensures data integrity. With the validation of the records, through the
clearinghouses and billing vendor, an operator is assured that the data captured in
the CIBER Records are accurate. Also, the information from the CIBER Record is
inserted into the subscriber’s bill. Information that can be extracted from the
CIBER Record to the subscriber bill is length of the call, where the call was placed,
and any special features used during the call, i.e. Directory Assistance, Call
Forwarding, Call Waiting, etc.

2.1 Pitfalls for not migrating to the X2 Records
As with the benefits, there are repercussions for not migrating to the X2 Records.
If a carrier decides to continue utilizing the X0 Records, then they will have to pay
their designated clearinghouses an additional charge to convert the X0 Records to
X2 Records. There is also a risk of losing critical information during the conversion
process. For example, if an operator is converting from a Type 20 Record to a
Type 22 Record and that operator is now utilizing MEID (Mobile Identifier) instead
of an ESN (Electronic Serial Number), when converting from a Type 20 to a Type
22 due to the length of the Electronic Serial field, which is only 11 positions, as
oppose to the ESN/IMEI/MEID field, which has 19 positions. During the conversion
process, critical data can be omitted.

Also, with the MSID/MDN is split, there is the potential of populating the MSID or
MDN fields incorrectly, which can cause an operator to bill the wrong subscriber or
customer. For example, if the MDN, the diable number, is populated in the MSID
field, then the record can be sent to the wrong operator, since the MSID indicates
the operator. With these examples, any of these pitfalls can result in loss of
roaming revenue.

2.2 Flash-Cut Date
Cibernet announced in the March 2006 CIBER Update, that as of January 16, 2007,
the designated clearinghouses will have an edit in place that would prohibit the
exchange of the X0 Records. To ensure that there is no loss of revenue or process

                                                                            Page 2 of 6
of records, operators will have to migrate to the X2 Records before the January 16,
2007 flash-cut date.

Carriers can still, currently, exchange the older record types but it is recommended
that the usage of the older record types be communicated to your roaming
partner. It is important to note here that after the January 16, 2007, flash-cut
date, an edit will be in place preventing the exchange of the older record types.

If an operator still has the need to exchange the older record types after the flash-
cut date, then they will have to contact their respective clearinghouse and request
that they bypass the edit.

3   Introduction of Wireless Local Number Portability (LNP)
Cibernet introduced the X2 record types in 1999 in response to the United States’
Wireless Number Portability (WNP) initiative. With WNP, a wireless consumer has
the ability to change service providers and keep the same phone number.

Previously the MIN was tied to a specific carrier, and served as both the dialable
number and the network registration and call processing number. To support
WLNP, the MIN remained the same and a new number type/space called MDN was
created. Under LNP, the MIN is either the IMSI that can be up to 15-digit long or
the 10-digit MIN. The first 5 or 6 digits of an IMSI or the first 6 digits of a MIN
identifies the carrier that owns that MIN; the MIN is generally not known to the
customer. The MDN value is dialable and can be ported from one carrier to
another. Countries that are currently splitting the MIN and MDN are as follows:
US, Canada, and New Zealand. Although your country might not require LNP, if
your subscribers are roaming in areas that require LNP, then your billing systems
must be able to handle LNP.

The MSID field is required to be populated because this field is used by the
clearinghouse to route the records appropriately to the correct home carrier. The
MBI, which is the first 6 digits of a block of 10,000 MINs, is used to uniquely
identify a wireless service provider. Each Serving Operator exchanges Technical
Data Sheets with their roaming partners providing the market and BID information
for each MBI line range. This information is used by each Serving Operator to map
the home BID on the CIBER Record.

This split needs identification and population in the CIBER Record to correctly bill
the subscriber’s home carrier via the MSID, and to identify the correct customer
via the MDN. The MSID identifies the carrier and the MDN identifies the

                                                                             Page 3 of 6
Below, are examples on how to populate an X2 record when the MDN and MIN are
split, and when the MIN and MDN are identical.

3.1 MDN/MIN Split
When a subscriber decides to port his/her number to another service provider, the
customer will now have two numbers: The MIN, which identifies the subscriber’s
service provider, and the MDN, which is the dialable phone number of the

When populating the CIBER Record, if the customer’s MIN is 301-555-4321, and
the MDN is 703-543-5387.

The MSID field will be populated as follows:

                           MSID                  301555432100000

The MSISDN/MDN field will be populated as follows:

                  MSISDN/MDN                     703543538700000

3.2 MDN/MIN Split Not Required
If the subscriber has not ported his/her number, in many cases, within the North
American Numbering Plan, then the MIN and the MDN will be the same. When
populating the CIBER Record, if the customer’s MDN is 301-555-4321, then the
MSID field will be populated as follows:

                           MSID                   30155543210000

The MSISDN/MDN field will be populated as follows:

                   MSISDN/MDN                     30155543210000

                                                                         Page 4 of 6
3.3 MSID Indicator
It is also necessary to populate the MSID Indicator to identify if this field will
contain either an ITU-T E.212 IMSI or a MIN.

4   Relevance
The correct population of the MDN, MSID and MSID Indicator fields within the
CIBER 22 records with the applicable data will ensure successful collection of the
wholesale usage and end-user billing.

4.1 Next Steps
Currently, the CIBER X2 Records allows the MSISDN/MDN field to be zero filled
when the MDN is not available or when number portability isn’t required. Cibernet
is soliciting feedback from operators to remove the edit that allows the
MSISDN/MDN field to be zero filled. Cibernet, along with the CDMA Development
Group will continue to solicit feedback and input from the operators. Once a
consensus is reached, Cibernet will finalize these changes in the January 1, 2007
CIBER Update.

                                                                               Page 5 of 6
                                    Appendix A

                    Test Plan for CIBER X0 to X2 Migration

Below is a test scenario for operators migrating from the X0 Records to the X2
Records. It is recommended that the Serve and Receiving operators test their
systems both as a sender and a receiver.

This scenario is operator to operator:

1. The Serve carrier should inform the Receiving carrier of the migration, at least
   three (3) months prior to the usage of the X2 Records.

2. During the testing process, it is recommended that the Receiving operator
   retain the X0 Records that has been sent for conversion. These records can be
   used for validation and confirmation that the conversion from an X2 Record to
   an X0 Record was done correctly.

3. Once the Serve carrier converts their system to exchange X2 Records, the
   Serve carrier should use the call detail information that was already exchanged
   with the Receiving operator as X0 records.

4. The Serve carrier will then send the X2 Records to the Receiving carrier via

5. The Receiving carrier will then compare the X0 and X2 Records for any
   discrepancies between the records.

                                                                           Page 6 of 6

Shared By: