ในบทความ "" เมื่อพูดถึงสถาปัตยกรรมของแพ็กเก็ตคอร์ของเครือข่าย NB-IoT เราได้กล่าวถึงรูปลักษณ์ของโหนด SCEF ใหม่ เราอธิบายในส่วนที่สามว่ามันคืออะไรและทำไมจึงจำเป็น?
เมื่อสร้างบริการ M2M นักพัฒนาแอปพลิเคชันจะต้องเผชิญกับคำถามต่อไปนี้:
- วิธีระบุอุปกรณ์
- อัลกอริธึมการตรวจสอบและการรับรองความถูกต้องใดที่จะใช้
- โปรโตคอลการขนส่งใดให้เลือกสำหรับการโต้ตอบกับอุปกรณ์
- วิธีการส่งข้อมูลไปยังอุปกรณ์อย่างน่าเชื่อถือ
- วิธีจัดระเบียบและสร้างกฎเกณฑ์ในการแลกเปลี่ยนข้อมูลกับพวกเขา
- วิธีการติดตามและรับข้อมูลเกี่ยวกับสภาพของพวกเขาทางออนไลน์
- วิธีส่งข้อมูลไปยังกลุ่มอุปกรณ์ของคุณพร้อมกัน
- วิธีส่งข้อมูลจากอุปกรณ์เครื่องหนึ่งไปยังไคลเอนต์หลายเครื่องพร้อมกัน
- วิธีรับการเข้าถึงบริการของผู้ให้บริการเพิ่มเติมแบบครบวงจรสำหรับการจัดการอุปกรณ์ของคุณ
เพื่อแก้ไขปัญหาเหล่านี้ จำเป็นต้องสร้างโซลูชัน "หนัก" ทางเทคนิคที่เป็นกรรมสิทธิ์ ซึ่งนำไปสู่ต้นทุนค่าแรงที่เพิ่มขึ้นและการบริการที่นำสินค้าออกสู่ตลาดได้ทันเวลา นี่คือจุดที่โหนด SCEF ใหม่เข้ามาช่วยเหลือ
ตามที่กำหนดโดย 3GPP SCEF (ฟังก์ชันการเปิดเผยความสามารถด้านบริการ) เป็นองค์ประกอบใหม่ทั้งหมดของสถาปัตยกรรม 3GPP ซึ่งมีหน้าที่เปิดเผยบริการและความสามารถที่ได้รับจากอินเทอร์เฟซเครือข่าย 3GPP ผ่าน API อย่างปลอดภัย
พูดง่ายๆ ก็คือ SCEF เป็นตัวกลางระหว่างเครือข่ายและแอปพลิเคชันเซิร์ฟเวอร์ (AS) ซึ่งเป็นหน้าต่างเดียวในการเข้าถึงบริการของผู้ให้บริการสำหรับการจัดการอุปกรณ์ M2M ของคุณในเครือข่าย NB-IoT ผ่านอินเทอร์เฟซ API ที่ได้มาตรฐานและใช้งานง่าย
SCEF ซ่อนความซับซ้อนของเครือข่ายของผู้ให้บริการ ช่วยให้นักพัฒนาแอปพลิเคชันสามารถสรุปกลไกที่ซับซ้อนเฉพาะอุปกรณ์สำหรับการโต้ตอบกับอุปกรณ์ได้
ด้วยการเปลี่ยนโปรโตคอลเครือข่ายให้เป็น API ที่คุ้นเคยสำหรับนักพัฒนาแอปพลิเคชัน SCEF API อำนวยความสะดวกในการสร้างบริการใหม่และลดเวลาในการออกสู่ตลาด โหนดใหม่ยังมีฟังก์ชันสำหรับระบุ/ตรวจสอบสิทธิ์อุปกรณ์เคลื่อนที่ กำหนดกฎสำหรับการแลกเปลี่ยนข้อมูลระหว่างอุปกรณ์และ AS ทำให้นักพัฒนาแอปพลิเคชันไม่จำเป็นต้องปรับใช้ฟังก์ชันเหล่านี้ที่ฝั่งของตน และย้ายฟังก์ชันเหล่านี้ไปที่ไหล่ของผู้ปฏิบัติงาน
SCEF ครอบคลุมอินเทอร์เฟซที่จำเป็นสำหรับการตรวจสอบสิทธิ์และการอนุญาตแอปพลิเคชันเซิร์ฟเวอร์ การดูแลรักษาความคล่องตัวของ UE การถ่ายโอนข้อมูลและการทริกเกอร์อุปกรณ์ การเข้าถึงบริการเพิ่มเติม และความสามารถของเครือข่ายผู้ให้บริการ
สำหรับ AS จะมีอินเทอร์เฟซ T8 เดียว ซึ่งเป็น API (HTTP/JSON) ที่กำหนดมาตรฐานโดย 3GPP อินเทอร์เฟซทั้งหมด ยกเว้น T8 ทำงานตามโปรโตคอล DIAMETER (รูปที่ 1)
T6a – ส่วนต่อประสานระหว่าง SCEF และ MME ใช้สำหรับขั้นตอนการจัดการความคล่องตัว/เซสชัน การส่งข้อมูลที่ไม่ใช่ IP การจัดเตรียมเหตุการณ์การตรวจสอบ และการรับรายงานเกี่ยวกับเหตุการณ์เหล่านั้น
S6t – ส่วนต่อประสานระหว่าง SCEF และ HSS จำเป็นสำหรับการตรวจสอบสิทธิ์สมาชิก การอนุญาตแอปพลิเคชันเซิร์ฟเวอร์ การได้รับ ID ภายนอกและ IMSI/MSISDN ร่วมกัน การจัดเตรียมเหตุการณ์การตรวจสอบ และการรับรายงานเกี่ยวกับเหตุการณ์เหล่านั้น
S6m/T4 – อินเทอร์เฟซจาก SCEF ถึง HSS และ SMS-C (3GPP กำหนดโหนด MTC-IWF ซึ่งใช้สำหรับการทริกเกอร์อุปกรณ์และการส่ง SMS ในเครือข่าย NB-IoT อย่างไรก็ตาม ในการใช้งานทั้งหมด ฟังก์ชันการทำงานของโหนดนี้จะรวมเข้ากับ SCEF ดังนั้นเพื่อให้วงจรง่ายขึ้น เราจะไม่พิจารณาแยกกัน) ใช้เพื่อรับข้อมูลเส้นทางสำหรับการส่ง SMS และการโต้ตอบกับศูนย์ SMS
T8 – อินเทอร์เฟซ API สำหรับการโต้ตอบ SCEF กับแอปพลิเคชันเซิร์ฟเวอร์ ทั้งคำสั่งควบคุมและการรับส่งข้อมูลจะถูกส่งผ่านอินเทอร์เฟซนี้
*ในความเป็นจริงแล้ว มีอินเทอร์เฟซมากกว่า มีเพียงอินเทอร์เฟซพื้นฐานที่สุดเท่านั้นที่แสดงไว้ที่นี่ รายการทั้งหมดมีอยู่ใน 3GPP 23.682 (4.3.2 รายการจุดอ้างอิง)
ด้านล่างนี้คือหน้าที่และบริการที่สำคัญของ SCEF:
- การเชื่อมโยงตัวระบุซิมการ์ด (IMSI) กับ ID ภายนอก
- การส่งทราฟฟิกที่ไม่ใช่ IP (การส่งข้อมูลที่ไม่ใช่ IP, NIDD)
- การดำเนินงานกลุ่มโดยใช้ ID กลุ่มภายนอก
- รองรับโหมดการรับส่งข้อมูลพร้อมการยืนยัน
- การบัฟเฟอร์ของข้อมูล MO (Mobile Originated) และ MT (Mobile Terminated)
- การรับรองความถูกต้องและการอนุญาตอุปกรณ์และเซิร์ฟเวอร์แอปพลิเคชัน
- การใช้ข้อมูลจาก UE หนึ่งรายการพร้อมกันโดย AS หลายรายการ
- รองรับฟังก์ชั่นการตรวจสอบสถานะ UE พิเศษ (MONTE - เหตุการณ์การตรวจสอบ);
- การเรียกใช้อุปกรณ์
- ให้บริการโรมมิ่งข้อมูลที่ไม่ใช่ IP
หลักการพื้นฐานของการทำงานร่วมกันระหว่าง AS และ SCEF นั้นขึ้นอยู่กับรูปแบบที่เรียกว่า การสมัครรับข้อมูล. หากจำเป็นต้องเข้าถึงบริการ SCEF ใด ๆ สำหรับ UE เฉพาะ แอปพลิเคชันเซิร์ฟเวอร์จำเป็นต้องสร้างการสมัครสมาชิกโดยการส่งคำสั่งไปยัง API เฉพาะของบริการที่ร้องขอ และได้รับตัวระบุที่ไม่ซ้ำกันในการตอบสนอง หลังจากนั้นการดำเนินการและการสื่อสารเพิ่มเติมทั้งหมดกับ UE ภายในกรอบของบริการนี้จะเกิดขึ้นโดยใช้ตัวระบุนี้
รหัสภายนอก: ตัวระบุอุปกรณ์สากล
การเปลี่ยนแปลงที่สำคัญที่สุดอย่างหนึ่งในรูปแบบการโต้ตอบระหว่าง AS และอุปกรณ์เมื่อทำงานผ่าน SCEF คือรูปลักษณ์ของตัวระบุสากล ในปัจจุบัน แทนที่จะเป็นหมายเลขโทรศัพท์ (MSISDN) หรือที่อยู่ IP เช่นเดียวกับในกรณีในเครือข่าย 2G/3G/LTE แบบคลาสสิก ตัวระบุอุปกรณ์สำหรับแอปพลิเคชันเซิร์ฟเวอร์จะกลายเป็น “ID ภายนอก” กำหนดโดยมาตรฐานในรูปแบบ “@” ที่นักพัฒนาแอปพลิเคชันคุ้นเคย
นักพัฒนาไม่จำเป็นต้องใช้อัลกอริธึมการรับรองความถูกต้องของอุปกรณ์อีกต่อไป เครือข่ายจะเข้ามาแทนที่ฟังก์ชันนี้โดยสมบูรณ์ รหัสภายนอกเชื่อมโยงกับ IMSI และนักพัฒนาสามารถมั่นใจได้ว่าเมื่อเข้าถึงรหัสภายนอกเฉพาะ รหัสนั้นจะโต้ตอบกับซิมการ์ดเฉพาะ เมื่อใช้ชิป SIM คุณจะได้รับสถานการณ์ที่ไม่เหมือนใครเมื่อ ID ภายนอกระบุอุปกรณ์เฉพาะโดยไม่ซ้ำกัน!
นอกจากนี้ ID ภายนอกหลายรายการสามารถเชื่อมโยงกับ IMSI เดียวได้ - สถานการณ์ที่น่าสนใจยิ่งขึ้นเกิดขึ้นเมื่อ ID ภายนอกระบุแอปพลิเคชันเฉพาะที่รับผิดชอบบริการเฉพาะบนอุปกรณ์เฉพาะโดยไม่ซ้ำกัน
ตัวระบุกลุ่มก็ปรากฏขึ้นเช่นกัน - รหัสกลุ่มภายนอก ซึ่งรวมถึงชุดของรหัสภายนอกแต่ละรายการ ขณะนี้ ด้วยคำขอเดียวไปยัง SCEF AS จึงสามารถเริ่มต้นการดำเนินการกลุ่ม โดยส่งข้อมูลหรือคำสั่งควบคุมไปยังอุปกรณ์หลายเครื่องที่รวมอยู่ในกลุ่มลอจิคัลเดียว
เนื่องจากข้อเท็จจริงที่ว่าสำหรับนักพัฒนา AS การเปลี่ยนไปใช้ตัวระบุอุปกรณ์ใหม่ไม่สามารถเกิดขึ้นได้ในทันที SCEF จึงทิ้งความเป็นไปได้ในการสื่อสาร AS กับ UE ผ่านหมายเลขมาตรฐาน - MSISDN
การส่งข้อมูลการรับส่งข้อมูลที่ไม่ใช่ IP (การส่งข้อมูลที่ไม่ใช่ IP, NIDD)
ใน NB-IoT ซึ่งเป็นส่วนหนึ่งของการเพิ่มประสิทธิภาพกลไกในการส่งข้อมูลจำนวนเล็กน้อย นอกเหนือจากประเภท PDN ที่มีอยู่แล้ว เช่น IPv4, IPv6 และ IPv4v6 ยังมีประเภทอื่นปรากฏขึ้น - ไม่ใช่ IP ในกรณีนี้ อุปกรณ์ (UE) จะไม่ได้รับการกำหนดที่อยู่ IP และข้อมูลจะถูกส่งโดยไม่ใช้โปรโตคอล IP การรับส่งข้อมูลสำหรับการเชื่อมต่อดังกล่าวสามารถกำหนดเส้นทางได้สองวิธี: classic - MME -> SGW -> PGW จากนั้นผ่านอุโมงค์ PtP ไปยัง AS (รูปที่ 2) หรือใช้ SCEF (รูปที่ 3)
วิธีการแบบคลาสสิกไม่ได้ให้ข้อได้เปรียบพิเศษใดๆ เหนือการรับส่งข้อมูล IP ยกเว้นการลดขนาดของแพ็กเก็ตที่ส่งเนื่องจากไม่มีส่วนหัว IP การใช้ SCEF เปิดโอกาสให้เกิดความเป็นไปได้ใหม่ๆ มากมาย และทำให้ขั้นตอนการโต้ตอบกับอุปกรณ์ง่ายขึ้นอย่างมาก
เมื่อส่งข้อมูลผ่าน SCEF ข้อดีที่สำคัญมากสองประการจะปรากฏเหนือการรับส่งข้อมูล IP แบบคลาสสิก:
การส่งการรับส่งข้อมูล MT ไปยังอุปกรณ์ผ่าน ID ภายนอก
หากต้องการส่งข้อความไปยังอุปกรณ์ IP แบบคลาสสิก AS จะต้องทราบที่อยู่ IP ของตน ปัญหาเกิดขึ้น: เนื่องจากอุปกรณ์มักจะได้รับที่อยู่ IP "สีเทา" เมื่อลงทะเบียน อุปกรณ์จึงสื่อสารกับแอปพลิเคชันเซิร์ฟเวอร์ซึ่งอยู่บนอินเทอร์เน็ตผ่านโหนด NAT โดยที่ที่อยู่สีเทาจะถูกแปลเป็นสีขาว ที่อยู่ IP สีเทาและสีขาวผสมกันจะคงอยู่ในช่วงเวลาจำกัด ขึ้นอยู่กับการตั้งค่า NAT โดยเฉลี่ยสำหรับ TCP หรือ UDP - ไม่เกินห้านาที นั่นคือ หากไม่มีการแลกเปลี่ยนข้อมูลกับอุปกรณ์นี้ภายใน 5 นาที การเชื่อมต่อจะยุติลง และอุปกรณ์จะไม่สามารถเข้าถึงได้อีกต่อไปตามที่อยู่สีขาวซึ่งเริ่มต้นเซสชันกับ AS มีวิธีแก้ไขหลายประการ:
1. ใช้การเต้นของหัวใจ เมื่อสร้างการเชื่อมต่อแล้ว อุปกรณ์จะต้องแลกเปลี่ยนแพ็คเก็ตกับ AS ทุก ๆ สองสามนาที เพื่อป้องกันไม่ให้การแปล NAT ปิดลง แต่คงไม่มีการพูดถึงประสิทธิภาพการใช้พลังงานใดๆ ที่นี่
2. ทุกครั้ง หากจำเป็น ให้ตรวจสอบความพร้อมใช้งานของแพ็คเกจสำหรับอุปกรณ์บน AS - ส่งข้อความไปยังอัปลิงค์
3. สร้าง APN ส่วนตัว (VRF) โดยที่แอปพลิเคชันเซิร์ฟเวอร์และอุปกรณ์จะอยู่บนเครือข่ายย่อยเดียวกัน และกำหนดที่อยู่ IP แบบคงที่ให้กับอุปกรณ์ มันจะใช้งานได้ แต่แทบจะเป็นไปไม่ได้เลยเมื่อเราพูดถึงอุปกรณ์จำนวนหลายพันหรือหลายหมื่นเครื่อง
4. สุดท้าย ตัวเลือกที่เหมาะสมที่สุด: ใช้ IPv6 โดยไม่จำเป็นต้องใช้ NAT เนื่องจากที่อยู่ IPv6 สามารถเข้าถึงได้โดยตรงจากอินเทอร์เน็ต อย่างไรก็ตาม แม้ในกรณีนี้ เมื่อลงทะเบียนอุปกรณ์อีกครั้ง อุปกรณ์จะได้รับที่อยู่ IPv6 ใหม่และจะไม่สามารถเข้าถึงได้โดยใช้ที่อยู่ก่อนหน้าอีกต่อไป
ดังนั้นจึงจำเป็นต้องส่งแพ็กเก็ตการเริ่มต้นบางส่วนพร้อมตัวระบุอุปกรณ์ไปยังเซิร์ฟเวอร์เพื่อรายงานที่อยู่ IP ใหม่ของอุปกรณ์ จากนั้นรอแพ็คเก็ตยืนยันจาก AS ซึ่งส่งผลต่อประสิทธิภาพการใช้พลังงานด้วย
วิธีการเหล่านี้ทำงานได้ดีสำหรับอุปกรณ์ 2G/3G/LTE ซึ่งอุปกรณ์ไม่มีข้อกำหนดที่เข้มงวดสำหรับการทำงานอัตโนมัติ ดังนั้นจึงไม่มีข้อจำกัดด้านเวลาออกอากาศและการรับส่งข้อมูล วิธีการเหล่านี้ไม่เหมาะกับ NB-IoT เนื่องจากมีการใช้พลังงานสูง
SCEF แก้ปัญหานี้ เนื่องจากตัวระบุอุปกรณ์เพียงตัวเดียวสำหรับ AS คือ ID ภายนอก AS จึงจำเป็นต้องส่งแพ็กเก็ตข้อมูลไปยัง SCEF สำหรับ ID ภายนอกเฉพาะเท่านั้น และ SCEF จะดูแลส่วนที่เหลือ ในกรณีที่อุปกรณ์อยู่ในโหมดประหยัดพลังงาน PSM หรือ eDRX ข้อมูลจะถูกบัฟเฟอร์และส่งมอบเมื่ออุปกรณ์พร้อมใช้งาน หากอุปกรณ์พร้อมใช้งานข้อมูลจะถูกส่งทันที เช่นเดียวกับทีมผู้บริหาร
AS สามารถเรียกคืนข้อความที่บัฟเฟอร์ไปยัง UE หรือแทนที่ด้วยข้อความใหม่ได้ตลอดเวลา
กลไกการบัฟเฟอร์ยังสามารถใช้เมื่อส่งข้อมูล MO จาก UE ไปยัง AS หาก SCEF ไม่สามารถส่งข้อมูลไปยัง AS ได้ในทันที เช่น หากงานบำรุงรักษายังคงดำเนินต่อไปบนเซิร์ฟเวอร์ AS แพ็กเก็ตเหล่านี้จะถูกบัฟเฟอร์และรับประกันว่าจะถูกส่งทันทีที่ AS พร้อมใช้งาน
ตามที่ระบุไว้ข้างต้น การเข้าถึงบริการเฉพาะและ UE สำหรับ AS (และ NIDD คือบริการ) ได้รับการควบคุมโดยกฎและนโยบายในด้าน SCEF ซึ่งช่วยให้มีความเป็นไปได้เฉพาะของการใช้ข้อมูลจาก UE หนึ่งรายการพร้อมกันโดย AS หลายรายการ เหล่านั้น. หาก AS หลายรายสมัครรับข้อมูลจาก UE หนึ่งรายการ หลังจากได้รับข้อมูลจาก UE แล้ว SCEF จะส่งข้อมูลดังกล่าวไปยัง AS ที่สมัครรับข้อมูลทั้งหมด เหมาะอย่างยิ่งสำหรับกรณีที่ผู้สร้างกลุ่มอุปกรณ์เฉพาะทางแบ่งปันข้อมูลระหว่างไคลเอนต์หลายราย ตัวอย่างเช่น ด้วยการสร้างเครือข่ายสถานีตรวจอากาศที่ทำงานบน NB-IoT คุณสามารถขายข้อมูลจากสถานีเหล่านั้นไปยังบริการต่างๆ มากมายได้พร้อมกัน
รับประกันกลไกการส่งข้อความ
บริการข้อมูลที่เชื่อถือได้เป็นกลไกในการรับประกันการส่งข้อความ MO และ MT โดยไม่ใช้อัลกอริธึมพิเศษในระดับโปรโตคอล เช่น การจับมือกันใน TCP ทำงานโดยการรวมแฟล็กพิเศษไว้ในส่วนบริการของข้อความเมื่อมีการแลกเปลี่ยนระหว่าง UE และ SCEF AS เป็นผู้ตัดสินใจว่าจะเปิดใช้งานกลไกนี้เมื่อส่งข้อมูลหรือไม่
หากกลไกถูกเปิดใช้งาน UE จะรวมแฟล็กพิเศษไว้ในส่วนเหนือศีรษะของแพ็กเก็ตเมื่อต้องมีการส่งมอบการรับส่งข้อมูล MO ที่รับประกัน เมื่อได้รับแพ็กเก็ตดังกล่าว SCEF จะตอบสนองต่อ UE ด้วยการรับทราบ หาก UE ไม่ได้รับแพ็คเก็ตการตอบรับ แพ็คเก็ตที่ส่งไปยัง SCEF จะถูกส่งอีกครั้ง สิ่งเดียวกันนี้เกิดขึ้นกับการรับส่งข้อมูล MT
การตรวจสอบอุปกรณ์ (เหตุการณ์การตรวจสอบ - MONTE)
ดังที่ได้กล่าวไว้ข้างต้น ฟังก์ชัน SCEF รวมถึงฟังก์ชันสำหรับตรวจสอบสถานะของ UE ที่เรียกว่า การตรวจสอบอุปกรณ์ และหากตัวระบุใหม่และกลไกการถ่ายโอนข้อมูลเป็นการเพิ่มประสิทธิภาพ (แม้ว่าจะร้ายแรงมาก) ของขั้นตอนที่มีอยู่ MONTE ก็เป็นฟังก์ชันใหม่ที่ไม่มีอยู่ในเครือข่าย 2G/3G/LTE MONTE อนุญาตให้ AS ตรวจสอบพารามิเตอร์ของอุปกรณ์ เช่น สถานะการเชื่อมต่อ ความพร้อมในการสื่อสาร ตำแหน่ง สถานะการโรมมิ่ง ฯลฯ เราจะพูดถึงรายละเอียดเพิ่มเติมในภายหลัง
หากจำเป็นต้องเปิดใช้งานเหตุการณ์การตรวจสอบใด ๆ สำหรับอุปกรณ์หรือกลุ่มอุปกรณ์ AS จะสมัครรับบริการที่เกี่ยวข้องโดยการส่งคำสั่ง API MONTE ที่เกี่ยวข้องไปยัง SCEF ซึ่งรวมถึงพารามิเตอร์ เช่น Id ภายนอกหรือ ID กลุ่มภายนอก, ตัวระบุ AS, การตรวจสอบ ประเภท จำนวนรายงาน ที่ AS ต้องการรับ หาก AS ได้รับอนุญาตให้ดำเนินการตามคำขอ SCEF จะจัดเตรียมเหตุการณ์ให้กับ HSS หรือ MME (รูปที่ 4) ทั้งนี้ขึ้นอยู่กับประเภท เมื่อมีเหตุการณ์เกิดขึ้น MME หรือ HSS จะสร้างรายงานไปยัง SCEF ซึ่งจะส่งไปที่ AS
การจัดเตรียมกิจกรรมทั้งหมด ยกเว้น "จำนวน UE ที่ปรากฏในพื้นที่ทางภูมิศาสตร์" เกิดขึ้นผ่าน HSS สองเหตุการณ์ “การเปลี่ยนแปลงการเชื่อมโยง IMSI-IMEI” และ “สถานะการโรมมิ่ง” ได้รับการติดตามโดยตรงบน HSS ส่วนที่เหลือจะได้รับการจัดเตรียมโดย HSS บน MME
กิจกรรมอาจเป็นแบบครั้งเดียวหรือเป็นช่วงก็ได้ และจะพิจารณาตามประเภทของกิจกรรม
การส่งรายงานเกี่ยวกับเหตุการณ์ (การรายงาน) ดำเนินการโดยโหนดที่ติดตามเหตุการณ์โดยตรงไปยัง SCEF (รูปที่ 5)
จุดสำคัญ: เหตุการณ์การตรวจสอบสามารถนำไปใช้กับอุปกรณ์ที่ไม่ใช่ IP ที่เชื่อมต่อผ่าน SCEF และอุปกรณ์ IP ที่ส่งข้อมูลในรูปแบบคลาสสิกผ่าน MME-SGW-PGW
มาดูเหตุการณ์การติดตามแต่ละเหตุการณ์ให้ละเอียดยิ่งขึ้น:
สูญเสียการเชื่อมต่อ — แจ้ง AS ว่า UE ไม่สามารถใช้งานได้อีกต่อไปสำหรับการรับส่งข้อมูลหรือการส่งสัญญาณ เหตุการณ์เกิดขึ้นเมื่อ "ตัวจับเวลาการเข้าถึงผ่านมือถือ" สำหรับ UE หมดอายุใน MME ในคำขอสำหรับการตรวจสอบประเภทนี้ AS สามารถระบุค่า "เวลาในการตรวจจับสูงสุด" ได้ - หากในช่วงเวลานี้ UE ไม่แสดงกิจกรรมใดๆ AS จะได้รับแจ้งว่า UE ไม่พร้อมใช้งาน โดยระบุเหตุผล เหตุการณ์นี้ยังเกิดขึ้นหาก UE ถูกบังคับให้ลบออกโดยเครือข่ายไม่ว่าด้วยเหตุผลใดก็ตาม
* เพื่อให้เครือข่ายทราบว่าอุปกรณ์ยังคงใช้งานได้ อุปกรณ์จะเริ่มขั้นตอนการอัพเดตเป็นระยะ - การอัปเดตพื้นที่ติดตาม (TAU) ความถี่ของขั้นตอนนี้กำหนดโดยเครือข่ายโดยใช้ตัวจับเวลา T3412 หรือ (T3412_extend ในกรณีของ PSM) ค่าจะถูกส่งไปยังอุปกรณ์ในระหว่างขั้นตอนการแนบหรือ TAU ถัดไป ตัวจับเวลาการเข้าถึงผ่านมือถือมักจะนานกว่า T3412 หลายนาที หาก UE ไม่ได้สร้าง TAU ก่อนหมดเวลา "ตัวจับเวลาการเข้าถึงผ่านมือถือ" เครือข่ายจะถือว่าไม่สามารถเข้าถึงได้อีกต่อไป
ความสามารถในการเข้าถึงของ UE – ระบุเมื่อ UE พร้อมใช้งานสำหรับการรับส่งข้อมูล DL หรือ SMS สิ่งนี้เกิดขึ้นเมื่อ UE พร้อมใช้งานสำหรับเพจ (สำหรับ UE ในโหมด eDRX) หรือเมื่อ UE เข้าสู่โหมด ECM-CONNECTED (สำหรับ UE ในโหมด PSM หรือ eDRX) เช่น สร้าง TAU หรือส่งแพ็คเก็ตอัปลิงค์
การรายงานตำแหน่ง – เหตุการณ์การตรวจสอบประเภทนี้ช่วยให้ AS สามารถสอบถามตำแหน่งของ UE ได้ ตำแหน่งปัจจุบัน (ตำแหน่งปัจจุบัน) หรือตำแหน่งที่ทราบล่าสุด (ตำแหน่งที่ทราบล่าสุด ซึ่งกำหนดโดย ID เซลล์ที่อุปกรณ์สร้าง TAU หรือการรับส่งข้อมูลครั้งล่าสุด) สามารถขอได้ ซึ่งเกี่ยวข้องกับอุปกรณ์ในการประหยัดพลังงาน PSM หรือ eDRX โหมด สำหรับ "ตำแหน่งปัจจุบัน" AS สามารถขอการตอบกลับซ้ำได้ โดย MME จะแจ้ง AS ทุกครั้งที่มีการเปลี่ยนแปลงตำแหน่งของอุปกรณ์
การเปลี่ยนแปลงสมาคม IMSI-IMEI – เมื่อเปิดใช้งานกิจกรรมนี้ SCEF จะเริ่มตรวจสอบการเปลี่ยนแปลงในชุดค่าผสมของ IMSI (ตัวระบุซิมการ์ด) และ IMEI (ตัวระบุอุปกรณ์) เมื่อมีเหตุการณ์เกิดขึ้นให้แจ้ง AS สามารถใช้เพื่อเชื่อมโยง ID ภายนอกเข้ากับอุปกรณ์อีกครั้งโดยอัตโนมัติในระหว่างการเปลี่ยนทดแทนตามกำหนด หรือใช้เป็นตัวระบุสำหรับการโจรกรรมอุปกรณ์
สถานะโรมมิ่ง – AS ใช้การตรวจสอบประเภทนี้เพื่อตรวจสอบว่า UE อยู่ในเครือข่ายในบ้านหรือในเครือข่ายของพันธมิตรโรมมิ่ง นอกจากนี้ ยังสามารถส่งข้อมูล PLMN (Public Land Mobile Network) ของผู้ปฏิบัติงานที่ลงทะเบียนอุปกรณ์ไว้ได้
การสื่อสารล้มเหลว — การตรวจสอบประเภทนี้จะแจ้ง AS เกี่ยวกับความล้มเหลวในการสื่อสารกับอุปกรณ์ โดยอิงตามสาเหตุของการสูญเสียการเชื่อมต่อ (รหัสสาเหตุการเผยแพร่) ที่ได้รับจากเครือข่ายการเข้าถึงวิทยุ (โปรโตคอล S1-AP) เหตุการณ์นี้สามารถช่วยระบุสาเหตุที่การสื่อสารล้มเหลว - เนื่องจากปัญหาบนเครือข่าย เช่น เมื่อ eNodeb โอเวอร์โหลด (ทรัพยากรวิทยุไม่พร้อมใช้งาน) หรือเนื่องจากความล้มเหลวของอุปกรณ์เอง (การเชื่อมต่อวิทยุเมื่อ UE สูญหาย)
ความพร้อมใช้งานหลังจาก DDN ล้มเหลว – เหตุการณ์นี้แจ้งให้ AS ทราบว่าอุปกรณ์พร้อมใช้งานหลังจากการสื่อสารล้มเหลว สามารถใช้ได้เมื่อจำเป็นต้องถ่ายโอนข้อมูลไปยังอุปกรณ์ แต่ความพยายามครั้งก่อนไม่ประสบผลสำเร็จเนื่องจาก UE ไม่ตอบสนองต่อการแจ้งเตือนจากเครือข่าย (เพจจิ้ง) และข้อมูลไม่ได้รับการจัดส่ง หากมีการร้องขอการตรวจสอบประเภทนี้สำหรับ UE ทันทีที่อุปกรณ์ทำการสื่อสารขาเข้า สร้าง TAU หรือส่งข้อมูลไปยังอัปลิงก์ AS จะได้รับแจ้งว่าอุปกรณ์พร้อมใช้งานแล้ว เนื่องจากขั้นตอน DDN (การแจ้งเตือนข้อมูลดาวน์ลิงก์) ทำงานระหว่าง MME และ S/P-GW การตรวจสอบประเภทนี้จึงใช้ได้กับอุปกรณ์ IP เท่านั้น
สถานะการเชื่อมต่อ PDN – แจ้ง AS เมื่อสถานะอุปกรณ์เปลี่ยนแปลง (สถานะการเชื่อมต่อ PDN) - การเชื่อมต่อ (การเปิดใช้งาน PDN) หรือการตัดการเชื่อมต่อ (การลบ PDN) AS สามารถใช้สิ่งนี้เพื่อเริ่มต้นการสื่อสารกับ UE หรือในทางกลับกัน เพื่อให้เข้าใจว่าการสื่อสารไม่สามารถทำได้อีกต่อไป การตรวจสอบประเภทนี้ใช้ได้กับอุปกรณ์ IP และที่ไม่ใช่ IP
จำนวน UE ที่มีอยู่ในพื้นที่ทางภูมิศาสตร์ – AS ใช้การตรวจสอบประเภทนี้เพื่อกำหนดจำนวน UE ในพื้นที่ทางภูมิศาสตร์ที่กำหนด
อุปกรณ์ทริกเกอร์)
ในเครือข่าย 2G/3G ขั้นตอนการลงทะเบียนในเครือข่ายเป็นแบบสองขั้นตอน: ขั้นแรก อุปกรณ์ที่ลงทะเบียนกับ SGSN (ขั้นตอนการแนบ) จากนั้น หากจำเป็น จะเปิดใช้งานบริบท PDP - การเชื่อมต่อกับแพ็กเก็ตเกตเวย์ (GGSN) เพื่อส่งข้อมูล ในเครือข่าย 3G ขั้นตอนทั้งสองนี้เกิดขึ้นตามลำดับคือ อุปกรณ์ไม่ได้รอสักครู่เมื่อจำเป็นต้องถ่ายโอนข้อมูล แต่เปิดใช้งาน PDP ทันทีหลังจากขั้นตอนการแนบเสร็จสมบูรณ์ ใน LTE ขั้นตอนทั้งสองนี้ถูกรวมเป็นหนึ่งเดียว กล่าวคือ เมื่อเชื่อมต่อ อุปกรณ์จะร้องขอการเปิดใช้งานการเชื่อมต่อ PDN ทันที (คล้ายกับ PDP ใน 2G/3G) ผ่าน eNodeB ไปยัง MME-SGW-PGW
NB-IoT กำหนดวิธีการเชื่อมต่อเป็น "แนบโดยไม่มี PDN" กล่าวคือ UE เชื่อมต่อโดยไม่สร้างการเชื่อมต่อ PDN ในกรณีนี้ ไม่สามารถส่งข้อมูลการรับส่งข้อมูล และสามารถรับหรือส่ง SMS เท่านั้น เพื่อส่งคำสั่งไปยังอุปกรณ์ดังกล่าวเพื่อเปิดใช้งาน PDN และเชื่อมต่อกับ AS จึงมีการพัฒนาฟังก์ชัน "การทริกเกอร์อุปกรณ์"
เมื่อได้รับคำสั่งให้เชื่อมต่อ UE จาก AS แล้ว SCEF จะเริ่มส่ง SMS ควบคุมไปยังอุปกรณ์ผ่านศูนย์ SMS เมื่อได้รับ SMS อุปกรณ์จะเปิดใช้งาน PDN และเชื่อมต่อกับ AS เพื่อรับคำแนะนำเพิ่มเติมหรือถ่ายโอนข้อมูล
อาจมีบางครั้งที่การสมัครอุปกรณ์ของคุณหมดอายุใน SCEF ใช่ การสมัครสมาชิกมีอายุการใช้งานของตัวเอง กำหนดโดยผู้ให้บริการหรือตกลงกับ AS เมื่อหมดอายุ PDN จะถูกปิดการใช้งานบน MME และอุปกรณ์จะไม่สามารถใช้งานได้กับ AS ในกรณีนี้ฟังก์ชัน "การเรียกใช้อุปกรณ์" จะช่วยได้เช่นกัน เมื่อได้รับข้อมูลใหม่จาก AS SCEF จะค้นหาสถานะการเชื่อมต่ออุปกรณ์และส่งข้อมูลผ่านช่องทาง SMS
ข้อสรุป
แน่นอนว่าฟังก์ชันการทำงานของ SCEF ไม่ได้จำกัดอยู่เพียงบริการที่อธิบายไว้ข้างต้น และมีการพัฒนาและขยายอย่างต่อเนื่อง ปัจจุบันบริการมากกว่าหนึ่งโหลได้รับมาตรฐานสำหรับ SCEF แล้ว ตอนนี้เราได้สัมผัสเฉพาะฟังก์ชั่นหลักที่เป็นที่ต้องการของนักพัฒนาเท่านั้น เราจะพูดถึงส่วนที่เหลือในบทความหน้า
คำถามเกิดขึ้นทันที: จะทดสอบการเข้าถึงโหนด "ปาฏิหาริย์" นี้เพื่อการทดสอบเบื้องต้นและการดีบักกรณีที่เป็นไปได้ได้อย่างไร ทุกอย่างง่ายมาก นักพัฒนาซอฟต์แวร์คนใดสามารถส่งคำขอไปที่ [ป้องกันอีเมล]ซึ่งเพียงพอที่จะระบุวัตถุประสงค์ของการเชื่อมต่อ คำอธิบายกรณีที่เป็นไปได้ และข้อมูลการติดต่อเพื่อการสื่อสาร
แล้วพบกันใหม่!
ผู้เขียน:
- ผู้เชี่ยวชาญอาวุโสของแผนกโซลูชันแบบบรรจบกันและบริการมัลติมีเดีย Sergey Novikov ,
- ผู้เชี่ยวชาญของแผนกโซลูชันแบบหลอมรวมและบริการมัลติมีเดีย Alexey Lapshin
ที่มา: will.com