Monday, November 10, 2008

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

Friday, November 07, 2008

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.

Thursday, November 06, 2008

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.

Monday, October 20, 2008

SNMP - Bagian 3

Management Information

Management Information Base (MIB) adalah koleksi informasi yang diorganisasi dalam bentuk hirarki. Sebuah file MIB adalah sebuah teks file dalam format ASN.1 yang merepresentasikan struktur hirarki dari informasi yang dapat diperoleh dari sebuah aplikasi atau sistem.

Dibawah ini adalah contoh hirarki yang menggambarkan MIB tree.

.
|
--------------------------------------------------
| | | |
ccitt(0) iso(1) itu(2) joint-iso-ccitt(3)
|
---------------------
| | | |
org(3)
|
dod(6)
|
internet(1)
|
----------------------
| | |
mgmt(2) private(4)
| |
mib-2(1) enterprise(1)
| |
| ...
|
--------------------------------------------------------------------...
| | | | | | | |
system interfaces addr-translation ip icmp tcp udp egp
(1) (2) (3) (4) (5) (6) (7) (8)


Managed object atau MIB object adalah sebuah atau beberapa karakteristik pada sebuah managed device misalnya beban CPU, besar memory yang digunakan. MIB pada dasarnya merupakan hirarki dari managed object.

Object identifier atau Obejct ID (OID) digunakan sebagai indentifikasi yang unik untuk setiap managed object yang ada dalam hirarki MIB. OID dapat direprensentasikan dalam sebuah nama misalnya .iso.org.dod.internet.mgmt.mib-2.interfaces.ifnumber atau nomor yang disebut sebagai object descriptor, misalnya .1.3.6.1.2.1.2.1

Sebuah managed object sebagai contoh ifnumber (number of interface) adalah sebuah ide abstrak, sedangkan representasi real dari informasi itu disebut dengan "instance" yang memiliki nilai dari object tersebut. Misalnya instance dari ifnumber adalah ifnumber.0 yang memiliki nilai 3 yang berarti sistem memiliki 3 network interface. Untuk mendapatkan nilai instance tersebut, NMS harus meminta informasi dengan mendefinisikan OID yaitu .1.3.6.1.2.1.2.1.0 (OID dari object ifnumber dengan ditambahkan .0 dibelakangnya).

Ada dua macam managed object, yaitu:

  • Scalar object yaitu sebuah object instance contohnya ifnumber
  • Tabular object yaitu beberapa object instance yang saling berelasi. Sebagai contoh object ifDescr yang merupakan informasi deskripsi dari masing-masing network interface akan memiliki 3 nilai yang berbeda jika jumlah network interface ada 3, misalnya:

    ifDescr.1 = "lo0"
    ifDescr.2 = "ce1"
    ifDescr.3 = "ce2"
Penjelasan yang cukup baik tentang scalar dan tabular object bisa dibaca di sini.

Suatu managed object ada yang hanya bisa dibaca dan ada pula yang bisa diset nilainya.

Karena pada awalnya SNMP didesain untuk me-manage jaringan TCP/IP, maka versi pertama MIB memiliki informasi yang spesifik untuk TCP/IP yaitu:
  • Deskripsi dari sistem
  • Jumlah dari networking interfaces yang dimiliki sebuah elemen (Ethernet adapters, serial ports ..)
  • Alamat IP address untuk setiap network interface
  • Jumlah (counts) dari paket atau datagram yang masuk (incoming) dan keluar (outgoing)
  • Tabel informasi tentang koneksi TCP yang aktif

Perlu diingat bahwa SNMPv1 menggunakan MIB-II. Pada MIB-II (RFC-1213) dispesifikasikan juga informasi untuk kategori-kategori yang umum seperti terlihat pada tabel berikut:


Category Information
---------- ---------------------------------------------
system The host or router operating system information
interfaces Network interrfaces information
addr-translation Address translation information
ip IP protocol information
icmp ICMP protocol information
tcp TCP protocol information
udp UDP protocol information
egp Exterior Gateway protocol information


Sebuah perusahaan atau vendor dapat membuat sendiri cabang (branch) dalam struktur MIB yang disebut sebagai private MIB. Cabang tersebut berada dibawah object .iso.org.dod.internet.private.enterprise dan harus didaftarkan ke IANA. List dari nomor untuk OID untuk perusahaan dapat dilihat di daftar ini. Pendaftaran akan mencegah adanya OID yang sama digunakan oleh perusahaan yang berbeda.


Structure of Management Information (SMI)

SMI adalah satu set aturan yang menspesifikasikan format untuk mendefinisikan managed object. Jadi jika kita membuat MIB maka kita perlu memahami SMI untuk dapat membuat struktur dan mendeskirpsikan managed object.

SMIv1 memiliki standar berikut:

  • RFC 1155 - Structure and Identification of Management Information for TCP/IP-based Internets
  • RFC 1212 - Concise MIB Definitions
  • RFC 1215 - A Convention for Defining Traps for use with the SNMP
SMIv2 memiliki standar berikut:
  • RFC 2578 - SMIv2 of SNMPv2
  • RFC 2579 - Textual Conventions for SNMPv2
  • RFC 2580 - Conformance Statements for SNMPv2

Followers