LTE移动网络中的CDN关键技术研究的论文[五篇范例]

第一篇：LTE移动网络中的CDN关键技术研究的论文

1LTE移动网络CDN关键技术

1.1CDN节点下沉

传统的CDN网络边缘节点通常部署于城域网内，对移动用户而言，中间需要经过基站、核心网等多个网络设备，物理路径较长，容易影响用户体验，因此将CDN节点下沉至核心网/基站侧，可以很好地缩短用户访问路径，提高响应速度。在核心网、基站侧部署CDN节点的组网架构如图2所示。由于运营商基站数量较多，为节约建设成本，减少维护工作量，建议选择用户数量较多、容量较大的基站部署CDN节点，部署方式为“分光+透明缓存”方式。将透明缓存设备（如刀片插板）集成到基站设备中，通过端口镜像方式或DPI分光设备将用户流量引导至透明缓存设备，由透明缓存设备根据用户访问热度，自动缓存热点内容。当用户请求热点内容时，直接由透明缓存设备发送内容给用户；当用户请求非热点内容时，则由用户访问源网站获得内容。CDN透明缓存设备工作原理如图3所示。CDN透明缓存设备业务流程如下。①用户发送HTTP请求，访问内容A，经过DPI设备；②DPI设备对HTTP进行分析，将结果发送给CDN节点进行匹配；③CDN节点搜索本地是否已缓存内容A（由于内容A热度不够，并未缓存）；④CDN将“未缓存”结果返回给DPI设备；⑤DPI设备通知用户继续访问源网站；⑥用户直接连接到源网站，请求内容A；⑦源网站返回内容A；⑧CDN节点统计内容A的访问热度，达到一定阈值时，向源网站请求内容A；⑨CDN将获取到的内容A缓存到本地；⑩当有其他用户再次访问该内容时，重复第①~③步，由于CDN已透明缓存该内容，在第④步返回给DPI设备的结果是“已缓存”，因此用户直接向CDN节点获取内容A；輯訛輥CDN节点返回内容A给用户。

1.2DNS缓存加速

用户在访问网页、视频、音频、图片等内容时，请求的URL通常是域名而非IP地址，例如http://www.xiexiebang.com/XXXX…，需要通过本地DNS进行解析。在2G/3G移动网络中，DNS服务器通常部署于城域网内，每次DNS解析请求都要通过基站、核心网，因路径较长而造成DNS时延较大，如图4所示。在LTE网络中，随着CDN节点下沉到核心网或者基站侧，可在CDN节点中增加DNS缓存系统，对移动用户访问流量中的DNS协议进行监听。为保证DNS解析性能和可靠性，可设定一定的阈值，当本地DNS服务器运行正常时（例如响应时间低于阈值，解析成功率高于阈值），仍由本地DNS服务器进行解析；当本地DNS服务器运行异常时（例如响应时间高于阈值，解析成功率低于阈值），则由CDN节点的DNS缓存系统进行解析。CDN的DNS缓存系统需要定期与本地DNS服务器进行同步，更新域名和IP地址的映射关系。以图4为例估算，采用CDN的DNS缓存系统加速后，每次DNS解析均可节约80ms，8次DNS解析可节约0.64s，总体解析时间约为原先的2/3，可以有效地降低DNS解析时间，提升用户访问速度，优化服务质量和业务体验。

1.3内容源优化及终端适配

目前移动用户使用的终端通常为基于苹果iOS、谷歌Android等操作系统的智能手机，和电脑相比，具有屏幕尺寸小、分辨率低、CPU频率低、内存小、存储容量小等特点，而互联网的海量内容大部分都是为电脑访问设计的，并没有针对移动终端进行优化。因此，在LTE移动网络中，由CDN节点对内容源进行优化缓存，并且在移动终端中通过客户端或者插件进行适配，能够根据用户终端的情况，动态优化内容呈现方式，降低用户终端和基站、核心网间的数据流量，释放更多的空口资源。在CDN节点内部署内容优化模块或系统，该系统可配置白名单对用户经常访问的热门网站进行预处理优化和缓存，例如，针对网页、图片等元素生成多种屏幕大小和分辨率的备份内容。移动终端在请求内容时，可在URL里附加屏幕大小、分辨率、网络质量等参数，由CDN节点的内容优化系统进行分析并返回合适的备份内容。具体优化方法如下。跟踪系统调用发现哪些帧在处理上耗时较长，通过优化页面布局等，提升客户端页面渲染性能，减少客户端处理时间。减小接口数据返回，通过减少首页数据返回，以分页获取后续数据的方式进行优化，从而减小数据传输时间。针对部分功能项，如排行和分类列表等页面图片采用延迟加载。由于一屏只能展示4~5条数据，所以可以采用图片延迟加载，第一屏只下载要展示的相关数据图片，网络传输的数据大小将大为减小，后续图片在滚动页面时再进行加载。压缩列表页图标大小，在不影响用户的视觉体验下，通过对图标进行压缩优化，使图片大小减少。增加请求压缩，针对自升级等携带大请求数据的接口请求进行压缩处理，一方面可以节省用户流量，另一方面加快了客户端的响应速度。

1.4视频智能优化

根据互联网权威机构的分析，视频内容在4G时代将成为主流应用，其流量将超过Web浏览，在2017年将占据60%以上的流量，因此，针对视频内容进行智能优化对LTE移动网络有着重要的意义。优化方法包括以下内容。

（1）视频转码技术，与终端智能适配CDN节点将热门的视频内容转换为多种封装格式、编码格式和分辨率的视频文件，例如，将FLV转换为MP4、TS等封装格式，将MPEG2转换为H.264编码格式，将1080P转换为720P、D5等分辨率等，结合2.3节中提到的终端适配技术，当终端请求内容时携带相关参数，由CDN节点进行分析并返回适配的视频内容。

（2）视频动态缓冲，感知网络变化目前移动视频内容主要是基于HTTP，而且大部分采用的是HTTPProgressiveDownload方式，即渐进式边下载边播放方式，客户端会按照可用的最大速率请求下载视频内容直至完成。然而根据统计，有相当比例的用户只会观看视频的一部分，持续下载会占用空口资源。因此，在CDN节点中可采取视频动态缓冲技术，根据移动网络的变化情况动态调节，例如当网络繁忙时，控制用户下载速率，保证用户有10s以上的缓冲时间即可；当网络空闲时，让用户下载速率最大化，快速下载剩余的视频内容，尽快释放空口资源。

（3）HLS视频内容优化目前，移动视频内容部分采用了苹果公司的HLS（HTTPLiveStreaming）技术，即每个视频内容存在多种码率的副本，由客户端根据网络带宽情况动态选择相应的副本。视频内容的码率若是高清或者超高清可以达到10Mbit/s以上。对于LTE移动网络而言，一方面容易造成用户带宽过高占用空口资源，另一方面手机屏幕较小难以体现超高清视频优势，因此可以在CDN节点中对存储的HLS视频内容进行优化，分析HLS视频内容的M3U8索引文件，删除其中不适用的码率信息以及对应的副本文件。对HLS视频内容进行精简，可以优化用户带宽和空口占用率，并且节省了CDN节点宝贵的存储空间。

1.5计费系统改造

在2G/3G/4G移动网络中，计费系统通常部署于核心网，如果将CDN节点下沉至核心网，不会影响计费系统统计用户实际消耗的流量，但是如果将CDN节点下沉至基站，则用户的实际流量中有一部分是由基站的CDN节点缓存提供，未经过核心网计费系统，会造成运营商的直接经济损失。因此，需要对计费系统进行改造，满足CDN节点下沉到基站的需要。由于计费系统实现较为复杂，若将计费系统也下沉到基站，首先技术难度较大，其次建设和运营维护成本较高，可通过在基站CDN节点中部署子系统，统计用户的流量使用情况，并定期以话单格式上传至核心网计费系统实现同步。

2结束语

随着LTE移动网络的大规模建设和部署，由于LTE网络高带宽的特点，未来将出现大量大流量、高带宽的业务。对运营商而言，频繁扩容LTE网络会消耗巨额的建设资金和运营维护成本，性价比不高，基于已有的LTE网络进行流量优化，一方面可以提高LTE网络使用效率，节约扩容资金；另一方面可以提升服务质量，增强用户体验。本文对LTE移动网络中的CDN关键技术进行了深入研究，提出了将CDN节点下沉至核心网/基站侧，对DNS解析进行缓存加速，对内容源进行优化并和终端智能适配，对视频内容进行智能优化，通过话单同步实现计费系统改造等关键技术，能够有效降低LTE骨干网和核心网的流量压力，提高空口资源利用率，缩短用户请求的响应时间，改善用户的4G业务感知。本文介绍的方法对LTE移动网络改动较小，以较小的建设和改造成本带来较大的经济效益，具有良好的实用性，可为中国电信等运营商建设和部署LTE移动网络提供参考依据。

第二篇：网络中流媒体关键技术研究

网络中流媒体关键技术研究

2004-2-9全新3G技术管理培训--摩托罗拉工程学院

张鲲 南京邮电学院

摘要 流媒体技术是在数据网络上以流的方式传输多媒体信息的技术。随着宽带网络的发展，流媒体技术的相关应用必将成为未来高速网络的主流应用之一。本文就流媒体的一些关键技术、机制和相关协议等方面做了较为详细的介绍。

关键词 流媒体 QoS 视频压缩 连续媒体分布服务 媒体同步引言

近年来，随着计算机技术、压缩技术以及网络技术的发展，网络中的流媒体业务也得到了飞速的发展和应用。所谓流媒体就是指在Internet/Intranet中使用流式传输技术的连续时基媒体。本文中着重介绍视频流。目前在Internet上传输视频还有许多困难，其根本原因在于Internet的无连接每包转发机制主要是为突发性的数据传输而设计的，不适用于对连续媒体流的传输。为了在Internet上有效地、高质量地传输视频流，还需要多种技术的支持，例如基于视频的压缩编码技术、应用层QoS技术、连续媒体分布服务、流服务器、媒体同步技术和相关协议等。

其中，原始视/音频经过视/音频压缩算法的预压缩存储在存储设备中。响应客户请求时，流服务器从存储设备中获得视/音频数据，应用层QoS控制模块根据网络状态和QoS要求来改变视/音频比特流。然后通过传输协议把压缩过的比特流打包并且发送到网上。由于拥塞数据包可能出现丢包或者过度时延。为了提高视/音频的传输质量，网络中配置了连续流媒体分布式服务。对于成功传输的数据包，它们首先通过传输层，然后在进行视/音频解码前经过应用层处理。为了获得在播放中的视频和音频的同步，还需要媒体同步机制。从上图中可以看出，这六个部分有着紧密的联系而且都是流媒体结构的组成部分。流媒体中的关键技术

2.1 视频压缩及编码

目前网络是异构性的，缺乏QoS质量控制，并且带宽也在很大范围内变化。传统的不可扩展性视频编码的目标是将视频压缩成适合一个或者几个固定码率的码流，是面向存储的，因此不适合网络传输。为了适应网络带宽的变化，面向传输的可扩展性编码的思想应运而生。可扩展性编码[2]就是将多媒体数据压缩编码成多个流，其中一个可以独立解码，产生粗糙质量的视频序列，它适应最低的网络带宽，称为基本层码流；其他的码流可以按层为单位在任何地点截断，称为增强层，用来覆盖网络带宽变化的动态范围，它们不可以单独解码，而只能与基本层和它以前的增强层联合在一起解码，用来提高观看效果。因此，可扩展

性码流具有一定的网络带宽适应能力。

可扩展性编码主要分为时域可扩展性编码、空域可扩展性编码和质量可扩展性编码。可以选择在时间、空间和信噪比（SNR）中的一个或者几个方面实现扩展。考虑到编码效率和复杂性两方面，MPEG组织采纳了精细可扩展性编码（FGS）和渐进的精细可扩展性编码（PFGS）[3]。精细可扩展性视频编码采用位平面（bitplane）编码，它的基本层使用基于分块运动补偿和DCT变换的编码方式达到网络传输的最低要求，增强层使用位平面编码技术对DCT残差进行编码来覆盖网络带宽的变化范围，它每一帧的增强层码流可以在任何地点截断，解码器重建的视频质量和收到并解码的比特数成正比，它可以实现连续的增强层速率控制。FGS虽然具有很好的可扩展性，但是效率太低，PFGS在保留了FGS所具有的网络带宽自适应和错误恢复能力的同时，还有效地提高了编码效率。但是可扩展性编码的效率较非可扩展性编码而言，还有一定差距。为了进一步压缩FGS和PFGS的基本层码流，有专家提出一种称为精细的空域可扩展性（Fine-Granularity Spatially Scalable,FGSS）的视频编码算法，使低分辨率和高分辨率的增强层码流都可以在任何地点截断，具有极强的网络带宽适应能力和错误恢复功能，同时保持了空域可扩展性编码的多分辨率特性，它可以满足拥有不同网络带宽和不同分辨率接收设备的许多用户的需求，性能得到了更大的提高。

结合多种视频编码技术来适应网络上的QoS波动是今后可扩展性视频编码的发展方向。比如，可扩展性视频编码可以适应网络带宽的变化；错误弹性编码可以适应丢包；DCVC（Delay Cognizant Video Coding）可以适应网络时延。这三种技术的结合可以更好地提供一种应对网络QoS波动的解决方案。

2.2 应用层QoS控制技术由于目前的Internet只提供Best-effort的服务，所以需要通过应用层的机制来实现QoS的控制。QoS控制技术主要集中在对网络带宽的变化进行响应和处理分组丢失的技术上，主要可以分为两类：拥塞控制技术和差错控制技术。

拥塞控制的目的是采用某种机制应对和避免网络阻塞，降低时延和丢包率。常用的拥塞控制机制有速率控制和速率整形。对于视频流，拥塞控制的主要方法是速率控制。速率控制机制试图使一个视频连接的需求与整个连接链路的可用带宽相匹配，这样可以同时使网络拥塞和包丢失率达到最小。速率控制机制主要包括基于源端的、基于目的的以及混合速率控制。在基于源端的控制机制中，视频源端收集反馈信息，进行控制计算并采取相应的控制动作。这种方法在因特网中被率先采用,但是在异构网络中的运行情况并不是很好。基于目的端的控制机制则主要根据所接收的视频流的状况向上层反映相应的统计信息，实时调整缓冲及播放内容，并力图使节奏均匀，这种机制使用较少。混合性速率控制的方法兼有前二者的特点，即目的端增加减少通道，而源端同时根据反馈调整各个通道的速率。混合速率控制方法的一个例子是目标集分组的方法。

拥塞控制只能减少数据包的丢失，但是网络中不可避免的会存在数据包丢失，而且到达时延过大的分组也会被认为没有用而被丢弃，从而降低了视频质量。要改善视频质量就需要一定的差错控制机制。差错控制机制包括：

（1）前向纠错（FEC）：FEC是通过在传输的码流中加入用于纠错的冗余信息，在遇到包丢失的情况时，利用冗余信息恢复丢失的信息。它的不足是增加了编码时延和传输带宽。

（2）延迟约束的重传。通常流的播放有时间限制，因此，仅有当重传的时间小于正常的播放时间时，重传才是有价值的。

（3）错误弹性编码（Error-Resilient Encoding）：在编码中通过适当的控制使得发生数据的丢失后能够最大限度的减少对质量的影响。在Internet环境下，最典型的方法是多描述编码（MDC）。MDC把原始的视频序列压缩成多位流，每个流对应一种描述，都可以提供可接受的视觉质量。多个描述结合起来提供更好的质量。该方法的优点是实现了对数据丢失的鲁棒性和增强的质量。其缺点是相比单描述编码（SDC），它在压缩的效率上受到影响。而且由于在多描述之间必须加入一定的相关性信息，这进一步降低了压缩的效率。

（4）错误的取消（concealment）：错误的取消是指当错误已经发生后，接受端通过一定的方法尽量削弱对人的视觉影响。主要的方法是时间和空间的插值（Interpolation）。近年来的研究还包括最大平滑恢复，运动补偿时间预测等。

2.3 连续媒体分布服务

连续媒体分布服务（continuous media distribution services）的目的是在Internet 尽力服务的基础上提供QoS和高效的音/视频传输，包括网络过滤（Network Filtering）、应用层组播（Application-Level Multicast）、内容复制（Content Replication）等，下面分别进行详细介绍。

网络过滤：网络过滤是拥塞控制的一种，不仅可以提高视频质量，还可以提高带宽利用率。不同于发送端的速率整形，网络过滤是在流服务器和客户端之间的传输路径上通过虚拟信道连入过滤器，该过滤器根据网络的拥塞状态实现速率的整形。网络过滤通常采用的是丢帧过滤器（frame-dropping filter），其基本方法是客户端根据网络丢包率向过滤器发送请求来增减丢帧速率，以调节媒体流的带宽。这种速率整形可以在拥塞点进行，这样可以提高速率控制的效率和拥塞控制的响应时间。

应用层组播：IP层的组播存在诸如可扩展性、网络管理和对高层应用的支持（例如差错控制，流量控制和拥塞控制）等屏障。应用层组播机制打破了IP组播的一些障碍，其目的在于构建网络上的组播服务，可以以更灵活的方式实现组播控制。它允许独立的CSPs和ASPs等建立它们的Internet组播网络，这些组播网络可以互连成为更大的媒体组播网络。媒体组播网络可以利用内容分布网络的互连，通过在不同种类的服务提供者（比如ISPs、CSPs和ASPs等）之间的应用层的对等关系来构建。媒体组播网络中每个具有组播能力的节点称为媒体桥（MediaBridge），它做为应用层的路由。每个媒体桥和一个或多个相邻的媒体桥通过明确的配置互连，这个互连建立了应用层重叠拓扑。媒体桥在媒体组播网络中用分布式应用层组播路由算法来确定一条优化的虚拟组播路径。如果网络不通或者过度拥挤，媒体组播网络会自动的根据应用层路由规则来重新确定路径。并且，只有当下游客户端需要某媒体内容时，媒体桥才会传输它。这就确保了不管客户端的数目而只有一个媒体流，从而节约了网络带宽。

内容复制：内容/媒体复制是提高媒体传输系统可扩展性的一项重要技术。内容复制具有以下优点：

（1）降低网络连接的带宽消耗。

（2）减轻流服务器负荷。

（3）缩短客户端时延。

（4）提高有效性。它主要有两种形式：caching（缓存）和mirroring（镜像）。镜像是把原始媒体内容拷贝到网络上其他分散的备份服务器中。用户可以从最近的备份服务器上获得媒体数据。缓存则是从原服务器中获得媒体文件，然后传输给客户端，同时在本地做备份。如果缓存中已经存在客户端需要的数据，缓存就会把本地拷贝传给用户而不是从传送原服务器中的媒体数据。

2.4 流服务器视频服务器在流媒体服务中起着非常重要的作用。当视频服务器响应客户的视频流请求以后，它从存储系统读入一部分视频数据到对应于这个视频流的特定缓存中，再把缓存的内容通过网络接口发送给相应客户，保证视频流的连续输出。目前存在三种类型的视频服务器结构[4]：

（1）通用主机方法。采用计算机主机作为视频服务器。它的主要功能是存储、选择、传送数据。缺点是系统成本高而且不利于发挥主机功能。

（2）紧耦合多处理机。把一些可以大量完成某指令或者专门功能的硬件单元组合成的专用系统级联起来，就构成了紧耦合多处理机实现的视频服务器。这种服务器费用低、性能高、功能强，但是扩展性较差。

（3）调谐视频服务器。这种服务器主板上有一个独特微码的嵌入式仿真器控制。通过在主板中插入更多的服务通路，可以方便地进行扩展。

对于流服务器，如何更有效支持VCR交互控制功能；如何设计磁盘阵列上多媒体对象高效可靠的存储和检索；如何设计更好的可伸缩多媒体服务器；如何设计兼有奇偶和镜像特性的容错存储系统是目前研究的重点。

2.5 媒体同步

所谓媒体同步是指保持一个数据流或者不同媒体流之间的时间关系。通常有三种类型的 同步控制：流内（intra-stream）同步、流间（inter-stream）同步和对象间（inter-object）同步。由于网络时延，导致媒体流在传输过程中失去同步关系，媒体同步机制可以确保客户端正确地恢复媒体流的同步。媒体同步机制实际上就是在媒体内或者媒体间说明其时间关系。说明时间关系的方法有：基于间隔的方法、基于轴的方法、基于控制流的方法和基于事件的方法。对于连续媒体，应用最为广泛的说明方法是基于轴的说明或时间戳。时间戳法是在每个媒体的数据流单元中加进统一的时间戳或时间码，具有相同时间戳的信息单元将同时予以表现。在发送时，将各个媒体都按时间顺序分成单元，在同一个时间轴上，给每个单元都打上一个时间戳，处于同一时标的各个媒体单元具有相同的时间戳。在各个媒体到达终端后，让具有相同时间戳的媒体单元同时进行表现，这样就得到了媒体之间同步的效果。对与终端系统而言，同步机制包括阻止（preventive）机制和纠正（corrective）机制。前者是主要通

过减小延迟和抖动来减少同步错误，后者主要是在发生同步错误之后恢复同步。考虑到Internet传输的延迟随机性，同步错误是不可避免的。因此，在接受方的错误补偿是必须的。

另外，同步多媒体集成语言SMIL（Synchronized Multimedia Integration Language）是由3W(World Wide Web Consortium)组织规定的多媒体操纵语言。可以实现多个流和文本信息在播放时的时间同步控制和空间位置布置。通过SMIL还可以实现一定的用户交互功能。

2.6 流媒体相关协议

2.6.1 实时传输协议（RTP）与实时传输控制协议（RTCP）

RTP(Real-time Transport Protocol)和RTCP（Real-time Control Protocol）都是基于IP的应用层协议。RTP为实时音/视频数据提供端到端的传送服务，包括有效载荷类型标识、序列标号、时间标签和源标识，可以提供时间信息和实现流同步。由于TCP中重传机制会引起时延，通常RTP运行于UDP之上，但是也可以在TCP或者ATM等协议之上运行。RTP本身并不提供可靠的传送机制，也不提供流量控制或者拥塞控制，而是通过与RTCP配合使用，使传输效率最佳。RTCP用来监视服务质量和在会议过程中交换信息。它提供QoS反馈、参与者标识、控制包缩放、媒体间同步等服务。RTCP包中包含已发数据包的数量、丢失数据包数量等统计资料。服务器可以根据这些信息动态的改变传输速率甚至有效载荷类型。

2.6.2 实时流协议（RTSP）RTSP（Real-time Streaming Protocol）是由RealNetworks和Netscape共同提出的一个应用层协议。它可以在媒体服务器和客户端之间建立和控制连续的音/视频媒体流，协同更低层协议RTP、RSVP等一起来提供基于Internet的整套流式服务。RTSP提供了一种可扩展框架，使得可控的、点播的实时数据的传送成为可能。它提供用于音频和视频流的“VCR模式”远程控制功能，例如暂停、快进、快退和定位。支持单播和组播。RTSP还提供选择发送通道的方法（如UDP、组播UDP和TCP）和基于RTP的发送机制。RTSP像是媒体服务器和客户端之间的“网络远程控制”，它提供多种服务，如从媒体服务器上检索媒体、邀请媒体服务器进入会议、添加媒体到现成节目。RTSP在语法和操作上类似于HTTP，因此许多HTTP的扩展机制都可以移植于RTSP上。在RTSP中，每个节目和媒体流由RTSP URL确定，全部节目和媒体特性都在节目描述文件中给予了描述，包括编码、语言、RTSP URLs、目的地址、端口号以及其他参数。但是，不同于HTTP的无状态和非对称，RTSP是有状态的、对称的协议。RTSP的服务器保持会话状态以连接RTSP流的请求，并且服务器和客户端都可以发出请求。

2.6.3 资源预留协议（RSVP）资源预留协议[5]（Resource Reserve Protocol）是运行于传输层的一个网络控制协议。RSVP允许数据流的接受方请求特殊的端到端QoS。RSVP是非路由协议，它同路由器协同工作，在传输路径的路由器上预留必要的带宽，减少网络的时延和抖动。RSVP的流程是单一的，并不区分发送方和接受方，且支持单播和组播，适应于可变成员个数和路由。RSVP领域的发展非常迅速，但是目前它的应用只限于在测试的小Intranet网络上。结论技术的进步和用户的需求促进了流媒体应用的迅速发展。在远程教育、数字图书馆、电子商务、视频点播、交互电视、远程医疗、网络音/视频、实时多媒体会议等方面，流媒体技术都起到很重要的作用。本文对网络中流媒体业务的关键技术和相关协议做了研

究，并探讨了未来流媒体技术发展的方向。我们相信，随着流媒体应用的不断普及，宽带流媒体技术及其应用必然会在未来的网络中发挥更重要的作用，并在一定程度上改变人们使用网络的方式。

参考文献

[1] Dapeng Wu,Yiwei Thomas Hou,Wenwu Zhu,Ya-Qin Zhang,Jon M.Peha.Streaming Video over the Internet:Approaches and Directions [J].IEEE Transactions on Circuits and Systems for Video Technology,2001;11(3):282-300

[2] Marta Mrak,Mislav Grgic,Sonja Grgic.Scalable Video Coding in Network Applications[C].In:Video/Image Processing and Multimedia Communications 4th EURASIP-IEEE Region 8 International Symposium on VIPromCom,2002

[3] Feng Wu,Shipeng Li,Ya-Qin Zhang.Progressive Granular Scalable(PFGS)Video Using Advance-Predicted Bitplane Coding(APBIC)[C].In:the Proceedings of the 35th Annual Hawaii International Conference on System Sciences(HICSS35),Hawaii,USA,2002

[4] 吴国勇,邱学刚,万燕仔.流媒体技术与应用[M].北京:北京邮电大学出版社,2001

[5] Lixia Zhang,Stephen Deering,Deborah Estrin,Scott Shenker,Daniel Zappala.RSVP: A New Resource ReSerVation Protocol[J].IEEE Communications Magazine,2002,40(5):116-127

第三篇：甘肃移动LTE网络6月测试报告—凉州区

甘肃移动LTE网络6月试报告

武威市凉州区

目录

1.1 DT测试分析.............................................................................................1.1.1 RSRP分布图...................................................................................1.1.2 SINR分布图....................................................................................1.1.3 DL分布图........................................................................................1.1.4 UL分布图........................................................................................1.2 问题区域...................................................................................................1.2.1平贵花园附近路段弱覆盖.................................................................1.2.2 西环路到公园路转弯路段弱覆盖......................................................1.2.3 文化路古浪县第五中学附近路段弱覆盖和切换不及时导致SINR差...........................................................................................1.2.4 建设路到西环路拐弯处弱覆盖和模三干扰导致SINR差...................1.3 问题总结与建议........................................................................................1.3.1 问题总结..........................................................................................1.3.2 建议.................................................................................................1.1 DT测试分析

1.1.1 RSRP覆盖分布图 1.1.2 SINR分布图

1.1.3 PDCP DL分布图 1.1.4 PDCP UL分布图 1.2问题区域

1.2.1武威市凉州区武威监狱附近越区覆盖RSRP差SIINR差

问题描述：武威市凉州区武威监狱附近越区覆盖。

问题分析：经过分析该点占用武威凉州区成功学校-2（PCI：130；RSRP-98）小区与武威凉州区武威监狱-1（PCI：312;RSRP-88）小区信号。

处理建议：建议下压武威凉州区成功学校-2小区方位角控制越区覆盖，并把武威凉州区武威监狱-2小区RS功率提升2db,增强覆盖。

1.2.2武威市凉州区熊猫公寓附近弱覆盖

问题描述：武威市凉州区熊猫公寓附近弱覆盖

问题分析：该问题点占用武威凉州区宋家园-1（PCI：354；RSRP：-106）小区信号，其邻区的RSRP也都较差此路段东侧有高楼阻挡，导致该问题路段弱覆盖。

解决方案：将武威凉州区宋家园-3（PCI：356）的方位角调整为340度，并把RS功率提升3db，以加强该问题路段的覆盖。1.2.3武威汽车北站处弱覆盖

问题描述:武威汽车北站处弱覆盖

问题分析：经过分析该路段占用武威凉州区北美-1（PCI：324；RSRP-96）小区信号，由于该弱覆盖路段距离基站316米，信号难以覆盖至此。

解决方案：需要核实该基站的方位角，调整武威凉州区北美-3小区的方位角或者拉远3小区解决弱覆盖问题。

1.2.4祁连大道天瑞花苑处弱覆盖RSRP差

问题描述：祁连大道天瑞花苑处弱覆盖RSRP差

问题分析：经分析该点占用武威凉州区国海商厦-3（PCI：343；RSRP-100）小区信号。由于该点距离武威国海商厦基站428米，周围楼宇较高信号难以覆盖至此。

处理建议：

1、核实武威国海商厦的方位角与下倾角，调整-1小区的方位角至60度，下倾角减小2度增强覆盖。

2、调整武威凉州区建安宾馆-3小区的方位角至270度并将下倾角减小2度增强覆盖。1.2.4靶场路靶场社区居委会附近RSRP差

问题描述：靶场路靶场社区居委会附近RSRP差

问题分析：该弱覆盖路段占用武威凉州区十八中-3（PCI：350；RSRP-95）小区信号和武威凉州区国资委-1（PCI：401）小信号。由于靶场路道路狭小附近楼层较高信号难以覆盖至此。

解决方案：

1、调整武威凉州区十八中-3小区的方位角至280度，下倾角减小2度增强覆盖。

2、调整武威凉州区国资委-2小区的方位角至120度，下倾角减小2度增强覆盖。

1.2.5擂台东路附近弱覆盖

问题描述：擂台东路附近弱覆盖

问题分析；该店占用武威凉州区万通小区-2（PCI：16;RSRP-99）小区信号，与武威凉州区新鲜七组-3（PCI：203）小区信号。由于武威凉州区万通小区-2越区覆盖大约935米。武威凉州区新鲜七组-3小区周围高楼较多无法覆盖至此。

处理建议：

1、下压武威凉州区万通小区-2小区的下倾角，控制越区覆盖。

2、减小武威凉州区新鲜七组-3小区的下倾角。增强覆盖。1.2.6解放军第十医院后面的巷子弱覆盖RSRP差

问题描述：解放军第十医院后面的巷子弱覆盖RSRP差。

问题分析：经过分析该路段占用武威凉州区乐巢乐巢宾馆-1（PCI：244；RSRP-100）小区余武威凉州区林茗香茶府-2（PCI；316）小区信号。由于巷子里面道路狭窄建筑物密集，周围基站都难以覆盖至此。

解决方案：

1、调整武威凉州区林茗香茶府-2小区方位角230度下倾角减小2度增强弱覆盖。

2、减小武威凉州区乐巢宾馆-1小区的下倾角增强覆盖。

1.2.7市政局北边的二环南东路弱覆盖RSRP差

问题描述：市政局北边的二环南东路弱覆盖RSRP差。

问题分析：该路段占用武威凉州区新鲜七组-1（PCI：50；RSRP）小区与武威凉州区市政局-1（PCI：199）小区信号。武威凉州区新鲜七组-1距离弱覆盖路段433米切是旁瓣信号信号覆盖至此损耗大。

解决方案：

1、调整武威凉州区新鲜七组-2小区的方位角至90度；下倾角减小2度减小弱覆盖。

2、调整武威凉州区市政局-1小区的下倾角至4度增强覆盖。1.2.8北关东路与二环东路交叉口处弱覆盖RSRP差

问题描述：北关东路与二环东路交叉口处弱覆盖RSRP低于-90。

问题分析：弱覆盖路段距离基站900多米信号难以覆盖至此，建议增加基站增强覆盖。解决方案：在北关东路与二环东路交叉口处增加基站

1.2.9武威凉州区图书馆处弱覆盖RSRP差

问题描述：武威凉州区图书馆处弱覆盖RSRP差。

问题分析：该弱覆盖路段周围楼宇较高武威凉州区人民医院-3（PCI：53；RSRP:-99）小区信号无法覆盖至此，周围站点武威凉州区浙江大厦-2（PCI：10）小区和武威凉州区电信局-1（PCI：63）小区信号无法覆盖至此。

解决建议：

1、调整武威凉州区人民医院-1小区的方位角至0度下倾角减小2度，作为主小区。

2、调整武威凉州区电信局-3小区的方位角至270度下倾角减小2度怎强覆盖。1.2.10迎宾大道祥泰宾馆附近弱覆盖RSRP差

问题描述：迎宾大道祥泰宾馆附近切换不及时RSRP差SINR差

问题分析：经过分析武威凉州区火车站（共享电信）-3（PCI：197；RSRP-113）小区是主小区，武威凉州区祥泰宾馆-2（PCI:414；RSRP-92）小区是邻小区；由于切换不及时导致RSRP和SINR变差。

解决方案:添加武威凉州区火车站（共享电信）-3小区与武威凉州区祥泰宾馆-2小区的邻居关系，并且重新设置A3事件的切换门限。

1.2.11成功学校东面的小巷子切换不及时ISNR差

问题描述：成功学校东面的小巷子切换不及时ISNR差

问题分析：分析后武威凉州区农机监理-2（PCI343 ；RSRP-83； SIRN-9）小区向武威凉州区成功学校-1（PCI 129）小区切换不及时导致SIRN差。

解决方案：

1、调整武威凉州区成功学校-1小区的方位角至170度增强覆盖。

2、下压武威凉州区农机监理-2小区的下倾角至6度。减少越区覆盖。1.2.12武威凉州区北关西路与民族街交叉口处SINR差

问及描述：武威凉州区北关西路与民族街交叉口处SINR差

问题分析：该路段占用武威凉州区八中-1（PCI：266:；RSRP：-106；SINR：3）小区北关西与武威凉州区建安宾馆-2（PCI:22；RSRP-93）小区信号。路与民族街交叉口周围站点较密信号杂乱干扰严重。

减小威武凉州区建安宾馆-2小区的方位角增强覆盖。

1.2.13和平街与署东巷较差口出SINR差

问题描述：和平街与署东巷较差口出SINR差

问题分析：该路段占用武威凉州区凉州医院-3（PCI 431； RSRP-91 ；SINR-5）小区信号与武威凉州区小北街-2（PCI 277； RSRP-98；ISNR 5）小区信号。由于该点周围楼层较高较密，信号难以覆盖至此。

解决方案：

1、检查周围站点的邻区关系保证切换正常。

2、调整武威凉州区北小街-2（PCI 277）的下倾角增强覆盖。1.2.14武威凉州区福利院附近SIRN差

问题描述：武威凉州区福利院附近SIRN差。

问题分析：该路段占用武威凉州区福利院-1（PCI197；RSRP-83； SINR-7）由于武威凉州区福利院基站一小区的PCI是197、二小区196、三小区195与周围站点PCI相反，存在干扰。

解决方案：

1、重新规划武威凉州区福利院基站的PCI，消除干扰。

2、调整武威凉州区福利院-1小区的方位角至0度。下倾角减小2度。

3、核查武威凉州区-1小区与武威凉州区东升小区-2小区的邻区关系，保证切换正常。

1.2.15二环西路与二环南路交叉口处SIRN差

问题描述：二环西路与二环南路交叉口处SIRN差

问题分析：分析后得武威凉州区知天一时代城-3（PCI 113；RSRP-101；SINR-12）小区向武威凉州区枣园-1（PCI 174；RSRP-97）小区未及时切换导致SINR变差。解决方案：

1、添加武威凉州区知天一时代城-3小区与武威凉州区枣园-1小区的邻区关系，保证正常切换。

2、调整武威凉州区枣园-1小区的方位角为10度下倾角减小2度增强覆盖。1.2.16祥泰宾馆附近SINR差

问题描述：凉州区祥泰宾馆附近SINR差。

问题分析：经过分析该路段占用武威凉州区火车站（共享电信）-3（PCI 197；RSRP-100；SINR-13）小区信号。由于切换不及时导致SINR变差。解决方案：

1、添加武威凉州火车站（共享电信）-3小区与武威凉州区祥泰宾馆-2小区的邻区关系。

2、重新设置添加武威凉州火车站（共享电信）-3小区到武威凉州区祥泰宾馆-2小区的切换门限。

第四篇：济南移动LTE网络国庆保障总结(中兴)

济南移动障总结

LTE网络国庆保

2014年10月10日 1 说明

2014年10月1日~7日国庆LTE网络质量保障是济南移动LTE网络建网以来的第一次国庆节保障，经历了济南大学开学的保障之后，有一次话务集中的保障，与大学开学营销不同的是，此次主要话务可能集中在汽车站、火车站及部分旅游景点，人员复杂、较多、终端类型也参差不齐，在中兴区域主要分布有火车站、汽车站及重要景区。保障流程

1、对所有热点区域如车站、景区、购物区、重要干线等周围站点进行扩容准备，提出扩容需求扩容双载波，同时开启负荷均衡策略。

2、对已经确定的高话务区域，今天提交给省公司进行升级，升级完毕后开启高负荷应对策略的参数，由于有些定时器参数不在集团规定范围，所以有些可能的大话务区域在指标监控当天7点前进行修改，晚上进行回退。

3、对已经确定的高话务区域提前进行测试摸底，避免小区出现其他问题影响用户感知。

4、每天提取重要站点的告警，及时发送给维护部门进行排障处理。

5、安排现场值班人员，包括前台和后台，前台在现场值班待命，后台人员在后台值班监控指标，尤其是拥塞、告警的小区。

6、早晨7点前后台人员到位，检查所有站点告警，退服、闪断、GPS故障等重要的告警及时通知维护部门进行排查。

7、15分钟粒度统计小区的RRC建立成功率、ERAB建立成功率、切换成功率、CSFB回落成功率、掉线率等指标，发现有拥塞导致的RRC失败尽快进行保障参数开启工作，由于有些保障参数与集团规范不一致，如定时器T302，T300等，晚上需要进行回退。

8、对于前台突发性投诉或者站点指标异常的小区，后台进行参数检查、邻区检查等优化完毕后，通知前台人员进行验证测试。

9、重点关注汽车站、火车站、旅游景区等VIP站点。

10、及时关注全网的流量、用户数、指标等变化情况，做好第二天值班人员的工作交接工作，如当天进行小区修改的明细、指标变化情况通过邮件和电话告知。济南LTE网络运行质量分析

此次国庆节保障期间省公司对拥塞小区的通报的标准如下： 1）RRC建立差:按小时统计，RRC连接建立失败次数大于200 2）ERAB建立差:按小时统计，ERAB连接建立失败次数大于200 3）接通率差：按小时统计，RRC连接请求次数大于200，ERAB连接请求次数大于200，无线接通率小于90% 济南国庆期间被通报问题比较严重的涉及小区27个，主要是RRC和ERAB建立失败次数大于200次，另外接通率低于90%的小区从网管统计7天共涉及小区103个：

3.1 RRC和ERAB失败次数大于200次原因分类

对此次被省公司通报的必要严重的小区27个进行了深入分析，主要原因集中为： 1）这些小区除长途汽车站外，其他的10个小区都是突发无法预估话务量的小区，平均用户数超过100个，最大超过150个，所以没有此部分小区进行版本升级，无法应对高话务，只能通过临时参数修改来解决。

2）对于EARB建立失败次数较多，而RRC失败没有问题，通过信令监测系统进行分析主要是集中在单一用户导致，出现此问题的有5个小区。

3）还有1室分小区也出现了前后台数据不同步的问题，导致了用户数不多，而RRC失败较多，通过数据重新同步后问题解决，导致出现此问题的原因有可能为传输链路闪断导致，后续会通过设置QOS告警来预警。

4）对于9个小区用户量少，但是RRC失败较多，通过采集后台数据提交后方分析，判断在601P03前版本下会出现对部分终端调度失败后，终端频繁发起请求频繁失败导致。

5）1个小区“济南大学食堂”是由于扩容第二载波后数据配置有问题导致RRC成功率较低，及时通知数据配置人员重新配置数据后问题恢复。6）1个小区“LFZ018254H_济阳仁风北陈”是外部干扰导致，全部RB底噪抬升至-70左右。

3.2 RRC和ERAB失败次数大于200次分析案例

1、对于ERAB失败小区较多的“[TDD]LDZ0100712R1_山大路雅悦-陶然居(12)”小区通过网管统计发现此小区指标恶化从10月7日18点开始恶化，10月8日8点开始恢复，检查小区参数正常，无告警，通过信令监测系统进行查询，发现出现ERAB建立失败都集中在某一用户，***用户，通过IMEI号86451002查询，用户终端为步步高X3L终端。

同样的对其他小区进行分析，除信令监测系统10月1日数据无法查询到外，其他小区ERAB失败都是某一用户导致，如惠尔大厦是***用户，使用的是Lenovo A788t终端。

2、对于类似于“LDZ0121133H1_天桥”站点，用户量较少，但是RRC请求次数较多，失败的原因主要是定时器超时导致的失败。

从网管的计数器统计上分析，产生MT-ACCESS、MO-SIGNALING、MO-DATA等定时器超时主要是统计采样点5，从信令深入分析主要是UE侧在发送RrcConnectionRequest消息之后启动的64ms的竞争解决定时器mac-ContentionResolutionTimer超时，Rrc连接建立失败。

经过研发确认，在进一步分析调度器本地UE实例建立失败的原因，发现是由于内部的TA模块在UE某次实例建立时校验状态出错，此部分UE主要涉及部分与终端芯片与协议不符导致，容易出现几率性的校验失败，主要是MTK芯片。

调度器建立UE实例过程是，先分配一个唯一的标识UeIdx，在给内部各个子模块建立实例，其中TA模块在建立UE时，首先校验UeIdx对应的状态，如果不为IDLE，则认为异常，返回失败。

而TA模块的UeIdx资源没有被回收，造成下一次这个UeIdx再被分配时，TA模块UE实例建立失败，这样循环导致RRC失败次数较多。

解决建议：目前正在升级的601P03版本，对部分不规范的芯片出现校验失败后重新删除UE实例，即使如果状态不为IDLE，也先把之前的状态清掉，继续建实例，并对此部分UE芯片校验进行记忆，避免继续校验失败。济南LTE网络国庆保障总结

1、此次国庆期间的LTE网络保障在10月1日上午人流密集、并且现场对于部分小区话务量预估不足，版本未升级，导致部分小区高用户拥塞，后续解决措施601P03版本全网升级后不会再出现此问题。

2、日常将加强对性能差小区的监控力度，结合信令监测系统对终端进行分析，做到及时预防。

3、后续将制定更加灵活、全面、细致的保障方案，对指标延长指标监控时间段，避免出现突发拥塞或者问题。

第五篇：对等网络中的信任感知和可信协同商务洽谈关键技术研究

对等网络中的信任感知和可信协同商务洽谈关键技术研究 【摘要】：在电子商务贸易蓬勃发展的同时，一个很现实的需要解决的就是如何使电子商务活动乃至协同商务用户之间能够进行更为有效的交互和协作。在基于Internet的网上商务交易活动进行的过程中，无论是对于企业还是消费者而言，一个必不可少的活动就是商务洽谈。在商务交易的任何发展阶段，商务洽谈始终是商务交易系统中十分关键的交互行为。随着P2P计算技术的发展，P2P网络环境下的协作系统也得到了广泛应用。P2P网络环境下的协作应用系统为用户提供了高度灵活的交互环境和便捷的资源访问接口、虚拟远程协作和资源共享，允许协作节点间形成动态的虚拟群组，使参与的节点可以联合处理资源、权能和信息以获得共同的应用目标，使任意地点的用户通过Internet以对等的方式协同工作，实现文件共享、即时通讯或虚拟远程协作等。电子商务作为P2P网络环境下协作系统中最活跃的应用系统，其参与交易的用户具有匿名性，在空间上具有分散性，这使得电子商务更加方便和灵活，但同时也加大了商务活动中的风险性和安全威胁，存在大量欺诈行为以及不可靠的服务质量。由于P2P系统中的节点更多地表现出理性和自私性，节点的目标往往是最大化自身的网络效用，从而导致了节点只想索取资源而不愿贡献资源的行为。在商务活动中，交易双方通过合作互惠互利取得尽可能大的利益。无论在传统的商业交易中还是新兴的电子商务活动中，信任都是双方合作的基础，是交易活动成功与否的核心因素。在P2P网络环境下，协

作节点的可信性问题制约了电子商务及其洽谈协作系统的应用。如何在P2P网络实体之间有效地建立授权和信任关系，实现灵活的信任协商策略，构建P2P网络环境下的适合于商务交易的具有安全保障作用的信任模型，从而使电子商务乃至协同商务洽谈用户之间能够进行更为有效的交互和协作，成为P2P网络环境协作应用研究的基础和重点问题。同时，通过对商务洽谈领域和协作理论现状的深入分析，作者发现，目前P2P网络环境下面向商务洽谈的协作研究工作存在着一些不足：缺少对商务洽谈活动过程综合性的全面的分析研究；缺少能充分体现商务洽谈活动特性和要求的、适合于P2P网络环境下信任感知的可信协同商务洽谈系统设计开发的形式化建模方法的研究；尤其缺乏为开放动态P2P网络环境下协作节点间的再次协作交互行为积累信誉评价信息的有效信任机制。因此，本文研究P2P网络环境中协作群组形成及运行过程中成员节点间信任的建立机制，并在确定实体(节点)间的信任关系后，重点研究信任感知的可信协同商务洽谈系统(TCBN)各成员交互行为的协作过程模型。在协作组成员节点交互协作行为完成之际(即本文所提出了协同洽谈评估阶段)，需要成员节点凭借主观经验，彼此间形成本次交易的信誉反馈评分，包括满意度、不满意度、推荐信息等，记录到资源数据库中，为再次可信的协作交互行为积累数据。基于策略的信任管理机制与以信任度量为主要研究内容的信任度评估模型相结合，形成P2P网络环境下的协作应用系统中一个更广义的信任管理概念和能力更强的授权和信任机制。因此，本文首先提出了一个基于LTTP的协作信任协商策略。结合本文所提

出的信誉机制，引入了LTTP(局部可信任第三方)机制，并通过对积极策略和削减策略的扩展，有效地解决信任协商循环依赖策略的问题。基于LTTP的协作信任协商策略是高效且完备的，能够有效减少信任证交换次数，降低网络开销，并且尽可能地保证协商的成功率。在基于信誉的信任管理技术中，本文重点对其关键组件——信任模型进行研究。通过对目前基于P2P环境的信任模型的分析，并针对现有全局信任模型存在的不足之处，本文结合网上商务交易的具体特点，提出了一个基于推荐和激励机制的全局信任模型，将实体反馈评分、近期信任度，评估者信任度、交易价值以及评分时间权重等均视为影响节点信任的主要因素，节点交互过程中相互进行信誉评价，最终得到节点的综合信任值。通过理论分析和仿真实验验证了本文面向商务交易的综合信任模型的特性。基于对商务洽谈活动过程要素及其关系的分析和对商务洽谈动态过程的综合性分析，作者发现并总结出商务洽谈具有异步性、并行性、并发性、不确定性等特征，而Petri网非常适合对具有上述特征的信息系统进行动态建模。针对有色Petri网系统缺乏对商务洽谈中某些特征的表现机制，作者对有色Petri网系统进行扩展，创造性地提出了面向商务洽谈的有色Petri网系统BN_CPN，并用它作为建模工具，构造了传统商务洽谈活动的形式化动态模型——Φ模型。在此基础上，结合协同商务洽谈系统的应用特征，将TCBN系统的体系结构划分为协作洽谈分析功能子模块(A子模块)、协作洽谈设计功能子模块(D子模块)、实时协作洽谈功能子模块(N子模块)和协作洽谈评估功能子模块(E子模块)。在协作洽谈评

估功能子模块(E子模块)中，基于本文所提出的面向商务交易的综合信任模型，设计了信誉反馈机制，通过对满意度、不满意度、推荐、激励等信誉评价信息的记录和逐渐积累，对协作实体(节点)的信誉评估度进行重新计算和优化，从而为再次的可信商务协作交互行为提供更有效和合理的信任机制。结合前面章节对P2P网络环境下信任管理技术特点的讨论，给出了一个P2P网络环境下的协作应用系统基于策略的信任与基于信誉的信任相结合的信任管理中间件。中间件的接口抽象了信任管理操作的细节，方便了协作应用进行定制扩展，通用的服务提高了协作应用在信任管理中的互操作性。借助该信任管理中间件，节点可以动态地参与协作群组、维护协作方的信任证、搜集协作方节点的信任信息，建立协作节点的信任，从而最终实现信任感知的协作行为。基于上述信任感知的TCBN系统形式化模型，结合本文所提出的协作系统信任管理中间件，并采用基于组件的实时通讯与协作实现技术方案，本文构造和实现了一个支持TCBN的虚拟洽谈环境VNegotiationRoom，通过VNegotiationRoom验证了本文提出的P2P网络环境下的协作系统信任管理机制、可信协同商务洽谈系统形式化模型、ADNE实现框架模型、以及协作系统信任管理中间件、实时通讯与协作实现技术方案的正确性和有效性，从而有效地解决了目前信任感知的可信协同商务洽谈研究中存在的关键问题。综上所述，本文主要的研究成果与工作归纳为：·提出了一个基于LTTP的协作信任协商策略。结合本文所提出的信誉机制，引入了LTTP(局部可信任第三方)机制，并通过对积极策略和削减策略的扩展，有效地解决信任协

商循环依赖策略的问题。·提出了一个基于推荐和激励机制的全局信任模型。结合网上商务交易的具体特点，将实体反馈评分、近期信任度，评估者信任度、交易价值以及评分时间权重等均视为影响节点信任的主要因素，通过节点交互过程中的相互信誉评价，最终得到节点的综合信任值。通过理论分析和仿真实验验证了本文信任模型的特性。·针对有色Petri网系统缺乏对电子商务洽谈系统中某些特性的表现机制，提出了面向商务洽谈的有色Petri网系统BN_CPN，并将其作为信任感知的可信协同商务洽谈系统形式化建模的建模工具。·提出了一套基于BN_CPN的信任感知的TCBN系统形式化建模方法和技术，设计了一个P2P网络环境下协作应用系统信誉反馈机制，通过对满意度、不满意度、推荐、激励等信誉评价信息的记录和逐渐积累，对协作实体(节点)的信誉评估度进行重新计算和优化，从而为再次的可信协作交互行为提供更有效和合理的信任机制。并以此为依据构造一个适合于TCBN系统设计、开发的实现框架参考模型——ADNE模型。·设计和实现了一个P2P网络环境下基于策略的信任与基于信誉的信任相结合的综合信任管理中间件。中间件的接口抽象了信任管理操作的细节，方便了协作应用进行定制扩展，通用的服务提高了协作应用在信任管理中的互操作性。·结合本文所提出的P2P网络环境下协作应用系统信任管理中间件，采用基于组件的实时通讯与协作实现技术方案，实现了一个基于ADNE模型的支持信任感知的TCBN的安全的虚拟洽谈环境VNegotiationRoom。通过该实验系统，验证了本文提出的P2P网络环境下协作应用系统信任管理机制、信任感知的TCBN系统建模方法、实现框架模型、P2P网络环境下协作应用系统信任管理中间件以及实时通讯与协作实现技术方案的有效性、可行性与正确性。本文所提出的P2P网络环境中信任感知的可信协同商务洽谈的信任管理机制和形式化协作模型及实现技术，在上海市科技攻关项目“中芬远程教育与远程商务洽谈研究与应用”(No．05107017)的一个子项目上得到了实际应用(已通过专家鉴定)。【关键词】：对等网络信任感知可信协同商务洽谈信任协商策略信誉信任模型信任反馈有色Petri网系统BN_CPN 【学位授予单位】：华东师范大学 【学位级别】：博士 【学位授予年份】：2007 【分类号】：TP393.08 【目录】：论文摘要7-11Abstract11-18第一章绪论18-411.1研究背景18-201.2P2P网络中信任管理和协作机制研究的目的和意义20-221.3研究现状概述22-351.4当前研究工作存在的问题35-361.5本文研究内容、论文结构及主要贡献36-41第二章协同商务与可信协同商务洽谈41-572.1本章目的412.2洽谈与协作41-522.3协同商务的定义与基本特征52-542.4可信协同商务洽谈(TCBN)54-562.5本章小结56-57第三章基于LTTP和推荐激励机制的综合信任模型57-843.1本章目的573.2信任基本概念57-623.3基于LTTP的信任协商策略62-753.4基于推荐和激励机制的信任模型75-823.5本章小结82-84第四章信任感知的TCBN系统建模方法与技术84-1334.1本章目的844.2

洽谈论域的形式化定义84-884.3洽谈活动过程分析88-934.4基于有色Petri网系统的协同洽谈活动动态建模93-1094.5可信协同商务洽谈TCBN系统建模109-1214.6TCBN系统信任反馈机制121-1254.7TCBN系统和传统商务洽谈活动的形式化建模之间关系125-1314.8本章小结131-133第五章信任感知的TCBN系统的实现框架模型133-1505.1本章目的1335.2ADNE实现框架参考模型的设计133-1425.3协作应用系统信任管理中间件142-1495.4本章小结149-150第六章信任感知的TCBN系统虚拟洽谈环境的实现150-1666.1本章目的1506.2支持TCBN的虚拟洽谈环境的研究现状150-1516.3支持TCBN的基于组件的实现技术分析151-1566.4VNegotiationRoom

体

系

架

构

分

析156-1586.5VNegotiationRoom的实现158-1656.6本章小结165-166第七章总结与展望166-1697.1本文工作总结166-1687.2进一步的研究工作168-169参考文献169-179附录A:攻读博士学位期间发表的论文179-180附录B:攻读博士学位期间参与的科研项目180附录C:攻读博士学位期间的获奖情况180-181致谢181

本论文购买请联系页眉网站。