التفاعل مع NIDD عبر SCEF باستخدام أداة Postman. جولة قصيرة في SCEF وميزاته

ستسمح هذه المقالة لأولئك الذين بدأوا للتو في تطويرهم أو قاموا بالفعل بتطبيق تقنية NB-IoT للحصول على فكرة عن كيفية التفاعل عن بعد مع جهاز NB-IoT.

صورة

مراجعة قصيرة


NB-IoT يخطو بسهولة في أعقاب 2G وقد أثبت نفسه كمعيار موفر للطاقة للاتصالات الخلوية ، والذي سيكون قادرًا في المستقبل المنظور على الضغط على 2G ، مما عزز موقعه. والسبب في ذلك هو القدرة على الاقتراب بمرونة من مسألة استهلاك الطاقة لواحد من أكثر أجزاء الجهاز استهلاكًا - جهاز الإرسال اللاسلكي. إذا لم تتعمق في التفاصيل ، فمع NB-IoT ، لدينا الفرصة لتهيئة أوضاع تشغيل الجهاز بمرونة من خلال تحديد جدول اتصالات الجهاز وتفاعل الجهاز مع الخوادم على الإنترنت.

بالتوازي مع ذلك ، فإن عدد أجهزة المشترك المتصلة في وقت واحد بخلية واحدة في تزايد كبير ، وكذلك تكاليف مشغل الهاتف المحمول للحفاظ على قابلية تشغيل هذا الاتصال نفسه.

من المفترض أن القارئ لديه فهم تقريبي لتقنية NB-IoT وهناك خبرة تفاعلية ضئيلة.
يتم تحديث المقالة وتحديثها بانتظام.


الصعوبات داخل شبكة NB-IoT


إلى جانب القدرة على التحكم في جهاز الإرسال اللاسلكي وكفاءة الطاقة العالية ، فقد ظهرت مشكلة إرسال البيانات في الاتجاه من الخادم إلى الوحدة (الجهاز). والسبب هو أنه من الممكن تزويد مئات الآلاف من الأجهزة بعناوين IP بيضاء ، ولكن هذا يستلزم كمية كبيرة من النفقات العامة ويقلل من الموثوقية الإجمالية للشبكة بسبب تعقيدها. تتلقى الوحدة عنوان NAT الخاص بالمشغل ومن الصعب على المشغل ترجمته "خارج" نظرًا للعدد الكبير من الأجهزة. على سبيل المثال: 100 ألف جهاز هو نفس عدد عناوين IP وفي إطار IPv4 يبدو ببساطة أنه من غير الممكن تنفيذ ذلك. يمكن أن يؤدي الانتقال إلى IPv6 إلى حل هذه المشكلة ، ولكن لا يزال يتعين عليك الدفع مقابل العنوان "الأبيض" للجهاز على الشبكة ، مما سيؤثر بشكل كبير على جيب عملاء الشركات.

أي ، في الحالة العامة ، اتضح أن الجهاز لا يمكن أن يعمل إلا في وضع أحادي الاتجاه عن طريق نقل البيانات إلى الخادم دون إمكانية تلقي البيانات من الخادم ، لأن الخادم لا يدرك عمليا عندما يتصل الجهاز لأول مرة. أو ، استخدم في المتوسط ​​ما لا يزيد عن خمس دقائق بعد إنشاء الاتصال بين الجهاز والخادم لنقل البيانات من الخادم إلى الجهاز.

NIDD (تسليم البيانات بخلاف IP) - لماذا هذا مطلوب؟


عند العمل مع شبكة NB-IoT ، يكون من الصعب جدًا اللجوء إلى جهاز لإرسال أمر أو بيانات معينة. لحل هذه المشكلة ، تم اختراع آلية لتحسين نقل كميات صغيرة من البيانات ، وهي تسليم البيانات بخلاف IP (NIDD). تقلل الآلية الحجم الكلي للرسالة المرسلة عن طريق تقليل الرؤوس. وهذا بدوره يؤثر بشكل إيجابي على خصائص الجهاز: فهو يقلل من استهلاك الطاقة ويزيد من الاستقلالية (عمر البطارية). ونتيجة لذلك ، يؤدي رفض دعم IP إلى أجهزة أرخص ، وتقليل وقت التطوير ، وزيادة القدرة التنافسية في سوق أجهزة إنترنت الأشياء ، إلخ.

SCEF (وظيفة التعرض لقدرة الخدمة) - هدية للمستخدمين


SCEF هو عنصر شبكة وظيفي ظهر لأول مرة وإصدار 3GPP الإصدار 13 ، تم نشره على جانب مشغل الهاتف المحمول وتوفير قناة اتصال آمنة بين SCS / AS (خادم القدرة على الخدمة / خادم التطبيق) وجهاز NB-IoT. يوفر SCEF قناة اتصال عند الاتصال بالجهاز عبر NIDD ويوفر الوصول إلى إمكانيات / خدمات الشبكة الإضافية لشبكة NB-IoT من خلال واجهة برمجة تطبيق واحدة (من وصف API T8). في الإصدار 3GPP 13 ، تم توحيد آلية SCEF فقط للتفاعل مع واجهات الشبكة الخلوية. وبالتالي ، يتم تحسين حمل الشبكة ، ويتم تبسيط التفاعل مع الجهاز ، ويتم تبسيط خوارزمية الجهاز نفسه.يفي SCEF أيضًا بالمتطلبات العالية لأمان نقل البيانات وتلبية المتطلبات لتأكيد نقل البيانات بنجاح في كلا الاتجاهين.


يتيح لك SCEF التجريد من الأنظمة المعقدة للتفاعل مع جهاز NB-IoT ، بما في ذلك عندما يكون الأخير في وضع eDRX أو PSM ولا يكون متاحًا لنقل البيانات في اتجاه الخادم-> الجهاز. عندما يتلقى الجهاز التسجيل و "متفق عليه" مع شبكة مشغل الشبكة بشأن جدول الاتصالات ، باستخدام واجهة بسيطة ، يمكنك نقل البيانات إلى الجهاز وتلقي البيانات منه ، وإدارة "اشتراك" جهازك و AS إلى أحداث معينة ، وتعيين وربط الأحداث الفريدة بنفسك أسماء المعرفات العالمية والمزيد. كل هذا من خلال نفس الواجهة - T8 API.

من المهم ملاحظة أن الخادم (AS) لا يمكن أن يكون خادمًا واحدًا ، بل عدة خوادم ، ويمكنك تكوين توزيع المعلومات بين الخوادم بمرونة لأحداث معينة أو مجموعات من الأجهزة.

كيف تعمل


الحل الأكثر شيوعًا لتنظيم وصول جهاز إلى شبكة خلوية هو استخدام وحدة خلوية ، على سبيل المثال:


عند التسجيل في شبكة خلوية ، تنقل هذه الوحدة إلى المشغل بعض المعلومات ، بما في ذلك IMSI لبطاقة SIM الخاصة بالمشترك والتي يمكن للمشغل ربطها بحساب المشترك أو المشترك نفسه إذا كان لديه حق الوصول إلى الحساب الشخصي للمشغل. وراء شاشة SCEF ، يتم إخفاء المعرفة بجلسة الاتصال التالية مع الجهاز. لا يمكن تسجيل جهاز غير IP في شبكة المشغل إلا إذا كان هناك اشتراك واحد على الأقل من SCS / AS على هذا الجهاز. لا يوجد اشتراك - لن يتصل أحد بهذا الجهاز عبر NIDD ، ولن يتم تسجيل الجهاز على الشبكة. وبالتالي ، فإن SCEF ، الذي يعرف عن جلسة الاتصال التالية ، قادر على نقل البيانات من / إلى الجهاز ، وفقًا لمعلمات التسليم المحددة وعمر الرسالة المرسلة ، دون الحاجة إلى تنظيم مراقبة إضافية لحالة نقل البيانات والتحكم في التسليم.

خفة


إن تضمين وحدات بايت البيانات من الجهاز في بروتوكول TCP ونقلها إلى الخادم يعد مكلفًا من حيث مئات الآلاف من أجهزة المشتركين في أسطول الشركة. يسمح لك SCEF بالتخلي عن IP على الجهاز ونقل البيانات غير المتعلقة بالملكية الفكرية فقط ، بدون رؤوس IP من خلال قناة الإشارة ، مما يساهم في تقليل تكلفة البايت المرسلة ويوفر مزايا إضافية من استخدام الخدمة. علاوة على ذلك ، لا يقوم SCEF بإجراء أي تغييرات على البيانات المرسلة للجهاز ومنه ، حيث يتم نقل الحمولة بشكل شفاف. لذلك ، باستخدام NIDD ، من الممكن نقل ليس فقط البيانات غير المهيكلة ، ولكن أيضًا البيانات "الملفوفة" بتنسيق قياسي مفهومة ، مثل JSON ، لتبسيط معالجة البيانات على الجانب AS.

بداية العمل


هيكل URI (معرف الموارد الموحد) على مثال Postman


بادئ ذي بدء ، تحتاج إلى الوصول إلى حسابك الشخصي من المشغل (خدمة M2M-manager). من أجل التنفيذ التجاري لـ MTS ، يتم توفير واجهة حساب شخصي واحدة ، حيث يمكنك بشكل مستقل إنشاء APN ، والوصول إلى تسجيل الدخول / كلمة المرور إلى API وتعيين أسماء ScsAsID ، extID لأجهزتك.

أولئك. سنحتاج على الأقل إلى:
  • ScsAsID - معرف AS الخاص بك
  • APN - لن يعمل الذي يستخدم عادة للتفاعل مع الشبكة
  • تسجيل الدخول / كلمة المرور - بيانات للوصول إلى حسابك الشخصي والتفاعل مع SCEF
  • عنوان URI –HTTP والمنفذ على الشبكة المقدم إليك من SCEF
  • معرف خارجي - معرف الجهاز


دعنا ننتقل إلى الممارسة


لقد انتهت النظرية ، دعنا ننتقل إلى الجزء الأكثر إثارة للاهتمام - الممارسة على وحدة إنتاج حلول SIMCom اللاسلكية - SIM7020E .

تحتاج أولاً إلى تكوين الوحدة النمطية نفسها للعمل مع NIDD. للقيام بذلك ، ضع الوحدة أولاً في وضع CFUN = 0 وقم بتكوينها:

AT+CFUN=0
+CPIN: NOT READY

OK
AT+ENVDM=1,tel_conn_mgr,default_pdn_flag,1,30
OK
AT*MCGDEFCONT="Non-IP","<APN>"
OK
AT+CFUN=1
OK

+CPIN: READY
AT+EGACT=1,4,"<APN>"
+EGACT:1

OK

+EGACT:1,1,1,4

التحقق من تسجيل الوحدة في شبكة بيانات الحزمة

AT+CGREG?
+CGREG: 0,1

OK

وإنهاء إعداد NIDD

AT+NIDD=0,"<APN>","<login>","<pass>"
+NIDD=0,0

OK

ستحتوي استجابة الوحدة على account_id هنا: + NIDD = 0 ، <account_id> - سيكون هذا مفيدًا عند تنشيط NIDD على الوحدة.

AT+NIDD=1,0
+NIDD=1,0

OK

في هذه الحالة ، account_id هو 0.

تم. في هذه المرحلة ، تم الانتهاء من العمل مع الوحدة. دعنا ننتقل إلى إعداد SCEF.

نقطة مهمة: بدون اشتراك مسجل في SCEF ، لن تتلقى الوحدة التسجيل على الشبكة!

SCEF


API T8


توجد وثيقة خاصة توضح تفاصيل التفاعل مع SCEF. تحدد واجهة برمجة التطبيقات هذه مجموعة من نماذج البيانات والموارد والإجراءات ذات الصلة لإرسال البيانات بخلاف IP.



العمل مع SCEF واشتراكات الخدمة - JSON (JavaScript Object Notation)


يجب أن يتم ترميز البيانات التي تتضمن تكوين SCEF ويتم إرسالها عبر HTTP / 1.1 إلى SCEF بتنسيق JSON ، ويجب أن يتضمن نص طلب HTTP نفسه في حقل نوع المحتوى رأس "application / json". في الوقت نفسه ، إذا تم تسليم الرسالة إلى المستلم وتم استلام تأكيد التسليم - يجب على SCEF حذف التكوين المناسب ، وإرسال الرسالة عبر HTTP POST لـ AS برمز الحالة "200 OK" وتشغيل التقرير الخاص بالحدث.

ساعي البريد


لن أخوض في كيفية العمل مع هذه الأداة المساعدة ، على الإنترنت يمكنك العثور على الكثير من المراجعات. يمكنني فقط أن أقول أن لديها بعض القيود في نسختها المجانية ، لكننا لسنا بحاجة إلى الكثير ، فالوظائف المقدمة مجانًا أكثر من كافية لمهامنا.

بعد تنزيله وفتحه ، سترحب علامة التبويب الأولى بنا - Launchpad ، حيث سيُعرض علينا إنشاء طلبنا الأول ، ولن نرفض.


تابع فورًا تكوين جهازنا الجديد.

في البداية ، قمنا بتكوين طريقة GET ، وقمنا بتبديلها إلى POST (بعد ذلك بقليل سيتضح سبب ضرورة ذلك). في علامة التبويب "التفويض" ، أدخل "بيانات الاعتماد" الموجودة لدينا:


الآن قم بإنشاء طلبنا الأول:


في نص الطلب ، نشير إلى:

{
    "externalId": "<ID >",
    "reliableDataService": false,
    "pdnEstablishmentOption": "WAIT_FOR_UE",
    "duration":"2020-12-31T23:59:59Z",
    "notificationDestination": "http://<IP >:<port>"
}

مهم!
انتبه على:
  • “duration” – duration SLA SCEF (SCSAS/ID) , SCEF ,
  • “maximumPacketSize” – /

دعنا نلاحظ على الفور أن الخيارات التالية ممكنة في "pdnEstablishmentOption":
  • WAIT_FOR_UE - المخزن المؤقت إذا كان الجهاز غير متوفر (غير مسجل على الشبكة أو في PSM أو في حالة أخرى)
  • INDICATE_ERROR - الرد فورًا بخطأ إذا كان الجهاز غير متوفر
  • SEND_TRIGGER - استخدم خدمة تشغيل الجهاز (قناة توصيل بديلة عبر الرسائل القصيرة). لا يعتبر هذا المقال.

نستخدم نفس المعلمة لإرسال البيانات إلى الجهاز. وعند إنشاء اشتراك ، يمكننا على الفور إرسال البيانات إلى الجهاز ، وتقليل عدد طلبات واجهة برمجة التطبيقات.
الكل! يمكنك النقر فوق الزر إرسال وفحص ما نحصل عليه ردًا من SCEF بعناية:

{
    "externalId": "<ID >",
    "duration": "2020-12-31T23:59:59Z",
    "notificationDestination": "http://<IP >:<port>",
    “reliableDataService": false,
    "maximumPacketSize": 500,
    "self": "/3gpp-nidd/v1/<ScsAsID>/configurations/<ID >",
    "status": "ACTIVE"
}

في الخط الذاتي ، نحن مهتمون في المقام الأول بمعرف التكوين الذي أنشأناه ، فمن غير المرغوب فيه للغاية فقدانه ، نظرًا لأن المشغلين على الأرجح لن يدعموا وظيفة الطلب لجميع التكوينات التي تم إنشاؤها. عندما يتم إنشاء عدة آلاف من الأجهزة في إطار ScsAsID واحد ، سيتم إنشاء الكثير من الحمل على خوادم SCEF لبث جميع تكوينات الجهاز. نأخذها كقاعدة: جهاز واحد = اشتراك واحد كجزء من خدمة ScsAsID.

وبالتالي ، يمكننا بالفعل تلقي البيانات من الوحدة النمطية على الخادم وعنوان IP والمنفذ الذي أشرنا إليه أعلاه.

نقل البيانات من الوحدة النمطية إلى AS


دعنا نحاول نقل البيانات من الجهاز إلى AS ، والعودة إلى وحدة SIM7020E وإذا لم نلمسها من الفصل السابق ولم نوقف تشغيلها ، فسنرسل الأمر إليها:

AT+NIDD=3,<account_id>,"6162636465"
OK

يرجى ملاحظة أن رسالتنا مشفرة في HEX وتحتوي على تسلسل بسيط: "abcde".
على الفور تقريبًا على الخادم (AS) ، وهو المضيف ، سنرى:

POST / HTTP/1.1
OCSGHTTPProcessor: 147ff7c6-a43d-4fc9-b303-0ca50f497747
X-callback-t8-type: 3
X-callback-url: http://<IP >:<port>
X-api-network-service-node: 0
Content-Type: application/json
Content-Length: 214
Host: <IP >:<port>
Connection: Keep-Alive
User-Agent: Apache-HttpAsyncClient/4.1.3 (Java/1.8.0_181)

{"externalId":"<ID >","niddConfiguration":"/3gpp-nidd/v1/<ScsAsID>/configurations/<ID >","data":"YWJjZGU=","reliableDataService":false}

وصلت الرسالة نفسها بترميز Base64 وتبدو كما يلي:
YWJjZGU=

إذا ترجمنا من ترميز Base64 ، نحصل على رسالتنا الأصلية:
abcde

يتم استخدام ترميز Base64 نظرًا لأنه عند استخدام ترميز ASCII ، تُفقد بعض البيانات أحيانًا ، كما أن استخدام Base64 يجعل الإرسال أكثر موثوقية.

وتجدر الإشارة أيضًا إلى أنه في هذه الحالة لا يتم تخزين المعلومات المرسلة من الوحدة داخل SCEF ويتم إرسالها على الفور إلى خادمنا عبر HTTP.

نقل البيانات من AS إلى الوحدة النمطية


لإرسال البيانات في الاتجاه من AS الخاص بنا إلى الوحدة ، دعنا نعود إلى Postman وننشئ طلبًا جديدًا باستخدام طريقة POST وترميز Base64. سوف نرسل 1234567890 (في Base64: MTIzNDU2Nzg5MA ==) إلى الوحدة الخاصة بنا:



يرجى ملاحظة أن الملحق قد ظهر في حقل "العنوان" ، الذي أشرنا فيه إلى التكوين الذي نريد إرسال الرسالة إليه. إذا تم تضمين العديد من الأجهزة في التكوين الخاص بنا ، يمكنك استخدام المعرف "externalGroupID" ومن ثم ستتلقى جميعها هذه البيانات. نقطة أخرى مهمة هي عمر الرسالة المرسلة ، المشار إليها بالثواني ولها نطاق واسع إلى حد ما.

بالمناسبة ، إذا كان الجهاز غير متصل بالإنترنت في هذه اللحظة ، فسيتم تخزين رسالتنا مؤقتًا على SCEF ، وسيخبرنا السطر "maxLatency" بعدد الثواني المتبقية حتى يتم تدمير الرسالة إذا لم يتصل الجهاز قبل المؤقت الذي قمنا بتعيينه . فيما يلي الشكل الذي ستبدو عليه تهيئة SCEF الحالية المطلوبة (باستخدام آلية GET ، المزيد عن ذلك أدناه):

{
    "externalId": "<ID >",
    "duration": "2020-12-31T23:59:59Z",
    "notificationDestination": "http://<IP >:<port>",
    "reliableDataService": false,
    "status": "ACTIVE",
    "niddDownlinkDataTransfers": [
    {
        "externalId": "<ID >",
        "reliableDataService": false,
        "data": "MDEyMzQ1Njc4OTA=",
        "maximumLatency": 96,
        "priority": 1,
        "self": "/3gpp-nidd/v1/<ScsAsID>/configurations/<ID >/downlink-data-deliveries/1"
    }
}

إذا ، بعد انتهاء الموقت ، لم يتم الاتصال بالجهاز ، فسيقوم SCEF بإخطار خادمك (AS) بأنه لم يتم تسليم الرسالة بسبب انتهاء صلاحية الموقت وسيتم حذف الرسالة:

POST / HTTP/1.1
OCSGHTTPProcessor: 14c8cab8-ecce-4868-a59e-1f784224518b
X-callback-t8-type: 4
X-callback-url: http://<IP >:<port>
X-api-network-service-node: 0
Content-Type: application/json
Content-Length: 139
Host: <IP >:<port>
Connection: Keep-Alive
User-Agent: Apache-HttpAsyncClient/4.1.3 (Java/1.8.0_181)

{"niddDownlinkDataTransfer":"/3gpp-nidd/v1/<ScsAsID>/configurations/<ID >/downlink-data-deliveries/1","status":"FAILURE"}

إذا نجحت SCEF ، فسوف ترد على الفور:

{
    "externalId": "<ID >",
    "reliableDataService": false,
    "status": "SUCCESS"
}

يمكنك إضافة القدرة على تحديد أولويات الرسائل في حالة تخزينها مؤقتًا. يتم تنظيمه بواسطة معلمة "الأولوية". عندما يتم إرسال رسالة جديدة إلى الجهاز وإذا تم تجاوز المخزن المؤقت للتسليم بواسطة SCEF ، فسيتم استبدال الرسالة برسالة ذات أولوية أقل ، وإلا فلن يتم قبول الرسالة للتسليم. من الممكن أيضًا حذف رسالة من المخزن المؤقت.

إذا تعذر تسليم الرسالة ، وتم تخزينها مؤقتًا ، فستتلقى ما يلي:

{
    "externalId": "<ID >",
    "reliableDataService": false,
    "self": "/3gpp-nidd/v1/<ScsAsID>/configurations/<ID >/downlink-data-deliveries/2",
   "status": "BUFFERING"
}

مهم!
:
/<ID >/downlink-data-deliveries/1
– SCEF. , . .

عند استلام الرسالة ، ستبلغ الوحدة عن URC التالي:

+NIDD=4,0,11,0,"3031323334353637383930"

في الترجمة من HEX إلى ASCII ستكون رسالتنا:

1234567890

فقط اتركها هنا. إشعار تسليم رسالة "مخزنة":

{
"niddDownlinkDataTransfer":"3gpp-nidd/v1/<ScsAsID>/configurations/<ID >/downlink-data-deliveries/1",
"status":"SUCCESS"
}

يمكن مراقبة حالة الجهاز من خلال خدمة SCEF أخرى تسمى "حدث المراقبة (MONTE)". ضمن MONTE ، من الممكن تلقي إشعارات حول الأحداث والوقت (على سبيل المثال ، عندما يصبح الجهاز متاحًا) ، باستخدام نظام اشتراك مماثل. لكن دعنا نتحدث عن هذا مرة أخرى.

الحصول على التكوين من SCEF


ربما لاحظت أنه يمكنك الحصول على التكوين الحالي من SCEF. لنفعل ذلك. نأخذ Postman الذي أحببناه بالفعل وننشئ الطلب التالي باستخدام طريقة GET:


أولئك. نترك نص الرسالة نفسه فارغًا ، وفي شريط العناوين نحتاج فقط إلى تحديد معرف التكوين الذي تم إنشاؤه لنا من أجل تلقي حالته الحالية استجابة:

{
    "externalId": "<ID >",
    "duration": "2020-12-31T23:59:59Z",
    "notificationDestination": " http://<IP >:<port>",
    "reliableDataService": false,
    "status": "ACTIVE",
    "niddDownlinkDataTransfers": []
}

حذف تكوين على SCEF


حسنًا والأخير - سنحذف التكوين الذي أنشأناه. للقيام بذلك ، استخدم نفس شريط العنوان الموجود في التكوين الحالي ، ولكن قم بتغييره إلى DELETE:


ردًا على ذلك ، سوف نتلقى:

{
    "externalId": " <ID >",
    "duration": "2020-12-31T23:59:59Z",
    " notificationDestination": " http://<IP >:<port>",
    "reliableDataService": false,
    "status": "TERMINATED"
}

حيث نرى في السطر "الحالة" أنه تم حذف التكوين الذي أنشأناه.

استنتاج


يمكن كتابة أكثر من أطروحة واحدة حول موضوع استخدام SCEF ، والموضوع واسع النطاق وسيصبح قريبًا وثيق الصلة للغاية بالعديد من أجهزة M2M في جميع المجالات ، وخاصة لإنترنت الأشياء. الشيء الرئيسي الذي أردت أن أنقله إليك هو كيفية بدء العمل مع NIDD و SCEF خارج الصندوق حتى تتمكن من معرفة ذلك بنفسك. ولكن أيضًا يسعدني دائمًا مساعدتك: support@simcom.com (المميزة بفريق RUS) ، في الرسالة يجب أن تشير إلى تفاصيل الاتصال الخاصة بك وبضع كلمات عن مشروعك.

في المقالات التالية ، سنحلل بعناية الجوانب الأخرى للعمل مع الوحدات الخلوية ، وسوف تكتب في التعليقات أي موضوع سيكون مفيدًا لك.

أود أن أقول شكرًا خاصًا لسيرجي نوفيكوف ، الخبير الأول في الحلول المتقاربة وخدمات الوسائط المتعددة.سانوف) من MTS للحصول على مساعدة لا تقدر بثمن في إعداد المقال.

المصادر المستخدمة


NB-IoT: كيف يعمل؟ الجزء 3: SCEF - نافذة واحدة للوصول إلى خدمات المشغل
ETSI TS 129 122

All Articles