iBeacon: vad är det, principen för beaconers funktion och BLE-konfiguration

Vad är iBeacon?

iBeacon — är en positioneringsteknik inomhus utvecklad av Apple och introducerad på WWDC 2013. Till skillnad från GPS, som inte fungerar inomhus, använder iBeacon Bluetooth Low Energy-beacons — små batteridrivna enheter som sänder fasta identifikationspaket. iOS- och Android-enheter tar emot dessa paket och beräknar det ungefärliga avståndet till beacone baserat på signalstyrkan (RSSI).

Historia och utveckling

Protokollet iBeacon blev den första massstandard för BLE-beacons, lanserad av Apple 2013 i iOS 7. Ursprungligen användes tekniken inom detaljhandeln: Apple Store-butiker implementerade iBeacon för att informera kunder om rabatter när de gick in i specifika zoner. Fram till 2025 har iBeacon-infrastrukturen miljontals installerade beacons världen över, även om alternativa protokoll har dykt upp — Eddystone från Google och AltBeacon med öppen källkod.

Användningsområden

iBeacon används i fem huvudsakliga scenarier: navigering inomhus (köpcentrum, flygplatser, museer), kontextuella aviseringar (rabatter vid butiksinträde), automatisering av arbetsprocesser (närvaromarkering), logistik och lagerhantering samt turistguider med automatisk uppspelning av innehåll när man närmar sig ett objekt. Enligt ABI Research (2025) uppskattas marknaden för BLE-beacons till 3,2 miljarder enheter i drift.

Struktur för iBeacon-protokollet och paketformat

iBeacon-paketet — är en Advertising PDU (Protocol Data Unit) som sänds i BLE-reklamkanalen på frekvenserna 2402, 2426 och 2480 MHz. Paketformatet är strikt fastställt och består av fyra fält: Apple iBeacon-prefix (0x4C000215), 16-byte UUID, 2-byte Major- och 2-byte Minor-värden samt 1-byte TX Power för avståndskalibrering. Den totala datastorleken är 30 byte, vilket ryms i en BLE Advertising PDU.

Hierarki för UUID, Major och Minor

iBeacon-identifierare bildar en trelagers hierarki. UUID tilldelas organisationen (t.ex. butikskedja), Major — en specifik butik eller våning, Minor — en specifik punkt i zonen (kassazon, varuavdelning). Denna hierarki gör att appen kan reagera flexibelt på olika kontextnivåer: när man går in i en butik (UUID + Major) kan appen ladda våningskartan och när man närmar sig en specifik avdelning (Minor) visa produktinformation.

TX Power och kalibrering

Fältet TX Power — är referensvärdet för signalnivån (RSSI) på 1 meters avstånd från beacone. När paketet tas emot registrerar enheten den faktiska RSSI och beräknar avståndet enligt formeln: distance = 10^((TX_Power - RSSI) / (10 * n)), där n är miljöns dämpningsfaktor (vanligtvis 2-4). Korrekt kalibrering av TX Power är avgörande för positioneringsnoggrannheten: ett fel på 1 dBm ger en avvikelse på upp till 30% på 5 meters avstånd.

Närhetszoner: Immediate, Near, Far

iOS definierar tre närhetszoner baserat på beräknat avstånd till beacone: Immediate (mindre än 0,5 meter), Near (0,5 till 3 meter) och Far (3 till 30-50 meter beroende på förhållanden). Exakt avstånd rapporteras inte — endast kategori. Detta är avsiktligt: RSSI påverkas av störningar, signalreflektioner och påverkan av människokroppen, så kategorier ger en stabilare positionsbestämning.

Immediate — omedelbar närhet

Immediate — zonen för direkt kontakt, när enheten befinner sig några centimeter från beacone. Används för scenarier som kräver maximal precision: betalning via terminal, öppning av digitalt lås, verifiering vid kontrollpunkt. I Immediate-zonen är RSSI vanligtvis mellan -30 och -60 dBm.

Near — medelavstånd

Zonen Near — iBeacons huvudsakliga arbetszon, som täcker avståndet 0,5 till 3 meter. Används för navigering inomhus — till exempel när man närmar sig en skyltdörr visar appen detaljerad information. I Near-zonen varierar RSSI mellan -60 och -80 dBm vid kalibrering TX Power = -59 dBm.

Far — långt avstånd

Far — maximala detekteringszonen för beaconsignalen. Används för att övervaka inträde i regionen (till exempel inträde i ett köpcentrum). På Far-avstånd är RSSI vanligtvis svagare än -80 dBm och noggrannheten för avståndsbestämning minskar avsevärt. För övervakning av inträde används system-API för region monitoring, inte bestämning av exakt zon.

Regionövervakning på iOS

iBeacon-region — är ett virtuellt område definierat av UUID (och valfritt Major + Minor). iOS tillåter övervakning av upp till 20 regioner samtidigt med CLLocationManager. Vid inträde i en region väcker systemet appen även i bakgrunden eller avslutat tillstånd och skickar en avisering via delegaten locationManager:didEnterRegion. Vid utträde ur regionen anropas locationManager:didExitRegion.

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 — bestämning av exakt zon

För att bestämma zonen (Immediate, Near, Far) används ranging — skanning av beacons i realtid. Till skillnad från övervakning fungerar ranging endast i appens aktiva läge och kräver tillstånd för platsåtkomst. Metoden locationManager:didRangeBeacons:inRegion returnerar en array av CLBeacon med fälten proximity (CLProximity.immediate, .near, .far, .unknown), accuracy (kalibrerat avstånd i meter) och rssi.

func locationManager(
    _ manager: CLLocationManager,
    didRangeBeacons beacons: [CLBeacon],
    in region: CLBeaconRegion
) {
    for beacon in beacons {
        switch beacon.proximity {
        case .immediate:
            print("Omedelbar närhet")
        case .near:
            print("Nära närhet")
        case .far:
            print("Avlägsen närhet")
        default:
            print("Okänd närhet")
        }
    }
}

iBeacon på Android: AltBeacon och plattformsoberoende integration

Android har inte inbyggt stöd för iBeacon eftersom protokollet är en proprietär lösning från Apple. Men med hjälp av tredjepartsbibliotek som AltBeacon från Radius Networks (nu en del av Open Beacon-organisationen) kan utvecklare integrera iBeacon i Android-appar. AltBeacon-biblioteket implementerar skanning av BLE-paket, tolkning av iBeacon-format och emulering av ranging och regionövervakning, liknande 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)

Tolkning av iBeacon-paket på Android

Tolkningsformatet för iBeacon i AltBeacon-biblioteket definieras av strängen layout: „m:2-3=0215” — kontroll av två byte av iBeacon-markören, „i:4-19” — 16-byte UUID, „i:20-21” — Major, „i:22-23” — Minor, „p:24-24” — TX Power. Samma format stöds för Eddystone och andra protokoll, vilket gör AltBeacon till ett universellt bibliotek för arbete med BLE-beacons på Android.

Begränsningar på Android

På Android har arbete med iBeacon tre viktiga begränsningar: bakgrundsskanning begränsas av tillverkare (Xiaomi, Huawei, Samsung dödar ofta bakgrundsprocesser), RSSI-noggrannheten är lägre än på iOS på grund av skillnader i BLE-stackar och för skanning krävs tillståndet ACCESS_FINE_LOCATION från Android 6.0 och BLUETOOTH_SCAN från Android 12.

iBeacon vs Eddystone: jämförelse av beaconprotokoll

Eddystone — öppet BLE-beaconprotokoll från Google, introducerat 2015. Till skillnad från iBeacon stödjer Eddystone fyra typer av paket: Eddystone-UID (fast identifierare), Eddystone-URL (överföring av URL för Physical Web), Eddystone-TLM (beacon-telemetri — batterinivå, temperatur) och Eddystone-EID (krypterad identifierare för skydd mot kloning). Även om Google avslutade utvecklingen av Physical Web 2022 används Eddystone-protokollet fortfarande i företagslösningar.

Val av protokoll för projektet

Valet mellan iBeacon och Eddystone beror på målplattform och användningsscenario. iBeacon föredras för iOS-appar tack vare native-integration med CoreLocation och regionövervakning i bakgrunden. Eddystone är lämpligare för Android-orienterade projekt och Physical Web-scenarier, där beacone överför URL utan att installera en app. För plattformsoberoende projekt används ofta AltBeacon, som stödjer båda protokollen.

Vanliga problem och begränsningar med iBeacon

Vid implementering av iBeacon möter utvecklare en rad begränsningar som måste beaktas i arkitekturdesignfasen. Felaktig hänsyn till dessa faktorer leder till instabil navigering, falska utlösningar och snabbare urladdning av beacon-batterier än beräknat.

Miljöns påverkan på RSSI

Signalnivån RSSI påverkas avsevärt av reflektioner från väggar, metallkonstruktioner, närvaro av människor och andra trådlösa enheter i 2,4 GHz-bandet. Inomhus kan RSSI-spridningen för en enda beacon nå 10-15 dBm per minut, vilket gör avståndsberäkningen inexakt utan användning av filter (utjämning med glidande medelvärde, Kalman-filtrering).

Gräns för regionövervakning

iOS stödjer övervakning av högst 20 regioner samtidigt för en app. För projekt som kräver täckning av stort område (flygplats, arena) är detta otillräckligt. Lösning — dynamisk regionväxling: när man går in i en region aktiveras grannregioner och avlägsna avaktiveras.

Övervakningens svarstid

Fördröjningen mellan inträde i en region och mottagande av avisering kan vara från 1 till 30 sekunder beroende på förhållanden. iOS skannar beacons periodiskt för att spara batteri, så omedelbar reaktion kan inte förväntas. För tidskritiska scenarier (dörröppning vid närmande) rekommenderas Immediate ranging, men det fungerar endast i appens aktiva läge.