CN106416356A - 上行数据包处理方法、装置和基站 - Google Patents
上行数据包处理方法、装置和基站 Download PDFInfo
- Publication number
- CN106416356A CN106416356A CN201580032765.6A CN201580032765A CN106416356A CN 106416356 A CN106416356 A CN 106416356A CN 201580032765 A CN201580032765 A CN 201580032765A CN 106416356 A CN106416356 A CN 106416356A
- Authority
- CN
- China
- Prior art keywords
- upstream data
- data bag
- packets
- base station
- rohc
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明实施例涉及上行数据包处理方法、装置和基站,该方法由基站执行,基站支持ROHC功能,且针对UE的ROHC功能处于开启状态,该方法包括:接收所述UE发送的上行数据包;当所述上行数据包为IP数据包,或者,对所述UE发送的上行数据包解压缩失败的次数达到门限次数时,向核心网传输所述上行数据包,其中,向核心网传输所述上行数据包之前,不对所述上行数据包进行ROHC解压缩处理。由上可见,本发明实施例中设定了两种触发条件,可以在满足上述两种触发条件中的任意一种时,不对上行数据包进行ROHC解压缩处理,而是直接将上行数据包传输给核心网,从而保障了语音质量,提高了基站上行ROHC特性的兼容性和灵活性。
Description
本发明涉及无线通信领域,尤其涉及上行数据包处理方法、装置和基站。
稳健包头压缩(Robust Header Compression,ROHC)协议是互联网工程任务组(Internet Engineering Task Force,IETF)针对无线链路的特点提出的稳健包头压缩技术规范。ROHC能实现头压缩,是因为同一数据流连续包头中存在一些静态域,在数据流刚开始传递时,ROHC压缩方将完整包头即静态域和动态域值保存在压缩上下文中,后续包参照此上下文进行压缩,仅传递变化的动态域,从而有效利用无线带宽资源。ROHC解压方收到新包时,将完整包头保存到本地的解压缩上下文中,后续的压缩包参照此上下文进行解压缩。这里所述的静态域是指不变的域,或者不是随机变化,而是按照一定规律变化的域。
ROHC技术能有效对抗压缩器和解压缩器之间的丢包现象,在保证稳健性的前提下,通过包头压缩减少头负荷节省带宽,极大地提高了系统无线空口资源的利用率,提升无线空口速率。ROHC协议的典型应用是网络电话,例如,用于基于互联网协议的语音传输(Voice over Internet Protocol,VoIP)中。当前,很多基站和用户设备(User Equipment,UE)都支持ROHC功能,UE根据ROHC协议对数据包进行压缩处理,当基站从该UE接收到数据包时,根据ROHC协议对数据包进行解压缩处理。
然而,现有技术中,由于某些终端厂商和基站厂商对ROHC协议理解不一致,导致某些UE直接向基站发送了原始的互联网协议(Internet Protocol,
IP)数据包。此时,若基站开启了针对该UE的ROHC功能,会对接收到的IP数据包,进行解压缩处理,解压缩失败后会把IP数据包当做非法格式的压缩包进行丢包处理,这样就会出现通话中断或者单通或者双不通,影响语音质量。
发明内容
本发明实施例提供了上行数据包处理方法、装置和基站,以提高基站上行ROHC特性的兼容性和灵活性,从而提高语音通话的质量。
第一方面,提供了一种上行数据包处理方法,所述方法由基站执行,所述基站支持ROHC功能,且针对UE的所述ROHC功能处于开启状态,所述方法包括:
接收所述UE发送的上行数据包;
当所述上行数据包为IP数据包,或者,对所述UE发送的上行数据包解压缩失败的次数达到门限次数时,向核心网传输所述上行数据包,其中,向核心网传输所述上行数据包之前,不对所述上行数据包进行ROHC解压缩处理。
结合第一方面,在第一方面的第一种可能的实现方式中,向核心网传输所述上行数据包之前,所述方法还包括:
确定所述上行数据包是否为IP数据包;
当所述上行数据包为IP数据包时,执行所述向核心网传输所述上行数据包的步骤。
结合第一方面的第一种可能的实现方式,在第一方面的第二种可能的实现方式中,所述确定所述上行数据包是否为IP数据包,包括:
对所述上行数据包的包头进行解析,获得所述上行数据包的包头首字节;
当所述包头首字节标识出所述上行数据包为互联网协议版本4(Internet Protocol version4,IPv4)数据包或互联网协议版本6(Internet Protocol version6,IPv6)数据包时,确定所述上行数据包为IP数据包。
结合第一方面,在第一方面的第三种可能的实现方式中,向核心网传输所述上行数据包之前,所述方法还包括:
统计对所述UE发送的上行数据包解压缩失败的次数;
当所述统计的次数达到所述门限次数时,执行所述向核心网传输所述上行数据包的步骤。
结合第一方面或第一方面的第一种至第三种中任一种可能的实现方式,在第一方面的第四种可能的实现方式中,当对所述UE发送的上行数据包解压缩失败的次数达到门限次数时,所述方法还包括:
关闭针对所述UE的所述ROHC功能。
第二方面,提供了一种上行数据包处理装置,所述装置设置于基站中,所述基站支持ROHC功能,且针对UE的所述ROHC功能处于开启状态,所述装置包括:
接收单元,用于接收所述UE发送的上行数据包;
确定单元,用于确定所述接收单元接收的所述上行数据包是否为IP数据包,或者,用于确定对所述UE发送的上行数据包解压缩失败的次数是否达到门限次数;
传输单元,用于当所述接收单元接收的所述上行数据包为IP数据包,或者,对所述UE发送的上行数据包解压缩失败的次数达到门限次数时,向核心网传输所述上行数据包,其中,向核心网传输所述上行数据包之前,不对所述上行数据包进行ROHC解压缩处理。
结合第二方面,在第二方面的第一种可能的实现方式中,所述确定单元包括:
统计子单元,用于统计对所述UE发送的上行数据包解压缩失败的次数;
确定子单元,用于当所述统计子单元统计出的次数达到门限次数时,确定对所述UE发送的上行数据包解压缩失败的次数达到门限次数。
结合第二方面,在第二方面的第二种可能的实现方式中,所述确定单元
包括:
解析子单元,用于对所述上行数据包的包头进行解析,获得所述上行数据包的包头首字节;
确定子单元,用于当所述解析子单元获得的所述包头首字节标识出所述上行数据包为IPv4数据包或IPv6数据包时,确定所述上行数据包为IP数据包。
结合第二方面或第二方面的第一种或第二种可能的实现方式,在第二方面的第三种可能的实现方式中,所述装置还包括:
关闭单元,用于在对所述UE发送的上行数据包解压缩失败的次数达到门限次数时,关闭针对所述UE的所述ROHC功能。
第三方面,提供了一种基站,所述基站支持ROHC功能,且针对UE的所述ROHC功能处于开启状态,所述基站包括:存储器、处理器、第一接口电路和第二接口电路;其中,所述第一接口电路用于所述基站与所述UE通信;所述第二接口电路用于所述基站与核心网通信;所述存储器,用于存储程序指令;所述处理器用于调用所述存储器存储的程序指令以执行:
通过所述第一接口电路接收所述UE发送的上行数据包;
确定所述上行数据包是否为IP数据包,或者,确定对所述UE发送的上行数据包解压缩失败的次数是否达到门限次数;
当所述上行数据包为IP数据包,或者,对所述UE发送的上行数据包解压缩失败的次数达到门限次数时,向核心网传输所述上行数据包,其中,向核心网传输所述上行数据包之前,不对所述上行数据包进行ROHC解压缩处理。
结合第三方面,在第三方面的第一种可能的实现方式中,所述存储器中存储使所述处理器确定对所述UE发送的上行数据包解压缩失败的次数是否达到门限次数的程序指令,以供所述处理器调用以执行:
统计对所述UE发送的上行数据包解压缩失败的次数;
当统计出的次数达到门限次数时,确定对所述UE发送的上行数据包解压
缩失败的次数达到门限次数。
结合第三方面,在第三方面的第二种可能的实现方式中,所述存储器中存储使所述处理器确定所述上行数据包是否为IP数据包的程序指令,以供所述处理器调用以执行:
对所述上行数据包的包头进行解析,获得所述上行数据包的包头首字节;
当所述包头首字节标识出所述上行数据包为IPv4数据包或IPv6数据包时,确定所述上行数据包为IP数据包。
结合第三方面或第三方面的第一种或第二种可能的实现方式,在第三方面的第三种可能的实现方式中,所述处理器还用于调用所述存储器中存储的程序指令以执行:
在对所述UE发送的上行数据包解压缩失败的次数达到门限次数时,关闭针对所述UE的所述ROHC功能。
本发明实施例提供了一种上行数据包处理方法,设定了两种触发条件:条件一,当上行数据包为IP数据包;条件二,对该UE发送的上行数据包解压缩失败的次数达到门限次数时。可以在满足上述两种触发条件中的任意一种时,不对上行数据包进行ROHC解压缩处理,而是直接将上行数据包传输给核心网,从而减少了对IP数据包进行解压缩处理后,基站将IP数据包当做非法格式的压缩包进行丢包处理所引起的通话中断等问题,相应地保障了语音质量,提高了基站上行ROHC特性的兼容性和灵活性。
图1为本发明实施例一提供的上行数据包处理方法流程图;
图2为IPv4数据包包头结构示意图;
图3为IPv6数据包包头结构示意图;
图4为本发明实施例二提供的上行数据包处理方法流程图;
图5为本发明实施例一提供的另一种上行数据包处理方法流程图;
图6为本发明实施例二提供的另一种上行数据包处理方法流程图;
图7为本发明实施例三提供的上行数据包处理装置结构图;
图8为本发明实施例三中确定单元702的一种组成结构图;
图9为本发明实施例三中确定单元702的另一种组成结构图;
图10为本发明实施例四提供的基站结构图。
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
考虑到IP数据包虽然未经过ROHC压缩处理,但在内容上并非错包、乱包,如果直接将其向上层透传,并不会对后续处理造成影响,反而有利于保证语音通话的连续性。此外,对于某个UE的数据包连续解压缩失败的情况下,基站也可以考虑对该UE退出ROHC,即不再对该UE的上行数据包进行ROHC解压缩处理,以保证通话的连续性。
因此,本发明实施例提供了一种上行数据包处理方法,针对现有技术中存在的由ROHC处理所引起的通话中断等问题,基站改进了现有的处理流程,通过透传IP数据包或退出ROHC等方式来提高语音通信的质量。例如,当基站支持ROHC功能,且针对UE的ROHC功能处于开启状态时,基站在接收到UE发送的上行数据包后,当上行数据包为IP数据包,或者,对该UE发送的上行数据包解压缩失败的次数达到门限次数时,直接向核心网传输未经ROHC解压缩的上行数据包,即将上行数据包直接向上传输,其中,传输上行数据包之前,不对上行数据包进行ROHC解压缩处理。由上可见,本发明实施例中,设定了两种触发条件:条件一,当上行数据包为IP数据包;条件二,对该UE
发送的上行数据包解压缩失败的次数达到门限次数时。可以在满足上述两种触发条件中的任意一种时,不对上行数据包进行ROHC解压缩处理,而是直接将上行数据包传输给核心网,从而减少了对IP数据包进行解压缩处理后,基站将IP数据包当做非法格式的压缩包进行丢包处理所引起的通话中断等问题,相应地保障了语音质量,提高了基站上行ROHC特性的兼容性和灵活性。
此外,也可以将条件一和条件二结合使用,例如,在满足条件一时,直接传输未经ROHC解压缩处理的上行数据包,但不关闭基站对该UE的ROHC功能;而当满足条件二时,关闭基站对该UE的ROHC功能,之后,基站在接收到该UE的上行数据包时,无需再对条件一进行判断,而是直接传输未经ROHC解压缩处理的上行数据包。
图1为本发明实施例一提供的上行数据包处理方法流程图,该方法由基站执行,该基站支持ROHC功能,且针对某个UE的ROHC功能处于开启状态,具体通过条件一触发传输未经ROHC解压缩的上行数据包的动作,该方法包括:
步骤101,接收该UE发送的上行数据包。
其中,上行数据包可能为压缩包,也可能为IP数据包。当基站针对该UE的ROHC功能处于开启状态时,通常情况下,基站接收的该UE发送的上行数据包应当为压缩包,但是,由于终端厂商和基站厂商对ROHC协议理解不一致或其他原因,基站接收的该UE发送的上行数据包可能为IP数据包。
步骤102,确定上行数据包是否为IP数据包。
本发明实施例中,可以采取如下方式确定上行数据包是否为IP数据包:对上行数据包的包头进行解析,获得上行数据包的包头首字节,当包头首字节标识出上行数据包为互联网协议版本4(Internet Protocol version4,IPv4)数据包或互联网协议版本6(Internet Protocol version6,IPv6)数据包时,确定该上行数据包为IP数据包。
参照图2所示的IPv4数据包包头结构示意图,以及,图3所示的IPv6数据包包头结构示意图,可知,IPv4数据包和IPv6数据包的包头首字节中均
包含用来标识IP数据包版本的字段,例如,Version字段。因此通过对上行数据包的包头进行解析,获得上行数据包的包头首字节,就可以确定该上行数据包是否为IP数据包。
此外,由于同一数据流连续数据包的包头中存在一些静态域,在数据流刚开始传递时,ROHC压缩方将完整包头即静态域和动态域值保存在压缩上下文中,后续数据包参照此压缩上下文进行压缩,仅传递变化的动态域,从而有效利用无线带宽资源。ROHC解压方收到新的数据包时,将完整包头保存到本地的解压缩上下文中,后续的压缩包参照此解压缩上下文进行解压缩。当针对UE的ROHC功能处于开启状态后,首先处于初始无上下文(NoContext,NC)状态下,ROHC解压端应该收到初始和上下文失败后恢复状态(Initialization and Refresh,IR)包,以建立解压端的解压缩上下文,只有当解压缩方建立起完整的上下文,压缩方才发送ROHC压缩包。
如果ROHC上行收到的第一个上行数据包不是IR包,那么解压端上下文无法建立,该上行数据包被丢掉,解压端继续处于NC状态,基站会给UE发送反馈信息,使其尽快发送IR包,使得通讯继续。如果接下来收到的上行数据包仍然不是IR包,解压端上下文无法建立,收到的上行数据包继续被丢掉。其中,IP数据包就是非IR包中的一类,如果UE一直发送IP数据包,那么这些IP数据包全部会被丢掉。
本发明实施例中,还可以采取如下方式确定上行数据包是否为IP数据包:判断解压端上下文是否激活;当判断出解压端上下文未激活时,确认处于NC状态;对上行数据包的包头进行解析,根据IR包类型标识位判断该上行数据包是否为IR包;当该上行数据包非IR包时,获得上行数据包的包头首字节,当包头首字节标识出上行数据包为IPv4数据包或IPv6数据包时,确定该上行数据包为IP数据包。
通过上述方式确定上行数据包是否为IP数据包,可以当针对UE的ROHC功能处于开启状态后,首先处于NC状态下时,当基站上行收到原始IP报文
时,不丢包,保障语音质量,提高基站对某些终端的容错性。其中,由于在NC状态下,基站应当收到UE发送的IR包,因此上述方式中先判断上行数据包是否为IR包,当判断出上行数据包非IR包时,再进一步判断上行数据包是否为IP数据包,从而可以在判断出上行数据包为IR包时,对上行数据包根据ROHC协议进行解压缩处理。
步骤103,当上行数据包为IP数据包时,向核心网传输上行数据包,其中,传输上行数据包之前,不对上行数据包进行ROHC解压缩处理。
通常地,基站接收到的压缩包会由分组数据汇聚协议(Packet Data Convergence Protocol,PDCP)层实体进行解压缩处理后,再向上层上传,本发明实施例中,当上行数据包为IP数据包时,由于其不是压缩包,因此不通过PDCP层实体进行解压缩处理,而是直接将上行数据包向上层透传。
本发明实施例提供了一种上行数据包处理方法,该方法由基站执行,该基站支持ROHC功能,且针对UE的ROHC功能处于开启状态,当接收到该UE发送的上行数据包后,当上行数据包为IP数据包时,不对上行数据包进行ROHC解压缩处理,而是直接向核心网传输上行数据包,从而避免了对IP数据包进行解压缩处理后,基站将IP数据包当做非法格式的压缩包进行丢包处理所引起的通话中断等问题,相应地保障了语音质量,提高了基站上行ROHC特性的兼容性和灵活性。
需要说明的是,条件二还可以用于关闭ROHC处理,以上方法可以和条件二结合使用,即在基站收到IP数据包的次数达到预设次数时,可以关闭ROHC处理。或者,当对UE发送的上行数据包解压缩失败的次数达到门限次数时,关闭针对该UE的ROHC功能。之后,便可以不再判断接收到的数据包是否为IP数据包,而直接向上传输接收到的数据包。
请继续参考图5,图5为本发明实施例一提供的另一种上行数据包处理方法流程图,即在以上步骤103之后,还可以包括以下步骤:
步骤104,当对UE发送的上行数据包解压缩失败的次数达到门限次数时,
关闭针对该UE的ROHC功能。
需要说明的是,对UE发送的上行数据包解压缩失败的判断可以在真正执行解压缩后根据解压缩结果而确定,也可以根据收到的数据包类型来确定,例如当收到的数据包为IP数据包时,则判断解压缩失败。
图4为本发明实施例二提供的上行数据包处理方法流程图,该方法由基站执行,该基站支持ROHC功能,且针对UE的ROHC功能处于开启状态,具体通过条件二触发传输未经ROHC解压缩的上行数据包的动作,该方法包括:
步骤401,接收该UE发送的上行数据包。
参照以上实施例,上行数据包可能为压缩包,也可能为IP数据包。
步骤402,对UE发送的上行数据包解压缩失败的次数达到门限次数时,关闭针对该UE的ROHC功能。
基站作为上行ROHC解压缩端,出现上行数据包解压缩失败,原因可能有:(1)压缩端在初始NC状态下,应发送IR包,使得解压缩端收到IR包后能建立解压缩上下文,但压缩端发送了非IR包;(2)当解压缩端和压缩端的上下文同步后,解压缩端能正确解压缩报文,可能由于网络不稳定原因引发空口丢包,继而两端的上下文失步,会导致上行数据包解压缩失败;(3)当解压缩端和压缩端的上下文同步后,解压缩端能正确解压缩报文,一段时间后,由于工作模式迁移或压缩状态迁移,需要发送某种特定压缩包类型时,压缩方没有发送这种格式的压缩包,解压缩端收到上行数据包就会解压缩失败;例如,发送IP数据包。
本发明实施例中,可以通过基站的无线资源控制(Radio Resource Control,RRC)层实体实现关闭针对该UE的ROHC功能。
需要说明的是,对UE发送的上行数据包解压缩失败的判断可以在真正执行解压缩后根据解压缩结果而确定,也可以根据收到的数据包类型来确定,例如当收到的数据包为IP数据包时,则判断解压缩失败。
步骤403,向核心网传输上行数据包,其中,传输上行数据包之前,不对
上行数据包进行ROHC解压缩处理。
本发明实施例二提供了一种上行数据包处理方法,该方法由基站执行,该基站支持ROHC功能,且针对UE的ROHC功能处于开启状态,对UE发送的上行数据包解压缩失败的次数达到门限次数时,不对上行数据包根据ROHC协议进行解压缩处理,而是直接将上行数据包向上传输,从而减少了ROHC功能所引起的通话中断等问题,相应地保障了语音质量,提高了基站上行ROHC特性的兼容性和灵活性。
此外,由于当上行数据包连续解压缩失败次数较多时,直接导致解压方和压缩方的上下文失步,以后的压缩包都不可能正确被解压缩,引起单通或双不通,影响用户的通话质量,因此优选地对UE发送的上行数据包解压缩失败的次数达到门限次数时,关闭针对该UE的ROHC功能,从而不仅可以解决上行数据包为IP数据包进行解压缩失败所引起的丢包等问题,还能解决前面提到的其他原因引起的上行数据包进行解压缩失败所引起的丢包等问题。
该条件二可以和以上条件一结合,即在以上步骤402之前,即对UE发送的上行数据包解压缩失败的次数达到门限次数之前,每次解压缩失败的数据包如果是IP数据包,则可以直接向核心网传输该IP数据包,请参考图6,该方法在步骤401之后,还包括:
步骤601,判断上行数据包是否为IP数据包,且
当上行数据包为IP数据包时,执行以上步骤403。且在对UE发送的上行数据包解压缩失败的次数达到门限次数时,便可以关闭ROHC功能,后续无线对数据包的类型做出判断,就可以直接向上传输。
图7为本发明实施例三提供的上行数据包处理装置结构图,所述装置设置于基站中,所述基站支持ROHC功能,且针对某个UE的所述ROHC功能处于开启状态,该装置用于执行本发明实施例提供的上行数据包处理方法,所述装置包括:
接收单元701,用于接收所述UE发送的上行数据包;
确定单元702,用于确定所述接收单元701接收的所述上行数据包是否为IP数据包,或者,用于确定对所述UE发送的上行数据包解压缩失败的次数是否达到门限次数;
传输单元703,用于当所述接收单元701接收的所述上行数据包为IP数据包,或者,对所述UE发送的上行数据包解压缩失败的次数达到门限次数时,向核心网传输所述上行数据包,其中,向核心网传输所述上行数据包之前,不对所述上行数据包进行ROHC解压缩处理。
如图8所示,当所述确定单元702用于确定所述接收单元701接收的所述上行数据包是否为IP数据包时,该确定单元702可以包括解析子单元7021和确定子单元7022。其中,解析子单元7021,用于对所述上行数据包的包头进行解析,获得所述上行数据包的包头首字节;确定子单元7022,用于当所述解析子单元7021获得的所述包头首字节标识出所述上行数据包为IPv4数据包或IPv6数据包时,确定所述上行数据包为IP数据包。
图9所示,当确定单元702用于确定对所述UE发送的上行数据包解压缩失败的次数是否达到门限次数时,该确定单元702可以包括统计子单元7023和确定子单元7024。其中,统计子单元7023用于统计对UE发送的上行数据包解压缩失败的次数;确定子单元7024用于当统计子单元7023统计出的次数达到门限次数时,确定对UE发送的上行数据包解压缩失败的次数达到门限次数。优选地,所述装置还包括:
关闭单元704,用于在对UE发送的上行数据包解压缩失败的次数达到门限次数时,关闭针对所述UE的所述ROHC功能。该关闭操作可以在传输上行数据包之前,也可以在传输上行数据包之后。
需要说明的是,本发明实施例中的接收单元701可以为基站的接收机,传输单元703可以为基站与核心网之间的接口。确定单元702可以为单独设立的处理器,也可以集成在基站的某一个处理器中实现,此外,也可以以程序代码的形式存储于基站的存储器中,由基站的某一个处理器调用并执行以
上确定单元702的功能。关闭单元704的实现同确定单元702,且可以与确定单元702集成在一起,也可以独立实现。这里所述的处理器可以是一个中央处理器(Central Processing Unit,CPU),或者是特定集成电路(Application Specific Integrated Circuit,ASIC),或者是被配置成实施本发明实施例的一个或多个集成电路。
图10为本发明实施例四提供的基站结构图,所述基站支持ROHC功能,且针对某个UE的所述ROHC功能处于开启状态,该基站用于执行本发明实施例提供的上行数据包处理方法,所述基站包括:存储器801、处理器802、第一接口电路803和第二接口电路804,该存储器801、处理器802、第一接口电路803和第二接口电路804之间通过系统总线805连接并完成相互间的通信。
第一接口电路803可以为空口电路,用于实现基站与UE之间的通信,其遵循空口协议;第二接口电路804可以为有线接口电路,用于实现基站与核心网之间的通信,其遵循接入网和核心网之间的S1通信协议,具体为数据面通信协议。存储器801用于存储程序指令;处理器802用于调用存储器801存储的程序指令,以执行以上任一实施例所提供的方法。
例如,处理器802调用存储器801存储的程序指令,执行以下操作:
通过第一接口电路803接收UE发送的上行数据包括;确定所述上行数据包是否为IP数据包,或者,确定对所述UE发送的上行数据包解压缩失败的次数是否达到门限次数;当所述上行数据包为IP数据包或者对所述上行数据包解压缩失败的次数达到门限次数时,向核心网传输所述上行数据包,其中,向核心网传输所述上行数据包之前,不对所述上行数据包进行ROHC解压缩处理。
可选地,当存储器801中存储的使处理802确定对UE发送的上行数据包解压缩失败的次数是否达到门限次数的程序指令时,处理器调用该指令以执行以下操作:
统计对所述UE发送的上行数据包解压缩失败的次数;
当统计出的次数达到门限次数时,确定对所述UE发送的上行数据包解压缩失败的次数达到门限次数。
可选地,当存储器801中存储使处理器802确定所述上行数据包是否为IP数据包的程序指令时,处理器802调用该指令以执行以下操作:
对所述上行数据包的包头进行解析,获得所述上行数据包的包头首字节;
当所述包头首字节标识出所述上行数据包为IPv4数据包或IPv6数据包时,确定所述上行数据包为IP数据包。
优选地,处理器802还用于根据存储器801中存储的程序指令执行以下操作:
在对所述UE发送的上行数据包解压缩失败的次数达到门限次数时,关闭针对所述UE的所述ROHC功能。
需要说明的是,这里的处理器802可以是一个处理器,也可以是多个处理元件的统称。例如,该处理器可以是CPU,也可以是ASIC,或者是被配置成实施本发明实施例的一个或多个集成电路,例如:一个或多个微处理器(digital singnal processor,DSP),或,一个或者多个现场可编程门阵列(Field Programmable Gate Array,FPGA)。
存储器801可以是一个存储装置,也可以是多个存储元件的统称,且用于存储可执行程序代码或接入网管理设备运行所需要参数、数据等。且存储器801可以包括随机存储器(RAM),也可以包括非易失性存储器(non-volatile memory),例如磁盘存储器,闪存(Flash)等。
系统总线805可以是工业标准体系结构(Industry Standard Architecture,ISA)总线、外部设备互连(Peripheral Component,PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture,EISA)总线等。该系统总线805可以分为地址总线、数据总线、控制总线等。为便于表示,图10中仅用一条空心线表示,但并不表示仅有一根总线或一种
类型的总线。
专业人员应该还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令处理器完成,所述的程序可以存储于计算机可读存储介质中,所述存储介质是非短暂性(英文:non-transitory)介质,例如随机存取存储器,只读存储器,快闪存储器,硬盘,固态硬盘,磁带(英文:magnetic tape),软盘(英文:floppy disk),光盘(英文:optical disc)及其任意组合。
以上所述,仅为本发明较佳的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求的保护范围为准。
Claims (13)
- 一种上行数据包处理方法,其特征在于,所述方法由基站执行,所述基站支持稳健包头压缩ROHC功能,且针对用户设备UE的所述ROHC功能处于开启状态,所述方法包括:接收所述UE发送的上行数据包;当所述上行数据包为互联网协议IP数据包,或者,对所述UE发送的上行数据包解压缩失败的次数达到门限次数时,向核心网传输所述上行数据包,其中,向核心网传输所述上行数据包之前,不对所述上行数据包进行ROHC解压缩处理。
- 如权利要求1所述的方法,其特征在于,向核心网传输所述上行数据包之前,所述方法还包括:确定所述上行数据包是否为IP数据包;当所述上行数据包为IP数据包时,执行所述向核心网传输所述上行数据包的步骤。
- 如权利要求2所述的方法,其特征在于,所述确定所述上行数据包是否为IP数据包,包括:对所述上行数据包的包头进行解析,获得所述上行数据包的包头首字节;当所述包头首字节标识出所述上行数据包为互联网协议版本4IPv4数据包或互联网协议版本6IPv6数据包时,确定所述上行数据包为IP数据包。
- 如权利要求1所述的方法,其特征在于,向核心网传输所述上行数据包之前,所述方法还包括:统计对所述UE发送的上行数据包解压缩失败的次数;当所述统计的次数达到所述门限次数时,执行所述向核心网传输所述上行数据包的步骤。
- 如权利要求1至4任一项所述的方法,其特征在于,当对所述UE发送的上行数据包解压缩失败的次数达到门限次数时,所述方法还包括:关闭针对所述UE的所述ROHC功能。
- 一种上行数据包处理装置,其特征在于,所述装置设置于基站中,所述基站支持稳健包头压缩ROHC功能,且针对用户设备UE的所述ROHC功能处于开启状态,所述装置包括:接收单元,用于接收所述UE发送的上行数据包;确定单元,用于确定所述接收单元接收的所述上行数据包是否为互联网协议IP数据包,或者,用于确定对所述UE发送的上行数据包解压缩失败的次数是否达到门限次数;传输单元,用于当所述接收单元接收的所述上行数据包为IP数据包,或者,对所述UE发送的上行数据包解压缩失败的次数达到门限次数时,向核心网传输所述上行数据包,其中,向核心网传输所述上行数据包之前,不对所述上行数据包进行ROHC解压缩处理。
- 如权利要求6所述的装置,其特征在于,所述确定单元包括:统计子单元,用于统计对所述UE发送的上行数据包解压缩失败的次数;确定子单元,用于当所述统计子单元统计出的次数达到门限次数时,确定对所述UE发送的上行数据包解压缩失败的次数达到门限次数。
- 如权利要求6所述的装置,其特征在于,所述确定单元包括:解析子单元,用于对所述上行数据包的包头进行解析,获得所述上行数据包的包头首字节;确定子单元,用于当所述解析子单元获得的所述包头首字节标识出所述上行数据包为互联网协议版本4IPv4数据包或互联网协议版本6IPv6数据包时,确定所述上行数据包为IP数据包。
- 如权利要求6至8任一项所述的装置,其特征在于,所述装置还包括:关闭单元,用于在对所述UE发送的上行数据包解压缩失败的次数达到门限次数时,关闭针对所述UE的所述ROHC功能。
- 一种基站,其特征在于,所述基站支持稳健包头压缩ROHC功能,且 针对用户设备UE的所述ROHC功能处于开启状态,所述基站包括:存储器、处理器、第一接口电路和第二接口电路;其中,所述第一接口电路用于所述基站与所述UE通信;所述第二接口电路用于所述基站与核心网通信;所述存储器,用于存储程序指令;所述处理器用于调用所述存储器存储的程序指令以执行:通过所述第一接口电路接收所述UE发送的上行数据包;确定所述上行数据包是否为互联网协议IP数据包,或者,确定对所述UE发送的上行数据包解压缩失败的次数是否达到门限次数;当所述上行数据包为IP数据包,或者,对所述UE发送的上行数据包解压缩失败的次数达到门限次数时,向核心网传输所述上行数据包,其中,向核心网传输所述上行数据包之前,不对所述上行数据包进行ROHC解压缩处理。
- 如权利要求10所述的基站,其特征在于:所述存储器中存储使所述处理器确定对所述UE发送的上行数据包解压缩失败的次数是否达到门限次数的程序指令,以供所述处理器调用以执行:统计对所述UE发送的上行数据包解压缩失败的次数;当统计出的次数达到门限次数时,确定对所述UE发送的上行数据包解压缩失败的次数达到门限次数。
- 如权利要求10所述的基站,其特征在于,所述存储器中存储使所述处理器确定所述上行数据包是否为IP数据包的程序指令,以供所述处理器调用以执行:对所述上行数据包的包头进行解析,获得所述上行数据包的包头首字节;当所述包头首字节标识出所述上行数据包为互联网协议版本4IPv4数据包或互联网协议版本6IPv6数据包时,确定所述上行数据包为IP数据包。
- 如权利要求10至12任一项所述的基站,其特征在于,所述处理器还用于调用所述存储器中存储的程序指令以执行:在对所述UE发送的上行数据包解压缩失败的次数达到门限次数时,关闭 针对所述UE的所述ROHC功能。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2015/079364 WO2016183820A1 (zh) | 2015-05-20 | 2015-05-20 | 上行数据包处理方法、装置和基站 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN106416356A true CN106416356A (zh) | 2017-02-15 |
Family
ID=57319151
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201580032765.6A Pending CN106416356A (zh) | 2015-05-20 | 2015-05-20 | 上行数据包处理方法、装置和基站 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN106416356A (zh) |
WO (1) | WO2016183820A1 (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112333773A (zh) * | 2020-11-24 | 2021-02-05 | 展讯半导体(成都)有限公司 | 通信处理方法、设备、装置及存储介质 |
CN113709812A (zh) * | 2019-03-29 | 2021-11-26 | Oppo广东移动通信有限公司 | 一种压缩处理方法、解压缩处理方法及相关设备 |
CN114339640A (zh) * | 2022-01-11 | 2022-04-12 | 赛特斯信息科技股份有限公司 | 基于rohc的5g语音传输方法 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040202167A1 (en) * | 1999-06-18 | 2004-10-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Robust header compression in packet communications |
CN1996941A (zh) * | 2006-06-30 | 2007-07-11 | 华为技术有限公司 | 一种鲁棒性头部压缩u模式出错时的处理方法 |
CN101159677A (zh) * | 2007-10-25 | 2008-04-09 | 华为技术有限公司 | 一种报文传输方法及网络节点装置 |
CN101212404A (zh) * | 2006-12-27 | 2008-07-02 | 大唐移动通信设备有限公司 | 鲁棒头压缩分组数据传输的方法及系统 |
CN101843054A (zh) * | 2007-10-31 | 2010-09-22 | 富士通株式会社 | 通信方法及通信终端、数据传送装置及控制装置 |
WO2014110773A1 (zh) * | 2013-01-17 | 2014-07-24 | 华为技术有限公司 | 一种数据包处理方法和装置 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101421972B (zh) * | 2006-04-12 | 2011-06-08 | 艾利森电话股份有限公司 | 远程通信网络中的数据包压缩及加密方法、节点与装置 |
CN101605355B (zh) * | 2009-06-12 | 2011-08-24 | 中国科学技术大学 | 一种用于LTE-advanced网络中继节点上的ROHC混合工作方式 |
CN102045132B (zh) * | 2009-10-23 | 2014-04-30 | 华为技术有限公司 | 基于重传机制的对头压缩数据包进行传输的方法和装置 |
EP2785091A1 (en) * | 2013-03-26 | 2014-10-01 | Alcatel Lucent | Method, apparatus and computer program product for determining validity of Hyper Frame Numbers used for decoding PDCP units |
-
2015
- 2015-05-20 WO PCT/CN2015/079364 patent/WO2016183820A1/zh active Application Filing
- 2015-05-20 CN CN201580032765.6A patent/CN106416356A/zh active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040202167A1 (en) * | 1999-06-18 | 2004-10-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Robust header compression in packet communications |
CN1996941A (zh) * | 2006-06-30 | 2007-07-11 | 华为技术有限公司 | 一种鲁棒性头部压缩u模式出错时的处理方法 |
CN101212404A (zh) * | 2006-12-27 | 2008-07-02 | 大唐移动通信设备有限公司 | 鲁棒头压缩分组数据传输的方法及系统 |
CN101159677A (zh) * | 2007-10-25 | 2008-04-09 | 华为技术有限公司 | 一种报文传输方法及网络节点装置 |
CN101843054A (zh) * | 2007-10-31 | 2010-09-22 | 富士通株式会社 | 通信方法及通信终端、数据传送装置及控制装置 |
WO2014110773A1 (zh) * | 2013-01-17 | 2014-07-24 | 华为技术有限公司 | 一种数据包处理方法和装置 |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113709812A (zh) * | 2019-03-29 | 2021-11-26 | Oppo广东移动通信有限公司 | 一种压缩处理方法、解压缩处理方法及相关设备 |
US11671870B2 (en) | 2019-03-29 | 2023-06-06 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | Compression processing method, decompression processing method and related devices |
CN112333773A (zh) * | 2020-11-24 | 2021-02-05 | 展讯半导体(成都)有限公司 | 通信处理方法、设备、装置及存储介质 |
CN112333773B (zh) * | 2020-11-24 | 2023-11-03 | 展讯半导体(成都)有限公司 | 通信处理方法、设备、装置及存储介质 |
CN114339640A (zh) * | 2022-01-11 | 2022-04-12 | 赛特斯信息科技股份有限公司 | 基于rohc的5g语音传输方法 |
CN114339640B (zh) * | 2022-01-11 | 2023-04-07 | 赛特斯信息科技股份有限公司 | 基于rohc的5g语音传输方法 |
Also Published As
Publication number | Publication date |
---|---|
WO2016183820A1 (zh) | 2016-11-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR100610658B1 (ko) | 데이터 패킷 접속을 위한 헤더 필드 압축 정의 방법, 압축 시스템, 이를 구비하는 네트워크 요소 및 이동국 | |
KR100605110B1 (ko) | 헤더 필드 압축시 콘텍스트 식별자 정의 | |
KR20040016064A (ko) | 비대칭 양방향 패킷데이터 송수신 방법 및 시스템 | |
JP2008005510A (ja) | 無線通信システムにおいてハンドオーバー後の状態報告を処理する方法及び装置 | |
US11477306B2 (en) | Wireless communication methods and devices | |
JP5017559B2 (ja) | 無線通信システムにおいてタイマーのデフォルト値を設定する方法及び装置 | |
JP2009512231A (ja) | セルラー通信ネットワークにおけるハンドオーバ中およびハンドオーバ後のヘッダ圧縮最適化方法 | |
US20200128112A1 (en) | Packet transmission method, proxy server, and computer-readable storage medium | |
TWI717619B (zh) | 用於避免封包分割之方法及其裝置 | |
WO2020001355A1 (zh) | 避免报文分片的方法和装置 | |
KR20210113332A (ko) | 이더넷 프레임의 전송 방법 및 통신 장치 | |
WO2019057016A1 (zh) | 一种数据处理方法及终端 | |
WO2016172958A1 (zh) | 一种流量动态控制方法、设备及网关、融合接入汇聚点 | |
CN106416356A (zh) | 上行数据包处理方法、装置和基站 | |
US10298509B2 (en) | Managing a sequence number range for radio link control entities in a radio access network during an on-going connection | |
EP3185505B1 (en) | Data packet transmission processing method and device | |
WO2020199030A1 (zh) | 一种压缩处理方法、解压缩处理方法及相关设备 | |
US8971310B2 (en) | Apparatus and method for end-to-end adaptive frame packing and redundancy in a heterogeneous network environment | |
WO2023102938A1 (zh) | 无线通信方法和通信设备 | |
WO2019047912A1 (zh) | 处理数据的方法和设备 | |
WO2017143538A1 (zh) | 语音数据传输方法以及装置 | |
WO2021097686A1 (zh) | 用于传输以太网压缩包的方法和设备 | |
WO2020078184A1 (zh) | 用户面数据完整性保护方法、装置、电子设备及介质 | |
WO2020063122A1 (zh) | 一种数据传输方法及装置 | |
CN109219079B (zh) | 一种ir报文传输方法及通信设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
WD01 | Invention patent application deemed withdrawn after publication | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20170215 |