MTU sa BLE: ano ito, laki ng packet at negosasyon

Ano ang MTU sa BLE?

Maximum Transmission Unit (MTU) sa konteksto ng BLE — ay ang maximum na laki ng Application Protocol Data Unit (APDU) na maaaring matanggap ng isang device sa isang GATT request. Ang MTU ay tinutukoy sa antas ng ATT (Attribute Protocol) at kasama ang ATT header (1 byte) + kapaki-pakinabang na data. Bilang default, lahat ng BLE device ay sumusuporta sa MTU na 23 bytes (23 = 1 byte ATT header + 22 bytes data).

Ang MTU ay hindi pisikal na limitasyon ng radio channel, kundi isang kasunduan sa pagitan ng mga device sa antas ng GATT. Ang pisikal na laki ng BLE packet sa Link Layer ay maaaring mas malaki (hanggang 27 bytes sa BLE 4.0, hanggang 257 bytes sa BLE 5.0 na may Data Length Extension), ngunit ang GATT layer ay naglilimita kung gaano karaming data ang naililipat sa isang transaction. Ang Data Length Extension (DLE) — ay isang hiwalay na mekanismo sa Link Layer na nagpapalaki ng pisikal na packet hanggang 251 bytes at dapat na hiwalay na negosasyon.

Pagkakaiba sa pagitan ng MTU at DLE: ATT MTU — kung gaano karaming data ang naililipat sa isang GATT request, DLE — kung gaano karaming data ang kasya sa isang Link Layer packet. Para sa maximum na bilis, parehong parameter ay dapat na negosasyon. Kung walang DLE, kahit na sa MTU na 247 bytes, ang data ay mafu-fragment sa ilang Link Layer packets na 27 bytes, na nagbabawas ng bandwidth.

Negosasyon ng MTU: pamamaraan at protocol

MTU Size Request — pamamaraan na pinasimulan ng Central pagkatapos mabuo ang GATT connection. Ang Central ay nagpapadala ng MTU Request na may specifikasyon ng kanyang MTU capacity (maximum na laki na kanyang matatanggap). Ang Peripheral ay tumutugon ng MTU Response gamit ang kanyang halaga. Ang ginamit na MTU ay ang minimum ng dalawang halaga. Kung ang Central ay nagmumungkahi ng MTU 512 at ang Peripheral ay sumusuporta lamang ng 128, ang connection ay gagamit ng MTU 128.

import CoreBluetooth

// Humingi ng maximum na MTU sa iOS
func requestMTU(central: CBCentralManager,
                    peripheral: CBPeripheral) {
    peripheral.maximumWriteValueLength(
        for: .withoutResponse
    )

// Awtomatikong nakikipag-ayos ang iOS ng MTU sa connection
            // MTU = 512 para sa BLE 5.0 devices
    let mtu = peripheral.maximumWriteValueLength(
        for: .withResponse
    )

    print("Na-negosasyong MTU: " +
          String(mtu))
}

Oras ng Negosasyon: ang MTU Request ay dapat ipadala pagkatapos matuklasan ang mga serbisyo (discoverServices), ngunit bago magsimula ang aktibong paglipat ng data. Sa iOS, ang Core Bluetooth ay awtomatikong nakikipag-ayos ng MTU sa connection — ang developer ay hindi kailangang magpadala ng MTU Request nang manu-mano. Sa Android, ang requestMTU ay dapat tawagan nang tahasan. Pagkatapos ng negosasyon, ang MTU ay nananatiling nakapirmi para sa connection na ito — ang muling negosasyon ay hindi posible nang walang pagdiskonekta at muling pagkonekta.

Mga Limitasyon ng ATT: bakit hindi maaaring higit sa 251 bytes ang MTU

ATT (Attribute Protocol) — ang protocol kung saan itinayo ang GATT. Ang ATT packet ay may maximum na laki na 257 bytes (ATT_MTU-1). Sa mga ito, 1 byte ay Opcode (uri ng operasyon), 1 byte ay Handle, at hanggang 255 bytes ay Value. Kaya, ang maximum na MTU na pinapayagan ng ATT specification ay 257 bytes (sa praktika ginagamit hanggang 251 bytes dahil ang ilang service field ay kailangan pa rin).

Para sa pagpapadala ng data na mas malaki kaysa sa MTU, ginagamit ang fragmentation sa antas ng application. Ang developer mismo ang naghahati ng data sa mga piraso na may sukat na ≤ MTU at ipinapadala ang mga ito nang sunud-sunod. Ang bawat piraso ay pormal na isang hiwalay na GATT Write Request. Ang tumatanggap na partido ay nag-assemble ng mga piraso sa isang buffer. Walang built-in na suporta para sa fragmentation sa GATT — ito ay gawain ng developer.

Kawili-wiling katotohanan: Ang iOS at Android ay humihiling ng MTU na 512 at 517 bytes ayon sa pagkakabanggit, ngunit ang halagang ito ay lumalampas sa limitasyon ng ATT. Sa praktika, ang BLE stack ay awtomatikong nagfa-fragment ng naturang data, na ipinapadala ang mga ito bilang ilang sunud-sunod na GATT request na maximum na 251 bytes. Para sa developer, ang pagkakaiba ay hindi napapansin — ang writeValue ay gumagana sa anumang laki hanggang 512 bytes sa iOS.

Epekto ng MTU sa Pagganap

Ang laki ng MTU ay direktang nakakaapekto sa bandwidth ng BLE connection. Sa MTU na 23 bytes, ang maximum na kapaki-pakinabang na bilis ng paglipat ay humigit-kumulang 7–10 KB/s sa ideal na kondisyon. Ang pagtaas ng MTU sa 247 bytes ay nagpapataas ng bilis sa 60–90 KB/s (may DLE at optimal na connection interval). Ito ay lalong mahalaga para sa mga application na naglilipat ng mga imahe, audio fragment, o log.

Ang pagganap ng BLE transmission ay nakadepende sa tatlong salik: MTU (kung gaano karaming data sa isang ATT request), connection interval (gaano kadalas nagaganap ang mga exchange event) at DLE (kung gaano karaming data sa isang Link Layer packet). Optimal na configuration para sa maximum na bilis: MTU = 247, DLE = 251, connection interval = 7.5 ms (minimum na halaga).

Ayon sa datos ng Bluetooth SIG White Paper (2023), ang pagtaas ng MTU mula 23 hanggang 247 bytes sa connection interval na 30 ms ay nagpapataas ng bandwidth mula 8 KB/s hanggang 42 KB/s — pagtaas ng 5 beses. Sa connection interval na 7.5 ms, ang bandwidth ay umaabot sa 88 KB/s. Para sa mga application na hindi nangangailangan ng mataas na bilis (temperature sensors, BLE beacons), ang standard na MTU na 23 bytes ay sapat pa rin.

Configuration ng MTU sa iOS at Android

iOS Core Bluetooth ay awtomatikong nakikipag-ayos ng MTU kapag kumokonekta sa Peripheral. Maaaring suriin ng developer ang kasalukuyang MTU sa pamamagitan ng maximumWriteValueLength, ngunit hindi ito maaaring manual na itakda. Ang iOS ay gumagamit ng MTU hanggang 512 bytes para sa BLE 5.0 devices at hanggang 247 para sa BLE 4.2. Para sa pagsulat ng malalaking volume ng data, gamitin ang writeType: .withResponse para sa garantisadong paghahatid.

// Humingi ng MTU sa Android (Kotlin)
val bluetoothGatt: BluetoothGatt = ...

// Humingi ng MTU 517 bytes
bluetoothGatt.requestMtu(517)

// Pangasiwaan ang resulta sa callback
override fun onMtuChanged(
    gatt: BluetoothGatt,
    mtu: Int,
    status: Int
) {
    if (status == BluetoothGatt.GATT_SUCCESS) {
        println("MTU negotiated: $mtu")
    }
}

Android ay nagbibigay ng BluetoothGatt.requestMtu(int), na nagpapahintulot sa paghiling ng anumang MTU hanggang 517 bytes. Ang aktwal na MTU ay tinutukoy ng peripheral device — kung ito ay sumusuporta lamang ng 23 bytes, ang Android ay magbabalik ng MTU 23. Para sa pagtukoy ng kasalukuyang MTU, gamitin ang gatt.requestMtu(0) — ito ay nagbabalik ng kasalukuyang halaga nang hindi sinusubukang baguhin ito. Ang Android 12+ ay sumusuporta sa awtomatikong negosasyon ng MTU sa connection sa pamamagitan ng TRANSPORT_LE.

Ang mga cross-platform framework (Flutter, React Native) ay karaniwang nagbibigay ng API para sa requestMTU. Sa library na FlutterBlue Plus, ang MTU ay itinakda bilang parameter ng connection. Sa RxAndroidBle — sa pamamagitan ng requestMtu method. Inirerekomenda na palaging makipag-ayos ng maximum na MTU kaagad pagkatapos matuklasan ang mga serbisyo, bago magsimula ang paglipat ng data, upang maiwasan ang fragmentation sa antas ng application.

MTU at OTA Updates

OTA (Over-The-Air) Firmware Updates — ang pinaka-demanding scenario pagdating sa MTU sa BLE. Ang tipikal na laki ng firmware ng IoT device ay 100–500 KB. Sa MTU na 23 bytes at connection interval na 30 ms, ang paglipat ng 100 KB ay tumatagal ng humigit-kumulang 2–3 minuto. Sa MTU na 247 bytes at DLE na 251 bytes — 20–40 segundo. At sa MTU na 512 bytes (iOS) — 10–15 segundo.

Ang proseso ng OTA update ay karaniwang kinabibilangan ng: fragmentation ng firmware sa mga packet na may sukat na ≤ MTU, sunud-sunod na pagpapadala sa pamamagitan ng Notify/Write, beripikasyon ng checksum sa bawat packet at kumpirmasyon ng pagtanggap. Kung ang isang packet ay nawala, ang device ay humihiling ng muling pagpapadala. Ang pagiging maaasahan ng OTA ay kritikal na nakadepende sa tamang pagpili ng MTU at connection interval.

Rekomendasyon para sa OTA: makipag-ayos ng maximum na MTU (247–512 bytes), itakda ang connection interval sa 7.5–15 ms (kung sinusuportahan ng device), gamitin ang DLE (Data Length Extension) para palakihin ang pisikal na packet hanggang 251 bytes. Para sa mga device na may limitadong buffer memory (hal., BLE modules batay sa nRF52), suriin ang maximum na MTU sa specifikasyon ng chip.