TR201901420T4 - Yük Dengeleme İçin Kaynak Durumlarının Baz İstasyonları Arasında Sinyallenmesi. - Google Patents

Abstract

Bir mobil iletişim sistemi tanımlanmış olup, burada baz istasyonları birbirleri arasında bir Efendi(Master)/Köle(Slave) protokolü kullanmak suretiyle iletişim kurmaktadırlar ve bu sayede komşu baz istasyonları ve/veya komşu hücreler arasında mobil cihazların teslimi ile ilgili kullanılabilecek olan yük dengeleme bilgisi değişimi gerçekleştirebilmektedirler. Ana baz istasyonu, uydu baz istasyonundan bir yük durum raporunu belirli bir zaman veya periyotta veya belirli olayların ardından sağlamasını talep eder.

Description

TARIFNAME YÜK DENGELEME IÇIN KAYNAK DURUMLARININ BAZ ISTASYONLARI ARASINDA SINYALLENMESI Mevcut bulus mobil telekomünikasyon aglari ile ilgili olup, özellikle münhasiran olmasa da bilhassa 3GPP standartlarina veya bunun esdegeri veya türevlerine göre çalismakta olan aglarla ilgilidir. Bulus, münhasir olmamakla birlikte özellikle transfer sonrasinda UTRANHn (Evrimlesmis Evrensel Radyo Erisim Agi (E-UTRAN) olarak adlandirilir) Uzun Vadeli Evrimi (LTE) ile ilgilidir.

Bir mobil telefon aginda, az bulunan telsiz kaynaklarinin ve islem yükünün baz istasyonlari arasinda paylasimi için yük dengeleme gerekmektedir (E-UTRAN içerisinde eN BS olarak adlandirilir). Bu yük dengelemenin gerçeklesebilmesi için yük ölçümleri baz istasyonlarinda yapilir ve komsu baz istasyonlari ile paylasilir ve bu yolla yük dengeleme ile dengeleme mekanizmasi incelenmistir. Özellikle, RANl, etkin yük dengeleine için gereken fiziksel katman ölçümlerini tartismis ve yük dengeleme için uplink ve downlink'de fiziksel kaynak blogu ölçümlerinin yük dengeleme ile ilgili olduklarini kabul etmistir. Bu amaçla asagidaki dört farkli ölçümü önermislerdir: 1) UL üzerinde GBR (gerçek zamanli trafik) için fiziksel kaynak blogu kullanimi 2) UL üzerinde gerçek olmayan trafik için fiziksel kaynak blogu kullanimi 3) DL üzerinde GBR (gerçek zamanli) trafik için fiziksel kaynak blogu kullanimi 4) DL üzerinde gerçek zamanli olmayan trafik için fiziksel kaynak blogu kullanimi Tüm bu ölçümler, kullanilan Fiziksel Kaynak Bloklarinin (PRB'ler) bir orani (yüzde) olarak bir trafik türü için, ayni dogrultudaki mevcut PRB'ler üzerinden belirli bir zaman araligi üzerinden olacak sekilde tanimlamis ve hücre basina olacak sekilde ölçülmüstür.

Pro gramlanmamis herhangi bir ileti veya geri ileti, kullanilmis olarak kabul edilmelidir.

Ayrica, RAN 1 bu kontrolün periyodik olarak saniyeler ile dakikalar arasinda araliklarla, hatta yogun saatler gibi beklenen trafik dalgalanmalarina bagli olarak daha yavas Sikliklarda yapilmasinin yeterli olacagina inanmaktadir.

Yine de, yük dengelemesi için baz istasyonlari arasinda bu bilginin sinyalizasyonunun detaylari halen daha tanimlanmalidir.

Tekniginde uzman kisilerin daha iyi anlainasi için bulusun 3G sistemi baglaminda açiklanacak olmasina karsin, transfer prosedürlerinin ilkeleri diger sistemlere, örnegin mobil cihazlar ya da Kullanici Cihazinin (UE) bazi diger cihazlardan biri (eNBsye karsilik gelmektedir) iletisim kurdugu diger CDMA ya da kablosuz sistemlere uygulanabilir.

Turuncu; "LTE'de Trafik Yükü Raporlama Üzerine"; 3GPP R3-060426 komsu hücrelerin trafik yükünün, bu hücrelerden birisine bir aktarma gerçeklestirmek için karar verilirken dikkate alinmasi gerektigini anlatmaktadir. Doküman çesitli mekanizmalari ve hücre yük bilgisi raporlama ile ilgili farkli seçenekleri analiz eder ve bunlar arasinda yoklamali (veya talep üzerine) ölçüm raporlama da bulunmakta olup, burada bir ölçüm raporlamasi yoklamasi yapilabilmektedir, yani spesifik durumlarda bulunan bir dügüm tarafindan esdeger dügümden belirli bir zaman araliginda hiç bir ölçüm alinmadigi durumda ölçüm istenebilir: olay tetiklemeli modda mesaj kayip sayilmaktadir ve firsatçi modda hücre fazla dolu sayilmaktadir.

NTT DoCoMo; "Yük dengeleme hakkinda LS Yanitlama" 3GPP TASLAGI R ve gerçek zamanli olmayan trafik için kullanim dahil olmak üzere fiziksel kaynak blogu kullanimiyla ilgili bir dizi ölçümden bahseder.

Bu bulusun uygulamalari, bu ölçümlerin baz istasyonlari arasinda sinyallenrnesi için etkili teknikler saglamayi amaçlamaktadir. Mevcut bulus, baz istasyonlarini, bir haberlesme sistemini ve ekteki istemlerde tanimlandigi üzere baz istasyonlari tarafindan gerçeklestirilen yönteinleri saglamaktadir. Ekteki isteinlerin kapsamina girineyen asagidaki tarifnainenin uygulamalari ve/ veya örnekleri, mevcut bulusun bir parçasi olarak kabul edilmemektedir.

Bir örnege göre, bir EUTRAN baz istasyonu tarafindan uygulanan bir yöntem sunlari ihtiva eder: yük dengeleme ölçümleri için komsu EUTRAN baz istasyonuna bir talep gönderme; istenen kaynak durum bilgisine yanit olarak bir veya daha fazla kaynak durum güncelleme mesajlarini komsu EUTRAN baz istasyonlarindan almak; ve talep edilen bir veya daha fazla kaynak durum mesajina bagli olarak yük dengeleme islemlerini gerçeklestirmek.

Baz istasyonu, kendisi için yük dengeleme kullanabilir ve bunlari yük dengeleme islemlerini gerçeklestirmek için kullanabilir. Bu ölçümler dogrudan baz istasyonu yoluyla ölçülebilir.

Bir ya da daha fazla durum güncelleme mesajlari, gerçek zamanli fiziksel kaynak blogu kullanimini gerçek zamanli ve/veya gerçek zainanli olmayan trafik için uplink veya downlink için tanimlayacak veri içerebilir.

Talepte bulunan baz istasyonu, diger baz istasyonunun belirli bir zamanda, periyodik olarak veya bir veya daha fazla olaya cevap olarak durum güncellemeleri saglamasini talep edebilir. Olay, mesela bir kaynagin komsu baz istasyonu tarafindan kullaniminin belirli bir esik degeri asmasi ve/veya uplink arayüz seviyesinin belirli bir esik degerin üzerine çikmasi olabilir.

Talep, tercihen yük ölçümlerinin elde edildigi bir zaman araligini tanimlar. Buna ek olarak, komsu baz istasyonlari birden çok iliskili hücre içerdiginde, talep, ölçümlerin üzerinde gerçeklestirilmesini talep edecek sekilde bu hücrelerin bir alt küinesini tanimlayabilir.

Baz istasyonu, iliskili bir veya birden fazla mobil iletisim cihazinin bir baska hücreye veya baz istasyonuna devrini, bir veya birden fazla alinan kaynak durum güncelleme mesajina bagli olarak kontrol edebilir. Bu durumda sunu gerçeklestirebilir; örnegin, dinamik olarak Devir ve Hücre yeniden seçme parametrelerini, alinan bir veya birden fazla alinan kaynak durum güncelleme mesajina bagli olarak kontrol edebilir.

Bu örnek ayrica bir EUTRAN baz istasyonu tarafindan gerçeklestiren bir yöntemi saglamakta ve sunlari ihtiva etmektedir: kaynak durumu bilgisi ile ilgili komsu bir EUTRAN baz istasyonundan bir talep almak; bir veya birden fazla yük dengeleme ölçümlerini içerecek sekilde bir veya birden fazla kaynak durum güncelleme mesaji olusturmak; ve olusturulan bir veya birden fazla kaynak durum güncelleme mesajini talep sahibi baz istasyonuna göndermek.

Daha baska örnekler, yukaridaki yöntemlerin uygulanmasi için karsilik gelen baz istasyonlarini saglamaktadir.

Daha baska örnekler, açiklanan tüm yöntemler için, ilgili ekipman üzerinde uygulama için karsilikli bilgisayar programlari veya bilgisayar programi ürünleri, ekipmanin kendisi (kullanici ekipmanlari, dügümleri veya ilgili bilesenleri) ve ekipmanin güncellenmesi için yöntemleri içerinektedir.

Bu bulusun örnek bir uygulainasi, asagida açiklanan ilisikteki çizime atfen, örnek verilerek tanimlanacaktir: Sekil 1, örnek yapilanmanin uygulanabildigi türden bir mobil telekomünikasyon sistemini Sekil 2, Sekil llde gösterilen sisteinin bir parçasini olusturan bir baz istasyonunu sematik olarak göstermektedir; Sekil 3a, sematik olarak, iki baz istasyonu arasinda yük dengeleme ölçümlerinin sinyalizasyonu için bir sinyalizasyon yöntemini göstermektedir; Sekil 3b, seinatik olarak, iki baz istasyonu arasinda yük dengeleme ölçümlerinin sinyalizasyonu için bir baska sinyalizasyon yönteinini göstermektedir; ve Sekil 30, sematik olarak, iki baz istasyonu arasinda bir sinyalizasyon arizasi olmasi durumunu göstermektedir; Sekil 3d sematik olarak sona erme isleminin iki baz istasyonu arasinda sinyallenmesi için bir yolu göstermektedir; Sekil 4, bir baz istasyonu içerisinde yük bilgisinin, dinamik olarak Devir ve hücre seçim parametrelerini kontrol etmek için kullanilabilecek bir yolu göstermektedir; Sekil 5, sematik olarak basit bir kaynak durum güncelleme prosedürünü göstermektedir; Sekil 6, sematik olarak bir efendi (master) köle (slave) tabanli kaynak durum güncelleme prosedürünü göstermektedir; Sekil 7a, sematik olarak, kaynak durumu gibi bir ortak ölçümün güncelleme prosedürünü Sekil 7b, sematik olarak, kaynak durumu gibi bir ortak ölçümün güncelleme prosedürünü gösterir (basarisiz baslangiç); Sekil 70, sematik olarak, kaynak durumu gibi bir ortak ölçümün güncelleme prosedürünü gösterir (sona erdirme), Sekil 8, sematik olarak bir yük bilgi prosedürünü göstermektedir; ve Sekil 9, bir eNB içerisinde yük bilgisinin, dinamik olarak Devir ve hücre yeniden seçim parametrelerini kontrol etmek için kullanilabilecek bir mekanizmayi göstermektedir.

Genel Bakis Sekil 1, mobil telefon (MT) 3-0, 3-1 ve 3-2 kullanicilarinin diger kullanicilar ile (gösterilmemistir) baz istasyonlarini 5-1 ya da 5-2 ve bir telefon agini kullanarak iletisim kurabildikleri bir mobil (hücresel) telekomünikasyon sistemini sematik olarak göstermektedir. Mobil telefonlar 3 ve baz istasyonlari 5 arasindaki kablosuz baglanti için bir dizi uplink ve downlink iletisim kaynagi (alt tasiyicilar, zaman araliklari vb.) bulunmaktadir.

Bu örnek düzenlemede, baz istasyonu 5 her bir mobil telefona 3 downlink kaynaklarini, mobil telefona 3 iletilecek veri miktarina bagli olmak üzere tahsis eder. Benzer sekilde, baz istasyonu 5 uplink kaynaklarini her bir mobil telefona 3, bu mobil telefonun 3 baz istasyonuna 5 göndermesi gereken veri türlerinin sayisina bagli olarak tahsis eder.

Her bir baz istasyonu 5, çekirdek telefon agi 7 ile arayüz saglamasi için bir "Sl" arayüzü ile komsu baz istasyonlari 5 ile arayüz saglamasi için bir "X2" arayüzü içermektedir. Baz istasyonlari 5 tarafindan gerçeklestirilen yük dengeleme ölçümleri, X2 arayüzler üzerinden komsu baz istasyonlarina 5 gönderilir. Bu örnek teskil eden düzenlemede, ölçüm raporlari, baz istasyonlari arasinda bir Efendi(Master)/Köle(Slave) sinyalizasyon mekanizmasi kullanilarak iletilmektedir ve burada bir Efendi(l\/laster) baz istasyonu 5-1 bir Kö le(Slave) baz istasyonundan 5-2 ölçüm raporlarini önceden talep edilen bir format ve periyodik formda vb. göndermesini talep eder ve burada Köle(Slave) baz istasyonu 5-2 istendigi sekilde yanit verir. Her bir baz istasyonu 5, komsu baz istasyonlarindan 5 yük dengeleme bilgisi toplarken bir Efendi(Master) olarak davranir ve kendi yük dengeleme bilgisini, komsu baz istasyonuna 5 saglarken Köle(Slave) olarak davranir. Bu yolla, her bir baz istasyonu 5 istedigi yük dengeleme bilgisini, kendi istedigi periyotlarda ve istedigi formatta elde edebilir. Bu durum, farkli yapim baz istasyonlari arasinda birlikte çalisabilirligi kolaylastirir ve X2 arayüzü üzerinde gereksiz trafigi önemli ölçüde azaltir.

Baz Istasyonu Sekil 2, bu örnek yapida gösterilen her bir baz istasyonunun 5 ana bilesenlerini göstermektedir. Gösterildigi sekilde her bir baz istasyonu 5, i) mobil telefonlara 3 bir ya da daha fazla anten 23 araciligi ile; telefon agi 7 ile Sl arayüzü 24 ile; ve iii) diger baz istasyonlari 5 ile X2 arayüzü araciligi ile sinyal almaya ve bunlara sinyal göndermeye yarayan bir alici-verici devresi 21 içermektedir. Bellekte 29 depolanan yazilim uyarinca bir kontrolör 27, alici-verici devresinin 21 isleyisini denetler. Yazilim, diger seylerin yani sira bir isletim sistemini 31, bir yük dengeleme modülü 32, bir devir modülü 33 ve bir kaynak ölçüm modülü 34 içerir. Yük dengeleme modülü 32 bir kaynak durum talep modülü 35 içermekte olup, bu, diger baz istasyonlarina 5 durum taleplerini olusturmak, diger baz istasyonunda 5 yük ile ilgili bilgi talep etmektedir ve bunun yanisira talep edildigi zaman yük bilgisini diger baz istasyonlarina 5 saglamak üzere bir kaynak durum güncelleme modülü 36 içermektedir. Devir modülü 33, bir haz istasyonuna 5 veya bu baz istasyonundan mobil telefon 3 devir islemlerini kontrolden sorumludur. Kaynak ölçüm modülü 34 (kaynak durum güncelleme modülü 36 diger baz istasyonlarina 5 gönderilir) yukarida tartisilan yük bilgisini elde etmeden sorumludur (bu yük bilgisi diger baz istasyonlarina 5 kaynak durum güncelleme modülü 36 tarafindan yüklenmistir), ve bunu, asagidaki yollarla gerçeklestirir: l) UL üzerinde GBR (gerçek zairianli trafik) için fiziksel kaynak blogu kullanimi; 2) UL üzerinde gerçek olmayan trafik için fiziksel kaynak blogu kullanimi; 3) DL üzerinde GBR (gerçek zamanli) trafik için fiziksel kaynak blogu kullanimi; ve 4) DL üzerinde gerçek zamanli olinayan trafik için fiziksel kaynak blogu kullanimi.

Yukaridaki tarif içerisinde baz istasyonu 5, anlama kolayligi gereksinimi sebebiyle bir dizi ayri modüllere sahip olarak tanimlanmistir (yük dengeleme modülü, devir modülü, kaynak ölçüm modülü Vb. gibi). Bu sekilde, örnegin mevcut bir sistem üzerinde bulusu uygulamak için degisiklikler yapildiginda belirli uygulamalar için bu modüller saglanabilirken; diger uygulamalarda ise, örnegin en bastan itibaren bulusa iliskin özellikler akilda tutularak tasarlanan sistemlerde, bu modüller, genel isletim sistemi ya da kodu içinde insa edilebilir ve bu sekilde bu modüller, ayri bir birim olarak farkedilemez.

Yük Dengeleme - Sinyal Mekanizmasi Bu Sekil 3a içerisinde gösterilmis olan örnek teskil eden düzenlemede, baz istasyonu tercihe bagli olarak komsulari tarafindan talep edilmesi durumunda yük bilgisi saglamaktadir. Bir baz istasyonu 5-1, komsu bir haz istasyonundan 5-2 kendi istedigi formatta yük bilgisini göndermesini talep edebilir (talep sahibi baz istasyonuna 5-1 uygulanmis olan Telsiz Kaynak Yönetimi (RRM) algoritmasina bagli olarak). Örnegin talepte bulunan baz istasyonu 5-1 bir Kaynak Durum Talebi içerisinde (kaynak durum talep modülü tarafindan 35 olusturulan) komsu baz istasyonlarina 5-2 yük bilgisinin yalnizca bir defa mi, periyodik olarak mi veya bir olay ile tetiklenecek sekilde olay tahrikli mi olacagini belirtebilir. Talebi alan ve sonra uygun zamanda/olayda Kaynak Durum Güncellemesi içerisinde (Kaynak durum güncelleme modülü 36 tarafindan olusturulan) uygun sekilde yanit saglayan baz istasyonu 5-2 ile birlikte olan sistemde talep sahibi baz istasyonu 5-1 bir davranmaktadir. Kullanilan zamanlama Sekil 3a'da gösterilmektedir.

Kaynak Durum Talep Mesaji Detaylari Efendi(Master) baz istasyonu 5- 1, Köle(Slave) baz istasyonuna 5-2 bir Kaynak Durum Talebi gönderecek ve fiziksel kaynak blogu kullanimi bilgisini raporlamasini talep edecektir. Kaynak Durum Talebi bir Raporlama Karakteristik Bilgi Elementi (IE) içerecektir ve bu, raporun bir defa ini, veya periyodik olarak mi, yoksa olayin da belirtildigi sekilde olay tahrikli olarak mi gerçeklesecegini belirtecektir. Eger Raporlama Karakteristikleri IE ayarli degilse, bu yapilanmada, Köle(Slave) baz istasyonu, Kaynak Durum Güncelleinesini yalnizca bir defa göndermelidir.

Bu örnek yapilanmada, Kaynak Durum Güncellemesini durdurmak için ayri bir mesaj gerekmemektedir, bunun yerine Efendi(Master) baz istasyonu 5-1 ayni talep mesajini, Raporlama Karakteristik IE degeri sifira ayarli olarak gönderir. Köle(Slave) baz istasyonu -2 bu mesaji Kaynak Durum Güncelleme raporlamasinin durdurulmasi için bir talep olarak yorumlamali ve bu yorumlama islemini aninda gerçeklestirerek ilgili Kaynak Durum Güncelleme mesajinda benzer bir sifir degeri ile bu talebin alindigini bildirmelidir.

Kaynak Durum Talebi mesajinin olay tetiklemeli raporlamayi birden fazla olay için talep etmesi halinde, bu olaylar için esik degerleri de belirtebilir. Örnegin, bir Efendi(Master) baz istasyonu 5-1, bir Köle(Slave) baz istasyonundan 5-2 yaklasik olarak tikanikligi bildirecek sekilde Toplam Fiziksel Kaynak Blogu kullanimi %95 üzerinde oldugunda raporlama yapmasini talep edebilir. Benzer sekilde Köle(Slave)”den, downlink iletilen gücünün belirli bir esik degerin üzerine çikmasi durumunda raporlamasi istenebilir.

Bu Örnek yapilanmada, Efendi(Master) baz istasyonu 5-1 tarafindan olusturulan Kaynak Durum Talebi mesajlari, "Ortalama Süresi" içerebilir ve bu, Efendi(Master) baz istasyonu 5-1 tarafindan talep edilen bilgilerin olusturulmasi için ölçüm araligini belirtir. Bu deger belirtilmemisse, daha sonra Köle(Slave) baz istasyonu 5-2 varsayilan bir degeri geçerli sayacaktir.

Bu örnek yapilanmada, Efendi(Master) baz istasyonu 5-1 tarafindan olusturulan Kaynak Durum Talebi mesajlari, bir Raporlama Süresi içerebilir ve bu, Efendi(Master) baz istasyonunun dahili RRM algoritinasina bagli olarak bir periyodik raporlamayi belirtir. Bu deger belirtilmemisse, Köle(Slave) baz istasyonu 5-2 varsayilan bir degeri geçerli sayabilir.

Teknikte uzman kisilerce anlasilacagi gibi, her bir baz istasyonu 5 birden çok farli hücreyi kontrol edebilir ve bu yapilanmada Efendi(Master) baz istasyonu 5-1 tarafindan olusturulan Kaynak Durum Talebi mesaji, ihtiyaç duydugu kaynak yük bilgilerinin gelmesini istedigi hücre ID'lerini de içerebilir. Bu deger belirtilmemisse, Köle(Slave) baz istasyonu 5-2 tüm hücrelerin kaynak yük durumunu raporlar.

Kaynak Durum Güncelleme Mesaji Detaylari Bu örnek teskil eden düzenlemede, Kaynak Durum Güncelleme mesaji, raporlamanin sebebini belirtir bir Raporlama Karakteristikleri IE içermelidir. Raporlama Karakteristikleri kaynaklari veya herhangi baska türde isleme kaynagindaki tikanmayi belirtecek sekilde rezerve edilebilir. Tikanma göstergesi içeren bir Kaynak Durum Güncelleme mesaji, Köle(Slave) baz istasyonu 5-2 tarafindan otonom olarak, kendisinden tikanma tespit edildiginde Kaynak durum güncellemesi göndermesini talep eden bir komsu Efendi(Master) baz istasyonuna 5-1 gönderilebilir. Ayrica, Köle(Slave) baz istasyonu 5-2 otonom olarak tikaniklik giderildiginde bir Kaynak Durum Güncellemesi mesaji gönderebilir. Köle(Slave) baz istasyonu 5-2 tarafindan, kendi hücresi içerisindeki UL arayüzü belirli bir esigin üzerine çiktiginda Kaynak durum güncellemesi talep etmis olan bir komsu Efendi(Master) baz istasyonuna 5-1 bir Kaynak Durum Güncelleme mesajini otonom olarak gönderebilir ve rapora mevcut prosedür "Yük bilgisi" eslik eder.

Kaynak Durum Güncellemesi mesaji, Efendi(Master) baz istasyonu 5-1 tarafindan talep edilen gerekli ölçümleri de içerecektir: 1) Efendi(Master) baz istasyonu 5-1 tarafindan belirtilen Ortalama/Raporlama Süresi üzerinden UL üzerindeki gerçek zamanli trafik için Ortalamali Fiziksel kaynak blogu kullanimi; 2) Efendi(Master) baz istasyonu 5-1 tarafindan belirtilen Ortalama/Raporlama Süresi üzerinden UL üzerindeki gerçek zamanli olmayan trafik için Ortalamali Fiziksel kaynak blogu kullanimi; 3) Efendi(Master) baz istasyonu 5-1 tarafindan belirtilen Ortalama/Raporlama Süresi üzerinden DL üzerindeki gerçek zamanli trafik için Ortalamali Fiziksel kaynak blogu kullanimi; ve 4) Efendi(Master) baz istasyonu 5-1 tarafindan belirtilen Ortalama/Raporlama Süresi üzerinden DL üzerindeki gerçek zamanli olmayan trafik için Ortalamali Fiziksel kaynak blogu kullanimi.

Genel olarak, yukarida da belirtildigi gibi, her bir baz istasyonu 5 hem Efendi(Master) (Kaynak Durum Bilgisi isterken) ve Köle(Slave) (Kaynak Durumu Raporlari saglarken) rollerini üstlenebilir. Ancak, bir baz istasyonu 5 bir yük dengeleme algoritmasini uygulayamazsa ve bu durumda komsu baz istasyonlarina 5 Kaynak Durum Raporlarini saglama ile ilgili yalnizca bir Köle(Slave) olarak davranis gösterir ve bu, zorunlu olmasi düsünülebilir.

Alternatif bir örnek düzenlemede, daha sofistike bir prosedür bulunabilir ve burada Köle(Slave`) baz istasyonu 5-2 bir Kaynak Durum Talebine, Sekil 3b (basarili baslatma) ve Sekil 30 (Baslatma basarisiz) içerisinde gösterilen sekilde yanit verebilir. Baslatma basarisizligi, Köle(Slave) baz istasyonu 5-2 talep edilen ölçümleri desteklemedigi için söz konusu olabilir. Ancak, eger her bir baz istasyonu 5 için kaynak durum güncelleme mesajlarini diger komsu baz istasyonlarina 5 saglamak zorunlu ise, bu durumda böyle bir yanit/basarisizlik mesajina gereksinim kalmayabilir, buna ek olarak, bir pozitif durma veya sonlandirma mesaji Efendi(Master) ve Köle(Slave) baz istasyonlari 5 arasindaki sinyalizasyonun Sekil 3d içerisinde gösterildigi sekilde sonlandirilmasi için gönderilebilir.

Tekniginde uzman kisilerin anlayacagi üzere, yukarida bahsedilen sinyalizasyon ile birlikte, yük raporlama, Efendi(Master) baz istasyonu 5-1 tarafindan belirtilen raporlama periyodu tabaninda gerçeklestirilebilir, böylece, uygulamaya özel algoritmalarin farkli baz istasyonlarinda 5 çalistirildigi birden çok satici olan senaryoda bile Efendi(Master) baz istasyonunun 5-1 etkin bir sekilde alinan kaynak durum bilgilerini kullanmasi mümkün olur.

Ayrica, X2 arayüzü 25 üzerinden yedekli sinyalizasyon azaltilmis olur.

Yük Bilgi Prosedürü Mevcut durumda, 3GPP Standart dokümani TS 36.423 bir Yük Bilgi Prosedürü tanimlar ve bunun amaci uplink girisimi asiri yükleme göstergesini iç frekans komsu baz istasyonlari 5 arasinda girisim koordinasyon amaçlari için iletmektir. Baz istasyonu 5, UL içerisinde belirli kaynak bloklari üzerinde bir mobil telefonun hücre kenarinda UL verisi iletmek için yüksek güç kullanmasi sebebiyle çok yüksek girisim seviyesi durumuna maruz kaldiginda asiri yükleme göstergeleri gönderilir. Bu mesaji alan baz istasyonlari, temelde mobil telefondan 3 girisime neden olan UL iletim gücünü azaltmasini ister.

Bir baz istasyonu 5 bu prosedürü, iç frekans komsu baz istasyonlarina 5 bir yük bilgi mesaji gönderme ile baslatir. Yük Bilgi Prosedürü, girisim asiri yükleme göstergelerini, baz istasyonu 5 bazi kaynak bloklarinda asiri girisim seviyelerine maruz kaldiginda göndermek için kullanilir.

Yukarida açiklandigi sekilde Kaynak Durum güncelleme prosedürü, bu Yük Bilgi Prosedürünü içinde barindirabilir ve bunun için Kaynak Durum Güncelleme mesajlari otonom bir sekilde Köle baz istasyonu 5-2 tarafindan kaynak durum güncellemesi talebinde bulunan komsu Efendi(Master) baz istasyonlarina 5-1 gönderilebiliyor olmalidir ve ayrica bu UL girisimi, kendi hücresi içerisinde belirli bir esik degerin üzerine çiktiginda iç frekans aramalari yapabilir. Böyle bir birlesmis prosedür "Kaynak Durum Güncellemesi" veya "Yük Bilgi Prosedürü" isimlerinden uygun olani ile isimlendirilebilir.

Iliskili SON Fonksiyonelligi Baz istasyonu 5 tarafindan yukaridaki sekilde elde edilen yük bilgisi, dinamik olarak Teslim ve Hücre (yeniden-) seçim parametrelerinin kontrolü için kullanilabilir ve bu parametreler baz istasyonu 5 tarafindan bir dahili SON birimi tarafindan (kendinden organize bir Ag olup baz istasyonu 5 içerisinde RRM fonksiyonelligi saglar) kontrol edilen bir hücreye aittir. Diger bir deyisle, elde edilen yük bilgisi, baz istasyonunun 5, agin kapsama alani dahilinde dolasmakta olan bir mobil telefonun 5 hangi hücreye iletilmesi gerektigini kontrol etmek için kullanilabilir: Bu, Sekil 4 içerisinde gösterilmektedir.

Güncellenebilir hücre yeniden seçim parametreleri sunlari içermektedir: 1. Iç frekans yeniden seçim Öncelikleri 2. tabakaya özel ofset (Iç frekans durumuna bunun nasil uygulanacagi, bir FF S (daha ileri çalisma) olup, bu, hücrelerin siralamasina dayalidir.) Yapilandirilabilir Teslim parametreleri sunlari içermektedir: l . Histerezis 2. Tetikleme süresi 3. vb.

Degisiklikler ve Alternatiller Yukarida ayrintili bir yapi tarif edilmistir. Tekniginde uzman kisilerin takdir edecegi üzere, halen burada belirtilen bulustan yararlanmaya devam ederek yukaridaki yapida bir dizi degisiklik yapilabilir ve alternatifler kullanilabilir.

Yukaridaki örnek teskil eden düzenlemede, bir mobil telefona dayali telekomünikasyon sistemi tarif edilmistir. Tekniginde uzman kisiler tarafindan takdir edilecegi üzere mevcut basvuruda tarif edilen sinyalizasyon ve transfer teknikleri diger bir iletisim sisteminde kullanilabilir. Diger iletisim dügümleri ya da cihazlari, örnegin kisisel veri asistanlari, dizüstü bilgisayarlar, web tarayicilari gibi kullanici cihazlarini içerebilir.

Yukaridaki örnek yapilarda, bir dizi yazilim modülü tanimlanmistir. Tekniginde uzman kisilerin takdir edecegi üzere, yazilim modülleri derlenmis ya da derlenmemis halde sunulabilir ve baz istasyonu ya da mobil telefona bir bilgisayar agi üzerinden ya da bir kayit ortami üzerinde bir sinyal olarak saglanabilir. Ayrica, bu yazilimin bir bölümü ya da tamaminin yerine getirilmesi için islevsellik, bir ya da daha fazla özel donanim devreleri kullanilarak yerine getirilebilir. Bununla birlikte, islevselliklerinin güncelleninesi için baz istasyonunun 5 ve mobil telefonlarin 3 güncellestirilmesini kolaylastirmasi nedeniyle yazilim inodüllerinin kullanimi tercih edilmektedir. Çesitli diger modifikasyonlar teknikte uzman kisilerce anlasilacaktir ve burada daha detayli olarak tarif edilmeyecektir. 3GPP terimleri için kaynakça LTE - Uzun Vadeli Evrimlesme (UTRANiin) eNodeB - E-UTRAN Node B UE - Kullanici Cihazi- mobil iletisim cihazi DL - downlink - bazdan mobile link UL - uplink - mobilden baza link HO - Transfer RLC - Radyo Link Kontrol RRC - Radyo Kaynak Kontrol RRM - Radyo Kaynak Yönetimi SAE - Sistem Mimari Evrimlesmesi C-RNTI - Hücre-Radyo Agi Geçici Tanimlayicisi SIB - Sistem Bilgi Blogu U-düzlemi - Kullanici Düzlemi X2 Arayüzü - iki eNodeB arasindaki arayüz Sl Arayüzü - eNodeB ve MME arasinda arayüz TA -Izleme Alani AS - Erisim Katinani RNL - Telsiz Agi Katinani TNL 7 Ulastirma Agi Katmani RACH - Rastgele Erisim Kanali MU MIMO - Çoklu Kullanici Çoklu Giris Çoklu Çikis DM RS 7 Demodülasyon Referans Sinyal Formati MCS - Modülasyon ve Kodlama Semasi Asagida, mevcut bulusun öngöiülen 3GPP LTE standardinda uygulanabilecegi yolun ayrintili bir tarifi asagida verilmistir. Çesitli özelliklerin olmazsa olinaz ya da gerekli olarak tanimlaninasina karsin, bu Örnegin standardin getirdigi diger gereklilikler nedeniyle yalnizca öngörülen 3GPP LTE standardi durumunda geçerli olabilir. Bu beyanlar, dolayisiyla mevcut bulusu herhangi bir sekilde sinirlandirmak üzere yorumlanamaz.

RAN1#51 Bis toplantisinda yük dengeleme mekanizmasi incelenmistir. Bir yanit LS, bildirmek için gönderilmistir. Bu katkida, yük dengelemeyi gerçeklestirmek için, ilgili sinyalizasyon ile ilgili daha detayli bilgiler sunmaktayiz. Ölçümler Tanimlar RAN] içerisinde etkin yük dengeleme için gereken fiziksel katman ölçümlerini tartismis ve yük dengeleme için uplink ve downlink'de fiziksel kaynak blogu ölçümlerinin bu kullanma durumu ile ilgili olduklarini kabul etmistir. Bu amaç için asagida siralanmis bulunan 4 farkli ölçümü önermislerdir > M1 UL üzerinde GBR (gerçek zamanli trafik) için fiziksel kaynak blogu kullanimi > M2 UL üzerinde gerçek olmayan trafik için fiziksel kaynak blogu kullanimi > M3 DL üzerinde GBR (gerçek zamanli) trafik için fiziksel kaynak blogu kullanimi > M4 DL üzerinde gerçek zamanli olmayan trafik için fiziksel kaynak blogu kullanimi Tüm bu ölçümler, kullanilan PRB'lerin bir orani (yüzde) olarak bir trafik türü için, ayni dogrultudaki mevcut PRB'ler üzerinden belirli bir zaman araligi üzerinden olacak sekilde tanimlamis ve hücre basina olacak sekilde ölçülmüstür. Programlanmamis herhangi bir ileti veya geri ileti, kullanilmis olarak kabul edilmelidir.

Ayrica, RAN 1 bu kontrolün periyodik olarak saniyeler ile dakikalar arasinda araliklarla, hatta yogun saatler gibi beklenen trafik dalgalanmalarina bagli olarak daha yavas sikliklarda yapilmasinin yeterli olacagina inanmaktadir.

Yük dengeleme için sinyalizasyonun detaylari henüz tanimlanmamistir, siradaki bölümde ölçülen büyüklüklerin X2 arayüzü üzerinden sinyallenmesinin nasil gerçeklestirilmesi gerektigi ile ilgili ve Teslim ve yeniden seçim parametrelerinin yeniden hangi parametreler ile yapilandirilabilecegi ile ilgili farkli fikirleri arastirdik.

X2 Üzerinden Sinyalizasyon 4.1. Idarenin; Tüm eNB'ler ölçülmüs bulunan yük bilgilerini diger komsular ile paylasir Bu, en kolay senaryodur (Sekil 5 içerisinde gösterilmistir) ve burada her bir eNB'ler, ölçülen yük bilgisini, aralarinda X2 bagi olan tüm komsularini örnegin su bilgileri göndermek suretiyle bilgilendirir: Periyodik olarak kaynak durum güncelleme mesaji.

Alternatif olarak, bu bilgi, belirli mesajlara "piggy back” yapilabilir.

Farkli saticilarin eNB'leri farkli algoritmalar uygulayabilir ve bu durumda Kaynak Durum Güncelleme Raporu farkli araliklarda islenebilir, bu sebeple raporlama için sabit bir aralik kullanilmasi durumunda raporlar çok fazla siklikta gönderilebilir ve eNB, bu raporlarin büyük bir kismini gözardi edebilir. Örnegin, eger yük dengeleme algoritmasi her 5 saniyede bir çalisiyorsa, bir Kayit Durumu Güncelleme raporlama araligi 1 saniye gibi bir aralikta sabit ise, bu durumda 5 rapordan 4'ü gözardi edilir. 4.2. eNB komsu eNB'lerden seçici olarak yük bilgisini talep eder Bir eNB, komsu eNB'nin, kendi istedigi sekilde yük bilgisini göndermesini talep edebilir (uygulanan RRM algoritmasina bagli olarak). Örnegin talepte bulunan eNB, bir Kaynak Durum Talebi içerisinde komsu eNB'ye yük bilgisinin yalnizca bir defa mi, periyodik olarak mi veya bir veya daha fazla olay ile tetiklenecek sekilde olay tahrikli mi olacagini belirtebilir. Bu, Sekil 6 içerisinde gösterilmektedir.

Biz buna Efendi(Master) Köle(Slave) kontigürasyonu diyoruz ve burada talepte bulunan eNB Efendi(Master) olup, talep ettigi formatta bilgi isteyebilmektedir.

Kaynak Durum Talep Mesaji Detaylari > Efendi(Master) eNBl, bir Kaynak Durum Talebini Köle(Slave) eNBZ'ye, fiziksel kaynak blogu kullanimini bir kere, periyodik olarak veya olaya bagli bir sekilde talep durumunu da belirtir sekilde gönderir. > Raporlama Karakteristikleri IE, raporlamanin bir defa, periyodik olarak, veya olay güdümlü (bu durumda olay belirtilir) olarak yapilmasi gerektigini belirtir. Eger Raporlama Karakteristikleri IE ayarlanmamis ise, bu durumda Kaynak Durum Güncellemesi Köle(Slave) eNB tarafindan yalnizca bir defa gönderilmelidir. > Kaynak Durum Güncellemenin Durdurulmasi için ayri bir mesaja ihtiyaç yoktur. Ayni talep mesajinda Raporlama Karakteristik degeri 0 ayarli ise, bu durum Kaynak Durum Güncelleme raporlamayi durdurma talebi olarak yorumlanmalidir ve bu durum alici tarafindan aninda islenir ve benzer bir 0 degeri için ilgili Kaynak Durum Güncelleme mesajinda bildirilmelidir. > Kaynak Durum Talep mesajinda, Raporlama karakteristikleri lE, Efendi(Master) eNB'nin periyodik veya birden fazla olay için ve mümkünse bu olaylar için esik degerler saglamak suretiyle olay tetiklemeli olarak talepte bulunmasina olanak tanir.

Kaynak Durum Talep mesaji, Ortalama Süre, Efendi(Master) eNB tarafindan içerilecek ve bu sayede Efendi(Master) eNB tarafindan talep edilen bilgilerin üretimi için bir ölçüm araligi belirtecek sekilde gerçeklestirilebilir. Bu deger belirtilmemis ise, Köle(Slave) eNB varsayilan bir degeri uygulamalidir.

Kaynak Durum Talep mesajinda; Raporlama Zamani, Efendi(Master) eNB tarafindan dahili RRM algoritmasina bagli bir raporlama isteyecek sekilde dahil edilebilir. Bu deger belirtilmemisse, Köle(Slave) eNB varsayilan bir degeri uygulamalidir.

Kaynak Durumu Talep mesajina, Efendi(Master) eNB, kaynak bilgisini almak istedigi hücrelerin hücre ld'lerini dahil edebilir. Bu deger belirtilmemisse, Köle(Slave) eNB tüm hücrelerin kaynak durumunu raporlar.

Kaynak Durum Güncelleme Mesaji Detaylari Kaynak Durum Güncelleme mesaji, bu raporun sebebini belirtmek üzere ayrica raporlama karakteristikleri IE'yi de içermelidir.

Raporlama Karakteristikleri IE içerisinde birkaç tane deger, hücre içerisinde UL veya DL yönünde Fiziksel katman kaynaklari veya herhangi baska türde isleme kaynagindaki tikanmayi belirtecek sekilde rezerve edilebilir. Tikanma göstergesi içeren bir Kaynak Durum Güncelleme raporu, Köle(Slave) eNB tarafindan otonom olarak, kendisinden tikanma tespit edildiginde Kaynak durum güncellemesi göndermesini talep eden bir koinsu Efendi(Master) eNB'lere gönderilebilir. Ayrica, Köle(Slave) eNB otonom olarak Kaynak Durum Güncelleme Raporunu, tikaniklik giderildiginde gönderebilir. Kaynak Durum Güncelleme Raporu otonom olarak Köle(Slave) eNB tarafindan, UL girisimi, içinde bulunulan hücreye ait esik deger asildiginda kaynak durum güncellemesi talep etmis olan komsu Efendi(Master) eNB'lere gönderebilir. Bu sayede mevcut prosedür yük bilgisini içerisine dahil eder.

Efendi(Master) eNB tarafindan belirtilen Ortalama/Raporlama Süresi üzerinden UL üzerindeki GBR (gerçek zamanli trafik) için Ortalamali Fiziksel kaynak blogu kullanimi Efendi(Master) eNB tarafindan belirtilen Ortalama/Raporlama Süresi üzerinden UL üzerindeki gerçek olmayan trafik için Ortalamali Fiziksel kaynak blogu kullanimi Efendi(Master) eNB tarafindan belirtilen Ortalama/Raporlama Süresi üzerinden DL üzerindeki GBR (gerçek zamanli trafik) için Ortalamali Fiziksel kaynak blogu kullanimi > Efendi(Master) eNB tarafindan belirtilen Ortalama/Raporlama Süresi üzerinden DL üzerindeki gerçek olinayan zamanli trafik için Ortalamali Fiziksel kaynak blogu kullanimi Genel olarak, her bir eNB, hem Efendi(Master) (Kaynak Durum Bilgisi isterken) hem de Köle(Slave) (Kaynak Durumu Raporlari saglarken) rollerini üstlenebilir. Ancak, bir eNB bir yük dengeleme algoritmasini uygulayamazsa ve bu durumda komsu eNB Kaynak Durum Raporlarini saglama ile ilgili yalnizca bir Köle(Slave) olarak davranis gösterir ve bu, zorunlu olmasi düsünülebilir.

Alternatif olarak, lur arayüzü üzerinde UMTS içerisinde tanimlanmis olan Genel Ölçüm Prosedürü'ne benzer daha sofistike bir prosedüre sahip olabilirdik ve burada sekil 7a içerisindeki Kaynak Durum Yanitinda belirtildigi gibi bir Kaynak Durum Talebine bir yanit bulunmaktadir. Sekil 6 içerisinde önerilen Efendi(Master) Köle(Slave) konfigürasyonu ile karsilastirildiginda, bu, eNB'nin Kaynak Durum Talebini, talep edilen ölçümü desteklemedigi durumda reddetmesine, Sekil 7b içerisinde gösterildigi sekilde olanak tanir.

Böyle bir prosedür, Sekil 6 içerisinde önerilen Efendi(Master) Köle(Slave) yapilandirmasi ile karsilastirildiginda 5 mesaj gerektirecektir. Ancak, eger her bir eNB için Kaynak Durum güncelleinesini diger komsu eNB'ye iletmesi zorunlu ise, bu durumda böyle bir yanit/ariza mesaji gerekli olmayabilir.

Böyle bir seçenek, yük bilgisinin Efendi(Master) eNB tarafindan belirtilen Raporlama periyoduna bagli olarak raporlanmasina olanak tanir ve bu durumda kaynak durum bilgisini çok sayida saticinin bulundugu bir senaryoda etkin bir sekilde kullanmaya ve uygulamaya Özel algoritmalarin etkin bir sekilde gerçeklestirilmesine olanak tanir. Ayrica, X2 üzerinde gereksiz sinyal bu sayede azaltilmis hale gelebilir.

Yük bilgisi prosedürü ile iliski Mevcut durumda Yük bilgisi Prosedürü [3] içerisinde tanimlanmistir. Yük gösterme prosedürünün amaci, uplink girisim asiri yükleme göstergesinin iç frekans komsulugu bulunan eNodeB'ler arasinda, girisim koordinasyonu amaçlari ile iletimidir.

Bir eNodeB, prosedürü, YÜK BILGISI mesajini iç frekans komsulugu bulunan eNodeB'lere Sekil 8 içerisinde gösterilen sekilde göndererek baslatir. YÜK BILGISI inesaji, girisim asiri yükleme göstergesi içerebilir. Yük gösterge prosedürü, girisim asiri yükleme göstergesini, eNB bazi kaynak bloklarinda asiri girisiin seviyelerine maruz kaldiginda göndermek için kullanilmalidir.

Kaynak Durum güncelleme prosedürü, bu yukaridaki Prosedürünü içinde barindirabilir ve bunun için Kaynak Durum Güncelleme raporlari otonom bir sekilde Köle(Slave) eNB tarafindan kaynak durum güncellemesi talebinde bulunan komsu Efendi(Master) eNB'lere gönderilebiliyor olmalidir ve ayrica bu UL girisimi, kendi hücresi içerisinde belirli bir esik degerin üzerine çiktiginda iç frekans aramalari yapabilir.

Dolayisiyla, basitlik amaçlari için bu iki prosedürün birlestirilmesini öneriyoruz. Bu birlestirilmis prosedürü, "Kaynak Dumm Güncelleme" veya "Yük Bilgi Prosedürü" isimlerinden hangisi daha uygun gelirse o sekilde adlandirabiliriz.

Iliskili SON Fonksiyonelligi ENB içindeki Yük Bilgisi, dinamik olarak Teslim islemini ve dahili SON birimi yardimiyla hücrelere ait hücre (yeniden) seçim parametrelerini dinamik olarak kontrol etmek için kullanilabilir. Bu mekanizma Sekil 9ada görülmektedir.

Güncellenebilir hücre yeniden seçim parametreleri sunlar olabilir. Iç frekans durumuna bunun nasil uygulanacagi, bir FFS (daha ileri çalisma) olup, bu, hücrelerin siralamasina dayalidir. 3. Iç frekans yeniden seçim öncelikleri 4. tabakaya Özel ofset Yapilandirilabilir Teslim parametreleri sunlar olabilir: 1. Histerezis 2. Tetikleme süresi 3. vb.

Sonuçlar Bu katkida, eNB'ler arasinda Kaynak durumu ile ilgili bilgi alis verisi için çesitli seçenekleri tartisacagiz. Biz Efendi(Master)/Köle(Slave)türü yapilandirmanin birden çok saticinin söz konusu oldugu bir senaryoda uygulamaya özel RRM algoritinalarinda kaynak durum raporlarinin saglanmasinda çok esnek olacagina inaniyoruz ve adapte edilmesi gerektigini düsünüyoruz. RAN 3'te önerilen Efendi(Master)/Köle(Slave)türü raporlama seçeneginde anlasilmasini ve XZAP özellikleri için [4] içerisindeki ilgili metin teklifinin kabul edilmesini siddetle tavsiye ediyoruz.

Ayrica, ilgili SON islevi ile optimize edilebilecek teslim ve Hücre yeniden seçim parametrelerini tartistik ve eger üzerinde anlasilabilirse, bazi detaylar Asama 2 TS içerisinde belirli hale getirilebilir.

Claims (1)

1. ISTEMLER Bir baz istasyonu tarafindan gerçeklestirilen yöntein olup, ilgili yöntein asagidakileri ihtiva etmektedir: bir komsu baz istasyonuna (5-2), komsu bir baz istasyonunun (5-2) kaynak durum güncelleme mesajlarim gönderecegi bir periyodikligi ihtiva etmekte olan bir kaynak durum talebinin gönderilmesi; periyodiklige dayanarak komsu baz istasyonu (5-2) tarafindan gönderilen en azindan bir adet kaynak durumu güncelleme mesajinin alinmasi, burada en azindan bir adet kaynak durum güncelleme mesaji, garantili bit hizi, GBR, trafigi için Iiziksel kaynak blogu kullanimini tanimlayan verileri ihtiva etmektedir; ve alinan bir veya daha fazla sayidaki kaynak durumu güncelleme mesajina göre yük dengeleme islemlerinin gerçeklestirilmesi. Bir baz istasyonu (5-2) tarafindan gerçeklestirilen yöntem olup, ilgili yöntem asagidakileri ihtiva etmektedir: bir komsu baz istasyonundan (5-I), bir komsu baz istasyonunun (5-2) kaynak durum güncelleme mesajlarini gönderecegi bir periyodikligi ihtiva etmekte olan bir kaynak durum talebinin alinmasi; ve periyodiklige göre en azindan bir adet kaynak durum güncelleme mesaj ini komsu baz istasyonuna (5-1) gönderme, burada en azindan bir adet kaynak durum güncelleme mesaji, garantili bit hizi, GBR, trafigi için bir fiziksel kaynak blogu kullanimini belirleyen verileri ihtiva etmektedir. Bir baz istasyonu (5-1) olup, asagidakileri ihtiva etmektedir: bir komsu baz istasyonuna (5-2), bir komsu baz istasyonunun (5-2) kaynak durum güncelleme mesajlarini gönderecegi bir periyodikligi ihtiva etmekte olan bir kaynak durum talebini göndermek amaçli olan araç; periyodiklige dayanarak komsu baz istasyonu (5-2) tarafindan gönderilen en azindan bir adet kaynak durumu güncelleme mesajini almak amaçli olan araç, burada en azindan bir adet kaynak durum güncelleme mesaji, garantili bit hizi, GBR, trafigi için fiziksel kaynak blogu kullanimini tanimlayan verileri ihtiva etmektedir; ve alinan bir veya daha fazla sayidaki kaynak durumu güncelleme mesajina dayali olarak yük dengeleme islemlerini gerçeklestirmek amaçli olan araç. Bir baz istasyonu (5-2) olup, asagidakileri ihtiva etmektedir: bir komsu baz istasyonundan (5-1), bir komsu baz istasyonunun (5-2) kaynak durum güncelleine mesajlarini gönderecegi bir periyodikligi ihtiva etmekte oldugu bir kaynak durum talebini almak amaçli olan araç; ve periyodiklige dayanarak en azindan bir adet kaynak durum güncelleine mesajinin, komsu baz istasyonuna (5-1) gönderilmesi amaçli olan araç , burada cn azindan bir adet kaynak durum güncelleme mesaji, garantili bit hizi, GBR, trafigi için bir fiziksel kaynak blogu kullanimini belirleyen verileri ihtiva etmektedir. Bir birinci baz istasyonunu (5-1), bir ikinci baz istasyonunu (5-2) ve bir mobil terminali (3) ihtiva etmekte olan bir haberlesme sistemi olup; burada birinci baz istasyonu (5-1), bir ikinci baz istasyonuna (5-2), bir komsu baz istasyonun kaynak durum güncelleme mesajlarini gönderecegi bir periyodikligi ihtiva etinekte olan bir kaynak durum talebini gönderme amaçli olan araci, periyodiklige dayanarak ikinci baz istasyonu (5-2) tarafindan gönderilen en azindan bir adet kaynak durumu güncelleme mesajini almak amaçli olan araci ihtiva eder, burada en azindan bir adet kaynak durum güncelleme mesaji, garantili bit hizi, GBR, trafigi için fiziksel kaynak blogu kullanimini belirleyen verileri ihtiva eder, ve alinan bir veya daha fazla sayidaki kaynak güncelleme mesajlarina bagli olarak yük dengeleme islemlerini gerçeklestirme amaçli olan araci ihtiva eder; burada ikinci baz istasyonu (5-2), birinci baz istasyonundan (5-1) gelmekte olan kaynak durum bilgisi talebini almak amaçli olan araci ve en azindan bir adet kaynak durum güncelleme mesaj ini birinci baz istasyonuna (5-1) göndermek amaçli olan araci ihtiva eder; ve burada mobil terminal (3), birinci baz istasyonu tarafindan gerçeklestirilen adi geçen yük dengeleme islemlerine dayanarak birinci baz istasyonundan aktarim yapmak amaciyla konfigürc edilmistir. Bir programlanabilir bilgisayar cihazinin Istem 1 veya Istein 2'ye ait olan yöntemi gerçeklestirmesini saglamak için bilgisayar ile uygulanabilir talimatlari ihtiva etmekte olan bir bilgisayar tarafindan uygulanabilir talimatlar ürünüdür.