add more citations, fix reference format

source/chapters/chapter1.tex

@@ -26,8 +26,8 @@ \subsection{Motivation and Aims}
 home-networking technology was originally developed for research labs and
 enterprise networks and does not account for the unique characteristics of home
 usage, such as the lack of professional administrators, deep heterogeneity, and
-expectations of privacy. Among all the challenges of home-networking,
-connecting all media devices and making them work together is becoming
+expectations of privacy \cite{stateofHN}. Among all the challenges of
+home-networking, connecting all media devices and making them work together is becoming
 increasingly interesting because of the rapid growth of consumer electronics
 markets. Although several widely used multimedia-streaming solutions have
 become available in the market, the standards employed are not compatible with

source/chapters/chapter2_1.tex

@@ -13,10 +13,11 @@
 Audio/Video device architecture which is more specifically targeted to
 multimedia home networking. Section \ref{2_2_1_1} introduces the general UPnP device architecture. Section \ref{2_2_1_2} presents the UPnP Audio/Video device architecture and a typical UPnP Audio/Video use scenario.
 \subsubsection{UPnP device architecture\label{2_2_1_1}}
-Universal Plug and Play (UPnP) is a series of networking protocols defined to 
+Universal Plug and Play (UPnP) is a series of networking protocols defined to
 work together and seamlessly discover the presence of all devices in the
 network, establishing functional network services for data sharing,
-communications, and entertainment among these discovered devices.
+communications, and entertainment among these discovered
+devices\footnote{\url{http://upnp.org/about/what-is-upnp/}}.
 
 In most UPnP scenarios, a control point controls the operation of one or more 
 UPnP devices. The interaction usually occurs in isolation between control point 
@@ -58,7 +59,7 @@ \subsubsection{UPnP device architecture\label{2_2_1_1}}
 
 \textbf{Description}
 
-The discovery message contains the URL (Uniform resource Locater) of the
+The discovery message contains the URL (Uniform Resource Locator) of the
 description information. A control point can send an HTTP GET request based on
 this URL to get a detailed UPnP description of the device. The description includes the device description and several service descriptions. 
 
@@ -139,8 +140,8 @@ \subsubsection{UPnP device architecture\label{2_2_1_1}}
 possess some basic functionalities.
 \subsubsection{UPnP A/V devices\label{2_2_1_2}}
 We now move on to study the UPnP A/V (audio/video) devices in home
-networking\label{upnpav}. The UPnP A/V architecture is shown in Figure
-\ref{upnp_playback}.
+networking\label{upnpav}. The UPnP A/V architecture \cite{upnp-av} is shown in
+Figure \ref{upnp_playback}.
 
 \begin{figure}[hb] 
 \centering \includegraphics[height=9cm]{charts/upnp_playback} 
@@ -151,7 +152,7 @@ \subsubsection{UPnP A/V devices\label{2_2_1_2}}
 devices, one of which acts as either a source or a sink. While coordinated by
 the AV control point, the devices themselves interact with each other using a
 non-UPnP communication protocol. The control point configures the devices as
-needed, triggers the flow of content, then gets out of the way.
+needed, triggers the flow of content, then gets out of the way \cite{upnp-av}.
 
 \textbf{Media Server}
 
@@ -161,7 +162,7 @@ \subsubsection{UPnP A/V devices\label{2_2_1_2}}
 contains a ContentDirectory Service (CDS), a ConnectionManager Service (CM) 
 , and an optional AVTransport Service (AVT) which depends on the supported 
 transfer protocols. Some media servers are capable of transferring multiple 
-content items at the same time. 
+content items at the same time \cite{upnp-av}. 
 
 The ContentDirectory service is used by the control point to enumerate the content 
 on the server. The primary action is ContentDirectroy::Browse(). After 
@@ -286,18 +287,20 @@ \subsubsection{UPnP A/V devices\label{2_2_1_2}}
 supported include volume control, seek, pause etc. 
 
 \subsection[DLNA]{Digital Living Network Alliance\label{2_2_2}} 
-DLNA is a relatively old industry standard compared with other home networking 
-solutions. It is mainly based on the UPnP Audio/Video architecture, which is 
-discussed in section \ref{2_2_1_2} and shown in Figure \ref{upnp_playback}. As a
-result, it is widely used by many manufactures. Newer home networking solutions
-are also influenced by DLNA and they follow similar technologies used in DLNA.
+DLNA is a relatively old industry standard compared with other home networking
+solutions\footnote{\url{http://www.dlna.org/dlna-for-industry/our-organization}}.
+It is mainly based on the UPnP Audio/Video architecture, which is discussed in
+section \ref{2_2_1_2} and shown in Figure \ref{upnp_playback}. As a result, it
+is widely used by many manufactures. Newer home networking solutions are also
+influenced by DLNA and they follow similar technologies used in DLNA.
 In this paper the DLNA and UPnP standard architectures are studied to help us
 gain a grasp of how a home networking solution could look like.
 
-An overview of the DLNA architecture \cite{dlna_guideline} can be divided into
-five parts: Architectures and Protocols, Media Format Profiles, Link Protection,
-Digital rights management (DRM), Interoperability Solutions (DIS) and Device
-Profiles.
+An overview of the DLNA
+architecture \cite{dlna_guideline} can be divided into five parts: Architectures
+and Protocols, Media Format Profiles, Link Protection, Digital rights management
+(DRM), Interoperability Solutions (DIS) and Device
+Profiles\footnote{\url{https://members.dlna.org/members/guidelines/published_guidelines/}}.
 
 \textbf{Architectures and Protocols}
 
@@ -361,12 +364,12 @@ \subsubsection{UPnP A/V devices\label{2_2_1_2}}
 DLNA Link Protection is defined as the protection of a content stream between two 
 devices on a DLNA network against illegitimate observation or interception.
 
-Content protection is an important mechanism to ensure that commercial content is protected 
-from piracy and illegitimate redistribution. Link Protection is a technique that enables the
+As defined in \cite{dlna_guideline}, content protection is an important
+mechanism to ensure that commercial content is protected from piracy and
+illegitimate redistribution. Link Protection is a technique that enables the
 distribution of protected commercial content on a home network. It provides
-protection for copyright holders and content providers without sacrificing
-consumer flexibility.
-\clearpage
+protection for copyright holders and content providers without sacrificing consumer flexibility.
+
 \textbf{Digital rights management (DRM) Interoperability Solutions (DIS) }
 
 DIS is intended to be used to enable the secure transfer and use of protected 
@@ -376,15 +379,19 @@ \subsubsection{UPnP A/V devices\label{2_2_1_2}}
 
 \textbf{Device Profiles}
 
-A Device Profile is a collection of DLNA capabilities and features within a DLNA device. For a device 
-to be compliant with a Device Profile, it has to conform to all of the guidelines listed for that 
-Device Profile.
+A Device Profile is a collection of DLNA capabilities and features within a DLNA
+device \cite{dlna_guideline}. For a device to be compliant with a Device
+Profile, it has to conform to all of the guidelines listed for that Device Profile.
 
-In practice, Device Profiles reference existing optional or recommended DLNA guidelines that enable certain features, and makes those DLNA guidelines mandatory within the context of a Device Profile. 
+In practice, Device Profiles reference existing optional or recommended DLNA
+guidelines that enable certain features, and makes those
+DLNA guidelines mandatory within the context of a Device Profile
+\cite{dlna_guideline}.
 A Device Profile can also provide some additional guidelines that complement or
 modify existing DLNA guidelines for a feature.
 
-A particular type of DLNA Device Profile is the Commercial Video Profile (CVP).
+A particular type of DLNA Device Profile is the Commercial Video Profile
+(CVP) \cite{dlna_guideline}.
 A CVP Device Profile is an extension of the DLNA guidelines that will allow
 content from service providers and multichannel video programming distributors
 to be distributed on the DLNA network. DLNA Commercial Video Profiles (CVPs)

source/chapters/chapter4.tex

@@ -24,16 +24,18 @@ \subsection{Evaluation of streaming performance\label{4_1}}
 deliver web pages and images across the World Wide Web. HTTP is a most widely adopted, open
 standard and the most ubiquitous method of content delivery on the Internet.
 HTTP objects can be delivered by a variety of web servers, including
-commercially used servers and open source servers. Both DLNA and Chromecast utilize
-HTTP to realize their streaming functionality.
+commercially used servers and open source
+servers\footnote{\url{http://blog.eduguru.in/http-versus-rtmp-which-way-to-go-and-why/}}.
+Both DLNA and Chromecast utilize HTTP to realize their streaming functionality.
 
 Unlike HTTP, another popular protocol, the Real Time Streaming Protocol (RTSP)
 \cite{rtsp_rfc} is a network control protocol used in entertainment and
 communications systems to control media streaming servers. RTSP is used to establish and control media
 sessions between two points, usually the server and player client. Clients of
 media servers issue VCR-like commands, such as PLAY and PAUSE, to facilitate
-real-time control of playback of media files from the server.  The RAOP
-protocol, which is virtually another version of RTSP, is used by AirPlay, for
+real-time control of playback of media files from the
+server\footnote{\url{http://blog.eduguru.in/http-versus-rtmp-which-way-to-go-and-why/}}.
+The RAOP protocol, which is virtually another version of RTSP, is used by AirPlay, for
 the streaming of iTunes music.
 
 This section presents the evaluation of HTTP and RTSP streaming servers and

source/reference.bib

@@ -2,7 +2,7 @@
 %% http://bibdesk.sourceforge.net/
 
 
-%% Created for Peng Liu at 2015-05-11 23:52:40 +0300 
+%% Created for Peng Liu at 2015-05-14 15:28:01 +0300 
 
 
 %% Saved with string encoding Unicode (UTF-8) 
@@ -32,19 +32,21 @@ @techreport{ntp_rfc
 @techreport{rtsp_rfc,
 	Author = {H. Schulzrinne, A. Rao, R. Lanphier},
 	Date-Added = {2015-05-11 20:29:37 +0000},
-	Date-Modified = {2015-05-11 20:30:33 +0000},
-	Institution = {Internet Engineering Task Force (IETF) },
+	Date-Modified = {2015-05-14 12:12:26 +0000},
+	Institution = {Internet Engineering Task Force (IETF)},
 	Month = {April},
 	Title = {Real Time Streaming Protocol (RTSP)},
+	Type = {RFC},
 	Year = {1998}}
 
 @techreport{ssdp_rfc,
 	Author = {Yaron Y. Goland, Ting Cai, Paul Leach, Ye Gu, Shivaun Albright},
 	Date-Added = {2015-05-11 20:27:24 +0000},
-	Date-Modified = {2015-05-11 20:29:13 +0000},
-	Institution = {Internet Engineering Task Force (IETF) },
+	Date-Modified = {2015-05-14 12:12:20 +0000},
+	Institution = {Internet Engineering Task Force (IETF)},
 	Month = {October},
 	Title = {Simple Service Discovery Protocol/1.0},
+	Type = {RFC},
 	Year = {1999}}
 
 @techreport{http_rfc,
@@ -58,10 +60,10 @@ @techreport{http_rfc
 	Year = {1999}}
 
 @techreport{rtp_rfc,
-	Author = {H. Schulzrinne, S.  Casner,  R. Frederick, V. Jacobson},
+	Author = {H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson},
 	Date-Added = {2015-05-11 20:23:51 +0000},
 	Date-Modified = {2015-05-11 20:25:01 +0000},
-	Institution = {Internet Engineering Task Force (IETF) },
+	Institution = {Internet Engineering Task Force (IETF)},
 	Month = {July},
 	Title = {RTP: A Transport Protocol for Real-Time Applications},
 	Type = {RFC},
@@ -150,39 +152,43 @@ @techreport{miracast_consumer
 @techreport{dial,
 	Author = {Netflix, Inc.},
 	Date-Added = {2014-06-17 19:18:45 +0000},
-	Date-Modified = {2014-06-17 19:21:18 +0000},
+	Date-Modified = {2015-05-14 12:13:54 +0000},
 	Institution = {Netflix, Inc.},
 	Title = {DIscovery And Launch protocol specification},
+	Type = {Standard},
 	Year = {2014},
 	Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QLi4uLy4uL21hdGVyaWFscy9ESUFMLTJuZFNjcmVlblByb3RvY29sLTEuNy5wZGbSFwsYGVdOUy5kYXRhTxEB/gAAAAAB/gACAAAMTWFjaW50b3NoIEhEAAAAAAAAAAAAAAAAAAAA0GaUh0grAAAACnxRHkRJQUwtMm5kU2NyZWVuUHJvdG9jb2wtMS43LnBkZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKfFnPxm8hAAAAAAAAAAAAAgACAAAJIAAAAAAAAAAAAAAAAAAAAAltYXRlcmlhbHMAABAACAAA0GZqVwAAABEACAAAz8ZE8QAAAAEAGAAKfFEACnwgAAp65gAKet4ACeBZAAKT1QACAGBNYWNpbnRvc2ggSEQ6VXNlcnM6AHBlbmdsaXU6AERvY3VtZW50czoAQWFsdG86AHRoZXNpczoAbWF0ZXJpYWxzOgBESUFMLTJuZFNjcmVlblByb3RvY29sLTEuNy5wZGYADgA+AB4ARABJAEEATAAtADIAbgBkAFMAYwByAGUAZQBuAFAAcgBvAHQAbwBjAG8AbAAtADEALgA3AC4AcABkAGYADwAaAAwATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAEgBNVXNlcnMvcGVuZ2xpdS9Eb2N1bWVudHMvQWFsdG8vdGhlc2lzL21hdGVyaWFscy9ESUFMLTJuZFNjcmVlblByb3RvY29sLTEuNy5wZGYAABMAAS8AABUAAgAO//8AAIAG0hscHR5aJGNsYXNzbmFtZVgkY2xhc3Nlc11OU011dGFibGVEYXRhox0fIFZOU0RhdGFYTlNPYmplY3TSGxwiI1xOU0RpY3Rpb25hcnmiIiBfEA9OU0tleWVkQXJjaGl2ZXLRJidUcm9vdIABAAgAEQAaACMALQAyADcAQABGAE0AVQBgAGcAagBsAG4AcQBzAHUAdwCEAI4AvwDEAMwCzgLQAtUC4ALpAvcC+wMCAwsDEAMdAyADMgM1AzoAAAAAAAACAQAAAAAAAAAoAAAAAAAAAAAAAAAAAAADPA==}}
 
 @techreport{upnp-av,
 	Author = {John Ritchie, Thomas Kuehnel, Wouter van der Beek, Jeffrey Kang},
 	Date-Added = {2014-06-05 20:47:47 +0000},
-	Date-Modified = {2014-06-05 20:49:33 +0000},
+	Date-Modified = {2015-05-14 11:19:28 +0000},
 	Institution = {UPnP Forum},
 	Month = {December},
-	Title = {UPnP AV Architecture},
+	Title = {UPnP AV Architecture:2},
+	Type = {Standard},
 	Year = {2010},
 	Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QNi4uLy4uL21hdGVyaWFscy9VUG5QLWF2LUFWQXJjaGl0ZWN0dXJlLXYyLTIwMTAxMjMxLnBkZtIXCxgZV05TLmRhdGFPEQIYAAAAAAIYAAIAAAxNYWNpbnRvc2ggSEQAAAAAAAAAAAAAAAAAAADQZpSHSCsAAAAKfFEfVVBuUC1hdi1BVkFyY2hpdGVjdHVyI0E3Qzc1LnBkZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAp8dc+2sgcAAAAAAAAAAAACAAIAAAkgAAAAAAAAAAAAAAAAAAAACW1hdGVyaWFscwAAEAAIAADQZmpXAAAAEQAIAADPtofXAAAAAQAYAAp8UQAKfCAACnrmAAp63gAJ4FkAApPVAAIAYU1hY2ludG9zaCBIRDpVc2VyczoAcGVuZ2xpdToARG9jdW1lbnRzOgBBYWx0bzoAdGhlc2lzOgBtYXRlcmlhbHM6AFVQblAtYXYtQVZBcmNoaXRlY3R1ciNBN0M3NS5wZGYAAA4ATgAmAFUAUABuAFAALQBhAHYALQBBAFYAQQByAGMAaABpAHQAZQBjAHQAdQByAGUALQB2ADIALQAyADAAMQAwADEAMgAzADEALgBwAGQAZgAPABoADABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAASAFVVc2Vycy9wZW5nbGl1L0RvY3VtZW50cy9BYWx0by90aGVzaXMvbWF0ZXJpYWxzL1VQblAtYXYtQVZBcmNoaXRlY3R1cmUtdjItMjAxMDEyMzEucGRmAAATAAEvAAAVAAIADv//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOAMcAzADUAvAC8gL3AwIDCwMZAx0DJAMtAzIDPwNCA1QDVwNcAAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAA14=}}
 
 @techreport{dlna_guideline,
 	Author = {Digital Living Network Alliance.},
 	Date-Added = {2014-06-04 19:39:57 +0000},
-	Date-Modified = {2014-06-04 19:46:31 +0000},
+	Date-Modified = {2015-05-14 12:13:42 +0000},
 	Institution = {Digital Living Network Alliance.},
 	Month = {March},
-	Title = {DLNA Guidelines},
+	Title = {DLNA Guidelines, Part 1-1: Architectures and Protocols},
+	Type = {Standard},
 	Year = {2014},
 	Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QVS4uLy4uL21hdGVyaWFscy9ETE5BIEd1aWRlbGluZXMgTWFyY2ggMjAxNCAtIFBhcnQgMS0xIEFyY2hpdGVjdHVyZXMgYW5kIFByb3RvY29scy5wZGbSFwsYGVdOUy5kYXRhTxECdAAAAAACdAACAAAMTWFjaW50b3NoIEhEAAAAAAAAAAAAAAAAAAAA0GaUh0grAAAACnxRH0RMTkEgR3VpZGVsaW5lcyBNYXJjaCNBN0M1Qy5wZGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKfFzPtVIzAAAAAAAAAAAAAgACAAAJIAAAAAAAAAAAAAAAAAAAAAltYXRlcmlhbHMAABAACAAA0GZqVwAAABEACAAAz7UoAwAAAAEAGAAKfFEACnwgAAp65gAKet4ACeBZAAKT1QACAGFNYWNpbnRvc2ggSEQ6VXNlcnM6AHBlbmdsaXU6AERvY3VtZW50czoAQWFsdG86AHRoZXNpczoAbWF0ZXJpYWxzOgBETE5BIEd1aWRlbGluZXMgTWFyY2gjQTdDNUMucGRmAAAOAIwARQBEAEwATgBBACAARwB1AGkAZABlAGwAaQBuAGUAcwAgAE0AYQByAGMAaAAgADIAMAAxADQAIAAtACAAUABhAHIAdAAgADEALQAxACAAQQByAGMAaABpAHQAZQBjAHQAdQByAGUAcwAgAGEAbgBkACAAUAByAG8AdABvAGMAbwBsAHMALgBwAGQAZgAPABoADABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAASAHRVc2Vycy9wZW5nbGl1L0RvY3VtZW50cy9BYWx0by90aGVzaXMvbWF0ZXJpYWxzL0RMTkEgR3VpZGVsaW5lcyBNYXJjaCAyMDE0IC0gUGFydCAxLTEgQXJjaGl0ZWN0dXJlcyBhbmQgUHJvdG9jb2xzLnBkZgATAAEvAAAVAAIADv//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOAOYA6wDzA2sDbQNyA30DhgOUA5gDnwOoA60DugO9A88D0gPXAAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAA9k=}}
 
 @techreport{multicastdns,
 	Author = {Stuart Cheshire, Marc Krochmal},
 	Date-Added = {2014-06-03 21:56:00 +0000},
-	Date-Modified = {2015-05-11 20:22:06 +0000},
-	Institution = {Internet Engineering Task Force (IETF) },
+	Date-Modified = {2015-05-14 12:27:55 +0000},
+	Institution = {Internet Engineering Task Force (IETF)},
 	Month = {February},
 	Title = {Multicast DNS},
+	Type = {RFC},
 	Url = {http://www.ietf.org/rfc/rfc6762.txt},
 	Year = {2013},
 	Bdsk-Url-1 = {http://www.ietf.org/rfc/rfc6762.txt}}