NB-IoT: bagaimana cara kerjanya? Bagian 3: SCEF – satu jendela akses ke layanan operator

Di dalam artikel "NB-IoT: bagaimana cara kerjanya? Bagian 2", berbicara tentang arsitektur inti paket jaringan NB-IoT, kami menyebutkan kemunculan node SCEF baru. Kami jelaskan di bagian ketiga apa itu dan mengapa itu diperlukan?

NB-IoT: bagaimana cara kerjanya? Bagian 3: SCEF – satu jendela akses ke layanan operator

Saat membuat layanan M2M, pengembang aplikasi menghadapi pertanyaan berikut:

  • cara mengidentifikasi perangkat;
  • algoritma verifikasi dan otentikasi apa yang digunakan;
  • protokol transport mana yang harus dipilih untuk berinteraksi dengan perangkat;
  • cara mengirimkan data ke perangkat dengan andal;
  • bagaimana mengatur dan menetapkan aturan untuk bertukar data dengan mereka;
  • cara memantau dan memperoleh informasi mengenai kondisinya secara online;
  • cara mengirimkan data secara bersamaan ke sekelompok perangkat Anda;
  • cara mengirim data secara bersamaan dari satu perangkat ke beberapa klien;
  • cara mendapatkan akses terpadu ke layanan operator tambahan untuk mengelola perangkat Anda.

Untuk mengatasinya, perlu untuk menciptakan solusi yang secara teknis “berat”, yang mengarah pada peningkatan biaya tenaga kerja dan waktu pemasaran layanan. Di sinilah node SCEF baru hadir untuk menyelamatkan.

Sebagaimana didefinisikan oleh 3GPP, SCEF (fungsi paparan kemampuan layanan) adalah komponen baru dari arsitektur 3GPP yang fungsinya untuk secara aman mengekspos layanan dan kemampuan yang disediakan oleh antarmuka jaringan 3GPP melalui API.

Dengan kata sederhana, SCEF adalah perantara antara jaringan dan server aplikasi (AS), satu jendela akses ke layanan operator untuk mengelola perangkat M2M Anda di jaringan NB-IoT melalui antarmuka API standar yang intuitif.

SCEF menyembunyikan kompleksitas jaringan operator, memungkinkan pengembang aplikasi untuk mengabstraksikan mekanisme spesifik perangkat yang kompleks untuk berinteraksi dengan perangkat.

Dengan mengubah protokol jaringan menjadi API yang familiar bagi pengembang aplikasi, SCEF API memfasilitasi pembuatan layanan baru dan mengurangi waktu pemasaran. Node baru ini juga mencakup fungsi untuk mengidentifikasi/mengautentikasi perangkat seluler, menentukan aturan pertukaran data antara perangkat dan AS, menghilangkan kebutuhan bagi pengembang aplikasi untuk mengimplementasikan fungsi-fungsi ini di pihak mereka, dan mengalihkan fungsi-fungsi ini ke pundak operator.

SCEF mencakup antarmuka yang diperlukan untuk otentikasi dan otorisasi server aplikasi, menjaga mobilitas UE, transfer data dan pemicuan perangkat, akses ke layanan tambahan dan kemampuan jaringan operator.

Menuju AS terdapat antarmuka T8 tunggal, API (HTTP/JSON) yang distandarisasi oleh 3GPP. Semua antarmuka, kecuali T8, beroperasi berdasarkan protokol DIAMETER (Gbr. 1).

NB-IoT: bagaimana cara kerjanya? Bagian 3: SCEF – satu jendela akses ke layanan operator

T6a – antarmuka antara SCEF dan MME. Digunakan untuk prosedur manajemen Mobilitas/Sesi, transmisi data non-IP, penyediaan peristiwa pemantauan dan penerimaan laporannya.

S6t – antarmuka antara SCEF dan HSS. Diperlukan untuk otentikasi pelanggan, otorisasi server aplikasi, mendapatkan kombinasi ID eksternal dan IMSI/MSISDN, menyediakan peristiwa pemantauan dan menerima laporan tentangnya.

S6m/T4 – antarmuka dari SCEF ke HSS dan SMS-C (3GPP mendefinisikan node MTC-IWF, yang digunakan untuk memicu perangkat dan transmisi SMS di jaringan NB-IoT. Namun, dalam semua implementasi, fungsionalitas node ini terintegrasi ke dalam SCEF, jadi untuk menyederhanakan rangkaian, kami tidak akan mempertimbangkannya secara terpisah). Digunakan untuk memperoleh informasi routing untuk pengiriman SMS dan interaksi dengan SMS center.

T8 – Antarmuka API untuk interaksi SCEF dengan server aplikasi. Baik perintah kontrol maupun lalu lintas dikirimkan melalui antarmuka ini.

*pada kenyataannya ada lebih banyak antarmuka; hanya yang paling dasar yang tercantum di sini. Daftar lengkap diberikan dalam 3GPP 23.682 (4.3.2 Daftar Titik Acuan).

Di bawah ini adalah fungsi dan layanan utama SCEF:

  • menghubungkan pengenal kartu SIM (IMSI) ke ID eksternal;
  • transmisi lalu lintas non-IP (Pengiriman Data Non-IP, NIDD);
  • operasi grup menggunakan ID grup eksternal;
  • dukungan untuk mode transmisi data dengan konfirmasi;
  • buffering data MO (Mobile Originated) dan MT (Mobile Terminated);
  • otentikasi dan otorisasi perangkat dan server aplikasi;
  • penggunaan data secara simultan dari satu UE oleh beberapa AS;
  • dukungan untuk fungsi pemantauan status UE khusus (MONTE – Monitoring Events);
  • pemicuan perangkat;
  • menyediakan roaming data non-IP.

Prinsip dasar interaksi antara AS dan SCEF didasarkan pada apa yang disebut skema. langganan. Jika perlu untuk mendapatkan akses ke layanan SCEF untuk UE tertentu, server aplikasi perlu membuat langganan dengan mengirimkan perintah ke API spesifik dari layanan yang diminta dan menerima pengidentifikasi unik sebagai tanggapan. Setelah itu semua tindakan dan komunikasi lebih lanjut dengan UE dalam kerangka layanan ini akan dilakukan menggunakan pengidentifikasi ini.

ID Eksternal: Pengidentifikasi perangkat universal

Salah satu perubahan terpenting dalam skema interaksi antara AS dan perangkat saat bekerja melalui SCEF adalah munculnya pengenal universal. Kini, alih-alih menggunakan nomor telepon (MSISDN) atau alamat IP, seperti yang terjadi pada jaringan 2G/3G/LTE klasik, pengidentifikasi perangkat untuk server aplikasi menjadi “ID eksternal”. Ini didefinisikan oleh standar dalam format yang familiar bagi pengembang aplikasi “ @ "

Pengembang tidak perlu lagi menerapkan algoritme autentikasi perangkat; jaringan sepenuhnya mengambil alih fungsi ini. ID Eksternal terkait dengan IMSI, dan pengembang dapat yakin bahwa ketika mengakses ID eksternal tertentu, ia berinteraksi dengan kartu SIM tertentu. Saat menggunakan chip SIM, Anda mendapatkan situasi yang benar-benar unik ketika ID eksternal secara unik mengidentifikasi perangkat tertentu!

Selain itu, beberapa ID eksternal dapat ditautkan ke satu IMSI - situasi yang lebih menarik muncul ketika ID eksternal secara unik mengidentifikasi aplikasi tertentu yang bertanggung jawab atas layanan tertentu pada perangkat tertentu.

Pengidentifikasi grup juga muncul - ID grup eksternal, yang mencakup sekumpulan ID eksternal individual. Sekarang, dengan satu permintaan ke SCEF, AS dapat memulai operasi grup - mengirimkan data atau perintah kontrol ke beberapa perangkat yang digabungkan menjadi satu grup logis.

Karena kenyataan bahwa bagi pengembang AS, transisi ke pengidentifikasi perangkat baru tidak dapat dilakukan secara instan, SCEF meninggalkan kemungkinan komunikasi AS dengan UE melalui nomor standar - MSISDN.

Transmisi lalu lintas non-IP (Pengiriman Data Non-IP, NIDD)

Di NB-IoT, sebagai bagian dari optimalisasi mekanisme transmisi data dalam jumlah kecil, selain tipe PDN yang sudah ada, seperti IPv4, IPv6 dan IPv4v6, tipe lain telah muncul - non-IP. Dalam hal ini, perangkat (UE) tidak diberi alamat IP dan data dikirimkan tanpa menggunakan protokol IP. Lalu lintas untuk koneksi tersebut dapat dirutekan dengan dua cara: klasik - MME -> SGW -> PGW dan kemudian melalui terowongan PtP ke AS (Gbr. 2) atau menggunakan SCEF (Gbr. 3).

NB-IoT: bagaimana cara kerjanya? Bagian 3: SCEF – satu jendela akses ke layanan operator

Metode klasik tidak menawarkan keuntungan khusus apa pun dibandingkan lalu lintas IP, kecuali mengurangi ukuran paket yang dikirimkan karena tidak adanya header IP. Penggunaan SCEF membuka sejumlah kemungkinan baru dan secara signifikan menyederhanakan prosedur interaksi dengan perangkat.

Saat mentransmisikan data melalui SCEF, ada dua keunggulan yang sangat penting dibandingkan lalu lintas IP klasik:


Pengiriman lalu lintas MT ke perangkat melalui ID eksternal

Untuk mengirim pesan ke perangkat IP klasik, AS harus mengetahui alamat IP-nya. Di sini muncul masalah: karena perangkat biasanya menerima alamat IP "abu-abu" saat registrasi, perangkat berkomunikasi dengan server aplikasi, yang terletak di Internet, melalui node NAT, di mana alamat abu-abu diterjemahkan menjadi putih. Kombinasi alamat IP abu-abu dan putih bertahan dalam waktu terbatas, bergantung pada pengaturan NAT. Rata-rata, untuk TCP atau UDP - tidak lebih dari lima menit. Artinya, jika tidak ada pertukaran data dengan perangkat ini dalam waktu 5 menit, koneksi akan terputus dan perangkat tidak lagi dapat diakses di alamat putih yang digunakan untuk memulai sesi dengan AS. Ada beberapa solusi:

1. Gunakan detak jantung. Setelah koneksi dibuat, perangkat harus bertukar paket dengan AS setiap beberapa menit, sehingga mencegah penutupan terjemahan NAT. Namun tidak ada pembicaraan mengenai efisiensi energi di sini.

2. Setiap saat, jika perlu, periksa ketersediaan paket untuk perangkat di AS - kirim pesan ke uplink.

3. Buat APN pribadi (VRF), di mana server aplikasi dan perangkat akan berada di subnet yang sama, dan tetapkan alamat IP statis ke perangkat. Ini akan berhasil, tetapi hampir tidak mungkin jika kita berbicara tentang armada yang terdiri dari ribuan, puluhan ribu perangkat.

4. Terakhir, opsi yang paling sesuai: gunakan IPv6, tidak memerlukan NAT, karena alamat IPv6 dapat diakses langsung dari Internet. Namun, meskipun demikian, ketika perangkat didaftarkan ulang, perangkat akan menerima alamat IPv6 baru dan tidak lagi dapat diakses menggunakan alamat sebelumnya.

Oleh karena itu, perlu mengirimkan beberapa paket inisialisasi dengan pengidentifikasi perangkat ke server untuk melaporkan alamat IP baru perangkat tersebut. Kemudian menunggu paket konfirmasi dari AS, yang juga mempengaruhi efisiensi energi.

Metode ini bekerja dengan baik pada perangkat 2G/3G/LTE, dimana perangkat tersebut tidak memiliki persyaratan ketat untuk otonomi dan, sebagai hasilnya, tidak ada batasan pada waktu tayang dan lalu lintas. Metode ini tidak cocok untuk NB-IoT karena konsumsi energinya yang tinggi.

SCEF memecahkan masalah ini: karena satu-satunya pengidentifikasi perangkat untuk AS adalah ID eksternal, AS hanya perlu mengirim paket data ke SCEF untuk ID eksternal tertentu, dan SCEF akan mengurus sisanya. Jika perangkat berada dalam mode hemat daya PSM atau eDRX, data akan di-buffer dan dikirimkan saat perangkat tersedia. Jika perangkat tersedia untuk lalu lintas, data akan segera dikirimkan. Hal yang sama berlaku untuk tim manajemen.

Kapan saja, AS dapat memanggil kembali pesan yang di-buffer ke UE atau menggantinya dengan yang baru.

Mekanisme buffering juga dapat digunakan saat mengirimkan data MO dari UE ke AS. Jika SCEF tidak dapat mengirimkan data ke AS dengan segera, misalnya jika pekerjaan pemeliharaan sedang berlangsung di server AS, paket-paket ini akan di-buffer dan dijamin akan dikirimkan segera setelah AS tersedia.

Seperti disebutkan di atas, akses ke layanan tertentu dan UE untuk AS (dan NIDD adalah layanan) diatur oleh aturan dan kebijakan di sisi SCEF, yang memungkinkan kemungkinan unik penggunaan data secara bersamaan dari satu UE oleh beberapa AS. Itu. jika beberapa AS telah berlangganan pada satu UE, maka setelah menerima data dari UE, SCEF akan mengirimkannya ke semua AS yang berlangganan. Ini sangat cocok untuk kasus di mana pembuat armada perangkat khusus berbagi data antara beberapa klien. Misalnya, dengan membuat jaringan stasiun cuaca yang berjalan di NB-IoT, Anda dapat menjual data dari stasiun tersebut ke banyak layanan secara bersamaan.

Mekanisme pengiriman pesan terjamin

Layanan Data yang Andal adalah mekanisme untuk menjamin pengiriman pesan MO dan MT tanpa menggunakan algoritma khusus di tingkat protokol, seperti jabat tangan di TCP. Ia bekerja dengan menyertakan tanda khusus di bagian layanan pesan ketika dipertukarkan antara UE dan SCEF. Apakah mekanisme ini akan diaktifkan atau tidak saat mentransmisikan lalu lintas ditentukan oleh AS.

Jika mekanisme ini diaktifkan, UE menyertakan flag khusus di bagian overhead paket ketika memerlukan jaminan pengiriman lalu lintas MO. Setelah menerima paket tersebut, SCEF merespons UE dengan pengakuan. Jika UE tidak menerima paket pengakuan, paket menuju SCEF akan dikirim ulang. Hal yang sama terjadi pada lalu lintas MT.

Pemantauan perangkat (pemantauan peristiwa - MONTE)

Seperti disebutkan di atas, fungsi SCEF, antara lain, mencakup fungsi untuk memantau keadaan UE, yang disebut. pemantauan perangkat. Dan jika pengidentifikasi baru dan mekanisme transfer data merupakan optimasi (walaupun sangat serius) dari prosedur yang ada, maka MONTE adalah fungsi yang benar-benar baru yang tidak tersedia di jaringan 2G/3G/LTE. MONTE memungkinkan AS untuk memantau parameter perangkat seperti status koneksi, ketersediaan komunikasi, lokasi, status roaming, dll. Kami akan membicarakan masing-masing secara lebih rinci nanti.

Jika perlu untuk mengaktifkan peristiwa pemantauan apa pun untuk perangkat atau sekelompok perangkat, AS berlangganan layanan terkait dengan mengirimkan perintah API MONTE yang sesuai ke SCEF, yang mencakup parameter seperti Id eksternal atau ID grup eksternal, pengidentifikasi AS, pemantauan jenis, jumlah laporan yang ingin diterima AS. Jika AS diberi wewenang untuk mengeksekusi permintaan tersebut, SCEF, tergantung pada jenisnya, akan menyediakan kejadian tersebut ke HSS atau MME (Gbr. 4). Ketika suatu peristiwa terjadi, MME atau HSS menghasilkan laporan ke SCEF, yang mengirimkannya ke AS.

Penyediaan semua kejadian, kecuali “Jumlah UE yang ada di wilayah geografis”, dilakukan melalui HSS. Dua peristiwa “Perubahan Asosiasi IMSI-IMEI” dan “Status Roaming” dilacak langsung di HSS, sisanya akan disediakan oleh HSS di MME.
Peristiwa dapat terjadi satu kali atau berkala, dan ditentukan oleh jenisnya.

NB-IoT: bagaimana cara kerjanya? Bagian 3: SCEF – satu jendela akses ke layanan operator

Pengiriman laporan tentang suatu peristiwa (reporting) dilakukan oleh node yang melacak peristiwa tersebut langsung ke SCEF (Gbr. 5).

NB-IoT: bagaimana cara kerjanya? Bagian 3: SCEF – satu jendela akses ke layanan operator

Poin penting: Peristiwa pemantauan dapat diterapkan pada perangkat non-IP yang terhubung melalui SCEF dan perangkat IP yang mentransmisikan data dengan cara klasik melalui MME-SGW-PGW.

Mari kita lihat lebih dekat setiap peristiwa pemantauan:

Hilangnya konektivitas — memberi tahu AS bahwa UE tidak lagi tersedia untuk lalu lintas data atau pensinyalan. Peristiwa ini terjadi ketika “pengatur waktu jangkauan seluler” untuk UE berakhir pada MME. Dalam permintaan untuk jenis pemantauan ini, AS dapat menunjukkan nilai "Waktu Deteksi Maksimum" - jika selama waktu ini UE tidak menunjukkan aktivitas apa pun, AS akan diberitahu bahwa UE tidak tersedia, dengan menyebutkan alasannya. Peristiwa tersebut juga terjadi jika UE dihapus secara paksa oleh jaringan karena alasan tertentu.

* Untuk memberi tahu jaringan bahwa perangkat masih tersedia, jaringan memulai prosedur pembaruan secara berkala - Pembaruan Area Pelacakan (TAU). Frekuensi prosedur ini diatur oleh jaringan menggunakan pengatur waktu T3412 atau (T3412_extend dalam kasus PSM), yang nilainya dikirimkan ke perangkat selama prosedur Lampirkan atau TAU berikutnya. Pengatur waktu jangkauan seluler biasanya beberapa menit lebih lama dibandingkan T3412. Jika UE belum membuat TAU ​​sebelum berakhirnya “Timer jangkauan seluler”, jaringan menganggapnya tidak lagi dapat dijangkau.

Keterjangkauan UE – Menunjukkan kapan UE tersedia untuk lalu lintas DL atau SMS. Hal ini terjadi ketika UE tersedia untuk paging (untuk UE dalam mode eDRX) atau ketika UE memasuki mode ECM-CONNECTED (untuk UE dalam mode PSM atau eDRX), yaitu. membuat TAU ​​atau mengirimkan paket uplink.

Pelaporan lokasi – Jenis kejadian pemantauan ini memungkinkan AS menanyakan lokasi UE. Lokasi saat ini (Lokasi Saat Ini) atau lokasi terakhir yang diketahui (Ditentukan oleh ID sel tempat perangkat membuat TAU ​​atau mengirimkan lalu lintas terakhir kali) dapat diminta, yang relevan untuk perangkat dalam mode hemat daya PSM atau eDRX. Untuk “Lokasi Saat Ini”, AS dapat meminta balasan berulang, dan MME akan memberi tahu AS setiap kali lokasi perangkat berubah.

Perubahan Asosiasi IMSI-IMEI – Saat event ini diaktifkan, SCEF mulai memantau perubahan kombinasi IMSI (pengidentifikasi kartu SIM) ​​dan IMEI (pengidentifikasi perangkat). Ketika suatu peristiwa terjadi, informasikan kepada AS. Dapat digunakan untuk secara otomatis mengikat ulang ID eksternal ke perangkat selama pekerjaan penggantian terjadwal atau berfungsi sebagai pengidentifikasi pencurian perangkat.

Status Jelajah – jenis pemantauan ini digunakan oleh AS untuk menentukan apakah UE berada di jaringan asal atau di jaringan mitra roaming. Secara opsional, PLMN (Jaringan Bergerak Darat Umum) dari operator tempat perangkat terdaftar dapat ditransmisikan.

Kegagalan komunikasi — Jenis pemantauan ini memberi tahu AS tentang kegagalan komunikasi dengan perangkat, berdasarkan alasan hilangnya koneksi (kode penyebab pelepasan) yang diterima dari jaringan akses radio (protokol S1-AP). Peristiwa ini dapat membantu menentukan mengapa komunikasi gagal - karena masalah pada jaringan, misalnya, ketika eNodeb kelebihan beban (Sumber daya radio tidak tersedia) atau karena kegagalan perangkat itu sendiri (Koneksi Radio Dengan UE Hilang).

Ketersediaan setelah Kegagalan DDN – peristiwa ini memberi tahu AS bahwa perangkat telah tersedia setelah kegagalan komunikasi. Dapat digunakan ketika ada kebutuhan untuk melakukan transfer data ke suatu perangkat, namun upaya sebelumnya tidak berhasil karena UE tidak merespon notifikasi dari jaringan (paging) dan data tidak terkirim. Jika jenis pemantauan ini telah diminta untuk UE, maka segera setelah perangkat melakukan komunikasi masuk, membuat TAU, atau mengirimkan data ke uplink, AS akan diberitahu bahwa perangkat telah tersedia. Karena prosedur DDN (pemberitahuan data downlink) bekerja antara MME dan S/P-GW, jenis pemantauan ini hanya tersedia untuk perangkat IP.

Status Konektivitas PDN – memberi tahu AS ketika status perangkat berubah (status konektivitas PDN) - koneksi (aktivasi PDN) atau pemutusan sambungan (penghapusan PDN). Hal ini dapat digunakan oleh AS untuk memulai komunikasi dengan UE, atau sebaliknya, untuk memahami bahwa komunikasi tidak lagi memungkinkan. Jenis pemantauan ini tersedia untuk perangkat IP dan non-IP.

Jumlah UE yang ada di suatu wilayah geografis – Jenis pemantauan ini digunakan oleh AS untuk menentukan jumlah UE di wilayah geografis tertentu.

Pemicu perangkat)

Dalam jaringan 2G/3G, prosedur registrasi dalam jaringan terdiri dari dua tahap: pertama, perangkat didaftarkan ke SGSN (prosedur lampirkan), kemudian, jika perlu, mengaktifkan konteks PDP - koneksi dengan gateway paket (GGSN) untuk mengirimkan data. Dalam jaringan 3G, kedua prosedur ini terjadi secara berurutan, yaitu. perangkat tidak menunggu saat diperlukan untuk mentransfer data, tetapi mengaktifkan PDP segera setelah prosedur lampiran selesai. Di LTE, kedua prosedur ini digabungkan menjadi satu, yaitu ketika terhubung, perangkat segera meminta aktivasi koneksi PDN (analog dengan PDP di 2G/3G) melalui eNodeB ke MME-SGW-PGW.

NB-IoT mendefinisikan metode koneksi sebagai “melampirkan tanpa PDN”, yaitu, UE melampirkan tanpa membuat koneksi PDN. Dalam hal ini, tidak tersedia untuk mengirimkan lalu lintas, dan hanya dapat menerima atau mengirim SMS. Untuk mengirim perintah ke perangkat tersebut untuk mengaktifkan PDN dan terhubung ke AS, fungsi “Pemicuan perangkat” dikembangkan.

Saat menerima perintah untuk menghubungkan UE tersebut dari AS, SCEF memulai pengiriman SMS kontrol ke perangkat melalui pusat SMS. Saat menerima SMS, perangkat mengaktifkan PDN dan terhubung ke AS untuk menerima instruksi lebih lanjut atau mentransfer data.

Mungkin ada saatnya langganan perangkat Anda berakhir di SCEF. Ya, langganan memiliki masa pakainya sendiri, ditentukan oleh operator atau disetujui oleh AS. Setelah habis masa berlakunya, PDN akan dinonaktifkan di MME dan perangkat tidak akan tersedia untuk AS. Dalam hal ini, fungsi “Pemicuan perangkat” juga akan membantu. Saat menerima data baru dari AS, SCEF akan mengetahui status koneksi perangkat dan mengirimkan data melalui saluran SMS.

Kesimpulan

Fungsionalitas SCEF, tentu saja, tidak terbatas pada layanan yang dijelaskan di atas dan terus berkembang dan berkembang. Saat ini, lebih dari selusin layanan telah distandarisasi untuk SCEF. Sekarang kami hanya menyentuh fungsi utama yang diminta oleh pengembang, kami akan membicarakan sisanya di artikel mendatang.

Pertanyaan yang segera muncul: bagaimana cara mendapatkan akses pengujian ke node "ajaib" ini untuk pengujian awal dan debugging kasus-kasus yang mungkin terjadi? Semuanya sangat sederhana. Pengembang mana pun dapat mengirimkan permintaan ke [email dilindungi], yang cukup untuk menunjukkan tujuan koneksi, deskripsi kemungkinan kasus, dan informasi kontak untuk komunikasi.

о овых еч!

Penulis:

  • pakar senior di departemen solusi konvergen dan layanan multimedia Sergey Novikov sanov,
  • pakar dari departemen solusi konvergen dan layanan multimedia Alexei Lapshin aslapsh



Sumber: www.habr.com

Tambah komentar