Menghitung signalling link occupancy

Biasanya dalam sebuah elemen STP menyediakan alat (tool) untuk memonitor atau mengoleksi informasi availability, performansi dan utilisasi dari MTP signalling link. Informasi tersebut biasa sisebut statistical counters.

Untuk menentukan beban (load) dari signalling link biasanya digunakan counter utilisasi. Counter utilisasi signalling link biasanya menampilkan data detail dari pengiriman (tranmisi) dan pengerimaan paket-paket Message Signaling Unit (MSU) serta paket-paket SIF+SIO selama periode waktu tertentu dalam satuan octet (8bit).

Link occupancy dapat dihitung dengan menghitung total octet yang dikirim atau diterima dalam waktu tertentu dibagi waktu pengukuran. Total octet adalah total pengiriman atau pengerimaan paket MSU dan paket SIF+SIO. Tapi perlu diingat bahwa sebuah paket MSU memiliki octet tambahan (overhead) karena adanya MTP Level 2 yaitu penambahan bit-bit untuk informasi/flag F+CK+LI+FSN+BSN yang besarnya 6 octet.

Dibawah ini adalah sebuah ilustrasi perhitungan link occupancy dari counter utilisasi:





Sebagai catatan, link occupancy yang direkomendasikan adalah 0.2 Erlangs untuk beban normal dan 0.4 Erlangs untuk beban tinggi (seperti yang dispesifikasikan pada dokumen spesifikasi ETSI 300 008 atau ITU-T Q.706 Recommendation). Jika occupancy lebih besar dari nilai tersebut maka sudah saatnya untuk mempertimbangkan penambahan link.

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.

WiMAX vs. LTE

Belum lama ini dalam sebuah kongress, ketua dari WiMAX Forum, Ron Resnick, mengungkapkan 'perlawanannya' terhadap LTE. Menurutnya LTE bukanlah sebuah evolusi tetapi seperti halnya WiMAX, LTE adalah sebuah loncatan teknologi. Hal ini diungkapkan karena biasanya orang melihat LTE adalah sebuah teknologi yang merupakan evolusi dari WCDMA/UMTS karena dibuat oleh organisasi 3GPP yang membuat standarisasi GSM, WCDMA/UMTS, IMS sehingga membuat konsepsi yang salah bahwa LTE bersifat backward compatible dengan standar 3G/UMTS atau paling tidak menawarkan jalur migrasi yang lebih mudah. Pada kenyataannya teknologi WCDMA atau CDMA200 sangat jauh berbeda dengan LTE. LTE malah lebih dekat dengan WiMAX. Sebuah keuntungan bagi WiMAX adalah teknologi ini telah tersedia dipasar dan commercial deployment telah dilakukan sejak beberapa tahun lalu. Ini akan membuat WiMAX menjadi lebih mature secara terknologi. Disisi lain LTE saat ini masih dalam tahap penyelesaian standar dan melakukan test deployment sehingga perlu waktu untuk operator agar dapat mengadopsi LTE. Berita selengkapnya silahkan lihat "WiMAX Forum chief hits back at LTE over-optimism"

Slide dari Dr.-Ing. Carsten Ball (Nokia Siemens-Networks, Germany) ini, cukup komprehensif menjelaskan perbandingan LTE dengan WiMAX dari sisi teknologi.

Komponen/elemen dari Intelligent Network

Komponen-komponen dari Intelligent Network

SSP= Service Switching Point
IP = Intelligent Periperal
SCP = Service Control Point
SDP = Service Data Point
SMP = Service Management Point
SMAP = Service Management Access Point
SCE = Service Creation Environtment

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.

Demo teknologi relaying yang akan digunakan pada LTE-Advanced

Tanggal 1 Desember 2008, NSN mendemonstrasikan teknologi yang akan digunakan pada LTE-Advance yaitu teknologi relaying. Dengan teknologi ini sebuah antena pada base station dapat ditambahakan untuk menambah cakupan (coverage) tanpa menggunakan backhaul tapi relay station ini mengirimkan data ke station sebelahnya yang memiliki backhaul dengan menggunakan frekuensi yang sama dengan frekuensi yang digunakan oleh perangkat pengguna misalnya ponsel. Dengan cara seperti ini maka peningkatan coverage lebih mudah dan lebih hemat biaya.

Teknologi relaying cocok untuk indoor coverage misalnya didalam gedung maupun di perkotaan dimana banyak gedung tinggi sehingga menghambat sinyal. Fungsi relay disini adalah memperkuat sinyal yang melemah karena adanya interferensi ataupun noise.


Gambar diambil dari presentasi Motohiro Tanno (NTT DoCoMo, Inc)

Berita selengkapnya disini.

LTE-Advanced

Sudah beberapa bulan, mungkin 1 sampai 2 bulan tidak buka website 3GPP. Hari ini buka dengan tampilan yang baru, yang lebih fresh dengan warna hijau dan terlihat lebih profesional. Tapi saya bukan mau ngomongin website 3GPP, saya mau ngasih tau kalau sekarang 3GPP sudah mulai mengembangkan teknologi yang lebih baru dari LTE yang diharapkan akan menjadi teknologi 4G.

Jadi LTE tidak akan menjadi teknologi 4G? Ya, sepertinya begitu. Ini karena organisasi telekomunikasi internasional, ITU, yang mendefinisikan teknologi 4G (IMT-Advanced) menspesifikasikan bahwa teknologi 4G harus memiliki data rate minimal 1 Gbps. Teknologi atau spesifikasi baru untuk memenuhi definisi 4G ini sudah mulai dikerjakan oleh 3GPP dan diberi nama LTE-Advanced. 3GPP telah mempublikasikan spesifikasi kebutuhan (technical requirement) TR-36.913 "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Requirements for Further Advancements for E-UTRA (LTE-Advanced)"untuk pengembangan LTE-Advanced ini pada bulan Juni 2008.

Memang teknologi berkembang begitu cepat melebihi aksebilitasnya sendiri pada masyarakat. Belum juga LTE digunakan oleh operator sebentar lagi kita akan punya LTE-Advanced.

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.

Domotics

Nokia membuat produk untuk rumah pintar (domotics) yaitu sebuah platform untuk mengontrol alat-alat dalam rumah seperti kulkas, tv, lampu, dan lain-lain lewat sebuah remote control atau ponsel ataupun PC.

Terdapat beberapa teknologi yang biasa digunakan pada rumah pintar, ada yang menggunakan sinyal yang dilewatkan pada saluran listrik (powerline) adapula yang menggunakan sinyal nirkabel atau yang menggunakan teknologi keduanya. Yang paling banyak digunakan adalah teknologi nirkabel, tapi sayangnya banyak sekali standar yang berbeda yang digunakan untuk keperluar rumah pintar ini. Beberapa standar misalnya Z-Wave, ISTEON, X10, ZigBee.

Lebih detail tentang teknologi ini silahkan baca di wikipedia

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.

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

SNMP - Bagian 2

Arsitektur SNMP

Gambar berikut meperlihatkan bagaimana SNMP digunakan sebagai protokol element management:



Managed device yaitu elemen yang dimonitor atau di-manage oleh NMS. Managed device dapat berupa elemen jaringan seperti router, hub, switch maupun komputer.

Agent adalah program atau software module yang berjalan di setiap elemen yang di monitor yang mengetahui informasi yang harus di-manage dan mentranslasikan informasi tersebut menjadi informasi yang kompatibel dengan SNMP atau dapat dikirimkan ke NMS melalui SNMP.

Manager atau NMS (Network-Management Station) adalah elemen yang menjalankan program untuk memonitor dan mengontrol managed device. NMS bisa mendapatkan langsung informasi dari agent misalnya informasi trap (alarm) atau meminta informasi dari agent.

SNMP - Bagian 1

SNMP (Simple Network Management Protocol) berawal dari kebutuhan terhadap suatu alat untuk mengadministrasi atau mengelola (manage) jaringan TCP/IP. Untuk itu perlu standarisasi protokol yang berfungsi untuk mengelola jaringan. Protokol yang didesain untuk itu kemudian dibuat diantaranya adalah SNMP dan CSMIE/CMP (Common Management Information Service Element / Common Management Information).

CMOT (Common Management Information Services and Protocol over TCP/IP) juga dibuat oleh OSI untuk keperluan yang sama. Cepatnya proses standarisasi SNMP oleh IETF dibanding CMOT yang dibuat OSI serta karena SNMP lebih sederhana membuat SNMP lebih cepat digunakan oleh publik.

Sebelumnya SNMP bernama SGMP (Simple Gateway Monitoring Protocol) yang didefinisikan pada RFC 1028 dan telah digunakan untuk monitoring gateway atau router.

SNMP dibuat berawal dari kebutuhan yang didefinisikan pada RFC 1052 (IAB Recommendations for the Development of Internet Network Management Standards). Setelah itu, tahun 1998 beberapa RFC mengenai SNMP dipublikasikan, yaitu:

• RFC 1065 - Structure and Identification of Management Information for TCP/IP-based internets
• RFC 1066 - Management Information Base for Network Management of TCP/IP-based internets
• RFC 1067 - A Simple Network Management Protocol

Setelah mengalami beberapa perubahan, barulah muncul standar SNMP versi 1 yang lengkap pada tahun 1991 dengan beberapa RFC berikut:

• RFC 1155 - Structure and Identification of Management Information for TCP/IP-based Internets
• RFC 1212 - Concise MIB Definitions
• RFC 1213 - Management Information Base for Network Management of TCP/IP-based internets: MIB-II
• RFC 1157 - Simple Network Management Protocol (SNMP)

Detail daftar RFC untuk SNMP v1 bisa dilihat disini.

April 1993, SNMP versi 2 menjadi standar dengan perubahan utama pada penambahan fitur baru yaitu keamanan dan otentifikasi. SNMP versi 2 tidak kompatibel dengan versi 1 karena SNMP v2 message memiliki header dan format PDU yang berbeda serta menggunakan 2 operasi protokol yang tidak dispesifikasikan pada versi sebelumnya.

• RFC 1902 - MIB Structure
• RFC 1903 - Textual Conventions
• RFC 1904 - Conformance Statements
• RFC 1905 - Protocol Operations
• RFC 1906 - Transport Mappings
• RFC 1907 - MIB
• RFC 1908 - Coexistence between Version 1 and Version 2

Detail daftar RFC untuk SNMP v2 bisa dilihat disini.


Tahun 1997 SNMP versi 3 mulai dibuat dan pada tahun 2002 menjadi full Internet standard. Dibanding versi sebelumnya, SNMP V3 memiliki fitur-fitur berikut:

- keamanan yang lebih baik dengan enkripsi dan access control,
- pengembangan remote configuration,
- privacy & message integrity

• RFC 3410 - Intoduction to Network Management Frameworks v3
• RFC 3411 - An Architecture for Describing SNMP Management Frameworks
• RFC 3412 - Message Processing and Dispatching
• RFC 3413 - SNMP Applications
• RFC 3414 - User-based Security Model (USM)
• RFC 3415 - View-based Access Control Model (VACM)
• RFC 3416 - Protocol Operations
• RFC 3417 - Transport Mappings
• RFC 3418 - MIB

Detail daftar RFC untuk SNMP v3 bisa dilihat disini.

Arsitektur UMTS Release-4

IETF telah mendesign sebuah protokol (RFC 2705) untuk mengontrol VoIP Gateway dari elemen eksternal pada tahun 1990. Protokol tersebut kemudian disebut media gateway control protocol (MGCP). MGCP dirancang untuk mengontrol jaringan yang menggunakan H.323, SIP RTSP, maupun SAP (Session Announcement Protocol).

MGCP kemudian dikembangkan IETF bersama-sama ITU.Hasil pengembangannya adalah protokol MEGACO yang dipublikasikan menjadi RFC 3525 oleh IETF sedangkan oleh ITU dipublikasikan sebagai H.248. RFC 3524 merupakan realisasi dari RFC 2805 "Media Gateway Control Protocol Architecture and Requirement".

Konsep arsitektur ini kemudian diadopsi oleh 3GPP untuk arsitektur jaringan UMTS. 3GPP membuat Mc interface (3GPP TS 29.232) yang merupakan modifikasi dari spesifikasi H.248 agar dapat digunakan dalam lingkungan GSM dan UMTS. Arsitektur ini dirilis pada UMTS Release-4 dan disebut-sebut sebagai distributed architecture atau layered architecture.

Inti dari arsitektur ini adalah separation of concerns (pemisahan) antara user plane dan control plane. User plane dimana media dikirimkan ditangani oleh Media Gateway (MGW) sedangkan control plane ditangani oleh MSC Server (MSS). (G)MSS melakukan control terhadap satu atau beberapa MGW.

Dibawah ini gambar aristektur UMTS Release-4.


Gambar diambil dari 3G South Africa

Dengan dipisahkannya antara user plane dan control plane maka didapat beberapa keuntungan yaitu:

• Satu MSC Server dapat mengontrol beberapa media gateway secara remote.
• Satu MGW juga dapat dibagi menjadi beberapa virtual MGW yang dikontrol oleh MSC Server yang berbeda.
• Ekspansi antara control plane (signaling) dan user plane (bearer) lebih fleksibel karena terpisah.
• Mempermudah migrasi dari GSM ke UMTS dan ke arsitekture All-IP network

Lebih detail tentang arsitektur UMTS R-4 ini bisa dibaca di 3GPP TS 32.002

Pendelegasian dalam proyek

Hampir semua posting di blog ini rata-rata sharing pengetahuan atau pengalaman tapi bukan curhat, tapi kalo mau jujur beberapa posting dibuat karena ada momen (trigger) tertentu misalnya kekecewaan. Posting kali ini juga ditrigger oleh sebuah konflik dalam sebuah proyek tapi saya tentu saja tidak mau curhat perasaan tapi ingin curhat pikiran menurut pandangan saya tentunya.

Konflik dalam sebuah proyek hal yang biasa dan semua orang yang terlibat dalam proyek tersebut haruslah dapat memanajemen konflik tersebut sehingga tidak menjadi sesuatu yang mengganggu proyek tetapi justru memberikan solusi.

Kadang kala konflik dalam sebuah proyek dimulai dari sesuatu yang tidak diprediksi sebelumnya. Tidak diprediksi sebelumnya bisa berarti tidak ada dalam dokumentasi, belum pernah dibicarakan baik di meeting, di email maupun dalam orbrolan informal, atau tidak ada di project planning. Sebagai contoh adalah adanya sesuatu kerjaan tidak didefinisikan. Pendefinisian pekerjaan (scope of work) memang sebaiknya cukup detail dan mencakup atribut-atribut perkerjaan tersebut misalnya waktu, orang yang akan melakukannya (Person in charge/PIC), dan lain-lain. Definisi pekerjaan tersebut haruslah terinformasikan ke setiap orang yang terkait. Adalah tugas seorang manajer proyek untuk dapat menginformasikan scope of work ke orang-orang yang terlibat dalam pekerjaan itu.

Fungsi manajemen dari seorang manajemen proyek memang dapat diartikan luas. Kadangkala seorang manajer proyek hanya fokus pada planning, costing, meeting dan monitoring. Mereka lupa bahwa me-manage berarti juga berarti melakukan fungsi manajemen sumber daya (resource). Manajemen sumber daya pada sebuah proyek bukanlah sekedar melakukan pendelegasian (assignment) tugas kepada seseorang seperti yang tertera dalam dokumen planning. Manajemen sumber daya berarti me-manage orang dan bisa jadi mendelegasikan tugas manajemen ke orang lain. Jadi fungsi manajemen sumber daya dalam sebuah proyek bisa jadi bukan hanya dipegang oleh manajer proyek saja, apalagi dalam sebuah proyek yang besar yang melibatkan cukup banyak orang.

Pendelegasian tugas manajemen ke orang lain ini sangat perlu didefinisikan dan juga dikomunikasikan. Yang penting dalam pendelegasian adalah bagaimana kita mendelegasikan tanpa kehilangan kontrol dan tetap menjaga accountability. Oleh karena itu seorang manajer proyek perlu mendefinisikan tanggung jawab utamanya kemudian mendelegasikan pekerjaan ataupun fungsi-fungsi manajemen lainnya ke tim proyek. Pendelegasian tidak semudah kelihatannya, banyak aspek yang perlu kita perhatikan seperti menentukan orang yang tepat untuk didelegasikan, memahami karakter orang yang mendapat delegasi, menginformasikan dengan jelas apa yang didelegasikan, memonitor (track) progress dan lain-lain. Beberapa posting dari pmhut.com ini tentang delegation cukup menarik untuk dipelajari.

Dengan pendelegasian yang baik akan menghindari konflik dalam proyek dan hasil akhirnya adalah proyek yang berjalan sukses.

Free SNMP library untuk Java

Monitoring aplikasi sangatlah penting apalagi aplikasi yang digunakan pada operator telekomunikasi. Ketidaktersediaan layanan dalam waktu sebentar saja mungkin akan menghilangkan kesempatan untuk mendapatkan keuntungan.

Buat anda yang sering membuat aplikasi dan memerlukan SNMP library untuk monitoring dan melakukan pengiriman alarm, dibawah ini ada beberapa alternatif Java API library yang gratis (free) yang dapat digunakan:

• SNMP4J
• Java SNMP Package
• Java Dynamic Management Kit (Java DMK)
• NetSNMPJ

Memonitor JVM menggunakan SNMP

Jika anda membuat aplikasi Java dan ingin memonitornya menggunakan SNMP, ada cara yang sederhana yaitu memonitor JVM. Tentu saja object yang dimonitor adalah yang berkaitan dengan JVM misalnya memory, thread, class loading, uptime, dan lain-lain. Lebih detail mengenai MIB object, anda bisa download standard MIB untuk JVM yang distandarisasi pada JSR 163 Java^TM Platform Profiling Architecture.

Untuk mengaktifkan fitur agent SNMP pada JVM dapat dibaca di petunjuk praktis disini. Jika dalam satu komputer anda menjalankan banyak aplikasi Java maka monitoring juga masih dapat dilakukan dengan menspesifikasikan port SNMP yang berbeda untuk masing-masing JVM.

Fitur management/monitoring dengan SNMP ini ada pada JVM versi 1.5 keatas dan perlu diperhatikan bahwa SNMP yang digunakan adalah versi 2.

Posting di blog lain tentang monitoring JVM dengan SNMP ada disini dan disini

Protokol Manajemen Jaringan: TL1

Selain CMIP dan SNMP ternyata ada protokol khusus untuk manajemen yaitu TL1 (Transaction Language 1). Saya baru saja update posing sebelumnya tentang Protokol Manajemen Jaringan untuk menambahkan TL1.

TL1 banyak juga digunakan pada jaringan telekomunikasi terutama jaringan optik dan jaringan akses broadband di Amerika bagian utara. Banyak digunakan di Amerika bagian utara karena prorokol ini dibuat sebagai standar terbuka oleh perusahaan Amerika yaitu Bellcore atau sekarang bernama Telcordia.

Beberapa dokumen standar tengang TL1 dapat dilihat di sini, tapi sayangnya dokumen-dokumen tersebut tidak gratis.

TL1 merupakan antarmuka (interface) yang berbasis ASCII sehingga input dan output dapat dengan mudah dibaca. Oleh karena ini TL1 biasa juga digunakan sebagai CLI (Command Line Interface) oleh orang yang memenej jaringan atau elemen pemonitor. Koneksi antara elemen (managed device) dengan administrator tidak didefinisikan tapi bisanya dilakukan dengan telnet atau koneksi lewat kabel RS-232.

Terdapat 4 tipe message dalam TL1, yaitu:

• Input Command Messages
  Message ini digunakan untuk memeberikan perintah (command) atau melakukan query kepada managed device
  
• Acknowledgment Messages
  Message ini dikirimkan oleh managed device ke terminal sebagai hasil dari input command message
  
• Output Response Messages
  Message ini dikirimkan oleh managed device ke terminal sebagai tanda bahwa managed device telah menerima input command message terutama jika output dari command akan memakan waktu lama.
  
• Autonomous Messages
  Message ini dikirimkan oleh managed-device ke terminal yang di-trigger langsung oleh managed-device karena kondisi tertentu misalnya mengirimkan alarm.

Beberapa link bahan bacaan tentang TL1 bisa dilihat di wikipedia atau baca sebuah halaman tentang TL1 Overview dari Adventnet yang menjelaskan cukup detail mengenai 4 jenis tipe message diatas.

Retrospective: Pembelajaran dari yang telah terjadi

Pembajaran dari pengalaman yang telah lalu adalah hal yang penting, begitu juga dalam proyek. Sangat penting untuk dapat melakukan review dari proyek yang telah lewat sehingga kita dapat belajar dari kesalahan dan kesuksesan sehingga kita dapat melakukan perbaikan pada proyek berikutnya. Istilah pebelajaran ini sering disebut sebagai leason learned atau retrospective.

Penting bagi seorang project manager untuk me-manage leason learned sehingga menjadi proses yang terus menerus dan dilakukan bersama. Pembelajaran dari proyek yang telah selesai sebaiknya dilakukan bersama-sama tapi belum tentu harus dilakukan dalam sebuah meeting dimana anggota team proyek mengeluarkan pendapatnya dan didengarkan oleh semua anggota tim. Bersama-sama sebaiknya diartikan bahwa sumber pemikiran, pendapat adalah dari semua anggota tim dan hasilnya diinformasikan kepada semua anggota dengan demikian setiap anggota memperoleh manfaat dari pembelajaran dari anggota yang lain. Meeting untuk sebuah pembelajaran boleh saja dilakukan namun hal ini saya kita bisa saja membuat anggota tidak bebas mengemukakan pendapat karena sebuah proyek kadang sarat dengan konflik.

Metode pembelajaran yang umum adalah dilakukan setelah proyek selesai dengan membuat meeting khusus. Metode ini sebaiknya mulai ditinggalkan. Pada agile methodology, proses pembelajaran dilakukan terus menerus layaknya iterasi software development. Metode ini disebut sebagai agile retrospective.

Beberapa hal yang perlu diperhatikan

• Buat lingkungan yang aman artinya lingkungan ketika melakukan retrospective harus dibuat sedemikian sehingga anggota tim dapat mengeluarkan pendapatnya tanpa takut misalnya takut karena menyinggung orang lain, takut mengurangi penilaian performance sehingga takut tidak naik jabatan, takut pendapatnya dianggap konyol dan lain-lain.
• Lakukan restrospective secara berkala dan lakukan juga jika ada kejadian-kejadian tertentu misalnya insiden.
• Fokus terhadap apa yang tidak berjalan dengan baik (gagal), solusi untuk memperbaikinya dan apa yang berjalan dengan baik misalnya apa yang berjalan efektif, sesuai jadwal.
• Jangan fokus hanya pada produk atau deliverables yang terkuantifikasi tapi perhatikan juga masalah-masalah interpersonal, tools yang digunakan untuk kerja, lingkungan kerja, time schedule, pembagian kerja dan lain-lain.
• Lakukan retrospective dengan efisien dengan tidak membuang banyak waktu.

Kumpulan pattern untuk iteration retrospective ini bagus sebagai bahan acuan untuk melakukan retrospective.

Beberapa buku tentang retrospective:

• Project Retrospectives: A Handbook for Team Reviews (Paperback)
• Agile Retrospectives: Making Good Teams Great,

Anda mungkin juga tertarik untuk melihat presentasi tentang Agile Retrospective dari pembuat buku diatas.

Aplikasi load-balancer

Saat ini saya butuh aplikasi load-balancer yang akan digunakan oleh aplikasi saat melakukan koneksi ke sebuah system yang terdiri dari beberapa back-end server. Terpikir untuk menggunakan aplikasi load-balancer gratisan tapi setelah dipikir lagi mungkin gak bisa karena load-balancer yang saya perlukan adalah load-balancer yang harus melakukan pendistribusian berdasarkan sebuah grup transaksi (beberapa request). Beberapa request yang akan dilakukan adalah:

1. Login
2. Do-something-A
3. Do-something-B
4. Do-something-C
5. Logout

ketiga request diatas harus selalu dikirimkan ke server yang sama. Hal ini diperlukan karena server-server yang menjadi tujuan tidak merupakan satu cluster sehingga session login yang dilakukan di server A tidak tereplikasi di server lainnya.

Jadi metode load-balancing yang saya perlukan adalah sticky load-balancing berdasarkan group transaction. Sticky berarti menempel. Beberapa transaksi yang saling berkaitan harus menempel (dikirimkan) pada server yang sama.

Sticky load-balancing adalah hal yang biasa dilakukan apalagi pada load-balancing trafik HTTP dan pengelompokan tujuan biasanya didasarkan pada:

• Alamat IP pengirim
• Session pengguna/cookies yang informasinya biasa terdapat pada HTTP header
  
• Bagian (parameter) yang ada di request URL
  

Jadi yang saya butuhkan bukanlah load-balancing sederhana dengan algoritma round-robin.

Sejak beberapa tahun lalu saya sudah menggunakan pound sebagai load-balancer dan reverse-proxy. Aplikasi ini gratis, mudah instalasinya, mudah dikonfigurasi tapi cocok untuk implementasi load-balancer HTTP/HTTPS.

Jika anda menginginkan load balancer yang melakukan pembagian pada layer TCP maka beberapa alternatif ini bisa digunakan:

• balance
• Pen
• Distributor: aplikasi yang ini berbasis Java

Untuk kebutuhan saya diatas sepertinya tidak bisa menggunakan aplikasi gratis tersebut, jadi saya berencana untuk meng-enhance apalikasi saja supaya melakukan load-balancingnya sendiri.

Catatan tambahan (2010/02/28):
Beberapa aplikasi load balancer yang mendukung sticky load balancing

• HAproxy, dapat melakukan sticky load balancing berdasarkan cookie misalnya JSESSIONID, lihat dokumentasinya disini.
• NGINX, lihat dokumentasinya disini
• Crossroad
  

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.

IN dan prepaid charging

Kalau saya lihat bagaimana IN digunakan di jaringan telekomunikasi di Indonesia ini maka saya lihat IN cenderung identik dengan prepaid charging yaitu tempat dimana rating dilakukan untuk pelanggan prabayar.

Fungsi utama IN adalah sebagai SCP (Service Control Point) yaitu sebagai otak dimana eksekusi logic untuk pengontrol call berlangsung. Lalu darimana asal mula IN digunakan sebagai element rating/charging untuk pelanggan prabayar?

Fitur online charging mulai ada dalam spesifikasi CAMEL 2 oleh sebab itu fungsi rating (penentuan biaya panggilan) dapat dilakukan secara internal yaitu pada mesin IN itu sendiri maupun secara eksternal.

ETSI European Norm (EN) 301 140-1 (‘Capability Set 2’, CS2) yang merupakan induk dari CAMEL mendefinisikan sebuah elemen bernama SDP (Service Data Point) yang berisi tabel call rating atau informasi account pelanggan. Jadi rating call tiap pelanggan dilakukan dengan cara mengambil informasi rating yang spesifik untuk pelanggan tersebut dari SDP. Fungsi SDP, yang disebut SDF (Service Data Function) dapat terintegrasi dalam elemen SCP/IN atau merupakan elemen yang terpisah.

Bagaimana integrasi antara SDP dengan SCP tidak didefinisikan pada ETSI EN 301 140-1 maupun pada CAMEL sehingga biasanya integration point ini menggunakan protokol yang dibuat sendiri oleh vendor produk IN.

Kadang menjadi salah kaprah bahwa rating/charging yang dilakukan di IN hanya bisa digunakan untuk pelanggan prabayar.

Protokol manajemen jaringan

Manajemen jaringan atau manajemen elemen pada jaringan telekomunikasi merupakan hal yang amat penting karena jaringan telekomunikasi dituntut untuk dapat melayani terus-menerus. Ketika saya mulai memasuki dunia telekomunikasi, saya baru mendapatkan sistem-sistem yang hampir selalu dirancang dengan high availability dan service availability yang tinggi. Kondisi tersebut dicapai dengan cara rancangan yang memperhatikan high availability baik pada elemen hardware maupun software. Selain itu keadaan elemen harus selalu dimonitor untuk mengetahui akan performansi elemen agar kesalahan (fault) maupun kondisi yang tidak diinginkan pada sistem dapat diketahui dengan cepat.

Menurut pengalaman saya, protokol yang paling sering digunakan untuk memonitor elemen pada jaringan telekomunikasi adalah SNMP (Simple Network Management Protocol). SNMP biasanya digunakan untuk memonitor performansi hardware seperti pengguaan CPU, memory, disk, serta parameter-parameter performansi dalam sistem (software) misalnya besarnya queue yang terpakai, penggunaan lisensi.

Mengapa SNMP?

Alasan mengapa SNMP banyak digunakan adalah karena SNMP adalah standar protokol yang memang dirancang untuk memanajemen jaringan dan SNMP merupakan protokol manajemen yang sederhana.

Sederhana tidak berarti mudah, SNMP cukup kompleks dan perlu tenaga yang lebih untuk mempelajari secara detail protokol ini terutama untuk mempelajari Structure of Management Information (SMI).

CMIP: Protokol standar manajemen untuk elemen telekomunikasi

SNMP bukan satu-satunya protokol yang bisa digunakan untuk keperluan manajemen jaringan seperti monitoring dan pengiriman alarm dan pengubahan parameter. Protokol yang telah menjadi standar untuk jaringan telekomunikasi adalah Common Management Information Protocol (CMIP) yang dibuat oleh ISO yang kemudian diadopsi sebagai standar oleh organisasi telekomunikasi dunia ITU-T yang dispesifikasikan pada recommendation series X.700.

Konsep CMIP hampir sama dengan SNMP tetapi CMIP memiliki lebih banyak fitur seperti authorization, access control,reporting yang lebih flexible, mendukung segala jenis tipe action.

3GPP, organisasi yang membuat standarisasi untuk jaringan GSM/UMTS/IMS/LTE juga menggunakan CMIP sebagai protokol manajemen jaringan (Lihat beberapa spesifikasi tentang Solution Set untuk Integration Reference Point pada seri 32).

Walaupun CMIP merupakan standar protokol yang diratifikasi oleh banyak organisasi telekomunikasi berkelas global tetapi pada kenyataannya SNMP masih lebih sering digunakan di jaringan operator.

Protokol lain yang didesain untuk manajemen jaringan misalnya:

• TL1 (Transaction Language 1)
  
• Java Management eXtensions (JMX) yang dispesifikasikan pada JSR-3 (JMX 1.X), JSR-255 (JMX 2.X), JSR-160 (JMX Remote API)
• Web Services Distributed Management (WSDM) yang dibuat OASIS
• WS-Management yang dibuat DMTF
• WMI (Windows Management Instrumentation)

Selain protokol-protokol tersebut kadang vendor juga menggunakan protokol sendiri atau menggunakan protokol yang umum seperti CORBA, HTTP.

OSS/BSS pada jaringan UMTS

Dapat dilihat di halaman ini, bahwa dokumen spesifikasi 3GPP yang membahas tentang OSS/BSS adalah seri 32.
List dari 3GPP spesification series 32 dapat dilihat disini.

Prinsip, kebutuhan dan arsitektur dari OSS/BSS bisa dibaca di dua dokumen berikut ini:

• TS 32.101 Telecommunication management; Principles and high level requirements
• TS 32.102 Telecommunication management; Architecture

Dokumen spesifikasi 3GPP pada seri 32 ini mencakup

• Charging management
• Configuration management
• Fault/alarm management
• Subscription management
• Security management
• Performance management
• Subscriber & equiptment tracing

Pada Release-8 di seri ini juga diperkenalkan konsep Self-Organising Network (SON) yaitu konsep otomatisasi proses network planning, configuration dan optimisation untuk jaringan telekomunikasi. Tentu saja SON ini bisa diimplementasikan pada jaringan Release-8 dimana arsitektur access network (E-UTRAN) menjadi flat karena hilangnya RNC (digunakannya eNodeB).

Silakan lihat juga posting saya tentang flat architecture.

CDMA

CDMA (code division multiple access) adalah telnologi transmisi radio. CDMA mulai dikembangkan pertama kali untuk keperluan komersial oleh Qualcomm. Pada awalnya teknologi ini banyak digunakan oleh operator di Amerika Utara dan merupakan saingan dari GSM yang menggunakan teknologi TDMA.

Pada akhirnya GSM pun menggunakan teknologi CDMA yaitu WCDMA yang memiliki prinsip yang sama dengan CDMA tetapi menggunakan lebar pita yang lebih besar. Saya tidak akan membas mengenai WCDMA atau UMTS tetapi CDMA yang biasa kita kenal yaitu memiliki brand name cdmaOne yang kemudian berevolusi mejadi CDMA2000.

Tahun 1993 CDMA Development Group (CDG) dibentuk. CDG adalah konsorsium international dari perusahaan-perusahaan seperti operator (carrier), vendor, produsen produk yang mengadopsi teknologi CDMA (bukan WCDMA).

CDMAOne

CDMAOne merupakan nama yang digunakan CDG sebagai teknologi seluler yang berbasis pada standar IS-95. IS-95 distandarisasi oleh Telecommunication Industry Association (TIA)
dan EAI Electronic Industries Association (EAI) pada bulan Juli 1993.

Pada tahun 1995, IS-95A dipublikasikan dan merupakan standar 2G CDMA yang banyak digunakan saat ini. Jaringan IS-95 menggunakan lebar pita kelipatan 1.25 MHz dan beroperasi pada frekuensi 800 dan 1900 MHz.

CDMAOne dapat melayani hingga pada kecepatan (data rates) 14.4 kbps.
Jaringan cdmaOne pertama kali di-launch secara komersial di Hongkong tahun 1995.


Topologi jaringan cdmaOne dapt dilihat dibawah ini:



Setalah IS-95A, dibuat IS-95B yang meningkatkan layanan dengan memberikan data rate yang lebih tinggi yaitu sampai 64 kbps untuk data packet-switced maupun circuit-switched. IS-95B atau disebut juga TIA/EIA-95 mengadopsi standar-standar lain yaitu IS-95A, ANSI-J-STD-008 dan TSB-74. ANSI-J-STD-008 menstandarisasi kompabilitas system CDMA PCS yang beroperasi pada 1.8 sampai 2 GHz

• TSB-74 mendeskipsikan interaksi antara IS-95 dengan sistem CDMA PCS
• IS-95B mulai digunakan September 1995 di Korea.
• IS-95B disebut-sebut sebagai teknologi 2.5G karena data ratenya yang sudah diatas teknologi 2G.

CDMAOne yang menggunakan standar TIA/EIA IS-95A dapat disebut sebagai CDMA yang bersesuaian dengan generasi 2G sedangkan CDMAOne dengan standar TIA/EIA IS-95B adalah generasi 2.5G. Standar core network yang digunakan CDMAOne adalah ANSI-41. Beberapa standar lain yang digunakan pada CDMAOne adalah:

• IS-95 Air interface
• IS-98 Mobile station
• IS-97 Base station
• IS-634 Base station controler and switch
• IS-41 & IS-124 Signaling

CDMA2000

Pengembangan dari CDMAOne adalah CDMA2000 yang diadopsi ITU-T sebagai salah satu teknologi 3G dalam payung standar IMT-2000 dengan nama CDMA Multi-Carrier (MC). Teknologi ini pertama kali di-launch komersial tahun 2000 di Korea selatan

Generasi awal CDMA2000 adalah CDMA2000 1x yang menggunakan 1.25 MHz, data rates up to 144 kbps 1XRTT. CDMA2000 pada awalnya mendukung mode single-carrier (1x) dan multi-carrier (3x), tetapi multi-carrier tidak pernah dikembangkan dan digunakan sampai pada standar CDMA Rev. B.



CDMA2000 1xEV-DO

Pengembangan selanjutnya CDMA200 adalah lahitnya CDMA 1xEV-DO Rel 0. EV-DO adalah singkatan dari Evolution Data Optimized atau Evolution Data Only. Peak data-rate EV-DO sampai pada 2.4Mbps pada penggunaan lebar pita 1.25 Mz. Pada Okteber 2006, di-launch CDMA 1xEV-DO Revision A.

CDMA 1xEV-DO Revision B atau CDMA2000 3x mengunakan 3.75 MHz dengan uplink/downlink yang lebih besar yaitu 1.8/3.1 Mbps dibuat. Teknologi ini dibuat dengan menggunakan arsitektur All-IP seperti halnya IMS. CDMA 1xEV-DO Revision B dipublikasikan dalam dokumen 3GPP2 C.S0024-B dan TIA/EIA/IS-856-B. Rev B tetapi hingga saat ini belum ada operator yang menggunakan Rev B.

CDMA Release C & D (EV-DV)
CDMA EV-DV (Evolution Data/Voice) dikembangkan oleh Qualcomm, tetapi dihentikan pemengembangannya dihentikan pada tahun 2005.

CDMA Rev C (UMB) adalah rencana pengembangan CDMA untuk bersaing dengan LTE/WiMAX dengan menggunakan teknologi OFDMA.

Gambar dibawah ini menunjukan evolusi CDMA2000 hingga UMB