Tunn klient

Kravet på användarvänlighet medför eventuellt att vissa funktioner måste avlägsnas från settop-boxen för att göra produkten attraktiv. Det leder till en mindre sofistikerad, men mer lättanvänd produkt. Den tunna klienten kan endast ta emot en videoström och till- hörande styrinformation. Detta innebär att om det ska vara möjligt att använda webben eller spela spel så måste dessa renderas och kodas till MPEG-4 i servern och sedan leve- reras som en videoström till klienten. Detta flyttar mycket av komplexiteten från klienten till servern och underlättar uppgraderingar och utveckling av nya tjänster. Vid många användare krävs dock stor datorkraft i servrarna.

Spelfunktionalitet kräver att det finns möjlighet att interagera med servern. Det måste till exempel finnas möjlighet att skicka styrkommandon. Utbudet av sådana öppna proto- koll är tyvärr bristfällig för tillfället, varför denna funktionalitet är svår att implementera i settop-boxen. Det som finns idag är bland annat en proprietär standard för att skicka USB över IP [26]. En öppen variant av denna standard hade varit ett alternativ.

Webbfunktionaliteten kräver att det finns möjlighet att välja vilken webbsida som ska visas. Detta innebär att åtminstone delar av HTTP måste implementeras, och då enbart med syfte att kunna välja webbsidor. Kvar återstår dessutom problemet med att klicka på länkar i den videoström som webbsidan kommer i. Eftersom målet med den tunna klien- ten är att skapa en enkel och billig settop-box väljs även denna funktionalitet bort.

De grundläggande protokoll som används i settop-boxen är baserade på ISMA:s speci- fikation, se kapitel 6. I figur 24 ges ett blockschema över designen.

Figur 24: Blockschema för system med tunn klient.

Klient Server ISMA Tangentbord (tillval) Fjärrkontroll Nätverks- anslutning TV-ut Internet

Mediaspelare Streaming server

I/O Control

GUI

Control

DRM Kodare

Systemdesign

MPEG-4-kompatibel settop-box för IP-nät baserad på öppna standarder 53 I figuren är serverns funktioner samlade på samma fysiska plats. Detta behöver dock ej vara fallet utan dessa kan spridas ut på servrar med olika fysiska placeringar. Det är exempelvis önskvärt att placera en streaming server fysiskt nära klienterna medan övrig funktionalitet till exempel kan samlas i en och samma server på valfri plats, se avsnitt 7.4.

Huvudfunktionaliteten hos den klient som presenteras ovan motsvarar den hos dagens settop-boxar, det vill säga den kan användas för att ta emot TV-sändningar. För att klien- ten ska fungera med video-on-demand-tjänster krävs möjlighet att beställa filmer från en leverantör. Eftersom klienten saknar funktionalitet som behövs för detta moment måste detta göras på annat sätt. Till exempel kan det ske via telefon eller via en separat dator med tillgång till webben.

För att närmare beskriva funktionen hos den tunna klienten presenteras i nästa avsnitt en genomgång av ett exempel på hur klienten kan användas.

7.3.2.1 Genomgång av exempel med tunn klient

För att använda settop-boxen måste först strömmen slås på. När detta gjorts försöker set- top-boxen erhålla en IP-adress via DHCP. Alternativt har en fast IP-adress angivits vid konfigurationen av settop-boxen. IP-adressen kan till exempel ha erhållits från ett smartcard kopplat till ett abonnemang. Om inget av dessa fall uppfylls måste settop- boxen fråga användaren efter en adress. Efter att IP-adressen erhållits behöver settop- boxen ha en adress till en streaming server eller till en server som innehåller information om tillgängliga kanaler. Detta kan göras på flera sätt. Det första alternativet är att settop- boxen erhåller abonnemangsinformation via ett smartcard. Denna information kan bland annat bestå av en adress till den server som ska användas. Det andra alternativet är att adressen till den server som ska användas delas ut tillsammans med DHCP-infor- mationen. Det tredje alternativet är att användaren, med hjälp av tangentbord eller fjärr- kontroll, matar in den adress som settop-boxen ska försöka nå.

Om den erhållna adressen är en giltig RTSP-adress hämtas information om tillgängliga videoströmmar i form av en lista med SDP-beskrivningar, se kapitel 4. Denna infor- mation presenteras sedan via inbyggt GUI. Via GUI kan sedan användaren starta de olika typerna av videoströmmar. Ett alternativ är att den startar den första videoströmmen automatiskt på liknande sätt som dagens TV-apparater.

I figur 25 ges ett flödesdiagram över ett scenario där settop-boxen först erhåller en IP- adress via DHCP, sedan frågar en server efter information om tillgänglig media i form av SDP och till sist startar en mediapresentation.

Figur 25: Flödesdiagram över ett scenario med en tunn klient.

Ett alternativt sätt att erhålla nödvändig information är att använda SAP eller SLP [18] [17]. SAP kan användas för att kontinuerligt annonsera ut tillgängliga kanaler i nät- verket. Klienten lyssnar på den multicastadress som används av SAP för att erhålla listan med SDP-beskrivningar. SLP kan användas för att få adresser till en rad olika tjänster i nätverket, se kapitel 4.

Händelse Klient Server Tid

Fråga efter IP- adress Konfirmera IP-adress Fråga efter program- information Förbered media Presentera media på skärmen DHCP DISCOVER DHCP OFFER DHCP REQUEST DHCP ACK RTSP DESCRIBE RTSP OK RTSP SETUP RTSP OK RTSP PLAY RTSP OK ... RTP STREAM RTP STREAM Starta strömmar

Systemdesign

MPEG-4-kompatibel settop-box för IP-nät baserad på öppna standarder 55

7.3.3 Hybridklient

Genom att utöka funktionaliteten hos den tunna klienten kan fler tjänster erbjudas, till exempel genom att en webb-browser byggs in. På detta sätt kan settop-boxen utnyttjas för direkt åtkomst av webben. Det som skiljer mellan den tunna klienten och hybrid- klienten är stödet för HTTP och den inbyggda webb-browsern. Med webbstödet ökas funktionaliteten i settop-boxen samtidigt som komplexiteten i servrarna minskar dras- tiskt. Detta gör hybridklienten till ett attraktivt alternativ jämfört med den tunna klienten. Nackdelen med denna design är att det krävs mer datorkraft och mer programvara i set- top-boxen och den blir därmed dyrare.

Även i hybridklienten måste spelfunktionen väljas bort på grund av saknaden av öppna standarder för styrinformationen.

Blockschemat för denna något mer avancerade settop-box liknar mycket det för den tunna klienten. I figur 26 ges ett blockschema för en hybridklient.

Figur 26: Blockschema för system med hybridklient.

Med hybridklienten går det att använda den inbyggda webb-browsern som en avancerad text-TV och programguide, där operatören kan presentera utförlig information om TV- sändningar och video-on-demand-tjänster. För övrigt fungerar hybridklienten på lik- nande sätt som den tunna klienten, se avsnitt 7.3.2.

7.3.3.2 Genomgång av exempel med hybridklient

Uppstarten av hybridklienten sker på samma sätt som för den tunna klienten, se avsnitt 7.3.2.1. När settop-boxen erhållit en IP-adress behöver den veta vilken server den ska söka efter. Även här kan den informationen komma från ett smartcard, från DHCP-infor- mationen, via SAP, via SLP eller från direkt inmatning av användaren. Skillnaden jäm- fört med den tunna klienten är att programinformation och dylikt kan hämtas i form av webbsidor och presenteras med hjälp av den inbyggda webb-browsern. Via webbsidan

Klient Server ISMA Fjärrkontroll Nätverks- anslutning TV-ut Internet

Mediaspelare Streaming server

I/O Control GUI/Browser Control DRM Kodare HTTP TV/VoD/Web Tangentbord (tillval)

går det sedan att navigera mellan olika videoströmmar eller vidare bland andra webb- sidor. Hybridklienten kan även användas för komma åt webben, precis som med en van- lig dator.

I figur 27 ges ett flödesdiagram för ett scenario där settop-boxen erhåller en IP-adress via DHCP, hämtar en webbsida, hämtar information om en mediapresentation från webb- sidan och till sist startar mediapresentationen.

Figur 27: Flödesdiagram över ett scenario med en hybridklient.

Händelse Klient Server

Fråga efter IP- adress Konfirmera IP-adress Fråga efter program- information Förbered media Presentera media på skärmen DHCP DISCOVER DHCP OFFER DHCP REQUEST DHCP ACK HTTP GET HTTP OK RTSP SETUP RTSP OK RTSP PLAY RTSP OK ... RTP STREAM RTP STREAM Starta strömmar Tid Hämta och presentera webbsida HTTP GET HTTP OK ...

Systemdesign

MPEG-4-kompatibel settop-box för IP-nät baserad på öppna standarder 57

7.3.4 Krav på systemresurser

Det existerar redan olika hårdvarulösningar för att avkoda MPEG-4 [28]. Dessa gör att kravet på processorkraft i settop-boxen kraftigt minskar. Det som fortfarande kräver processorkraft är dekryptering och en eventuell webbläsare. Detta hanteras rimligtvis med en relativt enkel processor. National Semiconductors har utvecklat en referens- design för settop-boxar som använder en av deras Geode-processorer på 266 Mhz [29].

7.4 Systemöversikt

Förutom de ISMA-kompatibla servrar som existerar, eller kommer att existera, på Inter- net kommer det antagligen att krävas specialiserade servrar fysiskt nära användaren för att vissa tjänster ska bli realiserbara. Till exempel måste TV-sändningar antagligen hålla hög kvalitet för att konkurrera med analog TV och DVB i större skala. Det är också rim- ligt att anta att dessa tjänster kommer att kosta pengar, vilket medför att någon form av abonnemang kommer att krävas för att bruka tjänsten. I ett system med dessa förutsätt- ningar är det därför önskvärt att det placeras ut en streaming server nära användaren. Denna server innehåller det videomaterial som erbjuds. Närheten till användaren gör att kvaliteten kan hållas hög. Den server som innehåller abonnemangsinformation kan däre- mot placeras på godtycklig plats eftersom denna server inte kommer att belastas speciellt hårt. I figur 28 ges en översikt över ett system med dessa förutsättningar.

Figur 28: Systemöversikt. Internet Lokalt nätverk Operatörs nätverk Klient Klient ... Control/ DRM server TV streaming server VOD streaming server Web/Info server

Videoströmmarna, som är de som belastar nätet hårdast, distribueras internt i det lokala nätet medan den övriga kommunikationen kan ske över längre sträckor. På detta sätt kan även klienternas mobilitet hållas hög eftersom alla användardata finns samlad på en plats. Det blir alltså möjligt för en klient att flytta runt mellan olika lokala nätverk.

59

MPEG-4-kompatibel settop-box för IP-nät baserad på öppna standarder

KAPITEL

8

8

SLUTSATSER

Detta kapitel sammanfattar examensarbetet samt beskriver resultat och de slutsatser som dragits. Några av de problem som finns förknippade med set- top-boxen diskuteras också.

8.1 Utvärdering av design

I kapitel 7 presenterades två sätt att designa en settop-box för IP-nät. Det ena förslaget är en tunn klient med begränsad funktionalitet som är designad med målsättningen att vara en billig produkt. Det andra förslaget är en något mer avancerad klient med större funk- tionalitet. Båda klienterna är baserade på den standard som utvecklats av ISMA och som fått ett stort stöd bland olika aktörer på marknaden. ISMA:s specifikation finns implementerad i ett projekt med öppen källkod som kallas MPEG4IP [32]. Implementa- tionen tyder på att specifikationen är väl fungerande och att den är en bra plattform för en settop-box. Ett undantag kan vara begränsningen i datatakt. ISMA:s rekommendation tillåter inte datatakter över 1.5 Mbps. För TV-sändningar kan det tänkas vara tillräckligt eftersom kraven normalt sett inte är lika höga då som när en film hyrs. Vid video-on- demand kan dock detta vara ett problem.

I efterföljande avsnitt diskuteras de fördelar respektive nackdelar som finns med de olika klienterna samt alternativa lösningar.

8.1.1 Fördelar

Den största fördelen med den tunna klienten är dess enkelhet. I större upplagor bör den kunna produceras mycket billigt och mjukvaran bör vara relativt enkel att implementera. Inte minst finns det redan väl fungerande implementationer med öppen källkod som kan vara en god start.

Hybridklienten är något mer komplex än den tunna klienten på grund av den inbyggda webb-browsern. De fördelar som webb-browsern innebär gör dock denna klient till det mest attraktiva valet. Möjligheten att använda webben gör det lätt att skapa video-on- demand-tjänster. Det gör det också lättare att hitta andra videotjänster på Internet. Web- ben kan även användas som en avancerad text-TV.

8.1.2 Nackdelar

En stor nackdel med den tunna klienten är svårigheten att använda den för video-on- demand. Med nuvarande design måste en dator eller telefon användas för att tjänsten ska fungera fullt ut. Här har hybridklienten ett stort försprång med sin webbfunktionalitet. Samtidigt kan det ses som en av hybridklientens nackdelar. Licenskostnaden för att få

använda en lämplig webb-browser i settop-boxen blir antagligen inte försumbar och priset kan mycket väl bli avgörande för om en produkt av det här slaget har någon fram- tid.

En annan nackdel är att spelfunktionen inte kan erbjudas i någon av de föreslagna klienterna. Rimligtvis borde en öppen standard för denna typ av styrinformation utveck- las inom en snar framtid eftersom centraliserade spel borde vara attraktiva för spel- företagen. Genom att spelen är samlade på en operatörskontrollerad server är till exempel piratkopiering av spel inte längre aktuellt. Om ett öppet protokoll för styr- information utvecklas kan spelfunktionen inkluderas relativt enkelt i settop-boxen.