Get best of the week

Interaksi dengan NIDD melalui SCEF menggunakan utilitas Postman. Tur singkat SCEF dan fitur-fiturnya

Artikel ini akan memungkinkan mereka yang baru memulai pengembangan mereka atau sudah menerapkan teknologi NB-IoT untuk mendapatkan ide tentang bagaimana berinteraksi dari jarak jauh dengan perangkat NB-IoT.

gambar

Ulasan singkat


NB-IoT dengan mudah menginjak tumit 2G dan telah memantapkan dirinya sebagai standar hemat energi untuk komunikasi seluler, yang di masa mendatang akan dapat menekan 2G, yang telah memperkuat posisinya. Alasan untuk ini adalah kemampuan untuk secara fleksibel mendekati masalah konsumsi energi dari salah satu bagian yang paling memakan perangkat - pemancar radio. Jika Anda tidak merinci lebih dalam, maka bersama dengan NB-IoT, kami memiliki kesempatan untuk secara fleksibel mengkonfigurasi mode operasi perangkat dengan menyesuaikan jadwal koneksi perangkat dan interaksi perangkat dengan server di Internet.

Sejalan dengan ini, jumlah perangkat pelanggan yang terhubung secara bersamaan ke satu sel meningkat secara signifikan, serta biaya operator seluler untuk mempertahankan operabilitas komunikasi ini sendiri.

Diasumsikan bahwa pembaca memiliki perkiraan pemahaman tentang teknologi NB-IoT dan ada pengalaman interaksi yang minimal.
Artikel ini diperbarui dan diperbarui secara berkala.


Kesulitan dalam jaringan NB-IoT


Bersama dengan kemampuan untuk mengontrol pemancar radio dan efisiensi energi yang tinggi, masalah pengiriman data dalam arah dari server ke modul (perangkat) telah datang. Alasannya adalah memungkinkan untuk menyediakan ratusan ribu perangkat dengan alamat IP putih, tetapi ini memerlukan sejumlah besar overhead dan mengurangi keandalan keseluruhan jaringan karena kerumitannya. Modul menerima alamat untuk NAT operator dan sulit bagi operator untuk menerjemahkannya "keluar" karena banyaknya perangkat. Sebagai contoh: 100 ribu perangkat adalah jumlah alamat IP yang sama dan dalam kerangka IPv4 sepertinya tidak mungkin untuk menerapkan ini. Transisi ke IPv6 dapat menyelesaikan masalah ini, tetapi Anda masih harus membayar untuk alamat "putih" perangkat di jaringan, yang secara signifikan akan mempengaruhi kantong klien korporat.

Artinya, dalam kasus umum, ternyata perangkat hanya dapat bekerja dalam mode satu arah dengan mentransmisikan data ke server tanpa kemungkinan menerima data dari server, karena server praktis tidak sadar ketika perangkat pertama kali berhubungan. Atau, gunakan rata-rata tidak lebih dari lima menit setelah koneksi antara perangkat dan server untuk mentransfer data dari server ke perangkat dibuat.

NIDD (Pengiriman Data Non-IP) - mengapa ini diperlukan?


Ketika bekerja dengan jaringan NB-IoT, sangat sulit untuk beralih ke perangkat untuk mengirimkan perintah atau data tertentu.Untuk menyelesaikan masalah ini, sebuah mekanisme untuk mengoptimalkan transfer sejumlah kecil data, Pengiriman Data Non-IP (NIDD), diciptakan. Mekanisme ini mengurangi ukuran keseluruhan dari pesan yang dikirimkan dengan mengurangi header. Ini, pada gilirannya, secara positif mempengaruhi karakteristik perangkat: ini mengurangi konsumsi daya dan meningkatkan otonomi (usia baterai). Akibatnya, penolakan dukungan IP mengarah ke perangkat yang lebih murah, mengurangi waktu pengembangan, meningkatkan daya saing di pasar perangkat IoT, dll.

SCEF (Fungsi Paparan Kemampuan Layanan) - hadiah untuk pengguna


SCEF adalah elemen fungsional dari jaringan yang pertama kali muncul dan 3GPP Release 13, ditempatkan di sisi operator seluler dan menyediakan saluran komunikasi yang aman antara SCS / AS (Server Kemampuan Layanan / Server Aplikasi) dan perangkat NB-IoT. SCEF menyediakan saluran komunikasi saat berkomunikasi dengan perangkat melalui NIDD dan menyediakan akses ke kemampuan / layanan jaringan tambahan dari jaringan NB-IoT melalui antarmuka pemrograman aplikasi tunggal (dari deskripsi T8 API). Dalam 3GPP Release 13, hanya mekanisme SCEF untuk berinteraksi dengan antarmuka jaringan seluler yang distandarisasi. Dengan demikian, beban jaringan dioptimalkan, interaksi dengan perangkat disederhanakan, algoritma perangkat itu sendiri disederhanakan.SCEF juga memenuhi persyaratan tinggi untuk keamanan transmisi data dan pemenuhan persyaratan untuk mengkonfirmasi transfer data yang berhasil di kedua arah.


SCEF memungkinkan Anda untuk abstrak dari sistem interaksi yang kompleks dengan perangkat NB-IoT, termasuk ketika yang terakhir dalam mode eDRX atau PSM dan tidak tersedia untuk transfer data ke arah perangkat server->. Ketika perangkat telah menerima pendaftaran dan "setuju" dengan jaringan operator jaringan tentang jadwal komunikasi, menggunakan antarmuka yang sederhana, Anda dapat mentransfer data ke perangkat dan menerima data darinya, mengelola "berlangganan" perangkat Anda dan AS ke acara-acara tertentu, mengatur dan mengikat yang unik sendiri Nama ID universal dan banyak lagi. Semua ini melalui antarmuka yang sama - T8 API.

Penting untuk dicatat bahwa server (AS) bisa bukan satu, tetapi beberapa, dan Anda dapat secara fleksibel mengkonfigurasi distribusi informasi antara server untuk acara atau kelompok perangkat tertentu.

Bagaimana itu bekerja


Solusi paling populer untuk mengatur akses perangkat ke jaringan seluler adalah penggunaan modul seluler, misalnya:


Ketika mendaftar di jaringan seluler, modul semacam itu mengirimkan informasi kepada operator, termasuk IMSI dari kartu SIM pelanggan yang dapat dikaitkan oleh operator dengan akun pelanggan atau pelanggan itu sendiri jika ia memiliki akses ke akun pribadi operator. Di belakang layar SCEF menyembunyikan pengetahuan tentang sesi komunikasi berikutnya dengan perangkat. Pendaftaran perangkat non-IP di jaringan operator hanya dimungkinkan jika ada setidaknya satu langganan dari SCS / AS ke perangkat ini. Tidak ada langganan - tidak ada yang akan berkomunikasi dengan perangkat ini melalui NIDD, dan perangkat tidak akan terdaftar di jaringan. Dengan demikian, SCEF, mengetahui tentang sesi komunikasi berikutnya, dapat mentransfer data dari / ke perangkat, sesuai dengan parameter pengiriman yang ditentukan dan masa pakai pesan yang dikirim, tanpa perlu mengatur pemantauan tambahan tentang status transfer data dan kontrol pengiriman.

Keringanan


Enkapsulasi unit byte data dari perangkat ke protokol TCP dan mentransfernya ke server mahal dalam hal ratusan ribu perangkat pelanggan dalam armada perusahaan. SCEF memungkinkan Anda untuk meninggalkan IP pada perangkat dan hanya mentransfer data non-IP, tanpa header IP melalui saluran sinyal, yang berkontribusi terhadap pengurangan ganda dalam biaya byte yang ditransmisikan dan memberikan manfaat tambahan dari penggunaan layanan. Selain itu, SCEF tidak membuat perubahan apa pun pada data yang dikirimkan baik ke perangkat maupun darinya, payload ditransmisikan secara transparan. Oleh karena itu, menggunakan NIDD adalah mungkin untuk mentransfer tidak hanya data yang tidak terstruktur, tetapi juga data yang "dibungkus" dalam format standar yang dapat dimengerti, seperti JSON, untuk menyederhanakan pemrosesan data di sisi AS.

Awal pekerjaan


Struktur URI (Uniform Resource Identifier) ​​pada contoh Postman


Pertama-tama, Anda perlu mendapatkan akses ke akun pribadi Anda dari operator (layanan M2M-manager). Untuk implementasi komersial MTS, satu antarmuka Akun Pribadi disediakan, di mana Anda dapat secara mandiri membuat APN, akses login / kata sandi ke API dan menetapkan nama ScsAsID, extID untuk perangkat Anda.

Itu setidaknya kita perlu:
  • ScsAsID - ID AS Anda
  • APN - yang biasanya digunakan untuk berinteraksi dengan jaringan tidak akan berfungsi
  • Login / Kata Sandi - data untuk akses ke akun pribadi Anda dan interaksi dengan SCEF
  • URI - alamat dan port HTTP pada jaringan yang disediakan untuk Anda oleh SCEF
  • externalID - ID perangkat kami


Mari kita lanjutkan berlatih


Teorinya sudah berakhir, mari kita beralih ke bagian yang paling menarik - praktik pada modul produksi SIMCom Wireless Solutions - SIM7020E .

Pertama, Anda perlu mengkonfigurasi modul itu sendiri untuk bekerja dengan NIDD. Untuk melakukan ini, pertama-tama letakkan modul dalam mode CFUN = 0 dan konfigurasikan:

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

Memeriksa pendaftaran modul di jaringan data paket

AT+CGREG?
+CGREG: 0,1

OK

Dan selesai mengatur NIDD

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

OK

Respons modul akan berisi akun_id di sini: + NIDD = 0, <account_id> - ini akan sangat berguna ketika mengaktifkan NIDD pada modul.

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

OK

Dalam hal ini, akun_id adalah 0.

Selesai. Pada tahap ini, pekerjaan dengan modul selesai. Mari beralih ke pengaturan SCEF.

Poin penting: tanpa berlangganan terdaftar di SCEF, modul tidak akan menerima pendaftaran di jaringan!

SCEF


API T8


Ada dokumen khusus yang merinci interaksi dengan SCEF. API ini mendefinisikan serangkaian model data, sumber daya, dan prosedur terkait untuk mentransmisikan data non-IP.



Bekerja dengan SCEF dan langganan layanan - JSON (Notasi Objek JavaScript)


Data yang menyertakan konfigurasi SCEF dan ditransmisikan melalui HTTP / 1.1 ke SCEF harus dikodekan dalam format JSON, dan isi permintaan HTTP itu sendiri di bidang Tipe-Konten harus menyertakan header "application / json". Pada saat yang sama, jika pesan dikirim ke penerima dan konfirmasi pengiriman diterima - SCEF harus menghapus konfigurasi yang sesuai, kirim pesan melalui HTTP POST untuk AS dengan kode status "200 OK" dan nyalakan laporan acara.

Tukang pos


Saya tidak akan mempelajari cara bekerja dengan utilitas ini, di Internet Anda dapat menemukan banyak ulasan. Saya hanya dapat mengatakan bahwa ia memiliki beberapa batasan dalam versi gratisnya, tetapi kami tidak perlu banyak, fungsi yang disediakan secara gratis lebih dari cukup untuk tugas-tugas kami.

Setelah kami mengunduhnya dan membukanya, tab pertama akan menyambut kami - Launchpad, tempat kami akan ditawari untuk membuat permintaan pertama kami, kami tidak akan menolak.


Segera lanjutkan ke konfigurasi perangkat baru kami.

Awalnya, kami telah mengkonfigurasi metode GET, beralih ke POST (beberapa saat kemudian akan menjadi jelas mengapa ini diperlukan). Pada tab "Otorisasi", masukkan "kredensial" yang kami miliki:


Sekarang buat permintaan pertama kami:


Di badan permintaan, kami menunjukkan:

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

Penting!
Perhatikan:
  • “duration” – duration SLA SCEF (SCSAS/ID) , SCEF ,
  • “maximumPacketSize” – /

Mari kita segera perhatikan bahwa opsi berikut dimungkinkan di "pdnEstablishmentOption":
  • WAIT_FOR_UE - buffer jika perangkat tidak tersedia (tidak terdaftar di jaringan atau di PSM atau di negara bagian lain)
  • INDICATE_ERROR - segera merespons dengan kesalahan jika perangkat tidak tersedia
  • SEND_TRIGGER - gunakan layanan Pemicu Perangkat (saluran pengiriman alternatif melalui SMS). Artikel ini tidak dipertimbangkan.

Kami menggunakan parameter yang sama untuk mengirim data ke perangkat. Dan saat membuat langganan, kami dapat segera mengirim data ke perangkat, mengurangi jumlah permintaan API.
Semua! Anda dapat mengklik tombol Kirim dan hati-hati memeriksa apa yang kami dapatkan sebagai respons dari 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"
}

Pada baris pribadi, kami terutama tertarik pada ID dari konfigurasi yang kami buat, sangat tidak diinginkan untuk kehilangannya, karena kemungkinan besar operator tidak akan mendukung fungsi permintaan dari semua konfigurasi yang dibuat. Ketika ada beberapa ribu perangkat yang dibuat dalam kerangka kerja satu ScsAsID, terlalu banyak beban akan dibuat pada server SCEF untuk menyiarkan semua konfigurasi perangkat. Kami menganggapnya sebagai aturan: satu perangkat = satu langganan sebagai bagian dari layanan ScsAsID.

Dengan demikian, kita sudah dapat menerima data dari modul di server, alamat IP dan port yang ditunjukkan di atas.

Transfer data dari modul ke AS


Mari kita coba mentransfer data dari perangkat ke AS, kembali ke modul SIM7020E dan jika kita tidak menyentuhnya dari bab sebelumnya dan tidak mematikannya, kami akan mengirimkan perintah ke sana:

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

Harap dicatat bahwa pesan kami dikodekan dalam HEX dan berisi urutan sederhana: "abcde".
Hampir segera di server (AS), yang merupakan tuan rumah, kita akan melihat:

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}

Pesan itu sendiri tiba dalam penyandian Base64 dan terlihat seperti ini:
YWJjZGU=

Jika kami menerjemahkan dari pengkodean Base64, kami mendapatkan pesan asli kami:
abcde

Pengkodean Base64 digunakan karena fakta bahwa ketika menggunakan pengkodean ASCII, beberapa data kadang-kadang hilang dan menggunakan Base64 membuat transmisi lebih dapat diandalkan.

Perlu juga dicatat bahwa dalam hal ini informasi yang dikirimkan dari modul tidak disimpan di dalam SCEF dan segera dikirim ke server kami melalui HTTP.

Transfer data dari AS ke modul


Untuk mengirim data ke arah dari AS ke modul, mari kembali ke tukang pos dan membuat permintaan baru menggunakan metode POST dan pengkodean Base64. Kami akan mengirimkan 1234567890 (di Base64: MTIzNDU2Nzg5MA ==) ke modul kami:



Harap perhatikan bahwa sebuah addendum telah muncul di bidang "address", di mana kami mengindikasikan konfigurasi mana yang ingin kami kirimi pesan. Jika beberapa perangkat disertakan dalam konfigurasi kami, Anda dapat menggunakan pengenal "externalGroupID" dan kemudian semuanya akan menerima data ini. Poin penting lainnya adalah masa pakai pesan yang dikirim, ditunjukkan dalam hitungan detik dan memiliki jangkauan yang cukup luas.

Ngomong-ngomong, jika perangkat tidak online saat ini, maka pesan kami akan buffered di SCEF, dan baris "maksimumLatency" akan memberi tahu kami berapa detik tersisa sampai pesan dihancurkan jika perangkat tidak menghubungi sebelum timer kami atur. . Di bawah ini adalah apa yang akan terlihat seperti konfigurasi SCEF saat ini (menggunakan mekanisme GET, lebih dari itu di bawah):

{
    "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"
    }
}

Jika, setelah penghitung waktu kedaluwarsa, perangkat masih belum menghubungi, SCEF akan memberi tahu server Anda (AS) bahwa pesan itu tidak terkirim karena penghitung waktu berakhir dan pesan akan dihapus:

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"}

Jika berhasil, SCEF akan segera merespons:

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

Anda dapat menambahkan kemampuan untuk memprioritaskan pesan jika pesan itu di-buffer. Ini diatur oleh parameter "prioritas". Ketika pesan baru dikirim ke perangkat dan jika buffer pengiriman terlampaui oleh SCEF, pesan akan diganti dengan pesan dengan prioritas lebih rendah, jika tidak maka pesan tidak akan diterima untuk pengiriman. Dimungkinkan juga untuk menghapus pesan dari buffer.

Jika pesan tidak dapat dikirim, dan buffer, Anda akan menerima yang berikut:

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

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

Setelah menerima pesan, modul akan melaporkan URC berikut:

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

Yang dalam terjemahan dari HEX ke ASCII akan menjadi pesan kami:

1234567890

Biarkan saja di sini. Pemberitahuan pengiriman pesan "buffered":

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

Memantau status status perangkat dimungkinkan melalui layanan SCEF lain yang disebut “Kegiatan Pemantauan (MONTE)”. Di dalam MONTE, dimungkinkan untuk menerima pemberitahuan tentang acara dan waktu (misalnya, ketika perangkat menjadi tersedia), menggunakan sistem berlangganan serupa. Tapi mari kita bicarakan ini lain kali.

Mendapatkan konfigurasi dari SCEF


Anda mungkin memperhatikan bahwa Anda bisa mendapatkan konfigurasi saat ini dari SCEF. Ayo lakukan itu. Kami mengambil tukang pos yang sudah kami cintai dan membuat permintaan berikut menggunakan metode GET:


Itu kita membiarkan badan pesan itu sendiri kosong, dan di bilah alamat kita hanya perlu menentukan ID konfigurasi yang dibuat untuk kita untuk menerima keadaan saat ini sebagai tanggapan:

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

Menghapus konfigurasi pada SCEF


Baik dan yang terakhir - kami akan menghapus konfigurasi yang dibuat oleh kami. Untuk melakukan ini, gunakan bilah alamat yang sama seperti pada konfigurasi saat ini, tetapi ubah ke DELETE:


Sebagai tanggapan, kami akan menerima:

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

Di mana pada baris "status" kita akan melihat bahwa konfigurasi yang dibuat oleh kami dihapus.

Kesimpulan


Lebih dari satu disertasi dapat ditulis tentang topik menggunakan SCEF, topiknya luas dan akan segera menjadi sangat relevan untuk banyak perangkat M2M di semua bidang, dan terutama untuk Internet hal-hal. Hal utama yang ingin saya sampaikan kepada Anda adalah bagaimana mulai bekerja dengan NIDD dan SCEF di luar kotak sehingga Anda dapat mengetahuinya sendiri. Tetapi saya juga selalu senang membantu Anda: support@simcom.com (ditandai untuk Tim RUS), dalam surat itu Anda harus menunjukkan rincian kontak Anda dan beberapa kata tentang proyek Anda.

Dalam artikel berikut, kami akan menganalisis dengan cermat aspek-aspek lain dari bekerja dengan modul seluler, dan Anda menulis di komentar topik mana yang menarik bagi Anda.

Saya ingin mengucapkan terima kasih khusus kepada Sergey Novikov, pakar senior solusi konvergen dan layanan multimedia.sanov) dari MTS untuk bantuan yang tak ternilai dalam mempersiapkan artikel.

Sumber yang digunakan


NB-IoT: bagaimana cara kerjanya? Bagian 3: SCEF - satu jendela akses ke layanan operator
ETSI TS 129 122

More articles:


All Articles