Wireless Telephony Application (WTA)

Chapter 18.11 Aplikasi Telephony Nirkabel (WTA)

WTA menyediakan alat untuk membangun aplikasi telephony. Hal ini terutama dirancang

untuk operator jaringan, operator, dan vendor peralatan. Keamanan jaringan dan

keandalan merupakan pertimbangan utama. Ekstensi dapat ditambahkan ke standar

Browser WML / WMLScript mendukung aplikasi WTA tambahan

Antarmuka Pemrograman (WTAI).

Karena WTA berada di luar cakupan TCP / IP, itu tidak menjamin lebih jauh

diskusi. Namun, informasi tambahan ada di situs OMA di

berikut spesifikasi:

WAP-266-WTA-20010908-a - Spesifikasi Aplikasi Telephony Nirkabel

WAP-268-WTAI-20010908-a - Antarmuka Aplikasi Telephony Nirkabel

Spesifikasi

WAP-255-WTAIGSM-20010908-a-WTAI, Adendum Khusus GSM

WAP-269-WTAIIS136-20010908-a-WTAI, IS-136 Adendum khusus

WAP-270-WTAIPDC-20010908-a-WTAI, Adendum Khusus PDC

WAP-228-WTAIIS95-20010908-a-WTAI, IS95 Adendum khusus

Wireless Identity Module (WIM)

Chapter 18.10.2 Modul Identitas Nirkabel (Wireless Identity Module / WIM)

Dalam menerapkan WTLS, penting untuk memiliki perangkat tamper-proof yang menyimpan

informasi rahasia (seperti kunci dan sertifikat) dan juga bisa melakukan yang lain

fungsi keamanan (seperti kriptologi). Perangkat seperti itu meningkatkan kesulitannya

dihadapi oleh pengguna jahat yang berusaha mendapatkan akses terhadap informasi tersebut. Dalam urutan

Untuk mencapai fungsi ini, arsitektur WAP2 mendefinisikan Wireless Identity

Modul (WIM). Ini biasanya ada sebagai kartu cerdas di dalam perangkat mobile.

Ditetapkan awalnya oleh spesifikasi OMA WAP-260-WIM-20010712-a, WIM digunakan untuk menyimpan kunci pribadi permanen dan menggunakan tombol seperti itu dalam fungsi.

seperti:

• Operasi penandatanganan
• Operasi pertukaran kunci
• Operasi kriptografi

Mengamankan sesi WTLS yang berumur panjang

Operasi ini berada di luar wilayah jaringan, dan dengan demikian menjamin tidak

Diskusi lebih lanjut. Namun, perhatikan bahwa kedua layer WTLS dan layer aplikasi

Wireless Transport Layer Security (WTLS)

Chapter 18.10.1 Keamanan Lapisan Transport Nirkabel (WTLS)

Banyak aplikasi di Web saat ini memerlukan koneksi yang aman antara a

client dan server aplikasi. WTLS adalah protokol keamanan, yang didefinisikan oleh

OMA WAP-261-WTLS-20010406-spesifikasi, untuk memastikan transaksi aman

pada terminal WAP

Catatan: WAP-261-WTLS-20010406-a hanya spesifikasi aslinya. Memiliki

telah diperbarui oleh spesifikasi WAP-261_100-WTLS-20010926-a,

WAP-261_101-WTLS-20011027-a, dan WAP-261_102-WTLS-20011027-a.

WTLS didasarkan pada Transport Layer Security (TLS) standar industri,

protokol, namun telah dioptimalkan untuk penggunaan komunikasi narrow-band

saluran. Ini memastikan integritas data, privasi, otentikasi, dan perlindungan penolakan layanan. Untuk aplikasi Web yang menggunakan standar keamanan internet

Teknik dengan TLS, gateway WAP secara otomatis dan transparan

mengelola keamanan nirkabel dengan biaya pemrosesan minimal. Ini menyediakan end-to-end

keamanan dan keamanan tingkat aplikasi. Ini termasuk fasilitas keamanan untuk

mengenkripsi dan mendekripsi, otentikasi, integritas, dan manajemen kunci yang kuat.

WTLS mematuhi peraturan tentang penggunaan algoritma kriptografi dan

panjang kunci di berbagai negara.

WTLS menggunakan mekanisme adaptasi khusus untuk lingkungan nirkabel

Misalnya, sesi aman lama yang ada, prosedur jabat tangan yang dioptimalkan untuk

jaringan nirkabel, dan reliabilitas data sederhana untuk pengoperasian pembawa datagram.

Gambar 18-21 menunjukkan lokasi WTLS pada model arsitektur WAP dan

arsitektur WTLS internal dengan protokol WTLS yang berbeda.

Tujuan lapisan WTLS

Tujuan utamanya adalah untuk memberikan keamanan antara client dan server dalam hal:

Data Privasi yang dikirim tidak disajikan dalam bentuk teks yang jelas sehingga sulit

bagi pengguna jaringan lain untuk melihat data. Ini sudah selesai

melalui penyandian arus data.

Integritas data Jika pengguna jaringan dapat mengubah data yang dikirim, itu adalah

terdeteksi oleh client atau server yang mengirim data. Ini adalah

dilakukan melalui pesan mencerna.

Otentikasi Mitra jaringan dapat memastikan bahwa dia terhubung

dengan pasangan sejati yang diinginkan dan tidak dengan orang lain

yang berpura-pura menjadi itu Hal ini dilakukan melalui digital

sertifikat.

Denial of service Menolak dan mendeteksi data yang tidak berhasil

diverifikasi. Hal ini dilakukan melalui fungsi WTLS.

Manajemen koneksi WTLS

Manajemen koneksi WTLS menyediakan komunikasi yang aman antara

klien dan server Beberapa langkah diperlukan dalam pendirian koneksi

proses melalui negosiasi untuk menyetujui parameter keamanan antara klien

dan server Hal ini serupa dengan proses pembentukan koneksi yang aman

Secure Socket Layer (SSL) (22,7, "Lapisan Soket Aman (SSL)" pada halaman 854).

Parameter keamanan untuk proses pembentukan koneksi aman bisa

termasuk, misalnya, algoritma kriptografi, prosedur pertukaran kunci, dan

otentikasi.

Layanan primitif memberikan dukungan untuk memulai koneksi yang aman ini. Itu

berikut layanan primitif tersedia:

SEC-Create: Memulai koneksi yang aman dengan pilihan berikut

parameter:

- Sertifikat klien

- Suite pertukaran kunci

- Suite Cipher

- Metode kompresi

- Aturan menyegarkan utama

- Sesi ID

SEC-Exchange: Melakukan otentikasi kunci publik atau pertukaran kunci dengan a

klien. Informasi tambahan tentang kunci publik ada dalam spesifikasi OMA

WAP-217-WPKI-20010424-a, WAP-217_103-WPKI-20011102-a, dan

WAP-217_105-WPKI-20020816-a.

SEC-Commit: Diprakarsai saat jabat tangan selesai dan peer

permintaan untuk beralih ke status koneksi yang disepakati.

SEC-Terminate: Mengakhiri koneksi.

SEC-Exception: Menginformasikan mitra lainnya tentang peringatan tingkat peringatan.

SEC-Create-Request: Server meminta klien untuk melakukan yang baru

jabat tangan

Ikhtisar protokol

Seperti ditunjukkan pada Gambar 18-21 di halaman 697, WTLS terdiri dari empat protokol

komponen:

Protokol rekaman

Protokol jabat tangan

Protokol peringatan

Protokol CipherSpec berubah

Catat protokol

Protokol rekaman adalah antarmuka ke lapisan atas (transaksi atau sesi

lapisan) dan lapisan bawah (transport layer). Ini menerima pesan dari

lapisan atas yang akan ditransmisikan, secara opsional memampatkan data, berlaku a

kode otentikasi pesan (MAC), mengenkripsi pesan, lalu mentransmisikan

pesan. Sebaliknya, data yang diterima didekripsi, diverifikasi, didekompresi,

dan dikirim ke lapisan yang lebih tinggi dari klien. Sisa empat protokol

bekerja sama sangat erat dengan protokol rekaman dalam mencapai langkah-langkah ini.

Protokol handshake

Protokol ini terdiri dari tiga subprotocol yang memungkinkan rekan kerja menyetujui keamanan

parameter untuk lapisan rekam. Protokol jabat tangan bertanggung jawab atas

proses negosiasi antara klien dan server dan digunakan saat

memulai WTLS Parameter ini dinegosiasikan selama jabat tangan:

Pengenal sesi Mengidentifikasi keamanan aktif dan yang dapat diedit

sidang.

Versi protokol versi protokol WTLS versi protokol.

Sertifikat Peer Certificate of the peer.

Metode kompresi Algoritma yang digunakan untuk kompres data sebelum enkripsi

CipherSpec Menentukan algoritma enkripsi data massal (seperti

sebagai null, RC5, DES, dan sebagainya) dan algoritma MAC

(seperti SHA-1). Ini juga mendefinisikan kriptografi

atribut, seperti ukuran MAC.

Rahasia rahasia 20 byte yang dibagi bersama antara client dan server.

Sequence number mode Sequence skema penomoran yang digunakan dalam secure ini

koneksi.

Key refresh Mendefinisikan seberapa sering beberapa nilai keadaan koneksi

(enkripsi kunci, rahasia MAC, dan IV) perhitungan

dilakukan.

Apakah bendera yang dapat diedit menunjukkan apakah sesi aman dapat dilakukan

digunakan untuk memulai koneksi aman baru.

Empat fase digunakan dalam pertukaran protokol jabat tangan, sebelum pengiriman

data aplikasi:

1. Tahap pertama: Selama fase ini, koneksi terjaga dan keamanan

kemampuan dinegosiasikan

2. Tahap kedua: Selama fase ini, otentikasi server dan pertukaran kunci

terjadi

3. Tahap ketiga: Selama tahap ini, otentikasi klien dan pertukaran kunci

terjadi

4. Fase keempat: Penyelesaian pembentukan koneksi aman.

Ubah protokol CipherSpec

Perubahan CipherSpec dikirim oleh klien atau server untuk memberi tahu pasangan lainnya

catatan selanjutnya akan dikirim melalui CipherSpec yang baru dinegosiasikan dan

kunci. Pesan ini dikirim saat jabat tangan setelah parameter keamanan

telah disepakati, tapi sebelum verifikasi selesai pesan dikirim.

Protokol peringatan

Pesan peringatan berisi informasi ke rekan tentang kejadian yang terjadi pada a

koneksi aman. Termasuk dalam alert adalah informasi tentang tingkat keparahan

pesan dan deskripsi peringatan. Tanda dibagi menjadi dua kategori, Penutupan

dan Kesalahan Tanda penutupan memberi informasi tentang mengapa sambungan aman

tertutup atau tidak bisa dibuka, sementara alert kesalahan memberikan rincian tentang kesalahan apapun

yang mungkin terjadi saat koneksi aman sedang berlangsung. Rincian tentang ini

peringatan ada di situs OMA di spesifikasi WAP-219-TLS-20010411.

Terowongan TLS nirkabel

Meski salah satu keunggulan yang diraih dengan menerapkan WAP2 adalah langsung

Koneksi dapat dibangun antara klien dan server WAP, arsitektur WAP2 masih memungkinkan proxy ada antara klien dan server. Seperti

Skenario, proses menyiapkan kemampuan TLS end-to-end menjadi lebih

rumit. Spesifikasi OMA WAP-219-TLS-20010411-spesifikasi alamat ini

dengan mendefinisikan proses pembuatan terowongan TLS di proxy.

Dalam skenario seperti itu, server proxy bertindak hanya sebagai relay data lapisan transport,

Tidak melakukan pemrosesan pada pesan yang dikirim antara server dan klien,

atau meneruskan pesan ke lapisan yang lebih tinggi dalam arsitektur. Ini diilustrasikan

pada Gambar 18-22.

Wireless Security

Chapter 18.10

Bagian ini secara singkat menguraikan Keamanan Lapis Baja Nirkabel, tujuannya, dan

bagaimana mengelola koneksinya dan memberikan gambaran singkat tentang protokol. Sebagai tambahan,

Bagian ini memberikan gambaran singkat tentang Modul Identitas Nirkabel.

Wireless Session Protocol (WSP)

Chapter 18.9.5 Protokol Sesi Nirkabel (WSP)

WSP, yang didefinisikan oleh OMA WAP-230-WSP-20010705-spesifikasi,

membuat sesi yang andal antara klien dan server dan melepaskannya

sesi secara tertib. Ilustrasi sesi klien / server masuk

Gambar 18-13 di halaman 686. Sesi sesi WSP menyetujui umum

tingkat fungsionalitas protokol dengan menggunakan kemampuan negosiasi. WSP menukar konten antara klien dan server menggunakan pengkodean kompak, dan juga kontrol

interupsi komunikasi Komunikasi interupsi terjadi dengan perubahan a

pembawa, seperti SMS (lihat Gambar 18-3 di halaman 661).

WSP mendefinisikan dua protokol:

Layanan sesi mode koneksi melalui layanan transaksi

Mode ini digunakan untuk koneksi lama. Status sesi dipertahankan.

Ada keandalan untuk data yang dikirim melalui sesi mode koneksi.

Layanan yang tidak dikonfirmasi dan koneksi-kurang melalui layanan transportasi datagram

Layanan ini cocok bila aplikasi tidak membutuhkan penyampaian data yang andal

dan tidak peduli dengan konfirmasi. Ini bisa digunakan tanpa benar-benar memiliki

membentuk sebuah sesi

WSP menyediakan semantik dan mekanisme berbasis Hypertext Transport

Protokol (HTTP) 1.1 dan perangkat tambahan untuk jaringan nirkabel dan WAP-nya

terminal. Penyempurnaan seperti itu mencakup hal-hal seperti sesi berumur panjang dan

mendorong data, negosiasi kemampuan, dan kemampuan untuk menunda dan melanjutkan

sidang.

Fungsionalitas dasar

Header konten digunakan untuk mendefinisikan tipe konten, encoding karakter,

bahasa, dan sebagainya. Compact binary encoding didefinisikan untuk yang terkenal

header untuk mengurangi inefisiensi protokol. Format data yang kompak didukung

yang menyediakan header konten untuk setiap komponen dalam data komposit

obyek. Ini adalah bentuk biner semantik yang setara

MIME-multipart / multimixed format yang digunakan oleh HTTP 1.1.

Sebagai bagian dari proses pembentukan sesi, request dan response header

yang tetap konstan selama sesi berlangsung bisa ditukar antara

pengguna layanan di klien dan server. WSP melewati client dan server

header sesi, serta header permintaan dan respon, tanpa penambahan atau

kepindahan.

Siklus hidup sesi WSP tidak terkait dengan protokol transport yang mendasarinya. sebuah

protokol pembentukan kembali sesi telah didefinisikan yang memungkinkan sesi menjadi

ditangguhkan dan dilanjutkan tanpa biaya pemrosesan awal.

Ini memungkinkan sesi ditangguhkan saat menganggur untuk melepaskan sumber daya jaringan atau

menghemat daya baterai Sesi ini dapat dilanjutkan dengan pembawa yang berbeda

jaringan.

Komunikasi layer-to-layer

Komunikasi antara lapisan dan antar entitas dalam lapisan sesi

dilakukan melalui layanan primitif. Mereka mewakili pertukaran logis informasi dan kontrol antara lapisan sesi dan berdekatan

lapisan.

Layanan primitif terdiri dari perintah dan respon masing-masing

terkait dengan layanan yang diberikan dan parameter. Sebagai contoh:

X-service.type (parameter)

Dimana X menunjuk lapisan yang menyediakan layanan; untuk WSP, itu adalah S. Layanan

jenisnya sama dengan yang digunakan untuk WDP, diilustrasikan pada Tabel 18-1 di halaman 674.

Bila menggunakan layanan primitif, parameter tambahan mungkin dilakukan. Mereka

jelaskan jenis parameter tertentu. Sebagai contoh:

Alamat Mereka menggambarkan alamat klien dan server untuk ditetapkan

sesi.

Header dan body Mereka menggambarkan badan-entitas HTTP. Tajuknya

membedakan antara permintaan dan tanggapan yang dikirim dari

client ke server atau sebaliknya. Tubuh berisi

isi pesan

Kemampuan Berikut adalah fasilitas layanan, misalnya:

• Unit data transaksi terbesar

• Kumpulan nama halaman kode

• Maksimum permintaan yang beredar

Kemampuannya bisa dinegosiasikan antara klien dan

server Push identifier Menunjukkan bahwa pesan yang diterima adalah transaksi push

dari sesi yang sedang menunggu di antarmuka layanan.

Alasan Penyedia layanan menggunakan jenis alasan untuk melaporkan

penyebab keadaan primitif tertentu.

 Alasan yang sah

adalah:

1. PROTOERR Aturan protokol dicegah

rekan dari melakukan

operasi dalam keadaan saat ini. Untuk

Contoh, PDU bekas tidak

diizinkan.

2. DISCONNECT Sesi terputus

sedangkan operasi masih di

kemajuan.

3. SUSPEND Sesi ditunda sementara

operasi masih berlangsung

4. RESUME Sesi dilanjutkan kembali

operasi masih berlangsung

5. CONGESTION Implementasi peer tidak bisa

memproses permintaan karena kurang

sumber daya

6. CONNECTERR Terjadi kesalahan pada sesi

penciptaan.

7. MRUEXCEEDED Ukuran SDU dalam permintaan adalah

lebih besar dari jumlah maksimal yang diterima

unit dinegosiasikan dengan rekan sejawatnya.

8. MOREXCEEDED Batas atas yang dinegosiasikan di atas

jumlah sekaligus

metode yang luar biasa atau push

permintaan sudah terlampaui

9. PEERREQ Layanan peer meminta

operasi yang akan dibatalkan

10. NETERR Kesalahan jaringan yang mendasarinya

mencegah penyelesaian permintaan

11. USERREQ Tindakan pengguna layanan lokal

adalah penyebab dari indikasi.

Contoh primitif layanan

Perilaku primitif layanan diilustrasikan dengan menggunakan bagan urutan waktu

(Gambar 18-12).

Angka ini menggambarkan layanan sederhana yang tidak dikonfirmasi. Klien memanggil a

S-request primitif, yang menghasilkan sebuah S-indication primitif di server (WSP lapisan peer). Garis putus-putus mewakili perambatan melalui penyedia

selama periode waktu tertentu

Layanan dan operasi sesi

WSP dirancang untuk berfungsi di atas layanan transaksi, dan juga langsung di

Layanan datagram tanpa menggunakan layer WTP. Ini berarti WSP bisa

berkomunikasi dengan WDP (lihat 18.9.1, "Protokol Datagram Nirkabel (WDP)" pada

halaman 672) atau dengan WTP (lihat 18.9.4, "Protokol Transaksi Nirkabel (WTP)" di

halaman 679), tergantung pada arsitektur aplikasi. Gambar 18-13 menunjukkan

dua sesi dari klien WAP ke server WAP.

Satu aplikasi WAE (diwakili oleh garis putus-putus) menggunakan layanan dari

lapisan sesi (WSP), lapisan transport (WDP), dan lapisan jaringan di

Klien WAP saat mengirim pesan melalui jaringan nirkabel ke WAP

proxy Di proxy WAP, lapisan peer setara juga digunakan untuk mencapai

menerima WAE.

Aplikasi WAE lainnya (ditunjukkan oleh garis padat) menggunakan tambahan

layanan dari lapisan transaksi (WTP). Ini karena kelas tambahan

layanan diperlukan untuk transaksi tertentu (lihat 18.9.4, "Transaksi Nirkabel

Protokol (WTP) "pada halaman 679).

Modus koneksi WSP

Layanan sesi mode koneksi menyediakan dua fasilitas standar:

Fasilitas manajemen sesi

Fasilitas manajemen sesi memungkinkan klien untuk terhubung ke server berbasis

pada kesepakatan fasilitas dan pilihan untuk digunakan. Selama sesi

Pembentukan, klien juga dapat bertukar informasi atribut untuk

durasi sesi Meski pembentukan sesi hanya bisa dilakukan oleh

Klien, sesi bisa diakhiri oleh keduanya. Peer dipanggil jika satu sisi

mencoba menghentikan sesi Agen pengguna juga diberitahu.

Fasilitas pelaporan pengecualian

Fasilitas pelaporan pengecualian memungkinkan penyedia layanan memberi tahu pengguna

tentang acara selama sesi berlangsung.

Ada beberapa fasilitas lain yang dikendalikan melalui kemampuan negosiasi

selama pembentukan sesi Ini adalah:

Metode fasilitas pemanggilan

Metode fasilitas pemanggilan memungkinkan klien untuk meminta server untuk mengeksekusi

sebuah operasi dan mengembalikan hasilnya ke klien. Operasi ini bisa jadi

dibandingkan dengan metode HTTP seperti GET, PUT, dan sebagainya (lihat RFC

2616), atau operasi yang ditentukan pengguna yang sesuai dengan permintaan / jawaban yang sama atau

pola transaksi Pengguna layanan diberi tahu tentang penyelesaian

operasi apakah berhasil atau gagal

Fasilitas push

Fasilitas push memungkinkan server mengirimkan informasi yang tidak diminta ke klien.

Informasi yang dikirim tidak dikonfirmasi. Pengiriman mungkin tidak bisa diandalkan.

Fasilitas push dikonfirmasi

Fasilitas push yang dikonfirmasi adalah fungsi yang sama seperti yang dijelaskan sebelumnya

ayat. Namun, informasi yang tidak diminta ini menuntut sebuah pengakuan

dari client ke server

Fasilitas resume sesi

Fasilitas lanjutan sesi memungkinkan kedua rekan untuk menunda sesi. Itu

keadaan sesi saat ini dipertahankan. Komunikasi lebih lanjut melalui ini

sesi tidak memungkinkan sampai klien melanjutkan sesi. Fungsi ini bisa

juga digunakan untuk mengalihkan sesi ke pembawa alternatif.

Modus koneksi WSP: kemampuan bernegosiasi

Informasi yang berkaitan dengan pengoperasian session service provider ini

ditangani melalui kemampuan. Kemampuan negosiasi digunakan antar rekan sejawat

menyetujui tingkat layanan yang dapat diterima.Rekan yang memulai proses negosiasi adalah inisiator dan rekan lainnya

responden. Pemrakarsa hanya mengusulkan satu set kemampuan. Responden

menyetujui atau menolak proposal

Negosiasi adalah tentang kemampuan, seperti:

• Daftar alamat alternatif untuk layanan permintaan yang sama
• Kesepakatan ukuran ukuran terbesar dari data transaksi
• Halaman kode judul
• Permintaan metode maksimal yang luar biasa
• Permintaan push maksimal yang maksimal

Modus koneksi WSP: Operasi

Gambar 18-14 di halaman 689 menunjukkan contoh sesi yang berhasil

proses pendirian melalui klien dengan seruan tindakan berikutnya

di server Beberapa layanan primitif digunakan pada klien dan sisi server:

S-Connect

Digunakan untuk memulai pembentukan sesi dan memberitahukan keberhasilannya

eksekusi. Beberapa parameter disediakan, seperti alamat klien (sesi

originator), alamat server (target sesi), header client dan server

(parameter tingkat aplikasi untuk menunjukkan bahwa header permintaan dan tanggapan

dari kedua pasangan digunakan sepanjang sesi), dan diminta dan

kemampuan bernegosiasi selama durasi sesi (misalnya, daftar

alias-address, client mengirim data ukuran unit, server mengirim data ukuran unit,

Permintaan metode maksimal, dan dorongan maksimal yang beredar

permintaan).

S-MethodInvoke

Digunakan untuk meminta operasi yang akan dijalankan oleh server. Layanan ini

primitif hanya bisa digunakan bersama dengan S-MethodResult, yang mengembalikan

Hasil dari server ke klien setelah eksekusi. Pengikut

Parameter valid: ID transaksi klien dan server (untuk membedakan antara

beberapa transaksi yang tertunda selama sesi yang sama), metode (untuk mengetahui mana

operasi harus digunakan, baik metode HTTP seperti GET atau PUT, atau

salah satu metode penyuluhan yang ditetapkan selama negosiasi kemampuan),

meminta Uniform Resource Identifier (URI) (untuk menentukan entitas mana yang

operasi berlaku), meminta header (setara dengan header HTTP), dan

badan permintaan (berisi data yang terkait dengan permintaan).

S-MethodResult

Layanan primitif ini mengembalikan respons terhadap permintaan operasi. Bisa jadi

dipanggil hanya setelah S-MethodInvoke sebelumnya telah terjadi. Pengikut

Parameter yang bisa digunakan untuk layanan primitif ini: client dan server

ID transaksi (membedakan antara transaksi tertunda), status (memberitahukan,

melalui kode status HTTP yang setara, RFC 2616, keadaan

meminta operasi yang diminta oleh S-MethodInvoke melalui klien),

header respon (seperti yang dijelaskan di bawah S-MethodeInvoke, tubuh respons,

data yang terkait dengan respon atau, jika status menunjukkan error,

berisi informasi kesalahan terperinci lebih lanjut), dan header pemberitahuan

(bisa digunakan untuk mengembalikan beberapa informasi kembali ke server).

S-Disconnect

Digunakan untuk memutuskan sambungan sesi, atau memberitahukan pengguna bahwa sesi tidak dapat dilakukan

mapan. Sebelum menerbitkan ini, transaksi yang tidak lengkap harus dilakukan

dibatalkan

Urutan kejadian ini bisa dijelaskan sebagai berikut:

1. Lapisan sesi klien dimulai dengan permintaan S-Connect.req. Server

Lapisan sesi memberitahukan lapisan atasnya (lapisan aplikasi) melalui a

S-Connect.ind menunjukkan bahwa permintaan koneksi diterima.

2. Server menggunakan respons S-Connect.res primitif untuk dikenali

penerimaan indikasi primitif Lapisan sesi klien menggunakan

konfirmasikan primitif untuk melaporkan bahwa aktivitas (S-Connect.req) telah dilakukan

selesai dengan sukses

3. Selama proses inisiasi sesi, lapisan sesi klien dapat dimulai

segera dengan mengirimkan permintaan S-MethodInvoke.req meminta

eksekusi di mesin server Permintaan ini menunjukkan bahwa lapisan atas

harus menjalankan operasi di sisi server.

4. Server mengirimkan respons S-MethodInvoke.res kepada klien yang mengkonfirmasikannya

permintaan S-MethodInvoke.req sebelumnya telah selesai dengan sukses. Itu

Klien diinformasikan melalui S-Method.cnf.

5. Setelah server menjalankan operasi, ia mengirimkan hasilnya ke klien

melalui S-MethodResult.req. Klien menunjukkan lapisan atas (the

lapisan aplikasi) melalui S-Method.Result.ind penerimaan kembali

data.

6. Karena mitra sesi telah menegosiasikan konfirmasi semua permintaan

(***. req), klien mengkonfirmasikan permintaan S-MethodResult.req dengan sebuah

S-MethodResult.res. tanggapan.

7. Permintaan dan tanggapan lebih lanjut dapat menggunakan sesi ini.

8. Sesi aktif dapat diakhiri dengan contoh ini dengan mengeluarkan a

Permintaan S-Disconnect.req ke server melalui client. Server mengirimkan a

S-Diconnect.ind ke layanan sesi di lapisan sesi, yang selesai

sesi. 

Layanan sesi di sisi klien akan diinformasikan untuk mencatat

sesi melalui S-Diconnect.ind.

Karena lapisan sesi tidak memberikan sekuensing antara beberapa

Permintaan metode yang tumpang tindih, indikasi mungkin disampaikan secara berbeda

pesanan dari permintaan yang dikirim Hal yang sama berlaku juga untuk tanggapan dan

konfirmasi, serta untuk primitif S-MethodResult yang sesuai. Itu

aplikasi harus menangani sequencing.

Ada beberapa layanan primitif sesi lainnya yang tidak digunakan dalam sampel

dari mode koneksi WSP. Ini adalah:

S-Suspender Menangguhkan sesi.

S-Resume Melanjutkan sesi yang ditangguhkan.

Acara S-Exception Reports.

S-MethodAbort Membatalkan permintaan operasi yang belum lengkap.

S-Push Mengirim informasi yang tidak diminta dari server.

S-ConfirmedPush Mengirim informasi yang tidak diminta dari server; namun,

klien harus mengkonfirmasi informasi ini.

S-PushAbort Menolak operasi push untuk push yang dikonfirmasi

Modus koneksi WSP menggunakan Wireless Transaction Protocol

Bagian ini menjelaskan pengoperasian saat sesi WSP dijalankan

Layanan Wireless Transaction Protocol (WTP) (lihat 18.9.4, "Transaksi Nirkabel

Protokol (WTP) "pada halaman 679).

Keuntungan menggunakan transaksi WTP dalam sesi WSP sebanding dengan

TCP. WTP menyediakan transmisi yang andal, transmisi ulang yang ditentukan secara selektif

kehilangan paket, segmentasi, dan reassembly pesan besar dan dikendalikan

arus data antar pengirim dan penerima.

Keuntungan lainnya adalah penggunaan kelas transaksi WTP yang didefinisikan dalam "WTP

kelas operasi "pada halaman 679. Tabel 18-3 menunjukkan bagaimana WSP menggunakan ketiganya

kelas transaksi

Guna menunjukkan kerjasama antara layanan sesi dan transaksi

layanan, beberapa diagram ditambahkan. Ini adalah contoh dari transaksi yang berbeda

layanan yang digunakan oleh layanan sesi.

Pembentukan sesi normal

Gambar 18-15 menunjukkan proses pembentukan sesi normal.

Penghentian sesi normal

Gambar 18-16 menunjukkan proses penghentian sesi normal.

Sesi normal ditunda dan dilanjutkan

Gambar 18-17 menunjukkan proses suspend dan resume normal

Pemanggilan metode normal

Gambar 18-18 menunjukkan proses pemanggilan metode normal

WSP connection-less

Layanan sesi connection-less menyediakan fasilitas yang tidak dikonfirmasikan. Mereka bisa

digunakan untuk bertukar entitas konten antar lapisan. Seperti mode koneksi

layanan, layanan connection-less asimetris, yang berarti tidak ada sequencing

pesan.

Layanan ini digunakan terutama untuk fasilitas push.

Layanan primitif berikut didefinisikan:

S-Unit-MethodInvoke

S-Unit-MethodResult

S-Unit-Push

Pemrosesan acara

Sesi dibedakan dengan pengenal sesi unik, yang berlaku selama

durasi sesi. Setiap sesi dikaitkan dengan peer quadruplet

alamat. Quadruplet ini terdiri dari:

Alamat klien

Port klien

Alamat server

Port server

Transaksi masuk ditugaskan ke sesi tertentu berdasarkan peer

alamat quadruplet Skema pengalamatan sesi semacam ini memungkinkan satu sesi

untuk terikat ke alamat rekan empat kali dalam satu waktu.

Wireless Transaction Protocol (WTP)

Chapter 18.9.4 Protokol Transaksi Nirkabel (WTP)

Protokol Transaksi Nirkabel, yang didefinisikan dalam OMA WAP-224-WTP-20010710-spesifikasi, menyediakan mekanisme terutama dirancang untuk terminal WAP dengan sumber daya terbatas melalui jaringan dan dengan rendah ke bandwidth sedang. Teknologi ini memungkinkan lebih banyak pelanggan pada saat yang sama jaringan karena pemanfaatan bandwidth yang berkurang.

WTP menyediakan transfer data yang tidak dapat diandalkan dan dapat diandalkan berdasarkan permintaan / balasan paradigma Tidak seperti TCP, tidak ada pengaturan koneksi dan robek. Dibandingkan dengan

TCP, dimana aliran SYN dan ACK dimulai sebelum data pertama dikirim,

WTP membawa data pada paket pertama pertukaran protokol. Selain itu, WTP

menggunakan model berorientasi pesan, berlawanan dengan berorientasi pada TCP

pelaksanaan.

Kelas operasi WTP

Ada tiga kelas operasi, penomoran nol sampai dua.

Kelas 0

Kelas 0 didefinisikan oleh spesifikasi OMA sebagai "pesan pemanggilan yang belum dikonfirmasi

tanpa hasil pesan. "Ini adalah datagram yang bisa dikirim dalam konteks

sesi WSP yang ada (lihat 18.9.5, "Protokol Sesi Nirkabel" pada

halaman 682). Namun, ini tidak dimaksudkan sebagai metode utama pengiriman datagrams. Untuk fungsi itu, gunakan WDP sebagai gantinya. Urutan kejadian dalam a

Transaksi kelas 0 adalah sebagai berikut:

1. Pengganti mengirim pesan panggil ke responder. Setelah pesan

telah dikirim, peran penggagas dalam transaksi telah berakhir. Tidak

pengiriman ulang dikirim dari pesan

2. Responden menerima pesan panggilan. Tidak ada tanggapan yang dikirim

mengakui penerimaan pesan panggil. Setelah pesannya selesai

diterima, transaksi selesai.

Karena tidak ada retransmisi atau balasan, jenis transaksi ini

dianggap tanpa kewarganegaraan dan tidak bisa dibatalkan. Ilustrasi tambahan dari sebuah Kelas

0 transaksi dapat ditemukan pada Gambar 18-12 di halaman 685).

Kelas 1

Kelas 1 didefinisikan sebagai "pesan konfirmasi yang dikonfirmasi tanpa hasil pesan." Ini

digunakan untuk push data yang andal (lihat 18.6, "WAP push architecture" di halaman 664),

dimana tidak ada tanggapan dari tujuan yang diharapkan, meski transaksi itu

masih disebut layanan datagram yang andal. Urutan kejadian di Kelas 1

transaksi adalah sebagai berikut:

1. Pengganti mengirim pesan panggil ke responder.

2. Responden menerima pesan panggilan dan mengembalikan sebuah

pengakuan (tapi bukan pesan hasil). Jika penggagas tidak menerima

sebuah pengakuan, pesan pemanggilan dipancarkan ulang.

Transaksi tetap dalam keadaan aktif sampai pengakuan tiba di

inisiator Setelah menerima pengakuan tersebut, Inisiator mempertimbangkan

transaksi telah berakhir Transaksi Kelas 1 dapat dibatalkan pada suatu titik

selama berurutan acara.

Kelas 2

Kelas 2 didefinisikan sebagai "pesan konfirmasi yang dikonfirmasi dengan satu hasil yang dikonfirmasi

pesan. "Di kelas ini, satu permintaan tunggal menghasilkan satu jawaban tunggal. Ini

terdiri dari model interaksi request / response khas yang paling banyak digunakan

dengan aplikasi Urutan kejadian dalam transaksi Kelas 2 adalah sebagai berikut:

1. Pengganti mengirim pesan panggil ke responder.

2. Responden mungkin akan mengirimkan kembali sebuah pengakuan atas pesan ini. Ini

terjadi jika responden tidak bisa mengirim kembali pesan hasil

segera.

3. Responden mengirimkan kembali pesan hasil. Jika tidak ada pengakuan

Sebelumnya pernah dikirim ke inisiator, pesan hasil ini tersirat

mengakui penerimaan pesan panggil. Jika inisiator menerima no

pengakuan atau pesan hasil, pesan ulang pesan panggil ulang.

4. Pemrakarsa mengirimkan kembali pengakuan setelah menerima hasilnya

pesan.

Transaksi dianggap selesai bila responden menerima

pengakuan. Jika tidak ada pengakuan diterima, responden

mentransmisikan kembali pesan hasilnya Transaksi bisa dibatalkan setiap saat

selama berurutan acara. Ilustrasi tambahan dari transaksi Kelas 2

ada pada Gambar 18-15 di halaman 692.

Komunikasi layer-to-layer

Layanan primitif digunakan untuk mengendalikan lalu lintas transaksi antar lapisan

klien dan server Layanan primitif ini memiliki sintaks yang serupa seperti yang dijelaskan

untuk WSP:

X - nama generik tipe (parameter)

Dimana X menunjuk lapisan yang menyediakan layanan. Untuk lapisan transaksi, itu

adalah TR. Tipe primitif dan singkatannya sama seperti yang dijelaskan

WDP (lihat Tabel 18-1 di halaman 674).

Ada tiga primitif untuk layanan ke lapisan atas:

TR-Invoke Memulai sebuah transaksi baru.

TR-Result Mengirimkan kembali hasil dari transaksi yang dimulai sebelumnya.

TR-Abort membatalkan transaksi yang ada.

Contoh alur urutan WSP-WTP

Gambar 18-11 menggambarkan aliran urutan primitif dan menunjukkan hubungannya

antara WSP dan WTP permintaan dan tanggapan. Alirannya didasarkan pada Kelas 2

Transaksi yang, seperti yang didefinisikan sebelumnya, adalah pertukaran pesan yang andal dan dapat dikonfirmasi.

Langkah-langkah berikut menggambarkan aliran urutan primitif:

1. Urutan pertama dimulai melalui aplikasi klien (misalnya, a

penyelidikan untuk layanan), yang dimulai dengan operasi S-MethodInvoke.req ke

aplikasi server dalam satu sesi

2. Urutan kedua adalah respon dari server untuk mengkonfirmasi ke WSP di

Client stack yang memanggil pesan (inquiry) telah diterima oleh

server

3. Urutan ketiga mengembalikan permintaan hasil (membalas pertanyaan) dari

server ke client

4. Urutan keempat mengkonfirmasikan tanda terima ke server yang jawabannya

diterima dengan benar

Wireless Control Message Protocol (WCMP)

Chapter 18.9.3

Protokol Pesan Kontrol Nirkabel (WCMP) sangat menutup cermin

fungsionalitas Internet Control Message Protocol (ICMP) yang didefinisikan dalam RFC

792 dan 2463. Ditetapkan dalam spesifikasi OMA WAP-202-WCMP-20010624-spesifikasi,

Ini digunakan oleh WDP untuk memberikan kemampuan seperti ICMP saat menggunakan wireless

pembawa yang tidak mendukung IP. Secara khusus, WCMP digunakan untuk melaporkan masalah

terjadi saat memproses datagrams. Kesalahan yang dilaporkan oleh pesan WCMP bisa

dibagi menjadi enam jenis, beberapa di antaranya dapat dibagi lagi menjadi kode. Ini

tercantum dalam Tabel 18-2.

Struktur pesan WCMP

Struktur pesan pesan WCMP bervariasi berdasarkan jenis nirkabel

pembawa yang digunakan oleh originator atau pesan, begitu juga dengan jenis WCAMP

pesan. Namun, setiap WCMP mematuhi format umum, seperti yang didefinisikan di dalamnya

Gambar 18-10.

Wireless Profiled Transmission Control Protocol (WP-TCP)

Chapter 18.9.2 Protokol Kontrol Transmisi Terpilih Nirkabel (WP-TCP)

Salah satu spesifikasi yang baru diperkenalkan oleh lapisan transport WAP2

Arsitektur adalah Wireless Profiled TCP (WP-TCP) yang digunakan untuk menyediakan

layanan berorientasi koneksi Implementasi WP-TCP didefinisikan dalam

OMA WAP-225-TCP-20010331-spesifikasi. Manfaat direalisasikan dari yang baru ini

implementasi meliputi:

Transfer data yang besar

Keamanan end-to-end

Kepatuhan terhadap protokol IETF

Penggunaan WP-TCP bisa menggunakan satu dari dua pendekatan.

Pendekatan split-TCP

Pendekatan split-TCP sangat erat mencerminkan model WAP 1.x. Di dalam

pendekatan, proxy ada antara klien WAP dan server asal, dan dua

koneksi dibuat Koneksi pertama dibuat menggunakan WP-TCP,

dan ada antara klien WAP dan proxy WAP. Koneksi kedua,

didirikan di atas TCP, ada antara proxy WAP dan server asal. Ini

diilustrasikan pada Gambar 18-8.

Menggunakan pendekatan semacam itu memungkinkan server WAP dan server proxy WAP masuk

Keuntungan dari pengoptimalan yang ada di WP-TCP tapi tidak di TCP saja. Ini adalah

Terutama penting karena ada banyak aspek pada koneksi nirkabel

yang menciptakan lingkungan yang tidak sesuai untuk TCP (ini didefinisikan dalam "WP-TCP

pengoptimalan "di halaman 676).

Namun, optimasi WP-TCP dirancang khusus untuk memungkinkan

Protokol menjadi lebih efisien dalam lingkungan seperti itu. Dengan membelah koneksi,

WP-TCP mampu beroperasi di lingkungan nirkabel, dan TCP mampu

beroperasi di lingkungan kabel. Informasi lebih lanjut tentang yang spesifik

Optimalisasi ada pada "optimasi WP-TCP" di halaman 676.

Pendekatan end-to-end

WP-TCP sesuai dengan RFC 0793 dan 1122. Oleh karena itu, setiap WP-TCP

Implementasi juga bisa berkomunikasi dengan komunikasi TCP, meski

koneksi yang dihasilkan akan kekurangan optimasi yang dirancang pada WP-TCP. Dalam mengimplementasikan koneksi end-to-end, WP-TCP berperilaku seperti TCP lainnya

aplikasi, membangun koneksi langsung dengan server asal. Ini adalah

diilustrasikan pada Gambar 18-9.

Keputusan untuk menerapkan pendekatan end-to-end melalui pendekatan split-TCP

biasanya ditentukan oleh service, server, dan hardware provisioning atau

kebutuhan khusus dari lapisan aplikasi.

Optimasi WP-TCP

Seperti disebutkan sebelumnya, skenario tertentu ada pada jaringan nirkabel yang membuat a

Koneksi TCP murni kurang diminati. Skenario tersebut meliputi:

Sering kehilangan paket

Ukuran jendela yang lebih kecil

Lama hening atau kehilangan koneksi karena eksponen back-off

mekanisme transmisi ulang

Transmisi redundan

Periode pemutusan karena kurangnya cakupan

Profil TCP untuk WP-TCP berusaha mengoptimalkan protokol untuk mengimbanginya

untuk skenario ini Secara khusus, delapan optimasi disertakan dalam WP-TCP.

Ini adalah:

Ukuran jendela yang besar: Built in to TCP adalah penggunaan Produk Delay Bandwidth

(BDP), dihitung dari bandwidth yang tersedia dan waktu pulang-pergi

hitung ukuran jendela minimum. Ini juga menghitung jendela maksimum

ukuran menggunakan nilai terkecil dari send atau receive buffer. WP-TCP bisa memilih

untuk menggunakan ukuran jendela maksimal, mengandalkan kontrol kemacetan

Mekanisme dibangun ke dalam TCP untuk mengatur data sesuai kebutuhan. WP-TCP

spesifikasi menunjukkan bahwa implementasi dari optimasi ini adalah

direkomendasikan, tapi tidak diperlukan

Opsi skala jendela: Entitas yang memilih untuk menggunakan ukuran jendela besar adalah

diperlukan juga untuk mengimplementasikan opsi skala jendela yang ditentukan oleh RFC 1323. Jika

sebuah entitas tidak mendukung optimasi ukuran jendela besar, implementasi

dari optimasi skala jendela bersifat opsional.

Pengukuran waktu round-trip: Juga didefinisikan dalam RFC 1323, round-trip time

pengukuran (RTTM) direkomendasikan untuk digunakan oleh entitas yang menerapkannya

Ukuran jendela lebih besar dari 64 K. Ini juga membutuhkan penggunaan cap waktu pilihan. Jendela awal yang besar: Implementasi TCP standar mencakup initial jendela sampai dua segmen dalam ukuran Namun, WP-TCP menggunakan ekstensi didefinisikan dalam RFC 2414 yang memungkinkan WP-TCP untuk mengirim jendela awal dari tiga atau empat segmen Ini terbatas pada 4380 byte. Implementasi ini

optimasi adalah opsional Jalur penemuan MTU: WP-TCP sekarang mendukung prosedur, yang didefinisikan dalam RFC 1191 dan 1981, digunakan untuk menemukan unit transmisi maksimum (MTU) dari

jalan yang diberikan Hal ini memungkinkan WP-TCP untuk mengoptimalkan jumlah data yang dikirim masuk

setiap paket untuk menghindari fragmentasi atau menjatuhkan paket. Implementasi dari

Optimalisasi ini direkomendasikan, namun tidak diperlukan.

MTU lebih besar dari MTU IP default: Jika sebuah entitas tidak dapat mendukung jalur MTU

temukan (misalnya, jika beberapa router di jalan tidak mendukungnya

dibutuhkan pesan ICMP), implementasi WP-TCP dapat mengasumsikan sebuah nilai

melebihi nilai default IPv4 atau IPv6. Namun, nilai yang diasumsikan harus

tidak melebihi 1500 byte, dan harus mencerminkan ukuran segmen maksimum

dinegosiasikan saat membuat koneksi TCP.

Pengakuan selektif: Algoritma pemulihan cepat, yang didefinisikan dalam RFC

2581, cenderung kurang efisien saat mencoba pulih dari banyak

kerugian dalam satu jendela Skenario ini sangat mungkin terjadi pada wireless

koneksi, dan karena itu, alternatif untuk algoritma fast recover itu

diimplementasikan Pengakuan selektif (SACK) didefinisikan dalam RFC 2018

dan memungkinkan WPT-TCP untuk mengirim ucapan terima kasih selektif, menunjukkan apa

data perlu dipancarkan ulang. Implementasi optimasi ini adalah

wajib.

Pemberitahuan kemacetan eksplisit (ECN): Ditetapkan di RFC 2481, ECN mengizinkan Penerima WP-TCP memberi tahu pengirim data kemacetan di jaringan. Hal ini memungkinkan pengirim untuk mengurangi kemacetan jendela. Implementasi optimasi ini bersifat opsional.

Protokol Nirkabel dan Wireless Datagram Protocol

Chapter 18.9 - 18.9.1

Protokol nirkabel

Protokol aplikasi nirkabel terdiri dari banyak subprotocol, masing-masing

menyediakan fungsionalitas yang berbeda untuk aplikasi nirkabel. Bagian ini menjelaskan

protokol ini dan skenario yang sesuai.

Wireless Datagram Protocol

WDP memberikan layanan yang konsisten ke lapisan atas (keamanan, transaksi, dan

sesi) arsitektur WAP. Hal ini didefinisikan dalam OMA

WAP-259-WDP-20010614-spesifikasi, dan memungkinkan aplikasi beroperasi

transparan atas berbagai layanan pembawa yang tersedia. Ini berkomunikasi

secara transparan atas berbagai layanan pembawa yang didukung oleh beberapa jaringan

jenis. WDP adalah layanan datagram connection-less dan tidak dapat diandalkan. Ini mendukung port

nomor pengalamatan Nomor port menunjuk ke tingkat lapisan WDP yang lebih tinggi.

Ini bisa berupa WTP, WTLS, WSP, atau aplikasi.

Untuk mendukung berbagai layanan pembawa dengan kemampuan spesifik dan

karakteristik, adaptasi diperlukan untuk menjaga agar WDP sebagai lapisan umum berbagai layanan pembawa. Oleh karena itu, WDP, dengan jenis lapisan adaptasi,

bekerja sama dengan lapisan pembawa yang mendasarinya. Gambar 18-7 di halaman 673 menunjukkan

struktur WDP umum

Pesan WDP dikirim oleh terminal WAP ke gateway data nirkabel

menggunakan layanan pembawa. Gateway data nirkabel memiliki pilihan untuk dilewati

Paket WDP ke server / proxy WAP melalui protokol tunneling, yaitu Antar muka antara gateway yang menyediakan layanan bearer dan WAP

server proxy. Misalnya, jika layanan pembawa adalah SMS GSM, gateway akan menjadi SMSC GSM dan akan mendukung protokol tunneling tertentu

antarmuka SMSC ke server lain. Hal ini juga memungkinkan untuk menggunakan subnetwork sebagai a

teknologi umum untuk menghubungkan dua perangkat komunikasi. Ini Koneksi bisa jadi, misalnya melalui jaringan area luas berbasis TCP / IP atau frame relay, atau LAN yang mengoperasikan TCP / IP over Ethernet. Proxy WAP / server mungkin menawarkan konten aplikasi atau mungkin beroperasi sebagai gateway antara nirkabel

Protokol WTP dan Internet kabel

Bila digunakan di atas lapisan jaringan IP, UDP digunakan sebagai pengganti WDP

WDP service primitives

Layanan primitif digunakan untuk mengendalikan lalu lintas transaksi antar lapisan

klien dan server Layanan primitif ini memiliki sintaks yang serupa dengan itu

dijelaskan untuk WSP:

X - nama generik tipe (parameter)

Dimana X menunjuk lapisan yang menyediakan layanan. Untuk lapisan WDP, itu adalah T. Tipe primitif dan singkatannya tercantum dalam Tabel 18-1.

Ada dua primitif untuk lapisan layanan:

T-D Unitdata Mengirim data sebagai datagram. WDP T-DError juga bisa menerima primitif T-DError jika diminta transmisi tidak dapat dijalankan oleh lapisan protokol WDP.

Memetakan WDP untuk IP

User Datagram Protocol (UDP), sebagai layanan datagram connection-less, digunakan

sebagai protokol WDP untuk jaringan pembawa nirkabel mana IP digunakan sebagai a

protokol routing UDP menyediakan pengalamatan berbasis port (tujuan dan sumber

Pelabuhan). IP menyediakan segmentasi dan reassembly

Profil User Agent

18.8 User Agent Profile (UAProf)

Salah satu aspek yang melekat pada jaringan nirkabel adalah adanya

perangkat keras mobile heterogen, terdiri dari berbagai kemampuan yang berbeda.

Oleh karena itu, server asal mungkin mengantarkan konten ke seluler

klien yang berada di luar kemampuan klien untuk ditampilkan. Untuk mencegah hal tersebut

Kejadian, User Agent Profile (UAProf) dibuat dan didefinisikan di OMA

WAP-248-UAProf-20011020-spesifikasi.

UAProf memungkinkan klien mengirim data mengenai kemampuan klien ke sebuah

server asal, sehingga menunjukkan jenis konten yang bisa dan tidak dapat server

Kirim. Informasi yang terkandung dalam UAProf meliputi:

• Data khusus perangkat keras, seperti produsen perangkat, perangkat keras
• versi, kemampuan gambar, dan sebagainya
• Data spesifik perangkat lunak, seperti sistem operasi, jenis encoders,
• aplikasi hadir, dan sebagainya
• Data spesifik browser, seperti bahasa mark-up dan scripting yang ada
• didukung
• Data spesifik jaringan, seperti statistik kinerja kapabilitas perangkat
• Data spesifik WAP, seperti kemampuan WML dan versi WAP

Selain itu, server asal atau server proxy dapat menyimpan informasi ini

mempercepat permintaan klien

Lingkungan Aplikasi Nirkabel (WAE2)

18.7 The Wireless Application Environment (WAE2)

The Wireless Application Environment (WAE2), yang didefinisikan oleh OMA

wap-236-waespec-20020207-spesifikasi, menyediakan lingkungan di mana

programmer dan pengembang bisa membuat aplikasi untuk penggunaan wireless

perangkat. Secara khusus, WAE2 dimaksudkan untuk memberikan akses yang optimal ke sumber daya dan aplikasi, sambil tetap berada dalam batasan CPU yang terbatas, baterai

hidup, dan bandwidth. Ini kompatibel dengan WAE asli (dari WAP versi 1). Gambar 18-6 mengilustrasikan di mana WAE2 sesuai dengan arsitektur WAP.

WAE2 mendefinisikan satu set format konten untuk pertukaran data yang dapat dioperasikan. Jalan

data dipertukarkan tergantung data dan agen pengguna WAE2 yang ditargetkan. Itu

Dua format utama adalah WML yang dikodekan dan format kode byte WMLScript.

Format ini terutama dirancang untuk terminal WAP untuk meminimalkan komputasi

daya dan penggunaan bandwidth yang lebih rendah. Ada, selain itu, format untuk data

jenis seperti:

• Gambar

Ini mendukung banyak pilihan kedalaman pixel, tabel ruang warna, pengkodean kecil,

Sangat rendah CPU dan RAM encoding dan permintaan presentasi, ketersediaan

alat umum, dan sebagainya.

• Pesan multipart

Ini mendukung skema pengkodean multipart yang dioptimalkan untuk pertukaran beberapa

mengetik konten melalui WSP (lihat 18.9.5, "Protokol Sesi Nirkabel" pada

halaman 682).

• Format khusus agen pengguna

Ini adalah fungsi yang mendukung dua format tambahan untuk pertukaran data

antara agen pengguna: electronic business card (vCard 2.1), dan elektronik

kalender dan format pertukaran penjadwalan (vCalender 1.0) yang ditentukan oleh

IMC.

WAE juga mendefinisikan format spesifik WTA untuk mendukung telepon nirkabel

aplikasi.

Keamanan

18.6.7 Security

Di lingkungan yang terpercaya, beberapa pertanyaan bisa muncul, misalnya:

• Bagaimana pemicu pendorong bisa diautentikasi?
• Peran apa yang dimainkan PPG dalam model keamanan dan terpercaya?
• Apa kebijakan kontrol akses untuk pemicu dorongan dan mendorong konten?
• Bagaimana klien bisa mengautentikasi sesuatu jika tidak memiliki sertifikat?

Mengautentikasi Inisiator Dorongan

Beberapa solusi berikut dapat digunakan untuk mengimplementasikan lingkungan keamanan

antara pemicu push dan PPG:

• Penggunaan sertifikat tingkat sesi (TSL dan SSL)

Jika konten push melintasi Internet antara pemicu push dan PPG,

TSL atau SSL dapat digunakan.

• Penggunaan sertifikat tingkat objek

Sertifikat dapat digunakan untuk menandatangani dan mengenkripsi konten yang ditekan pada sebuah

end-to-end. Hal ini memperkuat tingkat kepercayaan pada konten

keaslian di akhir klien

• Otentikasi HTTP

Otentikasi dasar melalui ID pengguna dan kata sandi tersedia. Di

Selain itu, otentikasi HTTP, misalnya, berdasarkan digest, bisa jadi

diimplementasikan

• Kombinasi teknologi

Pendekatan lain adalah menggabungkan teknologi dengan menggunakan sesi TLS / SSL

dengan PPG, sedangkan otentikasi HTTP dapat digunakan untuk mengotentikasi push

pemrakarsa. Konten yang bertanda tangan dan terenkripsi kemudian dapat dikirim melalui ini

sesi terotentikasi

Otentikasi klien

Jika klien dan PPG mampu menciptakan lingkungan yang terpercaya, PPG bisa

Mengotentikasi inisiator dorongan atas nama klien itu, yaitu kepercayaan dapat bersifat transitif.

Situasi kepercayaan dapat terbentuk antara klien dan PPG dengan mempertahankan daftar

PPG yang terpercaya dalam sistem klien. Penggerak push memiliki sertifikat atau kunci publik

untuk otentikasi end-to-end dari server asal

Insfratuktur Sisi Client

18.6.6 Client-side infrastructure

Dorongan berorientasi koneksi memerlukan sesi WSP yang aktif. Seperti dijelaskan di

18.6.5, "Protokol push over-the-air (OTA)" di halaman 668, kebutuhan klien a

aplikasi inisiasi sesi khusus (SIA) untuk menyiapkan sesi push

dengan PPG. Setelah menerima permintaan sesi dari PPG, SIA menetapkan a

sesi dengan PPG dan laporan yang aplikasi klien menerima konten selesai

sesi yang baru dibuka SIA juga bisa mengabaikan permintaan sesi dari

PPG jika tidak ada aplikasi yang sesuai tersedia atau terpasang.

Saat klien menerima konten yang didorong, petugas operator melihat dorongannya

header pesan untuk menentukan aplikasi tujuannya. Petugas operator ini

bertanggung jawab untuk menolak konten jika aplikasi tujuan tidak diinstal. ini

juga bertanggung jawab untuk mengkonfirmasikan operasi ke PPG.

Protokol Push Over-The-Air (OTA)

Chapter 18.6.5 Push over-the-air protocol (OTA)

OTA bertanggung jawab untuk mentransmisikan konten dari PPG ke pengguna klien
agen melalui jaringan nirkabel

OTA dapat menggunakan sesi WSP untuk mengirimkan konten. Namun, sesi WSP
bekerja dalam mode connection-oriented dan harus ditetapkan oleh klien sebelumnya
untuk pengiriman konten yang ditekan Dalam hal ini, dimana tidak ada WSP aktif
sesi, aplikasi inisiasi sesi di klien harus membentuk sesi.
Ini fungsi baru di klien bekerja seperti server yang mendengarkan permintaan sesi
dari server OTA dan merespons dengan menyiapkan sesi WSP untuk push
tujuan.

Klien dapat memverifikasi informasi identitas server OTA terhadap daftar
server seperti itu sebelum mencoba sesi push apapun.

Indikasi layanan

Chapter 18.6.4 Indikasi layanan

Jenis konten indikasi layanan (SI) memungkinkan pengiriman notifikasi
pengguna dengan cara asinkron (misalnya, e-mail baru). SI berisi a
pesan singkat dan Uniform Resource Identifier (URI), menunjukkan layanan.
Pesan tersebut disampaikan kepada pengguna pada bagian penerima tamu. Pengguna sekarang dapat memilih untuk
baik memulai layanan dengan segera atau menunda untuk eksekusi selanjutnya. Jika SI itu
Ditunda, klien menyimpannya untuk memungkinkan pengguna menangani SI nanti.

Protokol Control Akses PUSH (PAP)

Chapter 18.6.3 Push access control protocol (PAP)

Pemicu push menggunakan PAP untuk mendorong konten melalui PPG ke domain WAP.

PAP dibawa melalui terowongan HTTP 1.1. PAP membawa entitas bergaya XML.

Operasi PAP

PAP mendukung operasi berikut:

• Penyerahan push (inisiator ke PPG)

Pesan push berisi entitas kontrol, yang menyediakan pengiriman

instruksi untuk PPG, entitas konten, yang merupakan konten tekstual untuk

Terminal WAP, dan, opsional, entitas kemampuan.

Bergantung pada jenis pesan (WML atau WMLScript), PPP mengubah ini

pesan ke bentuk yang dioptimalkan bandwidth lebih banyak sebelum diteruskan

over-the-air (OTA). Selain itu, enkripsi bisa digunakan saat mengirim pesan

ke klien

• Pemberitahuan hasil (PPG ke inisiator)

Jika pemrakarsa push meminta konfirmasi pengiriman yang berhasil,

pesan notifikasi dikembalikan ke pemicu inisiator. Ini memberi dorongan

inisiator kesadaran bahwa klien WAP juga telah mengakui

pengiriman berhasil ke PPG.

• Pembatalan push (inisiator ke PPG)

Entitas XML ini dikirim dari pemicu push ke PPG, meminta agar

konten yang dikirim sebelumnya dibatalkan PPG merespon jika

pembatalan itu berhasil atau tidak.

• Permintaan status (inisiator ke PPG)

Inisiator pemicu meminta status pengiriman selama proses 2 arah

klien WAP:

- Cara pertama: Dorong inisiator → PPG

- Cara kedua: PPG → klien

• Permintaan kemampuan klien (inisiator ke PPG)

Permintaan pemicu push, dari PPG, informasi tentang kemampuannya

dari terminal WAP tertentu. PPG merespon dengan multipart / terkait

pesan dalam dua bagian:

-Bagian pertama adalah tentang pelaksanaan pesan itu sendiri.

- Pada bagian kedua, kemampuan dari terminal WAP didefinisikan oleh yang dilaporkan Kelompok Profil User Agent.

Push Proxy Gateway Pada Wireless Application Protocol

Chapter 18.6.2 

PPG adalah jalur akses untuk konten yang didorong dari Internet ke ponsel

jaringan. Ia melakukan segala sesuatu yang diperlukan untuk operasi semacam ini, seperti:

• Otentikasi
• Keamanan
• Kontrol klien

Sebagai pemilik gateway, ia memutuskan siapa yang bisa mengakses domain WAP dan

siapa yang diizinkan untuk mendorong pesan

Ikhtisar layanan PPG

Layanan gateway push proxy meliputi:

• Otentikasi identifikasi inisiator push, kontrol akses
• Parsing dan deteksi kesalahan dalam informasi kontrol konten
• Layanan penemuan klien
• Resolusi alamat
• Penyandian biner dan kompilasi jenis konten tertentu untuk meningkatkan OTA
• Konversi protokol

Akses dari sisi internet

PPG menerima konten dari sisi internet, yang terbagi menjadi beberapa bagian

menggunakan jenis konten multipart / terkait. Bagian pertama berisi informasi untuk

PPG, misalnya:

• Informasi penerima
• Waktu habis
• Permintaan panggilan balik
• PPG mengakui penguraian informasi kontrol ini. Jika push
• permintaan inisiator, ia juga dapat memanggil kembali server yang mendorong saat status terakhir
• penyerahan push ke klien WAP telah tercapai, dan akan melaporkannya
• status (terkirim, dibatalkan, atau kadaluarsa).
• 
  

PPG mendorong pengiriman konten

PPG mencoba menemukan klien WAP yang benar dan, jika berhasil, mengirimkan konten

menggunakan protokol push over-the-air. Sidang untuk menyampaikan dibatasi oleh timeout

ditentukan untuk klien Batas waktu ini dapat diatur oleh pemicu atau kebijakan

dari operator seluler

Framework PUSH Pada WAP

Chapter 18.6.1- Push Framework

Dalam TCP / IP, permintaan informasi ke server dapat dimulai dari klien

hanya. Namun, penyedia layanan informasi juga membutuhkan cara untuk menghubungi klien

tanpa permintaan klien yang luar biasa. Misalnya, penyedia layanan surat kabar menginginkannya

untuk memberi tahu klien WAP bahwa e-mail ada di kotak surat klien, dan juga menginginkannya

memberikan semua nama pengirim, atau untuk memberikan harga saham terbaru, headline

berita, dan kondisi cuaca dan lalu lintas dimana klien WAP berlangganan.

Jenis transaksi ini, dimana server merupakan inisiator dari koneksi dengan a

Klien WAP, adalah fitur baru. Ini dirancang dengan nama push initiator, as

diilustrasikan pada Gambar 18-5.

Karena klien WAP berada di domain WAP dan server berada di

Internet, keduanya tidak berbagi protokol push initiator. Karena itu, sekali lagi, gateway

Dukungan diperlukan untuk menyediakan fungsi ini. Pintu gerbang yang melakukan dorongan

disebut push proxy gateway (PPG).

Jika penggagas push ingin mengirimkan informasi ke klien WAP, kontak tersebut akan menghubungi

push proxy gateway (PPG). Menggunakan protokol internet tradisional bersama dengan

push access protocol (PAP). PPG meneruskan konten push ke WAP

domain, di mana ia ditransmisikan melalui udara dengan menggunakan protokol push over-the-air

(OTA).

PPG mungkin memiliki kemampuan untuk memberi tahu pemrakarsa pemicu tentang keadaan

pengiriman pesan ke klien Tapi ini bisa memakan waktu lama, karena

Klien WAP mungkin tidak online. Jika klien online, ia dapat menerima atau menolak

mendorong konten

PAP menggunakan pesan XML, yang dapat terowongan melalui HTTP melalui

Internet.

Arsitektur WAP Push

Chapter 18.6 - WAP Push Architecture

Desain model client / server hanya memungkinkan klien untuk mengajukan permintaan

sebuah layanan dari server. Server merespon dengan mentransmisikan informasi ke

klien. Jenis pertukaran informasi ini disebut teknologi tarik, karena

klien menarik informasi dari server.

Metode WWW adalah contoh tipikal teknologi tarik. Klien masuk

URL untuk mengambil informasi dari server Web. Server Web mengirimkan

informasi ke klien untuk menampilkan halaman Web pada browser Web.

Setelah teknologi Web tradisional, penyedia layanan nirkabel tidak dapat mengirim

pesan ke klien tanpa permintaan yang dibuat Untuk membuat ini

mungkin layanan, arsitektur push dirancang.

Sebaliknya, arsitektur WAP mendefinisikan, sebagai tambahan, teknologi push. Kedua

ditunjukkan Gambar 18-4. Teknologi ini juga didasarkan pada model client / server,

namun tidak ada permintaan eksplisit dari client ke server. Transaksi push

diprakarsai oleh server saja. Ini digunakan untuk mengirimkan informasi ke WAP

terminal tanpa tindakan pengguna sebelumnya.

Sistem Messaging Multimedia

Chapter 18.5 System Messaging Multimedia

Sistem pesan multimedia (MMS) mendefinisikan protokol tingkat aplikasi

aktivitas yang dilakukan untuk mewujudkan layanan MMS dalam lingkungan WAP

untuk menyediakan operasi olahpesan, yang memungkinkan berbagai jenis konten dan media

jenis yang akan dibagikan di jaringan.

MMS ini dimaksudkan untuk memberikan dukungan bagi pengguna untuk berbagi media baru

Kemampuan hadir di perangkat mobile, seperti memotret atau merekam video.

Sistem pesan multimedia dipandang sebagai pengiriman asinkron

sistem. Ini sama seperti pada sistem pengiriman e-mail dan beberapa Internet lainnya

aplikasi. Jenis sistem pengiriman ini memungkinkan penggunaan jaringan secara optimal

kemampuan, baik untuk client maupun server jaringan.

Karakteristik khusus MMS adalah kemampuan untuk mendukung aktivitas messaging dengan

sistem pesan lain yang tersedia di Internet.

Untuk informasi lebih lanjut tentang MMS, lihat OMA

Spesifikasi WAP-205-MMSArchOverview-20010425.

]

Client Identifier Pada Wireless Application Protocol

Chapter 18.4 Client Identifiers

Pengenal klien (ID klien) mengidentifikasi perangkat selular di jaringan. Klien

ID dapat diberikan oleh komponen server proxy atau bisa dibentuk dengan menggunakan

sintaks yang didefinisikan dalam spesifikasi ID klien.

Spesifikasi ID Klien didefinisikan dalam OMA WAP-196-ClientID-20010409-a

dokumen spesifikasi Spesifikasi ini tidak mengecualikan yang lainnya

alternatif identifikasi

Format sintaksis ID klien didefinisikan dengan menggunakan Augmented Backus-Naur

Bentuk.

Arsitektur pada Wireless Application Protocol

Chapter 18.3.WAP Architecture

Model pemrograman ini adalah model pemrograman Web dengan beberapa ekstensi
dan penyempurnaan yang sesuai dengan karakteristik klien nirkabel. Ini
Model pemrograman menambahkan dua perangkat tambahan ke model pemrograman Web:

•   Dorong
•   Dukungan Wireless Telephony (WTA)

Pemrogram akan melihatnya sebagai keuntungan karena mereka akan bertemu dengan yang terkenal
antarmuka berdasarkan teknologi client / server.

Feature and performance-enhancing proxies

Berbagai fungsi kemudian disediakan oleh proxy WAP, termasuk:

Protocol gateway

Menerjemahkan permintaan dari tumpukan protokol nirkabel (untuk

Misalnya, WAP 1.x stack-WSP, WTP, WTLS, dan

WDP) ke protokol WWW (HTTP dan TCP / IP). Juga

dapat melakukan pencarian DNS untuk URL yang diminta oleh

klien.

Content encoders and decoders

Menerjemahkan konten WAP untuk pemanfaatan yang lebih baik dari

link yang mendasarinya, mengurangi penggunaan bandwidth dengan cara yang berbeda

teknik kompresi

User Agent Profile Manager

Digunakan terutama untuk mengkomunikasikan perangkat klien kemampuan dan preferensi pribadi ke server aplikasi.

Caching proxy

Caching sering diakses sumber daya, caching proxy dapat meningkatkan pemanfaatan jaringan.

Element pada Jaringan WAP

Klien WAP dapat berkomunikasi dengan server aplikasi secara langsung atau melalui

proxy. Klien WAP mendukung mekanisme seleksi proxy yang memungkinkannya

gunakan proxy yang paling tepat untuk layanan tertentu atau untuk terhubung langsung dengan itu

pelayanan seperlunya

Untuk mengoptimalkan komunikasi antar perangkat dan server aplikasi, proxy

dapat ditemukan untuk memberikan peningkatan fitur yang digabungkan ke wireless

jaringan (misalnya, teleponi, lokasi dan provisi) atau proxy bisa jadi

terletak di jaringan aman untuk menyediakan saluran aman antara perangkat nirkabel

dan jaringan aman.

Komponen Pada Arsitektur WAP

Di sini, kami memberikan penjelasan singkat tentang tumpukan protokol:

Bearer networks

Jaringan pembawa (Bearer networks) yang berbeda diizinkan. Sebagai transportasi lapisan bertindak sebagai antarmuka antara layanan pembawa dan lapisan atas tumpukan WAP, lapisan transport Spesifikasi mendefinisikan pembawa yang didukung dan fungsinya diterapkan untuk mengakses masing-masing pembawa.

Transport services

Layanan ini bertugas mengangkut barang tak terstruktur

data di jaringan pembawa yang mendasarinya, menciptakan sebuah

implementasi abstrak yang konsisten di seluruh

pembawa yang didukung Layanan transportasi meliputi

datagram dan layanan koneksi antara lain.

Transfer services

Layanan ini memberikan implementasi untuk

terstruktur transfer data informasi antar jaringan

elemen. Layanan yang paling populer termasuk adalah hypermedia

transfer (seperti HTTP, Wireless Session Protocol, dan

Wireless Transaction Protocol), streaming data (seperti

audio dan video), dan transfer pesan (seperti

Enkapsulasi Layanan Pesan Multimedia).

Session services 

Layanan ini menetapkan keadaan bersama di antara jaringan

elemen. Misalnya, layanan meliputi kemampuan

negosiasi, push over udara, layanan sinkronisasi, dan cookies.

Application framework

Menyediakan aplikasi tujuan umum

lingkungan berbasis kombinasi World Wide Web

(WWW), Internet, dan teknologi mobile. Yang utama

Tujuan dari kerangka aplikasi adalah untuk membangun sebuah

lingkungan interoperabel yang akan memungkinkan penyedia layanan

untuk membangun aplikasi dan layanan yang akan didukung oleh

berbagai macam platform yang berbeda secara efisien.

Kerangka aplikasi meliputi, antara lain, push,

pesan multimedia, dan format konten.

Security services

Ini adalah bagian mendasar dari arsitektur WAP dan itu

hadir di banyak lapisannya. Layanannya biasa

yang ditawarkan di lapisan ini adalah otentikasi, privasi, integritas,

dan non-penolakan.

Service discovery

Ini adalah bagian mendasar dari arsitektur WAP dan

ini juga bisa ditemukan di banyak lapisan. Beberapa contoh

Ini adalah antarmuka fungsi eksternal (EFI)

penyediaan, penemuan navigasi, dan pencarian layanan.

Other services and applications

Arsitektur WAP memungkinkan satu set layanan atau aplikasi diimplementasikan melalui serangkaian antarmuka yang didefinisikan dengan baik. Misalnya, aplikasi seperti e-mail, kalender, perdagangan elektronik, atau layanan seperti halaman kuning atau peta dan arahan sedang dikembangkan untuk menggunakan protokol WAP.