Anda di halaman 1dari 17

ATURAN IFHO/ SHIFTING

TRAFFIC
(in Bahasa)
Mencerdaskan kehidupan bangsa
Copyright@Ngayum2016
Sweet.arum@gmail.com
ATURAN IFHO/ SHIFTING TRAFFIC
• Semisal aturan dari operatornya seperti ini

• Bingung kan maksutnya apa?


• Jangan hanya main setting follow angkanya tapi ngga tau
maksutnya.. Ya kan??
• Ngoptim kalo tau basic filosofinya, mau diubah2 kaya apapun,
kita akan ngerti resultnya bakal gimana tanpa nunggu
monitoring result hourly besok. Sakti kan? :D

Copyright@Ngayum2016
BLINDHO U21 to U21
• U2 ke U2 blindho TRUE, Why? Jelas lah, kan
footprintnya sama. Jadi kalo mau lempar2an
F1 ke F2 U2100, atau sebaliknya, nggak usah
pake measure treshold (apalagi pake
compres2)
• Sehingga settingannya BLINDHO=TRUE

Copyright@Ngayum2016
BLINDHO U21 to U9 (atau sebaliknya)
• U2 ke U9 blindho FALSE, dan U9 ke U21 juga FALSE. Why?
Karena pertama: masalah footprint.
• Pertimbangan
– kita ngga bisa maen buang traffic dari U21 ke U9 karena U9 lebar
foot printnya, dia harus cover cell edge. Otomatis kalo misal dibuang
semua ke U9 ya shringking coverage U9nya.
– kita nggak bisa maen buang U9 ke U21 karena U21 bisa jadi congest
krn coveragenya kecil, lebih kecil dari U9, ostosmastis ya limited
power, limited footprint, limited resource, limited WBPP.
• Makanya pertimbangannya BLINDHO=FALSE. Supaya terukur
dan nggak sembarangan lempar traffic (soalnya kan beda
telapak. Gimanapun footprint U21<U9)

Copyright@Ngayum2016
HOCOVPRIO - 1
• kalo HOCOVPRIO=0 (OFF), berarti dia artinya:
setelan "coverage-based HO"nya mati,
maksutnya itu, dia ngga liat RSCPnya mau
bagus apa ngga, yang dia liat EcN0nya, kalo
EcN0nya mencukupi ya dia HO.
• kalo HOCOVPRIO nyala atau >0, berarti
artinya: dia HARUS liat RSCPnya, dan harus
bagus RSCPnya supaya triggered HO.

Copyright@Ngayum2016
HOCOVPRIO - 2
• U2 to U9 diset HOCOVPRIO 2. Artinya untuk melakukan IFHO, U2 kudu liat
coveragenya footprintnya si U9 dulu gimana, nahhh kalo di U9 nya RSCP bagus, ya
sudah IFHOin aja ke U9
• Nah kalo kondisi sebaliksnya, U9 to U2 diset HOCOVPRIO = 0, artinya setelan
"pengenalan" coverage utk HO dari U9 ke U21 mati, nah kalo mati, U9 akan lihat U21
berdasarkan quality, nah kalo U21 qualitynya bagus, artinya kan secara load sama
dengan U21 nggak digandulin traffic terlalu banyak, artinya "NO CONGESTION" atau
"RESOURCE MENCUKUPI“. Kalao sudah begitu, ya udin, silahkan U9 HO ke U21.
• Makanya HOCOVPRIOnya dibuat 0 (OFF) kalo dari U9 yang telapak besar ke U21 ke
telapak kecil. Mengingat U21 bakal congest kalo ditambahin traffic dari U9. Makanya,
U9 to U21 HOCOVPRIO=2, supaya U9 susah IFHO ke U21 (mencegah tambahan load di
U21).
– Note: kan traffic/load kalo gede, otomatis shrinking lah itu cell bordernyah, Nah apalagi
qualitynya, pasti ikut jelek juga. Inget RSSI kan berbanding terbalik sama EcN0, RSSI besar
otomatis EcN0 bakal kisut. Walaupun misal RSCPnya bagus banget (RSSI berbanding lurus sama
RSCP).

Copyright@Ngayum2016
IDLEQOFFSET2SN - 1
• IDLEQOFFSET2SN > IDLEQOFFSET1SN. itu
syarat awalnya.
• dan biasanya IDLEQOFFSET1SN = 0
• IDLEQOFFSET2SN biasanya diadjust untuk
balancing traffic (ngatur traffic) between U21
dan U9.

Copyright@Ngayum2016
IDLEQOFFSET2SN - 2
• IDLEQOFFSET2SN kalo minus artinya semua traffic gampang ke
situ (ke target).
• Jika U9 to U2 nilainya MINUS, Berarti artinya traffic dari U900
dibuangnya ke U2100 (Digampangin buang ke U2100 gitu deh)
• Misal gini (ini misal, perbandingannya nggak gini juga):
– U900 100 = U2100 100 >>>> itu balance kan? itu IDLEQOFFSET2SN=0
– U900 80 = U2100 120 >>>> itu IDLEQOFFSET2SN=-2 (traffic dibuang ke
2100)
– U900 40 = U2100 160 >>>> itu IDLEQOFFSET2SN=-3 (traffic dibuang
makin banyak ke 2100)
– U900 10 = U2100 190 >>>> itu IDLEQOFFSET2SN=-5 (traffic dibuang
makin banyak ke 2100)

Copyright@Ngayum2016
IDLEQOFFSET2SN - 3
• IDLEQOFFSET2SN kalo plus artinya semua traffic
di keep di source.
• Misal gini yak
– U900 120 = U2100 80 >>>> itu IDLEQOFFSET2SN=+2
(traffic di keep di U900)
– U900 160 = U2100 40 >>>> itu IDLEQOFFSET2SN=+3
(traffic makin di keep di U900)
– U900 190 = U2100 10 >>>> itu IDLEQOFFSET2SN=+5
(traffic makin di keep di U900)

Copyright@Ngayum2016
IDLEQOFFSET2SN – STUDY CASE - 1
• Sektor 1 dan 2 nggak balance usernya. Traffic
di U9 kecil banget (garis hijau), di U21 traffic
garang banget (garis biru dan merah).

Copyright@Ngayum2016
IDLEQOFFSET2SN – STUDY CASE - 2
• Kita buang semua traffic ke U9. Caranya ya traffic dibuang ke
U9 aja sebagian. IDLEQOFFSET2SN U9 ke U21 dibuat + (dikeep
di U9), IDLEQOFFSET2SN U21 ke U9 dibuat – (U21 ke U9).

Copyright@Ngayum2016
IDLEQOFFSET2SN – STUDY CASE - 3
• Bener kan, setelah dirun, all traffic terserap ke
U9. Tapi kan masih nggak balance. Harus ada
another adjustment.

Copyright@Ngayum2016
IDLEQOFFSET2SN – STUDY CASE - 4
• Balancing berarti tidak hanya masalah buang-buangan traffic.
Tapi ini masalah keseimbangan. Lalu supaya setimbang harus
gimana? Ya buat saja: Traffic gampang ke “U9” dan gampang
ke “U21”, beres :D

Copyright@Ngayum2016
IDLEQOFFSET2SN – STUDY CASE - 4
• Voila! Traffic balance:

Copyright@Ngayum2016
IDLEQOFFSET2SN – STUDY CASE - 5
• Traffic balance, CSSR juga improve:

Copyright@Ngayum2016
ATURAN TILTING U21 dan U9
• Sebaiknya U9 footprint dibiarkan > U21. Apalagi untuk
daerah city yang rata2 usernya punya HP support U9.
• Tapi jika harus di adjust, maksimalnya, U9 footprint sama
dengan U21 footprint. U9=U21.
• Cuma ada resikonya, kalo misalnya RET 2100 = RET U900,
SHO OH bakal tinggi (tapi CQI mostly jadi bagus).
• Sedangkan kalo RET 2100 < RET U900, SHO OH jadi bagus
(tapi CQI biasanya jelek).
• Namun yang diatas itu general case ya, kecuali kita ubah2
lagi HOCOVPRIOnya untuk setting decision dia boleh/nggak
HO.

Copyright@Ngayum2016
SEKIAN DULU YAKH
^__^

Copyright@Ngayum2016

Anda mungkin juga menyukai