這部分的內容大多來源於網絡及官方文檔，按照自己的翻譯理解整理所成。東西比較多，從頭慢慢看還是可以懂個大概的。
目錄：
一、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://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的商家必須按這個標准走。里面內容不太清楚，我現在沒有這個GUIDELINES，這個必須是DLNA會員才能拿到，我在的公司已經不是會員了，拿不到了，加會員要10000刀。改天看能不能找Cyberlink拿份coppy。
下面先大概看看DLNA的一些architecture，model和sdandard，都是從網上抄過來的，其他的等拿到Guidelines再補充。
四、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推送媒體內容。