เปิดใช้ LoRa-Node ใหม่ด้วยวิธี OTAA
ลงไม้ลงมือ : “การเปิดใช้งานอุปกรณ์ LoRa-Node ใหม่ ด้วยวิธี OTAA Join”
บทความ โดย… วิสิทธิ์ เวียงนาค
ช่วงเริ่มต้นการศึกษาใช้งาน LoRaWAN ใหม่ๆ จะได้ยินบ่อยๆ กับคำว่า OTAA ตัวโหนดจะต้องกำหนดค่า DevEUI AppEUI และ AppKey ส่งไปให้ Network Server เพื่อเปิดใช้งาน แค่นี้ก็เพียงพอทำให้ปวดหัวแล้ว ยังไม่พอเจ้าตัว AppKey มันยังถูกนำไปสร้างเซสชันคีย์อื่นด้วย เช่น NwkSkey และ AppSkey แน่นอนว่าคงมีคำถามอยู่ในใจอย่างมากมาย โดยเฉพาะการเปิดใช้งานอุปกรณ์และขั้นตอนการทำงานว่ามันเป็นอย่างไรกันแน่ มันมีความปลอดภัยในการรับส่งข้อมูลไหม ถ้าจะเอาไปใช้งานจริงๆ ต้องมีอะไรบ้าง ต้องเตรียมการอะไรบ้าง เรียกว่ามีคำถามอยู่ไม่ใช่น้อย บางคนทุ่มสุดตัวค้นหาข้อมูลจนปวดหัวหรือบางคนคิดมากเกิน ท้อแท้ไปเลยก็มี บทความนี้จะทำให้ท่านเข้าใจและคลายความสงสัยให้กับท่าน และเชื่อได้แน่นอนว่าท่านจะได้เห็นภาพใหญ่การเชื่อมต่อเข้าเครือข่ายของ LoRaWAN อย่างแน่นอน
ผู้เขียนมีความตั้งใจที่จะอธิบายและแสดงขั้นตอนการทำงานของ LoRaWAN เป็นขั้นเป็นตอนตั้งแต่ต้นจนจบ โดยอ้างอิงตาม มาตรฐาน LoRaWAN 1.0.x ไม่ได้อ้างอิงเวอร์ชั่น LoRaWAN 1.1 ที่พึ่งประกาศมาไม่นานนี้นะครับ
LoRaWAN ทำงานเหมือน WiFi ไหม ?
หลายคนคงเคยใช้ WiFi มาก่อน คงคุ้นเคยกันดี มันมีทั้งรุ่นที่รองรับความถี่ 2.4GHz และ 5GHz คงคิดว่าการเชื่อมต่อเครือข่ายมันก็คงทำงานคล้ายๆ กัน โดยตัว Device จะทำการค้นหาตัว Access Point ถ้าตัวไหนสัญญาณดีก็จะใช้ตัวนั้น แล้วก็เลือกกดเข้าไปเชื่อมต่อ ใส่รหัสผ่านที่มีทั้งให้ใส่เฉพาะรหัสผ่านอย่างเดียว หรือใส่ทั้งยูสเซอร์และรหัสผ่าน จากนั้นก็สามารถเชื่อมต่อกับเครือข่ายได้
ต้องบอกเลยว่ามันไม่เหมือนกันเลย มีความต่างกันมากมายทีเดียว ระหว่าง LoRaWAN และ WiFi โดยภาพรวมการทำงานการรับส่งข้อมูลจาก LoRa-Node จะทำการส่งข้อมูลเป็นแพคเกจผ่านคลื่นความถี่ไร้สาย LoRa ไปยังตัว Gateway สำหรับประเทศไทยจะใช้คลื่นความถี่ 920–925 MHz (AS923) จากนั้นตัว Gateway จะทำการส่งต่อแพคเกจไปยัง Network Server เพื่อจัดการให้ LoRaWAN ทำงาน และส่งแพคเกจต่อไปยัง Application Server เพื่อนำแพคเกจที่ได้ ไปถอดรหัสเป็นข้อมูลเพื่อนำไปใช้งานต่อไป โดยมีการเข้ารหัสการรับส่งข้อมูลตลอดทั้งเส้นทาง
การเปิดใช้งานอุปกรณ์ LoRa ใหม่ด้วยวิธี OTAA
ก่อนที่อุปกรณ์ LoRa ปลายทาง ในที่นี่ขอเรียกว่า LoRa-Node ก็แล้วกัน จะสามารถสื่อสารกับ Network Server ได้ LoRa-Node จำเป็นต้องเปิดใช้งานเสียก่อนและต้องผ่านกระบวนการเชื่อมต่อเครือข่ายให้สมบูรณ์ กลไกลนี้เป็นวิธีการจัดการควบคุมการเชื่อมต่อ LoRa-Node ไปยัง Network Server โดย LoRa-Node จำเป็นต้องพิสูจน์ตัวตนและตรวจสอบสิทธิ์การเชื่อมต่อเครือข่าย LoRaWAN เสียก่อน จึงสามารถรับส่งข้อมูลได้ ขั้นตอนนี้จะทำทุกครั้งที่เปิดอุปกรณ์ขึ้นมาใหม่ มีให้เลือกอยู่สองแบบ แบบแรกคือ OTAA (Over-The-Air Activation) และแบบที่สองคือ ABP (Activation-By-Personalisation) สำหรับเรื่องของความปลอดภัยของข้อมูล OTAA มีปลอดภัยมากกว่าในกระบวนการเชื่อมต่อระหว่าง LoRa-Node กับ Network Server และเป็นที่นิยมใช้กันในปัจจุบันเพราะมีความสามารถจัดการกับตัวโหนดที่มีจำนวนมากๆ ได้ดีกว่ามาก
มาดูกันว่าภาพรวมของการเปิดใช้อุปกรณ์ LoRa-Node ใหม่แบบ OTAA มีขั้นตอนการทำงานกันอย่างไร โดยธรรมชาติของตัวโหนด LoRaWAN พอมีไฟเลี้ยงจ่ายให้มันและเร่ิมการทำงาน สิ่งที่มันทำอันดับแรกคือการส่งบรอดแคสแพจเกจออกไปทั่วเลย ถ้าในบริเวณนั้นมีตัว LoRaWAN Gateway ของเรา หรือของชาวบ้านอยู่ด้วย ถ้าใช้คลื่นความถี่เดียวกันตามข้อกำหนดของประเทศไทย (AS923) ก็จะได้รับแพคเกจ กันหมด มันไม่สามารถเลือกส่งได้นะครับว่าจะไปให้ Gateway ตัวไหน ไม่ส่งให้ตัวไหน มันจะส่งไปหาทั้งหมดถ้ามีสัญญาณสื่อสารได้ แพคเกจที่ LoRaWAN Gateway ได้รับจะส่งต่อไปยัง Network Server และ Application Server เพื่อตรวจสอบความถูกต้องของแพคเกจและพิสูจน์ตัวตนเข้าเชื่อมต่อเครือข่าย ถ้าพบว่าถูกต้องก็จะนำแพคเกจไปโปรเซสต่อ แต่ถ้าพบว่าไม่ถูกต้องก็จะแตะแพคเกจทิ้งไป ไม่นำไปโปรเซสต่อ
ขั้นตอนการเปิดใช้งานอุปกรณ์ LoRa ใหม่ด้วยวิธี OTAA มีดังต่อไปนี้
ขั้นเตรียมพร้อม ให้สร้าง LoRa-Node ใหม่ใน Network Server ก่อน
ก่อนที่จะเร่ิมกระบวนการเปิดใช้งานอุปกรณ์ LoRa ใหม่ด้วยวิธี OTAA ขั้นตอนแรกคือการเตรียมความพร้อม ท่านต้องกำหนดคีย์ DevEUI , AppEUI and AppKey ให้กับ LoRa-Node เสียก่อน ซึ่งมีหลายวิธี เช่นกำหนดใน CODE ที่เขียนขึ้น หรือใช้ AT Command กำหนดให้กับโมดูล LoRa โดยตรง ทั้งนี้ขึ้นอยู่กับโมดูลใช้งาน จากนั้นให้สร้าง LoRa-Node ใน Network Server โดยกำหนดคีย์ต่างๆ ให้ตรงกัน
ขั้นตอนที่ 1. การขอเชื่อมต่อ (Join Request Package)
หลังจากที่จ่ายไฟเลี้ยงให้กับ LoRa-Node และเปิดใช้งานแล้ว LoRa-Node ก็จะทำการส่งบรอดแคสแพจเกจออกไปให้ตัว LoRaWAN Gateway ตัวไหนที่อยู่ในรัศมีทำการ มีสัญญาณ LoRa แรงดีและใช้คลื่นความถี่ย่านเดียวกันก็จะได้รับแพคเกจจาก LoRa-Node กันถ้วนหน้าโดยแพคที่ตัวโหนดส่งออกไปเรียกว่า “Join Request” มีหน้าตาแพคเกจ รูปแบบ JSON คล้ายรูปข้างล่าง ในแพคเกจ “Join Request” ประกอบด้วย DevEUI (8 bytes), JoinEUI (8 bytes) และ DevNonce (2 bytes) แพคเกจนี้ไม่ได้เข้ารหัสข้อความนะครับ แต่มันจะอาศัยใช้ AppKey สร้างรหัส MIC (Message Integrity Code) ขึ้นมาใหม่ เพื่อรับรองความถูกต้องของข้อความ (integrity of the message) ที่ส่งไปยัง Network Server ว่าไม่มีใครมาแอบเปลี่ยนแก้ไขข้อมูลระหว่างทาง
ข้อมูลที่ LoRa-Node ส่งไปให้ Network Server ประกอบไปด้วย
DevEUI เป็นหมายเลขจำนวน 16 ตัว ฐาน 16 (HEX) คือมีตัวอักษร 1-F และ 0–9 เท่านั้น ตัวเลขนี้จะไม่ซ้ำกัน (Uniquely Identifies) คล้ายๆ กับ MAC Address ในอุปกรณ์ Network ที่คุ้นเคยกันดี ที่เอาไว้อ้างอิงว่าเป็นอุปกรณ์ตัวไหนกำหนดโดยโรงงานผู้ผลิต แต่สำหรับ DevEUI แล้ว เราสามารถกำหนดเองได้ ยังไม่มีหน่วยงานไหนดูแลแบบจริงจัง เอาเป็นว่าในเครือข่าย LoRaWAN เดียวกันขอให้ไม่ซ้ำกันก็พอครับ
JoinEUI ตัวนี้เปลี่ยนชื่อมาจาก AppEUI ตามมาตรฐาน LoRaWAN 1.0/1.0.2 เอาไว้ใช้เพื่อบอกให้กับ Network Server รู้ว่าจะใช้ Join-Server ตัวไหนสำหรับการพิสูจน์ตัวตนใหักับแพคเกจ Join-Request สำหรับเครือข่ายของ CAT LoRaWAN ในประเทศไทย จำเป็นต้องกำหนดคีย์นี้ด้วย แต่สำหรับ Network Server บางตัวที่อื่น อาจไม่สนใจก็ได้ครับ ไม่ต้องกำหนดคีย์นี้ก็ได้ถ้ามันมี Join-Server อยู่แค่ตัวเดียว
DevNonce คือเลขหมายที่เกิดจากการสุ่มสร้างขึ้นมาจากตัวโหนด เพื่อส่งไปให้ Network Server เกิดขึ้นมาในช่วงกระบวนการ Join-Request เพื่อป้องกันการปลอมตัวตอบกลับแพคเกจ Join-Request เลขหมายที่สร้างขึ้นมาจะไม่ซ้ำกันระหว่างตัวโหนดกับ Network Server
MIC คำนวณมาจาก LoRa-Node มันจะอาศัยใช้ AppKey สร้างรหัส MIC (Message Integrity Code) ขึ้นมาใหม่ เพื่อรับรองความถูกต้องของข้อความ (integrity of the message) ที่ส่งไปยัง Network Server ว่าไม่มีใครมาแอบเปลี่ยนแก้ไขข้อมูลระหว่างทาง
ขั้นตอนที่ 2. Gateway ส่งต่อแพคเกจ (Package Forwarder)
หลังจากที่ LoRaWAN Gateway ได้รับแพคเกจที่ประกอบไปด้วย joinEUI , devEUI , devNonce และ AppKey แล้ว มีสองอย่างที่จะทำต่อ แบบที่หนึ่ง ตัว LoRaWAN Gateway ที่ได้ลงโปรแกรม Package Forwarder ไว้ แบบนี้ มันจะส่งตัวแพคเกจต่อไปให้ตัว Gateway Bridge Server และ Network Server ด้วยโปรโตรคอล UDP โดยปกติจะใช้พอร์ตหมายเลข 1680 หรือ 1700 ส่วนแบบที่สองคือ ตัว LoRaWAN Gateway ที่ได้ลงโปรแกรม Package Forwarder และ Gateway Bridge Server ไว้ในตัวเดียวกัน แบบนี้ตัว LoRaWAN Gateway จะทำการแปลงข้อมูลจาก UDP ให้เป็น MQTT ในรูปแบบ JSON แล้วส่งแพคเกจต่อไปยัง MQTT Borker ที่ติดตั้งไว้ไปให้ Network Server
ขั้นตอนที่ 3. Network Server พิสูจน์ตัวตนและสร้างคีย์ (Authentication and Session Key Generation)
หลังจากที่ Network Server ได้รับแพคเกจแล้ว จะตรวจสอบว่าเลขหมายของ DevNonce มีการใช้ก่อนหน้าหรือไม่ ถ้าพบว่ามีการใช้มาก่อน ก็จะแตะแพคเกจออกไปทันที แต่ถ้าพบว่ายังไม่เคยใช้ ก็จะโปรเซสต่อโดย Network Server จะนำ AppKey (ที่เราเคยกำหนดไว้ตอนสร้าง LoRa-Node) สร้างเป็นรหัส MIC (Message Integrity Code) ขึ้นมา โดยรหัส MIC (Message Integrity Code) ที่สร้างขึ้นนี้ เป็นของฝั่ง Network Server เองนะครับ จากนั้นมันจะเปรียบเทียบรหัส MIC ที่มันสร้างขึ้นมาเองกับรหัส MIC ที่ได้รับจากแพคเกจ “Join-Request” ว่าตรงกันหรือไม่ ถ้าแพคเกจ มีความถูกต้องจริง คือข้อความไม่มีการแอบแก้ไข แอบเปลี่ยนข้อมูลระหว่างทาง (Integrity of the Message) แล้ว Network Server ก็จะโปรเซสต่อ มันจะสร้างคีย์ขึ้นมาใหม่ได้แก่ DevAddr (Device Address) , AppNonce และ NetID
Network Server จะทำการสร้างแพคเกจขึ้นมาใหม่ เรียกว่า “Join-Accept” ประกอบด้วย DevAddr, AppNonce, NetID และ Network Settings จากนั้นมันจะนำ AppKey มาสร้างรหัส MIC (Message Integrity Code) ขึ้นมาใหม่อีกชุด และทำการ เข้ารหัสแพคเกจด้วย AppKey จากนั้น Network Server จะส่งแพคเกจตอบกลับไปยัง LoRa-Node โดยแพคเกจที่ตอบกลับไปตอนนี้จะเข้ารหัสไว้ด้วย (Encrypted Message) โดยใช้อัลกอริทึมในการเข้ารหัส คือ AES 128 บิต (Advanced Encryption Stabdard) และมี MIC (Message Integrity Code) ส่งไปเพื่อตรวจสอบความถูกต้องของข้อมูลอีกด้วย
การเข้ารหัสข้อมูลด้วย AppKey คำนวณและใช้สมการดังต่อไปนี้
aes128_decrypt(AppKey, AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList | MIC)
แพคเกจที่ Network Server ส่งไปให้ตัวโหนดประกอบไปด้วย
AppNonce คือชุดหมายเลขที่ Network Server สุ่มสร้างขึ้นที่ไม่ซ้ำกัน (unique ID) แล้วส่งไปให้ตัวโหนด จะถูกสร้างขึ้นในขั้นตอนการสร้างแพคแกจ “Join-Accept” หลังจากที่ตัวโหนดได้รับ AppNonce จากแพคเกจที่ Network Server ส่งไป ตัวโหนดจะนำ AppNonce และ DevNonce มาสร้าง “เซสชั่นคีย์” ได้แก่ NwkSKey (Network Session Key) และ AppSKey (Application Session Key)
NetID หมายเลขของเครือข่าย (unique ID)
DevAddr คล้ายกับ IP Address ของ Network ที่คุ้นเคยกันดี เป็น address ของตัวโหนดแบบสั้นที่ได้มาจาก Network Server มีขนาด 32 บิตและจะไม่ซ้ำกันใน Network เดียวกัน มันจะถูกใช้ระบุใน Header ของแพคเกจเฟรมที่รับส่งกัน ระหว่างตัวโหนด Network Server และ Application Server
DLSetting ค่าการตั้งค่าของ Downlink พารามิเตอร์ต่างๆ เช่น ค่า data rate ของดาวน์ลิงค์ที่ใช้ในการสื่อสารระหว่างตัวโหนดเป็นต้น
RxDelay ค่าหน่วงเวลาที่ใช้ในการรับและส่งข้อมูล
CFList การกำหนดค่าความถี่ที่ใช้งาน และการตั้งค่าแต่ละความถี่
มาถึงตอนนี้ทั้ง LoRa-Node และ Network Server ก็จะมีข้อมูล DevAddr AppNonce และอื่นๆ ที่เหมือนกันอยู่ในประเป๋าทั้งคู่ ตัว LoRa-Node และ Network Server จะนำ AppNonce และ DevNonce มาสร้างเซสชั่นคีย์ ได้แก่ NwkSKey (Network Session Key) และ AppSKey (Application Session Key) จากนั้น Network Server จะส่ง AppSKey and DevAddr ไปให้ Application Server ด้วย
การคำนวณการสร้าง NwkSKey และ AppSKey ได้มาจากสมการดังต่อไปนี้
NwkSKey
aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16)
AppSKey
aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)
เท่ากับว่าตอนนี้มีกุญแจอยู่ 2 ดอก ดอกแรก คือ NwkSKey (Network Session Key) คนที่ถือกุญแจนี้ก็คือ LoRa-Node และ Network Server ตัว ส่วนดอกที่สอง ก็คือ AppSKey (Application Session Key) คนที่ถือกุญแจนี้ก็คือ LoRa-Node และ Application Server
ขั้นตอนที่ 4. Application Server สื่อสารกับตัว LoRa-Node
Network Session Key (NwkSKey) จะนำมาใช้สำหรับการสื่อสารข้อมู ระหว่าง LoRa-Node และ Network Server คีย์นี้จะใช้ในการคำนวณเพื่อตรวจสอบความถูกต้องของข้อความ MIC (Message Integrity Code) ว่าข้อความทั้งหมดเป็นข้อความที่เชื่อถือได้
ส่วน Application Session Key (AppSKey) จะนำมาใช้ในการสื่อสารข้อมูลระหว่าง LoRa-Node และ Application Server ใช้สำหรับการเข้ารหัสและถอดรหัสข้อมูล Payload ทั้งหมด โดยจะเข้ารหัสระหว่างตัวโหนดและ Application Server ซึ่งหมายความว่าไม่มีใครสามารถแอบอ่านเนื้อหาของข้อความระหว่างทางที่รับส่งได้
ความปลอดภัยของ LoRaWAN
LoRa-Node ทุกตัวจะถูกบังคับให้เข้ารหัสข้อมูล Payload และ Header แบบ Advanced Encryption Standard (AES) อัลกอริทึม 128 บิต จะมีความปลอดภัยแบบ 2 ชั้นคือ
- ชั้นของ Network Server โดยใช้ NwkSkey ทำการตรวจสอบ ความถูกต้องของข้อมูลความน่าเชื่อถือของข้อมูล Message Integrity Code (MIC)
- ชั้นของ Application Server ท่ีทำการเข้ารหัส payload โดยใช้ AppSKey จากตัวโหนดไปยัง Applicaiton Server
หมายความว่าการรับส่งข้อมูลจาก LoRa-Node ไปยัง Application Server มีการเข้ารหัสข้อมูลตลอดเส้นทางและเป็นแบบ end-to-end มีความปลอดภัยสูงมากครับ
คงจะพอเห็นภาพการเปิดใช้งานอุปกรณ์ LoRa-Node ใหม่ ด้วยวิธี OTAA Join กันแล้ว LoRaWAN อาจดูมีความซับซ้อนบ้างเล็กน้อยเพราะเป็นเทคโนโลยีใหม่ที่พึ่งเกิดขึ้นมา แต่มีมาตรฐานต่างๆ กำกับการทำงานอย่างครบถ้วน ไม่ได้ยากนะครับ
ผู้เขียนมีความตั้งใจที่จะนำเสนอการใช้ IoT-LoRaWAN-NBIOT สำหรับพัฒนา SMART CITY เพื่อให้ผู้ที่สนใจนำไปพัฒนาต่อยอดสร้างนวกรรมใหม่ๆ ขอเป็นส่วนหนึ่งเล็กๆ น้อยๆ ช่วยผลักดันประเทศของเราให้เข้าสู่ยุคดิจิตอล Thailand 4.0 อย่างแท้จริง
ติดตามข่าวสารทางเพจ facebook “วิสิทธิ์ เวียงนาค” ได้ที่ลิงค์นี้
ติดตามข่าวสารทางกลุ่ม facebook “IoT-SmartCity” ได้ที่ลิงค์นี้
