Slide Title 2

Morbi quis tellus eu turpis lacinia pharetra non eget lectus. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Donec.

Slide Title 3

In ornare lacus sit amet est aliquet ac tincidunt tellus semper. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.

Kamis, 27 Februari 2014

Reparenting pada 2G/3G

Sering sekali ditemukan perencanaan reparenting maupun rehoming disisi operator telekomunikasi guna mengoptimalkan jaringan yang ada. Secara sederhana Reparenting padat eknologi 2G merupakan pemindahan koneksi MSC yang satu ke MSC yang lain, jadi  beberapa BSC yang misalnya di handle oleh MSC Aakan dpindahkan seluruhnya ke MSC B. Sedangkan  Rehoming perpindahan koneksi BSC, dimana beberapa BTS yang dihandle oleh BSC A akan dipindahkan ke BSC B misalnya. Agar lebih jelas perhatikan gambar di bawah:




Umumnya prosedur dalam melakukan reparenting pada operator punya flow proses tersendiri. Sebagai contoh tim OSS awalnya akan menginformasikan site-site mana saja yang akan dilakukan optimalisasi dengan rencana reparenting tersebut. Kemudian informasi tersebut akan diambil oleh tim BSS biasanya tim RND , lalu menginputkan informasi site yang akan di lakukan plan reparenting kedalam website yang terintegrasi dengan system billing.  Informasi tersebut diidentifikasikan dengan yang namanya CGI (Cell Global Identification). Apa itu CGI , coba lihat ilustrasi sebagai berikut :


CGI berisi 4 kumpulan angka, yang terdiri dari MCC, MNC, LAC dan CI.  Jika kita meninjau negara Indonesia maka semua operator akan memiliki nilai CGI yang diawali dengan MCC= 510 sebagai idenifikasi operator tersebut berada di Indonesia yang sudah distandardkan, sedangkan dalam menentukan tipe operatornya maka dibedakan pada MNCnya, misalkan untuk operator Telkomsel MNCnya =10, XL= 11, Indosat=01. Selanjutnya nilai LAC dan CI sepenuhnya di create oleh masing-masing operator.
Seperti yang dijelaskan dalam melakukan reparenting di butuhkan informasi CGI yang akan berubah. Misalkan akibat perpindahan MSC , CGI akan mengalami perubahan, namun umumnya  yang berubah hanya pada informasi LACnya saja.  Sebagai contoh CGI awal adalah: 510-10-67812-12345 ,akibat rencana reparenting maka CGI nya akan diubah menjadi  CGI baru: 510-10-67811-12345 .Berikut ilustrasi pada table inputan RND


Karena system Web tersebut terintegrasi dengan system billing , maka data tersebut akan diload dalam waktu tertentu agar data CGI di sisi Billing juga terupdate. Lalu pertanyaannya , apa hubungannya informasi CGI ini disisi Billing? . Umumnya CGI ini akan diolah operator dalam menentukan tariff pelanggan. Contoh kasarnya, misalkan pelanggan yang berada pada CGI 1 akan memiliki tariff telepon Rp.X/menit, sedangkan pelanggan yang berada pada CGI2  akan memiliki tariff telepon sebesar Rp Y/menit. Maka penting untuk mengupdate data CGI disisi billing karena berhubung langsung dengan pentarifan pelanggan. Dan database di sisi Billing secara otomatis melakukan update untuk plan reparenting.


Dalam case diatas saya coba ambil contoh CGI reparenting yang benar-benar baru, dalam artian CGI tersebut belum pernah dipakai disisi Billing, dimana CGI baru ini akan mereplace CGI yang lama, sehingga nantinya CGI yang lama tidak terpakai lagi. Ada kalanya kasus dilapangan, CGI plannya berupa  CGI yang pernah ada di system Billing, sehingga diperlukan logic yang mengidentifikasikan apakah CGI itu sudah pernah dipakai atau belum. Sehingga nantinya di dalam database tidak terjadi duplicate CGI yang bisa menyebabkan system Billing memiliki hasil ambiguitas dalam menentukan parameter CGI yang tepat dalam menghitung tariff pelanggan. Hal ini terjadi pada umumnya untuk BTS Mobile yang sering berpindah-pindah tempat bahkan kembali ke tempat asal.
Kembali lagi pada proses , Terlihat bahwa CGI plan telah terupdate walaupun CGI tersebut belum riil ada di lapangan. Selanjutnya tim RND akan request EWO ke tim engineering dalam hal melakukan Eksekusi terhadap CGI plan terebut dan activity repaenting tersebut umumnya dilakukan malam hari agar tidak begitu menggagu pelanggan eksisiting. Dan ketika selesai dieksekusi, maka tim OSS lapangan akan mengupdate CGI baru telah berhasil dilakukan dan database di Web RND akan terupdate dengan otomatis dengan adanya skema reconciliation terhadap kombinasi SiteID + CellName +CI  dan Billing akan terupdate pula dari informasi yang ada pada database Web RND .



Dan skema reparenting pun secara umum telah selesai dilakukan. Have a nice day! :)

0 komentar:

Posting Komentar