Bisnis mobile advertising

Saat ini mobile advertising atau iklan lewat media perangkat bergerak sedang menjadi topik yang banyak dibicarakan. Beberapa analis memprediksikan mobile advertising ini akan menjadi potensi besar dan akan menjadi revenue stream batu buat operator. Memang kalau dibandingkan dengan internet advertising, bisnis mobile advertising ini masih sedikit jadi ada potensi besar untuk makin berkembang. Apalagi didukung dengan semakin besarnya pemakaian layanan data lewat perangkat bergerak.

Dibanding layanan value-added lainnya seperti SMS, RBT yang merupakan penyumbang keuntungan terbesar di pasar Indonesia, kemungkinan mobile advertising bisa menjadi penyumbang ketiga terbesar jika operator dapat menggarapnya dengan lebih baik. Perlu kreativitas dalam membuat layanan berbasis mobile advertising ini karena iklan sebernarnya bukan layanan tetapi merupakan informasi tambahan yang dapat ditambahkan atau dilewatkan pada layanan lain misalnya SMS, MMS, RBT, MCA, VMS dan lain-lain.

Contoh sederhana mobile ad adalah pengiriman informasi iklan lewat SMS secara broadcast. Contoh lain yang lebih kreatif misalnya:

• Penambahan teks iklan pada SMS yang dikirimkan dari seseorang ke orang lain dengan memanfaatkan sisa karakter yang bisa dimuat dalam SMS yaitu 160
• karakter. Bagi si pengirim SMS menjadi gratis atau mendapatkan diskon karena pesan singkatnya disisipi oleh iklan.
• Iklan dalam bentuk RBT. Pelanggan yang menggunakan RBT iklan akan mendapatkan tambahan pulsa atau gratis layanan lainnya setiap kali RBT-nya didengarkan oleh pemanggil.
• Penambahan teks iklan pada SMS missed-call alert.
• Banner iklan pada halaman portal mobile-site operator.

Layanan-layanan yang mendapat diskon karena disisipi oleh iklan atau pelanggan yang mendapatkan gratis layanan lain karena dia mendapatkan iklan membuat konsep mobile advertising menarik bagi pelanggan. Konsep ini disebut 'ad founded' dimana pelanggan mendapatkan keuntungan dari iklan.

Mobile ad ini akan menjadi lebih baik jika operator dapat melakukan targeted advertising yaitu hanya memberikan iklan pada orang yang dimungkinkan tertarik pada jenis iklan tertentu. Hal ini dapat dilakukan karena operator memiliki data pelanggannya apalagi jika data tersebut bisa lebih detail misalnya dengan melihat histori dari konten-konten yang pernah didownload oleh pelanggan.

Mobile ad menjadi menarik bagi para agensi iklan atau perusahan yang memerlukan promosi produknya karena targeted, sehingga iklan ini bisa dibilang lebih personal. Mobile ad juga dapat dikirim kapan saja karena perangkat bergerak yang dimiliki pelanggan hampir selalu 'online' dan pelanggan memiliki billing relationship dengan operator sehingga membuat kemudahaan dalam memberikan benefit pada pelanggan.

Mobile ad bisa juga mejadi lebih menarik jika lebih tertarget pada posisi pelanggan. Hal ini bisa dilakukan dengan menggunakan Location-Based Service (LBS).

Semakin booming-nya mobile ad ini terlihat juga dati berlomba-lombanya vendor-vendor telekomunikasi mulai melirik bisnis ini. Beberapa perusahan alat telekomunikasi mulai bergerak untuk memiliki portofolio produk/layanan untuk mobile ad dengan cara membuatnya atau mengakuisisi peruhaan yang sudah dulu dibisnis ini.


September 2007, perusahaan telekomunikasi Nokia mengakuisisi enPocket sebuah perusahaan yang memimpin di dunia mobile advertising. Sep 2008, Nokia juga mengabarkan bahwa beberapa pemain di industri media besar di eropa masuk dalam "Nokia Media Network". Pemain dalam industri media itu termasuk Agence France-Presse, France; RTL Mobile, Germany; Cuatro, Spain; Grupo Prisa, publisher of El País, Spain; Unidad Editorial, publisher of El Mundo, Spain; CNET, UK; Telegraph Media Group, UK; Trinity Mirror, UK; dan International Herald Tribune, pan-European


Feb 2008, Ericsson juga melakukan launching layanan hosted mobile advertising dan pada 14 Sep 2008, mereka mengumumkan kerjasamanya dengan operator KPN dari Belanda untuk implementasi layanan hosted mobile advertising pada pelanggan KPN. Dengan layanan hosted mobile advertising, KPN dapat melakukan targeted advertisements dengan berbasis preferensi konsumennya dan agensi juga dapat membuat dan mengelola iklan menggunakan reporting tools.

Motorola, lewat Motorola Ventures juga mulai melakukan investasi di bisnis mobile ad ini dengan memberikan dana pada Amobee Media Systems untuk pengembangan teknologi mobile ad.

Gembar-gembor mobile advertising

Dengan adanya gembar-gembor mobile advertising yang bisa kita lihat diberbagai website, dokumen hasil market analisis serta banyaknya para vendor telekomunikasi yang masuk ke bisnis ini, maka dengan ini saya berpendapat bahwa .... booming-nya mobile advertising ini masih terlalu dibesar-besarkan. Kenyataannya bisnis ini belum terlalu besar.

Di Indonesia, beberapa operator juga sudah mulai giat menggalakan bisnis mobile advertising ini seperti XL, esia, indosat, dan lain-lain tapi belum terlihat persaingan diantara mereka pada bisnis ini.

Jadi saya setuju dengan sebuah artikel ini: mobile advertising is massively overhyped, says analyst firm.

Bisa jadi memang mobile advertising ini menjadi booming karena efektifitasnya, tetapi perlu diingat mobile ad ini bukan tanpa tanpa tantangan permasalahan. Mobile ad perlu dilakukan dengan hati-hati agar tidak menggangu (intrusive) karena hampir semua pemilik ponsel atau perangkat bergerak mengganggap ponsel sebagai perangkat personal. Mereka membayar untuk membeli layanan sehingga iklan dapat dianggap tidak berhak masuk.

Dapat dimungkinkan nantinya pelanggan membutuhkan preimum service untuk menghindari iklan pada perangkat bergeraknya. Artikel Ad-averse Mobile Users Will Pay to Avoid Advertising memaparkan hasil survey yang menunjukan walopun 56% reponden berpendepat bahwa mendownload content harusnya bisa gratis, tetapi ada kecenderungan konsumen yang tidak menginginkan adanya iklan dan mereka memilih membayar lebih untuk menghindari iklan. Dari survey tersebut telihat juga sebenarnya, kebanyakan kalangan muda tidak keberatan untuk membayar konten yang didalamnya tidak terdapat iklan.

Dari perusahaan IT menjadi vendor telekomunikasi

Ide konvergensi antara dunia telekomunikasi, new media dan IT yang semakin mengemuka dan terimplementasi sedikit demi sedikit, membuat banyak perusahaan IT mulai melirik teknologi komunikasi dan bermain dibisnis ini. Vendor-vendor besar seperti IBM, Sun, Oracle, Microsoft semua mulai melirik bisnis telekomunikasi dengan membuat produk-produk khusus untuk keperluan operator dan mengembangkan teknologi untuk layanan baru yang berbasis unified messaging. Beberapa perusahaan IT tersebut ada juga yang mengembangkan solusi berbasis produk dari rekanan misalnya IBM dan beberapa perusahaan seperti Oracle mengakusisi perusahaan lain yang memiliki portofolio produk telekomunikasi.

Dengan adanya teknologi VoIP dan semakin populernya teknologi SIP membuat berbagai layanan telekomunikasi berbasis suara dapat dibuat dengan mudah. Teknologi berbasis SIP ini semakin populer karena arah dari perkembangan telekomunikasi bergerak dalam jaringan operator pun nantinya akan menggunakan teknologi SIP. Jadi walaupun belum banyak operator yang all-IP architecture dan telekomunikasi berbasis SIP, tetapi telah banyak vendor-vendor membuat produk berbasis teknologi ini.

SDP yang dikatakan sebagai penghubung antara dunia telekomunikasi dan IT saat ini juga mengarah pada penggunaan SIP untuk mengekpos layanan suara yang dimiliki operator ke perusahan-perusahan 3rd party. Walaupun operator masih menggunakan teknologi TDM (switch based) untuk layanan suara, hal ini tidak menghentikan operator untuk dapat mengadopsi teknologi SIP untuk SDP. Beberapa solusi SDP memasukan sebuah elemen VoIP gateway yang dapat menjembatani antara jaringan TDM dengan jaringan IP.

Tapi berita baru bahwa Microsoft akan menghentikan (end of life) produk SDP-nya yang bernama Connected Services Framework (CSF) sangat mengejutkan saya karena secara pribadi saya baru saja melihat presentasi dari Microsoft yang mengesankan minggu lalu tentang Content Delivery Platform dan Interactive Media Manager. Secara umum berita ini juga pasti mengejutkan karena Microsoft telah memiliki sebanyak 30 customer yang menggunakan solusi SDP-nya serta produk CSF ini baru di-launching tahun 2005.

LBS sudah mati?

Layanan berbasis lokasi (Location-Based Service) atau sering disingkat LBS adalah ide untuk memberikan layanan value-added pada pelanggan layanan telekomunikasi yang berbasis pada informasi dimana pelanggan itu berada. Layanan ini telah terealisasi sejak dulu. Hampir semua produsen-produsen alat telekomunikasi besar meninvestasikan uangnya untuk membuat produk LBS dan telah mengimplementasikannya pada banyak operator. Tetapi kelihatannya LBS ini gagal menjadi layanan yang benar-benar digunakan oleh pelanggan.

Hal tersebut terjadi juga di Indonesia, saya dengar beberapa operator telah memiliki produk LBS dan beberapa telah meluncurkan produknya ke pasar tetapi layanan ini tidak populer. Alih-alih mendapatkan untung, operator telah meninvestasikan pada layanan yang tidak menghasilkan atau bahkan bisa dibilang gagal. Menurut pendapat saya kegagalan ini karena, pertama, layanan ini tidak dikelola dengan baik, hal ini terlihat dari kurangnya promosi serta kurangnya keandalan layanan. Sering kali layanan ini mengalami masalah sehingga pengguna tidak mendapatkan informasi yang mereka inginkan.

Yang kedua, layanan LBS memiliki keterbatasan karena menggunakan SMS sebagai pembawa informasi. Layanan LBS biasanya menggunakan SMS sebagai bearer, pengguna harus menggirimkan SMS untuk meminta informasi dan LBS server akan bertanggung jawab untuk memberikan informasi dengan mengirimkan SMS. Bayangkan bagaimana seorang pengguna mendapatkan informasi lokasi ATM terdekat dengan disebutkan nama jalan atau gedung, bisa jadi si pengguna bahkan tidak tau dimana letak gedung atau jalannya. Jika kita menanyakan sebuah lokasi tertentu kepada orang lain biasanya kita akan meminta petunjuk arah, ini yang tidak didapatkan pada layanan LBS.

Jadi akan lebih baik jika layanan berbasis lokasi ini diintegrasikan dengan aplikasi peta pada ponsel. Tetapi masalah lain timbul yaitu keakuratan dari posisi pengguna. Produk LBS saat ini kebanyakan menentukan posisi dari base station yang digunakan oleh pengguna. Radius dari cakupan base station adalah beberapa kilometer sehingga posisi yang didapatkan tidak akurat. Untuk itu dibutuhakan teknologi yang lebih akurat seperti GPS yang bisa menentukan lokasi dengan tingkat kesalahan yang kecil. Kendala penggunaan teknologi GPS sebagai layanan berbasis lokasi dari operator adalah aplikasi GPS pada ponsel saat ini tidak terintegrasi dengan jaringan operator. Untuk itu perlu solusi integrasi antara LBS yang berbasis GPS dengan jaringan operator atau layanan informasi dari penyedia konten.

Belum lama ini, bulan November lalu, Sagem Orga sebuah produsen smart card dan produsen produk GPS, BlueSky Positioning, melakukan kerjasama untuk membuat GPS terintegrasi dengan SIM card. Kita lihat saja nanti bagaimana perkembangannya.

WURFL browser

Menyambung posting sebelumnya tentang kapabilitas perangkat bergerak (mobile device), kali ini saya akan berbicara tentang database perangkat yaitu database yang menyimpan data-data perangkat dan kapabilitasnya.

Pendeteksian jenis perangkat bergerak (ponsel) pada situs WAP atau CDMS biasanya dilakukan dengan cara melihat isi (value) dari parameter yang terdapat pada header HTTP atau WSP request. Parameter tersebut adalah user-agent atau x-wap-profile atau x-wap-profile-diff. Parameter user-agent ada pada spesifikasi HTTP (RFC 2616) dan telah digunakan oleh aplikasi browser komputer. Dua parameter yang terakhir adalah parameter dari standar OMA User Agent Profile (UAProf).

Untuk mengetahui kapabilitas dari perangkat tentu saja kita perlu sebuah device capability repository atau database yang menyimpan deskripsi dan kapabilitas dari sebuah perangkat. Mengelola sebuah device capability repository atau device desctiption repository tidaklah mudah apalagi jika kita menginginkan data kapabilitas yang lengkap. Data kapabilitas bisa banyak sekali misalnya berupa ukuran layar, kemapuan menjalankan aplikasi Java, kemampuan memutarkan file musik dan lain-lain. Sebuah perangkat dengan model yang sama juga dapat memiliki kapabilitas yang berbeda karena biasanya perangkat dengan model sama pun mengalami perbaikan misalnya perbaikan sistem operasinya.

Karena pentingnya data kapabilitas ini maka biasanya produk-produk seperti mobile CMS atau MDSP, MMSC, WAP portal, memiliki komponen device capability repository. Beberapa perusahaan seperti HP juga membuat produk serupa yang khusus menangani device capability repository. Data kapabilitas dari sebuah perangkat bisa didapat dari dokumen XML UAProf atau dengan melakukan riset sendiri.

Selain dari dokumen XML UAProf, data kapabilitas juga bisa diperoleh dari komunitas di Internet. Sebuah proyek yang membuat data kapabilitas perangkat secara independen dan terbuka adalah WURFL. Proyek ini membuat sebuah dokumen XML yang berisi data kapabilitas dari perangkat bergerak. Siapapun dapat menambahkan atau mengedit data tersebut. Beberapa perusahaan besarpun ada yang menggunakan WURFL sebagai basis device repository-nya.

Beberapa proyek open-source lain membuat antar muka pengguna agar kita dapat dengan mudah melihat data kapabilitas dari perangkat yang disimpan dalam dokumen XML WURFL, diantaranya adalah

• WURFL Browser (Demo bisa dilihat disini)
• Browser dengan menggunakan Adobe Flex (Demo bisa dilihat disini)
• Mobile Device Information (mDevInf), browser berupa aplikasi Java desktop
  

Smartcard Web Server (SCWS)

Belum lama ini Gemalto dan LG me-launching produk yang mendukung teknologi Smartcard Web Server (SCWS). Apa sebenarnya SCWS itu?

SCWS adalah teknologi HTTP web server yang ditanamkan pada smartcard misalnya kartu SIM, USIM, RUIM dan lain-lain sehingga pengguna dapat melakukan browsing ke konten atau halaman tampilan secara offline dengan menggunakan aplikasi browser. Browsing dapat dilakukan offline karena konten disimpan di dalam smartcard, sedangkan kontennya dapat diupdate secara remote oleh operator. Jadi SCWS mirip on-device portal. Kita hanya perlu membuka browser dan mengetikan URL seperti biasa untuk dapat mengakses SCWS, misalnya http://127.0.0.1:20080/cgi/SSO?account=username&passwd=123

SCWS merupakan teknologi standar yang dikembangkan oleh OMA dan sampai saat ini telah dirilis dua versi yaitu versi 1.0 dan yang paling terakhir adalah versi 1.1.

Arsitektur SCWS diperlihatkan pada gambar berikut:




Beberapa elemen yang terlibat adalah

• Browser yang diinstall pada divais yaitu aplikasi yang digunakan untuk menampilkan konten
  
• SCWS Gateway yang berapa pada divais yang berfungsi mengubah protokol HTTP/HTTPS (TCP/IP) ke protokol yang digunakan oleh smartcard. Selain itu elemen ini juga berfungsi sebagai pembatas atau pengontrol akses (control policy) terhadap smartcard dengan menggunakan rule yang disimpan di smartcard.
• SCWS Server yaitu aplikasi di smartcard yang memproses request dari browser.
• SCWS Administration application yaitu aplikasi yang berada jauh dari devais (remote) untuk mengadministrasi SCWS. Aplikasi ini biasanya berada di operator untuk misalnya meng-update konten yang ada di SCWS.

Cukup sekian ya, untuk lebih jelasnya silakan baca dokumen spesifikasi dari OMA atau lihat slide presentasi ini.

Masalah roaming di perbatasan negara (border roaming)

Pelanggan telepon bergerak yang berada dekat dengan negara lain biasanya mengalami masalah roaming yang tidak sengaja (inadvertent/accidental) karena ponselnya mendapatkan sinyal yang lebih baik dari operator negara sebelah dan operator tersebut memiliki roaming agreement dengan home operator. Hal ini bisa terjadi misalnya saja diantara perbatasan Indonesia dan Malaysia di pulau Kalimantan. Jika saja orang Indonesia yang merupakan pelanggan telepon selular Indonesia berada masih di wilayah Indonesia tapi dekat Malaysia, dia dapat dengan tidak sengaja melakukan pemanggilan roaming ke rekannya di Indonesia karena dengan tidak sadar ternyata ponselnya terkoneksi dengan jaringan operator milik Malaysia. Tentu saja hal tersebut tidak diinginkan oleh pelanggan karena akan membuat biaya komunikasi menjadi lebih mahal.

Masalah border roaming ini menjadi semakin mengemuka jika jumlah pelanggan di perbatasan sangat besar seperti yang terjadi di perbatasan Republik Irlandia yang berbatasan langsung dengan Irlandia Utara (Inggris). Permasalahan seperti ini dapat diatasi dengan mengedukasi pelanggan atau memberikan solusi di sisi operator.

Menghindari masalah ini, pelanggan dapat dengan mudah menonaktifkan "automatic network selection."

Pada sisi operator, masalah ini dapat diatasi jika operator dapat mengendalikan proses roaming. Border roaming solution adalah solusi untuk melakukan pengontrolan roming dari pengguna yang ada di perbatasan seperti yang dijelaskan diatas. Starhome, sebuah perusahaan solusi telekomunikasi yang terkenal dengan solusi roamingnya, memiliki teknologi (produk) yang dinamakan Intelligent Boarder Roaming sebagai solusi permasalah tersebut. Detail teknis solusi tersebut dapat dilihat pada US Patent nomor 7333808 . Selain Starhome, Pyro Telecom juga memiliki solusi sejenis.

Layanan Collect Call

Collect call adalah layanan telepon yang pembayarannya dilakukan oleh penerima telepon. Jadi jika biasanya penelpon yang akan membayar tagihan atau berkurang pulsanya (balance), kebalikan dari itu fasilitas collect call berarti pembayaran atau pengurangan pulsa telepon dilakukan pada sisi penerima (called party). Fasilitas ini sering juga disebut reverse charge.

Mungkin anda berfikir enak sekali si penelepon bisa telpon tapi ditanggung si penerima. Fasilitas ini tidak seperti itu. Fasilitas collect call ini akan meminta persetujuan penerima telpon untuk panggilan yang akan dibebankan padanya atau biasanya penerima telepon telah memiliki daftar nomor-nomor pemanggil yang dapat melakukan collect call padanya.

Fasilitas ini muncul pada dasarnya karena setiap operator ingin mengingkatkan keuntungannya (ARPU), oleh karena itu operator akan selalu mencari cara agak keberhasilan pada saat pemanggilan (call completion) meningkat. Ketidakberhasilan saat pemanggilan bisa jadi karena masalah teknis atau hanya karena sipemanggil tidak memiliki cukup balance. Nah lalu dicarilah cara agar penelpon tetap bisa melakukan percakapan tanpa perlu membayar tapi uang diambil dari orang lain yaitu orang yang ditelpon. Bisa jadi ada juga layanan dimana si A menelpon si B dan yang bayar si C. Layanan-layanan supplentary atau value-added memang kadang-kadang sederhana dan solusinya pun sederhana.

Teknisnya gimana?

Dibawah ini saya jelaskan bagaimana biasanya collect call digunakan pada jaringan telepon bergerak seperti GSM:

1. Orang yang akan melakukan pemanggilan telepon (A#) men-dial dengan cara memberikan prefix didepan nomor telepon yang akan dipanggil (B#) misalnya *22*08111111111.
Jika anda berfikir angka tersebut adalah angka untuk mengakses fasilitas USSD, pikiran anda memang benar.
2. A# kemudian akan menerima pesan bahwa proses collect call sedang menunggu persetujuan B#. Pesan dapat berupa Flash SMS atau USSD message.
3. B# kemudian akan menerima pesan USSD dan diminta untuk menjawab menekan suatu tombol, misalnya tekan 1 jika anda setuju menerima collect call dari A#
4. Jika B# setuju maka sambungan telepon antara A# dan B# berlangsung

Solusinya?

Karena teknis penggunaannya bermacam-macam maka solusi untuk collect call ini juga bermacam-macam. Intinya adalah agar billing system melakukan pengurangan balance pada perima telepon. Pada kasus pelanggan prabayar hal tersebut harus dilakukan secara langsung oleh IN, charging mediation ataupun elemen khusus yang memang ditambahkan pada jaringan operator untuk solusi ini. Sedangkan pada kasus pelanggan pasca bayar maka elemen yang membuat CDR (call data record) selama pemanggilan collect call yang akan diproses billing system haruslah memberikan informasi kepada siapa biaya akan dibebankan, dalam hal ini si penerima telepon.

Jelaslah bahwa layanan collect call hanya dapat digunanakan oleh pelanggan satu operator atau tidak lintas operator.

Elemen yang bertanggung jawab agar collect call ini terjadi dapat terintegrasi pada MSC atau dapat pula berupa satu elemen tersendiri yang terintegrasi ke MSC, IN, Charging Mediation/Billing system dan ke elemen pendukung seperti SMSC. untuk lebih jelasnya anda bisa juga baca dari Patent 6792261

Dapat iklannya, gratis layanannya.

Seperti halnya layanan broadcast TV yang tidak berbayar (gratis), sekarang tipe layanan seperti itupun sudah mulai diadopsi pada layanan telekomunikasi (voice, sms, dan lainnya). Intinya adalah memberikan layanan gratis bicara atau gratis SMS tapi anda akan 'diganggu' dengan iklan yang muncul pada ponsel. Jadi operator mendapatkan keuntungan dari pemasang iklan (advertiser dan biro/agen iklan) yang mengirimkan iklan.

Iklan dapat dikirimkan dengan berbagai cara, misalnya lewat SMS, MMS ataupun suara. Tentu masing-masing cara tersebut memiliki kelebihan dan kekurangan. Di Inggris, blyk telah memberikan layanan seperti ini pada ribuan anak muda dan iklan dikirimkan ke ponsel dengan menggunakan MMS karena pengguna dapat membalas (reply) dengan mudah dan iklannya pun dapat berbentuk beberapa gambar, klip ataupun teks. Memang iklan dalam bentuk MMS bisa lebih menarik tetapi pengguna dapat dengan mudah juga menonaktifkan layanan MMS agar dia tidak memperoleh iklan seperti diberitakan mobiletoday.co.uk di sini.

Blyk adalah sebuah perusahaan MVNO (Mobile Virtual Network Operator). MVNO tidak memiliki infrastruktur jaringan radio maupun core network, oleh sebab itu di Inggris Blyk menggandeng operator Orange sebagai partnernya.

Teknologi yang digunakan oleh operator MVNO seperti Blyk menurut saya tidak susah. Tentu operator virtual seperti bukan berarti tidak punya infrastruktur sendiri sama sekali. Infrastruktur utama yang mendukung bisnisnya haruslah dimiliki sendiri, dalam hal Blyk saya kira infrastruktur utamanya adalah sebuah advertising engine, gateway yang terkoneksi ke real operator, dan tentu saja portal untuk subscribernya. Selain itu tentu saja mereka perlu infrastruktur IT untuk operasional bisnisnya yaitu Business Support System (BSS) seperti customer support system, billing system, dan lain-lain.

On-Device Portal

On-Device Portal (ODP) adalah aplikasi pada ponsel atau device yang digunakan untuk melakukan pencarian (browsing/discovery), pembelian (download) mobile content seperti ringtone, gambar, wallpaper, musik, video, game dan juga mengakses informasi dan layanan lainnya.

Sebagai contoh sebuah ODP adalah Nokia Catalogs atau Nokia Download!. Jika anda memiliki ponsel Nokia dengan sistem operasi S60, biasanya didalam menu terdapat aplikasi Catalogs atau Download!. Dengan aplikasi tersebut anda bisa lihat konten-konten yang dapat dibeli. Tentu saja konten-konten tersebut muncul dan dapat dibeli jika operator telah bekerja sama dengan Nokia agar aplikasi tersebut berjalan dan pengguna dapat di-charge sesuai dengan tarif konten.

Mungkin penjelasan dari Nokia Content Discoverer (NDC) sebagai produk end-to-end ODP dari Nokia ini bisa jadi penjelasan tentang defini ODP:

"an application that makes it easy for a mobile phone user to connect to a catalog of content such as ringing tones, video, and applications. Operators get better content revenue and the ability to integrate multiple delivery systems, content providers and developers get an excellent way to distribute their offerings, and consumers get an easy, one-stop "mobile shopping mall" for all their mobile needs."

On-Device Portal memberikan kemudahan karena aplikasi terinstal di ponsel sehingga interaksi dengan user menjadi cepat. Berbada dengan WAP portal yang membutuhkan banyak komunikasi antara device dengan WAP server melalui GPRS. Komunikasi antara aplikasi ODP dengan backend server (content database) dilakukan hanya untuk mendapatkan metadata dari konten dan gambar preview dari kontent. Sedangkan layout dan gambar-gambar pada menu yang statis biasanya tidak diambil dari backend server.

Komunikasi antara aplikasi ODP dengan backend server biasanya melalui HTTP sehingga memerlukan koneksi GPRS. Tetapi tidak ada protokol standar yang digunakan oleh semua ODP.

Karena aplikasi ODP diinstall di dalam ponsel maka teknologi yang digunakan untuk membuat aplikasi ODP pun bermacam-macam sesuai dengan sistem operasi ponsel atau framework yang sudah ada dalam ponsel misalnya teknologi yang berbasis sistem operasi Symbian (S60), RIM (OS yang digunakan pada Blackberry), Windows Mobile, Java/J2ME, Brew atau Adobe Flash Lite.

Biasanya sebuah aplikasi ODP di-bundle dalam penawaran penjualan ponsel sebagai suatu strategi marketing. Jika tidak maka pengguna harus repot-repot untuk mendownload aplikasi dan menginstall-nya di handset mereka. Untuk orang awam hal itu tentu sulit dilakukan.

Melihat lahan SDP

Jika kita ingin lihat pemain-pemain dalam solusi Service Delivery Platform (SDP), mungkin posting di blog Alan Quayle bisa dijadikan sumber acuan. Karena definisi SDP yang tidak begitu jelas batasannya dan luasnya cakupan SDP maka pada SDP landscape yang dibuat oleh Alan Quayle bisa kita lihat perbandingan perusahaan/vendor yang memiliki solusi ini dengan detail pada jenis/kategori apa saja yang diberikan, yaitu

1. CDP (Content Delivery Platform) yang merupakan subset dari SDP yaitu platform yang digunakan untuk menjual content seperti ringtone, music, video, game dan lain-lain.
2. SDP itu sendiri.
   

Masing-masing solusi CDP dan SDP di-breakdown menjadi

Tipe CDP:

• Managed Mobile Content: CDP yang diletakan (hosted) di sisi supplier dan dimiliki oleh supplier dengan brand yang dimiliki operator. Jadi operator tidak pusing untuk memiliki dan mengelola CDP sendiri.
  
• Mobile Content: Produk CDP yang dibeli, diinstall, dan dikelola oleh operator.
  
• IPTV: Sebuah CDP untuk STB (Set-Top Box) yang memberikan layanan TV lewat jaringan broadband IP.

Sedangkan tipe SDP, dibagi menjadi bagian-bagian solusi berikut:

• Messaging: SDP yang berfokus pada konten SMS premium yaitu pengiriman kontent dengan SMS/WAP push/MMS dengan tarif yang ditentukan dari harga SMS/WAP Push/MMS tersebut.
  
• SIP application server: SDP yang berfokus pada aplikasi suara (voice)
  
• Business: SDP yang berfokus pada layanan bisnis dan itegrasi antar proses bisnis.
• Real-Time charging: Komponen SDP untuk dapat melakukan real-time charging pada layanan yang digunakan oleh pengguna (subscriber).
• 3rd Party Communications and Messaging: Platform untuk koneksi antara operator dengan partner dengan menggunakan OSA OSE, Parlay, JAIN SLEE, atau standar protokol lainnya.
  
• Service Creation /Management: Komponen SDP component yang berfokus pada proses pembuatan (provisioning) dan pengelolaan layanan.
  
• Unified SDP: Sebuah SDP yang dibuat khusus dengan menggabungkan semua elemen kategori diatas termasuk juga CDP.

Silahkan langsung lihat saja perbandingannya di sini.

Ngomong-ngomong, selain SDP landscape, Alan Quayle juga membuat landscape lain seperti On Device Portal, Fixed Mobile Convergence, Service Management. Blog tersebut bagus untuk dijadikan referensi untuk orang yang tertarik pada VAS dan SDP.

Service Delivery Platform (SDP)

Sudah lama saya ingin menulis tengang SDP, tapi baru kesampaian sekarang. Silakan menikmati :-)

Istilah Service Delivery Platform (SDP) memang tidak jelas definisinya sehingga sulit memberikan dekripsi yang komprehensif. Isilah SDP telah menjadi buzzword (hype) yang sering digunakan oleh orang-orang marketing untuk dapat menjual platform-nya ke operator telekomunikasi. Diartikel ini saya coba menjelaskan apa itu SDP.

Dari report berjudul "Wireless-SDP: Market Assessment" yang dikeluarkan Stratecast Partners, SDP dapat didefinisikan sebagai:

An Information technology-driven solution designed to simplify the service creation process, using relatively common software toolsets, across functional and architectural boundaries, integrating a variety of data driven capabilities.

Jadi kalo kita lihat definisi tersebut, penulisnya berusaha membuat definsi SDP dari tujuan dan ciri-ciri SDP yang pada dasarnya didapat dari pengalaman nyata implementasi SDP oleh vendor di jaringan telekomunikasi milik operator.

Dari definisi tersebut juga dapat dilihat bahwa SDP merupakan solusi yang menyatukan dunia IT dengan dunia telekomunikasi. SDP saya kira dimulai dengan konsep NGN yang mengusung konvergensi telnologi IT dengan telekomunikasi yang kemudian mulai diimplementasikan dengan dibuatnya arsitektur IMS (IP Multimedia Solution) oleh 3GPP. Dengan IMS kita dapat dengan mudah membuat aplikasi tambahan baru pada jaringan telekomunikasi karena memang IMS dirancang untuk itu. Ide tersebut kemudian ditarik ke realita jaringan operator sekarang dimana IMS belum diimplementasikan secara nyata yaitu dengan cara membuat solusi yang dapat diimplementasikan langsung yaitu SDP. Upgrade jaringan ke IMS yang memerlukan waktu dan biaya tidak sedikit. Dengan SDP, operator yang ingin membuat layanan-layanan tambahan baru yang melibatkan content provider atau pihak ketiga lainnya tidak perlu upgrade jaringannya ke IMS.

Solusi untuk SDP sering disebut sebagai Service Delivery Framework (SDF) tapi kadang istilah SDP dan SDF digunakan tanpa ada pembedaan. Salah satu organisisi yang berusaha untuk membuat standarisasi untuk SDF yang dilihat dari kacamata Service Provider adalah TM Forum.

Gambar SDP Context dibawah ini saya kira cukup menunjukan dimana posisi SDP dalam jaringan telekomunikasi


Gambar copyright dari OSSObserver

Service Delivery Platform didesain untuk mendukung hal-hal berikut:

• Mempermudah pengadaan layanan rich communications dan layanan hiburan
• Cepatnya adopsi suatu layanan baru dan proses deployment (rollout)
• Membuat layanan lebih fleksibel dan lebih terbuka (extensible) sehingga mempermudah pemberian layanan dari pihak ketiga
• Mengurangi biaya pembuatan layanan baru sehingga diharapkan akan meningkatkan keungungan
• Meningkatkan ARPU dengan cara memberikan layanan yang dibutuhkan pelanggan dengan cepat

berdasarkan artikel ini, SDF biasanya terdiri dari domain-domain berikut :

• Manajemen dari Product Lifecycle environment
• Pembuatan layanan (service creation) atau aplikasi baru termasuk komponen yang dapat digunakan kembali (reusable)
• Manajemen dari Service Execution environment dan Service Enabler environment.
• Adaptasi dan pendefinisian proses OSS/BSS untuk SDF itu sendiri

Catatan: Service execution environtment adalah lingkungan yang dibuat agar dapat mendukung suatu aplikasi layanan dapat dieksekusi; Service Enabler evirontment adalah building-block dasar pada infraktrusktur jaringan telekomunikasi yang digunakan oleh aplikasi layanan sehingga layanan tersebut dapat diberikan ke end-user. Lihat gambar SDP context diatas.

Vendor-vendor telekomunikasi yang memiliki portofolio SDP dalam layanan atau produknya memiliki visi yang berbeda-beda oleh sebab itu implementasinya juga menjadi berbeda. Beberapa vendor fokus pada produk yang memberikan layanan content delivery dan solusi yang mengekspos jaringan operator ke content provider tapi beberapa vendor fokus ke penyedian excecution evirontment dan aplikasi middleware untuk mengekspos enabler application.

Untuk lebih jelas soal contoh-contoh layananan yang dapat dibangun diatas SDP ini silakan cari implementasi/produk dari vendor-vendor yang memberikan solusi SDP.

Two-sided Telecom Business Model

Bukan hal baru sebenarnya bahwa operator telekomunikasi saat ini berusaha mendapatkan keuntungan (revenue) tidak hanya dari pelanggannya saja. Operator mulai mengembangkan sayap untuk mendapatkan keuntungan dari value-added service seperti penjualan konten, membuat wap portal dengan memasan iklan sehingga dapat memperoleh keuntungan dari agensi iklan dan cara-cara lainnya.

Sebagian contoh tersebut memberikan gambaran bahwa terdapat peluang lain untuk mendapatkan keuntungan yang tidak langsung dari pelanggan (end-user). Hal inilah yang diusung oleh Telco 2.0 Initiative dengan istilah Two-sided Telecom Business Model (Lagi-lagi buzzword). Presentasi (slide) ini cukup bagus untuk mengerti latar belakang serta konsep Two-sided Telecom Business Model.

Gambar dibawah ini menrepresentasikan bagaimana konsep model bisnis ini.

WAP Push lewat protokol SMPP

Seperti sudah dijelaskan di posting sebelumnya dan sebelumnya, WAP push biasanya dikirimkan dalam bentunk XML ke PPG (Push Proxy Gateway) dengan menggunakan prokol PAP (Push Application Protocol). Contoh sebuah body message pada PAP untuk mengirimkan WAP push ke ponsel adalah seperti ini:

          
   <si>                                                                                             
   <indication href="http://cp.com/dl/javagames.php">
     Klik untuk download konten                                                                          
   </indication>                                                                                  
   </si>                                                                                            

Kita perlu ingat juga bahwa WAP push didesain agar "bearer independent" artinya dapat dikirimkan dari jaringan operator ke ponsel lewat bearer apapun yaitu SMS, USSD, circuit switch atau packet switch (GPRS). WAP push paling sering dikirimkan lewat bearer SMS dengan cara mengirimkan ke SMSC menggunakan protokol SMPP. Lalu bagaimana WAP push dapat dikirimkan lewat SMPP?

WAP push dikirimkan menggunakan submit_sm request ke SMSC, ada beberapa parameter yang harus diset pada submit_sm yaitu ESM_CLASS, DATA_CODING dan message (payload). Nilai untuk ESM_CLASS dan DATA_CODING adalah sebagai berikut

ESM_CLASS = 0x40
DATA_CODING = 0xF5

Sedangkan parameter message yang biasa kita isi teks dari SMS harus kita isi dengan kode WAP push XML yang disederhanakan dengan cara dibuat dalam bentuk biner. Hal ini dilakukan agar data menjadi lebih kecil. Penjelasan yang lebih detail dapat dibaca dari spesifikasi WBXML (WAP Binary XML) yaitu standar representasi XML dalam bentuk biner. WBXML dispesifikasikan oleh WAP Forum atau Open Mobile Alliance.

Sekarang coba kita encode XML diatas menjadi kode hexa WAP push. Setiap tag XML maupun atribut memiliki kode tertentu, sedangkan untuk teks yang merupakan nilai dari element atau attribute kita ubah menjadi string hexa dengan diawali dengan kode 03 yang berarti awal dari sebuah string ASCII dan diakhiri dengan 00.

Bagian XML                                        Kode hexa
------------------------------------------------  -----------------------------------------------------------
<si>                                               45
<indication                                        C6
href='http://                                      0C
Tanda awal untuk string ASCII                      03
cp.com/dl/javagames.php                            63702E636F6D2F646C2F6A61766167616D65732E706870
Tanda akhir string                                 00
> (Penutup tag indication)                         01
Tanda awal untuk string ASCII                      03    
Klik untuk download konten                        4B6C696B20756E74756B20646F776E6C6F6164206B6F6E74656E74
Tanda akhir string                                 00
</indication>                                      01
</si>                                              01

Jadi sekerang kita telah memiliki kode hexa dari XML WAP push yaitu 45C60C0363702E636F6D2F646C2F6A61766167616D65732E7068700001034B6C696B20756E74756B20646F776E6C6F6164206B6F6E74656E74000101


Sebelum memasukan kode tersebut dalam payload message di submit_sm request, kita memerlukan bagian UDH (User Data Header) sebagai berikut

 Header parameter                                                          Value
------------------------------------------------------------------------- ---------
UDH lenght                                                                06
                                                                          0504
Destination port                                                          0B84
Source port                                                               23F0
                                                                              
Transaction ID: Push ID                                                   DC
PDU Type: Push                                                            06
Headers lenght: 1                                                         01
Content type: application/vnd.wap.sic (0x80 | 0x2E)                       AE                                                                                                                                                                       

Version: 1.2                                                              02
Public identifier: -//WAPFORUM//DTD SI 1.0//EN (Service Indication 1.0)   05
Character Set: utf-8                                                      6A
String table: 0 bytes                                                     00

Sekarang kita telah memiliki header yaitu 0605040B8423F0DC0601AE02056A00,header ini harus disimpan selum kode binary XML dari message.

Contoh lengkap bagaimana membuat WAP push dengan menggunakan Java SMPP library atau library versi aslinya dari Logica, saya tulis dibawah ini:

// Create submit_sm request
SubmitSM request = new SubmitSM();

// Set binary message specific params
request.setEsmClass((byte)(Data.SM_UDH_GSM)); //0x40
request.setDataCoding((byte)0x0f5);
...

// Create hexa code for WAP push
String hexMessage = "0605040B8423F0DC0601AE02056A0045C60C03"                           
      + byteArrayToHexString("cp.com/dl/javagames.php".getBytes()).toUpperCase()
      + "000103"                                                                      
      + byteArrayToHexString("Klik untuk download konten".getBytes()).toUpperCase()   
      + "000101";                                                                     

// Set WAP push as short message data                                                                                        
request.setShortMessageData(hexToByteArray(hexMessage));

//Send submit_sm request to SMSC
session.submit(request);         

Kode diatas menggunakan dua method utilitas byteArrayToHexString syaitu untuk mengubah string byte array menjadi hexadesimal byte yang direpresentasikan dalam string dan method hexToByteArray yang melakukan hal kebalikannya.

Kedua method tersebut saya tuliskan dibawah

public static String byteArrayToHexString(byte[] b) {
                                             
  int    len = b.length;                     
  char[] s   = new char[len * 2]; // + 2 ];  
  //s[0] = '\'';                             
  int j = 0;                                 
  for (int i = 0; i < len; i++) {            
      int c = ((int) b[i]) & 0xff;           
                                                           
      s[j++] = (char) HEXBYTES[c >> 4 & 0xf];
      s[j++] = (char) HEXBYTES[c & 0xf];     
  }                                          
                                             
  //s[j] = '\'';                             
                                             
  return new String(s);                      
}

public static byte[] hexToByteArray(String s) throws IOException {     
                                                                     
  int    l    = s.length() / 2;                                      
  byte[] data = new byte[l];                                         
  int    j    = 0;                                                   
                                                                     
  if (s.length() % 2 != 0) {                                         
      throw new IOException(                                         
          "hexadecimal string with odd number of characters");    //NOI18N
  }                                                                  
                                                                     
  for (int i = 0; i < l; i++) {                                      
      char c = s.charAt(j++);                                        
      int  n, b;                                                     
                                                                     
      n = HEXINDEX.indexOf(c);                                       
                                                                     
      if (n == -1) {                                                 
          throw new IOException(                                     
              "hexadecimal string contains non hex character");    //NOI18N
      }                                                              
                                                                     
      b       = (n & 0xf) << 4;                                      
      c       = s.charAt(j++);                                       
      n       = HEXINDEX.indexOf(c);                                 
      b       += (n & 0xf);                                          
      data[i] = (byte) b;                                            
  }                                                                  
                                                                     
  return data;                                                       
}                                                                                                                             

Jika kita lihat secara keseluruhan paket (PDU) dari sebuah submit_sm untuk WAP push adalah seperti contoh berikut ini:

Mobile Content Delivery Solution

Saya sudah membicarakan mengenai Mobile CMS di posting sebelumnya. Di posting ini saya akan membahas tentang Mobile Content Delivery Solution (MCDS) yaitu sebuah konsep solusi untuk operator telekomunikasi yang mempermudah management konten dan pengiriman konten ke pelanggan (subscriber). MCDS bisa dibilang sama dengan mobile CMS karena sebuah MCDS merupakan sistem end-to-end untuk content management dan delivery.

Sebuah MCDS biasanya memiliki fitur-fitur berikut ini:

Modul Content Discovery/Delivery yang terintegrasi dengan elemen yang berfungsi sebagai delivery/discovery channel seperti
- Web/WAP portal
- SMS
- WAP push
- USSD
- IVR


Modul Content Management yang berfungsi sebagai tempat penyimpanan kontent (content storing), menyimpan metadata/informasi kontent, pengkategorisasian kontent, content lifecycle management termasuk submission dan workflow untuk persetujuan (approval) serta pengelolaan digital-right (DRM).

Modul Content Promotion atau Campaign Management yang memberikan kemudahan untuk melakukan promosi misalnya
hadiah (gift), undian (coupons), broadcast, paket, sponsored promotion, up-sell, cross-sell dan lain-lain.

Modul 3rd Party Content Provider Management yang memberikan kemudahan untuk mengelola konten yang berasal dari provider konten yang berlainan dengan skema bagi-hasil yang berbeda.

Modul Profile/Device management yang berfungsi sebagai tempat menyimpan informasi pelanggan serta jenis perangkat yang digunakan sehingga kontent dapat dikirimkan ke pengguna yang tepat sasaran.

Modul Reporting yang memberikan laporan-laporan yang dibutuhkan baik sebagai alat analisis atau rekonsiliasi antara operator dan content provider.

Berkembangnya bisnis konten mendorong vendor-vendor telekomunikasi untuk memberikan solusi/produk MCDS. Beberapa contoh produk MCDS diantaranya

• Solusi dari BEA-MobileAware-EMCDocumentum,
• Ericsson memiliki produk dari hasil akuisisi Drutt Corporation
  
• Nokia Siemens Networks menggunakan prooduk dari 3rd party yaitu XIAM + Hydra yang tergabung dalam TheSDPAlliance.org
• Sun Microsystem juga memiliku Sun Java System Content Delivery Server
• Solusi dari HP yang menggunakan produk-produk 3rd party
  

ICAP: Internet Content Adaptation Protocol

ICAP adalah kependekan dari Internet Content Adaptation Protokol, sebuah protokol yang digunakan untuk keperluan adaptasi konten sehingga konten yang di-deliver ke pengguna semakin baik.

ICAP diperkenalkan pada tahun 1999 oleh ICAP Forum sebagai standar protokol yang digunakan antara proxy server dan callout server. Protokol ini dispesifikasikan pada RFC 3507 tapi belum menjadi standard global dari IETF.

ICAP biasanya digunakan pada sebuah web proxy atau WAP untuk berkomunikasi dengan ICAP server. Dalam hal ini web proxy atau WAP gateway adalah sebuah ICAP client. ICAP server memiliki fungsi tersendiri misalnya virus scanning, pengubahan/adaptasi konten, pengubahan bahasa, penambahan iklan, penyaringan konten, kompresi data dan lain-lain.

Pada dasarnya protokol ini merupakan sebuah remote procedure call yang dibangun diatas protokol HTTP jadi cukup sederhana dan didesain agar scalable. ICAP memiliki dua

komponen utama yaitu:

1. Transaction semantics -- "Bagaimana client meminta layanan adaptasi?"
2. Control of policy -- "Kapan client hatus meminta layanan dapatasi, dan adaptasi seprti apa dan dari mana?"
   

Secara teknis operasi pada ICAP berfokus pada modifikasi pada HTTP request dan modifikasi pada HTTP response sehingga didefinisikan 2 mode operasi yaitu:

1. request modification (REQMOD) mode, yang memiliki dataflow sebagai berikut

      origin-server
          |  ^
          |  |
       5  |  |  4
          |  |
          v  |              2
      ICAP-client    -------------->   ICAP-resource
        (proxy)    <--------------   on ICAP-server
          |  ^             3
          |  |
       6  |  |  1
          |  |
          V  |
         client

2. response modification (RESPMOD) mode, yang memiliki dataflow sebagai berikut

      origin-server
          |  ^
          |  |
       3  |  |  2
          |  |
          V  |            4
      ICAP-client    -------------->   ICAP-resource
         (proxy)    <--------------   on ICAP-server
          |  ^            5
          |  |
       6  |  |  1
          |  |
          v  |
         client

Seperti halnya HTTP, ICAP juga mendukung otentifikasi, enkripsi. Sebuah ICAP client juga dapat melakukan caching dengan menyimpan response hasil dari ICAP server ke

internal cache.

Seperti apa sederhananya protokol ini kita lihat saja dari contoh operasi REQMOD berikut ini yang menambahkan (insert) data pada response yang didapat dari www.origin-server.com

  RESPMOD icap://icap.example.org/satisf ICAP/1.0
  Host: icap.example.org
  Encapsulated: req-hdr=0, res-hdr=137, res-body=296

  GET /origin-resource HTTP/1.1
  Host: www.origin-server.com
  Accept: text/html, text/plain, image/gif
  Accept-Encoding: gzip, compress

HTTP Response dari www.origin-server.com

  HTTP/1.1 200 OK
  Date: Mon, 10 Jan 2000 09:52:22 GMT
  Server: Apache/1.3.6 (Unix)
  ETag: "63840-1ab7-378d415b"
  Content-Type: text/html
  Content-Length: 51

  33
  Ini data yang diberikan oleh server www.origin-server.com
  0

Contoh ICAP Response-nya dalah sebagai berikut:

  ICAP/1.0 200 OK
  Date: Mon, 10 Jan 2000  09:55:21 GMT
  Server: ICAP-Server-Software/1.0
  Connection: close
  ISTag: "W3E4R7U9-L2E4-2"
  Encapsulated: res-hdr=0, res-body=222

  HTTP/1.1 200 OK
  Date: Mon, 10 Jan 2000  09:55:21 GMT
  Via: 1.0 icap.example.org (ICAP Example RespMod Service 1.1)
  Server: Apache/1.3.6 (Unix)
  ETag: "63840-1ab7-378d415b"
  Content-Type: text/html
  Content-Length: 92

  5c
  Ini data yang diberikan oleh server www.origin-server.com.
  IKLAN: Iklan ini ditambahkan oleh ICAP server.
  0

Adaptasi kontent (transcoding)

Sebuah MMS dapat memuat konten file berbetuk gambar, video, atau file lainnya tetapi tidak semua file dapat ditampilkan pada ponsel. Jika seorang mengirimkan MMS dengan file MP3, belum tentu si penerima dapat menjalankan MP3 tersebut di ponselnya.

Keterbatasan seperti itu biasanya diatasi dengan cara mengubah (transcode) file ke format yang dapat dijalankan atau ditampilkan pada ponsel penerima. Fungsi transcoding tersebut dilakukan oleh MMSC ketika MMS diterima dan akan dikirimkan ke ponsel tujuan.

MMSC perlu mengetahui tipe posel dari pengguna yaitu orang yang akan menerima MMS. MMSC dapat mengetahui dengan melihat HTTP request header yaitu pada header UserAgent atau UAProf. Atau jika database subscriber profile tersedia, MMSC dapat melakukan request untuk meminta data tipe ponsel pengguna.

Setelah mengetahui tipe atau kemampuan (capability) ponsel maka MMSC dapat melakukan transcoding ke bentuk file yang di-suport oleh ponsel penerima.

OMA mambuat standar/spesifikasi antarmuka (interface) yaitu dinamakan STI (Standard Transcoding Interface) yang digunakan elemen yang membutuhkan proses transcoding (misalnya MMSC) dengan elemen yang melakukan transcoding (transcoder). Hal ini diperlukan agar operabilitas antar elemen dari vendor yang berbeda dapat dicapai dengan mudah.

STI menggunakan SOAP lewat HTTP sebagai dasar protokol transaksi. Proses komukasi pada STI digambarkan sebagai berikut

  +---------+               +------------+
  |         |----request--->|            |
  |  MMSC   |               | Transcoder |
  |         |<---response---|            |    
  +---------+               +------------+  

Sebuah request terdiri dari bagian yaitu

• source yaitu objek media yang akan di-transcode dan informasi tentang objek tersebut misalnya format, resolusi, dan lain-lain.
• target yaitu informasi hasil objek yang diinginkan misalnya format, resolusi, bitrate, codec, size atau tipe handset
  

Objek media yang akan di-transcode sendiri dapat disertakan dalam SOAP message sebagai SOAP attachment atau hanya referensi ke objek eksternal yang alamatnya ditulis di SOAP message.

Dalam sebuah request dapat memiliki beberapa perintah (job) untuk melakukan transcoding dan request juga dapat memiliki beberapa attachment objek media.

Object media hasil sebuah proses transcoding juga dapat di-attach pada SOAP message maupun disimpan dalam remote content storage.

   Application platform      Transcoding platform         Remote content
   ====================      ====================         ==============
             |                         |                        |     
             |---------request-------->|                        |     
             |                         |---------fetch--------->|     
             |                         |<-----------------------|                       |                         |----+                   |                       |                         | transcode              |                       |                         |    |                   |                       |                         |<---+                   |                       |                         |--------store---------->|     
             |                                                  |     
             |-----------------------fetch--------------------->|     
             |<-------------------------------------------------|                       |                                                  |   

Lebih jelas tentang OMA STI dapat dibaca pada dokumen spesifikasi berikut yang dapat di download di sini

• Architecture of the Standard Transcoding Interface
• Req Doc Standard Transcoding Interface Requirements
• Specifications Standard Transcoding Interface Specification
• Schemas Standard Transcoding Interface Schema

Beberapa project open source yang mengimplementasikan OMA-STI

• ALEMBIK Media Transcoding Server
  
• Morfeo MyMobileWeb
• GAIA Transcoder Server

Standarisasi MMS

Standarisasi terpenting yang berhubungan dengan MMS adalah dari OMA/WAP Forum dan 3GPP, yaitu

- Dari OMA

• MMS Architecture
• MMS Encapsulation Protocol
• MMS client Transaction
• MMS Conformance Document
• Standard Transcoding Interface (STI) 1.0

- Dari 3GPP

• TS 23.140 Multimedia Messaging Service (MMS); Functional description; Stage 2
• TS 22.140 Multimedia Messaging Service (MMS); Stage 1
• Spesifikasi untuk billing
• 32.270 Telecommunication management; Charging management; Multimedia Messaging Service (MMS) charging
• 32.299 Telecommunication management; Charging management; Diameter charging applications

Kedua standarisasi tersebut saling berhubungan. Spesifikasi 3GPP mereferensi kepada spesifikasi dari OMA.

  OMA relese           3GPP release
 -------------------  -------------
  WAPForum MMS1.0      3GPP Rel-99
  OMA MMS 1.1          3GPP Rel-4
  OMA MMS 1.2          3GPP Rel-5
  OMA MMS 1.3          3GPP Rel-6

Versi terakhir dari MMS adalah MMS 1.3

Layanan Missed Call Alert (MCA)

Missed call alert (MCA) merupakan layanan yang diberikan operator selular agar pelanggannya tahu jika ada panggilan yang tidak terjawab dari pelanggan lain yang diakibatkan karena ponselnya mati, sibuk, tidak memperoleh sinyal akibat diluar area layanann ataupun panggilan yang memang tidak dijawab. Pelanggan biasanya mendapatkan informasi berupa SMS yang memuat informasi waktu panggilan (call) dan nomor telepon pemanggil.

Dengan layanan ini pelanggan akan selalu tau siapa yang mencoba mengontak walaupun ponselnya sedang tidak dalam keadaan aktif. Dari sisi oprator, layanan ini memberikan nilai tambah karena persentase pemanggilan-kembali (call back) akan meningkat karena pelanggan cenderung untuk menelepon balik si penelopon jika dia tahu bahwa ada panggilan yang tidak terjawab. Peningkatan jumlan pemanggilan ini, otomatis berarti memberikan peningkatan keuntungan. Oleh sebab itu, biasanya layanan ini tidak berbayar dan merupakan layanan standar. Pelanggan biasanya hanya dibebani biaya penginriman SMS dengan harga standar. Beberapa operator ada pula yang memberi tarif pada layanan ini dan tidak memberikannya sebagai layanan standar sehingga pelanggan memiliki kebebasan untuk tidak menggunakannya.

Ada 2 metode untuk sistem MCA yaitu

1. Call dilempar (forward) ke MCA server atau solusi MCA yang terintegrasi dengan VMS.

Layanan MCA kadang merupakan fitur dari sebuah VMS (Voice Mail System) sehingga tidak perlu sebuah box terpisah yang menangani layanan ini.

Pada metode ini, jika switch (MSC) tidak dapat menghubungi nomor tujuan maka switch akan mengalihkan panggilan ke MCA server atau VMS. MCA/VMS mengetahui dengan langsung dengan meneripa ISUP message (IAM) dari switch. Pada solusi tanpa VMS, MCA akan pemproses event tersebut dengan mengirimkan ISUP message ke switch untuk memutuskan sambungan REL dan menyiapkan sebuah pesan teks untuk kemudian dikirimkan ke SMSC.

Jika solusi MCA berada di VMS biasanya pemanggil akan mendengerkan pesan suara (interactive voice response) yang meminta pemanggil meninggalkan pesan suara. Jika pemanggil meninggalkan pesan suara maka VMS akan mengirimkan pesan yang berisi informasi adanya voice mail kepada nomor tujuan. Jika pemanggil tidak meninggalkan pesan (memutuskan sambungan) maka VMS akan memproses sebagai missed call yaitu menyiapkan sebuah pesan teks yang menginformasikan adanya missed call untuk kemudian dikirimkan ke SMSC.

  
Arsitektur dari solusi ini adalah sebagai  berikut:

          +-------+                   +-----------+
   A# ----|  MSC  |<----------------->| VMS / MCA |
          +-------+                   +-----------+
                                           |
          +-------+                        |
   B# <---|  SMSC |<-----------------------'
          +-------+   

2. Mendeteksi missed call lewat penyadapan (tapping) signaling dari MSC ke VMS.

Pada metode ini, MCA server merupakan elemen terpisah dengan VMS dan switch secara otomatis akan selalu mengalihkan pemanggilan ke VMS jika nomor tujuan (B#) tidak dapat dihubingi. MCA server mengetahui adanya missed call dengan cara melakukan penyadapan signaling link antara switch dengan VMS. MCA memilih message ISUP yang sesuai yaitu IAM kemudian memprosesnya dengan membuat SMS dan mengirimkannya ke SMSC.

          +-------+                   +------+
   A# ----|  MSC  |<--------+-------->| VMS  |
          +-------+         |         +------+
                            |
                     +------------+
                     | MCA server |
                     +------------+
                            | 
          +-------+         | 
   B# <---|  SMSC |<--------'
          +-------+                            

Layanan Welcome Roamers

Ada bayak elemen yang masuk katergori Value Added System (VAS) yang berbasis dari teknologi SS7 signaling probe atau signaling monitoring, diantaranya adalah welcome roamers, missed call alert, location based service, fraud detection.

Signaling probe berarti cara mendapatkan informasi dengan memonitor (capture) informasi yang lewat dalam suatu koneksi fisik dalam jaringan telekomunikasi yang berbasis SS7. Probing dilakukan pada jalur komukasi antar elemen misalnya koneksi E1/T1, SDH/SONET dengan secara pasif sehingga tidak mengganggu jalur komunikasi. Setiap informasi yang lewat kemudian diproses atau difilter oleh application layer.

Welcome roamers

Welcome roamers adalah salah satu layanan dalam telekomunikasi bergerak yang berfungsi untuk mengirimkan pesan SMS pada orang yang melakukan roaming (roamer) baik itu inbound roamer maupun outbound roamer.

Dengan adanya layanan welcome roamers, operator dapat memberi pesan penting tertentu untuk roamer misalnya ucapan selamat datang dengan memberi tahu waktu setempat serta nomor-nomor penting untuk dihubungi misalnya nomor polisi, hotel, resoran. Operator dapat juga melakukan personalisasi pesan dengan menggunakan bahasa di negara asal roamer.

Dibawah ini adalah arsitektur jaringan untuk solusi welcome roamer:

                                                 :
                                  Visited PLMN   :   Home PLMN
                                                 :       
             +---------+                         :        +----------+
   Roamer----| MSC/VLR |------+---------------------------|  HLR     |
             +---------+      |                  :        +----------+
                              |                  :       
                              |                  :
             +------+     +----------------+     :
             | SMSC |-----| Welcome Roamer |     :
             +------+     | Server         |     :
                          +----------------+     :
                                                 :

Layanan welcome roamer untuk inbound roamer dapat dibuat dengan cara melakukan probing pada koneksi antara Visited-MSC/VLR dengan Home-HLR. Secara sederhana prosesnya dapat dijelaskan sebagai berikut:

1. Pada saat inbound roamer tehubung ke VPLMN, maka VLR di VPLMN akan melakukan location update (MAP_UPDATE_LOCATION) ke HLR di HPLMN.
   
   
2. Sistem welcome roamer yang selalu melakukan probing akan mengambil informasi alamat (global title) HLR dan IMSI dari si roamer dari paket location update.
   
   
3. Kemudian sistem welcome roamer memproses informasi tersebut yaitu mengirimkan pesan/SMS lewat SMSC. SMS yang dikirim dapat berbeda-bebeda tergantung dari negara/operator dimana roamer berasal.
   

Layanan welcome roamer untuk outbound roamer dapat dibuat dengan cara yang mirip, yaitu dilakukan probing pada koneksi VPLMN dengan HLR di HPLM. Saat location update (LU) dilakukan oleh visited-MSC/VLR ke HLR, MSIDN dan global title dari Visiting-MSC dilihat untuk kemudian roamer dikirim SMS.

Sepertinya layanan welcome SMS untuk outbound roamer jarang diimplementasikan oleh operator.

Modul Probing

Untuk melakukan probing ke saluran SS7 signaling biasanya welcome roamer server memiliki modul fisik terpisah yang disebut probing/moniotoring module atau tapping module. Modul ini yang melakukan pengambilan informasi (menyadap) signaling, penguatan (amplifying) dan pemfilteran untuk kemudian dikirimkan modul pemroses.

Tapping (penyadapan) biasanya dilakukan pada kabel E1/T1 Tx (tranmitter) dan Rx (receiver) yang dihubungkan ke sebuah DDF (Digital Distribution Frame), seperti gambar dibawah ini

      +-------+                    +-------+
      |       |                    | DDF   |
      |  MSC  |---------Tx---------|---+---|------------> Link internasional
      |       |--------------Rx----|-+-|---|<--------------
      |       |                    | | |   |
      +-------+                    +-|-|---+
                                     | |
                                     | |
                                     | |
                              +-----------------+
                              | Probing  Module |
                              +-----------------+