Plug and Play Mobile Services (PnP-MS) Symbian Mobile

Konsep Teknologi

Layanan Seluler PnP adalah konsep yang, dengan menggunakan teknologi yang ada, menyediakan akses perangkat yang tidak dikonfigurasi (dibeli di mana saja di dunia) kepada pengguna akhir ke portal dukungan khusus operator.

Ini berarti bahwa pengguna akhir dapat mengambil perangkat langsung dari kotak dan perangkat mampu menyetel up koneksi browser dengan portal dukungan tepercaya operator rumah pengguna meskipun ada tidak ada pengaturan khusus operator di perangkat.

Portal dukungan dapat membantu pengguna untuk mendapatkan pengaturan koneksi (dan/atau aplikasi) yang dimuat ke perangkat, dan mungkin memberi pengguna tautan untuk mengunduh, misalnya, nada dering. Semua tentang memulai perangkat untuk menggunakan layanan data. Inti dari PnP-MS adalah mekanisme untuk mendapatkan akses ke URL www.Help-Portal.com/page1, menggunakan nama APN terkenal "initAccess". Dengan cara ini operator dapat membuat domain aman sepenuhnya dalam kendalinya. Operator, melalui infrastruktur jaringan IP-nya, memiliki kekuatan untuk mengarahkan perangkat yang meminta domain http://www.help-potral.com/ ke situs Web yang dikendalikan sendiri, secara default ke portal dukungan lokal. Operator dapat secara mandiri menentukan struktur dan layanan disediakan oleh portal dukungan ini. Selain dua pengaturan pabrik ini, URL dan titik akses,tidak diperlukan pra-konfigurasi pabrik perangkat seluler.

PnP-MS menawarkan model kepercayaan baru yang memanfaatkan hubungan kepercayaan antara klien dan jaringan infrastruktur. PnP-MS menerapkan hubungan SIM-ke-HLR tepercaya untuk menciptakan lingkungan data dengan kepercayaan eksplisit pada operator. Hasilnya mirip dengan sistem berbasis PKI, tetapi tanpa ketidakpastian atau kompleksitas yang terkait dengan penyebaran PKI.

Secara keseluruhan, Layanan Seluler Plug and Play adalah teknologi yang memungkinkan serbaguna dan kompatibel dengan hampir semua model bisnis dan arsitektur layanan. Ini memasok "penemuan layanan data" fungsionalitas yang telah hilang dari jaringan GPRS dan WCDMA. Segala sesuatu yang berhubungan dengan layanan aktivasi, konfigurasi, personalisasi, dan penyesuaian adalah kasus penggunaan di atas inti Kegunaan.

Klien – Antarmuka Server

Bab ini menjelaskan parameter antarmuka klien-ke-server antara klien PnP-MS dan Portal Dukungan.

Ketika "penyediaan melalui HTTP" digunakan, ada juga antarmuka server-ke-klien baru, yaitu, pengemasan dan penandatanganan dokumen OMA CP saat diangkut melalui HTTP. Detailnya ini antarmuka didefinisikan dalam Spesifikasi Layanan Seluler Plug and Play yang dapat diminta dari Layanan Seluler.

1. Komunikasi HTTP :

Klien Layanan Seluler Plug and Play menggunakan HTTP untuk berkomunikasi dengan portal dukungan. Inisial permintaan ke portal mungkin berisi parameter informasi perangkat tambahan. Parameter ini dapat digunakan untuk meningkatkan pengalaman pengguna dengan mengoptimalkan tindakan sisi server.

Klien PnP-MS mengumpulkan informasi seperti kode negara dan jaringan, alasan untuk koneksi, permintaan bantuan opsional, dan versi aplikasi dan mengunggahnya ke portal ketika browser diluncurkan. Parameter dikirim ke portal hanya sekali, dalam permintaan GET pertama ke alamat logis http://www.help-portal.com/page1.

Semua parameter adalah opsional. Namun, mereka berkontribusi secara signifikan terhadap pengalaman pengguna yang baik dan akan digunakan oleh sebagian besar klien PnP-MS yang berdedikasi.

Tabel 1: Nama parameter utama dan formatnya

Contoh Format:

www.help-portal.com/page1?MCC=xxx & MNC=yyy & TOKEN=1234

2. Parameter Permintaan HTTP help-portal.com :

Parameter yang disajikan di bagian ini diunggah dari perangkat ke Portal Dukungan sebagai bagian dari permintaan HTTP GET pertama. Parameter mengungkapkan status perangkat selain kemampuan. Parameter juga digunakan untuk memulai Konteks HTTP tepercaya yang akan digunakan untuk penyediaan melalui HTTP.

3. PKS+MNC (dari kartu SIM)

Informasi tentang jaringan rumah sangat meningkatkan tingkat layanan dalam kasus di mana perangkat dirutekan ke domain help-portal.com global. Konten portal kemudian dapat langsung menjadi diadaptasi tanpa interaksi pengguna, dan pengalihan dapat dilakukan (jika memungkinkan).

Namespace untuk dua parameter ini dapat ditemukan dalam spesifikasi berikut yang diterbitkan sebagai Lampiran pada Buletin Operasional ITU (OB) :

• 803 Daftar Negara Bergerak atau Kode Area Geografis (Pelengkap Rekomendasi ITU-TE.212 (11/98)) (Jabatan pada 1 Januari 2004)
• 801 Mobile Network Code (MNC) untuk rencana identifikasi internasional untuk terminal bergerak dan pengguna ponsel (Menurut Rekomendasi ITU-T E.212 (11/98)) (Posisi pada 1 Desember 2003)

4. PKS+MNC saat ini (dari jaringan tempat perangkat terpasang)

Portal dukungan dapat menggunakan informasi tentang roaming untuk menawarkan fitur yang disesuaikan.

5. TOKEN untuk penyediaan

Klien memberikan kode TOKEN acak ke portal dukungan tepercaya (Layanan Konfigurasi). Itu service meneruskan kode ini ke server penyedia untuk digunakan sebagai USERPIN (menggunakan standar proses penandatanganan) ketika dokumen penyediaan dikirim ke klien. Perangkat kemudian dapat secara otomatis menerima penyediaan tanpa interaksi pengguna yang tidak perlu.

Klien memverifikasi apakah koneksi dipercaya. Jika klien PnP-MS digunakan untuk terhubung menggunakan jalur akses atau jalur akses yang tidak dipercaya, maka TOKEN tidak terkirim. Jalur akses tepercaya dalam GPRS dan Lingkungan WCDMA diidentifikasi dengan nama titik akses "initAccess".

6. Validitas TOKEN

TOKEN yang dikirim ke portal dukungan memiliki masa berlaku terbatas yang diberlakukan oleh klien. Tokennya adalah sehingga berumur pendek.

7. Hubungkan Alasan

Klien menginformasikan portal dukungan alasan koneksi. Portal dukungan dapat menggunakan ini informasi untuk menyesuaikan pengalaman pengguna.

8. Versi kemampuan Layanan Seluler Plug and Play

Parameter versi digunakan untuk mengekspresikan kemampuan Layanan Seluler Plug and Play dari perangkat, karena mereka tidak bergantung pada model perangkat, melainkan pada serangkaian kemampuan yang mungkin diperbarui secara dinamis di perangkat. Versi kapabilitas dapat menyematkan informasi tentang fitur klien yang terkait dengan, misalnya :

• Dukungan penyediaan OTA
•  Dukungan pengunduhan dokumen penyediaan OMA melalui HTTP
•  Dukungan pemicu ke sesi manajemen perangkat OMA
•  Versi keamanan
•  Versi teknologi restart browser

Setiap rilis utama dari agen pengguna tertentu menunjukkan ketidakcocokan ke belakang. Setiap rilis kecil menunjukkan penambahan fungsionalitas yang tidak merusak kompatibilitas mundur. Perlu dicatat bahwa kompatibilitas mundur dalam rilis utama mungkin tidak mutlak, tetapi cukup untuk membuat server mengabaikan perbedaan.

Solusi pembuatan versi ini memberlakukan persyaratan untuk logika manajemen versi di server. Itu server akan memerlukan tabel yang memetakan versi klien tertentu ke fungsionalitas over-the-air yang didukung. Informasi ini kemudian digunakan untuk mengoptimalkan transaksi dengan perangkat tertentu.

 9. Minta Bantuan

Klien dapat meminta bantuan untuk masalah mengatasi masalah lainnya. Artinya, klien PnP-MS menjadi bagian dari lingkungan bantuan online yang lebih umum.

Misalnya, klien PnP-MS dimulai karena pengguna akhir ingin mengonfigurasi aplikasi baru tertentu. Server kemudian menerima permintaan untuk menyediakan konfigurasi yang berdiri sendiri untuk aplikasi ini, atau untuk memicu sesi manajemen untuk mengonfigurasi yang ada dengan mengonfigurasi aplikasi khusus.

Parameter nilai, string, adalah "format bebas". Artinya, tidak ada format khusus yang telah ditentukan, tetapi menyarankan agar beberapa jenis pengidentifikasi nama ruang digunakan di awal string untuk memberi tahu elemen mana yang kueri.

10. Penyediaan Pengaturan

Pengaturan layanan biasanya akan dikirimkan dari portal dukungan ke klien menggunakan teknologi penyediaan OTA yang terkenal. Bergantung pada kemampuan klien, operasi penyediaan dapat dilakukan dengan cara yang berbeda :

• Sebagian besar perangkat mendukung penggunaan OMA CP melalui SMS. Ini adalah teknologi penyediaan default.
• Beberapa perangkat baru yang kompatibel dengan PnP-MS mendukung penggunaan OMA CP melalui HTTP.
• Metode kepemilikan lainnya dapat digunakan.

A TOKEN (lihat “Parameter dari help-portal.com HTTP Request” untuk detail tentang TOKEN dan parameter cVersion) yang digunakan untuk menandatangani pesan Penyediaan CP OMA digunakan untuk memfasilitasi model kepercayaan PnPMS.

Klien PnP-MS memberikan kode TOKEN acak ke portal dukungan tepercaya (layanan konfigurasi) di permintaan HTTP GET pertama. Portal meneruskan kode ini ke server penyedia untuk digunakan sebagai USERPIN (menggunakan proses penandatanganan CP OMA standar) saat dokumen penyediaan dikirim ke klien. Perangkat kemudian dapat secara otomatis menerima penyediaan tanpa pengguna yang tidak perlu interaksi.

Sebelum mengirim TOKEN, klien memverifikasi apakah koneksi tersebut tepercaya. Jika klien PnP-MS adalah digunakan untuk terhubung menggunakan jalur akses atau jalur akses yang tidak terpercaya, maka TOKEN tidak terkirim. Terpercaya titik akses berada di lingkungan GPRS dan WCDMA yang diidentifikasi melalui nama titik akses "initAccess".

Portal dukungan dan server penyedia harus (jika klien mendukungnya) menggunakan TOKEN sebagai USERPIN ketika pesan OMA CP ditandatangani untuk pengiriman ke perangkat (dengan asumsi bahwa klien memberikan TOKEN ke portal dukungan). Portal dukungan dapat menyimpulkan dari cVersion parameter apakah klien dapat memetakan TOKEN menjadi parameter PENGGUNA CP OMA, dan jika ini pemetaan dimungkinkan baik dalam hal pengiriman SMS, atau dalam hal pengiriman melalui HTTP. Jika konsep TOKEN tidak dapat digunakan, metode lain, seperti input manual USERPIN, harus digunakan. Namun, ini tidak nyaman dan meningkatkan risiko kesalahan.

Kemasan sebenarnya dari dokumen OMA CP untuk transportasi melalui HTTP didefinisikan dalam Plug and Play. Spesifikasi Layanan Seluler. Spesifikasi ini mendefinisikan penggunaan pembungkus untuk pengemasan, mirip dengan satu digunakan dalam OMA DRM.

Menyebarkan Layanan Penyediaan Pengaturan

Bab ini menyajikan prinsip-prinsip penerapan layanan penyediaan pengaturan menggunakan Plug dan arsitektur Play Mobile Services dengan portal dukungan lokal. Komponen yang dibutuhkan dan fungsi dan interaksi (setidaknya pada tingkat logis) dijelaskan kemudian dalam bab ini. Layanan yang tersedia di portal dukungan lokal sama sekali tidak terbatas pada penyediaan pengaturan; memiliki telah digunakan di sini sebagai contoh konkret.

Portal dukungan lokal berarti dalam konteks ini layanan yang dirancang dan dipelihara oleh operator alih-alih menggunakan Portal Dukungan global (fallback) di http://www.help-portal.com/ dioperasikan oleh Produsen seluler sejenis (dan produsen perangkat lainnya).

Produsen seluler menganjurkan untuk mengubah rute domain portal bantuan.com (melalui DNS atau lainnya sarana yang sesuai) ke portal dukungan lokal khusus operator ini.

1. Layanan Penyediaan Pengaturan

 Sejauh ini konsumen mengalami banyak kesulitan untuk mendapatkan pengaturan awal ke perangkat seluler mereka untuk layanan seperti browsing dan pesan multimedia. Langkah-langkah kompleks untuk melakukannya secara praktis memblokir potensi penggunaan layanan tersebut, atau kebutuhan akan dukungan menyebabkan beban tambahan pada meja layanan.

Dengan bantuan arsitektur Layanan Seluler Plug and Play dan aplikasi klien pendukung, situasi dapat disederhanakan dengan menyiapkan layanan penyediaan pengaturan yang dapat diakses dengan perangkat yang tidak dikonfigurasi sebelumnya.

Pengguna meluncurkan layanan dengan mengklik "Bantuan Layanan" (klien PnP-MS) atau yang setara di menu untuk sambungkan ke portal dukungan lokal atau, jika tidak tersedia, ke situs cadangan global. Dalam beberapa perangkat fungsionalitas PnP-MS disertakan ke dalam urutan boot pertama dengan kartu SIM baru.

Koneksi yang sama dapat dibuat hanya dengan meluncurkan browser menggunakan bookmark (atau default beranda) didefinisikan sebagai www.help-portal.com/page1 dan "initAccess" tetapi kemudian perangkat tambahan informasi tidak dapat dikirim. Setelah itu, dalam kasus yang paling mudah, pengguna menerima penyediaan akan dieksekusi.

Pengalaman pengguna akhir dalam menerima setelan bergantung pada metode penyediaan. Penyediaan dapat menjadi 'diam' (yaitu, tidak ada interaksi pengguna yang diperlukan) ketika OMA CP melalui HTTP dan TOKEN yang dikirim oleh klien PnPMS digunakan, atau mungkin memerlukan penerimaan pengguna atas pesan penyediaan dan mengetik kode PIN khusus. Di lingkungan operator, tentu saja, juga dimungkinkan untuk menggunakan penandatanganan NETWPIN mekanisme yang didefinisikan dalam OMA CP melalui SMS. Portal dukungan mungkin menawarkan berbagai layanan lain selain layanan pengaturan.

2. Ringkasan Persyaratan

Penyebaran portal dukungan dan layanan pengaturan memerlukan aplikasi Web, yaitu: aplikasi portal, selain klien PnP-MS opsional. Dengan asumsi bahwa server penyedia adalah tersedia, tidak diperlukan elemen jaringan baru, tetapi jaringan itu sendiri perlu dikonfigurasi untuk mendukung "initAccess" GPRS Access Point Node (APN).

Contoh Gambar : Penyediaan pengaturan menggunakan Layanan Seluler Plug and Play

Tabel 2 secara singkat merangkum persyaratan utama.

Tabel 2: Persyaratan utama

3. Plug and Play Klien Layanan Seluler

Saat diluncurkan, klien PnP-MS harus selalu menggunakan Nama Titik Akses “initAccess” terlebih dahulu di coba sambungkan ke URL www.help-portal.com/page1.

Jika upaya untuk terhubung melalui "initAccess" gagal, maka klien dapat menjalankan operasi fallback. Ini fallback terdiri dari penggunaan pengaturan konektivitas aktif (default) browser untuk mendapatkan akses ke URL yang sama. Model kepercayaan PnP-MS tidak valid dalam skenario mundur, dan perangkat seluler tidak menawarkan parameter TOKEN ke server. Hal ini membuat tidak mungkin untuk menggunakan penyediaan melalui HTTP.

Klien PnP-MS harus menyediakan parameter informasi perangkat ke portal dukungan. Mungkin mengumpulkan informasi seperti kode negara dan jaringan, alasan, permintaan bantuan, dan versi aplikasi dan unggah ke portal saat browser diluncurkan. Parameter harus dikirim ke portal saja sekali, dalam permintaan GET pertama ke www.help-portal.com/page1. Klien harus dapat menerima pesan pengaturan pengaturan menggunakan OTA yang sesuai metode :

• OMA CP melalui HTTP
• OMA CP melalui SMS
• Metode kepemilikan lainnya

Bersama dengan perangkat PnP-MS yang disempurnakan dengan klien PnP-MS, perangkat standar dengan browser pengaturan yang ditetapkan sebagai Beranda = www.help-portal.com/page1, dan Titik Akses = initAccess dapat digunakan. Dalam hal ini manfaat parameter informasi perangkat tidak dapat diperoleh.

4. Infrastruktur jaringan

Jaringan GPRS/GSM perlu dikonfigurasi agar memiliki titik akses yang dapat diakses dengan titik akses beri nama "initAccess", dan pelanggan harus diberikan akses ke titik akses jaringan tersebut.

Gambar : Elemen jaringan Plug and Play Layanan Seluler

5. Titik akses "initAccess"

HLR, SGSN, dan GGSN harus dikonfigurasi untuk mengenali permintaan "initAccess" APN (karena itulah nama yang akan diminta oleh aplikasi klien PnP-MS), dan memetakannya ke GGSN tertentu sumber. APN dan GGSN "initAccess" harus memberikan perangkat klien TCP/HTTP alamat server DNS khusus.

Jaringan harus memiliki APN lain yang menyediakan akses jaringan reguler kepada klien untuk banyak layanan. APN "initAccess" dirancang untuk digunakan hanya untuk dukungan (seperti layanan data penemuan) dan jenis penyediaan layanan.

6. DNS di jaringan IP

Server DNS operator berada di posisi kunci sehubungan dengan perutean permintaan HTTP untuk www.help-portal.com/page1 ke server Web khusus operator. DNS operator, yang terkait dengan "initAccess" APN harus menerjemahkan domain www.helpportal.com ke alamat IP portal dukungan lokal milik operator dan bermerek.

Mungkin juga, karena ini dapat dilihat sebagai segmen jaringan yang terisolasi, menerjemahkan setiap yang tidak diizinkan nama host ke alamat IP portal dukungan lokal. Server www.help-portal.com global memang ada sebagai layanan cadangan, yaitu, jika portal dukungan URL diminta dari DNS generik, kemudian perangkat dirutekan ke situs Web (dalam hal ini di-host oleh produsen perangkat) yang menawarkan jenis layanan pengaturan serupa.

7. Kontrol akses

Untuk membuat domain khusus dan aman untuk layanan konfigurasi dan aktivasi, APN “initAccess”, portal dukungan lokal, dan server DNS khusus semuanya harus ditempatkan di segmen jaringan terisolasi di mana lalu lintas dijaga oleh router/firewall dengan kontrol akses yang sangat ketat.

Kontrol akses ini, dalam banyak kasus, juga dapat dikonfigurasi ke dalam GGSN (APN). Saat menggunakan APN "initAccess", akses jaringan IP mungkin dibatasi hanya untuk dukungan lokal pintu gerbang.

8. Proksi HTTP

Klien Layanan Seluler Plug and Play, termasuk klien Nokia Symbian S60 dan S40 (java), secara eksplisit tidak gunakan gateway WAP atau proxy HTTP; sebaliknya mereka terhubung langsung ke server Web.

Penyebaran harus menekankan fakta bahwa klien PnP-MS tidak dikonfigurasi sebelumnya dengan cara apa pun dan alamat APN "initAccess" dan URL www.help-portal.com/page1 adalah satu-satunya nilai prasetel di perangkat ini. Klien PnP-MS akan meminta alamat server Web dari Domain Name Server (DNS), dengan : mengeluarkan permintaan ke www.help-portal.com. Alamat DNS disediakan oleh GGSN (yaitu, APN).

Dimungkinkan untuk menggunakan perangkat apa pun yang mendukung TCP dan HTTP (dan XHTML untuk kenyamanan kegunaan). Sebuah cara sederhana untuk mengaktifkan perangkat untuk PnP-MS adalah dengan memuat/membuat bookmark yang sesuai. Pilihan lainnya adalah sudah memasang bookmark ini di pabrik, dan bahkan mungkin diaktifkan sebagai rumah default halaman perangkat.

Jika perangkat seluler bekas tidak memiliki klien PnP-MS, tetapi sebagai alternatif bookmark dengan URL www.help-portal.com/page1 dan menggunakan APN yang ada, maka kebutuhan akan WAP Gateway ditentukan oleh infrastruktur jaringan.

Gateway WAP dapat digunakan untuk otentikasi MSISDN sebagai solusi sementara sampai klien SIR telah digunakan (dengan asumsi bookmark yang telah dikonfigurasi sebelumnya). Lihat Bagian 4.6, “Otentikasi Klien” untuk informasi lebih lanjut. Jika proxy HTTP akan transparan, yaitu, tidak secara eksplisit ditangani oleh klien, maka itu tidak bisa digunakan untuk otentikasi.

9. SGSN di jaringan GPRS

Kapasitas berlisensi SGSN mungkin dalam beberapa penerapan menyebabkan masalah jika semua pelanggan GSM diberikan akses GPRS ke "initAccess" APN PnP-MS. Namun, ada beberapa faktor yang dapat digunakan untuk mengurangi situasi :

• Sebagian besar perangkat GPRS yang diketahui dikirim dari pabrik dengan pengaturan mode pengoperasian GPRS yang ditetapkan sebagai "Bila diperlukan". Ini berarti bahwa mereka akan melakukan GPRS melampirkan dengan SGSN hanya ketika mereka secara eksplisit membutuhkan komunikasi data.
• Anda dapat meminta perangkat baru yang dijual ke jaringan agar mode pengoperasian GPRS disetel ke "Bila diperlukan". Pengecualiannya adalah smartphone kelas atas yang diharapkan memiliki banyak konektivitas data (dan masuk akal untuk mengoptimalkan pengalaman pengguna).
• Fitur SGSN "Detach Timer" dapat digunakan. Timer ini akan melepaskan ponsel yang terhubung dengan GPRS yang tidak aktif. Seringkali pengatur waktu ini disetel ke nilai seperti 12 jam atau bahkan lebih. Dalam banyak kasus bahkan tidak digunakan. Namun, itu dapat dengan mudah diatur ke nilai seperti 6 jam, atau bahkan agresif seperti 3 jam.
• Perangkat dengan mode operasi GPRS "Jika tersedia" akan mencoba menyambung kembali, tetapi bukti dari penerapan menunjukkan pengurangan beban SGSN yang signifikan.
• Selain fitur pelepasan SGSN, pembersihan database SMMU SGSN yang lebih agresif dapat ditentukan.
• Selama masa transisi, hak untuk menggunakan APN “initAccess” mungkin terbatas pada mereka yang memiliki izin untuk menggunakan layanan GPRS biasa (yaitu, semacam langganan GPRS)

Catatan : Ketika kapasitas SGSN mencapai batasnya, perangkat baru yang mencoba melakukan "attach GPRS" akan ditolak. Oleh karena itu, penting untuk memiliki kapasitas SGSN yang memadai (tetapi ada beberapa metode yang dapat digunakan untuk mengurangi beban).

10. Penyedia Server

Server penyediaan mengirimkan pengaturan ke perangkat seluler menggunakan penyediaan yang sesuai protokol. Dalam arsitektur PnP-MS, server penyediaan dikonfigurasi sehingga portal dukungan di izinkan untuk memulai penyediaan dengan parameter yang sesuai, seperti nomor telepon atau alamat IP, model, dan versi perangkat lunak. Bergantung pada kemampuan klien, operasi penyediaan dapat dijalankan dengan cara yang berbeda :

• Sebagian besar perangkat mendukung penggunaan OMA CP melalui SMS.
• Beberapa perangkat baru yang kompatibel dengan PnP-MS mendukung penggunaan OMA CP melalui HTTP.
• Metode kepemilikan lainnya juga dapat digunakan

Menandatangani pesan penyediaan menggunakan TOKEN memberlakukan model kepercayaan PnP-MS. Portal dukungan meneruskan kode TOKEN, yang awalnya disediakan oleh klien, ke penyediaan server. TOKEN akan digunakan sebagai USERPIN (menggunakan proses penandatanganan yang ditentukan dengan baik) ketika dokumen penyediaan dikirim ke klien. Perangkat kemudian dapat secara otomatis menerima penyediaan tanpa interaksi pengguna yang tidak perlu. Server penyedia harus (jika klien mendukungnya) menggunakan TOKEN sebagai USERPIN ketika pesan OMA CP ditandatangani untuk pengiriman ke perangkat (dengan asumsi bahwa klien menyediakan TOKEN ke portal dukungan dan portal menyampaikannya ke server penyedia).

11. Otentikasi Klien

Jika penyediaan dilakukan melalui HTTP, otentikasi klien biasanya tidak diperlukan untuk penyediaan itu sendiri, tetapi layanan yang disediakan mungkin memerlukan identitas.

Beberapa kasus penggunaan, seperti yang menyertakan aktivasi layanan atau langganan layanan, memerlukan identitas klien yang diautentikasi, atau setidaknya perangkat klien (misalnya, nomor telepon). Otentikasi klien dapat dilakukan di jaringan GPRS. GGSN mengetahui nomor telepon klien dan biasanya mengomunikasikannya ke server AAA (atau proxy) menggunakan protokol Radius. Dalam banyak instalasi, Gateway WAP juga memiliki informasi ini. Aplikasi Web portal dukungan dapat mengambil informasi dari gateway WAP atau dari server AAA.

Alternatif lain untuk otentikasi adalah dengan menggunakan SMS. Misalnya, dimungkinkan untuk meminta pengguna akhir untuk mengirim pesan SMS ke nomor tertentu. Isi pesan SMS dapat berupa kode referensi yang dipublikasikan melalui aplikasi Web.

Ada beberapa kasus penggunaan, misalnya penyediaan menggunakan SMS sebagai pembawa, yang bekerja dengan baik dengan identitas yang diberikan pengguna sebagai lawan dari identitas yang diautentikasi. Metode ini terbukti dalam praktik, karena sudah ada banyak layanan di mana pengguna akhir memasukkan nomor telepon yang harus dikirimi pesan penyediaan.

12. Menggunakan WAP Gateway

MSISDN dapat ditanyakan dari SIR (Subscriber Identification Resolver) WAP Gateway komponen yang mampu menyelesaikan data pelanggan dari alamat IP. SIR menerima pelanggan informasi dari GGSN. Fungsionalitas server SIR dari Gateway WAP dapat digunakan bahkan jika lalu lintas tidak dirutekan pintu gerbang.

Selain itu, Nokia menawarkan kode contoh klien SIR yang berjalan di lingkungan Java™. klien SIR adalah satu set kelas Java (yang berjalan pada platform server Web Java). Kiriman adalah kode sumber yang dapat digunakan seperti itu, atau sebagai contoh bagaimana klien SIR dapat diimplementasikan. WAP Gateway (dan HTTP Proxy) dapat memberikan nomor MSISDN ke server penyedia sebagai bagian dari header HTTP. Namun, ini bukan cara implementasi yang disarankan.

13. Aplikasi Web Portal Dukungan Lokal

Segmen jaringan yang dapat diakses dari titik akses "initAccess" harus memiliki server Web yang berisi layanan Web yang sesuai untuk bertindak sebagai portal dukungan lokal. Portal ini menghubungkan pengguna ke layanan yang tersedia.

Petunjuk visual dari halaman awal portal dukungan (URL: www.help-portal.com/page1) harus sebagai sesederhana mungkin untuk menarik terutama bagi pengguna baru yang tidak terbiasa dengan layanan data apa pun. Layanan terpenting yang tersedia melalui halaman awal adalah memicu pengiriman pesan konfigurasi ke perangkat. Mengirim pesan konfigurasi ke perangkat seluler yang benar memerlukan nomor telepon (MSISDN) perangkat kecuali OMA CP melalui HTTP digunakan. Nomor telepon terutama harus diambil oleh sarana otentikasi jaringan.

Jika otentikasi jaringan awalnya tidak dapat digunakan, layanan yang dipilih masih dapat digunakan. Beberapa layanan dasar dapat diimplementasikan (tanpa risiko signifikan) bahkan dengan ponsel sederhana yang dimasukkan pengguna nomor atau metode alternatif, seperti verifikasi identitas melalui pos dan SMS balasan, dapat dimanfaatkan. Otentikasi yang andal hanya menjadi sangat penting pada tahap implementasi lebih lanjut ketika aktivasi dan langganan layanan, alih-alih penyediaan pengaturan biasa, menjadi pusatnya dari fungsionalitas.

Domain help-portal.com memiliki ruang nama URL yang dicadangkan. Semua jalur yang dimulai dengan "/ halaman" adalah dicadangkan untuk penggunaan di masa mendatang. Layanan portal dukungan lokal tidak boleh menggunakan URL seperti www.helpportal.com/pageA atau www.help-portal.com/pagetwo kecuali diizinkan secara eksplisit dalam PnP-MS spesifikasi. Jika dan ketika diizinkan, maka semantik juga akan ditentukan.

Implementasi server juga akan sangat diuntungkan dari informasi tambahan yang dikomunikasikan dalam HTTP header User-Agent dan Accept-Language. Misalnya, perangkat Nokia menggunakan beberapa metode untuk menunjukkan model telepon ke server. Itu metode dengan penetrasi tertinggi adalah komunikasi model telepon di Pengguna browser Header HTTP agen. Alternatifnya adalah dengan menggunakan tajuk UAPROF yang dalam banyak kasus ditambahkan oleh tumpukan HTTP.

Istilah dan Singkatan