Friday, December 28, 2007

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.

Thursday, December 27, 2007

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

Wednesday, December 26, 2007

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.

Saturday, December 22, 2007

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.

Tuesday, December 11, 2007

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.

Tuesday, November 27, 2007

LTE/SAE: evolusi 3G pada UMTS

Sebelum ketinggalan momentum, saya akan tulis tentang LTE (Long Term Evolution) yang mulai digembar-gemborkan oleh beberapa perusahaan yang memproduksi alat-alat telekomunikasi seperti Alcatel-Lucent, Ericsson, NSN dan lain-lain.

LTE atau SAE (Long Term Evolution/System Architecture Evolution) adalah telnologi yang sedang dirumuskan oleh 3GPP sebagai evolusi dari teknologi 3G/UMTS yang ada saat ini. Teknologi ini dibuat dengan tujuan meningkatkan beberapa aspek diantaranya:

  • perbaikan efisiensi spektral: penggunaan spektrum yang fleksibel dan lebar pita (band with) yang scalable dari 1.25MHz sampai 20 MHz
  • peningkatan kapasitas
  • latensi yang rendah
  • biaya operasional yang lebih rendah
  • memiliki performansi yang tinggi
Target yang ingin dicapai oleh teknologi ini adalah downlink/uplink peak data rate sampai pada 100/50 Mbps.

LTE berarti evolusi pada Radio Access (UTRA) atau air interface dan Radio Access Network (UTRAN), sedangkan SAE berarti evolusi atau migrasi pada arsitektur jaringan inti (core network) yang dilakukan untuk mencapai tujuan diatas.

Kata Evolution agaknya diambil karena para pencetus LTE mulai memikirkan perubahan besar dengan melihat teknologi baru pada air interface dan arsitektur sistem tanpa melihat sistem yang ada saat ini. Hal ini menyebabkan adanya banyak perubahan, misalnya seperti penggunaan teknologi OFDM (Orthogonal Frequency Division Multiplexing) sebagai basis air interface pada lapisan akses radio (radio access layer), arsitektur system flat IP (All-IP), level modulasi yang lebih tinggi dan lain-lain.

Studi tentang LTE/SAE ini diharapkan selesai pada tahun 2007 dan mulai dicoba (trial) pada tahun 2008. Tapi kemungkinan teknologi ini baru akan diadopsi secara komersial pada tahun 2011. Ini lebih lambat dari pada target komersial untuk teknologi serupa UMB (Ultra Mobile Broadband) [link] yang merupakan evolusi dari teknologi CDMA200 yang ditargetkan akan dipakai komersial tahun 2009.

LTE disebut-sebut sebagai teknologi 4G untuk UMTS yang bersaing dengan UMB dan WiMax 2 (IEEE 802.16m) untuk masuk dalam payung standarisasi 4G yaitu IMT-Advanced yang baru saja direncakanan ITU (Iternational Telecommunication Union). Kita lihat saja nanti siapa yang lebih dulu memberikan keuntungan data rates yang lebih besar bagi kita.

Penjelasan tentang SAE/LTE dapat dilihat di website 3GPP ini

Saturday, November 17, 2007

Perjelas kontrak lisensi produk untuk menghindari masalah

Lisensi produk (license) merupakan hal yang penting untuk diperhatikan ketika kita akan membeli produk. Definisi lisensi dari produk yang akan dibeli harus jelas dan dikritisi. Hal ini untuk menghindari terjadinya masalah ditengah jalan ketika lisensi telah mencapai batas dan pembeli produk ingin menambah kapasitas dari produk yang dibelinya.

Masalah lisensi sering terjadi pada perusahan-perusahan telekomunikasi baik di perusahaan kecil maupun besar. Masalah sering terjadi dan diketahui terlambat sehingga tidak menguntungkan bagi pembeli. Masalah yang umum adalah ketika suatu produk telah dibeli dengan mahal tetapi menghasilkan keuntungan (revenue) yang tidak signifikan dan lisensi yang dibeli cepat sekali habis.

Pada produk-produk telekomunikasi, biasanya lisensi berdasar pada angka yang menunjukan kapasitas produk misalnya:
  • Jumlah pelanggan (subscriber)
  • Besarnya transaksi per detik tertinggi (Peak Transaction per Second/ TPS), jumlah transaksi perbulan
  • Jumlah panggilan per detik (Call Attempt per Second/ CAPS)
  • Jumlah CPU
Perhitungan lisensi dengan menggunakan TPS sering kali tidak jelas (absurd). Misalnya saja produk SMSC atau messaging gateway memiliki lisensi 100 TPS, tidak serta merta berarti lisensi akan habis jika telah terjadi transaksi SMS sebanyak 100 per detik.Perlu didefinisikan transaksi apa saja yang akan dihitung. Dalam sebuah elemen produk telekomunikasi biasanya terintegrasi dengan banyak elemen lain, dalam hal produk SMSC biasa terhubung dengan MSC/MSS, HLR, aplikasi third party (content provider), database dan lain-lain. Pasa setiap titik integrasi tentu akan terjadi transaksi sehingga perlu diperhatikan transaksi ke elemen mana yang termasuk dalam lisensi dan seperti apa definisi satu transaksi itu.

Thursday, November 15, 2007

Petunjuk untuk spesifikasi 3GPP (external link)

Setelah saya membuat post tentang "Petunjuk untuk spesifikasi 3GPP", saya menemukan posting lain mengenai hal yang sama di sini (Finding your way on the 3GPP website). Perlu untuk dibaca, dia menjelaskan lebih banyak tentang working group, agenda, meeting dan alamat untuk mendapatkan dokumen-dokumen terkait.

Petunjuk untuk spesifikasi 3GPP

Jika Anda bekerja di bidang telekomunikasi nirkabel atau pelajar yang mempelajarinya, dan pekerjaan Anda membawa Anda untuk membaca dokumen spesifikasi standar GSM/3GPP maka sebaiknya Anda pelajari bagaimana 3GPP melakukan versioning atau rilis dokumennya. Lakukan hal ini sebelum anda bingung spesifikasi mana yang seharusnya Anda baca.

Sebelumnya saya telah sedikit menjelaskan bagaimana versioning dari spesifikasi yang dikeluarkan OMA. Tidak banyak yang ditulis karena memang sederhana dan tidak banyak dokumen yang dihasilkan jika dibandingkan dengan 3GPP.

Mempelajari spesifikasi dari 3GPP sangat menarik karena dokumen yang ada begitu banyak dan teknologi yang dilingkupinya begitu luas dan kompleks. Dengan mempelajari spesifikasi 3GPP, kita dapat memahami bagaimana teknologi GSM atau 3G/UMTS bekerja mulai dari telepon selularnya, arsitektur jaringan operator hingga detil bagaimana antar elemen pada arsitektur itu berkerja. Selain itu kita juga bisa melihat dengan detil bagaimana teknologi telekomunikasi nirkabel berevolusi dari 2G ke 3.9G atau 4G.

Tentang 3GPP

3GPP merupakan kolaborasi dari beberapa organisasi telekomunikasi yang membuat standar atau spesifikasi untuk 3GSM/UMTS yaitu pengembangan teknologi dari GSM. 3GPP .

Suatu tujuan/target, perubahan (enhancement) substansial atau penambahan fitur (Feature) baru biasanya direncakan dalam sebuah Work Plan. Work plan berisi item-item

pekerjaan yang lebih rinci yang akan dilakukan oleh group yang menghasilkan Change Request (dokumen perubahan) dan atau Technical Specification dan Technical Report. Ada baiknya kita membaca Work Plan untuk mengetahui teknologi yang digunakan atau akan digunakan pada suatu rilis (Release). Work Plan dari setiap rilis dapat diunduh di sini

Lebih detail tentang metode kerja TSG dapat dilihat di dokumen TR 21.900

TR dan TS

3GPP mempublikasikan hasil pekerjaannya yang penting yaitu Technical Report (TR) dan Technical Specification (TS).

Technical Specification adalah spesifikasi teknis dari suatu bagian/cakupan kecil suatu fitur (building-block). Suatu TS biasanya terdiri dari beberapa stage, yang akan dijelaskan dibawah.

Technical Report merupakan hasil dari studi awal (initial study) dan studi kelayakan (feasibility study) suatu fitur dan didalamnya tercakup petunjuk untuk implementasi awal (early implementation) dari sebuah fitur baru.

Release

Sebuah rilis dibuat oleh 3GPP jika ada pemanbahan fitur atau perubahan yang drastis dari suatu kebutuhan (requirement). Jika suatu rilis diberhentikan (freeze) berarti spesifikasinya telah final. rilis baru dan tujuannya biasanya adalah untuk meningkatkan performansi, kecepatan data dan lain-lain oleh karena itu biasanya biasanya ada perubahan besar pada elemen arsitekrur atau radio interface pada setiap rilis.

Rilis 3G dimulai dari
Release 99 (R99) selesai tahun 1999,
Release 4 (Rel-4) selesai tahun 2001,
Release 5 (Rel-5) selesai tahun 2002,
Release 6 (Rel-6) selesai tahun 2005,
Release 7 (Rel-7) selesai tahun 2007,
Rilis terkini adalah Release 8 dan masih dalam pengembangan.

List feature per rilis dapat dilihat di sini

Penomoran TS/TR

Mengenal cara penomoran TS sangat penting, terutama mengetahui hubungannya dengan rilis. Agak malas menjelaskannya disini tapi karena ini penting jadi sebaiknya penjelasan mengenai numbering di web site 3GPP harus dibaca sebelum menlanjutkan membaca artikel ini.

Selain cara penomoran, ada beberapa istilah yang perlu kita tahu juga yaitu stage dan phase.

Stage digunakan untuk menunjukan jenis spesifikasi.

Stage 1: deskripsi kebutuhan atau layanan
Stage 2: Analisis logik, fungsionalitas elemen dan aliran informasi antar elemen
Stage 3: Detil implementasi, protokol

Phase digunakan untuk menunjukan evolusi atau versi dari fungsionalitas tertentu, misalnya phase 1, phase 2, phase 2+, phase 3 dan seterusnya.

Menemukan dokumen spesifikasi yang diinginkan.

Untuk menemukan dokumen spesifikasi yang kita cari, sebaiknya kita buka halaman Specification Release Matrix, kemudian cari dengan fungsi search/find browser.

Thursday, November 08, 2007

WiMAX masuk sebagai standar 3G

Pada tanggal 19 Oktober 2007, standar teknologi komunikasi nirkabel pita-lebar (broadbad wireless access) IEEE 802.16 atau yang lebih dikenal dengan WiMAX, telah diresmikan oleh organisasi telkomunikasi dunia (ITU) menjadi salah satu set standar teknologi 3G. Ini berarti WiMAX telah berada pada posisi yang sejajar dengan teknologi 3G yang lain seperti W-CDMA/UMTS (IMT-MC) dan cdma2000 EV/DO (IMT_DS) yang lebih dulu banyak digunakan sebagai teknologi 3G untuk telepon bergerak.

Standar 3G yang dimaksud adalah IMT-2000 yang merupakan standar global yang mendefinisikan kebutuhan dari teknologi 3G dan sebuah set dari standar-standar lain yang disebut Recommendation yang dibuat oleh ITU. Terminologi untuk teknologi IEEE 802.16 yang dispesifikasiakan pada ITU-R M.1457 Recommendation adalah "IMT-200 OFDA TDD WMAN"

WiMAX sebenernya telah ramai diimplementasikan di berbagai negara, dan kelihatannya di Indonesia WiMAX akan mulai populer juga walaupun saat ini (November 2007) belum ada layanan WiMAX komersial yang beroperasi. Implikasi dari sisi komersial dari dimasukannya WiMAX menjadi teknologi 3G standar adalah persaingan antar perusahan (vendor, operator telekomunikasi, pemroduksi alat-alat telekomunikasi) yang telah bergerak di teknologi 3G lainnya dengan perusahaan yang bergerak di teknologi WiMAX.

Persaingan akan menjadi menarik karena teknologi WiMAX merupakan teknologi murah (low cost) dan berbasis layanan wireless internet. Berbasis wireless internet berarti semua elemen telah berbasis pada jaringan IP (all-IP network) mulai dari jaringan inti (Core network) sampai pada perangkat pengguna (user equipment). Karena berbasis IP, WiMAX menggunakan teknologi VoIP (Voice over Internet Protocol) untuk komunikasi suara antar pelanggan. Pada telnologi 3G lainnya, arsitektur All-IP dan VoIP belum mulai diterapkan. Pada teknologi 3G UMTS, arsitektur All-IP dan VoIP mulai diterapkan pada standar 3GPP rilis 5 dan saat ini kebanyakan operator mengimplementasikan 3GPP rilis 4.

Dari sisi teknis, diadopsinya WiMAX pada standar IMT-2000 berarti tambahan pekerjaan bagi organisasi-organisasi terkait untuk membahas bagaimana jaringan telepon tetap (fixed network) dan teknologi 3G lainnya dapat berinteraksi (interoperability) dengan teknologi WiMAX secara harmonis.

Press release dari masuknya WiMAX menjadi standar 3G dapat dilihat di sini.

Tuesday, November 06, 2007

Layanan USSD callback (UCB) : Solusi roaming untuk pra-bayar

Layanan USSD callback (UCB)

Proses charging pelanggan prabayar harus dilakukan secara realtime, hal ini membuat proses tersebut sulit dilakukan jika pelanggan tersebut roaming di luar negeri. Interoperability antar dua jaringan yang berbeda sulit dilakukan karena setiap oprator bisa jadi menggunakan protokol yang sama sekali berbeda atau berbeda versi. Salah satu solusi untuk pelanggan prabayar yang roaming adalah menggunakan CAMEL Phase 2, hanya saja masalahnya tidak semua operator mendukung CAMEL-2. Untuk itulah ada solusi lain yang disebut USSD callback.

Prinsip USSD callback ini adalah, pelanggan (A number) mengirimkan kode perintah kepada home network agar home network melakukan pemanggilan (call) ke pelanggan yang itu sendiri (A number) serta ke pelanggan yang dituju (B number).

Karena solusi ini menggunakan USSD, maka pelanggan yang roaming hanya perlu melakukan dial dengan kode akses tertentu, misalnya #123*628012345678# untuk menghubungi nomor

+628012345678.

Proses dan arsitektur dari USSD callback adalah sebagai berikut:


VISITED NETWORK | HOME NETWORK

.-----------. | .-----------.
| |--2.USSD Request--->| |
| MSC | | | HLR |
| | | |
'-----------' | '-----------'
^ |
| | | 3.USSD Request
| v
1.Dial | .-----------. 4. Cek .------------------.
| | |----------->| Billing System |
| | |UCB System | | atau IN |
Penelpon <-----6.Callback-----| |----------->| |
| '-----------' 7. Commit '------------------'
|
| 5a.Setup call
|
| V
.-----------.
| | | 5b.Setup call
| MSC |----------------> Yang ditelpon
| | |
'-----------'

  1. Pelanggan pra-bayar yang berada di visited network mengirimkan perintah USSD dan diterima oleh VMSC
  2. USSD request diteruskan ke HLR di home network
  3. HLR mengetahui bahwa perintah USSD tersebut adalah perintah callback yang harus diteruskan ke UCB system
  4. USSD Callback system kemudian melakukan pengecekan terhadap sisa pulsa (balance) dari penelpon dengan mengirimkan pesan ke Billing System atau Intelligent Network (Service COntrol Point). Pengecekan dapat dilakukan secara terus menerus (reguler) selama percakapan berlangsung, atau hanya pada saat awal.
    Jika pengecekan dilakukan satu kali disaat awal, maka UCB system harus tahu kapan percakapan harus diputuskan dengan sisa pulsa yang dimiliki si pemanggil.
    Karena penelpon berlokasi diluar home network (roaming) dan biasanya harga percakapan roaming berbeda (lebih mahal) maka biasanya UCB system akan mengirimkan MAP ATI (Any-Time Interrogation) ke HLR untuk mendapatkan lokasi dari pemanggil.
  5. Jika penelpon masih memiliki pulsa maka UCB system melakukan pemanggilan ke nomor tujuan.
  6. UCB system melakukan pemanggilan ke penelon untuk membuat sambungan dengan nomor tujuan. Dalam gambar ditunjukan panah langsung dari USSD Callback Server ke penelepon hanya untuk mempermudah pemahaman. Pada kenyataaanya, USSD Callback Server akan melakukan pemanggilan lewat Gateway MSC di home network untuk kemudian diteruskan ke VMSC.
  7. Pengurangan pulsa dilakukan USSD Callback server dengan cara mengirimkan commit request ke billing system atau IN.

Adakalanya layanan UCB dilakukan oleh IN/SCP, beberapa produk IN telah menambahkan fasilitas ini didalamnya sehingga operator tidak memerlukan produk atau server terpisah. Operasi InitiateCallAttempt diperlukan untuk dapat terjadinya callback ke penelpon dan sambungan ke orang yang ditelpon. InitiateCallAttempt didukung oleh ETSI INAP CS-1 atau CAP-4 (CAMEL Aplication Part phase 4) atau phase yang lebih tinggi. INAP atau CAP digunakan hanya untuk interaksi antar SCP/IN dengan MSC/MSS sehingga visited network tetap tidak perlu mendukung CAMEL.

Apa yang diperlukan oleh USSD Callback System?

Dari arsitektur diatas kita bisa tahu bahwa sebuah USSD Callback System perlu mendukung atau memiliki

  • Signaling link (SS&/SIGTRAN) dengan MAP untuk mendapatkan informasi USSD message dari HLR
  • ISUP untuk setup/release pemanggilan (call)
  • Koneksi untuk voice trunk
  • Koneksi ke elemen lain misalnya SMSC untuk pengiriman notifikasi
  • Charging protokol misalnya Diameter

Monday, November 05, 2007

Skenario charging

Ada dua jenis skenario online billing atau charging yang biasa digunakan dalam jaraingan telekomunikasi, yaitu:

-> Two steps charging scenario.

Charging terhadap pelanggan dilakukan dengan mengirimkan permintaan (request) ke billing system dua kali yaitu:

  1. Charging reserve request.
    Transaksi pembayaran yang bertujuan untuk memverifikasi apakan pelanggan memiliki balance yang cukup untuk kemudian di reserve. Jika balance yang dimiliki pelanggan cukup, billing system akan menjawab dengan positive acknowledge dan identifikasi transaksi (transaction ID) untuk kemudian service node melanjutkan proses layanannya.

    Transaction ID digunakan untuk melakukan langkah berikutnya. Jika balance tidak cukup, billing system akan menjawab dengan negative acknowledge dan service node menggagalkan proses layanannya dan berhenti melakukan transaksi.

  2. Charing commit/release request.
    Transaksi ini memberitahukan billing system untuk melakukan commit terhadap transaksi sebelumnya jika layanan yang dilakukan service node berhasil atau memberitahukan untuk merilis (mengagalkan) transaksi sebelumnya jika layanan yang dilakukan service node gagal atau terjadi masalah (error).


-> One step billing scenario

Charging terhadap pelanggan dilakukan dengan mengirimkan informasi harga yang harus diambil dari kredit atau ditambahkan pada tagihan ke billing sistem. Response dari

billing system yang menunjukan ya (acknowledge) atau tidak (negative acknowledge) akan menentukan apakah layanan akan dilanjutkan atau tidak jadi diberikan.

Skenario charging ini lebih efisien karena transaksi lebih sedikit, tetapi skenario ini tidak dapat menggantikan skenario dua langkah karena untuk beberapa layanan,

transaksi dua langkah lebih cocok digunakan misalnya untuk layanan yang bisa dibatalkan ditengah jalan.

USSD

USSD (Unstructured Supplementary Service Data) adalah proses atau teknologi untuk pertukaraninformasi teks antara sebuah telepon bergerak dan aplikasi pada jaringan operator. Teknologi USSD pertama kali dibuat untuk jaringan GSM dan kemudian tetap digunakan pada jaringan 3G/UMTS.

Sebuah kode akses USSD atau USSD message dari ponsel adalah digit yang diawali dengan tanda * dan diakhiri dengan tanda #. Setiap parameter dibatasi oleh tanda *.
Contoh-contoh USSD message yang dikirimkan ponsel ke jaringan operator:

*123#
*123*1*9789732404229650#

Respon yang didapat oleh pengguna dapat berupa:
  • informasi atau notifikasi yang tidak perlu jawaban, misalnya informasi jumlah tagihan (billing)
  • informasi atau pilihan yang berupa menu yang meminta jawaban dari pengguna.

Jika pengguna mendapatkan respon yang meminta jawaban dan tidak menjawab selama beberapa saat maka jaringan operator akan menutup sesi dialog tersebut.

Awalnya, USSD didesain untuk mempermudah interaksi antara ponsel pelanggan dengan operator jaringan dalam menggunakan supplementary service. Supplementary service adalah layanan tambahan seperti call waiting, call barring, dan lain-lain. untuk mengaktifkan, menghapus atau melakukan setting pada layananan tersebut, pelanggan dapat melakukannya dengan cara menekan tombol kode akses pada ponsel dan mengirimkannya dengan menekan tombol panggilan. Biasanya suatu ponsel telah memiliki menu untuk settingsupplementary service sehingga kita tidak perlu menghafalkan kode-kode akses tersebut. Dibalik layar, ketika kita mengakses menu tersebut, ponsel akan mengirimkan USSD message ke jaringan operator.

Input kode akses dari user yang akan dikirimkan sebagai USSD message dispesifikasikan pada standar GSM 02.30 atau 3GPP TS 22.030, yang berjudul "Man-machine Interface (MMI) of the Mobile Station (MS)"

Beberapa fakta mengenai USSD:

- USSD merupakan session oriented artinya selama dialog berlangsung switching akan mendedikasikan sebuah bearer.
- WAP, SIM Toolkit dapat menggunakan USSD sebagai bearer
- USSD disupport mulai CAMEL phase 2
- Mudah diakses, hanya perlu menekan nomor (kode akses)
- USSD dapat mengirimkan informasi teks sampai 182 karakter

USSD memiliki 2 mode transaksi yaitu:

1. Pull mode atau mobile-initiated yaitu interaksi yang dimulai (inisialisasi) dari ponsel pengguna
2. Push mode atau network-initiated yaitu interaksi yang dimulai (inisialisasi) dari aplikasi yang berada di jaringan operator


USSD dispesifikasikan pada standar GSM 02.90 (USSD Stage 1), GSM 03.90 (USSD Stage 2), 04.90 atau 3GPP TS 22.090 (USSD Stage 1) 23.090 (USSD State 2) 24.099 (USSD Stage 3).

USSD Phase 1 hanya support mobile-initiated operation artinya pengguna ponsel hanya bisa mengirimkan suatu perintah USSD untuk kemudian direspon oleh jaringan operator.

Komunikasi hanya terjadi sekali (satu kali permintaan dan satu kali jawaban).

Pada USSD Phase 2, dialog dapat terjadi antara ponsel dan jaringan operator sehingga pertukaran informasi (request dan response) dapat terjadi beberapa kali. Informasi juga dapat diinisialisasi dari jaringan operator (network-initiated)

Pada jaringan operator transfer informasi dari sebuah pesan USSD antar elemen dilakukan menggunakan SS7 signaling yaitu MAP (Mobile Application Part). Proses pengiriman

informasi untuk mobile-initiated USSD adalah sebagai berikut:

1. Ponsel pelanggan menggirimkan informasi digit ke MSC jaringan operator.
2. MSC mengirimkan informasi tersebut ke HLR.
3. Kemudian HLR meproses informasi tersebut atau mengirimkan ke USSD gateway.
4. USSD gateway kemudian mengirimkan informasi ke sebuah aplikasi
5. Aplikasi memberikan respon ke USSD gateway
6. USSD gateway mengirimkan response ke HLR
7-8. HLR kemudian mengirimkan response ke pelanggan lewat MSC.



.-------. .-------. .------------. .----------.
---1---> | |---2---> | | ---3---> | | ---4---> | |
Ponsel <---8--- | MSC |<---7--- | HLR | <---6--- |USSD gateway| <---5--- | Aplikasi |
| | | | | | | |
'-------' '-------' '------------' '----------'



Komponen aplikasi pada arsitektur diatas bisa berupa aplikasi apasaja, misalnya billing system, content management system (CMS) atau aplikasi di content provider yang berada di luar jaringan operator.

USSD Gateway berfungsi sebagai penghubung antara aplikasi dengan jaringan inti telekomunikasi (core network). USSD gateway tidak dispesifikasikan pada dokumen GSM/3GPP tapi biasanya elemen ini hampir selalu ada untuk mempermudah komunikasi yang dilakukan aplikasi. Konunikasi antar USSD gateway dengan aplikasi biasanya berbasis TCP/IP misalnya

menggunakan HTTP. Jadi USSD gateway menjembatani jaringan IP (packet based) dengan jaringan jaringan SS7 (circuit based) sehingga operator jaringan dapat membuat layanan tambahan (value added service) dengan mudah.



MAP sebagai pendukung transaksi USSD yang menghubungkan MSC dengan HLR dan HLR dengan USSD gateway menspesifikasikan beberapa operasi (command) untuk mengirimkan USSD message.

Pada GSM 09.02 (MAP Phase 1) hanya ada satu operasi yang berhubungan dengan USSD:

  • MAP_PROCESS_UNSTRUCTURED_SS_DATA
    Perintah ini membawa informasi dari ponsel pelanggan (mobile-initiated), dikirimkan MSC ke HLR atau dari HLR ke USSD gateway untuk meminta informasi.

Pada GSM 09.02 (MAP Phase 2 dan phase 2+) terdapat tambahan 2 operasi untuk USSD yaitu:

  • MAP_UNSTRUCTURED_SS_REQUEST
    Perintah ini dikirimkan dari USSD gateway ke HLR atau dari HLR ke MSC untuk diteruskan ke pelanggan.
    Perintah ini diinisialiasi oleh operator (network-initiated) dan digunakan untuk meminta informasi dari pelanggan.
  • MAP_UNSTRUCTURED_SS_NOTIFY
    Perintah ini dikirimkan dari USSD gateway ke HLR atau dari HLR ke MSC untuk diteruskan ke pelanggan.
    Perintah ini merupakan network-initiated, digunakan untuk memberikan informasi dari pelanggan.

Monday, October 22, 2007

Proteksi mobile content dengan OMA DRM

Kebutuhan proteksi terhadap content

Mobile content seperti musik, video, games, wallpaper, saat ini telah menjadi barang yang hampir selalu ada di setiap ponsel. Mobile content yang ada dalam ponsel biasanya didapatkan pengguna dengan cara transfer dari suatu media misalnya CD ke dalam ponsel atau dengan membeli (download) dari content provider.

Bisnis mobile content yang berkembang pesat dan mahalnya harga content mendorong adanya pembajakan. Pembajakan pada mobile content biasanya terjadi dengan cara menduplikasikan content dari satu ponsel ke ponsel lain. Untuk menghindari pembajakan maka diperlukan adanya mekanisme proteksi terhadap content.

Dengan adanya mekanisme proteksi terhadap content maka pencipta, pemilik atau penjual content akan dapat melindungi contentnya dan memperoleh keuntungan yang lebih besar. Mekanisme untuk melindungi hak pada suatu content biasa disebut manajemen hak digital atau Digital Right Management (DRM).

Mekanisme proteksi tidak hanya memproteksi content hanya dari penduplikasian content saja. Lebih dari itu dengan proteksi yang ada sekarang telah dapat membatasi pengguna (user) untuk menjalankan atau melihat content. Dengan standar proteksi OMA DRM, pemilik content dapat membatasi akses terhadap content seperti misalnya hanya dapat dilihat beberapa kali saja atau content dapat memiliki waktu kadaluarsa.

Elemen-elemen dan mekanisme DRM
Elemen yang telibat dalam mekanisme DRM diantaranya:

  • DRM content adalah content atau objek media yang diproteksi atau didefinisikan haknya.
  • Right object adalah suatu hak tertentu
  • Right issuer adalah subjek yang mendefinisikan hak-hak subscriber pada suatu DRM content. Right issuer biasanya adalah penyedia konten (content provider) atau operator telekomunikasi (carrier)
  • DRM agent adalah aplikasi di sisi pengguna misalnya ponsel yang memastikan hak-hak objek media tidak terlanggar.

Secara garis besar mekanisme DRM yang umum dapat digambarkan sebagai berikut:

[Right issuer]
|
| ,----------------------.
mendefinisikan | | ,--------------------------.
| | [Objek media/Konten] | | Download server/ | ,----------------.
| | |--->| Content Managemen System |--->| DRM Agent/User |
+------------>[Hak-hak (Rights)] | | (CMS) | `----------------'
| | `--------------------------'
`----------------------'


  1. Right issuer mendifinisikan hak-hak suau konten untuk kemudian diasosiasikan dengan konten dengan cara tertentu
  2. Kemudian konten beserta metadata yang mendefinikan hak dari konten tersebut dipublikasikan pada sebuah download server
  3. Pengguna kemudian dapat mengambil kontent dari download server. DRM agent memastikan bahwa metadata yang mendefinisikan hak dari konten juga ter-download dan membatasi hak yang bisa pengguna lakukan pada konten tersebut.
  4. Setiap kali pengguna akan melakukan sesuatu pada kontent misalnya mengirimkan lewat bluetooth atau MMS, DRM agent akan mengecek pada metadata hak apakah aksi dari pengguna diperbolehkan atau tidak.

OMA DRM

OMA DRM adalah standar industri yang digunakan luas untuk keperluan proteksi content. OMA DRM merupakan spesifikasi untuk digital right management khususnya konten untuk perangkat bergerak (mobile content). Digital right management adalah manajemen proteksi hak pada suatu content digital sehingga pendistribusian dan penggunaannya dapat terkontrol.

OMA DRM dibuat oleh Open Mobile Alliance (OMA) yang merupakan aliansi dari beberapa perusahaan. Spesifikasi DRM, pertama kali yang dibuat OMA adalah versi 1.0 yang terdiri dari tiga dokumen spesifikasi teknis yaitu

  1. Dokumen spesifikasi DRM, merupakan dokumen utama yang menjelaskan bagaimana DRM berkerja dan astitektur sistem secara keseluruhan.
  2. Dokumen 'DRM Content Format' (DCF) yang berisi penjelasan format content dari suatu objek konten terenkripsi yang diproteksi oleh DRM serta metadatanya, fungsionalitas hak-hak terhadap content.

OMA DRM versi 1.0 mendefiniskan 3 metode

1. OMA forward-lock

Mekanisme ini adalah yang paling sederhana untuk memproteksi konten. Dengan forward-lock, konten yang telah ada di suatu perangkat tidak dapat ditransfer ke perangkat yang lain. Pendistribusian kontent dengan forward-lock ditandai dengan MIME type "application/vnd.oma.drm.message", dibawah ini contoh HTTP reponse dari download server ketika mengirimkan content dengan OMA forward-lock.

HTTP/1.1 200 OK
Content-type: application/vnd.oma.drm.message; boundary=boundary-XXX
Content-Length: 574

--boundary-XXX
Content-Type: image/jpeg
Content-Transfer-Encoding: binary

[File gambar.jpg disini]
--boundary-XXX--


2. Combined delivery

Mekanisme ini mirip dengan forward-lock, akan tetapi hak-hak akses lain dapat ditambahkan selain pelarangan tranfer ke perangkat lain. Contoh hak akses lain misalnya content hanya dapat dimainkan (play) sekali dan hanya dapat digunakan dalam waktu satu minggu. Pengiriman konten dengan mekanisme ini ditandai dengan MIME type "application/vnd.oma.drm.message". Selain konten, pengiriman ini juga mengirimkan metadata berformat teks XMLyang menspesifikasikan hak-hak pada content.


HTTP/1.1 200 OK
Content-type: application/vnd.oma.drm.message; boundary=boundary-XXX
Content-Length: 893

--boundary-XXX
Content-type: application/vnd.oma.drm.rights+xml
Content-Transfer-Encoding: binary

<o-ex:rights
xmlns:o-ex="http://odrl.net/1.1/ODRL-EX"
xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#/">
<o-ex:context>
<o-dd:version>1.0</o-dd:version>
</o-ex:context>
<o-ex:agreement>
<o-ex:asset>
<o-ex:context>
<o-dd:uid>cid:gambar.jpg</o-dd:uid>
</o-ex:context>
</o-ex:asset>
<o-ex:permission>
<o-dd:display>
<o-ex:constraint>
<o-dd:count>3</o-dd:count>
</o-ex:constraint>
</o-dd:display>
</o-ex:permission>
</o-ex:agreement>
</o-ex:rights>

--boundary-XXX
Content-type: image/jpeg
Content-ID: <gambar.jpg>
Content-Transfer-Encoding: binary

[File gambar.jpg disini]
--boundary-XXX--


3. Separate delivery

Mekanisme ini menambahkan proteksi keamanan pada konten dengan cara mengenkripsi content. Hak-hak yang ada pada content didefinisikan pada file terpisah dan dikirim terpisah. Dengan adanya cara ini memungkinkan konten untuk diditribusikan ke peringkat lain yang tidak memiliki lisensi (right object) kemudian perangkat tersebut dapat meminta lisensi untuk dapat melihat preview atau membelinya. Mekanisme distribusi tersebut sangat menguntungkan pemilik content karena pemilik konten dapat mendistribusikan ke orang lain untuk kemudian orang lain memebeli atau mendistribusikannya lagi. Proses distribusi dari satu pengguna ke pengguna lain seperti itu disebut superdistribution.

Kontent yang dikirim dengan mekanisme separate delivery harus berupa DRM content format (DCF) yaitu konten yang dienkripsi sesuai dokumen spesifikasi DRM Content Format yang termasuk dalam spesifikasi OMA DRM. Dengan format ini, konten dapat dengan bebas ditransfer ke siapa saja lewat jalur yang tidak aman tetapi untuk menakses konten sesorang memerlukan Content Encryption Key (CEK) yang bisa didapatkan dari Right issuer. Contoh pengiriman content DCF lewat HTTP:

HTTP/1.1 200 OK
Content-type: application/vnd.oma.drm.content;
Content-Length: 1234
X-Oma-Drm-Separate-Delivery: 12

[DRM content dalam format DCF]


Pada contoh diatas, header "X-Oma-Drm-Separate-Delivery" menunjukan berapa lama (dalam detik), DRM agent harus telah mendapatkan right object yang didefinisikan dalam WAP push.

Right object yang menyertai kontent dikirim terpisah dengan menggunakan WAP-push setelah konten selesai didownload. WAP-push yang dikirim berisi right object dalam format REL (Rights Expression Language) yang juga ada dalam bundel spesifikasi OMA DRM. REL ditulis dalam bentuk XML dan dikirimkan lewat WAP-push bentuk WAP binary XML (WBXML). Contoh PAP dari WAP-push yang dikirim sebagai berikut:


<?xml version="1.0"?>
<!DOCTYPE pap PUBLIC "-//WAPFORUM//DTD PAP 1.0//EN"\n "http://www.wapforum.org/DTD/pap_1.0.dtd" >
<pap>
<push-message push-id="Content123456789123456789"
source-reference="VASProviderABC"
progress-notes-requested="false">
<address address-value="WAPPUSH=62123456789/TYPE=PLMN@ppg"/>
<quality-of-service priority="low" delivery-method="notspecified"/>
</push-message>
</pap>
--multipart-boundary
Content-Type: application/vnd.oma.drm.rights+wbxml
X-Wap-Application-Id: x-wap-application:drm.ua

[Right object format REL]
--multipart-boundary--


OMA DRM versi 2

OMA DRM versi 2 juga terdiri dari 3 dokumen spesifikasi teksnis. Perbedaan utama OMA DRM 1.0 dengan OMA DRM 2.0 adalah adanya perbaikan atau penambahan pada funsionalitas dan keamanan (security). Perbaikan pada sistem keamanan dicapai dengan penyediaan mekanisme otorisasi bilateral antara pihak yang mendefinisikan hak (rights issuer) dengan perangkat.

Penambahan fungsionalitas pada versi 2 misalnya adanya fungsi preview (test-drive), mekanisme berbagi content dalam suatu komunitas atau domain, kemampuan perangkat yang tidak terkoneksi untuk dapat menkonsumsi DRM content dan kemampuan untuk memproteksi konten streaming dengan mengunakan format PDCF (Packetize DCF). Pada DRM versi 2 juga diperkenalkan Rights Object Acquisition Protocol (ROAP) yang merupakan protokol antara Rights issuer dengan DRM agent.

Spesifikasi OMA

Memahami standar, spesifikasi, aturan atau regulasi sangat penting dalam mempelajari telekomunikasi. Di sini saya akan mebahas satu persatu bagaimana proses spesifikasi atau standarisasi dibuat, terutama proses rilis (release) atau versioning dari dokumen yang dipublikasikan. Hal ini penting agar kita selalu mengacu pada versi dokumen yang benar. Mengacu pada dokumen yang berbeda versi bisa berakibat fatal.

OMA (Open Mobile Alliance) memiliki beberapa jenis dokumen yaitu:

  • Requirement Document
  • Technical specification/material yang berjenis
    • Enabler Release
    • Reference Release
  • Test specification dan Validation Plan Document

Yang paling penting untuk dijadikan referensi adalah dokumen Enabler release.

Dokumen spesifikasi yang dikeluarkan OMA memiliki format versioning seperti standar software "x.y.z" misalnya OMA MMS versi 1.1, versi 1.2 atau versi 1.3.

Setiap dokumen OMA melewati dua fase rilis yaitu

  • Phase 1 (Candidate release). Semua spesifikasi OMA yang dipublikasikan, awalnya berada pada phase ini yaitu approved dan bisa diimplementasikan pada produk atau solusi untuk dapat dilakukan interoperability test.

  • Phase 2 (Approved Release) yaitu release yang telah melewati komentar publik serta validari interoperability.

Penjelasan ini bersumber pada halaman OMA release program, di halaman tersebut juga bisa diliat semua versi dan posisi phase untuk seriap versi dari semua set spesifikasi (Enabler).

Mobile CMS

CMS (Content Management System) identik dengan system yang digunakan untuk mengelola kontent web yang biasanya berupa halaman html (teks & gambar).

Operator telekomunikasi atau content provider saat ini biasanya memiliki apa yang disebut Mobile Content Management System, yaitu CMS untuk mengelola konten perangkat bergerak yang dijual kepada pelanggannya. Konten yang dimaksud misalnya:

- Gambar atau Wallpaper
- Nada dering (ringtone)
- Kontent teks seperti berita, ramalan, pesan bijak
- Nokia smart messaging (Operator logo, gambar, ringtone)
- Games
- Rekaman video (recorded)
- Live video/TV
- Audio/video ring back tone (Nada sambung pribadi)
- Multimedia presentation (SMIL)
- Theme

Karena banyaknya jenis konten yang disediakan maka CMS ini lebih kompleks dari CMS biasa.

Apa yang spesifik atau yang membedakan antara CMS untuk sebuah website dengan CMS untuk mobile content? Dibawah ini adalah daftar karakteristik atau fitur yang dimiliki Mobile-CMS tapi biasanya tidak terdapat pada web-CMS:

  • Jenis kontennya lebih beragam
  • Konten dijual, berarti memiliki harga dan melibatkan proses pembayaran (charging) sehingga memerlukan integrasi dengan billing system
  • Konten tidak diperuntukan untuk semua jenis perangkat sehingga perlu manajemen perangkat agar dipastikan pelanggan yang membeli konten dapat menikmati konten yang dibelinya.
  • Akses untuk mendapatkan kontent beragam misalnya melalui situs WAP/WEB, SMS, USSD, IVR, STK
  • Kanal pengiriman (delivery channel) beragam bisa lewat SMS, MMS, wap push
  • Karena dua poin diatas, biasanya mobile-CMS juga berfungsi sebagai content delivery system (CDS) yang berfungsi untuk mengirimkan konten lewat beragam layanan.
  • Perlu integrasi dengan network elemen lain seperti SMSC, MMSC untuk pengiriman konten
  • Karena dijual jadi kadang perlu dilengkapi dengan fitur promosi misalnya diskon, broadcast, content bundling, quiz, limited time frame free, recommended contents (top contents), pin based draw (pengundian), syembara untuk membuat dan mengirimkan kontent
  • Perlu integrasi dengan streaming server untuk dapat mengirimkan konten seperti video, online TV
  • Perlu adanya modul untuk customer care
  • Reporting atua statisktik yang diperlukan yang lebih kompleks
  • Perlu adanya database pelanggan termasuk didalamnya mungkin data jenis/tipe perangkat atau ponsel yang digunakan pelanggan
  • Karena konten tidak gratis dan rawan pembajakan maka diperlukan proteksi (DRM) terhadap konten dari pengkopian ilegal
  • Konten biasanya berasal dari beberapa content provider sehingga diperlukan mekanisme pembagian keuntungan (revenue sharing)
  • Perlu deskripsi yang jelas untuk setiap konten karena pelanggan tidak dapat langung menikmati konten. Fitur preview biasanya diperlukan untuk memperjelas seperti apa konten yang bisa didapatkan oleh pembelinya.
  • Adanya layanan berlangganan (Subcription) dengan pengiriman terjadwal (scheduled/automatic delivery)

Tuesday, October 09, 2007

Provisioning

Jika Anda bekerja di bidang telekomunikasi terutama yang berhubungan dengan system yang memiliki data pelanggan (subscriber) tentu akan mendengar istilah subscriber provisioning. Kalau saya lihat di kamus bahasa Inggris, provisioning berarti "the activity of supplying or providing something."

Istilah provisioning sering digunakan sebagai istilah teknis yang menunjukan proses penyediaan suatu layanan. Dalam hal subscriber provisioning, penyedian service biasanya dicapai dengan penyedian data subscriber pada sebuah system sehingga subscriber dapat menggunakan layanan yang disediakan oleh sistem tersebut. Jadi provisioning berhubungan penyediaan sesuatu sebagai persiapan agar suatu sistem atau layanan dapat digunakan.

Istilah provisioning dalam telekomunikasi, tidak hanya berkaitan dengan subscriber, tetapi bisa entitas lain misalnya service, produk, content provider, perangkat bergerak (ponsel), konten yang dapat digunakan oleh pelanggan di ponselnya dan lain-lain.

Karena banyak sekali layanan yang dapat diberikan suatu operator telekomunikasi, maka biasanya suatu layanan memiliki standar proses provisioning atau proses provisioning yang umum sehingga memudahkan operator telekomunikasi dan juga pelanggannya. Misalnya layanan GPRS, yang proses provisioningnya biasanya menggunakan OTA (Over-the-air) yaitu operator mengirimkan setting untuk GPRS ke ponsel pelanggan untuk kemudian bisa disimpan sehigga layanan GPRS bisa langsung digunakan.

Proses provisioning dapat berupa
  • general provisioning yaitu membuat layanan tersedia untuk semua pelanggan oleh penyedia layanan tanpa perlu menunggu
  • pre-arranged provisioning yaitu membuat layanan tersedia untuk seorang pelanggan (individual) jika kondisi tertentu terpenuhi misalnya layanan diminta oleh pelanggan.
Proses provisioning pelanggan dan service yang paling dasar di operator telekomunikasi adalah provisioning di network elements yaitu HLR dan IN. Sebelum sebuah sim card dijual dan bisa dipergunakan, data pelanggan seperti IMSI, MSIDN, dan konfigurasi layanan dasar seperti panggilan telepon (voice call), SMS, GPRS dan lain-lain perlu di-provision di kedua network elemen tersebut. Proses yang dilakukan biasanya secara masal karena nomor yang akan dijual banyak dan tidak ada data spesifik pelanggan.

Convergent Billing

Istilah corvergent billing atau converged billing sering digunakan sebagai istilah dalam tekomunikasi saat ini terutama pada bidang telekomunikasi nirkabel (wireless). Istilah ini menjadi tren marketing sehingga maksud sebenarnya menjadi bias.

Convergent menurut saya dapat diterjemahkan menjadi memusat atau memfokus. Dalam bahasa inggris istilah ini dijelaskan sebagai "tending to come together from different directions." Jadi secara harfiah convergent billing bisa diartikan billing terpusat.

Entah bagaimana sejarahnya kata convergent ini jadi begitu populer tapi yang jelas kalau kita lihat sekarang, hampir semua billing system yang digunakan saat ini adalah sistem yang terpusat artinya hanya sebuah billing sistem yang digunakan untuk melayani semua layanan (service) baik itu layanan suara (voice), data,SMS, GPRS, VAS content dan lain-lain. Istilah convergent billing juga sering digunakan untuk menunjukan bahwa proses billing untuk layanan pelanggan prabayar dan pascabayar dilakukan pada satu system.

Convergent billing berarti billing yang berfokus pada customer dalam hal ini pelanggan layanan telekomunikasi dan bukan berfokus pada masing-masing layanan yang diberikan. Ini berarti setiap customer memiliki sebuah data pembayaran yang komprehensif dalam satu sistem sehingga memudahkan customer care dalam melayani pelanggannya. Biasanya convergent billing system memiliki antar muka untuk customer care yang menjadi alat utama saat melayani keluhan pelanggan dan bahkan produk billing system ini biasanya dilengkapi dengan customer relationship management (CRM).

Pendaftaran layanan (service provisioning) untuk customer akan menjadi lebih mudah dengan adanya convergent billing, yaitu dengan memiliki sebuah (single point) service provisioning pada billing system untuk semua service. Hal ini dapat dicapai dengan mendaftarkan pelanggan pada semua elemen service sehingga pada dasarnya setiap pelanggan dapat menggunakan layanan yang tersedia pada operator tetapi penggunaan layanan dikontrol secara realtime ketika data tagihan (charging record) dikirim ke billing system. Cara ini dapat dilakukan dengan asumsi bahwa convergent billing system adalah biling system modern yang menangani customer prabayar dan customer pascabayar dengan cara yang sama yaitu realtime charging. Single point service provisioning juga baik dilakukan jika aspek negatif diabaikan seperti pembebanan jaringan dan begitu besarnya lisensi dari produk suatu service element karena harus menyimpan semua data pelanggan sejak awal.

Keuntungan lain dengan adanya convergent billing adalah fleksibilitas pendefinisian mekanisme pembayaran. Operator dapat dengan fleksibel melakukan kalkulasi harga pada setiap layanan atau kalkulasi yang melibatkan beberapa layanan. Hal ini penting bagi operator untuk dapat bersaing dengan melukan promosi atau diskon pada layanan yang diberikannya.

Secara teknis pemusatan pada satu sistem billing berarti integrasi antara beberapa elemen layanan (service element) menuju sebuah elemen yang berujung pada sistem billing. Karena service element seperti MSC, SGSN/GGSN, SMSC, MMSC dan lain-lain memiliki format rekaman tagihan dan juga protokol tersendiri untuk mengirimkannya ke billing system maka convergent billing system harus mampu beradaptasi terhadap semua perbedaan tersebut. Jika fitur adaptasi tidak dimiliki billing system, maka paling tidak adaptasi harus dilakukan pada elemen lain di depan billing system.

Biasaya billing system tidak memiliki antar muka untuk dapat melayani semua elemen dan operator tidak mau mengeluarkan effort yang banyak dengan membuat lapisan adaptasi pada setiap elemen. Oleh karena itu, dalam arsitektur convergent billing biasanya ada elemen lain yang disebut mediation device atau charging gateway yang berfungsi untuk mengadaptasi baik data tagihan maupun protokol antara service element dengan billing system. Arsitektur dan aliran data tagihan digambarkan dibawah ini


,-------------. ,----------------.
service element -------->| | | |
+----->| Mediation |=========>| Billing system |
service element --' +--->| | | |
| `-------------' `----------------'
service element ----'

  • Beberapa produsen produk convergent billing system yang digunakan oleh operator di Indonesia diantaranya adalah:

    Amdocs dipakai Excelcomindo
  • Convergys, produknya bernama IRB atau Geneva dipakai Telkomsel, Indosat, HCPT Indonesia
  • Comverse, dipakai NTS, mobile8
  • Redknee, dipakai Bakrie Telecom

Friday, October 05, 2007

Regulasi telekomunikasi

Teknologi tidak terlepas dari bisnis dan bisnis tidak terlepas dari regulasi. Pada teknologi telekomunikasi regulasi dapat meliputi beberapa aspek misalnya standarisasi teknis, pengalokasian spektrum frekuensi dan lain-lain.

Di Indonesia regulasi telekomunikasi diurus oleh sebuah badan bernama BRTI (Badan Regulasi Telekomunikasi Indonesia). Badan ini dibentuk pemerintah jadi pada intinya regulasi telekomukasi Indonesia masih diatur oleh pemerintah oleh karena itu regulasi di Indonesia bukan hanya menjadi masalah bisnis dan teknis tapi bisa menyangkut politis.

Badan yang berperan pada regulasi telekomunikasi:


Dokumen-dokumen yang berkaitan dengan regulasi telekomunikasi seperti peraturan pemerintah (PP), keputusan menteri, dan lain-lain dapat dilihat di website tersebut.

Thursday, October 04, 2007

Proses Penerimaan MMS

Dibawah ini saya jelaskan bagaimana proses suatu MMS diterima pada sebuah ponsel dari jaringan operator.

MMSC sebagai elemen yang menerima MMS dari subscriber akan mengirimkan notifikasi (MMS notification) kepada ponsel tujuan. Notifikasi MMS yang memberitahukan ponsel bahwa subscriber mendapat kiriman MMS diterima ponsel dalam bentuk WAP-push yang dikirim lewat SMS bearer. WAP-push indikator tersebut memiliki header content type yang berisi "application/vnd.wap.mms-message" dan header X-Wap-Application-Id yang berisi "x-wap-application:mms.ua". Dari header tersebut ponsel tau bahwa WAP push tersebut adalah MMS notification indicator dan harus diproses oleh MMS agent. MMS agent kemudian memproses notification tersebut yaitu meresponse untuk memberitahu MMSC bahwa notification indicator telah diterima kemudian melakukan request (WSP/HTPP GET) ke MMSC untuk mendownload content dari MMS.

Sebuah MMS notification indicator membawa informasi diantaranya:

  • Nomor versi MMS
  • Alamat pengirim MMS
  • Subject dari MMS
  • Deliveri report status yang menunjukan pengirim membutuhkan staus delivery report atau tidak
  • MMS message class, yang menunjukan prioritas pengiriman
  • Ukuran MMS
  • Waktu kadaluarsa (expiry) dari MMS
  • Lokasi MMS content yaitu alamat untuk mengambil isi dari MMS

Informasi tersebut dispesifikasikan pada dokumen spesifikasi OMA yang berjudul "Multimedia Messaging Service Encapsulation Protocol" dan juga spesifikasi 3GPP TS 23.140 (Multimedia Messaging Service (MMS); Functional description) pada bagian yang membahas tentang MM1 interface. MM1 interface adalah interface yang menhubungkan antara MMSC dengan ponsel.

Dalam spesifikasi OMA, notifikasi MMS disebut M-Notification.ind dan serponsenya disebut M-NotifyResp.ind. Sedangkan pada MM1 interface, notifikasi MMS disebut MM1_notification.REQ dan responnya disebut MM1_notification.RES

Sebuah ponsel biasanya memiliki setting untuk penerimaan MMS yaitu

- Cara penerimaan yang menentukan apakah MMS client/agent akan otomatis mengambil MMS content setelah mendapat MMS notifikasi
- APN (Access Point Name) yang merupakan setting GPRS bearer agar MMS content dapat dikirim dari ponsel ke MMSC atau diambil dari MMSC

Pada kasus pengambilan MMS langsung (otomatis) proses pengambilan digambarkan sbb:


ponsel MMS Proxy-Relay (MMSC)
------ ----------------------
| |
|<-- M-Notification.ind / MM1_notification.REQ ---|
| |
|--- M-NotifyResp.ind / MM1_notification.RES ---->|
| |
|----- MM1_retrieve.REQ (WAP/HTTP GET) ---------->|
| |
|<---- MM1_retrieve.RES / M-retrieve.conf --------|
| |
|-- M-NotifyResp.ind / MM1_acknowledgement.REQ -->|
| |
| |
| |

Monday, October 01, 2007

Mengenal IN (Intelligent Network)

IN adalah istilah yang biasa digunakan dalam dunia telekomunikasi untuk mendeskripsikan suatu fungsionalitas dalam jaringan telekomunikasi yang bersifat intelligent.
Intelligent disini dapat berarti terkontrol walaupun tidak bersifat 'pintar' seperti istilah intelligent control yang digunakan di dunia kontrol industri.

Arsitektur IN pada jaringan sentral (core network) telekomunikasi memisahkan antara fungsi switching dan pengaturan logic. Dalam jaringan sentral GSM atau CDMA, IN biasanya diasosiasikan dengan sebuah elemen yang mengatur jalannya end user service seperti call control, SMS, GPRS, USSD dan lain-lain. Elemen tersebut biasanya adalah sebuah mesin (server) yang berdiri sendiri yang dihubungkan dengan MSC (Mobile Switching Center). Operator menggunakan elemen IN untuk mendefinisikan setiap logika pengontrolan dari sebuah service.

Sebelum MSC memproses sebuah service digunakan oleh user, misalnya layanan pemanggilan (call), MSC akan menghubungi elemen IN untuk menayakan bagaimana service itu akan ditangani. Elemen IN kemudian akan menganilis service berdasarkan logic yang telah didefinisikan, kemudian memberikan hasil eksekusi logic tersebut ke MSC. Contoh hasil eksekusi misalnya "lanjutkan pemanggilan" atau "putuskan pemanggilan" (reject call) atau "lanjutkan pemanggilan dan beritahu IN untuk keputusan berikutnya setiap satu menit".

Dengan adanya IN maka service yang diberikan oleh operator menjadi beragam karena adanya fasilitas analisa untuk pengambilan keputusan pada jalannya suatu service.
IN juga membuat operator mudah untuk mengubah suatu logic service. Hal ini sangat berguna bagi operator untuk melakukan suatu promosi.

Contoh promosi yang bisa diimplementasikan pada IN adalah close user group (CUG) untuk pemanggilan yaitu fasilitas yang mengatur logic untuk sebuah kelompok nomor. Promosi ini biasa disebut "friend and family" dimana anda dapat mendefinisikan beberapa nomor-nomor teman atau keluarga anda sehingga setiap anda melakukan panggilan pada nomor tersebut anda mendapatkan potongan harga. Beberapa fasilitas seperti CUG, call forwarding dan lain-lain telah distandarisasi atau didefinisikan dalam suatu arsitektur network misalnya dalam standar GSM yaitu CAMEL (Customized Application for Mobile network Enhanched Logic) atau dalam standar CDMAOne/CDMA200/IS yaitu WIN (Wireless Intelligent Network) atau standar ITU yaitu CS (Capability Set).

Karena fungsinya sebagai pengontrol, maka elemen IN biasa disebut Service Control Point (SCP) dan fungsinya biasa disebut Service Control Function (SCF).
Selain SCF beberapa fungsi lainnya diantaranya adalah:

  • Service Data Function (SDF)
    SDF menyimpan data Subscriber dan network yang diperlukan oleh SCF pada eksekusi service.
  • Service Resource Function (SRF)
    SRF menyediakan specialized resources yang dibutuhkan ketika eksekusi service pada SCF misalnya penerima digit, yang melakukan play announcement, dan lain-lain.
  • Service Management Function (SMF)
    SMF memberikan fungsi provision, deployment dan support
  • Service Management Access Function (SMAC)
    SMAC merupakan fungsi interface bagi user untuk mengakses SMF
  • Service Creation Environtment Function (SCEF)
    SCEF memberikan fungsionalitas untuk mendefiniskan, menbuat (develop) dan melakukan test suatu service.


Sejarah IN




Sebelum adanya konsep IN, sebuah telecommunication switching (exchange) melakukan semua proses yang diperlukan dalam memberikan layanan terhadap pengguna telekomunikasi. Fungsi call-processing, service data dan service logic terdapat pada switch sehingga sering disebut monolithic platform.

Konsep IN pertama kali diperkenalkan oleh Telcordia (atau Bellcore) yaitu advanced intelligent networks (AIN) pada tahun 1980. Pada awalnya Bellcore membuat konsep AIN untuk mempermudah pengelolaan dan deployment dari suatu service baru di sebuah oprerator cabang yang berada di daerah dengan cara membuat suatu elemen pengontrol (service control logic) yang terpusat. Telcordia mengawali IN dengan versi pertamanya yaitu IN/1 kemudian dalam beberapa tahun merilis seri spesifikasi yaitu AIN 0, AIN 0.1, AIN 0.2

Spesifikasi AIN 0.1:
  • TR-NWT-001284, Advanced Intelligent Network (AIN) 0.1 Switching Systems Generic Requirements
  • TR-NWT-001285, Advanced Intelligent Network (AIN) 0.1 Switch-Service Control Point (SCP Application Protocol Interface Generic Requirements)

Spesifikasi AIN 0.2:
  • GR-1298-CORE, AINGR: Switching Systems
  • GR-1299-CORE, AINGR: Switch-service Control Point (SCP)/Adjunct

Sekitar tahun 1990, setelah Telcordia mempublikasikan AIN 0.1, Organisasi internasional ITU kemudian membuat standar IN dengan yang berbasis pada AIN. Pada tahun 1993, akhirnya ITU mempublikasikan standard IN pada dokumen seri ITU Q.1200 dan sampai saat ini standar tersebut menjadi dasar hampir semua teknologi IN sekarang.

Standard IN yang dispesifikasikan ITU selalu diperbarui terus menerus sehingga dibuatlah versi yang menunjukan sebuah rilis yaitu yang disebut capability set (CS). Setiap CS mendefinisikan sebuah himpunan fitur-fitur dimana sebuah service baru dapat dibuat.

Sejak pertama kali standar IN dibuat, ITU telah merilis beberapa capability set yaitu

  • Tahun 1992, capability set yang pertama CS-1
  • Tahun 1995, CS-1 direvisi menjadi CS-1 R atau CS-1+
  • Tahun 1997, dirilis CS-2
  • Tahun 1999, dirilis CS-3
  • Tahun 2001, dirilis CS-4

Standard untuk masing-masing CS tersebut adalah

  • Q.12x0 Structure of IN CS-x
  • Q.12x1 Introduction to IN CS-x
  • Q.12x2 IN Service Plane Architecture for CS-x (not for CS-1)
  • Q.12x3 IN Global Functional Plane Architecture for CS-x
  • Q.12x4 IN Distributed Functional Plane Architecture for CS-x
  • Q.12x5 IN Physical Plane Architecture for CS-x
  • Q.12x8 IN Interface Recommendations for CS-x
  • Q.12x9 IN User Guide for CS-x

dengan x menunjukan angka rilis CS yaitu 1,2,3,4 dan seterusnya.

Model Konsep IN



Dalam jaringan telekomunikasi yang berbasis CCS, switching sering disebut sebagai SSP (Service Control Point) dan elemen IN disebut SCP (Service Control Point). Hubungan SSP dan SCP dapat digambarkan sebagai berikut:


-------query------->
SSP SCP
<----response-------


Fungsi utama SCP adalah sebagai Service Control Function (SCF). Selain SCF beberapa fungsi lainnya diantaranya adalah:

  • Service Data Function (SDF)
    SDF menyimpan data Subscriber dan network yang diperlukan oleh SCF pada eksekusi service.
  • Service Resource Function (SRF)
    SRF menyediakan specialized resources yang dibutuhkan ketika eksekusi service pada SCF misalnya penerima digit, yang melakukan play announcement, dan lain-lain.
  • Service Management Function
    SMF memberikan fungsi provision, deployment dan support
  • Service Management Access Function (SMAC)
    SMAC merupakan fungsi interface bagi user untuk mengakses SMF
  • Service Creation Environtment Function (SCEF)
    SCEF memberikan fungsionalitas untuk mendefiniskan, menbuat (develop) dan melakukan test suatu service.

Fungsi-fungsi diatas didefinisikan pada IN Conceptual Model (INCM) yang didefinisikan pada standar ITU (CCITT Recommendation Q.1201). INCM merupakan suatu basis untuk standarisasi dan petunjuk (guidelines) desain untuk arsitektur sebuah IN. INCM menjelaskan konsep IN dalam 4 bidang (planes) yaitu:

  • Service plane
  • Global functional plane
  • Distributed functional plane
  • Physical plane

INCM dijelaskan pada standar-standar berikut:

  • Q.1200 General Series IN Recommendations Structure
  • Q.1201 Principles of the IN Architecture
  • Q.1202 IN Service Plane Architecture
  • Q.1203 IN Global Functional Plane Architecture
  • Q.1204 IN Distributed Functional Plane Architecture
  • Q.1205 IN Physical Plane Architecture
  • Q.1208 General Aspects of the IN Application Protocol
  • Q.1290 Glossary of Terms Used in the Definition of IN


Realisasi IN



Karena jaringan telokomunikasi dari mulai adanya IN hingga saat ini berbasis CCS atau SS7 maka realisasi IN pada jaringan telekomunikasi juga menggunakan protokol SS7. Telcordia mespesifikasikan IN/1 dan AIN sebagai protokol antara SSP dan SCP, sedangkan ITU dan ETSi membuat protokol INAP.

Gambar dibawah ini menunjukan posisi protokol IN tersebut dalam stack SS7


| INAP | IN/1 | AIN |
+-------------------+
| TCAP |
+-------------------+
| SCCP |
+-------------------+
| MTP Layer 3 |
+-------------------+
| MTP Layer 2 |
+-------------------+
| MTP Layer 1 |
+-------------------+

INAP yang dispesifikasikan oleh ETSI menggunakan standar ITU TCAP, sedangkan AIN menggunakan ANSI TCAP.

ETSI INAP



Dengan adanya standar IN dalam arsitektur maupun protokol maka diharapkan implementasi IN dalam jaringan telekomunikasi yang terdiri dari berbagai elemen dari manufaktur yang berbeda menjadi lebih mudah. Kenyataannya hal itu tidak terjadi, banyak bagian dari spesifikasi yang diinterpretasikan berbeda karena tidak mendetailnya spesifikasi yang dibuat ITU-T. Oleh sebab itu, ETSI membuat standar INAP yang berbasis dari ITU-T INAP.

Untuk dapat diimplementasikan di mobile network yaitu GSM, ETSI membuat spesifikasi yang memperluas ETSI INAP yaitu CAMEL. Relasi rilis INAP dan CAMEL diperlihatkan pada gambar dibawah


ITU-T CS-1 ---> ITU-T CS-2 ---> ITU-T CS-3 ---> ITU-T CS-4
: : :
: : :
CORE INAP 1 ---> CORE INAP 2 ---> CORE INAP 3
\ \______________ \_____________ \____________
\ \ \ \
\ \ \ \
CAMEL 1 ---> CAMEL 2 ---> CAMEL 3 ---> CAMEL 4

Followers