ประเภทข้อความใดที่สามารถใช้สำหรับโปรโตคอลเครือข่ายเซลลูลาร์แบบ IoT

สิ่งนี้ทำให้ฉันสนใจเมื่อเร็ว ๆ นี้เมื่อฉันพบวิดีโอที่น่าอัศจรรย์บน Youtube โดย:

ไมเคิลอีเดอร์สัน: การเปรียบเทียบเทคนิคการส่งข้อความสำหรับ IOT, OpenIoTSummit มูลนิธิลินุกซ์

สไลด์สำหรับการพูดของเขามีอยู่ที่นี่

บนสไลด์ 26 และ41 นาทีของวิดีโอที่เขาพูดถึงเกี่ยวกับวิธีการ (ให้ฉันถอดความ):

ผู้ให้บริการเครือข่ายมือถือต้องการให้ผู้บริโภค IoT ใช้ข้อความประเภทHTML , XMLหรือJSONเนื่องจากพวกเขาใช้ข้อมูลมากขึ้น ข้อมูลเพิ่มเติมหมายความว่าพวกเขาสามารถเรียกเก็บเงินจากผู้บริโภคได้มากขึ้นสำหรับบริการ

ฉันเข้าใจว่าโปรโตคอลที่เป็นกรรมสิทธิ์จำนวนมาก ได้แก่ SigFox , Wireless HARTหรือZ Waveมีอัตราการส่งข้อมูลที่ต่ำกว่าและการส่งข้อมูลขนาดใหญ่ผ่านผู้ให้บริการดังกล่าวอาจเป็นเรื่องที่มีราคาแพง

คำถาม

• มีรูปแบบการส่งข้อความที่มีน้ำหนักเบาอื่น ๆที่ใช้สำหรับการใช้งานในโปรโตคอลที่เป็นกรรมสิทธิ์ซึ่งทำให้เป็นโซลูชั่นที่คุ้มค่าสำหรับผู้บริโภค IoT ในปัจจุบันและอนาคตหรือไม่? (ถ่ายในที่มืด: รูปแบบบางอย่างที่เรียกว่าLightweight XML หรือ HTML หรือ JSONกำลังวางอยู่ที่ไหนสักแห่ง?)

• อาจจะมีบางอย่างเช่นCBORหรืออาจจะใช้?

คุณกำลังถามเกี่ยวกับโปรโตคอลหรือรูปแบบข้อความหรือไม่? เรามักจะใช้คำว่าโพรโทคอลไม่ถูกต้องเมื่อเราหมายถึงรูปแบบของข้อมูล ฉันทำสิ่งนี้ด้วยตัวเองบ่อยครั้งเพราะความแตกต่างนั้นไม่ชัดเจนสำหรับทุกคน

โปรโตคอลการส่งข้อความที่ใช้ใน IoT มีแนวโน้มที่จะมีขนาดเล็กพอสมควรอย่างน้อยก็มากกว่า http และมีคุณสมบัติที่สำคัญที่มีความสำคัญในการส่งข้อความ (เซสชันการควบคุมการไหลความน่าเชื่อถือ ฯลฯ ) รูปแบบข้อความเป็นข้อมูลในข้อความที่ส่ง ฉันคิดว่านี่คือสิ่งที่คุณถาม

รูปแบบข้อความที่กะทัดรัดที่สุดคือรูปแบบไบนารีที่หมุนด้วยมือซึ่งพิจารณาอย่างรอบคอบ มันถูกใช้บ่อยเมื่ออยู่ในสถานการณ์ที่มีแบนด์วิธต่ำเมื่อคุณต้องการส่งสองสามไบต์และรู้ว่าไบต์เหล่านั้นเป็นอย่างไร สำหรับข้อความที่มีขนาดใหญ่ขึ้นข้อเสียมีความสำคัญและควรหลีกเลี่ยงค่าใช้จ่ายทั้งหมด

ฉันผ่านการประเมินอย่างละเอียดเกี่ยวกับตัวเลือกการทำให้เป็นอันดับข้อมูลที่แตกต่างกัน ฉันคาดว่า protobuf, messagepack มีขนาดเล็กพอสมควร อย่างไรก็ตามปัญหาที่สองของฉันคือการค้นหาไลบรารีที่ได้รับการบำรุงรักษาและพร้อมใช้งานบนแพลตฟอร์มต่าง ๆ รวมถึง C บนอุปกรณ์

รูปแบบที่ฉันตัดสินอย่างแปลกใจคือ gzip ที่บีบอัด JSON มันง่ายที่จะติดตั้งและเข้าใจใช้งานได้ทุกที่และด้วยข้อมูลที่ฉันใช้อยู่นั้นมีขนาดเท่ากันหรือเล็กกว่าวิธีอื่น ๆ

และระวังด้วยว่าหากคุณมีช่องทางที่ปลอดภัยเช่น TLS คุณจะต้องใช้ข้อมูลจำนวนมาก (> 6KB) ในการจับมือ TLS

ไม่กี่ปีที่ผ่านมาฉันคาดว่ารูปแบบเช่นบัฟเฟอร์โปรโตคอลจะครอง แต่ไม่เกิดขึ้นจริงมาก อาจเป็นเพราะความง่ายที่ json สามารถเขียนและแยกวิเคราะห์ (และบีบอัด) ฉันชอบรูปลักษณ์ของFlatbuffersแต่ข้อดีคือความเร็วในการแยกวิเคราะห์มากกว่าการกะทัดรัด

เนื่องจากคุณอยู่ในช่วงการตรวจสอบฉันขอแนะนำให้คุณเขียนโค้ดเล็กน้อยในแต่ละรายการโดยใช้ข้อมูลที่เป็นเรื่องปกติสำหรับสถานการณ์ของคุณและทำการเปรียบเทียบบางอย่าง การมีข้อมูลหนักเมื่อคุณเริ่มช่วยยืนยันการเลือกของคุณ

ข้อได้เปรียบที่สำคัญของรูปแบบที่อิงกับมาร์กอัปคือคุณรักษาความยืดหยุ่นในการเลือกข้อมูลที่คุณส่ง สิ่งนี้มีความสำคัญอย่างมากในระบบนิเวศที่กำลังพัฒนาซึ่งคุณคาดว่าจะได้รับบริการจากการพัฒนาในช่วงหลายปีที่ผ่านมา

แม้ว่าโครงสร้างข้อมูลไบนารีที่เข้ารหัสอย่างแน่นหนาจะมีประสิทธิภาพในการส่ง แต่คุณต้องตัดสินใจล่วงหน้าอย่างน้อยว่าโครงสร้างจะมีลักษณะอย่างไร เมื่อหลังจากนั้นคุณก็รู้ว่าแม้กระทั่งหนึ่งเขตข้อมูลที่ต้องการการขยายตัวคุณก็ติดอยู่ แม้แต่การเปิดตัวการปรับปรุงโปรโตคอลก็ทำได้ยากเนื่องจากคุณไม่สามารถล้าสมัยการเข้ารหัสเก่าได้จนกว่าจะถึงจุดสิ้นสุดทุกจุด

สิ่งนี้ชี้ให้เห็นว่าวิธีการที่เหมาะสมที่สุดคือการผสมผสานแพ็กเก็ตมินิมัลลิสต์และการเข้ารหัสโดยใช้มาร์กอัป ค่านี้ขึ้นกับแบนด์วิดท์สูงสุดที่โหลด หากคุณถ่ายโอนชิ้นวิดีโอขนาดบ่อยอยู่แล้วการเพิ่มประสิทธิภาพข้อมูลควบคุมไม่บ่อยก็คุ้มค่าน้อยลง หากคุณมีการถ่ายโอนขนาดเล็กบ่อยครั้ง (อุณหภูมิอาจจะ) มันทำให้รู้สึกถึงการลดค่าใช้จ่ายในการส่ง - แต่อาจเพียงแค่ชุดการถ่ายโอนเป็นสิ่งที่ดี