!HU000008617T2! (19)
HU
(11) Lajstromszám:
E 008 617
(13)
T2
MAGYAR KÖZTÁRSASÁG Szellemi Tulajdon Nemzeti Hivatala
EURÓPAI SZABADALOM SZÖVEGÉNEK FORDÍTÁSA (21) Magyar ügyszám: E 07 764735 (22) A bejelentés napja: 2007. 06. 20. (96) Az európai bejelentés bejelentési száma: EP 20070764735 (97) Az európai bejelentés közzétételi adatai: EP 2077009 A1 2008. 05. 02. (97) Az európai szabadalom megadásának meghirdetési adatai: EP 2077009 B1 2010. 05. 05.
(51) Int. Cl.: H04L 12/56 (2006.01) (87) A nemzetközi közzétételi adatok: WO 08049472 PCT/EP 07/005412
(30) Elsõbbségi adatok: 0602284 2006. 10. 27.
(73) Jogosult: Telefonaktiebolaget LM Ericsson (publ), 164 83 Stockholm (SE)
SE
(72) Feltalálók: BERGSTRÖM, Joakim, 114 30 Stockholm (SE); MEYER, Michael, 52080 Aachen (DE); WIEMANN, Henning, 52062 Aachen (DE)
HU 008 617 T2
(54)
(74) Képviselõ: Sári Tamás Gusztáv, DANUBIA Szabadalmi és Jogi Iroda Kft., Budapest
Hosszjelzõ-optimalizálás
A leírás terjedelme 14 oldal (ezen belül 6 lap ábra) Az európai szabadalom ellen, megadásának az Európai Szabadalmi Közlönyben való meghirdetésétõl számított kilenc hónapon belül, felszólalást lehet benyújtani az Európai Szabadalmi Hivatalnál. (Európai Szabadalmi Egyezmény 99. cikk (1)) A fordítást a szabadalmas az 1995. évi XXXIII. törvény 84/H. §-a szerint nyújtotta be. A fordítás tartalmi helyességét a Szellemi Tulajdon Nemzeti Hivatala nem vizsgálta.
1
HU 008 617 T2
Mûszaki terület A jelen találmány telekommunikációs hálózatban átvitt adatcsomagokban lévõ kommunikációs fejlécre vonatkozik, és különösen a fejléc méretének optimalizálására. A találmány háttere A 3GPP terminológia szerint egy felsõbb réteg protokollja PDU¹t (Packet Data Unit: csomagadategység) ad át egy alsóbb réteg protokolljának, és elvárja, hogy az a társentitásának átadásra kerüljön. Más szavakkal az alsóbb réteg biztosítja az átviteli szolgáltatást a felsõbb rétegnek. Az alsóbb réteg nézõpontjából a felsõbb réteg adategysége így az SDU (service data unit: szolgálati adategység). A protokollréteg (mint például az RLC réteg az LTE-nél vagy a WCDMA-nál) szegmentálhatja az SDU-kat, amennyiben a teljes SDU¹t nem lehet egyszerre átvinni. Mindamellett egyesíthet több ilyen SDU¹t (SDU-szegmenst). Végül egy vagy több ilyen SDU (SDU-szegmens) becsomagolható egy PDU¹ba. Fejléc kerül kialakításra, amely arra vonatkozó információt tartalmaz, hogy hogyan kell értelmezni a PDU hasznos (payload) szakaszát. A PDU ezután átadásra kerül a következõ alsóbb rétegnek, amely azt SDU-ként kezeli. Az 1. ábra egy jellemzõ MAC PDU fejlécét mutatja be. Ez egy vagy több RLC PDU¹t tartalmazhat (amelyekre mint MAC SDU¹k is lehet hivatkozni) és ezek mindegyike egy vagy több RLC SDU¹t (például PDCP PDU¹t) tartalmazhat, vagy ezek szegmenseit. Az ilyen MAC PDU¹k átvitelre kerülnek az alsóbb rétegek által a társprotokollverem (peer protocoll stack) felé. A fejlécinformáción alapulóan az MAC és RLC vevõ újra össze tudja állítani az eredeti RLC SDU¹t. E találmány szempontjából különös jelentõséggel bírnak az MAC és az RLC fejlécekben lévõ hosszmezõk (Length Field) és hosszjelzõk (Length Indicator). Ezek a vevõ társ-protokollentitást ellátják a tartalmazott SDU¹k újra összeállításához szükséges információval. A jelen találmánnyal összefüggésben az MAC fejlécben lévõ hosszmezõ (Length Field) és az RLC fejlécben lévõ hosszjelzõ (Length Indicator) határozza meg egy SDU (szolgálati adategység) vagy annak egy szegmensének méretét. Alternatív módon a mezõk információt szolgáltathatnak egy SDU pozíciójára vonatkozóan, azaz egy SDU elsõ bájtjának távolságára vonatkozóan a tartalmazó PDU elsõ (hasznos) bájtjától. A korábbi mindazonáltal hatékonyabb, amennyiben a legnagyobb támogatott SDU kisebb, mint a legnagyobb támogatott PDU. A mezõk mindkét típusa lehetõvé teszi a vevõ számára, hogy meghatározza bármely tartalmazott SDU vagy annak szegmense elsõ és utolsó bájtjának méretét és ezáltal pozícióját. Ennek az iratnak a hátralévõ részében ezért az SDU pozícióazonosító (SDU position identifier) kifejezést alkalmazzuk az ilyen mezõkre vonatkozó általánosabb kifejezésként. Az SDU pozícióazonosítók szükséges hossza a megcímzett SDU¹k és/vagy a tartalmazó PDU várt méretétõl és méretfelbontásától (size-granularity) függ. Az egyik általánosan használt felbontás az egy bájt. An-
5
10
15
20
25
30
35
40
45
50
55
60 2
2
nak érdekében, hogy képesek legyünk megcímezni a PDU¹k belsejében bármely méretet vagy pozíciót egészen 2x bájtig, a hosszmezõknek és hosszjelzõknek legalább x bitet kell tartalmazniuk (például 215=32 768). x a legnagyobb támogatott SDU mérete lehet, amennyiben arról tudjuk, hogy kisebb, mint a legnagyobb támogatott PDU. A technika állása szerinti protokolloknál az ilyen hossz- és pozícióazonosítók hossza statikusan vagy félig statikusan van konfigurálva a legnagyobb várt PDU vagy SDU méretén alapulóan. A 7. ábra RLC/MAC fejlécre vonatkozó példát szemléltet, és becslést ad az LTE RLC-ben és MACban lévõ fejlécmezõkhöz szükséges bitek számára. Látható, hogy a hosszmezõ (Length Field, LF), csakúgy, mint a hosszindikátor (Length Indicator, LI) jelentõs mértékben hozzájárul a fejléc teljes méretéhez. Mindaddig, amíg a hasznos rész (payload) nagyméretû a fejléc méretével való összehasonlításban, úgy ez nem jelent nagy problémát. Mindazonáltal amennyiben csak néhány bájtnyi hasznos részt kell becsomagolni (encapsulate), ez az erõforrások pazarlását jelenti. Amennyiben a PDU-ban a hasznos rész (payload), úgy a viszonylagos fejléc-többletterhelés (header overhead) nagy. Amennyiben például csak egyetlen VoIP csomag van befoglalva egy RLC PDU¹ba, amely azután egy MAC PDU¹ba van becsomagolva, úgy a hosszmezõ (LF) jelentõs többletterhelést (overhead) hoz létre. Ennek az az oka, hogy a rögzített méretû hosszmezõnek nagyon nagy szállítási blokkokat is támogatnia kell úgy, hogy például 15 bitet kell felhasználni. Például 30 bájtos kis csomagok esetén ez ~6% többletterheléssé (overhead) gyûlik össze. Mivel az összes SDU nagy része kisméretû csomag (például VoIP, TCP-ACK¹k és SIP jelzésátvitel), ez jelentõs mértékûvé válik. Egy másik probléma lép fel, amennyiben több kisméretû SDU¹t kell egyetlen RLC PDU¹ba becsomagolni. Ekkor egy-egy hosszjelzõre (LI) van szükség mindegyikhez, kivéve az utolsót, ahogy a 8. ábrán látható. Amennyiben minden egyes beágyazott RLC SDU például csak 30 bájtos (240 bites), úgy a 13+1 bites többletterhelés (overhead) csaknem 6%¹kal egyenlõ az utolsó kivételével az összes RLC SDU esetén. A 8. ábra egy RLC/MAC PDU RLC/MAC fejlécét szemlélteti úgy, hogy 4 RLC SDU van becsomagolva egy RLC PDU¹ba. Az UMTS RLC protokoll – ahogy az például a 3GPP TS 25.322 iratban leírásra került – már lehetõséget nyújt arra, hogy a hosszindikátorok méretét a maximális várt PDU mérethez adaptálják. Mindazonáltal az UMTS RLC esetén a PDU mérete elõre konfigurálva van (az UM esetén a maximális méret elõre konfigurált, és az LI ettõl a maximális mérettõl függ). Az EP 1104207 irat adatcsomagot tár fel változtatható hasznosrész-mezõvel (payload field), és ahol a megoldás a hosszjelzõ mezõt rögzített felbontású (granularitású) megfelelõ méretûre változtatja. Annak érdekében, hogy ezt megvalósítsák, egy önálló mezõt ad-
1
HU 008 617 T2
nak a fejléchez ahhoz, hogy jelöljék, amennyiben a hasznos rész (payload) hossza nem oktettek egész egysége, és így a megfelelõ felbontást (granularitást). Ez azzal a hátránnyal bír, hogy az infrastruktúra-hálózat minden egyes szintjén minden egyes csomag megvizsgálását követeli meg annak érdekében, hogy kikövetkeztessék az adatcsomag méretét és típusát. Ez az adatcsomagok standardizált implementálásának megváltoztatását követeli meg, és még mindig jelentõs fejlécméretet tesz szükségessé. Mindemellett csak két különbözõ LI méret támogatott az UMTS esetén. A WO2005/006599 irat csomópont-elrendezést tár fel csomagadategységben lévõ fejléc optimalizálására optimalizált PDU méret létrehozására szolgáló eszközzel. Ennél az elrendezésnél a hosszjelzõ mezõ csak a mezõben lévõ változó vonatkozásában optimalizált, amely a hasznos rész (payload) méretétõl függõen változik. Mindemellett ennél az elrendezésnél a hosszjelzõ egy méretváltozó. A találmány összefoglalása Célunk a jelen találmánnyal megoldást biztosítani a fent említett problémák és hátrányok közül legalább néhány megoldására. Ezt bizonyos számú vonatkozás viszonylatában érjük el, amelyek közül egy elsõnél PDU-ban lévõ fejléc méretének optimalizálására szolgáló telekommunikációs csomópont tartalmaz: – eszközt a PDU aktuális méretébõl az SDU pozícióazonosító szükséges méretének származtatására; – eszközt PDU fejléc létrehozására optimalizált SDU pozícióazonosító-mérettel; – eszközt vevõ csomópontnak vezérlõjel küldésére különálló kommunikációs csatornán vagy egy másik fejlécelemben a PDU méretére vonatkozó információval; – eszközt a PDU-nak a vevõ csomópontnak való küldésére. A csomópont-elrendezés tartalmazhat továbbá: – eszközt vezérlõjel-információnak adó csomópontelrendezéstõl való vételére a PDU méretére vonatkozó információval; – eszközt a PDU említett méretébõl az SDU pozícióazonosító optimális méretének származtatására; – eszközt optimalizált PDU vételére az adó csomópont-elrendezéstõl; – eszközt a vett optimalizált PDU dekódolására az SDU pozícióazonosítók említett származtatott méretén alapulóan. Az SDU pozícióazonosítók optimális mérete a PDU¹k és/vagy az SDU¹k támogatott méretétõl függ. Egy PDU¹n belül elhelyezkedõ SDU méretét és pozícióját kifejezõ SDU pozícióazonosító optimális mérete a PDU bájtokban vett méretének kettes alapú logaritmusának függvényeként számítható ki a legközelebbi nagyobb egészre kerekítve. LF_size=ceil(log2(PDU_Size)). Amennyiben a tartalmazott SDU¹k méretérõl ismert, hogy kisebb, mint az adott PDU mérete, úgy az
5
10
15
20
25
30
35
40
45
50
55
60 3
2
SDU pozícióazonosítók mérete a következõk szerint határozható meg: LF_size=ceil(log2(min(PDU_Size, MAX_SDU_Size))) Közeghozzáférés-vezérlõ funkció állíthatja be az SDU pozícióazonosítók méretét. Az SDU pozícióazonosító mérete bármely egész számra beállítható. A protokoll specifikációjától függõen az SDU pozícióazonosító méretének felbontása (granularitása) egy bitnél nagyobb lehet. Az optimális méret ekkor felkerekítésre kerül a következõ támogatott méretre. A vezérlõjel-információ egy közös vezérlõcsatornán átvitt szállításiformátum-információ lehet. A közös vezérlõcsatorna L1 vezérlõcsatorna lehet. A jelen találmány egy másik vonatkozása szerint eljárást biztosítunk telekommunikációs hálózatban hasznos (payload) adatcsomagok fejlécméretének optimalizálására, amely eljárás az alábbi lépéseket tartalmazza: – a PDU aktuális méretébõl egy szolgálati adategység, SDU pozícióazonosítóinak szükséges méretét származtatjuk; – PDU fejlécet hozunk létre optimalizált SDU pozícióazonosító-mérettel; – vevõ csomópontnak vezérlõjelet küldünk különálló kommunikációs csatornán vagy egy másik fejlécelemben a PDU méretére vonatkozó információval; – a PDU¹t a vevõ csomópontnak küldjük. A jelen találmány egy még további vonatkozásának megfelelõen távközlési hálózatban hasznos (payload) adatcsomagok átviteléhez jelet biztosítunk, amely fejlécet tartalmaz dinamikusan állítható SDU pozícióazonosító-méretekkel. Emellett utasításkészletet biztosítunk telekommunikációs hálózatban lévõ csomópontban, amely az alábbiakra szolgáló utasításkészleteket tartalmaz: – vezérlõjel-információ vétele adó csomópont-elrendezéstõl a PDU méretére vonatkozó információval; – a PDU említett méretébõl az SDU pozícióazonosítók optimális méretének származtatása; – optimalizált PDU vétele az adó csomópont-elrendezéstõl; – a vett optimalizált PDU dekódolása az SDU pozícióazonosítók említett származtatott méretén alapulóan. A találmány alapkoncepciója az, hogy optimalizáljuk az SDU pozícióazonosítók méretét a teljes csomagadategység-méret, például MAC PDU és RLC PDU méretétõl függõen. Ez az optimalizálás rendre a teljes szállítási blokk és a teljes RLC PDU méretének ismeretén alapul. Ez mind a felhasználói oldalon, mind az infrastruktúraoldalon végrehajtásra kerül az átvitelt megelõzõen, és mindkét oldal úgy van elrendezve, hogy dekódolja a csomagokat ennek a sémának megfelelõen. Különálló jelet alkalmazva ahhoz, hogy jelezzük az LF és/vagy LI mezõk változását, lehetõség nyílik arra, hogy a jelen találmányt beágyazzuk standardizált kommunikációs protokollba anélkül, hogy annak a magját módosítanánk. A jelen találmány azzal az
1
HU 008 617 T2
elõnnyel bír, hogy a fejléc méretezése során rugalmas kisebb adatcsomagokat biztosítva, és csökkentve a szükségtelen kommunikációs többletterhelést (overhead) ezzel. Mindemellett a jelen találmány nem hat zavaróan az ilyen típusú kommunikációra vonatkozó jelenlegi szabványra, lehetõvé téve a megoldás kényelmes megvalósítását a jelenlegi ilyen típusú kommunikációs hálózatokban.
5
A rajz rövid leírása Az alábbiakban a találmányt nem korlátozó módon és nagyobb részletességgel leírjuk példakénti megvalósítási módokra való hivatkozással, amelyek a csatolt rajzon kerültek szemléltetésre. A rajzon az 1. ábra egy, a jelen találmány szerinti hálózati topológiát szemléltet vázlatosan; a 2. ábra egy, a jelen találmány szerinti felhasználói berendezést szemléltet vázlatosan; a 3. ábra egy, a jelen találmány szerinti infrastruktúrakészüléket szemléltet vázlatosan; a 4. ábra egy, a jelen találmány szerinti eljárást szemléltet vázlatosan; az 5. ábra egy, a jelen találmány szerinti másik eljárást szemléltet vázlatosan; a 6. ábra egy, a jelen találmány szerinti hasznos (payload) adatcsomagot szemléltet vázlatosan; a 7. ábra egy, az ismert technikáknak megfelelõ normál RLC/MAC PDU RLC/MAC fejlécét szemlélteti vázlatosan; és a 8. ábra egy, az ismert technikáknak megfelelõ normál RLC/MAC PDU RLC/MAC fejlécét szemlélteti vázlatosan.
10
Elõnyös megvalósítási módok részletes leírása Az 1. ábrán a 100 hivatkozási jel általánosságban egy, a találmány szerinti hálózatot jelöl. Bizonyos fajtájú 101, 102, 103 felhasználói berendezés (user equipment, UE) például 101 mobiltelefon, 102 laptop vagy 103 PDA (Personal Digital Assistant: személyi digitális asszisztens) van 110 csatlakoztatva közvetlenül vagy közvetve vezeték nélküli kapcsolaton 104 telekommunikációs átjáróhoz (például bázisállomáshoz) és az más (nem ábrázolt) felhasználókkal vagy (nem ábrázolt) szolgáltatásokkal kommunikál, amelyek hozzáférhetõek 105 kommunikációs infrastruktúrahálózaton vagy azon keresztül. A kommunikációs hálózat példának okáért magában foglalhatja a 100 telekommunikációs hálózat és az internet infrastruktúrahálózat-részeit. Az 1. ábrán a kommunikációs átjáró a 105 kommunikációs infrastruktúrahálózathoz bármilyen alkalmas fajtájú rögzített vagy vezeték nélküli 106 hálózati összeköttetésen keresztül van csatlakoztatva. A 105 infrastruktúrahálózat nem nyilvános hálózatot vagy nyilvános hálózatot (például az internetet) tartalmazhat. A felhasználói berendezés és/vagy a telekommunikációs átjáró mint telekommunikációs csomópont lehet jelölve, és a jelen találmánynál azok egy csomagadategységben, PDU-ban lévõ fejléc méretének optimalizálására vannak elrendezve, és a csomópont tartalmaz:
35
15
20
25
30
40
45
50
55
60 4
2
– eszközt a PDU aktuális méretébõl a szolgálati adategység, SDU pozícióazonosítói szükséges méretének származtatására; – eszközt PDU fejléc létrehozására optimalizált SDU pozícióazonosító mérettel; – eszközt vezérlõjel küldésére vevõ csomópontnak különálló kommunikációs csatornán vagy egy másik fejlécelemben (megjegyezzük, hogy az RLC hosszjelzõ mérete az MAC fejlécben lévõ hosszmezõbõl (Length Field) származtatható. Mindkettõt ugyanaz a szállítási blokk tartalmazhatja, és ezért nem különálló kommunikációs csatornán vannak) a PDU méretére vonatkozó információval (ez a másik vezérlõinformáció az alábbi lehet: a) L1 vezérlõinformáció, amely meghatározza a teljes MAC PDU méretét és b) hosszmezõ (Length Field), amely a teljes RLC PDU méretét határozza meg. a) az optimális LF származtatására használható, és b) egy LI (Length Indicator: hosszjelzõ) optimális méretének származtatására használható); – eszközt a PDU küldésére vevõ csomópontnak. A csomópont tartalmazhat továbbá: – eszközt vezérlõjel-információ vételére adó csomópont-elrendezéstõl a PDU méretére vonatkozó információval; – eszközt a PDU említett méretébõl az SDU pozícióazonosítók optimális méretének származtatására; – eszközt optimalizált PDU vételére az adó csomópont-elrendezéstõl; – eszközt a vett optimalizált PDU dekódolására az SDU pozícióazonosítók említett származtatott méretén alapulóan. Az SDU pozícióazonosítók optimális mérete a PDU¹k és/vagy SDU¹k támogatott méretétõl függ. A PDU¹n belül elhelyezkedõ SDU méretét és pozícióját kifejezõ SDU pozícióazonosítók optimális mérete a PDU bájtban vett mérete kettes alapú logaritmusának függvényeként számítható a legközelebbi nagyobb egészre kerekítve. LF_size=ceil(log2(PDU_Size)) Amennyiben a tartalmazott SDU-król ismert, hogy kisebbek, mint az adott PDU mérete, úgy az SDU pozícióazonosítók mérete a következõk szerint határozható meg: LF_size=ceil(log2(min(PDU_Size, MAX_SDU_Size))) A protokoll specifikációjától függõen az SDU pozícióazonosító felbontása (granularitása) egy bitnél nagyobb lehet. Az optimális méret ekkor a következõ támogatott méretre felkerekítésre kerül. A támogatott méret bármely alkalmas egész számú bit lehet. Telekommunikációs hálózatban hasznos (payload) adatcsomagok fejlécméretének optimalizálására szolgáló eljárás az alábbi lépéseket tartalmazhatja: – a PDU aktuális méretébõl az SDU pozícióazonosítók szükséges méretét származtatjuk; – PDU fejlécet hozunk létre optimalizált SDU pozícióazonosító-mérettel;
1
HU 008 617 T2
– vevõ csomópontnak vezérlõjelet küldünk különálló kommunikációs csatornán vagy egy másik fejlécelemben a PDU méretére vonatkozó információval. A jelen találmány hátterében meghúzódó gondolat az, hogy a szolgálati adategység (SDU) pozícióazonosítójának, például a hosszmezõnek (Length Field) (ahogy az 1. és 2. ábrán látható) aktuálisan szükséges mérete soha nem nagyobb, mint LF_Size_Opt=ROUNDUP(Log2(MAC_PDU_Sizebyte)) Ugyanez érvényes a hosszindikátor(ok)ra [amely(ek) ugyancsak az 1. és 2. ábrán látható(ak)], amely(ek) az RLC PDU méretétõl függ(enek): LI_Size_Opt=ROUNDUP(Log2(RLC_PDU_Sizebyte)) Ennek az az oka, hogy az LF és az LI valójában mutatók (pointerek), amelyek a PDU-ban egy pozícióra (bájtra) mutatnak. És ezen pozíciók indexe kisebb, mint a PDU teljes mérete bájtokban. A jelen találmány szerinti eljárásnál az MAC (RLC) adó beállítja az LF mezõ (LI mezõ) méretét a szállítási blokk (RLC PDU) aktuális méretétõl függõen. Ez elvégezhetõ az átviendõ csomag méretének megvizsgálása révén a szoftverben, és a hosszmezõk (Length Field) megfelelõ méretének meghatározásával. A vevõ ugyanazt a szabályt alkalmazza az LF mezõ (és/vagy az LI mezõ) méretének meghatározására a vett szállítási blokkban (RLC PDU). Megjegyezzük, hogy ez ismeri a teljes szállítási blokk méretét a szállítási formátumból, amely például egy közös vezérlõcsatornán (például az L1 vezérlõcsatornán) kerül átvitelre, és amelyre mindenképpen szükség van a dekódoláshoz. Az RLC PDU mérete ezután ismert a hosszmezõbõl (Length Field, LF). A közös vezérlõcsatorna különálló (logikailag és/vagy fizikailag különálló) lehet a hasznos forgalom (payload traffic) átvitelére használt kommunikációs csatornához képest. Második megvalósítási módként csak kiválasztott méretek lehetnek megengedhetõek az LF és LI mezõkhöz. Például valaki bájthoz igazodó fejlécméreteket, azaz 8 bit többszöröseit kitevõ fejlécméreteket kíván kapni. Az „E” bittel kombinálva az Ll¹nek így vagy 7, vagy 15 bitesnek kell lennie. Így a fent említett szabály kiterjeszthetõ úgy, hogy a pillanatnyi LI hossz vagy 7 (RLC PDU¹k <128 bájt esetén), vagy 15 (RLC PDU¹k >128 bájt esetén). Az eljárás mindkét irányban, uplink és downlink irányban végrehajtható, és a kommunikációs összeköttetés mindkét oldalán lévõ készülékekben, azaz a 101 UE¹ben és egy megfelelõ 104 infrastruktúrakészülékben (például bázisállomásban vagy RNC-ben a kommunikációs technológiától és a hálózati konfigurációtól függõen), amelyek átjáróként vannak elrendezve a 105 kommunikációs hálózat felé. Mindkét készülék (a felhasználói oldalon és az infrastruktúraoldalon) emellett úgy van elrendezve, hogy dekódolja a csomagokat, amelyek átvitelre kerültek az optimalizált SDU pozíciójelzõk alkalmazásával. Az SDU pozíciójelzõk dinamikusan optimalizálhatóak streaming módon. A hosszmezõre (Length Field) vonatkozó egy példát adunk meg most. Amennyiben az RLC SDU például 30 bájt (240 bit) nagyságú, úgy egy rögzített mére-
5
10
15
20
25
30
35
40
45
50
55
60 5
2
tû, például 15 bites hosszmezõ (Length Field) ~6% többletterhelést (overhead) ad. Mivel az SDU¹k legnagyobb része kis csomag (például VoIP, TCP-ACK¹k vagy SIP jelzésátvitel) ez jelentõs hatással van a teljes protokollhatékonyságra. Tulajdonképpen 5 bites hosszmezõ (Length Field) elégséges lenne 255 bitig terjedõ RLC PDU méretének leírására. A fent említett 30 bájtos RLC SDU-hoz ez ~2% (5/240) viszonylagos többletterhelést (overhead) ad, ami jelentõs javulás a rögzített hosszjelzõvel (Length Indicator) összehasonlítva. Megjegyezzük, hogy a vevõ meg tudja határozni a hosszmezõ (Length Field) aktuális méretét a szállítási formátumon alapulóan, amely egy közös vezérlõcsatornán, például az L1 vezérlõcsatornán átvitelre kerül. A szállítási formátum tartalmazza a kitöltést (padding) magában foglaló teljes szállítási blokk (MAC PDU) méretét. Egy, az ennek a példának megfelelõ konfigurációval bíró hasznos adatcsomag a 6. ábrán látható együtt a hosszjelzõre vonatkozó alábbi példával. Hasonló példa adható meg a hosszjelzõre (Length Indicator, LI). Például amennyiben az MAC fejléc azt jelzi, hogy a beágyazott RLC PDU csak 30 bájt nagyságú, azonban a rögzített méretû LI mezõnek még mindig 13 bájtosnak kellene lennie ahhoz, hogy nagy RLC SDU-kat is támogasson. A potenciális nyeresége annak, hogy az LI mezõ méretét az RLC PDU aktuális méretéhez kötjük, így 8 bit ennél a példánál. A 6. ábra ennek a példának az alkalmazásával egy hasznos adatcsomagot (PDU¹t) mutat be a hosszmezõ- (Length Field, LF) konfigurációra vonatkozó fent említett példával összefüggésben. A találmány egyszerû módot ad arra, hogy hatékonyan csökkentsük az RLC fejléc méretét az LTE esetén [azaz a 3GPP rádiós technológia hosszú távú fejlõdése (Long Term Evolution) esetén, amely a 3GPP rádiós hozzáférési technológia továbbfejlõdése nagy adatsebességû, kis késleltetésû (látenciájú) és csomagoptimalizált rádiós hozzáférési technológia irányában, például a jelzésátvitel optimalizálása révén], azonban alkalmazható lehet bármilyen más kommunikációs rendszernél, ahol adategységeket hozunk létre és viszünk át hasonló módon. A fejléc-többletterhelés (header overhead) fontos kérdés az LTE protokolltervezés esetén, mivel az a protokoll teljesítményére hatással van, csakúgy, mint a rendszer kapacitására. A megoldás javítja a hatékonyságot és a kommunikáció sebességét, különösen az olyan szolgáltatások esetén, amelyek sok kisméretû adategységet generálnak, mint például a VoIP, a TCPACK¹k és a jelenlét-információ (Presence-Information). Például a VolP szolgálatoknál különösen fontos ez, mivel az ilyen fajtájú kommunikáció függ a kis késleltetéstõl (azaz a kommunikációs átvitel során fellépõ rövid késéstõl; a VoIP szolgáltatások felhasználói a szolgáltatás minõségét legalább részben arra a késésre figyelemmel fogják meghatározni, amely a beszéd és azon idõpont között telik el, amikor az megérkezik a kommunikációs összeköttetés másik végpontjára), és a csomagméret beállítása révén lehetõség nyílik arra, hogy
1
HU 008 617 T2
csökkentsük az átviteli idõt, és hogy csökkentsük a kommunikációs csatornákon küldött adatok mennyiségét, ami a kommunikáció jobb teljesítményére vezet. A fent említett hosszoptimalizálási megoldás infrastruktúra-csomópontban és/vagy felhasználói berendezésben kerül implementálásra szoftveres utasításkészletként [amely szoftverfeldolgozó egységen, például mikroprocesszoron vagy DSP¹n (Digital Signal Processor: digitális jelfeldolgozó) fut] vagy valamilyen hardverben található utasításkészletként [amely hardver például FPGA (Field programmable Gate Array: helyszínen programozható, logikai kapukat tartalmazó tömb] vagy ASIC (Application Specific Integrated Circuit: alkalmazásspecifikus integrált áramkör). A 2. ábra egy, a jelen találmány szerinti 200 felhasználói berendezés vázlatos blokkdiagramját szemlélteti. 201 feldolgozóegység (például processzor) úgy van elrendezve, hogy utasításkészleteket futtasson a berendezés kommunikációs részének mûködtetésére. A 201 processzor azután legalább egy felejtõ vagy nem felejtõ 202, 203 memóriaegységet használhat (például RAM¹ot vagy flash memóriát). 204 felhasználói interfész egység együttmûködhet a berendezés felhasználójával bármilyen alkalmas típusú felhasználóiinterfész-berendezés (például billentyûzet, billentyûblokk és/vagy más típusú gombok vagy akár beszédvezérelt megoldás) alkalmazásával. A 200 felhasználói berendezés 205 kommunikációs interfésszel lehet felszerelve a 105 kommunikációs hálózattal a 104 kommunikációs átjárón keresztül való kommunikálásra, és az továbbá különálló 206 kommunikációs interfésszel lehet felszerelve külsõ vagy belsõ egységgel vagy készülékekkel való kommunikálás céljából; példának okáért amennyiben a 200 felhasználói berendezés laptop része, úgy a különálló kommunikációs interfész a laptop belsõ feldolgozó és kommunikációs részeihez lehet csatlakoztatva a 105 kommunikációs hálózat és a 102 laptop bármely alkalmazása közötti információ mediálása céljából. Az utasításkészlet(ek) a berendezés részévé tehetõ(ek) a gyártás idején, letölthetõ(ek) a 100 telekommunikációs hálózat felé tartó vezeték nélküli kommunikációs összeköttetés alkalmazásával, vagy letölthetõ(ek) egy kommunikációs hálózat felé tartó más összeköttetés alkalmazásával, mint például az alábbiak, de nem korlátozva azokat ezekre: a 101 mobiltelefon és egy (nem ábrázolt) PC közötti szinkronizációs összeköttetés, egy laptop és egy kommunikációs hálózat (például az internet) közötti TCP/IP összeköttetés és egy PDA és egy olyan PC közötti vezeték nélküli összeköttetés (például Bluetooth, 802.11, 802.15 vagy 802.16 sorozatú vezeték nélküli kommunikációs protokollok közül legalább egy alkalmazásával), amely azután az internethez van csatlakoztatva. A 3. ábra egy, a jelen találmány szerinti infrastruktúra-csomópontot (például bázisállomást vagy RNC¹t) szemléltet vázlatos blokkdiagramon, ahol is 301 feldolgozóegység kezel kommunikációs adatokat és kommunikációs vezérlõinformációt. A 300 infrastruktúra-csomópont tartalmaz továbbá 302 felejtõ (például
5
10
15
20
25
30
35
40
45
50
55
60 6
2
RAM) és/vagy 303 nem felejtõ memóriát (például merevlemezt vagy flash memóriát), valamint 304 interfészegységet. A 300 infrastruktúra-csomópont tartalmazhat továbbá 305 lefelé irányuló (downstream) kommunikációs egységet, valamint 306 felfelé irányuló (upstream) kommunikációs egységet, amelyek mindegyike megfelelõ (nem ábrázolt) csatlakoztatóinterfésszel van ellátva. Az infrastruktúra-csomópontban lévõ összes egység egymással közvetlenül vagy közvetve a 301 feldolgozó egységen keresztül kommunikálni tud. A hálózathoz csatlakoztatott mobil egységek felé és felõl történõ kommunikáció kezelésére szolgáló szoftver legalább részlegesen ebben a csomópontban kerül végrehajtásra, és a a csomópontban is lehet tárolva; mindazonáltal a szoftver dinamikusan lehet betöltve a csomópont indulásakor vagy egy késõbbi fázisban például egy szervizidõtartam során. A szoftver számítógépes programtermékként implementálható, és számítógéppel olvasható eltávolítható közegen, például hajlékony lemezen, CD¹n (kompaktlemezen), DVD¹n (digitális videolemezen), flash vagy hasonló eltávolítható memóriaközegen (például compact flash, SD secure digital, memorystick, miniSD, MMC multimedia card, smart media, transflash, XD), HD–DVD¹n (High Definition DVD) vagy Bluray DVD¹n, USB¹n (Universal Serial Bus) alapuló eltávolítható memóriaközegen, mágnesszalagos közegen, optikai tárolóközegen, magnetooptikai közegen, buborékmemórián lehet terjesztve és/vagy tárolva, vagy hálózaton (mint például Ethernet, ATM, ISDN, PSTN, X.25, internet, helyi hálózat (Local Area Network, LAN) vagy hasonló, az infrastruktúra-csomópont felé adatcsomagok eljuttatására alkalmas hálózatokon át terjedõ jelként lehet terjesztve. A 4. ábra egy, a jelen találmány szerinti eljárást szemléltet vázlatos blokkdiagramon, ahol is a kommunikáció adóoldala (infrastruktúra vagy felhasználói oldala): 401. Megvizsgálja az adatcsomagot (csomagadategységet) minden egyes csomaghoz vagy adatcsomagtípushoz, amely általában ahhoz az alkalmazáshoz küldendõ; 402. Kiszámol egy megfelelõ hosszmezõméretet; 403. Kiszámol egy megfelelõ hosszjelzõméretet; 404. Ennek megfelelõen az elküldendõ adatcsomagot kialakítja vagy átalakítja; 405. Az adatcsomagra vagy az adatcsomag típusára vonatkozó szinkronizált vezérlõjelzésinformáció-csomagot küld (például különálló vezérlõjel-csatornán, amely fizikai vagy logikai); 406. A létrehozott vagy átalakított adatcsomagot elküldi. A kommunikáció vevõoldala ennek megfelelõen rendelkezik egy, az adatcsomagok kezelésére szolgáló folyamattal azok dekódolására alkalmazásspecifikus adatokká, amely az 5. ábrán került szemléltetésre, ahol is a vevõ: 501. Vezérlõjel-információcsomagot vesz, amely információt tartalmaz a veendõ adatcsomagra vonatkozóan;
1
HU 008 617 T2
502. Veszi a hasznos adatcsomagot (payload data packet); 503. Dekódolja a hasznos adatcsomagot (payload data packet) a vezérlõjel-információból származó információ alkalmazásával, ahol is a hosszmezõ (Length Field) és a hosszjelzõ (Length Indicator) hossza meg van adva; 504. Átadja a dekódolt hasznos (payload) információt egy alkalmazásnak. A jelen találmány felhasználásra találhat számos telekommunikációs alkalmazás esetén, és az nincs korlátozva a példaként fent megadott 3GPP hálózatra. Meg kell jegyeznünk, hogy a „tartalmaz” kifejezés nem zárja ki más elemek vagy lépések jelenlétét azokon túl, amelyek felsorolásra kerültek, és a valamely elemet megelõzõ „egy” szó nem zárja ki több ilyen elem jelenlétét. A találmány legalább részben akár szoftveresen, akár hardveresen implementálható. Meg kell jegyeznünk továbbá, hogy bármely hivatkozási jel nem korlátozza az igénypontok oltalmi körét, és hogy több „eszköz”, „készülék” és „egység” valósulhat meg ugyanazon hardverelem révén. A fent említett és leírt megvalósítási módok csak példaként kerültek megadásra, és azok nem korlátozó jellegûek a jelen találmányra nézve. Egyéb megoldások, alkalmazások, célkitûzések és funkciók a találmánynak az alább megadott igénypontokban igényelt oltalmi körén belül a szakember számára nyilvánvalóak. Definíciók LTE Long Term Evolution: hosszú távú fejlõdés RLC Radio Link Control: rádiós összeköttetésvezérlés MAC Medium Access Control: közeghozzáférés-vezérlés PDU Packet Data Unit: csomagadategység SDU Service Data Unit: szolgálati adategység VoIP Voice over Internet Protocol: beszédhangátvitel internetprotokoll felett GGSN Gateway GPRS Service Node: átjáró GPRS szolgálati csomópont GPRS General Packet Radio Service: általános csomagalapú rádiós szolgálat GTP GPRS Tunnelling Protocol: GPRS alagútprotokoll IP Internet Protocol: internetprotokoll PDN Packet Data Network: csomagalapú adathálózat PDP Packet Data Protocol: csomagalapú adatprotokoll PLMN Public Land Mobile Network: nyilvános földi mobilhálózat RNC Radio Network Controller: rádiós hálózati vezérlõ SGSN Serving GPRS Service Node: kiszolgáló GPRS szolgáltató csomópont UE User Equipment (=MS): felhasználói berendezés
2
UMTS
Universal Mobile Telecommunications System: univerzális mobil telekommunikációs rendszer LAN Local Area Network: helyi hálózat 5 TCP/IP Transmission Control Protocol/Internet Protocol: átvitelvezérlõ protokoll/ internetprotokoll ACK Acknowledgement: nyugtázás SIP Session Initiation Protocol: viszonylétesítõ protokoll. 10
SZABADALMI IGÉNYPONTOK 15
20
25
30
35
40
45
50
55
60 7
1. Csomópont-elrendezés kommunikációs hálózatban (100) csomagadategységben, azaz PDU-ban lévõ fejléc méretének optimalizálására, amely tartalmaz: – eszközt a PDU aktuális méretébõl szolgálati adategység, azaz SDU pozícióazonosítója szükséges méretének származtatására; az alábbiakkal jellemezve: – eszköz PDU fejléc létrehozására optimalizált SDU pozícióazonosító-mezõmérettel; – eszköz vezérlõjel küldésére egy, a PDU fejléctõl elkülönülõ fejlécben vevõ csomópont-elrendezésnek (101, 102, 103, 104) a PDU méretére vonatkozó információval; és – eszköz a PDU küldésére vevõ csomópont-elrendezésnek. 2. Az 1. igénypont szerinti csomópont-elrendezés, amely tartalmaz továbbá: – eszközt vezérlõjel-információ fogadására adó csomópont-elrendezéstõl (101, 102, 103, 104) a PDU méretére vonatkozó információval; – eszközt a PDU méretére vonatkozó információból az SDU pozícióazonosítók optimális méretének származtatására; – eszközt optimalizált PDU vételére az adó csomópont-elrendezéstõl; – eszközt a vett optimalizált PDU dekódolására az SDU pozícióazonosítók származtatott méretén alapulóan. 3. Az 1–2. igénypontok bármelyike szerinti csomópont-elrendezés, ahol is az SDU pozícióazonosítók optimális mérete a PDU bájtban vett kettes alapú logaritmusának függvényeként van kiszámítva a legközelebbi nagyobb egészre kerekítve. 4. Az 1–3. igénypontok bármelyike szerinti csomópont-elrendezés, ahol is közeghozzáférés-vezérlési funkció állítja be az SDU pozícióazonosító-méretet. 5. Az 1–4. igénypontok bármelyike szerinti csomópont-elrendezés, ahol is az SDU pozícióazonosító-méret bármely egész számra van beállítva. 6. Az 1–4. igénypontok bármelyike szerinti csomópont-elrendezés, ahol is az SDU pozícióazonosító-méret támogatott méretek készletének egyikére van beállítva, amelyek legalább olyan nagyok, mint a meghatározott optimális méret. 7. Az 1–6. igénypontok bármelyike szerinti csomópont-elrendezés, ahol is a vezérlõjel-információ kö-
1
HU 008 617 T2
zös vezérlõcsatornán átvitt szállításiformátum-információ. 8. A 7. igénypont szerinti csomópont, ahol is a közös vezérlõcsatorna L1 vezérlõcsatorna. 9. Az 1–8. igénypontok bármelyike szerinti csomópont, ahol is az SDU pozícióazonosító hosszmezõ és hosszjelzõ legalább egyikét tartalmazza. 10. Az 1–9. igénypontok bármelyike szerinti csomópont, ahol is a csomópont mobilterminál és infrastruktúra-csomópont egyikét tartalmazza. 11. Eljárás csomagadategységek, azaz PDU fejlécméretének optimalizálására telekommunikációs hálózatban (100), amely az alábbi lépéseket tartalmazza: – a PDU aktuális méretébõl szolgálati adategység, azaz SDU pozícióazonosító-mezõjének szükséges méretét származtatjuk; az alábbiakkal jellemezve: – PDU fejlécet hozunk létre optimalizált SDU pozícióazonosító-mérettel; – vevõ csomópontnak vezérlõjelet küldünk különálló kommunikációs csatornán vagy egy másik fejlécelemben a PDU méretére vonatkozó információval; – a PDU¹t a vevõ csomópontnak küldjük; ahol is a vezérlõjel az SDU pozícióazonosító-méretre vonatkozó információt tartalmaz. 12. Vevõ csomópont vezeték nélküli kommunikációs hálózatban (100), amely tartalmaz:
5
10
15
20
25
8
2
– eszközt vezérlõjel-információ vételére adó csomópont-elrendezéstõl (101, 102, 103, 104) csomagadategység¹, azaz PDU mezõ méretére vonatkozó információval, a PDU egy másik üzenetben veendõ; az alábbiakkal jellemezve: – eszköz a PDU méretére vonatkozó információból az SDU pozícióazonosítók optimális méretének származtatására; – eszköz optimalizált csomagadategységek vételére az adó csomópont-elrendezéstõl; – eszköz a vett optimalizált PDU dekódolására az SDU pozícióazonosítók származtatott méretén alapulóan. 13. Utasításkészlet kommunikációs hálózatban (100) lévõ csomópont-elrendezésben, amely az alábbiakra szolgáló utasításkészleteket tartalmaz: – küldendõ hasznos adatok fogadása; – a PDU aktuális méretébõl szolgálati adategység, azaz SDU pozícióazonosító-mezõje szükséges méretének származtatása; azzal jellemezve, hogy az alábbiakra szolgáló utasításkészletet tartalmaz továbbá: – PDU fejléc létrehozása optimalizált SDU pozícióazonosító-mérettel; – vevõ csomópont-elrendezésnek (101, 102, 103, 104) egy, a PDU fejléctõl elkülönülõ fejlécben vezérlõjel küldése a PDU méretére vonatkozó információval; és – a PDU küldése vevõ csomópontnak.
HU 008 617 T2 Int. Cl.: H04L 12/56
9
HU 008 617 T2 Int. Cl.: H04L 12/56
10
HU 008 617 T2 Int. Cl.: H04L 12/56
11
HU 008 617 T2 Int. Cl.: H04L 12/56
12
HU 008 617 T2 Int. Cl.: H04L 12/56
13
HU 008 617 T2 Int. Cl.: H04L 12/56
Kiadja a Szellemi Tulajdon Nemzeti Hivatala, Budapest Felelõs vezetõ: Szabó Richárd osztályvezetõ Windor Bt., Budapest
