SMART IKT FÖR ATT BO OCH ARBETA I NORRA DJURGÅRDSSTADEN HEMMADOMÄNEN

Transkript

1 SMART IKT FÖR ATT BO OCH ARBETA I HEMMADOMÄNEN

2 2(22) Följande personer har bidragit till rapporten. Örjan Mattsson (editor), Acreo Bruce Horowitz, TeliaSonera Michael Åström, Ericsson Stefan Avesand, Ericsson Christer Lindqvist, Acreo

3 3(22) Förord Detta dokument är en delrapport i Smart IKT projektet. Dokumentet behandlar IKT- lösningen i det smarta hemmet som skall stödja, både dagens kommersiella bredbandstjänster som multimedia men även fastighetstjänster och olika samhällstjänster baserade på bredband. På sikt är avsikten att förslag och synpunkter framförda i denna rapport skall ligga till grunden för nybyggnation i Norra Djurgårdsstaden.

4 4(22) Innehåll 1 Inledning Tjänstefunktionalitet Hemmanät Kommunikationsgateway, fastnätsanslutning Kommunikationsgateway, mobil anslutning Realisering av hemmadomän Summering Appendix A HGI Home Gateway Initiative Appendix B.DLNA, Digital Living Network Alliance & UPnP, Universal Plug and Play... 19

5 5(22) 1 Inledning Att med hjälp av Smart IKT kunna förbättra livskvaliteten och öka hållbarheten ställer naturligtvis krav på hur IKT strukturen skall se ut i hemmet. Förenklat kan man beskriva problemställningen som att man signalmässigt skall ansluta de kundspecifika utrustningarna som terminaler, sensorer och sensornät, aktuatorer mm via en hemmadomän till det publika accessnätet. Hemmadomänen kan sägas bestå av en eller flera gateway med tillhörande funktionalitet och av hemmanät Fig. Logisk och fysisk bild av hemmadomänen I studien har vi kartlagt den funktionalitet hos en gateway som krävs både av typen generisk kommunikation och mer specifika krav från de tjänstesegment som Smart IKT skall stödja. Vi har vid realiseringen antagit en kommunikationsgateway för anslutning mot accessnätet och en eller flera tjänstegateway som hanterar kraven från de olika tjänstesegmenten. I studien har vi ägnat uppmärksamhet åt accessformerna till det publika nätet både i form av anslutning till det fasta nätet och till det mobila. Dessutom hur olika tekniker och affärsmodeller kommer in och påverkar lösningen. Vi har stämt av med relevanta IKT standarder inom området som HGI, DLNA och UPnP, se Appendix A och B. HGI far fram rekommendationer för hemmagateway medan DLNA och UPnP är mer inriktade ihopkoppling av olika utrustningar för multimedia men kan bli aktuell för ihopkoppling av annan utrustning i framtiden. I kapitel 8 Realisering finns förslag hur en hemmadomän skulle kunna byggas upp beaktande de krav och önskemål som kommer från boendeform och tillgänglig infrastruktur, hanteringsvänlighet för slutkund, energiförbrukning, affärsmodeller och legala aspekter. Vi har däremot inte haft möjligheten att täcka in kostnads- och driftsaspekten.

6 6(22) 2 Tjänstefunktionalitet Olika tjänster representerande de segment som hemmadomänen skall stödja ställer olika krav på funktionaliteten hos gateway. I utredningen har vi gått igenom aktuella valda områden som vård, omsorg, larm, energi och fastighetsautomation samt multimedia. Det sistnämnda inkluderar Internetaccess, VoIP, IPTV och spel. För alla dessa områden har vi försökt bedöma behovet av bandbredd och fördröjning, krav på säker kommunikation i nätet, krav på tillgänglighet, brandväggsproblematiken, robusthetskrav, krav på säker elförsörjning i form av UPS, behov av datalagring, aktuell exekveringsmiljö samt provisionering. Syftet med kartläggningen är att utreda om det är möjligt att i en tjänstegateway realisera kraven från flera tjänstesegment för att minimera antalet tjänstegateway. Rent generellt kan man säga att de tjänster som är associerade till samhällsfunktioner och även fastighetsautomation ställer högre krav på säkerheten och robustheten jämfört med dagens triple playtjänster. Typ Bandbredd & fördröjning Säker kommunikation Tillgänglighet Interface Brandvägg Robusthet Datalagring UPS Exekverings miljö Vård Video upp till 10 Mb/s Krypto IPsec VPN Hög Dual homing Heart beat BT Zigbee BT ULE USB Ethernet Via certifikat VPN IP-adress Skydd mellan 3:e part SW Lokala data för autonom drift Viktigt Native eller OSGI CE? Omsorg Video, TV upp till 10 Mb/s VPN sekretess Trygghetslar m hög Dual homing Z-Wave BT ULE USB Ethernet HDMI Standard Skydd mellan 3:e part SW Lokal SW för styrning För trygghetslarm Native eller OSGI Larm larm <100 kb/s cam 1 Mb/s up ~ 1s Tjänstespecifikt Krypto VPN Hög Dual homing ZigBee Ethernet BT ULE Z-Wave USB etc. Standard Skydd mellan 3:e part SW Nej Viktigt men ej strikt krav Native eller OSGI Energi & fastigh. Låg BB < 100 kb/s ~ 500 ms Krypto VPN eller tjänstespecifikt Låga krav ZigBee Z-Wave 6LoWPan KNX Standard XMPP Skydd mellan 3:e part SW Lokal SW för styrning Ja, men beror på mätartyp Native eller OSGI Multim. Video (10 Mb/s per TV-kanal) Låg fördr. ~ 20 ms Tjänstespecifikt Kryptoaccelerator Hög, dock ej kritiskt Ethernet CAT-iq Wi-Fi CA Standard Skydd mellan 3:e part SW Nej Nej Native eller OSGI Mkt CPU 2.1 Vård Den mest bandbreddskrävande applikationen för vård i hemmet är video där krav ställs på hög upplösning, och att kunna följa ett visst rörelsemönster. Video börjar dessutom bli aktuellt för fysisk rehabilitering på distans via exempelvis Kinectsystemet. Vård i hemmet är den applikation som ställer de högsta säkerhetskraven. Av sekretess och integritetsskäl måste förbindelsen till exempelvis vårdcentral vara krypterad och gå i en VPN tunnel. Användaren måste kunna autenticiera sig. Kraven på tillgänglighet på förbindelsen är hög, jämför exempelvis med vårdens eget interna nät Sjunet som har kravet 99,999%. Dual homing" dvs. alternativ förbindelse exempelvis via mobilnätet bör därför finnas. På samma sätt säker kraftförsörjning av utrustningen via UPS, Uninterrupted Power Supply

7 7(22) Lokala data för autonom drift i händelse av förbindelsebortfall eller av integritetsskäl skall kunna sparas. Vårdgateway kan komma att klassas som telemedicinsk utrustning och får krav på CE märkning klass 3, dvs. ingen programvaru- och hårdvaruändring efter certifiering. 2.2 Omsorg Även i kvarboendefallet finns video med på listan över viktiga applikationer både för kommunikation och för monitorering. Även TV är intressant för tvåvägskommunikation till och från hemtjänst. Även i omsorgsfallet finns vissa sekretesskrav även om de är lägre än i vårdfallet. Tillgänglighetskravet är högt med tanke på det digitala trygghetslarmet som alltid skall finnas. Idag använder man heart beats för att på larmcentralen bli medveten om när förbindelse saknas. UPS är önskvärt för trygghetslarmet. För omsorg finns inte samma hårda krav på CE märkning som för vård. Lokal programvara exekveras och miljön kan vara native eller exempelvis OSGI. 2.3 Larm Här avses tjänsten larm- och trygghetsfunktioner som inbrottslarm, vattenlarm, brandlarm och enkel styrning av värme, lyse samt kameraövervakning. Kunden är normalt en privatperson. Det finns inga större bandbreddskrav då upplösningen på kamerabilden inte behöver vara särskilt hög. Däremot finns det krav på säker kommunikation så att styrning och övervakning inte kan manipuleras. Stöd för 3:e part programvara är en viktig del av funktionaliteten. 2.4 Energi och fastighetsautomation Denna tjänst täcker funktioner som IMD, individuell mätning och debitering samt tillhörande presentation av mätdata, styrning av värme, belysning och som blivit aktuellt på senare tid styrning av elförsörjningen för att kapa effekttopparna och utnyttja prisskillnaden på el under dygnet. Modesta krav gäller på bandbredd och fördröjning, siffran 500 ms är den fördröjning man tål när det gäller att exempelvis tända en lampa. Däremot är det höga krav på säkerhet. Debiteringsdata är känslig information liksom kunskapen om el- och vattenförbrukning då det kan avslöja om en person är hemma eller ej. Däremot inga större krav på tillgänglighet. UPS kan vara aktuellt beroende på mätartyp Det finns många olika interface alltifrån gamla M-bus till Zigbee, Z-wave, KNX både tråd och radio,ule och 6LoWPAN. Dessutom tillkommer troligen nya, mer energieffektiva interface i framtiden. De flesta interface behöver hanteras lokalt i gateway med programvara som hanterar respektive protokoll och levererar tjänster till andra applikationer. I fallet 6LoWPAN är det istället ren IPv6 och gatewaydelen kan i princip vara mer transparent bortsett från brandvägg och syns därför inte som tjänster på samma sätt. För 6LoWPAN baserade lösningar är det istället den enskilda sensorn eller aktuatorn som kan leverera själva tjänsten direkt till tjänstekonsumenten. Detta möjliggör även äkta "end-to-end" tjänster där en sensor kan stå i direkt kontakt med t ex energileverantörens tjänster på Internet men det ställer krav på att noden har direktkontakt med Internet och att säkerheten är löst.

8 8(22) 2.5 Multimedia Här avses i första hand traditionell triple play men även spel. Avancerade interaktiva spel kan ställa krav på mycket kort fördröjning vilket kräver en trådad förbindelse. Bandbredden bör vara åtminstone 10 Mb/s per kanal för att klara HDTV. Man kan lösa TV distributionen i hemmet på olika sätt och en möjlighet är att ha Set top box i en multimediagateway och sedan slavboxar till TV apparaterna. Det kräver i så fall en kryptoaccelerator i HW och generellt kräver multimediaboxen stor processorkraft för bildbearbetningen. I nya installationer använder man DECT för telefontjänsten men i befintliga miljöer kan det vara aktuellt med ATA funktionalitet för att kunna utnyttja det befintliga telefonnätet. Vad gäller tillgänglighet hos förbindelsen så är den inte kritisk även om en del kan tycka det vid sportsändningar av exempelvis VM i fotboll. 3 Hemmanät Hemmanätet avser realiseringen av den elektroniska kommunikationen i hemmet. Det kan delas upp i två delar. Den ena är det Ethernet-baserade nätet som kopplar ihop switchar, gateways, routers, datorer och andra enheter såsom set-top-boxar och mediaspelare. Det är vanligen i grunden kopparbaserat och uppbyggt med Cat5e-kablar. Ofta finns det också ett trådlöst Wi-Fi-nätverk, där ovanstående enheter kan kommunicera trådlöst och kopplas till det trådade nätet via en accesspunk. Över hela detta nätverk sker sedan kommunikationen med IP. Det finns även andra tekniker som PLC, "power line communication", men det är en osäker teknik som inte behandlas vidare här. Den andra delen av hemmanätet består av andra tekniker än Ethernet. För tjänster som fastighetstjänster, larm och samhällstjänster behöver man ansluta aktuell tjänstegateway till enheter såsom givare och aktuatorer, inte nödvändigtvis IP-baserade. Exempel på lösningar för dessa anslutningar kan vara USB, DECT, ULE, Bluetooth, Z-wave, 6LowPan etc. IT-skåp HAN Givare 3G backup Tjänste GW 1 KNX, Zigbee Z-wave BlueTooth ULE - Givare WAN Kommunikations GW Tjänste GW 2 IT DECT el. PSTN Telefon 3G backup IP över Ethernet Tjänste GW triple play IP över Ethernet IP över Ethernet Dator Set-topbox TV Flera av dessa är trådlösa standarder för energisnål kommunikation med låg hastighet, skräddarsydda för sitt ändamål. Flera kommer i IP-fierad form och på sikt kan man gissa att många kommer att ersättas av lågeffekt WiFi.

9 9(22) 3.1 Cat 5e/Cat6 Kopparbaserad kabel med åtta ledare som klarar av en bandbredd på upp till 1 Gbit/s (1000BASE-T Ethernet). Vedertagen standard som vanligen dras i alla nybyggda bostäder, men även eftermonteras i äldre bestånd som hemmanät. Alla enheter med uttag för trådbaserat nätverk som datorer, tvapparater, mediaspelare och nätverkslagringsenheter (NAS) har interface mot kabeln. Används ofta även som fastighetsnät i flerfamiljshus istället för fiber. 3.2 WiFi Teknik för trådlösa nätverk på 2,4 och 5 GHz-banden som är väl spridd och nästan alla apparater såsom datorer, mediaspelare, mobiltelefoner, läsplattor m.m. har stöd för tekniken. Genom ett antal olika standarder under IEEE (främst a, b, g och n i nuläget, ac beräknas under 2012) uppnås hastigheter på upp till 1 Gbit/s (ac) brutto. Säkerhet är viktigt i och med att det är ett etermedium och kryptering bör användas. Störningar från mikrovågsugnar, trådlösa telefoner, larm m.m. kan förekomma liksom mellan olika Wi-Fi-nätverk då det bara finns tre icke överlappande kanaler 20 MHzkanaler på 2,4 GHz-bandet. På 5 GHz-bandet finns det 19 icke-överlappande 20 MHz-kanaler i Europa som tillsammans med det faktum att 5 GHz är betydligt mindre utnyttjat gör det störningsfriare. Däremot är räckvidden något kortare för 5 GHz beroende på den högra frekvensen. 3.3 USB Universal Serial Bus är ett gränssnitt som främst var tänkt som ersättare för de äldre serie- och parallellportarna och kan hantera hastigheter på upp till 12 Mbit/s (USB 1.1, Full-Speed), 480 Mbit/s (USB 2.0, Hi-Speed) samt 5 Gbit/s (USB 3.0, Super-Speed). Tillåten kabellängd är upp till 5 m och enheter kan strömförsörjas via USB-kabeln. I dag är användningsområdet främst anslutning av skrivare, ljudenheter samt anslutning av andra gränssnitt, såsom 3G-modem eller ZigBee. 3.4 DECT Digital Enhanced Cordless Telecommunications är en standard för radiogränssnittet för trådlösa telefoner. Räckvidden uppgår till ca 50 m inomhus och 300 m utomhus. Utnyttjar 1900 MHz bandet. 3.5 CAT-iq, ULE DECT teknologin CAT-iq, Cordless Advanced Technology-internet and quality, erbjuder möjligheten till HD telefoni. Ett annex till CAT-iq är ULE som stöder effektsnål radiokommunikation till givare etc. 3.6 BlueTooth Efter den danske vikingakungen Harald Blåtand döptes detta gränssnitt för trådlös kommunikation på 2,4 GHz-bandet mellan exempelvis tangentbord och dator, headset och telefon eller telefon och dator. BT finns i ett flertal standarder, där den senaste har versionnummer 4.0. Även tre olika effektklasser finns definierade där Class 1 ger den längsta räckvidden på upp till 100 m. Datahastigheten var ursprungligen specificerad till 72 kbit/s men har senare utökats upp till drygt 3 Mbit/s. BT använder frekvenshoppsteknik (1600 hopp/sekund) för att undvika störningar. Det finns ett stort antal profiler definierade och två enheter som skall kommunicera måste tillsammans stödja samma profil.

10 10(22) 3.7 ZigBee och Z-Wave ZigBee och Z-Wave är två liknande standarder för trådlös styrning och övervakning av utrustning i hem och fastigheter, Plattformen har stöd för mesh-nätverk, stjärnnät och trädstruktur. Tekniken bygger på IEEE och är utvecklad för att vara energisnål. 4 Kommunikationsgateway, fasta nätet Kommunikationsgateway är den enhet som ansluter hemmet till det publika accessnätet och i detta fall antas att det är en anslutning till det fasta nätet. Anslutning till mobila nät behandlas i nästa kapitel. Kommunikationsgatewayen kan vara en del i en annan enhet som omfattar en större mängd funktionalitet men den innehåller alltid en viss uppsättning funktioner, varav några är av fysisk natur. Exempel på de senare är terminering av accessnätsanslutningen. Kopplingen till accessnätet kan bestå av en fiberoptisk kabel, vilken vanligen ansluts direkt till en medieomvandlare (från optiska till elektriska signaler) i kommunikationsgatewayen. En fiberoptisk anslutning kan antingen vara av Ethernettyp (punkt-till-punkt) eller någon form av PON (Passivt Optiskt Nätverk). Accessnätsanslutningen kan också bestå av en elektrisk Ethernetport med RJ-45-kontakt. Detta förekommer främst i flerbostadshus, då kabellängden, inklusive korskopplingskablar, inte kan överstiga 100 meter. Ett tredje alternativ till accessnätsanslutning kan vara en anslutning till det allmänna telefonnätet för access via xdsl eller kabelnät. Då innehåller kommunikationsgatewayen det nödvändiga modemet för att konvertera signalerna till Ethernet. Anslutningen till hemmanätet sker via ett antal, dock minst en, Ethernetportar med RJ-45-kontakt. Kommunikationsgatewayen kan, men måste inte, innehålla någon form av batteri för strömförsörjning vid strömavbrott. I alla händelser så kräver en kommunikationsgateway strömförsörjning för sin funktion. Även om det är möjligt att driva den via PoE (Power over Ethernet, strömförsörjning via accessnätsanslutningens koppar-ethernetkabel), så torde det vanligaste alternativet vara strömförsörjning via elnätet. Egenskaper hos några olika kommunikationsgateway Kravområde IPv4 lager 2 IPv4 lager 3 IPv6 lager 3 Antalet portar 4-8 st =antalet uttag = antalet uttag Tjänsteseparation VLAN IP-adress IP-adress Korskoppling Manuellt i IT-skåp Plug-and-play Plug-and-play Brandvägg I tjänstegateway I tjänstegateway I tjänstegateway Management TR-069 TR-069 TR-069 3:e parts SW Nej Nej Nej

11 11(22) QoS Ja?? UPS Ja Ja Ja Antal hemmanät = antalet VLAN (tjänster) Flera IP-nät på samma hemmanät Ett IP-nät för allt I figuren ovan listas olika grundtyper av kommunikationsgateways tillsammans med de egenskaper och krav som bör ställas på respektive typ. Här följer en genomgång av typerna. 4.1 Kommunikationsgateway, lager 2 Denna typ är vanlig i VLAN-baserade stadsnät samt för xdsl-anslutningar. Varje tjänst kommer in till gatewayen via accessnätet på ett eget VLAN. Kommunikationsgatewayen taggar sedan av VLAN:en och skickar ut dem på var sin port där respektive utrustning sedan ansluts. Varje tjänst hanterar själv tilldelning av IP-adresser. Alla adresser är privata förutom till Internettjänsten. Varje tjänst har ett eget lager två nät, med helt egna IP-nät. Detta får till följd att ska man ansluta en set-top-box, STB, för IPTV och samtidigt ansluta tv:n till Internet (vilket är vanligt med moderna TV apparater), så måste man använda två fysiska förbindelser från IT-skåpet i bostaden till tv:n. Vid in- eller urkoppling av tjänst måste kommunikationsoperatören konfigurera om kommunikationsgatewayen.

12 12(22) 4.2 Kommunikationsgateway, lager 3 En del stadsnät och operatörer använder en kommunikationsgateway som erbjuder alla tjänster på alla portar. Detta görs genom att ansluten utrustning identifieras på något sätt (via MAC-adress eller Vendor-ID i DHCP t.ex.) och då tilldelas en IP-adress på ett lämpligt IP-nät efter detta. Antingen kan detta göras i accessnoden, då hemmagatewayen bara är en dum switch, eller så kan hemmagatewayen själv göra det vilket gör att tjänsterna kan behållas VLAN-separerade i accessnätet. Alla adresser är privata förutom till Internettjänsten. QoS hanteras här antingen i accessnoden eller i gatewayen, beroende på vilken av dem som delat ut IP-adressen, men sker fortfarande på lager två igenom accessnätet. Alla tjänster delar på ett nät, vilket gör att man inte behöver tänka på hur man ansluter annan utrustning till kommunikationsgatewayen. Det går också att förgrena hemmanätet enkelt med dumma switchar vilket gör att man skulle klara sig med en förbindelse i fallet ovan med IPTV-STB och Internetansluten TV. Vid in- eller urkoppling av tjänst måste kommunikationsoperatören konfigurera om kommunikationsgatewayen om det är denna som delar ut IP-adresserna. Om det är accessnoden som gör detta är det där omkonfigureringen måste ske. IPv6 har ännu inte implementerats allmänt. Det är väldigt lik IPv4 förutom adresserna. Eftersom dessa räcker till alla kommer alla adresser vara unika och publika i samma nät och någon tjänsteseparering på lager 2 behövs inte längre. IPv6 kommer att under överskådlig tid att samexistera med IPv4. IP-adresstilldelning fungerar automatiskt genom s.k. stateless autoconfiguration. Även här delar alla tjänster på samma nät vilket förenklar utvidgning av hemmanätet som blir likadan som det förra fallet. Ingen omkonfiguration av kommunikationsgatewayen behöver ske vid förändring av konsumerade tjänster. Tjänsteaccessen styrs i stället av tjänsteleverantören.

13 13(22) 5 Kommunikationsgateway, mobil anslutning 3GPP- baserade accessnät, både 3G och LTE erbjuder flera intressanta möjligheter för mobil kommunikation från en kommunikations- eller tjänstegateway. 3 GPP kommunikation kan även erhållas från terminalutrustningen eller sensorn själv och inte bara från en gateway. Detta erbjuder möjligheten att få motsvarande funktionalitet som en gateway hos mobila enheter som datorer, surfplattor och även mobiltelefoner. Detta kan ses som att utöka hemmadomänen utanför hemmets väggar till alla de platser där man har en mobil enhet som kan interagera med sin omgivning. Den mobila enheten kan sägas bli en förlängning av en hemmagateway utanför hemmet. Den ständigt förbättrade processorkraften hos mobila enheter öppnar upp möjligheten till en personlig gateway som kan fungera som aggregatorer för en mängd olika informationskällor i närheten av enheten. För att kunna erbjuda tjänsteprioriteringar och QoS möjligheter i 3 GPP nätet finns redan olika tekniska standarder framtagna. En option är att konfigurera aktuell gateway med mobil kommunikation så att den ansluter till två olika accesspunkter, vilket innebär att man skapar två separata kanaler för olika prioriterad trafik. Dessa två kanaler kan genereras i exempelvis kommunikationsgatewayen som två separata IP subnät precis som i fallet anslutning till fasta nätet. En annan option är att utnyttja möjligheten hos 3GPP näten att skapa ett nytt Packet Data Protocol (PDP) kontext med en av nätet initierad bärare. Detta kräver ingen ny förbindelse till en annan accesspunkt men kan prioritera trafik baserat på IP adresser från samma accesspunkt (AP). LTE nätet erbjuder redan en sådan möjlighet och existerande 3G nätet kommer snart att bli uppgraderade med den funktionen. Den tredje optionen är en kombination av de två tidigare teknikerna. Den erbjuder en finare granularitet av prioritetsklasser och bygger på två olika accesspunkter och två PDP ramar per accesspunkt när så behövs. Ett tänkbart exempel kan vara en konfiguration där IMS baserade tjänster levereras

14 14(22) via en separat accesspunkt och mediainformationen hos IMS tjänsterna konfigureras dynamiskt med ett annat PDP kontext. kommunikationsgateway inbyggd konnektivitet tjänstegateway 6 Realisering av hemmadomän Frågeställningarna vid realiseringen av hemmadomänen har delats upp i tre huvudområden. Antal tjänstegateway Anslutning till det fasta och mobila accessnätet Hemmanätet, det fysiska och logiska Det är många faktorer som styr valet av realiseringen. Faktorer som främst påverkar är Boendeform och tillgänglig infrastruktur Kundperspektivet, där man måste beakta att samhällstjänster och fastighetstjänster har flera kunder, både slutkund och kommun, landsting och fastighetsägare Krav från tjänsterna för alla de olika segment som skall stödjas Affärsmodeller både ur operatörernas och tjänsteleverantörernas perspektiv Miljöaspekter, i första hand energiförbrukningen Kostnadsaspekten, både vad gäller investering och drift Vi har inte närmare penetrerat kostnadsdelen som är relativt komplex

15 15(22) 6.1 Antal tjänstegateway I den funktionella skissen över gateway var den funktionen uppdelad i en kommunikationsdel och ett antal tjänstegateway betjänande de olika segmenten. I denna rapport utgår vi från att kommunikationsgatewayen är en egen enhet. Om så skall vara fallet är en fråga för utredningen om kommunikationsoperatörsrollen. Vår fokusering är om det finns behov av flera tjänstegateway. Ur kundperspektiv är ett minimum antal burkar av intresse. Det samma gäller ur miljösynpunkt. Varje tjänstegateway kan då de flesta gränssnitt är aktiverade ha en effektförbrukning på W att jämföra med en enkel kommunikationsgateway på ca 5 W. Det pågår både inom EU och i standardiseringsorgan som IEEE och HGI arbete med att ta fram riktlinjer för hur man via power down och andra mekanismer kan få ner strömförbrukningen. Med färre enheter och mindre total energiförbrukning så blir möjligheten att införa UPS mer generellt också enklare. I rapporten har det gjorts en sammanställning av de funktionella krav som de olika tjänstesegmenten ställer på en gateway. Den enhet som avviker mest är vårdgateway som har mycket höga krav på olika former av säkerhet och på att klara kraftbortfall. Dessutom tillkommer legala krav som CE klassning. För medicinsk utrustning finns stränga krav på CE märkning klass 3. Det karakteriseras av att enheten och dess SW skall vara certifierad och får sedan inte modifieras eller uppdateras utan ny certifiering. Det är inte klarlagt om utrustning för vård i hemmet kan få lindrigare krav eftersom detta är ett nytt tillämpningsområde. Om så inte är fallet måste aktuell vårdgateway vara en separat enhet som ansluts via det fasta nätet eller det mobila om det sistnämnda uppfyller de stränga tillgänglighetskraven som diskuteras, alternativt fungera som en back up. Krav från övriga tjänstesegment borde, utom i speciella fall, utan alltför ökad kostnad kunna realiseras i en enda tjänstegateway med de processorkapaciteter och minnesstorlekar som de senaste chippen erbjuder. De flesta interfacen till olika terminalenheter och sensorer realiseras via proppbara USB enheter som belastar respektive tjänst. När bredbandsnätet, både det fasta och mobila, kommer att utnyttjas för samhällstjänster och fastighetstjänster uppstår frågan vem som ska sköta driften dessa tjänster. Det är långtifrån säkert att de konventionella operatörerna vill ta det ansvaret, och man kan tänka sig specialiserade tjänsteoperatörer, exempelvis vårdoperatörer, omsorgsoperatörer, larmoperatörer etc. Dessa baserar sin kommunikation på avtal med aktuell operatör men kan vilja ha sina egna specialiserade tjänstegateway som de som tjänsteoperatör både sköter drift och underhåll. Sådana operatörsroller finns inte idag, men utrullning av samhällstjänster kräver att man löser detta problem. Man skulle kunna undvika nackdelarna med många enheter som det skapar via virtualisering av tjänstegateway exempelvis genom OpenFlow teknik så att logiskt varje operatör har sin egen tjänstegateway men fysiskt är det samma enhet. Bred forskning pågår inom OpenFlow men kommersialisering är några år bort. 6.2 Anslutning till accessnätet De anslutningsformer som är aktuella är anslutning till det fasta nätet via fiber eller höghastighets DSL och till det mobila nätet där det för vissa tjänster krävs LTE eller bättre. Resonemanget förutsätter naturligtvis att båda anslutningsformerna finns. Det är inte bara frågan om antingen fast eller

16 16(22) mobilt utan ofta kompletterande. Ett sådant uppenbart fall är när man använder mobilnätet via "dual homing" som en redundant väg för att öka tillgängligheten. Det fasta nätets styrka är - åtminstone vad gäller fiberanslutning - att bandbredden är i stort sett obegränsad och att förbindelsen är stabil och störningsfri. Marginalkostnaden är liten för att tillföra nya tjänster, bara den fysiska infrastrukturen i hemmet finns på plats. Nackdelarna blir ett större beroende av operatörernas affärsmodeller och att komplexiteten för slutkunden beror på realiseringen av tjänstegateway och det logiska hemmanätet. Det mobila nätet kan användas för de flesta tjänster. Ett frågetecken är TV distribution åtminstone i dagens läge. Ett annat frågetecken är anslutning för vård i hemmet där kraven på tillgänglighet är så höga att mobil anslutning enbart kan ses som en reservförbindelse. Det mobila nätets styrka är dess flexibilitet. Det mest uppenbara fallet är att varje tjänst, dvs. varje terminal har en egen mobil access och då är man totalt oberoende av andra tjänster och andra operatörer. Ett exempel är digitala trygghetslarm med GSM anslutning Det finns även digitala trygghetslarm med två SIM kort för att förbättra tillgängligheten. Prislappen ökar för varje tjänst och då är nästa steg att samla ihop tjänsterna i en tjänstegateway för den mobila accessen eller från en kommunikationsgateway. Den nackdel man då får är beroendet av affärsmodeller och till andra tjänster. 6.3 Hemmanätet, det fysiska och logiska Hemmanätet kan förenklat sägas bestå av ett IP baserat nät för multimediatjänsterna Internetaccess, IP telefoni och IPTV samt ett antal oftast radiobaserade förbindelser till olika sensorer, aktuatorer osv. Vad gäller triple play nätet kan det fysiskt realiseras via kabelnät typ Cat5 och/eller WiFi nät. Allmännyttan har i sina bostäder valt ett kabelnät som går till flertalet rum trots den kostnad det innebär. Skälet till detta är att man inte vill ta ansvar för aktiv utrustning typ WiFi av underhållsskäl och att man vill säkerställa kvalitet i bandbreddsuttagen. Det finns dessutom hyresgäster som är känsliga för att ha radiokommunikation i sina lägenheter. Om man väljer WiFi för sin TV anslutning bör man satsa på 5 Ghz bandet för att säkra bandbredd och separation. Vad gäller IP telefoni är DECT det naturliga valet men många vill fortfarande återanvända sitt analoga telefonnät vilket kräver en relativt kostsam ATA enhet för konvertering Logiskt kan kommunikationen mot accessnätet ske via lager 2 eller lager 3 enligt vad som visats tidigare. Lager 2 nät ger via VLAN en god separering mellan tjänsterna och enkel möjlighet till prioritering. Kommunikationsgatewayen är förutom mediaomvandlare en ren switch med ett antal porter, en för varje tjänst. Nackdelen är att det blir lika många logiska hemmanät som antalet portar dvs. varje bredbandsuttag kommer att vara anslutet till ett av dessa nät och om man vill byta nät måste omkoppling på något sätt ske. I större nät arbetar man oftast på lager 3 och undviker därigenom en del av de begränsningar som lager 2 nätet har. Det är kommunikationsoperatören som samordnar adresstilldelningen i detta fall. Fortfarande har man i IPv4 fallet besvär med begränsningen av antalet publika adresser vilket försvårar enkelheten i hantering för slutkunden. Med introduktionen av IPv6 kan man skapa verklig plug and play för slutkunden vilket är den situation man måste sträva efter.

17 17(22) 7 Summering Den utredning som gjorts avseende Hemmadomän för Smart IKT visar att potentialen finns att skapa en flexibel, modulär realisering som kan stödja de flesta applikationerna även om denna utredning inte har fördjupat sig i kostnadsaspekterna Det största frågetecknet gäller kraven på vård i hemmet där det inte bara är höga säkerhetskrav utan också legala krav som gör att en integration med övrig utrustning i dagsläget är svårt. Vård i hemmet är en ny frågeställning där regelverket släpar efter. Teknikutvecklingen arbetar för att man kan integrera alla typer av tjänster i en Gateway vilket är önskvärt ur hållbarhetssynpunkt utan det blir snarare affärsmodellerna som kan bli hindrande. Användande av IP stödjer också en integration. Idag finns många typer av kommunikationsprotokoll till olika smarta utrustningar och troligen ser vi en utveckling mot mer gemensamma IP baserade lösningar. Knäckfrågor vad gäller smarta hemmet är naturligtvis komplexiteten vad gäller hantering för slutkunden och driften och underhållet av all utrustning. Vad gäller den första frågan ger IPv6 en potential med en mer plug & play liknande lösning vid anslutning av olika utrustningar, men ren IPv6 är fortfarande en framtidsvision. Vad gäller driften så är det en frågeställning som kräver mer utredande liksom hela problematiken kring säker kraftförsörjning. Detta blir en central fråga när vi blir mer och mer beroende av smart utrustning i hemmet.

18 18(22) Appendix A. HGI, Home Gateway Initiative The HGI, founded in 2004 by major broadband service providers (BSPs), and joined by leading vendors of digital home equipment, is shaping the way that IP services are delivered to the home. The HGI publishes requirements for digital home building blocks. Those building blocks are the hardware and software in the digital home that connect consumers and services. They include home gateways, home networks, and home network devices. The HGI s outputs include Requirements documents for home gateways and home networking equipment. HGI requirements documents, which include RD in the title, describe functional requirements for devices or features. An example is the HGI-RD001-R3 document, which describes functional requirements for home gateways in the Release 3 timeframe. Test plans for home gateways and home networking equipment, together with HGIorganised test events that evaluate vendors compliance against functional and performance requirements. Home network and services guidelines. HGI guideline documents, which include GD in the title, provide in-depth analysis of the services, architectures, and issues associated with deployment of services. An example is the HGI-GD002-R2 document, which provides analysis of the deployment of IMS by Broadband Service Providers (BSPs). Policy statements that reflect consensus views of the BSPs in the HGI Management Committee, in areas like energy efficiency, power line home networking requirements, WIFI requirements, etc. These statements are often made through a liaison process with other industry stakeholders. HGI s current work brings major extension of capabilities of the Home Gateway and the home network. The Home Gateway will be more configurable, allowing Service Providers to provide applications and diagnostics in response to their customers specific needs, while the Home Gateway and home network will become more environmentally friendly. The HGI identified these major themes for their current work: Reduction of energy consumption in the home network; Diagnostics capabilities that help Service Providers to support their customers in case of network problems; Understanding the impact of unmanaged services upon services and end-end network requirements; Incorporation of Next Generation Access technologies into the HGI home network requirements. Software Module Execution Environment This section contains requirements for creating a gateway software execution environment that will make it possible to create software modules that extend the capabilities of a standard RGW. Not all

19 19(22) functions will be suitable for execution in such an environment. What these functions have in common are: Control functions rather than data plane transmission functions Functions that easily interface to other modules. Functions which may be implemented once and run on different home gateway models Functions where flexibility is needed in choosing the appropriate version of that function Functions suitable to a multi-service provider model, in which different service providers may provide similar functions on different home gateways. There are, conversely, some functions in a home gateway which are not are not recommended to run as modules, but to implement only in native software. Some of these functions are the networking features (e.g. routing, bridging, NAT), the basic remote management and the firmware upgrade from the ACS. The main factor is that these functionalities must be preserved in the case of an execution environment fault. These functionalities are generally offered in native software, and gain from a direct interaction with the hardware. The software execution environment is typically an OSGi Service Platform which is a Java based technology that adds a comprehensive component model to Java. Moreover, the OSGi provides specifications of optional services. The following figure is an instantiation of the generic architecture for OSGi technology: To enable the software execution environment the following functions are identified in the gateway. HG Core (HG_Core) The HG_Core is using a dedicated operating system (OS). On this operating system, the HG native software is running, providing all or parts of the home gateway functions. Native drivers give access to hardware modules. The summation of the home gateway hardware, operating system, native software and drivers is forming the HG_Core. HG Execution Environment (HG_EE) The service platform is running on the HG_Core, and is used for flexible application software module execution and management. The platform allows life cycle control (install, start, update, stop and uninstall) of provider-managed software modules. The sum-

20 20(22) mation of the service platform and the software modules forms the HG_EE. There may be more than HG_EE running on top of the HG Core. HG Application Programming Interface (HG_API) The HG_API is provided to modules running in the HG Execution Environment (HG_EE), giving standardized access to residential gateway functions. The HG_API can be implemented as part of the HG_Core and as modules running in an HG_EE. The minimal function set of the HG_API must provide access to the parameters defined in TR-098, profiled for the actual HG features. It is assumed that the HG_API is provided by a module (or a set of modules). The actual implementation these modules point to may be found in HG_Core and/or in other modules. Access to the HG_API must be explicitly granted by the operator for each module on a per function basis. Management Agent (MA) A piece of software running on the HG and using CWMP that intermediates between a Remote Management System (RMS) and the HG. It handles requests from the RMS to set and get parameters from the HG or execute HG functions. Moreover, the MA sends notifications from the HG back to the RMS.