Gambaran Umum USSD

2025-03-22

Data Layanan Tambahan Tidak Terstruktur (USSD) adalah protokol komunikasi yang digunakan oleh perangkat Global System for Mobile Communications (GSM) untuk berkomunikasi dengan operator jaringan seluler (biasanya disebut sebagai "MO").

Untuk memahami USSD, sangat membantu untuk membandingkannya dengan saudara kandungnya yang paling terkait erat: layanan pesan singkat (SMS). USSD dan SMS adalah standar GSM, yang berarti mereka diperkenalkan sebagai fitur di perangkat seluler generasi kedua. Namun, berbeda dengan SMS, USSD adalah koneksi berbasis sesi. Meskipun SMS digunakan untuk olahpesan tanpa sesi pendek, USSD biasanya digunakan untuk perintah dan kontrol perangkat seluler. Karena diperlukan untuk mempertahankan sesi, USSD tidak mendukung kemampuan store-and-forward seperti yang dilakukan SMS. Pesan USSD dan SMS dikirim dengan karakter yang mematuhi GSM 7-bit, tetapi USSD memiliki batas 184 karakter dibandingkan dengan 160 untuk SMS.

Pesan USSD dapat dikirim dari ponsel dengan membuka dialer dan mengetik kode. Tidak semua kode didukung oleh setiap ponsel atau MO. Dalam beberapa kasus, perangkat lunak telepon atau sistem operasi dapat mencegah pengiriman kode secara manual. Salah satu kode yang diperlukan yang harus diimplementasikan adalah *#06#. Kode ini menampilkan International Mobile Equipment Identifier (IMEI) modem, tetapi beberapa ponsel akan mencegah Anda menghubungi nomor ini secara langsung. Jika Anda mengikuti cara konvensional untuk menemukan IMEI modem melalui pengaturan ponsel Anda, nomor tersebut diambil menggunakan kode ini.

Jika perangkat keras telepon dapat langsung menangani perintah kode seperti dalam contoh IMEI, tidak ada sesi jaringan yang akan dimulai. Kode lain yang memerlukan komunikasi jaringan akan membuka sesi dan kemudian mengirim pesan yang terdiri dari perintah dan parameter yang diperlukan, jika berlaku. Salah satu contohnya adalah kode yang memeriksa saldo Anda saat ini dan status rencana dengan MO.

USSD di Windows diimplementasikan sebagai permukaan API WinRT. Kelas implementasi antarmuka ini berfungsi sebagai mesin keadaan untuk sesi USSD, tetapi pada akhirnya mengandalkan Layanan WWAN untuk melakukan pekerjaan berat. API-API ini diimplementasikan dengan pola pabrik.

Menerapkan USSD

Hal utama yang perlu diingat adalah bahwa API yang menghadap publik didefinisikan oleh IDL. Implementasi dapat membingungkan karena ini, terutama jika Anda tidak terbiasa dengan WinRT. Bagian dari kebingungan berasal dari penggunaan kata 'pabrik' yang tampak ambigu. Faktori dapat merujuk ke implementasi antarmuka statis dari sebuah kelas atau faktori sebenarnya yang menyediakan antarmuka yang dapat diaktifkan ke kelas runtime.

Topik ini meninjau konsep WinRT dan kemudian menjelaskan implementasi berdasarkan konsep-konsep ini. Anda dapat selalu merujuk ke IDL untuk klarifikasi lebih lanjut.

Antarmuka

Antarmuka mengidentifikasi Antarmuka Biner Aplikasi (ABI). Mereka menjelaskan fungsi yang dapat Anda panggil di kelas apa pun yang mengimplementasikan antarmuka.

Kelas Runtime

Ini adalah kelas aktual. Mereka mewakili, berdasarkan nama, apa yang pada akhirnya diekspos sebagai nama kelas ke ABI. Setiap kelas runtime mungkin memiliki nol atau lebih antarmuka (tetapi harus mendeklarasikan setidaknya satu antarmuka default jika memiliki satu atau beberapa antarmuka), nol atau lebih antarmuka statis, dan tag yang dapat diaktifkan jika perlu. Masing-masing antarmuka ini diimplementasikan dalam file yang berbeda sebagai kelas "Impl" yang berbeda namun mereka akan tampak menjadi satu kelas terpadu ke ABI.

Antarmuka biasanya muncul sebagai metode instance pada objek yang ada.

Antarmuka statis muncul kepada klien sebagai metode statis pada kelas runtime itu sendiri.

Tag yang dapat diaktifkan menentukan antarmuka pabrik yang akan menghasilkan instans kelas runtime. Ini tidak terlihat sama sekali oleh klien, muncul sebagai konstruktor untuk kelas runtime itu.

Implementasi USSD

Diagram memperlihatkan implementasi USSD.

Alur: Buka, Kirim, Terima, Tutup.

Buka, Kirim

diagram Alur memperlihatkan permintaan USSD dengan proses balasan.

Klien menggunakan salah satu fungsi statis UssdSession.CreateFromNetworkAccountId atau UssdSession.CreateFromNetworkInterfaceId untuk membuat objek UssdSession.
Terlepas dari API yang disebut, ID antarmuka jaringan diperlukan untuk menginisialisasi UssdSession. Dalam kasus *NetworkAccountID, langkah-langkah diambil untuk mengambil ID antarmuka jaringan dari ID Akun. CreateInternal() dipanggil untuk membuat instans UssdSession dan memanggil Initialize() pada instans yang baru dibuat. Selama langkah-langkah inisialisasi, utas pekerja dijalankan dan pengendali peristiwa untuk memicu peristiwa bagi utas tersebut dibuat. Langkah 3 dan 4 juga dilakukan selama Initialize() dari instance.
Initialize() dipanggil pada objek anggota WwanWrapper. Fungsi ini menerima fungsi panggilan balik statis serta konteks untuk memungkinkan fungsi statis memetakan panggilan balik ke konteks objek.
WwanWrapper membuka handle ke WwanService, mendaftar antarmuka, dan berlangganan pemberitahuan USSD dengan menyediakan penunjuk fungsi panggilan balik statis dan konteks "this".
Objek UssdSession dikembalikan ke klien.
Klien membuat UssdMessage baru dengan memanggil konstruktor dengan string pesan. WinRT mengaburkan UssdMessageFactory pada proses ini.
Klien memanggil SendMessageAndGetReplyAsync pada objek sesi, melewati instans UssdMessage.
Saat ini SendMessageAndGetReplyAsync membuat objek operasi khusus yang disebut UssdSendMessageAndGetReplyOperation. Dari namanya, tampaknya objek tersebut mencakup logika terkait pengiriman satu pesan melewati lapisan (dan menunggu balasan), tetapi ini tidak sesuai kenyataannya. WinRT memerlukan parameter keluar khusus untuk operasi asinkron, yang dapat kita lihat sebagai parameter ke-2 pada definisi untuk fungsi ini.
```
HRESULT SendMessageAndGetReplyAsync(
            [in] UssdMessage* message,
            [out, retval] Windows.Foundation.IAsyncOperation<UssdReply>** asyncInfo);
```
Ini adalah IUssdSendMessageAndGetReplyOperation, antarmuka yang dinamai melalui typedef, yang memenuhi parameter ini dengan menjanjikan bahwa operasi ini pasti akan mengembalikan UssdReply. Antarmuka ini tidak didefinisikan dalam IDL, tetapi diimplementasikan oleh kelas UssdSendMessageAndGetReplyOperationImpl. Perhatikan bahwa header untuk kelas ini memiliki ekstensi khusus:
```
class UssdSendMessageAndGetReplyOperationImpl :
    public Microsoft::WRL::RuntimeClass<
        Windows::Networking::NetworkOperators::IUssdSendMessageAndGetReplyOperation,
        Windows::Internal::AsyncBaseFTM<IUssdSendMessageAndGetReplyCompletedHandler, Microsoft::WRL::SingleResult>>
```
Objek UssdSendMessageAndGetReplyOperation memungkinkan WinRT untuk mengaburkan kompleksitas operasi asinkron ini dan semua kompartementalisasi dan proksi memori yang mengikutinya. Untuk informasi selengkapnya, lihat SendMessageAndGetReplyAsync.

Untuk saat ini, pahami bahwa operasi asinkron yang dijelaskan di atas hanya memanggil kembali ke objek UssdSession tempat logika untuk operasi ini sebenarnya terkandung. Kita dapat memvisualisasikan secara lebih sederhana bahwa UssdSession itu sendiri mengemas pekerjaan di sini. Kita sekarang dapat menegaskan bahwa, terlepas dari sifat asinkron, hanya satu UssdMessage yang dapat dikirim pada satu waktu.

Yang sebenarnya dilakukan oleh fungsi SendMessageAndGetReplyAsync adalah:
- Objek UssdSession berubah menjadi keadaan sibuk, menyimpan konten UssdMessage, dan memulai tindakan asinkron.
- OnOperationStart() adalah titik masuk untuk logika asinkron. Asumsikan untuk skenario ini bahwa tidak ada sesi aktif. Fungsi ini membuat objek WWAN_USSD_REQUEST dengan RequestType=WwanUssdRequestInitiate.
- Langkah 9 dan 10 terjadi sebagai tindakan yang diambil oleh fungsi ini.
m_wwanWrapper.SendRequest dipanggil untuk menangani pekerjaan meneruskan pesan ke WwanService.
WwanWrapper menggunakan handle WwanService untuk memanggil API WwanService dan melakukan tindakan.

Menerima

diagram Alur yang menggambarkan proses penerimaan USSD.

Setelah langkah 10, kami ditinggalkan dalam keadaan di mana permintaan dikirim ke WwanService untuk menginisialisasi sesi USSD baru dan mengirim pesan USSD di bawah sesi tersebut. Setelah beberapa waktu, balasan akan tersedia.

WwanService akan memanggil fungsi panggilan balik statis yang disediakan di langkah 4 dengan konteks yang juga dilampirkan.
Konteks akan digunakan untuk mengambil instans WwanWrapper dan memanggil NotificationCallback().
WwanWrapper akan mengikuti pola yang sama dengan langkah 11, memanggil panggilan balik statis ke UssdSession, menyediakan konteks yang disimpan di langkah 3.
Mirip dengan langkah 12, konteks digunakan untuk memanggil panggilan balik pada instans UssdSession.
UssdSession menyimpan WWAN_USSD_EVENT (dalam keadaan terkunci) dan memberi tahu utas pekerja untuk menangani kejadian.
HandleOperationReply() mengambil objek UssdSendMessageAndGetReplyOperationImpl yang ada dan meneruskan data peristiwa ke handler internalnya.
Operasi akan membangun UssdReply dan memanggil FireCompletion() untuk menandai tindakan asinkron sebagai telah selesai.
WinRT menyamarkan penyelesaian aksi asinkronik dari sudut pandang klien. (Entah mereka telah menunggu tindakan atau memiliki logika pemanggilan balik.)

Lebih banyak pesan dapat dikirim di bawah sesi yang sama. Jika sesi dipertahankan, RequestType di masa mendatang adalah WwanUssdRequestContinue.

Tutup

Diagram Alir memperlihatkan proses penutupan USSD.

Setelah langkah 18, klien telah menerima balasan ke UssdMessage mereka. Mereka mungkin atau mungkin belum terus menggunakan UssdSession aktif untuk mengirim pesan tambahan. Kami akan berasumsi bahwa pada titik tertentu di masa mendatang, klien akan secara manual memanggil Close() pada UssdSession. Jika klien tidak secara eksplisit memanggil Close(), maka fungsi tersebut akan dipanggil selama destruktor UssdSession.

Klien memanggil Close() pada instans UssdSession.
WWAN_USSD_REQUEST dibuat dengan RequestType=WwanUssdRequestCancel.
Permintaan dikirim ke m_wwanWrapper seperti pada langkah 9.
Permintaan dikirim ke WwanService seperti pada langkah 10.

Hasil dari permintaan ini tidak penting. Pada dasarnya, sesi ditutup. Bahkan dalam kasus tepi ekstrem di mana pesan entah bagaimana tidak pernah dikirimkan, sesi USSD baru akan selalu mengambil alih sesi yang ada.

Pengujian Perangkat Keras Lab Kit (HLK)

Lihat langkah-langkah untuk menginstal HLK.

Di HLK Studio sambungkan ke driver Modem Seluler perangkat dan jalankan pengujian: Win6_4.MB.GSM.Data.TestUssd.

Panduan Pemecahan Masalah MB USSD

Kumpulkan dan dekode log menggunakan instruksi di MB Collecting Logs.
Kata kunci untuk pemfilteran
1. OID_WWAN_USSD
2. NDIS_STATUS_WWAN_USSD
3. Permintaan WWAN_USSD
4. WWAN_USSD_EVENT

Lihat Juga

Operasi USSD MB