Proses roaming MMS

Agar ketika roaming seorang pengguna dapat melakukan pengiriman MMS atau menerima MMS maka diperlukan dua syarat penting yaitu adanya kesepakatan (agreement) antara kedua operator untuk SMS roaming atau circuit switched (CS) roaming serta GPRS roaming atau packet switched (PS) roaming. Kedua hal tersebut diperlukan karena transaksi MMS melibatkan WAP push lewat bearer SMS dan koneksi TCP/IP.

Proses pererimaan MMS pada seseorang yang menggunakan jaringan operator lain (roamer) adalah sebagai berikut:

Misalkan pelanggan A dan B adalah pelanggan operator yang sama yaitu operator X.

1. Pelanggan A mengirimkan MMS ke pelanggan B yang melakukan roaming di negara lain di operator Y.
   MMS akan dikirimkan ke MMSC operator X.
2. MMSC ngirimkan MMS indicator berupa SMS ke SMSC operator X.
   SMSC operator X akan mengirimkan MMS indicator ke Gateway MSC menggunakan protokol MAP (SS7).
3. GMSC akan mengirimakan MMS indicator ke MSC operator Y juga menggunakan MAP.
4. MSC operator Y akan mengirimkan MMS indicator SMS ke pelanggan B.
   Pelanggan B menerima MMS indicator.
5. Jika ponsel B diset untuk menerima MMS secara otomatis walaupun ketika roaming, maka ponsel B akan melakukan koneksi GPRS.
6. Koneksi GPRS dimulai dengan terjadinya koneksi dari ponsel ke Visiting SGSN (SGSN operator Y) dengan menggunakan access point operator X, sehingga session (active PDP context) dari user dibuat di VSGSN.
7. VSGSN (visiting SGSN) melakukan koneksi ke Home GGSN (GGSN operator X) lewat koneksi internet (VPN/leased line) atau melalui jaringan prvider GRX (GPRS Roaming Exchange).
   Request WSP/HTTP untuk pengambilan MMS di MMSC operator X dikirimkan dari ponsel melalui VSGSN dan HGGSN.
8. HGGSN meneruskan request tersebut ke MMSC operator X.
   MMSC memberikan response berupa MMS ke ponsel pelanggan B
   

                         VPLMN   :   HPLMN                                      
                                 :                                              
                                 :                                              
      B<---5---- MSC <-----------4--------- GMSC <---3----- SMSC                        ^                          :                            ^                          |                          :                            |                          |                          :                            2                          |                          :                            |                          |                          :                            |                          '----6---> SGSN <---7--(internet)----> GGSN <---8---> MMSC <----1---- A                                       :                                                                                  :                                                                                  :                                              

Proses pengiriman MMS dari seseorang yang menggunakan jaringan operator lain (roamer) hanpir sama dengan proses diatas, yaitu:

1. Pelanggan A (roamer) mengirimkan MMS dari ponselnya ke pelanggan B.
   Koneksi GPRS dimulai dengan terjadinya koneksi dari ponsel ke Visiting SGSN (SGSN operator Y) dengan menggunakan access point operator X, sehingga session (active PDP context) dari user dibuat di VSGSN.
2. VSGSN (visiting SGSN) melakukan koneksi ke Home GGSN (GGSN operator X) lewat koneksi internet (VPN/leased line) atau melalui jaringan prvider GRX (GPRS Roaming Exchange).
3. Request WSP/HTTP untuk pengambilan MMS di MMSC operator X dikirimkan dari ponsel melalui VSGSN dan HGGSN.
   HGGSN meneruskan request tersebut ke MMSC operator X.
   MMSC memberikan response yang menandakan bahwa MMS telah diterima oleh MMSC.
4. MMSC ngirimkan MMS indicator berupa SMS ke SMSC
   

                        VPLMN   :   HPLMN                             
                                :                         SMSC ----5-----,
                                :                           ^            |
    B                           :                           |            |
    |                           :                           4            |
    |                           :                           |            v
    '----1----> SGSN ----2--(internet)----> GGSN ----3---> MMSC ---6---> A
                                :                                     
                                :                                     
                                :                                     

Sebagai referensi, GSM Assosiation (GSMA) mempublikasikan dokumen teknis mengenai MMS roaming dan interworking yaitu IR.52 "MMS Interworking Guidelines" dan IR.33 "GPRS roaming Guidelines"

Detail proses GPRS roaming akan saya tulis lain kali.

MMSC (Multimedia Messaging Service Center)

MMS dan fungsionalitas MMSC dispesifikasikan oleh 3GPP dan OMA. Definisi dan format MMS serta proses perngiriman/penerimaan MMS dapat dibaca pada spesifikasi tersebut. Pada posting ini saya jelaskan secara singkat bagaimana proses tersebut berjalan dan arsitektur elemen yang mengatur MMS.

Jaringan packet switched pada core network digunakan sebagai lalu-lintas sebuah multimedia message (MM). MM akan dikirimkan oleh ponsel ke sebuah elemen yang berfungsi sebagai pengatur lalu-lintas dan penyimpan MM yang disebut MMSC (Multimedia Messaging Service Center). Proses peringiriman MMS dapat dijelaskan secara garis besar sebagai berikut:

1. Sebuah ponsel harus mengetahui alamat dari MMSC operator agar bisa mengirimkan sebuah MMS. Ponsel akan melakukan koneksi GPRS dan session GPRS dibuat pada SGSN.
2. Lewat WAP gateway, MMS dikirimkan ke MMSC menggunakan protokol HTTP atau WSP/WAP.
3. MMSC akan mengirimkan MMS ke tujuan. Jika tujuan adalah pelanggan pada operator yang sama maka MMSC akan mengirimkan WAP Push indikator-MMS ke ponsel tujuan. Jika tujuan adalah alamat email maka SMSC akan mengirimkannya ke Email Server tujuan.
4. Jika Wap Push indikator-MMS tidak dapat dikirimkan maka MMS akan disimpan ke dalam tempat penyimpanan atau Multimedia Message Box (MMBox).
5. MMSC kemudian akan melakukan pengiriman ulang (retry) ke tujuan beberapa kali. Jika hingga batas retry MMS tidak dapat dikirimkan maka biasanya MMSC akan mengirimkan pesan SMS kepada nomor tujuan memberitahukan bahwa sebuah MMS diterima dan dapat diambil melalui alamat web site (URL) tertentu.
   

Pada dasarnya MMSC merupakan penggabungan dua fungsi yaitu MMS Server dan MMS Proxy/Relay. MMS Server berfungsi sebagai tempat antrian atau penyimpanan MM (MMBox). Sedangkan MMS Proxy/Relay berfungsi sebagai elemen yang menghubungkan MMS Server dengan ponsel pengguna, melakukan inisialisasi koneksi, mengirimkan notifikasi, routing dan lain-lain.

Arsitektur yang umum adalah sebagai berikut

MMS client                          +-----------+                                     
(ponsel)    <--( Jaringan radio )-->| SGSN/GGSN |                                     
                                  +-----------+                                     
                                       ^
                                       |
                               +-----------------+
                               |WAP Gateway & PPG|
                               +-----------------+
                                       ^                                               
                                       |                                               
                                 ( Jaringan IP )                                       
                                       |                                               
                                       v                                               
                                    +------+                         --> MMSC lain     
                                    | MMSC |<---( Jaringan Internet )--> VASP          
                                    +------+                         --> SMTP/Email server

Titik-titik integrasi (reference point) yang menunjukan hubungan antara MMSC dengan elemen lain diberinama dan dispesifikasikan dalam dokumen 2GPP TS 20.140 (Multimedia Messaging Service Functional description) sebagai berikut:

• MM1: Reference point antara MMS User Agent denan MMS Relay/Server. Biasanya menggunakan WAP/WSP, walaupun dalam spesifikasi dimungkinkan untuk menggunakan protokol lain berbasis TCP/IP misalnya HTTP
• MM2: Reference point antara MMS Relay dengan MMS Server. Belum dispesifikasikan.
• MM3: Reference point antara MMS Relay/Server dengan external (legacy) messaging systems, misalnya MMSC lain atau Mail Server. Pada reference point ini biasanya digunakan protokol SMTP/IMAP.
• MM4: Reference point antara the MMS Relay/Server dengan MMS Relay/Server yang lain yang berada di lain MMSE (Multimedia Message Service Environment). Protocol yang digunakan adalah SMTP (RFC 821). STD 11 (RFC 2822), MIME (RFC 2046)
• MM5: Reference point antara the MMS Relay/Server dengan Home Location Register (HLR). Menggunakan MAP.
• MM6: Reference point antara the MMS Relay/Server dengan MMS User Databases. Belum dispesifikasikan.
• MM7: Reference point antara the MMS Relay/Server dengan MMS VAS Applications. Berbasis SOAP dan SOAP message with attachment [http://www.w3.org/TR/SOAP-attachments] dengan HTTP sebagai transport layer.
• MM8: Reference point antara the MMS Relay/Server dengan billing system. Belum dispesifikasikan.
  

                   .------------------------------.                           
+--------+         |                              |         +---------------+ 
| MMS UA |<--MM1-->| MMS Relay<--MM2-->MMS Server |<--MM3-->| Legacy System | 
+--------+         |                              |         +---------------+ 
                   '------------------------------'                           
                                             |||||           +-----------------+
                                             ||||+----MM4-->| MMS Relay/Server |
                                             ||||            +-----------------+
                                             ||||                              
                                             ||||           +--------+        
                                             |||+-----MM5-->|  HLR   |        
                                             |||            +--------+        
                                             |||                              
                                             |||            +---------------+ 
                                             ||+------MM6-->| User Database | 
                                             ||             +---------------+ 
                                             ||                                
                                             ||             +-----------------+
                                             |+-------MM7-->| VAS Application |
                                             |              +-----------------+
                                             |                                
                                             |              +----------------+
                                             +--------MM8-->| Billing System |
                                                            +----------------+

Protokol SMS: SMRSE

Saya pernah baca tentang SMRSE protocol (Short Message Relay Service Element), yaitu protokol khusus untuk lalu-lintas SMS antara SMSC dengan MSC. Protokol ini berbasis TCP/IP sebagai alternatif dari MAP (3GPP TS 29.002) yang berbasis SS7.

Spesifikasinya dibuat oleh Nokia dan dispesifikasikan pada 3GPP TS 23.047, tetapi ternyata tidak ada spesifikasi tersebut tidak ada dan sangat sulit mendapatkan informasi tentang protokol ini di Internet.

Protokol ini dibuat dan digunakan pada produk SMSC Nokia, sepertinya kemudian diusulkan menjadi standar tetapi tidak sampai disetujui oleh 3GPP. Protokol lain yang dibuat Nokia yaitu CIMD malah lebih populer sebagai protokol SMS antara SMSC dengan aplikasi eksternal.

Update: Setelah dicari-cari, akhirnya saya menemukan spesifikasi SMRSE interface ini. SMRSE interface dispesifikasikan sebagai standard GSM oleh ETSI yaitu GSM 03.47 Example protocol stacks for interconnecting Service Centre(s) (SC) and Mobile-services Switching Centre(s) (MSC) yang bisa didownload dokumennya disini.

Aplikasi pada SIM card

SIM Application Toolkit (SAT) atau sering disebut juga STK saja adalah aplikasi yang berada di SIM (Subscriber Identity Module) card atau USIM card dan dijalankan pada ponsel atau perangkat bergerak (mobile device) lainnya.

Jika didalam SIM card terdapat STK, secara otomatis biasanya ponsel akan menambahakan satu menu item atau ikon untuk mengaksesnya. Jika kita akses dengan mengklik menu item tersebut, kita dapat melihat menu selanjutnya yang ditampilkan oleh ponsel. Aplikasi tersebut disediakan oleh operator dan biasanya digunakan untuk mengakses informasi tertentu, misalnya informasi billing, download konten, informasi berita dan lain-lain.

Karena disimpan dalam SIM card, maka aplikasi ini tidak bisa menyimpan data yang besar sehingga biasanya STK didesain sangat sederhana dan tidak menyimpan data yang dinamis (perlu selalu diperbarui). Lalu bagaimana aplikasi ini bisa menampilkan data konten yang begitu banyak? STK dapat memerintahkan ponsel untuk mengirimkan data ke jaringan operator melalu SMS sehingga data cukup disimpan dalam sebuah elemen di jaringan operator kemudian STK memintanya dengan mengirimkan data lewat SMS.

,-----------------.
|        Ponsel   |
|                 |
| ,--------------.|                 +------+               +------------+
| |   SIM card   ||                 |      |               |            |
| |              ||--------//------>| SMSC |-------------->| STK Server |
| | ,----------. ||<-------//------ |      |<--------------|            |
| | | aplikasi | ||                 +------+               +------------+
| | `----------' ||
| `--------------'|
`-----------------'

Pada 2G Network, SAT didefinisikan pada standar ETSI GSM 11.14. Pada release 4 (3G), dispesifikasikan pada 3GPP TS 31.111.

Spesifikasi 3GPP yang berkaitan diantaranya:

• 11.11 Specification of the Subscriber Identity Module - Mobile Equipment (SIM-ME) Interface
• 11.14 Specification of the SIM Application Toolkit (SAT) for the Subscriber Identity Module - Mobile Equipment (SIM-ME) interface
• 03.48 Security mechanisms for SIM application toolkit; Stage 2
  

• 31.111 Universal Subscriber Identity Module (USIM) Application Toolkit (USAT)
• 51.011 Specification of the Subscriber Identity Module - Mobile Equipment (SIM-ME) interface
• 51.014 Specification of the SIM Application Toolkit for the Subscriber Identity Module - Mobile Equipment (SIM-ME) interface
• 23.048 Security mechanisms for the (U)SIM application toolkit; Stage 2
  

Analisis trafik menggunakan Erlang

Sebelum sebuah operator telepon berdiri, biasanya operator telah memiliki target jumlah pelanggannya. Lebih detail lagi dari jumlah pelanggan tersebut operator melakukan kalkulasi sehingga didapatkan business case yang rasional. Setelah itu barulah operator atau vendor yang akan membangun infrastruktur melakukan perencanaan pambangunan jaringan. Hal yang sama juga dilakukan oleh operator yang akan melakukan ekspansi jaringannya.

Perencaan pembangunan jaringan inti (core network) dilakukan dengan mengikuti langkah-langkah berikut:

1. Pendefinisian kebutuhan jaringan (assessment)
2. Dimensioning yaitu menganalisis dan melakukan perhitungan terhadap kebutuhan dari infrastruktur sesuai target yang telah dibuat.
3. Pembuatan master plan
4. Pembuatan detil perencanaan seperti detil prosedur dan detil spesifikasi tiap-tiap elemen yang dibutuhkan
   

Sebuah definisi kebutuhan jaringan biasanya dibagi per wilayah dengan mempertimbangkan jumlah target pelanggan disetiap wilayah, efektifitas perawatan, biaya-biaya dan lain-lain. Target-target dari kebutuhan juga biasanya didefinisikan per satuan waktu sehingga pembangunan infrastruktur dapat dilakukan bertahap.

Kebutuhan dari trafik tersebut direpresentasikan dalam traffic profiles yang terdiri dari parameter-parameter seperti:

• Trafik per pelanggan dalam Erlang
• Jumlah panggilan selama waktu sibuk (Busy Hour Call Attempts/BHCA) per perlanggan
• Average call duration atau Mean Holding Times (MHT)
• Grade of service atau blocking rate
• Persentase trafik data
• Persentase trafik mobile originated (MO)
• Persentase trafik mobile terminated (MT)
• Persentase trafik ke PSTN
• Persentase trafik ke jaringan PLMN lain
• Persentase trafik ke switch di wilayah lain
  

Dari profil trafik tersebut barulah bisa dilakukan dimensioning. Dimensioning yang terpenting adalah menentukan jumlah link atau trunk yang dibutuhkan dari elemen switching. Perhitungan kebutuhan link dari trafik telekomunikasi dipelajari dalam studi teletraffic engineering. Studi tersebut melibatkan teori trafik dan antrian.

Sebelum kita bahas bagaimana biasanya jumlah link/trunk dihitung, kita perlu tahu dulu apa itu Erlang. Erlang merupakan satuan tanpa dimensi yang digunakan untuk menunjukan intensitas lalu-lintas (traffic occupancy) suatu sistem telekomunikasi.

Satu erlang biasanya didefinisikan sebagai penggunaan link/circuit oleh pemanggilan (call) selama 3600 detik secara kontinyu dalam durasi satu jam.


Contoh perhitungan Erlang sederhana:

Jika terjadi 100 pemanggilan dalam satu jam, dengan masing-masing pemanggilan lamanya 2 menit. Maka pemakaian trafik dalam erlang adalah

Total durasi panggilan selama sejam = 100 panggilan x 2 menit = 200 menit
Trafik selama sejam dalam Erlangs = 200 menit / 1 jam = 3,33 jam / 1 jam = 3.33 erlangs

Sejumlah trafik harus dilayani oleh sejumlah trunk atau link circuit dari switching oleh sebab itu perlu ditentukan berapa banyak link yang dibutuhkan untuk sejumlah trafik tertentu sehingga tidak terjadi pemanggilan yang terblok (blocked call) karena keterbatasan link yaitu saat jumlah link yang tersedia untuk melayani pemanggilan lebih sedikit dari jumlah pemanggilan dalam saat yang bersamaan (kondisi sibuk).

Operator biasanya memiliki nilai batas persentase pemanggilan yang terblok (blocking rate) sehingga dapat ditentukan kebutuhan akan link yang diperlukan.

Dengan menggunakan model trafik Erlang-B maka kita dapat menghitung probabilitas terjadinya bloking jika diketahui besarnya trafik dan jumlah link. Probalitas tersebut disebut juga Grade of Service (GoS) yang menungjukan kualitas jaringan. Semakin kecil GoS berarti kualitas jaringan dalam melayani pelanggan semakin baik.

Model trafik Erlang-B dirumuskan sebagai berikut:

         m
        E
      -----
        m!
GoS = -------------
     m
    ___    i
    \     E
     >  -----
    /     i!
    ---
    i= 0

Lihat persamaan diatas dalam format gambar.

Dengan,

E adalah trafik dalam erlang,
N adalah jumlah link/trunk

Jadi jika diketahui GoS dan trafik yang diharapkan (E), kita dapat mengetahui jumlah link yang diperlukan (N). Anda dapat menggunakan kalkulator online untuk perhitungan menggunakan Erlang-B diatas.

Model Erlang-B diatas biasa digunakan dalam telekomunikasi dengan asumsi-asumsi tertentu, salah asumsinya adalah pemanggilan yang tidak sukses karena kondisi sibuk tidak masuk dalam antrian serta tidak terjadi pengulangan pemanggilan (retry).


Pada kenyataannya pelanggan biasanya mencoba melakukan pemanggailan lagi (rerty) jika pemanggilan tidak sukses. Dengan model trafik Extended Erlang-B, maka faktor jumlah retry jika terjadi pemanggilan tidak sukses tidak lagi diabaikan.


Sekian dulu tulisan saya tentang Erlang dan analisis trafik jaringan telekomunikasi, lain kali mungkin saya akan tulis contoh studi kasus perhitungannya.

Kemampuan (kapabilitas) suatu perangkat bergerak

Ada banyak alasan mengapa operator telekomunikasi atau service provider perlu mangetahui perangkat yang digunakan oleh pelanggannya. Alasan utamanya adalah untuk dapat menentukan atau memberikan layanan yang sesuai untuk diberikan kepada pelanggannya terutama layanan nilai tambah (value added service). Sebagai contoh operator yang mengetahui hanya sebagian kecil saja dari pelanggannya yang menggunakan perangkat 3G maka operator tersebut dapat menentukan agar tidak terlalu fokus pada promosi layanan 3G seperti video call. Contoh lain misalnya sebuah penyedia konten (content provider) yang harus memberikan konten yang memang dapat ditampilkan atau dijalankan pada perangkat si pembeli.

Informasi yang perlu diketahui dari sebuah perangkat?

Kita mengenal sebuah perangkat misalnya ponsel dengan nama produsen dan tipenya, misalnya Nokia N80, SonyEricsson , Samsung SGH800 dan lain-lain. Dengan mengetahui tipe suatu perangkat maka kita akan mengetahui kapabilas dari perangkat tersebut misalnya perangkat mana yang mendukung 3G atau perangkat yang dapat menjalankan Java game dan lain-lain. Jadi yang menjadi fokus informasi dari sebuah perangkat adalah segala aspek kemampuan (capability) dari perangkat tersebut. Jika informasi kapabilitas yang diketahui dari suatu perangkat lebih lengkap tentu saja lebih baik.

Ada banyak cara operator atau service provider mengetahui perangkat yang digunakan oleh pelanggannya. Dua cara yang paling umum adalah

- Mengetahui nomor seri perangkat atau IMEI
Untuk mengetahui IMEI dari perangkat yang digunakan pelangganya, operator menyimpan aplikasi didalam SIM card yang men-trigger proses pada saat perangkat tersebut diaktifkan. Proses tersebut akan membaca IMEI untuk kemudian mengirimkannya bersama-sama dengan informasi IMSI/ICCID/MSISDN ke sebuah sistem lewat SMS.

Cara ini hanya dapat mengetahui jenis atau tipe perangkat saja sehingga untuk mengetahui detil kapabilitas dari perangkat tersebut perlu adanya database lain mengelola data kapabilas dari setiap perangkat. Data tersebut perlu dikelola (maintain), terutama jika ada perangkat baru di pasaran maka database perlu diperbarui dengan data kapabilitas perangkat baru tersebut.


- Mengetahui jenis perangkat dari informasi yang diberikan pada HTTP/WAP header.
Jika aplikasi browser pada perangkat melakukan koneksi HTTP/WAP pada sebuah web server maka browser akan memberikan informasi client pada HTTP header. Informasi client tersebut terdapat dalam parameter user-agent atau x-wap-profile. Contoh sebuah HTTP header dari request sebuah ponsel:

  host: operator.co.id
  accept-language: en
  user-agent: Nokia6680/1.0(5.04.40) SymbianOS/8.0 Series60/2.6 Profile/MIDP-2.0 Configuration/CLDC-1.1
  x-wap-profile: "http://nds1.nds.nokia.com/uaprof/N6680r100.xml"
  accept: text/html,text/vnd.wap.wmlscript,*/*;q=0.001,text/ecmascipt,application/x-javascript,application/vnd.oma.dd+xml,[dihapus]
  accept-charset: iso-8859-1,utf-8,iso-10646-ucs-2;q=0.600,*;q=0.001
  accept-encoding: gzip, deflate,indentity;q=0.900,*;q=0.001
  Connection: Keep-Alive

Dengan metode ini, setiap sistem yang diakses oleh pengguna (user) dapat mengetahui jenis atau kapabilitas dari perangkat yang digunakan meskipun sistem itu berada diluar jaringan operator.

User-Agent

Dari sebuah user-agent header kita biasanya dapat menemukan jenis perangkat, versi dari sistem operasi, versi dari browser atau aplikasi client yang digunakan pada perangkat tersebut, kapabilitas Java dan lain-lain.

Pada contoh header diatas kita bisa lihat bahwa orang yang mengakses sistem menggunakan Nokia tipe 6680 dengan sistem operasi SymbianOS jenis Series60. Dengan mengetahui informasi tersebut maka sebagian besar kapabilitas dari perangkat dapat ketahui karena sebuah tipe perangkat dengan versi yang sama akan memiliki kapabilitas yang sama pula.

Biasaya informasi yang lengkap didapatkan jika koneksi HTTP/WAP dilakukan oleh browser/aplikasi client bawaan dari pembuat perangkat tersebut. Ada kalanya jika kita menggunakan browser lain yang kita install sendiri maka informasi user-agent header tidak lengkap.


User agent Profile (UAprof)

UAProf adalah sebuah standar yang menspesifikasikan pendokumentasian dari kapabilitas sebuah suatu perangkat (user agent). Informasi tentang jenis/tipe perangkat serta kapabitasnya tersebut disimpan dalam sebuah dokumen XML. UAProf dibuat oleh OMA berdasarkan standar CC/PP (Composite Capabilities/Preferences Profiles) dan RDF (Resource Description Framework) yang dibuat oleh W3C.

UAProf dari sebuah perangkat disimpan pada sebuah server yang dapat diakses oleh publik yang biasanya dikelola oleh perusahaan yang membuat perangkat. Alamat URL dimana UAProf berada dapat diketahui pada HTTP header yaitu pada parameter x-wap-profile seperti contoh diatas atau jika koneksi yang digunakan adalah WSP/WAP maka URL ada pada parameter Profile.

Pada contoh diatas xml dokumen UAProf berada di

  http://nds1.nds.nokia.com/uaprof/N6680r100.xml

Dengan mengakses URL tersebut kita dapat melihat kapabilitas dari perangkat Nokia 6680. Kapabilitas dari suatu perangkat dibagi dalam beberapa blok deskripsi yaitu:

• Hardware platform yang mendeskripsikan karakteristik hardware misalnya tipe perangkat, model, ukuran layar, kemampuan input output dan lain-lain
• Software platform yang berisi koleksi atribut yang berhubungan dengan lingkungan operasi perangkat misalnya OS, video atau audio encoder, API yang didukung oleh perangkat dan lain-lain
• BrowserUA yang berisi parameter-parameter yang mendeskripsikan aplikasi browser
• NetworkCharacteristics yang berisi parameter-parameter yang berhubungan dengan kemampuan akses jaringan
• WapCharacteristics yang berisi parameter-parameter yang berhubungan dengan kemampuan WAP
• PushCharacteristics yang berisi parameter-parameter yang berhubungan dengan Push (WAP push)
  

Contoh sebuah blok UAProf:

        <rdf:Description rdf:ID="PushCharacteristics">
           <rdf:type rdf:resource="http://www.openmobilealliance.org/tech/profiles/UAPROF/ccppschema-20021212#PushCharacteristics"/>
           <prf:Push-Accept-Charset>
              <rdf:Bag>
                 <rdf:li>ISO-8859-1</rdf:li>
                 <rdf:li>ISO-10646-UCS-2</rdf:li>
                 <rdf:li>US-ASCII</rdf:li>
                 <rdf:li>UTF-8</rdf:li>
              </rdf:Bag>
           </prf:Push-Accept-Charset>
           <prf:Push-Accept-Encoding>
              <rdf:Bag>
                 <rdf:li>base64</rdf:li>
                 <rdf:li>quoted-printable</rdf:li>
              </rdf:Bag>
           </prf:Push-Accept-Encoding>
           <prf:Push-Accept-Language>
              <rdf:Seq>
                 <rdf:li>en-US</rdf:li>
              </rdf:Seq>
           </prf:Push-Accept-Language>
           <prf:Push-Accept-AppID>
              <rdf:Bag>
                 <rdf:li>x-wap-application:wml.ua</rdf:li>
                 <rdf:li>*</rdf:li>
              </rdf:Bag>
           </prf:Push-Accept-AppID>
           <prf:Push-MsgSize>34170</prf:Push-MsgSize>
        </rdf:Description>

Penjelasan lebih lanjut tentang UAProf dapat dibaca di dokumen spesifikasinya

Dengan adanya UAProf maka operator dapat memiliki data kapabilitas dari perangkat tanpa perlu susah payang mengelolanya karena UAProf biasanya disediakan oleh pembuat
perangkat. Tetapi tidak semua perangkat mendukung UAProf sehingga operator mungkin perlu membuat data kapabilitas sendiri untuk perangkat-perangkat yang tidak mendukung UAProf.

IMT-advanced: Payung dari teknologi 4G?

Saat ini teknologi 3G yang dipayungin oleh standar ITM-2000 terlihat sudah semakin banyak digunakan sehingga kebutuhan akan akses data nirkabel yang memiliki kecepatan tinggi semakin dibutuhan baik untuk layanan bergerak maupun tidak bergerak (nomadic). Untuk itu, ITU sebagai organisasi telekomunikasi mulai mendefinikan sistem komunikasi masa depan yang diharapkan bisa memenuhi kebetuhan tersebut.

Untuk mencapai sistem komunikasi bergerak/nirkabel masa depan yaitu system beyond 3G/IMT-2000, Kelompok kerja Working Party 8F (WP 8F) yang berada dibawah ITU Radiocommunication Sector (ITU-R) mendefinikan IMT-Advanced. Tim tersebut akan berkerja untuk mendefinikan dan prinsip-prinsip teknologi yang akan digunakan dan memanggil secara terbuka kandidat dari teknologi ini selama tahun 2008-2009. Jadi kemungkinan IMT-Advanced ini juga akan memayungi beberapa standar teknologi, tapi bisa juga hanya satu teknologi yang disetujui.

Fitur-fitur yang menjadi kunci dari IMT-Advanced ini diatantanya adalah:

• Konvergensi dari semua sistem komunikasi bergerak/nirkabel
• Memiliki bermacam layanan dan QoS yang memberikan kenyamanan pada pengguna
• Kecepatan data (data rate) yang lebih tinggi mencapai 100Mbps pada mobilitas tinggi dan 1Gbps jika dalam kondisi diam
• Kemampuan roaming secara global
• Handover antar jaringan akses yang berbeda-beda
• Memiliki arsitektur jaraingan All-IP
• Memiliki QoS yang setara dengan jaringan wireline

IMT-Advanced mulai dibicarakan awal tahun 2007 dan diharapkan mulai tersedia secara komersial pada awal tahun 2011.

Saat ini teknologi nirkabel seperti wireless broadband dan 3G terlihat semakin konvergen. OFDM atau OFDMA menjadi teknologi utama yang digunakan sebagai air interface pada generasi berikutnya dari UMTS, CDMA2000 dan WiMAX. Teknologi OFDM/OFDMA diperkirakan dapat memenuhi kebutuhan data rate yang tinggi yang didefiniskan pada IMT-Advanced, oleh karena itu kemungkinan besar IMT-Advanced akan mengadopsi OFDM/OFDMA sebagai teknologi utama.

Karena OFDM/OFDMA telah diadopsi oleh WiMAX 2, LTE/SAE (pengembangan dari UMTS) dan UMB (pengembangan dari EV-DO) dan ketiga standar itu dinaungi oleh organisasi yang kuat maka akan ada persaingan yang bersifat politis agar ketiga teknologi tersebut diadopsi sebagai basis teknologi IMT-Advanced.

UMB: Evolusi CDMA2000 menuju 4G

Belum lama ini, September 2007, spesifikasi air interface UMB (3GPP2 C.s0084-0 v2.0) dipublikasikan oleh dua organisasi yang menaungi teknologi CDMA2000 yaitu CDMA Development Group (CDG) dan 3GPP2.

Ultra Mobile Broadband (UMB) merupakan nama yang menggantikan CDMA EV-DO Revision C yang merupakan versi baru dari CDMA2000. UMB diharapkan dapat memberikan peak data rate yang lebih besar sampai 288 Mbps untuk upload dan 75 Mbps untuk download dengan penggunaan lebar pita 20MHz. Peningkatan data rate tersebut didapatkan dengan menerapkan teknologi baru pada air interface yaitu Orthogonal Frequency Division Multiple Access (OFDMA) dan teknik antena yang lebih baik yaitu dengan Multiple Input Multiple Output (MIMO), Space Division Multiple Access (SDMA) dan beamforming.

Teknologi ini juga masih menggunakan CDMA sebagai air interface untuk mendukung backward compability sehingga pengguna UMB masih dapat menggunakannya pada jaringan CDMA2000 1X dan 1xEV-DO.

Detail dari press release UMB dapat dilihat di sini.