Telecom Service Broker

Tulisan dari LightReading berjudul "Telecom Service Broker" ini menarik untuk dibaca. Dalam artikel itu kita akan tau apa, bagaimana dan siapa yang membuat produk "telecom service broker."

Konsep telecom service broker memang sama dengan service broker yang ada di dunia IT atau Service Oriented Architecture (SOA) saat ini. Tapi perlu diingat kata pertama dalam judul itu (Telecom) membuat konteksnya agak lain.

Istilah service broker di area provider telekomunikasi ini mulai menjadi berita ketika beberapa produsen produk ini membentuk Service Broker Forum bulan Maret 2009 oleh Aepona, AppTrigger, Convergin, jNetX dan OpenCloud.

Pada dasarnya elemen telecom service broker dibuat untuk memberikan kemampuan pada operator telekomunikasi untuk melakukan konektifitas antar aplikasi, interaksi antar layanan, network orchestration dengan menggunakan standar 3GPP.

Telecom service broker juga mengadupsi konsep elemen Service Capability Interaction Manager (SCIM) dalam jaringan IMS. Perlu diketahui awalnya SCIM adalah konsep yang belum didefinisikan dengan jelas tapi sudah dituliskan pada standar IMS di 3GGP R7. Studi tentang service broker oleh 3GPP bisa dilihat di TR 23.810 Study on Architecture Impacts of Service Brokering yang merupakan bagian dari 3GPP R8.

Pada website Service Borker Forum, dijelaskan paling tidak fungsi utama dari service broker adalah

• SCIM
• IM-SSF
• IN-IN Trigger Management
• Protocol/Call Flow Management
• Subscriber Data Management Interaction

Gambar berikut memperlihatkan posisi service broker seperti definisi yang dijerlaskan Service Broker Forum:

"A network element that efficiently manages service interaction and service composition and resides between the service layer and the converging network and is traditionally decoupled from the core switch and the service execution or service creation environment"

Gambar diambil dari Service Broker Webinar slide presentation

Seperti ditulis di artikel LightReading, :

"service-broker functionality has long existed in mobile networks, but that many operators were not translating this need into a defined product category"

Jadi konsep telecom service broker sejak lama dan sudah mulai diimplementasikan seiring dengan berkembangnya Parlay-X, IMS/SCIM, SDP, Next Generation IN, Telco 2.0, OneAPI dan API-API lain yang mengekspos jaringan/layanan operator telekomunikasi ke "dunia luar" (IT world/3rd parties/Internet). Dan saya pede untuk mengatakan kalo ini sebenarnya adalah strategi marketing vendor-vendor telekomunikasi yang punya produk tersebut untuk dapat menjual (atau istilah sopannya mengedukasi para customer dalam hal ini operator telekomunikasi).

Saya tidak yakin kalo operator-operator di Indonesia dalam waktu dekat akan migrasi ke MIS atau SIP dari tradisional signaling (SS7), jadi yang relevan buat operator-operator di Indonesia adalah telecom service broker yang mengekspos legacy system (seperti MSC, legacy IN, SMSC, HLR, dll) ke "dunia luar". Di beberapa operator juga banyak lebih memilih untuk mulai menggunakan SIGTRAN (SS7 over IP) dibanging migrasi menggunakan SIP.

Jadi dalam kasus telecom service broker ini yang akan jadi preferred choice di Indonesia adalah yang bisa mengekspos legacy system.

Lagi lagi API untuk Telekomunikasi: OneAPI

Seperti sudah dijelaskan sebelumnya, usaha untuk membuat API atau interface yang membuka layanan dari operator atau provider telekomunikasi telah dilakukan beberapa organisasi, salah satunya adalah OneAPI yang diusing oleh GSM Assosiation, sebuah organisasi atau asosiasi internasional yang beranggotakan operator/provider telekomunikasi GSM dan vendor telekomunikasi.

Awalnya proyek OneAPI ini dinamai 3rd party access, yang dari namanya sudah jelas tujuannya adalah membuat API untuk memberikan akses kepada pihak ketiga ke layanan atau network yang dimiliki operator telekomunikasi.

Saya tidak akan membahas terlalu jauh tentang OneAPI karena API ini belum lama muncul, belum mature dan informasi atau dokumentasinya pun masih sangat minim.

Proyek pilot secara komersialnya baru dilakukan bulan lalu (Februari 2010), sedangkan spesifikasi dan dokumentasinya baru akan dirilis bulan Maret 2010. Saat ini API ini baru menspesifikasikan fungsi-fungsi untuk Messaging (SMS and MMS), Location, Payments dengan tekonologi Web Service dan RESTful. Spesifikasi OneAPI ini kemungkinan akan dikeluarkan oleh OMA.

Rencananya, OneAPI versi 2 akan memasukan fungsi-fungsi berikut:

• Data Connection profile
• QoS Quality of Service
• Remaining Credits Look-Up
• SMS triggering via UDH
• In-app billing

Lebih lanjut tentang OneAPI ini bisa dilihat di portal atau di library.

OneAPI: The first standard telecom RESTful API?

Saya sendiri bertanya-tanya mengapa dibuat standar baru dengan teknologi REST? Yang jelas REST ini lebih sederhana dibanding SOAP dan juga mudah karena menggunakan protokol HTTP.

Dan yang pasti beberapa vendor memang sudah mulai menggunakan REST sebagai interface untuk solusi SDP. Coba anda baca artikel "Who Makes What: RESTful Service Delivery Platforms". Bisa jadi RESTful API akan semakin banyak digunakan menggantikan SOAP seiring dengan makin populernya konsep Telco 2.0.

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.

Open API untuk telco

Dalam sebuah arsitektur SDP biasanya terdapat elemen yang mengekspos jaringan operator kepada dunia luar misalnya perusahaan rekanan (3rd parties) yang ingin memberikan layanannya kepada pelanggan operator. Elemen ini membuat jaringan operator menjadi semakin terbuka bagi siapapun dan mempermudah operator untuk mengeluarkan layanan-layanan baru pada pelanggannya.

Untuk keperluan mengekspos jaringannya, operator biasanya membuat sebuah API (application programming interface) yang dipublikasikan secara terbuka dan bahkan membuat komunitas developer agar semakin banyak orang yang dapat membuat aplikasi yang dapat digunakan oleh subscriber. API seperti ini disebut dengan istilah Telco API.

Berdasatkan riset, penggunaan Telco API dapat meningkatkan ARPU sampai 36%. Hal ini disampaikan oleh Alan Quayle dalam Asia SDP Summit 2008, November lalu (Paper tentang Telco API dari Alan Quayle dapat dilihat disini). Tentu saja ini menjadi menarik bagi operator yang sekarang sedang mengalami kecenderungan penurunan ARPU karena perang tarif.

Beberapa standar API sebenarnya telah dibuat seperti Parlay/OSA, ParlayX yang berbasis web service, JAIN yang berbasis Java. Tetapi itu saja tidak cukup, kemudahaan untuk membuat layanan bagi developer adalah kunci penting. Oleh sebab itu, ketersediaan akan integrated development environtment (IDE), tools, simulator, contoh kode program aplikasi, dokumentasi serta file-file binary API yang siap digunakan adalah kunci penting bagi operator untuk dapat menggaet developer.

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.

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