61阅读

接口协议-HDMI接口与协议

发布时间:2018-04-23 所属栏目:webservice接口协议

一 : HDMI接口与协议

深入了解HDMI接口

一、HDMI接口的工作原理

这张图是HDMI接口的架构示意图。从左边的信号源中你可以看到,HDMI接口的信源可以是任何支持HDMI输出的设备,而接入端也可以是任何带有HDMI输 入接口的设备。无论他们是音频设备、视频设备还是控制设备,HDMI接口都可以应用其中。

在HDMI接口中的数据信号采用的是TMDS最小化传输差分信号协议。这种数据传输协议曾经在DVI接口上得到广泛的应用。而HDMI接口上的数据信号也沿用了这种协议。这种协议会将标准8bit数据转换为10bit信号,并且在转换过程中使用微分传送。微分传送这种技术也曾经被广泛的应用于千兆以太网的数据传输中。

在HDMI接口中音频、视频数据的传输时可以使用三条TMDS数据通道。视频信息在传送时被转换城连续的24bit像素数据,每个时钟周期可以传送10bit的数据。像素时钟周期传输比率大约在25MHz至165MHz之间。一般来说标准的NTSC 480i隔行信号的像素时钟传输比率大约为13.5MHz。若传输信号的比率小于25MHz,HDMI会采用自动循环技术填补码率,将信号的码率提升到25MHz的水平。而HDMI接口最高每秒可以传输165M像素的数据量,这个数据吞吐能力是相当惊人的。在未来一段时间内足以应付高码率,高数据流家用电器的信号传输任务。

HDTV最高的标准是1080p,它每屏的分辨率为1920X1080,若每秒传输60帧图像(1080p@60),那么最终的像素时钟传输比率为124.4MHz。由此看来HDMI接口完全可以从容应付当今的消费电子产品的各项应用。当然HDMI也支持双接口并联模式,那样可以提供惊人的330MHz传输比率。但是目前这种双并联HDMI接口不会用于一般消费阶层。

在HDMI中所采用的视频信号的编码方式为RGB格式,如YCbCr 4:4:4 或YCbCr 4:2:2格式,他们每个像素都是24bit。YCbCr是一种数字视频信号的格式,它与YPbPr格式相类似。(目前DVD播放机的分量输出都是使用YCbCr/YPbPr格式)这种视频信号标准也就是我们经常所说的“YUY”。Y的意思是亮度,它并不带有图像颜色的信息。只是负责记录图像中黑色与白色信息。Cb是图像中蓝色与亮度的差异值(B-Y),而Cr是红色与亮度之间的差异值(R-Y)。  那么Y、Cb、Cr这三个值就定义了视频编码时的采样率。而上文中的“4”代表使用NTSC或PAL制式时的采样率,即13.5MHz。那么我们看到的4:4:4,意思就是Y、Cb、Cr的编码采样率各是13.5MHz。而我们看到的4:2:2格式中Cb、Cr的采样率各是6.75MHz。那么现在你就能很明显的区分出上面两个YCbCr格式中哪个视频质量更好了。

在HDMI接口中,音频信号能够使用2至8声道,每个声道的采样率为192KHz。另外HDMI接口也提供了DDC显示数据通道,它会向视频接收装置发送配置信息和数据格式信息。接收装置可以读取这些E-EDID增强扩展显示识别数据的信息。最后HDMI接口也提供了CEC消费电子控制通道,通过这条通道可以控制视听设备的工作。

二、HDMI接口连接器

按照电气结构和物理形状的区别,HDMI接口可以分为Type A 、Type B、 Type C三种类型。每种类型的接口分别由用于设备端的插座和线材端的插头组成,使用5V低电压驱动,阻抗都是100欧姆。这三种插头都可以提供可靠的TMDS连接。

Type A型接口

A型是标准的19针HDMI接口,普及率最高。

A型的插座成扁平的“D”型,上宽下窄。接口外侧设有一圈厚度为0.5毫米的金属材质屏蔽层,防止来自外界的各种干扰信号。其中用于设备端的插座内径最宽处14毫米,高4.55毫米。19跟引脚在中心位置分两层排列。每根引脚的宽度为0.45毫米,长度为4.1毫米。A型的插头外径是最宽处13.9毫米,高4.45毫米。内部的引脚呈环状排列。而HDMI标准规定这些尺寸的误差要控制在相当小的范围内(0.05毫米左右),以保证良好的接触性。

A型接口每个时钟周期可以传输165MHz的像素的信息。

Type B型接口

B型接口的物理结构相比于A型接口,基本形状并没有太大变化,都是“D”型。但是其插座端最大宽度达到了21.3毫米,比A型的14毫米足足大了一圈。有29个引脚,可以提供双TMDS传输通道,因此支持更高的数据传输率和Dual-Link DVI连接。

B型接口每个时钟周期可以传送高达330MHz的像素信息。

Type C型接口

C型HDMI接口设计目的就是为了紧凑型便携设备,因此C型插座的尺寸只有10.5×2.5毫米,而插头也只有10.42×2.4毫米。非常的小巧。

C型接口每个时钟周期可以传输165MHz的像素的信息。

由于TMDS标准中指出,线缆的长度不得超过15米。因此使用TMDS标准的HDMI接口线缆长度也被限制在15米以内。这个长度对于一般的家用和办公领域来说已经足够了。

带有A型HDMI接口的信号发射装置可以连接到使用B型接口的接收装置上,此时需要一个B到A型的转换接口即可顺利连接。但是需要注意的是,一个带有B型接口的信号发射装置是不可能连接一个带有A类接口的信号接收装置。目前HDMI接口已经可以向下兼容DVI接口,他们之间只需使用专用的转接线缆即可相互转换。

专利许可费

不幸的是,HDMI接口并不是一个开放的标准。制造商必须向HDMI标准制定协会支付版税,来换取一个生产许可证。不过这个版税可不便宜,每年要交纳15000美元的许可费,并且更黑的是每生产一个HDMI接口就要支付0.15美元的许可费。只有这样制造商才能在自己的产品和使用手册中标识支持HDMI的logo。如果制造商已经是HDCP高清数字内容保护协议的会员那么每个带有HDMI接口的产品只需交纳0.04美元的许可费。如果制造商在其产品中使用HDCP高清数字内容保护机制,那么就必须要交纳15000美元的年费,在加上每个产品0.005美元的购买密匙费。

三、针脚定义

为了方便大家查阅资料,以及各位DIY玩家对HDMI接口作进一步了解以A型HDMI接口为例介绍各个针脚的定义。

1.数据通道(TMDS通道)

HDMI的数据通道和DVI的数据通道都采用TMDS信号(最小化传输差分信号)。通过TMDS信号传送音频,视频,以及各种辅助数据 。

信号编码方式:遵循DVI 1.0规格。A型HDMI接口是单链接,B型HDMI接口是双链接(带宽增加一倍)。

视频像素带宽:从25 MHz到340 MHz (A型, HDMI 1.3) 或至 680 MHz (B型)。带宽低于25MHz的视频信号如NTSC 480i将以倍频方式输出。每个像素的容许数据量从24位至48位。支持每秒120张画面,1080p分辨率画面传送以及WQSXGA分辨率。

像素编码方式:RGB 4:4:4,YCbCr 4:4:4 (8-16 bits per component);YCbCr 4:2:2 (12 bits per component) 。

音频采样率:32 kHz, 44.1 kHz, 48 kHz, 88.2 kHz, 96 kHz, 176.4 kHz, 192 kHz。

音频声道数量:最大8声道。

音频流规格:IEC61937兼容流,包括高流量无损信号如Dolby TrueHD, DTS-HD Master Audio。

2.CEC通道(必须预留线路但可以不必实现)

CEC全文为Consumer Electronics Control,用来传送工业规格的AV Link协议信号,以便支持单一遥控器操作多台AV机器。为单芯线双向串行总线。

3.DDC通道

DDC全文为Display Data Channel,传送端与接收端可利用DDC通道得知彼此的传送与接收能力,但HDMI仅需单向获知接收端(显示器)的能力。使用100kHz时钟频率的I2C信号。传送数据结构为VESA Enhanced EDID (V1.3)。

3. SCL和SDA

SCL的全文是Serial Clock,SDA的全文是Serial Data。

这两支脚位是用来让source(DVD) 和 display (TV)作沟通,在电视内部都有一个记忆体,存放有这台电视所支持的分辨率,例如:720P 或1080P,如果source(DVD)不知道目前所连接的电视所支持的电视分辨率是多少时,source(DVD) 就不知道要放送出什么分辨率的讯号。因此在一开始source(DVD)会透过这两支脚位去读取电视所支持的分辨率,当source(DVD) 知道后source(DVD) 才放送出符合电视分辨率的影像画面。其中SCL是时钟(CLOCK)脚位,SDA是资料脚位。

4.DVI转HDMI

由于HDMI和DVI采用相同的TMDS信号,所以很容易互相转换。

但是DVI没有规定传送音频信号,所以DVI转HDMI,或者HDMI转DVI都只有视频信号,没有音频信号。

AMD的APU是一种特例,APU平台的DVI信号来自HDMI,所以DVI接口用DVI转接HDMI也有音频信号。

四、HDMI 1.4新增功能

HDMI最新的版本是1.4版,1.4版新增功能简介如下。

1.HDMI以太网通道(HDMI Ethernet Channel,HEC)

HDMI 1.4版数据线将增加一条数据通道,支持高速双向通讯。支持该功能的互连设备能够通过百兆以太网发送和接收数据,可满足任何基于IP的应用。

HDMI以太网通道将允许基于互联网的HDMI设备和其它HDMI设备共享互联网接入,无需另接一条以太网线。新功能还将提供一个连接平台,允许HDMI设备之间共享内容。

HDMI以太网络通道技术在单一HDMI缆线中集成视频、音频与数据流,兼具HDMI连接的一流信号品质与便利性,与家用娱乐网络的强大与弹性功能。HDMI以太网络通道在HDMI连接中加入专用的数据通道,提供高达100 Mb/sec的双向高速网络功能。

2.音频回授通道(Audio Return Channel,ARC)

带有内置调谐器与HDMI接口的电视,无须使用其他音频缆线,即可"上传"音频数据至环绕声系统。在高清电视直接接收音频和视频内容的情况下,这个新通道能让高清电视通过HDMI线把音频直接传送到A/V功放接收机上,无需另外一条线缆。

3.HDMI 3D功能

新规范将为HDMI设备定义通用3D格式和分辨率,实现家庭3D系统输入输出部分的标准化,最高支持两条1080p分辨率的视频流。

3D技术发展迅猛,同时间有数项竞争技术齐头并进,因此HDMI 1.4规格为常见的3D显示技术定义了相关协议,包括:图帧、图线、图场可选方法,并排方法(全景与半景),2D加深度方法。

4.支持更高分辨率

HDMI设备支持的高清分辨率将达到4K×2K,四倍于目前的1080p,能够和众多数字家庭影院以同样的分辨率传输内容。

具体格式:3840×2160 24Hz/25Hz/30Hz;4096×2160 24Hz 。

5.拓展支持色彩空间

HDMI技术将支持专为数码相机设计的色彩空间,包括sYCC601、Adobe RGB、AdobeYCC601,可在连接数码相机的时候显示更精确的逼真色彩。

6.Micro HDMI迷你接口

新的Micro HDMI接口将比现在19针MINI HDMI版接口小50%左右,可为相机、手机等便携设备带来最高1080p的分辨率支持及最快5GB的传输速度。

7.汽车连接系统(Automotive Connection System,ACS)

一种为车载高清内容传输设计的线缆规范,可避免发热、震动、噪音等汽车内部常见环境的影响,也为汽车制造商在车内传送高清内容提供了一套切实可行的解决方案。

汽车用连接版本为HDMI E TYPE

8.五种HDMI1.4新标识

如今,HDMI似乎是与高清标准画上了等号。无论是在液晶电视、蓝光播放器,还是HTPC、投影机上,这个小小的接口都是必不可少的,有了它就意味着这个设备进入了次时代影音播放器的行列。而就在大多数人还在争论是否更先进的Display Port将会取代HDMI的时候,HDMI1.4版悄然登场。不过,尽管HDMI新版本增添了不少功能,但并不是每项技术都是必备的,所以为了让消费者能够明确功能,不至于花冤枉钱,近日,HDMI标准授权机构对1.4版本发布了新规范。

根据HDMI标准授权机构的指示精神,从即日起,对于那些HDMI线缆的制造商在销售和宣传新版本的时候,禁止再使用笼统的版本号标识,而旧版本则应该在一年内去除所有版本号标识的标签、说明、包装等。

4-1.JPG(30.83 KB)

补充说明

DVI和HDMI都是TMDS的信号协议。

HDMI的TMDS信号包括视频和HD音频,DVI只有视频。这是它们的区别。

这就出现2中可能:

一种是:

集成显卡设计时,如果DVI和HDMI分别设计,这样的DVI的TMDS信号是没有HD音频的,

只有HDMI的TMDS信号是有HD音频的。这样的DVI接口通过DVI-HDMI转接成HDMI是没有HD音频信号的。

Intel的集成显卡,AMD的785、880集成显卡,以及AMD和NV的独立显卡都是这样设计的。

另一种是:

集成显卡按HDMI设计,TMDS信号包含视频和HD音频,

DVI是从HDMI转接过来的,

这样的DVI接口通过DVI-HDMI转接成HDMI就含有HD音频信号的。

AMD的APU就是这样设计的。

HDMI接口与HDMI协议

什么是HDMI接口?

HDMI的英文全称是“High Definition Multimedia”,中文的意思是高清晰度多媒体接口。HDMI接口可以提供高达5Gbps的数据传输带宽,可以传送无压缩的音频信号及高分辨率视频信号。同时无需在信号传送前进行数/模或者模/数转换,可以保证最高质量的影音信号传送。应用HDMI的好处是:只需要一条HDMI线,便可以同时传送影音信号,而不像现在需要多条线材来连接;同时,由于无线进行数/模或者模/数转换,能取得更高的音频和视频传输质量。对消费者而言,HDMI技术不仅能提供清晰的画质,而且由于音频/视频采用同一电缆 ,大大简化了家庭影院系统的安装。

2002年的4月,日立、松下、飞利浦、Silicon Image、索尼、汤姆逊、东芝共7家公司成立了HDMI组织开始制定新的专用于数字视频/音频传输标准。2002年岁末,高清晰数字多媒体接口(High-definition Digital Multimedia Interface)HDMI 1.0标准颁布。HDMI在针脚上和DVI兼容,只是采用了不同的封装。与DVI相比,HDMI可以传输数字音频信号,并增加了对HDCP的支持,同时提供了更好的DDC可选功能。HDMI支持5Gbps的数据传输率,最远可传输15米,足以应付一个1080p的视频和一个8声道的音频信号。而因为一个1080p的视频和一个8声道的音频信号需求少于4GB/s,因此HDMI还有很大余量。这允许它可以用一个电缆分别连接DVD播放器,接收器和PRR。此外HDMI支持EDID、DDC2B,因此具有HDMI的设备具有“即插即用”的特点,信号源和显示设备之间会自动进行“协商”,自动选择最合适的视频/音频格式。

传统的AV复合和色差接口都需要独立分开音频和视频数据线来传输信号,同为数字接口的DVI接口则并不支持音频传输,目前唯有HDMI具备了在一条数据线上同时传送影音信号的能力,因此人们也习惯把HDMI称为“高清一线通”。

什么是HDCP协议?

HDCP是High-bandwidth Digital Content Protection的缩写,中文可称作“HDCP数字内容保护”。HDCP技术是由好莱坞与半导体界巨人Intel合作发开,它可以实际运用在显卡、DVD播放机等传输端,以及显示器、电视机、投影机的接收端之间。是高清电影、电视节目的重要反盗版技术,不支持HDCP协议的显示器无法正常播放有版权的高清节目。

DVD之后的高清电影节目采用了HDCP和AACS反盗版技术,蓝光和HD DVD都使用了这种反盗版技术,高清电视(HDTV)也会使用。使用了HDCP和AACS反盗版技术后电影节目只能在支持HDCP的设备上正常播放,否则只能看到黑屏显示或者低画质显示(清晰度大约只有正常的四分之一),也就便失去了高清的价值。其中AACS是加密技术,同时被用在HD DVD和蓝光光盘当中,保护光盘中的视频内容无法正常复制出来在其它地方播放。

而HDCP协议是用来防止视频内容在传输的过程被完整的复制下来。这种技术并不是让数字讯号无法被不合法的录制下来,而是将数字讯号进行加密,让不合法的录制方法,无法达到原有的高分辨率画质。例如蓝光影碟机在播放高清碟片时无法同时录下清晰的节目,在计算机上播放碟片时无法清晰的录制显示器上的节目。HDCP从始到终都保护视频信号,也就是说整套播放系统中每一个环节都必须支持HDCP协议,如果显示器不支持HDCP协议,那么就无法正常播放高清节目,只能看到黑屏或者低画质的节目。要支持HDCP协议,必须使用DVI、HDMI等数字视频接口,传统的VGA等模拟信号接口无法支持HDCP协议。当使用VGA等模拟信号接口时,画面就会下降成为低画质,或者提示无法播放,从而失去高清的意义,防止了盗版。需要说明的是,HDMI接口内嵌了HDCP协议,带有HDMI接口的显示器都支持HDCP协议。但是并不是带DVI接口的液晶显示器都支持HDCP协议,必须经过带有相应硬件芯片,通过认证的显示器才行。

在电脑平台上受到HDCP技术保护的数据内容在输出时会由操作系统中的COPP驱动(认证输出保护协议)首先验证显卡,只有合法的显卡才能实现内容输出,随后要认证显示设备的密钥,只有符合HDCP要求的设备才可以最终显示显卡传送来的内容。HDCP传输过程中,发送端和接受端都存储一个可用密钥集,这些密钥都是秘密存储,发送端和接受端都根据密钥进行加密解密运算,这样的运算中还要加入一个特别的值KSV(视频加密密钥)。同时HDCP的每个设备会有一个唯一的KSV序列号,发送端和接受端的密码处理单元会核对对方的KSV值,以确保连接是合法的。HDCP的加密过程会对每个像素进行处理,使得画面变得毫无规律、无法识别,只有确认同步后的发送端和接受端才可能进行逆向处理,完成数据的还原。在解密过程中,HDCP系统会每2秒中进行一次连接确认,同时每128帧画面进行一次发送端和接受端同步识别码,确保连接的同步。为了应对密钥泄漏的情况,HDCP特别建立了“撤销密钥”机制。每个设备的密钥集KSV值都是唯一的,HDCP系统会在收到KSV值后在撤销列表中进行比较和查找,出现在列表中的KSV将被认做非法,导致认证过程的失败。这里的撤销密钥列表将包含在HDCP对应的多媒体数据中并将自动更新。

可见要想在计算机上播放有版权的高清节目,不论是HDTV、蓝光还是HD DVD碟片,都要求显示器和显卡支持HDCP协议。不过厂商要为产品打上HDCP的Logo,则需要支付一定的认证费用,还要增加硬件芯片,显然提高了成本,目前只有部分产品通过认证。由于高清节目会逐渐普及,HDCP已成定局,因此支持HDCP协议的设备也会越来越多。

全面解密HDMI接口技术

提起数码产品的接口,大家都能列举出一大片,什么S端子、AV端子、色差分量接口、VGA接口、DVI接口……而说到HDMI数字信号接口,消费者更不会陌生,作为最新一代的数字接口,HDMI已经广泛应用于各种数码产品上,不管是平板电视、DVD碟机、高清播放机,还是投影仪、数码摄像机、液晶显示器,以及蓝光DVD和HD DVD,都少不了HDMI数字信号接口的身影。

消费者对HDMI接口的优点都非常了解,这里笔者也不准备再多介绍,提起为何HDMI接口有这些优点可能大家就不清楚了,HDMI接口在数据的保密技术上的优势获得了众多企业的推崇,那么到底其又有何特点,下面将给大家一一解开谜底。

HDMI的基本传输原理

HDMI(High-Definition Multimedia Interface)又被称为高清晰度多媒体接口,是首个支持在单线缆上传输,不经过压缩的全数字高清晰度、多声道音频和智能格式与控制命令数据的数字接口。HDMI接口由Silicon Image美国晶像公司倡导,联合索尼、日立、松下、飞利浦、汤姆逊、东芝等八家著名的消费类电子制造商联合成立的工作组共同开发的。HDMI最早的接口规范HDMI1.0于2002年12月公布,目前的最高版本是于今年6月发布的HDMI1.3规范。

HDMI源于DVI接口技术,它们主要是以美国晶像公司的TMDS信号传输技术为核心,这也就是为何HDMI接口和DVI接口能够通过转接头相互转换的原因。美国晶像公司是HDMI八个发起者中唯一的集成电路设计制造公司,是高速串行数据传输技术领域的领导厂商,因为下面要提到的TMDS信号传输技术就是它们开发出来的,所以这里稍微提及一下。

TMDS(Transition Minimized Differential Signaling)也被称为最小化传输差分信号,是指通过异或及异或非等逻辑算法将原始信号数据转换成10位,前8为数据由原始信号经运算后获得,第9位指示运算的方式,第10位用来对应直流平衡(DC-balanced,就是指在编码过程中保证信道中直流偏移为零,电平转化实现不同逻辑接口间的匹配),转换后的数据以差分传动方式传送。这种算法使得被传输信号过渡过程的上冲和下冲减小,传输的数据趋于直流平衡,使信号对传输线的电磁干扰减少,提高信号传输的速度和可靠性。

一般情况下,HDMI连接由一对信号源和接受器组成,有时候一个系统中也可以包含多个HDMI输入或者输出设备。每个HDMI信号输入接口都可以依据标准接收连接器的信息,同样信号输出接口也会携带所有的信号信息。HDMI数据线和接收器包括三个不同的TMDS数据信息通道和一个时钟通道,这些通道支持视频、音频数据和附加信息,视频、音频数据和附加信息通过三个通道传送到接收器上,而视频的像素时钟则通过TMDS时钟通道传送,接收器接受这个频率参数之后,再还原另外三个数据信息通道传递过来的信息。

视频和音频信号传输

HDMI输入的源编码格式包括视频像素数据、控制数据和数据包。其中数据包中包含有音频数据和辅助信息数据,同时HDMI为了获得声音数据和控制数据的高可靠性,数据包中还包括一个BCH错误纠正码。HDMI的数据信息的处理可以有多种不同的方式,但最终都是在每一个TMDS通道中包含2位的控制数据、8位的视频数据和4位的数据包。HDMI的数据传输过程可以分成三个部分:视频数据传输期、岛屿数据传输期和控制数据传输期。

HDMI数据传输示意图,HDMI有三个TMDS数据信息通道

视频数据传输期,HDMI数据线上传送视频像素信号,视频信号经过编码,生成3路(即3个TMDS数据信息通道,每路8位)共24位的视频数据流,输入到HDMI发射器中。24位像素的视频信号通过TMDS通道传输,将每通道8位的信号编码转换为10位,在每个10位像素时钟周期传送一个最小化的信号序列,视频信号被调制为TMDS数据信号传送出去,最后到接受器中接收。

岛屿数据传输期,TMDS通道上将出现音频数据和辅助数据,这些数据每4位被一组,构成一个上面提到的4位数据包,数据包和视频数据一样,被调制为10位一组的的TMDS信号后发出。视频数据传输期和岛屿数据传输期均开始于一个Guard Band保护频带,Guard Band由2个特殊的字符组成,这样设计的目的在于在明确限定控制数据传输期之后的跳转是视频数据传输期。

HDMI的数据传输周期示意图:左到右分别为控制数据传输期、岛屿数据传输期、视频数据传输期

控制数据传输期,在上面任意两个数据传输周期之间,每一个TMDS通道包含2位的控制数据,这一共6位的控制数据分别为HSYNC(行同步)、VSYNC(场同步)、CTL0、CTL1、CTL2和CTL3。每个TMDS通道包含2位的控制数据,采用从2位到10位的的编码方法,在每个控制周期最后的阶段,CTL0、CTL1、CTL2和CTL3组成的文件头,说明下一个周期是视频数据传输期还是岛屿数据传输期。

岛屿数据和控制数据的传输是在视频数据传输的消隐期,这意味着在传输音频数据和其他辅助数据的时候,并不会占据视频数据传输的带宽,并且也不要一个单独的通道来传输音频数据和其他辅助数据,这也就是为什么一根HDMI数据线可以同时传输视频信号和音频信号的原因。

HDMI的高音视频带宽

HDMI的数据信息的处理可以有多种不同的方式,也就是说HMDI支持多种方式的视频编码,通过对3个TMDS数据信息通道的合理分配,既可以传输RGB数字色度分量的4:4:4信号,也可以传输YCbCr数字色差分量的4:2:2信号,最高可满足24位视频信号的传输需要。

HDMI每个TMDS通道视频像素流的速率一般在25MHz~165MHz之间,HDMI1.3规范已经将这一上限提升到了225MHz,当视频格式的速率低于25MHz时,将使用像素重复法来传输,即视频流中的像素被重复使用。以每个TMDS通道最高165MHz的频率计算,3个TMDS通道传输R/G/B或者Y/Cb/Cr格式编码的24位像素视频数据,最高带宽可以达到4.95Gbps,实际视频信号传输带宽接近4Gbps,而现在最高规格的高清视频格式1080p所需的带宽仅仅为2.2Gbps,因此HDMI拥有的充足带宽不仅可以满足现在高清视频的需要,在今后相当长一段时间内都可以提供对更高清晰度视频格式的支持。

除了高的视频信号带宽之外,HDMI还在协议中加入了对音频信号传输的支持,形成了业界首个单线缆多媒体接口协议。HDMI的音频信号不占用额外的通道,而是采用和其他辅助信息一起组成数据包,利用3个TMDS通道在视频信号传输的消隐期,以岛屿数据的形式传送。即使在传输1080p(60Hz)的视频信号的时候,还可以提供最高8路,每路采样频率192kHz的高质量音频信号,相比之下,CD音频制式44.1kHz的两声道信号,以及最新的DVD-Audio音频格式96kHz的6声道信号,就相形见绌了。

。www.61k.com”

二 : 基于SGIP协议编写短信网关接口

通过不断的调试和沟通,短信功能终于好使了

为了让更多的人少走弯路,特将编写方法和注意事项记录下来,希望能够对大家有帮助;

短信网关的申请流程(此部分工作我们有专门的同事去搞定,我仅略知一二,仅供参考);

向宽带公司(我们用的是联通在信平台)提交申请,然后一顿审核,

审核通过后,宽带公司在网关做数据(分配接入号、公司代码、绑定ip等)

做完数据后会通知接口人,并要求测试

基于SGIP协议的短信接口开发:

我是在华为的短信开发包的基础上开发的,由于不知道该包是否涉及版权问题,所以本人暂不提供了,可以到网上自行解决;

下载后就是一个jar包

短信发送的代码如下:

上行:

import java.io.UnsupportedEncodingException;
import java.math.BigInteger;
import com.huawei.insa2.comm.sgip.message.SGIPMessage;
import com.huawei.insa2.comm.sgip.message.SGIPSubmitMessage;
import com.huawei.insa2.comm.sgip.message.SGIPSubmitRepMessage;
import com.huawei.insa2.util.Args;
import com.huawei.smproxy.SGIPSMProxy;

public class Mt {

    private static String SPNumber = "1065579112";//接入号码
    private static String ChargeNumber = "000000000000000000000"; // 计费号码,我们是白名单
    private static String ServiceType = "JXHD";//服务类型
    private static String host = "192.168.88.156"; // 主机名,网关IP
    private static int port = 8801; // 端口号,这里特别注意下,接入协议中写的是8804,害得我调了很久,后来才知道改了,所以,这个在接入前,建议与网关人员确定
    private static String CorpId = "52322"; // 企业代码
    private static String login_Name = "fslt"; // 登陆名
    private static String login_PassWord = "fslt"; // 登陆密码

    public static void main(String[] args) throws UnsupportedEncodingException {
        int srcnode =new BigInteger("82322").intValue();    //源节点编号,这一步非常重要,华为包中,该字段类型为int,而接入协议中要求在企业代码前加上30000,这样就超过了int的取值范围,所以需要用BigInteger转一下就可以了
        Args argstr = new Args();
        argstr.set("host", host);
        argstr.set("port", port);
        argstr.set("transaction-timeout", 10); // 操作超时时间(单位:秒)
        argstr.set("read-timeout", 15); // 物理连接读操作超时时间(单位:秒)
        argstr.set("source-addr",  srcnode); // SP…ID(最大为六位字符)
        argstr.set("login-name", login_Name);
        argstr.set("login-pass", login_PassWord);
        argstr.set("debug", "false");
        
        // 连接登陆
        SGIPSMProxy sgipsmp = new SGIPSMProxy(argstr); // 这里
        try {
            //connect表示向SMG登陆,登录名与密码分别是SMG向SP分配的用户名与密码,调用这个接口方法,向SMG发送Bind命令消息。(www.61k.com)
            //如果发送消息超时或通信异常则抛出异常,需要调用者捕获处理。
            boolean reslut = sgipsmp.connect(login_Name, login_PassWord); // 登陆得到true和false

            if (reslut) {
                System.out.println("连接成功...........");
            } else {
                System.out.println("连接失败(用户名或密码错误)...........");
                return;
            }
        } catch (Exception ex) {
            System.out.println("网络异常...........");
            ex.printStackTrace();
            return;
        }

        String[] UserNumber = { "8618686619970","8618686619977"};//接收短信的手机号码,前边要加上86

        String content = "抚松联通家校互动项目已成功启动,发送一个测试信息给您!";
        byte[] MessageContent = content.getBytes("GB2312");

        try {
            // 下发短息
            SGIPSubmitMessage sgipsubmit = new SGIPSubmitMessage(
                    SPNumber, // SP的接入号码
                    ChargeNumber, // 付费号码 string
                    UserNumber, // 接收该短消息的手机号,最多100个号码 string[]
                    CorpId, // 企业代码,取值范围为0~99999 string
                    ServiceType, // 业务代码,由SP定义 stirng
                    03, // 计费类型 int
                    "0", // 该条短消息的收费值 stirng
                    "0", // 赠送用户的话费 string
                    0, // 代收费标志0:应收1:实收 int
                    0, // 引起MT消息的原因 int
                    06, // 优先级0~9从低 到高,默认为0 int
                    null, // 短消息寿命的终止时间 date
                    null, // 短消息定时发送的时间 date
                    1, // 状态报告标记 int
                    0, // GSM协议类型 int
                    0, // GSM协议类型 int
                    15, // 短消息的编码格式 int
                    0, // 信息类型 int
                    MessageContent.length, // 短消息内容长度 int
                    MessageContent, // 短消息的内容 btye[]
                    "0" // 保留,扩展用 string
            );
            // 收到的响应消息转换成rep
            int status = ProcessSubmitRep(sgipsmp.send(sgipsubmit));
            System.out.println(status);
            if (status == 0) {
                System.out.println("消息发送成功..........");
            } else {
                System.out.println("消息发送失败..........");
            }
        } catch (Exception ex) {
            ex.printStackTrace();            
        }

    }

    private static int ProcessSubmitRep(SGIPMessage msg) {
        // 收到的响应消息转换成repMsg
        SGIPSubmitRepMessage repMsg = (SGIPSubmitRepMessage) msg;
        System.out.println(repMsg.getSrcNodeId());
        System.out.println("status:::::::" + repMsg.getResult());
        if (repMsg != null && repMsg.getResult() == 0) {
            System.out.println("发送成功:::");
        }
        return repMsg.getResult();
    }

}

 下行:

import com.huawei.insa2.comm.sgip.message.SGIPDeliverMessage;
import com.huawei.insa2.comm.sgip.message.SGIPMessage;
import com.huawei.insa2.comm.sgip.message.SGIPSubmitRepMessage;
import com.huawei.insa2.util.Args;
import com.huawei.smproxy.SGIPSMProxy;

public class Mo extends SGIPSMProxy {

    //SMG服务器信息
    private static String serHost = "192.168.88.156";
    private static int serviceport = 8801;
    
    //本机信息
    private static String localhost = "192.168.88.156";
    private static int localport = 8805;
    
    //private static String login_Name="huanghai";
    //private static String login_PassWord="123456";
    
    public Mo(Args args) {
        super(args);
        System.out.println("进入启动监听........");
        startService(localhost, localport); //我想知道这里传递的host和port是本地的还是那的
    }
    public static void main(String[] args)
    {
        Args argstr = new Args();
        argstr.set("serHost", serHost);
        argstr.set("serviceport", serviceport);
        argstr.set("localhost", localhost);
        argstr.set("localport", localport);
        argstr.set("transaction-timeout", 10); // 操作超时时间(单位:秒)
        argstr.set("read-timeout", 15); // 物理连接读操作超时时间(单位:秒)
        //这里的安全认证问题如何解决?
        
        Mo mymo=new Mo(argstr);        
    }
    /**
     * 收到用户回复的短信(上行)。
     * 
     * @param msg
     *            收到的消息
     * @return 返回的相应消息。
     */
    public SGIPMessage onDeliver(SGIPDeliverMessage msg) {
        /** @todo do some thing to handle this message. then return a response */

        ProcessRecvDeliverMsg(msg);
        System.out.println("正在等待接收.......");
        return super.onDeliver(msg);
    }

    /**
     * 对收到短讯中心下发的短消息的处理。 收到用户信息
     * 
     * @param msg
     *            短讯中心下发的短消息
     */
    public void ProcessRecvDeliverMsg(SGIPMessage msg) {
        if (msg instanceof SGIPSubmitRepMessage) {
            System.out.println("返回下发短信的相应消息");
        }
        if (msg instanceof SGIPDeliverMessage) {
            // 收到用户发送的短信(上行)
            SGIPDeliverMessage deliverMsg = (SGIPDeliverMessage) msg;
            String userNumber = deliverMsg.getUserNumber(); // 手机号码
            String msgContent = deliverMsg.toString(); // 短信内容
            // byte[] msgId = deliverMsg.getMsgContent();
            System.out.println("userNumber::::::" + deliverMsg.getUserNumber());
            System.out.println("msgcontent:::::::" + deliverMsg.toString());
            System.out.println("spNumber::::::::" + deliverMsg.getSPNumber());

            //log.info("收到消息:" + deliverMsg);
            System.out.println("收到消息 :"+deliverMsg);
            
            int commandId = deliverMsg.getCommandId(); // 响应类型
            System.out.println("commandId:::::::::" + commandId);
            if (commandId == 0) { //上传短信(接收)
                System.out.println("dstaddr::::::" + deliverMsg.getSPNumber());
                try {

                } catch (Exception e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
            }
        }
    }
}

代码参考:

http://www.oschina.net/question/96894_13041

JAR包下载+说明书下载+SGIP1.2官方文档:/Files/littlehb/lib.rar

三 : LTE网络接口种类和主要协议

与3G网络相比,LTE网络结构更加扁平化、网络结构功能却更加复杂。省去了RNC一层,原有RNC部分功能上移至EPC设备,而另外一部分功能则下移至eNodeB设备。这种架构使得eNodeB承担了原有RNC的部分控制功能,网络资源分配,网络切换直接由eNodeB完成,并定义了几个新的接口。

LTE网络接口种类和主要协议

接口名称

连接网元

接口功能描述

主要协议

S1-MME

eNodeB - MME

用于传送会话管理(SM)和移动性管理(MM)信息,即信令面或控制面信息

S1-AP

S1-U

eNodeB - SGW

在GW与eNodeB设备间建立隧道,传送用户数据业务,即用户面数据

GTP-U

X2-C

eNodeB - eNodeB

基站间控制面信息

X2-AP

X2-U

eNodeB - eNodeB

基站间用户面信息

GTP-U

S3

SGSN - MME

在MME和SGSN设备间建立隧道,传送控制面信息

GTPV2-C

S4

SGSN – SGW

在S-GW和SGSN设备间建立隧道,传送用户面数据和控制面信息

GTPV2-C

GTP-U

S5

SGW – PGW

在GW设备间建立隧道,传送用户面数据和控制面信息(设备内部接口)

GTPV2-C

GTP-U

S6a

MME – HSS

完成用户位置信息的交换和用户签约信息的管理,传送控制面信息

Diameter

S8

SGW – PGW

漫游时,归属网络PGW和拜访网络SGW之间的接口,传送控制面和用户面数据

GTPV2-C

GTP-U

S9

PCRF-PCRF

控制面接口,传送QoS规则和计费相关的信息

Diameter

S10

MME - MME

在MME设备间建立隧道,传送信令,组成MME Pool,传送控制面数据

GTPV2-C

S11

MME – SGW

在MME和GW设备间建立隧道,传送控制面数据

GTPV2-C

S12

RNC –SGW

传送用户面数据,类似Gn/Gp SGSN控制下的UTRAN与GGSN之间的Iu-u/Gn-u接口。

GTP-U

S13

MME –EIR

用于MME和EIR中的UE认证核对过程

GTPV2-C

Gx(S7)

PCRF – PGW

提供QoS策略和计费准则的传递,属于控制面信息

Diameter

Rx

PCRF –IP承载网

用于AF传递应用层会话信息给PCRF,传送控制面数据

Diameter

SGi

PGW – 外部互联网

建立隧道,传送用户面数据

DHCP/Radius

/IPSEC/L2TP/GRE

SGs

MME - MSC

传递CSFB的相关信息

SGs-AP

Sv

MME - MSC

传递SRVCC的相关信息

GTPv2-C

Gy

P-GW - OCS

传送在线计费的相关信息

Diameter

四 : WCDMA_Iu接口协议介绍79

WCDMA Iu接口协议介绍

? Iu接口概述 ? RANAP协议主要消息流程

? Iu接口主要业务流程

? Iu-CS接口的用户面协议 ? Iu-PS接口的用户面协议

Iu接口在WCDMA系统中的位置

GMSC Gs Gb GGSN

VMSC/VLR Iu-CS A BSS Abis BTS Uu BTS

SGSN

Iu-PS

RNC Iub NODE B Um NODE B

Iu接口与空中Uu接口的协议转换关系

SMS / G美眉 / 美眉

Relay

NAS AS

SMS / G美眉 / 美眉

NAS AS

RRC RLC MAC L1

RRC RLC MAC L1

RANAP SCCP Signalling Bearer AAL5 ATM

RANAP SCCP Signalling Bearer AAL5 ATM Iu

Uu

UE

RNS

MSC/ SGSN N

注:Iu接口协议 RANAP以下(含),属于接入层(AS:Assess Stratum) RANAP之上(不含)属于非接入层(NAS:non-assess stratum)

Iu接口的3个作用域

UTRAN

Node B RNC Node B

Core Network (CN)

CS Domain “Iu-CS” PS Domain “Iu-PS”

Node B RNC Node B

BC Domain “Iu-BC”

Iu Interface

注:1个RNC最多存在1个Iu-PS接口,1个Iu-CS接口,但可以有多个Iu-BC接口

lu-PS与Iu-CS接口使用RANAP协议,lu-BC域使用SABP协议

CS域的Iu接口协议结构

Radio Network Layer Control Plane RANAP User Plane Iu UP Protocol Layer

Transport Network Layer

Transport Network User Plane

Transport Network Control Plane

Q.2630.1

Transport Network User Plane

SCCP MTP3b SSCF-NNI SSCOP AAL5

Q.2150.1 MTP3b SSCF-NNI SSCOP AAL5 AAL2

ATM Physical Layer

CS域的Iu接口协议结构

?上图中SSCF-NNI,SSCOP,AAL5 协议合称SAAL-NNI协议 ?Iu接口CS域的控制面采用RANAP协议,运用SCCP提供的0 类与两类业务类型,与GSM的A接口功能类似 ?Iu接口CS域的用户面采用AAL2(ATM 两类适配层),为 语音通讯提供固定的持续的比特速率(AMR语音速率)

?用户面微通道的建立与释放,采用传送网络控制协议 (TNCP:ITU-T Q.2630.1)

?电路域信令面与用户面分离是3G比2G的1个突破

PS域的Iu接口协议结构

Radio Network Layer Control Plane User Plane Iu UP Protocol Layer

RANAP

Transport Network Layer

Transport Network User Plane

Transport Network Control Plane

Transport Network User Plane

SCCP M3UA MTP3-B SCTP SSCF-NNI SSCF-NNI SSCOP AAL5 IP GTP-U UDP IP AAL5

ATM Physical Layer

ATM Physical Layer

PS域的Iu接口协议结构

? 在SCCP与AAL52个层次之间,有2种协议方案:SAAL + MTP3B 和 SIGTRAN,只需使用其中的1种 ? 由于PS呼叫的特性:数据突发性,可变的速率要求, 用户面使用 AAL5(可变比特速率)来与ATM适配;由于 每个呼叫不需要单独专用的微通道,PS域没有SVC的分配 与释放流程,所以不需要传输网络的控制面功能 ? 单个用户的数据包的相关性的标识,通过GTP-U协议 实现(RANAP分配TEID与GTP-U联系)

Iu-BC接口协议栈体系结构

Radio Network Layer SA Broadcast Plane SABP Protocol Layer

Transport Network Layer

Transport Network User Plane

TCP IP AAL5

ATM Physical Layer

Iu-BC接口协议栈体系结构

? 1个RNC

可以和几个CBC相连,就可以以有几个Iu-BC 域, CBC可以分别用于不同类型的消息广播(如天气预报,股 票信息等) ? BC域的无线网络层(RNL)协议为SABP协议(业务区广 播协议),对应规范为TS25.419 ? SABP直接使用TCP/IP提供的服务

Iu接口协议规范

Radio Network Layer Control Plane User Plane Cell Broadcast Plane

25.413

25.415

25.419

Transport Network Layer

Transport Network User Plane

Transport Network Control Plane

Transport Network User Plane

Transport Network User Plane

25.412

25.414

25.411

Iu接口协议规范

23.930 23.110 25.410 25.411 25.412 25.413 25.414 25.415 25.419

Iu设计准则(Iu Principles) UMTS接入层业务与功能 UTRAN Iu接口:总述及原则 UTRAN Iu接口:UTRAN Iu 层1接口 UTRAN Iu接口信令传输 UTRAN Iu接口RANAP信令 UTRAN Iu接口数据传输与传输信令 UTRAN Iu接口用户面协议 UTRAN Iu接口服务区广播协议(SABP)

? Iu接口概述 ? RANAP协议主要消息流程

? Iu接口主要业务流程

? Iu-CS接口的用户面协议 ? Iu-PS接口的用户面协议

RANAP主要消息流程概述/分类

从消息传送方式分,RANAP的基本过程可以分为2类:面向连 接型和无连接型。前者在Iu接口需要建立1个专用的连接,与特 定的单个UE相关;后者在RNC与CN间传送,不须建立专用连接 其中,复位(Reset)、复位资源(Reset Resource)、流量 控制(Overload Control) 、寻呼(Paging)采用 SCCP 无连接 业务进行传递; 错误指示(Error Indication)按具体情况决定 采用无连接业务还是面向连接业务;其它流程采用面向连接业务 面向连接的消息都是与单个UE相关的消息,如UE 的位置更新 流程,呼叫流程;无连接消息是与系统维护管理有关的消息,影 响部分或所有的UE用户 RANAP无连接消息大多是可以上下行双向的(Paging消息除 外),面向连接的消息大多是单向的(Error Indicaion和 Direct Transfer消息除外)

RANAP主要消息流程概述/分类

为方便介绍,我们将RANAP消息流程分为以下几类:

? Iu信令连接建立/释放/直接传输

? SRNC迁移 ? 指配/加密/寻呼协调 ? PS域特有流程 ? 无连接消息流程

Iu信令连接建立/释放/直接传输

R N C S : Ril E s e CC i a M ) C ( t Ue P I n s a g S :C CC C P

连立 接阶 建段

C N

D Ts ie r f rt a r c n e D Ts ie r f rt a r c n e

数送 据阶 传段

I R eqt u la e s e R e s u e I R em ula o a e C n e s m d I R em ula olt e Ce e s p e S :L CR C S P D S :L CR C C P

连放 接阶 释段

Iu信令连接建立/释放/直接传输

Initia l UE Message CN Do main Indicator LA I RA C SAI NAS-PDU 表 明 RNC 发 来的 此消息是 发往 CS 域还 是 PS 域 , 用 于 CS / PS 合 设(共用 一 个 信令点) 时作为 区分 ; UE 当 前所在 的位置区 路 由区(仅 用于 PS 域 ) UE 当 前所在

业务区 层 3信 息(UE 直 接发送给 CN 的 经过 RNC 透 传的消 息), 表明 UE 发 起事务 的 原 因:位置 更新、 呼叫、短 消息始 发、补充 业务激活 等 唯 一标识 Iu 接 口的1个 处理事 务, 对 应于 SCCP 面 向连 接业务的 1个连 接号 码; RANAP 协 议层次 的 RNC 标 识 , 与 SCCP/ MTP 层 的信 令点编 码对应 ; 包 含 UE -- CN 间 透传消 息的内容 ,属于 TS24.008协 议 的内容 此 IE 仅 在 下行方向 需要。目 前取值 有两种 : SAPI 0 对应 普通呼 叫业务, 3 对 应于 SMS 短 消息业 务; 原 因值 原 因值 SAPI

Iu Signalling Connection Identifier Global RNC-ID Direct Transfer NAS-PDU SAPI Iu Release Request Iu Release Co mmand Cause Cause

Iu信令连接建立/释放/直接传输

?Iu信令连接的概念: 是 UE 与 CN 之间事务处理的1个标识:其生命周期起始于事务处理的开 始,终止于事务处理的结束 CN也可以发起Iu连接建立(迁移的目的侧),在迁移一节专门描述 ?RNC发起连接建立的原因: RNC 发起连接连接,是由于收到了 UE 发起的某种事务处理请求,包括: 位置更新/IMSI 分离 呼叫 短消息始发 补充业务激活等 ?UE与CN间消息在Iu接口的透传机制: 连接建立前: 通过Initial UE Message 中的 NAS-PDU 传递 连接建立后: UE与CN间的透传消息在Iu接口通过Direct Transfer消息中的NAS-PDU传递

Iu信令连接建立/释放/直接传输

?Iu 连接释放原因 正常情况下都是由CN主动发起Iu释放,CN主动发起Iu释放的原因: UE和CN间事务结束 CN接收到了Iu Release Request消息 SRNS的重定位结束 RNC只有在接入侧发生异常的情况下才会发起Iu释放请求,其主动发起 Iu释 放请求的原因有: O&M 干预 非特定原因 用户非活动态 一致性检查失败 UE产生的信令连接释放 与UE的无线连接丢失 ?连接释放的一般步骤 事务处理完毕:位置更新成功;主被叫挂机等;异常失败; Iu连接释放 SCCP连接释放

SRNS迁移

R NC2

R NC1 连接已经建立 R elocation R equired

CN

S CCP: CR ( R elocation R equest) S CCP: CC

R elocatin R Ack eq.

R elocation Command

R elocation Detect R elocation Complete

Iu 释放/ S CCP 释放

呼叫在目的侧继续

Iu-CS 接口迁移成功流程

SRNS迁移

Relocation required Relocation Type Cause Source ID Target ID MS Classmark 2 MS Classmark 3 Source RNC To Target RNC Transparent Container Old BSS To New BSS Information Target RNC To Source RNC Transparent Container L3 Information RABs To Be Released RABs Subject To Data Forwarding

Critica lity Diagnostics

原 因值 原 服务区( SAI) 目 标服 务区( SAI) MS 的 级别信息2( 向 GSM 系 统切换时) MS 的 级别信息3( 向 GSM 系 统切换时) SRNC 向 TRNC 透传的消息

原 BSS 向新 BSS 透传的信息(向 GSM 系 统切换时) TRNC 向 SRNC 透传的消

Relocation Command

L3 信息 要 被释放的 RAB ID 组 需 要数据前转的 RAB ID 及其相关的用户面信息 诊 断 IE

SRNS迁移

1、前图画的是SRNC与DRNC属于同一CN下成功切换的情况; 若两者属于不同CN,则RANAP消息要经过E接口的消息传递到 目标CN

2、SRNS在CN内部RNC之间的迁移,对于CN来说,就是CN与UE 之间的连接从经由RNC1转到经由RNC2,CN与RNC1的连接释放, 重新建立起与RNC2的连接

SRNS迁移

迁移协调

?切换源侧RNC对两条Iu信令连接的协调

?当RNC与CN的CS、PS各存在1个Iu信令连接时,Relocation

Required消息向CS、

PS同时发出 ?RNC只有从CS、PS都收到了Relocation Command消息之后,才发起SRNS的切换 ?当RNC从其中的一条Iu信令连接上收到 Relocation Preparation Failure消息后, RNC要主动在另外一条信令连接上发送Relocation Cancel消息 ?当源侧RNC主动发起Relocation Cancel消息时,应向CS、PS都要发送

?切换目的侧RNC对两条Iu信令连接的协调

?目的侧RNC运用Relocation

Request中的IMSI来协调两个Iu信令连接 ?目的侧RNC只有全收到 CS、PS来的 Relocation Request消息之后,才回 Relocation Requet Acknowledge 消息同时给给CN的CS、PS ?RNC发给CS、PS的Relocation Request Ack消息中的 IE “Target RNC to Source RNC Transparent Container ” 不应有冲突 ? “ Relocation Complete ” , “ Relocation Cancel ”消息,也应在2条Iu信令 连接上都要发送

SRNS迁移

RNC1

CN

RNC2

连接已经建立 Relocation Required

Relocation Request S CCP CC

Relocation Prep. Failure 呼叫在源侧继续进行

Relocation Failure Iu 释放/ S CCP 释放

迁移目的侧资源分配失败流程

SRNS迁移

迁移目的侧资源分配失败流程 1、迁移目标侧RNC资源分配失败,目标RNC向CN发起 Relocation Failure消息

2、CN收到上述消息之后,向源侧RNC发起Relocation Prep. Failure 消息

3、切换目标侧的Iu连接释放掉,呼叫在源侧继续保持

SRNS迁移

RNC1 连接已经建立 Relocation Required

CN

RNC2

Relocation Request S CCP CC Relocatin Req. Ack

Relocation Command Relocation Cancel Relocation Cancel Ack. 呼叫在源侧继续保持 Iu 释放/ S CCP 释放

迁移源侧主动取消迁移流程

SRNS迁移

迁移源侧主动取消迁移流程 1、切换取消可以发生在切换准备(Relocation Preparation)流程的过程中,或在切换准备流程之后。 也就是说,Relocation Cancel消息可以在收到CN的 Relocation Command之前发送,在CN下发Relocation Command消息之后,RNC也仍然可以发起 Relocation Cancel流程 2、源侧RNC发起Relocation Required流程之后,若没 有收到CN的迁移取消或迁移命令,不能连续发起第2次 Relocation Required流程

指配/加密/寻呼协调

除了前面的 2 类消息外,以下 RANAP 消息完成与 呼叫过程相关的一些特别的功能,专列为一

类:

?RAB 指配

?加密 ?寻呼协调

指配/加密/寻呼协调:指配

R N C

C N

R n eS A meu B e u t) An s p s tq e s R i g t ( E2 消 R 3息 Q0 ) (6 Q . . 1 E2 消 C3息 F 0 ) (6 Q . . 1 R n e( p A mn ) B ep e A not s ts S s R u i g s e

Iu 接口 RAB 指配过程(建立)

指配/加密/寻呼协调:指配

R N C R su A es B R Re e q l e e a t R n eR A m sa B eu ls A n ee s tq e s R i g t ( e ) R n e( a A m ne B ep e A no ls s ts R s R i g s e e ) R6 息 E3 ) L 0 ( Q消 . . 2 1 R6 息 L2 消 C0 ) ( 3 Q . . 1

C N

Iu 接口 RAB 指配过程(释放)

指配/加密/寻呼协调:指配

R N C

C N

I e od us m R m lea e a C n Ie o us p R m l el e a e C t e R6 息 E3 ) L 0 ( Q消 . . 2 1 R6 息 L2 消 C0 ) ( 3 Q . . 1

Iu接口Iu释放伴随RAB释放

指配/加密/寻呼协调:指配

? AAL2信令的建立与释放流程,仅在CS域存在,PS域不需要;传输网络控制面与信令面 流程通过BindingID(含在RAB Assign. Req中,与AAL2信令的ERQ消息的IE SUGR是相同 的),这样,就将同1个呼叫的用户面与信令面关联起来了 ? 用户面资源的分配由RNC发起(CS 域);1个RAB ID对应于1个AAL2信令连接,1个 AAL2信令的连接建立/释放流程只能对应1个 RAB ID ? RAB指配请求(建立)消息中实际上只含有对于用户面资源的QoS要求、用户面地址/版 本等信息,真正的用户面资源由AAL2信令(TNCP:传输网络控制面)来建立 ? RAB指配流程(释放)消息中含有要释放的RAB ID及释放原因;此流程也同时伴随着 AAL2信令的释放流程(CS域)

? 在异常情况下(如RNC检测到用户面资源故障,或资源被抢占),RNC也可以发起 RAB Release Request

? 若某个Iu信令连接上存在多个 RAB ID , 当其中的某个呼叫(对应1个RAB ID )结 束时,只要通过RAB指配流程释放其中1个RAB ID资源即可了 ? 如果1个Iu信令连接上只指配了1个RAB ID ,当此RAB ID释放时,可以直接用 Iu释 放流程,不必使用RAB指配流程(释放)

指配/加密/寻呼协调:指配

RAB Assignment Request RABs To Be Setup Or Modified

>First Setup Or Modify Item >>RAB ID >>NAS Synchronisation Indicator >>RAB Parameters >>User Plane Information >>>User Plane Mode >>>UP Mode Versions >>Transport Layer Information >>>Transport Layer Address >>>Iu Transport Association >>Service Handover >Second Setup Or Modify Item >> PDP Type Information >>Data Volume Reporting Indication >>DL GTP-PDU Sequence Number >>UL GTP-PDU Sequence Number >>DL N-PDU Sequence Number >>UL N-PDU Sequence Number RABs To Be Released >RAB ID >Cause

最 先建立或修改的 RAB 信 息 RAB 标 识 仅 在 RAB Modify 使 用 RAB QoS 参数, 用来指示 RNC 选择合适的用户面资源 用 户面模式:支持模式或透明模式 用 户面版本:目前只支持版本1 ; 传 送层信息 CN 本 端的 ATM 地址 CS: Binding id PS: GTP TEID

五 : 接口协议

接口协议还有很多


PS/2接口协议是现在大多数键盘、鼠标与PC机通讯的标准协议。其中鼠标对PC机的通讯更为简单,只是传输数据的内容不一样而已


EPC ALE[2] 协议是EPC 中间件与阅读器模块和客户应用程序之间的接口协议. 该协议定义了客户可以如何过虑和整合来自多个阅读器的EPC标签


NetBIOS协议是1种在局域网上的程序(www.61k.com)可以使用的应用程序编程接口(API)


GSM的无线信令接口协议是指GSM 的Um接口上信令及其传输所应遵守的规定
本文标题:接口协议-HDMI接口与协议
本文地址: http://www.61k.com/1160308.html

61阅读| 精彩专题| 最新文章| 热门文章| 苏ICP备13036349号-1