一种数据包传输方法及设备与流程

本申请涉及通信技术领域，尤其涉及一种数据包传输方法及设备。

背景技术：

长期演进(longtermevolution，lte)承载话音(voiceoverlte，volte)是一种ip数据传输技术，全部业务承载于4g网络上，可实现数据与语音业务在同一网络下的统一，即4g网络不仅仅提供高速率的数据业务，同时还提供高质量的音视频通话。但是，对于长期演进(longtermevolution，lte)无线承载语音业务，空口传输容易产生丢包。同时volte是基于ip多媒体子系统(ipmultimediasubsystem，ims)语音业务，演进型基站(enodeb)和移动性管理实体(mobilitymanagemententity，mme)、服务网关(servinggateway，sgw)、分组数据网(packetdatanetwork，pdn)网关(pdngateway，pgw)、ims等网元通过ip传输网络连接。由于ip传输网络中传输设备节点众多，传输网络上各设备都有可能产生丢包。所以，空口和各设备节点产生的丢包，将影响volte业务端到端的业务感知。

volte网络架构如图1所示，一个ue发送的语音数据包经过enodeb、sgw/pgw、ims等网元传输到达另一个ue。

基于volte的协议栈结构，ue发送的语音数据包在应用层使用实时传送协议(real-timetransportprotocol，rtp)协议承载，rtp承载在用户数据报协议(userdatagramprotocol，udp)/ip层上。ue将语音包在空口上通过qos级别标识符(qosclassidentifier，qci)1业务承载上行发送至enodeb。现有的enodeb仅实现对业务的透传，将ue发送的rtp/udp/ip语音数据包承载在通用分组无线业务(generalpacketradioservice，gprs)隧道协议(gprstunnelprotocol，gtp)/udp/ip上，发送至sgw/pgw。sgw/pgw将接收到的rtp/udp/ip语音数据包转发至ims，ims处理后再发送到对端ue所在的sgw/pgw。对端sgw/pgw再将rtp/udp/ip语音数据包承载在gtp/udp/ip上，发送至对端ue所在的enodeb。enodeb按照目前的实现，将业务数据通过空口qci1业务承载下行透传至对端ue。以上即为一个volte语音业务的端到端传输过程。

根据语音及时性强的特点，在ue到enodeb的上行qci1空口传输时，采用的是非确认传输模式(unacknowledgedmode，um)，不可避免在空口信道差时容易产生丢包。同时，对于语音业务数据包在enodeb至sgw/pgw、ims间传输时，各设备节点和传输网络也有可能产生部分丢包。而enodeb现有的实现方案，enodeb只对语音业务数据进行透传，不会额外针对语音业务数据的特点进行主动补齐，从而对于以上产生的语音丢包不能进行修复。因此，当发生语音业务丢包时，对于volte语音业务感知，其平均意见值(meanopinionscore，mos)评分将降低。

技术实现要素：

本申请实施例提供了一种数据包传输方法及设备，用以通过检测数据传输过程中的丢包，从而修复丢失的数据包。

本申请实施例提供的一种数据包传输方法，包括：

对于用户设备和核心网之间传输的数据包进行丢包检测；

当确定发生丢包时，利用缓存的数据包修复丢失的数据包并发送，其中，所述缓存的数据包，是当没有发生丢包时缓存的数据包。

通过该方法，对于用户设备和核心网之间传输的数据包进行丢包检测；当确定发生丢包时，利用缓存的数据包修复丢失的数据包并发送，其中，所述缓存的数据包，是当没有发生丢包时缓存的数据包。从而实现了通过检测数据传输过程中的丢包，修复丢失的数据包，提升了用户的业务感知。

较佳地，所述缓存的数据包，是当没有发生丢包时缓存的最新接收到的数据包。

较佳地，所述数据包为语音实时传送协议rtp数据包。

较佳地，所述利用缓存的数据包修复丢失的数据包，具体包括：

利用缓存的数据包中的信息，通过修改缓存的数据包中的rtp序号、时间戳、校验和信息，修复丢失的数据包。

较佳地，所述进行丢包检测，具体包括：

判断所述用户设备当前处于业务激活期还是业务静默期；

若所述用户设备当前处于业务激活期，则利用接收到的当前数据包的序号进行丢包检测；

若所述用户设备当前处于业务静默期，则利用静默期传输数据包的周期进行丢包检测。

较佳地，利用静默期传输数据包的周期内接收到的数据包数，判断所述用户设备当前处于业务激活期还是业务静默期。

较佳地，若所述用户设备当前处于业务激活期，则将修复的数据包发送的同时还将当前接收到的数据包进行发送。

较佳地，该方法还包括：

若所述用户设备当前处于业务激活期，则将当前接收到的数据包替换缓存的数据包；

若所述用户设备当前处于业务静默期，则将修复的数据包替换缓存的数据包。

本申请实施例提供的一种数据包传输设备，包括：

第一单元，用于对于用户设备和核心网之间传输的数据包进行丢包检测；

第二单元，用于当确定发生丢包时，利用缓存的数据包修复丢失的数据包并发送，其中，所述缓存的数据包，是当没有发生丢包时缓存的数据包。

较佳地，所述缓存的数据包，是当没有发生丢包时缓存的最新接收到的数据包。

较佳地，所述数据包为语音实时传送协议rtp数据包。

较佳地，所述第二单元利用缓存的数据包修复丢失的数据包，具体包括：

利用缓存的数据包中的信息，通过修改缓存的数据包中的rtp序号、时间戳、校验和信息，修复丢失的数据包。

较佳地，所述第一单元具体用于：

判断所述用户设备当前处于业务激活期还是业务静默期；

若所述用户设备当前处于业务激活期，则利用接收到的当前数据包的序号进行丢包检测；

若所述用户设备当前处于业务静默期，则利用静默期传输数据包的周期进行丢包检测。

较佳地，所述第一单元利用静默期传输数据包的周期内接收到的数据包数，判断所述用户设备当前处于业务激活期还是业务静默期。

较佳地，若所述用户设备当前处于业务激活期，则所述第二单元将修复的数据包发送的同时还将当前接收到的数据包进行发送。

较佳地，所述第二单元还用于：

若所述用户设备当前处于业务激活期，则将当前接收到的数据包替换缓存的数据包；

若所述用户设备当前处于业务静默期，则将修复的数据包替换缓存的数据包。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为现有技术中的volte的网络架构示意图；

图2为本申请实施例提供的一种数据包传输方法的流程示意图；

图3为本申请实施例提供的一种enodeb上行数据包传输流程示意图；

图4为本申请实施例提供的一种enodeb下行数据包传输流程示意图；

图5为本申请实施例提供的一种语音业务静默期和激活期的数据包传输周期示意图；

图6为本申请实施例提供的一种数据包传输设备的结构示意图。

具体实施方式

本申请实施例提供了一种数据包传输方法及设备，用以通过检测数据传输过程中的丢包，从而修复丢失的数据包。

本申请实施例提供的技术方案，能够在基站上实现自动实时检测经基站传输的数据包(例如语音业务数据包)的丢包，根据业务周期性的特点，主动补齐数据包，保证数据包的连续。

参见图2，在基站侧，本申请实施例提供的一种数据包传输方法，包括：

s101、对于用户设备和核心网之间传输的数据包进行丢包检测；

其中，用户设备和核心网之间传输的数据包，可以是上行的数据包，也可以是下行的数据包。

s102、当确定发生丢包时，利用缓存的数据包修复丢失的数据包并发送，其中，所述缓存的数据包，是当没有发生丢包时缓存的数据包。

通过该方法，对于用户设备和核心网之间传输的数据包进行丢包检测；当确定发生丢包时，利用缓存的数据包修复丢失的数据包并发送，其中，所述缓存的数据包，是当没有发生丢包时缓存的数据包。从而实现了通过检测数据传输过程中的丢包，修复丢失的数据包，使得用户设备和核心网之间传输的数据包连续，提升了用户的业务感知。

较佳地，所述缓存的数据包，是当没有发生丢包时缓存的最新接收到的数据包。

较佳地，所述数据包为语音rtp数据包。

当然，也可以是其他业务类型的数据包。

较佳地，所述利用缓存的数据包修复丢失的数据包，具体包括：

利用缓存的数据包中的实时传送协议(real-timetransportprotocol，rtp)序号、时间戳、校验和信息，修复丢失的数据包。

例如，缓存的数据包是丢失的数据包的上一个数据包，即最新接收到的数据包，则可以将缓存的数据包的rtp序号加一；若当前处于语音静默期，则对于高清语音业务，将缓存的数据包的时间戳加2560，对于标清的语音业务，将缓存的数据包的时间戳加1280，若当前处于语音激活期，则对于高清语音业务，将缓存的数据包的时间戳加320，对于标清的语音业务，将缓存的数据包的时间戳加160；根据修改完的rtp序号和时间戳，重新计算udp层的校验和。从而完成对丢失的数据包的修复，得到补齐包。

较佳地，所述进行丢包检测，具体包括：

判断所述用户设备当前处于业务激活期还是业务静默期；

若所述用户设备当前处于业务激活期，则利用接收到的当前数据包的序号进行丢包检测；

例如，若序号连续，则说明没有丢包，否则，认为发生丢包。

若所述用户设备当前处于业务静默期，则利用静默期传输数据包的周期进行丢包检测。

例如，在静默期传输数据包的周期内，收到数据包，则说明没有丢包，否则，认为发生丢包。

较佳地，利用静默期传输数据包的周期内接收到的数据包数，判断所述用户设备当前处于业务激活期还是业务静默期。

例如，业务静默期的数据包传输周期大于业务激活期的数据包的传输周期，则在业务静默期的数据包传输周期内若收到多个数据包，则说明当前处于业务激活期，若仅收到一个数据包，则说明当前处于业务静默期。

较佳地，若所述用户设备当前处于业务激活期，则将修复的数据包发送的同时还将当前接收到的数据包进行发送。

较佳地，该方法还包括：

若所述用户设备当前处于业务激活期，则将当前接收到的数据包替换缓存的数据包；

若所述用户设备当前处于业务静默期，则将修复的数据包替换缓存的数据包。

本申请实施例提出在基站运行过程中，基站实时检测ue上行发送的语音rtp数据包和核心网下行发送的语音rtp数据包，是否丢包，例如可以检测数据包的实时传送协议(real-timetransportprotocol，rtp)序号，并缓存最新接收到的语音rtp数据包，当发现产生丢包时，修改缓存的语音rtp数据包中的rtp序号、时间戳、校验和信息后，实现修复一个丢失的语音rtp数据包，并发送给核心网或ue，其中，上行方向，是发给核心网，下行方向，是发给ue。

参见图3、图4，上行方向和下行方向同理，本申请实施例提供的语音rtp数据包的传输过程包括：

基站小区建立后，当每个ue建立qci1的语音业务承载后，为该ue上行和下行方向各分配一个语音缓存包存储空间。随后按照以下步骤在上行和下行方向分别进行语音数据包传输和丢包修复：

步骤一、基站进行语音激活期和静默期判断。参见图5，根据语音业务具有周期性的特点，在语音激活期以20ms为周期传输语音数据包，在语音静默期以160ms为周期传输sid包。所以可根据160ms内接收到的语音包数进行激活期/静默期判断，超出2个包则为语音激活期，否则为静默期。

步骤二、语音rtp丢包检测。

当前处于语音激活期时，当enodeb接收到一个新的rtp语音包时，根据rtp协议进行各字段解析。rtp协议报文中存在序列号(sequencenumber)字段。当不发生丢包时，每个rtp语音包的序列号都比前一个rtp语音包增加1。因此，当enodeb接收到一个新的rtp语音包时，判断当前rtp语音包的序列号是否等于前一个rtp语音包的序列号加1，如果相等，则说明没有丢包。如果当前rtp语音包的序列号大于前一个rtp语音包的序列号加1，则说明产生了丢包，需要进行丢包修复。

当前处于语音静默期时，如果没有丢包，两个语音静默包的时间间隔为160ms。因此，基站针对该用户启动160ms的定时器，如果定时器超时还未收到语音包，则认为产生了丢包，需要进行丢包修复。当定时器超时，或者收到了语音静默包后，基站需要重启该定时器，进行下一个语音静默包的监测。

步骤三、语音丢包修复。当发生丢包时，将缓存的前一个rtp语音包复制，并根据rtp协议进行各字段解析。rtp协议报文中存在序列号(sequencenumber)和时间戳(timestamp)字段，udp层协议报文中存在校验和(checksum)字段，这些字段在每个rtp语音包中都会改变。所以，将rtp语音包复制时，这三个字段需要进行修正：

序列号：按照缓存包中的序列号加1；

时间戳：对于高清语音业务，当前处于语音静默期时，按照缓存包中的时间戳加2560；当前处于语音激活期时，按照缓存包中的时间戳加320；对于标清语音业务，当前处于语音静默期时，按照缓存包中的时间戳加1280；当前处于语音激活期时，按照缓存包中的时间戳加160；

校验和：根据修改后的序列号和时间戳，重新计算udp层的校验和；具体地，例如：将整个数据包按照16位进行累加计算：

步骤一、按每16位求和得出一个32位的数；

步骤二、如果这个32位的数，高16位不为0，则高16位加低16位再得到一个32位的数；

重复步骤二直到高16位为0，将低16位取反，得到检验和。

步骤四、语音包缓存和发送。

当没有发生丢包时，enodeb将当前接收到的包替换缓存包，并将当前包发送至下一个网元(上行发送至核心网，下行发送至ue)。

当发生丢包时：

当前处于语音静默期时，enodeb将修复后的补齐包替换缓存包，并将修复后的补齐包发送至下一个网元(上行发送至核心网，下行发送至ue)。

当前处于语音激活期时，enodeb将当前包替换缓存包，并将修复后的补齐包和当前包发送至下一个网元(上行发送至核心网，下行发送至ue)。

参见图6，与上述方法相对应地，本申请实施例提供的一种数据包传输设备，包括：

第一单元11，用于对于用户设备和核心网之间传输的数据包进行丢包检测；

第二单元12，用于当确定发生丢包时，利用缓存的数据包修复丢失的数据包并发送，其中，所述缓存的数据包，是当没有发生丢包时缓存的数据包。

较佳地，所述缓存的数据包，是当没有发生丢包时缓存的最新接收到的数据包。

较佳地，所述数据包为语音实时传送协议rtp数据包。

较佳地，所述第二单元利用缓存的数据包修复丢失的数据包，具体包括：

利用缓存的数据包中的信息，通过修改缓存的数据包中的rtp序号、时间戳、校验和信息，修复丢失的数据包。

较佳地，所述第一单元具体用于：

判断所述用户设备当前处于业务激活期还是业务静默期；

若所述用户设备当前处于业务激活期，则利用接收到的当前数据包的序号进行丢包检测；

若所述用户设备当前处于业务静默期，则利用静默期传输数据包的周期进行丢包检测。

较佳地，所述第一单元利用静默期传输数据包的周期内接收到的数据包数，判断所述用户设备当前处于业务激活期还是业务静默期。

较佳地，若所述用户设备当前处于业务激活期，则所述第二单元将修复的数据包发送的同时还将当前接收到的数据包进行发送。

较佳地，所述第二单元还用于：

若所述用户设备当前处于业务激活期，则将当前接收到的数据包替换缓存的数据包；

若所述用户设备当前处于业务静默期，则将修复的数据包替换缓存的数据包。

综上所述，本申请实施例中，enodeb对数据包解析rtp协议，从而进行rtp丢包的检测，检测到发生rtp丢包后，根据之前缓存的rtp包，修复一个传输过程中丢失的rtp语音包并传输，因此，本申请能够自动检测语音rtp包传输过程中的丢包，并自动复制修复一个传输过程中丢失的rtp语音包从而减少volte语音业务传输过程中的rtp丢包率，使得数据包连续，提升volte语音的业务感知。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。