Ngitung Traffic (edisi dua)

 

Sistem WCDMA

Kalau sebelumnya sudah dibahas sistem GSM, sekarang kita coba di sistem WCDMA. Nah yang ini agak-agak njlimet memang. Karena berbeda dengan GSM yang sudah jelas kapasitas per TRx nya. Di dalam WCDMA tidak ada yang seperti itu, dimana diantara kapasitas, cakupan, dan kecepatan harus ada trade off yang pas. Karena masing-masing saling mempengaruhi.

 

Untuk menghitung coverage, pada prinsipnya sama dengan GSM, kita harus menghitung link budget untuk mendapatkan MAPL (Maximum Allowable Path Loss), hanya perbedaan yang mendasar:

1.      Ada beberapa parameter tambahan di system WCDMA (cari sendiri ya, biar gak males.. hihihihi..)

2.      Hitung uplink dan downlink, terus bandingkan dari keduanya ambil radius yang terkecil dari keduanya.

Untuk coverage dan link budget, serta pemodelan propagasinya butuh bahasan tersendiri karena sangat banyak.

 

Supaya lebih mempermudah lihat contoh kasus berikut ini:

Contoh:

Berapa jumlah cell yang harus di bangun untuk memenuhi permintaan pasar:

-          50 Pelanggan dengan kecepatan 144 Kbps

-          100 Pelanggan dengan kecepatan 64 Kbps

Untuk mempermudah, kita ambil formula yang sudah jadi (dengan berbagai standart dan asumsi parameter yang biasa di gunakan):

 

Bearer service	Eb/No(dB)	No [ή=50%]
12,2 kbps	4,8	27,1
64 kbps	2,4	9,06
144 kbps	1,7	4,79
384 kbps	0,4	2,5

 

(Training Material, “Total Solutions of 3G UMTS and Transmission Network Design”, April 2006)

         

Dari data di atas didapatkan:

Jumlah pelanggan total = 50 + 100 = 150

Maksimum pelanggan per cell (dari table diatas)

·          No untuk 144kbps = 4,79 user /cell

·          No untuk 64kbps = 9,06 user /cell

·           

Complete load untuk total 150 pelanggan

            = (2/3*9,06) + (1/3*4,79)

            = 7,64 user / cell

 

1 Km2 150 user => 150/7,64 = 19,63 Cell per km2

Anggap 1 Node B terdiri dari 3 Cell, artinya dibutuhkan 19,63/3 = 6,54 Node B (dibulatkan menjadi 7 node B!) untuk memenuhi demand pasar diatas.

 

Contoh lain Kasus dimensioning (capacity)

 

Data:

·          Total Subscriber           100000

·          BH mE/subs (voice)      25 mErlang

·          BH mE/subs (CS64)      5 mErlang

Asumsi lain

·          Jumlah data yang ditransfer tiap user/jam rata-rata = 700 kbyte/jam

 

Data umum UMTS (source from Ericsson)

Data jumlah kanal maksimum (Mpole) untuk uplink

 

Dengan menggunakan persamaan di atas didapatkan data sebagai berikut (kalau tidak percaya silakan dihitung sendiri.. J):

 

RAB	Pedesterian A
Speech 12,2 kbps	95
CS 64 kbps	14
PS 128 kbps	11

 

Data jumlah kanal maksimum (Mpole) untuk downlink

Dengan rumus diatas didapatkan

 

RAB	Pedesterian A
Speech 12,2 kbps	110
CS 64 kbps	14
PS 128 kbps	11

 

Langkah-langkah dimensioningnya (untuk uplink dulu ini yah..):

1.      Buat inisialisasi loading factornya

η = η(voice)  + η(RT data) + η(NRT data)

note. RT = Real Time

 

Ambil untuk inisialisasi awal η = 0,4

η = (Mspeech/Mmax,speech) + (Mcs64/Mmax,cs64) = 0,4

Cari angka untuk memenuhi loading faktor 0,4 misalkan:

Kanal suara (voice) = 17 kanal

Kanal CS64 = 3 kanal

η = (17/95) + (3/14) = 0,4

 

2.      Hitung kapasitas uplink

Dari data awal diatas, anggap:

1.      Kanal suara = 17 kanal

2.      Kanal CS64 = 3 kanal

Hitung kapasitas uplink, lihat dari tabel Erlang

Asumsi GOS untuk voice 2% dan CS64 = video call = GOS 5%

Dari tabel Erlang didapatkan

17 Kanal suara = 10,66 Erlang = 426 subscriber (@subscriber = 25 mErlang)

3 Kanal CS64 = 0.899 Erlang = 180 subscriber (@subscriber = 5 mErlang)

 

Misalkan dianggap 426 subscriber (voice) dan 180 subscriber (CS64) tidak seimbang, coba lagi sampai dirasakan seimbang antara voice dan CS64 nya.

Ambil 11 kanal suara dan 4 kanal CS64, didapatkan: 233 subscriber voice dan 305 subscriber untuk CS64.

 

3.      Hitung jumlah site yang diperlukan untuk memenuhi kapasitas Uplink

Asumsi 3 sektor/site, sehingga total jumlah sektor yang dibutuhkan adalah:

100000/233 = 429 sektor = 143 site.

 

4.      Hitung uplink coverage (MAPL)

Ini hitung sendiri ya, link budget dengan berbagai parameternya. (kalau sempat insya 4jJ1 saya bahas juga, plus tidak males.. hihihiih)

Nah dari perhitungan link budget, outputnya adalah MAPL (Maximum Allowable Path Loss), yaitu loss maksimum yang masih diijinkan oleh sistem.

 

5.      Hitung jumlah site yang dibutuhkan untuk memenuhi cakupan UL

Dari perhitungan no 4, masukkan ke dalam model propagasi yang sesuai. Ada berbagai pemodelan propagasi yang biasa di gunakan (tinggal disesuaikan dengan kondisi, ex frekuensi, urban atau rural, dsb).

Output dari pemodelan ini adalah jumlah site yang dibutuhkan..

Misalkan saja didapatkan nilai 52 sektor/18 site.

 

6.      Hitung iterasi selanjutnya jika dirasakan belum memuaskan (naikkan loading factor)

Dari step no (3) dan no (5) bandingkan, apakah seimbang atau nilainya njomplang. Kalau dianggap tidak seimbang, kita lakukan perhitungan ulang (iterasi) dari awal dengan cara “memainkan” factor loadingnya.

 

Misalkan kita naikkan loading faktor menjadi 60%, dengan cara yang sama seperti di atas didapatkan:

18 kanal suara = 11,5 E (dari tabel) = 460 subscriber voice (@subs = 25 mErlang)

6 kanal CS64 = 2,96 E (dari tabel) = 592 subscriber CS64 (@subs = 5 mErlang)

Kalau dianggap nilai diatas adalah seimbang, maka jumlah subscriber yang bisa didukung adalah 460 subscriber/sector.

 

Dimana jumlah sektor

100000/460 = 217 sektor = 73 site.

Note. Loading factor 60% dianggap maksimal untuk WCDMA (range antara 20% – 60%) dimana nilai yang direkomendasikan adalah 40%.

 

7.      Cek apakah volume data sesuai dengan kapasitas yang tersedia

ASUMSI Final:

18 kanal disediakan untuk voice

6 kanal disediakan untuk CS64

           

Beban server = (11,5/95) + (2,96/14) = 0,33

Maka, loading faktor yang tersedia untuk layanan lain (data) = 0,6 – 0,33 = 0,27

 

Mmax(128K) = 11

Beban sektor   = 11 x 0,27 x 128K x ( 3600/8 )

                        = 171 Mbyte / jam/sektor

 

Kalau jumlah subscriber = 500,

Demand aktual adalah 500 X 700 kbyte = 350 Mbyte/jam/sektor

 

Dari perhitungan diatas ternyata demand > beban yang mampu disediakan -> perlu penambahan site!

 

Lakukan hal yang sama untuk arah downlink, bagaimana Anda rekayasanya sehingga didapatkan hasil akhir yang balance antara uplink dan downlink.

 

Nah itulah sekilas, cara perhitungan traffik pada sistem WCDMA. Nilai-nilai paramater diatas hanya merupakan contoh, silakan dicoba sesuai dengan kondisi yang lebih real di masing-masing daerah.

 

Semoga membantu,

 

 

- Belajar Ngitung-ngitung Trafik -

- Belajar Ngitung-ngitung Trafik -

Edisi Satu

 

Di dalam dunia teknologi seluler, ada satu bahasan yang cukup menantang, yaitu dimensioning trafik! Dimana kita meramal jumlah pelanggan yang akan kita layani sampai beberapa tahun ke depan, sehingga bisa di rencanakan berapa jumlah Network Element yang harus dibangun oleh operator untuk melayani pelanggan tersebut. Memang tidak bisa “pas” seperti matematika, karena statistik yang dibicarakan disini. Oke, langsung aja kita coba bahas.

 

Artikel ini akan coba memberikan gambaran perhitungan traffik untuk sistem GSM dan WCDMA, dengan asumsi-asumsi yang biasa dipakai. Untuk saat ini saya tidak akan membahas terlebih dulu mengenai perhitungan Interface (Abis, Ater, IuPs atau IuCs dan sebagainya). Yang coba saya tekankan disini, baru sampai dimensioning RBS saja. (Semoga insya 4jJ1 next saya bisa bahas core network plus interface, karena saya juga mesti belajar dulu hihihihi..).

 

System GSM

Kita tahu bahwa GSM terdiri dari 8 time slot yang bisa diduduki oleh pelanggan. Misalnya ada satu BTS dengan konfigurasi 2/2/2 (3 sektor dengan masing-masing sektor terdiri dari 2 TRX =16 timeslot). Sehari-hari kita tidak hanya melakukan telepon, tapi juga SMS, artinya kita tidak hanya butuh kanal suara (TCH) namun juga butuh kanal signalling untuk mengakomodir SMS (menggunakan kanal SDCCH).

 

Typical value untuk tiap pelanggan yang dipakai dalam planning jaringan adalah:

TCH load          = 25 mErlang

SDCCH load     = 4 mErlang

 

Anggap kita sudah selesai melakukan evaluasi dan didapat hasilnya 14 timeslot dipakai untuk traffic dan 2 timeslot untuk signalling. Langkah berikutnya yang harus kita lakukan adalah melihat Tabel Erlang yang sudah disebut diatas.

 

 

Dari tabel Erlang tersebut kita lihat untuk jumlah kanal traffic sebanyak 14 dapat menghandle 8,2 Erlang untuk bisa mencapai GOS 2%.

 

Yang menjadi pertimbangan adalah, dalam desain kita banyak menggunakan asumsi-asumsi (syarat dan ketentuan berlaku), sebut saja pemodelan propagasi, link budget, kita menggunakan asumsi yang tentu masih bisa ditoleransi. Namun sebagai engineer kita tidak boleh “kaku”, artinya harus disesuaikan dulu dengan kondisi environment nya. Apalagi kalau kita perhatikan semua perhitungan dan asumsi yang digunakan diambil dari penelitian yang dilakukan diluar yang tentu kondisinya berbeda dengan daerah kita masing-masing. Memang perlu sedikit “dimodifikasi” kalau kita benar-benar ingin mendesain dengan baik. Hal ini sangat berdampak terhadap network, dan perlu diperhatikan ketika teman-teman mendesain (network planning).

 

Ambil contoh traffic pelanggan biasanya kita menggunakan = 25 mErlang. Tapi dengan kondisi seperti sekarang mungkin kita perlu membuat nilai yang lebih “realistis”.

 

Misal Operator BuTel (Bumi Telekomunikasi.inc) mempunyai produk sebagai berikut

Produk	Jumlah User	Holding Time	Call Attempt	Load Traffic
A	80	40 menit	1	53,33
B	20	3 menit	4	4
Total	100	43	5	57,33

Note. (Load traffic silakan cari sendiri darimana nilainya)

 

Dari tabel diatas didapat rata-rata traffic untuk masing-masing pelanggan adalah:

0,57 Erlang! (bandingkan dengan typical value yang biasa kita gunakan antara 25-35 mErlang). Artinya kalau kita mendesain masih dengan data yang lama, sementara pola pikir pelanggan sudah berubah, Network akan mengalami Overload.

 

Yang ujungnya adalah susah call, drop call, hingga Network Down, impactnya tentunya pelanggan tidak puas, pergi, dan (Operator BuTel tidak jadi didirikan.. hihihihi)

 

Next. Ngitung traffik system WCDMA

 

Bumi 4 Kg!!

Dikarenakan hancurnya baterai laptop saya, jd biar gambar yang berbicara..

Kompilasi Bumi

Have a nice day..

inad#pkp