!HU000008037T2! (19)
HU
(11) Lajstromszám:
E 008 037
(13)
T2
MAGYAR KÖZTÁRSASÁG Magyar Szabadalmi Hivatal
EURÓPAI SZABADALOM SZÖVEGÉNEK FORDÍTÁSA (51) Int. Cl.:
(30) Elsõbbségi adatok: 499638 P 2003. 09. 02. 513460 P 2003. 10. 21.
(73) Jogosult: Nokia Corporation, 02150 Espoo (FI)
US US
(72) Feltalálók: CURCIO, Igor, Danilo, Diego, FIN-33100 Tampere (FI); LUNDAN, Miikka, FIN-33820 Tampere (FI); AKSU, Emre, Baris, FIN-33720 Tampere (FI) (54)
HU 008 037 T2
H04L 29/06
(21) Magyar ügyszám: E 04 769236 (22) A bejelentés napja: 2004. 09. 01. (96) Az európai bejelentés bejelentési száma: EP 20040769236 (97) Az európai bejelentés közzétételi adatai: EP 1661366 A1 2005. 03. 10. (97) Az európai szabadalom megadásának meghirdetési adatai: EP 1661366 B1 2010. 02. 17.
(2006.01) H04L 12/56 (2006.01) (87) A nemzetközi közzétételi adatok: WO 05022865 PCT/IB 04/002826
(74) Képviselõ: dr. Harangozó Gábor, DANUBIA Szabadalmi és Jogi Iroda Kft., Budapest
Szolgáltatásminõségre vonatkozó beágyazott információ továbbítása
A leírás terjedelme 16 oldal (ezen belül 4 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 Magyar Szabadalmi Hivatal nem vizsgálta.
1
HU 008 037 T2
A találmány szakterülete A találmány szolgáltatásminõségre vonatkozó információ továbbítására szolgáló eljárással kapcsolatos, amely információ legalább egy irányban továbbítandó egy elsõ eszköz és egy második eszköz között. A találmány vonatkozik továbbá a megfelelõ eszközökre, a megfelelõ hálózati elemekre és a megfelelõ rendszerekre. A találmány háttere Azon sokféle szolgáltatások egyike, amelyre vonatkozóan az adott szolgáltatás minõségére jellemzõ információt kell adott esetben továbbítani, lehet például egy adatfolyam-szolgáltatás. Egy adatfolyam-szolgáltatás (streaming class service) esetén egy, az adatfolyamot küldõ szerver (streaming server) médiaadatokat küld egy hálózaton keresztül egy, adatfolyamot fogadó kliensnek (streaming client) oly módon, hogy a médiaadatok egy állandó és folytonos adatfolyamként feldolgozhatók a kliens oldalán. A folyamatos adatküldési (streaming) alkalmazásra példaként említhetõk az internetes videotermékek. Az adatfolyamküldõ szerver azonban a hálózaton belül is elhelyezkedhet. A hálózat- vagy az internetszolgáltató üzemeltetõi érdekeltek abban, hogy képesek legyenek értékelni egy adatfolyamot fogadó kliens felhasználója által érzékelt szolgáltatásminõséget (QoS). Jelenleg a 3GPP TS 26.234 szabvány szerinti protokollok használatával definiált adatfolyam-szolgáltatási kapcsolat (streaming session) csak korlátozott minõségû információ megismerését teszi lehetõvé a végfelhasználó által érzékelt minõség tekintetében. A kliens a szervernek valós idejû átvitelvezérlõ protokoll (Real-Time Transport Control Protocol, RTCP) szerinti vevõoldali jelentéseket (Receiver Reports) továbbít a hálózat viselkedésére vonatkozó információkkal, amely információk például csomagvesztésekkel, késleltetési jitterrel, a fogadott szekvenciaszám legnagyobb kumulált értékébõl vagy a valós idejû átviteli protokoll (Real-Time Transport Protocol, RTP) csomagokkal kapcsolatos egyéb információkat tartalmaz. Ezenkívül a szerver adóoldali jelentéseket (Sender Reports) küld a kliensnek, amely az adóra vonatkozó információkat tartalmaz. Ezek a jelentések azonban nem teszik lehetõvé egy adatfolyamküldõ szerver számára – vagy egy adatfolyamküldõ szerveren keresztül az üzemeltetõ számára –, hogy bármilyen további információt szerezzen az adatfolyamot fogadó klienstõl az észlelt QoS-értékre vonatkozóan, például a sérült videokeretek számáról, az újrapufferelések idõtartamáról, az audiorések hosszáról stb. Ezek az információk az adatfolyamot fogadó klienstõl az adatfolyamküldõ szerverhez csak az RTCP jelentésekben jelenleg hordozott információ kiterjesztésével továbbíthatók, vagyis az RTCP kibõvített jelentésekkel (RTCP Extended Reports) vagy RTCP XR csomagokkal. Egy ilyen kiterjesztés QoS-mérõszámok egy csoportját tartalmazza, melyek információval szolgálnak a kapcsolat felépítésérõl és lebontásáról, a beszéd- és audiorésekrõl, a sérült videokeretekrõl, az újrapufferelésrõl és a
5
10
15
20
25
30
35
40
45
50
55
60 2
2
kezdeti pufferelésrõl, egymás után elveszett csomagokról és más lehetséges információkról a kapcsolatra és a médiaátvitelre vonatkozóan. Az IETF RFC 2328 (RTSP specifikáció, 1998. április), az IETF RFC 3550 (RTP specifikáció, 2003. július) és az RTP vezérlõprotokoll kibõvített jelentések (RTCP XR, 2003. május) tervezete például lehetõvé teszi az adatfolyamot fogadó kliens számára, hogy információt szolgáltasson a beérkezõ RTP csomagokról, ideértve a csomagvesztési hányadot, a késleltetési jittert, a beérkezõ legmagasabb szekvenciaszámot és csomagvesztések szekvenciáját. Az alábbi két dokumentum, nevezetesen a Draft Rel¹6 „PSS Quality Metrics Permanent Document”, 3GPP TSG¹S4 Meeting #27, 2003. július 7–11., Tdoc S4–030562 és a „Stream Quality Metrics – Client metrics”, 3GPP TSG¹S4 Meeting #26, 2003. május 5–9., Tdoc S4–030353 a QoS-mérõszámok további általános problémáit ismerteti a 3GPP (3rd Generation Partnership Project) együttmûködésben. Az elsõ irat azt ismerteti, hogy milyen információt kell elküldeni a beszédre, audióra, videóra, játékra és hálózati mérõszámokra vonatkozó 25 különbözõ paraméter felhasználásával, továbbá, hogy milyen protokollt kell használni. Ezenkívül a második irat magas szintû követelményeket és mûszaki megfontolásokat tartalmaz. Az említett iratok egy olyan eljárást definiálnak, amelyben a kliens kiszámítja az információt és elküldi azt a szervernek, amennyiben az kéri. Átviteli célokra az RTSP protokoll GET_PARAMETER üzenetének használatát javasolja, melyet a szerverbõl a kliensnek kell elküldeni, valamint az RTSP protokollnak a kliensbõl a szerverhez küldendõ SET_PARAMETER üzenetének használatát javasolja. Ezeket az üzeneteket részletesebben is definiálják az alábbi dokumentumban: „Streaming quality MetricsTransport”, 3GPP TSG¹S4 Meeting #28, 2003. szeptember 1–5., Tdoc S4–030629. Ebben az iratban azt javasolják, hogy a QoS-mérõszámok triggerelésére a szerverbõl a klienshez egy RTSP SET_PARAMETER üzenetet továbbítsanak. A kliens egy RTSP 200 OK üzenettel válaszolhat, ha elfogadja, hogy QoS-mérõszámokat küldjön. A szerver ezután elküldheti a QoSmérõszámokra vonatkozó kapcsolat leírását egy további SET_PARAMETER üzenettel, amely a kapcsolat leírását tartalmazó METRICS¹SETUP paramétert tartalmaz, amely tartalmaz egy tartomány (Range), egy idõtartam (Period) és egy küldõ (Sender) paramétert. Szintén ezt az üzenetet kell elfogadnia a kliensnek is egy RTSP 200 OK üzenettel. Az is lehetséges, hogy a szerver megkéri a klienst, hogy juttassa el számára a QoS-mérõszámok kapcsolatának leírását egy GET_PARAMETER üzenettel. Miután a QoS-mérõszámok kapcsolata leírásra került és abban megállapodtak, akár a kliens is elküldheti a QoS-mérõszámokat egy SET_PARAMETER üzenettel, vagy a szerver lekérdezheti a QoS-mérõszámokat egy GET_PARAMETER üzenettel. Ezen megoldás egyik hátránya, hogy a szükséges három pár üzenet olyan késleltetést idéz elõ, amely le-
1
HU 008 037 T2
lassíthatja a kapcsolat felépítését. A javasolt megoldás még akár össze is keverheti több kapcsolat létesítését, mivel a kliens már esetleg el is küldte az elsõ üzenetet ahhoz, hogy adatot kapjon a szervertõl, mielõtt megérkezne hozzá a második SET_PARAMETER üzenet. Andrew S. Tanenbaum „Számítógép-hálózatok” (2002. augusztus 31., Pearson Education Inc., Upper Saddle River, NJ, USA) címû könyvében azt javasolja, hogy megkülönböztetett szolgáltatásokat (differentiated services, DS) nyújtsanak azok a routerek, amely azonos adminisztratív tartományba tartoznak. Az adminisztráció egy sor olyan szolgáltatási osztályt definiál, amelyek megfelelõ továbbítási szabályokkal rendelkeznek. Amennyiben egy kliens egy DS szolgáltatásra jelentkezik, a tartományba belépõ kliens adatcsomagjai tartalmazhatnak egy szolgáltatás típusa (Type of Service) mezõt, amelynek eredményeként egyes osztályok számára jobb szolgáltatást nyújt, mint a többi számára. A találmány összefoglalása A találmánnyal célunk egy eszköznek a szolgáltatás minõségére vonatkozó információval való eddigieknél jobb ellátása, például egy adatfolyamküldõ szerver ellátása olyan információval, amely egy adatfolyamszolgáltatás végfelhasználó által érzékelt minõségére vonatkozik. A találmánnyal további célunk két eszköz közötti adatfolyam-szolgáltatási kapcsolat létesítésének felgyorsítása és a kapcsolatfelépítések összekeverésének elkerülése. Ennek megfelelõen az 1. igénypont szerinti eljárást, a 10. igénypont szerinti szoftverkódot és a 11. igénypont szerinti eszközt javasoljuk. Hasonló módon egy hálózathoz tartozó hálózati elemet is javasolunk, amely szolgáltatás minõségre vonatkozó információknak egy, az adott hálózathoz hozzáférõ eszköznek történõ továbbítására vonatkozó megfelelõ jellemzõkkel rendelkezik. A találmány értelmében ezenkívül egy rendszert is javasolunk, amely legalább két eszközt tartalmaz. Az elsõ eszköz megfelel a fentiekben javasolt eszköznek. A második eszköz egy olyan vevõegységet tartalmaz, amely az elsõ eszköz által továbbított protokollüzenetet fogadja és egy olyan leválasztókomponenst tartalmaz, amely leválasztja a szolgáltatásminõséggel kapcsolatos információt a beérkezõ protokollüzenetekrõl. A találmány azon a felismerésen alapul, hogy a QoS-sel kapcsolatos információnak legalább egy része hozzácsatolható azokhoz a protokollüzenetekhez, amelyeket két eszköz között továbbítunk valamilyen módon. Ennek eredményeként az üzenetek száma lecsökken, mivel a QoS-sel kapcsolatos információkat tartalmazó dedikált üzenetpárok használatát kiküszöböljük. A QoS-sel kapcsolatos információ továbbítására dedikált üzeneteket használó ismert megoldásokkal összevetve, a találmány egyik elõnye, hogy kevesebb jelzési többletadatot igényel, továbbá az adatcsere felgyorsul, lehetõvé teszi a kapcsolat gyorsabb felépítését, továbbá lehetõvé teszi nagyobb mennyiségû QoSsel kapcsolatos információ egyszerû továbbítását. Az ilyen nagyobb mennyiségû QoS-sel kapcsolatos infor-
5
10
15
20
25
30
35
40
45
50
55
60 3
2
máció használható például a QoS-adatok egyeztetésére vonatkozó üzenetváltásokhoz, az egyeztetett QoSadatok egynél többször történõ továbbításához, a QoS-adatoknak egy felépített kapcsolat során tervezett megváltoztatásához vagy QoS-adatoknak egy kapcsolat során történõ továbbításának leállításához. Amennyiben a QoS-sel kapcsolatos információ a kapcsolatfelépítõ üzenetekben kerül elhelyezésre, a kapcsolat felépítése közben az összekeveredés szintén kiküszöbölhetõ. Nyilvánvaló, hogy a protokollüzenet összeállítása és a QoS-sel kapcsolatos információknak ezen üzenethez történõ hozzácsatolása megvalósítható, de nem szükségszerûen megvalósítandó több egymást követõ lépésben. A hozzácsatolás a protokollüzenet összeállításának részét is képezheti. Ezenkívül a QoS-sel kapcsolatos információ egy protokollüzenet bármely részéhez hozzácsatolható, például elhelyezhetõ a protokollüzenet fejrészében vagy attribútumként a protokollüzenet törzsében. További elõnyt jelent, hogy lehetõség nyílik a jelentésküldések értesítések gyakoriságának beállítására. A találmány egyik lehetséges kiviteli alakjánál a javasolt eljárás az alábbi lépéseket tartalmazza: legalább az egyik eszközben létrehozzuk a szolgáltatás minõségére vonatkozó információt egy protokollüzenet fejrészében vagy egy attribútumában, majd továbbítjuk a protokollüzenetet a megfelelõ másik elsõ eszköznek és a második eszköznek. A találmány egy másik lehetséges kiviteli alakjánál a javasolt szoftverkód elõállítja a szolgáltatás minõségére vonatkozó információt egy protokollüzenetnek legalább egy fejrész mezõjében vagy egy attribútumában. A találmány egy további lehetséges kiviteli alakjánál az összeállító komponens úgy van kialakítva, hogy a szolgáltatás minõségére vonatkozó információt egy protokollüzenet fejrész mezõje és annak egy attribútuma közül legalább az egyikben elõállítja. A bemutatott kiviteli alakok azon a felismerésen alapulnak, hogy egy protokollüzenet fejrészének vagy attribútumának felhasználása a QoS-sel kapcsolatos információ továbbítására különösen elõnyös, mivel ebben az esetben egyetlen vezérlõmodul használható a protokollüzenetek elemzésére és az információ kinyerésére, ideértve a QoS-sel kapcsolatos információkat, majd a kinyert információ továbbítására a rendszerben lévõ azon modulok számára, amelyeknek szükségük van az adott információkra. A bemutatott kiviteli alakok így például egy újonnan definiált RTSP fejrész mezõn alapulhatnak, amely a QoS-sel kapcsolatos információ továbbítására használandó egy adatfolyam-szolgáltatási kapcsolat felépítés során vagy egy adatfolyamküldés során. Az új RTSP fejrész vagy attribútum használatán kívül további lehetõség egy új RTSP üzenet definíció használata a QoS-mérõszámok jelzésére, egy tartalomhosszúság (content length) mezõ használata és egy üzenettest beszúrása egy RTSP üzenet végére, vagy QoS-mérõszámokkal kapcsolatos paraméterkészlet definiálása a SET_PARAMETER és a GET_PARAMETER RTSP üzenetek használatánál. Az
1
HU 008 037 T2
implementáló szakember azt is választhatja, hogy nem használ RTSP fejrész mezõt a QoS-mérõszámokhoz annak érdekében, hogy a QoS-mérõszámok jelzését teljesen elválassza az adatfolyam-küldési kapcsolat szintû jelzéstõl. A protokollüzenet általában elsõsorban – de nem kizárólagosan – egy RTSP üzenet, egy RTCP üzenet, egy kapcsolatkezdeményezõ protokoll (SIP) üzenet vagy egy kapcsolatleíró protokoll (SDP) leírás. A javasolt módszerben az RTSP üzenetek használata azzal a különös elõnnyel jár, hogy ez a protokoll rugalmas átvitelt tesz lehetõvé, ami sokkal megbízhatóbb, mint az RTCP adatátvitel. Az a szolgáltatás, amelyre a szolgáltatásminõség vonatkozik, lehet például – de nem kizárólagosan – egy adatfolyam-szolgáltatás. Az ilyen adatfolyam-szolgáltatáshoz használható például az RTSP és az RTCP. Ennek megfelelõen a javasolt eszközök lehetnek például egy adatfolyam-szolgáltatásban részt vevõ vevõegységek vagy adóegységek, vagyis egy adatfolyamot fogadó kliens vagy egy adatfolyamküldõ szerver. A találmány különösen alkalmas arra, hogy lehetõvé tegye egy adatfolyamküldõ szerver számára, hogy kitalálja azt, hogy egy adatfolyamot fogadó kliens az adott idõpontban hogyan fogadja az adatokat és hogyan szerezzen több információt a felhasználó által tapasztalt minõségrõl (QoE – Quality of Experience), valamint azokról a problémákról, amelyek egy adatfolyam-szolgáltatási kapcsolat során felmerülhetnek. További szolgáltatás lehet például az IP¹alapú hangátvitel, a videotelefonálás, vagy egyirányú videobeszélgetés. További ilyen szolgáltatásként használható különösen az SIP konferenciakapcsolási protokoll. A protokollüzenet továbbítása megvalósítható például egy kapcsolat létesítése során és/vagy egy, az adott szolgáltatásra vonatkozó, felépített kapcsolat során. A QoS-sel kapcsolatos információ egy megfelelõ protokollüzenetben tartalmazhat például egy folyamatban lévõ szolgáltatásnál elért QoS¹re vonatkozó jelentést. Ez a jelentés tartalmazhat például olyan paramétereket és/vagy nyers adatokat, amelyeket egyik eszköz szolgáltat a másik számára. A nyers adatok közé tartoznak például az eseményekrõl vagy mérési adatokról szóló értesítések, míg a paraméterek, amelyeket mérõszámoknak is nevezünk, feldolgozott nyers adatok. Ezenkívül, a QoS-sel kapcsolatos információ tartalmazhat egy elsõ eszköztõl egy második eszközhöz irányuló kérést egy folyamatban lévõ szolgáltatásra vonatkozóan elért QoS¹re vonatkozó ilyen információ szolgáltatására és/vagy olyan adatok szolgáltatására, amelyek az elért QoS¹re vonatkozó, továbbítandó információt határozzák meg. Ilyen adatok az eszközök között az adott jelentésben megküldendõ elért QoS¹re vonatkozó információ mértékének és gyakoriságának egyeztetésének részét képezik. Egy elõnyös kiviteli alaknál, például adatfolyamszolgáltatás esetén, a QoS-sel kapcsolatos információt egy kapcsolatleíró protokoll (Session Description Protocol, SDP) üzenet vagy egy RTSP DESCRIPTION reply message 200 OK üzenet, egy RTSP SETUP üze-
5
10
15
20
25
30
35
40
45
50
55
60 4
2
net, egy RTSP PLAY üzenet, egy RTSP PAUSE üzenet vagy egy RTSP TEARDOWN üzenet fejrész mezõje tartalmazza. Az „QoS-mérõszám paraméterek létrehozása” üzenet célszerûen egy SDP üzenethez van csatolva egy RTSP DESCRIPTION üzenetre adott válasz belsejében. Szintén elõnyös, ha a „QoS-mérõszám paraméter változás” üzenet bármilyen RTSP üzenethez, például egy RTSP PAUSE üzenethez van csatolva, amit vagy maga a kliens eszköz vagy a kliens eszköz felhasználója kezdeményez. Meg kell jegyezni, hogy az SDP nem használható egy felépített kapcsolat során. A QoS-jelentés definiálásához, például egy adatfolyam-szolgáltatáshoz, a minimális követelmények egy halmazát kell definiálni. A továbbiakban a QoS-jelentés tulajdonságait definiáljuk, amelyek lehetõvé teszik, hogy az említett tulajdonságok a lehetõ legnagyobb mértékben ki legyenek használva, valamint hogy az adatfolyam-szolgáltatás teljesítménye maximális legyen. Nyilvánvaló azonban, hogy a megfelelõ tulajdonságok elõnyösek más típusú szolgáltatások esetén is. Elõnyös, ha a QoS-jelentés egyeztethetõ egy adatfolyamküldés kezdetén és egy felépített kapcsolat során. Elõnyös továbbá, ha a QoS-jelentést mindig az adatfolyamküldõ szerver kérelmezi. Szintén elõnyös, ha lehetõség nyílik a mérõszámok egy csoportjának egyetlen üzenetben történõ csoportosítására. A szerver a klienst egyetlen üzenet révén kérheti arra, hogy küldjön jelentést egyetlen nyers adatról vagy egyetlen paraméterrõl vagy több nyers adatról és/vagy több paraméterrõl. Szintén elõnyös, ha lehetõség van a jelentés egyeztetésére a kapcsolat vagy a média szintjén, mint granularitási jellemzõ, például a levegõinterfészen továbbított információ minimalizálására és annak szelektív kiválasztására, hogy mirõl szóljon a jelentés és melyik közegbõl legyen továbbítva. Szintén elõnyös, ha lehetõség van a jelentésküldés ki¹, illetve bekapcsolására. A jelentésküldés gyakorisága lehet periodikus, eseményvezérelt vagy történhet egy kapcsolat végén. Periodikus jelentésküldés esetén a periódust az adatfolyamküldõ szerver határozza meg és azzal egyetért az adatfolyamot fogadó kliens. Az adatfolyamot fogadó kliens az egyeztetett értékekkel válaszol, amelyek kevésbé optimálisak is lehetnek, mint azok, amiket a szerver kért. Eseményvezérelt jelentés küldés esetén a „rossz minõségû” eseményekrõl ad számot az adatfolyamot fogadó kliens. Ez a megoldás minimálisra csökkenti az adatfolyamot fogadó klienstõl az adatfolyamküldõ szerverhez továbbítandó információ mennyiségét. A kapcsolat végén végrehajtott jelentésküldés problémákat okozhat, ha a kapcsolat abnormális módon ér véget. Amennyiben a szolgáltatás szünetelõ (Pause) állapotban van, a kliens esetleg nem küld QoS-sel kapcsolatos visszacsatoló adatokat annak érdekében, hogy megelõzze a rádiós erõforrások felesleges igénybevételét haszontalan adatok küldésével. A szervernek képesnek kell lennie kezelni az ilyen megszakítást. A QoS-mérõszámokat célszerûen a szerver számítja ki. Magyarán, az adatfolyamot fogadó kliens az ese-
1
HU 008 037 T2
mények és/vagy mérési eredmények egy csoportjáról ad tájékoztatást és a szerver végzi el a számításokat, például meghatározza egy adott idõablakra vonatkozó bizonyos értékek minimumát, átlagát és/vagy maximumát. Az adatfolyamküldõ szerver azonban késleltetheti is az aktuális statisztikák kiszámítását a kapcsolat végéig vagy az alacsonyabb terheléssel járó idõszakokig. Arra is lehetõség van, hogy a mérõszámokat a kliens számítsa ki. Ebben az esetben a kliensben lévõ eszközök komplexitásának minimálisnak kell lenni. Ügyelni kell azonban arra is, hogy a különbözõ szerverek azonos módon számítsák ki a QoS-mérõszámokat annak érdekében, hogy biztosítani lehessen az objektivitást. Miután a 3¹as és 4¹es szintû (L3–L4) mérõszámok rendelkezésre állnak a normális RTCP jelentésekben vagy RTCP XR jelentésekben, a találmány különösen jól használható 5¹ös szintû (L5) mérõszámok és nyers adatok továbbítására. A kliensnek képesnek kell lennie adott számú QoS-jelentés pufferelésére és azokban egyetlen jelentésben történõ elküldésére egy adott idõkorláton belül annak érdekében, hogy normálisra csökkenjen a levegõinterfészen keresztül továbbított üzenetek száma. Az ilyen elküldött információra példa a kapcsolatazonosító, a hibák közötti idõtartam, az idõcímke stb. A jelen találmány további céljait és jellemzõit a leírás további részében ismertetjük részletesen a mellékelt rajzra történõ hivatkozással. Nyilvánvaló azonban, hogy a rajz kizárólag illusztrációs célokat szolgál, és nem jelenti a találmány korlátozását, a találmányt a mellékelt igénypontok ismertetik. Szükséges megjegyeznünk továbbá, hogy az ábrák nem méretarányosak és kizárólag a leírásban bemutatott struktúrák és eljárások elvének bemutatására szolgálnak. Az ábrák rövid ismertetése Az 1. ábra egy olyan rendszert ábrázol vázlatosan, amelyben a találmány implementálható; a 2. ábra az 1. ábrán látható rendszerben lévõ kliens által észlelhetõ eseményeket és mérési eredményeket bemutató táblázat; a 3. ábra az 1. ábrán látható rendszerben lévõ klienssel kiszámítható mérõszámokra példák bemutató táblázat; és a 4. ábra egy vázlatos jelzési folyamatábra, amely a találmány szerinti eljárás egyik kiviteli alakját mutatja be. A találmány részletes ismertetése Az 1. ábra egy olyan 10 rendszer mutat vázlatosan, amelyben a találmány alkalmazható. A 10 rendszer tartalmaz egy olyan 20 adatfolyamküldõ szervert, amely kérésre továbbított videoadatfolyamot (video streaming on¹demand) biztosít. A 10 rendszer tartalmaz továbbá egy olyan 30 adatfolyamot fogadó klienst, amely megvalósítható például egy mobiltelefonban. A 30 adatfolyamot fogadó kliens egy 40 hálózaton keresztül kapcsolódik a 20 adatfolyamküldõ szerverhez és a 20 adatfolyamküldõ szer-
5
10
15
20
25
30
35
40
45
50
55
60 5
2
vertõl kérhet, illetve fogadhat videoadatfolyamot. A 40 hálózat összekapcsolhat például egy nyilvános földi mobiltelefon-hálózatot (PLMN), amelyhez a mobiltelefon a 30 adatfolyamot fogadó kliensen keresztül csatlakozhat, és az internetet, amelyhez a 20 adatfolyamküldõ szerver csatlakoztatható. Szükségesnek tartjuk megjegyezni, hogy a 30 adatfolyamot fogadó kliens része is lehet a 40 hálózat egyik hálózati elemének. A 20 adatfolyamküldõ szerver tartalmaz egy olyan 21 egyesítõkomponenst, amely egyesíti egy 22 adóegységhez továbbított RTSP üzeneteket, valamint egy olyan 23 leválasztókomponenst, amely egy 24 vevõegységhez tartozó QoS-adatok leválasztására szolgál. A 21, 23, 31 és 33 komponensek megvalósíthatók szoftverként és hardverként egyaránt. A 30 adatfolyamot fogadó kliens alkalmas arra, hogy egy adatfolyamküldõ szervernek való továbbítás céljából három különbözõ típusú QoS-sel kapcsolatos értéket szolgáltasson, nevezetesen eseményeket, mérési eredményeket és mérõszámokat. Az események a 30 adatfolyamot fogadó kliensben elõforduló véletlen események vagy hibák, amelyek anomáliákat és a közeg elméleti, referenciaként szolgáló hibamentes átvitelétõl való eltéréseket idéznek elõ, és amelyek tartalmazhatják például egy beszédszünet idõtartamát. A mérési eredmények egy olyan nyomkövetõ rendszert határoznak meg, amely monitorozza az adatfolyamszolgáltatási kapcsolatot normál és abnormális körülmények között, és tartalmazhatja például a kapcsolatfelépítés idejét. A mérõszámok az eseményeken és a mérési eredményeken alapuló számítások, melyek tartalmazhatják például egy beszédszünet átlagos és/vagy maximális idõtartamát. Az 1. ábrán látható 10 rendszerben egy olyan eljárást implementálunk, amely képes kezelni az események, mérési eredmények és mérõszámok továbbítását a 30 adatfolyamot fogadó klienstõl a 20 adatfolyamküldõ szerverhez. Közelebbrõl, a 30 adatfolyamot fogadó kliens és a 20 adatfolyamküldõ szerver között bármelyik irányban továbbított összes QoS-sel kapcsolatos adat, ideértve az eseményeket, a mérési eredményeket és a mérõszámokat, akárcsak a QoS-sel kapcsolatos definíciókat és egyeztetési adatokat, a 21, illetve 31 egyesítõkomponensek által történõ továbbítás céljából olyan RTSP üzenetekhez csatoljuk, amelyek más célból már egyesítve vannak. A kiegészített RTSP üzenetet ezután a megfelelõ 20, 3 adóegység 22, 32 adója révén a 40 hálózaton keresztül továbbítjuk a megfelelõ 30, 20 vevõegység 34, 24 vevõjéhez. A megfelelõ 30, 20 vevõegységben a QoS-adatokat további felhasználás céljából leválasztjuk a beérkezõ RTSP üzenetrõl a QoS-adatok leválasztására szolgáló megfelelõ 33, 23 leválasztókomponensben. Amennyiben a 30 adatfolyamot fogadó kliens eseményeket vagy mérési eredményeket továbbít, az adatfolyamot fogadó kliens csak észleli az eseményeket és/vagy mérési eredményeket és azokról jelentést küld a 20 adatfolyamküldõ szervernek. A 20 adatfolyamküldõ szerver ezután elvégzi a mérõszámok kiszá-
1
HU 008 037 T2
mítását. Ha a mérõszámok meghatározásra kerültek és a 30 adatfolyamküldõ szerver továbbította azokat, a 20 adatfolyamküldõ szerver elõzetesen kiszámított mérõszámokat kap. Ha a 30 adatfolyamot fogadó kliens számítja ki a mérõszámokat, nagyobb feldolgozási teljesítmény szükséges a mobiltelefonban, és a továbbítandó adatok még terjedelmesebbek, mivel egyetlen eseményen vagy mérési eredményen kívül számos további mérõszám számítható ki. Azokra az eseményekre és mérési eredményekre, amelyeket 30 adatfolyamot fogadó kliens tud érzékelni, a 2. ábrán látható táblázatban mutatunk be példákat, míg azokra a mérõszámokra, amelyeket a 30 adatfolyamot fogadó kliens vagy a 20 adatfolyamküldõ szerver tud kiszámítani, a 3. ábrán látható táblázatban mutatunk be példákat. Nyilvánvaló, hogy a 10 rendszerben alkalmazott események, mérési eredmények és mérõszámok listája eltérhet a példaként bemutatottól. A fentieken túl a 30 adatfolyamot fogadó klienstõl a 20 adatfolyamküldõ szerverhez továbbított, eseményeket, mérési eredményeket és/vagy mérõszámokat tartalmazó visszacsatoló üzenetek továbbításának gyakoriságát négy különbözõ módon lehet definiálni. Az elsõ, periodikus megoldásnál a visszacsatoló üzeneteket egy kapcsolat során küldjük vissza bizonyos ütemezés szerint. Ez lehetõséget biztosít a szerver számára arra, hogy szükség esetén beállítsa a továbbított média-adatfolyam(ok) QoS-értékét. A meghatározott gyakoriságtól függõen ez a felfelé irányuló összeköttetésen (uplink) többlet adatforgalmat idézhet elõ, amennyiben a jelentésküldés periódusideje túl rövid. A második, eseményalapú megközelítésnél a visszacsatoló üzeneteket a 30 kliensben megvalósuló események bekövetkezése alapján küldjük el. Ez az eljárás szintén lehetõvé teszi a 20 szerver számára, hogy szükség esetén lépéseket tegyen a kapcsolat során. Amennyiben az eseménygyakoriság túl nagy, túl sok többletforgalom keletkezhet a felfelé irányuló összeköttetésen, hacsak nem több eseményt ugyanahhoz az üzenethez fûzünk hozzá. A harmadik lehetõség, hogy egy visszacsatoló üzenetet csak egyszer küldjünk el a kapcsolat végén. Ez az eljárás rendkívül hatékony a sávszélesség felhasználása szempontjából, de az esemény, amelyrõl a jelentés szól, esetleg már aktualitását veszti a kapcsolat végére. A negyedik megközelítés az, amikor egy visszacsatoló üzenetet az elõzõ kapcsolat eseményeivel, mérési eredményeivel vagy mérõszámaival együtt, a következõ kapcsolat elején küldjük el. Ez az eljárás azzal a hátránnyal jár, hogy azok az események, amelyekrõl a jelentés szól, akár többnaposak is lehetnek attól függõen, hogy a felhasználó milyen gyakran vesz igénybe szolgáltatást, és ezért adott esetben aktualitását veszti az ilyen jelentés. Az 1. ábrán látható rendszerben a QoS-sel kapcsolatos adatok átvitelének lényegében két szakasza van; egy tárgyalási szakasz az adatfolyam-szolgáltatási kapcsolat felépítése során és egy visszacsatolási szakasz a folyamatban lévõ adatfolyam-szolgáltatási kapcsolat során. Mindkét szakaszt részletesen ismertetjük a 4. ábra segítségével. A 4. ábrán egy olyan jelzési fo-
5
10
15
20
25
30
35
40
45
50
55
60 6
2
lyamatábra látható vázlatosan, amely a 20 adatfolyamküldõ szerver és a 30 adatfolyamot fogadó kliens közötti jelzést szemlélteti. Ezenkívül újbóli tárgyalási szakaszokra szintén lehetõség van a folyamatban lévõ adatfolyam-szolgáltatási kapcsolat során. Egy RTSP kapcsolatfelépítés során egy adatfolyam-szolgáltatási kapcsolat létesítésekor a 30 adatfolyamot fogadó kliens és a 20 adatfolyamküldõ szerver megegyeznek abban, hogy milyen mérõszámokat, mérési eredményeket és eseményeket továbbítanak és milyen gyakran. Az egyeztetés céljából az alábbi új QoS-mérõszám fejrészt definiáljuk, amely eltér a fentiekben említett TSG-SA4 Meeting #28 iratban definiált fejrésztõl: QoS-header=”QoS-Metrics” ”:” ”Off” / 1#(stream-url ”;” Metrics ”;” Sending-rate [”;” Range]) CRLF stream-url=”url” ”=” rtsp_URL Metrics=”metrics” ”=” ”{”1#(1*TEXT)”}” Sending-rate=”rate” ”=” 1 *DIGIT / ”End” Range=as defined in RFC 2327 DIGIT=as defined in RFC 2326 Rtsp_URL=as defined in RFC 2326 Ez a fejrész a 20 adatfolyamküldõ szerver vagy a 30 adatfolyamot fogadó kliens által továbbított bármilyen RTSP üzenet részét képezheti. A definiált QoSmérõszámok használatának két útja van, amennyiben csak az Off paramétert használjuk, ez azt jelzi, hogy vagy a 20 szerver vagy a 30 kliens törölni akarja az események, mérési eredmények és mérõszámok átvitelét. Ha viszont a fejrész más paramétereket, például stream-url, Metrics, Sending-rate vagy adott esetben Range paramétert tartalmaz, akkor a mérõszámok átvitelének megkezdését, illetve újbóli elkezdését kérjük. A stream-url mezõ egy RTSP session url azonosító vagy egy RTSP Media Control url azonosító. Ha a fejrészt az RTSP Session Control url információval használjuk, akkor a QoS-mérõszámokat használjuk a kapcsolati szinten. Ha az url egy RTSP Media Control url, akkor a QoS-mérõszámokat a médiaszinten használjuk és minden egyes média kap egy saját QoS-mérõszámok vonalat. Az elképzelhetõ, hogy ugyanarra az url¹re többször is hivatkoznak. Ha a Sending-rate és a Range információ eltér az elõzõleg definiálttól, akkor az új mérõszám-paramétereket egy eltérõ paraméterkészletnek tekintjük, amely az adott url¹re, de más mérõszámokra vonatkozik. Máskülönben, ugyanarra az RTSP control url nem lehet egynél többször hivatkozni ugyanazon Sending-rate és Range értékek esetén. A Metrics mezõt azon mérõszámok, mérési eredmények és események mennyiségének korlátozására használjuk, amelyekrõl jelentést kell küldeni. Ez a mezõ azon mérõszámok, mérési eredmények és eseményeket leíró nevek listáját tartalmazza, amelyekrõl jelentést kell küldeni egy kapcsolat során. Azokat a neveket, amelyek nem szerepelnek a Metrics mezõben, nem használjuk a kapcsolatban. A Sending-rate mezõt a sebesség beállítására használjuk. Ha a Sending-rate értéke 0, akkor a 30 kliens a visszacsatoló üzeneteket a 30 kliensben történõ eseményektõl függõen bármely idõpontban el-
1
HU 008 037 T2
küldheti. 1¹nél nagyobb értékek pontos üzenetküldési idõközt adnak meg másodpercben kifejezve. A legrövidebb idõintervallum másodpercenként 1, míg a leghosszabb intervallum határozatlan. A visszacsatolás küldési intervallum eltérhet a különbözõ médiák esetén, azonban ajánlatos valamilyen szinkronizálást fenntartani a többletforgalom elkerülése érdekében. Az End érték azt jelzi, hogy csak egyetlen visszacsatoló üzenet lett elküldve a kapcsolat végén. A Range mezõ a visszacsatolt küldés idõkorlátjának definiálására használható. Ez hasonló az Off paraméter elküldéséhez, azonban lehetõvé teszi elõzõleg egy On állapot idõtartományának meghatározását az egyeztetési szakaszban. A definiált QoS-Metrics mezõ képes kezelni azt a szituációt, amikor a mérõszámok kiszámítását a 20 adatfolyamküldõ szerverben hajtjuk végre, és amikor a 20 adatfolyamot fogadó kliens csak eseményeket és/vagy mérési eredményeket küld a szervernek, valamint abban az esetben, amikor a 30 adatfolyamot fogadó kliens elõzetesen kiszámított mérõszámokat küld a 20 adatfolyamküldõ szervernek. Ezenkívül egy új QoSMetrics SDP attribútumot is definiálunk, amely felhasználható akár kapcsolatként, akár egy médiaszintû SDP attribútumként. A definíció szintaxisa az RFC 2327 szabványon alapul, amelynek az anyaga a jelen leírás részét képezi: a=QoS-Metrics: Metrics ”;” Sending-rate [”;” Range]) CRLF Metrics=”metrics” ”=” ”{” 1#(1*TEXT) ”}” Sending-rate=”rate” ”=” 1*DIGIT / ”End” Range=as defined in RFC 2327 DIGIT=as defined in RFC 2327 Egy adatfolyam-szolgáltatási kapcsolat létrehozásához a 30 adatfolyamot fogadó kliens egy RTPS DESCRIBE kérést küld a 4. ábrán látható 1 üzenetként a 20 adatfolyamküldõ szervernek: C¹>S DESCRIBE rtsp://example.com/foo/bar/baz.3gp RTSP/1.0 Cseq: 1 A C¹>S reprezentáció a 30 klienstõl a 20 szerverhez irányuló átvitelt jelöl. A QoS-Metrics mezõ tényleges egyeztetése ezt követõen az elsõ DESCRIBE válasszal indulhat az alábbi módon. Az 1¹es DESCRIBE kérésnek a 30 klienstõl való fogadásakor a 20 szerver kilistázza a kívánt QoS-mérõszámok információját az SDP leírásban, amihez a QoS-Metrics SDP attribútumot használja. Ezek a mérõszámok akár az adatfolyam-szolgáltatási kapcsolat szintjén, akár a média szintjén az SDP-ben definiálhatók. Ez kellõ flexibilitást biztosít a QoS-folyamatnak, így ugyanis fontos médiakomponensek részletesebben monitorozhatók. A 20 adatfolyamküldõ szerver az SDP leírást egy DESCRIBE válasz 200 OK üzenethez csatolja és a választ a 4. ábrán látható 2¹es üzenetként továbbítja a 30 adatfolyamot fogadó kliensnek. Az is lehetséges, hogy a szerver listázza ki a QoS-mérõszámokat a DESCRIBE válaszüzenetbe a QoS-Metrics fejléc használatával, ahelyett, hogy az SDP attribútu-
2
mot használna. A 30 adatfolyamot fogadó kliensnek le kell ellenõriznie a válaszban egy ilyen fejrész jelenlétét. Szükségesnek tartjuk megjegyezni, hogy a fent említett, TSG¹S4 Meeting #28¹ra vonatkozó dokumentum5 ban már négy dedikált QoS-üzenetre van szükség eddig a pontig. Az alábbiakban egy megfelelõ kapcsolati szintû üzenetre mutatunk be egy példát, ahol a kért kapcsolati paraméterek az RTPSSetupTime és az InitialBufferingTi10 me, ahol a kért videoparaméterek a Framegap és a Framegap_ave, továbbá ahol a kért videoparaméterek az AudioGap_ave és AudioGap_max. Szükségesnek tartjuk megjegyezni, hogy a paraméterek nevei csak példaként szolgálnak és a megfelelõ név a mérõszámokat, a méré15 si eredményeket és/vagy az eseményeket jelölhetik. S¹>C RTSP/1. 0 200 OK Cseq: 1 Content-Type: application/sdp Content-Base: rtsp://example.com/foo/bar/baz.3gp/ 20 Content-Length: 800 Server: Nokia RTSP Server
25
30
35
40
45
50
55
60 7
v=O o=–3268077682 433392265 IN IP4 63.108. 142.6 s=QoS Enables Session Description Example
[email protected] c=IN IP4 0.0.0.0 t=0 0 a=range:npt=0–83.660000 a=QoS-Metrics:{RTSPSetupTime, InitialBufferingTime};rate=End a=control:* m=video 0 RTP/AVP 96 b=AS:28 a=QoS-Metrics: {Framegap_max, Framegap_ave};rate=15;range:npt=0–40 a=control:tracklD=3 a=rtpmap:96 MP4V-ES/1000 a=range:npt=0–83.666000 a=fmtp:96profile-levelid=8;config= 000001b008000001b5090000010000000120008440fa28 302090a28f m=audio 0 RTP/AVP 98 b=AS:13 a=QoS-Metrics:{AudioGap_ave, AudioGap_max};rate=20 a=control:tracklD=5 a=rtpmap:98 AMR/8000 a=range:npt=0–83.660000 a=fmtp:98 octet-align=1 a=maxptime:200 Az S ¹>C jelölés a 20 szervertõl a 30 klienshez történõ átvitelt jelöli. A QoS-egyeztetés bármikor végrehajtható a kapcsolat során, amennyiben az egyik fél engedélyezni kívánja a QoS-mérõszám jelzést. Az itt bemutatott példakénti listában ezt a kapcsolatfelépítés fázisában
1
HU 008 037 T2
tesszük meg az SDP attribútum felhasználásával. Az is lehetséges, hogy a QoS-mérõszámokat valamilyen másik RTSP üzenetben küldjük el a QoS-Metrics SPD attribútum vagy a találmány szerinti QoS-Metrics fejrész mezõ felhasználásával. A 30 adatfolyamot fogadó kliens kiválasztja a beérkezõ 200 OK üzenet SDP attribútumában felsorolt QoS-mérõszámok közül az elfogadható mérõszámokat vagy javaslatot tesz új értékekre egy elsõ SETUP kérésben. Amennyiben a 30 kliens támogatja a QoS-mérõszámokat, akkor el kell küldenie egy SETUP kérést vagy valamilyen más RTSP üzenetet, amely tartalmazza a kiválasztott/módosított QoS-mérõszámokat akár a kapcsolati szintre, akár a médiaszintre vonatkozóan, amely éppen felépítés alatt áll. Egy ilyen SETUP kérési üzenetet jelöl a 4. ábrán látható 3¹as üzenet. Egy alternatív RTSP üzenet lehet például a PLAY kérés, amit a 4. ábrán látható 5¹ös üzenet jelöl. Egy megfelelõ, példakénti SETUP üzenet az alábbi módon épül fel: C¹>S SETUP rtsp://example.com/foo/bar/baz.3gp/ tracklD=3 RTSP/1.0 Cseq: 2 QoS-Metrics:url=”rtsp://example.com/foo/bar/ baz.3gp/track ID=3”; metrics={Framegap_max, Framegap_ave}; rate=10;range:npt=0–40, url=”rtsp://example.com/foo/bar/baz.3gp”; metrics={RTSPSetupTime, InitialBufferingTime};rate=End A fenti példában szereplõ SETUP kérésben a 30 adatfolyamot fogadó kliens a QoS-mérõszámok küldési gyakoriságát 15¹rõl 10¹re módosítja az alábbi vezérlõ url¹re vonatkozóan: ”rtsp://example.com/foo/bar/baz.3gp/trackID=3” Annak jelölésére, hogy mind a kapcsolati szintû, mind a médiaszintû QoS-mérõszámokat támogatja a 30 adatfolyamot fogadó kliens, a 30 adatfolyamot fogadó kliensnek a médiaszinthez tartozó összes támogatott és/vagy módosított QoS-mérõszámot el kell küldenie. Szintén el kell küldenie a kiválasztott kapcsolati szint QoS-mérõszámait legalább az egyik SETUP kérésben. A 20 adatfolyamküldõ szerver fogadja ezt a SETUP kérést és visszaküld egy 200 OK üzenetet az elfogadott QoS-mérõszámokkal, melyeket a 30 kliens küldött, és ahol a visszaküldött üzenet újból nyugtázza a változásokat. Ez a 200 OK üzenet a 4. ábrán 4¹es üzenetként látható. A 20 adatfolyamküldõ szerver a 200 OK üzenetben vissza is utasíthatja a 30 adatfolyamot fogadó kliens által tett módosításokat. A módosítások elutasításához a 20 adatfolyamküldõ szerver vagy új értékeket állít be és újból visszaküldi a módosított mérõszámokat a 30 adatfolyamot fogadó kliensnek a 200 OK üzenethez csatolva, vagy egyszerûen figyelmen kívül hagyja azokat a mérõszámokat és nem nyugtázza újból azokat. Ha azt feltételezzük, hogy a 20 adatfolyamküldõ szerver nyugtázta a változtatásokat, akkor az alábbi példában bemutatott SETUP válaszüzenetet küldheti vissza:
5
10
15
20
25
30
35
40
45
50
55
60 8
2
S¹>C RTSP/1.0 200 OK Cseq: 2 Session: 17903320 Transport:RTP/AVP;unicast;client_port= =7000–7001;server_port=6970–6971 QoS-Metrics:url=”rtsp://example.com/foo/bar/ baz.3gp/tracklD=3”; metrics={Framegap_max, Framegap_ave}; rate=10;range:npt=0–40, url=”rtsp://example.com/foo/bar/baz.3gp”; metrics={RTSPSetupTime, InitialBufferingTime};rate=End Amint a 30 adatfolyamot fogadó kliens megkapja ezt a 4¹es 200 OK üzenetet az általa küldött 3¹as SETUP kérés üzenetre válaszként, tudomást szerez arról, hogy a 20 adatfolyamküldõ szerver támogatja a QoSmérõszámokat. Továbbá, a 30 kliens arról is tudomást szerez, hogy a 20 szerver elfogadta a QoS-Metrics RTSP fejrészben felsorolt mérõszámok támogatását. Ugyanez a jelzés valósul meg a kapcsolat során más médiakomponensek esetében is. Ez esetben a kapcsolatszintû QoS-mérõszámok egyeztetését nem feltétlenül ismételjük meg. Amennyiben a 20 adatfolyamküldõ szerver nem hagyja jóvá a 30 adatfolyamot fogadó kliens által tett módosításokat, a 20 szerver és a 30 kliens tovább folytathatja az egyeztetéseket egészen addig, amíg a 30 kliens egy RTSP PLAY kérést nem küld, amely a 4. ábrán 5¹ös üzenetként szerepel. A 20 szerver erre adott RTSP PLAY válasza, amely a 4. ábrán a 6¹os üzenet, visszaküldi a végsõ egyeztetett QoS-mérõszámokat, amely tartalmazza a kapcsolatszintû és médiaszintû QoS-Metrics értéket. Szükségesnek tartjuk megjegyezni, hogy minden egyes alkalommal, amikor QoS-Metrics header mezõt küldünk egy RTSP kérésben, annak meg kell jelennie az adott kérdésnek megfelelõ válaszban is. Máskülönben a választ fogadó 20, 30 vevõ azt feltételezi, hogy a megfelelõ másik 30, 20 végberendezés nem támogatja a QoS-mérõszámokat. Szükségesnek tartjuk továbbá megjegyezni, hogy a 30 adatfolyamot fogadó kliens esetleg majd rendelkezik az SDP leírással, mielõtt kezdeményezi a kapcsolatot, például egy fájl formájában. Amennyiben az SDP leírást az adott 20 szervertõl a DESCRIBE választól eltérõ módon kérdezzük le, az adatfolyamküldõ szerver által fogadott elsõ üzenet a 4. ábrán látható 3 SETUP üzenet. A 4. ábrán látható 1¹es DESCRIBE kérés üzenethez és 2¹es DESCRIBE válasz üzenethez tartozó nyilakat ezért csak szaggatott vonallal jelöltük. Ebben az esetben a 30 adatfolyamot fogadó kliens kezdeti QoS-mérõszáma információt küldhet egyeztetésre a 3¹as SETUP üzenetben. Ha a 3¹as SETUP üzenet QoS-mérõszám információt tartalmaz, a 20 adatfolyamküldõ szerver elfogadhatja a mérõszámokat vagy újakat javasolhat a 4¹es SETUP válaszban és a QoS-mérõszámok egyeztetése a fent ismertetett módon tovább folytatódhat a következõ RTSP üzenetekben. Ha az elsõ 3¹as SETUP üzenet nem tartalmazza a QoS-mérõszám információt és a 20 adatfolyamküldõ szerver egyeztetni akarja a
1
HU 008 037 T2
QoS-mérõszámokat a 30 adatfolyamot fogadó klienssel, akkor a 20 adatfolyamküldõ szerver QoS-mérõszám információk közlését kérheti a 30 adatfolyamot fogadó klienstõl a 4¹es SETUP válasz elküldésével. Ha a 30 adatfolyamot fogadó kliens elfogadja a kért QoS-mérõszámokat vagy meg akarja azokat változtatni, a 30 adatfolyamot fogadó kliensnek el kell helyezni a mérõszám információt a következõ TRSP üzenetben. Ha nincs QoS-mérõszám információ a következõ RTSP üzenetben, akkor ez azt jelenti, hogy a 30 adatfolyamot fogadó kliens nem támogatja a QoS-mérõszámokat. Az egyeztetés befejezõdését követõen a 30 adatfolyamot fogadó kliens elindíthatja a visszacsatoló üzenetek küldését. A visszacsatoló üzeneteket is megbízható átviteli mechanizmus alkalmazásával kell elküldeni. E célból lehetõség van bármilyen RTSP kérés-válasz üzenetpár használatára az adatfolyam-szolgáltatási kapcsolat során. Például, ha egy RTSP PAUSE üzenetet küldünk bármilyen módon a kapcsolat során, egy visszacsatoló üzenet helyezhetõ el ebben a PAUSE üzenetben. Amennyiben egy visszacsatoló üzenetet csak a kapcsolat végén kell elküldeni, akkor használható egy RTSP TEARDOWN üzenet a felesleges forgalom kiküszöbölése céljából. Egy ilyen TEARDOWN üzenetet használunk egyébként a legutolsó visszacsatoló üzenet elküldésére a periodikus visszacsatolt jelentésküldés esetén is. A visszacsatoláshoz szintén egy új fejrészt definiálunk. Az alábbi fejrész képes kezelni az eseményekre, mérési eredményekre vagy mérõszámokra vonatkozó módszerek küldését. A definíció szintaxisa az RFC 2326 szabványon alapul, amely szintén a jelen leírás részét képezi: Feedbackheader=”QoS-Feedback”:” 1# (stream-url 1*(parameters) CRLF) stream-url =”url”=”rtsp URL parameters =”Metrics”=”{”SP / 1# (Value „SP Timestamp]) ”}” Metrics=*TEXT Value=1*DIGIT [”.”*DIGIT] Timestamp=1*DIGIT DIGIT=as defined in RFC 2326 Rtsp_URL=as defined in RFC 2326 SP=as defined in RFC 2326 A Stream-url a visszacsatoló paraméterhez tartozó RTSP session url vagy a media control url azonosító. A Parameters definícióban szereplõ Metrics mezõ a mérõszámok, mérési eredmények vagy események nevét tartalmazza és azonosnak kell lennie a QoS-Metrics egyeztetési mezõben szereplõ Metrics mezõvel. Ajánlatos a mérõszámok sorrendjét azonosnak venni a szintaktikai elemzés egyszerûsítése céljából. A Value mezõ a Metrics mezõ eredményeit hagyja meg. Az opcionális Timestamp mezõ azt idõpontot adja meg, amikor az esemény vagy a mérési eredmény elõállítása történt, vagy amikor a mérõszám ki lett számítva. A fejrész lehetõvé teszi nulla eseményekrõl való jelentést, valamint szóköz (space, SP) megadását is. Amennyiben eseményeket és mérési eredményeket használunk a mérõszámok küldéséhez, lehetõség
5
10
15
20
25
30
35
40
45
50
55
60 9
2
van arra, hogy ugyanaz az esemény egynél többször következzen be egy küldési periódus alatt. Ebben az esetben a mérõszámok típusai, vagyis az események vagy mérési eredmények neve többször is elõfordulhat, ami az események számát jelzi a szervernek. Amennyiben a visszacsatoló üzenetekhez használt protokollnak az RTCP-nek kell lennie az RTSP helyett, használhatóak RTCP APP csomagok (Application-defined RTCP packet, packet type 204) vagy az RTCP RR (receiver report, packet type 201) csomagok kiterjesztései. Akármelyik csomagot is használjuk, annak legalább a Metrics mezõt, a Value mezõt és adott esetben a Timestamp mezõt tartalmaznia kell. A Metrics a mérõszám neve vagy egy üres üzenet jelölése (ASCII vagy szám), a Value a mérõszámok eredménye (szám). Az idõcímke azt az idõpontot adja meg, amikor az esemény bekövetkezett vagy amikor a mérõszámokat kiszámították (szám), és ezt csak szükség esetén adjuk meg. Az RTCP fejrészek az adott médiára vonatkozó információt tartalmaznak, így szükségtelen ezt az információt megismételni többletmezõk felhasználásával. A visszacsatoló üzenetekben a QoS-Feedback fejrész csak a módosított QoS-mérõszámokat tartalmazza. Ha egy mérõszám-paraméter nem szerepel a listán, de az egyeztetésre került a felépítési fázisban, akkor arról a mérõszám-paraméterrõl feltélezzük, hogy változatlan vagy nem lett módosítva. A 30 adatfolyamot fogadó kliens az alábbi üzenetet használhatja valamilyen RTSP üzenetben a PLAY kérést követõen. Egy ilyen üzenetet jelöl a 4. ábrán látható 7¹es üzenet. Szükségesnek tartjuk megjegyezni, hogy a paraméterek nevei csak példaként szolgálnak. OPTIONS rtsp://example.com/foo/bar/baz.3gp RTSP/1.0 Cseq: 302 Session: 17903320 QoS-Feedback: url=”rtsp://example.com/foo/bar/baz.3gp/ tracklD=3”;Framega p_max=100 6000; Framegapave=50 6000 url=”rtsp://example.com/foo/bar/baz.3gp/tracklD=5”; AudioGap_ave=340.5 52; AudioGap_max=0 500 Az RTSP visszacsatoló üzenetek összefûzésére is lehetõség van annak érdekében, hogy elkerüljük a nagy üzenetküldési gyakoriságot, például egy eseményalapú küldés miatt. Egy RTSP visszacsatoló üzenet alternatívájaként a 30 adatfolyamot fogadó kliens például az alábbi RTCP RR üzenetet használhatja a QoS-adatok közlésére: RTCP header Report block Profile specific extension AudioGap_ave 105.5 6000 AudioGapmax 123 500 További alternatív lehetõséget jelent, hogy a kliens például az alábbi RTCP APP üzenetet is használhatja: RTCP APP header Name QoS_Metrics
1
HU 008 037 T2
Application-dependent data Audiogap_ave 105.5 6000 Audiogap_max 123 500 Amennyiben a kiszámított mérõszámok helyett mérési eredményeket vagy eseményeket közlünk, az esemény leírása egynél több értéket tartalmazhat. Ez érdekes lehet abban az esetben, ha például az értesítési periódus során két olyan különálló esemény van, ahol RTP csomagok vesztek el. Egy RTSP üzenetben használható alábbi példa még az opcionális idõcímke információt is tartalmazza: OPTIONS rtsp://example.com/foo/bar/baz.3gp RTSP/1.0 Cseq: 302 Session: 17903320 QoS-Feedback: url=”rtsp://example.com/foo/bar/baz.3gp/ tracklD=3”;Vcorruption_dur ={100 6000,215.4 11000}; Lost_RTP={3 6000,5 11000} url=”rtsp://example.com/foo/bar/baz.3gp/trackl D=5”; Acorruption_dur={97 6000,221 11000} Egy RTCP RR üzenetben használható alábbi példa az opcionális idõcímke információt is tartalmazza: RTCP header Report block Profile specific extension Acorruption_dur 97 6000 Acorruption_dur 221 11000 Egy RTCP APP üzenetben használt alábbi példa az opcionális idõcímke információt is tartalmazza: RTCP APP header Name QoS Metrics Application-dependent data Acorruption_dur 97 6000 Acorruption_dur 221 11000 Az is lehetséges, hogy vagy a 20 adatfolyamküldõ szerver vagy a 30 kliens meg akarja változtatni az egyeztetett paramétereket egy kapcsolat során. A 20 szerver például bizonyos információkat gyakrabban igényelhet, míg a 30 kliens jelezheti, hogy nem tud annyi paramétert biztosítani, amennyiben megegyeztek. A teljes QoS-mérõszám küldés akár ki is kapcsolható. Ahhoz, hogy késõbb újból elkezdhesse a mérõszámok küldését, a 30 adatfolyamot fogadó kliens vagy a 20 adatfolyamküldõ szerver egy új kérést küldhet el. Egy folyamatban lévõ adatfolyam-szolgáltatási kapcsolat során lehetõség van bármilyen RTSP üzenet használatára a QoS-mérõszám paraméterek újbóli egyeztetéséhez. Egy kezdetben egyeztetett jelentésküldés bármilyen módosítása szintén része lehet a 4. ábrán látható 7¹es üzenetnek. Az alábbiakban egy példát láthatunk arra, amikor egy kapcsolat során a 30 kliens vagy a 20 szerver egy változtatásra vonatkozó kérést küld, vagy a 30 kliens vagy a 20 szerver egy újraindításra vonatkozó kérést küld egy kapcsolat során, azt követõen, hogy a QoSmérõszámok át lettek állítva:
C¹>S, S¹>C
5
10
15
20
25
30
35
40
45
50
55
60 10
2
OPTIONS rtsp://example.com/foo/bar/ baz.3gp/trackID=5 RTSP/1.0 Cseq:302 Session: 17903320 QoS-Metrics: metrics=AudioGap_ave, AudioGap_num, AudioGap_max;rate=20 A változtatásra vonatkozó kérdésre adott válasz, amely a kérés elfogadását jelzi, az alábbi példában bemutatott módon definiálható mindkét irányban: S¹>C, C¹>S RTSP/1.0 200 OK Cseq:302 Session: 17903320 Qos-metrics: metrics=AudioGap_ave, AudioGap_num, AudioGap_max;rate=20 A változtatásra vonatkozó kérdésre adott válasz, amely a kérés elutasítását tartalmazza, például az alábbi módon definiálható mindkét irányban: S¹>C, C¹>S RTSP/1.0 200 OK Cseq:302 Session: 17903320 QoS-Metrics:metrics=AudioGap_ave, AudioGap_max;rate=20 Amennyiben az új értékek nem kerülnek elfogadásra, az elõzõleg használt paramétereket ismételjük, ami azt jelenti, hogy az elõzõleg egyeztetett helyzet változatlanul fennmarad. A mérõszámok listája mindig abszolút. Nincs lehetõség az adott listához hozzáadni vagy abból elvenni, azonban a mérõszámok új listájával helyettesíthetõ a régi lista. Az alábbiakban a 30 kliens vagy a 20 szerver által egy kapcsolat során küldött üzenetre látható példa, amely a mérõszámok kikapcsolására szolgál: C¹>S, S¹>C OPTIONS rtsp://example.com/foo/bar/ baz.3gp RTSP/1.0 Cseq: 302 Session: 17903320 QoS-Metrics: Off Szükségesnek tartjuk megjegyezni, hogy a mérõszámok kikapcsolhatók mind a kapcsolati szinten, mind a médiaszinten. Az url megadja, hogy melyik szintet használjuk. A fenti példában a mérõszámokat az összes média tekintetében a kapcsolati szinten kapcsoltuk ki. Amennyiben a mérõszámok kikapcsolására vonatkozó kérés elfogadásra kerül, a válasz mindkét irányban az alábbi példában bemutatott módon definiálható: S¹>C, C¹>S RTSP/1.0 200 OK Cseq: 302 Session: 17903320 QoS-Metrics: Off Amennyiben a mérõszámok kikapcsolására vonatkozó kérés elutasításra kerül, a válasz mindkét irányban például az alábbi módon definiálható: S¹>C, C¹>S RTSP/1.0 200 OK Cseq: 302 Session: 17903320 QoS-Metrics:metrics=AudioGap_ave, AudioGap_max;rate=20
1
HU 008 037 T2
Vagyis, ha a kikapcsolás nem kerül elfogadásra, az elõzõleg használt paramétereket ismételjük, ami azt jelzi, hogy az elõzõleg egyeztetett helyzet változatlanul fennmarad. Szükség esetén azonban lehetõség nyílik a küldési paraméterek újbóli egyeztetésére. A 30 adatfolyamot fogadó kliens implementálása egyszerû, ha csak esemény észlelésre van szükség. A bemutatott eljárás egyik elõnye, hogy az üzenetek periodikusan küldhetõk, továbbá, hogy az üzenetek a lehetõ legkisebb méretûre vannak kialakítva. A bemutatott eljárás lehetõvé teszi a 3GPP TSG¹S4 Meeting #28¹ra vonatkozó, fent említett dokumentumban bemutatottnál több információ továbbítását. Ezenkívül a bemutatott eljárás a felépítést gyorsabbá teszi, mivel ahhoz kevesebb üzenetre van szükség. A javasolt eljárás további elõnye, hogy lehetõvé teszi az összes felhasznált mérõszám egyeztetését. Lehetõvé teszi továbbá a mérõszám küldések újbóli egyeztetését egy kapcsolat közepén, amennyiben szükséges, továbbá szükség esetén az összes mérõszámküldés kikapcsolását is. A bemutatott eljárás idõcímkét is biztosít a mérõszámokhoz, amelyek pontosabban megadják az esemény idõpontját, mint a többi megoldásnál használt idõtartomány. Egy üres üzenetet definiálunk arra az esetre, ha nem lenne leírandó üzenet egy periodikus üzenetküldésben. Az üzenetküldés optimalizálása érdekében több üzenet össze is fûzhetõ.
5
10
15
20
25
30 SZABADALMI IGÉNYPONTOK 1. Eljárás szolgáltatásminõséggel kapcsolatos információ továbbítására, amely információ egy elsõ eszköz (30) és egy második eszköz (20) között legalább az egyik irányban továbbítandó, amely eljárás során az említett eszközök (20, 30) közül legalább az egyikben az alábbi lépéseket hajtjuk végre: összeállítunk egy protokollüzenetet szolgáltatásminõséggel kapcsolatos információ továbbításától eltérõ célból; a szolgáltatásminõséggel kapcsolatos információt az említett protokollüzenethez csatoljuk; és az említett protokollüzenetet az említett elsõ eszköz (30) és második eszköz (20) közül a másiknak elküldjük, azzal jellemezve, hogy a szolgáltatásminõségre vonatkozó információ olyan információt tartalmaz, amely megadja, hogy az elsõ eszköznek (30) milyen gyakorisággal kell jelentést küldenie a szolgáltatás elért minõségérõl a második eszköznek (20). 2. Az 1. igénypont szerinti eljárás, azzal jellemezve, hogy a protokollüzenet az alábbiak egyike: valós idejû adatfolyam-szolgáltatási protokollüzenet, valós idejû átvitelvezérlési protokollüzenet és kapcsolatkezdeményezõ protokollüzenet. 3. Az 1. igénypont szerinti eljárás, azzal jellemezve, hogy az átvitelt akkor valósítjuk meg, amikor az elsõ eszköz (30) és a második eszköz (20) között egy adott szolgáltatásra vonatkozóan kapcsolatot létesítünk.
35
40
45
50
55
60 11
2
4. Az 1. igénypont szerinti eljárás, azzal jellemezve, hogy az átvitelt az elsõ eszköz (30) és a második eszköz (20) között egy adott szolgáltatásra létesített kapcsolat során továbbítjuk. 5. Az 1. igénypont szerinti eljárás, azzal jellemezve, hogy a szolgáltatásminõségre vonatkozó információ egy szolgáltatás elért minõségére vonatkozó információt tartalmaz, amelyrõl az elsõ eszköznek (30) kell jelentést küldenie a második eszköznek (20). 6. Az 5. igénypont szerinti eljárás, azzal jellemezve, hogy az elért szolgáltatási minõségre vonatkozó információ az elért szolgáltatási minõséggel kapcsolatos esemény, mérési eredmény és mérõszám körül legalább az egyikre vonatkozó információt tartalmaz. 7. Az 5. igénypont szerinti eljárás, azzal jellemezve, hogy az elért szolgáltatási minõségre vonatkozó információt nem továbbítjuk az említett szolgáltatás szünetelõ állapota alatt. 8. Az 1. igénypont szerinti eljárás, azzal jellemezve, hogy a szolgáltatásminõségre vonatkozó információ az elsõ eszköz (30) és a második eszköz (20) között annak az egyeztetésére vonatkozó információt tartalmaz, hogy az elsõ eszköz (30) egy elért szolgáltatási minõségre vonatkozóan milyen mértékben küldjön jelentést a második eszköznek (20). 9. Az 1. igénypont szerinti eljárás, azzal jellemezve, hogy a szolgáltatás minõségre vonatkozó információt az említett protokollüzenet fejrésze és az említett protokollüzenet egy attribútuma közül legalább az egyikhez csatoljuk. 10. Számítógépi program szolgáltatásminõséggel kapcsolatos információ továbbítására, amely információ egy elsõ eszköz (30) és egy második eszköz (20) között legalább az egyik irányban továbbítandó, amely számítógépi program az említett eszközök (20, 30) közül legalább az egyikben való futtatása során az alábbi funkciókat hajtja végre: egy protokollüzenet összeállítása szolgáltatásminõséggel kapcsolatos információ továbbításától eltérõ célból; és a szolgáltatásminõséggel kapcsolatos információnak az említett protokollüzenethez történõ csatolása; azzal jellemezve, hogy a szolgáltatásminõségre vonatkozó információ olyan információt tartalmaz, amely megadja, hogy az elsõ eszköznek (30) milyen gyakorisággal kell jelentést küldenie a szolgáltatás elért minõségérõl a második eszköznek (20). 11. Eszköz (20, 30), amely tartalmaz: egy egyesítõkomponenst (21, 31) a szolgáltatásminõséggel kapcsolatos információ továbbításától eltérõ célra szolgáló protokollüzenet összeállítására és a szolgáltatásminõségre vonatkozó információnak az említett üzenethez való csatolására, ahol a szolgáltatásminõségre vonatkozó információ egy második eszköznek (30, 20) továbbítandó, azzal jellemezve, hogy a szolgáltatásminõséggel kapcsolatos információ olyan információt tartalmaz, amely megadja, hogy az elsõ eszköz (20, 30) és a második eszköz (30, 20) közül
1
HU 008 037 T2
az egyiknek milyen gyakorisággal kell az elért szolgáltatás minõségrõl jelentést küldenie az említett elsõ eszköz (30, 20) és második eszköz (20, 30) közül a másiknak. 12. A 11. igénypont szerinti eszköz (20, 30), azzal jellemezve, hogy tartalmaz továbbá egy olyan adókomponenst (22, 32), amely az egyesítõkomponens (21, 31) által összeállított protokollüzenetet a másik eszköznek (30, 20) továbbítja. 13. A 11. igénypont szerinti eszköz (20, 30), azzal jellemezve, hogy a protokollüzenet az alábbiak egyike: valós idejû adatfolyam-szolgáltatási protokollüzenet, valós idejû átvitelvezérlési protokollüzenet és kapcsolatkezdeményezõ protokollüzenet. 14. A 11. igénypont szerinti eszköz (20, 30), azzal jellemezve, hogy tartalmaz továbbá egy adókomponenst (22, 32) az említett egyesítõkomponens (21, 31) által összeállított protokollüzenetnek a másik eszközhöz (30, 20) történõ továbbítására az elsõ eszköz (30) és a második eszköz (20) között egy adott szolgáltatásra vonatkozó kapcsolat létesítésekor. 15. A 11. igénypont szerinti eszköz (20, 30), azzal jellemezve, hogy tartalmaz továbbá egy adókomponenst (22, 32) az említett egyesítõkomponens (21, 31) által összeállított protokollüzenetnek a másik eszközhöz (30, 20) történõ továbbítására az elsõ eszköz (30) és a második eszköz (20) között egy adott szolgáltatásra vonatkozó kapcsolat során. 16. A 11. igénypont szerinti eszköz (20, 30), azzal jellemezve, hogy az említett egyesítõkomponens (21, 31) úgy van kialakítva, hogy a szolgáltatásminõségre vonatkozó információként az említett elsõ eszköz (30) által a második eszköznek (20) továbbítandó, elért szolgáltatási minõségre vonatkozó információt csatolja az említett egyesített protokollüzenethez. 17. A 16. igénypont szerinti eszköz (20, 30), azzal jellemezve, hogy az elért szolgáltatási minõségre vonatkozó információ az elért szolgáltatási minõséggel kapcsolatos esemény, mérési eredmény és mérõszám közül legalább az egyikre vonatkozó információt tartalmaz.
5
10
15
20
25
30
35
12
2
18. A 16. igénypont szerinti eszköz (20, 30), azzal jellemezve, hogy tartalmaz továbbá egy adókomponenst (22, 32) az egyesítõkomponens (21, 31) által összeállított protokollüzenetnek a másik eszközhöz (30, 20) történõ továbbítására, ahol az adókomponens (22, 32) úgy van kialakítva, hogy az elért szolgáltatás minõségre vonatkozó információt az adott szolgáltatás szünetelõ állapotán kívül továbbítja. 19. A 11. igénypont szerinti eszköz (20, 30), azzal jellemezve, hogy az egyesítõkomponens (21, 31) úgy van kialakítva, hogy az említett egyesített protokollüzenethez az elsõ eszköz (30) és a második eszköz (20) közötti azon egyeztetéssel kapcsolatos információt csatol, amely egyeztetés célja annak meghatározása, hogy az elsõ eszköz (30) az elért szolgáltatási minõségrõl milyen mértékben küldjön jelentést a második eszköznek (20) a szolgáltatásminõségre vonatkozó információ formájában. 20. A 11. igénypont szerinti eszköz (20, 30), azzal jellemezve, hogy az egyesítõkomponens (21, 31) úgy van kialakítva, hogy a szolgáltatásminõségre vonatkozó információt a protokollüzenet fejrésze és a protokollüzenet valamely attribútuma körül legalább az egyikhez csatolja. 21. A 11. igénypont szerinti eszköz, azzal jellemezve, hogy az eszköz egy mobiltelefon (30). 22. A 11. igénypont szerinti eszköz, azzal jellemezve, hogy az eszköz egy hálózat valamely hálózati eleme (20). 23. Rendszer, amely legalább a 11–20. igénypontok bármelyike szerinti elsõ eszközt (20, 30) és egy második eszközt (30, 20) tartalmaz, amely második eszköz (30, 20) tartalmaz egy vevõegységet (34, 24) az említett elsõ eszköz (20, 30) által továbbított protokollüzenet vételére; és amely második eszköz (30, 20) tartalmaz egy leválasztókomponenst (33, 23) a szolgáltatásminõséggel kapcsolatos információnak egy beérkezõ protokollüzenetrõl történõ leválasztására.
HU 008 037 T2 Int. Cl.: H04L 29/06
13
HU 008 037 T2 Int. Cl.: H04L 29/06
14
HU 008 037 T2 Int. Cl.: H04L 29/06
15
HU 008 037 T2 Int. Cl.: H04L 29/06
Kiadja a Magyar Szabadalmi Hivatal, Budapest Felelõs vezetõ: Szabó Richárd osztályvezetõ Windor Bt., Budapest
