CN101094162A - 一种采用头部去除方式传输媒体流的方法 - Google Patents
一种采用头部去除方式传输媒体流的方法 Download PDFInfo
- Publication number
- CN101094162A CN101094162A CNA2006100864521A CN200610086452A CN101094162A CN 101094162 A CN101094162 A CN 101094162A CN A2006100864521 A CNA2006100864521 A CN A2006100864521A CN 200610086452 A CN200610086452 A CN 200610086452A CN 101094162 A CN101094162 A CN 101094162A
- Authority
- CN
- China
- Prior art keywords
- field
- head
- payload
- address
- length
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种采用头部去除(HR)方式传输媒体流的方法，该方法包括如下步骤：A.网络侧和用户终端(UE)分别根据主被叫地址信息以及净荷类型配置自身的头部重组器；B.UE/网络侧的头部去除器将承载媒体流的报文的头部删除，然后将所述报文的净荷发送至网络侧/UE；C.网络侧/UE的头部重组器收到净荷后，根据步骤A配置的所述信息生成报文头部，并将所生成的报文头部与所接收到的净荷组合生成报文。本发明方法可以在空口只发送IMS媒体流而不发送报文头部，有效利用空口资源，从而增加系统容量。
Description
技术领域
本发明涉及无线通信技术领域，特别涉及一种采用头部去除(HeadRemoval，HR)方式传输媒体流的方法。
背景技术
IP多媒体子系统(IP Multimedia Subsystem，IMS)媒体流以压缩的媒体分组包的传输来实现媒体数据的传输，占用资源少，由此带来的突出优点是成本很低，价格便宜，因此被认为商业前景巨大，并被应用于许多领域，特别是第三代(3G)无线通信系统中，其中包括采用了通用无线分组业务(General Packet Radio Service，GPRS)的宽带码分多址(Wideband CodeDivision Multiple Access，WCDMA)系统。
WCDMA系统的网络架构图如图1所示，由用户设备(User Equipment，UE)101、无线接入网(Radio Access Network，RAN)102、核心网(CoreNetwork，CN)103和外部网络104组成，其中RAN 102进一步包括基站105和无线网络控制器(Radio Network Controller，RNC)106，CN 103进一步包括GPRS业务支持节点(Service GPRS Support Node，SGSN)107和GPRS网关支持节点(Gateway GPRS Support Node，GGSN)108。
WCDMA系统提供广播(BC)域、电路交换(Circuit Switch，CS)域和分组业务(Packet Service，PS)域的接入和传输。目前BC域提供系统内广播，CS域提供电路交换的业务的接入和传输，PS域提供分组业务的接入和传输，其中主要是互联网协议(Internet Protocol，IP)报文的接入和传输。承载IMS媒体数据的IP报文通过基于用户数据报协议(User DatagramProtocol，UDP)/IP承载的实时传输协议(Real-time Transport Protocol，RTP)进行传输，因此也是在PS域中进行接入和传输。UE和外部网络之间的IP报文的传输过程如下：
以从UE到外部网络的传输为例，IP报文由UE 101通过无线链路的空中接口Uu以及基站105传输给RNC 106，再由RNC 106通过Iu接口传给SGSN 107，SGSN 107再将IP报文传送给GGSN 108，并由GGSN 108将IP报文发送到外部网络103；从外部网络到UE的传输则是按照相反的顺序进行传输。
在上述传输过程中，SGSN根据不同的业务的服务质量(Quality ofService，QoS)建立无线接入承载(Radio Access Bearer，RAB)，并将RAB映射到Uu接口和Iu接口，而RNC建立无线承载(Radio Bearer，RB)上，并将RB映射到Uu接口。第三代合作伙伴计划(Three Generation PartnershipProject，3GPP)定义的Uu接口的协议结构如图2所示。从纵向来看，Uu接口分为接入层(AS)和非接入层(NAS)，AS通过如下业务接入点(SAP)：通用控制(GC)、通告(Nt)、专用控制DC)为NAS提供业务。NAS分为三个协议层，从下到上依次为：
L1无线物理层，通过传输信道(Transport Channel)提供Uu口的数据传输服务；
L2数据链路层，又分为三个子层：媒体接入控制层(MAC)、无线链路控制层(RLC)、广播控制层(BMC)和分组数据聚合协议层(PDCP)；其中MAC利用L1无线物理层提供的数据传递业务向高层提供数据传递、无线资源和MAC参数的重新分配、测量报告等业务；RLC通过报文的分片、重组、确认重传、排序、流控等提供报文在RB上的传输；BMC提供广播服务；PDCP提供报文在RB上的分流、压缩等服务；MAC层通过与RLC层间的SAP向RLC层提供逻辑信道，逻辑信道分为两类：控制信道和业务信道，其中控制信道用来传送控制平面信息，包括广播控制信道(BCCH)、寻呼控制信道(PCCH)、专用控制信道(DCCH)、公共控制信道(CCCH)和共享信道控制信道(SHCCH)；业务信道用来传送用户平面信息，包括专用业务信道(DTCH)和公共业务信道(CTCH)；
L3网络层，包括无线资源控制层(RRC)，RRC处理UE和UTRAN间L3的控制平面信令，RRC主要完成下述功能：来自NAS和AS信息的广播，UE和UTRAN间RRC连接的建立、重建、维护和释放，用户平面无线承载的建立、重配和释放，RRC连接的无线资源的指配、重配置和释放等。
WCDMA系统中，承载IMS媒体流的IP/UDP/RTP报文结构如图3所示，包括头部和净荷两部分，其中头部又分为IP头部、UDP头部、RTP头部，净荷即为报文所承载的IMS媒体流数据。若IP头部为IPv4头部格式，则长度为20字节，其格式如图4所示；若IP头部为IPv6头部格式，则长度为40字节，其格式如图5所示。UDP头部和RTP头部格式分别如图6和图7所示，以上图4至图7各个头部格式的具体内容将在后面详述。
目前在3GPP UTRAN中传输IMS媒体流时，将IP/UDP/RTP头部和净荷一起传输，庞大的IP/UDP/RTP头部将极大地浪费空口资源，从而降低系统容量。为解决这个问题，提出了一种新的传输IMS媒体流的方案：发送方通过空中接口发送媒体流时，先将庞大的IP/UDP/RTP头部去除，只发送IMS媒体流数据，即报文的净荷部分；接收方再根据必要的信息恢复原来的IP报文；这种方案被称作HR。但是到目前为止，在WCDMA系统上采用HR技术传输媒体流的标准还在制定中，尚无HR具体的实现方法。
发明内容
有鉴于此，本发明的目的在于，提出一种采用HR方式传输媒体流的方法，可以实现通过HR方式发送IMS媒体流，提高空口资源的利用率。该方法包括如下步骤：
A、网络侧和用户终端UE分别根据主被叫地址信息以及净荷类型配置自身的头部重组器；
B、UE/网络侧的头部去除器将承载媒体流的报文的头部删除，然后将所述报文的净荷发送至网络侧/UE；
C、网络侧/UE的头部重组器收到净荷后，根据步骤A配置的所述信息生成报文头部，并将所生成的报文头部与所接收到的净荷组合生成报文。
所述主被叫地址信息包括源IP地址、目的IP地址、源端口和目的端口。
所述步骤A之前进一步包括：
AA1、主被叫UE确定媒体流的净荷类型、通知对方UE自身的IP地址和端口；
AA2、主被叫任一方UE将自身IP地址和端口作为源IP地址和端口，将会话另一方UE的IP地址和端口作为目的IP地址和端口，并向网络侧发送包含源IP地址、目的IP地址、源端口、目的端口以及净荷类型的启用HR指示信息。
步骤AA1为：主被叫UE通过会话初始协议SIP进行会话信息协商，确定媒体流的净荷类型、通知对方UE自身的IP地址和端口。
步骤A进一步包括：网络侧或UE根据源IP地址或目的IP地址的长度确定报文头部长度，并将所确定的报文头部长度存入自身的头部去除器中；
则步骤B所述UE/网络侧的头部去除器将承载媒体流的报文的头部删除为：UE/网络侧的头部去除器根据所存储的报文头部长度将承载媒体流的报文的头部删除。
所述报文为IP/用户数据报协议UDP/实时传输协议RTP报文。
步骤A所述确定报文头部长度为：若源IP地址长度为32比特，则确定报文长度为40字节；若源IP地址长度为128比特，则确定报文长度为60字节。
步骤B进一步包括：UE/网络侧的头部去除器从报文头部中提取出序列号，通过带外信令将所提取的序列号发送至网络侧/UE。
步骤B所述将净荷发送至网络侧/UE之前，进一步包括：UE/网络侧的头部去除器从报文头部中提取出序列号，将所提取的序列号写入净荷中。
步骤B所述将净荷发送至网络侧/UE之前，进一步包括：UE/网络侧的头部去除器从报文头部中提取出序列号，并生成仅包括所提取的序列号的头部；
则所述将净荷发送至网络侧/UE为：将带有所生成的仅包括序列号的头部的净荷发送至网络侧/UE。
步骤C所述生成报文头部包括生成RTP头部、UDP头部和IP头部；
则所述生成RTP头部为：将版本字段写为2，将P/X/CC字段都写为0；若所收到的是第一个净荷时，将M字段设置为1，否则设置为0；将所配置的净荷类型写入净荷类型PT字段；将所收到的序列号写入序列号字段；在收到第一个净荷时，随机产生初始时间戳Time Stamp值为TS0，将TS0写入Time Stamp字段；收到第n个净荷时，根据公式TSn＝TS0+(SNn-SN0)×Delta计算出TSn，并将TSn写入Time Stamp字段，其中，SN0为第一个净荷的序列号，SNn为第n个净荷的序列号，当PT字段为3时Delta为160，当PT字段为9时Delta为320；在收到第一个净荷时产生一个随机值写入同步源标识符字段SSRC，收到第n个净荷时，仍然将第一次生成的随机值写入SSRC；n为大于1的整数；
所述生成UDP头部为：将所配置的源端口和目的端口分别写入源端口字段和目的端口字段；将所收到净荷的长度加上RTP头部长度12字节以及UDP头部长度8字节得到的总长度写入长度字段；根据所收到的净荷以及所生成的源端口字段、目的端口字段以及长度字段用预设的算法计算出检验总和Checksum字段的值，并将该值写入Checksum字段，或者将Checksum字段设置为0；
则所述生成IP头部为：若源IP地址长度或目的IP地址长度为32比特，则设置版本字段的值为4，若源IP地址长度或目的IP地址长度为128比特，则设置版本字段的值为6；
若版本字段被设置为4，则设置IHL字段的值为5，设置服务类型TOS字段的值为0，将UDP头部的长度字段的值加20后写入总长度字段；在收到第一个净荷时产生随机值写入IP ID字段，在收到第n个净荷时将前一个IP ID字段的值加1后写入IP ID字段；将分段字段中的保留指示设置为0，不分段指示设置为1，更多分段指示设置为0，并将段偏移字段设置为0；设置默认值，并将所设置的默认值写入生存时间TTL字段；将协议字段设置为17；根据重组后的头部生成Checksum字段或者将Checksum字段设置为0；将所设置的源IP地址和默认IP地址分别写入源IP地址字段和默认IP地址字段；
若版本字段被设置为6，则将通行级别字段设置为0，将流标签字段设置为0，将所收到的净荷长度加上RTP头部长度12字节和UDP头部长度8字节得到的值写入净荷长度字段；将下一个头部字段设置为17；设置默认值，并将所设置的默认值写入路由限制字段；将所设置的源IP地址和目的IP地址分别写入源IP地址字段和目的IP地址字段；将已确定的UDP头部写入下一个头部内容字段。
所述网络侧的头部重组器与头部去除器位于无线网络控制器RNC、服务GPRS支持节点、或网关GPRS支持节点GGSN。
从以上技术方案可以看出：在传输媒体流之前，UE和网络侧根据源IP地址、目的IP地址、源端口、目的端口、净荷类型等必要信息配置自身的头部重组器，这样UE或网络侧任何一方，将承载媒体流的IP/UDP/RTP报文头部去除后向对方发送媒体流净荷，而接收媒体流净荷的一方的头部重组器根据已配置的信息生成IP/UDP/RTP报头，将所生成的报头与净荷组合在一起生成完整的IP/UDP/RTP报文。这样就实现了空口只传送报文的净荷部分，有效利用空口资源，从而增加系统容量。
附图说明
图1为WCDMA系统网络框架及IMS媒体流的传输示意图；
图2为Uu接口的分层结构示意图；
图3为IP/UDP/RTP报文结构示意图；
图4为图3所示的报文中IPv4格式IP头部结构示意图；
图5为图3所示的报文中IPv6格式IP头部结构示意图；
图6为图3所示的报文中的UDP头部结构示意图；
图7为图3所示的报文中RTP头部结构示意图；
图8为本发明采用HR方式实现IMS媒体流传输的流程图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细阐述。
目前3GPP协议中只定义了与HR相关的两个功能实体：头部去除器(Head Tripper)和头部重组器(Header Reconstructor)，且规定这两个实体必须同时位于RNC和UE。头部去除器负责去除媒体流的IP/UDP/RTP头部，然后再将净荷帧在链路上发送；头部重组器负责从链路接收IMS媒体帧，然后重组IP/UDP/RTP头部。在该过程中，需要提供必要的信息给头部重组器来重组IP、UDP和RTP头部，同时也需要考虑配置给RNC的参数以及如何将这些参数配置给RNC。
如3GPP标准TS26.236中描述的一样，对3GPP IMS语音服务，RTP净荷承载以自适应多速率(Adaptive Multiple Rate，AMR)或AMR-WB码进行编码语音数据包含下面的限制：
1.每个RTP分组里面只能封装一个语音帧。
2.不能使用信道复用会话。
因此RTP包在传输过程中通常不会被分段。所以在IP/UDP/RTP头部中有很多部分都是固定不变的，更利于我们采用HR技术。下面以3GPP IMS语音服务为例，分别对RTP头部、UDP头部以及IP头部中的各个字段内容进行分析，指出在HR技术中，哪些字段信息为需要与IMS媒体流一起传送的必要信息，以及如何给RNC配置参数。
RTP报文头部如图7所示，其中：
版本(Version)、P、X、CC字段：这些字段是固定不变的。标准文档RFC3550规定版本字段为2，由于在WCDMA系统的IMS中规定不允许在一个语音流中同时使用多个会话也不允许包含RTP头包含扩展信息，所以P、X和CC字段始终为0；因此，不需要配置这些字段给头部重组器。
M字段：3GPP规定中的AMR，AMR-WB编码格式的语音采用RTP传输时，当发送的是第一个RTP分组时，M字段置1，其余全部置0，因此，头部重组器可以在收到第一个净荷时将该位置1，其余全部置0，故该字段不需要配置给头部重组器。
净荷类型(Payload Type，PT)字段：该字段代表RTP净荷采用何种类型编码。当采用AMR编码时为3，采用AMR-WB编码时为9，因此该字段需要配置给头部重组器，配置后保持不变。
序列号(Sequence Number)字段：该字段由发送方初始化为一个随机值，每发送一个RTP分组，该字段都将增加1；由于RTP分组到达头部去除器的时间可能有先后差别，因而序列号到达头部去除器时可能并不是每个都增加1；因此该字段需要每次发送，头部去除器可以采用多种方法传输该字段，比如将它放入去除头部后的净荷中传输，也可以通过带外信令传输等。
时间戳(Time Stamp)字段：3GPP系统的IMS中规定每个RTP分组的净荷只包含一个语音帧，AMR的采样率为8000Hz，一个语音帧为20ms，因此每个RTP分组的Time Stamp的值将增加(20/1000)÷(1/8000)＝160；而AMR-WB的采样率为16000Hz，所以每个RTP分组的Time Stamp将增加320；即编码类型一定时，Time Stamp的值将按照一个固定的值增加。
因此，在收到第一个净荷时，头部去除器功能实体可以产生一个随机的Time Stamp记为TS0，设头部重组器收到的第一个序列号值为SN0，TimeStamp的固定增量Delta可以通过配置的PT字段值得到，即若PT＝3，则Delta＝160；若PT＝9，则Delta＝320。以后若收到的序列号为SN，则Time Stamp的值TS为：
TS＝TS0+(SN-SN0)×Delta。
故该字段不需要配置给头部重组器。但是头部重组器内部需要有一个映射表，如表1所示：
| Payload Type | Time Stamp Delta |
| 3 | 160 |
| 9 | 320 |
表1
同步源标识符字段(Synchronization Symbol Resource Sect，SSRC)：该字段是发送方产生的一个随机值，且在发送的所有分组中保持不变，因此可以在头部重组器收到第一个净荷时产生一个随机值，并且以后收到净荷时同样用该值重组头部即可，故该字段不需要配置给头部重组器。
综上，在RTP头部中需要配置给头部重组器的信息只有PT字段。其中PT字段在会话初始协议(Session Initiation Protocol，SIP)协商后UE就可以知道。
UDP的报文头部如图6所示，其中：
源端口(Source Port)字段用于标识发送方的语音流端口号，该字段需要配置给头部重组器；
目的端口(Destination Port)字段用于标识接收方的语音流端口号，该字段需要配置给头部重组器；
长度(Length)字段：该字段为UDP头部和净荷部分长度的总和，它可以由头部重组器根据收到的净荷长度计算出UDP分组的总长度，即总长度＝收到的净荷长度+RTP头部长度(12字节)+UDP头部长度(8字节)；因此该字段不需要配置给头部重组器。
检验总和(Checksum)字段：该字段的生成有固定的计算方法，头部重组器可以根据收到的净荷和重组后的头部一起计算出Checksum，若不需要该值的话可以将其直接设0；因此该字段不需要配置给头部重组器。
综上，在UDP头部中需要配置给头部重组器的信息有源端口和目的端口字段。
对于IP头部，先考虑IPv4格式的IP头部，如图4所示，其中：
版本(Version)字段用于标识所采用的IP版本，IPv4为4，IPv6为6。头部重组器可以通过根据IP头部的源IP地址(Source IP Address)字段长度或目的IP地址(Destination IP Address)来判断是IPv4或IPv6：若长度为32比特则表示采用的是IPv4，则重组时设置版本字段为4；若为长度128比特则表示采用的是IPv6，则重则时设置版本字段为6。因此该字段不需要配置给头部重组器。
IP头部长度(IP Head Length，IHL)字段以4字节的倍数来表示头部的大小，当没有IPv4扩展选项时，是固定值为5，因此该字段不需要配置给头部重组器。
服务类型(Type of Service，TOS)字段目前没有被使用，所以头部重组器可以直接设置为0，因此该值不需要配置给头部重组器。
总长度(Total Length)字段：该字段表示IP数据包的长度，包括头部和IP净荷的长度。该字段的值可以设置为重组后的UDP头部中的长度字段+20。因此该字段不需要配置给头部重组器。
IP ID字段：通常的IP协议栈的发送方每发送一个IP分组，该字段的值都会被加1，由于IMS媒体帧没有分段和段重组，可以让头部重组器在收到第一个净荷时产生一个随机值作为IP ID，以后每收到一个净荷将其加1即可。因此该字段不需要配置给头部重组器。
分段(Frag)和段偏移(Fragment Offset)字段：其中Frag有3比特，包含保留指示(Reserved，R)，不分段指示(Don’t Fragment，DF)，更多分段指示(More Frag，MF)，在不分段的情况下，R＝0，DF＝1，MF＝0，且Fragment Offset＝0，都是固定值。因此分段和段偏移字段不需要配置给头部重组器。
生存时间(Time to Live，TTL)字段：IPv4分组每经过一个路由器，该值减1，当TTL的值减为0时，则丢弃IPv4分组。该值对接收方不是很重要，在头部重组器可以默认设定一个值，比如30。因此该字段不需要配置给头部重组器。
协议(Protocol)字段：当应用层采用UDP时，该值固定为17，因此该字段不需要配置给头部重组器。
检验总和(Checksum字段)：该字段可以按照重组后的头部重新生成，若不需要该值的话可以将其直接设0。因此该字段不需要配置给头部重组器。
源IP地址(Source IP Address)字段和目的IP地址(Destination IPAddress)字段分别用于标识发送方的IP地址以及接收方的IP地址，因此这两个字段需要配置给头部重组器。
综上所述，在IPv4头部中，需要配置给头部重组器的信息有源IP地址字段和目的IP地址字段。
IPv6格式的IP头部如图5所示，其中：
版本字段同前IPv4版本字段的处理，该字段不需要配置给头部重组器。
通行级别(Tranffic Class)字段默认设置为0，该字段不需要配置给头部重组器。
流标签(Flow Label)字段默认值为0，该字段不需要配置给头部重组器。
净荷长度(Payload Length)字段用于表示IPv6净荷的长度，头部重组器可以通过实际的净荷长度加上RTP头部长度和UDP头部长度计算出来，因此该字段不需要配置给头部重组器。
下一个头部(Next Header)字段：该字段和IPv4中的协议字段一样，表示下一个头部的类型。当采用UDP时，该值固定为17，因此该字段不需要配置给头部重组器。
路由限制(Hop Limit)字段：该字段和IPv4中的TTL字段一样，IPv6分组每经过一个路由器该值将减1，当该值为0时，路由器将丢弃该IPv6分组，头部重组器可以设置一个默认的值给该字段，比如30，故该字段不需要配置给头部重组器。
源IP地址(Source IP Address)字段和目的IP地址(Destination IPAddress)字段分别用于标识发送方的IP地址以及接收方的IP地址，因此这两个字段需要配置给头部重组器。
下一个头部内容(Next Header Content)字段即为UDP头部，因此该字段按照对UDP头部的讨论内容来配置。
综上所述，不论采用IPv4还是IPv6来传输3GPP IMS语音会话，都需要配置给头部去除器的参数有主被叫双方的地址信息和净荷类型，主被叫双方地址信息包括源IP地址、目的IP地址、源端口和目的端口；净荷类型为PT字段；而序列号需要每次和净荷一起发送。由于头部去除器和头部重组器必须同时位于RNC和UE，所以当UE通过SIP协议协商会话信息后，若UE决定启用HR方式，并在自身的头部重组器配置上述参数后，启用HR指示以及上述参数发送给RNC；RNC根据所收到的启用HR指示启用HR功能，并根据所收到的上述参数配置头部重组器，而头部去除器只需要将到达它的IP语音分组的IP/UDP/RTP头部去掉即可，所以头部去除器可以根据配置给头部重组器的源IP地址字段或目的IP地址字段的大小判断采用的是IPv4还是IPv6，从而去除相应大小的头部即可。若IP/UDP/RTP报文中承载其他格式的媒体信息，如多媒体、媒体流等，只要满足1.每个RTP分组里面只封装一个媒体帧；2.使用单一信道进行会话，则同样适用上述讨论。
根据以上讨论，采用HR方式实现IMS媒体流传输的完整流程如图8所示，包括如下步骤：
步骤801：主被叫UE通过SIP协议进行会话信息协商，确定媒体流的净荷类型，并通知对方自身的IP地址以及端口号；
步骤802：进行会话的任一UE独立决定是否采用HR方式，若不用HR方式，则采用原有的IP/UDP/RTP报文传输方式进行传输；若采用HR方式，则该UE向RNC发送启用HR指示消息，该消息中包括源IP地址、源端口、目的IP地址、目的端口以及净荷类型；其中，源IP地址及源端口为该UE自身的IP地址及端口号，目的IP地址及目的端口为会话另一方UE的IP地址及端口号。
步骤803：RNC收到启用HR指示消息，根据其中的源IP地址、源端口、目的IP地址、目的端口以及净荷类型配置头部重组器，根据源IP地址或目的IP地址的长度判断采用的是IPv4还是IPv6，若是IPv4，则确定报文头部长度为40字节，若是IPv6，则确定报文头部长度为60字节，用所确定头部的长度配置头部去除器。UE采用相同的方式配置自身头部重组器与头部去除器。
步骤804：本步骤分成如下两种情况：
1)上行方向发送IMS媒体流：UE的头部去除器将IP/UDP/RTP报文头部中的序列号提取出来，然后将报文最前部与所配置的报文头部长度相同长度的部分删除，将删除后剩下的净荷部分发送至RNC，并通过带外信令向RNC发送序列号；
2)下行方向发送IMS媒体流：RNC的头部去除器将IP/UDP/RTP报文头部中的序列号提取出来，然后将报文最前部与所配置的报文头部长度相同长度的部分删除，将删除后剩下的净荷部分发送至UE，并通过带外信令向UE发送序列号；
步骤805：本步骤也分成两种情况：
1)上行方向接收IMS媒体流：RNC收到净荷和序列号后，头部重组器根据步骤803所配置的参数以及序列号生成报文头部，并将所生成的报文头部与净荷组合起来生成IP/UDP/RTP报文；
2)下行方向接收IMS媒体流：UE收到净荷和序列号后，头部重组器根据步骤803所配置的参数以及序列号生成报文头部，并将所生成的报文头部与净荷组合起来生成IP/UDP/RTP报文。所述生成报文头部中各个字段的方式可采用前面对各个字段的讨论结果所述的方式。
其中，发送序列号可以采用其他方式，例如，将序列号添加到净荷中或将原报文头部去除后生成一个仅包括序列号的头部，从而实现将序列号和净荷一起发送。或者当网络状况比较稳定时也可以不发送序列号，在配置头部重组器时，将双方的头部重组器同步，双方的头部重组器保存有相同的初始序列号；发送方每发送一个净荷，则发送方的头部存储器保存的序列号加1，接收方每接收一个净荷，其头部重组器根据所保存的序列号以及其他配置信息生成报文头部，然后头部重组器保存的序列号加1。
实际应用中，网络侧的头部重组器和头部去除器不一定在RNC中，也可设置在SGSN或GGSN中，甚至不一定在同一个网元中，例如，将头部去除器设置于RNC中，而将头部重组器设置于GGSN中；其采用HR方式实现IMS媒体流传输的流程与上述流程基本类似，只是实现的地点有所差别。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。
Claims (12)
1、一种采用头部去除HR方式传输媒体流的方法，其特征在于，该方法包括如下步骤：
A、网络侧和用户终端UE分别根据主被叫地址信息以及净荷类型配置自身的头部重组器；
B、UE/网络侧的头部去除器将承载媒体流的报文的头部删除，然后将所述报文的净荷发送至网络侧/UE；
C、网络侧/UE的头部重组器收到净荷后，根据步骤A配置的所述信息生成报文头部，并将所生成的报文头部与所接收到的净荷组合生成报文。
2、根据权利要求1所述的方法，其特征在于，所述主被叫地址信息包括源IP地址、目的IP地址、源端口和目的端口。
3、根据权利要求2所述的方法，其特征在于，所述步骤A之前进一步包括：
AA1、主被叫UE确定媒体流的净荷类型、通知对方UE自身的IP地址和端口；
AA2、主被叫任一方UE将自身IP地址和端口作为源IP地址和端口，将会话另一方UE的IP地址和端口作为目的IP地址和端口，并向网络侧发送包含源IP地址、目的IP地址、源端口、目的端口以及净荷类型的启用HR指示信息。
4、根据权利要求3所述的方法，其特征在于，步骤AA1为：主被叫UE通过会话初始协议SIP进行会话信息协商，确定媒体流的净荷类型、通知对方UE自身的IP地址和端口。
5、根据权利要求2所述的方法，其特征在于，步骤A进一步包括：网络侧或UE根据源IP地址或目的IP地址的长度确定报文头部长度，并将所确定的报文头部长度存入自身的头部去除器中；
则步骤B所述UE/网络侧的头部去除器将承载媒体流的报文的头部删除为：UE/网络侧的头部去除器根据所存储的报文头部长度将承载媒体流的报文的头部删除。
6、根据权利要求2所述的方法，其特征在于，所述报文为IP/用户数据报协议UDP/实时传输协议RTP报文。
7、根据权利要求6所述的方法，其特征在于，步骤A所述确定报文头部长度为：若源IP地址长度为32比特，则确定报文长度为40字节；若源IP地址长度为128比特，则确定报文长度为60字节。
8、根据权利要求6所述的方法，其特征在于，步骤B进一步包括：UE/网络侧的头部去除器从报文头部中提取出序列号，通过带外信令将所提取的序列号发送至网络侧/UE。
9、根据权利要求6所述的方法，其特征在于，步骤B所述将净荷发送至网络侧/UE之前，进一步包括：UE/网络侧的头部去除器从报文头部中提取出序列号，将所提取的序列号写入净荷中。
10、根据权利要求6所述的方法，其特征在于，步骤B所述将净荷发送至网络侧/UE之前，进一步包括：UE/网络侧的头部去除器从报文头部中提取出序列号，并生成仅包括所提取的序列号的头部；
则所述将净荷发送至网络侧/UE为：将带有所生成的仅包括序列号的头部的净荷发送至网络侧/UE。
11、根据权利要求8、9或10所述的方法，其特征在于，步骤C所述生成报文头部包括生成RTP头部、UDP头部和IP头部；
则所述生成RTP头部为：将版本字段写为2，将P/X/CC字段都写为0；若所收到的是第一个净荷时，将M字段设置为1，否则设置为0；将所配置的净荷类型写入净荷类型PT字段；将所收到的序列号写入序列号字段；在收到第一个净荷时，随机产生初始时间戳Time Stamp值为TS0，将TS0写入Time Stamp字段；收到第n个净荷时，根据公式TSn＝TS0+(SNn-SN0)×Delta计算出TSn，并将TSn写入Time Stamp字段，其中，SN0为第一个净荷的序列号，SNn为第n个净荷的序列号，当PT字段为3时Delta为160，当PT字段为9时Delta为320；在收到第一个净荷时产生一个随机值写入同步源标识符字段SSRC，收到第n个净荷时，仍然将第一次生成的随机值写入SSRC；n为大于1的整数；
所述生成UDP头部为：将所配置的源端口和目的端口分别写入源端口字段和目的端口字段；将所收到净荷的长度加上RTP头部长度12字节以及UDP头部长度8字节得到的总长度写入长度字段；根据所收到的净荷以及所生成的源端口字段、目的端口字段以及长度字段用预设的算法计算出检验总和Checksum字段的值，并将该值写入Checksum字段，或者将Checksum字段设置为0；
则所述生成IP头部为：若源IP地址长度或目的IP地址长度为32比特，则设置版本字段的值为4，若源IP地址长度或目的IP地址长度为128比特，则设置版本字段的值为6；
若版本字段被设置为4，则设置IHL字段的值为5，设置服务类型TOS字段的值为0，将UDP头部的长度字段的值加20后写入总长度字段；在收到第一个净荷时产生随机值写入IP ID字段，在收到第n个净荷时将前一个IP ID字段的值加1后写入IP ID字段；将分段字段中的保留指示设置为0，不分段指示设置为1，更多分段指示设置为0，并将段偏移字段设置为0；设置默认值，并将所设置的默认值写入生存时间TTL字段；将协议字段设置为17；根据重组后的头部生成Checksum字段或者将Checksum字段设置为0；将所设置的源IP地址和默认IP地址分别写入源IP地址字段和默认IP地址字段；
若版本字段被设置为6，则将通行级别字段设置为0，将流标签字段设置为0，将所收到的净荷长度加上RTP头部长度12字节和UDP头部长度8字节得到的值写入净荷长度字段；将下一个头部字段设置为17；设置默认值，并将所设置的默认值写入路由限制字段；将所设置的源IP地址和目的IP地址分别写入源IP地址字段和目的IP地址字段；将已确定的UDP头部写入下一个头部内容字段。
12、根据权利要求1～10任一项所述的方法，其特征在于，所述网络侧的头部重组器与头部去除器位于无线网络控制器RNC、服务GPRS支持节点SGSN、或网关GPRS支持节点GGSN。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2006100864521A CN101094162A (zh) | 2006-06-21 | 2006-06-21 | 一种采用头部去除方式传输媒体流的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2006100864521A CN101094162A (zh) | 2006-06-21 | 2006-06-21 | 一种采用头部去除方式传输媒体流的方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101094162A true CN101094162A (zh) | 2007-12-26 |
Family
ID=38992199
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA2006100864521A Pending CN101094162A (zh) | 2006-06-21 | 2006-06-21 | 一种采用头部去除方式传输媒体流的方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101094162A (zh) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102056235A (zh) * | 2009-11-09 | 2011-05-11 | 华为技术有限公司 | 一种数据传输方法、设备和系统 |
| CN102347955A (zh) * | 2011-11-01 | 2012-02-08 | 杭州依赛通信有限公司 | 一种基于虚拟通道的可靠数据传输协议 |
| CN104320390A (zh) * | 2009-06-25 | 2015-01-28 | 皇家飞利浦电子股份有限公司 | 用于处理数据分组的方法和设备 |
| CN104662931A (zh) * | 2012-10-17 | 2015-05-27 | 高通股份有限公司 | 用于减少针对nfc数据交换协议消息的开销的方法和装置 |
| WO2015154557A1 (zh) * | 2014-08-21 | 2015-10-15 | 中兴通讯股份有限公司 | 数据报文的传输处理方法及装置 |
| WO2017185368A1 (zh) * | 2016-04-29 | 2017-11-02 | 华为技术有限公司 | 一种信令传输方法和设备 |
| WO2021134346A1 (zh) * | 2019-12-30 | 2021-07-08 | 华为技术有限公司 | 一种反馈方法及装置 |
| CN113438297A (zh) * | 2021-06-22 | 2021-09-24 | 京信网络系统股份有限公司 | 数据传输方法、装置、网元设备和计算机可读存储介质 |
-
2006
- 2006-06-21 CN CNA2006100864521A patent/CN101094162A/zh active Pending
Cited By (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10694008B2 (en) | 2009-06-25 | 2020-06-23 | Koninklijke Philips N.V. | Method and device for processing data packets |
| CN104320390A (zh) * | 2009-06-25 | 2015-01-28 | 皇家飞利浦电子股份有限公司 | 用于处理数据分组的方法和设备 |
| US11683403B2 (en) | 2009-06-25 | 2023-06-20 | Koninklijke Philips N.V. | Method and device for processing data packets |
| US11323551B2 (en) | 2009-06-25 | 2022-05-03 | Koninklijke Philips N.V. | Method and device for processing data packets |
| CN104320390B (zh) * | 2009-06-25 | 2017-12-22 | 皇家飞利浦电子股份有限公司 | 用于处理数据分组的方法和设备 |
| US10791204B2 (en) | 2009-06-25 | 2020-09-29 | Koninklijke Philips N.V. | Method and device for processing data packets |
| WO2011054259A1 (zh) * | 2009-11-09 | 2011-05-12 | 华为技术有限公司 | 一种数据传输方法、设备和系统 |
| CN102056235A (zh) * | 2009-11-09 | 2011-05-11 | 华为技术有限公司 | 一种数据传输方法、设备和系统 |
| US9055471B2 (en) | 2009-11-09 | 2015-06-09 | Huawei Technologies Co., Ltd. | Data transmission method, apparatus and system |
| CN102056235B (zh) * | 2009-11-09 | 2017-04-26 | 华为技术有限公司 | 一种数据传输方法、设备和系统 |
| CN102347955A (zh) * | 2011-11-01 | 2012-02-08 | 杭州依赛通信有限公司 | 一种基于虚拟通道的可靠数据传输协议 |
| CN104662931A (zh) * | 2012-10-17 | 2015-05-27 | 高通股份有限公司 | 用于减少针对nfc数据交换协议消息的开销的方法和装置 |
| CN104662931B (zh) * | 2012-10-17 | 2019-01-08 | 高通股份有限公司 | 用于减少针对nfc数据交换协议消息的开销的方法和装置 |
| US10225310B2 (en) | 2014-08-21 | 2019-03-05 | Xi'an Zhongxing New Software Co. Ltd. | Transmission processing methods and apparatuses of data packet |
| WO2015154557A1 (zh) * | 2014-08-21 | 2015-10-15 | 中兴通讯股份有限公司 | 数据报文的传输处理方法及装置 |
| WO2017185368A1 (zh) * | 2016-04-29 | 2017-11-02 | 华为技术有限公司 | 一种信令传输方法和设备 |
| WO2021134346A1 (zh) * | 2019-12-30 | 2021-07-08 | 华为技术有限公司 | 一种反馈方法及装置 |
| CN113438297A (zh) * | 2021-06-22 | 2021-09-24 | 京信网络系统股份有限公司 | 数据传输方法、装置、网元设备和计算机可读存储介质 |
| CN113438297B (zh) * | 2021-06-22 | 2022-07-29 | 京信网络系统股份有限公司 | 数据传输方法、装置、网元设备和计算机可读存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100608844B1 (ko) | ＶｏＩＰ 서비스를 제공하는 무선통신 시스템 | |
| CN1615618B (zh) | 双向分包数据传输系统和方法 | |
| US7558240B2 (en) | Radio telecommunications apparatus and method for communications internet data packets containing different types of data | |
| EP1604535B1 (en) | Telecommunications apparatuses and method for communicating internet protocol packet data | |
| EP1053608B1 (en) | Device and method for communicating packet voice data in mobile communication system | |
| CN101047711B (zh) | Ip报文传输、协商带宽节省能力和节省网络带宽的方法 | |
| CN101347012B (zh) | 使用共享补充扩展码的、结合基于ip的语音的无线通信网络 | |
| CN101094162A (zh) | 一种采用头部去除方式传输媒体流的方法 | |
| CN101213802A (zh) | 用于控制经由分组网络支持语音业务的移动通信系统中的语音业务速率的方法和装置 | |
| CN101369977A (zh) | 数据传输的方法、装置和系统 | |
| JP2006522518A5 (zh) | ||
| JP2007221797A (ja) | 移動通信システムのｍｂｍｓサービスのためのｐｄｃｐ構造及び動作方法 | |
| US20090225702A1 (en) | Uplink transmission method, downlink transmission method, and convergence device | |
| CN101388825A (zh) | 一种传输gprs隧道协议数据包的方法和设备 | |
| WO2009026845A1 (fr) | Procédé d'émission et de réception de données, appareil de point d'accès sans fil, passerelle et système de communication | |
| CN100579069C (zh) | 语音前向纠错信息传输在cdma2000系统中的实现方法 | |
| CN101170487B (zh) | 数据流复用中的压缩方法和压缩系统以及压缩设备 | |
| CN100407694C (zh) | 降低实时业务时延及时延抖动的方法 | |
| CN107886961A (zh) | 基于VoLTE承载的自适应多速率中低速话音优化方法 | |
| CN100428744C (zh) | 通信网络中分组数据的传输方法及其系统 | |
| US20050152341A1 (en) | Transmission of voice over a network | |
| US7170858B2 (en) | Rate control for multiplexed voice and data in a wireless communications system | |
| CN100454906C (zh) | 在无线分组网中传输基于网络承载的语音流的方法及网关 | |
| US8391284B2 (en) | Usage of feedback information for multimedia sessions | |
| KR20080015693A (ko) | 이동통신시스템에서 단말의 버퍼 상태 보고 방법 및 장치 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
| WD01 | Invention patent application deemed withdrawn after publication |