personal advertising voor interactieve digitale televisie...
TRANSCRIPT
Jozef Janssens
(iDTV)Personal advertising voor interactieve Digitale Televisie
Academiejaar 2007-2008Faculteit IngenieurswetenschappenVoorzitter: prof. dr. ir. Paul LagasseVakgroep Informatietechnologie
Master in de ingenieurswetenschappen: computerwetenschappen Scriptie ingediend tot het behalen van de graad van
Begeleiders: Philip Leroux, Wim HolvoetPromotoren: prof. dr. ir. Filip De Turck, prof. dr. ir. Bart Dhoedt
VOORWOORD i
Voorwoord
Sinds de opkomst van advertising op het internet zien de TV zenders hun inkomsten aanadvertenties dalen. Het grote voordeel dat internet reclame heeft is dat door middel vancookies de surfers kunnen geprofileerd worden, althans binnen de scope van een adverteer-der. Door de komst van interactieve digitale televisie zullen de TV zenders de mogelijkheidhebben hierop een antwoord te bieden. Een van de mogelijkheden bestaat erin om kijkerste profileren aan de hand van hun interactie met interactieve digitale reclames.
Voor mij was het vlug duidelijk dat dit een interessant onderwerp is en iets wat we ookdaadwerkelijk in de toekomst kunnen verwachten. Dit laatste maakte het onderwerp nogmeer aantrekkelijk. De keuze was dan ook rap gemaakt.
Traditioneel volgt nu een dankwoord. Ik zou dan ook eerst en vooral mijn begeleidersPhilip Leroux, Wim Holvoet en Valentijn Verbrugghe willen bedanken voor de ondersteu-ning tijdens het maken van deze scriptie. Zij waren altijd bereid mij te helpen en het wasaltijd aangenaam om bij hun mijn ideeën te kunnen toetsen. Ook wil ik mijn promotorenProf Filip De Turck en Prof Bart Dhoedt bedanken om mij de kans te geven deze scriptiete doen.
Vervolgens wil ik mijn ouders bedanken om mij de mogelijkheid te geven om te studerenaan de universiteit. Voor veel mensen in de maatschappij is dit niet zo evident als hetwas voor mij. Ook wil ik ze bedanken voor de ondersteuning tijdens het maken van dezescriptie.
Wie toch ook in dit dankwoord moet is Peter Dedecker voor al de LATEX documenten diehij vrij ter beschikking stelt.
Tot slot wil ik al mijn vrienden bedanken om mij geregeld in staat te stellen mijn gedachteneens te verzetten.
Jozef Janssens, juni 2008
TOELATING TOT BRUIKLEEN ii
Toelating tot bruikleen
“De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en
delen van de masterproef te kopiëren voor persoonlijk gebruik.
Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met
betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van
resultaten uit deze masterproef.”
Jozef Janssens, juni 2008
Personal advertisingvoor interactieve Digitale Televisie
(iDTV)door
Jozef Janssens
Scriptie ingediend tot het behalen van de academische graad vanMaster in de ingenieurswetenschappen: computerwetenschappen
optie Informatie- en Communicatietechnologie
Academiejaar 2007–2008
Promotoren: Prof. Dr. Ir. F. De Turck, Prof. Dr. Ir. B. Dhoedt
Begeleiders: P. Leroux, W. Holvoet
Faculteit IngenieurswetenschappenUniversiteit Gent
Vakgroep InformatietechnologieVoorzitter: Prof. Dr. Ir. P. Lagasse
Samenvatting
In deze scriptie wordt uitgewerkt hoe reclames kunnen gepersonaliseerd worden voor in-teractieve digitale televisie in een DSL netwerk. Dit wordt gedaan aan de hand van hetTV3P algoritme. Het TV3P algoritme splitst op in twee delen. Een deel profileert dekijkers, het andere selecteert reclames op basis van dit profiel. De profilering gebeurt opde set-top box en het selecteren van reclames op de DSLAM. Dit alles wordt in een proofof concept geïmplementeerd. Tot slot wordt de implementatie getest.
Trefwoorden
Interactieve Digitale Televisie, profilering, gepersonaliseerde reclame, DSL netwerk.
Personal advertising voor interactive DigitalTelevision (iDTV)
Jozef Janssens
Supervisor(s): Prof. Dr. Ir. Filip De Turck, Prof. Dr. Ir. Bart Dhoedt, Philip Leroux, Wim Holvoet, ValentijnVerbrugghe
Abstract— In this article the possibility to offer personalized advertise-ments for iDTV on a DSL network is researched. This includes a study ofthe DSL network, researching a suited algorithm and an implementation ofthe algorithm in a proof of concept.
Keywords—Interactive Digital Television, profiling, personalized adver-tisements, DSL network.
I. INTRODUCTION
Since the rise of advertising on the internet broadcastingagencies have seen revenues from advertising decline. Withthe arrival of iDTV (Interactive Digital Television) to the sceneadvertising on television sets sounds appealing again. One ad-vantage that advertising on the internet still holds is the abilityto profile surfers through the use of cookies. This only workswithin the scope of an advertiser’s network yet it is still morethan TVs had to offer. In this article we look at the possibility tooffer personalized advertisements for iDTV on a DSL network.For this purpose the structure of a DSL network is looked atin more detail. Next a suited algorithm is searched and imple-mented in a proof of concept.
II. DSL NETWORK
The DSL network can be split up in three parts, the homenetwork, the access network and the core network. These arelooked at in more detail.
A. Home network
The home network holds the CPE (Customer Premises Equip-ment). Typically these are modems or, in the case of digital tele-vision, set-top boxes. They connect devices in the home networksuch as computers or television sets to the DSL network.
B. Access network
In the access network multiple CPE are connected to aDSLAM (DSL Access Multiplexer). This DSLAM combinesthe signals coming from the CPE into one by multiplexing theincoming signals. In the other direction the DSLAM demulti-plexes the signal into many different signals going to the CPE.
The DSLAM are connected with each other in an ethernet net-work. At the edge of this ethernet network a BNG (BroadbandNetwork Gateway) routes all the traffic between the DSLAMand the core network.
C. Core Network
The core network connects all the BNG with each other. TheBNG form the edge of the core network. Within the core net-work there are connections with other network and application
service providers and with content providers. There will also beVOD servers, billing servers, an IT department, etc.
III. ALGORITHMS
In this part we will take a brief look at two algorithms thatcan be used to provide users with personalized commercials.
A. Collaborative filtering
A.1 User based
User based collaborative filtering[1] relies on the notion thatthe user is part of a group of similarly-behaving people. Thus ifone takes the group that matches the user more closely than anyother, one can use the preferences of that group as a profile forthe user. If this were used for commercials one would search fora group that found the same commercials interesting and thenlook at which other commercials the group found interesting aswell.
A.2 Item based
Item based collaborative filtering[1] has another angle on thesame problem. It relies on the notion that there are relationsbetween preferences. There is no longer a need to find a group,which is a big computational advantage. If this were used forcommercials one would search the commercials that are similarto the ones the user found interesting.
B. TV3P
The TV3P algorithm [2] allows us to build a profile of the userbased on his or her interaction with the commercial. For this acommercial has a profile of its own which consists of terms thatdescribe the content. Whenever the user interacts his or her pro-file is updated by either including these terms along with a scoreif they didn’t exist, or by adapting the score to reflect the inter-action. The algorithm also allows for a negative interaction withthe commercial, which subtracts from the score. To provide theuser with personalized commercials one compares the profile ofthe user with the profile of the commercials and selects thosethat are most relevant.
IV. PROOF OF CONCEPT
In the proof of concept the profiling part of the TV3P algo-rithm was implemented on the STB. Not a real STB was usedhowever, a PC fulfilled that role. The selection of personalizedcommercials for the user happens on the DSLAM, which is alsorepresented by a PC. The DSLAM gets its commercials through
Fig. 1. High level architecture of the proof of concept
a data carousel which originates from the core network. In or-der to increase the storage efficiency on the DSLAM it will onlystore commercials that are relevant to the users on the differentCPE. To get personalized commercials the DSLAM will keeptrack of which users are currently watching which channel. Forthe active users it saves which commercials to send in memory.The DSLAM will try to get the commercials to the STB beforethe commercials have to start. The STB in turn stores the com-mercials before playing them. This opened up the door to havethe STB pick the commercials for its users from its own pool ofcommercials. However this has to take into account the numberof times a commersial was played, otherwise the same commer-cials would play over and over.
V. TESTING
In a number of tests we researched how sensitive the imple-mentation of the TV3P algorithm is to changes to its parameters.For this we tracked the number of commercials till the profilesreach steady state. The result of the test is shown in figures 2, 3and 4. Aside from some anomalies, the implementatie is ratherrobust with only a varying weightdistribution having a definiteimpact.
Due to time constraints we resorted to modeling (fig. 5) thestorage usage on the STB and DSLAM instead of testing it.Making the model did give an insight into the complexity ofthe matter.
VI. CONCLUSION
This work provides a solution to personalize commercials foriDTV on a DSL network. A proof of concept that allows toprofile and personlize commercials was implemented. There isstill much room for improvement, however.
REFERENCES
[1] G. Karypis Evaluation of item-based top-N recommendation algorithms,Proceedings Of The 2001 Acm Cikm. Tenth International Conference OnInformation And Knowledge Management, pp. 247-254, 2001.
[2] Z. W. Yu and X. S. Zhou TV3P: An adaptive assistant for personalized TV,Ieee Transactions On Consumer Electronics, vol. 50, pp. 393-399, 2004.
Steady state in functie van gespeelde reclames
0,00
0,20
0,40
0,60
0,80
1,00
1,20
0,00 50,00 100,00 150,00 200,00 250,00 300,00
Gespeelde reclames
Ste
ad
y s
tate
alpha = 0,1
alpha = 0,3
alpha = 0,5
alpha = 0,7
alpha = 0,9
Fig. 2. Steady state for varying alpha
Steady state in functie van gespeelde reclames
0,00
0,20
0,40
0,60
0,80
1,00
1,20
0,00 50,00 100,00 150,00 200,00 250,00 300,00
Gespeelde reclames
Ste
ad
y s
tate
50% - 50%
60% - 40%
70% - 30%
80% - 20%
90% - 10%
Fig. 3. Steady state for varying weightdistribution
Steady state in functie van gespeelde reclames
0,00
0,20
0,40
0,60
0,80
1,00
1,20
0,00 50,00 100,00 150,00 200,00 250,00 300,00 350,00
Gespeelde reclames
Ste
ad
y s
tate
Top-N 20
Top-N 40
Top-N 60
Top-N 80
Top-N 100
Fig. 4. Steady state for varying top-n
Opslagcapaciteit Verbruik
0
200
400
600
800
1000
1200
1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101
Reclameblokken
Ve
rbru
ik (
aa
nta
l re
cla
me
s)
DSLAM
STB
Fig. 5. Modelled storage usage for optimized solution
INHOUDSOPGAVE vi
Inhoudsopgave
Voorwoord i
Toelating tot bruikleen ii
Overzicht iii
Extended abstract iv
Inhoudsopgave vi
Gebruikte afkortingen viii
1 Inleiding 11.1 Interactieve Digitale Televisie . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Interactieve reclame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Theoretische benadering 42.1 Doelstelling scriptie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 DSL Netwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Het oude DSL netwerk . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.2 Het nieuwe DSL netwerk . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Algoritmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.1 Collaborative Filtering Algoritmen . . . . . . . . . . . . . . . . . . 82.3.2 TV3P Algoritme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.1 Kwaliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.2 Schaalbaarheid en complexiteit . . . . . . . . . . . . . . . . . . . . 142.4.3 Keuze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Inpassing TV3P in DSL netwerk . . . . . . . . . . . . . . . . . . . . . . . . 162.5.1 Profilering gebruiker . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5.2 Reclame personaliseren . . . . . . . . . . . . . . . . . . . . . . . . . 17
INHOUDSOPGAVE vii
3 Proof of concept 193.1 Opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 STB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 Reclamebeheer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.2 Profielbeheer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.3 Communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.4 Package stb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 DSLAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.1 Kanalen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.2 Communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.3 Reclame Beheer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3.4 Profiel Beheer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4 Videobeelden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.4.1 JMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.4.2 Reclames uitwisselen en afspelen . . . . . . . . . . . . . . . . . . . . 393.4.3 Streamen video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 Testen 434.1 Parameter test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.1 Test opstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.2 Verversingsfactor α . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.1.3 Verhouding gewichten impliciete en expliciete feedback . . . . . . . 474.1.4 Top-N termen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 Storage test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3 Bandbreedte test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5 Besluit 56
Bibliografie 57
Lijst van figuren 59
Lijst van tabellen 61
GEBRUIKTE AFKORTINGEN viii
Gebruikte afkortingen
STB Set-Top Box
EPG Electronic Program Guide
VOD Video On Demand
iDTV Ineractieve Digitale Televisie
DSL Digital Subscriber Line
CPE Customer-Premises Equipment
DSLAM DSL Access Multiplexer
ATM Asynchronous Transfer Mode
STM Synchronous Transport Module
BRAS Broadband Remote Access Server
PPP Point-to-Point Protocol
IP Internet Protocol
QOS Quality of Service
NSP Network Service Provider
ASP Application Service Provider
IT Information Technology
BNG Broadband Network Gateway
TV3P TV Program Personalization for PDR
PDR Personal Digital Recorder
JMF Java Media Framework
RTP Real-Time Transmission Protocol
RTCP Real-Time Control Protocol
FOBS4JMF FOBS for JMF
GEBRUIKTE AFKORTINGEN ix
FOBS Ffmpeg OBjectS
INLEIDING 1
Hoofdstuk 1
Inleiding
1.1 Interactieve Digitale Televisie
Sinds 2005 bieden ook in Vlaanderen een aantal operatoren interactieve digitale televisie
aan. Digitale televisie heeft ten opzichte van analoge televisie een aantal sterke troeven.
Zo kan door het beeld digitaal te coderen de nodige bandbreedte sterk gereduceerd wor-
den. Ook zijn de digitale beelden minder gevoelig voor storingen door de ingebouwde
redundancy in de codering. Voor de kijker komt dit neer op meer kanalen aan een hogere
beeldkwaliteit. Om digitale televisie te ondersteunen heeft met een hardware decoder
nodig die het digitale signaal kan omzetten in beeld. Deze hardware decoder kan zich
bevinden in de televisies zelf. Echter in Vlaanderen werkt men vooral met set-top boxen
(STB). Deze bieden dan ook een interactiviteit aan via software, ’middleware’ genaamd.
Het interactieve luik van iDTV is een extra troef van digitale televisie. Het laat toe om te
interageren met de televisie maar ook met de televisie zender. Interactie met de televisie
biedt een betere gebruikerservaring. De EPG kan geconsulteerd worden om te zien welke
programma’s momenteel spelen. E-mails of websites kunnen bekeken worden. Er zijn ook
games voorzien. Interactie met de televisie zenders gebeurt via het return path. Dit is het
pad van communicatie van de set-top box naar de content providers (dit zijn de televisie
zenders). Een voorbeeld van interactie met een zender is stemmen op een kandidaat voor
bijvoorbeeld Idool 2008. Nog een vorm van interactiviteit is de mogelijkheid voor video
on demand (VOD), hierbij kan de kijker een video aanvragen om af te spelen, hij of zij
moet niet langer naar de videotheek.
1.2 Interactieve reclame 2
1.2 Interactieve reclame
Interactieve reclames laten toe dat de kijker, als deze geïnteresseerd is, interageert met
de reclame. Deze interactie kan een deelname zijn aan een wedstrijd die de adverteerder
uitschrijft. Het kan ook een vraag voor extra informatie zijn in de vorm van video’s of
webpagina’s.[5] Een interactieve reclame zal doorgaans extra informatie willen geven bui-
ten de video stroom, bijvoorbeeld om een wedstrijd aan te kondigen. Om dit mogelijk
te maken wordt gebruik gemaakt van grafische overlay of herschaling. Deze twee functi-
onaliteiten worden aangeboden door de set-top box. Bij grafische overlay wordt de extra
informatie bovenop het beeld getoond. De video stroom is de basislaag en daarboven
komen een of meerdere transparante lagen. Op deze transparante lagen kan dan de ex-
tra informatie aangebracht worden. Bij herschaling zal het beeld verkleind worden en de
extra informatie rond dit beeld geschikt worden.
Om interactie zoals een deelname aan een wedstrijd mogelijk te maken zal ook een lokale
interactie nodig zijn. Hierbij moet de gebruiker kunnen ingaan op de wedstrijd, eventueel
vragen invullen, zijn of haar gegevens invullen en doorsturen. Om dit invullen van gege-
vens te vereenvoudigen kan men deze informatie opslaan op de STB en dan automatisch
invullen, zoals teruggevonden wordt in webbrowsers. Aangezien een STB meestal een
multi-user omgeving is zal hierbij moeten gewerkt worden met verschillende identificaties
voor de verschillende familieleden. Hieruit wordt geselecteerd bij het invullen. Dit zal
nog altijd veel sneller zijn dan altijd opnieuw naam en adres in te typen. Het digitale
wedstrijdformulier zal na het invullen worden gestuurd naar de adverteerders, dit via het
return path besproken in de vorige sectie.
Het is duidelijk dat de interactieve reclames van de toekomst iets zullen te bieden hebben
aan de kijkers. Ze kunnen deelnemen aan wedstrijden, direct extra informatie opvragen
of misschien zelf direct kopen. Het is dus voor de kijkers thuis interessant om zo veel
mogelijk reclames te krijgen die in hun interesse sfeer liggen. Voor de kijkers vormen
gepersonaliseerde interactieve reclames een voordeel. De adverteerders zelf zijn hierbij ook
gebaat want ze bereiken veel beter de doelgroepen die ze willen bereiken en staan er ook in
een nauwer contact mee. Om een voorbeeld te geven: Bank X heeft jongerenrekeningen en
effectenrekeningen als product. Als doelgroepen heeft Bank X dus jongeren en beleggers.
Deze twee doelgroepen liggen ver uit elkaar. Gepersonaliseerde reclames laat Bank X toe
1.3 DSL 3
om tegelijkertijd met verschillende reclames deze twee doelgroepen in te lichten over hun
nieuwe producten of promoties.
1.3 DSL
Deze scriptie spitst zich toe op de implementatie van gepersonaliseerde advertenties voor
iDTV in een DSL netwerk. In Vlaanderen zijn er momenteel twee operatoren die iDTV
aanbieden. Hoewel beiden iDTV aanbieden gebruikt elk een andere netwerk technologie
en structuur. Een operator gebruikt Kabel om iDTV aan te bieden, de andere DSL. Het
verschil tussen deze twee netwerken ligt in hun geschiedenis.
Het Kabel netwerk is ontworpen om analoge televisie signalen te broadcasten naar alle
mensen aangesloten op het netwerk. Iedereen krijgt continu dezelfde analoge signalen
(zenders) en de kijker beslist naar welke van deze signalen te kijken. Het Kabel netwerk
wordt gedeeld met alle gebruikers.
Het DSL netwerk komt voort uit het telefonie netwerk. Dit is meer gericht op punt
tot punt verbindingen tussen twee gebruikers waarbij een centrale de verbinding maakt.
Iedere gebruiker op dit netwerk heeft als het ware zijn eigen lijn tot aan de centrale. Het
is geen gedeeld netwerk. In het kader van iDTV zal de video stroom vanuit “de centrale”
over de gebruiker zijn eigen lijn gestuurd worden. In het volgende hoofdstuk wordt hierop
dieper ingegaan.
THEORETISCHE BENADERING 4
Hoofdstuk 2
Theoretische benadering
2.1 Doelstelling scriptie
Het doel van deze scriptie is onderzoeken hoe gepersonaliseerde reclame voor iDTV op een
DSL netwerk kan geïmplementeerd worden. Hiervoor is een studie van het DSL netwerk
nodig en een studie van algoritmen om reclame te personaliseren. Uit deze algoritmen
moet er een gekozen worden die het best in het DSL netwerk geïntegreerd kan worden.
Dit in functie van de kwaliteit, schaalbaarheid, bandbreedte beperkingen en complexiteit.
2.2 DSL Netwerk
2.2.1 Het oude DSL netwerk
In dit deel zullen we het oude DSL netwerk bespreken. Hoewel dit digitale televisie kan
ondersteunen houden we dit voor het volgende deel. Dit deel is bedoeld om een overzicht
te geven van de structuur. Het DSL netwerk kan opgesplitst worden in drie delen. Het
thuisnetwerk, accessnetwerk en kernnetwerk.
Thuisnetwerk
Het thuisnetwerk weergegeven op figuur 2.1 is dit deel van het DSL netwerk waar de
Customer-Premises Equipment (CPE) zich bevinden. Dit zijn typisch modems voor tele-
fonie en/of internet.
2.2 DSL Netwerk 5
Figuur 2.1: Structuur van het oudere DSL netwerk. [6]
Accessnetwerk
De CPE uit het thuisnetwerk worden verbonden met een DSL Access Multiplexer (DSLAM).
De DSLAM werkt als een ATM aggregator en cross connect. Als ATM aggregator zal
deze de signalen van de verschillende CPE combineren in een signaal door te multiplexen.
In de omgekeerde richting wordt dit signaal gesplitst door te demultiplexen. Het aantal
CPE dat verbonden is met een DSLAM is beperkt.
Verschillende DSLAM’s worden met elkaar verbonden in een ATM netwerk, dit noemt men
het aggregatienetwerk weergegeven op figuur 2.1. Het ATM netwerk bestaat doorgaans uit
STM-1 lijnen (bandbreedte van 155Mbit/s). Aan de grens van dit netwerk bevindt zich
de Broadband Remote Access Server (BRAS). De BRAS is een IP node die het verkeer
routeert van en naar het kernnetwerk. Afhankelijk van welke standaard wordt gevolgd
kan een BRAS eenvoudige functionaliteit hebben (vooral PPP terminatie en tunneling)
of ook IP QOS, subscriber management, geavanceerde IP processing, ... ondersteunen.
Kernnetwerk
Het kernnetwerk wergegeven in figuur 2.1 is het centrum van het DSL netwerk. Het
connecteert alle BRAS’s met elkaar, deze vormen de grens van het kernnetwerk. Verder
bevat het kernnetwerk connecties met andere NSP’s en/of ASP’s en de IT infrastructuur
(nodig voor monitoring, billing, onderhoud, ...)
2.2 DSL Netwerk 6
2.2.2 Het nieuwe DSL netwerk
In het nieuwe DSL netwerk migreren de service providers van een ATM aggregatienetwerk
naar een ethernet aggregatienetwerk. Dit is nodig om hogere bitrates te krijgen alsook
diensten te ondersteunen die QOS, multicast en availability vereisten hebben. Dezelfde
opsplitsing blijft gelden.
Figuur 2.2: Structuur van het nieuwe DSL netwerk. [7]
Thuisnetwerk
In het thuisnetwerk weergegeven in figuur 2.2 bevinden zich ook set-top boxen onder de
CPE. Een STB is nodig om het digitale signaal van digitale televisie te decoderen. Dit
kan eventueel ook in het televisie toestel zelf gebeuren indien dit met een decoder is uit-
gerust welke de digitale standaard van de provider kan decoderen. Naast het decoderen
van het digitaal signaal, wat hardwarematig gebeurt, bevat een STB ook een software
gedeelte. Dit software gedeelte, middleware genaamd, zal instaan voor interactiviteit met
de gebruiker. De middleware zal de communicatie beheren, dit is enerzijds met de gebrui-
ker via bijvoorbeeld de afstandbediening, anderzijds ook met het netwerk. Communicatie
met het netwerk is bijvoorbeeld nodig voor VOD of om op een interactieve reclame via
het netwerk (return path) te antwoorden. De middleware zal ook het beeld controleren
om bijvoorbeeld interactieve applicaties of reclames (via overlays) af te beelden.
2.2 DSL Netwerk 7
Accessnetwerk
Hier is het ATM aggregatienetwerk vervangen door een ethernetnetwerk, zie figuur 2.2. De
BRAS wordt vervangen door een Broadband Network Gateway (BNG). Dit is een BRAS
met meer functionaliteit. De BNG moet onder andere multicast, VLAN’s en VPN services
ondersteunen. Er bestaat ook de mogelijkheid om met meerdere gespecialiseerde BNG’s
te werken. Bijvoorbeeld kan er gekozen worden om een videoBNG specifiek voor digitale
televisie naast een normale BNG te werken. Deze twee BNG’s moeten samen de nodige
functionaliteit aanbieden, maar zijn niet verplicht elk alles aan te bieden. Dit maakt
het mogelijk dat men kernnetwerken specifiek voor digitale televisie uitrolt en enkel het
access- en thuisnetwerk met internet en telefonie deelt. Dit wordt weergegeven in figuur
2.3.
Figuur 2.3: Werken met een videoBNG. [7]
Kernnetwerk
In het kernnetwerk weergegeven in figuur 2.2 zitten naast de vorige onderdelen nu ook
content providers, dit is bijvoorbeeld de VRT, en VOD servers.
2.3 Algoritmen 8
2.3 Algoritmen
In dit deel worden een aantal algoritmen besproken waarna gekeken wordt naar de inte-
gratie in het DSL netwerk.
2.3.1 Collaborative Filtering Algoritmen
Er bestaan twee varianten van collaborative filtering algoritmen [3], deze worden hierna in
meer detail uitgelegd. De algoritmen worden gebruikt in aanrader systemen voor websites.
Ze baseren zich op correlaties tussen de keuzes van een gebruiker (aankopen, downloads,
etc.) en deze van vorige gebruikers. Op basis van deze correlaties worden nieuwe items
aangeraden aan de gebruiker. In het kader van deze scriptie komt een item overeen met
een (interactieve) reclame, een keuze met een interactie en het aanraden met afspelen.
User Based
In user based collaborative filtering gaat men ervan uit dat elke gebruiker tot een grotere
groep van gebruikers met dezelfde voorkeuren behoort. Items die door deze groep werden
gekozen, kunnen aangeraden worden aan een gebruiker die verwant is aan deze groep.
Men kan het algoritme best begrijpen door een user-item matrix R te beschouwen met
dimensie NxM.
R =
1 0 0 . . . 1
0 1 0 . . . 1
1 1 1 . . . 0... . . . ...
0 1 1 . . . 0
In matrix R stelt elke rij het profiel van een gebruiker voor. Elke kolom stelt een item
voor. Op plek ri,j in matrix R zal een één staan als het item j door gebruiker i werd ge-
kozen en een nul als dit niet zo is. Deze matrix moet dus bij elke keuze van een gebruiker
geupdate worden.
V =(
1 1 0 . . . 1)
2.3 Algoritmen 9
Wil men items aanraden aan een gebruiker wiens profiel de vector V (dimensie 1xM)
is, dan zal men de N gebruikers in R vergelijken met de vector V. Er wordt een groep
samengesteld van de K meest gelijkaardige gebruikers aan V. Eens deze groep gevonden
is kunnen de items die nog niet in V voorkomen en het meest frequent gekozen werden
door de groep, aan gebruiker V worden aangeraden. De frequentie kan men op twee
manieren bepalen. Ofwel wordt de som genomen van het aantal keer een item werd
gekozen. Ofwel worden eerst de rijen van de groep genormaliseerd alvorens deze som te
nemen. Deze laatste methode zorgt ervoor dat gebruikers die veel items kiezen een minder
grote impact hebben, dit leidt tot betere resultaten.
Item Based
In item based collaborative filtering wordt uitgegaan van dezelfde user-item matrix R.
Echter hier worden relaties tussen verschillende items gelegd. Als een gebruiker een be-
paald item kiest zal hij waarschijnlijk geïnteresseerd zijn in gelijkaardige items. Per item
j in de matrix R worden de K meest gelijkaardige items {j1, j2, . . . , jk} en een correlatie-
score {sj1 , sj2 , . . . , sjk} bijgehouden. Wil men aan een gebruiker V een item aanraden dan
zal men de unie nemen van de sets van K meest gelijkaardige items van elk item j in
V (j werd gekozen) verminderd met de items in V zelf. Deze set noemt men de set C.
Vervolgens worden de items c ∈ C geordend volgens dalende correlatie met V, dit is de
som van correlatie-scores tussen c en elke item in V. De correlatie-scores kunnen bepaald
worden op twee verschillende manieren.
Cosine-Based Similarity ziet items als vectoren en neemt als correlatie-score tussen twee
items v en u de cosinus tussen de twee vectoren die overeenstemmen met de v-de en u-de
kolom in matrix R.
cos(~u,~v) = ~v.~u‖~v‖‖~u‖
Conditional Probability-Based Similarity gaat uit van een conditionele kans dat een item
u wordt gekozen indien item v al werd gekozen door de gebruiker. Voor u en v is dit het
aantal gebruikers dat u en v gekozen hebben, gedeeld door het totaal aantal gebruikers
dat v heeft gekozen. P (u|v) = Freq(uv)Freq(v)
waarbij Freq(X) het aantal gebruikers dat items
in set X heeft gekozen, is. Een nadeel aan deze formule is dat als een item u veel gekozen
wordt omdat het populair is, zal P (u|v) ook hoog zijn. Er is echter niet noodzakelijk een
2.3 Algoritmen 10
verband tussen u en v. De formule wordt daarom als volgt aangepast.
P (u|v) =Freq(uv)
Freq(v)(Freq(u))α0 ≤ α ≤ 1
De parameter α is hier ingevoerd om vrijheid te geven bij het schalen van P (u|v). De
optimale factor is probleem specifiek (zie [3]).
2.3.2 TV3P Algoritme
Het TV3P algoritme [1] vindt zijn oorsprong in het aanraden van TV programma’s uit
de Electronic Program Guide (EPG) op basis van een profiel van de gebruiker en een
profiel van het TV programma. In het kader van deze scriptie komt een TV programma
overeen met een (interactieve) reclame en het aanraden ervan met afspelen. Het profiel
van de gebruiker is een vector 2-tuples waarbij elke tuple bestaat uit een term en een
gewicht, gesorteerd op afnemend gewicht. Het profiel van een programma is de metadata
die dit programma beschrijft, hiervoor wordt de MPEG-7 Description Definition Langu-
age (DDL) structuur gebruikt. De metadata heeft dan volgende velden: Titel, Genre,
Acteur, Kernwoord en Duur (dit is de duur van het programma). De werking van het
algoritme valt uiteen in twee delen, enerzijds is er een systeem dat programma’s aanraadt
en anderzijds een systeem dat het profiel van de gebruiker opstelt en aanpast.
Programma’s aanraden
Het profiel van een gebruiker met m termen ziet er uit als volgt:
P = ((t1, w1) , (t2, w2) , . . . , (tm, wm)) wi ≥ wi+1
Hierbij is ti een term en wi het overeenkomstige gewicht. In het algoritme worden de top
n hoogste termen genomen wat neerkomt op:
P = (w1, w2, . . . , wn)
Vervolgens wordt voor het programma een gelijkaardig profiel opgesteld:
C = (u1, u2, . . . , un)
Waarbij ui een gewicht is dat bepaald wordt als volgt. Voor elke categorie in de metadata
(Titel, Genre, ...) bestaat een vast gewichtWx met volgende rangorde: WT itel > WGenre >
2.3 Algoritmen 11
WActeur > WKernwoord. Er wordt voor elke term ti gezocht of deze term voorkomt in het
profiel van het programma. Is dit zo dan krijgt ui de overeenkomstige waarde Wx. Komt
de term meerdere keren voor dan wordt Max(Wx) genomen. Komt de term niet voor dan
wordt 0 genomen.
Nu wordt een correlatie-score bepaald voor het TV programma. Hiervoor wordt de cosinus
functie gebruikt zoals in Item-Based Collaborative Filtering:
cos(C,P ) = C.P‖C‖‖P‖
Als deze score groter is dan een vaste threshold θ, dan wordt het programma gezien als
relevant voor de gebruiker, deze kunnen dan aangeraden worden. Anderzijds kunnen ook
de x hoogst scorende programma’s aangeraden worden.
Profilering van de gebruiker
Om het profiel van een gebruiker op te stellen en aan te passen wordt rekening gehouden
met de feedback die de gebruiker geeft. Deze feedback is op te splitsen in impliciete en
expliciete feedback. Onder impliciete feedback wordt verstaan hoe lang een programma
wordt bekeken. Voor expliciete feedback is dit de actie die de gebruiker onderneemt ten
opzichte van aangeraden programma’s (het tonen, het automatisch laten spelen of het
verwijderen).
Impliciete profilering
Als een programma afloopt of de gebruiker zapt weg dan wordt impliciete profilering
uitgevoerd. Hierbij worden alle termen in de metadata van het programma overlopen.
Bestaat de term ti al in het profiel van de gebruiker dan wordt het bestaande gewicht wigeupdate als volgt:
w′i = (1− α)wi + α ∆wi 0 ≤ α ≤ 1 (2.1)
∆wi =TrTt
Imax − iImax
1 ≤ i ≤ Imax
Met Tr
Ttde verhouding van de tijd gekeken op de totale duur van het programma en Imax
het totaal aantal termen in het profiel, zodanig dat de factor Imax−iImax
belangrijkere termen
positief beïnvloedt.
Bestaat de term nog niet in het profiel dan wordt volgende formule gebruikt om het
gewicht te berekenen:
2.4 Analyse 12
wi = α Tr
Ttε > λ
ε is een vaste waarde die de factor Imax−iImax
moet uitdrukken. Met het gedeelte > λ wordt
bedoeld dat een term pas wordt opgenomen in het profiel als zijn gewicht groter is dan
een vooropgestelde threshold λ.
Expliciete profilering
Op basis van interacties van de gebruiker wordt expliciete profilering uitgevoerd. Hierbij
worden opnieuw termen in de metadata van het programma over lopen. Als de term
ti bestaat wordt het gewicht geupdate als in formule 2.1. ∆wi wordt bepaald op basis
van de interacties: toon of verwijder het aangeraden programma, of laat het automatisch
afspelen.
• Toon: Dit is sterke positieve feedback. ∆wi = 2
• Automatisch afspelen: Dit is zwakke positieve feedback. ∆wi = 1
• Verwijder: Dit is sterk negatieve feedback. ∆wi = −2
Impliciete + Expliciete profilering
Om impliciete en expliciete profilering te combineren wordt volgende formule gebruikt:
w′i = (1− α)wi + α ∆wi 0 ≤ α ≤ 1
∆wi = WI ∆wiI +WE ∆wiE
WI +WE = 1 0 ≤ WI ≤ 1
0 ≤ WE ≤ 1
Hierbij is ∆wiI de ∆wi bekomen door impliciete profilering en ∆wiE de ∆wi bekomen
door expliciete profilering. WI en WE worden gebruikt om meer of minder nadruk te
leggen op ofwel impliciete ofwel expliciete profilering.
2.4 Analyse
2.4.1 Kwaliteit
Collaborative Filtering
Bij beide varianten van collaborative filtering is het duidelijk dat geen rekening wordt
gehouden met de inhoud van de items. In user based wordt een item aangeraden wanneer
2.4 Analyse 13
het veel voorkomt in een groep van gelijken. Het is mogelijk dat een populair item sowieso
in een de groep zit ook al heeft de huidige gebruiker daar geen interesse in. Voor item
based geldt hetzelfde probleem, hier wordt geprobeerd de inhoud te schatten door relaties
te zoeken tussen items. Echter twee populaire items kunnen hierbij met elkaar gelinkt
worden, ook al zijn ze heel verschillend. Concreet voor reclames is dit nog minder wenselijk
dan voor bijvoorbeeld producten op websites, aangezien de adverteerders een bepaalde
doelgroep voor ogen hebben.
Uit bovenstaande blijkt ook dat collaborative filtering een voorkeur vertoont voor meer
populaire items. Hierdoor moet een item al een zeker momentum hebben eer het aange-
raden begint te worden. Als opnieuw naar reclames als items wordt gekeken, moet een
reclame niet alleen meerdere malen afgespeeld worden bij verschillende gebruikers maar
daarenboven moet er ook interactie zijn vooraleer de reclame gepersonaliseerd begint te
worden. Er zal bijgevolg in een reclame blok een aantal random (nieuwe) reclames moe-
ten zitten om nieuwe reclames een kans te geven om ingang te vinden. De kans bestaat
nog altijd dat een reclame nooit ingang vindt doordat het doelpubliek niet of te weinig
interageert met de reclame, ook al wordt ze afgespeeld.
Ten slotte wordt het testresultaat [3] van collaborative filtering bekeken. In de test uit-
gevoerd werden verschillende datasets gebruikt. Twee daarvan springen in het oog. Een
dataset is een cataloog. De andere dataset is er een van film ratings. Collaborative Filte-
ring behaalt een recall ratio van maximaal ongeveer 50% bij een cataloog, dit valt echter
terug naar ongeveer 25% bij de films dataset. De recall ratio is:
recall ratio = aantal hitsaantal relevante items
waarbij het aantal hits slaat op het aantal correct aangeraden items, of beter reclames die
de gebruiker interesseren. Het aantal relevante items is het totaal aantal items (reclames)
in de collectie die interessant zijn voor de gebruiker. Wat deze score uitdrukt is de
hoeveelheid relevante items, of hier reclames, die ontdekt worden door het algoritme.
TV3P Algoritme
In het TV3P algoritme wordt duidelijk rekening gehouden met de inhoud van de recla-
mes aangezien deze beschreven worden aan de hand van metadata in hun profiel. Deze
inhoud vindt ook zijn weg naar het profiel van de gebruiker aangezien de termen worden
2.4 Analyse 14
overgenomen. Het is voor adverteerders mogelijk om hun doelgroep te bereiken door de
metadata die aan hun reclame wordt gegeven correct te kiezen.
Ook heeft een reclame niet een bepaald momentum nodig eer het wordt aangeraden. Dit
nodige momentum is verlegd naar de termen in de metadata. Het momentum van deze
termen zal ook veel rapper bereikt worden omdat enerzijds ook impliciete profilering van
de gebruiker wordt gedaan en dus geen interactie vereist is om een term op te nemen.
Anderzijds zal de reclame die enkele nieuwe termen bevat op basis van de reeds bestaande
termen al aangeraden worden. De nieuwe termen hebben dus een betere blootstelling
aangezien de reclame zowel in het stuk random reclame als gepersonaliseerde reclame
terecht komt. Een deel random reclames binnen het reclameblok blijft nodig om reclames
met enkel nieuwe termen in de metadata de nodige blootstelling te geven. Deze situatie
doet zich bijvoorbeeld voor bij een redelijk jong gebruikers profiel.
Tot slot behaalt TV3P een hogere recall ratio. In feite slaagt het TV3P algoritme er in
om een recall ratio van 100% te behalen [1], dit gaat echter ten koste van de precision.
precision = aantal hitsaantal items aangeraden
Hierbij is het aantal items aangeraden te interpreteren als het aantal reclames dat wordt
afgespeeld. De precision drukt uit hoeveel items correct aangeraden worden. Of in geval
van reclames hoeveel relevante reclames zitten in een reclame blok. Beide scores conflic-
teren met elkaar, er kan een hogere precisie behaald worden door de aanradings threshold
te verhogen, echter dit zorgt ervoor dat niet alles wat relevant voor een gebruiker is ook
zo herkend wordt, de recall ratio daalt. In ieder geval heeft het TV3P algoritme een hoge
precision (60%-100%) ongeacht de recall ratio, indien het profiel consistent is met wat
de gebruiker wil. Is dit niet zo dan haalt het TV3P algoritme gemiddeld 40% precision,
ongeacht de recall ratio.
2.4.2 Schaalbaarheid en complexiteit
Collaborative Filtering
User based collaborative filtering kampt het meest met schaalbaarheid problemen. Voor
elke gebruiker moeten k gelijkaardige gebruikers gevonden worden, hiervoor moet de vol-
ledige matrix R doorlopen worden. Dit moet elke keer reclame afgespeeld wordt, herhaald
2.4 Analyse 15
worden aangezien ondertussen het profiel van de gebruiker of de matrix R veranderd kan
zijn en bijgevolg een betere reclameblok kan samengesteld worden. De complexiteit per
gebruiker per reclameblok is O(mn) +O(km) (met n de het aantal rijen en m het aantal
kolommen in matrix R) aangezien de gebruiker met n − 1 gebruikers wordt vergeleken
en elke vergelijking is n operaties. Vervolgens worden uit de k gebruikers nog de meest
voorkomende items gehaald, dit geeft aanleiding tot de tweede term. Het is duidelijk dat
de meest doorslaggevende parameter n is. In een worst case scenario zal een reclame-
blok tegelijk aan alle bestaande gebruikers moeten gestuurd worden, de complexiteit is
dan O(mn2) +O(kmn). Aangezien het aantal gebruikers dat gelijktijdig een reclameblok
moet krijgen in de miljoenen kan liggen, wordt dit probleem aanzienlijk. Hieraan kan
tegemoet gekomen worden door clustering van de gebruikers en door het rekenwerk te
distribueren over meerdere servers.
Item based collaborative filtering is beter schaalbaar doordat de relaties tussen items
op voorhand berekend worden. De complexiteit van het berekenen van deze relaties is
O(m2n) (er worden m(m−1) reclames met elkaar vergeleken, elke vergelijking is n opera-
ties). Het grote voordeel is dat deze berekening niet bij elke reclameblok en elke gebruiker
moet gebeuren. Dit kan gebeuren op tijdstippen wanneer er weinig mensen TV kijken.
Om een reclameblok voor gebruiker V samen te stellen, zal een complexiteit van O(k‖V ‖)gelden. Aangezien per reclame die in vector V een 1 heeft de k meest gelijkaardige items
worden opgehaald en gesommeerd, wat k operaties oplevert. In een worst case scenario
zal een reclameblok tegelijk aan alle bestaande gebruikers moeten gestuurd worden, de
complexiteit is dan O(kmn). Hierbij werd uitgegaan dat elke gebruiker een profiel met
enkel enen in heeft, wat niet logisch is maar toch een bovengrens van complexiteit geeft.
Item based collaborative filtering is in het worst case geval een factor n beter. Het zal
bijgevolg meer schaalbaar zijn dan user based.
TV3P Algoritme
Het TV3P algoritme is opgesplitst in twee delen. Eerst wordt het profileren van een ge-
bruiker bekeken. Per reclame zal per term in het profiel van de reclame gezocht worden
of deze al in het profiel zit, vervolgens wordt de waarde van term ofwel geupdate, ofwel
wordt de term met een waarde hoger dan de opgegeven threshold toegevoegd. In ieder
geval vraagt het berekenen van de waarde van een term een elftal operaties. De com-
2.5 Inpassing TV3P in DSL netwerk 16
plexiteit wordt beïnvloedt door de lengte van het profiel van de reclame (LRecl) en dat
van de gebruiker (LGebr). De complexiteit is dan O(LReclLGebr). Dit is per reclame. Het
profileren van een gebruiker is echter niet heel tijd kritisch, dit kan bijvoorbeeld in de
achtergrond gebeuren terwijl een programma lopende is.
Bij het samenstellen van een reclameblok worden uit het profiel van een gebruiker de top-N
waarden gehaald en deze worden per reclame met het profiel van die reclame vergeleken.
De complexiteit hiervan is O(N LRecl) Dit moet gebeuren voor alle reclames dus wordt de
complexiteit van het samenstellen van een reclameblok voor een gebruiker O(N LRecl m)
(met eenzelfde aantal reclames als voor collaborative filtering) In het worst case scenario
waarbij alle gebruikers tegelijk een reclameblok nodig hebben is dit O(N LRecl m n).
Aangezien vooral n de doorslaggevende factor hierin is zal de complexiteit vergelijkbaar
zijn met deze van item based collaborative filtering.
2.4.3 Keuze
Er wordt gekozen voor het TV3P algoritme verder uit te werken. Het TV3P algoritme
levert een hogere kwaliteit ten opzichte van beide collaborative filtering algoritmen. Daar-
enboven is de schaalbaarheid en complexiteit ten opzichte van item based collaborative
filtering vergelijkbaar.
2.5 Inpassing TV3P in DSL netwerk
2.5.1 Profilering gebruiker
Het is voor de hand liggend dat de profilering van de gebruiker op de STB gebeurt. Op de
STB is namelijk alle informatie aanwezig dat het profileringsalgoritme nodig heeft. Het
is ook ontworpen om op een STB te werken. De vraag die gesteld kan worden is wat de
toegevoegde waarde is van de profilering elders in het netwerk te doen.
In het kernnetwerk profilering uitvoeren kan een toegevoegde waarde hebben indien de
profielen kunnen ingekeken worden, bijvoorbeeld voor marktonderzoek. Echter aangezien
miljoenen kijkers tegelijkertijd reclames kunnen krijgen en de profilering gebeurt op het
kijkgedrag ten opzichte van deze specifieke reclames (interactie, wegzappen, niets doen)
wordt deze oplossing al rap te complex.
2.5 Inpassing TV3P in DSL netwerk 17
De toegevoegde waarde van de gebruikers te profileren op een BNG of een DSLAM kan
zijn dat dit samen gebeurt met het selecteren van reclames. Waarna enkel nog de reclames
uitgezonden worden naar de juiste gebruikers. Dit zorgt ervoor dat geen profielen moeten
uitgewisseld worden. Dit vergt echter dat de DSLAM of BNG het gedrag van de gebruiker
in de gaten houden. In tegenstelling tot in het kernnetwerk “weet” de DSLAM of BNG niet
wanneer een gebruiker interageert of wegzapt. Deze zien enkel de datastromen veranderen
en zouden ze daarenboven moeten interpreteren. Dit creëert een overhead.
De toegevoegde waarde van profilering op de STB uit te voeren blijft dat gebruik wordt
gemaakt van de gedistribueerde rekenkracht zonder veel overhead noch een hoge com-
plexiteit.
2.5.2 Reclame personaliseren
Dit kan gebeuren op meerdere locaties binnen het DSL netwerk. Op de DSLAM, BNG of
in het kernnetwerk. Er moet echter rekening gehouden worden met de schaalbaarheid.
Wanneer het personaliseren van reclame gebeurt in het kernnetwerk dan moet dit voorzien
zijn om, in een worst case scenario, alle gebruikers tegelijkertijd van een reclameblok te
voorzien. Dit is echter geen schaalbare oplossing. Hoe meer gebruikers hoe hoger de
vereisten in het kernnetwerk.
Wordt het personaliseren van reclame dichter bij de gebruiker gedaan, dit is op de BNG
of DSLAM, dan verandert het verhaal. Per BNG of DSLAM is er een vast maximum
aantal gebruikers. Als er gebruikers bijkomen waardoor het netwerk uitgebreid moet
worden dan schaalt het algoritme mee. Voor de schaalbaarheid is dit een interessante
oplossing. In deze oplossing is er echter een bijkomend probleem. Aangezien de reclames
reeds aanwezig zijn in het kernnetwerk, daar bevinden zich namelijk de content providers,
is het eenvoudig om daar reclameblokken te personaliseren. In deze oplossing moeten
de nodige reclames zich op de BNG of DSLAM bevinden. Er is bijgevolg een transport
van reclames naar de BNG’s of DSLAM’s nodig. Dit transport kan gebeuren aan de
hand van een data carousel, welke wordt gemulticast naar alle BNG’s of DSLAM’s vanuit
het kernnetwerk. In deze data carousel worden dan de reclames samen met hun profiel
gestuurd. Aangezien de gebruikers hun profielen zullen uploaden naar de BNG of DSLAM
kan deze uit de data carousel de reclames halen die nuttig zijn voor ’zijn’ gebruikers. Als
2.5 Inpassing TV3P in DSL netwerk 18
de profielen in de data carousel los van de reclames worden verstuurd op tijdstippen
waarop weinig dataverkeer is kan de vrije rekenkracht benut worden voor de keuze van
reclames. Op de andere tijdstippen moet de DSLAM of BNG dan enkel nog de juiste data
pakketten uit de data carousel halen. Er rest nog de keuze tussen de DSLAM en de BNG.
Aangezien de DSLAM veel minder gebruikers heeft dan een BNG is het interessanter om
hier de reclame te personaliseren. Naast de directe impact van het aantal gebruikers op
de complexiteit, zal dit ook het aantal reclames beïnvloeden. Immers de reclames die
uit de data carousel gehaald worden zullen gericht zijn op een kleinere groep gebruikers.
Hierdoor houden de DSLAM’s een kleinere subset van reclames over en moet er minder
rekenwerk verricht worden bij het samenstellen van een reclameblok. Met andere woorden
beide factoren m en n in de complexiteit worden gereduceerd. Het enige nadeel is dat de
data carousel tot aan de DSLAM gemulticast dient te worden.
PROOF OF CONCEPT 19
Hoofdstuk 3
Proof of concept
3.1 Opstelling
In de proof of concept wordt het TV3P algoritme geïmplementeerd in een test opstelling.
Hierbij werd de keuze gemaakt om in Java te programmeren. Origineel was het plan om
een echte STB te gebruiken. Dit bleek echter niet mogelijk door de beperkte ondersteu-
ning van Java op de huidige DSL set-top boxen. De STB werd vervangen door een PC.
Ook de extra functionaliteit op de DSLAM werd op een PC geïmplementeerd. In feite zijn
DSLAM’s layer 2 switchen en vraagt de implementatie van het TV3P algoritme volledig
layer 7 functionaliteit. Hiermee werd geen rekening gehouden in de proof of concept. In
de proof of concept wordt ook de data carousel die reclames vanuit het kernnetwerk naar
de DSLAM’s brengt achterwege gelaten. De hoog niveau architectuur is weer te vinden op
figuur 3.1. Hierop zijn de belangrijkste componenten te zien. De architectuur is symme-
Figuur 3.1: Hoog niveau architectuur van de Proof of Concept
3.2 STB 20
trisch. Het profielbeheer zal op de STB de profielen van de meerdere gebruikers beheren
en updaten. Op de DSLAM zal dit enkel de profielen van op alle STB’s beheren. Het
reclamebeheer op de DSLAM zal de reclames beheren en klaarzetten voor de gebruikers.
Op de STB worden ook reclames opgeslagen. De communicatie zorgt voor de uitwisseling
van profielen, reclames en controle boodschappen. In de volgende delen bekijken we de
STB en DSLAM naderbij.
3.2 STB
Figuur 3.2: Package diagram van de STB
In figuur 3.2 wordt de STB meer in detail weergegeven. In de volgende delen wordt
dieper ingegaan op de verschillende packages in dit package diagram. Hierbij komen
echter de packages “beans” en extra in functie van reclamebeheer en profielbeheer voor.
De package “beans” biedt enkel datastructuren voor reclames, profielen en gebruikers in
de vorm van entity beans. Ook bevat deze package klassen die voor deze beans de toegang
tot de databank beheren. De package extra bevat enkele datastructuren die nodig waren
in de algoritmen en de klasse matrix van JAMA[10] om matrix bewerkingen te doen.
3.2 STB 21
3.2.1 Reclamebeheer
Figuur 3.3: Package reclamebeheer op de STB en verband met package communicatie
De structuur van de package reclamebeheer en de relatie met de communicatie package is
te zien op figuur 3.3. Voor dit te ontleden wordt eerst bekeken hoe reclame wordt voorge-
steld in de proof of concept. Hierna volgen de klassen ReclameBeheer en ReclameSpeler.
Reclame
In de proof of concept heeft reclame een structuur zoals in figuur 3.4 wordt weergegeven.
Een ReclameProfiel bevat de metadata van een reclame. Deze is gebaseerd op de metadata
voor een TV programma beschreven in het TV3P algoritme[?]. De vergelijking tussen de
verschillende categorieën wordt gemaakt in tabel 3.1.
TV programma Reclame
Titel Merk en Product
Genre Beschrijving
Kernwoorden en Acteurs Kernwoorden
Tabel 3.1: Vergelijking tussen het profiel van reclame en dat van TV programma’s
3.2 STB 22
Figuur 3.4: Reclames in de Proof of Concept
De redenering achter het gebruik van Product en Merk als Titel is dat dit een bepaald
product definieert net zoals een titel. Het genre van een film beschrijft de inhoud in
grote lijnen, daarom is naar analogie een categorie beschrijving toegevoegd. Dit zou enkel
gebruikt mogen worden voor de beschrijving van het product. Vervolgens is de categorie
Acteurs bij Kernwoorden toegevoegd aangezien deze categorie van minder groot belang is
in reclames. Het is uiteraard aan de adverteerder om deze termen in te vullen. Wil deze
meer nadruk leggen op het belang van de Acteur kan deze altijd gepromoveerd worden
naar de categorie Beschrijving. Om aan de adverteerder nog extra vrijheid te geven zal
deze per reclame zelf de gewichten (zie sectie ??) kunnen instellen. Zo is het mogelijk dat
een adverteerder minder de nadruk legt op zijn merknaam dan op zijn product of meer
op de beschrijving.
Het ReclameProfiel wordt vervolgens opgenomen in de klasse Reclame. In deze klasse
wordt extra vaste informatie toegevoegd. De bestandsnaam, de duur van de reclame
en een boolean die uitdrukt of deze reclame mag onderworpen worden aan profilering.
Dit laatste is toegevoegd om de adverteerders de keuze te laten of de reclame wordt
geprofileerd. Dit laat ook toe aan de uitbater van het netwerk om hieraan een business
3.2 STB 23
model te koppelen waarin verschillende prijzen worden gevraagd voor gepersonaliseerde
reclames. De reden waarom deze informatie niet opgenomen werd in het ReclameProfiel is
dat verschillende reclames mogelijk zijn voor eenzelfde product en bijgevolg voor eenzelfde
profiel. Profielen kunnen hergebruikt worden.
Ten slotte wordt de Reclame opgenomen in de klasse ReclameBean. Deze bean is een
entity bean en wordt gebruikt voor persistentie. Ook hier wordt extra informatie toe-
gevoegd, op de versheidsdatum na is dit informatie die tijdens het uitvoeren aangepast
wordt. De versheidsdatum is een variabele die ingesteld kan worden door de adverteerder
en deze drukt uit tot welke datum de reclame actief mag zijn in het netwerk.
ReclameBeheer
In figuur 3.3 wordt de klasse ReclameBeheer weergegeven en de relatie met de package
communicatie. De taak van ReclameBeheer is de reclames die zich lokaal op de STB bevin-
den te personaliseren. Dit voor de gebruiker die op dat moment actief is. ReclameBeheer
wordt aangestuurd door input van communicatie.STB1. Als er van gebruiker veranderd
wordt of reclames toekomen van de DSLAM dan zal dit via communicatie.STB gebeuren.
Deze geeft die informatie door aan ReclameBeheer. Ook het ophalen van reclames voor
een reclameblok gebeurt door communicatie.STB.
Om reclames te personaliseren wordt gebruik gemaakt van het algoritme beschreven in
sectie 2.3.2. Dit algoritme wordt gebruikt om de ids bij te houden van de reclames die
interessant zijn voor de gebruiker, dit zijn gepersonaliseerde reclames. Tegelijkertijd wordt
een lijst bijgehouden van de ids van de reclames die dit niet zijn, dit zijn random reclames.
Er wordt maar een gedeelte van de reclames in een reclameblok gepersonaliseerd. In
eerste instantie zijn er een aantal verplichte reclames die niet gepersonaliseerd worden.
Daarnaast worden ook een aantal van de random reclames afgespeeld. Deze random
reclames zijn bedoeld om blootstelling te geven aan andere reclames en dus ook andere
termen.
Als gevraagd wordt om een reclameblok te geven, dan wordt dit gedaan door reclames-
VoorUser(...) op te roepen met de parameters aantalVrij en aantalVerplicht (deze bepalen1Om verwarring te vermijden met de set-top box (STB) wordt naar de klasse STB uit de package
communicatie verwezen met communicatie.STB
3.2 STB 24
het aantal vrije en verplichte reclames). Het aantal vrije reclames bevat niet een vast aan-
tal gepersonaliseerde reclames, dit zal ook voor een deel bestaan uit random reclames. De
verhouding wordt bepaald door het aantal reclames die gepersonaliseerd kunnen worden
op het totaal aantal reclames. De idee is dat als er weinig reclames kunnen gepersonali-
seerd worden er beter meer random reclames worden afgespeeld. Om een minimum aantal
random reclames te garanderen is een parameter maxVerhouding ingevoerd. Dit is het
maximum aantal gepersonaliseerde reclames ten opzichte van random reclames.
Nog een belangrijke aanpassing aan het TV3P algoritme is dat niet alleen de reclames
worden gesorteerd op hoe hoog ze scoren, er wordt ook rekening gehouden met het aantal
keer ze zijn afgespeeld. Het huidige algoritme dat hiervoor wordt gebruikt, deelt de scores
van de reclames door het aantal keer gespeeld en sorteert dit op afnemende volgorde.
Vervolgens worden de reclames uit het begin van deze lijst gehaald.
Tot slot wordt nog opgemerkt dat in de proof of concept alle reclames een vaste duur
hebben. Dit werd zo gekozen om het samenstellen en afspelen van reclames te vereenvou-
digen.
ReclameSpeler
In figuur 3.3 wordt ook de klasse ReclameSpeler weergegeven en de relatie met de package
communicatie. Aangezien de reclame zich bevindt op de STB is er maar één ReclameSpe-
ler nodig voor alle kanalen. Deze reclamespeler zal het gedrag simuleren dat de kijkers
gewoon zijn geworden. Wanneer een gebruiker wegzapt en op een andere reclameblok
uitkomt dan zal de huidige reclame ook moeten veranderen.
De ReclameSpeler thread wordt gestart door communicatie.STB wanneer deze het signaal
krijgt dat een reclameblok gespeeld moet worden. Bij het starten worden via communi-
catie.STB reclames opgevraagd aan ReclameBeheer. Na het uitspelen van een reclame
wordt dit gesignaleerd aan communicatie.STB.
3.2 STB 25
3.2.2 Profielbeheer
Figuur 3.5: Package profielbeheer en verband met de package communicatie
De structuur van de package profielbeheer en de relatie met de communicatie package is te
zien op figuur 3.5. Eerst wordt het profiel naderbij bekeken, vervolgens het ProfielBeheer
en de Profilering.
Profiel
Het profiel is zoals in het TV3P algoritme [?] beschreven een lijst van termen en waarden.
Deze zijn opgenomen in een LinkedHashMap<String,Double>. In het algoritme is er
nood aan een lijst gesorteerd op volgorde van de waarden. Er is bijgevolg een TreeMap
nodig, echter in een TreeMap wordt gesorteerd op de Keys en niet op de Values (aangezien
deze niet uniek zijn). Dit kan opgelost worden door de String en Double te combineren
3.2 STB 26
Figuur 3.6: Profielen in de Proof of Concept
in een klasse die de Comparable interface implementeert. Door een gepaste compareTo
functie te definiëren worden StringDouble’s eerst gesorteerd op Double en vervolgens op
String. Een andere mogelijkheid was om een TreeSet te gebruiken, echter het is veel
handiger om de Double’s gesorteerd uit de TreeMap te halen via .values() in vergelijking
met een lus die over de TreeSet<StringDouble> itereert. De LinkedHashMap is hierdoor
niet overbodig geworden, deze is nodig om bij een edit een oude StringDouble te vinden
en deze te verwijderen.
Het Profiel wordt opgenomen in een entity bean klasse UserBean. Op een STB kunnen er
meerdere UserBean’s aanwezig zijn, er is alleszins op zijn minst een user met een default
profiel. De UserBean klasse voegt nog extra informatie toe. Het tijdstip van aanmaak
en laatst aangepast, dit laat toe om in de DSLAM te controleren op de leeftijd van de
actieve profielen en eventueel om een update te vragen. Voor de gebruikers is er een naam
voorzien die ze aan hun profiel kunnen geven. Er wordt niet gecontroleerd op uniciteit
van deze naam. De stbid is de id van de STB, dit is nodig om een unieke sleutel te vormen
samen met de id.
ProfielBeheer
Het ProfielBeheer houdt een lijst bij van alle profielen op de STB en verzorgt de commu-
nicatie met de databank en met profilering. Deze klasse is een facade klasse, er valt dus
3.2 STB 27
weinig over te zeggen.
Profilering
De klasse Profilering implementeert het profileren gedeelte van het TV3P algoritme (zie
sectie 2.3.2. Het wijkt echter af bij de expliciete profilering. In de proof of concept worden
andere delta’s gebruikt ten opzichte van het TV3P algoritme. (zie tabel 3.2)
TV3P Proof of concept
Positieve interactie ∆wi = 2 2
Geen interactie ∆wi = 1 0
Wegzappen ∆wi = -2 -1
Tabel 3.2: Vergelijking gebruikte ∆wi tov TV3P
Aangezien een reclame uitkijken minder significant is vergeleken met een TV programma
uitkijken zetten we ∆wi op 0. Analoog is de negatieve interactie minder significant,
reclames worden nu eenmaal rapper weggezapt ongeacht de inhoud, hiervoor nemen we
dan -1. De overige parameters zijn instelbaar.
Elke keer dat de reclamespeler signaleert aan communicatie.STB dat een reclame is uitge-
speeld wordt dit gesignaleerd aan profilering via ProfielBeheer. Eerst wordt gekeken of er
werd geïnterageerd met deze reclame of niet. Dit wordt opgeslagen in de huidige reclame
aan de hand van een boolean. Als een gebruiker wegzapt zal dit onderschept worden in
communicatie.STB en eveneens gesignaleerd worden. Ook nu wordt gecontroleerd of er
interactie gebeurde, in dat geval wordt voorrang gegeven aan interactie, de reclame zal
niet afgehandeld worden alsof weggezapt werd.
De profilering bij een interactie wordt in de code als volgt gedaan:
UserBean i n t e r a c t i e (ReclameBean current , UserBean c u r r e n tP r o f i e l ) {
P r o f i e l u s e rP r o f i e l = cu r r e n tP r o f i e l . g e tP r o f i e l ( ) ;
g roo t t e = (double ) u s e rP r o f i e l . g e tS i z e ( ) ;
k i j kT i j d = ( (double ) cur r ent . getReclame ( ) . getGespee ld ( ) )
/ ( (double ) cur r ent . getReclame ( ) . getDuur ( ) ) ;
indexFactor = null ;
nieuwGewicht = null ;
3.2 STB 28
gewicht = null ;
for ( S t r ing term : cur rent . getReclame ( ) . g e tP r o f i e l ( )
. getStr ingsEnGewichten ( ) . keySet ( ) ) {
i f ( u s e rP r o f i e l . conta in s ( term )){
indexFactor = ( g roo t t e − (double ) ( u s e rP r o f i e l . indexOf ( term ,
u s e rP r o f i e l . g e tS i z e ( ) ) ) ) / g roo t t e ;
nieuwGewicht = (1−alpha )∗ u s e rP r o f i e l . getWeight ( term )
+alpha ∗ k i j kT i j d ∗ indexFactor ∗ gew i ch t Imp l i c i e t
+alpha ∗ d e l t a I n t e r a c t i e ∗ gew i ch tExp l i c i e t ;
u s e rP r o f i e l . e d i t ( term , nieuwGewicht ) ;
} else {
gewicht = alpha ∗ k i j kT i j d ∗ de fau l t IndexFactor ∗ gew i ch t Imp l i c i e t
+alpha ∗ d e l t a I n t e r a c t i e ∗ gew i ch tExp l i c i e t ;
i f ( gewicht >= aanvaardingsThreshold ){
u s e rP r o f i e l . e d i t ( term , gewicht ) ;
}
}
}
c u r r e n tP r o f i e l . s e t P r o f i e l ( u s e rP r o f i e l ) ;
u s e rP r o f i e l = null ;
return c u r r e n tP r o f i e l ;
}
3.2 STB 29
3.2.3 Communicatie
Figuur 3.7: Package communicatie
Ook dit deel begint met een entity bean te vermelden, vervolgens wordt de communicatie
package nader bekeken.
STBBean
De STBBean is de laatste entity bean uit de beans package. Per STB is er een enkele
STBBean. Deze klasse houdt informatie bij over de STB die vooral van belang is voor de
Figuur 3.8: STBBean
3.2 STB 30
DSLAM. De DSLAM heeft het IP address en de poort nodig om een connectie met de
STB op te zetten. Verder houdt de STBBean een lijst bij van alle reclames die op de STB
aanwezig zijn. Dit laat toe dat de DSLAM deze reclames niet in rekening brengt wanneer
deze reclames selecteert om naar de STB te sturen.
STB
In de package communicatie bevinden zich drie interfaces. De DSLAMInterface is de RMI
interface die aangeboden wordt door de RMI server op de DSLAM. De STBInterface is
de RMI interface die aangeboden wordt aan de DSLAM door de RMI server op de STB.
Ten slotte is de LocalInterface een interface die lokaal gebruikt wordt.
De klasse STB is het zenuwcentrum van de STB. Deze klasse zorgt enerzijds voor com-
municatie tussen de STB en de DSLAM en anderzijds communicatie tussen verschillende
packages en klassen. Deze klasse heeft dan ook referenties naar al deze verschillende
klassen.
In de communicatie met DSLAM wordt ervan uitgegaan dat de STB het IP-address en
poort van de DSLAM weet. Bij het opstarten zal de STB zich altijd bij de DSLAM
identificeren met zijn STBBean en het default profiel via de login functie. Wordt voor
de eerste keer opgestart dan zal STB een STBBean aanmaken en deze registreren bij
de DSLAM. Bij dit registreren krijgt STB een id toegewezen, eens de id ontvangen is,
wordt de STBBean weggeschreven naar de databank. Vervolgens wordt het default profiel
geregistreerd op dezelfde manier. Ook elk ander profiel dat wordt aangemaakt wordt op
deze manier geregistreerd. Nu dat een STBBean en een profiel bestaan, kan er ingelogd
worden. Verder biedt de DSLAM een functie aan om een kanaal op te vragen en om de
STBBean te updaten, dit laatste is nodig om de DSLAM up-to-date te houden over welke
reclames aanwezig zijn op de STB.
Bij het opvragen van een kanaal zal STB eerst een check doen of de reclamespeler niet
actief is. Indien dit zo is dan wordt deze beëindigd en wordt de laatste reclame geprofileerd
als zijnde weggezapt. Ook wordt bij het opvragen van een kanaal de ID van het actieve
profiel meegestuurd zodanig dat de DSLAM weet wie naar welke reclame kijkt. Enkel de
ID wordt doorgestuurd aangezien een UserBean vele malen groter is en het niet nuttig is
om dit elke keer als gezapt wordt door te sturen.
3.2 STB 31
De DSLAM kan de profielen up-to-date houden door ze op te vragen via de STBInterface.
Dit geeft ook flexibiliteit aan de DSLAM om dit te schedulen. De STBInterface wordt
ook gebruikt om tekst te printen naar de display van de STB, reclames toe te voegen
aan het reclamebeheer en te signaleren dat een reclameblok moet beginnen. Wanneer
reclame gesignaleerd wordt moet opgelet worden dat de reclamespeler niet een tweede
keer wordt gestart. Het is mogelijk dat een kijker net weggezapt heeft maar naar een
andere reclameblok. In dit geval is het mogelijk dat de reclame speler nog actief is,
dit wordt uitgebuit door op de reclame speler de functie veranderKanaal op te roepen.
Hierdoor herbegint de reclame speler.
3.2.4 Package stb
Deze laatste package op de STB verzorgt een kleine GUI die het beeldscherm van een
TV moet simuleren. Er zijn vijf kanalen voorzien om uit te kiezen. Een kanaal wordt
weergegeven door elke vijf seconden een timestamp en het kanaal af te drukken. Ook
reclames afgespeeld door de reclame speler worden zo weergegeven. Tijdens het afspelen
van een reclame kan “geinterageerd” worden via een klik op de knop. Verder is het mogelijk
om het profiel van de gebruiker weer te geven. De mogelijkheid bestaat ook om meerdere
profielen aan te maken, te verwijderen en actief te zetten. Tot slot kan deze GUI de
parameters die gebruikt worden in het TV3P algoritme instellen.
Figuur 3.9: GUI
3.3 DSLAM 32
3.3 DSLAM
Figuur 3.10: Package diagram van de DSLAM
Door de symmetrische structuur van de DSLAM en de STB is de functionaliteit binnen
de DSLAM gelijkaardig. Er zijn toch een aantal accenten die anders gelegd worden.
3.3.1 Kanalen
Figuur 3.11: Package kanalen op de DSLAM
In een Kanaal wordt via communicatie.DSLAM naar alle gebruikers die kijken een
timestamp en het kanaal id om de vijf seconden gestuurd. Hiervoor wordt bijgehouden
welke gebruikers kijken. Het kanaal zal op het einde van de vorige reclame blok aan
3.3 DSLAM 33
communicatie.DSLAM laten weten wanneer de volgende reclameblok komt. Het aantal
vrije en verplichte reclames wordt ook door het kanaal bepaald.
De taak van de klasse Simulator is enkel een array van vijf kanalen te managen.
3.3.2 Communicatie
Figuur 3.12: Package communicatie op DSLAM
3.3 DSLAM 34
De klasse DSLAM in de package communicatie is het zenuwcentrum voor de DSLAM
zoals de klasse STB dit voor de STB was. Deze klasse implementeert de DSLAMInterface
en LocalInterface om functies aan respectievelijk de STB en lokale klassen te bieden, de
STBInterface wordt gebruikt om functies op de STB op te roepen. Ook heeft DSLAM
referenties naar verschillende klassen die aangestuurd dienen te worden. Tot zover de
gelijkenis met de STB.
Aangezien in een kanaal moet bijgehouden worden welke gebruikers momenteel kijken
en gebruikers kunnen zappen moet de klasse DSLAM bijhouden naar welk kanaal een
gebruiker aan het kijken is. Zo kan deze bij het juiste kanaal verwijderd worden en aan
een ander toegevoegd worden. Hiernaast bestaat de mogelijkheid dat bij het zappen een
gebruiker reclame moet ontvangen. Aangezien de reclamespeler op de STB staat kan niet
zomaar van kanaal veranderd worden. De klasse DSLAM zal dan ook bijhouden op welke
kanalen momenteel reclame speelt, wanneer ze gestart is en hoe lang ze duurt. Als een
gebruiker hiernaartoe zapt zal direct geantwoord worden met signalReclame(...). In dit
geval wordt ook beroep gedaan op de reclame die al lokaal op de STB aanwezig is.
Als de gebruiker normaal naar een kanaal kijkt en niet wegzapt zal de DSLAM op voorhand
reclames sturen, deze weet immers vooraf wanneer de reclame komt.
3.3 DSLAM 35
3.3.3 Reclame Beheer
Figuur 3.13: Package reclamebeheer op de DSLAM
De relatie tussen de klasse ReclameBeheer en communicatie.DSLAM is dezelfde als op de
STB. Met de ReclamePusher is er geen relatie, dit is enkel een timertask die gescheduled
wordt door de DSLAM.
ReclameBeheer
Het verschil tot de klasse ReclameBeheer op de STB is dat hier voor meerdere gebruikers
gepersonaliseerde reclame moet bepaald worden. Wanneer een gebruiker wordt toege-
voegd kan deze los van de andere gebruikers worden opgenomen. Dit vormt dus geen
schaalbaarheids probleem. Echter wanneer een enkele reclame toegevoegd of verwijderd
worden, moet geheel het algoritme opnieuw worden doorlopen aangezien deze reclame
geprofileerd dient te worden voor alle gebruikers. Als toch alle berekeningen moeten
herhaald worden is het veel interessanter om verschillende reclames tegelijkertijd toe te
voegen.
Er zit ook een verschil in de manier waarop reclameblokken worden samengesteld in de
3.3 DSLAM 36
functie reclamesVoorUser(...). Aangezien in de DSLAM de reclames nog niet afgespeeld
zijn, wordt dit niet gebruikt om reclame blokken te bepalen. Ook worden reclames die
de gebruiker al heeft ontvangen niet opgenomen in het algoritme. Heeft de gebruiker nog
geen enkele reclame ontvangen dan wordt drie maal zoveel reclame gestuurd dan nodig is.
Dit is om op de STB meer keuze te krijgen in het geval de gebruiker tijdens deze reclame
wegzapt naar een kanaal waar een reclameblok bezig is (en eventueel nog maal wegzapt
naar weer een reclameblok).
Verder wordt ook reclamesVrijBasis opgesteld. Deze bevat reclames die geen enkele term
met elkaar gemeenschappelijk hebben en wordt aangemaakt uit alle vrije reclames voor-
handen. Dit is nuttig om een leeg profiel sneller op te bouwen doordat reclames volledig
verschillen worden veel unieke termen direct opgenomen.
ReclamePusher
In plaats van een reclamespeler heeft de DSLAM een reclamepusher. Dit is een timertask
die door de DSLAM wordt gescheduled om op voorhand reclames naar de gebruikers te
sturen. Op het moment van uitvoeren zal deze de gebruikers opvragen die op dat moment
naar het kanaal kijken waarvoor de timertask is gescheduled. Hierna worden voor deze
gebruikers gepersonaliseerde reclames opgevraagd en doorgestuurd.
3.3.4 Profiel Beheer
Figuur 3.14: Profielpoller in de package profielbeheer
De package profielbeheer op de DSLAM bevat naast ProfielBeheer en Profiel ook een
profielpoller. Dit is een thread die regelmatig voor alle actieve profielen controleert of
het niet aangewezen is om een update van het profiel te vragen aan de STB. Of het
al dan niet aangewezen is om een profiel te updaten wordt bepaald uit de variabelen
aangemaakt en aangepast in de UserBean. Aangemaakt is het tijdstip waarop het profiel
3.4 Videobeelden 37
is aangemaakt en aangepast het laatste tijdstip dat er een aanpassing is gebeurt. Deze
waarden veranderen enkel in de STB. Ligt aangemaakt en aangepast dicht bij elkaar dan
betekent dit dat het profiel nog jong is en er dus meerdere updates per tijdseenheid nodig
zijn. Natuurlijk moet niet om de vijf minuten naar een update gevraagd worden. Er
moet ook nog rekening gehouden worden met het verschil tussen aangepast en de huidige
tijd. Wanneer het profiel ouder is, wordt enkel rekening gehouden met het verschil tussen
aangepast en de huidige tijd. Als het te lang geleden is sinds een update wordt een nieuwe
gevraagd.
3.4 Videobeelden
De proof of concept kan nog verbeterd worden door videobeelden toe te voegen. Hoewel
dit niet tot in de code geraakt is, wordt toch de denkoefening gemaakt.
Er wordt verwacht dat de DSLAM de kanalen simuleert door een continue videostroom
af te spelen, dit kan een film zijn die gelooped wordt. De gebruiker moet kunnen zappen
van kanaal naar kanaal. Reclame filmpjes moeten ook uitgewisseld worden en op een
ordentelijke manier afgespeeld worden.
3.4.1 JMF
JMF is een framework voor java dat toelaat om media bestanden af te spelen, om te
vormen, te streamen en te capturen.[8] Het omvormen of afspelen gebeurt zoals in figuur
Figuur 3.15: JMF: Media processing model
3.15 wordt weergegeven. Een Input komende van een file, capture of netwerk stream
3.4 Videobeelden 38
wordt verwerkt in Process. Vervolgens wordt het weergegeven (of afgespeeld) of opnieuw
omgezet naar een file of netwerk stream. De inputs worden datasources genoemd. Deze
hebben allen een MediaLocation welke via een MediaLocator of een string kan bepaald
worden. Een process dat een datasource afspeelt wordt een player genoemd. De player
heeft in het framework een eigen klasse die door de klasse Processor wordt ge-extend. Een
processor heeft alle functionaliteit van een player, en kan bovendien gebruikt worden om
de videostroom om te vormen.
Het capturen is een speciaal geval van bovenstaande. In dit geval is de datasource een
capture bron (bijvoorbeeld een camera) die dan door een player of processor zal afgespeeld
of opgeslaan of gestreamed worden.
Het streamen van media gebeurt met het Real-Time Transmission Protocol (RTP) en kan
opgesplitst worden in twee delen. Aan een zijde heeft men het opzetten van de stream aan
de hand van een datasource, weergegeven in een figuur 3.16. Aan de andere zijde wordt
de stream ontvangen, weergegeven in figuur 3.17. Zoals te zien in beide figuren wordt
een RTP Session aangestuurd door een Session Manager. Deze Session Manager houdt
bij welke streams en participanten zich in de RTP Session bevinden. Een participant kan
actief en passief zijn. Actieve participanten sturen Real-Time Control Protocol (RTCP)
controle berichten en RTP data, passieve participanten sturen enkel controle berichten. De
Session manager heeft methoden om een RTP sessie te initialiseren en er in te participeren,
individuele streams uit een sessie te verwijderen en de sessie af te sluiten.
Figuur 3.16: Opzetten van een stream
Tot slot van deze korte weergave van JMF wordt vermeld dat de standaard JMF enkel
een beperkt aantal bestandsformaten ondersteunt. Dit kan echter aanzienlijk uitgebreid
worden door gebruik te maken van FOBS4JMF[9]. Dit is een uitbreiding op JMF die
een wrapper is voor de ffmpeg library. FOBS4JMF kan bijgevolg elke file afspelen welke
3.4 Videobeelden 39
Figuur 3.17: Ontvangen van een stream
kan afgespeeld worden door de ffmpeg, op een platform dat door ffmpeg ondersteunt
wordt. Dit geeft ondermeer ondersteuning voor xvid en h264 bestanden. Echter voor
RTP transmissie blijkt deze support (nog) niet te bestaan.
3.4.2 Reclames uitwisselen en afspelen
Reclames afspelen met JMF is niet ingewikkeld als de locatie op de harde schijf van
reclame filmpjes bekend is. Aangezien dit kan bijgehouden worden in de klasse Reclame
in de variabele bestandsNaam is dit gemakkelijk in te passen.
JMF levert een MediaPlayer bean dit heeft alle functionaliteit van een speler, bestanden
kunnen gelooped worden, gestart, gestopt enzovoort. Na de constructor aan te roepen
moet de datasource juist gezet worden. Dit kan met het commando .setMediaLocation(...)
dat een string met als vorm “file:///C:/test.avi” als parameter neemt (om een file te
openen). Om de reclame te starten wordt .start() aangeroepen. Vooraleer de video op
het scherm te zetten echter moet de MediaPlayer gerealiseerd worden. Aangezien de
controller een RealizeCompleteEvent throwed volstaat het om een ControllerListener aan
MediaPlayer toe te voegen en bij een RealizeCompleteEvent de video toe te voegen aan
het scherm (maw op een JPanel of JFrame).
Aangezien een andere MediaPlayer voor de beeldstroom van de TV programmas zal zor-
gen, moeten deze twee MediaPlayers zich boven elkaar bevinden en veranderd worden
naargelang een programma of een reclameblok gespeeld wordt. Dit is mogelijk aan de
hand van een Layered Pane in Swing.
Om een sequentie reclames aan elkaar te zetten wordt opnieuw de ControllerListener
gebruikt. Als een reclame stopt doordat ze uitspeelt, wordt er een EndOfMediaEvent
gethrowed. Door dit op te vangen en vervolgens de nodige acties te ondernemen zoals de
3.4 Videobeelden 40
MediaLocation verzetten, is het mogelijk de volgende reclame te starten.
Ook het controleren van deze speler in de moeilijkere gevallen waarbij weggezapt wordt
van een reclameblok naar een reclameblok of naar een ander kanaal moet opgevangen
kunnen worden. Wanneer weggezapt wordt, wordt de functie stop() van MediaPlayer
aangeroepen. Nu wordt ofwel een signalReclame boodschap ontvangen of niet. Indien
niet wordt de programma MediaPlayer bovenaan geplaatst. Indien wel een signalReclame
ontvangen wordt, wordt de reclame MediaPlayer bovenop geplaatst en opnieuw gestart.
De moeilijkheid zit in het uitwisselen van de reclames. Er zou via sockets gewerkt kun-
nen worden, maar voor grote files geeft dit op java problemen. Een mogelijke oplossing
hiervoor is misschien om een FTP server te plaatsen op de DSLAM. De reclame beans
worden zoals nu gepushed naar de STBs. Hierop halen de STBs deze files op bij de FTP
server.
3.4.3 Streamen video
Het streamen van video gebeurt in JMF via RTP. De bestandsformaten die door JMF2.1.1
ondersteund worden zijn weergegeven in tabel 3.32 [11]2 * JPEG/RTP can only be transmitted in video dimensions that are in multiple of 8 pixels.
** H.263/RTP can only be transmitted in 3 different video dimensions: SQCIF (128x96), QCIF (176x144)
and CIF (352x288).
*** MPEG/RTP video can only be transmitted from pre-encoded MPEG content, i.e. from an MPEG-
encoded file or MPEG enabled capture source. Real-time software MPEG encoding is not feasible for
RTP transmission.
3.4 Videobeelden 41
Media Type RTP Payload Cross Platform Solaris/Linux Windows
Version Performance Pack Performance Pack
Audio: G.711 (U-law) 8 kHz 0 R,T R,T R,T
Audio: GSM mono 3 R,T R,T R,T
Audio: G.723 mono 4 R R,T R,T
Audio: 4-bit mono DVI 8 kHz 5 R,T R,T R,T
Audio: 4-bit mono DVI 11.025 kHz 16 R,T R,T R,T
Audio: 4-bit mono DVI 22.05 kHz 17 R,T R,T R,T
Audio: MPEG Layer I, II 14 R,T R,T R,T
Video: JPEG (420, 422, 444)* 26 R R,T R,T
Video: H.261 31 - R R
Video: H.263** 34 Mode A Only R,T R,T
Video: MPEG-I*** 32 T R,T R,T
Tabel 3.3: Ondersteunde media formaten voor RTP
Deze functionaliteit zou moeten komen in de package kanalen. Er gelden volgende vereis-
ten:
• De video stroom moet gepushed worden naar de gebruikers.
• Reclameblokken moeten gesimuleerd worden, tijdens een reclameblok staat het beeld
stil.
• Meerdere gebruikers moeten tegelijkertijd naar eenzelfde stroom kunnen kijken.
• Ook als niemand kijkt moet het kanaal verder afspelen.
JMF biedt Push en Pull Data-Sources, bij een Pull Data-Source is het de gebruiker die
de videostroom initieert en de data flow controleert, bij een Push Data-Source wordt dit
gedaan door de server. Uit de eerste eis volgt dat een Push Data-Source zal nodig zijn.
De tweede eis kan opgelost worden door de bestaande code te hergebruiken. In plaats
van een tijd te stoppen met het kanaal te printen via java rmi wordt op dat moment de
videostroom gepauzeerd.
De derde eis is mogelijk op te lossen door een Cloneable Data-Source te gebruiken. JMF
heeft namelijk ook een aantal Specialty Data-Sources. De Cloneable Data-Source is daar
een van. Dit laat toe om van een datasource te clonen via de createClone methode.
Wanneer methodes zoals start en stop op de originele datasource wordt uitgevoerd worden
dit gepropageerd naar alle clonen hiervan. Met andere woorden de clonen volgen het
3.4 Videobeelden 42
gedrag van het origineel. Dit zal gecombineerd met de eerste eis aanleiding geven tot een
Cloneable Push Data-Soource. Per gebruiker wordt een kloon gemaakt, deze kloon wordt
vervolgens via unicast elke met een eigen RTP Session naar de gebruiker gepushed.
Een andere mogelijkheid om de derde eis op te lossen is met behulp van de Session
Manager gebruikers toe te voegen aan de RTP Session en te verwijderen en in multicast
de datasource te pushen.
De vierde eis is mogelijk op te lossen door altijd te streamen naar een dummy. Deze
dummy zou bijvoorbeeld de DSLAM zelf kunen zijn.
TESTEN 43
Hoofdstuk 4
Testen
4.1 Parameter test
In deze parameter test worden volgende parameters van het TV3P algoritme getest:
• De verversingsfactor α in w′i = (1− α)wi + α∆wi
• Verhouding van de gewichten voor impliciete en expliciete feedback.
• Top-N termen die in overweging worden genomen bij het correleren van reclame aan
een gebruiker.
De eerste 2 parameters hebben een directe invloed op de opbouw van een profiel. Door
alpha te veranderen, wordt controle uitgevoerd over de snelheid waarmee een waarde
verandert. Door de verhouding van impliciete en expliciete feedback te veranderen wordt
de nadruk verlegd op interactie of het uitkijken van reclame. De laatste parameter bepaalt
hoeveel termen betrokken worden in het selecteren van gepersonaliseerde reclame. Hoe
meer termen er gebruikt worden hoe beter de geselecteerde reclames aansluiten bij het
profiel.
De vraag is welk effect deze parameters hebben op de snelheid waarmee tot een steady-
state profiel wordt gekomen.
4.1.1 Test opstellen
Om deze test te automatiseren werden reclames gegenereerd op een automatische wijze.
Hierbij moet rekening gehouden worden met volgende situaties:
4.1 Parameter test 44
• Een merk kan meerdere producten hebben.
• Een product kan meerdere merken hebben.
• Termen in beschrijving en kernwoorden kunnen tussen verschillende reclames over
lappen.
• Reclames kunnen verplicht zijn.
Om hieraan te voldoen wordt een lijst met merken, een lijst met producten en een lijst
met beschrijvingstermen en kernwoordtermen gemaakt. Deze termen zijn van de vorm
“Mxx”, “Pxx” en “BKxx” respectievelijk, hierbij is “xx” een nummer. Een reclame wordt
nu gegenereerd door at random een term uit de merken lijst te kiezen als merk, hetzelfde
wordt gedaan voor product. Vervolgens worden at random minimum twee maximum acht
termen at random uit de lijst voor beschrijvingen en kernwoorden gehaald. Deze termen
worden verdeeld over de categorieën beschrijving en kernwoord, met een verhouding 23
voor kernwoorden en 13voor beschrijvingen. De gewichten van de categorieën zijn voor
alle reclames gelijk en als volgt:
• WMerk = 1
• WProduct = 1.25
• WBeschrijving = 0.75
• WKernwoord = 0.5
Uiteindelijk wordt nog at random bepaald of deze reclame verplicht is of niet, op zo een
wijze dat gemiddeld ongeveer 25% van de reclames verplicht zijn.
Voor het testen worden 600 reclames gegenereerd uit 75 merken, 300 producten en 900
beschrijvings- en kernwoordtermen. Deze cijfers zijn zo gekozen om de gewenste over-
lappingen te creëren. Een tekortkoming is dat de kans bestaat dat een bepaald koppel
merk-product twee maal voorkomt met een volledig verschillende beschrijving en kern-
woorden.
Aangezien de bedoeling is om de snelheid tot steady-state te bepalen, moet er een manier
zijn om de steady-state uit te meten. Hiervoor wordt voorgesteld dat op regelmatige
tijdstippen het huidige profiel wordt vergeleken met de versie op het vorige tijdstip. Bij
4.1 Parameter test 45
deze vergelijking wordt gekeken naar de top-100 termen van beide profielen en wordt het
percentage dat overlapt, bepaald. Dit wordt gedaan door de overlappende termen te tellen
en dan te delen door 100. Profielen met weinig termen worden bijgevolg niet weergegeven
als in steady-state. Als het percentage overlap gedurende een aantal perioden 100% is
wil dit zeggen dat de top-100 termen niet veranderen en is het profiel in steady-state. De
top-100 termen kunnen wel altijd onderling van volgorde veranderen.
Om de interactie van de gebruiker te simuleren worden 100 termen gekozen waarop de
gebruiker ofwel wegzapt ofwel interageert (elk 50 termen). Deze termen overlappen niet.
Indien zowel een wegzap-term als een interactie-term in een reclame voorkomen zal de
interactie afhangen van welke term eerst wordt gedetecteerd.
4.1.2 Verversingsfactor α
In deze test worden alle parameters constant gehouden en varieert α van 0.1 tot 0.9 in
stappen van 0.2. De threshold om termen in het profiel te aanvaarden, beschreven in
sectie 2.3.2, wordt zo ingesteld dat termen uit een reclame enkel toegevoegd worden als
deze reclame uitgespeeld werd. Aangezien de initiële score afhankelijk is van α moet de
threshold mee variëren met α. De andere parameters worden constant gehouden:
• Gewicht expliciete feedback: 70%
• Gewicht impliciete feedback: 30%
• Top-N: 60
Om de afwijkingen als gevolg van randomizatie in te perken wordt voor elke waarde van
alpha de test twee keer uitgevoerd. Hierna werd de gemiddelde waarde genomen. De
resultaten worden weergegeven in figuur 4.1 en 4.2. In figuur 4.1 wordt de steady-state
in functie van het aantal reclames weergegeven. Hierbij stijgt de steady state heel snel
in het begin. Dit is logisch aangezien de profielen onder 100 termen zitten. Elke reclame
die uitgespeeld wordt, wordt toegevoegd en dit doet de score direct stijgen. Voor α = 0.3
stijgt de steady state score snelst en blijft even op 1.0. Echter dit is eerder te wijten aan
toeval dan aan de waarde voor α. Aangezien in het begin α veel minder doorslaggevend
is aangezien het profiel wordt opgevuld zoals hierboven beschreven.
4.1 Parameter test 46
Steady state in functie van gespeelde reclames
0,00
0,20
0,40
0,60
0,80
1,00
1,20
0,00 50,00 100,00 150,00 200,00 250,00 300,00
Gespeelde reclames
Ste
ad
y s
tate
alpha = 0,1
alpha = 0,3
alpha = 0,5
alpha = 0,7
alpha = 0,9
Figuur 4.1: Steady state in functie van het aantal reclames
De oorzaak voor de afwijking kan zijn dat door een aantal wegzap interacties er in andere
reclameblokken wordt terechtgekomen. In deze reclameblokken worden reclames uitge-
speeld zonder interactie, zoals eerder vermeldt, geeft dit aanleiding tot een stijging van
de steady-state score.
Wat tegen deze mogelijkheden spreekt is dat er weinig interacties zijn (zie figuur 4.2) en
ook relatief weinig reclames afgespeeld werden (zie figuur 4.1), toch stijgt de steady-state
score sneller.
Vermoedelijk ligt de oorzaak in het toevoegen van een aantal reclames met veel termen.
Doordat er meer termen zijn wordt sneller naar de steady state score van 1.0 toegewerkt.
Dat deze score hier ook even blijft hangen is waarschijnlijk te wijten aan het feit dat α
laag is. In ieder geval valt deze curve zwaar terug.
Ook de curve voor α = 0.9 vertoont een anomalie. Deze krijgt veel meer reclames en telt
veel meer interacties en toch beweegt deze curve traag naar steady state 1.0. Dit kan
niet anders dan het wegzappen naar andere reclameblokken zijn. Wat echter moeilijk te
verklaren valt is dat geen betere reclames komen. Dit patroon wordt moeilijk doorbroken,
er komen ook nooit nieuwe reclames toe aangezien de STB altijd in een reclameblok zit.
4.1 Parameter test 47
Steady state in functie van interacties.
0,00
0,20
0,40
0,60
0,80
1,00
1,20
0,00 20,00 40,00 60,00 80,00 100,00 120,00
Interacties
Ste
ad
y s
tate
alpha = 0,1
alpha = 0,3
alpha = 0,5
alpha = 0,7
alpha = 0,9
Figuur 4.2: Steady state in functie van interacties
Uit de resultaten blijkt dat de waarde van α weinig invloed heeft op de snelheid waarmee
een steady-state wordt bereikt. Dit zal meer afhangen van het toeval. Om het profiel de
nodige flexibiliteit om te veranderen, te geven, wordt in wat volgt een waarde α = 0.5
gebruikt.
4.1.3 Verhouding gewichten impliciete en expliciete feedback
In deze test wordt de invloed van de gewichten voor impliciete en expliciete feedback
bekeken. Hierbij houden we α constant op 0.5 en Top-N op 60. Aangezien een groter
gewicht aan impliciete feedback dan aan expliciete feedback geven niet aan te raden is
worden de gewichten genomen zoals weergegeven in tabel 4.1.
4.1 Parameter test 48
Gewicht Impliciet Gewicht Expliciet
50% 50%
40% 60%
30% 70%
20% 80%
10% 90%
Tabel 4.1: Geteste gewichten impliciete en expliciete feedback
Ook hier werd voor elke combinatie de test twee keer uitgevoerd en de gemiddelde waarde
genomen. De resultaten worden weergegeven in figuur 4.3 en 4.4.
Steady state in functie van gespeelde reclames
0,00
0,20
0,40
0,60
0,80
1,00
1,20
0,00 50,00 100,00 150,00 200,00 250,00 300,00
Gespeelde reclames
Ste
ad
y s
tate
50% - 50%
60% - 40%
70% - 30%
80% - 20%
90% - 10%
Figuur 4.3: Steady state in functie van het aantal reclames
Hier worden duidelijkere verschillen opgemeten. Een hoger gewicht geven aan de expliciete
feedback heeft een positieve invloed op de snelheid waarmee steady-state wordt bereikt.
Dit is te verwachten aangezien de termen die door positieve feedback beïnvloed werden
een meer robuuste score krijgen. De termen beïnvloed door negatieve feedback worden
ook zwaarder gestraft.
4.1 Parameter test 49
Steady state in functie van interacties.
0,00
0,20
0,40
0,60
0,80
1,00
1,20
0,00 20,00 40,00 60,00 80,00 100,00 120,00 140,00
Interacties
Ste
ad
y s
tate
50% - 50%
60% - 40%
70% - 30%
80% - 20%
90% - 10%
Figuur 4.4: Steady state in functie van interacties
Er is hier toch voorzichtigheid geboden, in de praktijk heeft de impliciete feedback een
groter belang dan in deze test. In het TV3P artikel [1] wordt getest met een groep mensen.
Hieruit blijkt dat een combinatie van expliciete en impliciete feedback beter scoort dan
elk afzonderlijk. In wat volgt wordt daarom een verhouding 80%-20% gebruikt, in de
plaats van 90%-10%.
Spijtig genoeg komt dezelfde anomalie als in de vorige test voor α = 0.9 terug naar boven
voor de 60%-40% test.
4.1.4 Top-N termen
In deze test wordt de invloed van de top-N bekeken. Top-N wordt gevarieerd van 20 tot
100 in stappen van 20. Hierbij houden we de volgende parameters constant:
• α: 0.5
• Gewicht expliciete feedback: 80%
• Gewicht impliciete feedback: 20%
4.2 Storage test 50
Ook in deze test werd voor elke top-N de test twee keer uitgevoerd en de gemiddelde
waarde genomen. De resultaten worden weergegeven in figuur 4.5 en 4.6.
Steady state in functie van gespeelde reclames
0,00
0,20
0,40
0,60
0,80
1,00
1,20
0,00 50,00 100,00 150,00 200,00 250,00 300,00 350,00
Gespeelde reclames
Ste
ad
y s
tate
Top-N 20
Top-N 40
Top-N 60
Top-N 80
Top-N 100
Figuur 4.5: Steady state in functie van het aantal reclames
Hierbij valt op dat voor zowel de waarde 20 als 80 een goed resultaat verkregen wordt.
Echter wanneer dit naderbij wordt bekeken is er een verschil in aantal interacties tussen
top-N 20 en top-N 80. Top-N 80 heeft minder interacties.
4.2 Storage test
Het doel van deze test is te meten in welke mate de DSLAM kan ontlast worden van
reclames. Immers als een reclame verspreid is naar alle STB’s kan de DSLAM deze
verwijderen. Echter wegens tijdsgebrek is deze test niet uitgevoerd. De code in de proof of
concept is niet voorzien op een test en heeft bovendien geen algoritmen die de verspreiding
van reclame besturen met het oog op een beter gebruik van de opslagcapaciteit. Er wordt
in dit deel toch getracht deze resultaten theoretisch te schatten en een aantal krijtlijnen
uitgezet om de prestaties te verbeteren.
In de huidige code heeft de DSLAM en de STB als het ware een oneindige opslagcapaci-
teit. Het verbruik van opslagcapaciteit wordt weergegeven in figuur 4.7. Hierbij werden
4.2 Storage test 51
Steady state in functie van interacties.
0,00
0,20
0,40
0,60
0,80
1,00
1,20
0,00 20,00 40,00 60,00 80,00 100,00 120,00 140,00
Interacties
Ste
ad
y s
tate
Top-N 20
Top-N 40
Top-N 60
Top-N 80
Top-N 100
Figuur 4.6: Steady state in functie van interacties
arbitrair op de DSLAM 1000 reclames gezet en werd per reclameblok 10 reclames ver-
stuurd.
Opslagcapaciteit Verbruik
0
200
400
600
800
1000
1200
1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101
Reclameblokken
Ve
rbru
ik (
aa
nta
l re
cla
me
s)
DSLAM
STB
Figuur 4.7: Verbruik opslagcapaciteit voor de huidig code.
Als de code aangepast zou worden zodanig dat de DSLAM die reclames verwijdert die
verspreid zijn onder de STB’s krijgt men een verbruik zoals in figuur 4.8 is weergegeven.
Hierbij neemt het verbruik op de DSLAM traag af in het begin omdat de kans kleiner
4.2 Storage test 52
is dat de reclameblokken voor de verschillende STB’s overlappen. Hieruit volgt dat het
langer duurt eer een reclame zich bevindt op alle STB’s. Naarmate het aantal reclames
daalt stijgt de kans tot overlap waardoor de afname in verbruik versnelt. In dit model
wordt verondersteld dat alle gebruikers evenveel reclames bekijken. Is dit niet zo dan zal
het verbruik van opslagcapaciteit op de DSLAM afhangen van de traagste gebruiker.
Opslagcapaciteit Verbruik
0
200
400
600
800
1000
1200
1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101
Reclameblokken
Ve
rbru
ik (
aa
nta
l re
cla
me
s)
DSLAM
STB
Figuur 4.8: Verbruik opslagcapaciteit voor aangepaste code
Voorgaande modellen gaan uit van de naïeve veronderstelling dat de STB een oneindig
grote capaciteit heeft. In realiteit zal de opslagcapaciteit op de STB een factor minder
zijn dan deze op de DSLAM. Nu moet op de STB een vervangingstrategie uitgewerkt
worden. De meest voor de hand liggende reclames om te verwijderen zijn de volgende:
• Reclames die werden weggezapt.
• Reclames die verplicht zijn, afgespeeld zijn en geen interactie hebben ondervonden.
• Random reclames die afgespeeld zijn en geen interactie hebben ondervonden.
• Reclames die het laagste scoren voor personalisatie
Deze strategie neigt naar een steady state waarbij de beste reclames overleven op de
STB. Het nadeel van deze strategie is dat ze moeilijk werkt in de multi-user omgeving
van de STB. Immers een reclame die op een moment vervangen wordt omdat deze niet
aansluit bij het huidige profiel is misschien de best scorende reclame voor een ander profiel.
4.2 Storage test 53
Hierdoor is het onmogelijk voor de DSLAM om reclames te verwijderen aangezien deze
best scorende reclame terug op de STB moet geraken.
Om rekening te houden met alle gebruikers wordt een lijst gemaakt van reclames die in
aanmerking komen om verwijderd te worden, volgens de eerder vermelde regels. Vervol-
gens wordt voor elke reclame in deze lijst de maximum personalisatie score en gemiddelde
personalisatie score, ten opzichte van alle gebruikers, bepaald. De maximum score drukt
uit hoe belangrijk de reclame is voor een bepaalde gebruiker. De gemiddelde score drukt
uit hoe belangrijk deze reclame is voor alle gebruikers samen. Door een gewogen som te
nemen van deze twee scores en op de gewogen som te sorteren kunnen de minst belangrijke
reclames verwijderd worden van de STB. Aangezien de maximum score de personalisatie
zijde belicht is het interessanter om het gewicht in de gewogen som hiervoor hoger te
kiezen dan van de gemiddelde score.
Aan de kant van de DSLAM is het nu mogelijk om de reclames die uitgezonden werden
naar alle STB’s te verwijderen. Echter aangezien de verplichte reclames ook verwijderd
worden op de STB zullen deze op de DSLAM aanwezig moeten blijven. Dit alles geeft
aanleiding tot het opslagcapaciteit verbruik weergegeven in figuur 4.9. Hierbij werd ver-
ondersteld dat een STB 10% opslagcapaciteit heeft ten opzichte van de DSLAM. En dat
in het netwerk 25% van de reclames verpicht is.
Opslagcapaciteit Verbruik
0
200
400
600
800
1000
1200
1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101
Reclameblokken
Ve
rbru
ik (
aa
nta
l re
cla
me
s)
DSLAM
STB
Figuur 4.9: Verbruik opslagcapaciteit voor eindige STB opslagcapacteit
De DSLAM blijft reclameblokken sturen zo lang er genoeg reclames zijn. Hierna valt deze
4.3 Bandbreedte test 54
terug op verplichte reclames. Daarenboven wordt het moeilijker om reclames ingang te
doen vinden op de STB’s doordat deze de beste balans aan reclame houden en de rest
verwijderen. Zo kan het zijn dat de DSLAM reclameblokken stuurt die niet worden afge-
speeld en vervolgens worden verwijderd. Door hiermee rekening te houden kan de DSLAM
zich beperken tot het versturen van enkele random reclames en verplichte reclames, zonder
deze te verwijderen. Dit zal er voor zorgen dat de DSLAM ook niet “leegloopt”.
Opslagcapaciteit Verbruik
0
200
400
600
800
1000
1200
1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101
Reclameblokken
Ve
rbru
ik (
aa
nta
l re
cla
me
s)
DSLAM
STB
Figuur 4.10: Verbruik opslagcapaciteit voor beperkt verwijderen
In bovenstaande modellen werd geen rekening gehouden met een instroom van nieuwe
reclames, noch een uitstroom van reclames als gevolg van het verstrijken van de vers-
heidsdatum.
4.3 Bandbreedte test
In deze test wordt de bandbreedte gemeten die opgebruikt wordt tussen de DSLAM en de
STB voor de uitwisseling van reclames, profielen en dergelijke. Zo wordt de overhead van
dit systeem bepaald. Ook deze test is niet uitgevoerd kunnen worden door tijdsgebrek.
Het uitwisselen van reclame filmpjes ontbreekt in de code. Opnieuw wordt het resultaat
geschat. Als teruggekeken wordt naar de DSLAMInterface en STBInterface in de proof
of concept worden volgende functies het meest gebruikt:
• void geefKanaal(int channelId, Long userId)
• void update(STBBean stbBean)
4.3 Bandbreedte test 55
• UserBean getProfiel()
• void print(String tekst)
• void setReclames(LinkedHashSet<ReclameBean> reclames)
• void signalReclame(Long duur, int aantalVrij, int aantalVerplicht)
Aangezien het de bedoeling is op zijn minst met reclame fimpjes te werken wordt de print
functie verder niet meer beschouwd.
De functies die het meest bandbreedte vragen zijn ongetwijfeld update(...), getProfiel()
en setReclames(...). Hierbij dient opgemerkt te worden dat update(...) wordt getriggered
door setReclames(...) en anders niet wordt gebruikt, deze twee kunnen samengenomen
worden. Ook wordt het aantal keer dat getProfiel() wordt aangeroepen gestuurd door
de ProfielPoller op de DSLAM. Deze profielpoller zal veel actiever zijn voor een nieuwe
gebruiker. Worst case kan gesteld worden dat per reclameblok getProfiel() wordt aange-
roepen.
Wordt voorgaande per reclameblok bekeken dan is de data die uitgewisseld wordt per re-
clameblok de grootte van een UserBean, een STBBean, een LinkedHashSet<ReclameBean>
en de grootte van de reclameblok zelf. Echter de grootte van de reclameblok zelf is vele
malen groter dan de UserBean, STBBean en LinkedHashSet<ReclameBean> samen. Dit
zal voornamelijk de bandbreedte opslorpen.
Wordt er gerekend dat een reclameblok vijf minuten duurt met een grootte van 30MB per
minuut. Als een reclamepusher tien minuten op voorhand de reclameblok zendt dan zal
dit kunnen aan een bitrate van 2 MBit/s
Als rekening wordt gehouden met vorige sectie 4.2, dan daalt het bandbreedte verbruik
naarmate er minder reclames ingang vinden om opgeslagen te worden op de STB. Stel dat
niet langer vijf minuten reclame maar enkel drie minuten reclame meer wordt gestuurd.
Er is nog altijd tien minuten voorzien, de nodige bandbreedte valt terug naar 1.2 MBit/s.
BESLUIT 56
Hoofdstuk 5
Besluit
In deze scriptie werd onderzocht hoe reclames kunnen gepersonaliseerd worden voor iDTV
in een DSL netwerk. Dit resulteerde in een werkende proof of concept. Werkend in die zin
dat de profielen van de reclames worden gepersonaliseerd. De proof of concept vertoont
inderdaad enkele gebreken zoals het ontbreken van JMF of een uitwisseling van daadwer-
kelijke reclames. Ook werd niet de volledige vooropgestelde oplossing geïmplementeerd
aangezien de data carousel niet werd opgenomen in de proof of concept.
In de toekomst zijn er zeker een aantal mogelijkheden voor een vervolg op deze scriptie.
In eerste instantie zou de stap kunnen gezet worden om dit dichter bij het DSL netwerk
te krijgen. Hiermee wordt bedoeld dat niet meer met PC’s wordt gewerkt maar met een
echte STB en DSLAM. Ook het uitbreiden van de proof of concept met niet enkel echte
reclamespots maar met interactieve reclames lijkt een uitdaging.
Naast het technische aspect is er ook de business zijde. Zoals al in het voorwoord werd
aangehaald kan dit de TV zenders meer concurrentieel maken tegenover het internet.
Echter de interactieve reclames in de proof of concept zitten in het netwerk van de network
service provider, niet van de content provider(zijnde de TV zenders). De vraag die kan
gesteld worden is hoe dit zal werken voor beide partijen.
In ieder geval is deze technologie een interessant gegeven om te volgen in de komende
jaren. We hopen dat deze scriptie hier toch iets heeft kunnen aan bijdragen.
BIBLIOGRAFIE 57
Bibliografie
[1] Z. W. Yu and X. S. Zhou. Tv3p: An adaptive assistant for personalized tv. Ieee
Transactions On Consumer Electronics, 50(1):393–399, 2004.
[2] W. Hongguang Zhang, W. Shibao Zheng, and W. Jianghai Yuan. A personalized
TV guide system compliant with mhp. IEEE Trans. Consum. Electron. (USA),
51(2):731–737, 2005.
[3] G. . Karypis. Evaluation of item-based top-N recommendation algorithms. Pro-
ceedings Of The 2001 Acm Cikm. Tenth International Conference On Information
And Knowledge Management, pages 247–254, 2001.
[4] J. .L. . Herlocker, J. .A. . Konstan, and J. . Riedl. Explaining collaborative filte-
ring recommendations. Cscw 2000. Acm 2000 Conference On Computer Supported
Cooperative Work, pages 241–250, 2000.
[5] Vincent Verstraete Philip Leroux Toon De Pessemier, Tom Deryckere. Interactieve
reclame formats voor iDTV: technische aspecten, september 2007.
[6] Architecture and Transport Working Group. Tr059: Dsl evolution - architecture
requirements for the support of qos-enabled ip services. http://www.dslforum.org/,
September 2003.
[7] Architecture and Transport Working Group. Tr101: Migration to ethernet-based dsl
aggregation. http://www.dslforum.org/, April 2006.
[8] Java media framework api guide. http://java.sun.com/, november 1999.
[9] Omnividea fobs. http://fobs.sourceforge.net/.
[10] Jama : A java matrix package. http://math.nist.gov/.
LIJST VAN FIGUREN 59
Lijst van figuren
2.1 Structuur van het oudere DSL netwerk. [6] . . . . . . . . . . . . . . . . . . 5
2.2 Structuur van het nieuwe DSL netwerk. [7] . . . . . . . . . . . . . . . . . . 6
2.3 Werken met een videoBNG. [7] . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Hoog niveau architectuur van de Proof of Concept . . . . . . . . . . . . . . 19
3.2 Package diagram van de STB . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Package reclamebeheer op de STB en verband met package communicatie . 21
3.4 Reclames in de Proof of Concept . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Package profielbeheer en verband met de package communicatie . . . . . . 25
3.6 Profielen in de Proof of Concept . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7 Package communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.8 STBBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.9 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.10 Package diagram van de DSLAM . . . . . . . . . . . . . . . . . . . . . . . 32
3.11 Package kanalen op de DSLAM . . . . . . . . . . . . . . . . . . . . . . . . 32
3.12 Package communicatie op DSLAM . . . . . . . . . . . . . . . . . . . . . . 33
3.13 Package reclamebeheer op de DSLAM . . . . . . . . . . . . . . . . . . . . . 35
3.14 Profielpoller in de package profielbeheer . . . . . . . . . . . . . . . . . . . . 36
3.15 JMF: Media processing model . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.16 Opzetten van een stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.17 Ontvangen van een stream . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1 Steady state in functie van het aantal reclames . . . . . . . . . . . . . . . . 46
4.2 Steady state in functie van interacties . . . . . . . . . . . . . . . . . . . . . 47
4.3 Steady state in functie van het aantal reclames . . . . . . . . . . . . . . . . 48
4.4 Steady state in functie van interacties . . . . . . . . . . . . . . . . . . . . . 49
LIJST VAN FIGUREN 60
4.5 Steady state in functie van het aantal reclames . . . . . . . . . . . . . . . . 50
4.6 Steady state in functie van interacties . . . . . . . . . . . . . . . . . . . . . 51
4.7 Verbruik opslagcapaciteit voor de huidig code. . . . . . . . . . . . . . . . . 51
4.8 Verbruik opslagcapaciteit voor aangepaste code . . . . . . . . . . . . . . . 52
4.9 Verbruik opslagcapaciteit voor eindige STB opslagcapacteit . . . . . . . . . 53
4.10 Verbruik opslagcapaciteit voor beperkt verwijderen . . . . . . . . . . . . . 54
LIJST VAN TABELLEN 61
Lijst van tabellen
3.1 Vergelijking tussen het profiel van reclame en dat van TV programma’s . . 21
3.2 Vergelijking gebruikte ∆wi tov TV3P . . . . . . . . . . . . . . . . . . . . . 27
3.3 Ondersteunde media formaten voor RTP . . . . . . . . . . . . . . . . . . . 41
4.1 Geteste gewichten impliciete en expliciete feedback . . . . . . . . . . . . . 48