Hoe We een Offline-naar-Cloud AI-Relay Bouwden met Bluetooth en GPT-4o

In streng beveiligde enterprise-omgevingen-zoals financiële handelsvloeren, gevoelige R&D-laboratoria en defensiegerelateerde locaties-is het werkstations vaak verboden om verbinding te maken met het openbare internet. Hoewel deze "air-gapping" of strikte netwerksegmentatie het risico op datalekken minimaliseert, maakt het moderne cloud-gehoste Large Language Models (LLM's) volledig ontoegankelijk. Engineers en analisten kunnen hierdoor geen gebruikmaken van tools zoals OpenAI's GPT-4o, wat de productiviteit belemmert.

Bij Seven Labs kregen we de taak om dit knelpunt op te lossen voor een klant die opereert in een zeer beperkte netwerkzone. De eis was helder: stel werkstations in een segment zonder internettoegang in staat om veilig cloud-gebaseerde LLM's te bevragen, zonder de firewallregels van het werkstation aan te passen of niet-geautoriseerde hardware zoals wifi-dongles te introduceren.

Onze oplossing was de Bluetooth AI Relay-een brug van edge naar cloud die lokale pc-verzoeken via een op Android gebaseerde RFCOMM-relay naar GPT-4o stuurt, met behulp van standaard Bluetooth-protocollen. Hier is de technische analyse van hoe we dit systeem in productie hebben ontworpen, geïmplementeerd en beveiligd.

---

1. Systeemarchitectuur: De Brug van Edge naar Cloud

De architectuur bestaat uit drie kerncomponenten:

1. De Client (Offline PC): Een lokale service op het werkstation die een loopback-API (bijv. http://localhost:8080/v1/chat/completions) ontsluit die voldoet aan de standaard OpenAI API-specificatie.
2. De Relay (Android Apparaat): Een React Native-applicatie die een gespecialiseerde Kotlin foreground service draait. Het Android-apparaat heeft toegang tot zowel mobiele data (LTE/5G) als Bluetooth, en fungeert als de brug.
3. De Cloud (OpenAI GPT-4o): De doel-LLM-backend die via HTTPS wordt bereikt.

+-------------+                    +-------------------------+                    +-----------------+
|             |     Bluetooth      |   Android Relay Device  |    Mobiele WAN     |                 |
|  Offline PC |  (RFCOMM Socket)   |                         |   (HTTPS Client)   |  OpenAI GPT-4o  |
|  [Client]   |<==================>| [Kotlin Service]        |------------------->|  API Endpoint   |
|             |                    | [React Native Engine]   |                    |                 |
+-------------+                    +-------------------------+                    +-----------------+

Waarom RFCOMM?

Voor het verzenden van ruwe JSON-payloads van prompts en antwoorden hadden we een stroomgeoriënteerd, betrouwbaar transportprotocol nodig. Hoewel Bluetooth Low Energy (BLE) met GATT-attributen uitstekend is voor telemetrie met lage doorvoer, is het ongeschikt voor grotere tekstblokken vanwege de strikte beperkingen van de Maximum Transmission Unit (MTU) en de overhead van pakketfragmentatie.

We kozen voor RFCOMM (Radio Frequency Communication), dat een seriële RS-232-poort emuleert over het L2CAP-protocol. RFCOMM regelt pakketvolgorde, flow control en retransmissie op native niveau. Dit biedt een betrouwbare, stroomgeoriënteerde socket (vergelijkbaar met een java.net.Socket-interface) die de hoge doorvoer aankan die nodig is voor LLM-prompts en -antwoorden.

---

2. De Android RFCOMM-server Implementeren in Kotlin

Om ervoor te zorgen dat de Android-applicatie inkomende Bluetooth-verbindingen betrouwbaar kon afhandelen, hebben we standaard React Native-wrappers omzeild-die vaak kampen met geheugenlekken en geen ondersteuning bieden voor achtergrond-persistentie-en de Bluetooth-stack rechtstreeks in Kotlin geïmplementeerd.

De Bluetooth Server-thread

De Bluetooth-server draait in een eigen thread en luistert op een specifiek Universally Unique Identifier (UUID):

package com.sevenlabs.airelay
 
import android.bluetooth.BluetoothAdapter
import android.bluetooth.BluetoothServerSocket
import android.bluetooth.BluetoothSocket
import android.util.Log
import java.io.IOException
import java.util.UUID
 
class BluetoothServerThread(
    private val adapter: BluetoothAdapter,
    private val onConnectionEstablished: (BluetoothSocket) -> Unit
) : Thread() {
 
    private val serverSocket: BluetoothServerSocket? by lazy(LazyThreadSafetyMode.SYNCHRONIZED) {
        adapter.listenUsingRfcommWithServiceRecord(
            "SevenLabsAIRelay",
            UUID.fromString("4a8b8c2d-9e0f-11ed-a8fc-0242ac120002")
        )
    }
 
    private var shouldKeepListening = true
 
    override fun run() {
        name = "SevenLabs-RFCOMM-Listener"
        Log.i("AIRelay", "RFCOMM Server Socket listening...")
 
        while (shouldKeepListening) {
            val socket: BluetoothSocket = try {
                serverSocket?.accept()
            } catch (e: IOException) {
                Log.e("AIRelay", "Server Socket accept failed", e)
                break
            }
 
            socket?.let {
                Log.i("AIRelay", "Incoming RFCOMM client connection accepted")
                onConnectionEstablished(it)
            }
        }
    }
 
    fun cancel() {
        try {
            shouldKeepListening = false
            serverSocket?.close()
        } catch (e: IOException) {
            Log.e("AIRelay", "Could not close server socket", e)
        }
    }
}

---

3. Persistente Werking: Kotlin Foreground Services & Wake-Lock Beheer

Een van de grootste uitdagingen op moderne Android-versies (Android 12+) is batterij-optimalisatie. Als het scherm van het mobiele apparaat wordt uitgeschakeld of de app wordt geminimaliseerd, brengt het Android-besturingssysteem de CPU in een diepe slaapstand (Doze Mode) en sluit het achtergrond-netwerksockets.

Om een ononderbroken werking te garanderen, heeft Seven Labs twee cruciale mechanismen geïmplementeerd:

1. Kotlin Foreground Service: De RFCOMM-server en de API-client draaien binnen een Android Foreground Service. Hierdoor wordt de app door het systeem herkend als een persistent proces en wordt er een permanente melding in de statusbalk weergegeven.
2. Wake-Locks en Wi-Fi Locks: Het expliciet instrueren van de kernel scheduler om de CPU wakker te houden en de mobiele verbinding actief te houden tijdens een actieve sessie.

De Implementatie van de Foreground Service

Hieronder staat de kern van de foreground service die de thread-levenscyclus en meldingen beheert:

package com.sevenlabs.airelay
 
import android.app.Notification
import android.app.NotificationChannel
import android.app.NotificationManager
import android.app.PendingIntent
import android.app.Service
import android.content.Context
import android.content.Intent
import android.os.Build
import android.os.IBinder
import android.os.PowerManager
import androidx.core.app.NotificationCompat
 
class AIRelayService : Service() {
 
    private var wakeLock: PowerManager.WakeLock? = null
    private var serverThread: BluetoothServerThread? = null
 
    override fun onCreate() {
        super.onCreate()
        acquireWakeLock()
        startForegroundService()
    }
 
    private fun acquireWakeLock() {
        val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
        wakeLock = powerManager.newWakeLock(
            PowerManager.PARTIAL_WAKE_LOCK,
            "SevenLabs::AIRelayWakeLock"
        ).apply {
            acquire(30 * 60 * 1000L) // 30 minuten veiligheidslimiet
        }
    }
 
    private fun startForegroundService() {
        val channelId = "seven_labs_ai_relay"
        val channelName = "AI Relay Foreground Service"
 
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            val channel = NotificationChannel(channelId, channelName, NotificationManager.IMPORTANCE_LOW)
            val manager = getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager
            manager.createNotificationChannel(channel)
        }
 
        val notificationIntent = Intent(this, MainActivity::class.java)
        val pendingIntent = PendingIntent.getActivity(
            this, 0, notificationIntent,
            PendingIntent.FLAG_IMMUTABLE or PendingIntent.FLAG_UPDATE_CURRENT
        )
 
        val notification: Notification = NotificationCompat.Builder(this, channelId)
            .setContentTitle("Seven Labs AI Relay Active")
            .setContentText("Routing Bluetooth RFCOMM data to GPT-4o...")
            .setSmallIcon(R.drawable.ic_notification)
            .setContentIntent(pendingIntent)
            .build()
 
        startForeground(1, notification)
    }
 
    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        // Start listening over Bluetooth
        val adapter = BluetoothAdapter.getDefaultAdapter()
        serverThread = BluetoothServerThread(adapter) { socket ->
            // Route stream data
            ConnectionHandler(socket).start()
        }
        serverThread?.start()
        return START_STICKY
    }
 
    override fun onDestroy() {
        serverThread?.cancel()
        wakeLock?.let {
            if (it.isHeld) it.release()
        }
        super.onDestroy()
    }
 
    override fun onBind(intent: Intent?): IBinder? = null
}

---

4. Structurering van de Payload en het Protocol

Omdat RFCOMM fungeert als een ruwe byte-stream, moesten we een protocol op applicatieniveau definiëren om individuele verzoeken en antwoordpakketten te segmenteren.

We hebben een lichtgewicht message frame-indeling ontworpen:

• Magic Bytes (4 bytes): SLAR (Seven Labs AI Relay) om de herkomst van pakketten te verifiëren.
• Payload Length (4 bytes): Big-endian integer die de exacte grootte van de payload specificeert.
• Payload Type (1 byte): Geeft aan of het pakket ruwe tekst, een SSE (Server-Sent Events) chunk, metadata of een foutcode is.
• Encrypted Payload (Variabel): Met AES-GCM versleutelde JSON-gegevens.

+------------+------------------+--------------+-----------------------+
| Magic (4B) | Length (4B, Int) | Type (1B, B) | Encrypted Payload (N) |
+------------+------------------+--------------+-----------------------+

Wanneer de Client op de offline pc een prompt verstuurt, verpakt de lokale daemon deze in dit frame, verzendt het via de RFCOMM-socket en wacht op antwoordframes.

Aan de kant van de Android Relay leest de Kotlin socket-lezer de lengte, leest het opgegeven aantal bytes, ontsleutelt de payload en stuurt het HTTP-verzoek door naar de OpenAI-API. Om token-streaming te ondersteunen, parseren we de SSE-datachunks die van OpenAI terugkomen, verpakken we deze als SSE Chunk-types en schrijven we ze opeenvolgend terug naar de Bluetooth socket-stream.

---

5. Beveiligingsarchitectuur: Zero-Trust over Bluetooth

Het verzenden van bedrijfsgegevens via Bluetooth brengt beveiligingsrisico's met zich mee. Bluetooth-verbindingen zijn gevoelig voor afluisteren en Man-in-the-Middle (MitM) aanvallen. Om deze relay geschikt te maken voor enterprise-omgevingen, heeft Seven Labs een cryptografische laag op applicatieniveau toegevoegd.

End-to-End Encryptie (E2EE)

Zelfs als de Bluetooth-koppeling (pairing) wordt gecompromitteerd, blijft de payload beveiligd.

1. Key Exchange: Wanneer de offline pc een verbinding initieert, voert deze een Elliptic-Curve Diffie-Hellman (ECDH) sleuteluitwisseling uit over de ruwe Bluetooth-socket met het Android-apparaat.
2. Tijdelijke Sessiesleutel: Beide endpoints leiden een gedeelde symmetrische sleutel (AES-256-GCM) af die uniek is voor die specifieke sessie.
3. Payload Versleuteling: Elke payload in het berichtframe wordt versleuteld met de sessiesleutel, waarbij voor elk frame een initialisatievector (IV) wordt gegenereerd. Dit voorkomt replay-aanvallen en afluisteren.

---

6. Prestaties en Latency Tuning

Onze benchmarks leverden de volgende prestatiestatistieken op in productie:

Metriek	Directe wifi (Controle)	RFCOMM Relay (Zonder Streaming)	RFCOMM Relay (Met SSE Streaming)
Time to First Token (TTFT)	~320ms	~980ms	~410ms
Doorvoer (Tokens/Sec)	65	42	58
Maximale Payload-grootte	Onbeperkt	5 MB	Gestreamd

Doorvoer Optimaliseren

Omdat de bandbreedte van Bluetooth beperkt is in vergelijking met wifi, is het streamen van antwoorden token-voor-token essentieel. Door SSE-chunks rechtstreeks door te sturen naar de client zodra ze binnenkomen van OpenAI, hebben we de waargenomen latentie (TTFT) met meer dan 50% verlaagd.

Daarnaast hebben we Gzip-compressie toegepast op prompts groter dan 20KB, wat de transmissietijd over Bluetooth verkort en knelpunten in de RFCOMM-buffer voorkomt.

---

7. Veelgestelde Vragen voor Bedrijven

Is dit niet in strijd met het air-gapping principe?

Het systeem werkt als een strikte protocol-proxy. Het offline werkstation heeft geen IP-verbinding met het mobiele netwerk, wat algemene internettoegang, side-channel poortscans of reverse-tunneling voorkomt. Alleen correct geformatteerde SLAR-frames op applicatieniveau worden doorgelaten.

Hoe beïnvloedt dit het batterijverbruik van het relay-apparaat?

Het gelijktijdig gebruiken van Bluetooth en mobiele data verbruikt ongeveer 8% batterij per uur bij continu gebruik. Door selectief gebruik te maken van Android PowerManager Wake-Locks-alleen tijdens actieve socket-sessies-hebben we het verbruik geminimaliseerd.

Hoe wordt de token-registratie beheerd?

Alle API-sleutels en verbruiksgegevens worden opgeslagen in de Android Relay-app of opgehaald van een enterprise-sleutelserver. Individuele gebruikers kunnen lokaal op het apparaat worden geauthenticeerd voordat de Diffie-Hellman-sleuteluitwisseling plaatsvindt.

---

Technische SEO-schema & Interne Links

• Trefwoorden: AI Relay, Offline Bluetooth AI, React Native Android, Kotlin foreground service, GPT-4o RFCOMM, secure AI systems.
• Interne Links:
  • Leer meer over onze Diensten voor AI-ontwikkeling op maat en hoe we systemen op maat ontwerpen.
  • Bekijk onze expertise in netwerkbeveiliging via VAPT-audits en penetratietesten.
  • Bekijk ons portfolio met casestudies over Software-ontwikkeling voor enterprises.

---

Bouw Veilige Edge-to-Cloud Systemen met Seven Labs

De combinatie van geavanceerde AI-technologieën en strikte beveiligingsrichtlijnen vereist ervaren systeemarchitecten. Of je nu behoefte hebt aan een offline LLM-implementatie, krachtige edge-computing of veilige IoT-relays: Seven Labs heeft de expertise in huis om passende en veilige oplossingen te ontwerpen en te implementeren.

Neem contact op met het engineeringteam van Seven Labs om de specifieke behoeften van jouw organisatie op het gebied van AI en infrastructuur te bespreken.