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

Passive Optical Network (Pengenalan)

Saya pernah nulis sendikit tentang jaringan optik (FTTx ) di posting sebelumnya. Karena jaringan optik ini salah satu teknologi yang sedang hot maka saya nulis lagi tentang dasar jaringan PON.


PON (Passive Optical Network) adalah jaringan point-to-multipoint berbasis fiber optik yang memiliki elemen pembagi optik (optical splitter) yang berfungsi sebagai penyalur data pada beberapa tujuan. Elemen pembagi tersebut bersifat passive artinya tidak melakukan manipulasi sinyal seperti penguatan pada sinyal optik.

PON pertama kali dibuat oleh FSAN (Full Service Access Network) yang kemudian distandarisasi oleh ITU-T (A/BPON, GPON) or IEEE (EPON).

Arsitektur sebuah jaringan PON adalah sebagai berikut:



Gambar diambil dari URL: http://www.infocellar.com/networks/new-tech/PON/PON-real.htm,

Sinyal optik downstream dan upstream merupakan dua buah sinyal yang berbeda panjang gelombangnya dan dilewatkan pada jalur fiber yang sama. Sinyal tersebut digabungkan dan dipisahkan oleh sebuah alat pada ujung jaringan yaitu pada kantor pusat service provider atau pada alat yang ada di sisi pelanggan. Pemisahan dan penggabungan sinyal optik dilakukan menggunakan sebuah filter wavelength division multiplexer (WDM).

Sinyal downstream adalah berupa paket-paket yang dikirimkan dengan cara broadcast lewat sebuah fiber, kemudian optical splitter akan mengirimkan paket-paket tersebut ke semua end-point. Jadi setiap ujung (termination) akan menerima paket data yang sama untuk kemudian disaring hanya data yang ditujukan padanya saja yang akan diproses. Untuk menjaga keamanan data maka setiap paket atau frame dapat dienkripsi tersebih dahulu.

Karena kemampuannya untuk mentransfer dengan bandwith yang tinggi dan jarak yang jauh (sekitar 20 sampai 30 km), PON biasa digunakan untuk jaringan metro atau untuk mobile backhaul yaitu koneksi antara core network dengan core network lain atau antara base station dengan core network.


Jaringan PON memiliki beberapa tipe. Tipe-tipe yang populer adalah

• APON atau BPON
• EPON atau GEPON
• GPON

APON/BPON

APON atau ATM PON adalah standar yang dikeluarkan oleh ITU-T dan diratifikasi tahun 1998 dengan standard G.983.1. APON menggunakan ATM sebagai transport protokolnya (layer 2). Setelah adanya penambahan standar G.983.3, APON kemudian diganti namanya menjadi BPON atau Broadband PON.

ITU-T BPON standard diantaranya:

• G.983.1 R: Basic architecture, PMD and TC for ATM-based B-PON
• G.983.2 R2: Operations Management Communications Interface
• G.983.3: WDM enhancement, for video overlays on B-PON
• G.983.3 A1: Support for higher bit rates
• G.983.3 A2: Optical best practices for B-PON
• G.983.4: DBA enhancement, for efficient bandwidth distribution
• G.983.5: Survivability enhancement, for protection switching

GPON

GPON atau Gigabit PON juga distandarisasi oleh ITU-T. GPON dapat mentransmisikan ATM cell atapun ethernet packet. Dengan berbasis teknologi Generic Framing Procedure (GFP) (standar ITU-T G.7041) membuat GPON memiliki bandwith efisiensi yang lebih baik yaitu 93% (BPON memiliki bandwith efisiensi sekitar 70%).

ITU-T GPON standard diantaranya:

• G.984.1: Requirements
• G.984.2: Physical layer
• G.984.3: Transmission Convergence layer
• G.984.3 A1: Refinements to TC layer
• G.984.4: Management layer
• G.984.4 A1: Refinements to Management layer

EPON

EPON atau Ethernet PON atau sering juga disebut GEPON (Gigabit Ethernet PON) merupakan standar IEEE 802.3ah yang diselesaikan tahun 2004. Standar ini merupakan bagian dari proyek Ethernet in the Last Mile (EFM).