CN107566330A - 适于维持接收数据质量的装置和用于接收数据的方法 - Google Patents

适于维持接收数据质量的装置和用于接收数据的方法 Download PDF

Info

Publication number
CN107566330A
CN107566330A CN201710447362.9A CN201710447362A CN107566330A CN 107566330 A CN107566330 A CN 107566330A CN 201710447362 A CN201710447362 A CN 201710447362A CN 107566330 A CN107566330 A CN 107566330A
Authority
CN
China
Prior art keywords
packet
header
media
sequence number
compression
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.)
Granted
Application number
CN201710447362.9A
Other languages
English (en)
Other versions
CN107566330B (zh
Inventor
J·帕龙
M·库格勒
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Apple Inc
Original Assignee
Intel IP Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Intel IP Corp filed Critical Intel IP Corp
Publication of CN107566330A publication Critical patent/CN107566330A/zh
Application granted granted Critical
Publication of CN107566330B publication Critical patent/CN107566330B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/4425—Monitoring of client processing errors or hardware failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
    • H04N21/6473—Monitoring network processes errors
    • 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/04—Error control

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请提出适于维持接收数据质量的装置和用于接收数据的方法。描述了一种通信设备，包括媒体输出单元；接收器，该接收器经配置用于接收分组序列的分组，分组包括压缩的报头和媒体有效载荷；以及处理器，该处理器经配置用于检测是否阻止压缩的报头的解压缩，并且，如果阻止了压缩的报头的解压缩，则经配置用于确定媒体有效载荷的序列号，从分组提取媒体有效载荷，并且将媒体有效载荷和序列号的指示转发到媒体输出单元。

Description

适于维持接收数据质量的装置和用于接收数据的方法
技术领域
本文中描述的实施例大体上涉及适于维持接收数据质量的装置和用于接收数据的方法。
背景技术
媒体数据通常根据使用的通信协议，通过将数据封装在包括报头的分组中，经由通信网络进行传输。为了使得数据传输更有效，可以对报头进行压缩。然而，例如，在已经丢失分组序列中的分组之前的一个或多个分组且因而对报头进行解压缩所必需的信息在接收器侧上不可用的情况下，可能出现分组的压缩的报头不能被解压缩的情况。这可能导致接收器侧上的媒体流中断(例如，音频间隙)。期望允许避免这样的音频间隙或保持这样的音频间隙尽可能小的方法。
发明内容
本申请提出适于维持接收数据质量的装置和用于接收数据的方法。
根据本申请，提出一种适于维持用于移动通信设备中的接收数据质量的装置，所述装置包括：媒体输出单元；接收器，所述接收器经配置用于接收分组序列的分组，所述分组包括压缩的报头和媒体有效载荷；以及处理器，所述处理器经配置用于确定是否出现所述压缩的报头的解压缩；以及基于没有所述压缩的报头的解压缩，确定所述媒体有效载荷的序列号，从所述分组提取所述媒体有效载荷，并且将所述媒体有效载荷和所确定的序列号转发到所述媒体输出单元。
此外，根据本申请，提出一种用于接收用于移动通信设备中的数据的方法，所述方法包括：接收分组序列的分组，所述分组包括压缩的报头和媒体有效载荷；确定是否出现所述压缩的报头的解压缩；以及基于没有所述压缩的报头的解压缩，确定所述媒体有效载荷的序列号；从所述分组提取所述媒体有效载荷；以及将所述媒体有效载荷和所确定的序列号转发到媒体输出单元。
此外，根据本申请，提出一种具有在其上记录的指令的计算机可读媒体，当由处理器执行所述指令时，所述指令使得所述处理器实行用于接收数据的方法。
附图说明
在附图中，相同的附图标记大体上是指不同视图中的相同部分。附图不一定是按比例绘制的，而是大体上重点放在例示本发明的原理上。在以下描述中，参考以下附图描述了各个方面，在附图中：
图1示出用于根据LTE(长期演进)的通信系统的示例。
图2示出用于在两个移动终端之间的VoLTE(LTE语音)连接的示例的VoLTE使用情况中涉及的协议层。
图3例示被添加用于在蜂窝网络(诸如图1的通信系统)上递送IP语音数据(即，用于数据封装)的协议报头。
图4示出具有导致报头解压缩失败的分组丢失的情形的示例。
图5示出用于第一方法处置报头解压缩失败的软件架构的示例。
图6示出用于第二方法处置报头解压缩失败的软件架构的示例。
图7示出在RoHC解压缩失败之后音频数据恢复的示例，这允许与图4的示例相比实现更短的音频中断时间。
图8示出关于报头重构的IPv4报头的图形表示。
图9示出关于报头重构的IPv6报头的图形表示。
图10示出关于报头重构的UDP报头的图形表示。
图11示出关于报头重构的RTP报头的图形表示。
图12示出根据实施例适于维持接收数据质量的装置。
图13示出流程图，其例示例如由通信设备进行的用于接收数据的方法。
具体实施方式
以下详细描述是指以说明的方式示出可以实践本发明的本公开的具体细节和方面的附图。可以利用其它方面，并且可以在不脱离本发明的范围的情况下，作出结构、逻辑和电改变。本公开的各个方面不一定互相排斥，因为本公开的一些方面可以与本公开的一个或多个其它方面组合以形成新的方面。
图1示出通信系统100，例如，LTE(长期演进)通信系统。
通信系统100包括无线电接入网络(例如，根据LTE的E-UTRAN(演进的UMTS(通用移动通信系统)陆地无线电接入网络))101和核心网络(例如，根据LTE的EPC(演进的分组核心网))102。无线电接入网络101可以包括基站(收发器)(例如，根据LTE的eNodeB、eNB)103。每个基站103提供用于无线电接入网络101的一个或多个移动无线电小区104的无线电覆盖。
位于移动无线电小区104(在该示例中，最左边的无线电小区104)中的一个中的移动终端(也称为UE(用户设备)或MS(移动电台))105可以与核心网络102通信，并且经由在移动无线电小区中提供覆盖(换句话说，操作)的基站与其它移动终端105通信。
在多个接入方法的基础上，控制和用户数据在基站103和位于由基站103操作的移动无线电小区104中的移动终端105之间通过空中接口106传输。
基站103借助于第一接口107(例如，X2接口)彼此互连。基站103也借助于第二接口108(例如，S1接口)连接到核心网络，例如，连接到MME(移动管理实体)109和服务网关(S-GW)110。例如，MME 109对控制位于E-UTRAN的覆盖区域中的移动终端的移动性负责，而S-GW110对处置移动终端105和核心网络102之间的用户数据的传输负责。
无线电接入网络101和核心网络可以根据各种通信技术例如移动通信标准支持通信。例如，根据LTE、UMTS、GSM(全球移动通信系统)、GPRS(通用分组无线业务)、EDGE(GSM演进增强型数据速率)无线电接入，每个基站103可经由自身和移动终端105之间的空中接口提供无线电通信连接。于是，无线电接入网络102可以操作作为E-UTRAN、UTRAN、GSM无线电接入网络或GERAN(GSM EDGE无线电接入网络)。类似地，核心网络102可以包括EPC、UMTS核心网络或GSM核心网络的功能。本文中所描述的方法也可以被应用于未来的RAT技术诸如5G。
对于经由空中接口106的上行链路无线电通信，移动终端105包括无线电发射机(TX RF)111。
移动终端105可包括身份模块112(例如，通过芯片卡实施的)，身份模块112允许移动终端105识别其自身为由无线电接入网络101和核心网络102形成的通信网络的订户(例如，为LTE订户)，并且因此允许移动终端105使用通信网络作为家庭网络。
根据LTE，移动终端105可以经由LTE语音(VoLTE)与另一个通信设备(例如，与另一个移动终端)通信。
图2示出用于经由LTE网络(例如，对应于无线电接入网络101的)两个移动终端(UE1和UE2)(例如，对应于移动终端105的)之间的VoLTE连接的示例的VoLTE使用情况中涉及的协议层。
在UE1中，由无线电记录应用程序201记录音频数据，并且由音频编码器202对音频数据进行编码。然后，由RTP(实时传送协议)层203、UDP(用户数据报协议)层204和IP协议层205处理编码的音频数据，以将编码的数据封装到IP/UDP/RTP分组中。分组被转发到包括PDCP层206、RLC层207、MAC层和层1(物理层)L1的LTE协议栈(或取决于所使用的通信网络例如3G或5G网络的另一个协议栈)，并且在LTE协议栈中的对应的处理之后，经由控制接口210被发送到网络。
网络中继IP级上的数据，即数据遍历层1 211、MAC层212、RLC层213、PDCP层214(包括RoHC解压缩)直至IP层215，并且在IP级上的中继之后，再次经由PDCP层214(包括RoHC压缩)、RLC层213、MAC层212向下中继到物理层211，并且经由空中接口216被发送到UE2中的接收器。应当注意，也可以以不同方式(例如，使用媒体网关)进行中继。在UE2中，以与UE1中相反的次序，数据遍历协议栈层1 217、MAC层218、RLC层219、PDCP层220、IP层21、UDP层222和RTP层223，由解码器224进行解码，并且最终由音频输出应用程序225输出。
如果被配置，则发送器侧(UE1)上的PDCP层206在发送之前使用RoHC(鲁棒报头压缩)压缩器226，压缩分组的更高层的报头(例如，取决于RoHC简档的RTP/UDP/IP报头或UDP/IP报头)。在接收器侧(UE2)上，在将分组转发到更高层之前，PDCP层220由RoHC解压缩器227对报头进行解压缩。
在3GPP LTE中，UMTS和GPRS报头压缩算法可用于减少空中接口106上的额外的开销。在LTE和UMTS的情况下，由PDCP(分组数据汇聚协议)子层执行压缩，在GPRS中，这通过SNDCP(子网相关汇聚协议)完成。大多数情况下，报头压缩是可选特征，而且尤其对于LTE语音(VoLTE)使用情况，RoHC算法通常是强制性的。
图3例示被添加用于在蜂窝网络(诸如通信系统100)上递送IP语音数据的(即，用于数据封装的)协议报头。
在应用层301上(在IP语音对应于音频子系统的情况下)提供了有效载荷，即，音频数据。RTP层添加RTP报头304，UDP层305添加UDP报头306，并且IP层307添加IP报头308。
在PDCP层308中，可以使用RoHC算法对RTP报头304、UDP报头306和IP报头308进行压缩，以生成压缩的报头310。然后，PDCP层308另外添加PDCP报头311，并且所得的分组被给到较低的层，如参考图2所解释的。在接收器侧上，在PDCP层中对应地执行RoHC解压缩。
仅用RoHC压缩协议层报头304、306、308。没有压缩用户数据(在VoLTE呼叫的情况下，音频有效载荷302)。取决于所配置的RoHC简档(profile)压缩这些协议层报头304、306、308。对于LTE语音使用情况，例如，以下RoHC简档可用于：
-RoHC简档1(RTP/UDP/IP)，如图3中所例示的
-RoHC简档2(UDP/IP)
也可以使用其它简档，诸如0x0101 ROHCv2 RTP、0x0102 ROHCv2 UDP和0x0004RoHC IP(RFC3843)。
在下行链路(DL)方向上RoHC解压缩失败的情况下(即，在图2的示例中的UE2侧上)，不能重构上层报头(例如，IP、UDP和RTP报头)，并且结果在蜂窝协议栈中的PDCP层220不能将IP数据递送到IP栈。因此，UE2还不能对所有后续分组的(例如，到UE1的VoLTE连接的)报头进行解压缩，直到UE2已经接收未压缩的(VoLTE连接的)完整报头，因为为了要对报头进行解压缩，要求先前分组的信息。因为分组缺失，所以也不能对接着的分组进行解压缩。一旦发生RoHC报头解压缩失败，PDCP层220就将RoHC反馈(否定ACK)发送到网络，以便对未压缩的报头请求重新同步。从在商业网络中的观察，花费大约100-150ms，直到在这样的情况下，移动终端可再次接收新的未压缩的帧。这导致100-150ms的音频间隙。结果是，由于音频间隙而且也由于用于补偿音频帧丢失的抖动缓冲器适应性而造成的语音质量劣化。
因为RoHC解压缩取决于先前接收的帧，一旦一个PDCP帧缺失，就可发生RoHC解压缩失败。在劣化的无线电条件的情况下，这可能很容易发生。结果，没有通过接收器(例如，移动终端105)正确解码的一个数据块可导致150ms的音频间隙。
图4示出分组丢失导致RoHC解压缩失败(导致多达150ms恢复时间)的情形的示例。
关于对应于RLC层219的RLC层401、对应于PDCP层220的PDCP层402、对应于RoHC227的RoHC 403、对应于IP层221的IP栈404、对应于音频解码器224和音频回放应用程序225的UDP层222和RTP层223以及音频子系统405示出示例。
在406中，RLC层401将在下行链路中接收的具有用于VoLTE连接的分组序列的压缩的IP分组#1的(即，包括压缩的报头的)PDU(协议数据单元)转发到PDCP层402。在407中，PDCP层402将对IP分组#1的解压缩请求发送到RoHC 403。在408中，假设RoHC 403对IP分组#1的报头成功地解压缩，并且将未压缩的报头发送到PDCP层402。在409中，PDCP层402将未压缩的IP分组#1递送到IP栈404，并且在对应的处理之后，在410中，IP栈404将IP分组#1的音频分组#1递送到音频子系统405，在411中，音频子系统405输出音频分组#1的音频数据。
类似地，对于用于VoLTE连接的分组序列的第二IP分组#2，在412中，RLC层401将在下行链路中接收的具有压缩的IP分组#2的(即，包括压缩的报头的)PDU(协议数据单元)转发到PDCP层402。在413中，PDCP层402将对IP分组#2的解压缩请求发送到RoHC 403。在414中，假设RoHC 403对IP分组#2的报头成功地解压缩，并且将未压缩的报头发送到PDCP层402。在415中，PDCP层402将未压缩的IP分组#2递送到IP栈404，并且在对应的处理之后，在416中，IP栈404将IP分组#2的音频分组#2递送到音频子系统405，在417中，音频子系统405输出音频分组#2的音频数据。
因此，成功地接收多个分组，但是在418中，假设在一些时间点处，用于VoLTE连接的分组序列的分组丢失，即，没有被UE2接收。
对于用于VoLTE连接的分组序列的后续IP分组#n，在419中，RLC层401将在下行链路中接收的具有压缩的IP分组#n的(即，包括压缩的报头的)PDU(协议数据单元)转发到PDCP层402。在420中，PDCP层402将对IP分组#n的解压缩请求发送到RoHC 403。由于在IP分组#n之前，已经丢失分组，所以RoCH 403不能对IP分组#n的报头成功地解压缩，并且在421中，将失败消息发送到PDCP层402。然后，在422中，PDCP层402丢弃IP分组#n。
类似地，对于用于VoLTE连接的分组序列的下一个IP分组#n+1，在423中，RLC层401将在下行链路中接收的具有压缩的IP分组#n的(即，包括压缩的报头的)PDU(协议数据单元)转发到PDCP层402。在424中，PDCP层402将对IP分组#n的解压缩请求发送到RoHC实体403。再次，由于已经丢失分组，所以RoHC 403不能对IP分组#n的报头成功地解压缩，并且在425中，将失败消息发送到PDCP层402。然后，在426中，PDCP层402丢弃IP分组#n。
因此，没有成功接收多个分组，即，在427中出现另外的解压缩失败，直到UE2接收包含用于IP分组#m的RoHC完整报头的PDU。
对于用于VoLTE连接的分组序列的IP分组#m，在428中，RLC层401将在下行链路接收的具有IP分组#m的PDU(协议数据单元)转发到PDCP层402。在429中，PDCP层402将对IP分组#m的解压缩请求发送到RoHC 403。即使IP分组#m具有完整的报头这也会发生，因为一旦配置RoHC，PDCP就必须发送所有分组作为RoHC压缩的分组。由于分组包括完整的未压缩报头，所以在430中，RoHC 403可重新同步且报告成功。在431中，PDCP层402将未压缩的IP分组#m递送到IP栈404，并且在对应的处理之后，在431中，IP栈404将IP分组#m的音频分组#m递送到音频子系统405，在417中，音频子系统405输出音频分组#m的音频数据。
对于用于VoLTE连接的分组序列的后续IP分组#m+1，在434中，RLC层401将在下行链路中接收的具有压缩的IP分组#m+1的(即，包括压缩的报头的)PDU(协议数据单元)转发到PDCP层402。在435中，PDCP层402将对IP分组#m+1的解压缩请求发送到RoHC 403。现在被重新同步，在436中，假设RoHC 403对IP分组#m+1的报头成功地解压缩，并且将未压缩的报头发送到PDCP层402。在437中，PDCP层402将未压缩的IP分组#m+1递送到IP栈404，并且在对应的处理之后，在438中，IP栈404将IP分组#m+1的音频分组#m+1递送到音频子系统405，在439中，音频子系统405输出音频分组#2的音频数据。
在如在问题陈述中描述的且在图4中例示的RoHC解压缩问题的情况下，丢掉的IP数据导致例如100-150ms的音频间隙240。
在以下中，描述了一种方法，在该方法中，代替丢掉数据，PDCP层220提取音频有效载荷，并且将音频有效载荷递送到音频子系统224、音频子系统225。这允许实现更短的音频中断时间。
例如，为了在RoCH解压缩失败的情况下检测音频数据且将音频数据递送到音频子系统224、音频子系统225，PDCP部件220应该：
-识别RoHC报头(即，压缩的报头)和音频有效载荷
-(选项1)基于最新成功地解压缩的报头和使用中的RoHC简档重构缺失的报头，然后遵循标准路径(即，经由IP层、UDP、RTP)递送IP分组，或作为替代
-(选项2)从具有或不具有RTP报头的PDCP SDU(服务数据单元)提取音频有效载荷，并且使用PDCP层220和音频子系统224、音频子系统225之间的专用接口，将音频数据连同用于音频数据重新排序的信息一起递送到音频子系统224、音频子系统225。
图5示出用于选项1的软件架构的示例。
对应于图2，在UE2侧上，架构包括RLC层501、PDCP层502、IP层503、UDP层504、RTP层505和音频解码器506。PDCP 502包括RoHC解压缩器507，另外还包括用于IP/UDP/RTP报头且包括PDCP分组序列号到RTP分组序列号的映射的分组报头数据库508。
图6示出用于选项2的软件架构的示例。
对应于图2，在UE2侧上，架构包括RLC层601、PDCP层602、IP层603、UDP层604、RTP层605和音频解码器606。PDCP 602包括RoHC解压缩器607，另外还包括数据库608，数据库608包括PDCP分组序列号到RTP分组序列号的映射。
另外，架构包括PDCP层602和音频解码器606(并且因此音频子系统)之间的直接接口609(即，避开IP栈层603、IP栈层604、IP栈层605的接口)。
图7示出在RoHC解压缩失败之后的音频数据恢复的示例，这允许与图4的示例相比实现更短的音频中断时间。
类似于图4，关于对应于RLC层219的RLC层701、对应于PDCP层220的PDCP层702、对应于RoHC 227的RoHC实体703、对应于IP层221的IP栈704、对应于音频解码器224和音频回放应用程序225的UDP层222和RTP层223以及音频子系统705示出示例。
类似于图4，在706中，RLC层701将在下行链路中接收的具有用于VoLTE连接的分组序列的压缩的IP分组#1的(即，包括压缩的报头的)PDU(协议数据单元)转发到PDCP层702。在707中，PDCP层702将对IP分组#1的解压缩请求发送到RoHC 703。在708中，假设RoHC 703对IP分组#1的报头成功地压缩，并且将未压缩的报头发送到PDCP层702。在709中，PDCP层702将未压缩的IP分组#1递送到IP栈704，并且在对应的处理之后，在710中，IP栈704将IP分组#1的音频分组#1递送到音频子系统705，在711中，音频子系统705输出音频分组#1的音频数据。
另外，对于用于VoLTE连接的分组序列的第二IP分组#2，在712中，RLC层701将在下行链路中接收的具有压缩的IP分组#2的(即，包括压缩的报头的)PDU(协议数据单元)转发到PDCP层702。在713中，PDCP层702将对IP分组#2的解压缩请求发送到RoHC 703。在714中，假设RoHC 703对IP分组#2的报头成功地解压缩，并且将未压缩的报头发送到PDCP层702。在715中，PDCP层702将未压缩的IP分组#2递送到IP栈704，并且在对应的处理之后，在716中，IP栈704将IP分组#2的音频分组#2递送到音频子系统705，在717中，音频子系统705输出音频分组#2的音频数据。
因此，成功地接收多个分组，但是在718中，假设在一些时间点处，用于VoLTE连接的分组序列的分组被丢失，即，没有被UE2接收。
对于用于VoLTE连接的分组序列的后续IP分组#n，在719中，RLC层701将在下行链路中接收的具有压缩的IP分组#n的(即，包括压缩的报头的)PDU(协议数据单元)转发到PDCP层702。在720中，PDCP层702将对IP分组#n的解压缩请求发送到RoHC 703。由于在IP分组#n之前已经丢失分组，所以在721中，RoHC 703不能对IP分组#n的报头成功地解压缩，并且将失败消息发送到PDCP层702。然而，在该示例中，代替丢弃IP分组#n，在722中，PDCP层702从IP分组#n提取有效载荷，并且根据选项1恢复其报头，并且在723中，将具有恢复的报头的IP分组#n的音频分组#n传输到IP栈704，并且在对应的处理之后，在724中，IP栈704将IP分组#n的音频分组#n递送到音频子系统705，在725中，音频子系统705输出音频分组#n的音频数据。可替代地，根据选项二，PDCP层702确定音频分组#n(即，IP分组#n的音频有效载荷)的RTP序列号，并且将音频分组#n和序列号直接传输到音频系统705。
类似地，对于用于VoLTE连接的分组序列的下一个IP分组#n+1，在726中，RLC层701将在下行链路中接收的具有压缩的IP分组#n+1的(即，包括压缩的报头的)PDU(协议数据单元)转发到PDCP层702。在727中，PDCP层702将对IP分组#n+1的解压缩请求发送到RoHC 703。再次，由于在IP分组#n之前已经丢失分组，所以RoHC 703不能对IP分组#n+1的报头成功地解压缩，并且在728中，将失败消息发送到PDCP层702。代替丢弃IP分组#n，在729中，PDCP层702从IP分组#n+1提取有效载荷，并且根据选项1恢复其报头，并且在730中，将具有恢复的报头的IP分组#n+1的音频分组#n+1传输到IP栈704，并且在对应的处理之后，在731中，IP栈704将IP分组#n+1的音频分组#n+1递送到音频子系统705，在732中，音频子系统705输出音频分组#n+1的音频数据。可替代地，根据选项2，PDCP层702确定音频分组#n+1的RTP序列号(即，IP分组#n的音频有效载荷)，并且直接将音频分组#n+1和序列号传输到音频系统705。
因此，即使没有成功地接收多个分组，即，在733中，对于多个分组，出现另外的解压缩失败，由于包含在丢失分组中的缺失的音频数据，所以仅存在很短的音频中断时间734，同时RoHC失败继续例如100-150ms的长度，直到UE2接收包含用于IP分组#m的RoHC完整报头的PDU。
对于用于VoLTE连接的分组序列的IP分组#m，在735中，RLC层701将在下行链路中接收的具有IP分组#m的PDU(协议数据单元)转发到PDCP层702。在736中，PDCP层702将对IP分组#m的解压缩请求发送到RoHC 703。由于分组包括完整的未压缩报头，所以在737中，RoHC 703可重新同步且报告成功。在738中，PDCP层702将未压缩的IP分组#m递送到IP栈704，并且在对应的处理之后，在739中，IP栈704将IP分组#m的音频分组#m递送到音频子系统705，在740中，音频子系统705输出音频分组#m的音频数据。
对于用于VoLTE连接的分组序列的IP分组#m+1，在741中，RLC层701将在下行链路中接收的具有压缩的IP分组#m+1的(即，包括压缩的报头的)PDU(协议数据单元)转发到PDCP层702。在742中，PDCP层702将对IP分组#m+1的解压缩请求发送到RoHC 703。现在被重新同步，在743中，假设RoHC 703对IP分组#m+1的报头成功地解压缩，并且将未压缩的报头发送到PDCP层702。在744中，PDCP层702将未压缩的IP分组#m+1递送到IP栈704，并且在对应的处理之后，在745中，IP栈704将IP分组#m+1的音频分组#m+1递送到音频子系统705，在746中，音频子系统705输出音频分组#2的音频数据。
在以下中，描述了用于从具有不能被解压缩的报头的分组检测(或提取)音频有效载荷的方法。如图3中例示的，在RoHC报头压缩之后，打包的数据由压缩的RoHC报头310和有效载荷302构成。
在VoLTE呼叫的情况下，如果使用RoHC简档1，则音频有效载荷302由AMR(自适应多速率)有效载荷或EVS(增强的语音服务)有效载荷构成，或和如果使用RoHC简档2，则音频有效载荷302由RTP报头+AMR有效载荷构成(这意味着在RoHC简档2的情况下，未被RoHC简档2压缩的RTP报头304被认为是有效载荷302的一部分)。
RoHC压缩的报头310可以为取决于RoHC算法的状态的可变大小。为了在解压缩失败之后提取音频有效载荷和/或重构RoHC报头，PDCP220层识别压缩的报头310的大小。可以由RoHC解压缩器227将RoHC报头大小给到PDCP部件220。作为替代，基于PDU大小的历史信息和先前接收的分组的RoHC报头(例如，最新成功打包接收的)(即，具有可解压缩的报头的)，PDCP部件220可以推断RoHC报头大小。一旦已经识别RoHC报头大小，PDCP层220就可使用以下方法中的一个来检索音频数据，并且将音频数据递送到音频子系统：
选项1：缺失的协议报头的重构且递送到IP栈
用该方法，在RoHC解压缩失败的情况下，PDCP部件502基于存储在数据库508中的先前接收的报头，重构缺失的报头。
例如，在最新成功的RoHC解压缩之后，PDCP部件502本地存储递送到上层(即，到IP层503且经由IP层503到更高层503、更高层505以及包括解码器506的音频子系统)的最后一个IP分组连同该IP分组的PDCP序列号。
然后，PDCP部件502可以基于以下，重构后续分组的协议报头(由于一个或多个丢失的分组，后续分组的协议报头不能被解压缩)：
已经通过复制公用字段存储的最后一个成功解压缩的报头的RTP报头、UDP报头和IP报头
由于最后一个成功解压缩而造成的PDCP分组缺失(即，丢失)的数量。这允许PDCP部件502通过考虑一个PDCP分组包含一个IP分组，重新计算RTP序列号和IP标识字段
可以从AMR报头提取的且计算RTP时间戳所要求的音频有效载荷(话音或静音)的类型。
PDCP部件502可以例如如以下用于RoHC简档1(RTP/UDP/IP)的重构分组的协议报头，即，当需要重构RTP、UDP和IP报头时：
PDCP部件502复制从最后一个未压缩的报头(或如果多于一个未压缩的报头存储在数据库5028中，则从多于一个未压缩的报头)复制的所有字段，除了重新计算的以下字段：
IPv4报头
总长度，基于数据的总大小，重新计算PDCP部件502
由于对于IP分段语音数据太小，所以分片偏移是不可用的(N/A)
报头校验和，PDCP部件502使用对应的IP校验和算法计算报头校验和
标识，可以通过将最后一个未压缩的IP报头增加在当前PDCP分组和包含最后一个未压缩的IP报头的PDCP分组之间接收的(或缺失的)IP分组的数量，重新计算标识。
IPv6报头
有效载荷长度，基于数据的总大小重新计算的有效载荷长度
下一个报头，当有效载荷仅为语音数据时，PDCP部件502可以设置为没有下一个报头。
UDP报头
将被重新计算的长度
校验和，PDCP部件502可以设置为0。然后，不通过接收UDP层校验校验和。
RTP报头
序列号(SN)；考虑到LTE协议栈按次序递送数据，PDCP部件502可以从最新成功解压缩的RTP报头和丢失PDCP分组的数量(由于每个PDCP分组包含一个RTP分组)，推断序列号。
时间戳，PDCP部件502可以考虑以下计算时间戳：
最新成功解压缩的RTP报头的时间戳。
丢失的PDCP分组的数量
当前音频有效载荷的音频数据类型。这可以使用音频有效载荷报头(例如，AMR报头)进行检测，或这可以从音频数据大小进行推断。
在当前PDCP分组和最后一个成功解压缩的分组之间经过的时间。
图8到图11例示报头重构，其中：
图8示出IPv4报头的图形表示。
图9示出IPv6报头的图形表示。
图10示出UDP报头的图形表示。
图11示出RTP报头的图形表示。
在图8到图11中，用对角阴影线示出在VoLTE期间恒定的或不重要的和示为空白的报头部分、可从一个或多个先前报头导出的部分，并且用垂直阴影线示出PDCP 502重新计算的部分。
大多数协议报头字段或是恒定的(可以从先前分组进行复制)，或可容易地被导出(例如，IP-ID新＝IP-ID旧+1)。
在RoHC简档2的情况下，即，当UDP报头和IP报头需要被重构时，PDCP层502可以应用如用于RoHC简档1的相同的报头重构，除了不需要重构的RTP报头以外。
一旦重构协议报头，PDCP层502可以重构完整的IP分组，并且将IP分组递送到IP栈。然后，音频子系统将使用传统路径即经由IP层503、UDP层504和RTP层505接收音频数据。
选项2：音频有效载荷提取和直接递送到音频子系统
用该选项，PDCP部件602直接从PDCP SDU提取音频有效载荷，而不用重构缺失的协议报头。可以从PDCP PDU提取音频数据，并且音频数据被递送到音频子系统。没有IPSec隧道被用于IMS语音数据，所以可以直接提取音频数据。
PDCP部件602使用专用接口609，将音频数据递送到音频子系统。为了帮助音频子系统确定何时播放音频数据，PDCP层602提供RTP序列号和RTP时间戳：
如果使用RoHC简档2，则没有压缩RTP报头。PDCP层602可直接从RTP报头取得RTP时间戳和RTP SN。
如果使用RoHC简档1，则对RTP报头进行压缩，并且PDCP层602导出RTP时间戳和RTPSN。
例如，可如以下完成RTP时间戳的导出：
知道LTE接入层顺序地递送数据，数据失序的唯一合理原因通常是存在由核心网络或由数据的发送者引入的一些扰乱。于是，具有递送到音频子系统的失序音频数据的可能性很低。假设顺序地递送PDCP层中的音频数据。
PDCP层602可根据以下，基于最新成功未压缩的RoHC报头和最新成功解压缩的分组和当前分组之间的PDCP分组的数量，确定RTP SN
估计的RTP_SN(RTP帧N)＝
最新成功递送的_RTP_SN+PDCP_SN(RTP帧N)
-PDCP_SN(最新成功递送的RTP帧)
其中最新成功递送的_RTP_SN为具有最新成功未压缩RoHC报头的RTP分组的RTPSN。包含该IP/RTP分组的PDCP PDU的对应的PDCP SN为PDCP_SN(最新成功递送的帧)。
可以根据以下，计算RTP时间戳(应当注意，该方法也可用于选项1中的RTP时间戳计算)：
RTP时间戳(RTP帧N)＝
最新成功递送的_RTP_时间戳+音频大小(缺失帧)
+音频大小(帧N)
帧N的音频大小(即，根据音频采样的音频分组的大小)取决于音频帧类型(话音或静音)。这可以使用当前帧的AMR报头来确定。可使用最后一个成功解压缩的帧和当前帧之间的Δ时间(时间差)且使用(多个)缺失帧的数量，估计(多个)缺失帧的音频大小。两个音频帧之间的Δ时间通常为20ms。两个静音帧之间的Δ时间通常为160ms。
例如，如果所测量的Δ时间为67ms且缺失帧的数量为2且当前帧为音频话音帧，则缺失帧很可能为音频话音帧。
如果所测量的Δ时间为365ms且缺失帧的数量为1且当前帧为静音帧，则缺失帧最可能为静音帧。
总之，根据各种示例，如图12中例示的提供一种装置。
图12示出根据实施例的适于维持用于移动通信设备中的接收数据质量的装置1200。
装置1200包括媒体输出单元1201和接收器1202，接收器1202经配置用于接收分组序列的分组，分组包括压缩的报头和媒体有效载荷。装置1200另外包括处理器1203，处理器1203经配置用于确定是否出现压缩的报头的解压缩；以及基于没有压缩的报头的解压缩，确定媒体有效载荷的序列号，从分组提取媒体有效载荷，并且将媒体有效载荷和所确定的序列号转发到媒体输出单元1201。
根据各种示例，换句话说，诸如移动终端的通信设备避免丢弃其头部不能解压缩的分组，换句话说，其保持包括在分组中的至少媒体有效载荷，尽管其不能对其报头进行解压缩，从分组提取媒体有效载荷，并且传递媒体有效载荷连同媒体有效载荷的序列号，用于输出媒体有效载荷。如果接收器接收具有可解压缩的报头的分组，即，不阻止对其解压缩，即，出现解压缩，则处理器通常可以对报头进行解压缩，并且基于来自解压缩的报头的信息，将媒体有效载荷转发到媒体输出电路。
应当注意，报头可包括多个协议的报头信息。例如，报头可包括UDP、IP和RTP报头信息。
例如，参考图12描述的方法允许在RoHC解压缩失败的情况下，基于PDCP层中的功能，将音频数据递送到通信设备的音频子系统(例如，抖动缓冲器或通信设备的音频解码器)，以
当RoHC解压缩失败时，基于用于VoLTE使用情况中的历史数据和RoHC简档，重构RTP/UDP/IP协议报头，
检测使RoHC解压缩失败的PDCP数据中的音频有效载荷
基于丢失的PDCP PDU，估计RTP序列号和RTP时间戳
将音频数据递送到音频子系统
在缺失报头的重构之后，经由协议层IP/UDP/RTP使用标准数据路径，或
(例如，根据AMR或EVS)使用到音频子系统，例如，到音频解码器或抖动缓冲器的专用直接接口
甚至在RoHC解压缩失败的情况下，该方法允许音频子系统播放音频。然后，减少音频间隙，从而提高音频质量。
可例如由一个或多个电路实施装置或移动通信设备的部件(例如，媒体输出电路、接收器和处理器)。“电路”可以被理解为任何种类的逻辑实施实体，“电路”可以为执行存储在存储器、固件或其任何组合中的软件的特殊目的的电路或处理器。因此，“电路”可以是硬连线逻辑电路或可编程逻辑电路诸如可编程处理器，例如，微处理器。“电路”也可以为执行软件例如任何种类的计算机程序的处理器。下面将更详细描述的相应功能的任何其它种类的实施方案也可以被理解为“电路”。
移动通信设备例如完成如图13中例示的方法。
图13示出例示例如由通信设备完成的用于接收数据的方法的流程图1300。
在1301中，通信设备接收分组序列的分组，分组包括压缩的报头和媒体有效载荷。
在1302中，通信设备确定是否出现压缩的报头的解压缩。
基于没有压缩的报头的解压缩，在1303中，通信设备确定媒体有效载荷的序列号，从分组提取媒体有效载荷，并且将媒体有效载荷和所确定的序列号转发到媒体输出单元。
以下示例从属于另外的实施例。
在示例1中为如图12中例示的装置。
在示例2中，示例1的主题可可选地包括媒体有效载荷包括音频数据。
在示例3中，示例1-2中的任一个的主题可可选地包括媒体有效载荷包括视频数据。
在示例4中，示例1-3中的任一个的主题可可选地包括分组序列的每个分组包括序列号，并且包括压缩的报头和媒体有效载荷。
在示例5中，示例1-4中的任一个的主题可可选地包括处理器另外经配置用于基于来自音频分组序列的先前分组的报头的信息，确定序列号。
在示例6中，示例1-5中任一个的主题可可选地包括先前分组为在通过移动通信设备对其报头进行解压缩的分组之前接收的音频分组序列的先前分组。
在示例7中，示例1-8中任一个的主题可可选地包括存储器，该存储器经配置用于存储先前分组的序列号，并且处理器经配置用于基于所存储的序列号，确定分组的序列号。
在示例8中，示例1-7中任一个的主题可可选地包括处理器经配置用于重构分组的报头，并且经配置用于将媒体有效载荷连同所重构的报头转发到媒体输出单元。
在示例9中，示例8的主题可可选地包括分组的报头包括序列号。
在示例10中，示例8-9中任一个的主题可可选地包括处理器经配置用于基于在通过移动通信设备对其报头进行成功解压缩的分组之前接收的音频分组序列的先前分组的报头，重构报头。
在示例11中，示例10的主题可可选地包括存储器，该存储器经配置用于存储在通过移动通信设备对其报头进行成功解压缩的分组之前接收的音频分组序列的先前分组的报头。
在示例12中，示例1-11中的任一个的主题可可选地包括处理器实现数据链路层的部件，并且报头包括互联网协议层、传送层和应用层中的至少一个的报头信息。
在示例13中，示例1-12中的任一个的主题可可选地包括媒体输出单元实现应用层的部件。
在示例14中，示例1-13中的任一个的主题可可选地包括序列号为应用层序列号。
在示例15中，示例1-14中的任一个的主题可可选地包括序列号为实时数据传输序列号。
在示例16中，示例1-15中的任一个的主题可可选地包括序列号为实时传送协议序列号。
在示例17中，示例1-16中的任一个的主题可可选地包括处理器实现移动通信设备的分组数据汇聚协议层的部件。
在示例18中，示例1-17中任一个的主题可可选地包括对媒体有效载荷进行编码，并且媒体输出单元包括媒体解码器。
在示例19中，示例1-18中任一个的主题可可选地包括处理器经配置用于确定媒体有效载荷的时间戳，并且经配置用于将媒体有效载荷、序列号和时间戳的指示转发到媒体输出单元。
在示例20中，示例1-19中任一个的主题可可选地包括没有出现压缩的报头的解压缩包括移动通信设备缺乏对压缩的报头解压缩所必需的数据。
在示例21中，示例1-20中任一个的主题可可选地包括没有出现压缩的报头的解压缩包括移动通信设备已经缺失包括对压缩的报头进行解压缩所必需的数据的分组序列的先前分组。
在示例22中，示例1-21中任一个的主题可可选地包括分组具有分组序列号，并且处理器经配置用于基于分组序列号，确定媒体有效载荷的序列号。
在示例23中，示例1-22中任一个的主题可可选地包括处理器实现通信层的部件，并且经配置用于将媒体有效载荷和序列号的指示转发到避开通信层上方的至少一个其它通信层的媒体输出单元。
在示例24中，示例1-23中任一个的主题可可选地包括处理器实现数据链路层的部件，并且至少一个其他通信层包括互联网协议层和传送层中的至少一个。
示例25是如图12中所例示的用于接收数据的方法。
在示例26中，示例25的主题可可选地包括媒体有效载荷包括音频数据。
在示例27中，示例25-26中任一个的主题可可选地包括媒体有效载荷包括视频数据。
在示例28中，示例25-27中任一个的主题可可选地包括分组序列的每个分组具有序列号，并且包括压缩的报头和媒体有效载荷。
在示例29中，示例25-28中任一个的主题可可选地包括基于来自音频分组序列的先前分组的报头的信息，确定序列号。
在示例30中，示例25-29中任一个的主题可可选地包括先前分组是在通过方法对分组的报头解压缩之前接收的音频分组序列的先前分组。
在示例31中，示例25-30中任一个的主题可可选地包括存储先前分组的序列号，并且基于所存储的序列号，确定分组的序列号。
在示例32中，示例25中的任一个的主题可可选地包括重构分组的报头，并且将媒体有效载荷连同所重构的报头转发到媒体输出单元。
在示例33中，示例32的主题可可选地包括分组的报头包括序列号。
在示例34中，示例32-33中任一个的主题可可选地包括基于在成功解压缩分组的报头之前接收的音频分组序列的先前分组的报头，重构报头。
在示例35中，示例34的主题可可选地包括存储器经配置用于存储在成功解压缩分组的报头之前接收的音频分组序列的先前分组的报头。
在示例36中，示例25-35中任一个的主题可可选地包括数据链路层实行确定、提取和转发，并且报头包括互联网协议层、传送层和应用层中的至少一个的报头信息。
在示例37中，示例25-36中任一个的主题可可选地包括媒体输出单元实现应用层的部件。
在示例38中，示例25-37中任一个的主题可可选地包括序列号为应用层序列号。
在示例39中，示例25-38中任一个的主题可可选地包括序列号为实时数据传输序列号。
在示例40中，示例25-39中任一个的主题可可选地包括序列号为实时传送协议序列号。
在示例41中，示例25-40中任一个的主题可可选地包括分组数据汇聚协议层实行确定、提取和转发。
在示例42中，示例25-41中任一个的主题可可选地包括对媒体有效载荷进行编码，并且媒体输出单元包括媒体解码器。
在示例43中，示例25-42中任一个的主题可可选地包括确定媒体有效载荷的时间戳，并且将媒体有效载荷、序列号和时间戳的指示转发到媒体输出单元。
在示例44中，示例25-43中任一个的主题可可选地包括没有出现压缩的报头的解压缩包括缺乏对压缩的报头解压缩所必需的数据。
在示例45中，示例25-44中任一个的主题可可选地包括没有出现压缩的报头的解压缩包括已经缺失包括对压缩的报头进行解压缩所必需的数据的分组序列的先前分组。
在示例46中，示例25-45中任一个的主题可可选地包括分组具有分组序列号，并且方法包括基于分组序列号，确定媒体有效载荷的序列号。
在示例47中，示例25-46中任一个的主题可可选地包括通信层实行确定、提取和转发，并且方法包括将媒体有效载荷和序列号的指示转发到避开通信层上方的至少一个其他通信层的媒体输出单元。
在示例48中，示例25-47中任一个的主题可可选地包括数据链路层实行确定、提取和转发，并且至少一个其他通信层包括互联网协议层和传送层中的至少一个。
示例49是一种具有在其上记录的指令的计算机可读媒体，当由处理器执行指令时，使得处理器实行根据示例25-48中的任一个的用于接收数据的方法。
根据另外的示例，通过了一种通信设备，包括媒体输出单元；接收器，该接收器经配置用于接收分组序列的分组，分组包括压缩的报头和媒体有效载荷；以及处理器，该处理器经配置用于检测是否阻止压缩的报头的解压缩，并且，如果阻止了压缩的报头的解压缩，则经配置用于确定媒体有效载荷的序列号，从分组提取媒体有效载荷，并且将媒体有效载荷和序列号的指示转发到媒体输出单元。
根据另外的示例，提供了用于接收数据的方法，包括接收分组序列的分组，分组包括压缩的报头和媒体有效载荷，检测是否阻止压缩的报头的解压缩，并且，如果阻止了压缩的报头的解压缩，则确定媒体有效载荷的序列号，从分组提取媒体有效载荷，并且将媒体有效载荷和序列号的指示转发到媒体输出单元。
应当注意，上面的示例中的任一个的特征中的一个或多个可以与其它示例中的任一个组合。
虽然已经描述了具体方面，但是本领域的技术人员应当理解，可以在其中作出在形式和细节上的各种改变，而不脱离如由所附权利要求书限定的本公开的方面的精神和范围。因此，由所附权利要求书指示范围，并且因而旨在包含落入权利要求书的等效的含义和范围内的所有改变。

Claims (25)

1.一种适于维持用于移动通信设备中的接收数据质量的装置，所述装置包括：
媒体输出单元；
接收器，所述接收器经配置用于接收分组序列的分组，所述分组包括压缩的报头和媒体有效载荷；以及
处理器，所述处理器经配置用于
确定是否出现所述压缩的报头的解压缩；以及
基于没有所述压缩的报头的解压缩，确定所述媒体有效载荷的序列号，从所述分组提取所述媒体有效载荷，并且将所述媒体有效载荷和所确定的序列号转发到所述媒体输出单元。
2.根据权利要求1所述的装置，其中所述媒体有效载荷包括音频数据。
3.根据权利要求1所述的装置，其中所述媒体有效载荷包括视频数据。
4.根据权利要求1所述的装置，其中所述分组序列的每个分组包括序列号，并且包括压缩的报头和媒体有效载荷。
5.根据权利要求1所述的装置，其中所述处理器另外经配置用于基于来自音频分组序列的先前分组的报头的信息，确定所述序列号。
6.根据权利要求1所述的装置，其中所述先前分组是在由所述移动通信设备对其报头进行解压缩的分组之前接收的所述音频分组序列的先前分组。
7.根据权利要求1所述的装置，包括存储器，所述存储器经配置用于存储所述先前分组的序列号，并且所述处理器经配置用于基于所存储的序列号，确定所述分组的序列号。
8.根据权利要求1所述的装置，其中所述处理器经配置用于重构所述分组的报头，并且经配置用于将所述媒体有效载荷连同所重构的报头转发到所述媒体输出单元。
9.根据权利要求8所述的装置，其中所述分组的报头包括所述序列号。
10.根据权利要求8所述的装置，其中所述处理器经配置用于基于在由所述移动通信设备对其报头进行成功解压缩的分组之前接收的所述音频分组序列的先前分组的报头，重构所述报头。
11.根据权利要求10所述的装置，包括存储器，所述存储器经配置用于存储在由所述移动通信设备对其报头进行成功解压缩的分组之前接收的所述音频分组序列的先前分组的报头。
12.根据权利要求1所述的装置，其中所述处理器实现数据链路层的部件，并且所述报头包括互联网协议层、传送层和应用层中的至少一个的报头信息。
13.根据权利要求1所述的装置，其中所述媒体输出单元实现应用层的部件。
14.根据权利要求1所述的装置，其中所述序列号为应用层序列号。
15.根据权利要求1所述的装置，其中所述序列号为实时数据传输序列号。
16.根据权利要求1所述的装置，其中所述序列号为实时传送协议序列号。
17.根据权利要求1所述的装置，其中所述处理器实现所述移动通信设备的分组数据汇聚协议层的部件。
18.根据权利要求1所述的装置，其中对所述媒体有效载荷进行编码，并且所述媒体输出单元包括媒体解码器。
19.根据权利要求1所述的装置，其中所述处理器经配置用于确定所述媒体有效载荷的时间戳，并且经配置用于将所述媒体有效载荷、所述序列号和所述时间戳的指示转发到所述媒体输出单元。
20.根据权利要求1所述的装置，其中没有出现所述压缩的报头的解压缩包括所述移动通信设备缺乏对所述压缩的报头解压缩所必需的数据。
21.根据权利要求1所述的装置，其中没有出现所述压缩的报头的解压缩包括所述移动通信设备已经缺失包括对所述压缩的报头进行解压缩所必需的数据的所述分组序列的先前分组。
22.根据权利要求1所述的装置，其中所述分组具有分组序列号，并且所述处理器经配置用于基于所述分组序列号，确定所述媒体有效载荷的序列号。
23.根据权利要求1所述的装置，其中所述处理器实现通信层的部件，并且经配置用于将所述媒体有效载荷和所述序列号的指示转发到避开所述通信层上方的至少一个其它通信层的所述媒体输出单元。
24.一种用于接收用于移动通信设备中的数据的方法，所述方法包括：
接收分组序列的分组，所述分组包括压缩的报头和媒体有效载荷；
确定是否出现所述压缩的报头的解压缩；以及
基于没有所述压缩的报头的解压缩，
确定所述媒体有效载荷的序列号；
从所述分组提取所述媒体有效载荷；以及
将所述媒体有效载荷和所确定的序列号转发到媒体输出单元。
25.一种具有在其上记录的指令的计算机可读媒体，当由处理器执行所述指令时，所述指令使得所述处理器实行根据权利要求24所述的用于接收数据的方法。
CN201710447362.9A 2016-06-30 2017-06-14 适于维持接收数据质量的装置和用于接收数据的方法 Active CN107566330B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP16177155.5A EP3264779B1 (en) 2016-06-30 2016-06-30 Apparatus adapted for maintaining receiving data quality and method for receiving data
EP16177155.5 2016-06-30

Publications (2)

Publication Number Publication Date
CN107566330A true CN107566330A (zh) 2018-01-09
CN107566330B CN107566330B (zh) 2022-01-04

Family

ID=56360202

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710447362.9A Active CN107566330B (zh) 2016-06-30 2017-06-14 适于维持接收数据质量的装置和用于接收数据的方法

Country Status (3)

Country Link
US (1) US10681108B2 (zh)
EP (1) EP3264779B1 (zh)
CN (1) CN107566330B (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110572850A (zh) * 2019-09-05 2019-12-13 京信通信系统（中国）有限公司 5g基站缓存处理业务数据方法、装置、设备和存储介质
CN110784439A (zh) * 2018-07-26 2020-02-11 苹果公司 用于压缩无线电承载的顺序分组递送

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180096370A (ko) * 2017-02-21 2018-08-29 삼성전자주식회사 무선 통신 시스템에서 암호화 파라미터 값을 결정하기 위한 장치 및 방법
CN114125058B (zh) * 2020-08-10 2023-05-16 华为技术有限公司 数据包解压缩方法、电子设备和网络侧设备
US20230291816A1 (en) * 2022-03-10 2023-09-14 Qualcomm Incorporated Protocol overhead reduction for packet data convergence protocol

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1655536A (zh) * 2004-02-12 2005-08-17 三星电子株式会社 在多媒体广播/多播业务系统中恢复报头解压缩的方法
US6999429B1 (en) * 2000-03-03 2006-02-14 Telefonaktiebolaget Lm Ericsson Access technology integrated header compression
CN1961520A (zh) * 2004-04-01 2007-05-09 诺基亚公司 用于在不可靠环境中启用报头压缩来提供网络数据恢复优化的方法和装置
CN101057479A (zh) * 2004-11-15 2007-10-17 艾利森电话股份有限公司 用于在首标解压缩中处理失序分组的方法及设备
CN101107829A (zh) * 2004-12-08 2008-01-16 高通股份有限公司 用于在稳健报头压缩中增强本地修复的方法和系统
CN100423481C (zh) * 2001-09-28 2008-10-01 松下电器产业株式会社 报头压缩分组接收装置和方法
US20160006784A1 (en) * 2014-07-04 2016-01-07 Electronics And Telecommunications Research Institute Method and apparatus for processing mpeg media transport protocol packets

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI107000B (fi) * 1999-02-17 2001-05-15 Nokia Mobile Phones Ltd Otsikon pakkaaminen reaaliaikaisissa palveluissa
US6680921B1 (en) * 1999-06-18 2004-01-20 Telefonaktiebolaget Lm Ericsson (Publ) Estimation of time stamps in real-time packet communications
US6608841B1 (en) * 1999-12-30 2003-08-19 Nokia Networks Oy System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks
US8077679B2 (en) * 2001-03-28 2011-12-13 Qualcomm Incorporated Method and apparatus for providing protocol options in a wireless communication system
US7836124B2 (en) * 2001-11-16 2010-11-16 Clearwire Legacy Llc RTP, UDP, IP header compression on the circuit switched type airlink access
US10009401B2 (en) * 2015-09-23 2018-06-26 Qualcomm Incorporated Call continuity in high uplink interference state
US10037240B2 (en) * 2015-09-24 2018-07-31 Qualcomm Incorporated Timestamp repair mechanism in case of decompression failure

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6999429B1 (en) * 2000-03-03 2006-02-14 Telefonaktiebolaget Lm Ericsson Access technology integrated header compression
CN100423481C (zh) * 2001-09-28 2008-10-01 松下电器产业株式会社 报头压缩分组接收装置和方法
CN1655536A (zh) * 2004-02-12 2005-08-17 三星电子株式会社 在多媒体广播/多播业务系统中恢复报头解压缩的方法
CN1961520A (zh) * 2004-04-01 2007-05-09 诺基亚公司 用于在不可靠环境中启用报头压缩来提供网络数据恢复优化的方法和装置
CN101057479A (zh) * 2004-11-15 2007-10-17 艾利森电话股份有限公司 用于在首标解压缩中处理失序分组的方法及设备
CN101107829A (zh) * 2004-12-08 2008-01-16 高通股份有限公司 用于在稳健报头压缩中增强本地修复的方法和系统
US20160006784A1 (en) * 2014-07-04 2016-01-07 Electronics And Telecommunications Research Institute Method and apparatus for processing mpeg media transport protocol packets

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110784439A (zh) * 2018-07-26 2020-02-11 苹果公司 用于压缩无线电承载的顺序分组递送
CN110784439B (zh) * 2018-07-26 2022-03-01 苹果公司 用于压缩无线电承载的顺序分组递送
US11388628B2 (en) 2018-07-26 2022-07-12 Apple Inc. In order packet delivery for compressed radio bearers
CN110572850A (zh) * 2019-09-05 2019-12-13 京信通信系统（中国）有限公司 5g基站缓存处理业务数据方法、装置、设备和存储介质

Also Published As

Publication number Publication date
US20180007113A1 (en) 2018-01-04
CN107566330B (zh) 2022-01-04
EP3264779B1 (en) 2022-04-13
US10681108B2 (en) 2020-06-09
EP3264779A1 (en) 2018-01-03

Similar Documents

Publication Publication Date Title
CN107566330A (zh) 适于维持接收数据质量的装置和用于接收数据的方法
JP5084842B2 (ja) 無線通信ネットワークにおける改良されたヘッダ圧縮
US9357039B2 (en) Header elimination for real time internet applications
KR102338994B1 (ko) 베어러를 재구성하는 방법 및 장치
EP1362446B1 (en) Transfer of ip data in communications system, using several logical connections for compressed fields on the basis of different contexts
EP1786170B1 (en) Header compression in voice packets
EP1626517A2 (en) Method and apparatus for transmitting/receiving VoIP packets with UDP checksum in an mobile communication system
US20110019695A1 (en) Wireless communication apparatus, header compression method thereof, and header decompression method thereof
JP2004533792A (ja) データパケット接続におけるヘッダ圧縮識別子の伝送
CN113796057B (zh) 无线通信系统中防止数据丢失的用户数据压缩方法和装置
EP4016948A1 (en) Method and apparatus for compressing ethernet header, and method and apparatus for decompressing ethernet header
TW200522579A (en) Methods for seamless delivery of broadcast and multicast content across cell borders and/or between different transmission schemes and related apparatus
JP4856251B2 (ja) 無線通信ネットワークにおけるヘッダの抑制
CN101371552B (zh) 无序输送的信道上的报头压缩方法
CN102318282B (zh) 一种压缩数据包的传输方法及装置
GB2525944A (en) Bearer reconfiguration
US20230140866A1 (en) Wireless data link layer compression and decompression
US20230025610A1 (en) Method and apparatus for driving pdcp during data decompression failure in next-generation mobile communication system
KR101595575B1 (ko) 이동 통신 시스템에서 데이터 송수신 방법 및 장치
US7599371B1 (en) System and method for optimizing data transport in a communications system
US20220124554A1 (en) Header compression adaptive to quality of radio channel
KR101020318B1 (ko) 비대칭 양방향 패킷데이터 송수신 방법 및 시스템
CN102342146A (zh) 鲁棒的数据传输
CN109219079A (zh) 一种ir报文传输方法及通信设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20200402

Address after: California, USA

Applicant after: Apple Inc.

Address before: California, USA

Applicant before: INTEL Corp.

Effective date of registration: 20200402

Address after: California, USA

Applicant after: INTEL Corp.

Address before: California, USA

Applicant before: INTEL IP Corp.

GR01 Patent grant
GR01 Patent grant