這部分的内容大多來源于網絡及官方文檔，按照自己的翻譯了解整理所成。東西比較多，從頭慢慢看還是可以懂個大概的。
目錄：
一、DNLA的建立
二、DLNA的成員
三、DLNA标準的制定
四、DLNA的裝置
五、DLNA的架構
六、雲時代的數字家庭（待填坑）
擴充閱讀I： UPnP的工作過程------------DLNA基礎協定架構
擴充閱讀II UPnP AV(Audio/Video) Architecture---------------DLNA媒體應用架構)
一、DNLA的建立
DLNA 成立于2003 年6 月24 日, 其前身是DHWG （Digital Home Working Group 數字家庭工作組），由Sony、Intel、Microsoft等發起成立、旨在解決個人PC ，消費電器，移動裝置在内的無線網絡和有線網絡的互聯互通，使得數字媒體和内容服務的無限制的共享和增長成為可能。DLNA的口号是Enjoy your music, photos and videos, anywhere anytime。該組織的官方網站是http://www.dlna.org . 頁面主色調green,black,white,silver和gray，後面要講到的UPnP的主業也是同樣的調調，這兩個關系挺大的，後面講。
二、DLNA的成員
這個組織将加入者分為兩個層次，最高層次為promoter, 其次為contributor。promoter制定标準和協定，contributor可以分享這個組織的資源，也可以送出标準，參與讨論。現在絕大多數的電子制造商都加入了該組織，至少是contributor，而且年費還很貴。成員名單可以從http://www.dlna.org/about_us/roster/中可以找到。
下圖是2008年DLNA的promoter：
下圖是2011年的promoter：
從上面兩個圖我們可以看見，DLNA的骨幹成員包括以Intel為首的晶片制造商；以HP為首的PC制造商，以Sony，Panasonic，Sharp，Samsung，LG 為首的家電、消費電子制造商；以CISCO，HUWEI，MOTOROLA，ERICSSON為首的電信裝置/移動終端/标準商；一家獨大的Microsoft軟體/作業系統商等等。
值得注意的有幾點：
1.DLNA這個東西基本Intel，Microsoft兩個領域巨頭在推，一個搞晶片，一個搞系統。AMD沒出現在2011的promoter名單中；Google來年會不會摻一腳不好說。還有QUALCOMM也參加進來了，這幾年的智能手機晶片處理器他家的也比較多，而且他家還有很多專利可以吃。
2.2011就剩HP一個大PC商了，其他大PC商如Acer,Asus都還不是promoter，他們肯定要搶着加入的。lenovo不僅從promotor名單中消失了，自然也不會是contributor了，和AMD一樣。最開始時lenovo是很積極的，在DHWG的時候也是骨幹成員，回來中國搞了一個“IGRS閃聯”，退出的原因不知道和這個有沒有關系。IGRS在很大程度上和DLNA是比較類似的，架構協定和UPnP也是比較像的。
3.Awox和Cablelabs都是做互聯多媒體裝置的。Broadcom主要是做移動消費電子，有硬體solution，也有産晶片。
4.ACCESS（愛可視）是做軟體的。現在軟體的需求很大，給第三方提供軟體solution是一塊很大的蛋糕。cyberlink和arcsoft也在做這方面，已經有些成熟的軟體solution了，像EMC，NeuSoft也有在做。
5.營運商開始加入了，像at&t美國電報電話公司，at&t也挺厲害的，到處搞簽約機，像是跟PSP VITA也簽了。以後中國移動聯通不知道會不會也跑來參加(有點難...)。
6.dts和dolby都是做音視訊标準的，他們基本是跑來收錢的，你機器上到他們的專利你就得付錢，跟以後肯定其他人也會跑來收錢。
三、DLNA标準的制定
該組織旨在建立一個基于開放的工業标準的互操作平台，并将确立技術設計規則，供企業開發數字家庭有關的産品。其工作目标是根據開放工業标準制定媒體格式，傳輸和協定互操作性的指南和規範，和其他工業标準化組織進行聯絡，提供互操作性測試，并進行數字家庭市場計劃的制定和實施。
DLNA并不是創造技術，而是形成一種解決的方案，一種大家可以遵守的規範。是以DLNA選擇的各種技術和協定都是目前所應用很廣泛的技術和協定。是以很多家都要參加，希望DLNA采納自己的協定和标準，以後自己好辦事，可以的話順便吃點專利費。大方向上肯定打不過Intel和Microsoft的，隻能跟着他們走，可以提起其他方面的協定和标準。DLNA的标準寫在DLNA GUIDELINES裡面，就是大家開會一起寫出來的，再開會不停修改的一個standard，一個specification。參加DLNA的商家必須按這個标準走，這樣大家的裝置才能互相通信。
四、DLNA的裝置
在講DLNA的架構之前先講一下DLNA規定的裝置分類，這些裝置就是DLNA标準執行的實體和邏輯對象。
這是一個DLNA 裝置的類圖。
1.Home NetWork Device(HND)。這類裝置指家庭裝置，具有比較大的尺寸及較全面的功能，主要與移動裝置差別開來，下屬5類裝置：
(1)Digital Media Server(DMS)。數字媒體伺服器，提供媒體擷取、記錄、存儲和輸出功能。同時，内容保護功能是對DMS的強制要求。DMS總是包含DMP的功能，并且肯能包含其他智能功能，包括裝置/使用者服務的管理；豐富的使用者界面；媒體管理/收集和分發功能。DMS的例子有PC、數字機頂盒（附帶聯網，存儲功能）和錄影機等等。
(2)DMP。數字媒體播放器。能從DMS/M-DMS上查找并擷取媒體内容并播放和渲染顯示。比如智能電視、家庭影院等。
(3)DMC。數字媒體控制器，查找DMS的内容并建立DMS與DMR之間的連接配接并控制媒體的播放。如遙控器。
(4)DMR。數字媒體渲染裝置。通過其他裝置配置後，可以播放從DMS上的内容。與DMP的差別在于DMR隻有接受媒體和播放功能，而沒查找有浏覽媒體的功能。比如顯示器、音箱等。
(5)DMPr。數字媒體列印機，提供列印服務。網絡列印機，一體化列印機就屬于DMPr。
2.Mobile Handheld Devices(MHD)手持裝置。相比家庭裝置，手持裝置的功能相對簡化一些，支援的媒體格式也會不同。
(1)M-DMS。與DMS類似，如行動電話，随身音樂播放器等。
(2)M-DMP。與DMP類似。比如智能移動電視。
(3)M-DMD。移動多媒體下載下傳裝置。如随身音樂播放器，車載音樂播放器和智能電子相框等
(4)M-DMU。移動多媒體下載下傳裝置。如攝像裝置和手機等。
(5)M-DMC。與DMC類似。P如DA，智能遙控器。 手持裝置沒有定義M-DMR，因為手持裝置會講究便利性，會附加查找控制功能，
要不然就隻是普通的移動電視或收音機了。
3.Networked Infrastructure Devices (NID) 聯網支援裝置。
(1)Mobile Network Connectivity Function (M-NCF)。移動網絡連接配接功能裝置。提供各種裝置接入移動網絡的實體媒體。 DLNA的希望是全部實作無線化。
(2)Interoperability Unit (MIU)媒體互動裝置。提供媒體格式的轉換以支援各種裝置需要。
設想一下這樣一個scenario：你下了班回到家，掏出手機撥到家庭模式，然後就在手機上遙控打開了等離子電視和PC，然後把訂閱的新聞通過PC下載下傳完成後打到等離子電視上播放。這時手機就是一個DMC/M-DMC，等離子電視是一個DMR，PC就是DMS。然後你手機上收到一張朋友從巴西傳來的照片，你看完之後把它同步到PC上存儲起來，這樣手機現在的身份是M-DMU，然後你把這張圖檔放到電子相框裡面。這個電子相框就是一個M-DMD，相框也有play的能力，是以他又是一個M-DMP。是以說這些裝置的功能角色都是不定的，界限也不是那麼嚴格。在DLNA Guidelines v1.0的時候還沒有智能手機，後來在v1.5加入了。這個裝置分類隻是定義了功能，而且功能也會變的。以後還會出其它新裝置，像pad,tab,touch各種各樣，到時候标準也會變的。
五、DLNA的架構
DLNA架構是個互聯系統，是以在邏輯上它也類似OSI（Open System Interconnection，開放系統互連）七層網絡模型。
DLNA架構分為如下圖7個層次：
DLNA ARCHITECTURE
(1) NetWorking Connectivity 網絡互聯方式:包括實體連接配接的标準，有有線的，比如符合IEEE802.3标準的Ethernet，；有無線
的 ，比如符合IEEE802.11a/g标準的WiFi，能做到54Mbps，藍牙(802.15)等,技術都很成熟。現在OFDM和MIMO(802.11n)已經能做到300Mbps了，早就超過比較普及的100Mbps的Ethernet了，隻不過産品還沒有普及，以後肯定會用到。
(2) NetWorking Stack 網絡協定棧：DLNA的互聯傳輸基本上是在IPV4協定簇的基礎上的。用TCP或者UDP來傳都可以。這一層相當于OSI網絡層。
(3)Device Discovery&Control 裝置發現和控制。
這個層次是比較essential的，是DLNA的基礎協定架構。DLNA用UPnP協定來實作裝置的發現和控制。下面重點看一下UPnP。
這一部分可以看一下http://upnp.org/sdcps-and-certification/standards/device-architecture-documents/裡的文檔。UPnP的工作過程 一文也做了詳細說明。下面概括總結性地說一說。
UPnP，英文是Universal Plug and play，翻譯過來就是通用即插即用。UPnP最開始Apple和Microsoft在搞，後來Apple不做了，Microsoft還在繼續做，Intel也加進來做，Sony，Moto等等也有加入。UPnP有個網站http://www.upnp.org/，我們發現DLNA的網頁和UPnP的網頁很像，顔色也差不多，就可以知道他們關系很好了。DNLA主要是在推UPnP。
微軟官方網站對UPnP的解釋：通用即插即用 (UPnP) 是一種用于 PC 機和智能裝置（或儀器）的常見對等網絡連接配接的體系結構，尤其是在家庭中。UPnP 以 Internet 标準和技術（例如 TCP/IP、HTTP 和 XML）為基礎，使這樣的裝置彼此可自動連接配接和協同工作，進而使網絡（尤其是家庭網絡）對更多的人成為可能。
舉個例子。我們在自己的PC（win7）裡面打開網絡服務的UPnP選項，然後再家庭網絡中共享一個裝着視訊的檔案夾，然後買一台SmartTV回來打開就可以找到這台PC的共享檔案夾，然後就直接在電視上選檔案播放了。
UPnP的另外一個作用是給家庭網内的devices做自動的網絡位址轉換NAT(NAT,Network Address Translation)和端口映射(Port Mapping)，因為家庭網絡裡面沒有那麼多IP，所有的devices可能都要通過同一個ip出去。轉換映射之後，家庭網絡内外的devices就可以通過internet自由地互相連接配接，而不受内網位址不可通路的阻礙。
UPnP Device Architecture 1.0中會說明裝置是怎樣通過UPnP來互相發現和控制，以及傳遞消息的。我們會專門用一章的篇幅來講一下UPnP Device Architecture，可見下文中的擴充閱讀I： UPnP的工作過程
(4)Media Management媒體管理。媒體管理包括媒體的識别、管理、分發和記錄（儲存），UPnP AV Architecture:1 and UPnP Printer Architecture:1這兩個屬于UPnP的文檔會說明如何進行媒體管理。我将在 擴充閱讀II：UPnP AV Architecture 一文中稍微詳細介紹UPnP AV裝置和CP之間的互動模型及媒體的控制。
UPnP AV Architecture 定義了UPnP AV裝置間媒體傳送以及和CP間的互動。UPnP AV也定義了兩種UPnP AV裝置：UPnP AV MediaServer（MS）和UPnP AV MediaRender（MR），以及他們具有的4種服務：
1)Content Directory Service(CDS)：能将可通路的媒體内容列出。
2)Connection Manager Service(CMS)：決定媒體内容可以通過何種方式由UPnP AV Media Server傳送至UPnP AV MediaRender。
3)AVTransport Service：控制媒體内容，比如播放、停止、暫停、查找等。
4)Rendering Control Service：控制以何種方式播放内容，比如音量、靜音、亮度等。
UPnP Printer Architecture:1 定義了列印裝置和CP的互動模型，這将不再細說。
(5) Media Transport 媒體傳輸：這一層用HTTP(HyperText Transfer Protocol)超文本傳輸協定。就是平時我們上網用的媒體傳輸協定。HTTP用TCP可靠傳輸，也有混合UDP方式的HTTP。現在HTTP的最新版本是HTTP1.1。可選協定是RTP。
exsample：我們輸入一個網址，回車，給server發一個request，用TCP我們就可以等server給我們消息，說明server收到我們的消息了，否則我們就重發；接着server給我們TCP包，我們收一個就給server回信說我們收到了，要是server收不到回信，他就認為包丢掉了，會再傳一個同樣的包過來。不停地回信就是會比較慢。
那如果我們用UDP會怎樣？就是說我們不給server回信說我們收到編号是x的包了，server也就不給我們重發丢掉的包了，這樣我們就丢包了。
但是我們傳stream的時候，比如視訊流，不用存，看完就完了，這種時候就可以用UDP來傳。加上區域網路裡面QoS本來就很高，丢包都是不太可能的。是以UDP肯定會用。區域網路多點傳播的時候也用UDP，這個在後面講。
媒體的傳輸方案如下：
1)從DMS/M-DMS至DMP/M-DMP，即使不立即播放。
2)從一個DMS到另一個DMS，這時接收方DMS播放接收媒體内容，表現為一個DMP；也可以不立即播放，可能隻是存儲或者處理。
媒體傳輸 模式有三種：
1)流傳輸。當DMR/DMP需要實時渲染接收媒體，媒體具時序性。
2)互動傳輸。不包含時序的媒體，如圖檔傳輸。
3)背景傳輸。非實時的媒體傳輸，比如上傳下載下傳等。
(6)Media Formats媒體格式。格式Formats在這裡等同于編碼格式Codec，平時我們說的編碼格式比如Mpeg-2，AVC，x264就是視訊編碼格式；PCM，mp3(MPEG-2 Layer 3)，aac，flac就是音頻編碼格式。而avi，rmvb，mkv這些是媒體封裝格式，包含視訊音頻可能還有字幕流。比如一個常見的字尾為mkv的檔案，它的視訊Codec是x264，音頻是aac，它的視音頻編碼屬于Mpeg-4 Codec Family。
我們知道不同裝置對編碼格式的支援能力不同，Media Formats這一部分規定了裝置應該具有的格式支援能力。下面的表是DLNA支援的所有編碼格式：
DLNA-proved format
| Video | Audio | Images | |
| MPEG-1 MPEG-2 H.263 MPEG-4 Part 2 MPEG-4 Part 10 WMV9 VC-1 | LPCM MPEG-1/2 L2 MPEG-1/2 L3 MPEG-4 AAC LC MPEG-4 AAC LTP MPEG-4 HE AAC MPEH-4 BSAC | AC-3 ATRAC3plus WMA WMA Professional AMR AMR-WB+ G.726 | JPEG PNG GIF TIFF |
針對家庭裝置和手持裝置，DLNA有不同的格式規定：
(7)Remote UI 遠端使用者接口。說白了就是遙控器。比如說有個TV，我們說不管是用遙控器還是直接在TV上按按鈕，效果是一樣的。不過兩者按鈕的排列布局是不一樣的。好了，現在到DLNA了，我想用手機當遙控器可不可以？當然可以，隻要獲得TV上按鈕的功能，傳到手機上來，模拟一個遙控器就好了。DLNA現在想用浏覽器的方式，TV給你一個XML，手機上就出現遙控器界面了，有點像webQQ，webOS那種，這樣在手機上就不需要用戶端了，TV功能更新了，手機直接跟TV要新的XML，很友善。
-------------------------------------------------------------------------------------------------------------------------------
擴充閱讀I： UPnP的工作過程
UPnP的工作過程分為6步：
（1）尋址(Addressing)。
位址是整個UPnP系統工作的基礎條件，每個裝置都應當是DHCP（Dynamic Host Configuration Protocol 動态主機配置協定）的客戶。當裝置首次與網絡建立連接配接後，利用DHCP服務，使裝置得到一個IP位址。這個IP位址可以是DHCP系統指定的，也可以是由裝置選擇的。當區域網路内沒有提供DHCP服務時，UPnP裝置将按照Auto-IP的協定，從169.254/169.16位址範圍擷取一個區域網路内唯一的IP位址。裝置還可以使用friendly name，這就需要域名解析服務（DNS）來轉換name和IP。這個過程用到的東西都是現存的，而且是很普及的，市面上買的路由器都會有。
（2）發現(Discovery)。
發現是 UPnP工作第一步。 當一個裝置被添加到網絡後，UPnP的發現協定允許該裝置向網絡上的Control Points(CPs)通知(advise)自己擁有的服務。同樣，當一個CP被添加到網絡後，UPnP發現協定允許該CP搜尋網絡上可用的裝置。這兩種情況下的多點傳播消息一般是裝置和服務的基本資訊，如它的類型，唯一辨別符，目前狀态參數等等。要注意裝置資訊和服務資訊都是要多點傳播出去的。發現的過程可以用下面Figure 1-1來描述。
下面詳細叙述UPnP發現裝置用到的協定：SSDP(Simple Service Discovery Protocol，簡單服務發現協定)，說明裝置是怎樣向網絡通知或者撤銷自己可以提供的服務；CP是如何搜尋裝置以及裝置是如何回應搜尋的。
SSDP格式套用HTTP1.1的部分消息頭字段，但是和HTTP不同，SSDP是采用UDP傳輸的，而且SSDP沒有Message Body，就是說SSDP隻有信頭而沒有信件内容的。
SSDP第一個要填充的字段是star - line，說明這是個什麼類型的消息。
比如填"NOTIFY * HTTP/1.1/r/n"，就說明這個SSDP消息是個通知消息，一般裝置加入網絡或者離開網絡都要NOTIFY，更新自己的服務後也要NOTIFY一下。别的裝置看見這個消息的star - line就知道有裝置狀态變了，自己就打開這個消息看一下有沒有需要更新的。如果填"NOTIFY * HTTP/1.1/r/n"，就要填LOCATION字段，填一個description URL，CP可以通過這個位址來取得裝置的詳細資訊。
填"M-SEARCH * HTTP/1.1/r/n"就是要搜尋了；respone别人的搜尋就填"HTTP/1.1 200 OK/r/n"。
SSDP第二個要填充的字段是目的位址HOST。比如填上"HOST: 239.255.255.250:1900"，就是多點傳播(multicast)搜尋，這裡239.255.255.250是多點傳播位址，就是說這條消息會給網絡裡面該組位址的裝置發，1900是SSDP協定的端口号。如果HOST位址是特定位址，那這就是單點傳播(unicast)。Respone不填這個字段，他會在ST字段裡面填respone address，就是發來搜尋資訊的裝置的位址，Respone消息的話還會發送一個包含自己位址URL的字段，Respone的意思就是跟Searcher說：我好像是你要找的人，我的電話是XXX，詳細情況請CALL我。Respone也是UDP單點傳播。
往後的字段就不細說了。通過字段的組合可以發送很多不同的資訊。
（3）描述(Description)
前面我們說了CP想要一個device更詳細的資訊，就打給它的URL跟它要。傳回來的東西一般是個XML（Extensible Markup Language，是種結構化的資料。和HTML比較像，有tag和data，具體不說了自己去查），描述分為兩部分：一個是device description，是device的實體描述，就是說這個device是什麼；還有一個是service descriptions，就是device的服務描述了，就是device能幹些什麼。這些device和device service的描述的格式也是有要求的，開發商也可以自定義，隻要符合UPnP Forum的規範。
這裡稍微解釋一下裝置描述和服務描述。
首先說裝置，比如一個家庭影院，有顯示屏，有功放音響，還有藍光機。那麼這個家庭影院home threatre，就是一個根裝置(root device)，它下屬有Screen，Amplifier,BDplayer這些從裝置。home threatre的描述XML中會有一個device list,列出Screen，Amplifier,BDplayer這些裝置的基本資訊及這些裝置描述的URL，以及裝置的presentationURL（這類似于web伺服器，通過通路presentationURL，本地會加載一個網頁，在這個網頁上可以操作裝置及其它擁有的服務）；還會有一個sevice list,裡面列出home threatre可調用的服務基本資訊及服務描述URL。
再來是服務，通過通路服務描述URL，可以取得服務描述XML，裡面會詳細介紹服務的資訊，包括幹什麼用的，屬于哪個裝置，有哪些action，需要哪些參數，怎麼調用等等。
（4）控制(Control)
拿到device description和service descriptions以後，那我們怎麼去遙控這些裝置呢？
在裝置描述部分，device description還有關于如何控制device的描述，會給出一個Control URL，CP可以向這個URL發送不同的控制資訊就可以控制device了，然後device也可以傳回一個資訊回報。
這種CP和device之間溝通資訊按照Simple Object Access Protocol (SOAP)的格式來寫。SOAP通過HTTP來傳，現在的版本是1.1，叫做SOAP 1.1 UPnP Profile。這個Profile把控制/回報資訊分成三種：UPnP Control Request，UPnP Control Response和UPnP Control Error Response，都比較好了解。SOAP協定是有信内容Body的，和SSDP不一樣。消息Body裡面就可以寫想調用的動作了，叫做Action invocation，可能還要傳參數，比如想播放一個視訊，要把視訊的URL傳過去；device收到後要respone，表示能不能執行調用，出錯的話會傳回一個錯誤代碼。
（5）事件(Eventing)
在服務進行的整個時間内，隻要變量值發生了變化或者模式的狀态發生了改變，就産生了一個事件，該事件服務提供者(某裝置的某個服務)會把該事件向整個網絡進行多點傳播（multicast）。而且，CP也可以事先向事件伺服器訂閱事件資訊，就像RSS訂閱一樣，保證将該CP感興趣的事件及時準确地單點傳播傳送過來（unicast）。
下面是一個Unicast eventing 的architecture圖，CP是subscriber，伺服器是publisher。
subscriber(通常是個CP)向publisher(通常是個service)發送訂閱消息(subscribe)，更新訂閱消息(renewal)，退訂消息(cancel)。publisher向subscriber推送訂閱(event:SIDX)。
事件的訂閱和推送這塊用的通信協定是GENA(General Event Notification Architecture) ，通過HTTP/TCP/IP傳送。GENA的格式就不細說了，詳細請參閱UPnP-arch-DeviceArchitecture-v1.1。下面列出訂閱過程供參考：
1.訂閱。subscriber發送訂閱消息主要包含事件URL(evenURL)，服務ID号(service identifier),這兩個可以在裝置服務描述資訊中找到，以及寄送位址(delivery URL)。還會包含一個訂閱期限(duration)。
2.成功訂閱。publisher收到訂閱資訊，如果同意訂閱的話就會為每個新subscriber 生成一個唯一的subscriber identifier并記錄subscriber 的duration和delivery URL。還會記錄一個順序增長event key用來保證事件确實推送到subscriber那裡。比如說有個新事件，key是6，然後把這個事件推送給某個subscriber那裡，subscriber那裡記錄的event key是4，現在收到的事件key是6，他就知道他沒收到key為5的事件，這樣他就向publisher索要漏收的事件，進而保證雙方變量值或狀态的一緻。
3.首次推送。訂閱同意訂閱之後還會向subscriber發送一組初始變量或狀态值，進行首次同步。
4.續訂。subscriber必須在訂閱到期前發送renewal續訂。
5.訂閱到期。訂閱到期後publisher會把subscriber的資訊删除，subscriber又回到訂閱前的狀态。
6.退訂。subscriber發送cancel資訊将會取消訂閱。subscriber因非正常退出網絡的話，則不會退訂直到訂閱到期。
7.訂閱操作失敗資訊。當訂閱、續訂和退訂不能被publisher接收或者出現錯誤時，publisher會發送一個錯誤代碼。
再簡單說下多點傳播（multicast，或者叫多點傳播，本文中兩者等同）和單點傳播。even的多點傳播采用UDP/IP，和SSDP一樣，就是端口号變成了7900。下圖是幾個協定的所處層的位置，可以清楚地看到它們之間的差别。首先關于IP多點傳播，要知道隻存在UDP多點傳播，沒有TCP多點傳播這回事。為什麼呢？多點傳播的重點是提高網絡效率，将同一資料包發送給盡可能多的可能未知的計算機。像這種對網内所有裝置的頻繁消息通知采用多點傳播是為了減小網絡負擔，SSDP也是一樣。
但是SSDP和multicast這種采用UDP方式的協定存在一個問題，就是可靠性不夠。解決的辦法就是多次通知，但是一般不會超過三次以免增加網絡負擔，這樣就得不償失了。像SSDP的話會采用定期廣播advertice的方式，使各種各樣原因而沒收到advertice的CP重新獲得advertice，又解決了UDP丢包的問題。
前面在尋址的時候用到的DHCP用的是UDP廣播(broadcast)。當一個新的裝置加入網絡時，他想要分個IP，但又不知道DHCP伺服器的IP位址，是以他就在網内廣播，用255.255.255.255位址來通知所有計算機。DHCP伺服器收到請求後會為他申請并傳回一個IP位址。
（6）表達(Presentation)
隻要得到了裝置的URL，就可以取得該裝置表達的URL，取得該裝置表達的HTML，然後可以将此HTML納入CP的本地浏覽器上。這部分還包括與使用者對話的界面，以及與使用者進行會話的處理。是以裝置表達可以了解成“遙控器”。這部分定義描述界面，規範界面以及傳輸界面内容。遠端界面是供CP使用者使用的，CP使用者通過遠端界面完成裝置描述的擷取，控制裝置，訂閱收取裝置事件等等。
好了， 到此，UPnP的工作過程的講解就結束了。總結一下：
UPnP分為6個步驟：
先是Addressing，裝置加入網絡，通過DHCP或者Auto-IP獲得IP；這部分在閃聯IGRS中是沒有定義的。
然後是Discovery，采用SSDP協定(UDP)，用multicast/unicast可以完成裝置的上線和離線通知群組播搜尋裝置，裝置用unicast(單點傳播,UDP)響應CP的搜尋。
往下是Description，通過HTTP協定(TCP)取回來是一個XML文檔，包含實體描述和服務描述；
再來是Control，采用SOAP協定(HTTP/TCP)，完成CP和devices之間的互動；
Eventing，采用GENA協定(HTTP/TCP)，完成裝置事件消息的訂閱和推送，為保證可靠性，故是TCP傳輸；事件的推送還有multicast (UDP)。
最後是Presentation。UPnP并沒有定義Presentation應該有哪些東西。一個HTML嘛，哪樣寫得好哪樣來！
擴充閱讀II UPnP AV(Audio/Video) Architecture
1.概述
下面是講解UPnP AV的會用到的一些對象術語。
Table1-1: Default Short Names for the AV Specifications
| AV Specification Name | Short Name |
| AVTransport | AVT |
| ConnectionManager | CM |
| ContentDirectory | CD |
| MediaRenderer | MR |
| MediaServer | MS |
| RenderingControl | RCS |
| ScheduledRecording | SRS |
在UPnP AV Architecture:1 (Document Version: 1.1) 文檔最開始的是這樣介紹的UPnP AV的：
本文檔描述了整體的UPnP AV 架構。該架構是UPnP AV裝置和服務範例的基礎架構。
該架構定義了 UPnP 控制端與 UPnP AV裝置基本互動，并且與特定裝置類型，媒體内容格式與傳輸協定無關。它支援如電視機，錄像機和 CD / DVD 播放機 / 自動點唱機，機頂盒，音響系統，MP3播放器，靜止圖像照相機，錄影機，電子相框，以及PC 等各種裝置，。該AV 架構允許裝置支援不同格式的多媒體格式（如MPEG2， MPEG4 和 JPEG 格式， MP3， Windows 媒體架構（ WMA ），位圖（BMP ）， NTSC 制式， PAL 制式， ATSC标準等）和多種類型的傳輸協定，如 IEC-61883/IEEE-1394，HTTP GET， RTP 協定， HTTP 的 PUT/郵政， TCP / IP 協定等）。以下各節描述了AV架構，以及如何各種UPnP AV裝置和服務協同工作，使各種最終使用者的情況。
“與特定裝置類型，媒體内容格式與傳輸協定無關”的内在含意是UPnP AV Architecture隻是提供了某種機制、模型，并沒有規定采用
何種技術來實作。技術的實作部分在 UPnP Device Architecture中有說明。
UPnP AV Architecture 定義了UPnP AV裝置間媒體傳送以及和CP間的互動。 UPnP AV 也定義了兩種 UPnP AV 裝置：UPnP AV MediaServer（ MS）和 UPnP AV MediaRender（MR ），以及他們具有的 4 種服務：
1)Content Directory Service(CDS)：能将可通路的媒體内容列出。
2)Connection Manager Service(CMS)：決定媒體内容可以通過何種方式由UPnP AV Media Server傳送至 UPnP AV MediaRender 。
3)AVTransport Service：控制媒體内容，比如播放、停止、暫停、查找等。
4)Rendering Control Service：控制以何種方式播放内容，比如音量、靜音、亮度等。
2.UPnP AV 裝置的互動模型
在裝置互動中， CP 是最重要的，因為 Action 通常是由CP發出的。UPnP AV 架構對 CP 的功能要求有 10條：發現 AV裝置，獲得所需的内容清單，獲得渲染器支援的協定/ 格式，比較/比對協定 / 格式，配置伺服器/渲染器，選擇所需的内容，開始内容傳輸，調整渲染參數，重複：選擇下一個内容，斷開伺服器和渲染器連接配接。
CP可以是MediaServer，也可以是MediaRenderer，也可能隻是遙控器remote control。根據CP的角色，歸納出下面三種常見的AV裝置互動模型：
(1)2-Box Pull Model
這種情況下CP是MediaRenderer，它可以是一個智能手機。CP主動向MediaServer索取媒體内容，獲得内容之後播放媒體，是拉(pull)的方式。
CP要做的是 獲得媒體清單>選取所需内容>比對協定 / 格式，MediaServer需要 選取所需内容>比對協定/格式>開始傳輸。
(2)2-Box Push Model
這種情況下CP是MediaServer，它可以是一個一體機。CP主動向MediaRenderer推送(push)媒體。
CP要做的是 本地選取所需内容>比對協定 / 格式>傳輸;MediaRenderer需要僅僅需要 比對協定/格式>接收媒體。
(3)3-box model
在 3-box model中，CP僅僅作為一個遙控器。也分為pull和push兩種方式。
當pull方式時，CP向Renderer發送Server及Server上所需媒體内容的URL，讓Renderer去取；
當push方式時，CP向Server發Renderer的URL，讓Server去向Renderer推送媒體内容。
本文結束。