Friday, June 27, 2008

ICAP: Internet Content Adaptation Protocol

ICAP adalah kependekan dari Internet Content Adaptation Protokol, sebuah protokol yang digunakan untuk keperluan adaptasi konten sehingga konten yang di-deliver ke pengguna semakin baik.

ICAP diperkenalkan pada tahun 1999 oleh ICAP Forum sebagai standar protokol yang digunakan antara proxy server dan callout server. Protokol ini dispesifikasikan pada RFC 3507 tapi belum menjadi standard global dari IETF.

ICAP biasanya digunakan pada sebuah web proxy atau WAP untuk berkomunikasi dengan ICAP server. Dalam hal ini web proxy atau WAP gateway adalah sebuah ICAP client. ICAP server memiliki fungsi tersendiri misalnya virus scanning, pengubahan/adaptasi konten, pengubahan bahasa, penambahan iklan, penyaringan konten, kompresi data dan lain-lain.

Pada dasarnya protokol ini merupakan sebuah remote procedure call yang dibangun diatas protokol HTTP jadi cukup sederhana dan didesain agar scalable. ICAP memiliki dua

komponen utama yaitu:

  1. Transaction semantics -- "Bagaimana client meminta layanan adaptasi?"
  2. Control of policy -- "Kapan client hatus meminta layanan dapatasi, dan adaptasi seprti apa dan dari mana?"

Secara teknis operasi pada ICAP berfokus pada modifikasi pada HTTP request dan modifikasi pada HTTP response sehingga didefinisikan 2 mode operasi yaitu:

1. request modification (REQMOD) mode, yang memiliki dataflow sebagai berikut

origin-server
| ^
| |
5 | | 4
| |
v | 2
ICAP-client --------------> ICAP-resource
(proxy) <-------------- on ICAP-server
| ^ 3
| |
6 | | 1
| |
V |
client



2. response modification (RESPMOD) mode, yang memiliki dataflow sebagai berikut

origin-server
| ^
| |
3 | | 2
| |
V | 4
ICAP-client --------------> ICAP-resource
(proxy) <-------------- on ICAP-server
| ^ 5
| |
6 | | 1
| |
v |
client


Seperti halnya HTTP, ICAP juga mendukung otentifikasi, enkripsi. Sebuah ICAP client juga dapat melakukan caching dengan menyimpan response hasil dari ICAP server ke

internal cache.

Seperti apa sederhananya protokol ini kita lihat saja dari contoh operasi REQMOD berikut ini yang menambahkan (insert) data pada response yang didapat dari www.origin-server.com


RESPMOD icap://icap.example.org/satisf ICAP/1.0
Host: icap.example.org
Encapsulated: req-hdr=0, res-hdr=137, res-body=296

GET /origin-resource HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain, image/gif
Accept-Encoding: gzip, compress

HTTP Response dari www.origin-server.com

HTTP/1.1 200 OK
Date: Mon, 10 Jan 2000 09:52:22 GMT
Server: Apache/1.3.6 (Unix)
ETag: "63840-1ab7-378d415b"
Content-Type: text/html
Content-Length: 51

33
Ini data yang diberikan oleh server www.origin-server.com
0


Contoh ICAP Response-nya dalah sebagai berikut:

ICAP/1.0 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Server: ICAP-Server-Software/1.0
Connection: close
ISTag: "W3E4R7U9-L2E4-2"
Encapsulated: res-hdr=0, res-body=222

HTTP/1.1 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Via: 1.0 icap.example.org (ICAP Example RespMod Service 1.1)
Server: Apache/1.3.6 (Unix)
ETag: "63840-1ab7-378d415b"
Content-Type: text/html
Content-Length: 92

5c
Ini data yang diberikan oleh server www.origin-server.com.
IKLAN: Iklan ini ditambahkan oleh ICAP server.
0

Tuesday, June 24, 2008

Adaptasi kontent (transcoding)

Sebuah MMS dapat memuat konten file berbetuk gambar, video, atau file lainnya tetapi tidak semua file dapat ditampilkan pada ponsel. Jika seorang mengirimkan MMS dengan file MP3, belum tentu si penerima dapat menjalankan MP3 tersebut di ponselnya.

Keterbatasan seperti itu biasanya diatasi dengan cara mengubah (transcode) file ke format yang dapat dijalankan atau ditampilkan pada ponsel penerima. Fungsi transcoding tersebut dilakukan oleh MMSC ketika MMS diterima dan akan dikirimkan ke ponsel tujuan.

MMSC perlu mengetahui tipe posel dari pengguna yaitu orang yang akan menerima MMS. MMSC dapat mengetahui dengan melihat HTTP request header yaitu pada header UserAgent atau UAProf. Atau jika database subscriber profile tersedia, MMSC dapat melakukan request untuk meminta data tipe ponsel pengguna.

Setelah mengetahui tipe atau kemampuan (capability) ponsel maka MMSC dapat melakukan transcoding ke bentuk file yang di-suport oleh ponsel penerima.

OMA mambuat standar/spesifikasi antarmuka (interface) yaitu dinamakan STI (Standard Transcoding Interface) yang digunakan elemen yang membutuhkan proses transcoding (misalnya MMSC) dengan elemen yang melakukan transcoding (transcoder). Hal ini diperlukan agar operabilitas antar elemen dari vendor yang berbeda dapat dicapai dengan mudah.

STI menggunakan SOAP lewat HTTP sebagai dasar protokol transaksi. Proses komukasi pada STI digambarkan sebagai berikut

+---------+ +------------+
| |----request--->| |
| MMSC | | Transcoder |
| |<---response---| |
+---------+ +------------+


Sebuah request terdiri dari bagian yaitu
  • source yaitu objek media yang akan di-transcode dan informasi tentang objek tersebut misalnya format, resolusi, dan lain-lain.
  • target yaitu informasi hasil objek yang diinginkan misalnya format, resolusi, bitrate, codec, size atau tipe handset

Objek media yang akan di-transcode sendiri dapat disertakan dalam SOAP message sebagai SOAP attachment atau hanya referensi ke objek eksternal yang alamatnya ditulis di SOAP message.

Dalam sebuah request dapat memiliki beberapa perintah (job) untuk melakukan transcoding dan request juga dapat memiliki beberapa attachment objek media.

Object media hasil sebuah proses transcoding juga dapat di-attach pada SOAP message maupun disimpan dalam remote content storage.

Application platform Transcoding platform Remote content
==================== ==================== ==============
| | |
|---------request-------->| |
| |---------fetch--------->|
| |<-----------------------| | |----+ | | | transcode | | | | | | |<---+ | | |--------store---------->|
| |
|-----------------------fetch--------------------->|
|<-------------------------------------------------| | |

Lebih jelas tentang OMA STI dapat dibaca pada dokumen spesifikasi berikut yang dapat di download di sini

  • Architecture of the Standard Transcoding Interface
  • Req Doc Standard Transcoding Interface Requirements
  • Specifications Standard Transcoding Interface Specification
  • Schemas Standard Transcoding Interface Schema
Beberapa project open source yang mengimplementasikan OMA-STI

Standarisasi MMS

Standarisasi terpenting yang berhubungan dengan MMS adalah dari OMA/WAP Forum dan 3GPP, yaitu

- Dari OMA
- Dari 3GPP


Kedua standarisasi tersebut saling berhubungan. Spesifikasi 3GPP mereferensi kepada spesifikasi dari OMA.


OMA relese 3GPP release
------------------- -------------
WAPForum MMS1.0 3GPP Rel-99
OMA MMS 1.1 3GPP Rel-4
OMA MMS 1.2 3GPP Rel-5
OMA MMS 1.3 3GPP Rel-6

Versi terakhir dari MMS adalah MMS 1.3

Monday, June 16, 2008

Dua IPTV standar baru: Quality of Experience (QoE) dan performance monitoring

Disaat IPTV deployment sudah mulai banyak dilakukan standarisasi internasional untuk IPTV yang dilakukan ITU justru baru dimulai.

Mengutip berita ini, IPTV Global Standards Initiative (GSI) yang merupakan bagian dari ITU-T baru-baru ini mengeluarkan 2 standard untuk IPTV yaitu:

  • ITU-T Rec. G.1080 Quality of experience requirements for IPTV

    QoE didefinisikan sebagai the overall acceptability of an application or service, as perceived subjectively by the end-user



  • ITU-T Rec. G.1081 Performance monitoring for IPTV

    Standard ini penting untuk memberikan QoS/QoE yang lebih baik pada pelanggan/customer. Performance monitor akan membantu dalam

    • Menemukan kesalahan/error pada end-to-end system (system debugging)
    • pengecekan utilitas resource utilization dan the work load dari komponen sistem
    • Membandingkan nilai (metrics) performansi dengan deployment ditempat lain
    • Memberikan basis untuk model dari sistem
    • menemukan bottlenecks pada sistem
    • mengoptimasi jaringan IPTV
    • memastikan performansi sistem tidak menurun
Sebgai catatan, beberapa standarisasi IPTV juga sedang dibikin dan diharapkan akan difinalisasi dalam waktu dekat, yaitu:

  • IPTV services requirements
  • IPTV architecture
  • Service scenarios for IPTV
  • Quality of experience requirements for IPTV
  • Traffic management mechanism for the support of IPTV services
  • Application layer reliability error recovery mechanisms for IPTV
  • Performance monitoring for IPTV
  • IPTV security aspects
  • IPTV network control aspects
  • IPTV multicast frameworks
  • IPTV related protocols
  • Aspects of IPTV end system – terminal device
  • Aspects of home network supporting IPTV services
  • IPTV middleware, applications, and content platforms
  • Toolbox for content coding
  • IPTV middleware
  • Service navigation system
  • IPTV metadata
  • Standards for IPTV multimedia application platforms

Thursday, June 12, 2008

FTTx

FTTx merupakan teknologi akses jaringan tetap yang sekarang sedang 'hot'. hal ini ditunjukan dengan besarnya pangsa pasar, bersaingnya vendor-vendor telekomunikasi besar untuk menjual produk-produk dan layanan deployment FTTx serta banyak dibicarakannya FTTx pada media. Jadi saya coba menulis tentang FTTx ini.

Dengan berkembangnya internet (layanan berbasis IP) dan konektivitas broadband maka kebutuhan akan bandwith yang besar dengan kecepatan tinggi menjadi meningkat. Hal ini juga didorong oleh operator yang berusaha memberikan layanan baru untuk meninggkatkan keuntungannya. Operator maupun vendor telekomunikasi saat ini sedang giat-giatnya jualan produk maupun service seperti IPTV atau Cable TV/CATV, Video on Demand yang membutuhkan bandwith yang besar.

Saat ini jaringan ke rumah-rumah didominasi oleh jaringan kabel tetap (fixed wireline) yang menggunakan tembaga (cooper) yang memiliki kekurangan karena dianggap tidak dapat memberikan bandwith yang tinggi dibandingkan dengan kabel fiber optik. Karena hal itu orang mulai beralih ke teknologi kabel optik untuk mendapatkan bandwith yang lebih tinggi menggunakan teknologi FTTx (Fiber to the x) yaitu istilah generik yang digunakan untuk beberapa arsitektur jaringan fiber optik untuk telekomunikasi yang menggantikan jaringan kabel tembaga.

Catatan: Dalam berita ini, kabel tembaga dengan teknologi Dynamic Spectrum Management (DSM) kecepatannya dapat menyaingi fiber optik.

Beberapa arsitektur jaringan fiber optik tersebut adalah:

FTTH (Fiber to the Home)
FTTH adalah arsitektur jaringan kabel fiber optik dibuat hingga sampai ke rumah-rumah atau ruangan dimana teminal berada.


FTTB (Fiber to the Building)
Jaringan kabel optik (fiber) sampai pada gedung komersial atau tempat tinggal dan kemudian didistrubusikan ke masing-masing ruangan dengan jaringan kabel tembaga (kabel telepon atau kabel CAT 5e/6)


FTTP (Fiber to the Premises)
FTTP merupakan nama generik yang digunakan untuk istilah FTTB dan FTTH karena secara arsitektur FTTB dan FTTB sama.

FTTC (Fiber to the Curb)
Jaringan fiber dibuat sampai pada suatu titik pendistribusian (curb) yang berada sekitar 100 feet dari tempat pengguna berada. Dari curb ke rumah-rumah digunakan koneksi kabel tembaga. Curb biasanya melayani 8 sampai 24 pelanggan.

FTTN (Fiber to the Node/Neighborhood)
jaringan fibre dibuat sampai pada suatu node yang berupa kabinet berlokasi di pinggir jalan sehingga disebut juga FTTCab. Jarak antara titik pendistribusian dengan pelanggak pada FTTN lebih jauh dariapada FTTC. Jumlah pelanggan yang bisa dilayani juga lebih banyak biasanya sampe ratusan pelanggan. FTTN juga menggunakan kabel tembaga untuk koneksi dari kabinet ke rumah-rumah.


Jadi dapat disimpulkan bahwa inti perbedaan antara teknologi FTTx diatas adalah bagaimana kabel fiber optik disambungkan sedekat mungkin dengan terminal yang dimiliki pelanggan seperti diilustrasikan pada gambar berikut:


Gambar copyright dari telcordia.com

Catatan istilah:
  • OLT - Optical Line Terminal, yaitu alat (device) yang berada pada kantor pusat operator jaringan telekomunikasi.
  • ONU - Optical Network Unit, yaitu device yang berfungsi mengubah sinyal optik menjadi sinyal eleketrik untuk kemudian sinyal tersebut di-demultiplex agar dapat didistribusikan menggunakan kabel tembaga ke tempat pelanggan (premises).
  • ONT - Optical Network Terminal, yaitu device yang berfungsi untuk mengubah sinyal optik menjadi sinyal elektrik yang berada pada tempat pelanggan agar pelanggan. Device ini digunakan pada jaringan FTTH.

Tuesday, June 10, 2008

Mengimplementasikan OMA DRM

Dalam posting saya tentang Proteksi mobile content dengan OMA DRM, Edwin Junaidi menanyakan bagaimana mengimplementasikan OMA DRM ini pada websitenya.

Pada dasarnya mengimplementasikan OMA DRM sangatlah mudah jika kita mengerti pemrograman web dan mengerti protokol HTTP. Jadi yang diperlukan adalah membuat program atau library karena OMA DRM hanya sebuah spesifikasi (dokumen) tanpa memberikan lirary implementasinya.

Tapi jangan khawatir, cobalah cari library OMA DRM di google sehingga anda tidak perlu memprogram from the scratch. Dari hasil serching google beberapa free library yang bisa digunakan adalah:

Contoh Java servlet juga bisa anda dapatkan di Nokia Forum atau langsung download file ini: Content_Download_And_OMA_DRM_Examples_v2_2_en.zip

Monday, June 09, 2008

Pasar jaringan telekomunikasi bergerak di Indonesia masih menjanjikan

Berdasarkan report dari Light Reading, Indonesia masuk dalam urutan ke-3 dari pasar jaringan telekomunikasi bergerak yang ada di dunia setelah China dan India. Hal tersebut dilihat dari perkembangan subscriber tahun lalu (2007).

Indonesia juga dipandang merupakan pasar yang menantang karena secara geografis memiliki banyak pulau-pulang dan pegunungan. Selain itu layanan (service) yang diberikan pada pasar Indonesia juga cukup beragam dan cukup advance seperti diberitakan CDMA Development Group (CDG) bahwa Indonesia adalah negara dengan perkembangan paling cepat dalam menggunakan teknologi CDMA2000 dan memiliki paling banyak operator CDMA.

Tapi sayangnya pemilik modal dari operator telekomunikasi Indonesia adalah perusahaan-perusahaan luar seperti:

  • Temasek Holdings/SingTel/STT Telemedia (Singapore) yang memiliki saham di Telkomsel dan Indosat (sebelum dibeli oleh Qtel)
  • Hutchison Telecommunications International Ltd (Hongkong) yang memiliki saham di HCPT
  • Telekom Malaysia Bhd (Malaysia) dan Etisalat (United Arab Emirates) yang memiliki saham di Excelcomindo
  • Maxis Communications Bhd (Malaysia) dan Saudi Telecom Co. (STC) yang memiliki saham di NTS
  • Qtel (Qatar) yang memiliki saham di Indosat setelah membelinya dari STT Telemedia belum lama ini

Friday, June 06, 2008

Bearer Independent Call Control (BICC)

Bearer Independent Call Control (BICC) adalah protokol signaling pada jaringan telekomunikasi seperti halnya ISUP. BICC dibuat berdasarkan N-ISUP yang digunakan pada Narrowband-ISDN. BICC dispesifikasikan pada ITU-T Recommendation Q.1901 dan Q.1902.x


BICC memisahkan antara signaling plane dengan media plane (bearer connection control) sehingga signaling dapat melalui jalur yang berbeda dengan media plane hal ini berbeda dengan ISUP yang membawa baik call control maupun informasi bearer control.
Disebut bearer independent karena BICC dirancang untuk dapat digunakan pada berbgai macam teknologi tranfer misalnya IP, SS7, TDM atau ATM.

BICC Capability Set 2 atau CS2 yang spesifikasinya selesai tahun 2001, digunakan oleh 3GPP sebagai protokol pada UMTS release 4 dimana arsitekturnya menggunakan MSS (MSC Server System) dan MGW (Media Gateway). BICC digunakan untuk antar dua MSS yang berhubungan (Nc interface) sebagai pengganti ISUP. Selain itu BICC juga dapat membawa message APM (Application Transport Mechanism) yang digunakan untuk saling tukar informasi bearer dari suatu call. APM dapat membawa misalnya alamat dari virtual MGW (BNC-ID), Global Title dari MGW (BIWF), code dan juga informasi IP bearer seperti IP address dan port number.

Arsitektur jaringan network BICC terdiri dari beberapa node atau elemen yang disebut serving node (SN) yaitu

1. Interface Serving Node (ISN)
ISN merupakan gateway atau proxy antara jaringan tradisional PSTN/ISDN dengan jaringan BICC. ISN memiliki 3 fungsi penting yaitu:
  • Bearer Function (BF) yaitu merupakan media gateway yang mengkonversi sinyal data/voice/multimedia dari jaringan TDM yang digunakan PSTN/ISDN ke sinyal berbasis paket yang digunakan pada jaringan BICC.
  • Bearer Control Function (BCF) yaitu fungsi yang mengontrol atau memberikan informasi bearer
  • Call Serving Function (CSF) yaitu fungsi yang mengontrol panggilan yang pada jaringan PSTN/ISDN ditangani oleh ISUP
2. Transit Serving Node (TSN)
TSN merupakan node yang menangani BICC di dua sisi yang menghubungkan ISN dengan ISN/TSN atau ISN/TSN dengan GSN.

3. Gateway Serving Node (GSN)
GSN serupa dengan TSN yaitu menagani BICC di dua sisi yang menghubungkan ISN/TSN dengan GSN pada jaringan BICC lain.

SN bisa saja tanpa BCF, SN ini disebut Call Mediation Node (CMN). Gambar Network Functional Model dari BICC architecture dapat dilihat di dokumen ITU-T Rec Q.1902.1.

Dibawah ini adalah gambar BICC Network Architecture yang diimplementasikan pada UMTS release 4.



Nc interface biasanya mengunakan IP sebagai transport dengan SIGTRAN sebagai protokol ditasnya. BICC dibawa dengan dengan M3UA dan SCTP pada SIGTRAN.

.------------.
| BICC |
+------------+
| M3UA |
+------------+
| SCTP |
+------------+
| IP |
+------------+
| Ethernet |
'------------'

Interworking BICC dan ISUP pada MSC dipesifikasikan pada ITU recommendation Q.1912.1 (ISUP-BICC Interworking) dan Q.19.12.2 (Interworking between selected signalling systems and BICC).


Dibawah ini saya list rekomendasi ITU-T untuk BICC CS-2:

  • Q.1902.1, BICC CS2 Functional Description
  • Q.1902.2, BICC CS2 General functions of messages and signals
  • Q.1902.3, Common Formats and Codes for BICC and ISUP
  • Q.1902.4, BICC protocol elements
  • Q.1902.5, Exceptions to APM in the context of BICC
  • Q.19xx.1, Interworking between BICC and ISUP
  • Q.19xx.2, Interworking between ISUP compatible signalling systems and the BICC protocol
  • Q.19xx.3, Interworking between the H.225.0 Multimedia Call Control protocol in an H.323 network and the BICC protocol
  • Q.19xx.4, Interworking DSS 2 to BICC
  • Q.19xy, Interaction between the INAP protocol and the BICC protocol
  • Q.ibcp, BICC IP Bearer Control Protocol
  • Q.cbc, Call and Bearer Control Protocol
  • Annex E to Q.1901, Signalling Transport Convergence for SCTP

Thursday, June 05, 2008

Provider Backbone Transport (PBT): Teknologi Ethernet untuk jaringan metro

Saat ini teknologi carrier-ethernet sedang mulai booming, hal ini didorong oleh semakin berkembangnya teknologi telekomunikasi dan internet yang mengarah pada konvergensi teknologi menggunakan komunikasi berbasis paket (packet-based). Teknologi Ethernet (IEEE 802.3) menjadi favorit karena relatif murah, mudah digunakan dan dapat memberikan bandwith yang cukup besar. Ethernet juga telah banyak digunakan terutama pada jaringan komputer (LAN).


Istilah PBT (Provider Backbone Transport) diperkenalkan oleh Nortel Networks dan British Telecom Group pada tahun 1996 sebagai sebuah produk atau teknologi baru untuk koneksi Ethernet yang disebut-sebut sebagai teknologi carrier-class. Carrier-class maksudnya adalah teknologi berkelas provider jaringan telekomunikasi (carrier) yang berarti memiliki QoS (Quality of Service) yang baik dan berkecepatan tinggi sehingga dapat digunakan untuk Metro Area Networks (MAN) atau disebut juga jaringan metro.

Secara ringkas kebutuhan dari jaringan metro diantaranya adalah:

- Infrastruktur yang efisien dan dapat melayani aplikasi packet data, voice, video
- Minimal biaya implementasi
- Kualitas yang tinggi dengan memaksimalkan penggunaan fasilitas yang ada
- Meminimalkan biaya operasional
- Memberikan Service Level Agreement (SLA)
- Meminimalkan masalah kompabilitas dengan teknologi yang sudah dipakai (backward compability issue)

Semua kebutuhan tersebut mendasari teknologi PBT.

Jaringan PBT terdiri dari Provider Backbone Bridge (PBB) yang distandarisasi pada IEEE 802.1ah disebut juga Mac-in-Mac atau MinM. Teknologi MAC-in-MAC menggunakan konsep VLAN tagging seperti yang digunakan pada teknologi Q-in-Q (IEEE 802.1ad). Kelebihannya dibanding QinQ adalah PBB dapat menangani lebih banyak (jutaan) layanan (service).

PBT beroperasi dengan cara memberikan konfigurasi routing pada Provider Backbone Bridged Network. Kemudian, provider dapat membuat trunk (jalur) maupun layanan untukkoneksi point-to-point pada jaringan Ethernet dengan sistem provisioning dan manajemen yang dimiliki PBT. Sebuah trunk didefinisikan dengan menggunakan VLAN ID dan pasangan alamat sumber serta alamat tujuan.

Berikut adalah gambar perbandingan beberapa paket Ethernet, termasuk paket Ethernet pada PBB.

Gambar diadopsi dari situs ini

PBB-TE (Provider Backbone Bridge – Traffic Engineering) merupakan standarisasi dari PBT dengan beberapa pengembangan (enhancement). PBB-TE didefinisikan pada standard IEEE 802.1Qay.

PBT/PBB-TE pada dasarnya memisahkan antara service layer dari Ethernet dengan network layer atau tunnel layer sehingga dapat provider dapat membuat point-to-point Ethernet tunnel yang bisa digunakan untuk mendeliver service apapun. PBT juga menghilangkan beberapa konsep yang terdapat pada Ethernet seperti flooding atau broadcasting, spanning tree protocol (STP) dan MAC address learning sehingga mengurangi kompleksitas.

Sebagai catatan, teknologi ini bersaing dengan T-MPLS yang distandarisasi oleh ITU, tapi kemudian T-MPLS dikembangkan lagi oleh ITU dan IETF menjadi teknologi yang disebut MPLS Transport Profile (MPLS-TP).

Lebih lanjut tentang PBT ini dapat anda baca di artikel berikut ini:
atau baca juga slide ini dan ini.

Oracle AWR & ADDM report

Sebelum Oracle versi 10g, kita dapat menggunakan statpack untuk melihat report performansi database. Tapi sejak database Oracle versi 10g, kita dapat dengan mudah menggunakan AWR ((Advanced Workload Repository) report untuk melakukan tuning performance dan melakukan analisis terhadap masalah yang ada dalam sistem
database.

Untuk membuat AWR report sangat mudah, tinggal eksekusi script awrrpti.sql kemudian ikuti perintahnya:


oracle$ sqlplus / as sysdba
SQL> @$ORACLE_HOME/rdbms/admin/awrrpti.sql




Setiap database biasanya secara default melakukan snapshot dari performansi sistem setiap satu jam sekali dan kemudian menyimpannya dalam repository statistik. Repository tersebutlah yang digunakan untuk membuat AWR report.

AWR dapat dibuat berdasarkan satu atau beberapa snapshot. Contoh list snapshot yang bisa dipilih ketika akan men-generate AWR report.

                                                           Snap
Instance DB Name Snap Id Snap Started Level
------------ ------------ --------- ------------------ -----
mydb1 MYDB 14897 15 Apr 2007 22:00 1
14898 15 Apr 2007 23:00 1
14899 16 Apr 2007 00:00 1



Kita dapat juga melakukan snapshot secara manual kapanpun diinginakan dengan perintah berikut


oracle$ sqlplus / as sysdba
SQL> exec dbms_workload_repository.create_snapshot;



Referensi:



Selain AWR, tool yang penting untuk mengecek atau menganalisis performansi adalah ADDM (Automated Database Diagnostic Monitor), yang memberikan saran untuk tuning pada sistem database misalnya

  • CPU bottlenecks
  • Undersized Memory Structures
  • I/O capacity issues
  • Beban (load) yang tinggi pada SQL statements, kompilasi dan eksekusi PL/SQL atau Java
  • Masalah pada cluster (RAC)
  • Masalah yang berhubungan dengan aplikasi yang menggunakan database
  • Masalah pada konfigurasi database
  • Masalah concurrency (busy buffer)
  • Masalah pada object-object database lainnya.

Untuk menjadlankan ADDM gunakan perintah berikut:


oracle$ sqlplus / as sysdba
SQL> @$ORACLE_HOME/rdbms/admin/addmrpt.sql



Referensi:


Catatan: Kedua tools tersebut dapat digunakan lewat antarmuka web yaitu pada Oracle Enterprise Manager (OEM) console yang biasanya bisa diakses lewat URL

  http://localhost:5500/em

Link berikut berguna untuk menganalisis hasil ADDM:

Tuesday, June 03, 2008

Layanan telco semakin seperti internet

Saat ini dunia telekomunikasi (telco) sedang mulai mengembangkan berbagai layanan yang semakin seperti layanan yang kita dapatkan pada dunia internet. Value added service semakin dipandang sebagai alternatif perolehan keuntungan dan penarik untuk mendapatkan pelanggan baru yang cukup menjanjikan.

Telco memang sedang berjalan menuju arah telnologi informasi. Kita bisa lihat beberapa operator di Indonesia mulai berlomba-lomba berkerja sama dengan pihak ketiga untuk memberikan layanan lebih pada pelanggannya. Perusahan seperti Yahoo, bergerak cepat menggandeng beberapa operator besar di Indonesia sehingga layanan mesin pencarinya dapat kita temukan dihalam depan situs portal WAP milik operator.

Google sebagai sebuah perusahaan yang terkenal dengan inovasinya telah memerikan layanan aplikasi terbuka dan gratis bagi pengguna internet dan saat diprediksi akan menjadi pesaingan berat pada layanan mobile ditahun-tahun mendatang. Dianggap pesaing karena dimungkinkan Google akan memberikan layanan-layanan gratis yang sebenarnya ingin dimiliki oleh operator dan ingin diterapkan sebagai layanan berbayar. Disamping itu telco juga ingin menuju arah yang dilakukan Google yaitu inovatif, disuka banyak orang karena layanan gratisnya tapi tetap dapat menhasilkan keuntungan.

Monday, June 02, 2008

Pengenalan Parlay/OSA

Parlay merupakan nama sebuah group (konsorsium indrustri) yang berfokus untuk membuat application programming interface (API) untuk jaringan telepon (operator) sehingga mempermudah pembuatan service baru baik dalam jaringan operator itu sendiri maupun service yang diberikan oleh partner (service provider).

Parlay dibentuk awal tahun 1998 dengan anggotanya adalah British Telecommunications PLC (BT), Microsoft, Nortel, Siemens dan Ulticom. Pada awalnya Parlay adalah organis tertutup untuk kemudian pada tahun 2000 keanggotaannya mulai terbuka dan sampai sekarang telah memiliki puluhan anggota termasuk vendor-vendor besar telekomunikasi maupun software.

IDE dari Parlay adalah untuk membuat standar interface yang terbuka sebagai protokol yang menghubungkan antara elemen network seperti SSF (Service Switching Function) dan SCF (Service Control Function) dan lain-lain dengan pihak lain (third party) sehingga mempermudah menambahan (deploy) service baru. API yang didesain tidak spesifik pada teknologi akses tertentu sehingga dapat direalisasikan atau dipetakan (mapping) pada teknologi yang spesifik seperti CORBA, Java, RPC, DCOM, Web service, dan lain-lain.

Spesifikasi Parlay tidak hanya memberikan sebuah interface standar tapi lebih dari itu Parlay menspesifikasikan sebuah framework yang mencakup security sehingga menjamin kemanan akses terhadap elemen yang dimiliki operator telekomunikasi juga service management.

Gambar dibawah ini menunjukan posisi Parlay dalam sebuah jaringan operator telekomunikasi.

+------------------------+
| Core Network Operator |
| |
| +--------+ +---------+ +-------------------+
| | Switch |<---->| Parlay |<====>| Service Provider |
| +--------+ | +---------+ +-------------------+
| | ^ |
| +--------+ | | |
| | IN |<---' | |
| +--------+ | |
| | |
| +-------------+ | |
| | Elemen lain |<---' |
| +-------------+ |
| |
+------------------------+


Spesifikasi API yang telah dibuat oleh Parlay pada akhir tahun 1999 diadopsi oleh ETSI dan 3GPP yang sedang mengembangkan OSA (Open Service Architecture). ETSI/3GPP melakukan penambahan minor pada Parlay tapi sejak Parlay rilis 3.0 atau OSA rilis 5, kedua bisa dibilang identik. Ada 2 interface yang tidak dicakup oleh OSA rilis 5 dari spesifikasi Parlay 3.0 yaitu policy management dan presence and availability (PAM).

Dibawah ini sejarah perkembangan spesifikasi Parlay:


  • Tahun 1999 mengeluarkan rilis 1.0
  • Tahun 1999 mengeluarkan rilis 1.1
  • Tahun 1999 mengeluarkan rilis 1.2 digunakan 3GPP sebagai spesifikasi OSA rilis 99
  • Tahun 2000 mengeluarkan rilis 2.0
  • Awal tahun 2001 mengeluarkan rilis 2.1 digunakan 3GPP sebagai spesifikasi OSA rilis
  • Desember 2001 mengeluarkan rilis 3.0 yang identik dengan 3GPP OSA rilis 5 sehingga sering ditulis Parlay/OSA.
  • Mei 2003 mengeluarkan Parlay X versi 1 yaitu web service interface.

Saat ini versi terakhir dari Parlay adalah versi 6.0. Pada 3GPP spesifikasi tersebut dapat ditemukan pada TS 29.198 Release 7.

Semua versi spesifikasi dapat didownload disini atau di website ETSI.


Dalam dokumen spesifikasi Parlay/OSA dibagi dalam beberapa grup interface yaitu:

  1. Call Control. yang terdiri dari 5 sub bagian yaitu:
    • Call Control Common Definitions
    • Generic Call Control
    • Multi-Party Call Control
    • Multi-Media Call Control
    • Conference Call Control
  2. User Interaction
  3. Mobility
  4. Terminal Capabilities
  5. Data Session Control
  6. Generic Messaging
  7. Connectivity Manager
  8. Account Management
  9. Charging
  10. Policy Management
  11. Presence and Availability Management
  12. Multi-Media Messaging
  13. Service Broker

Followers