Esn Vs. Meid

[HetalDP 947]

MEID = 56 Bit / 14 Character Hex (All New LG above VX-8300 is using this)

ESN = 32 Bit / 8 Character Hex (Old Handset uses)

pESN as a solution?

pESN presents the option for an MEID-equipped device to exist on a currently deployed CDMA network (e.g., a network conforming to IS-2000 Release 0 or IS-2000 Release A). Like a true ESN, a pESN is a 32-bit number. A pESN uses an eight-bit manufacturer ID code field that, by definition, is set to a fixed value of 0×80. In other words, one of the eight-bit manufacturer ID codes (0×80) from the overall ESN space is now reserved to indicate that a pESN is in use. The remaining 24 bits of a pESN are derived from the MEID programmed into the device. The least significant 24 bits of an SHA-1 digest[1] of the device's MEID are used to populate the lower 24 bits of the pESN (Figure 2).

Once a pESN is derived, an MEID-equipped device can use that pESN in any scenario where a true ESN would have been used, including over-the-air messaging sent to a network. Conversely, the CDMA network can use this same pESN to address messaging to the device. Because pESN is compatible with the existing structure of true ESNs, no changes are required to the currently deployed CDMA air interface.

Use of pESNs is unfortunately not without its problems, though. Since all pESNs use the manufacturer ID code of 0×80, there are only a little more than 16 million unique pESN values. This ensures that there will almost certainly be multiple devices deriving the same pESN. In a CDMA network, this creates the possibility of at least two problems:

ESNs have been a predominant method used by a network to address messaging to a mobile device. If multiple devices are operating with the same pESN, there is a chance that more than one of these devices might receive a mobile-directed message and respond to it.

In all CDMA networks deployed to date, a device's ESN is used to derive a public long code mask (PLCM). The PLCM is the coding used to separate multiple users transmitting reverse dedicated channels on the same frequency at the same time. Again, if multiple devices are operating with the same pESN, they would also derive the same PLCM, and if using reverse dedicated channels at the same time, there is a good chance the network will not be able to demodulate their reverse traffic. Of course, the chance of a collision is slim: a collision would only occur when two mobiles with the same pESN transmitted at the same time to the same base station. Statistically, though, some of those calls will be emergency calls, making this an unacceptable risk.

CDMA air interface technology already offers a solution to the first problem. While ESN addressing is one option available to networks, other options also exist. For example, by addressing messages with ESN plus international mobile station identifiers (IMSI), a network can ensure that no more than one mobile device will match a message's addressing fields.

The second problem, however, cannot be solved with existing CDMA deployments. To that end, a group of leading CDMA industry participants converged last February on a proposed solution to the PLCM collision problem. This proposed solution was summarized in CDG reference document 107, published in March 2005, and has subsequently undergone minor modifications. As of this article's writing, a final air interface definition for a proposed solution was on the verge of publication as 3GPP2 C.S0072 mobile station equipment identifier (MEID) support for cdma2000 spread spectrum systems, also to be known as TIA-1082.

CDMA/3GPP2 MEID to pESN Conversion tool

You may or may not be aware that the CDMA/3GPP2 side of the mobile world is changing its mobile handset identifier from an Electronic Serial

Number (ESN) to a Mobile Equipment Identifier (MEID) due to having sold far too many phones :-) (...and it was only 24 bits).

MEIDs are effectively the same as GSM IMEIs but use a different range of manufacturer codes and a different check-digit calculation. See 3GPP2

X.S0008 if you want to see more/are a masochist.

Why is this on the Erlang list? Well I've implemented a small page in Yaws/Erlang that allows validation of the check-digits and the

calculation of the psuedo-ESN (used for backward compatibility). It was a pleasant experience to implement the SHA-1 hashing (using crypto) and

the 2x LUHN checkdigit calculations. I must say that converting standards specifications into an Erlang implementation is far nicer than

doing it in C/C++/Java.

Some examples:

http://www.neolineas.com/pesn.yaws?meid=AF0123450ABCDE - 3GPP2 example

http://www.neolineas.com/pesn.yaws?meid=A00000000023299

Some helpful hints for the archive:

* http://schemecookbook.org/Erlang/NumberConvOctHex shows a nice way of converting hex numbers in ASCII to usable integers (credit:

BrentAFulgham <http://schemecookbook.org/Main/BrentAFulgham>)

* Using lists:flatten(string:tokens(String, " ")) is an easy, brute force, way to kill user formatting of input numbers (assuming formatting

is irrelevant)

* io_lib:format outputs unflattened lists when padding which will cause grief if you expect a flat "string" in later processing.

Edited March 13, 2007 by hpnasik

[just5fun 2]

The page 'http://www.neolineas.com/pesn.yaws?meid=AF0123450ABCDE' has been removed due to some sort of copywright issue...

FYI: The conversion scheme is pretty simple as long as you can do SHA-1 Hash Calculations...

[petar 15]

this post of hetal is prety old. He has left CDMA & moved on to GSM...

[just5fun 2]

this post of hetal is prety old. He has left CDMA & moved on to GSM...

That was your 666th post! I feel special that you used it on me. Seriously though, I'm new here and was just looking through the threads. I didn't even realize it was such an old thread... Sorry about that.