EDN首页   博客首页 用户登陆  |  注册
aaa
发表于 2006/8/20 1:29:10

1

关于投票

技术前瞻:Wi-Fi的下一代标准802.11n

作者: 郭长祐
  1999年IEEE正式颁布IEEE 802.11a、11b,自此WLAN市场飞跃兴起,不过11a、11b各有优缺,11a的传输速度快(54Mbps),但传输距离、穿墙表现等不如 11b,11b则覆盖、渗透力强,但仅有11Mbps。因此IEEE机构于2000年起着手强化11b的传速(因11a使用5GHz频段,并非是全球通行的ISM频段),设定目标是突破20Mbps,此新制订于2003年完成,即IEEE 802.11g,最初设定为20Mbps,最后定案的传速与11a相同:54Mbps,使用与11b相同的频段,传距虽低于11b,但覆盖、渗透都还是优于11a,因此立即成为继11b之后的新主流,是2004年WLAN的市场主流焦点。

  完成11g后,IEEE组织很快地进行下一个提升目标,与11g制订工作时(Task Group g,TGg)相同的,设定了一个传速突破目标,这次订在超越100Mbps,亦即用无线方式超越现有Ethernet实线的100Base-T。

  ▲图说:Wi-Fi联盟负责IEEE 802.11x产品的标准测试、互通测试,并准允业者在通过测试的产品包装上使用Wi-Fi标章。(图片来源/Wi-Fi.org)

  IEEE 802.x与IEEE 802.11x的定位

  许多人都知道Ethernet的IEEE标准为802.3,也知道Wi-Fi的IEEE标准为802.11,但更完整、连续的定义范畴与配置当如何关连?可能少有人关注,然在更进一步说明11n前,或许该对此有些了解。

  ▲图说:IEEE 802.x系列规范在OSI七层协议中的最底两层之配置分布情形。

  事实上802.x系列是相互关连,包括实现局域网络的802.3(Ethernet),也包含无线局域网络的802.11(Wi-Fi),许多其它范畴的有线、无线标准也同样在此范畴内。

  其中IEEE 802.1、802.2是整体通跨性的规范,都位在Data Link层(Physical层的上一层),不过OSI7层协定过于理想,务实运用时通常将Data Link层再拆分成位于上端的Logical Link Control层(简称:LLC),以及处于下端的Media Access Control层(简称:MAC,亦有人称:Medium Access Control),802.2即是LLC层的共通规范,802.1则是MAC层中有桥接需求时的共通规范。

  既然是桥接,就表示并非是MAC层的全部,桥接之外的MAC层以及更基础位置的Physical层(简称:PHY)即是今日各式通讯应用的发挥处,例如Ethernet、Token Bus(802.4)、Token Ring(802.5)、Wi-Fi(802.11)、WiMAX(802.16)、WPAN化定位的Bluetooth(802.15.1)、 WiMEDIA/UWB(802.15.3a)、ZigBee(802.15.4)等都位处在此,诸多不胜枚举

  进一步的,由于本文旨在讨论下一代的WLAN:802.11n。与802.1、802.2相当类似,比802.11a、11b还要初始的 802.11,规范了WLAN的共通部分,最主要是确立了共同的MAC层规格,无论是802.11a、11b、还是11g,都是以802.11初始的 MAC定义为基础,更简单说即是使用相同的MAC。

  附注:802.11的PHY层也允许用IR(infrared)红外线方式来传输通讯,不一定要用RF无线,表示传输介质中立,但IR用法并不普及。

  除了读者购买终端Wi-Fi产品时会在意的11a、b、g之外,其实还有许多其它的802.11x规范是用来补充与强化整个802.11家族之用,下表简述802.11x家族的所有相关规范。

  所有的802.11x制订,都不脱PHY层、MAC层的范畴,有的仅调整MAC(如:强化安全的802.11i),有的仅修正PHY(如:提升传速的802.11g),有时则两者同时调修。

  

  11n制订提案:WWiSE对TGn Sync

       或许家庭用户会重视让多媒体应用更流畅的802.11e,或许企业用户会更重视存取安全的802.11i,但相信无论何种用户都会更在意加速传输的802.11n,截至目前为止速度一直是WLAN的首要卖点,因此11n会被持续高度关切,自是可以理解。

  不过,从过去的制订速度来看,1997年完成802.11、1999年公布802.11a/b、2000年开始802.11g,2003年正式敲定,每次约要2~3年时间才能完成,不过这次的传速提升制订已确定比过往冗长,因为对11n规格提案的看法分歧,而形成了WWiSE(World Wide Spectrum Efficiency)、TGn Sync(Task Group n)两大阵营对峙的局面。由于两阵营都有10多家以上的国际大厂支持,IEEE去年截止11n的提案收件,两阵营分别呈上自家的提案,今年将投票决定以何种提案为基础依据,然后才进入全程的规范制订程序,预计11n正式发表的时间,乐观会在2006年底,一般看法会至2007年初,甚至更晚。

  ▲图说:WWiSE阵营表示,在2×2收发天线组态、64-QAM调变、Code Rate 5/6的条件下可达135Mbps,且属视界穿透性(NLOS)传输,效果表现上与使用40MHz频宽的情形相接近(暗指另一阵营的主张并非必要),图为 WWiSE提案技术在使用不同侦错方式时的噪讯比差异。(图片来源/WWiSE.org)

  两阵营提案上的分歧主要在于每通道的占用频宽,WWiSE倾向20MHz,原因是能与11a/b/g的通道规划兼容,且较具国际通跨性,而 TGn Sync则力主40MHz,理由是能有更高传速表现及提升潜力。通道运用及跨国适用是主要争议,其它的小争议还包括实现新高速方式的复杂度,即编码、调变方式。

  在两阵营对峙过程中陆续有业者选边站,如Motorola、Qualcomm等业者的自行提案遭撤回后,Motorola转而加入WWiSE,Qualcomm则加入TGn Sync。

  附注:之后WWiSE也将40MHz列入选用规格,40MHz依据日本电信法规并不准允使用,其它各国各地亦多有不同,而TGn Sync也提供20MHz的加速作法。

  ▲图说:TGn Sync阵营认为用2×2组态、40MHz通道频宽,在成本、用电、信号清晰度上等各层面都有益处,图为TGn Sync提案技术于不同收发天线数、不同信道频宽、以及在较狭短的保护区间(Short GI)时的传输量与噪讯比表现。(图片来源/TGnSync.org)

  实现11n的技术共识:OFDM、MIMO

  虽然WWiSE、TGn Sync各有技术提案,但两营为实现加速所运用的技术却一致,包括使用OFDM(Orthogonal Frequency Division Multiplexing)调变/解调技术,及MIMO(Multiple Input Multiple Output)发送/接收技术。另外MAC层的编码方式亦有改变,还有PHY层也可能用上智能天线(Intelligent Antenna、Smart Antenna)技术。

  附注:过去802.11a/b/g都只有PHY层的差异,三者都使用相同的MAC层,然既有的MAC层无法因应更高的传输,所以802.11n也进行MAC层的改变、提升。

  先说明OFDM,事实上这不是802.11家族第一次使用OFDM调变技术,早在1999年的802.11a上即有使用,2003年的 802.11g也用,仅802.11b未用,不过唯有用此技术才能在有限频段中提升传输率,所以802.11n也必须续用,并加重运用与倚赖。

  过去未用OFDM时的作法称为单载波(Single Carrier;SC),每个载波间为防止干扰而保有一定的频率间隔,此间隔称为保护带、保护区间(Guard Band,或称Guard Interval,简称GI),居家地面无线电视、有线电视即是如此,以美规NTSC来说,每个节目频道用一个载波来传输,一个载波占用6MHz,而载波与载波间有1MHz左右的未用保留,以防两个节目讯号相互干扰。

  由于无线频段有限,不可能增加频段,而单载波作法不仅每个载波都要单独占用频段,且抗干扰的未用间隔也一样耗用频段,如此频宽难再增加。

  而OFDM是让载波间没有间隔,而且还让多个载波在频带使用上交迭,按理论这会造成相互干扰,但实际上将多个载波的调变波形(已经过BPSK、 QPSK、16QAM、64QAM等调变法,将数字数据转成模拟波形)进行快速傅立叶转换(Fast Fourier Transform;FFT),转换成多组相位正交(因为正交,所以各波相互间少干扰)的正弦波,并将各波进行相加,形成一复杂波形,再将此复杂波形透过天线发送出去,接收端用相逆方式还原,复杂波形用反转快速傅立叶(Inverse Fast Fourier Transform;IFFT)恢复成多个正交正弦波,再回复成各载波的调变波形,最后将波形解调变回数字数据。

  简单说,过去发送单载波且为简单的调变波形,如今类似用一个复杂波形来同时传送多个载波,近似压缩用意,以此让有限频宽获得更高的传输效益。以往OFDM不常被运用的原因,在于能执行FFT/IFFT演算的数字信号处理器(Digital Signal Processor;DSP),其效能、价格难以用在强调平价普及的民用(家庭、企业)无线装置上,但昂贵的军方设施则可行,如今DSP的价格效能比大幅提升,使一般无线产品也能使用OFDM技术。

  MIMO多天线技术

  ▲图说:MIMO技术运用多组发送、接收天线,在通讯空间中增辟传送路径数,藉此加速传输。(图片来源/AirgoNetworks.com中,由Farpoint Group行动、无线通讯顾问机构所撰写的白皮书)

  除了更彻底运用OFDM技术以求加速外,另一个加速方式是802.11过去从未用过的MIMO技术,最简单的说法即是透过增加收发天线的数目来达到加速,目前常言的有收发两端各两组天线(2×2)、各三组天线(3×3)、各四组天线(4×4)等,天线数愈多也意味着传输率愈高。

  现有802.11a/b/g多是使用单一天线,即便有的末端产品采用双天线,也仅在于强化方位覆盖效果,同一时间内只使用两天线中的其一,以反复、快速切换的方式来使用两天线(如:无线基地台同时服务各方位的多个存取装置),或侦测两天线的收发信号强度后,选择信号较强的一支来持续使用(如:笔记型计算机两侧各埋一个天线),并非是两个各自独立运作的天线。相对的而MIMO的多天线则是各天线都有自主运作的能力,各天线用自己的调变方式发送电波,用自己的解调变方式接收电波。

  在多个天线的后端则需集中、一致的工作,将要发送的数据进行分拆,才交给复数以上的天线来发送,接收端也用多组天线接收,然后将多组波形解调的结果重新合并回数字数据。另外收发两端也不见得要有对称的天线数目,所以不仅可以有MIMO,亦可以有SIMO(Single Input Multiple Output)、MISO、MIMO 4×2(4个发送天线,2个接收天线)、MIMO 3×4(3发4收)等多样组态变化,且都比既有802.11a/b/g的SISO快速。

  附注:倘若要采取收发两端天线数目不对称的MIMO组态,多须采行接收天线数多于发送天线数的组态,理由在于每一个从发送天线所送出的调变波就如同一个「未知变量」,而每个接收天线都会收到所有发送天线的波讯,但各天线收到各波形的讯号强弱有别,透过后端DSP的归纳、比对、推算,才能完整求取出原本各个的发送波形,倘若接收天线数较少,则会使可供归纳、比对的条件减少,接收信息不足,而难以完整回推。

  较多的接收天线可多方收集、比对讯号(哪怕是经过多方反射、波折后才抵达的微弱信号),以强化接收效果,相反的发送端的功率最高,多个强波一起相邻发送则容易相互干扰。

  用譬喻来解释,过去只用时间轴、频率轴(含振幅、相位因素)所构成的2D平面式路径来收送电波,如今运用传递空间上增辟更多传送路径,升级成3D立体式传送,获得更大的携行传量潜力。

  与OFDM相同的,MIMO的多天线作法按理来说等于是制造收发上的更多干扰,过去用单天线进行单一电波传递时,发散出去的电波会在空间路径中遭遇阻碍物而产生反射,接收端的天线除了收到方位良好的直射电波外,多少也会接收到未预期性的反射电波,使正确的波形遭受影响,而MIMO要在空间路径上发出一个以上的波形,也容易造成相互影响。

  对此,MIMO可用偏波方式来避免干扰,一个天线可用水平波形发送,另一个天线可用垂直波形发送,或者用左旋波发送,或右旋波发送,用空间维度的差别来实现多波同时传送。

  至于接收方面,其实不限定一对一的接收,由于有多支接收天线,多支天线接收同一发送波形,则各天线因角度、方位差异而收到强弱不等的信号,将多个不等信号进行集中归纳的运算后,不仅可将噪声干扰排除以更加确定信号的正确性(信号更清晰,也意味着可更远、更快地收发),同时还可以推算出发送端的方位,而让后续的通讯运作进行方位角度上的最佳化收发,此即是所谓的数组天线(Array Antenna)原理,也是智能天线的原理,或称适性天线(Adaptive Antenna),一般报章媒体所言的神盾战舰,其实就是具备相位数组雷达的军舰,雷达(RADAR)其实是缩写,全称是RAdio Direction And Ranging(无线定位与测距)。

  MIMO好处不仅在收发方位最佳化,也包含距离最佳化,与雷达相同的,发送一个脉波后测试多久后反射回复,以得知收发另一端的距离,若距离远则在发送电波时将功率增大,以抵抗传送路径上的信号衰落,相反则在近距离发送低功率信号,此称为Beam Forming技术,类似在暗境中开手电筒找物,照远处则增加光照,近处则可减弱。现有的802.11a/b/g则是不论远近一律采相同功率发送。

  结论

  OFDM、MIMO、Smart Antenna(归属在MIMO范畴中)等是802.11n的关键加速技术。此外,既然已经确定802.11n会更动MAC层,那么也运用此次机会来强化 MAC中的编码设计,如降低实质数据之外的讯框(Frame)占用量,增加传输效益,另外也强化管理性或其它相关机制,毕竟802.11a/b/g都使用 1997年就大致底定的MAC设计(于初始的802.11规范中),后续的制订多仅为小幅增修,时至今日确实该有较大的提升,以免阻碍日后更多的先进发展。不过,整个802.11n的制订主要还是为了加速传输,其次是拓展覆盖面积。

  最后,在802.11n未正式登场前,已有诸多业者提出超越现今54Mbps的方案,并多少提前使用了前述的技术(此泛称为Pre-n方案),如Atheros的VLocity(AR5005芯片)就具有Beam Forming技术,Airgo的True MIMO自然是用MIMO技术,另外Broadcom强调该公司现有11g芯片只要加搭其开发的AfterBurner(后燃器,战斗机喷射引擎的后段,民用喷射机、教练机多不具备后燃器)软件也可加速。

  除此之外,也有业者是对频段上进行变通运用以求加速,方法是同时启用802.11b/g于2.4GHz频段中的三个最互不干扰的通道(Ch1、 6、11)来加速,此称为Channel Bonding,或者直接将某一通道的占用频宽扩大(例如:从原本标准规范中的20MHz提升至40MHz)也属Channel Bonding作法,此作法的缺点是牺牲在覆盖区内运用通道进行区隔的能力,或严重干扰同一覆盖区内的他人Wi-Fi使用。

  ▲图说:Channel Bonding技术是同时开启IEEE 802.11g一个以上的通道,为了有最大加速及最低干扰,最佳的规划运用方式是启用1、6、11等三信道,三信道同时开通可达162Mbps传速(现有 54Mbps的3倍),或者同时开通两通道亦有108Mbps的加倍效果,而三通道相互间有着约5MHz的隔离保护带,避免运作中的通道产生相邻干扰。

  或许有人担忧各业者的先行、超规、专属作法,但其实在过去的11b、11g时代就很普遍,例如11b+、Turbo b、Turbo g等,如今旧事重演,转变成11g+、Super g之类,然在新正式标准颁布后,业者的特规就会收敛,如过去56kbps传统模拟拨接调制解调器的年代(1998年左右),U.S. Robotic抢先推出X2,Rockwell也对应祭出K56flex,最后都被ITU正式颁订的V.90给消灭。

  不过这次11n的制订时间将比过往的11b、11g更久,先行、超规、专属的时间也会久些,若拖延过久则正式规格的价值将可能生变,然这都只是推论,一切仍在未定之天。

  附注:希腊神话中的天神:宙斯(Zeus)拥有一面能抵挡任何攻击的盾牌,称为Aegis(神盾)。过去美国海军推测:若与前苏联海军开战,则俄方最可能使用的战术,是在交战首波即对美方舰队发射大量的攻舰飞弹,让舰队的电战(雷达)系统难以应付迎面而来的饱和攻击而受创。(饱和在此指的是飞行而来的攻击物,其数目过多,多到超过舰上雷达同时间最多可跟盯的数目,如此电战系统将疲于应付为数众多的攻击,很容易因响应不及或目标疏漏而被命中,甚至是被多枚击中而沈没)

  为因应此种可能攻势,美国海军着手研发名为Aegis的新式电战系统,此电战系统在战舰上设置四面相位数组天线,各面可涵盖110度的方位,以此达到360度的全方位涵盖(110×4=440,但其实各面的角度有些许重迭),每一面天线内其实是由数百、上千个独立子天线(现有802.11n的 MIMO技术提案仅有2~4个天线,亦有业者扩增至6个)所组构成,以蜂巢、数组方式规则排列,如此战舰在面对诸多的飞机、飞弹时,可指派数个子天线为一组,一组对应一个飞行物并持续紧锁、追踪,成千上百的子天线可以拆分成多组,同时跟盯多个空中目标,然后再加以反制。

  至于反制作法,多半是搭配垂直发射系统,在最短时间内发射多枚飞弹来因应多量攻击,过去的单臂、双臂的飞弹发射架只能逐一、逐二地发射飞弹,无法在短时间内发射多枚飞弹。类似的,传统扇区雷达、橘皮天线无法同时跟盯过多数目的空中目标,而相位数组雷达可以。

  凡具有神盾雷达系统的战舰即称神盾舰,最早的神盾舰是美国的Ticonderoga级轻巡洋舰(沿用Spruance级驱逐舰的舰体,再加搭神盾系统),之后则有Arleigh Burke级驱逐舰,或日本海上自卫队的金刚级驱逐舰(美国技术移转)。

  相位数组雷达的军事应用除神盾战舰外,还包括爱国者飞弹的雷达系统,潜舰的数组声纳(强化回音方位确认),及地面单位为了与正藏匿于水下的潜舰发送电讯,必须在陆地建立占地庞大的数组天线,用超低频(Extremely Low Frequency;ELF,3kHz以下)将无线信号送达水下的潜舰,另外大型天文电波望远镜的天线也运用相同的数组作法。

 

系统分类: 通信网络  |  用户分类: 网络通信  |  标签: 无标签  |  来源: 无分类  | 

点击查看原文

发表评论 阅读全文(2356) | 回复(0)

发表于 2006/8/12 12:37:37

1

关于投票

Some Frequently Asked Questions about RTP

http://www.cs.columbia.edu/~hgs/rtp/faq.html

系统分类: 嵌入式  |  用户分类: 网络通信  |  标签: RTP  |  来源: 无分类  | 

点击查看原文

发表评论 阅读全文(982) | 回复(0)

发表于 2006/8/10 12:45:01

4

关于投票

实时传输协议(RTP)和实时控制协议(RTCP)

 

RTP是一种提供端对端传输服务的实时传输协议,用来支持在单目标广播和多目标广播网络服务中传输实时数据,而实时数据的传输则由RTCP协议来监视和控制。

RTP定义在RFC

使用RTP协议的应用程序运行在RTP之上,而执行RTP的程序运行在UDP的上层,目的是为了使用UDP的端口号和检查和。如图16-12所示,RTP可以看成是传输层的子层。由多媒体应用程序生成的声音和电视数据块被封装在RTP信息包中,每个RTP信息包被封装在UDP消息段中,然后再封装在IP数据包中。

1889中。信息包的结构包含广泛用于多媒体的若干个域,包括声音点播(audio-on-demand)、影视点播(video on demand)、因特网电话(Internet telephony)和电视会议(videoconferencing)。RTP的规格没有对声音和电视的压缩格式制定标准,它可以被用来传输普通格式的文件。例如,WAV或者GSM(Global System for Mobile communications)格式的声音、MPEG-1和MPEG-2的电视,也可以用来传输专有格式存储的声音和电视文件。

 

TCP/IP模型

 

应用层(application)

传输层

RTP

 

UDP

 

IP

 

数据链路层(data link)

 

物理层(physical)

图16-12 RTP是传输层上的协议

从应用开发人员的角度来看,可把RTP执行程序看成是应用程序的一部分,因为开发人员必需把RTP集成到应用程序中。在发送端,开发人员必需把执行RTP协议的程序写入到创建RTP信息包的应用程序中,然后应用程序把RTP信息包发送到UDP的套接接口(socket interface),如图16-13所示;同样,在接收端,RTP信息包通过UDP套接接口输入到应用程序,因此开发人员必需把执行RTP协议的程序写入到从RTP信息包中抽出媒体数据的应用程序。

TCP/IP模型

 

应用层(application)

 

RTP

 


套接接口

UDP

 

IP

 

数据链路层(data link)

 

物理层(physical)

 

图16-13 RTP和UDP之间的接口

现以用RTP传输声音为例来说明它的工作过程。假设音源的声音是64 kb/s的PCM编码声音,并假设应用程序取20毫秒的编码数据为一个数据块(chunk),即在一个数据块中有160个字节的声音数据。应用程序需要为这块声音数据添加RTP标题生成RTP信息包,这个标题包括声音数据的类型、顺序号和时间戳。然后RTP信息包被送到UDP套接接口,在那里再被封装在UDP信息包中。在接收端,应用程序从套接接口处接收RTP信息包,并从RTP信息包中抽出声音数据块,然后使用RTP信息包的标题域中的信息正确地译码和播放声音。

如果应用程序不使用专有的方案来提供有效载荷类型(payload type)、顺序号或者时间戳,而是使用标准的RTP协议,应用程序就更容易与其他的网络应用程序配合运行,这是大家都希望的事情。例如,如果有两个不同的公司都在开发因特网电话软件,他们都把RTP合并到他们的产品中,这样就有希望:使用不同公司电话软件的用户之间能够进行通信。

这里需要强调的是,RTP本身不提供任何机制来确保把数据及时递送到接收端或者确保其他的服务质量,它也不担保在递送过程中不丢失信息包或者防止信息包的次序不被打乱。的确,RTP的封装只是在系统端才能看到,中间的路由器并不区分那个IP数据报是运载RTP信息包的。

RTP允许给每个媒体源分配一个单独的RTP信息包流,例如,摄像机或者麦克风。例如,有两个团体参与的电视会议,这就可能打开4个信息包流:两台摄像机传送电视流和两个麦克风传送声音流。然而,许多流行的编码技术,包括MPEG-1和MPEG-2在编码过程中都把声音和电视图像捆绑在一起以形成单一的数据流,一个方向就生成一个RTP信息包流。

RTP信息包没有被限制只可应用于单目标广播,它们也可以在一对多(one-to-many)的多目标广播树或者在多对多(many-to-many)的多目标广播树上传送。例如,多对多的多目标广播,在这种应用场合下,所有发送端通常都把他们的RTP信息包流发送到具有相同多目标广播地址的多目标广播树上。

16.6.2 RTP信息包标题域

RTP标题由4个信息包标题域和其他域组成:有效载荷类型(payload type)域,顺序号(sequence number)域,时间戳(timestamp)域和同步源标识符(Synchronization Source Identifier)域等。RTP信息包的标题域的结构如下图所示:

Payload

Type
(有效载荷类型)

Sequence Number

(顺序号)

Timestamp

(时间戳)

Synchronization Source Identifier
(同步源标识符)

Miscellaneous Fields
(其他)

 

1. 有效载荷类型

RTP信息包中的有效载荷域(Payload Type Field)的长度为7位,因此RTP可支持128种不同的有效载荷类型。对于声音流,这个域用来指示声音使用的编码类型,例如PCM、自适应增量调制或线性预测编码等等。如果发送端在会话或者广播的中途决定改变编码方法,发送端可通过这个域来通知接收端。表16-01列出了目前RTP所能支持的声音有效载荷类型。

表16-01 目前RTP所能支持的声音有效载荷类型

有效载荷号

声音类型

采样率(kHz)

数据率(kb/s)

0

PCM mu-law

8

64

1

1016

8

4.8

2

G.721

8

32

3

GSM

8

32

6

DVI

16

64

7

LPC

8

2.4

9

G.722

8

48~64

14

MPEG Audio

90

-

15

G.728

8

16

对电视流,有效载荷类型可以用来指示电视编码的类型,例如motion JPEG, MPEG-1,MPEG-2或者H.231等等。发送端也可以在会话或者期间随时改变电视的编码方法。表16-02列出了目前RTP所能支持的某些电视有效载荷类型。

表16-02 目前RTP所能支持的声音有效载荷类型

有效载荷号

电视格式

26

Motion JPEG

28

-

31

H.261

32

MPEG-1 video

33

MPEG-2 video

 

2. 顺序号

顺序号(Sequence Number Field)域的长度为16位。每发送一个RTP信息包顺序号就加1,接收端可以用它来检查信息包是否有丢失以及按顺序号处理信息包。例如,接收端的应用程序接收到一个RTP信息包流,这个RTP信息包在顺序号86和89之间有一个间隔,接收端就知道信息包87和88已经丢失,并且采取措施来处理丢失的数据。

3. 时间戳

时间戳(Timestamp)域的长度为32字节。它反映RTP数据信息包中第一个字节的采样时刻(时间)。接收端可以利用这个时间戳来去除由网络引起的信息包的抖动,并且在接收端为播放提供同步功能。

4. 同步源标识符

同步源标识符(Synchronization Source Identifier,SSRC)域的长度为32位。它用来标识RTP信息包流的起源,在RTP会话或者期间的每个信息包流都有一个清楚的SSRC。SSRC不是发送端的IP地址,而是在新的信息包流开始时源端随机分配的一个号码。

16.6.3 实时传输控制协议

实时传输控制协议(Real-time Control Protocol,RTCP)也定义在1996年提出的RFC 1889中。多媒体网络应用把RTCP和RTP一起使用,尤其是在多目标广播中更具吸引力。当从一个或者多个发送端向多个接收端广播声音或者电视时,也就是在RTP会话期间,每个参与者周期性地向所有其他参与者发送RTCP控制信息包,如图16-14所示。RTCP用来监视服务质量和传送有关与会者的信息。对于RTP会话或者广播,通常使用单个多目标广播地址,属于这个会话的所有RTP和RTCP信息包都使用这个多目标广播地址,通过使用不同的端口号可把RTP信息包和RTCP信息包区分开来。

图16-14 每个参与者周期性地发送RTCP控制信息包

RTCP的主要功能是为应用程序提供会话质量或者广播性能质量的信息。每个RTCP信息包不封装声音数据或者电视数据,而是封装发送端和/或者接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况,这些反馈信息对发送端、接收端或者网络管理员都是很有用的。RTCP规格没有指定应用程序应该使用这个反馈信息做什么,这完全取决于应用程序开发人员。例如,发送端可以根据反馈信息来修改传输速率,接收端可以根据反馈信息判断问题是本地的、区域性的还是全球性的,网络管理员也可以使用RTCP信息包中的信息来评估网络用于多目标广播的性能。

16.6.4 实时流放协议

实时流放协议(Real-Time Streaming Protocol,RTSP)是一个刚开始开发的协议,它的设想描述在RFC

播放的数据流被分成许多信息包,信息包的大小很适用于客户机和服务器之间的带宽。当客户机已经接收到足够多的信息包之后,用户软件就可开始播放一个信息包,同时对另一个信息包解压缩和接收第三个信息包。这样用户就不需要把整个媒体文件从服务器上下载之后就可立即播放。广播源可以是现场的数据流也可以是存储的数据流。

RTSP协议想要提供控制多种应用数据传送的功能,提供一种选择传送通道的方法,例如UDP, TCP, IP多目标广播通道,以及提供一种基于RTP协议的递送方法。正在设计的RTSP将工作在RTP的上层,用来控制和传送实时的内容。

RTSP能够与资源保留协议一起使用,用来设置和管理保留带宽的流式会话或者广播。

2326文件中。RTSP是应用级的实时流放协议,它主要目标是为单目标广播和多目标广播上的流式多媒体应用提供牢靠的播放性能,以及支持不同厂家提供的客户机和服务机之间的协同工作能力。

http://publishblog.blogchina.com/blog/tb.b?diaryID=5335330

系统分类: 嵌入式  |  用户分类: 网络通信  |  标签: RTP RTCP  |  来源: 无分类  | 

点击查看原文

发表评论 阅读全文(13870) | 回复(9)

Total , Page /