BAB IV ANALISA HANDOVER PADA MSC

Ukuran: px

Mulai penontonan dengan halaman:

Download "BAB IV ANALISA HANDOVER PADA MSC"

Veronika Setiawan
6 tahun lalu
Tontonan:

1 BAB IV ANALISA HANDOVER PADA MSC 4.1 Topologi Jaringan Dalam penelitian ini, peneliti mengambil studi kasus di Jaringan Selular PT. Telkomsel wilayah Sumbagut. Dalam studi kasus ini terjadi permasalahan mengenai kurang optimalnya Handover dari MSC 3G ke MSC 2G. o Tabel 4.1 Informasi Node Element Informasi dari masing-masing Node Element adalah sebagai berikut: Node ID SPC GT Address Vendor MSPMS1 [3G] Ericsson MMDN2 [2G] Siemens STPMDN N/A NSN STPMDN N/A NSN RNMDN1 [3G] 6430 N/A Ericsson BTMDN3 [2G] 6218 N/A Ericsson Topologi jaringan yang mencakup node-node tersebut adalah sebagaimana gambar berikut. STP2 STP3 MSPMS1 MMDN2 MGMDN 1 RNM DN1 BSC Signaling Tapping Point Signaling Connection Payload Gambar 4.1 Topologi Jaringan 25

4.2 Analisa Tingkat Keberhasilan Handover Untuk menghitung tingkat keberhasilan dari MSC Handover dari 3G ke 2G, data statistik diambil dari MSPMS1 sejak tanggal 1 Desember 2009 sampai 14 Desember

2 4.2 Analisa Tingkat Keberhasilan Handover Untuk menghitung tingkat keberhasilan dari MSC Handover dari 3G ke 2G, data statistik diambil dari MSPMS1 sejak tanggal 1 Desember 2009 sampai 14 Desember 2009 sebagaimana tabel berikut. Tabel 4.2 Tingkat keberhasilan MSC-Handover dari 3G ke 2G (before) Dengan menggunakan rumus baku HOSR tingkat keberhasilan di atas maka dapat diketahui tingkat keberhasilan sebagaimana rumus berikut. HOSR= ( ) x 100% = 66.6 % ( ) Gambar 4.2 MSC HO 3G ke 2G, MSPMS1 ke MMDN2 26

3 4.3 Analisa Permasalahan Ketersediaan Kanal Proses Handover ini memerlukan ketersediaan kanal dari MSPMS1/MGMDN1 ke arah MMDN2. - Trunk Route - SAE - Signaling link HO bermasalah maka pengecekan dari sudut pandang dimensioning harus di lakukan terlebih dahulu. Tapi untuk kasus diatas terlihat tidak ada masalah dari sisi dimensioning karna MSC HO hanya bermasalah dari MSPMS1 ke MMDN1 dan MMDN2. Disarankan juga untuk memeriksa apakah terjadi congestion pada salah satu Signalling route. Dari data-data di atas terlihat bahwa ketersediaan kanal bukan merupakan permasalahan Data Konfigurasi Data konfigurasi yang berkaitan dengan proses MSC Handover yang harus didefinisikan di MSC adalah sebagai berikut: Memastikan neighbouring target MSC/BSC sudah dibuat. Memastikan alamat Global Title MSC harus konsisten disemua MSC. Memastikan routing data dan HO number series untuk MSC HO sudah terdifinisi dengan benar. Memastikan software routes untuk Inter-MSC HO sudah dengan benar. Memastikan orriginating cell harus di definisikan sebagai internal cell di BSC asal dan sebagai inner cells di MSC asal. Memastikan target cell harus di definisikan sebagai internal cell di target BSC, sebagai inner cell di target MSC, sebagai external cell di originating BSC and sebagai outer cell di target MSC. Memastikan parameter cell harus konsisten antara definisi cell secara internal di origin BSC dan di inner cell di target MSC, definisi outer cell di originating MSC dan external cell definisi di originating BSC. 27

4 Memastikan CGI (Cell Global Identity) dari originating cell harus di definisikan dengan konsisten pada definisi internal cell di origin BSC dan di definisi internal cell di origin MSC. Memastikan CGI dari originating cell harus di definisikan dengan konsisten di internal cell pada origin BSC dan pada definisi inner cell di origin MSC. Memastikan neighbour cell relation harus di definisikan di BSC asal. Dari data konfigurasi di atas terlihat bahwa semua data konfigurasi yang terkait sudah didefinisikan dengan benar. Untuk itu perlu dilakukan investigasi lebih lanjut dengan melakukan signaling trace antara kedua MSC Signaling Trace Untuk mendapatkan informasi lebih detail mengenai masalah yang terjadi, maka diperlukan untuk melakukan signaling tapping pada interface berikut: - Ns interface (antar MSC) - A interface (MSC BSC) STP2 STP3 MSPM S1 MMDN 2 RNM DN1 BTM DN3 Signaling Tapping Point SignalingConnection Gambar 4.3 Topologi Jaringan 28

5 Dari hasil signaling trace tersebut dapat diketahui proses yang terjadi seperti berikut: 1. MSPMS1 mngirimkan MAP HO Preparation Request ke arah MMDN2 melalui STMDN2. MAP HO ini dikirim menggunakan protokol SCCP connection oriented dengan beberapa type format: a. UDT: jika SCCP user data nya lebih kecil dari 228 octet b. XUDT : jika SCCP user data nya lebih besar dari 228 octet 2. STPMDN2 akan meneruskan MAP HO Preparation Request tersebut kearah MMDN2 tanpa melakukan perubahan 3. MMDN2 akan mengirimkan BSSMAP HO request ke arah BSC. BSSMAP ini dikirimkan menggunakan protocol SCCP connection oriented dengan skenario sebagai berikut: a. MMDN2 mengirimkan BSSMAP HO request dalam protokol SCCP dengan tipe Connection Request (CR). CR ini mempunyai message length maksimum 225 octet. Message length 225 octet ini akan terjadi jika MAP HO Preparation Request mencapai 240 octet. Jadi BSSMAP HO request dalam protokol SCCP dengan tipe CR hanya akan berlaku untuk MAP HO Preparation Request yang message lengthnya kurang dari 240 octet. b. MMDN2 mengirimkan CR kosong (tanpa aplikasi) ke arah BSC sebelum mengirimkan BSSMAP HO request. Hal ini disebabkan oleh BSSMAP HO request yang terlalu panjang sehingga tidak cukup untuk dimasukan kedalam Connection Request (CR). Hal ini akan terjadi jika MAP HO Preparation Request mencapai lebih dari atau sama dengan 240 octet. 29

6 4. BSC merespon BSSMAP HO request yang dikirim oleh MMDN2 dengan dua perilaku yang berdeda. a. BSC akan mengirimkan BSSMAP HO Acknowledge dalam protokol SCCP dengan tipe Connection Confirm (CC) untuk BSSMAP HO request yang dikirimkan oleh MMDN2 sebagaimana dijelaskan pada point 3a diatas. Sehingga proses HO bisa diteruskan ke proses berikutnya. Gambar 4.4 Urutan BSSMAP-HO yang sukses b. BSC tidak mengirimkan respon apapun terhadap CR kosong yang dikirimkan oleh MMDN2 sebagaimana yang dijelaskan pada point 3b diatas. Hal ini menyebabkan terjadinya time-out di MMDN2 setelah menunggu respon dari BMDN3 selama 6 detik dan akan mengirimkan MAP system failure ke MSPMS1 yang mengakibatkan gagalnya proses Handover. Gambar 4.5 Urutan BSSMAP-HO yang gagal 30

Proses ini bisa dilihat dari signaling trace antara MMDN2 dan BTMDN3 berikut. Dimana CR kosong yang dikirim MMDN2 tidak ada assosiasi ID yang menunjukkan respon dari BSC. Gambar 4.

7 Proses ini bisa dilihat dari signaling trace antara MMDN2 dan BTMDN3 berikut. Dimana CR kosong yang dikirim MMDN2 tidak ada assosiasi ID yang menunjukkan respon dari BSC. Gambar 4.6 Hasil dari BSSMAP-HO yang gagal Berdasarkan standard, CR kosong tersebut seharusnya direspon BMDN3 dengan menggunakan Connection Confirm (CC) dan diikuti pengiriman BSSMAP HO request dalam format DT1. Berikut merupakan proses yang sesuai standard: Gambar 4.7 Standar CR Kosong Dari analisa signaling trace diatas dapat dilihat bahwa: BTMDN3 tidak dapat meresponse CR kosong yang dikirimkan oleh MMDN2, dimana CR kosong ini adalah implementasi yang sesuai dengan standard. 31

BTMDN3 mempunyai software release R6a yang mempunyai limitasi minimum message length untuk CR yaitu lebih dari 10 octet. Sementara CR kosong yang diterima dari MMDN2 mempunya meesage length 7 octet.

8 BTMDN3 mempunyai software release R6a yang mempunyai limitasi minimum message length untuk CR yaitu lebih dari 10 octet. Sementara CR kosong yang diterima dari MMDN2 mempunya meesage length 7 octet. Solusi untuk kasus diatas adalah dengan melakukan software correction disisi BSC yaitu oleh Ericsson sebagai provider. Software correction ini (NWBYJ-0604) akan menghilangkan limitasi tersebut. 4.4 Implementasi dan Verifikasi Setelah software correction dilakukan BSC sudah bisa merespon CR kosong yang dikirimkan oleh MMDN2 sebagaimana sudah dijelaskan pada Gambar 4.5 diatas. Hal ini bisa dilihat dari hasil signaling trace berikut: Gambar 4.8 Signaling Trace untuk CR kosong yang di respon 32

Untuk melihat pengaruh terhadap tingkat keberhasilan dari handover setelah dilakukan software correction, maka data statistik dari MSPMS1 diambil

3 Tingkat keberhasilan MSC-Handover dari 3G ke 2G (after) Dengan menggunakan rumus baku HOSR tingkat keberhasilan di atas maka dapat diketahui tingkat

9 Untuk melihat pengaruh terhadap tingkat keberhasilan dari handover setelah dilakukan software correction, maka data statistik dari MSPMS1 diambil sebagaimana berikut: Tabel 4.3 Tingkat keberhasilan MSC-Handover dari 3G ke 2G (after) Dengan menggunakan rumus baku HOSR tingkat keberhasilan di atas maka dapat diketahui tingkat keberhasilan sebagaimana rumus berikut. HOSR= ( ) x 100% = 89.4 % ( ) Dapat dilihat bahwa tingkat keberhasilan untuk Handover 3G ke 2G dari MSPMS1 ke MMDN2 mengalami peningkatan menjadi 89.4%, target tercapai. Gambar 4.9 MSC HO 3G ke 2G, MSPMS1 ke MMDN2 33

dokumen-dokumen yang mirip

BAB III METODOLOGI. beragam menyebabkan network administrator perlu melakukan perancangan. suatu jaringan dapat membantu meningkatkan hal tersebut.

BAB III METODOLOGI. beragam menyebabkan network administrator perlu melakukan perancangan. suatu jaringan dapat membantu meningkatkan hal tersebut. BAB III METODOLOGI 3.1 Introduksi Kondisi jaringan yang semakin kompleks dan penggunaan aplikasi yang beragam menyebabkan network administrator perlu melakukan perancangan jaringan dengan performa yang