ES2366192T3 - Envío de información por un canal de comunicación. - Google Patents

Envío de información por un canal de comunicación. Download PDF

Info

Publication number
ES2366192T3
ES2366192T3 ES05749640T ES05749640T ES2366192T3 ES 2366192 T3 ES2366192 T3 ES 2366192T3 ES 05749640 T ES05749640 T ES 05749640T ES 05749640 T ES05749640 T ES 05749640T ES 2366192 T3 ES2366192 T3 ES 2366192T3
Authority
ES
Spain
Prior art keywords
data
channels
bit rate
physical layer
application layer
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.)
Expired - Lifetime
Application number
ES05749640T
Other languages
English (en)
Inventor
Harinath Garudadri
Phoom Sagetong
Sanjiv Nanda
Stein A. Lundby
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.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
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 Qualcomm Inc filed Critical Qualcomm Inc
Application granted granted Critical
Publication of ES2366192T3 publication Critical patent/ES2366192T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

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
    • 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/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • 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
    • 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/1066—Session management
    • H04L65/1101—Session protocols
    • 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/75—Media network packet handling
    • 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/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 
    • 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
    • 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/04—Protocols for data compression, e.g. ROHC
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/166—IP fragmentation; TCP segmentation
    • 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/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/115—Selection of the code volume for a coding unit prior to coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/124—Quantisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H04N19/152—Data rate or code amount at the encoder output by measuring the fullness of the transmission buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/164—Feedback from the receiver or from the transmission channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/174—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a slice, e.g. a line of blocks or a group of blocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • 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/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
    • 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/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6131—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a mobile phone network
    • 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/61—Network physical structure; Signal processing
    • H04N21/6156—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network
    • H04N21/6181—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network involving transmission via a mobile phone network
    • 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/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • 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/64707—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 for transferring content from a first network to a second network, e.g. between IP and wireless
    • 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
    • H04W28/065—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H04W72/044—Wireless resource allocation based on the type of the allocated resource
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H04W88/181—Transcoding devices; Rate adaptation devices
    • 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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • 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/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4788—Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H04W72/1263—Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Time-Division Multiplex Systems (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)
  • Telephone Function (AREA)
  • Alarm Systems (AREA)
  • Reverberation, Karaoke And Other Acoustics (AREA)
  • Reduction Or Emphasis Of Bandwidth Of Signals (AREA)

Abstract

Un procedimiento para transmitir información de capa de aplicación en un sistema de comunicación inalámbrica (100), comprendiendo el procedimiento: determinar (2004) tamaños posibles de paquete de capa física de una pluralidad de canales disponibles de comunicación de tasa de bits constante; establecer limitaciones para particionar unidades de información de capa de aplicación de manera que las particiones se dimensionen para que el tamaño de cada partición coincida con uno de los tamaños de paquete de la capa física determinados disponibles en la pluralidad de canales de comunicación disponibles inalámbrica de tasa de bits constante, caracterizado porque esta etapa comprende particionar una unidad de información de capa de aplicación en múltiples particiones descodificables de manera independiente, de manera que exista una correspondencia de uno a uno entre las unidades de información de capa de aplicación particionadas y los paquetes de la capa física comunicados por los canales de comunicación disponibles.

Description

Reivindicación de prioridad conforme a 35 U.S.C. §119
La presente solicitud de patente reivindica prioridad sobre la solicitud provisional U.S. nº 60/571.673, titulada "Multimedia Packets Carried by CDMA Physical Layer Products", depositada el 13 de mayo de 2004, y cedida al cesionario de la misma.
REFERENCIA A LAS SOLICITUDES COPENDIENTES PARA LA PATENTE
La presente solicitud para patente se relaciona con las siguientes solicitudes de patente copendientes U.S.:
"Method And Apparatus For Allocation Of Information To Channels Of A Communication System", con expediente de abogado nº 030166U2, depositada al mismo tiempo que este documento, cedida al cesionario de este documento; y "Header Compression Of Multimedia Data Transmitted Over A Wireless Communication System", con expediente de abogado nº 030166U3, depositada al mismo tiempo que este documento, cedida al cesionario de este documento; y "Synchronization Of Audio And Video Data In A Wireless Communication System", con expediente de abogado nº 030166U4, depositada al mismo tiempo que este documento, cedida al cesionario de este documento.
ANTECEDENTES
I. Campo
La presente invención se refiere en general al envío de información por un sistema de comunicación, y más concretamente, a la partición de unidades de información para que coincidan con un paquete de capa física de un enlace de comunicación de tasa de bits constante.
II. Antecedentes
La demanda del envío de datos multimedia por diversas redes de comunicación está aumentando. Por ejemplo, los consumidores desean el envio de vídeo por diversos canales de comunicación, como Internet, redes de radio y línea telefónica. Los datos multimedia pueden tener distintos formatos y velocidades de datos, y las diversas redes de comunicación utilizan diferentes mecanismos para la transmisión de datos en tiempo real por sus canales de comunicación respectivos.
Un tipo de red de comunicación que se ha convertido en algo común son las redes móviles de radio para comunicaciones inalámbricas. Los sistemas de comunicación inalámbrica tienen muchas aplicaciones que incluyen, por ejemplo, teléfonos móviles, paginación, bucles locales inalámbricos, asistentes digitales personales (PDAs), telefonía por Internet, y sistemas de comunicación por satélite. Una aplicación especialmente importante son los sistemas de telefonía móvil para abonados móviles. Tal como se utiliza en este documento, el término sistema "celular" abarca frecuencias de servicios de comunicaciones personales (PCS) y celulares. Se han desarrollado diversas interfaces a través del aire para tales sistemas de telefonía móvil que incluyen el acceso múltiple por división de frecuencia (FDMA), el acceso múltiple por división de tiempo (TDMA), y el acceso múltiple por división de código (CDMA).
Se han establecido diferentes estándares nacionales e internacionales domésticos para soportar las diversas interfaces aéreas, por ejemplo, el Servicio Avanzado de Telefonía Móvil (AMPS), el Sistema Global para Móviles (GSM), el Servicio General de Paquetes vía Radio (GPRS), el Entorno GSM de Datos Mejorados (EDGE), el Estándar Provisional 95 (IS-95) y sus derivados, IS-95A, IS-95B, ANSI J-STD-008 (a menudo denominado colectivamente en este documento IS-95), y los sistemas de alta velocidad de datos emergentes como el cdma2000, el Servicio Universal de Telecomunicaciones Móviles (UMTS), y el CDMA de banda ancha (WCDMA). Estos estándares son promulgados por la Asociación de la Industria de las Telecomunicaciones (AIT), el Proyecto de Asociación de Tercera Generación (3GPP), el Instituto Europeo de Estándares de Telecomunicaciones (ETSI), y otros organismos normativos conocidos.
A los usuarios o clientes de redes móviles de radio, como las redes de telefonía móvil, les gustaría recibir datos multimedia de transmisión, como vídeo, multimedia, y protocolo de Internet (IP) por un enlace de comunicación inalámbrica. Por ejemplo, los clientes desean poder recibir video, como una teleconferencia o emisiones de televisión, en su teléfono móvil u otro dispositivo de comunicación inalámbrico portátil. Otros ejemplos del tipo de datos que los clientes desean recibir con sus dispositivos de comunicación inalámbrica incluyen difusión/emisión multimedia y acceso a Internet.
5
10
15
20
25
30
35
40
45
50
55
Existen diferentes tipos de fuentes de datos multimedia y diferentes tipos de canales de comunicación en los que se desea transmitir los datos de transmisión. Por ejemplo, una fuente de datos multimedia puede producir datos a una tasa de bits constante (CBR) o a una tasa de bits variable (VBR). Además, el canal de comunicación puede transmitir datos a una CBR o a una VBR. La Tabla 1 más adelante enumera diversas combinaciones de fuentes de datos y canales de comunicación.
Tabla 1
Fuente
Canal Ejemplo
CBR
CBR
Ley mu o Ley A en PSTN
VBR
VBR
video MPEG-4 por línea de telefonía IP, vocoder de velocidad variable cdma2000 como el vocoder 13K, EVRC y SMV por canal fundamental (FCH)
CBR
VBR Flujo continuo AMR en cdma2000 FCH
VBR
CBR Vídeo comprimido por redes inalámbricas por conmutación de circuitos (3G-324M)
Por lo general los canales de comunicación transmiten datos en trozos, lo que denominamos paquetes de capa física o tramas de capa física. Los datos generados por la fuente multimedia pueden ser un flujo de bytes continuo, como una señal de voz codificada que utiliza la ley mu o la ley A. Con mayor frecuencia, los datos generados por la fuente multimedia consisten en grupos de bytes, llamados paquetes de datos. Por ejemplo, un codificador de vídeo MPEG-4 comprime la información visual como una secuencia de unidades de información, lo que se denomina en este documento tramas de vídeo. La información visual por lo general es codificada a una velocidad constante de trama de vídeo por el codificador, de por lo general 25 ó 30 Hz, y debe ser renderizada a la misma velocidad por el descodificador. El período de trama de vídeo es el tiempo entre dos tramas de vídeo y puede calcularse como la inversa de la velocidad de trama de vídeo, por ejemplo el período de trama de vídeo de 40 ms se corresponde con una velocidad de trama de vídeo de 25 Hz. Cada trama de vídeo se codifica en un número variable de paquetes de datos, y todos los paquetes de datos se transmiten al descodificador. Si se pierde una parte de un paquete de datos, ese paquete se vuelve inutilizable por el descodificador. Por otro lado, el descodificador puede reconstituir la trama de vídeo incluso si se pierden algunos de los paquetes de datos, pero a costa de cierta degradación de la calidad en la secuencia de vídeo resultante. Por lo tanto, cada paquete de datos contiene parte de la descripción de la trama de vídeo, y los paquetes de número son por lo tanto variables de una trama de vídeo a otra.
En el caso en el que una fuente produce datos a una tasa de bits constante y un canal de comunicación transmite los datos a una velocidad constante, los recursos del sistema de comunicación se utilizan de manera eficiente, suponiendo que la velocidad de datos de canal de comunicación sea por lo menos tan rápida como la velocidad de datos de origen, o si las dos velocidades de datos se ajustan de otra manera. En otras palabras, si la velocidad de datos constante de la fuente es la misma que la velocidad constante de datos del canal, entonces pueden utilizarse plenamente los recursos del canal, y los datos de origen pueden transmitirse sin retardo. Asimismo, si la fuente produce datos a una velocidad variable y el canal transmite a una velocidad variable, entonces mientras la velocidad de datos de canal pueda soportar la velocidad de datos de origen, entonces las dos velocidades de datos pueden ajustarse y, nuevamente, los recursos del canal se utilizan plenamente y todos los datos de origen pueden transmitirse sin retardo.
Si la fuente produce datos a una velocidad constante de datos y el canal es un canal de velocidad variable de datos, entonces los recursos de canal pueden no ser utilizados de manera tan eficiente como es posible. Por ejemplo, en este caso desajustado la ganancia de multiplexación estadística (SMG) es menor que la comparada con una fuente CBR en un canal CBR ajustado. La ganancia de multiplexación estadística resulta cuando el mismo canal de comunicación puede ser utilizado, o multiplexado, entre varios usuarios. Por ejemplo, cuando se utiliza un canal de comunicación para transmitir voz, el que habla no suele hablar continuamente. Es decir, habrá una “secuencia de habla” del orador seguida de un silencio (escucha). Si la relación de tiempo entre la “secuencia de habla” y el silencio fuese, por ejemplo 1:1, entonces en promedio el mismo canal de comunicación podría multiplexarse y podría soportar dos usuarios. Pero en caso en el que la fuente de datos tiene una velocidad constante de datos y se envía por un canal de velocidad variable, no hay SMG porque no hay momento en que el canal de comunicación puede ser utilizado por otro usuario. Es decir, no hay descanso durante el "silencio" para una fuente CBR.
El último caso indicado en la Tabla 1 anterior, es la situación en la que la fuente de datos multimedia es un flujo de tasa de bits variable, como un flujo de datos multimedia como vídeo, y se transmite por un canal de comunicación que tiene una tasa de bits constante, como un canal inalámbrico de radio con una asignación de tasa de bits constante. En este caso, el retardo se introduce por lo general entre la fuente y el canal de comunicación, creando "chorros" de datos de manera que el canal de comunicación pueda utilizarse de manera eficaz. En otras palabras, el flujo de datos de velocidad variable se almacena en una memoria intermedia y se retarda el tiempo suficiente para que la salida de la memoria intermedia pueda ser vaciada a una velocidad de datos constante, para que coincida con la velocidad de datos fija del canal. La memoria intermedia necesita almacenar, o retardar, datos suficientes para poder mantener una salida constante sin "vaciar" la memoria intermedia de manera que el canal de comunicación CBR se utilice plenamente y no se malgasten los recursos del canal de comunicación.
El codificador genera periódicamente tramas de vídeo según el período de trama de vídeo. Las tramas de vídeo consisten en paquetes de datos, y la cantidad total de datos en una trama de vídeo es variable. El descodificador de vídeo debe renderizar las tramas de vídeo a la misma velocidad de trama de vídeo utilizada por el codificador para garantizar un resultado aceptable para el espectador. La transmisión de los tramas de vídeo, que tienen una cantidad variable de datos, a una velocidad constante de trama de vídeo y por un canal de comunicación de velocidad constante puede resultar en ineficiencias. Por ejemplo, si la cantidad total de datos en una trama de vídeo es demasiado grande para ser transmitida en el período de trama de vídeo en la tasa de bits del canal, entonces el descodificador puede no recibir toda la trama a tiempo para renderizarla según la velocidad de trama de vídeo. En la práctica, se utiliza una memoria intermedia de conformación del tráfico para suavizar tales grandes variaciones para el envío por un canal de velocidad constante. Esto introduce un retardo al renderizar el vídeo, si el codificador debe mantener una velocidad constante de trama de vídeo.
Otro problema es que si los datos de múltiples tramas de vídeo están contenidos en un único paquete de capa física, entonces la pérdida de un único paquete de capa física resulta en la degradación de múltiples tramas de vídeo. Incluso en situaciones en las que los paquetes de datos están cerca de los tamaños de paquete de capa física, la pérdida de un paquete de capa física puede resultar en la degradación de múltiples tramas de vídeo.
A partir del documento WO 02/23745 A2 se conocen un procedimiento y un dispositivo para la transmisión de datos de alta velocidad en un sistema de comunicación inalámbrica. En una forma de realización de transmisión desde una unidad móvil, los datos se reciben en un formato de protocolo de punto a punto multienlace y se separan en flujos de datos individuales. Cada flujo de datos se modula en una portadora diferente y se emite al mismo tiempo.
US 2003/0208615 se refiere a un procedimiento y a un dispositivo para ajustar el tamaño máximo de las secuencias de información transmitidas en una red de telecomunicaciones. Para que cada secuencia de información sea transmitida, el identificador del terminal de destino y el tamaño máximo correspondiente de las secuencias de información se leen en la base de información; el tamaño máximo leído se compara con el tamaño máximo actual permitido por el protocolo de red; y, si el tamaño máximo leído es menor que el tamaño máximo actual, el tamaño máximo actual se ajusta asignándole el valor del tamaño máximo leído.
Por lo tanto, existe en la técnica una necesidad de dispositivos y técnicas que puedan mejorar la transmisión de datos multimedia de velocidad de datos variable por los canales de velocidad de datos constante.
RESUMEN
La invención se define en las reivindicaciones independientes 1 y 16.
Formas de realización divulgadas en este documento abordan las necesidades anteriormente indicadas proporcionando unos procedimientos y dispositivo para transmitir unidades de información por un canal de comunicación de tasa de bits constante. Las técnicas incluyen la partición de las unidades de información en paquetes de datos en los que el tamaño de los paquetes de datos se selecciona para que coincida con los tamaños de paquete de datos de capa física de un canal de comunicación. Por ejemplo, el número de bytes contenidos en cada unidad de información puede variar con el tiempo y el número de bytes que cada paquete de datos de capa física que pueden llevar los canales de comunicación puede variar de manera independiente. Las técnicas describen la partición de las unidades de información, creando así una pluralidad de paquetes de datos. Por ejemplo, puede limitarse un codificador de manera que codifique las unidades de información en paquetes de datos de tamaños que no superen, o "coincidan con", los tamaños de paquete de capa física del canal de comunicación. A continuación, los paquetes de datos se asignan a los paquetes de datos de capa física de los canales de comunicación.
La frase "trama multimedia", para vídeo, se utiliza en este documento para referirse a una trama de vídeo que puede visualizarse/renderizarse en un dispositivo de visualización, después de la descodificación. Una trama de vídeo puede dividirse adicionalmente en unidades descodificables de manera independiente. En el lenguaje de vídeo, éstas se denominan "segmentos". En el caso de audio y voz, la expresión "trama multimedia" se utiliza en este documento para referirse a la información en una ventana temporal durante la cual la voz y el audio se comprimen para su transporte y descodificación en el receptor. La frase "intervalo de unidad de información" se utiliza en este documento para representar la duración de tiempo de la trama multimedia descrita anteriormente. Por ejemplo, en el caso de video, el intervalo de la unidad de información es 100 milisegundos en el caso de un video de 10 tramas por segundo. Además, como ejemplo, en el caso de la voz, el intervalo de unidad de información es por lo general de 20 milisegundos en cdma2000, GSM y WCDMA. A partir de esta descripción, debería resultar evidente que, por lo general las tramas de audio/voz no se dividen adicionalmente en unidades descodificables de manera independiente y por lo general las tramas de vídeo se dividen adicionalmente en segmentos que son descodificables de manera independiente. Debería resultar evidente a partir del contexto cuándo las frases "trama multimedia", "intervalo de unidad de información", etc. se refieren a datos multimedia de vídeo, audio y voz.
Las técnicas pueden utilizarse con diversas interfaces a través del aire, como el Sistema Global para Comunicaciones Móviles (GSM), el Servicio General de Paquetes vía Radio (GPRS), el Entorno GSM de Datos Mejorados (EDGE), o los estándares basados en CDMA como TIA/EIA-95-B (IS-95), TIA/EIA-98-C (IS-98), IS-2000, HRPD, y CDMA de banda ancha (WCDMA), y otros.
Los aspectos incluyen determinar tamaños posibles de paquete de capa física de por lo menos un canal de comunicación disponible de tasa de bits constante. Las unidades de información se particionan, creando así una pluralidad de paquetes de datos de manera que el tamaño de un paquete de datos individual no exceda, o se ajuste a, uno de los paquetes de capa física de por lo menos uno de los canales de comunicación de tasa de bits constante. A continuación los paquetes de datos se codifican y asignan a los paquetes de capa física del canal de comunicación ajustado de tasa de bits constante. La información de codificación puede incluir un codificador fuente equipado con un módulo de control de velocidad capaz de generar particiones de tamaño variable.
Utilizando las técnicas descritas, las unidades se codifican en un flujo de paquetes de datos que se transmiten por uno o más canales de tasa de bits constante. Como las unidades de información varían en tamaño, pueden ser codificadas en paquetes de datos de tamaño diferente, y diferentes combinaciones de canales de tasa de bits constante, con diferentes tamaños disponibles de paquete de capa física, pueden utilizarse para transmitir los paquetes de datos. Por ejemplo, una unidad de información puede incluir datos de vídeo que se incluyen en tramas de vídeo de diferentes tamaños, y por tanto pueden seleccionarse diferentes combinaciones de paquetes de capa física de canal de comunicación de tasa de bits fija para la transmisión de las tramas de vídeo de tamaños diferentes.
Otros aspectos incluyen determinar un tamaño de paquete de capa física y una velocidad de datos disponible de una pluralidad de canales de comunicación de tasa de bits constante. A continuación, se asignan unidades de información a los paquetes de datos, en los que se seleccionan los tamaños de paquete de datos individuales para que tengan un tamaño que encaje en un paquete de capa física de uno de los canales de comunicación individuales de tasa de bits constante. Puede seleccionar una combinación de canales individuales de tasa de bits constante de manera que los tamaños de paquete de capa física coincidan con los tamaños de paquete de flujo de datos de tasa de bits variable. Pueden seleccionarse diferentes combinaciones de canales de tasa de bits constante, por ejemplo uno o más, dependiendo del flujo de datos de tasa de bits variable.
Otro aspecto es un codificador configurado para aceptar las unidades de información. A continuación, las unidades de información se particionan en paquetes de datos en los que el tamaño de los paquetes de datos individuales no supera, o coincide con, un tamaño de paquete de capa física de uno de un canal de comunicación disponible de velocidad de bits constante.
Otro aspecto es un descodificador configurado para aceptar flujos de datos de una pluralidad de canales de comunicación de tasa de bits constante. Los flujos de datos son descodificados y los flujos de datos descodificados se acumulan en un flujo de datos de tasa de bits variable.
Ejemplos de canales de comunicación de tasa de bits constante incluyen GSM, GPRS, EDGE, o los estándares basados en CDMA como TIA/EIA-95-B (IS-95), TIA/EIA-98-C (IS-98), IS-2000, HRPD, y CDMA de banda ancha (WCDMA).
Otras características y ventajas de la presente invención se pondrán de manifiesto a partir de la siguiente descripción de las formas de realización de ejemplo, que ilustran, a modo de ejemplo, aspectos de la invención.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
La Figura 1 es una ilustración de partes de un sistema de comunicación 100 construido según la presente invención. La Figura 2 es un diagrama de bloques que ilustra una red de datos por paquetes de ejemplo y diversas opciones de interfaz aérea para enviar paquetes de datos por una red inalámbrica en el sistema de Figura 1. La Figura 3 es un diagrama de bloques que ilustra dos tramas de radio 302 y 304 en el sistema de Figura 1 que utilizan la interfaz aérea GSM. La Figura 4 es un gráfico que ilustra un ejemplo de variación de los tamaños de trama para una secuencia de vídeo típica en el sistema de Figura 1. La Figura 5 es un diagrama de bloques que ilustra el retardo de almacenamiento en memoria intermedia utilizado para soportar la transmisión de tramas de diversos tamaños a transmitir por un canal CBR en el sistema de Figura 1. La Figura 6 es un gráfico que ilustra el retardo de almacenamiento en memoria intermedia introducido fluyendo continuamente un flujo multimedia de tasa de bits variable (VBR) por un canal CBR en el sistema de Figura 1. La Figura 7 es un gráfico de barras que ilustra el retardo de la memoria intermedia ∆b en milisegundos, para diversos videoclips de secuencias de 50 tramas codificados con una velocidad nominal de 64 kbps y una constante Qp para AVC/H.264 y MPEG-4 en el sistema. La Figura 8 es un gráfico de barras que ilustra la calidad visual, representada por la bien comprendida métrica objetiva “relación señal a ruido de pico” (PSNR), de las secuencias ilustradas en la Figura 7.
La Figura 9 es un diagrama que ilustra los diversos niveles de encapsulación presentes cuando se transmiten datos multimedia, como datos de vídeo, por un enlace inalámbrico que utiliza el protocolo UDP/RTP/IP en el sistema. La Figura 10 es un diagrama que ilustra un ejemplo de la asignación de paquetes de datos de aplicación, como paquetes de datos multimedia, en paquetes de datos de capa física en el sistema. La Figura 11 ilustra un ejemplo de codificación de paquetes de capa de aplicación según la técnica EBR en el sistema. La Figura 12 es un diagrama de bloques que ilustra una forma de realización de un códec que transmite un flujo de datos VBR por una red IP/UDP/RTP, como Internet. La Figura 13 es un gráfico de barras que ilustra la disminución relativa de la relación señal a ruido de pico (PSNR) para diversos ejemplos de secuencias de vídeo codificadas, utilizando diferentes técnicas de codificación y con una pérdida de paquete de canal es del 1%. La Figura 14 es un gráfico de barras que ilustra la disminución relativa de la relación señal a ruido de pico (PSNR) cuando la pérdida de canal es del 5% para varios ejemplos de secuencias codificadas de vídeo. La Figura 15 es un gráfico de barras que ilustra el porcentaje de paquetes de datos defectuosos recibidos para las secuencias de vídeo codificadas de Figura 13. La Figura 16 es un gráfico de barras que ilustra el porcentaje de paquetes de datos defectuosos recibidos para las secuencias de vídeo codificadas de Figura 14. La Figura 17 es un gráfico que ilustra el PSNR de una secuencia de vídeo codificada de muestra frente a la tasa de bits para cuatro casos diferentes. La Figura 18 es un gráfico que ilustra el PSNR de otras secuencias de vídeo codificadas frente a la tasa de bits para cuatro casos diferentes. La Figura 19 es un gráfico que ilustra el plan de transmisión para un flujo AVC/H.264 de una velocidad media de 64 kbps. La Figura 20 es un diagrama de flujo que ilustra una forma de realización de un procedimiento de transmisión de datos. La Figura 21 es un diagrama de flujo que ilustra otra forma de realización de un procedimiento de transmisión de datos. La Figura 22 es un diagrama de bloques de un dispositivo de comunicación inalámbrica, o una estación móvil (MS), construida según una forma de realización de ejemplo de la presente invención.
DESCRIPCIÓN DETALLADA
La expresión "de ejemplo" se utiliza en este documento para referirse a "servir como ejemplo, caso, o ilustración". Cualquier forma de realización descrita en este documento como "de ejemplo" no debe interpretarse necesariamente como preferente o ventajosa sobre otras formas de realización.
La expresión "flujo continuo" se utiliza en este documento para referirse al envío en tiempo real de datos multimedia de naturaleza continua, como información de vídeo, voz o audio, por canales dedicados y compartidos en aplicaciones conversacionales, de unidifusión y de difusión. La frase "trama multimedia", para video, se utiliza en este documento para referirse a una trama de vídeo que puede visualizarse/renderizarse en un dispositivo de visualización, después de la descodificación. Una trama de vídeo puede dividirse adicionalmente en unidades descodificables de manera independiente. En el lenguaje de vídeo, éstas se denominan "segmentos". En el caso de audio y voz, el término "trama multimedia" se utiliza en este documento para referirse a la información en una ventana temporal en la cual la voz o el audio se comprimen para el transporte y la descodificación en el receptor. La frase "intervalo de unidad de información" se utiliza en este documento para representar la duración de tiempo de la trama multimedia descrita anteriormente. Por ejemplo, en el caso del video, el intervalo de la unidad de información es 100 milisegundos en el caso de un video de 10 tramas por segundo. Además, como ejemplo, en el caso de la voz, el intervalo de unidad de información es por lo general de 20 milisegundos en cdma2000, GSM y WCDMA. A partir de esta descripción, debería resultar evidente que, por lo general las tramas de audio/voz no se dividen adicionalmente en unidades descodificables de manera independiente y por lo general las tramas de vídeo se dividen adicionalmente en segmentos que son descodificables de manera independiente. Debería resultar evidente a partir del contexto cuándo las frases "trama multimedia", "intervalo de unidad de información", etc. se refieren a datos multimedia de vídeo, audio y voz.
Se describen técnicas para transmitir las unidades de información por una pluralidad de canales de comunicación de tasa de bits constante. Las técnicas incluyen particionar las unidades de información en paquetes de datos en los que el tamaño de los paquetes de datos se selecciona para que coincida con los tamaños de paquete de datos de capa física de un canal de comunicación. Por ejemplo, las unidades de información pueden darse a una velocidad constante y los canales de comunicación pueden transmitir los paquetes de datos de capa física a una velocidad diferente. Las técnicas describen la partición de las unidades de información, creando así una pluralidad de paquetes de datos. Por ejemplo, puede limitarse un codificador de manera que codifique las unidades de información en tamaños que coincidan con los tamaños de paquete de capa física del canal de comunicación. A continuación, los paquetes de datos codificados se asignan a los paquetes de datos de capa física del canal de comunicación. Las unidades de información pueden incluir un flujo de datos de tasa de bits variable, datos multimedia, datos de vídeo, y datos de audio. Los canales de comunicación incluyen GSM, GPRS, EDGE, o los estándares basados en CDMA como TIA/EIA-95-B (IS-95), TIA/EIA-98-C (IS-98), IS2000, HRPD, cdma2000, CDMA de banda ancha (WCDMA), y otros.
Los aspectos incluyen determinar los tamaños de paquete de capa física posibles de por lo menos un canal de comunicación disponible de tasa de bits constante. Las unidades de información se particionan, creando así una pluralidad de paquetes de datos de manera que el tamaño de un paquete de datos individual se haga coincidir con uno de los paquetes de capa física de por lo menos uno de los canales de comunicación de tasa de bits constante. A continuación, los paquetes de datos son codificados y asignados a los paquetes de capa física del canal de comunicación ajustado de tasa de bits constante. De esta manera, las unidades de información se codifican en un flujo de paquetes de datos que se transmiten por uno o más canales de tasa de bits constante. Como las unidades de información varían, pueden codificarse en paquetes de datos de tamaño diferente, y diferentes combinaciones de canales de tasa de bits constante, con diferentes tamaños disponibles de paquete de capa física, pueden utilizarse para transmitir paquetes de datos. Por ejemplo, una unidad de información puede incluir datos de vídeo que se incluyen en tramas de diferentes tamaños, y por tanto pueden seleccionarse diferentes combinaciones de paquetes de capa física de canal de comunicación de tasa de bits fija para adaptarse a la transmisión de tramas de video de diferente tamaño.
Otros aspectos incluyen determinar un tamaño de paquete de capa física y una velocidad de datos disponibles de una pluralidad de canales de comunicación de tasa de bits constante. A continuación, las unidades de información se asignan a los paquetes de datos, en los que se seleccionan tamaños individuales de paquete de datos para que tengan un tamaño que encaje en un paquete de capa física de uno de los canales de comunicación individuales de tasa de bits constante. Puede seleccionarse una combinación de canales individuales de tasa de bits constante de manera que los tamaños de paquete de capa física coincidan con los tamaños de paquete de flujo de datos de tasa de bits variable. Pueden seleccionarse diferentes combinaciones de canales de tasa de bits constante, por ejemplo uno o más, dependiendo del flujo de datos de tasa de bits variable.
Otro aspecto es un codificador configurado para aceptar las unidades de información. A continuación, las unidades de información se particionan en paquetes de datos en los que el tamaño de los paquetes de datos individuales coincide con un tamaño de paquete de capa física de uno de un canal de comunicación disponible de tasa de bits constante.
Otro aspecto es un descodificador configurado para aceptar flujos de datos de una pluralidad de canales de comunicación de tasa de bits constante. Los flujos de datos son descodificados y los flujos de datos descodificados se acumulan en un flujo de datos de tasa de bits variable.
Ejemplos de unidades de información incluyen flujos de datos de tasa de bits variable, datos multimedia, datos de vídeo, y datos de audio. Las unidades de información pueden darse a una velocidad de repetición constante. Por ejemplo, las unidades de información pueden ser tramas de datos de vídeo. Ejemplos de canales de comunicación de tasa de bits constante incluyen canales CMDA, canales GSM, canales GPRS, y canales EDGE.
También se proporcionan ejemplos de protocolos y formatos para transmitir unidades de información, como datos de tasa de bits variable, datos multimedia, datos de vídeo, datos de voz, o datos de audio, de una fuente o servidor de contenido en la red por cable a un móvil. Las técnicas descritas son aplicables a cualquier tipo de aplicación multimedia, como las aplicaciones de transmisión de unidifusión, conversacionales y de transmisión de difusión. Por ejemplo, las técnicas pueden utilizarse para transmitir datos multimedia, como datos de vídeo (como un servidor de contenido en la transmisión por cable a un móvil inalámbrico), así como otras aplicaciones multimedia como los servicios de difusión/multidifusión, o servicios conversacionales y de audio como la videotelefonía entre dos móviles.
La figura 1 muestra un sistema de comunicación 100 construido según la presente invención. El sistema de comunicación 100 incluye una infraestructura 101, múltiples dispositivos de comunicación inalámbrica (WCD) 104 y 105, y unos dispositivos de comunicación fija 122 y 124. Los WCDs también se denominarán estaciones móviles (MS) o móviles. En general, los WCDs pueden ser móviles o fijos. Los dispositivos de comunicación fija 122 y 124 pueden incluir, por ejemplo, nodos de servicio, o servidores de contenido, que proporcionan diversos tipos de datos multimedia como los datos de flujo continuo. Además, las MSs pueden transmitir datos de flujo continuo, como los datos multimedia.
La infraestructura 101 también puede incluir otros componentes, como las estaciones base 102, los controladores de estación base 106, los centros de conmutación móvil 108, una red de conmutación 120, y similares. En una forma de realización, la estación base 102 se integra con el controlador de estaciones base 106, y en otras formas de realización la estación base 102 y el controlador de estaciones base 106 son componentes separados. Pueden utilizarse diferentes tipos de redes de conmutación 120 para enrutar señales en el sistema de comunicación 100, por ejemplo, redes IP, o la red de telefonía pública conmutada (PSTN).
La expresión "enlace directo" o "enlace descendente" se refiere a la ruta de señales desde la infraestructura 101 hasta una MS, y la expresión "enlace reverso" o "enlace ascendente" se refiere a la ruta de señales desde una MS hasta la infraestructura. Como se muestra en la Figura 1, las MSs 104 y 105 reciben las señales 132 y 136 en el enlace directo y transmiten las señales 134 y 138 en el enlace reverso. En general, las señales transmitidas desde una MS 104 y 105 están destinadas a ser recibidas en otro dispositivo de comunicación, como otra unidad remota, o un dispositivo de comunicación fija 122 y 124, y se enrutan a través de una red IP o red de conmutación. Por ejemplo, si la señal 134 transmitida desde un WCD de inicio 104 está destinada a ser recibida por una MS de destino 105, la señal se enruta a través de la infraestructura 101 y se transmite una señal 136 en el enlace directo a la MS de destino 105. Asimismo, las señales iniciadas en la infraestructura 101 pueden emitirse a una MS 105. Por ejemplo, un proveedor de contenido puede enviar datos multimedia, como datos multimedia de flujo continuo, a una MS 105. Por lo general, un dispositivo de comunicación, como una MS o un dispositivo de comunicación fijo, puede ser un iniciador de y un destino para las señales.
Ejemplos de una MS 104 incluyen teléfonos móviles, ordenadores personales habilitados para la comunicación inalámbrica, y asistentes digitales personales (PDA), y otros dispositivos inalámbricos. El sistema de comunicación 100 puede diseñarse para soportar uno o más estándares inalámbricos. Por ejemplo, los estándares pueden incluir los estándares denominados Sistema Global para Comunicaciones Móviles (GSM), Servicio General de Paquetes vía Radio (GPRS), Entorno GSM de Datos Mejorados (EDGE), TIA/EIA-95-B (IS-95), TIA/EIA-98-C (IS-98), IS2000, HRPD, cdma2000, CDMA de banda ancha (WCDMA), y otros.
La Figura 2 es un diagrama de bloques que ilustra una red de datos de paquete de ejemplo y diversas opciones de interfaz aérea para el envío de datos de paquete por una red inalámbrica. Las técnicas descritas pueden implementarse en una red conmutada de datos de paquete 200 como la ilustrada en la Figura 2. Como se muestra en el ejemplo de la Figura 2, el sistema de red conmutada de datos de paquete puede incluir un canal inalámbrico 202, una pluralidad de nodos receptores o MS 204, un nodo emisor o servidor de contenido 206, un nodo de servicio 208, y un controlador 210. El nodo emisor 206 puede acoplarse al nodo de servicio 208 a través de una red 212 como Internet.
El nodo de servicio 208 puede comprender, por ejemplo, un nodo de servicio de datos de paquete (PDSN) o un nodo de soporte GPRS de servicio (SGSN) y un nodo de soporte GPRS pasarela (GGSN). El nodo de servicio 208 puede recibir datos de paquete del nodo emisor 206, y servir los paquetes de información al controlador 210. El controlador 210 puede incluir, por ejemplo, un controlador de estaciones base/función de control de paquetes (BSC/PCF) o un controlador de red de radio (RNC). En una forma de realización, el controlador 210 se comunica con el nodo de servicio 208 por una red de acceso de radio (RAN). El controlador 210 se comunica con el nodo de servicio 208 y transmite los paquetes de información por el canal inalámbrico 202 a por lo menos uno de los nodos receptores 204, como una MS.
En una forma de realización, el nodo de servicio 208 o el nodo emisor 206, o ambos, también pueden incluir un codificador para codificar un flujo de datos, o un descodificador para descodificar un flujo de datos, o ambos. Por ejemplo el codificador puede codificar un flujo de vídeo y producir así tramas de datos de tamaño variable, y el descodificador podría recibir tramas de datos de tamaños variables y descodificarlos. Dado que las tramas son de diverso tamaño, pero la velocidad de trama de vídeo es constante, se produce un flujo de tasa de bits variable de datos. Asimismo, una MS puede incluir un codificador para codificar un flujo de datos, o un descodificador para descodificar una flujo de datos recibidos, o ambos. El término "códec" se utiliza para describir la combinación de un codificador y un descodificador.
En un ejemplo ilustrado en la Figura 2, los datos, como datos multimedia, del nodo emisor 206 que se conecta a la red, o a Internet 212 pueden enviarse a un nodo receptor, o MS 204, a través del nodo de servicio, o Nodo de Servicio de Datos de Paquete (PDSN) 206, y un Controlador, o Controlador de Estación Base/Función de Control de Paquetes (BSC/PCF) 208. La interfaz del canal inalámbrico 202 entre la MS 204 y el BSC/PCF 210 es una interfaz aérea y, por lo general, puede utilizar muchos canales para los datos de señalización y portadores, o carga útil.
Interfaz aérea
La interfaz aérea 202 puede operar según cualquiera de una serie de estándares inalámbricos. Por ejemplo, los estándares pueden incluir estándares basados en TDMA, como el Sistema Global para Comunicaciones Móviles (GSM), el Nodo de Soporte GPRS Pasarela (GPRS), el Entorno GSM de Datos Mejorados (EDGE), o los estándares basados en CDMA como TIA/EIA-95-B (IS-95), TIA/EIA-98-C (IS-98), IS2000, HRPD, cdma2000, CDMA de banda ancha (WCDMA), y otros.
En un sistema basado en cdma2000, los datos pueden transmitirse en múltiples canales, por ejemplo, en un canal fundamental (FCH), utilizado generalmente para transmitir voz, un canal de control dedicado (DCCH), un canal suplementario (SCH) y un canal de datos de paquete (PDCH) así como otros canales.
El FCH proporciona un canal de comunicación para la transmisión de voz a múltiples velocidades fijas, p. ej., velocidad completa, media velocidad, un cuarto de velocidad y 1/8º de velocidad. El FCH proporciona estas velocidades y cuando la actividad de voz de un usuario requiere menos que la velocidad completa para lograr una calidad de voz de destino, el sistema reduce la interferencia a otros usuarios en el sistema utilizando una de las velocidades de datos más baja. El beneficio de reducir la velocidad fuente para aumentar la capacidad del sistema es bien conocido en las redes CDMA.
DCCH es similar a FCH pero proporciona sólo tráfico de velocidad completa a una de dos velocidades fijas, 9,6 kbps en la configuración de radio tres (RC3) y 14,4 en la configuración de radio cinco (RC5). Esto se denomina velocidad de tráfico 1 x. SCH puede configurarse para proporcionar velocidades de tráfico a 1x, 2x, 4x, 8x y 16x en cdma2000. Cuando no hay datos a transmitir, DCCH y SCH pueden suspender la transmisión, es decir que no transmiten ningún dato, también denominado dtx, para garantizar una menor interferencia a los demás usuarios en el sistema o para mantenerse dentro del margen de potencia de transmisión del transmisor de la estación base. El PDCH puede configurarse para transmitir paquetes de datos que son n*45 bytes, donde n={1,2,4,8}.
Los canales DCCH y FCH proporcionan un retardo constante y una pérdida baja de paquete de datos para la comunicación de datos, por ejemplo, para permitir servicios conversacionales. Los canales PDCH y SCH proporcionan múltiples canales de tasa de bits fija que proporcionan más anchos de banda, por ejemplo, 300 kbps a 3 Mbps, que FCH y DCCH. SCH y PDCH también tienen retardos variables porque estos canales son compartidos entre muchos usuarios. En el caso de SCH, se multiplexan múltiples usuarios en el tiempo, lo que introduce diferentes cantidades de retardo dependiendo de la carga del sistema. En el caso del PDCH, el ancho de banda y el retardo dependen, por ejemplo, de las condiciones de radio, la calidad de servicio (QoS) negociada, y otras consideraciones de programación. Hay disponibles canales similares en los sistemas basados en TIA/EIA-95-B (IS-95), TIA/EIA-98-C (IS-98), IS2000, HRPD, UMTS, y CDMA de banda ancha (WCDMA).
Hay que reseñar que el FCH proporciona múltiples velocidades de datos de bits fijas (completa, media, un cuarto y 1/8) para conservar la potencia requerida por un usuario de voz. Por lo general, un codificador de voz, o vocoder, utilizará una velocidad de datos inferior cuando la estructura de tiempo-frecuencia de una señal a transmitir permita una mayor compresión sin comprometer indebidamente la calidad. Esta técnica se denomina comúnmente codificación de voz de tasa de bits variable controlada en origen. Por lo tanto, en un sistema basado en TIA/EIA-95-B (IS-95), TIA/EIA-98-C (IS-98), IS2000, HRPD, UMTS, o cdma2000 existen múltiples canales de tasa de bits fija para la transmisión de datos.
En un sistema basado en CDMA, como cdma2000, los canales de comunicación se dividen en un flujo continuo de "intervalos". Por ejemplo, los canales de comunicación pueden dividirse en segmentos de 20 ms o intervalos de tiempo. Esto también se denomina "intervalo de tiempo de transmisión" (TTI). Los datos transmitidos durante estos intervalos de tiempo se ensamblan en paquetes, en los que el tamaño de los paquetes de datos depende de la velocidad de datos disponible, o ancho de banda, del canal. Por lo tanto, durante cualquier intervalo de tiempo individual es posible que haya paquetes de datos individuales transmitiéndose por su canal de comunicación respectivo. Por ejemplo, durante un único intervalo de tiempo, un paquete de datos puede transmitirse en el canal DCCH y un paquete de datos diferente puede transmitirse simultáneamente en el canal SCH.
Asimismo, en un sistema basado en GSM, o GPRS, o EDGE, los datos pueden transmitirse entre el BSC 208 y la MS 204 utilizando múltiples intervalos de tiempo dentro de una trama.
La Figura 3 es un diagrama de bloques que ilustra dos tramas de radio 302 y 304 en la interfaz aérea GSM. Como se muestra en la Figura 3, cada una de las tramas de radio de interfaz aérea GSM 302 y 304 se divide en ocho intervalos de tiempo. Los intervalos de tiempo individuales se asignan a determinados usuarios en el sistema. Además, la recepción y la transmisión GSM utiliza dos frecuencias diferentes y el enlace directo y el enlace reverso tienen un desfase de tres intervalos de tiempo. Por ejemplo, en la Figura 3 una trama de radio de enlace descendente 302 comienza en el instante t0 y se transmitiría en una frecuencia, y una trama de radio de enlace ascendente 304 se transmitiría en una frecuencia diferente. La trama de radio de enlace descendente 302 tiene un desfase de tres intervalos de tiempo, TS0-TS2, de la trama de radio de enlace ascendente. Tener un desfase entre las tramas de radio de enlace descendente y ascendente permite que los dispositivos de comunicación inalámbrica,
o terminales, puedan operar sin tener que ser capaces de transmitir y recibir al mismo tiempo.
Los avances en los dispositivos de comunicación inalámbrica GSM, o terminales, han resultado en terminales GSM que pueden recibir múltiples intervalos de tiempo durante las mismos tramas de radio. Estos se denominan "clases multiintervalo" y pueden encontrarse en el Anexo B del TS 45.002 del 3GPP, incorporado en este documento en su totalidad. Por lo tanto, en un sistema basado en GSM, o GPRS, o EDGE existen múltiples intervalos de tiempo fijos disponibles para la transmisión de datos.
Características Multimedia de VBR Datos multimedia de tasa de bits variable (VBR), como el vídeo, suelen incluir características comunes. Por ejemplo, los datos de vídeo son capturados generalmente a una velocidad de trama constante por un sensor, como una cámara. Un transmisor multimedia generalmente requiere un tiempo de procesamiento finito con un límite superior para codificar el flujo de vídeo. Un receptor multimedia generalmente requiere un tiempo de procesamiento finito con un límite superior para descodificar el flujo de vídeo.
Generalmente es deseable reconstruir las tramas multimedia a la misma velocidad de trama a la que se produjeron. Por ejemplo, en el caso del video es deseable visualizar las tramas de vídeo reconstruidas a la misma velocidad a la que se capturó el video en un sensor o cámara. Que la velocidad de captura y reconstrucción sean iguales facilita la sincronización con otros elementos multimedia, por ejemplo, sincronizando un flujo de vídeo con un audio adjunto, o voz, el flujo se simplifica.
En el caso del vídeo, desde el punto de vista de la percepción humana, suele ser deseable mantener un nivel de calidad constante. Es generalmente más molesto y cansado para una persona procesar un flujo multimedia continuo con fluctuaciones en la calidad que procesar un flujo multimedia de calidad constante. Por ejemplo, suele ser molesto para una persona procesar un flujo de vídeo que incluya artefactos de calidad como las imágenes congeladas y el efecto pixelado.
Consideraciones de retardo
El transporte de contenido multimedia, por ejemplo, audio/video por lo general provoca retardos. Algunos de estos retardos se deben a ajustes del códec y algunos se deben a ajustes de red como las transmisiones de protocolo de radioenlace (RLP) que permiten, entre otras cosas, la retransmisión y la reorganización de los paquetes enviados por la interfaz aérea, etc. Una metodología objetiva para evaluar el retardo de las transmisiones multimedia es observar el flujo codificado. Por ejemplo, no puede descodificarse una transmisión hasta haber recibido un paquete completo, descodificable de manera independiente. Por lo tanto, el retardo puede verse afectado por el tamaño de los paquetes y la velocidad de transmisión.
Por ejemplo, si un paquete tiene un tamaño de 64 kbytes, y se transmite por un canal de 64 kbytes por segundo, entonces el paquete no puede descodificarse, y debe retardarse, durante 1 seg hasta que se recibe todo el paquete. Todos los paquetes que se reciben tendrían que ser retardados lo suficiente para adaptar el paquete más grande, de manera que los paquetes puedan descodificarse a una velocidad constante. Por ejemplo, si se transmiten paquetes de video, o de tamaño variable, un receptor tendría que retardar, o almacenar en memoria intermedia, todos los paquetes recibidos en una cantidad igual al retardo necesario para adaptar el mayor tamaño de paquete. El retardo permitiría que el vídeo fuese renderizado, o visualizado, a una velocidad constante. Si el tamaño de paquete máximo no se conoce de antemano entonces pueden hacerse estimaciones del tamaño de paquete máximo, y el retardo asociado, en base a los parámetros utilizados durante la codificación de los paquetes.
La técnica recién descrita puede utilizarse en la evaluación del retardo para cualquier códec de vídeo (H.263, AVC/H.264, MPEG-4, etc.). Además, dado que sólo los descodificadores de vídeo están especificados normativamente por el Grupo de Expertos en Imágenes en Movimiento (MPEG) y la Unión Internacional de Telecomunicaciones (UIT), resulta útil disponer de una medida objetiva que pueda utilizarse para estimar los retardos introducidos por diferentes implementaciones de codificador para móviles en las implementaciones inalámbricas típicas.
En general, los flujos de vídeo tendrán más retardo que otros tipos de datos de servicios multimedia, por ejemplo, más retardo que la voz, el audio, el texto, etc. Debido al mayor retardo experimentado por lo general por un flujo de vídeo, los demás datos multimedia que necesitan estar sincronizados con los datos de vídeo necesitarán habitualmente ser retardados intencionalmente para mantener la sincronización con el vídeo.
Retardos de codificador/descodificador
En algunas técnicas de codificación multimedia, las tramas de datos multimedia se codifican o descodifican utilizando la información de una trama de datos multimedia de referencia anterior. Por ejemplo, los códecs de vídeo que implementan el estándar MPEG-4 codificarán y descodificarán diferentes tipos de tramas de vídeo. En MPEG-4, el video se codifica por lo general en una trama "I" y una trama "P". Una trama I es autónoma, es decir, incluye toda la información necesaria para renderizar, o visualizar, una trama completa de video. Una trama P no es autónoma y por lo general contendrá información diferencial con respecto a la trama anterior, como información de textura diferencial y vectores de movimiento. Por lo general, las tramas I son aproximadamente 8 a 10 veces mayores que una trama P, dependiendo de la configuración del codificador y del contenido. La codificación y la descodificación de datos multimedia introducen retardos que pueden depender de los recursos de procesamiento disponibles. Una implementación típica de este tipo de esquema puede utilizar un memoria intermedia ping-pong para permitir que los recursos de procesamiento visualicen o capturen simultáneamente una trama y procesen otra.
Los codificadores de vídeo como H.263, AVC/H.264, MPEG-4, etc. tienen una velocidad de naturaleza intrínsecamente variable debido a la codificación predictiva y también debido al uso de codificación de longitud variable (VLC) de muchos parámetros. El envío en tiempo real de los flujos de bits de velocidad variable por las redes conmutadas de circuito y las redes conmutadas de paquetes se lleva a cabo generalmente mediante la conformación de tráfico con memorias intermedias en el emisor y el receptor. Las memorias intermedias de conformación de tráfico introducen un retardo adicional que es por lo general indeseable. Por ejemplo, el retardo adicional puede ser molesto durante una teleconferencia cuando hay retardo entre cuando una persona habla y cuando otra persona oye la voz.
Los retardos de codificador y de descodificador pueden afectar a la cantidad de tiempo que tienen los codificadores y los descodificadores para procesar datos multimedia. Por ejemplo, un límite superior en el tiempo permitido para que un codificador y un descodificador procesen los datos y mantengan una velocidad de trama deseada viene dado por:
imagen1
donde ∆e y ∆d representan los retardos de codificador y de descodificador, respectivamente; y ƒ es la velocidad de trama deseada, en tramas por segundo (fps), para un servicio dado.
Por ejemplo, los datos de vídeo por lo general tienen unas velocidades de trama deseadas son 15 fps, 10 fps, ó 7,5 fps. Un límite superior en el tiempo permitido para que un codificador y un descodificador procesen los datos y mantengan la velocidad de trama deseada resulta en unos límites superiores de 66,6 ms, 100 ms y 133 ms respectivamente velocidades de trama de 15 fps, 10 fps, ó 7,5 fps respectivamente.
Retardo de memoria intermedia de control de velocidad
En general, para mantener una calidad perceptual constante de un servicio multimedia, puede requerirse un número diferente de bits para diferentes tramas. Por ejemplo, un códec de vídeo puede necesitar utilizar un número diferente de bytes para codificar una trama I que una trama P para mantener una calidad constante. Por lo tanto, mantener unos resultados de velocidad de trama constante y una calidad constante resulta en que el flujo de vídeo tenga un flujo de tasa de bits variable. La calidad constante en un codificador puede lograrse estableciendo un "parámetro de cuantización" (Qp) de codificador a un valor constante o menos variable alrededor de un destino Qp.
La Figura 4 es un gráfico que ilustra un ejemplo de variación en tamaños de trama para una secuencia de vídeo típica titulada "Carphone". La secuencia Carphone es una secuencia de vídeo estándar, bien conocida por los expertos en la materia, y se utiliza para proporcionar una secuencia de vídeo "común" para su uso en la evaluación de diversas técnicas, como la compresión de vídeo, corrección de errores y transmisión. La Figura 4 muestra un ejemplo de la variación en tamaño de trama, en bytes, para un número de muestra de tramas de datos Carphone codificados utilizando técnicas de codificación AVC/H.264 y MPEG-4 indicadas por las referencias 402 y 404 respectivamente. Puede lograrse una calidad de codificación deseada estableciendo el parámetro codificador "Qp" a un valor deseado. En la Figura 4, los datos Carphone se codifican utilizando un codificador MPEG con un Qp=33 y utilizando un codificador AVC/H.264 con un Qp=33. Cuando los flujos de datos codificados ilustrados en la Figura 4 se van a transmitir por un canal de tasa de bits constante (CBR), como un canal de radio inalámbrico típico, las variaciones en tamaño de trama tendrían que ser "suavizadas" para mantener una tasa de bits QoS constante, o negociada. Por lo general, este "suavizamiento" de las variaciones en tamaño de trama resulta en una introducción de retardo adicional, llamado comúnmente retardo de almacenamiento en memoria intermedia ∆b.
La Figura 5 es un diagrama de bloques que ilustra cómo el retardo de almacenamiento en memoria intermedia puede utilizarse para soportar la transmisión de tramas de diversos tamaños para ser transmitidas por un canal CBR. Como se muestra en la Figura 5, las tramas de datos de tamaño variable 502 entran a la memoria intermedia
504. La memoria intermedia 504 almacenará un número suficiente de tramas de datos para que las tramas de datos que tienen un tamaño constante puedan devolverse desde la memoria intermedia 506 para su transmisión por un canal CBR 508. Una memoria intermedia de este tipo se denomina comúnmente memoria intermedia "cubo agujerado". Una memoria intermedia "cubo agujerado" devuelve datos a una velocidad constante, como un cubo con un agujero en el fondo. Si la velocidad a la que el agua entra en el cubo varía, entonces el cubo debe mantener una cantidad suficiente de agua en el cubo para evitar que el cubo se seque cuando la velocidad del agua que entra al cubo disminuye a menos de la velocidad de la fuga. Asimismo, el cubo debe ser lo suficientemente grande para que el cubo no se desborde cuando la velocidad del agua que entra al cubo sobrepasa la velocidad de la fuga. La memoria intermedia 504 funciona de manera similar al cubo y la cantidad de datos que la memoria intermedia necesita almacenar para evitar el subdesbordamiento de la memoria intermedia resulta en un retardo correspondiente al período de tiempo que los datos permanecen en la memoria intermedia.
Figura 6 es un gráfico que ilustra el retardo de almacenamiento en memoria intermedia introducido por el flujo continuo de un flujo multimedia de tasa de bits variable (VBR) por un canal CBR en el sistema de la Figura 1. Como se ilustra en la Figura 6, se codifica una señal de vídeo utilizando un esquema de codificación VBR, MPEG-4, que produce un flujo VBR. El número de bytes en el flujo VBR se ilustra en la Figura 6 mediante una línea 602que representa el número cumulativo o total de bytes necesarios para transmitir un número dado de tramas de vídeo. En este ejemplo, el flujo MPEG-4 se codifica a una tasa de bits media de 64 kbps y se transmite por un canal CBR de 64 kbps. El número de bytes transmitidos por el canal CBR se representa mediante una línea 604 de pendiente constante correspondiente a la velocidad de transmisión constante de 64 kps.
Para evitar el subdesbordamiento de la memoria intermedia en el descodificador, debido a la recepción insuficiente de datos en el descodificador para permitir la descodificación de una trama de vídeo completa, la visualización, o emisión, 606 en el descodificador debe retardarse. En este ejemplo, el retardo es de 10 tramas, ó 1 segundo, para una velocidad de visualización deseada de 10 fps. En este ejemplo, se utilizó una velocidad constante de 64 kbps para el canal, pero si un flujo MPEG-4 que tiene una velocidad media de datos de 64 kbps es transmitido por un canal CBR de 32 kbps, el retardo de almacenamiento en memoria intermedia aumentaría con la longitud de la secuencia. Por ejemplo, para la secuencia de 50 tramas ilustrada en la Figura 6, el retardo de almacenamiento en memoria intermedia aumentaría a 2 segundos.
En general, el retardo de almacenamiento en memoria intermedia ∆b debido a las limitaciones por subdesbordamiento de la memoria intermedia puede calcularse como sigue:
imagen1
donde:
B(i) = Ocupación de memoria intermedia en el codificador en bytes en el instante i (trama de vídeo #i) R(i) = Salida de codificador en bytes en el instante i (trama de vídeo #i) C(i) = Número de bytes que puede transmitirse en un segundito de trama i ƒ = Número deseado de tramas por segundo BW(i) = Ancho de banda disponible en el instante i
Adviértase que para el caso especial de transmisión CBR,
imagen1
Para evitar el subdesbordamiento de memoria intermedia de descodificador, o inanición de memoria intermedia, durante toda la presentación, la emisión tiene que ser retardada el tiempo necesario para transmitir la ocupación máxima de la memoria intermedia en el codificador. Por lo tanto, el retardo de almacenamiento en memoria intermedia puede representarse como:
imagen1
El denominador en la Ecuación 5 representa la velocidad de datos media para la duración de toda la sesión I. Para una asignación de canal CBR, el denominador es C. Los análisis anteriores también pueden utilizarse para calcular los tamaños nominales de memoria intermedia de codificador necesarios para evitar el desbordamiento en el codificador calculando el max{Be(i)} para todos los i en un conjunto de secuencias ejemplares.
Ejemplo de retardo de memoria intermedia AVC/H.264 y MPEG-4
La Figura 7 es un gráfico de barras que ilustra el retardo de memoria intermedia ∆b en milisegundos, para diversos videoclips de secuencias de 50 tramas codificados con una velocidad nominal de 64 kbps y un Qp constante para AVC/H.264 y MPEG-4. Como se muestra en la Figura 7, la secuencia de tramas MPEG-4 de la Figura 6 se representa mediante una barra 702 que indica un retardo de memoria intermedia de 1000 ms. La misma secuencia de vídeo codificada utilizando AVC/H.264 se representa mediante una barra 704 que indica un retardo de memoria intermedia de 400 ms. Ejemplos adicionales de videoclips de secuencias de 50 tramas se muestran en la Figura 7, donde se indica el retardo de memoria intermedia asociado con cada secuencia, codificada con MPEG-4 y AVC/H.264.
La Figura 8 es un gráfico de barras que ilustra la calidad de vídeo, representada por la relación señal a ruido de pico (PSNR), de las secuencias ilustradas en la Figura 7. Como se muestra en la Figura 8, la secuencia Carphone codificada utilizando MPEG-4 con Qp=15 se representa mediante una barra 802 que indica una PSNR de aproximadamente 28 dB. La misma secuencia codificada utilizando AVC/H.264 con Qp=33 se indica mediante una barra 804 que indica una PSNR de aproximadamente 35 dB.
Retardo de canal de transmisión
El retardo de transmisión ∆t depende del número de retransmisiones utilizadas y cierto tiempo constante para una red dada. Se puede dar por hecho que ∆t tiene un valor nominal cuando no se utilizan retransmisiones. Por ejemplo, se puede dar por hecho que ∆t tiene un valor nominal de 40 ms cuando no se utilizan retransmisiones. Si se utilizan retransmisiones, la tasa de pérdida de tramas (FER) disminuye, pero aumentará el retardo. El retardo dependerá, por lo menos en parte, del número de retransmisiones y retardos suplementarios asociados.
Consideraciones de tolerancia de errores
Al transmitir flujos RTP por un enlace inalámbrico, o canal, habrá generalmente ciertas pérdidas de paquetes residuales porque los flujos RTP son sensibles al retardo y garantizar un 100% de transmisión fiable por medio de un protocolo de retransmisión, como RLP o RLC, no resulta práctico. Más adelante se proporciona una descripción de diversos protocolos, como el protocolo RTP/UDP/IP para ayudar a comprender el efecto de los errores de canal. La Figura 9 es un diagrama que ilustra diversos niveles de encapsulación presentes durante la transmisión de datos multimedia, como datos de vídeo, por un enlace inalámbrico utilizando el protocolo RTP/UDP/IP.
Como se muestra en la Figura 9, un códec de vídeo genera una carga útil, 902 que incluye información que describe una trama de vídeo. La carga útil 902 puede componerse de varios paquetes de video (no mostrados). La carga útil 902 incluye una cabecera de segmento (SH) 904. Por lo tanto, un paquete de datos de capa de aplicación 905 consiste en los datos de vídeo 902 y la cabecera de segmento 904 asociada. Como la carga útil pasa por una red, como Internet, puede añadirse información de cabecera adicional. Por ejemplo, pueden añadirse un cabecera de protocolo en tiempo real (RTP) 906, un cabecera de protocolo de datagramas de usuario (UDP) 908, y una cabecera de protocolo de Internet (IP) 910. Estas cabeceras proporcionan información utilizada para enrutar la carga útil desde su fuente hasta su destino.
Tras entrar en la red inalámbrica, se añade una cabecera de protocolo de punto a punto (PPP) 912 para proporcionar información de sincronización de trama para serializar los paquetes en un flujo de bits continuo. Un protocolo de radioenlace, por ejemplo, RLP en cdma2000 o RLC en WCDMA, empaqueta a continuación la secuencia de bits en paquetes RLP 914. El protocolo de radioenlace permite, entre otras cosas, la retransmisión y la reorganización de los paquetes enviados por la interfaz aérea. Finalmente, la capa MAC de interfaz aérea toma uno
o más paquetes RLP 914, los empaqueta en paquetes de capa MUX 916, y añade una cabecera de multiplexación (MUX) 918. A continuación, un codificador de canal de capa física añade un checksum (CRC) 920 para detectar errores de descodificación, y una parte de cola 922 que forma un paquete de capa física 925.
Las sucesivas encapsulaciones descoordinadas ilustradas en la Figura 9, tienen varias consecuencias en la transmisión de datos multimedia. Una de esas consecuencias es que puede haber un desajuste entre los paquetes de datos de capa de aplicación 905 y los paquetes de capa física 925. Como resultado de este desajuste, cada vez que se pierde un paquete de capa física 925 que contiene partes de uno o más paquetes de capa de aplicación 905, se pierde toda la capa de aplicación correspondiente 905. Dado que pueden incluirse partes de un único paquete de datos de capa de aplicación 905 en más de un paquete de datos de capa física 925, perder un paquete de capa física 925 puede resultar en la pérdida de todo un paquete de capa de aplicación 905 porque todo el paquete de datos de capa de aplicación 905 es necesario para ser descodificado correctamente. Otra consecuencia es que si se incluye parte de más de un paquete de datos de capa de aplicación 905 en un paquete de datos de capa física 925, entonces la pérdida de un único paquete de datos de capa física 925 puede resultar en la pérdida de más de un paquete de datos de capa de aplicación 905.
La Figura 10 es un diagrama que ilustra un ejemplo de asignación convencional de paquetes de datos de aplicación 905 como paquetes de datos multimedia, en paquetes de datos de capa física 925. En la figura 10 se muestran dos paquetes de datos de aplicación 1002 y 1004. Los paquetes de datos de aplicación pueden ser paquetes de datos multimedia, por ejemplo cada paquete de datos 1002 y 1004 puede representar tramas de vídeo. Las encapsulaciones descoordinadas ilustradas en la Figura 10 pueden resultar en un paquete de capa física con datos de un único paquete de datos de aplicación o de más de un paquete de datos de aplicación. Como se muestra en la Figura 10, un primer paquete de datos de capa física 1006 puede incluir datos de un paquete de capa de aplicación única 1002, mientras que un segundo paquete de datos de capa física 1008 puede incluir datos de más de un paquete de datos de aplicación 1002 y 1004. En este ejemplo, si el primer paquete de datos de capa física 1006 se "pierde", o corrompe durante la transmisión, entonces se pierde un único paquete de datos de capa de aplicación 1002. Por otro lado si se pierde el segundo paquete de capa física 1008, entonces también se pierden dos paquetes de datos de aplicación 1002 y 1004.
Por ejemplo, si los paquetes de datos de capa de aplicación son dos tramas de vídeo sucesivas, entonces la pérdida del primer paquete de datos de capa física 1006 resulta en la pérdida de una única trama de vídeo. Pero, la pérdida del segundo paquete de datos de capa física resulta en la pérdida de ambas tramas de vídeo porque si se pierden partes de ambas tramas de vídeo ninguna de las tramas de vídeo puede ser correctamente descodificada, o recuperada, por un descodificador.
Control de tasa de bits explícita (EBR)
El uso de una técnica denominada control de tasa de bits explícita (EBR), más que CBR o VBR, puede mejorar la transmisión de una fuente VBR por un canal CBR. En las EBR las unidades de información se particionan en paquetes de datos de manera que el tamaño de los paquetes de datos coincida con un tamaño disponible de un paquete de capa física. Por ejemplo, un flujo de datos VBR, como datos de vídeo, puede particionarse en paquetes de datos de manera que los paquetes de datos de capa de aplicación coincidan con los paquetes de datos de capa física de un canal de comunicación por el que van a transportarse los datos. Por ejemplo, en EBR un codificador puede ser limitado, o configurado, para devolver bytes en el instante i (anteriormente denominado R(i)) que coincide con "la capacidad" del canal físico utilizado para enviar el flujo de datos en cualquier estándar a través del aire, como GSM, GPRS, EDGE, TIA/EIA-95-B (IS-95), TIA/EIA-98-C (IS-98), cdma2000, CDMA de banda ancha (WCDMA), y otros. Además, los paquetes codificados pueden limitarse de manera que produzcan paquetes de datos dimensionados, es decir, el mismo número de bytes o menos, que el tamaño de los paquetes de datos de capa física del canal de comunicación. Además, puede limitarse el codificador de manera que cada paquete de datos de capa de aplicación que proporciona es descodificable de manera independiente. Las simulaciones de la técnica EBR, sobre un codificador de referencia AVC/H.264, muestran que no existe ninguna pérdida perceptible de calidad cuando se limita el codificador según las técnicas EBR, siempre que se utilice un número adecuado de velocidades explícitas para limitar la codificación VBR. Más adelante se describen ejemplos de limitaciones para algunos canales como ejemplos.
Codificación y descodificación multimedia
Como se ha señalado, los codificadores multimedia, por ejemplo los codificadores de vídeo, pueden generar tramas multimedia de tamaño variable. Por ejemplo, en algunas técnicas de compresión, cada nueva trama multimedia puede incluir toda la información necesaria para renderizar plenamente el contenido de la trama, mientras que otras tramas pueden incluir información sobre los cambios en el contenido de un contenido plenamente renderizado anteriormente. Por ejemplo, como se ha señalado anteriormente, en un sistema basado en técnicas de compresión MPEG-4, las tramas de vídeo pueden ser por lo general de dos tipos: tramas I o P. Las tramas I son autónomas, similares a los archivos JPEG, en que cada trama I contiene toda la información necesaria para renderizar, o visualizar, una trama completa. En contraposición, las tramas P incluyen por lo general información con respecto a la trama anterior, como información diferencial con respecto a los vectores de movimiento y de trama anteriores. Por lo tanto, dado que las tramas P dependen de las tramas anteriores, una trama P no es autónoma, y no puede renderizar o visualizar, una trama completa sin depender de una trama anterior, en otras palabras una trama P no puede auto descodificarse. En este documento, la palabra "descodificada" se utiliza para referirse a la reconstrucción completa para visualizar una trama. Por lo general, las tramas I son más grandes que las tramas, P, por ejemplo, aproximadamente 8 a 10 veces mayores, dependiendo de los ajustes del codificador y del contenido.
En general, cada trama de datos puede particionarse en partes, o "segmentos", de manera que cada segmento pueda ser descodificado de manera independiente, como se describe adicionalmente más adelante. En un caso, una trama de datos puede estar contenida en un único segmento, en otros casos una trama de datos se divide en múltiples segmentos. Por ejemplo, si la trama de datos es información de vídeo, entonces la trama de vídeo puede incluirse dentro de un segmento descodificable de manera independiente, o la trama puede dividirse en más de un segmento descodificable de manera independiente. En una forma de realización, cada segmento codificado se configura de manera que el tamaño del segmento coincida con un tamaño disponible de un paquete de datos de capa física de canal de comunicación. Si el codificador está codificando información de vídeo entonces cada segmento se configura de manera que el tamaño de cada segmento de vídeo coincida con un tamaño disponible de un paquete de capa física. En otras palabras, los tamaños de segmento de trama coinciden con los tamaños de paquete de capa física.
Las ventajas de hacer segmentos de un tamaño que coincida con un tamaño disponible de datos de capa física de canal de comunicación es que hay una correspondencia de uno a uno entre los paquetes de aplicación y los paquetes de datos de capa física. Esto ayuda a aliviar algunos de los problemas asociados con la encapsulación descoordinada como se ilustra en la Figura 10. Por lo tanto, si se corrompe, o pierde, un paquete de datos de capa física durante la transmisión sólo se pierde el segmento correspondiente. Además, si cada segmento de una trama es descodificable de manera independiente, entonces la pérdida de un segmento de una trama no impedirá la
5
10
15
20
25
30
35
40
45
descodificación de los demás segmentos de la trama. Por ejemplo, si una trama de vídeo se divide en cinco segmentos, de manera que cada segmento sea descodificable de manera independiente y coincida con un paquete de datos de capa física, entonces la corrupción, o la pérdida, de uno de los paquetes de datos de capa física resultará en la pérdida de sólo el segmento correspondiente y los paquetes de capa física que se transmitan con éxito pueden ser correctamente descodificados. Por lo tanto, aunque no pueda descodificarse toda la trama de vídeo, partes de la misma sí pueden serlo. En este ejemplo, cuatro de los cinco segmentos de vídeo serán descodificados con éxito, y por lo tanto permitirán que la trama de video sea renderizada, o visualizada, aunque con un menor rendimiento.
Por ejemplo, si los segmentos de vídeo se comunican de un nodo emisor a una MS, en un sistema basado en cdma2000, que utiliza los canales DCCH y SCH entonces los segmentos de video se dimensionarán para que coincidan con estos canales disponibles. Como se ha señalado anteriormente, el canal DCCH puede configurarse para soportar velocidades de datos fijas múltiples. En un sistema basado en cdma2000, por ejemplo, el DCCH puede soportar velocidades de transmisión de datos de 9,60 kbps ó 14,4 kbps dependiendo del conjunto de velocidades seleccionado (RS), RS1 y RS2 respectivamente. El canal SCH también puede configurarse para soportar velocidades de datos fijas múltiples, dependiendo de la configuración de radio SCH (RC). El SCH soporta múltiplos de 9,6 kps cuando se configura en RC3 y múltiplos de 14,4 kps cuando se configura como RC5. Las velocidades de datos SCH son:
imagen1
donde n = 1, 2, 4, 8, ó 16 dependiendo de la configuración de canal.
La tabla 2, a continuación, ilustra los tamaños de paquete de datos de capa física posibles para los canales DCCH y SCH en un sistema de comunicación basado en cdma2000. La primera columna identifica un caso, o configuración posible. Las columnas segunda y tercera son el conjunto de velocidades DCCH y la configuración de radio SCH respectivamente. La cuarta columna tiene cuatro entradas. La primera es el caso dtx en el que no se envían datos en DCCH ni en SCH. La segunda es el tamaño de paquete de datos de capa física de un intervalo de tiempo de 20 ms para el canal DCCH. La tercera entrada es el tamaño de paquete de datos de capa física de un intervalo de tiempo de 20 ms para el canal SCH. La cuarta entrada es el tamaño de paquete de datos de capa física de un intervalo de tiempo de 20 ms para una combinación de los canales DCCH y SCH.
Tabla 2
Tamaños Posibles de Paquete de Capa Física para Combinaciones de DCCH y SCH
Caso
Configuración DCCH Configuración SCH Tamaños de Paquete de capa física (bytes) dtx, DCCH SCH DCCH+SCH
1
RS1 2x en RC3 0, 20, 40, 60
2
RS1 4x en RC3 0, 20, 80, 100
3
RS1 8x en RC3 0, 20, 160, 180
4
RS1 16x en RC3 0, 20, 320 340
5
RS2 2x en RC3 0, 31, 40, 71
6
RS2 4x en RC3 0, 31, 80, 111
7
RS2 8x en RC3 0, 31, 160, 191
8
RS2 16x en RC3 0, 31, 320 351
9
RS1 2x en RC5 0, 20, 64, 84
10
RS1 4x en RC5 0, 20, 128, 148
11
RS1 8x en RC5 0, 20, 256, 276
12
RS1 16x en RC5 0, 20, 512 532
13
RS2 2x en RC5 0, 31, 64, 95
14
RS2 4x en RC5 0, 31, 128, 159
15
RS2 8x en RC5 0, 31, 256, 287
16
RS2 16x en RC5 0, 31, 512 543
Hay que reseñar que existe un compromiso a tener en cuenta cuando un paquete de datos de capa de aplicación es demasiado grande para encajar en los paquetes de datos de capa física DCCH o SCH y en su lugar se va a utilizar un paquete combinado SCH más DCCH. Un compromiso al decidir codificar un paquete de datos de capa de aplicación para que se dimensione para encajar en un tamaño de paquete combinado SCH más DCCH de datos, frente a hacer dos paquetes, es que un paquete más grande de capa de aplicación, o un segmento, produce generalmente una mayor eficiencia de compresión, mientras que los segmentos más pequeños producen generalmente una mayor tolerancia a los errores. Por ejemplo, un segmento más grande requiere generalmente menos sobrecarga. Con referencia a la Figura 9, cada segmento 902 tiene su propia cabecera de segmento 904. Por lo tanto, si se utilizan dos segmentos en lugar de uno, hay dos cabeceras de segmento añadidas a la carga útil, resultando en más datos necesarios para codificar el paquete y reduciendo así la eficiencia de compresión. Por otro lado, si se utilizan dos segmentos, uno transmitido en el DCCH y el otro transmitido en el SCH, entonces la corrupción, o pérdida, de sólo uno de los paquetes de datos DCCH o SCH todavía permitiría la recuperación de los demás paquetes de datos, mejorando así la tolerancia a los errores.
Para ayudar a comprender la Tabla 2 se explicará en detalle la derivación del Caso 1 y 9. En el Caso 1 DCCH se configura como RS1 correspondiente a una velocidad de datos de 9,6 Kbps. Dado que los canales se dividen en intervalos de tiempo de 20 ms, dentro de un intervalo de tiempo individual la cantidad de datos, o el tamaño de paquete de capa física, que puede transmitirse en DCCH configurado como RS1 es:
imagen1
Debido a la sobrecarga adicional que se añade al paquete de capa física, por ejemplo, RLP para la corrección de errores, sólo 20 bytes están disponibles para el paquete de datos de capa de aplicación, que incluye el segmento y la cabecera de segmento. Por lo tanto, la primera entrada en la cuarta columna de la Tabla 2, para el Caso 1 es 20.
El SCH para el Caso 1 en se configura como 2x en RC3. RC3 se corresponde con una velocidad de datos de base de 9,6 Kbps y el 2X significa que la velocidad de datos de canal es dos veces la velocidad de datos de base. Por lo tanto, dentro de un intervalo de tiempo individual la cantidad de datos, o el tamaño de paquete de capa física, que puede transmitirse en SCH configurado 2x RC3 es:
imagen1
En este caso, debido a la sobrecarga adicional que se añade al paquete de capa física, sólo 40 bytes están disponibles para el paquete de datos de capa de aplicación, que incluye el segmento y la cabecera de segmento. Por lo tanto, la segunda entrada en la cuarta columna de la Tabla 2, para el Caso 1 es 40. La tercera entrada en la cuarta columna de la Tabla 2 para el Caso 1 es la suma de las entradas primera y segunda, ó 60.
El Caso 9 es similar al Caso 1. En ambos casos DCCH se configura RS1, correspondiente a un tamaño de paquete de capa física de 20 bytes. El canal SCH en el Caso 9 se configura 2x RC5. RC5 se corresponde con una velocidad de datos de base de 14,4 Kbps y el 2X significa que la velocidad de datos de canal es dos veces la velocidad de datos de base. Por lo tanto, dentro de un intervalo de tiempo individual la cantidad de datos, o el tamaño de paquete de capa física, que puede transmitirse en SCH configurado 2x RC5 es:
imagen1
En este caso, debido a la sobrecarga adicional que se añade al paquete de capa física, sólo 64 bytes están disponibles para el paquete de datos de capa de aplicación, que incluye el segmento y la cabecera del segmento. Por lo tanto, la segunda entrada en la cuarta columna de la Tabla 2, para el Caso 9 es 64. La tercera entrada en la cuarta columna de la Tabla 2 para el Caso 9 es la suma de las entradas primera y segunda, ó 84.
Las demás entradas en la Tabla 2 se determinan de manera similar, donde RS2 se corresponde con DCCH que tiene una velocidad de datos de 14,4 Kbps, correspondiente a 36 bytes dentro de un intervalo de tiempo de 20 mseg del cual 31 están disponibles para la capa de aplicación. Hay que reseñar que la operación dtx está disponible para todos los casos, y que el tamaño de carga útil es cero, donde no se transmiten datos en cualquiera de los canales. Cuando los datos de usuario pueden transmitirse en menos de los intervalos disponibles de capa física (de 20 ms cada uno), dtx se utiliza en los intervalos posteriores, reduciendo la interferencia con otros usuarios en el sistema.
Como se muestra en la Tabla 2 anteriormente indicada, configurando los múltiples canales disponibles de velocidad de datos fija, por ejemplo DCCH y SCH, un conjunto de canales CBR puede comportarse de manera similar a un canal VBR. Es decir, configurar los múltiples canales de velocidad fija puede hacer que un canal CBR se comporte como un canal seudo-VBR. Las técnicas que aprovechan el canal seudo-VBR incluyen determinar los tamaños posibles de paquete de datos de capa física correspondientes a la tasa de bits de un canal CBR a partir de una pluralidad de canales de comunicación disponibles de tasa de bits constante, y codificar un flujo de tasa de bits variable de datos creando así una pluralidad de paquetes de datos de manera que un tamaño de cada uno de los paquetes de datos coincida con un tamaño de uno de los tamaños de paquete de datos de capa física.
En una forma de realización, la configuración de los canales de comunicación se establece al comienzo de una sesión y, a continuación, no se cambia a lo largo de la sesión o sólo se cambia con poca frecuencia. Por ejemplo, el SCH analizado en el ejemplo anterior se establece generalmente en una configuración y permanece en esa configuración a lo largo de toda la sesión. Es decir, el SCH descrito es un SCH de velocidad fija. En otra forma de realización, la configuración del canal puede cambiarse dinámicamente durante la sesión. Por ejemplo un SCH de velocidad variable (V-SCH) puede cambiar su configuración para cada intervalo de tiempo. Es decir, durante un intervalo de tiempo un V-SCH puede configurarse en una configuración, como 2x RC3, y en el siguiente intervalo de tiempo el V-SCH puede configurarse en una configuración diferente, como 16xRC3 o cualquier otra configuración posible de V-SCH. Un V-SCH proporciona flexibilidad adicional, y puede mejorar el rendimiento del sistema en las técnicas EBR.
Si la configuración del canal de comunicación es fija para toda la sesión, entonces los segmentos o paquetes de capa de aplicación se seleccionan para que encajen en uno de los paquetes disponibles de datos de capa física que están disponibles. Por ejemplo, si el DCCH y el SCH se configuran como RS1 y 2xRC3, como se ilustra en el Caso 1 en la Tabla 2, entonces los segmentos de capa de aplicación se seleccionarían para encajar en paquetes de 0 bytes, 20 bytes, 40 bytes, ó 60 bytes. Asimismo, si los canales se configurasen como RS1 y 16xRC3, como se ilustra en el Caso 4 de la Tabla 2, entonces los segmentos de capa de aplicación se seleccionarían para encajar en paquetes de 0 bytes, 20 bytes, 320 bytes, ó 340 bytes. Si se utilizase un canal V-SCH entonces es posible cambiar entre dos configuraciones diferentes para cada segmento. Por ejemplo, si el DCCH se configura como RS1 y el V-SCH se configura como RC3, entonces es posible cambiar entre cualquiera de las configuraciones de V-SCH 2xRC3, 4xRC3, 8xRC3, ó 16xRC3, correspondientes a los Casos 1-4 de la Tabla 2. La selección entre estas diversas configuraciones proporciona paquetes de datos de capa física de 0 bytes, 20 bytes, 40 bytes, 60 bytes, 80 bytes, 100 bytes, 160 bytes, 180 bytes, 320 bytes, ó 340 bytes como se ilustra en los Casos 1-4 de la Tabla 2. Por lo tanto, en este ejemplo, la utilización de un canal V-SCH permite seleccionar segmentos de capa de aplicación para que encajen en cualquiera de los diez tamaños diferentes de paquete de datos de capa física enumerados en los Casos 1-4 de la Tabla 2. En el caso de cdma2000, el tamaño de los datos enviados es estimado por la MS y este proceso se denomina "detección ciega".
Puede utilizarse una técnica similar en el CDMA de banda ancha (WCDMA) utilizando un canal de datos (DCH). El DCH, de manera similar a V-SCH, soporta tamaños diferentes de paquete de capa física. Por ejemplo, el DCH puede soportar velocidades de 0 a nx en múltiplos de 40 octetos, donde 'nx' se corresponde con la velocidad asignada máxima o el canal DCH. Los valores típicos de nx incluyen 64 kbps, 128 kbps y 256 kbps. En una técnica denominada "indicación explícita" puede indicarse el tamaño de los datos enviados utilizando una señalización adicional, eliminando así la necesidad de la detección ciega. Por ejemplo, en el caso de WCDMA, el tamaño de los paquetes de datos enviados puede indicarse utilizando el "indicador de combinación de formato de transporte" (TFCI), de manera que la MS no tenga que hacer la detección ciega, reduciendo así la carga computacional en la MS, cuando se utilizan paquetes de diferentes tamaños como en EBR. Los conceptos EBR descritos son aplicables a la detección ciega y la indicación explícita de los tamaños de paquete.
Seleccionando los paquetes de datos de capa de aplicación de manera que encajen en los paquetes de datos de capa física, una combinación de canales de comunicación de tasa de bits constante, con sus velocidades de datos total, puede transmitir un flujo de datos VBR con un rendimiento similar a, y en algunos casos superior a, un canal de comunicación VBR. En una forma de realización, un flujo de datos de tasa de bits variable se codifica en un flujo de paquetes de datos que son de un tamaño que coincide con el tamaño de paquete de datos de capa física de los canales de comunicación disponibles, y a continuación se transmite por una combinación de canales de tasa de bits constante. En otra forma de realización, a medida que varía la tasa de bits del flujo de datos de tasa de bits variable éste puede codificarse en paquetes de datos de tamaño diferente y pueden utilizarse diferentes combinaciones de canales de tasa de bits constante para transmitir los paquetes de datos.
Por ejemplo, diferentes tramas de datos de vídeo pueden tener tamaños diferentes y por lo tanto, pueden seleccionarse diferentes combinaciones de canales de comunicación de tasa de bits fija para adaptar la transmisión de las tramas de vídeo de diferente tamaño. En otras palabras, los datos de tasa de bits variable pueden transmitirse de manera eficaz por un canal de tasa de bits constante asignando los paquetes de datos a por lo menos uno de los canales de comunicación de tasa de bits constante para hacer coincidir la tasa de bits total de los canales de comunicación de tasa de bits constante con la tasa de bits del flujo de tasa de bits variable.
Otro aspecto es que el codificador puede limitarse para limitar el número total de bits utilizado para representar el flujo de datos de tasa de bits variable a un número de bits máximo preseleccionado. Es decir, si el flujo de datos de tasa de bits variable es una trama de datos multimedia, como vídeo, la trama puede dividirse en segmentos donde los segmentos se seleccionan de manera que cada segmento pueda descodificarse de manera independiente y el número de bits en el segmento se limita a un número preseleccionado de bits. Por ejemplo, si los canales DCCH y SCH se configuran RS1 y 2xRC3 respectivamente (Caso 1 en la Tabla 2) entonces el codificador puede limitarse de manera que un segmento no sea mayor que cualquiera de 20 bytes, 40bytes ó 60 bytes.
En otra forma de realización la utilización del EBR para transmitir datos multimedia puede utilizar el canal de datos por paquetes cdma2000 (PDCH). El PDCH puede configurarse para transmitir paquetes de datos que sean n*45 bytes, donde n={1,2,4,8}. Nuevamente, utilizando el PDCH para los datos multimedia, por ejemplo datos de vídeo, puede particionarse en "segmentos" que coincidan con los tamaños disponibles de paquete de capa física. En
5
15
25
35
45
55
cdma2000, el PDCH tiene diferentes velocidades de datos disponibles del PDCH directo (F-PDCH) y el PDCH reverso (R-PDCH). En cdma2000 el F-PDCH tiene ligeramente menos ancho de banda disponible que el R-PDCH. Aunque esta diferencia de ancho de banda puede ser aprovechada, en algunos casos resulta ventajoso limitar el R-PDCH al mismo ancho de banda que el F-PDCH. Por ejemplo, si una primera MS transmite un flujo de vídeo a una segunda MS, el flujo de vídeo será transmitido por la primera MS en el R-PDCH y recibido por la segunda MS en el F-PDCH. Si la primera MS utilizase todo el ancho de banda del R-PDCH entonces tendrían que eliminarse algunos de los flujos de datos para que se ajustase al ancho de banda de la transmisión F-PDCH a la segunda MS. Para mitigar las dificultades asociadas con el reformateado de la transmisión desde la primera MS de manera que pueda transmitirse a la segunda MS en un canal con un ancho de banda menor, el ancho de banda del R-PDCH puede limitarse de manera que sea el mismo que el F-PDCH. Una forma de limitar el ancho de banda F-PDCH es limitar los tamaños de paquete de datos de aplicación enviados en el R-PDCH a los soportados por el F-PDCH y a continuación añadir "bits de relleno" para los bits restantes en el paquete de capa física R-PDCH. En otras palabras, si los bits de relleno se añaden a los paquetes de datos R-PDCH para que coincidan con los paquetes de datos F-PDCH, entonces los paquetes de datos R-PDCH pueden utilizarse en el enlace directo F-PDCH con cambios mínimos, por ejemplo, con sólo descartar los bits de relleno.
Utilizando la técnica que se acaba de describir, la Tabla 3 enumera los tamaños posibles de paquete de datos de capa física para el F-PDCH y el R-PDCH para cuatro casos posibles de velocidades de datos, uno para cada valor de n, y el número de "bits de relleno" que se añadirá al R-PDCH.
Tabla 3
n Tamaño de Paquete de capa física (bytes) F-PDCH y R-PDCH Bits de relleno R-PDCH 1 45 0 2 90 24 4 180 72
8 360 168
Tamaños Posibles de Paquete de capa física para PDCH y “Bits de Relleno” para R-PDCH
Como con EBR que utiliza DCCH más SCH, cuando un flujo multimedia, como un flujo de vídeo, es particionado en segmentos, los tamaños de segmento menores generalmente mejoran la tolerancia a los errores, pero pueden comprometer la eficacia de compresión. Asimismo, si se utilizan segmentos mayores, en general, habrá un aumento en la eficiencia de compresión, pero el rendimiento de sistema puede degradarse debido a los paquetes perdidos debido a que la pérdida de un paquete individual resulta en la pérdida de más datos.
Asimismo, pueden llevarse a cabo técnicas de ajuste de datos multimedia, como segmentos de vídeo, a un tamaño disponible de un paquete de capa física en sistemas basados en otros estándares a través del aire. Por ejemplo, en un sistema basado en GSM o GPRS, o EDGE las tramas multimedia, como los segmentos de vídeo, pueden dimensionarse para que coincidan con los intervalos de tiempo disponibles. Como se ha señalado anteriormente, muchos dispositivos GSM, GPRS y EDGE son capaces de recibir múltiples intervalos de tiempo. Por lo tanto, dependiendo del número disponible de intervalos de tiempo, un flujo codificado de tramas puede limitarse de manera que los segmentos de vídeo coincidan con los paquetes físicos. En otras palabras, los datos multimedia pueden codificarse de manera que los tamaños de paquete coincidan con un tamaño disponible de un paquete de capa física, como el intervalo de tiempo GSM, y la velocidad de datos total de los paquetes utilizados de capa física soporte la velocidad de datos de los datos multimedia.
Consideraciones de rendimiento EBR
Como se ha señalado, cuando un codificador de flujos de datos multimedia opera en un modo EBR genera segmentos multimedia ajustados a la capa física, y por lo tanto no hay pérdida de la eficiencia de compresión en comparación con un modo VBR verdadero. Por ejemplo, un códec de vídeo que opera según la técnica EBR genera segmentos de vídeo ajustados a la capa física concreta por la que se transmite el video. Además, hay beneficios con respecto a la tolerancia a los errores, baja latencia, y menor sobrecarga de transmisión. Los detalles de estos beneficios se explican adicionalmente más adelante.
Rendimiento en errores de canal
Como se ha analizado en referencia a la Figura 10, puede observarse que en una encapsulación convencional, cuando se pierde un paquete de capa física, puede perderse más de una capa de aplicación. En la técnica EBR, cada pérdida de paquete físico en el enlace inalámbrico resulta en la pérdida de exactamente un paquete de datos de aplicación.
La Figura 11 ilustra un ejemplo de codificación de paquetes de capa de aplicación según la técnica EBR. Como se ha señalado anteriormente, los paquetes de capa de aplicación pueden ser de diversos tamaños. Como se ha analizado en las Tablas 2 y 3, los paquetes de capa física también pueden ser de diversos tamaños, por ejemplo, la capa física puede componerse de canales que utilizan tamaños diferentes de paquetes de datos de capa física. En el ejemplo de la Figura 11, se ilustran cuatro paquetes de aplicación 1102, 1104, 1106, y 1108 y cuatro paquetes de capa física 1110, 1112, 1114, y 1116. Se ilustran tres ejemplos diferentes de ajuste de los paquetes de capa de aplicación a los paquetes de capa física. En primer lugar, puede codificarse un único paquete de capa de aplicación de manera que se transmita dentro de múltiples paquetes de capa física. En el ejemplo mostrado en la Figura 11, un único paquete de capa física 1102 se codifica en dos paquetes de capa física 1110 y 1112. Por ejemplo, si DCCH y SCH se configuran RS1 y 2xRC3 respectivamente (Caso 1 en la Tabla 2) y el paquete de datos de aplicación es 60 bytes, entonces podría transmitirse por los dos paquetes de capa física correspondientes a la combinación de paquetes DCCH y SCH. Se prevé que un único paquete de capa de aplicación pueda codificarse en cualquier número de paquetes de capa física correspondientes a los canales de comunicación disponibles. Un segundo ejemplo mostrado en la Figura 11 es que un único paquete de capa de aplicación 1104 se codifique en un único paquete de capa física 1114. Por ejemplo, si el paquete de datos de capa de aplicación es 40 bytes, podría transmitirse utilizando sólo el paquete de datos de capa física SCH en el Caso 1 de la Tabla 2. En estos dos ejemplos la pérdida de un único paquete de capa física resulta en la pérdida de sólo un único paquete de capa de aplicación.
Un tercer ejemplo ilustrado en la Figura 11 es que pueden codificarse múltiples paquetes de capa de aplicación en un único paquete de capa física 1116. En el ejemplo mostrado en la Figura 11, dos capas de aplicación 1106 y 1108 se codifican y transmiten en un único paquete de capa física. Se prevé que puedan codificarse más de dos paquetes de capa de aplicación para encajar en un único paquete de capa física. Un inconveniente de este ejemplo es que la pérdida de un único paquete de capa física 1116 resultaría en la pérdida de múltiples paquetes de capa de aplicación 1106 y 1108. Sin embargo, puede haber compromisos, como la plena utilización de capa física, que garantizaría la codificación de múltiples paquetes de capa de aplicación a transmitir dentro de un único paquete de capa física.
La Figura 12 es un diagrama de bloques que ilustra una forma de realización de un códec que transmite una flujo de datos VBR a través de una red IP/UDP/RTP, como Internet. Como se muestra en la Figura 12 el códec genera un paquete de datos de capa de aplicación 1202 que incluye una carga útil, o segmento, 1204 y una cabecera de segmento 1206. La capa de aplicación 1202 pasa por la red donde se adjunta la información de cabecera IP/UDP/RTP 1208 al paquete de datos de capa de aplicación 1202. A continuación el paquete pasa por la red inalámbrica donde una cabecera RLP 1210 y una cabecera MUX 1212 se adjuntan al paquete. Dado que se conoce el tamaño de la cabecera IP/UDP/RTP 1208, la cabecera RLP 1210, y la cabecera MUX 1214, el códec selecciona un tamaño para el segmento 1204 de manera que el segmento y todas las cabeceras asociadas encajen en el paquete de datos de capa física, o carga útil, 1216.
La Figura 13 es un gráfico de barras que ilustra la disminución relativa de la relación señal a ruido de pico (PSNR) para diversos ejemplos de secuencias de vídeo codificadas, utilizando un canal de transmisión VBR verdadero, y utilizando una transmisión EBR que utiliza DCCH más SCH, y PDCH, cuando la pérdida de paquete de canal es del 1%. Las secuencias de vídeo ilustradas en la Figura 13 son secuencias de vídeo estándares, que son bien conocidas por los expertos en la materia, y se utilizan para proporcionar secuencias de vídeo "comunes" para su uso en la evaluación de diversas técnicas, como la compresión de vídeo, transmisión y corrección de errores. Como se muestra en la Figura 13, las secuencias VBR verdadero 1302 tienen la mayor disminución PSNR seguida del EBR que utiliza PDCH 1306 y entonces el EBR que utiliza DCCH más SCH 1304. Por ejemplo, en la secuencia de Carphone la secuencia VBR verdadera 1302 sufría aproximadamente una disminución de 1,5 dB en PSNR, mientras que el EBR que utiliza PDCH 1306 y el EBR que utiliza DCCH y SCH 1304 sufrieron unas disminuciones en PSNR de aproximadamente 0,8 y 0,4 dB respectivamente. La Figura 13 ilustra que cuando un canal de transmisión experimenta una pérdida de paquete del 1% la distorsión, medida mediante PSNR, para la secuencia VBR es más grave que para las secuencias EBR.
La Figura 14, similar a la Figura 13, es un gráfico de barras que ilustra la disminución relativa de la relación señal a ruido de pico (PSNR) cuando la pérdida de canal es del 5% para diversos ejemplos de secuencias de vídeo codificadas estándares, que utilizan un VBR verdadero 1402, EBR que utiliza DCCH más SCH 1404, y EBR que utiliza PDCH 1406. Como se muestra en la Figura 14, las secuencias VBR verdadero 1402 tienen la mayor disminución PSNR seguidas por el EBR que utiliza PDCH 1406 y a continuación el EBR que utiliza DCCH más SCH 1404. Por ejemplo, en la secuencia de Carphone la secuencia VBR verdadero 1402 sufría aproximadamente una disminución de 2,5 dB en PSNR, mientras el EBR que utiliza PDCH 1406 y el EBR que utiliza DCCH más SCH 1404 sufrían unas disminuciones en PSNR de aproximadamente 1,4 y 0,8 dB respectivamente. Comparando las Figuras 14 y 13 ilustran que cuando a medida que la pérdida de paquete de canal de transmisión aumenta la distorsión, medida mediante PSNR, es más grave para la secuencia VBR que para las secuencias EBR.
La Figura 15 es un gráfico de barras que ilustra el porcentaje de macrobloque defectuoso recibido para las secuencias de vídeo codificadas de la Figura 13, que utiliza VBR verdadero 1502, EBR que utiliza DCCH y SCH 1504, y EBR que utiliza PDCH 1506, cuando la pérdida de paquete de canal es del 1%. La Figura 16 es un gráfico de barras que ilustra el porcentaje de macrobloques defectuosos recibidos para las secuencias de vídeo codificadas de la Figura 14, que utiliza VBR verdadero 1602, EBR que utiliza DCCH y SCH 1604, y EBR que utiliza PDCH 1606, cuando la pérdida de paquete de canal es del 5%. La comparación de estos gráficos muestra que en ambos casos el porcentaje de macrobloques defectuosos es mayor en las secuencias VBR que en las secuencias EBR. Hay que reseñar que en EBR, dado que los segmentos coinciden con el tamaño de paquete de capa física, el porcentaje defectuoso de segmentos debe ser el mismo que la velocidad de pérdida de paquete. Sin embargo, dado que los segmentos pueden incluir diferentes números de macrobloques, la pérdida de un paquete de datos, correspondiente a un segmento, puede resultar en un número diferente de macrobloques defectuoso que la pérdida de un paquete de datos diferente correspondiente a un segmento diferente que incluye un número diferente de macrobloques.
La Figura 17 es un gráfico que ilustra la distorsión de la velocidad de una de las secuencias de vídeo codificadas estándar, titulada "Foreman." Como se muestra en la Figura 17, se ilustran cuatro casos diferentes que ilustran el PSNR frente a la tasa de bits. Los dos primeros casos muestran la secuencia de vídeo codificada que utiliza VBR 1702 y 1704. Los dos casos siguientes muestran la secuencia de vídeo codificada que utiliza EBR15, donde EBR15 es EBR que utiliza DCCH más SCH configurado como RS2 y 8x en RC5 respectivamente, como se enumera en el caso 15 en la Tabla 2 anteriormente indicada. Los flujos de datos VBR y EBR se transmiten por un canal "limpio" 1702 y 1706 y un canal "ruidoso" 1704 y 1708. Como se ha señalado anteriormente, en un canal limpio no hay ningún paquete perdido durante la transmisión, y un canal ruidoso pierde un 1% de los paquetes de datos. Como se muestra en la Figura 17 la secuencia codificada VBR que se transmite por un canal limpio 1702, tiene el PSNR más alto para todas las tasas de bits. Pero la secuencia codificada EBR15 que se transmite por un canal limpio 1706 tiene casi el mismo rendimiento PSNR, o distorsión de la velocidad, para todas las tasas de bits. Por lo tanto, hay una disminución muy pequeña del rendimiento entre la codificación VBR y EBR 15 cuando el canal de transmisión es limpio. Este ejemplo ilustra que cuando no hay ningún paquete perdido durante la transmisión puede haber suficiente granularidad en una configuración de codificación EBR para tener un rendimiento casi igual a una configuración de codificación VBR verdadero.
Cuando la secuencia codificada VBR se transmite por un canal ruidoso 1704 el PSNR disminuye significativamente, más de 3 dB, por todas las tasas de bits. Pero, cuando la secuencia codificada EBR15 se transmite por el mismo canal ruidoso 1708, aunque su rendimiento PSNR se degrada por todas las tasas de bits, su rendimiento sólo disminuye aproximadamente 1 dB. Por lo tanto, cuando se transmite por un canal ruidoso el rendimiento PSNR de una secuencia codificada EBR15 es aproximadamente 2 dB mayor que una secuencia codificada VBR transmitida por el mismo canal ruidoso. Como muestra la Figura 17, en un canal limpio el rendimiento de distorsión de velocidad de la codificación EBR15 es comparable a la codificación VBR, y cuando el canal se vuelve ruidoso el rendimiento de distorsión de velocidad de la codificación EBR15 es superior a la codificación VBR.
La Figura 18 es un gráfico, similar a la Figura 17, que ilustra las curvas de distorsión de velocidad de otras secuencias de vídeo codificadas, titulado "Carphone". Nuevamente, se ilustran cuatro casos diferentes que muestran el PSNR frente a la tasa de bits. Los dos primeros casos muestran la secuencia de vídeo codificada que utiliza VBR 1802 y 1804. Los dos casos siguientes muestran la secuencia de vídeo codificada que utiliza EBR15, donde EBR15 es EBR que utiliza DCCH más VSCH configurado como RS2 y 8x en RC5 respectivamente, como se enumera en el caso 15 en la Tabla 2 anteriormente indicada. Los flujos de datos VBR y EBR se transmiten por un canal "limpio" 1802 y 1806, y un canal "ruidoso" 1804 y 1808. En este ejemplo, el rendimiento PSNR de la secuencia codificada EBR15 transmitida por un canal limpio 1806 supera el rendimiento de la secuencia VBR por el canal limpio 1802. El rendimiento PSNR de la secuencia EBR15 por el canal ruidoso 1808 supera la secuencia VBR transmitida por el canal ruidoso 1804 en aproximadamente 1,5 dB. En este ejemplo, la utilización de la secuencia Carphone en un canal limpio y uno ruidoso resultó en que el rendimiento de distorsión de velocidad de la codificación EBR15 tuvo un rendimiento superior, medido mediante PSNR, que la codificación VBR.
Consideraciones de latencia
El uso de la codificación EBR mejora el rendimiento de latencia. Por ejemplo, utilizando segmentos EBR pueden transmitirse segmentos de video por un canal inalámbrico sin memorias intermedias de conformación de tráfico en el codificador y el descodificador. Para los servicios en tiempo real esto supone un beneficio significativo ya que puede mejorarse la experiencia de usuario global.
Para ilustrar el retardo de almacenamiento en memoria intermedia debido a la naturaleza de tasa de bits variable (VBR) de la codificación de vídeo, téngase en cuenta un plan de transmisión para una secuencia típica codificada a una tasa de bits media de 64 kbps y transmitida por un canal CBR de 64 kbps, mostrado en la Figura 6. Para evitar el subdesbordamiento de memoria intermedia en el descodificador, la visualización, representada por la curva 608, debe ser retardada. En este ejemplo, el retardo es de 10 tramas ó 1 segundo para una velocidad de visualización deseada de 10 fps.
El retardo ∆b debido a limitaciones de subdesbordamiento de memoria intermedia puede calcularse como sigue: donde
imagen1
imagen1
B(i) = Ocupación de memoria intermedia en el codificador en bytes en la trama i R(i) = Salida de codificador en bytes para la trama i C(i) = nº de bytes que pueden transmitirse en el intervalo de trama i ƒ = Número deseado de tramas por segundo BW(i) = Ancho de banda disponible en bits en un intervalo de trama i
.i
׊ C=C(i)Adviértase que para el caso especial de transmisión CBR,
Para evitar la inanición de memoria intermedia de descodificador durante toda la presentación, la reproducción debe retardarse el tiempo necesario para transmitir la ocupación de memoria intermedia máxima en el codificador.
imagen2
ningún retardo de almacenamiento en memoria intermedia. Entonces, se deduce que la ocupación de memoria intermedia en el codificador es 0, ya que los datos pueden transmitirse a medida que llegan. Es decir,
imagen1
Adviértase que las tramas de vídeo por lo general abarcan múltiples tramas de capa MAC K (intervalos). Si es posible variar C(i) por los intervalos K de manera que puedan transmitirse todos los R(i), entonces el retardo ∆b debido al almacenamiento en memoria intermedia es 0, ya que B(i) es 0.
imagen1
La Figura 19 ilustra el ejemplo de transmisión para una secuencia EBR típica codificada a una velocidad media de 64 kbps. En la Figura 19 se muestran los bytes cumulativos frente al número de tramas para la fuente 1902, la transmisión 1904 y la visualización 1906 de un flujo multimedia. En el ejemplo de la Figura 19, el retardo de almacenamiento en memoria intermedia es 0, pero los retardos debidos a la codificación, descodificación y transmisión están todavía presentes. Sin embargo, estos retardos son por lo general mucho menores en comparación con el retardo de almacenamiento en memoria intermedia VBR.
La Figura 20 es un diagrama de flujo que ilustra una forma de realización de un procedimiento de transmisión de datos. El flujo comienza en el bloque 2002. A continuación el flujo continúa al bloque 2004. En el bloque 2004 se determinan los tamaños posibles de paquete de capa física de los canales de comunicación disponibles. Por ejemplo, si se utilizan los canales DCCH y SCH entonces la configuración de estos canales de radio establecerá los tamaños disponibles de paquete de capa física, como se ilustra en la Tabla 2, anteriormente indicada. A continuación el flujo continúa al bloque 2006 donde se recibe una unidad de información, por ejemplo una trama de un flujo de datos de tasa de bits variable. Ejemplos de los flujos de datos de tasa de bits variable incluyen un flujo multimedia, como una secuencia de vídeo. A continuación el flujo continúa al bloque 2008.
En el bloque 2008 las unidades de información se particionan en segmentos. Las particiones, o segmentos, se seleccionan de manera que su tamaño no supere el tamaño de uno de los tamaños posibles de paquete de capa física. Por ejemplo, las particiones pueden dimensionarse de manera que cada tamaño de la partición no sea mayor que por lo menos uno de tamaños disponibles de los paquetes de capa física. A continuación el flujo continúa al bloque 2010 donde la partición se codifica y se asigna a un paquete de capa física. Por ejemplo, la codificación de información puede incluir un codificador fuente equipado con un módulo de control de velocidad capaz de generar particiones de tamaño variable. A continuación, en el bloque 2012 se determina si todas las particiones de la trama han sido codificadas y asignadas a un paquete de capa física. Si no lo han sido, un resultado negativo en el bloque 2012, entonces el flujo continúa al bloque 2010 y la siguiente partición se codifica y se asigna a un paquete de capa física. Volviendo al bloque 2012, si todas las particiones de la trama han sido codificadas y asignadas a un paquete de capa física, un resultado afirmativo en el bloque 2012, entonces el flujo continúa al bloque 2014.
En el bloque 2014 se determina si el flujo de información ha terminado, como al final de una sesión. Si el flujo de información no ha terminado, un resultado negativo en el bloque 2014, el flujo continúa al bloque 2006 y se recibe la siguiente unidad de información. Volviendo al bloque 2014, si el flujo de información ha finalizado, como el final de una sesión, un resultado afirmativo en 2014, entonces el flujo continúa al bloque 2016 y el proceso se detiene.
La Figura 21 es un diagrama de flujo que ilustra otra forma de realización de un procedimiento de transmisión de datos. El flujo comienza en el bloque 2102. A continuación el flujo continúa al bloque 2104. En el bloque 2104 se determinan los tamaños posibles de paquete de capa física de los canales de comunicación disponibles. Por ejemplo, si se utilizan los canales DCCH y SCH, entonces la configuración de estos canales de radio establecerá los tamaños disponibles de paquete de capa física, como se ilustra en la Tabla 2, anteriormente indicada. A continuación el flujo continúa al bloque 2106 donde se recibe una unidad de información. Por ejemplo, la unidad de información puede ser datos de tasa de bits variable como un flujo multimedia, o un flujo de vídeo. A continuación el flujo continúa al bloque 2108.
En el bloque 2108 se determina si es deseable reconfigurar la configuración de los canales de comunicación. Si se está utilizando un canal de comunicación que puede reconfigurarse durante una sesión, como un canal V-SCH, puede ser deseable cambiar la configuración del canal durante una sesión. Por ejemplo, si las tramas de datos que tienen más datos de los que pueden ser transmitidos por la configuración actual de los canales de comunicación puede ser deseable cambiar la configuración a un ancho de banda mayor de manera que el canal de comunicación pueda soportar más datos. En el bloque 2108 si se decide que no se desea reconfigurar los canales de comunicación, un resultado negativo en el bloque 2108, el flujo continúa al bloque 2110. En el bloque 2110 la unidad de información se particiona en tamaños de manera que su tamaño no supere el tamaño de uno de los tamaños posibles de paquete de capa física. Volviendo al bloque 2108, si se determina que se desea reconfigurar el canal de comunicación, un resultado afirmativo en el bloque 2108, el flujo continúa al bloque 2112. En el bloque 2112 se determina un tamaño deseado de paquete de capa física. Por ejemplo, puede analizarse la unidad de información recibida y puede determinarse el tamaño de un paquete de datos necesario para transmitir toda la unidad. A continuación el flujo continúa al bloque 2114. En el bloque 2114 se determina una configuración de canal de comunicación deseada. Por ejemplo, pueden determinarse los diversos tamaños de paquete de capa física de diferentes configuraciones de los canales de comunicación disponibles y puede seleccionarse una configuración que tenga paquetes de capa física que sean lo suficientemente grandes como para adaptar la unidad de información. A continuación se reconfiguran los canales de comunicación como corresponda. A continuación el flujo continúa al bloque 2110 donde la unidad de información se divide en tamaños de manera que su tamaño coincida con el tamaño de uno de los tamaños posibles de paquete de capa física de los canales de comunicación reconfigurados. A continuación el flujo continúa al bloque 2116. En el bloque 2116 la partición se codifica y se asigna a un paquete de datos de capa física. Por ejemplo, la información de codificación puede incluir un codificador fuente equipado con un módulo de velocidad controlada capaz de generar particiones de tamaño variable. A continuación el flujo continúa al bloque 2118.
En el bloque 2118 se determina si todas las particiones de la unidad de información han sido codificadas y asignadas a un paquete de capa física. Si no lo han sido, un resultado negativo en el bloque 2118, entonces el flujo continúa al bloque 2110 y la siguiente partición se codifica y se asigna a un paquete de capa física. Volviendo al bloque 2118, si todas las particiones de la unidad de información han sido codificadas y asignadas a un paquete de capa física, un resultado afirmativo en el bloque 2118, entonces el flujo continúa al bloque 2120.
En el bloque 2120 se determina si el flujo de información ha terminado, como al final de una sesión. Si el flujo de información no ha terminado, un resultado negativo en el bloque 2120, entonces el flujo continúa al bloque 2106 y se recibe la siguiente unidad de información. Volviendo al bloque 2120, si ha terminado el flujo de información, un resultado afirmativo en el bloque 2120, entonces el flujo continúa al bloque 2122 y el proceso se detiene.
La Figura 22 es un diagrama de bloques de un dispositivo de comunicación inalámbrica, o una estación móvil (MS), construido según una forma de realización de ejemplo de la presente invención. El dispositivo de comunicación 2202 incluye una interfaz de red 2206, un códec 2208, un procesador central 2210, un dispositivo de memoria 2212, un producto de programa 2214, y una interfaz de usuario 2216.
Las señales desde la infraestructura son recibidas por la interfaz de red 2206 y enviadas al procesador central 2210. El procesador central 2210 recibe las señales y, dependiendo del contenido de la señal, responde con las acciones apropiadas. Por ejemplo, el procesador central 2210 puede descodificar la señal recibida por sí mismo, o puede enrutar la señal recibida al códec 2208 para la descodificación. En otra forma de realización, la señal recibida se envía directamente al códec 2208 desde la interfaz de red 2206.
En una forma de realización, la interfaz de red 2206 puede ser un transceptor y una antena para interconectarse a la infraestructura por un canal inalámbrico. En otra forma de realización, la interfaz de red 2206 puede ser una tarjeta de interfaz de red utilizada para interconectarse a la infraestructura por líneas telefónicas fijas. El códec 2208 puede implementarse como un procesador digital de señal (DSP), o un procesador general como una unidad de procesamiento central (CPU).
Tanto el procesador central 2210 como el códec 2208 se conectan a un dispositivo de memoria 2212. El dispositivo de memoria 2212 puede utilizarse para almacenar datos durante la operación del WCD, así como para almacenar el código de programa que será ejecutado por el procesador central 2210 o el DSP 2208. Por ejemplo, el procesador central, el códec, o ambos, pueden operar bajo el control de instrucciones de programación que se almacenan temporalmente en el dispositivo de memoria 2212. El procesador central 2210 y el códec 2208 también pueden incluir una memoria de almacenamiento de programa propia. Cuando se ejecutan las instrucciones de programación, el procesador central 2210 o el códec 2208, o ambos, llevan a cabo sus funciones, por ejemplo la descodificación o codificación de flujos multimedia. Por lo tanto, las etapas de programación implementan la funcionalidad del códec 2208 y el procesador central 2210 respectivo, de manera que pueda hacerse que el procesador central y el códec lleven a cabo las funciones de descodificación o codificación de flujos de contenido como se desee. Las etapas de programación pueden recibirse de un producto de programa 2214. El producto de programa 2214 puede almacenar, y transferir las etapas de programación a la memoria 2212 para su ejecución por el procesador central, el códec, o ambos.
El producto de programa 2214 puede ser chips de memoria de semiconductor, como memoria RAM, memoria flash, memoria ROM, memoria EPROM, memoria EEPROM, registros, así como otros dispositivos de almacenamiento como un disco duro, un disco extraíble, un CD-ROM, o cualquier otra forma de medio de almacenamiento conocido en la técnica que pueda almacenar instrucciones legibles por ordenador. Además, el producto de programa 2214 puede ser el archivo fuente que incluye las etapas de programa que se recibe de la red y se almacena en la memoria y a continuación se ejecuta. De esta manera, las etapas de procesamiento necesarias para la operación según la invención pueden incorporarse en el producto de programa 2214. En la Figura 22, el medio de almacenamiento de ejemplo se muestra acoplado al procesador central 2210 de manera que el procesador central pueda leer la información desde, y escribir información en, el medio de almacenamiento. De manera alternativa, el medio de almacenamiento puede integrarse en el procesador central 2210.
La interfaz de usuario 2216 se conecta al procesador central 2210 y al códec 2208. Por ejemplo, la interfaz de usuario 2216 puede incluir una pantalla y un altavoz utilizados para devolver datos multimedia al usuario.
Los expertos en la materia reconocerá que la etapa de un procedimiento descrito en relación con una forma de realización puede intercambiarse sin alejarse del alcance de la invención.
Los expertos en la materia también entenderán que la información y las señales pueden representarse utilizando cualquiera de una variedad de diferentes tecnologías y técnicas. Por ejemplo, los datos, las instrucciones, las órdenes, la información, las señales, los bits, los símbolos y los chips a los que puede hacerse referencia a lo largo de toda la descripción anterior pueden representarse mediante voltajes, corrientes, ondas electromagnéticas, partículas o campos magnéticos, partículas o campos ópticos, o cualquier combinación de los mismos.
Los expertos entenderán adicionalmente que los diversos bloques lógicos ilustrativos, módulos, circuitos, y etapas de algoritmo descritos en relación con las formas de realización divulgadas en este documento pueden implementarse como hardware electrónico, programas informáticos, o combinaciones de ambos. Para ilustrar claramente esta posibilidad de intercambiar el hardware y el software, se han descrito anteriormente diversos componentes ilustrativos, bloques, módulos, circuitos, y etapas generalmente en términos de su funcionalidad. Si dicha funcionalidad se implementa como hardware o software depende de las limitaciones de diseño y la aplicación concreta impuestas en el sistema global. Los expertos en la materia pueden implementar la funcionalidad descrita de formas diferentes para cada aplicación concreta, pero no debe interpretarse que tales decisiones de implementación se alejan del alcance de la presente invención.
Los diversos circuitos, módulos y bloques lógicos ilustrativos descritos en relación con las formas de realización divulgadas en este documento pueden implementarse o llevarse a cabo con un procesador de propósito general, un procesador digital de señal (DSP), un circuito integrado para aplicaciones específicas (ASIC), una matriz de puertas programable (FPGA) u otro dispositivo lógico programable, lógica de transistor o puerta discreta, componentes de hardware discreto, o cualquier combinación de los mismos diseñada para llevar a cabo las funciones descritas en este documento. Un procesador de propósito general puede ser un microprocesador, pero alternativamente, el procesador puede ser cualquier procesador convencional, controlador, microcontrolador, o máquina de estados. Un procesador también puede implementarse como una combinación de dispositivos informáticos, p. ej., una combinación de DSP y un microprocesador, una pluralidad de microprocesadores, uno o más microprocesadores junto con un núcleo DSP, o cualquier otra configuración de ese tipo.
Las etapas de un procedimiento o algoritmo descritas en relación con las formas de realización divulgadas en este documento pueden realizarse directamente en el hardware, en un módulo de software ejecutado por un procesador,
o en una combinación de los dos. Un módulo de software puede residir en la memoria RAM, memoria flash, memoria ROM, memoria EPROM, memoria EEPROM, registros, disco duro, un disco extraíble, un CD-ROM, o cualquier otra forma de medio de almacenamiento conocido en la técnica. Un medio de almacenamiento de ejemplo se acopla al procesador de manera que el procesador pueda leer información desde, y escribir información en, el medio de almacenamiento. Alternativamente, el medio de almacenamiento puede integrarse en el procesador. El procesador y el medio de almacenamiento pueden residir en un ASIC. El ASIC puede residir en un terminal de usuario. Alternativamente, el procesador y el medio de almacenamiento pueden residir como componentes discretos en un terminal de usuario.
5
La descripción anterior de las formas de realización divulgadas se proporciona para que cualquier persona experta en la materia fabrique o utilice la presente invención. Diversas modificaciones a estas formas de realización se pondrán fácilmente de manifiesto para los expertos en la materia, y los principios genéricos definidos en este documento pueden aplicarse a otras formas de realización sin apartarse del alcance de la invención. Por lo tanto, la
10 presente invención no pretende limitarse a las formas de realización mostradas en este documento sino que debe responder al alcance más amplio de conformidad con los principios y características novedosas divulgadas en este documento.

Claims (25)

  1. REIVINDICACIONES
    1.
    Un procedimiento para transmitir información de capa de aplicación en un sistema de comunicación inalámbrica (100), comprendiendo el procedimiento:
    determinar (2004) tamaños posibles de paquete de capa física de una pluralidad de canales disponibles de comunicación de tasa de bits constante; establecer limitaciones para particionar unidades de información de capa de aplicación de manera que las particiones se dimensionen para que el tamaño de cada partición coincida con uno de los tamaños de paquete de la capa física determinados disponibles en la pluralidad de canales de comunicación disponibles inalámbrica de tasa de bits constante, caracterizado porque esta etapa comprende particionar una unidad de información de capa de aplicación en múltiples particiones descodificables de manera independiente, de manera que exista una correspondencia de uno a uno entre las unidades de información de capa de aplicación particionadas y los paquetes de la capa física comunicados por los canales de comunicación disponibles.
  2. 2.
    Un procedimiento según la reivindicación 1, en el que particionar las unidades de información multimedia de capa de aplicación comprende un codificador fuente (2208) equipado con un módulo de control de velocidad capaz de generar particiones de tamaño variable.
  3. 3.
    Un procedimiento según la reivindicación 1, en el que las unidades de información multimedia de capa de aplicación comprenden un flujo de datos de tasa de bits variable.
  4. 4.
    Un procedimiento según la reivindicación 1, en el que las unidades de información multimedia de capa de aplicación comprenden datos multimedia.
  5. 5.
    Un procedimiento según la reivindicación 1, en el que las unidades de información multimedia de capa de aplicación comprenden datos de vídeo.
  6. 6.
    Un procedimiento según la reivindicación 1, en el que las unidades de información multimedia de capa de aplicación comprenden datos de audio.
  7. 7.
    Un procedimiento según la reivindicación 1, en el que los canales de comunicación de tasa de bits constante son canales CDMA.
  8. 8.
    Un procedimiento según la reivindicación 7, en el que los canales de comunicación de tasa de bits constante incluyen un canal suplementario.
  9. 9.
    Un procedimiento según la reivindicación 7, en el que el canal de comunicación de tasa de bits constante incluye un canal de control dedicado.
  10. 10.
    Un procedimiento según la reivindicación 7, en el que el canal de comunicación de tasa de bits constante incluye un canal de datos por paquetes.
  11. 11.
    Un procedimiento según la reivindicación 1, en el que los canales de comunicación de tasa de bits constante son canales GSM.
  12. 12.
    Un procedimiento según la reivindicación 1, en el que los canales de comunicación de tasa de bits constante son canales EDGE.
  13. 13.
    Un procedimiento según la reivindicación 1, en el que los canales de comunicación de tasa de bits constante son canales GPRS.
  14. 14.
    Un procedimiento según la reivindicación 1, en el que las limitaciones se utilizan durante la codificación de las unidades de información de capa de aplicación.
  15. 15.
    Un procedimiento según la reivindicación 1, en el que las unidades de información de la capa de aplicación se producen en un intervalo constante.
  16. 16.
    Un dispositivo de comunicación inalámbrica que comprende:
    un controlador configurado para determinar un conjunto de tamaños de paquete de capa física para la transmisión de información por una pluralidad de canales disponibles de comunicación de tasa de bits constante; un codificador configurado para particionar unidades de información de la capa de aplicación en paquetes de datos, en el que se selecciona un tamaño de paquete de datos individual para que coincida con uno de los tamaños de paquete de la capa física determinados de la pluralidad de canales disponibles de comunicación de tasa de bits constante, caracterizado porque el codificador se configura adicionalmente para particionar una unidad de información de capa de aplicación en múltiples particiones descodificables de manera independiente, de manera que exista una correspondencia de uno a uno entre las unidades de información particionadas y los paquetes de la capa física comunicados por los canales de comunicación disponibles.
  17. 17.
    Un dispositivo de comunicación inalámbrica según la reivindicación 16, en el que el codificador comprende adicionalmente un módulo de control de velocidad capaz de generar particiones de tamaño variable.
  18. 18.
    Un dispositivo de comunicación inalámbrica según la reivindicación 16, que comprende adicionalmente un transmisor configurado para transmitir los paquetes de la capa física.
  19. 19.
    Un dispositivo de comunicación inalámbrica según la reivindicación 16, en el que las unidades de información de capa de aplicación comprenden un flujo de tasa de bits variable.
  20. 20.
    Un dispositivo de comunicación inalámbrica según la reivindicación 16, en el que las unidades de información de capa de aplicación comprenden datos multimedia.
  21. 21.
    Un dispositivo de comunicación inalámbrica según la reivindicación 16, en el que las unidades de información de capa de aplicación comprenden datos de vídeo.
  22. 22.
    Un dispositivo de comunicación inalámbrica según la reivindicación 16, en el que la pluralidad de canales de tasa de bits constante son canales CDMA.
  23. 23.
    Un dispositivo de comunicación inalámbrica según la reivindicación 16, en el que la pluralidad de canales de tasa de bits constante son canales GSM.
  24. 24.
    Un dispositivo de comunicación inalámbrica según la reivindicación 16, en el que la pluralidad de canales de tasa de bits constante son canales GPRS.
  25. 25.
    Un dispositivo de comunicación inalámbrica según la reivindicación 16, en el que la pluralidad de canales de tasa de bits constante son canales EDGE.
ES05749640T 2004-05-13 2005-05-13 Envío de información por un canal de comunicación. Expired - Lifetime ES2366192T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US57167304P 2004-05-13 2004-05-13
US571673P 2004-05-13

Publications (1)

Publication Number Publication Date
ES2366192T3 true ES2366192T3 (es) 2011-10-18

Family

ID=34969576

Family Applications (4)

Application Number Title Priority Date Filing Date
ES05748133T Expired - Lifetime ES2354079T3 (es) 2004-05-13 2005-05-13 Sincronización de datos de audio y vídeo en un sistema de comunicación inalámbrico.
ES05748216T Expired - Lifetime ES2323011T3 (es) 2004-05-13 2005-05-13 Compresion de cabecera de datos multimedia transmitidos sobre un sistema de comunicacion inalambrico.
ES05749459T Expired - Lifetime ES2318495T3 (es) 2004-05-13 2005-05-13 Procedimiento y aparato para asignacion de informacion a canales de un sistema de comunicaciones.
ES05749640T Expired - Lifetime ES2366192T3 (es) 2004-05-13 2005-05-13 Envío de información por un canal de comunicación.

Family Applications Before (3)

Application Number Title Priority Date Filing Date
ES05748133T Expired - Lifetime ES2354079T3 (es) 2004-05-13 2005-05-13 Sincronización de datos de audio y vídeo en un sistema de comunicación inalámbrico.
ES05748216T Expired - Lifetime ES2323011T3 (es) 2004-05-13 2005-05-13 Compresion de cabecera de datos multimedia transmitidos sobre un sistema de comunicacion inalambrico.
ES05749459T Expired - Lifetime ES2318495T3 (es) 2004-05-13 2005-05-13 Procedimiento y aparato para asignacion de informacion a canales de un sistema de comunicaciones.

Country Status (14)

Country Link
US (6) US20050259623A1 (es)
EP (9) EP2262304B1 (es)
JP (5) JP4448171B2 (es)
KR (6) KR100870215B1 (es)
CN (5) CN1977516B (es)
AT (4) ATE508567T1 (es)
BR (4) BRPI0510953A (es)
CA (6) CA2566125C (es)
DE (4) DE602005013517D1 (es)
ES (4) ES2354079T3 (es)
MX (4) MXPA06013193A (es)
MY (3) MY141497A (es)
TW (4) TWI381681B (es)
WO (4) WO2005114943A2 (es)

Families Citing this family (204)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7136395B2 (en) * 2000-11-30 2006-11-14 Telefonaktiebolaget L M Ericsson (Publ) Method and system for transmission of headerless data packets over a wireless link
ATE508567T1 (de) 2004-05-13 2011-05-15 Qualcomm Inc Zustellung von informationen über einen kommunikationskanal
US7599371B1 (en) * 2004-06-09 2009-10-06 Cisco Technology, Inc. System and method for optimizing data transport in a communications system
FI20040817A0 (fi) * 2004-06-14 2004-06-14 Nokia Corp Pakkausparametrien siirto matkaviestinjärjestelmässä
US7664057B1 (en) * 2004-07-13 2010-02-16 Cisco Technology, Inc. Audio-to-video synchronization system and method for packet-based network video conferencing
US20060062312A1 (en) * 2004-09-22 2006-03-23 Yen-Chi Lee Video demultiplexer and decoder with efficient data recovery
US7804850B2 (en) * 2004-10-01 2010-09-28 Nokia Corporation Slow MAC-e for autonomous transmission in high speed uplink packet access (HSUPA) along with service specific transmission time control
JP4838143B2 (ja) * 2004-11-17 2011-12-14 シャープ株式会社 送信装置
US8095116B2 (en) * 2004-11-30 2012-01-10 Telefonaktiebolaget Lm Ericsson (Publ) Method for delivering multimedia files
US7675872B2 (en) * 2004-11-30 2010-03-09 Broadcom Corporation System, method, and apparatus for displaying pictures
US7970345B2 (en) * 2005-06-22 2011-06-28 Atc Technologies, Llc Systems and methods of waveform and/or information splitting for wireless transmission of information to one or more radioterminals over a plurality of transmission paths and/or system elements
US7764713B2 (en) * 2005-09-28 2010-07-27 Avaya Inc. Synchronization watermarking in multimedia streams
US8102878B2 (en) * 2005-09-29 2012-01-24 Qualcomm Incorporated Video packet shaping for video telephony
US9692537B2 (en) * 2005-10-18 2017-06-27 Avago Technologies General Ip (Singapore) Pte. Ltd. System, method, and apparatus for jitter reduction in a video decoder system
US8842555B2 (en) * 2005-10-21 2014-09-23 Qualcomm Incorporated Methods and systems for adaptive encoding of real-time information in packet-switched wireless communication systems
US8548048B2 (en) * 2005-10-27 2013-10-01 Qualcomm Incorporated Video source rate control for video telephony
US8406309B2 (en) 2005-10-21 2013-03-26 Qualcomm Incorporated Video rate adaptation to reverse link conditions
US8994879B2 (en) * 2005-10-21 2015-03-31 Thomson Licensing Method and apparatus for audio and video synchronization timestamp rollover correction
US8514711B2 (en) * 2005-10-21 2013-08-20 Qualcomm Incorporated Reverse link lower layer assisted video error control
US7839948B2 (en) * 2005-12-02 2010-11-23 Qualcomm Incorporated Time slicing techniques for variable data rate encoding
JP4747816B2 (ja) * 2005-12-05 2011-08-17 日本電気株式会社 パケット相乗り方法、プログラム及び装置
US8014389B2 (en) * 2005-12-06 2011-09-06 Lippershy Celestial Llc Bidding network
US20080310451A1 (en) * 2005-12-23 2008-12-18 Koninklijke Philips Electronics N.V. Splitting of a Data Stream
US20070169152A1 (en) * 2005-12-30 2007-07-19 Daniel Roodnick Data and wireless frame alignment for error reduction
US8953596B2 (en) * 2006-01-06 2015-02-10 Qualcomm Incorporated Conserving network capacity by releasing QoS resources
US8284713B2 (en) * 2006-02-10 2012-10-09 Cisco Technology, Inc. Wireless audio systems and related methods
KR100754736B1 (ko) * 2006-02-10 2007-09-03 삼성전자주식회사 영상 수신 시스템에서 영상 프레임의 재생 방법 및 그 장치
KR100728038B1 (ko) * 2006-03-03 2007-06-14 삼성전자주식회사 Ｐｌｃ 네트워크상에서 데이터를 묶어서 전송하는 방법 및장치
US7876695B2 (en) * 2006-03-07 2011-01-25 Telefonaktiebolaget Lm Ericsson (Publ) Communication station and method providing flexible compression of data packets
JP4659657B2 (ja) * 2006-03-28 2011-03-30 富士通株式会社 フレーム多重装置
WO2007114633A2 (en) * 2006-04-03 2007-10-11 Lg Electronics Inc. Method of performing scheduling in a wired or wireless communication system and network scheduler thereof
US7684816B2 (en) * 2006-04-06 2010-03-23 Motorola, Inc. Method and apparatus to facilitate communication resource allocation for supergroups
EP2022210A1 (en) * 2006-05-15 2009-02-11 Telefonaktiebolaget L.M. Ericsson Wireless multicast for layered media
CN1983905B (zh) * 2006-05-25 2011-05-11 华为技术有限公司 终端在1x网络下建立HRPD网络分组数据业务的方法
US7920469B2 (en) * 2006-06-15 2011-04-05 Alcatel-Lucent Usa Inc. Indicating a variable control channel structure for transmissions in a cellular system
US20070299983A1 (en) * 2006-06-21 2007-12-27 Brothers Thomas J Apparatus for synchronizing multicast audio and video
US20070297454A1 (en) * 2006-06-21 2007-12-27 Brothers Thomas J Systems and methods for multicasting audio
US7584495B2 (en) * 2006-06-30 2009-09-01 Nokia Corporation Redundant stream alignment in IP datacasting over DVB-H
US20080025249A1 (en) * 2006-07-28 2008-01-31 Qualcomm Incorporated 1xEVDO WIRELESS INTERFACE TO ENABLE COMMUNICATIONS VIA A SATELLITE RELAY
US20080025312A1 (en) * 2006-07-28 2008-01-31 Qualcomm Incorporated Zero-header compression for improved communications
US8060651B2 (en) * 2006-08-17 2011-11-15 Sharp Laboratories Of America, Inc. Systems and methods for adaptively packetizing data partitions for transport over a network
US8644314B2 (en) * 2006-09-07 2014-02-04 Kyocera Corporation Protocol and method of VIA field compression in session initiation protocol signaling for 3G wireless networks
US8379733B2 (en) * 2006-09-26 2013-02-19 Qualcomm Incorporated Efficient video packetization methods for packet-switched video telephony applications
US8484059B2 (en) 2006-10-17 2013-07-09 At&T Intellectual Property I, L.P. Methods, systems, and products for surveying facilities
US8069412B2 (en) * 2006-10-17 2011-11-29 At&T Intellectual Property I, L.P. Methods, systems, and products for mapping facilities data
US20080101476A1 (en) * 2006-11-01 2008-05-01 Qualcomm Incorporated Video coding rate adaptation to reduce packetization overhead
CN101179484A (zh) * 2006-11-09 2008-05-14 华为技术有限公司 一种不同媒体流间的同步方法及系统
CN100450163C (zh) * 2006-11-30 2009-01-07 中兴通讯股份有限公司 一种移动多媒体广播视音频同步播放的方法
US7889191B2 (en) * 2006-12-01 2011-02-15 Semiconductor Components Industries, Llc Method and apparatus for providing a synchronized video presentation without video tearing
US7953118B2 (en) * 2006-12-08 2011-05-31 Microsoft Corporation Synchronizing media streams across multiple devices
CN103298029A (zh) 2006-12-19 2013-09-11 创新音速有限公司 无线通讯系统改善连续封包连通功能的方法及其相关装置
US8005043B2 (en) * 2007-01-03 2011-08-23 Samsung Electronics Co., Ltd Method and apparatus for scheduling downlink packets in a mobile communication system
CA2671731A1 (en) 2007-01-04 2008-07-17 Qualcomm Incorporated Method and apparatus for distributed spectrum sensing for wireless communication
KR101370478B1 (ko) * 2007-01-10 2014-03-06 퀄컴 인코포레이티드 멀티미디어 전화 통신을 위한 컨텐트- 및 링크-의존 코딩 적응 구조
KR101369838B1 (ko) * 2007-04-20 2014-03-06 삼성전자주식회사 전송 스트림 생성장치, 송신 장치, 수신 장치, 이들이포함된 디지털 방송 시스템 및 그 방법
KR100861594B1 (ko) * 2007-04-23 2008-10-07 주식회사 케이티프리텔 멀티미디어 데이터 전송률 제어 장치 및 그 방법
US8667318B2 (en) * 2007-05-14 2014-03-04 Picongen Wireless, Inc. Method and apparatus for wireless clock regeneration
EP2183927A4 (en) * 2007-05-14 2014-12-17 Sigma Group Inc WIRELESS MULTIMEDIA SYSTEM
CN100574283C (zh) * 2007-06-12 2009-12-23 华为技术有限公司 上、下行传输方法及汇聚节点
EP2023521A1 (en) * 2007-07-17 2009-02-11 Alcatel Lucent System and method for improving the use of radio spectrum in transmission of data
CN101094406B (zh) * 2007-07-23 2010-09-29 北京中星微电子有限公司 一种视频数据流的传输方法及装置
GB0715281D0 (en) 2007-08-07 2007-09-12 Nokia Siemens Networks Oy Reduced transmission time interval
US7826360B1 (en) 2007-08-27 2010-11-02 Marvell International Ltd. Adjusting transmission rates during packet expansion using in band signaling
JP4410277B2 (ja) * 2007-08-28 2010-02-03 富士通株式会社 半導体装置、および半導体装置の制御方法
KR100916469B1 (ko) 2007-08-29 2009-09-08 엘지이노텍 주식회사 미디어 장치 및 그 제어방법
US9521186B2 (en) 2007-09-13 2016-12-13 International Business Machines Corporation Method and system for file transfer over a messaging infrastructure
ES2675947T3 (es) * 2007-10-02 2018-07-13 Nokia Technologies Oy Control de MTU de IP basado en planificación multirradio
EP2206368A1 (en) * 2007-10-04 2010-07-14 Telefonaktiebolaget LM Ericsson (PUBL) Inter-system handoff using circuit switched bearers for serving general packet radio service support nodes
KR100918961B1 (ko) 2007-10-09 2009-09-25 강릉원주대학교산학협력단 무선 통신망에서 동적 영역 압축 및 ｎｃｂ 결정방법
KR101422012B1 (ko) * 2007-10-19 2014-07-23 엘지전자 주식회사 제어채널 생성 방법, 제어채널 복호화 방법, 이를 구현하는기지국 및 단말
US8797850B2 (en) * 2008-01-10 2014-08-05 Qualcomm Incorporated System and method to adapt to network congestion
US9705935B2 (en) * 2008-01-14 2017-07-11 Qualcomm Incorporated Efficient interworking between circuit-switched and packet-switched multimedia services
US20090185534A1 (en) * 2008-01-18 2009-07-23 Futurewei Technologies, Inc. Method and Apparatus for Transmitting a Packet Header
US9357233B2 (en) * 2008-02-26 2016-05-31 Qualcomm Incorporated Video decoder error handling
JP5115802B2 (ja) * 2008-03-11 2013-01-09 富士通株式会社 スケジューリング装置、スケジューリング方法、およびプログラム
CN101257366B (zh) * 2008-03-27 2010-09-22 华为技术有限公司 编解码方法、通讯系统及设备
US20090268732A1 (en) * 2008-04-29 2009-10-29 Thomson Licencing Channel change tracking metric in multicast groups
MX2010012117A (es) * 2008-05-07 2010-12-01 Digital Fountain Inc Manipulacion de canal rapida y proteccion de corriente de alta calidad sobre un canal de difusion.
CN102057687B (zh) * 2008-06-11 2013-06-12 皇家飞利浦电子股份有限公司 媒体流成分的同步
US20100003928A1 (en) * 2008-07-01 2010-01-07 Motorola, Inc. Method and apparatus for header compression for cdma evdo systems
US20100027524A1 (en) * 2008-07-31 2010-02-04 Nokia Corporation Radio layer emulation of real time protocol sequence number and timestamp
JP2010081212A (ja) * 2008-09-25 2010-04-08 Mitsubishi Electric Corp 音声伝送装置
JP5135147B2 (ja) * 2008-09-29 2013-01-30 富士フイルム株式会社 動画ファイル送信サーバおよびその動作制御方法
US8966543B2 (en) * 2008-09-29 2015-02-24 Nokia Corporation Method and system to enable adaptation between physical bearers and OMA-BCAST
JP5363588B2 (ja) * 2008-12-08 2013-12-11 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 受信オーディオデータをビデオデータと同期させるための装置及び方法
US8204038B2 (en) * 2009-01-13 2012-06-19 Mediatek Inc. Method for efficient utilization of radio resources in wireless communications system
JP4650573B2 (ja) 2009-01-22 2011-03-16 ソニー株式会社 通信装置、通信システム、プログラム、および通信方法
WO2010101996A1 (en) 2009-03-03 2010-09-10 Davenport Ronald R A wired internet network system for the internet video streams of radio stations
US8958475B2 (en) * 2009-07-02 2015-02-17 Qualcomm Incorporated Transmitter quieting and null data encoding
US8902995B2 (en) 2009-07-02 2014-12-02 Qualcomm Incorporated Transmitter quieting and reduced rate encoding
US9112618B2 (en) 2009-07-02 2015-08-18 Qualcomm Incorporated Coding latency reductions during transmitter quieting
KR101669533B1 (ko) * 2009-07-06 2016-10-26 삼성전자주식회사 무선통신 시스템에서 매체 접속 제어 계층 패킷을 구성하는 방법 및 시스템
EP2460104A4 (en) 2009-07-27 2016-10-05 Ibm METHOD AND SYSTEM FOR TRANSFORMING LOGICAL DATA OBJECTS FOR STORAGE USE
CN101998508B (zh) * 2009-08-14 2013-08-28 华为技术有限公司 数据封装方法及装置
WO2011027936A1 (ko) * 2009-09-03 2011-03-10 에스케이 텔레콤주식회사 근거리 무선통신 기반 프로토콜의 상위에 탑재되는 전송계층의 헤더정보를 압축 및 해제하기 위한 시스템 및 방법, 그리고 이에 적용되는 장치
EP2302845B1 (en) 2009-09-23 2012-06-20 Google, Inc. Method and device for determining a jitter buffer level
WO2011068355A2 (ko) * 2009-12-01 2011-06-09 삼성전자 주식회사 상호 계층 최적화를 이용한 멀티미디어 데이터 패킷을 송신하는 방법 및 장치
US8780720B2 (en) 2010-01-11 2014-07-15 Venturi Ip Llc Radio access network load and condition aware traffic shaping control
US20110182257A1 (en) * 2010-01-26 2011-07-28 Qualcomm Incorporated White space spectrum commmunciation device with multiplexing capabilties
KR20110090596A (ko) * 2010-02-04 2011-08-10 삼성전자주식회사 지터 보정 방법 및 장치
EP2362653A1 (en) 2010-02-26 2011-08-31 Panasonic Corporation Transport stream packet header compression
CN101877643B (zh) * 2010-06-29 2014-12-10 中兴通讯股份有限公司 多点混音远景呈现方法、装置及系统
US8630412B2 (en) 2010-08-25 2014-01-14 Motorola Mobility Llc Transport of partially encrypted media
US8477050B1 (en) 2010-09-16 2013-07-02 Google Inc. Apparatus and method for encoding using signal fragments for redundant transmission of data
US20120243602A1 (en) * 2010-09-23 2012-09-27 Qualcomm Incorporated Method and apparatus for pipelined slicing for wireless display
US8736700B2 (en) * 2010-09-30 2014-05-27 Apple Inc. Techniques for synchronizing audio and video data in an image signal processing system
US8595374B2 (en) 2010-12-08 2013-11-26 At&T Intellectual Property I, L.P. Method and apparatus for capacity dimensioning in a communication network
CN103262639B (zh) * 2010-12-20 2016-08-10 雅马哈株式会社 无线音频传输方法
WO2012100201A1 (en) * 2011-01-21 2012-07-26 Qualcomm Incorporated User input back channel for wireless displays
US9413803B2 (en) 2011-01-21 2016-08-09 Qualcomm Incorporated User input back channel for wireless displays
US20130013318A1 (en) 2011-01-21 2013-01-10 Qualcomm Incorporated User input back channel for wireless displays
US8964783B2 (en) * 2011-01-21 2015-02-24 Qualcomm Incorporated User input back channel for wireless displays
US10135900B2 (en) 2011-01-21 2018-11-20 Qualcomm Incorporated User input back channel for wireless displays
US9787725B2 (en) 2011-01-21 2017-10-10 Qualcomm Incorporated User input back channel for wireless displays
US20130022032A1 (en) * 2011-01-26 2013-01-24 Qualcomm Incorporated Systems and methods for communicating in a network
US8856212B1 (en) 2011-02-08 2014-10-07 Google Inc. Web-based configurable pipeline for media processing
EP2490447A1 (en) * 2011-02-16 2012-08-22 British Telecommunications Public Limited Company Compact cumulative bit curves
JP2012222530A (ja) * 2011-04-06 2012-11-12 Sony Corp 受信装置及び方法、並びにプログラム
US8831108B2 (en) * 2011-05-04 2014-09-09 Cavium, Inc. Low latency rate control system and method
EP2547062B1 (en) 2011-07-14 2016-03-16 Nxp B.V. Media streaming with adaptation
CN102325261A (zh) * 2011-09-14 2012-01-18 上海交通大学 立体视频采集合成系统的视间视频数据消抖同步方法
CN102521294A (zh) * 2011-11-30 2012-06-27 苏州奇可思信息科技有限公司 基于音频触发式课件的远程教育授课方法
US20130155918A1 (en) * 2011-12-20 2013-06-20 Nokia Siemens Networks Oy Techniques To Enhance Header Compression Efficiency And Enhance Mobile Node Security
CN103179094B (zh) * 2011-12-22 2019-10-01 南京中兴软件有限责任公司 Ip报文头的发送、接收方法、发送装置以及接收装置
CN103179449B (zh) * 2011-12-23 2016-03-02 联想(北京)有限公司 媒体文件的播放方法、电子设备和虚拟机架构
US8687654B1 (en) * 2012-01-05 2014-04-01 Google Inc. Method to packetize an encoded video frame
GB2498992B (en) * 2012-02-02 2015-08-26 Canon Kk Method and system for transmitting video frame data to reduce slice error rate
US20130223412A1 (en) * 2012-02-24 2013-08-29 Qualcomm Incorporated Method and system to improve frame early termination success rate
EP2648418A1 (en) * 2012-04-05 2013-10-09 Thomson Licensing Synchronization of multimedia streams
US9098596B2 (en) * 2012-04-10 2015-08-04 Cable Television Laboratories, Inc. Redirecting web content
US9204095B2 (en) * 2012-05-04 2015-12-01 Hong Jiang Instant communications system having established communication channels between communication devices
CN102665140B (zh) * 2012-05-16 2014-04-09 哈尔滨工业大学深圳研究生院 一种avs视频帧的rtp封装方法
CN103428523B (zh) * 2012-05-22 2015-07-08 华为技术有限公司 评估视频质量的方法和装置
US9031319B2 (en) 2012-05-31 2015-05-12 Apple Inc. Systems and methods for luma sharpening
US11089247B2 (en) 2012-05-31 2021-08-10 Apple Inc. Systems and method for reducing fixed pattern noise in image data
US9332239B2 (en) 2012-05-31 2016-05-03 Apple Inc. Systems and methods for RGB image processing
US9743057B2 (en) 2012-05-31 2017-08-22 Apple Inc. Systems and methods for lens shading correction
US9014504B2 (en) 2012-05-31 2015-04-21 Apple Inc. Systems and methods for highlight recovery in an image signal processor
US9077943B2 (en) 2012-05-31 2015-07-07 Apple Inc. Local image statistics collection
US8917336B2 (en) 2012-05-31 2014-12-23 Apple Inc. Image signal processing involving geometric distortion correction
US9025867B2 (en) 2012-05-31 2015-05-05 Apple Inc. Systems and methods for YCC image processing
US8953882B2 (en) 2012-05-31 2015-02-10 Apple Inc. Systems and methods for determining noise statistics of image data
US9105078B2 (en) 2012-05-31 2015-08-11 Apple Inc. Systems and methods for local tone mapping
US8872946B2 (en) 2012-05-31 2014-10-28 Apple Inc. Systems and methods for raw image processing
US8817120B2 (en) 2012-05-31 2014-08-26 Apple Inc. Systems and methods for collecting fixed pattern noise statistics of image data
US9142012B2 (en) 2012-05-31 2015-09-22 Apple Inc. Systems and methods for chroma noise reduction
US8863307B2 (en) 2012-06-05 2014-10-14 Broadcom Corporation Authenticating users based upon an identity footprint
TWI513320B (zh) * 2012-06-25 2015-12-11 Hon Hai Prec Ind Co Ltd 視訊會議裝置及其唇形同步的方法
US9236053B2 (en) * 2012-07-05 2016-01-12 Panasonic Intellectual Property Management Co., Ltd. Encoding and decoding system, decoding apparatus, encoding apparatus, encoding and decoding method
US9668161B2 (en) * 2012-07-09 2017-05-30 Cisco Technology, Inc. System and method associated with a service flow router
KR101947000B1 (ko) 2012-07-17 2019-02-13 삼성전자주식회사 방송 시스템에서 멀티미디어 데이터의 전송 특징 정보 전달 방법 및 장치
US20140142955A1 (en) * 2012-11-19 2014-05-22 Apple Inc. Encoding Digital Media for Fast Start on Digital Media Players
US20140192200A1 (en) * 2013-01-08 2014-07-10 Hii Media Llc Media streams synchronization
US20140310735A1 (en) * 2013-04-12 2014-10-16 Codemate A/S Flat rate billing of content distribution
US9532043B2 (en) 2013-08-02 2016-12-27 Blackberry Limited Wireless transmission of real-time media
FR3011155A1 (fr) * 2013-09-26 2015-03-27 Orange Procedes de synchronisation, de generation d'un flux, programmes d'ordinateur, media de stockage, dispositifs de restitution, d'execution et de generation correspondants.
US20150195326A1 (en) * 2014-01-03 2015-07-09 Qualcomm Incorporated Detecting whether header compression is being used for a first stream based upon a delay disparity between the first stream and a second stream
US9282171B2 (en) * 2014-03-06 2016-03-08 Qualcomm Incorporated Context establishment in marginal grant conditions
US9369724B2 (en) * 2014-03-31 2016-06-14 Microsoft Technology Licensing, Llc Decoding and synthesizing frames for incomplete video data
WO2015179811A1 (en) * 2014-05-22 2015-11-26 Kyocera Corporation Unlicensed frequency band with licensed frequency band timing
CN103986941A (zh) * 2014-05-28 2014-08-13 深圳市智英实业发展有限公司 一种无线音视频传输系统
EP3016432B1 (en) * 2014-10-30 2018-07-04 Vodafone IP Licensing limited Content compression in mobile network
US10129839B2 (en) * 2014-12-05 2018-11-13 Qualcomm Incorporated Techniques for synchronizing timing of wireless streaming transmissions to multiple sink devices
KR102349450B1 (ko) * 2014-12-08 2022-01-10 삼성전자주식회사 무결성 검사 데이터 제공 방법 및 장치
US9692709B2 (en) 2015-06-04 2017-06-27 Oracle International Corporation Playout buffering of encapsulated media
KR102402881B1 (ko) 2015-06-05 2022-05-27 한화테크윈 주식회사 감시 시스템
US9929879B2 (en) 2015-06-09 2018-03-27 Oracle International Corporation Multipath support of real-time communications
CN104980955A (zh) * 2015-06-19 2015-10-14 重庆市音乐一号科技有限公司 一种改善Wi-Fi Display传输速度的方法
WO2017008263A1 (en) * 2015-07-15 2017-01-19 Mediatek Singapore Pte. Ltd. Conditional binary tree block partitioning structure
CN105245273B (zh) * 2015-08-27 2017-12-12 桂林理工大学 一种照度均衡的rs232与vlc通信协议转换方法
WO2017071730A1 (en) * 2015-10-26 2017-05-04 Telefonaktiebolaget Lm Ericsson (Publ) Length control for packet header sampling
WO2017074811A1 (en) * 2015-10-28 2017-05-04 Microsoft Technology Licensing, Llc Multiplexing data
GB201519090D0 (en) * 2015-10-28 2015-12-09 Microsoft Technology Licensing Llc Multiplexing data
CN106817350A (zh) * 2015-11-30 2017-06-09 中兴通讯股份有限公司 报文处理方法及装置
US11924826B2 (en) 2015-12-10 2024-03-05 Qualcomm Incorporated Flexible transmission unit and acknowledgment feedback timeline for efficient low latency communication
US10332534B2 (en) * 2016-01-07 2019-06-25 Microsoft Technology Licensing, Llc Encoding an audio stream
KR101700370B1 (ko) * 2016-06-08 2017-01-26 삼성전자주식회사 지터 보정 방법 및 장치
KR102497216B1 (ko) * 2017-05-10 2023-02-07 삼성전자 주식회사 슬라이스 기반의 압축을 수행하는 영상 처리 장치 및 영상 처리 방법
US10367750B2 (en) * 2017-06-15 2019-07-30 Mellanox Technologies, Ltd. Transmission and reception of raw video using scalable frame rate
GB2564644B (en) * 2017-07-12 2020-12-16 Canon Kk Method and system of encoding a data stream according to a variable bitrate mode
EP3643074A4 (en) * 2017-08-25 2020-04-29 SZ DJI Technology Co., Ltd. SYSTEMS AND METHODS FOR SYNCHRONIZING FRAME SYNCHRONIZATION BETWEEN A PHYSICAL LAYER FRAME AND A VIDEO FRAME
EP3493535B1 (en) * 2017-11-29 2020-09-09 Mitsubishi Electric R & D Centre Europe B.V. Method for controlling a video encoder of a video camera installed on a moving conveyance
WO2019114911A1 (es) 2017-12-13 2019-06-20 Fiorentino Ramon Sistema interconectado para la transmisión inalámbrica de audio y vídeo de alta calidad entre dispositivos de electrónica de consumo
US10437745B2 (en) * 2018-01-05 2019-10-08 Denso International America, Inc. Mobile de-whitening
US10608947B2 (en) * 2018-02-26 2020-03-31 Qualcomm Incorporated Per-flow jumbo MTU in NR systems
KR102011806B1 (ko) * 2018-04-12 2019-08-19 주식회사 넷커스터마이즈 Udt 기반 트래픽 가속 방법
WO2019231376A1 (en) * 2018-06-01 2019-12-05 Telefonaktiebolaget Lm Ericsson (Publ) Method for bundling sampling data for wireless transmission
DE102018212655A1 (de) * 2018-07-30 2020-01-30 Conti Temic Microelectronic Gmbh Erkennung der Bewegungsabsicht eines Fußgängers aus Kamerabildern
US10834296B2 (en) * 2018-09-12 2020-11-10 Roku, Inc. Dynamically adjusting video to improve synchronization with audio
CN109618240A (zh) * 2018-10-26 2019-04-12 安徽清新互联信息科技有限公司 用于实时音视频传输的无线多信道自适应均衡方法
US12321662B2 (en) 2019-09-10 2025-06-03 Sonos, Inc. Synchronizing playback of audio information received from other networks
CN111064541B (zh) * 2019-12-18 2021-05-11 中国南方电网有限责任公司超高压输电公司 一种高低速数据传输通道复用的方法
CN111131917B (zh) * 2019-12-26 2021-12-28 国微集团(深圳)有限公司 音频频谱实时同步方法、播放装置
CN113595965A (zh) * 2020-04-30 2021-11-02 中兴通讯股份有限公司 业务数据处理、交换、提取方法及设备、计算机可读介质
CN111866753B (zh) * 2020-06-02 2021-06-29 中山大学 一种数字传输广播通信方法及系统
WO2021252548A1 (en) * 2020-06-08 2021-12-16 Sky Peak Technologies, Inc. Content shaping and routing in a network
CN114390335B (zh) * 2020-10-22 2022-11-18 华为终端有限公司 一种在线播放音视频的方法、电子设备及存储介质
KR102408433B1 (ko) * 2021-07-27 2022-06-10 한국항공우주연구원 다중 데이터 전송 방법 및 시스템
CN114071185B (zh) * 2021-11-16 2025-09-16 北京百度网讯科技有限公司 视频流下发的方法、相关装置及计算机程序产品
CN115484239B (zh) * 2022-09-15 2023-10-27 北京百度网讯科技有限公司 多媒体数据流的处理方法、装置、电子设备及存储介质
US20240339117A1 (en) * 2023-04-07 2024-10-10 Apple Inc. Low latency audio for immersive group communication sessions
KR102872864B1 (ko) * 2023-11-06 2025-10-16 영남대학교 산학협력단 V2x 기반의 자율협력주행을 위한 양방향 링크 장치 및 방법
US20260012498A1 (en) * 2024-07-05 2026-01-08 SimpliSafe, Inc. Streaming network topology
CN119051729B (zh) * 2024-10-30 2025-01-07 中国电子科技集团公司第五十四研究所 复杂多场景卫星通信可靠多站协同分发方法、系统

Family Cites Families (129)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4948019A (en) 1989-03-31 1990-08-14 Rodum Roland K Collapsible clothes hanger
JP2712656B2 (ja) 1989-10-25 1998-02-16 日本電気ホームエレクトロニクス株式会社 Ｃｄ―ｒｏｍ記録方法
AU2908492A (en) 1991-10-22 1993-05-21 Cae, Inc. Synchronous parallel electronic timing generator
EP0614317A3 (en) 1993-03-05 1995-01-25 Sony Corp Decoding video signals.
JP3364281B2 (ja) * 1993-07-16 2003-01-08 パイオニア株式会社 時分割ビデオ及びオーディオ信号の同期方式
JP3003839B2 (ja) * 1993-11-08 2000-01-31 エヌ・ティ・ティ移動通信網株式会社 Ｃｄｍａ通信方法および装置
US5541852A (en) * 1994-04-14 1996-07-30 Motorola, Inc. Device, method and system for variable bit-rate packet video communications
US5583652A (en) * 1994-04-28 1996-12-10 International Business Machines Corporation Synchronized, variable-speed playback of digitally recorded audio and video
US5510842A (en) 1994-05-04 1996-04-23 Matsushita Electric Corporation Of America Parallel architecture for a high definition television video decoder having multiple independent frame memories
US5646693A (en) 1994-11-04 1997-07-08 Cismas; Sorin Memory utilization for video decoding and display with 3:2 pull-down
KR0137701B1 (ko) * 1994-12-13 1998-05-15 양승택 엠피이지-2(mpeg-2) 시스템의 피이에스(pes) 패킷화 장치
FI114178B (fi) 1995-01-09 2004-08-31 Nokia Corp Radiokapasiteetin dynaaminen jakaminen TDMA-järjestelmässä
US5898695A (en) * 1995-03-29 1999-04-27 Hitachi, Ltd. Decoder for compressed and multiplexed video and audio data
US5914717A (en) 1995-07-21 1999-06-22 Microsoft Methods and system for providing fly out menus
KR0164184B1 (ko) 1995-08-31 1999-01-15 배순훈 동영상 압축디스크의 엔코딩제어장치
US5844600A (en) * 1995-09-15 1998-12-01 General Datacomm, Inc. Methods, apparatus, and systems for transporting multimedia conference data streams through a transport network
KR970012585U (ko) 1995-09-21 1997-04-25 자동차용 선바이저
US6058141A (en) * 1995-09-28 2000-05-02 Digital Bitcasting Corporation Varied frame rate video
IT1281001B1 (it) * 1995-10-27 1998-02-11 Cselt Centro Studi Lab Telecom Procedimento e apparecchiatura per codificare, manipolare e decodificare segnali audio.
US5570372A (en) * 1995-11-08 1996-10-29 Siemens Rolm Communications Inc. Multimedia communications with system-dependent adaptive delays
US5717464A (en) * 1995-12-18 1998-02-10 Divicom, Inc. Rate control for a video encoder
IL117133A (en) * 1996-02-14 1999-07-14 Olivr Corp Ltd Method and system for providing on-line virtual reality movies
JPH09312656A (ja) * 1996-03-21 1997-12-02 Sony Corp 伝送装置およびその方法
US5867230A (en) 1996-09-06 1999-02-02 Motorola Inc. System, device, and method for streaming a multimedia file encoded at a variable bitrate
US6041067A (en) 1996-10-04 2000-03-21 Matsushita Electric Industrial Co., Ltd. Device for synchronizing data processing
US6473404B1 (en) * 1998-11-24 2002-10-29 Connect One, Inc. Multi-protocol telecommunications routing optimization
KR100204043B1 (ko) * 1996-11-28 1999-06-15 정선종 분산처리환경 상에서 오디오/비디오 데이타 전송을 위한 스트림 채널 형성방법
US6154780A (en) 1996-12-18 2000-11-28 Intel Corporation Method and apparatus for transmission of a flexible and error resilient video bitstream
DE19652708C2 (de) * 1996-12-18 1999-08-12 Schott Glas Verfahren zum Herstellen eines befüllten Kunststoff-Spritzenkorpus für medizinische Zwecke
EP0861001B1 (en) 1997-02-07 2012-05-23 Texas Instruments Incorporated Error resilient video encoding
KR100223298B1 (ko) * 1997-02-12 1999-10-15 서평원 광대역 종합 정보 통신망의 터미널 정합 장치
US6542481B2 (en) * 1998-06-01 2003-04-01 Tantivy Communications, Inc. Dynamic bandwidth allocation for multiple access communication using session queues
US6181711B1 (en) 1997-06-26 2001-01-30 Cisco Systems, Inc. System and method for transporting a compressed video and data bit stream over a communication channel
US6577610B1 (en) 1997-06-30 2003-06-10 Spacenet, Inc. Flex slotted Aloha transmission system and method
US6124895A (en) 1997-10-17 2000-09-26 Dolby Laboratories Licensing Corporation Frame-based audio coding with video/audio data synchronization by dynamic audio frame alignment
US5913190A (en) 1997-10-17 1999-06-15 Dolby Laboratories Licensing Corporation Frame-based audio coding with video/audio data synchronization by audio sample rate conversion
JP3407287B2 (ja) 1997-12-22 2003-05-19 日本電気株式会社 符号化復号システム
US7043749B1 (en) * 1998-02-27 2006-05-09 Tandberg Telecom As Audio-video packet synchronization at network gateway
US6192257B1 (en) 1998-03-31 2001-02-20 Lucent Technologies Inc. Wireless communication terminal having video image capability
JPH11298878A (ja) 1998-04-08 1999-10-29 Nec Corp 画像スクランブル方法およびそれを実施する装置
US6539011B1 (en) 1998-06-10 2003-03-25 Merlot Communications, Inc. Method for initializing and allocating bandwidth in a permanent virtual connection for the transmission and control of audio, video, and computer data over a single network fabric
FI106832B (fi) * 1998-06-10 2001-04-12 Nokia Networks Oy Suurinopeuksinen datasiirto matkaviestinjärjestelmässä
US6085270A (en) * 1998-06-17 2000-07-04 Advanced Micro Devices, Inc. Multi-channel, multi-rate isochronous data bus
US6496504B1 (en) 1998-08-06 2002-12-17 Ricoh Company, Ltd. Smart allocation of bandwidth for multiple independent calls on a digital network
US6728263B2 (en) * 1998-08-18 2004-04-27 Microsoft Corporation Dynamic sizing of data packets
US6295453B1 (en) 1998-10-07 2001-09-25 Telefonaktiebolaget Lm Ericsson (Publ) Multi-full rate channel assignment for a cellular telephone system
JP2000175189A (ja) * 1998-12-07 2000-06-23 Univ Tokyo 動画符号化方法およびそれに用いる動画符号化装置
JP3454175B2 (ja) 1998-12-24 2003-10-06 日本ビクター株式会社 画像情報送出装置
FI106998B (fi) * 1999-01-15 2001-05-15 Nokia Mobile Phones Ltd Bittinopeuden ohjaus multimedialaitteessa
US7016337B1 (en) 1999-03-02 2006-03-21 Cisco Technology, Inc. System and method for multiple channel statistical re-multiplexing
US6473442B1 (en) 1999-04-12 2002-10-29 Telefonaktiebolaget Lm Ericsson (Publ) Communications system and method for matching and balancing the bit rates of transport channels to the bit rate of a physical channel
KR100335441B1 (ko) 1999-05-01 2002-05-04 윤종용 다중 비디오 디코딩 장치 및 그 방법
KR100352981B1 (ko) 1999-05-21 2002-09-18 유혁 엠펙-1 데이터 전송 장치 및 그 방법
KR100608042B1 (ko) 1999-06-12 2006-08-02 삼성전자주식회사 멀티 미디어 데이터의 무선 송수신을 위한 인코딩 방법 및그 장치
US6262829B1 (en) 1999-07-29 2001-07-17 Hewlett-Packard Co. Method of digital grayscale control using modulation of a slow-acting light source
US6680955B1 (en) * 1999-08-20 2004-01-20 Nokia Networks Oy Technique for compressing a header field in a data packet
FI107680B (fi) 1999-12-22 2001-09-14 Nokia Oyj Menetelmä videokuvien lähettämiseksi, tiedonsiirtojärjestelmä, lähettävä videopäätelaite ja vastaanottava videopäätelaite
CN101364837B (zh) 2000-01-14 2016-02-03 交互数字技术公司 用于码分多址通信的设备和方法
GB0000873D0 (en) * 2000-01-14 2000-03-08 Koninkl Philips Electronics Nv Interconnection of audio/video devices
US6996069B2 (en) * 2000-02-22 2006-02-07 Qualcomm, Incorporated Method and apparatus for controlling transmit power of multiple channels in a CDMA communication system
JP2001245268A (ja) 2000-02-29 2001-09-07 Toshiba Corp コンテンツ伝送システム及びコンテンツ処理装置
EP1146713B1 (en) * 2000-03-03 2005-04-27 NTT DoCoMo, Inc. Method and apparatus for packet transmission with header compression
US6993009B2 (en) * 2000-03-10 2006-01-31 Hughes Electronics Corporation Method and apparatus for deriving uplink timing from asynchronous traffic across multiple transport streams
US20020114388A1 (en) 2000-04-14 2002-08-22 Mamoru Ueda Decoder and decoding method, recorded medium, and program
US7680912B1 (en) 2000-05-18 2010-03-16 thePlatform, Inc. System and method for managing and provisioning streamed data
US6535043B2 (en) * 2000-05-26 2003-03-18 Lattice Semiconductor Corp Clock signal selection system, method of generating a clock signal and programmable clock manager including same
US7292772B2 (en) 2000-05-29 2007-11-06 Sony Corporation Method and apparatus for decoding and recording medium for a coded video stream
US7274679B2 (en) * 2000-06-22 2007-09-25 Mati Amit Scalable virtual channel
US7149549B1 (en) 2000-10-26 2006-12-12 Ortiz Luis M Providing multiple perspectives for a venue activity through an electronic hand held device
US6529527B1 (en) 2000-07-07 2003-03-04 Qualcomm, Inc. Method and apparatus for carrying packetized voice and data in wireless communication networks
JP4337244B2 (ja) 2000-07-25 2009-09-30 ソニー株式会社 Ｍｐｅｇ画像ストリームのデコード装置およびデコード方法
WO2002015564A1 (en) * 2000-08-16 2002-02-21 Koninklijke Philips Electronics N.V. Method of playing multimedia applications
WO2002015591A1 (en) 2000-08-16 2002-02-21 Koninklijke Philips Electronics N.V. Method of playing multimedia data
CN100420211C (zh) 2000-08-23 2008-09-17 皇家菲利浦电子有限公司 通信系统和设备
SE517245C2 (sv) 2000-09-14 2002-05-14 Ericsson Telefon Ab L M Synkronisering av audio- och videosignaler
US6747964B1 (en) * 2000-09-15 2004-06-08 Qualcomm Incorporated Method and apparatus for high data rate transmission in a wireless communication system
KR20020043139A (ko) 2000-12-01 2002-06-08 윤종용 이동통신시스템에서 고속 데이터 서비스를 위한 스케쥴링방법
US6920118B2 (en) * 2000-12-20 2005-07-19 Lucent Technologies Inc. Method and apparatus for communicating heterogeneous data traffic
US6904059B1 (en) * 2001-03-06 2005-06-07 Microsoft Corporation Adaptive queuing
US6859500B2 (en) * 2001-03-20 2005-02-22 Telefonaktiebolaget Lm Ericsson Run-length coding of non-coded macroblocks
US20030016702A1 (en) 2001-03-30 2003-01-23 Bender Paul E. Method and system for maximizing standby time in monitoring a control channel
WO2002085016A1 (en) * 2001-04-11 2002-10-24 Cyber Operations, Llc System and method for network delivery of low bit rate multimedia content
WO2002087212A2 (en) * 2001-04-20 2002-10-31 France Telecom Research And Development L.L.C. Replacing commercials according to location and time
US7230941B2 (en) 2001-04-26 2007-06-12 Qualcomm Incorporated Preamble channel decoding
US20020194606A1 (en) * 2001-06-14 2002-12-19 Michael Tucker System and method of communication between videoconferencing systems and computer systems
JP2003046949A (ja) * 2001-07-30 2003-02-14 Hitachi Ltd データ多重化方法、データ記録媒体、データ記録装置及びデータ記録プログラム
US7327789B2 (en) 2001-08-06 2008-02-05 Matsushita Electric Industrial Co., Ltd. Decoding apparatus, decoding method, decoding program, and decoding program storage medium
JP4647149B2 (ja) * 2001-08-06 2011-03-09 独立行政法人情報通信研究機構 トランスポートストリームの送信装置および受信装置
KR100885904B1 (ko) * 2001-08-10 2009-02-26 가부시키가이샤 한도오따이 에네루기 켄큐쇼 레이저 어닐링장치 및 반도체장치의 제작방법
US20080002669A1 (en) 2001-09-14 2008-01-03 O'brien Ray Packet voice gateway
US6968091B2 (en) * 2001-09-18 2005-11-22 Emc Corporation Insertion of noise for reduction in the number of bits for variable-length coding of (run, level) pairs
US7336680B2 (en) 2001-09-18 2008-02-26 Scientific-Atlanta, Inc. Multi-carrier frequency-division multiplexing (FDM) architecture for high speed digital service
US7075946B2 (en) 2001-10-02 2006-07-11 Xm Satellite Radio, Inc. Method and apparatus for audio output combining
CN1511420A (zh) 2001-11-09 2004-07-07 ���µ�����ҵ��ʽ���� 运动图像编码方法和装置
US7453843B2 (en) * 2001-12-11 2008-11-18 Texas Instruments Incorporated Wireless bandwidth aggregator
US7292690B2 (en) 2002-01-02 2007-11-06 Sony Corporation Video scene change detection
DE10300048B4 (de) 2002-01-05 2005-05-12 Samsung Electronics Co., Ltd., Suwon Verfahren und Vorrichtung zur Bildcodierung und -decodierung
US7130313B2 (en) 2002-02-14 2006-10-31 Nokia Corporation Time-slice signaling for broadband digital broadcasting
US7596179B2 (en) 2002-02-27 2009-09-29 Hewlett-Packard Development Company, L.P. Reducing the resolution of media data
FI114679B (fi) 2002-04-29 2004-11-30 Nokia Corp Satunnaisaloituspisteet videokoodauksessa
FR2839407B1 (fr) 2002-05-02 2004-12-17 Canon Kk Procede et dispositif d'ajustement de la taille maximale des sequences d'information transmises dans un reseau de telecommunications
US8699505B2 (en) * 2002-05-31 2014-04-15 Qualcomm Incorporated Dynamic channelization code allocation
US20030224806A1 (en) * 2002-06-03 2003-12-04 Igal Hebron System and method for network data quality measurement
US6956875B2 (en) * 2002-06-19 2005-10-18 Atlinks Usa, Inc. Technique for communicating variable bit rate data over a constant bit rate link
US7486678B1 (en) 2002-07-03 2009-02-03 Greenfield Networks Multi-slice network processor
RU2332705C2 (ru) 2002-07-16 2008-08-27 Нокиа Корпорейшн Способ предоставления возможности компенсации задержки передачи пакетов при потоковой передаче мультимедийных данных
CN1221132C (zh) * 2002-07-30 2005-09-28 华为技术有限公司 实现多种视音频流格式转换的装置和方法
US7567509B2 (en) 2002-09-13 2009-07-28 Dialogic Corporation Methods and systems for jitter minimization in streaming media
TW569556B (en) 2002-10-04 2004-01-01 Avid Electronics Corp Adaptive differential pulse-code modulation compression encoding/decoding method capable of fast recovery and apparatus thereof
US7191384B2 (en) * 2002-10-17 2007-03-13 Qualcomm Incorporated Method and apparatus for transmitting and receiving a block of data in a communication system
US7068708B2 (en) * 2002-12-13 2006-06-27 Motorola, Inc. Method and receiving unit for demodulating a multi-path signal
JP2004226272A (ja) 2003-01-23 2004-08-12 Seiko Epson Corp シミ欠陥の検出方法及び装置
EP1608094A4 (en) 2003-03-10 2010-04-28 Panasonic Corp OFDM SIGNAL TRANSMISSION METHOD, TRANSMISSION DEVICE AND RECEPTION DEVICE
US7400889B2 (en) 2003-04-01 2008-07-15 Telefonaktiebolaget Lm Ericsson (Publ) Scalable quality broadcast service in a mobile wireless communication network
US7535876B2 (en) 2003-04-01 2009-05-19 Alcatel-Lucent Usa Inc. Method of flow control for HSDPA and HSUPA
CN1774715A (zh) 2003-04-14 2006-05-17 皇家飞利浦电子股份有限公司 用于对音频－视频流执行自动配音的系统和方法
US7391717B2 (en) * 2003-06-30 2008-06-24 Microsoft Corporation Streaming of variable bit rate multimedia content
KR100651566B1 (ko) * 2003-08-26 2006-11-28 삼성전자주식회사 이동통신 단말기에서 출력 버퍼링을 이용한 멀티미디어재생 장치 및 그 제어 방법
EP1662793B1 (en) * 2003-09-02 2020-01-15 Sony Corporation Content reception device, video/audio output timing control method, and content providing system
US9351013B2 (en) * 2003-11-13 2016-05-24 Qualcomm Incorporated Selective and/or scalable complexity control for video codecs
US20050138251A1 (en) 2003-12-18 2005-06-23 Fanning Blaise B. Arbitration of asynchronous and isochronous requests
WO2005074316A2 (en) 2004-01-29 2005-08-11 Chaoticom, Inc. Systems and methods for providing digital content and caller alerts to wireless network-enabled devices
US7599435B2 (en) 2004-01-30 2009-10-06 Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. Video frame encoding and decoding
US7558221B2 (en) * 2004-02-13 2009-07-07 Seiko Epson Corporation Method and system for recording videoconference data
US7586882B2 (en) * 2004-03-19 2009-09-08 Telefonaktiebolaget Lm Ericsson (Publ) Higher layer packet framing using RLP
US7530089B1 (en) 2004-03-29 2009-05-05 Nortel Networks Limited System and method for improving video quality using a constant bit rate data stream
US7865255B2 (en) * 2004-03-31 2011-01-04 Mstar Semiconductor, Inc. Audio buffering system and method of buffering audio in a multimedia receiver
CN100576820C (zh) * 2004-05-07 2009-12-30 艾格瑞系统有限公司 与帧集合一起使用的mac报头压缩
ATE508567T1 (de) 2004-05-13 2011-05-15 Qualcomm Inc Zustellung von informationen über einen kommunikationskanal

Also Published As

Publication number Publication date
CA2565977C (en) 2013-06-11
CA2566124C (en) 2014-09-30
ES2323011T3 (es) 2009-07-03
TWI353759B (en) 2011-12-01
WO2005114943A3 (en) 2006-01-19
CN1973515A (zh) 2007-05-30
KR20070014200A (ko) 2007-01-31
JP4448171B2 (ja) 2010-04-07
WO2005114950A1 (en) 2005-12-01
JP2007537682A (ja) 2007-12-20
BRPI0510953A (pt) 2007-11-20
CA2811040A1 (en) 2005-12-01
CN1985477B (zh) 2012-11-07
EP1757027A1 (en) 2007-02-28
KR100870215B1 (ko) 2008-11-24
WO2005114919A1 (en) 2005-12-01
KR20090039809A (ko) 2009-04-22
JP4361585B2 (ja) 2009-11-11
BRPI0510952A (pt) 2007-11-20
MXPA06013193A (es) 2007-02-14
EP1751956A2 (en) 2007-02-14
EP2262304A1 (en) 2010-12-15
JP2007537683A (ja) 2007-12-20
KR100918596B1 (ko) 2009-09-25
KR20080084866A (ko) 2008-09-19
TW200623737A (en) 2006-07-01
CA2565977A1 (en) 2005-12-01
DE602005023983D1 (de) 2010-11-18
JP5356360B2 (ja) 2013-12-04
CN1973515B (zh) 2013-01-09
MXPA06013210A (es) 2007-02-28
CN1977516A (zh) 2007-06-06
MXPA06013211A (es) 2007-03-01
CA2771943C (en) 2015-02-03
KR20070014201A (ko) 2007-01-31
KR101068055B1 (ko) 2011-09-28
EP1751956B1 (en) 2011-05-04
US9717018B2 (en) 2017-07-25
DE602005013517D1 (de) 2009-05-07
WO2005114943A2 (en) 2005-12-01
KR101049701B1 (ko) 2011-07-15
BRPI0510952B1 (pt) 2019-09-03
US8089948B2 (en) 2012-01-03
ATE484157T1 (de) 2010-10-15
EP1751987A1 (en) 2007-02-14
US10034198B2 (en) 2018-07-24
EP2214412A2 (en) 2010-08-04
JP2011142616A (ja) 2011-07-21
BRPI0510961A (pt) 2007-11-20
DE602005027837D1 (de) 2011-06-16
TWI381681B (zh) 2013-01-01
KR20070013330A (ko) 2007-01-30
CA2771943A1 (en) 2005-12-01
ATE426988T1 (de) 2009-04-15
CA2566125A1 (en) 2005-12-01
US8855059B2 (en) 2014-10-07
TW200618564A (en) 2006-06-01
EP3331246A1 (en) 2018-06-06
CN102984133B (zh) 2016-11-23
US20050259613A1 (en) 2005-11-24
JP2007537681A (ja) 2007-12-20
JP2007537684A (ja) 2007-12-20
EP2182734B1 (en) 2013-12-18
MXPA06013186A (es) 2007-02-14
US20140362740A1 (en) 2014-12-11
MY139431A (en) 2009-09-30
TW200618544A (en) 2006-06-01
CA2566125C (en) 2012-01-24
CN1969562B (zh) 2011-08-03
CN1985477A (zh) 2007-06-20
EP1751987B1 (en) 2010-10-06
US20050259694A1 (en) 2005-11-24
BRPI0510962A (pt) 2007-11-20
JP4554680B2 (ja) 2010-09-29
CN102984133A (zh) 2013-03-20
EP1751955A1 (en) 2007-02-14
CN1969562A (zh) 2007-05-23
DE602005011611D1 (de) 2009-01-22
EP1757027B1 (en) 2008-12-10
MY142161A (en) 2010-10-15
US9674732B2 (en) 2017-06-06
TW201145943A (en) 2011-12-16
KR20070023731A (ko) 2007-02-28
CA2566124A1 (en) 2005-12-01
MY141497A (en) 2010-04-30
US20050259623A1 (en) 2005-11-24
US20050259690A1 (en) 2005-11-24
EP2262304B1 (en) 2012-08-22
ATE417436T1 (de) 2008-12-15
EP1751955B1 (en) 2009-03-25
ES2318495T3 (es) 2009-05-01
ATE508567T1 (de) 2011-05-15
CN1977516B (zh) 2010-12-01
KR100871305B1 (ko) 2008-12-01
EP2182734A1 (en) 2010-05-05
EP2592836A1 (en) 2013-05-15
CA2566126A1 (en) 2005-12-01
TWI394407B (zh) 2013-04-21
US20150016427A1 (en) 2015-01-15
ES2354079T3 (es) 2011-03-09
WO2005115009A1 (en) 2005-12-01
KR100906586B1 (ko) 2009-07-09
EP2214412A3 (en) 2012-11-14

Similar Documents

Publication Publication Date Title
ES2366192T3 (es) Envío de información por un canal de comunicación.
TWI416900B (zh) 用以配置資訊至一通信系統之通道之方法及裝置
HK1106360A (en) Delivery of information over a communication channel
HK1107462A (en) Method and apparatus for allocation of information to channels of a communication system