iBeacon: What It Is, Beacon Operating Principle and BLE Configuration

What Is iBeacon?

iBeacon is an indoor positioning technology developed by Apple and introduced at WWDC 2013. Unlike GPS, which does not work inside buildings, iBeacon uses Bluetooth Low Energy beacons — small battery-powered devices that transmit fixed identification packets. iOS and Android devices receive these packets and calculate the approximate distance to the beacon based on signal strength (RSSI).

History and Development

The iBeacon protocol was the first mass standard for BLE beacons, launched by Apple in 2013 with iOS 7. Initially, the technology was used in retail: Apple Stores implemented iBeacon to inform customers about discounts when entering specific zones. By 2025, the iBeacon infrastructure includes millions of installed beacons worldwide, although alternative protocols have emerged — Eddystone by Google and AltBeacon with open source code.

Application Areas

iBeacon is used in five main scenarios: indoor navigation (shopping malls, airports, museums), contextual notifications (discounts upon entering a store), workflow automation (attendance tracking), logistics and warehouse management, and tourist guides with automatic content playback when approaching an object. According to ABI Research (2025), the BLE beacon market is estimated at 3.2 billion devices in operation.

iBeacon Protocol Structure and Packet Format

An iBeacon packet is an Advertising PDU (Protocol Data Unit) transmitted on BLE advertising channels at frequencies 2402, 2426, and 2480 MHz. The packet format is strictly fixed and consists of four fields: the Apple iBeacon prefix (0x4C000215), a 16-byte UUID, a 2-byte Major and a 2-byte Minor value, and a 1-byte TX Power for distance calibration. The total data size is 30 bytes, fitting into a single BLE Advertising PDU.

UUID, Major and Minor Hierarchy

iBeacon identifiers form a three-level hierarchy. UUID is assigned to an organization (e.g., a retail chain), Major to a specific store or floor, and Minor to a specific point within the zone (checkout area, product department). This hierarchy allows the app to flexibly respond to different context levels: upon entering a store (UUID + Major), the app can load a floor map, and when approaching a specific department (Minor), show product information.

TX Power and Calibration

The TX Power field is a reference signal strength (RSSI) value at 1 meter distance from the beacon. Upon receiving the packet, the device records the actual RSSI and calculates the distance using the formula: distance = 10^((TX_Power - RSSI) / (10 * n)), where n is the environmental attenuation coefficient (typically 2-4). Proper TX Power calibration is critical for positioning accuracy: a 1 dBm error results in up to 30% inaccuracy at 5 meters distance.

Proximity Zones: Immediate, Near, Far

iOS defines three proximity zones based on the calculated distance to the beacon: Immediate (less than 0.5 meters), Near (0.5 to 3 meters), and Far (3 to 30-50 meters depending on conditions). The exact distance is not disclosed — only the category. This is intentional: RSSI is subject to interference, signal reflections, and the influence of the human body, so categories provide more stable location determination.

Immediate — Direct Proximity

Immediate is the direct contact zone, when the device is within centimeters of the beacon. Used for scenarios requiring maximum accuracy: payment via terminal, opening a digital lock, verification at a checkpoint. In the Immediate zone, RSSI is typically between -30 and -60 dBm.

Near — Medium Distance

The Near zone is the main working range of iBeacon, covering distances from 0.5 to 3 meters. Used for indoor navigation — for example, when approaching a product display, the app shows detailed information. In the Near zone, RSSI ranges from -60 to -80 dBm with TX Power calibration of -59 dBm.

Far — Long Distance

Far is the maximum beacon signal detection zone. Used for monitoring entry into a region (e.g., entering a shopping center). At Far distance, RSSI is typically weaker than -80 dBm, and distance accuracy significantly decreases. For entry monitoring, system API region monitoring is used rather than precise zone determination.

Region Monitoring on iOS

An iBeacon region is a virtual area defined by UUID (and optionally Major + Minor). iOS allows monitoring up to 20 regions simultaneously using CLLocationManager. Upon entering a region, the system wakes the app even in the background or killed state and sends a notification via the delegate locationManager:didEnterRegion. Upon exiting a region, locationManager:didExitRegion is called.

import CoreLocation

let locationManager = CLLocationManager()
let region = CLBeaconRegion(
    uuid: UUID(uuidString: "E2C56DB5-DFFB-48D2-B060-D0F5A71096E0")!,
    identifier: "myBeaconRegion"
)
locationManager.delegate = self
locationManager.requestAlwaysAuthorization()
locationManager.startMonitoring(for: region)

Ranging — Determining the Exact Zone

To determine the zone (Immediate, Near, Far), ranging is used — real-time scanning of beacons. Unlike monitoring, ranging only works in the active app mode and requires location permission. The locationManager:didRangeBeacons:inRegion method returns an array of CLBeacon with proximity fields (CLProximity.immediate, .near, .far, .unknown), accuracy (calibrated distance in meters), and rssi.

func locationManager(
    _ manager: CLLocationManager,
    didRangeBeacons beacons: [CLBeacon],
    in region: CLBeaconRegion
) {
    for beacon in beacons {
        switch beacon.proximity {
        case .immediate:
            print("Immediate proximity")
        case .near:
            print("Near proximity")
        case .far:
            print("Far proximity")
        default:
            print("Unknown proximity")
        }
    }
}

iBeacon on Android: AltBeacon and Cross-Platform Integration

Android does not have built-in iBeacon support, as the protocol is Apple’s proprietary solution. However, using third-party libraries such as AltBeacon from Radius Networks (now part of the Open Beacon organization), developers can integrate iBeacon into Android apps. The AltBeacon library implements BLE packet scanning, iBeacon format parsing, and emulation of ranging and region monitoring similar to the iOS API.

val beaconManager = BeaconManager.getInstanceForApplication(context)
beaconManager.beaconParsers.add(
    BeaconParser().setBeaconLayout(
        "m:2-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"
    )
)
beaconManager.backgroundBetweenScanPeriod = 5000
beaconManager.foregroundScanPeriod = 1100
beaconManager.bind(this)

iBeacon Packet Parsing on Android

The iBeacon parsing format in the AltBeacon library is defined by the layout string: “m:2-3=0215” — checking two bytes of the iBeacon marker, “i:4-19” — 16-byte UUID, “i:20-21” — Major, “i:22-23” — Minor, “p:24-24” — TX Power. The same format is supported for Eddystone and other protocols, making AltBeacon a universal library for working with BLE beacons on Android.

Limitations on Android

On Android, working with iBeacon has three key limitations: background scanning is restricted by manufacturers (Xiaomi, Huawei, Samsung often kill background processes), RSSI accuracy is lower than on iOS due to differences in BLE stacks, and scanning requires ACCESS_FINE_LOCATION permission since Android 6.0 and BLUETOOTH_SCAN since Android 12.

iBeacon vs Eddystone: Beacon Protocol Comparison

Eddystone is an open BLE beacon protocol by Google, introduced in 2015. Unlike iBeacon, Eddystone supports four packet types: Eddystone-UID (fixed identifier), Eddystone-URL (URL transmission for Physical Web), Eddystone-TLM (beacon telemetry — battery level, temperature), and Eddystone-EID (encrypted identifier for clone protection). Although Google discontinued Physical Web development in 2022, the Eddystone protocol continues to be used in enterprise solutions.

Choosing a Protocol for Your Project

The choice between iBeacon and Eddystone depends on the target platform and use case. iBeacon is preferable for iOS apps due to native integration with CoreLocation and background region monitoring. Eddystone is better suited for Android-oriented projects and Physical Web scenarios, where the beacon transmits a URL without installing an app. For cross-platform projects, AltBeacon is often used, supporting both protocols.

Common iBeacon Issues and Limitations

When implementing iBeacon, developers face a number of limitations that must be considered during the architecture design phase. Incorrect consideration of these factors leads to unstable navigation, false triggers, and faster beacon battery drain than estimated.

Environmental Impact on RSSI

The signal level RSSI is subject to significant fluctuations due to reflections from walls, metal structures, the presence of people, and other wireless devices in the 2.4 GHz range. Indoors, RSSI variation for a single beacon can reach 10-15 dBm per minute, making distance calculation inaccurate without using filters (moving average smoothing, Kalman filtering).

Region Monitoring Limit

iOS supports monitoring no more than 20 regions simultaneously per app. For projects requiring large area coverage (airport, stadium), this is insufficient. The solution is to use dynamic region switching: when entering one region, adjacent ones are activated and distant ones are deactivated.

Monitoring Response Time

The delay between entering a region and receiving a notification can range from 1 to 30 seconds depending on conditions. iOS scans beacons periodically to save battery, so instant response should not be expected. For time-critical scenarios (door opening upon approach), Immediate ranging is recommended, but it only works in the active app mode.