这部分的内容大多来源于网络及官方文档，依照自己的翻译理解整理所成。东西比較多，从头慢慢看还是能够懂个大概的。
文件夹：
一、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)。数字媒体server，提供媒体获取、记录、存储和输出功能。同一时候，内容保护功能是对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映射(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上按button，效果是一样的。只是两者button的排列布局是不一样的。好了，如今到DLNA了，我想用手机当遥控器可不能够？当然能够，仅仅要获得TV上button的功能，传到手机上来，模拟一个遥控器就好了。DLNA如今想用浏览器的方式，TV给你一个XML，手机上就出现遥控器界面了，有点像webQQ，webOS那种，这样在手机上就不须要client了，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协议的port号。假设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（这类似于webserver，通过訪问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也能够事先向事件server订阅事件信息，就像RSS订阅一样，保证将该CP感兴趣的事件及时准确地单播传送过来（unicast）。
以下是一个Unicast eventing 的architecture图，CP是subscriber，server是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一样，就是port号变成了7900。下图是几个协议的所处层的位置，能够清楚地看到它们之间的区别。首先关于IP多播，要知道仅仅存在UDP多播，没有TCP多播这回事。为什么呢？多播的重点是提高网络效率，将同一数据包发送给尽可能多的可能未知的计算机。像这样的对网内全部设备的频繁消息通知採用多播是为了减小网络负担，SSDP也是一样。
可是SSDP和multicast这样的採用UDP方式的协议存在一个问题，就是可靠性不够。解决的办法就是多次通知，可是一般不会超过三次以免添加网络负担，这样就得不偿失了。像SSDP的话会採用定期广播advertice的方式，使各种各样原因而没收到advertice的CP又一次获得advertice，又攻克了UDP丢包的问题。
前面在寻址的时候用到的DHCP用的是UDP广播(broadcast)。当一个新的设备增加网络时，他想要分个IP，但又不知道DHCPserver的IP地址，所以他就在网内广播，用255.255.255.255地址来通知全部计算机。DHCPserver收到请求后会为他申请并返回一个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设备，获得所需的内容列表，获得渲染器支持的协议/
格式，比較/匹配协议
/ 格式，配置server/渲染器，选择所需的内容，開始内容传输，调整渲染參数，反复：选择下一个内容，断开server和渲染器连接。
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推送媒体内容。
本文结束。