Mobile equipment identifier

Commonly, opening the phone's dialler and typing *#06# will display its MEID. ==Administration==

The separation between international mobile equipment identifiers (IMEIs) used by GSM/UMTS and MEIDs is based on the number ranges. There are two administrators: the global decimal administrator (GDA) for IMEIs and the global hexadecimal administrator (GHA). As of August 2006, the TIA acts as the GHA to assign MEID code prefixes (0xA0 and up), and the GSM Association acts as the global decimal administrator. TIA also allocates IMEI codes, specifically destined for dual-technology phones, out of the RR=99 range. This range is commonly (but not exclusively) used for LTE-capable handsets with CDMA support. Other administrators working under GSMA may also allocate any IMEI for use in dual-technology phones. When allocating an IMEI in dual-technology phones, the 14-digit hexadecimal MEID is the first 14 decimal digits of the IMEI. For instance, Apple and LG normally use RR=35 which is allocated by BABT while Chinese brands such as Huawei use two RR=86 IMEIs allocated by TAF for 3GPP networks alongside a distinct RR=99 decimal or RR=A0 hexadecimal MEID for 3GPP2 networks. Every IMEI can also be used as an MEID in CDMA devices (as well as in single-mode devices designed with GSM or other 3GPP protocols) but MEIDs can also contain hexadecimal digits and this MEID variant cannot be used as an IMEI. ==Display formats==

There are two standard formats for MEIDs, and both can include an optional check-digit. This is defined by 3GPP2 standard X.S0008. The hexadecimal form is specified to be 14 digits grouped together and applies whether all digits are in the decimal range or whether some are in the range 'A'–'F'. In the first case, all digits are in the range '0'–'9', the check-digit is calculated using the normal base 10 Luhn algorithm, but if at least one digit is in the range 'A'–'F' this check digit algorithm uses base 16 arithmetic. The check-digit is never transmitted or stored. It is intended to detect most (but not all) input errors, it is not intended to be a checksum or CRC to detect transmission errors. Consequently, it may be printed on phones or their packaging in case of manual entry of an MEID (e.g. because there is no bar code or the bar code is unreadable). The decimal form is specified to be 18 digits grouped in a 5–5–4–4 pattern and is calculated by converting the manufacturer code portion (32 bits) to decimal and padding on the left with '0' digits to 10 digits and separately converting the serial number portion to decimal and padding on the left to 8 digits. A check-digit can be calculated from the 18 digit result using the standard base 10 Luhn algorithm and appended to the end. Note that to produce this form the MEID digits are treated as base 16 numbers even if all of them are in the range '0'–9'. ==pESN conflicts==

Because the pESN is formed by a hash on the MEID there is the potential for hash collisions. These will cause an extremely rare condition known as a 'collision' on a pure ESN-only network as the ESN is used for the calculation of the Public Long Code Mask (PLCM) used for communication with the base-station. Two mobiles using the same pESN within the same base-station area (operating on the same frequency) can result in call setup and page failures. The probability of a collision has been carefully examined. Roughly, it is estimated that even on a heavily loaded network the frequency of this situation is closer to 1 out of 1 million calls than to 1 out of 100 000. 3GPP2 specification C.S0072 provides a solution to this problem by allowing the PLCM to be established by the base station. It is easy for the base station to ensure that all PLCM codes are unique when this is done. This specification also allows the PLCM to be based on the MEID or IMSI. A different problem occurs when ESN codes are stored in a database (such as for OTASP). In this situation, the risk of at least two phones having the same pseudo-ESN can be calculated using the birthday paradox and works out to about a 50 per cent probability in a database with 4,800 pseudo-ESN entries. 3GPP2 specifications C.S0016 (Revision C or higher) and C.S0066 have been modified to allow the replacement MEID identifier to be transmitted, resolving this problem. Another problem is that messages delivered on the forward paging channel using the pESN as an address could be delivered to multiple mobiles seemingly randomly. This problem can be avoided by using mobile identification number (MIN) or IMSI based addressing instead. ==Code to convert==

This short Python script will convert an MEID to a pESN. import hashlib meid = input("Enter a MEID: ").upper() bytes = bytearray.fromhex(meid) s = hashlib.sha1(bytes) • Decode the hex MEID (convert it to binary!) pesn = "80" + s.hexdigest()[-6:].upper() • Put the last 6 digits of the hash after 80 print("pESN:", pesn) The CDG also provides a JavaScript calculator with more conversion options. This C# method will convert an MEID from HEX to DEC format (or return empty for an invalid MEID HEX value) public static string HexToDecimal(string input) { if (input.Length != 14) { return ""; // Not a valid hex MEID. } string hexPart1 = input.Substring(0, 8); string hexPart2 = input.Substring(8, 6); try { string decPart1 = int.Parse(hexPart1, System.Globalization.NumberStyles.HexNumber).ToString().PadLeft(10, '0'); string decPart2 = int.Parse(hexPart2, System.Globalization.NumberStyles.HexNumber).ToString().PadLeft(8, '0'); return decPart1 + decPart2; } catch (System.FormatException ex) { return ""; // Hex parse failed, not a valid hex MEID. } } ==References==