NB-IoT: ມັນເຮັດວຽກແນວໃດ? ສ່ວນທີ 3: SCEF – ປ່ອງຢ້ຽມດຽວຂອງການເຂົ້າເຖິງການບໍລິການຂອງຜູ້ປະກອບການ

ໃນບົດຂຽນ“NB-IoT: ມັນເຮັດວຽກແນວໃດ? ພາກທີ 2", ເວົ້າກ່ຽວກັບສະຖາປັດຕະຍະກໍາຂອງ packet core ຂອງເຄືອຂ່າຍ NB-IoT, ພວກເຮົາໄດ້ກ່າວເຖິງຮູບລັກສະນະຂອງ SCEF node ໃຫມ່. ພວກເຮົາອະທິບາຍໃນສ່ວນທີສາມວ່າມັນແມ່ນຫຍັງແລະເປັນຫຍັງມັນຈຶ່ງຕ້ອງການ?

ເມື່ອສ້າງບໍລິການ M2M, ຜູ້ພັດທະນາແອັບພລິເຄຊັນປະເຊີນກັບຄໍາຖາມຕໍ່ໄປນີ້:

• ວິທີການກໍານົດອຸປະກອນ;
• ຂັ້ນຕອນການຢັ້ງຢືນ ແລະການກວດສອບອັນໃດທີ່ຈະໃຊ້;
• ພິທີການການຂົນສົ່ງໃດທີ່ຈະເລືອກເອົາສໍາລັບການພົວພັນກັບອຸປະກອນ;
• ວິ​ທີ​ການ​ໃຫ້​ຂໍ້​ມູນ​ທີ່​ເຊື່ອ​ຖື​ໄດ້​ກັບ​ອຸ​ປະ​ກອນ​;
• ວິທີການຈັດຕັ້ງແລະສ້າງກົດລະບຽບສໍາລັບການແລກປ່ຽນຂໍ້ມູນກັບພວກເຂົາ;
• ວິທີການຕິດຕາມກວດກາແລະໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບສະພາບຂອງເຂົາເຈົ້າອອນໄລນ໌;
• ວິທີການສົ່ງຂໍ້ມູນພ້ອມກັນກັບກຸ່ມຂອງອຸປະກອນຂອງທ່ານ;
• ວິທີການສົ່ງຂໍ້ມູນພ້ອມກັນຈາກອຸປະກອນຫນຶ່ງໄປຫາລູກຄ້າຫຼາຍໆຄົນ;
• ວິທີການເຂົ້າເຖິງແບບປະສົມປະສານກັບການບໍລິການຜູ້ປະກອບການເພີ່ມເຕີມສໍາລັບການຄຸ້ມຄອງອຸປະກອນຂອງທ່ານ.

ເພື່ອແກ້ໄຂພວກມັນ, ມັນຈໍາເປັນຕ້ອງສ້າງການແກ້ໄຂ "ຫນັກ" ທາງດ້ານເຕັກນິກທີ່ເປັນເຈົ້າຂອງ, ເຊິ່ງເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍແຮງງານເພີ່ມຂຶ້ນແລະການບໍລິການເວລາຕະຫຼາດ. ນີ້ແມ່ນບ່ອນທີ່ node SCEF ໃຫມ່ມາຊ່ວຍ.

ຕາມທີ່ກຳນົດໄວ້ໂດຍ 3GPP, SCEF (ຟັງຊັນການເປີດເຜີຍຄວາມສາມາດໃນການບໍລິການ) ແມ່ນອົງປະກອບອັນໃໝ່ທັງໝົດຂອງສະຖາປັດຕະຍະກຳ 3GPP ທີ່ມີໜ້າທີ່ໃນການເປີດເຜີຍການບໍລິການ ແລະຄວາມສາມາດຢ່າງປອດໄພທີ່ສະໜອງໃຫ້ໂດຍການໂຕ້ຕອບເຄືອຂ່າຍ 3GPP ຜ່ານ APIs.

ໃນຄໍາສັບຕ່າງໆງ່າຍດາຍ, SCEF ແມ່ນຕົວກາງລະຫວ່າງເຄືອຂ່າຍແລະເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນ (AS), ປ່ອງຢ້ຽມດຽວຂອງການເຂົ້າເຖິງການບໍລິການຂອງຜູ້ປະຕິບັດງານສໍາລັບການຄຸ້ມຄອງອຸປະກອນ M2M ຂອງທ່ານໃນເຄືອຂ່າຍ NB-IoT ຜ່ານການໂຕ້ຕອບ API ທີ່ເຂົ້າໃຈໄດ້ມາດຕະຖານ.

SCEF ເຊື່ອງຄວາມຊັບຊ້ອນຂອງເຄືອຂ່າຍຂອງຜູ້ປະຕິບັດການ, ອະນຸຍາດໃຫ້ຜູ້ພັດທະນາແອັບພລິເຄຊັນສາມາດຖອດຖອນກົນໄກທີ່ສະລັບສັບຊ້ອນ, ສະເພາະອຸປະກອນສໍາລັບການພົວພັນກັບອຸປະກອນຕ່າງໆ.

ໂດຍການປ່ຽນໂປຣໂຕຄອນເຄືອຂ່າຍເປັນ API ທີ່ຄຸ້ນເຄີຍສໍາລັບຜູ້ພັດທະນາແອັບພລິເຄຊັນ, SCEF API ອຳນວຍຄວາມສະດວກໃຫ້ແກ່ການສ້າງບໍລິການໃໝ່ໆ ແລະຫຼຸດຜ່ອນເວລາຕໍ່ຕະຫຼາດ. node ໃຫມ່ຍັງປະກອບມີຫນ້າທີ່ສໍາລັບການກໍານົດ / ການກວດສອບອຸປະກອນມືຖື, ກໍານົດກົດລະບຽບສໍາລັບການແລກປ່ຽນຂໍ້ມູນລະຫວ່າງອຸປະກອນແລະ 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. ຢ່າງໃດກໍຕາມ, ໃນການປະຕິບັດທັງຫມົດ, ການເຮັດວຽກຂອງ node ໄດ້ຖືກລວມເຂົ້າໃນ. SCEF, ດັ່ງນັ້ນເພື່ອຄວາມງ່າຍດາຍຂອງວົງຈອນ, ພວກເຮົາຈະບໍ່ພິຈາລະນາມັນແຍກຕ່າງຫາກ). ໃຊ້ເພື່ອຮັບຂໍ້ມູນເສັ້ນທາງສຳລັບການສົ່ງ SMS ແລະການໂຕ້ຕອບກັບສູນ SMS.

T8 - ການໂຕ້ຕອບ API ສໍາລັບການໂຕ້ຕອບ SCEF ກັບເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນ. ທັງຄໍາສັ່ງຄວບຄຸມແລະການຈະລາຈອນຖືກສົ່ງຜ່ານການໂຕ້ຕອບນີ້.

* ໃນ​ຄວາມ​ເປັນ​ຈິງ​ແລ້ວ​ມີ​ການ​ໂຕ້​ຕອບ​ຫຼາຍ​ກວ່າ​, ມີ​ພຽງ​ແຕ່​ພື້ນ​ຖານ​ທີ່​ສຸດ​ທີ່​ມີ​ລາຍ​ການ​ຢູ່​ທີ່​ນີ້​. ບັນຊີລາຍຊື່ຄົບຖ້ວນແມ່ນໃຫ້ຢູ່ໃນ 3GPP 23.682 (4.3.2 ບັນຊີລາຍຊື່ຂອງຈຸດອ້າງອີງ).

ຂ້າງລຸ່ມນີ້ແມ່ນຫນ້າທີ່ແລະການບໍລິການທີ່ສໍາຄັນຂອງ SCEF:

• ການເຊື່ອມໂຍງຕົວລະບຸ SIM card (IMSI) ກັບ ID ພາຍນອກ;
• ການສົ່ງຕໍ່ການຈະລາຈອນທີ່ບໍ່ແມ່ນ IP (Non-IP Data Delivery, NIDD);
• ການດໍາເນີນງານກຸ່ມໂດຍໃຊ້ ID ກຸ່ມພາຍນອກ;
• ສະຫນັບສະຫນູນຮູບແບບການສົ່ງຂໍ້ມູນທີ່ມີການຢືນຢັນ;
• buffering ຂອງ MO (Mobile Originated) ແລະ MT (Mobile Terminated) ຂໍ້ມູນ;
• ການກວດສອບແລະການອະນຸຍາດຂອງອຸປະກອນແລະເຄື່ອງແມ່ຂ່າຍຂອງຄໍາຮ້ອງສະຫມັກ;
• ການນໍາໃຊ້ພ້ອມກັນຂອງຂໍ້ມູນຈາກຫນຶ່ງ UE ໂດຍຫຼາຍ ASEs;
• ສະ​ຫນັບ​ສະ​ຫນູນ​ສໍາ​ລັບ​ຫນ້າ​ທີ່​ການ​ຕິດ​ຕາມ​ສະ​ຖາ​ນະ​ພາບ UE ພິ​ເສດ (MONTE – Monitoring Events);
• ການກະຕຸ້ນອຸປະກອນ;
• ສະໜອງຂໍ້ມູນໂຣມມິງທີ່ບໍ່ແມ່ນ IP.

ຫຼັກການພື້ນຖານຂອງການພົວພັນລະຫວ່າງ AS ແລະ SCEF ແມ່ນອີງໃສ່ໂຄງການທີ່ເອີ້ນວ່າ. ການສະໝັກໃຊ້. ຖ້າມັນເປັນສິ່ງຈໍາເປັນເພື່ອເຂົ້າເຖິງການບໍລິການ SCEF ໃດໆສໍາລັບ UE ສະເພາະ, ເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນຕ້ອງການສ້າງການສະຫມັກໂດຍການສົ່ງຄໍາສັ່ງໄປຫາ API ສະເພາະຂອງບໍລິການທີ່ຮ້ອງຂໍແລະໄດ້ຮັບຕົວກໍານົດທີ່ເປັນເອກະລັກໃນການຕອບສະຫນອງ. ຫຼັງຈາກນັ້ນ, ທຸກໆການກະທໍາເພີ່ມເຕີມແລະການສື່ສານກັບ UE ພາຍໃນກອບຂອງການບໍລິການນີ້ຈະເກີດຂຶ້ນໂດຍໃຊ້ຕົວລະບຸນີ້.

ID ພາຍນອກ: ຕົວລະບຸອຸປະກອນທົ່ວໄປ

ຫນຶ່ງໃນການປ່ຽນແປງທີ່ສໍາຄັນທີ່ສຸດໃນໂຄງການປະຕິສໍາພັນລະຫວ່າງ AS ແລະອຸປະກອນໃນເວລາທີ່ເຮັດວຽກຜ່ານ SCEF ແມ່ນການປະກົດຕົວຂອງຕົວກໍານົດທົ່ວໄປ. ໃນປັດຈຸບັນ, ແທນທີ່ຈະເປັນເບີໂທລະສັບ (MSISDN) ຫຼືທີ່ຢູ່ IP, ເຊັ່ນດຽວກັບກໍລະນີໃນເຄືອຂ່າຍ 2G/3G/LTE ຄລາສສິກ, ຕົວລະບຸອຸປະກອນສໍາລັບເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນຈະກາຍເປັນ "ID ພາຍນອກ". ມັນຖືກກໍານົດໂດຍມາດຕະຖານໃນຮູບແບບ “@” ທີ່ຄຸ້ນເຄີຍກັບນັກພັດທະນາແອັບພລິເຄຊັນ.

ຜູ້ພັດທະນາບໍ່ຈໍາເປັນຕ້ອງປະຕິບັດລະບົບການພິສູດຢືນຢັນອຸປະກອນອີກຕໍ່ໄປ; ເຄືອຂ່າຍຈະປະຕິບັດຫນ້າທີ່ນີ້ຢ່າງສົມບູນ. ID ພາຍນອກຖືກຜູກມັດກັບ IMSI, ແລະຜູ້ພັດທະນາສາມາດແນ່ໃຈວ່າເມື່ອເຂົ້າເຖິງ ID ພາຍນອກສະເພາະ, ມັນພົວພັນກັບ SIM card ສະເພາະ. ໃນ​ເວ​ລາ​ທີ່​ການ​ນໍາ​ໃຊ້​ຊິ​ມ​ຊິມ​, ທ່ານ​ຈະ​ໄດ້​ຮັບ​ສະ​ຖາ​ນະ​ການ​ເປັນ​ເອ​ກະ​ລັກ​ທີ່​ສົມ​ບູນ​ໃນ​ເວ​ລາ​ທີ່ ID ພາຍນອກ​ລະ​ບຸ​ອຸ​ປະ​ກອນ​ສະ​ເພາະ​ໃດ​ຫນຶ່ງ​!

ຍິ່ງໄປກວ່ານັ້ນ, ID ພາຍນອກຫຼາຍສາມາດເຊື່ອມໂຍງກັບຫນຶ່ງ IMSI - ສະຖານະການທີ່ຫນ້າສົນໃຈຫຼາຍເກີດຂື້ນເມື່ອ ID ພາຍນອກກໍານົດສະເພາະຄໍາຮ້ອງສະຫມັກທີ່ຮັບຜິດຊອບສໍາລັບການບໍລິການສະເພາະໃດຫນຶ່ງໃນອຸປະກອນສະເພາະໃດຫນຶ່ງ.

ຕົວລະບຸກຸ່ມຍັງປາກົດ - ID ກຸ່ມພາຍນອກ, ເຊິ່ງລວມມີຊຸດຂອງ ID ພາຍນອກຂອງບຸກຄົນ. ໃນປັດຈຸບັນ, ດ້ວຍການຮ້ອງຂໍຫນຶ່ງໄປຫາ SCEF, AS ສາມາດລິເລີ່ມການດໍາເນີນງານຂອງກຸ່ມ - ການສົ່ງຂໍ້ມູນຫຼືຄໍາສັ່ງຄວບຄຸມໄປຫາອຸປະກອນຫຼາຍອັນລວມຢູ່ໃນກຸ່ມຢ່າງມີເຫດຜົນດຽວ.

ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າສໍາລັບນັກພັດທະນາ AS, ການຫັນປ່ຽນໄປສູ່ຕົວກໍານົດອຸປະກອນໃຫມ່ບໍ່ສາມາດເກີດຂຶ້ນໄດ້ທັນທີ, SCEF ໄດ້ປະໄວ້ຄວາມເປັນໄປໄດ້ຂອງການສື່ສານ AS ກັບ UE ຜ່ານຕົວເລກມາດຕະຖານ - MSISDN.

ການສົ່ງຂໍ້ມູນການຈະລາຈອນທີ່ບໍ່ແມ່ນ IP (ການສົ່ງຂໍ້ມູນທີ່ບໍ່ແມ່ນ IP, NIDD)

ໃນ NB-IoT, ເປັນສ່ວນຫນຶ່ງຂອງການເພີ່ມປະສິດທິພາບຂອງກົນໄກສໍາລັບການສົ່ງຂໍ້ມູນຂະຫນາດນ້ອຍ, ນອກເຫນືອຈາກປະເພດ PDN ທີ່ມີຢູ່ແລ້ວເຊັ່ນ IPv4, IPv6 ແລະ IPv4v6, ປະເພດອື່ນໄດ້ປາກົດ - ບໍ່ແມ່ນ IP. ໃນ​ກໍ​ລະ​ນີ​ນີ້, ອຸ​ປະ​ກອນ (UE) ບໍ່​ໄດ້​ຮັບ​ມອບ​ຫມາຍ​ເປັນ​ທີ່​ຢູ່ IP ແລະ​ຂໍ້​ມູນ​ຈະ​ຖືກ​ສົ່ງ​ໂດຍ​ບໍ່​ມີ​ການ​ນໍາ​ໃຊ້ IP protocol. ການຈະລາຈອນສໍາລັບການເຊື່ອມຕໍ່ດັ່ງກ່າວສາມາດຖືກນໍາທາງໃນສອງທາງ: ຄລາສສິກ - MME -> SGW -> PGW ແລະຫຼັງຈາກນັ້ນຜ່ານອຸໂມງ PtP ໄປ AS (ຮູບ 2) ຫຼືໃຊ້ SCEF (ຮູບ 3).

ວິທີການຄລາສສິກບໍ່ໄດ້ສະເຫນີຂໍ້ໄດ້ປຽບພິເສດໃດໆກ່ຽວກັບການຈະລາຈອນ IP, ຍົກເວັ້ນການຫຼຸດຜ່ອນຂະຫນາດຂອງແພັກເກັດທີ່ສົ່ງເນື່ອງຈາກບໍ່ມີສ່ວນຫົວ IP. ການນໍາໃຊ້ SCEF ເປີດຄວາມເປັນໄປໄດ້ໃຫມ່ຈໍານວນຫນຶ່ງແລະເຮັດໃຫ້ຂັ້ນຕອນການພົວພັນກັບອຸປະກອນງ່າຍຂຶ້ນ.

ເມື່ອສົ່ງຂໍ້ມູນຜ່ານ SCEF, ສອງຂໍ້ໄດ້ປຽບທີ່ມີຄວາມສໍາຄັນຫຼາຍປາກົດຢູ່ໃນການຈະລາຈອນ IP ແບບຄລາສສິກ:


ການຈັດສົ່ງການຈະລາຈອນ MT ໄປຫາອຸປະກອນຜ່ານ ID ພາຍນອກ

ເພື່ອສົ່ງຂໍ້ຄວາມໄປຫາອຸປະກອນ IP ຄລາສສິກ, AS ຕ້ອງຮູ້ທີ່ຢູ່ IP ຂອງມັນ. ນີ້ແມ່ນບັນຫາທີ່ເກີດຂື້ນ: ເນື່ອງຈາກອຸປະກອນມັກຈະໄດ້ຮັບທີ່ຢູ່ IP "ສີຂີ້ເຖົ່າ" ເມື່ອລົງທະບຽນ, ມັນຕິດຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນ, ເຊິ່ງຕັ້ງຢູ່ໃນອິນເຕີເນັດ, ຜ່ານ NAT node, ບ່ອນທີ່ທີ່ຢູ່ສີຂີ້ເຖົ່າຖືກແປເປັນສີຂາວ. ການປະສົມປະສານຂອງທີ່ຢູ່ IP ສີຂີ້ເຖົ່າແລະສີຂາວໃຊ້ເວລາຈໍາກັດ, ຂຶ້ນກັບການຕັ້ງຄ່າ NAT. ໂດຍສະເລ່ຍ, ສໍາລັບ TCP ຫຼື UDP - ບໍ່ເກີນຫ້ານາທີ. ນັ້ນແມ່ນ, ຖ້າບໍ່ມີການແລກປ່ຽນຂໍ້ມູນກັບອຸປະກອນນີ້ພາຍໃນ 5 ນາທີ, ການເຊື່ອມຕໍ່ຈະແຕກແຍກແລະອຸປະກອນຈະບໍ່ສາມາດເຂົ້າເຖິງທີ່ຢູ່ສີຂາວທີ່ກອງປະຊຸມກັບ AS ໄດ້ເລີ່ມຕົ້ນ. ມີຫຼາຍວິທີແກ້ໄຂ:

1. ໃຊ້ການເຕັ້ນຂອງຫົວໃຈ. ເມື່ອການເຊື່ອມຕໍ່ໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນ, ອຸປະກອນຈະຕ້ອງແລກປ່ຽນແພັກເກັດກັບ AS ທຸກໆສອງສາມນາທີ, ດັ່ງນັ້ນການປ້ອງກັນການແປພາສາ NAT ຈາກການປິດ. ແຕ່ບໍ່ສາມາດເວົ້າໄດ້ກ່ຽວກັບປະສິດທິພາບພະລັງງານໃດໆຢູ່ທີ່ນີ້.

2. ທຸກໆຄັ້ງ, ຖ້າຈໍາເປັນ, ກວດເບິ່ງຄວາມພ້ອມຂອງແພັກເກດສໍາລັບອຸປະກອນໃນ AS - ສົ່ງຂໍ້ຄວາມໄປຫາ uplink.

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​, ຂໍ້​ມູນ​ຈະ​ໄດ້​ຮັບ​ການ buffed ແລະ​ສົ່ງ​ໃນ​ເວ​ລາ​ທີ່​ອຸ​ປະ​ກອນ​ມີ​ໃຫ້​. ຖ້າອຸປະກອນສາມາດໃຊ້ໄດ້ສໍາລັບການຈະລາຈອນ, ຂໍ້ມູນຈະຖືກຈັດສົ່ງທັນທີ. ດຽວກັນນີ້ແມ່ນຄວາມຈິງສໍາລັບທີມງານຄຸ້ມຄອງ.

ໄດ້ທຸກເວລາ, AS ສາມາດເອີ້ນຄືນຂໍ້ຄວາມທີ່ buffed ໄປຫາ UE ຫຼືປ່ຽນມັນດ້ວຍອັນໃຫມ່.

ກົນໄກ buffering ຍັງສາມາດຖືກນໍາໃຊ້ໃນເວລາທີ່ສົ່ງຂໍ້ມູນ MO ຈາກ UE ກັບ AS. ຖ້າ SCEF ບໍ່ສາມາດສົ່ງຂໍ້ມູນໄປຫາ AS ໄດ້ທັນທີ, ຕົວຢ່າງເຊັ່ນຖ້າວຽກງານບໍາລຸງຮັກສາແມ່ນດໍາເນີນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ AS, ແພັກເກັດເຫຼົ່ານີ້ຈະຖືກຂັດຂວາງແລະຮັບປະກັນວ່າຈະຖືກຈັດສົ່ງທັນທີທີ່ AS ສາມາດໃຊ້ໄດ້.

ດັ່ງທີ່ໄດ້ກ່າວໄວ້ຂ້າງເທິງ, ການເຂົ້າເຖິງການບໍລິການສະເພາະແລະ UE ສໍາລັບ AS (ແລະ NIDD ແມ່ນການບໍລິການ) ແມ່ນຖືກຄວບຄຸມໂດຍກົດລະບຽບແລະນະໂຍບາຍໃນດ້ານ SCEF, ເຊິ່ງອະນຸຍາດໃຫ້ມີຄວາມເປັນໄປໄດ້ທີ່ເປັນເອກະລັກຂອງການນໍາໃຊ້ຂໍ້ມູນພ້ອມກັນຈາກຫນຶ່ງ UE ໂດຍຫຼາຍໆ ASes. ເຫຼົ່ານັ້ນ. ຖ້າ AS ຫຼາຍໆຄົນໄດ້ລົງທະບຽນກັບ UE ຫນຶ່ງ, ຫຼັງຈາກນັ້ນຫຼັງຈາກໄດ້ຮັບຂໍ້ມູນຈາກ UE, SCEF ຈະສົ່ງມັນໄປຫາ AS ທັງຫມົດທີ່ຈອງ. ນີ້ແມ່ນເຫມາະສົມດີສໍາລັບກໍລະນີທີ່ຜູ້ສ້າງຂອງເຮືອອຸປະກອນພິເສດແບ່ງປັນຂໍ້ມູນລະຫວ່າງລູກຄ້າຈໍານວນຫນຶ່ງ. ຕົວຢ່າງ, ໂດຍການສ້າງເຄືອຂ່າຍຂອງສະຖານີສະພາບອາກາດທີ່ເຮັດວຽກຢູ່ໃນ NB-IoT, ທ່ານສາມາດຂາຍຂໍ້ມູນຈາກພວກມັນໃຫ້ກັບການບໍລິການຫຼາຍຢ່າງພ້ອມກັນ.

ກົນໄກການຈັດສົ່ງຂໍ້ຄວາມຮັບປະກັນ

ການບໍລິການຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້ແມ່ນກົນໄກສໍາລັບການຮັບປະກັນການຈັດສົ່ງຂໍ້ຄວາມ MO ແລະ MT ໂດຍບໍ່ມີການນໍາໃຊ້ algorithms ພິເສດໃນລະດັບໂປໂຕຄອນ, ເຊັ່ນ: ການຈັບມືໃນ 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 identifier, ການຕິດຕາມ. ປະເພດ, ຈໍານວນຂອງບົດລາຍງານ, ທີ່ AS ຕ້ອງການທີ່ຈະໄດ້ຮັບ. ຖ້າ AS ໄດ້ຮັບອະນຸຍາດໃຫ້ປະຕິບັດການຮ້ອງຂໍ, SCEF, ຂຶ້ນກັບປະເພດ, ຈະສະຫນອງເຫດການໃຫ້ກັບ HSS ຫຼື MME (ຮູບ 4). ເມື່ອເຫດການເກີດຂຶ້ນ, MME ຫຼື HSS ສ້າງບົດລາຍງານໃຫ້ SCEF, ເຊິ່ງສົ່ງມັນໄປຫາ AS.

ການສະຫນອງເຫດການທັງຫມົດ, ຍົກເວັ້ນ "ຈໍານວນຂອງ UE ທີ່ມີຢູ່ໃນເຂດພູມສາດ", ເກີດຂຶ້ນຜ່ານ HSS. ສອງເຫດການ "ການປ່ຽນແປງຂອງສະມາຄົມ IMSI-IMEI" ແລະ "ສະຖານະໂຣມມິງ" ແມ່ນຖືກຕິດຕາມໂດຍກົງໃນ HSS, ສ່ວນທີ່ເຫຼືອຈະຖືກຈັດໃຫ້ໂດຍ HSS ໃນ MME.
ເຫດການສາມາດເປັນຄັ້ງດຽວ ຫຼືເປັນໄລຍະ, ແລະຖືກກໍານົດໂດຍປະເພດຂອງມັນ.

ການສົ່ງບົດລາຍງານກ່ຽວກັບເຫດການ (ການລາຍງານ) ແມ່ນດໍາເນີນໂດຍ node ທີ່ຕິດຕາມເຫດການໂດຍກົງກັບ SCEF (ຮູບ 5).

ຈຸດສໍາຄັນ: ການຕິດຕາມເຫດການສາມາດຖືກນໍາໃຊ້ກັບທັງສອງອຸປະກອນທີ່ບໍ່ແມ່ນ IP ທີ່ເຊື່ອມຕໍ່ຜ່ານ SCEF ແລະອຸປະກອນ IP ທີ່ສົ່ງຂໍ້ມູນໃນແບບຄລາສສິກຜ່ານ MME-SGW-PGW.

ຂໍໃຫ້ພິຈາລະນາຢ່າງລະອຽດໃນແຕ່ລະເຫດການການຕິດຕາມ:

ການສູນເສຍການເຊື່ອມຕໍ່ — ແຈ້ງ​ໃຫ້ AS ວ່າ UE ບໍ່​ມີ​ຕໍ່​ໄປ​ແລ້ວ​ສໍາ​ລັບ​ການ​ຈະ​ລາ​ຈອນ​ຂໍ້​ມູນ​ຫຼື​ສັນ​ຍານ​. ເຫດການເກີດຂຶ້ນເມື່ອ “ໂມງຈັບເວລາເຂົ້າເຖິງມືຖື” ສໍາລັບ UE ໝົດອາຍຸໃນ MME. ໃນການຮ້ອງຂໍສໍາລັບການຕິດຕາມກວດກາປະເພດນີ້, AS ສາມາດຊີ້ບອກມູນຄ່າ "ເວລາກວດຫາສູງສຸດ" ຂອງມັນ - ຖ້າໃນລະຫວ່າງເວລານີ້ UE ບໍ່ສະແດງກິດຈະກໍາໃດໆ, AS ຈະຖືກແຈ້ງໃຫ້ຊາບວ່າ UE ບໍ່ສາມາດໃຊ້ໄດ້, ຊີ້ບອກເຫດຜົນ. ເຫດການດັ່ງກ່າວຍັງເກີດຂື້ນຖ້າ UE ຖືກບັງຄັບໂດຍເຄືອຂ່າຍໂດຍເຫດຜົນໃດກໍ່ຕາມ.

* ເພື່ອໃຫ້ເຄືອຂ່າຍຮູ້ວ່າອຸປະກອນຍັງມີຢູ່, ມັນເລີ່ມຂັ້ນຕອນການອັບເດດເປັນໄລຍະ - Tracking Area Update (TAU). ຄວາມຖີ່ຂອງຂັ້ນຕອນນີ້ແມ່ນຖືກກໍານົດໂດຍເຄືອຂ່າຍໂດຍໃຊ້ຕົວຈັບເວລາ T3412 ຫຼື (T3412_extended ໃນກໍລະນີຂອງ PSM), ມູນຄ່າທີ່ຖືກສົ່ງໄປຫາອຸປະກອນໃນລະຫວ່າງຂັ້ນຕອນ Attach ຫຼື TAU ຕໍ່ໄປ. ເຄື່ອງຈັບເວລາການເຂົ້າເຖິງມືຖືໂດຍປົກກະຕິແມ່ນຫຼາຍນາທີຍາວກວ່າ T3412. ຖ້າ UE ບໍ່ໄດ້ເຮັດ TAU ກ່ອນທີ່ຈະຫມົດອາຍຸຂອງ "ໂມງຈັບເວລາການເຂົ້າເຖິງມືຖື", ເຄືອຂ່າຍຖືວ່າມັນບໍ່ສາມາດເຂົ້າເຖິງໄດ້.

ການ​ເຂົ້າ​ເຖິງ UE – ຊີ້ບອກເວລາທີ່ UE ສາມາດໃຊ້ໄດ້ສໍາລັບການຈາລະຈອນ DL ຫຼື SMS. ອັນນີ້ເກີດຂຶ້ນເມື່ອ UE ສາມາດໃຊ້ໄດ້ສໍາລັບຫນ້າເວັບ (ສໍາລັບ UE ໃນໂຫມດ eDRX) ຫຼືເມື່ອ UE ເຂົ້າສູ່ໂໝດ ECM-CONNECTED (ສໍາລັບ UE ໃນໂຫມດ PSM ຫຼື eDRX), i.e. ເຮັດໃຫ້ TAU ຫຼືສົ່ງແພັກເກັດ uplink.

ການ​ລາຍ​ງານ​ສະ​ຖານ​ທີ່​ – ປະເພດຂອງເຫດການການຕິດຕາມນີ້ອະນຸຍາດໃຫ້ AS ສອບຖາມສະຖານທີ່ຂອງ UE. ບໍ່ວ່າຈະເປັນສະຖານທີ່ປະຈຸບັນ (ສະຖານທີ່ປະຈຸບັນ) ຫຼືສະຖານທີ່ສຸດທ້າຍທີ່ຮູ້ຈັກ (ກໍານົດໂດຍ ID ຕາລາງຈາກອຸປະກອນທີ່ເຮັດ TAU ຫຼືການສົ່ງຕໍ່ຄັ້ງສຸດທ້າຍ) ສາມາດຮ້ອງຂໍໄດ້, ເຊິ່ງກ່ຽວຂ້ອງກັບອຸປະກອນໃນ PSM ຫຼື eDRX ຮູບແບບການປະຫຍັດພະລັງງານ. ສຳລັບ “ສະຖານທີ່ປັດຈຸບັນ”, AS ສາມາດຮ້ອງຂໍການຕອບກັບຊ້ຳໆ, ໂດຍ MME ຈະແຈ້ງໃຫ້ AS ໃນແຕ່ລະຄັ້ງທີ່ສະຖານທີ່ຂອງອຸປະກອນມີການປ່ຽນແປງ.

ການປ່ຽນແປງຂອງສະມາຄົມ IMSI-IMEI – ເມື່ອເຫດການນີ້ຖືກເປີດໃຊ້, SCEF ເລີ່ມຕິດຕາມການປ່ຽນແປງໃນການປະສົມປະສານຂອງ IMSI (ຕົວລະບຸບັດ SIM) ແລະ IMEI (ຕົວລະບຸອຸປະກອນ). ເມື່ອເຫດການເກີດຂຶ້ນ, ແຈ້ງໃຫ້ AS. ສາມາດຖືກນໍາໃຊ້ເພື່ອ rebind ID ພາຍນອກອັດຕະໂນມັດກັບອຸປະກອນໃນລະຫວ່າງການເຮັດວຽກທົດແທນທີ່ກໍານົດເວລາຫຼືເຮັດຫນ້າທີ່ເປັນຕົວລະບຸສໍາລັບການລັກອຸປະກອນ.

ສະຖານະໂຣມມິງ – ການຕິດຕາມປະເພດນີ້ຖືກນໍາໃຊ້ໂດຍ AS ເພື່ອກໍານົດວ່າ UE ຢູ່ໃນເຄືອຂ່າຍເຮືອນຫຼືຢູ່ໃນເຄືອຂ່າຍຂອງຄູ່ຮ່ວມງານໂຣມມິງ. ທາງເລືອກອື່ນ, PLMN (Public Land Mobile Network) ຂອງຜູ້ປະກອບການທີ່ອຸປະກອນໄດ້ຖືກລົງທະບຽນສາມາດສົ່ງຜ່ານໄດ້.

ຄວາມລົ້ມເຫຼວຂອງການສື່ສານ — ການ​ຕິດ​ຕາມ​ປະ​ເພດ​ນີ້​ແຈ້ງ AS ກ່ຽວ​ກັບ​ຄວາມ​ລົ້ມ​ເຫຼວ​ໃນ​ການ​ສື່​ສານ​ກັບ​ອຸ​ປະ​ກອນ​, ໂດຍ​ອີງ​ໃສ່​ເຫດ​ຜົນ​ສໍາ​ລັບ​ການ​ສູນ​ເສຍ​ການ​ເຊື່ອມ​ຕໍ່ (ລະ​ຫັດ​ເຫດ​ການ​ປ່ອຍ​) ທີ່​ໄດ້​ຮັບ​ຈາກ​ເຄືອ​ຂ່າຍ​ການ​ເຂົ້າ​ເຖິງ​ວິ​ທະ​ຍຸ (S1-AP protocol​)​. ເຫດການນີ້ສາມາດຊ່ວຍກໍານົດວ່າເປັນຫຍັງການສື່ສານລົ້ມເຫລວ - ເນື່ອງຈາກບັນຫາໃນເຄືອຂ່າຍ, ຕົວຢ່າງເຊັ່ນ, ເມື່ອ eNodeb ຖືກໂຫຼດເກີນ (ຊັບພະຍາກອນວິທະຍຸບໍ່ມີ) ຫຼືຍ້ອນຄວາມລົ້ມເຫຼວຂອງອຸປະກອນຕົວມັນເອງ (Radio Connection With UE Lost).

ມີໃຫ້ຫຼັງຈາກ DDN ລົ້ມເຫລວ – ເຫດການນີ້ແຈ້ງໃຫ້ AS ວ່າອຸປະກອນດັ່ງກ່າວໄດ້ສາມາດໃຊ້ໄດ້ຫຼັງຈາກການສື່ສານລົ້ມເຫລວ. ສາມາດນໍາໃຊ້ໄດ້ໃນເວລາທີ່ມີຄວາມຕ້ອງການທີ່ຈະໂອນຂໍ້ມູນກັບອຸປະກອນ, ແຕ່ຄວາມພະຍາຍາມທີ່ຜ່ານມາບໍ່ປະສົບຜົນສໍາເລັດເພາະວ່າ UE ບໍ່ຕອບສະຫນອງການແຈ້ງເຕືອນຈາກເຄືອຂ່າຍ (paging) ແລະຂໍ້ມູນບໍ່ໄດ້ຖືກຈັດສົ່ງ. ຖ້າການກວດສອບປະເພດນີ້ໄດ້ຮັບການຮ້ອງຂໍສໍາລັບ UE, ຫຼັງຈາກນັ້ນທັນທີທີ່ອຸປະກອນເຮັດໃຫ້ການສື່ສານຂາເຂົ້າ, ເຮັດໃຫ້ TAU ຫຼືສົ່ງຂໍ້ມູນໄປຫາ uplink, AS ຈະໄດ້ຮັບການແຈ້ງເຕືອນວ່າອຸປະກອນໄດ້ກາຍເປັນທີ່ມີຢູ່. ເນື່ອງຈາກຂັ້ນຕອນ DDN (downlink data notification) ເຮັດວຽກລະຫວ່າງ MME ແລະ S/P-GW, ການກວດສອບປະເພດນີ້ສາມາດໃຊ້ໄດ້ກັບອຸປະກອນ IP ເທົ່ານັ້ນ.

ສະຖານະການເຊື່ອມຕໍ່ PDN – ແຈ້ງ​ໃຫ້ AS ເມື່ອ​ສະ​ຖາ​ນະ​ພາບ​ອຸ​ປະ​ກອນ​ການ​ປ່ຽນ​ແປງ (ສະ​ຖາ​ນະ​ພາບ​ການ​ເຊື່ອມ​ຕໍ່ PDN​) - ການ​ເຊື່ອມ​ຕໍ່ (ການ​ກະ​ຕຸ້ນ PDN​) ຫຼື​ການ​ຕັດ​ການ​ເຊື່ອມ​ຕໍ່ (ການ​ລົບ PDN​)​. ນີ້ສາມາດຖືກນໍາໃຊ້ໂດຍ AS ເພື່ອລິເລີ່ມການສື່ສານກັບ UE, ຫຼືໃນທາງກັບກັນ, ເພື່ອເຂົ້າໃຈວ່າການສື່ສານເປັນໄປບໍ່ໄດ້ອີກຕໍ່ໄປ. ປະເພດຂອງການຕິດຕາມນີ້ສາມາດໃຊ້ໄດ້ສໍາລັບອຸປະກອນ IP ແລະທີ່ບໍ່ແມ່ນ IP.

ຈໍານວນ UE ທີ່ມີຢູ່ໃນພື້ນທີ່ທາງພູມສາດ - ປະເພດຂອງການຕິດຕາມນີ້ຖືກນໍາໃຊ້ໂດຍ AS ເພື່ອກໍານົດຈໍານວນຂອງ UE ໃນເຂດພື້ນທີ່ສະເພາະໃດຫນຶ່ງ.

ການກະຕຸ້ນອຸປະກອນ)

ໃນເຄືອຂ່າຍ 2G / 3G, ຂັ້ນຕອນການລົງທະບຽນໃນເຄືອຂ່າຍແມ່ນສອງຂັ້ນຕອນ: ທໍາອິດ, ອຸປະກອນລົງທະບຽນກັບ SGSN (ຂັ້ນຕອນການຄັດຕິດ), ຫຼັງຈາກນັ້ນ, ຖ້າຈໍາເປັນ, ມັນເປີດໃຊ້ PDP context - ການເຊື່ອມຕໍ່ກັບ packet gateway (GGSN) ເພື່ອສົ່ງຂໍ້ມູນ. ໃນເຄືອຂ່າຍ 3G, ສອງຂັ້ນຕອນນີ້ເກີດຂຶ້ນຕາມລໍາດັບ, i.e. ອຸ​ປະ​ກອນ​ບໍ່​ໄດ້​ລໍ​ຖ້າ​ສໍາ​ລັບ​ປັດ​ຈຸ​ບັນ​ໃນ​ເວ​ລາ​ທີ່​ມັນ​ຕ້ອງ​ການ​ໂອນ​ຂໍ້​ມູນ​, ແຕ່​ໄດ້​ເປີດ​ນໍາ​ໃຊ້ 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. ໃນ​ກໍ​ລະ​ນີ​ນີ້​, ການ​ທໍາ​ງານ "ອຸ​ປະ​ກອນ triggering​" ຍັງ​ຈະ​ຊ່ວຍ​ໄດ້​. ເມື່ອໄດ້ຮັບຂໍ້ມູນໃໝ່ຈາກ AS, SCEF ຈະຊອກຫາສະຖານະການເຊື່ອມຕໍ່ອຸປະກອນ ແລະສົ່ງຂໍ້ມູນຜ່ານຊ່ອງທາງ SMS.

ສະຫລຸບ

ການທໍາງານຂອງ SCEF, ແນ່ນອນ, ບໍ່ຈໍາກັດພຽງແຕ່ການບໍລິການທີ່ອະທິບາຍຂ້າງເທິງນີ້ແລະພັດທະນາຢ່າງຕໍ່ເນື່ອງແລະຂະຫຍາຍ. ປະຈຸ​ບັນ, ຫຼາຍກວ່າ​ໜຶ່ງ​ໝື່ນ​ບໍລິການ​ໄດ້​ຮັບ​ມາດຕະຖານ​ແລ້ວ​ສຳລັບ SCEF. ໃນປັດຈຸບັນພວກເຮົາໄດ້ສໍາຜັດພຽງແຕ່ຫນ້າທີ່ຕົ້ນຕໍທີ່ຕ້ອງການຈາກນັກພັດທະນາ; ພວກເຮົາຈະເວົ້າກ່ຽວກັບສ່ວນທີ່ເຫຼືອໃນບົດຄວາມໃນອະນາຄົດ.

ຄໍາຖາມທີ່ເກີດຂື້ນທັນທີ: ວິທີການເຂົ້າເຖິງການທົດສອບກັບໂຫນດ "ມະຫັດສະຈັນ" ນີ້ສໍາລັບການທົດສອບເບື້ອງຕົ້ນແລະການດີບັກຂອງກໍລະນີທີ່ເປັນໄປໄດ້? ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍຫຼາຍ. ນັກພັດທະນາສາມາດສົ່ງຄໍາຮ້ອງຂໍໄປຫາ [email protected], ໃນທີ່ມັນພຽງພໍທີ່ຈະຊີ້ບອກຈຸດປະສົງຂອງການເຊື່ອມຕໍ່, ລາຍລະອຽດຂອງກໍລະນີທີ່ເປັນໄປໄດ້ແລະຂໍ້ມູນຕິດຕໍ່ສໍາລັບການສື່ສານ.

ноновыхвстреч!

ຜູ້ຂຽນ:

• ຜູ້ຊ່ຽວຊານອາວຸໂສຂອງພະແນກການແກ້ໄຂແລະການບໍລິການ multimedia Sergey Novikov Sanov,
• ຊ່ຽວ​ຊານ​ຂອງ​ວິ​ທີ​ແກ້​ໄຂ convergent ແລະ​ພະ​ແນກ​ບໍ​ລິ​ການ multimedia Alexey Lapshin​ ລົ້ມ

ແຫຼ່ງຂໍ້ມູນ: www.habr.com