Open Market Handsets untuk CDMA

Seperti kita ketahui, baik di Indonesia maupun di Amerika dimana CDMA banyak digunakan, ponsel (handset) untuk CDMA identik dengan satu operator. Handset yang kita miliki tidak bisa digunakan untuk operator lain karena RUIM card tidak bisa diganti dengan RUIM card dari operator lain. RUIM card adalah istilah untuk SIM card pada CDMA. Cara seperti ini menguntungkan operator karena pengguna akan punya tendensi untuk tetap menggunakan handsetnya karena ia telah mengeluarkan uangnya untuk membeli handset yang harganya lebih mahal dari harga voucher.

Tetapi hal ini merugikan pengguna dan produsen handset. Dengan dorongan dari produsen handset, maka CDG memulai proyek Open Market Handsets (OMH) agar handset CDMA dapat digunakan secara lebih bebas (open) oleh operator manapun dan data dalam handset dapat dipindahkan ke non-volatile memory pada RUIM card. Proyek OHM adalah bagian dari proyek besar CDG yaitu Global Handset Requirements for CDMA (GHRC) yang mendefinisikan kebutuhan-kebutuhan dan standar agar perangkat CDMA menjadi perangkat yang open-device dan open-application.

OHM telah telah dilakukan dibeberapa negara di Asia termasuk Indonesia. Berita lengkapnya bisa dilihat disini.

Membuat situs WAP (Mobile web) anda dapat ditemukan oleh mesin pencari

Berdasarkan berita ini, search engine masih didesain untuk mencari situs web untuk PC bukan situs WAP/web untuk perangkat bergerak (mobile web site) seperti ponsel. Saat ini agar sebuah mobile web site dapat ditemukan oleh mesin pencari (search engine), lebih baik anda membuatnya dengan menggunakan domain .mobi atau menggunakan domain seperti m.name.com, wap.name.com atau name.com/mobile.

Untuk mempermudah proses pencarian search engine pada mobile web site maka beberapa perusahaan mengusulkan sebuah standar untuk search engine optimization untuk mobile website yaitu dengan menggunakan metaTXT. metaTXT adalah teknologi yang sederhana tetapi untuk membuatnya menjadi berjalan, konsep ini harus digunakan oleh banyak mobile web site sehingga perusahaan-perusahaan search engine mulai mencari file metaTXT dalam proses pencariannya. Agar digunakan oleh lebih banyak situs maka metaTXT haruslah dijadikan standar, oleh sebab itu beberapa perusahan mengusulkan ke beberapa organisasi seperti W3C, dotMobi dan Mobile Marketing Association untuk mengadopsi metaTXT sebagai standar.

Contoh sebuah file meta.txt:

name:example.com
description: example.com is a widely used example website
keywords: example, demo, demonstration
pc: http://www.example.com
mobile:http://m.example.com
rss:http://rss.example.com/rss/topstoriesoftheday.xml
rss:http://rss.example.com/rss/toppoliticalstory.xml
rss:http://rss.example.com/rss/topsportstory.xml
podcast:http://rss.example.com/podcasting/news.xml
video:http://rss.example.com/rss/tutorial.xml
longitude:12.3456789
latitude:98.7654321
region:MM

Anda juga bisa menggunakan sebuah tool untuk men-generate file meta.txt

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
  

Evolusi CDMA2000/EV-DO menuju 4G akan mati?

Minggu lalu, diberitakan bahwa Qualcomm, sebuah perusahaan telekomunikasi besar yang mengembangkan teknologi CDMA, menghentikan pengembangan teknologi Ultra Mobile Broadband (UMB) yang mereka lakukan. Ini berarti kemungkinan teknologi CDMA2000 harus mengadopsi LTE atau WiMAX untuk dapat memberikan layanan 4G. Bahkan Qualcomm sudah mulai mensupport pengembangan LTE sejak tahun ini.


Disisi lain operator-operator didunia belum ada yang memeperlihatkan ketertarikan pada UMB. Sebuah operator besar CDMA di Amerika, Verizon Wireless telah mengumumkan bahwa mereka akan menguji coba penggunaan teknologi Long Term Evolution (LTE) dari telnologi EV-DO yang mereka gunakan saat ini. Dan bulan Maret lalu, diberitakan juga bahwa KDDI, sebuah operator telekomunikasi di Jepang yang menggunakan CDMA2000 akan LTE sebagai teknologi 'next-generation mobile broadband'-nya.

Bahkan CDMA Development Group (CDG), sebagai organisasi yang menaungi operator-operator maupun vendor yang menggunakan teknologi CDMA, bulan lalu menyatakan akan mendukung anggotanya yang akan memilih WiMAX atau Long Term Evolution (LTE) sebagai standar 4G.

Jadi bagaimana nasib operator-operator CDMA lainnya?

Standar Identity Management (IdM) untuk NGN

Pada era NGN dimana teknologi informasi dan telekomunikasi menjadi konvergen, indentity management (IdM) menjadi sangat penting. Pengguna harus dimudahkan dalam proses authentication dan authorization pada setiap jaringan akses atau layanan operator atau layanan dari organisi mananapun yang bisa diakses dari divas yang terhubung ke jaringan operator. Oleh karena itu ITU-T mulai bekerja untuk membuat standarisasi untuk identity management yang baru untuk memenuhi kebutuhan saat ini maupun masa mendatang. Pekerjaan ini dilakukan oleh Study Group 17, yang selain bekerja untuk membuat riset untuk IdM, juga melakukan riset untuk telecommunication security serta languages and description technique.

Progress dari pekerjaan pembuatan standard ini telah menghasilkan beberapa draft yang berhubungan dengan requirement, framework, capabilities dari Identity Management pada bulan September 2008 lalu. Sayangnya dokumen-dokumen tersebut hanya bisa diakses oleh pengguna terdaftar yang hanya bisa didapat oleh orang-orang yang bekerja di organisasi atau perusahaan anggota ITU-T. :-(

Saat ini sebenarnya beberapa organisasi atau perusahaan seperti OASIS, Liberty Alliance Project, Microsoft, IBM dan lain-lain telah membuat standar untuk IdM baik pada level konsep atau framework maupun protokol. Jadi kemungkinan ITU-T akan mengadopsi standar yang sudah ada ;-)

iPhone SDK

Beberapa bulan yang lalu saya melihat demo bagaimana sebuah aplikasi iPhone dapat dibuat dengan mudah dengan menggunakan iPhone SDK dan dijual dengan mudah ke semua pengguna iPhone. Sepertinya Apple, pembuat iPhone mengerti bahwa banyak sekali developer-developer kreatif yang suka membuat software untuk hobi maupun riset dan mempublikasikan software kreasinya itu sebagai aplikasi gratis di Internet. Alih-alih memberikan software gratis, Apple dapat membuat aplikasi itu tidak gratis lagi tapi mungkin dijual murah dan developernya masih bisa mendapatkan uang dengan mudah.

Model bisnis yang dilakukan untuk penjualan aplikasi iPhone ini adalah revenue share, jadi Apple masih dapat terus mendapatkan keuntungan dari penjualan software iPhone hanya dengan menyediakan platform untuk penjualan (store) yaitu tempat pengguna iPhone dapat mendownload aplikasi. Ribuan aplikasi pun saat ini dapat didownload dengan mudah di Application Store.

Apple memang bisa membuat orang jatuh cinta pada produknya, begitu banyak orang saat ini 'fanatik' pada produk Apple. Bahkan sebuah perusahaan penyandang dana KPCB membuat iFund yaitu inisiatif yang mengajak perusahaan yang membuat aplikasi, layanan maupun komponen untuk iPhone dengan menginvestatsikan 100 miliar US dollar. Fokus aplikasi yang akan dibuat adalah location based services, social networking, mCommerce (termasuk advertising dan payments), komunikasi, dan hiburan (entertainment).

iPhone SDK yang dirilis Maret 2008 ini terbukti menarik banyak developer maupun perusahan-perusahaan lain untuk membuat aplikasi iPhone. Diberitakan bahwa sudah lebih dari 100 ribu developer men-download iPhone SDK hingga saat ini.

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.

SCA: Model untuk mengimplementasikan SOA

Service Component Architecture (SCA) adalah satu set spesifikasi yang yang mendeskripsikan sebuah model untuk membangun (development dan delopment) sistem-sistem atau aplikasi-aplikasi dalam sebuah arsitektur service oriented (Service Oriented Architecture/SOA).

SCA dibuat oleh sebuah organisasi terbuka bernama OSOA yang kemungkinan akan diambil oleh OASIS, organisasi yang mengeluarkan banyak standar Web Services. Pada awalnya SCA dibuat oleh IBM dan BEA, lalu diikuti oleh vendor lain hingga akhirnya pada tahun 2006 dibentuklah OSOA.org dan mempublikasikan spesifikasi SCA versi 0.95

Spesifikasi final versi 1.0 pertama kali dirilis tahun 2007. Spesifikasi ini menitik beratkan pada bagaimana sebuah komponen (composite application) dibangun sehingga dapat dengan mudah digunakan kembali (reuse), diekspos fungsinya sehingga dapat digunakan oleh komponen atau aplikasi lain dengan berbagai metode akses, diimplentasikan dengan berbagai bahasa pemrograman, dan bagaimana kita dapat mendefinisikan aturan (policy) interaksi antar komponen.

Secara sederhana, fokus dari spesifikasi SCA adalah

• Assembly,
  
• Client dan Implementasion Model,
• Policy Framework,
• Binding.

Lebih jelasnya silakan baca penjelasannya di sini dan download spesifikasinya di sini. Selain itu, artikel tentang pengenalan SCA dari dari David Chappell cukup jelas juga sebagai bahan awal pemahaman SCA.

Mencari infrastruktur open source (gratis) yang mengimplementasikan SCA? Silakan lihat Apache Tuscany

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.