Index of /projects/meif_protocol

[ICO]NameLast modifiedSizeDescription

[DIR]Parent Directory  -  
[DIR]utils/21-Aug-2013 22:39 -  
[TXT]style.css21-Aug-2013 22:39 89  
[DIR]research/21-Aug-2013 22:39 -  
[TXT]README.html21-Aug-2013 22:39 13K 
[TXT]LICENSE.html21-Aug-2013 22:39 59K 
[TXT]GLOSSARY.html21-Aug-2013 22:39 3.4K 

Nokia MEIF Protocol Reverse Engineering

Nokia MEIF Protocol Reverse Engineering

Please read LICENSE{.html,md}

Source Code © Copyright 2013 TJ <>
Program code and scripts licensed under the GNU General Public License version 3.0

Documentation © Copyright 2013 TJ <>
Non-source code text and supporting data (visual, audible, formatting) is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License.

Site Map

Utility scripts {utils/}

Research {research/}

This project is aimed at developers, hackers and others wishing to understand the proprietary Nokia Measurement Engine - Positioning Engine Interface protocol (known as ME-PE I/F or MEIF) being used in Broadcom and other manufacturers Geo-Location chipsets. The Nokia "AGPS Measurement Engine Interface Specification" document is confidential and only released by Nokia under a no-financial-cost Non-Disclosure Agreement (NDA). The Internet Archive's WayBack machine has a copy of the original 2007 MEIF overview published by Nokia. Nokia: please publish the specification freely.

This project tracks the research, resources, references and tools created to analyse the protocol. The output will be an application programming interface (API) specification that is sufficient for other open source programmers to write a working MEIF support library.

Those involved in this reverse engineering project should not involve themselves in writing code that implements the API specification in order to maintain a clean-room implementation.

FSF Replicant project

I heard about the Free Software Foundation's Replicant project looking for donations and developers in late July 2013 and, having previously suffered brain-ache due to closed-source device drivers (HTC Bravo, HTC Vision, Nvidia Tegra 2 in Notion Ink Adam) I decided to join in and help work towards the project's objective of a totally Free operating system derived from the Google Android 'Open Source' Project (AOSP).

Replicant's aim is to replace the many closed-source binary blobs in most Android-based devices with real open-source alternatives. This is a major challenge since most of those binary blobs are drivers for hardware devices which rarely have openly published technical documentation sufficient for open source developers to create alternative implementations. This results in users being unable to easily upgrade their devices with security fixes and new features when their device manufacturer or network operator doesn't provide those updates.

It also means that alternative operating systems installed on those devices must use closed-source binary blobs with copyright restrictions that prevent or hamper re-distribution, and that alternative operating systems that continue to add and improve features that change existing device interfaces risk losing key functionality. This is particularly problematic for 3D-accelerated GPU drivers, camera drivers, and GNSS receiver drivers.

I was made aware of the long-standing lack of understanding of the MEIF protocol on several Samsung devices and decided it was something I am well-equipped to reverse engineer and could make a contribution, not just to the Replicant project but, to the wider open-source development community for Android-based devices and beyond.

Current, experimental, and future Global Navigation Satellite Systems (GNSS)

The GNSS receiver is able to receive signals from one or more of the satellite constellations operated by nation states or regional organisations.

Why use the MEIF binary protocol when the text-based NMEA-0183 is easy to parse?

When the USA's NAVSTAR GPS was the only geo-location service available and GPS receivers were mostly discrete devices it made sense for the receiver to use a simple text-based protocol specified by the National Marine Electronics Association (NMEA) to inform its host of the calculated time and position. This data was easily interpreted by humans too if they cared to manually read it. As host devices became more sophisticated Application Programming Interface (API) libraries and applications came to rely upon parsing NMEA-0183 text strings.

As more satellite constellations were launched, and the USA's GPS was no longer the sole service, receivers had to become more complex and include greater processing power to analyse the signals received. The increased power demand was a particular problem for what are often battery-operated devices. Another key issue was the rapid development of geo-location technologies and services demanding greater processing power and rendering existing receiver devices behind the times unless expensive and problematic in-the-field firmware upgrades were provided.

Because Time To First Fix (TTFF) can often be a minute or more Assisted-GPS (A-GPS) was developed. It uses ground-based services to deliver up-to-the-minute accurate ephemeris tables (which describe each satellite's orbit and location) which would be passed to the receiver. This avoids the need for the receiver to wait for each satellite to send its own ephemeris table - something that can take several minutes.

MEIF is a good solution to the problem of growing complexity in receivers and geo-location services; it being kept confidential by Nokia is a bad thing.

Measurement Engine - Positioning Engine Interface

For those reasons Nokia developed the ME-PE interface specification. In essence what it defines is the separation of the receiver signal measurement logic (which tunes and decodes the raw signals from the satellites) from the positioning logic (which combines the data received from all satellites in view, and other sources such as 802.11a/b/g/n access-point locations, cellular telephone towers, etc.) to calculate the current time, position, and velocity).

ME-PE separation means that the receiver silicon can be ultra low-power and does not need upgrading as new satellite constellations are launched. The host device's CPU is responsible for doing the position calculation based on that device's power strategy.

A further significant benefit is that the receiver no longer needs to process ephemeris tables from satellite or A-GPS. Instead, the host device CPU is responsible for both fetching and using the tables.

Using a binary protocol is time and space-efficient. It allows the machines to efficiently perform two-way communication directly without the need for embedding a parser in the receiver to convert human-readable text into machine-readable bits - a further reduction in the complexity of the receiver.

Some so-called smart-phones (I'd prefer to call them Personal Digital Assistants (PDAs) with telephone applications) made by Samsung include Broadcom chipsets. These include a Global Navigation Satellite System (GNSS) receiver that communicates with the host CPU through a serial port using the MEIF protocol. Other manufacturers of mobile devices and GNSS integrated circuits are adopting MEIF too.

Broadcom / Global Locate Library and Samsung GPS daemon

Broadcom provides a Global Locate Library API (GLL) to its chip-set customers which understands the MEIF protocol and talks to the GNSS receiver over a serial communications device - usually a Universal Asynchronous Receiver Transmitter (UART). In the case of Samsung they have incorporated the Broadcom GLL (and other libraries) into their GPS daemon (GPSd) along with other geo-location services such as Location Based Services (LBS) and Assisted GPS (A-GPS) using Secure User Plane Location (SUPL).

The result is a long-running background daemon process that opens the device's serial port and communicates with the GNSS receiver using the MEIF protocol.

Although the binary communication is opaque the Samsung gpsd very kindly writes an extensively detailed debug log to /sdcard/gps/ when logging properties are set in its configuration file.

Broadcom inherited the GPS chip-sets and the GLL when they bought Global Locate Inc., in July 2007. At that time Global Locate designed and sold A-GPS chipsets under the brand name Hammerhead and supported them with their Global Locate Library on the hosts. That software is the basis of the Samsung/Broadcom GNSS driver of today. There is detailed investigation into that history and several very useful source-code and binary driver discoveries have been made.

As a result of the Samsung gpsd logs I began the process of reverse-engineering the MEIF protocol on 29th July 2013.


Check the Research Index for detailed information and investigations.

The initial focus of my research has been into the text strings found in the debug information stored in and alongside the binary code and associated resource files in the regular drivers distributed by Broadcom and device manufacturers with devices, and the text written to the Serial Log (SLOG) facility by the GNSS driver.

Understanding the acronyms and abbreviated words (see GLOSSARY.html) that make up the class, method, function and constant names used in the (source) code has been a big help in understanding the structure of the code and how it relates to the hardware and protocols it implements.

Researching the history of the Broadcom silicon devices and associated driver libraries, including identifying names and email addresses of programmers involved, has led to building probably the best public understanding of the history of the A-GPS chips outside of Broadcom. That knowledge should help to identify associations to other programs and libraries that may provide the break-through we need to understand the MEIF protocol and how to replicate the GNSS drivers completely.


I will publish my reverse engineering code and research work-in-progress and results to my Gitorious account in the MEIF protocol project.