ES2270631T3 - Metodo y dispositivo para reducir el tiempo de proceso de datos en redes de comunicacion. - Google Patents
Metodo y dispositivo para reducir el tiempo de proceso de datos en redes de comunicacion. Download PDFInfo
- Publication number
- ES2270631T3 ES2270631T3 ES99965453T ES99965453T ES2270631T3 ES 2270631 T3 ES2270631 T3 ES 2270631T3 ES 99965453 T ES99965453 T ES 99965453T ES 99965453 T ES99965453 T ES 99965453T ES 2270631 T3 ES2270631 T3 ES 2270631T3
- Authority
- ES
- Spain
- Prior art keywords
- data
- protocol
- protocol layer
- layer
- data packets
- 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
Links
Classifications
-
- 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
- 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
-
- 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/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Método para mejorar un tiempo de procesamiento de datos recibidos en aplicaciones orientadas por paquetes en una transmisión de datos entre un transmisor y un receptor cada uno de ellos comprendiendo una capa primera y una segunda subyacente de protocolo a través de una red de comunicación, en el que: - los datos de la primera capa de protocolo son liberados en la segunda capa de protocolo en el transmisor (20); - los datos de la primera capa de protocolo están divididos en paquetes de datos consecutivos de la segunda capa de protocolo generando una secuencia de paquetes de datos consecutivos con números de secuencia, por lo que un paquete de datos de la segunda capa de protocolo contiene datos de solamente un paquete de datos de la primera capa de protocolo (30); - los paquetes de datos de la segunda capa de protocolo se transmiten a través de la red de comunicación (50); - los paquetes de datos de la segunda capa de protocolo recibidos en el receptor (60) se clasifican en la segunda capade protocolo en la secuencia de paquetes de datos consecutivos por medio de los números de secuencia; - los paquetes de datos recibidos se asignan a paquetes de datos de la primera capa de protocolo en la segunda capa de protocolo; - después de haber sido generado completamente un paquete de datos de la primera capa de protocolo (100), dicho paquete de datos es examinado para la asociación a un flujo de datos y es liberado en la primera capa de protocolo (110);
Description
Método y dispositivo para reducir el tiempo de
proceso de datos en redes de comunicación.
El invento se refiere a un método y dispositivo
para mejorar el tiempo de proceso de aplicaciones orientadas a datos
recibidos por paquetes en la transmisión por redes de comunicación,
en especial a través de una red IP y de una red de comunicación
móvil tal como el Sistema Global para Comunicación Móvil (GSM), el
Sistema de Telecomunicación Móvil Universal (UMTS) o el Servicio
General de Radio por Paquetes (GPRS).
En el documento A-4.703.475 el
problema de minimizar el retraso de los mensajes es tratado
distribuyendo paquetes de mensaje a través de varios enlaces físicos
y reordenando los paquetes recibidos en una base de mensaje, en la
que un mensaje es asignado a un canal lógico. Para este fin una capa
de sesión asigna el mensaje recibido a un canal lógico disponible y
pasa el mensaje al nivel de paquete, que divide el mensaje en
paquetes de datos y añade un encabezamiento que incluye la
información sobre el número de canal lógico asignado. Se introduce
un enlace adicional múltiple para añadir un encabezamiento
multienlace que incluye un número de secuencia del canal lógico, el
cual define el orden secuencial de los paquetes de datos en el canal
lógico. De esta forma los paquetes de datos establecidos se
transmiten en una red. En el receptor los paquetes de datos
recibidos son clasificados de acuerdo con el número de canal lógico
y el número de secuencia de canal lógico y son pasados a la capa de
paquetes cuando se consigue el orden secuencial correcto en el canal
lógico particular.
El documento "Montaje de nuevo de paquetes
durante la pérdida de celda" de G. J. Armitage y K. M. Adams en
la Red IEEE. La revista de Comunicaciones por Ordenador, volumen 7,
nº 5, 1 de septiembre de 1993, páginas 26-34 explica
cómo volver a montar los paquetes de datos de una capa de protocolo
superior de los datos recibidos de una capa de protocolo inferior.
Con este objeto, en el lado del emisor un paquete de datos se
segmenta en paquetes (celdas) de datos menores y cada celda obtiene
un encabezamiento con una entrada sobre el tipo de transporte de la
información, que es recibida de los paquetes de datos de la capa de
protocolo superior. La información puede ser el comienzo del mensaje
(BOM), la continuación del mensaje (COM) o el final del mensaje
(EOM). Adicionalmente se añade una entrada MID en cada celda para
reconocer la correspondencia con un paquete de un nivel superior.
Sobre la base de esta información se vuelve a montar un paquete de
datos de una capa superior en el receptor, en el que son ignoradas
las celdas COM o EOM con el valor MID que no correspondan a un
paquete actual vuelto a montar. El procedimiento de montaje de nuevo
se interrumpe cuando se recibe un paquete fuera de orden. Éste es
reconocido cuando el número de secuencia no es el siguiente.
Se define un protocolo como una totalidad de
todas las declaraciones entre instancias asociadas con el fin de una
comunicación común. De esta forma, un protocolo de unión común es un
requisito previo para un intercambio de datos entre dos nodos de la
red de comunicación. Se requiere que los protocolos estén definidos
universalmente y sean compatibles entre sí, porque solamente sobre
una base uniforme es posible enlazar diferentes redes entre sí en
secuencia para comunicarse también más allá de los límites de un
sistema.
Desde el punto de vista de una estructura
modular el protocolo completo de una comunicación es dividido en
capas. Cada capa resuelve las tareas asignadas a ella por medio de
un protocolo propio. Una comunicación entre las capas contiguas está
garantizada a través de interfaces claramente definidos. En este
caso, una capa n está enlazada con la capa n+1 directamente en la
parte superior de ella prestando servicios a dicha capa, y a la capa
n-1 directamente debajo de dicha capa utilizando los
servicios de dicha capa. Adicionalmente existe una comunicación con
la capa n de la comunicación asociada utilizando los servicios de
todas las capas inferiores. Así, el flujo de datos lógicos de las
unidades PDU de datos de protocolo se realiza en respectivamente una
capa de protocolo. En el lado receptor los datos se procesan en una
secuencia inversa, es decir los datos son liberados de las capas
inferiores a las capas de protocolo directamente en la parte
superior de ellas.
La estructura de la pila de protocolos puede
variar en respuesta a la red física y a la aplicación. La variación
tiene, sin embargo, que estar dentro de límites compatibles para
garantizar la comunicación entre redes diferentes. La pila de
protocolos normalizada para aplicaciones de Internet es la pila de
protocolos TCP/IP (protocolo de control de transmisión/protocolo
internet). Consta de cuatro capas. La capa más alta -la capa de
aplicación- comprende protocolos de aplicación. Por ejemplo, un
protocolo de transporte, el denominado TCP (protocolo de control de
transmisión) está dispuesto directamente debajo de éste. El
protocolo de Internet -el denominado IP- forma la capa de la red.
Las dos capas más bajas -la capa de enlace y la capa física- pueden
combinarse para formar el término capas orientadas a la red, ya que
están definidas específicamente en respuesta a la red dispuesta
debajo de ellas. En la figura 2 están ilustradas dicha estructura
modular de la pila de protocolos TCP/IP y los enlaces de
comunicación entre las respectivas capas.
El protocolo de transporte TCP ofrece un
servicio de transmisión fiable para un flujo de bytes. La fiabilidad
aquí se refiere a estar libre de errores, mantenimiento de
secuencias y protección contra pérdida de datos y duplicados. La
corrección de errores se realiza usando el método denominado ARQ
(solicitud de repetición automática). Una copia de los paquetes que
han de enviarse se genera en el lado de la transmisión y se guarda
hasta que el paquete de datos enviado es confirmado positivamente
por el lado opuesto. El receptor examina el paquete recibido y
confirma la correcta recepción por medio de una confirmación
positiva y rechaza la recepción de un paquete recibido
incorrectamente. Respecto a esto se ha de advertir de que el TCP no
permite la transmisión de confirmaciones negativas. La repetición de
paquetes transmitidos incorrectamente se efectúa por medio de un
mecanismo con base en las confirmaciones positivas, es decir si no
existe confirmación positiva el transmisor deduce en ciertas
circunstancias que un paquete no ha sido recibido.
El flujo de bytes que ha de transmitirse, que es
pasado desde la capa de aplicación a la capa TCP, es dividido por el
TCP en segmentos que son transmitidos como datagramas IP. Un
datagrama IP designa un paquete de datos que se está formado de
acuerdo con las reglas del protocolo IP. La característica del
datagrama consiste en que el intercambio de datos que se realiza
usando datagramas no es fiable. De esta forma el IP no garantiza que
un paquete sea transmitido realmente a un receptor. También los
datagramas IP pueden estar confundidos en su secuencia, o pueden
llegar al receptor en duplicados. Dentro de los límites de este
concepto, está, sin embargo, la tarea del TCP de detectar la
transmisión defectuosa y de corregir los errores producidos.
Los datagramas IP se transmiten, además, de
acuerdo con el principio de jerarquía, a la capa de enlace dispuesta
directamente debajo. Dicha capa recibe los datagramas IP y los
organiza en las denominadas tramas. Esto se produce por medio de un
método que es conocido por el nombre de entramado, es decir la capa
de enlace empaqueta un datagrama IP en una o más tramas, en el que
las tramas están limitadas por el uso de combinaciones de bits
específicas. Está especificado en cuanto a qué combinaciones de bits
están referidas al separador de comienzo, la denominada marca
inicial, y a cuál el separador final, la denominada marca final, de
una trama.
Aparte del entramado, la capa de enlace realiza
dos tareas adicionales. La capa de enlace también es responsable de
la detección de errores. De este modo, las tramas transmitidas
incorrectamente son rechazadas de forma usual por el receptor de la
capa de enlace. Para este fin el paquete de datos está provisto de
un campo para aplicar un denominado código cíclico, la denominada
secuencia de comprobación FCS o la comprobación cíclica de
redundancia CRC. La idea es interpretar un paquete de datos como un
polinomio. El transmisor suplementa el paquete de datos de tal forma
que el receptor recibe el resto 0 por la división a través de un
denominado polinomio generador. De esta forma se realiza la
detección de errores. La capa de enlace también efectúa
opcionalmente la corrección de errores. Esto se produce por paquetes
recibidos repetidos incorrectamente, por ejemplo, usando el método
ARQ.
Los protocolos de la capa de enlace se aplican
usualmente entre nodos de red contiguos directamente de forma
física. Para este fin se han definido varios protocolos
alternativos. En cuanto a qué protocolo se aplica entre dos nodos de
red, depende de la red por medio de la cual los dos nodos de red
están enlazados. El conocido protocolo
punto-a-punto, el PPP, constituye un
ejemplo de protocolo de la capa de enlace. El PPP realiza las dos
primeras tareas de la capa de enlace, el entramado y la detección de
errores. Por tanto, el PPP no realiza una repetición de los paquetes
incorrectamente recibidos. Incluso aunque existe un modo específico
de puesta en práctica de trabajo del PPP en un denominado "modo
numerado" RFC 1663, usualmente no se usa.
Debido al hecho de que el PPP no es soporte de
una corrección por medio de la transmisión repetida de paquetes, o
debido a que el proceso sería ineficaz a altas tasas de errores de
transmisión, se aplica un protocolo adicional en redes que tienen
una tasa de errores especialmente alta en una transmisión de datos.
Por ejemplo, las redes de comunicaciones móviles son conocidas por
ser redes con grandes tasas de errores de transmisión. El GSM
(Sistema Global de Comunicaciones Móviles) y el GPRS (Servicio de
Radio General por Paquetes) deben clasificarse como tales. Un
protocolo adicional, el denominado RLP (protocolo de enlace por
radio) está aplicado en la capa de enlace de la red GSM. El RLP
segmenta el flujo de bytes recibido de la capa PPP en tramas, que
usualmente son menores que las tramas del nivel PPP. La corrección
de errores es tratada por el método ARQ en la base de dichas tramas.
La funcionalidad del ARQ requiere que las tramas estén numeradas
consecutivamente. Por lo tanto, cada trama recibe un número de
secuencia continuo claro durante el agrupamiento. En el estado de
las puestas en práctica actuales el flujo de bytes es segmentado de
forma transparente en tramas RLP y es empaquetado. Por eso sigue sin
considerarse de qué clases de datos, control de datos o datos
actuales se trata. La capa RLP sólo puede ver un flujo de bytes. Por
eso puede ocurrir que los datos de dos tramas diferentes PPP estén
combinadas en una trama RLP. La trama RLP recibe entonces la marca
final de la primera trama PPP e igualmente la marca final del
siguiente paquete PPP. La solución a este problema la proporciona el
documento EP 0.973.302 que aconseja examinar el flujo de bytes por
separadores en el emisor. Así, se establece una diferencia entre
los diferentes paquetes PPP al empaquetar el flujo de bytes en
paquetes RLP en el lado de transmisión evitando que datos de dos
paquetes PPP se combinen en un RLP.
La misma funcionalidad se realiza en la red GPRS
por medio del protocolo RLC, resultante de que ambos protocolos, el
RLP y el RLC son similares al HDLC según las normas ISO (control de
enlace de datos de alto nivel) ISO87 y que, por consiguiente, tienen
una estructura similar. Una diferencia entre los protocolos está en
la generación de las tramas.
El objeto de una estructura jerárquica es
desarrollar una estructura de protocolo, en la que las capas de
protocolo sean independientes entre sí en lo referente a un aspecto
horizontal. Por tanto, se consigue que aplicaciones diferentes y
protocolos de transporte diferentes son transmitidos mediante el
mismo protocolo de red, tal como el protocolo IP de Internet.
Además, permite que una capa de protocolo IP pueda funcionar en
diferentes plataformas físicas. Por lo tanto, los datagramas IP
pueden transmitirse a través de redes físicas diferentes, tales como
GSM, Internet, GPRS.
Al usuario la comunicación en los niveles de
protocolo permanece sustancialmente invisible. Espera que el sistema
disponible sea soporte de los diferentes servicios, tales como la
transmisión y recepción de correos, flujo de datos o de lectura de
páginas web. Los datos hechos disponibles para la transmisión
frecuentemente exceden el tamaño de los paquetes que pueden ser
transmitidos en un enlace físico. Por esta razón, se divide un
mensaje en paquetes más pequeños, que se disponen consecutivamente
para una transmisión. La división de los datos es parte del
formateo. El formateo de los datos se realiza en cada capa de
protocolo. En ciertas capas de protocolo, tales como la capa RLP, se
produce una división de datos, es decir dichos datos se subdividen
en bloques de datos menores. Los bloques de datos tienen nombres
diferentes en las diferentes capas, por ejemplo, se llaman
datagramas en la capa del protocolo IP, y tramas en la capa de
enlace. Además, los bloques de datos, que no se refieren
individualmente a una capa de protocolo, son designados mediante el
término paquete de datos.
El formateo de los datos comprende en particular
la adición de datos de control que son característicos de cada capa
de protocolo. En la mayoría de los casos los datos de control se
adjuntan al comienzo de un paquete de datos en forma del denominado
encabezamiento y/o al final en forma del denominado pie de página.
Los datos reales están contenidos en el campo de los datos de
usuario. Dicho mecanismo se explica a continuación con más detalle
por medio de una pila de protocolos TCP/IP.
De acuerdo con la figura 3 los datos de usuario
se segmentan en la capa de aplicación, y se añade información de
control a cada paquete de datos. Dichos paquetes de datos son por lo
tanto enviados a la capa de transporte TCP. Dicha capa añade sus
datos de control en forma de un encabezamiento. Dichos datos son
pasados a una capa de red en la que, por ejemplo, el IP contiene los
datos de control pertinentes tales como información de enrutamiento.
De este modo se forma un datagrama IP, que en el siguiente paso es
pasado a una capa de enlace. Los protocolos de la capa de enlace,
tales como por ejemplo el PPP, procesan los datos recibidos
añadiendo información de control propia tal como los separadores.
Los paquetes de datos que se generan en este nivel se denominan
tramas. Tales tramas se transmiten después a través de la red
disponible. Sucede que los paquetes de datos llegan al receptor de
una cierta capa en una secuencia diferente. Puede ser la tarea del
receptor de esta capa reproducir la secuencia transmitida. Ésta es
la tarea de, por ejemplo, un receptor un TCP o RCP, aunque no, por
ejemplo, de un receptor IP.
El mecanismo de empaquetamiento de los datos en
las capas de protocolo se conoce con el término de encapsulamiento.
La función inversa se denomina desencapsulamiento y se realiza en el
lado receptor.
En lo que sigue, los paquetes de datos, los
cuales bien se refieren a las tramas RLP o a las tramas RLC o
también a las tramas PPP, trabajando cada una en un modo numerado,
se denominan con el término general de trama L2ARQ.
Los datos de usuario se envían al receptor en la
forma de las tramas L2ARQ. Al mismo tiempo, las tramas L2ARQ son
almacenadas en una memoria intermedia del transmisor. Esto parece
necesario en el caso de que el paquete esté repetido. Por medio de
los números consecutivos en las tramas L2ARQ un receptor determina
si un paquete ha sido perdido durante la transmisión. Si se ha
perdido una trama L2ARQ, se inicia la repetición de dicha trama
L2ARQ. Por medio de un mecanismo correspondiente el transmisor
recibe un mensaje sobre el error producido, y se coge de la memoria
intermedia el paquete con el número correspondiente y se transmite
de nuevo. Si un paquete se transmite al receptor con éxito, se
retira de la memoria intermedia en el lado transmisor.
El mecanismo descrito se refiere al denominado
modo numerado. Dicho modo realiza un servicio fiable asegurando una
transmisión de datos fiable desde un transmisor a un receptor.
También existe el denominado modo no numerado. En dicho modo no se
realiza corrección de errores usando el proceso ARQ. De esta forma
el modo realiza un servicio no fiable.
Sin embargo, la repetición de los paquetes
implica que los paquetes llegados en el lado receptor son provistos
en una secuencia que no se corresponde con la secuencia
transmitida.
En los procedimientos de desarrollo actuales la
tarea del protocolo de la capa de enlace, siempre que sea soporte
del ARQ, es traer las tramas L2ARQ a la secuencia transmitida. Esto
implica que, por ejemplo, los paquetes RLP recibidos se acumulen en
una memoria intermedia en el lado receptor hasta que se reproduzca
la secuencia de los paquetes RLP. Esto significa que una trama RLP
es liberada en la capa directamente en su parte superior solamente
cuando dicha trama ha sido completamente recibida y cuando dicha
trama es la siguiente en la secuencia. Si, por ejemplo, se repite
una trama debido a un error, todas las tramas siguientes ya
recibidas son guardadas en la memoria intermedia hasta que la trama
repetida haya sido recibida sin errores. Solamente cuando los
paquetes RLP estén dispuestos en una secuencia correspondiente, que
se genera por medio de una secuencia de números, son
consecuentemente pasados a la capa PPP. Antes de esto se borra la
información de control.
El receptor de la capa PPP realiza una
identificación de las tramas PPP. Con este fin se buscan los
separadores. Cuando se ha reconocido que una trama PPP está
completa, el datagrama IP recibido es pasado a la capa IP que
después pasa el segmento TCP recibido a la capa de protocolo
TCP.
Debido al hecho de que las tramas L2ARQ se
almacenan temporalmente en la capa de enlace que permite llevar
dichas tramas a la secuencia correspondiente, pueden producirse
altos tiempos de procesamiento. En particular, esto tiene un efecto
negativo sobre las aplicaciones que son sensibles a los retrasos de
tiempo. Retrasos de tiempo largos en cualquier caso perjudican el
procesamiento eficiente de datos. En el caso de las aplicaciones que
son sensibles a los retrasos esto incluso puede causar la
interrupción de una ejecución de un trabajo. Adicionalmente, este
método requiere una gran memoria intermedia en las correspondientes
capas de protocolo, especialmente sin embargo, en la capa de
protocolo RLP, debido a que los paquetes están temporalmente
guardados en la memoria intermedia en dicho nivel hasta que la
secuencia solicitada haya sido reproducida. Sin embargo, grandes
tiempos de almacenamiento de datos dan lugar a grandes retrasos de
tiempo para el procesamiento de datos en una estructura de
protocolos jerarquizada.
Por lo tanto, es objeto del presente invento
proporcionar un método y un dispositivo que garantice un
procesamiento más eficaz de los datos por el receptor aplicaciones
orientadas por paquetes en una transmisión de datos. En especial, es
un objeto del invento reducir la necesidad del espacio de memoria en
el lado receptor.
De acuerdo con el invento, dicho objeto es
provisto por la enseñanza de la reivindicación 1 de la patente y por
la enseñanza de la reivindicación 24 de la patente.
Es ventajoso que no se produzcan largos tiempos
de almacenamiento temporal a lo largo de la transmisión directa de
los paquetes generados completamente en la capa de enlace a la capa
de protocolo dispuesta directamente en la parte superior de
ella.
Por esta razón también ha resultado ser
ventajoso que los datos recibidos se transmitan más rápidamente a la
capa de aplicación, lo que garantiza un modo más estable de trabajo
de las aplicaciones sensibles a los retrasos.
Otra ventaja consiste en la reducción de la
capacidad de almacenamiento necesaria en la capa de protocolo
correspondiente en el lado receptor, ya que los datos recibidos no
se guardan en la memoria intermedia hasta que se disponga una
secuencia correspondiente de los datos recibidos, pero los paquetes
generados de forma completa son liberados directamente en la capa de
protocolo en la parte superior de ella, incluso si algunos paquetes
de datos no han sido posiblemente recibidos antes.
De las reivindicaciones 2 a 23 y de la
reivindicación 25 de la patente se pueden deducir formas ventajosas
adicionales del invento.
A continuación se explica el invento con más
detalle por medio de realizaciones y figuras, en las que:
- la figura 1 muestra un diagrama de flujos del
método de acuerdo con el invento,
- la figura 2 muestra una ilustración de capas
de protocolo en Internet,
- la figura 3 muestra un diagrama esquemático de
datos de usuario,
- la figura 4 muestra una ilustración de un
sistema de red,
- la figura 5 muestra un diagrama del Protocolo
de Internet,
- la figura 6 muestra una ilustración de una
trama RLP,
la figura 7 muestra una ilustración de un modo
interflujo, y
- la figura 8 muestra una ilustración de un modo
intraflujo.
A continuación se explica el invento por medio
de la figura 1 y de la reivindicación 1 de la patente.
De acuerdo con la figura 1 se disponen los
paquetes de datos de una primera capa de protocolo en un lado
transmisor 10 y son consecuentemente pasados a una segunda capa de
protocolo 20 directamente debajo de ella. Dicha capa empaqueta los
datos recibidos en paquetes de datos de la segunda capa de protocolo
30. Con respecto a esto se llama la atención sobre que un paquete de
datos de la segunda capa de protocolo no contiene los datos de dos
paquetes de datos diferentes de la primera capa de protocolo. Cada
paquete de datos de la segunda capa de protocolo recibe un único
número de secuencia. Los paquetes de datos de la segunda capa de
protocolo empaquetados de esta forma son pasados a una red
disponible en la secuencia actual 40 y son consecuentemente
transmitidos a través de la red 50. Los paquetes de datos
individuales de la segunda capa de protocolo son recibidos en el
lado receptor 60. Los paquetes de datos de la segunda capa de
protocolo recibidos son clasificados en una secuencia por medio del
número de secuencia 70 y se almacenan en la memoria intermedia
dispuesta 80. Se examinan en secuencia para reconocer los paquetes
de datos de la primera capa de protocolo 90. Si se recibe un paquete
de datos de la segunda capa de protocolo, primero se examina si este
paquete de datos contiene separadores de la primera capa de
protocolo. Si los contiene, se trata de una marca inicial o de una
marca final de un paquete de datos de la primera capa de protocolo.
En caso de una marca inicial, esto significa que los siguientes
paquetes de datos de la segunda capa de protocolo pertenecen a un
nuevo paquete de datos de la primera capa de protocolo. Los paquetes
de datos de la segunda capa de protocolo se guardan en la memoria
intermedia hasta que se haya recibido completamente un paquete de
datos de la primera capa de protocolo 100. Esto se detecta mediante
la recepción de un paquete de datos de la segunda capa de protocolo,
en la que el campo de datos contiene una marca final y además es la
siguiente en una secuencia. Solamente se libera un paquete de datos
generado completamente de la primera capa de protocolo a la capa de
protocolo directamente en la parte superior 110 de ella.
A continuación, se explica el invento por medio
de la reivindicación 24 de la patente.
Un formateamiento de paquetes de datos de una
primera capa de protocolo en una segunda capa de protocolo y su
disposición de acuerdo con una secuencia de transmisión es realizado
por unos medios para proporcionar paquetes de datos de una primera
capa de protocolo a una segunda capa de protocolo. Dichos paquetes
de datos se transmiten a través de una red provista de medios de
transmisión. Los medios de recepción para recibir los paquetes de
datos en el lado de recepción reciben los paquetes. Con medios de
clasificación para clasificar los paquetes de datos, los paquetes de
datos recibidos son dispuestos en una secuencia de paquetes de datos
consecutivos y se almacenan en una memoria intermedia durante el
almacenamiento temporal de los paquetes de datos recibidos de la
segunda capa de protocolo. Los paquetes de datos de la segunda capa
de protocolo son examinados en cuanto a si se puede reconocer un
paquete de datos de la primera capa de protocolo. Esto se realiza
usando medios de detección para detectar un paquete de datos
completamente combinado de la primera capa de protocolo. Por lo
tanto, se examina un paquete de datos generado de forma completa por
unos medios de examen para la asociación a un flujo de datos. Por lo
tanto, se libera se libera un paquete de datos examinado por unos
medios de liberación para liberar un paquete de datos generados de
forma completa en la primera capa de protocolo.
Un posible campo de aplicación del invento está
en el campo de las aplicaciones de Internet a través de una red
móvil de datos, tal como la GSM. A continuación se explica más
detalladamente una posible aplicación del invento por medio de una
realización, en la que el procesamiento de los datos se ilustra como
de la aplicación en el lado de transmisión hasta la liberación de
los paquetes de datos generados de forma completa en el lado de
recepción.
Para este fin se usa un sistema de red, que se
muestra de forma esquemática en la figura 4. En ella se ilustra
esquemáticamente una comunicación entre un abonado móvil, por
ejemplo, con una estación móvil, y un abonado integrado en una red
fija, el servidor. La parte superior de la figura muestra el enlace
físico con las correspondientes unidades de comunicación, y la parte
inferior constituye el enlace lógico con los protocolos
implicados.
La estación móvil MS puede, por ejemplo, ser un
ordenador portátil. Dicho ordenador portátil está conectado a través
de una función de adaptación a la terminal (TAF), cuya tarea es, por
ejemplo, realizada por la tarjeta PCMCIA (Asociación Internacional
de Tarjetas de Memoria de Ordenador Personal), con la estación móvil
MS, por ejemplo, un teléfono móvil. La estación móvil MS comunica
con una BTS (Estación Transceptora Base), que nuevamente comunica
con un BSC (Controlador de Estación Base). La conexión a una red de
teléfonos analógica, la denominada red pública de teléfonos
conmutada (PSTN) se realiza por medio de un módem, que está
integrado en la denominada función de interconexión IWF. La función
de interconexión IWF forma parte del centro de conmutación móvil, el
denominado centro de servicios de conmutación (MSC). Además, la
conexión se realiza a través de una red telefónica pública PSTN a un
proveedor de servicios de Internet (ISP). La conexión a un terminal
de abonado el servidor, se establece a través de Internet. Por
motivos de claridad no se ha ilustrado la conexión a través de
Internet con más detalle en la figura 4.
Ha de advertirse que las aplicaciones se ponen
en práctica independientemente de las capas de los protocolos
subyacentes. La transmisión de los datos así generados se realiza de
un modo transparente al usuario. Éste es también el fin de la
estructura jerárquica de la pila de protocolos, es decir para
garantizar una transmisión óptima y estable sin tener que implicar
al usuario en los hechos del sistema. Se espera, sin embargo, del
sistema subyacente que sea soporte de todas las aplicaciones
utilizadas por el usuario, tal como el acceso a Internet o la
transferencia de datos de vídeo. Sin embargo, las diferentes
aplicaciones tienen requerimientos diferentes en el sistema.
Ciertas aplicaciones de Internet como una
transacción bancaria, por ejemplo, requieren un protocolo de
transporte seguro, para garantizar solamente de esta forma un flujo
de datos libre de errores durante las transacciones monetarias a
través de Internet. Una transmisión de datos segura está garantizada
por el denominado Protocolo de Control de Transmisión TCP.
En contraposición con esto no se requiere en el
caso de una transferencia de vídeo usar un protocolo que garantice
una transmisión de datos segura fiable, ya que la seguridad de un
flujo de datos fiable está posiblemente asociada a tiempos de
transmisión mayores. En el caso de transmisión de vídeo es mejor
garantizar una transmisión más rápida de datos en secuencia para de
este modo obtener una impresión real en la presentación de las
imágenes de vídeo. Los errores que puedan producirse durante una
transmisión están dentro de ciertos límites y pueden ser tolerados
cuando las imágenes de vídeo son retransmitidas. Por esta razón no
se usa un protocolo de corrección de errores. Un ejemplo de tales
protocolos del nivel de transmisión es el denominado Protocolo de
Datagrama de Usuario UDP.
En la mayoría de los casos un usuario utiliza
varias aplicaciones durante una sesión, por ejemplo, si desea enviar
un correo electrónico y transmitir un vídeo en segundo plano al
mismo tiempo. En este caso, el usuario genera dos diferentes flujos
de datos, en los que la transmisión del correo electrónico tiene
como base el TCP y la transmisión de vídeo tiene como base el UDP.
Otro ejemplo es el acceso a Internet. En la mayoría de los casos se
accede a varias páginas de Internet durante una sesión, que a menudo
están localizadas en servidores diferentes. A pesar de que los
flujos de datos generados son exclusivamente flujos TCP, en este
caso están implicados diferentes flujos de datos ya que los
receptores son diferentes.
Tal distinción se tiene en cuenta en la capa de
protocolo de la red, tal como la capa IP. Dicha capa comprende
recibir paquetes de la capa del protocolo de transporte y
empaquetarlos para formar paquetes con su propio formato. La figura
5 ilustra un formato de un paquete IP. Dicho paquete contiene datos
de control entre los que, por ejemplo, está incluida la versión del
protocolo IP, por ejemplo IPv4 o IPv6. Esto no se ha mostrado con
detalle en la figura 5. Además, el formato de los datos IP está
provisto de un campo que contiene la información con respecto al
protocolo de transporte. En el caso de un protocolo UDP esto
significa que en dicho campo se introduce una combinación de bits,
que corresponde a la designación del UDP.
Sin embargo, el factor decisivo al distinguir el
flujo de datos es no solamente el tipo de protocolo sino también el
factor relativo en cuanto a qué direcciones están contenidas en el
encabezamiento IP. Esto significa que, si tanto la dirección IP del
transmisor y la dirección IP del receptor son idénticas en dos
paquetes IP de acuerdo con la figura 5, el encabezamiento TCP tiene
que ser examinado adicionalmente en secuencia para averiguar la
diferencia entre los flujos de datos. Diferentes números de puertos
están asignados a diferentes flujos de datos. Dichos números de
puertos identifican el correspondiente flujo de datos en el nivel de
transmisión por medio del cual se garantiza una comunicación entre
las instancias del socio. El encabezamiento de un paquete TCP
contiene la información con respecto al número de puerto, que es
comparada al diferenciar el flujo de datos. Solamente cuando los
números de puerto del transmisor y del receptor son idénticos, el
flujo de datos es el mismo. Si dichas direcciones son diferentes, es
decir si tanto las direcciones IP y los números de puerto difieren
entre sí, los receptores son diferentes y, por lo tanto, los flujos
de datos son diferentes. Dicho mecanismo se aplica en la versión
actual del IP utilizada, la denominada versión 4 IPv4 del Protocolo
de Internet. En la siguiente versión IP, la denominada versión 6 del
Protocolo de Internet, IPv6, la definición es básicamente la misma.
Aquí, diferentes flujos de datos son diferenciados por medio de los
denominados identificadores de flujo de datos, también denominados
identificadores de flujo. El método descrito también puede ser
transferido en IPv6 y básicamente a cada pila de protocolos en la
que se puede identificar el flujo de datos.
Dependiendo de si los paquetes en la capa IP
proceden de flujos de datos idénticos o diferentes, se establece una
diferencia entre dos modos. En caso de paquetes IP de un flujo de
datos idéntico interviene un modo de interflujo de datos o de
intraflujo de datos. El término modo interflujo designa un modo, en
el que son diferenciados los paquetes que pertenecen a flujos de
datos diferentes.
De acuerdo con la figura 4, en el caso en que ya
se ha creado un enlace en la capa de transporte entre una estación
móvil y un servidor en Internet, a continuación se muestra un
ejemplo de flujo de datos de dicho servidor a la estación móvil MS.
En este ejemplo se muestra más detalladamente la implicación de las
unidades de comunicación y de los protocolos de comunicación.
Los datagramas IP empaquetados en la capa de la
red se transmiten a través de Internet a un denominado Proveedor de
Servicios de Internet ISP. El ISP transmite los paquetes IP
recibidos a la capa PPP. Dicha capa genera un flujo de bytes
formateado en tramas PPP a partir de los datos obtenidos. Para
diferenciar los respectivos paquetes se añaden los separadores. Por
lo tanto, las tramas PPP son dispuestas para una transmisión
analógica. El ISP proporciona un módem para la transmisión modulando
los datos a una señal de audio en respuesta a la tasa y modo de
transmisión. En el ejemplo ilustrado, en el que una conexión se
realiza a través de una red analógica, la PSTN, es un módem V.32. Si
la conexión se realiza a través de una red ISDN, se usa, por ejemplo
un protocolo V.110. Para controlar el flujo, es decir en secuencia
para evitar un sobreflujo de datos en la función de interconexión
IWF, se usa un protocolo V.42. Dicha tarea corresponde a la del
protocolo de enlace por radio RLP en el GSM.
En la función de interconexión IWF, se produce
la conversión de los datos recibidos en el formato deseado para el
GSM.
Esto significa que el flujo de bytes de la capa
PPP es liberado en la capa RLP. Dicha capa empaqueta el flujo de
bytes recibido en tramas RLP. En la figura 6 se ilustra un formato
de una trama RLP. Una trama RLP consta de 240 bits. 16 bits de ellos
están destinados a la información de encabezamiento y 24 bits a la
secuencia de comprobación de la trama FCS. Un factor decisivo al
empaquetar las tramas PPP en tramas RLP es que los paquetes de datos
de las capas superiores de protocolo no son directamente visibles a
la capa RLP en el flujo de bytes recibido. Esto significa sobre todo
que la capa RLP no puede establecer una diferencia entre las tramas
PPP o entre los datagramas IP y, por tanto, entre los paquetes de la
capa de transporte. Para diferenciar los paquetes, el flujo de bytes
tiene que ser comprobado en cuanto a los separadores. Esto es
necesario para evitar que los datos de dos tramas PPP diferentes
sean empaquetadas en una trama RLP. Cada trama RLP nuevamente
generada está provista de un número de secuencia. Los paquetes
dispuestos de esta forma son transmitidos a través de una red móvil
dispuesta. Durante la transmisión la secuencia de las tramas RLP
puede ser confundida debido a los errores de transmisión producidos
y al proceso ARQ usado para su corrección. Esto, por tanto, implica
que las tramas sean recibidas por el receptor en una secuencia
cambiada. El receptor comprueba primero el número de secuencia de
las tramas RLP recibidas para averiguar la posición de la trama RLP
en la secuencia actual. En otro paso se comprobará si la trama RLP
recibida contiene un separador. Si contiene una marca inicial se
deduce que es la primera trama en una trama PPP consecutiva y se
almacena en una memoria intermedia en la posición correspondiente.
Las tramas RLP consecutivas que muestran los números consecutivos
también se guardan después en la memoria intermedia en la posición
correspondiente. Esto continúa hasta que una trama PPP recibe el
estatus de una trama generada de forma completa. Una trama PPP está
completamente generada si la posición inicial y la marca final han
sido correctamente recibidas y todas las tramas RLP han sido
recibidas correctamente sin espacios libres y si están situadas en
la secuencia correcta entre la trama RLP que contiene la marca
inicial y la trama LP que contiene la marca final. Antes de que la
tramas RLP sean almacenadas en la memoria intermedia las tramas son
desencapsuladas, es decir se retiran los datos de control de la capa
de protocolo RLP.
Al comprobar los paquetes RLP, no solamente son
diferenciados los paquetes PPP, sino que la comprobación de las
tramas puede ampliarse a la detección de los paquetes IP. Ésta es la
base para diferenciar entre el modo de interflujo y el modo de
intraflujo. Como ya se ha mencionado, el encabezamiento IP contiene
la información relativa al protocolo de transporte utilizado y a las
direcciones correspondientes. Debido al hecho de que un datagrama
completo se ajusta en una trama PPP, el examen de una trama PPP
finalizada puede ser asignado al reconocimiento de un datagrama y a
la información de él, es decir en cuanto a si están implicados los
datagramas IP del mismo o diferentes flujos de datos.
Para este fin, los datos de control de la trama
son comprobados después de que haya sido generado una trama completa
PPP. Los datos son examinados particularmente sobre los datos de
control de la respectiva capa de protocolo. Esto se realiza usando
unos medios de reconocimiento para reconocer un paquete de datos
completamente combinados. Esto significa que la información
referente a los datos de control de la capa respectiva debe estar
disponible a dichos medios, para solamente sobre esta base tomar una
decisión cuyos datos procedan de la capa de enlace, en particular
del PPP, y de donde arranquen en la trama PPP los datos de control
de la capa de control IP. Debido a que el formato de la
desencapsulamiento de los datos está normalizado en cada capa, ha de
establecerse una puesta en práctica en dicho mecanismo que sea
similar a las normas de encapsulamiento válidas. En las
realizaciones que se explican más adelante se da una explicación más
detallada del examen de los datagramas IP.
Un datagrama IP se transmite a la capa de
protocolo -la capa de transporte- directamente en la parte superior
de ella. Los paquetes TCP son numerados consecutivamente por igual,
y debido a la numeración actual se genera la secuencia de los
paquetes TCP en la capa de transporte. En otras palabras, el TCP es
responsable de la disposición de los paquetes TCP en una secuencia
correcta. En este nivel también son detectados los paquetes
defectuosos, y los errores son retirados comenzando una
investigación sobre la transmisión repetida de los paquetes.
Debido al hecho de que el TCP es responsable de
la generación de la secuencia correcta de los paquetes TCP
transmitidos ya no se requiere realizar la misma también también en
la capa de protocolo de la red. Esto particularmente permite que los
datagramas IP sean recibidos en una secuencia cambiada. La causa de
la recepción de los datagramas IP en la secuencia incorrecta es la
transmisión asíncrona de ellos. Los paquetes individuales pueden
tomar caminos diferentes hacia el receptor, por lo que puede ocurrir
que los paquetes enviados adelanten unos a otro en su camino, por lo
que llegan al receptor en una secuencia cambiada. Debido al hecho de
que la capa de transporte, en particular la TCP, es responsable de
generar la secuencia, no es importante en cuanto a qué amplitud de
la secuencia de los paquetes IP en la red está cambiada. Esto
significa particularmente que no se ha influido en la eficiencia del
procesamiento de paquetes si la secuencia es adicionalmente cambiada
por la capa RLP de protocolo.
Lo mismo pasa con el UDP, en el que está
admitido el cambio de la secuencia de paquetes.
A continuación, por medio de la figura 7, se
explica más detalladamente una aplicación del invento de acuerdo con
la reivindicación 16 de la patente para el modo interflujo.
En el modo interflujo son diferenciados los
paquetes que pertenecen a diferentes flujos de datos. Con este
objeto se examinan tramas PPP generadas de forma completa tal como
se ha descrito anteriormente. En dicho modo las tramas PPP ya son
liberadas por el receptor RLP, primeramente, cuando han sido
recibidas de forma completa y correcta, y, en segundo lugar, cuando
se ha garantizado que no están contenidas más tramas PPP en los
datos posiblemente introducidos en la memoria intermedia por el
receptor RLP, que pertenece al mismo flujo de datos de las tramas
PPP para ser liberadas.
Después de que hayan sido reconocidos los datos
de control de la capa IP el campo del protocolo de transporte puede
ser buscado dentro de dichos datos. Si la entrada en dicho campo es
diferente en las tramas PPP examinadas, definitivamente están
implicados diferentes flujos de datos. Sin embargo, si la entrada
con respecto al protocolo de transporte es concurrente, se examinan
las direcciones IP de los transmisores y de los receptores. En caso
de acuerdo de las direcciones, se examina el número de puerto de los
transmisores y de los receptores. Si no se pueden detectar
diferencias durante este examen, están implicadas tramas PPP del
mismo flujo de datos.
A continuación, de acuerdo con la figura 7, se
supone el caso de que los datos transmitidos desde dos diferentes
flujos de datos, el flujo de datos UDP y el flujo de datos TCP, 170.
Los paquetes de datos PPP son generados a partir de los datos en un
proceso de encapsulamiento, 180. Dependiendo de si está implicado un
flujo de datos UDP o un flujo de datos TCP, se diferencian dos tipos
de paquetes de datos PPP, el PPP(IP(TCP(n))) y
el PPP(IP(UDP(n))). Aquí la n designa el número
de secuencia de un paquete UDP o de un paquete TCP. De acuerdo con
la figura 7 dos paquetes de datos,
PPP(IP(UDP(1))),
PPP(IP(UDP(2))) y dos paquetes de datos
PPP(IP(TCP(1))),
PPP(IP(TCP(2))) se generan en la capa de
protocolo PPP. Éstos son después transmitidos a la capa de protocolo
RLP que los empaqueta en un flujo de las tramas RLP consecutivas
RLP(1), RLP(2), ... RLP(12), 190. Como ya se ha
mencionado anteriormente, no existe diferencia entre los diferentes
paquetes de datos de la capa de protocolo en la parte superior de
ella en la capa de protocolo RLP. De acuerdo con la figura 7, el
paquete de datos PPP(IP(TCP(1))) está dividido
en RLP(1), RLP(2), RLP(3) y RLP(4). Los
otros paquetes de datos de la capa de protocolo de la red también
están divididos de esta forma. Las tramas RLP finalizadas son
después transmitidas a través de una red 200. Durante la transmisión
puede producirse un cambio en la secuencia de las tramas RLP, lo
cual puede ser debido a la frecuente repetición de tramas RLP
incorrectamente transmitidas del flujo de datos TCP.
Suponiendo que el receptor recibe, de acuerdo
con la figura 7, la trama RLP(1) primero, 210, y las tramas
RLP RLP(5), RLP(6), RLP(7) son recibidas
después, 220. Éstos son reconocidos como paquete recibido de forma
completa. Por lo tanto, se examina dicho paquete en secuencia para
detectar el tipo del flujo de datos. Se reconoce que es un paquete
UDP, PPP(IP(UDP(1))) y es liberado en la capa
PPP, 230. Sin embargo, la capa PPP solamente es liberada cuando se
está seguro de que definitivamente no existen tramas PPP del mismo
flujo de datos contenidas en los datos posiblemente introducidos en
la memoria intermedia por el receptor RLP. En esta realización
solamente se admite liberar tramas PPP en la capa de protocolo PPP
que pertenecen a flujos de datos diferentes, o al mismo flujo de
datos, sin embargo, solamente en la secuencia correcta con respecto
a la numeración de las tramas RLP.
De acuerdo con la figura 7, las tramas RLP,
RLP(8), RLP(9), RLP(10) son las siguientes para
ser recibidas, 240. Éstas son entonces nuevamente almacenados en una
memoria intermedia y son reconocidos como un paquete completo
PPP(IP(UDP(2))), 250. Como el protocolo RLP
tiene la información de que el primer paquete UDP,
PPP(IP(UDP(1))) que pertenece al mismo flujo de
datos ya ha sido liberado, ahora se toma una decisión sobre la base
de esta información para liberar el
PPP(IP(UDP(2))) en la capa de protocolo PPP.
Como las tramas PPP del paquete TCP todavía no han sido generados
completamente, como el PPP(IP(TCP(1)))
solamente contiene el RLP(1), todavía está conservado en la
memoria intermedia. Sin embargo, si el
PPP(IP(UDP(1))) tampoco está completo, el
PPP(IP(UDP(2))) es conservado en la memoria
intermedia hasta que se haya generado completamente el
PPP(IP(UDP(1))).
La siguiente realización aconseja una puesta en
práctica ampliada, en la que se admita una liberación de tramas PPP
completamente generadas que pertenezcan a flujos de datos tanto
diferentes como idénticos.
A continuación se explica dicha realización con
más detalle por medio de la figura 8 y la reivindicación 17 de la
patente.
Suponiendo que debido a una mala calidad
temporal de la conexión producida durante la transmisión de los
primeros paquetes PPP, primeramente se recibe de forma completa el
PPP(IP(UDP(2))). Esto tiene lugar debido a la
recepción de las tramas RLP(8), RLP(9),
RLP(10), 280. La memoria intermedia solamente contiene una
trama RLP, la trama RLP(5), 270. Debido al hecho de que está
admitido el modo de intraflujo, de todas las tramas generadas de
forma completa, también se liberan las que pertenecen al mismo flujo
de datos. Esto significa, exclusivamente que se ha tomado aviso de
la integridad de una trama PPP. Las capas superiores son las
responsables de la disposición de los paquetes en la secuencia
correcta. También, el RLP(1), que fue recibido primero y que
constituye la primera trama de un
PPP(IP(TCP(1))) generada de forma incompleta,
es mantenida en la memoria intermedia, 260.
En lo anterior, el invento fue presentado por
medio de una aplicación a modo de ejemplo en el campo GSM. En otras
redes existen las mismas posibilidades de aplicación, tales como la
red GPRS. Dicha red está pensada para la transmisión de una
aplicación orientada por paquetes del transmisor al receptor. La
estructura de la pila de protocolos también es compatible en ambos
casos.
El invento también puede ser aplicado en un
entorno en el que solamente está provisto de un enlace de protocolo.
Esto significa que se pone en práctica un protocolo de enlace único
en lugar del PPP y RLP en el GSM o del LLC y RLC en el GPRS. En este
caso se requiere que dichos protocolos trabajen de un modo fiable.
Por ejemplo, es posible encontrar esta forma de aplicación en el
UMTS.
Claims (25)
1. Método para mejorar un tiempo de
procesamiento de datos recibidos en aplicaciones orientadas por
paquetes en una transmisión de datos entre un transmisor y un
receptor cada uno de ellos comprendiendo una capa primera y una
segunda subyacente de protocolo a través de una red de comunicación,
en el que:
- -
- los datos de la primera capa de protocolo son liberados en la segunda capa de protocolo en el transmisor (20);
- -
- los datos de la primera capa de protocolo están divididos en paquetes de datos consecutivos de la segunda capa de protocolo generando una secuencia de paquetes de datos consecutivos con números de secuencia, por lo que un paquete de datos de la segunda capa de protocolo contiene datos de solamente un paquete de datos de la primera capa de protocolo (30);
- -
- los paquetes de datos de la segunda capa de protocolo se transmiten a través de la red de comunicación (50);
- -
- los paquetes de datos de la segunda capa de protocolo recibidos en el receptor (60) se clasifican en la segunda capa de protocolo en la secuencia de paquetes de datos consecutivos por medio de los números de secuencia;
- -
- los paquetes de datos recibidos se asignan a paquetes de datos de la primera capa de protocolo en la segunda capa de protocolo;
- -
- después de haber sido generado completamente un paquete de datos de la primera capa de protocolo (100), dicho paquete de datos es examinado para la asociación a un flujo de datos y es liberado en la primera capa de protocolo (110);
2. Método de acuerdo con la reivindicación 1, en
el que un procesamiento de los datos en el transmisor y/o receptor
está basado en una estructura modular de protocolo.
3. Método de acuerdo con la reivindicación 1 ó
2, en el que los paquetes de datos de la segunda capa de protocolo
están numerados consecutivamente y marcados por un número de
secuencia correspondiente.
4. Método de acuerdo con una de las
reivindicaciones 1 a 3, en el que la primera capa de protocolo es
soporte de al menos dos modos de transmisión, un modo fiable y un
modo no fiable.
5. Método de acuerdo con la reivindicación 4, en
el que los paquetes de datos de la segunda capa de protocolo son
corregidos por medio de transmisión repetida en caso de un error de
transmisión y usando el modo de transmisión fiable.
6. Método de acuerdo con una de las
reivindicaciones 1 a 5, en el que los datos de la primera capa de
protocolo están claramente diferenciados entre sí por medio de
separadores.
7. Método de acuerdo con la reivindicación 3, en
el que los paquetes de datos recibidos se clasifican en una
secuencia que corresponde a un número de secuencia.
8. Método de acuerdo con la reivindicación 3 ó
7, en el que el número de secuencia es un número de secuencia RLP
(Protocolo de Enlace por Radio) o un número de secuencia RLC
(Control de Enlace por Radio).
9. Método de acuerdo con una de las
reivindicaciones precedentes 1 a 8, en el que los paquetes de datos
recibidos son almacenados en una memoria intermedia del
receptor.
10. Método de acuerdo con una de las
reivindicaciones 1 a 9, en el que un paquete de datos de la primera
capa de protocolo es llevado a un estatus de paquete de datos
generado completamente, si se ha recibido correctamente una marca
inicial y una final dentro de los paquetes de datos de la segunda
capa de protocolo , y si todos los paquetes de datos de la segunda
capa de protocolo que descansa en medio han sido recibidos
correctamente de acuerdo con su secuencia correcta.
11. Método de acuerdo con la reivindicación 10,
en el que los paquetes de datos generados de forma completa de la
primera capa de protocolo se examinan de acuerdo con las reglas de
un proceso de encapsulamiento para identificar paquetes de capas de
protocolo adicionales.
12. Método de acuerdo con la reivindicación 10 u
11, en el que al menos un campo de control que comprende datos de
control está dispuesto en los paquetes de datos generados de forma
completa de la primera capa de protocolo, para entregar la
información referente a un flujo de datos pertinente.
13. Método de acuerdo con la reivindicación 12,
en el que los datos de control son adjuntados a las secuencias de
datos reales como campos de control en las correspondientes capas de
protocolo en forma de un encabezamiento y/o un pie de página.
14. Método de acuerdo con una de las
reivindicaciones 1 a 13, en el que un flujo de datos está
diferenciado por medio de ciertos datos de control en los campos de
control dispuestos para ello.
15. Método de acuerdo con la reivindicación 14,
en el que los datos de control de los flujos de datos
diferenciadores son las direcciones del transmisor y/o del receptor
en forma de direcciones de fuente, direcciones de destino y de
números de puertos.
16. Método de acuerdo con una de las
reivindicaciones 1 a 15, en el que los paquetes de datos son
liberados directamente en la primera capa de protocolo en la segunda
capa de protocolo, si los paquetes de datos en la segunda capa de
protocolo han sido primeramente recibidos de forma completa y
correcta, y si en segundo lugar se ha garantizado que los datos
posiblemente guardados en la memoria intermedia por el receptor de
la segunda capa de protocolo no contienen paquetes de datos
adicionales de la primera capa de protocolo que pertenecen al mismo
flujo de datos de los paquetes de datos de la primera capa de
protocolo para ser liberados.
17. Método de acuerdo con una de las
reivindicaciones 1 a 15, en el que en la segunda capa de protocolo
los paquetes de datos de la primera capa de protocolo son liberados
directamente en la primera capa de protocolo, si dichos paquetes de
datos han sido recibidos completa y correctamente.
18. Método de acuerdo con la reivindicación 1,
en el que los paquetes de datos de la primera capa de protocolo son
datagramas IP y los paquetes de datos de la segunda capa de
protocolo son tramas PPP, en los que las tramas PPP son corregidas
por medio de transmisión repetida cuando se produce un error.
19. Método de acuerdo con la reivindicación 1,
en el que los paquetes de datos de la primera capa de protocolo son
tramas PPP y los paquetes de datos de la segunda capa de protocolo
son tramas de datos RLP.
20. Método de acuerdo con la reivindicación 1,
en el que la transmisión de datos se realiza a través de una red IP
y de una red de comunicación móvil.
21. Método de acuerdo con la reivindicación 1,
en el que las aplicaciones orientadas por paquetes son aplicaciones
de Internet.
22. Método de acuerdo con las reivindicaciones
18 a 21, en el que una aplicación de Internet se transmite por medio
del protocolo de transporte Protocolo de Control de Transmisión
(TCP).
23. Método de acuerdo con las reivindicaciones
18 a 21, en el que una aplicación de Internet se transmite por medio
del protocolo de transporte Protocolo de Datagramas de Usuario
(UDP).
24. Dispositivo para mejorar un tiempo de
procesamiento de datos recibidos en aplicaciones orientadas por
paquetes en una transmisión de datos entre un transmisor y un
receptor, cada uno con una primera y una segunda capa de protocolo
subyacente, a través de una red de comunicación, que comprende:
- -
- medios para proveer paquetes de datos de una primera capa de protocolo a una segunda capa de protocolo (10), que está adaptada para dividir los datos de la primera capa de protocolo en paquetes de datos consecutivos de la segunda capa de protocolo generando una secuencia de paquetes de datos consecutivos con números de secuencia, en los que un paquete de datos de la segunda capa de protocolo contiene datos de solamente un paquete de datos de la primera capa de protocolo (30);
- -
- medios de transmisión para transmitir los paquetes de datos (40);
- -
- medios de recepción para recibir los paquetes de datos (60);
- -
- medios de clasificación para clasificar los paquetes de datos recibidos en la secuencia de paquetes de datos consecutivos por medio de números de secuencia (70);
- -
- medios de reconocimiento para reconocer un paquete de datos combinado de forma completa de la primera capa de protocolo en la secuencia de datos consecutivos (100);
- -
- medios para examinar la asociación de los paquetes de datos de la primera capa de protocolo con un flujo de datos después de haber sido reconocido un paquete de datos de la primera capa de protocolo;
- -
- medios de liberación para liberar un paquete de datos generado de forma completa en la primera capa de protocolo (110).
25. Dispositivo de acuerdo con la reivindicación
24 que comprende una memoria intermedia para almacenar temporalmente
los paquetes de datos recibidos de la segunda capa de protocolo.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP98124010A EP1014641A1 (de) | 1998-12-22 | 1998-12-22 | Verfahren und Vorrichtung zur Reduzierung der Aufarbeitungszeit von Daten in Kommunikationsnetzen |
| EP98124010 | 1998-12-22 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2270631T3 true ES2270631T3 (es) | 2007-04-01 |
Family
ID=8233163
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES99965453T Expired - Lifetime ES2270631T3 (es) | 1998-12-22 | 1999-12-13 | Metodo y dispositivo para reducir el tiempo de proceso de datos en redes de comunicacion. |
Country Status (10)
| Country | Link |
|---|---|
| US (1) | US6948108B1 (es) |
| EP (2) | EP1014641A1 (es) |
| JP (1) | JP4594530B2 (es) |
| CN (1) | CN1287576C (es) |
| AT (1) | ATE332051T1 (es) |
| AU (1) | AU760994B2 (es) |
| CA (1) | CA2356900A1 (es) |
| DE (1) | DE69932184T2 (es) |
| ES (1) | ES2270631T3 (es) |
| WO (1) | WO2000038390A1 (es) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3525869B2 (ja) * | 2000-07-12 | 2004-05-10 | 日本電気株式会社 | パケット通信システムの接続装置及び方法 |
| FR2818066B1 (fr) | 2000-12-12 | 2003-10-10 | Eads Airbus Sa | Procede et dispositif de transmission deterministe de donnees asynchrones mises en paquet |
| FR2818844B1 (fr) * | 2000-12-22 | 2003-03-07 | Mitsubishi Electricite | Procede de transmission de donnees entre au moins un emetteur et au moins un recepteur, emetteur, recepteur et systeme de transmission correspondants |
| WO2002069519A1 (en) * | 2001-02-23 | 2002-09-06 | Nokia Inc. | System and method for fast gprs for ipv6 communications |
| US7096261B2 (en) * | 2001-03-12 | 2006-08-22 | Qualcomm Incorporated | Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection |
| EP1253736A3 (en) * | 2001-04-26 | 2003-12-10 | NTT DoCoMo, Inc. | Data link transmission control for mobile communications |
| US20030002467A1 (en) * | 2001-06-29 | 2003-01-02 | Leung Nikolai K.N. | Internet protocol framing using radio link protocol |
| KR100469720B1 (ko) * | 2001-10-15 | 2005-02-02 | 삼성전자주식회사 | 이동통신시스템에서 과금장치 및 방법 |
| CN100438492C (zh) * | 2003-09-30 | 2008-11-26 | 美国博通公司 | 用于IEEE802.11g接收器的分类器 |
| US7269146B2 (en) * | 2003-10-20 | 2007-09-11 | Motorola Inc. | Method and apparatus for interchanging and processing mobile radio subsystem control information |
| US7814219B2 (en) * | 2003-12-19 | 2010-10-12 | Intel Corporation | Method, apparatus, system, and article of manufacture for grouping packets |
| KR100583872B1 (ko) * | 2004-03-17 | 2006-05-26 | 주식회사 팬택앤큐리텔 | 기지국의 상향 링크 패킷 전송 방법 및 그 방법이 구현된이동통신 시스템 |
| US20050207392A1 (en) * | 2004-03-19 | 2005-09-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Higher layer packet framing using RLP |
| US7586882B2 (en) | 2004-03-19 | 2009-09-08 | Telefonaktiebolaget Lm Ericsson (Publ) | Higher layer packet framing using RLP |
| US7626926B2 (en) * | 2004-12-09 | 2009-12-01 | Airvana, Inc. | Traffic management in a wireless data network |
| JP5210895B2 (ja) * | 2008-02-20 | 2013-06-12 | 株式会社日立製作所 | 無線通信システム、端末及び基地局 |
| CN101729224A (zh) * | 2008-10-20 | 2010-06-09 | 富士通株式会社 | 传输数据生成装置和接收机 |
| CN102377805A (zh) * | 2010-08-20 | 2012-03-14 | 贺心雅 | 自动腹膜透析无线网络系统及数据传输方法 |
| CN102761571B (zh) * | 2011-04-28 | 2014-11-12 | 上海市特种设备监督检验技术研究院 | 电梯智能物联终端 |
| CN109743766B (zh) * | 2018-02-13 | 2020-06-16 | 华为技术有限公司 | 一种数据路由选择的方法及装置 |
Family Cites Families (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4703475A (en) * | 1985-12-04 | 1987-10-27 | American Telephone And Telegraph Company At&T Bell Laboratories | Data communication method and apparatus using multiple physical data links |
| JPS6399651A (ja) * | 1986-10-15 | 1988-04-30 | Nec Corp | デ−タ通信方式 |
| US5243592A (en) * | 1990-10-15 | 1993-09-07 | Digital Equipment Corporation | Method and apparatus for distance vector routing on datagram point-to-point links |
| JPH04291556A (ja) * | 1991-03-20 | 1992-10-15 | Fujitsu Ltd | 通信制御方式 |
| US6088342A (en) * | 1997-05-05 | 2000-07-11 | Nokia Mobile Phones Limited | Dynamic configuration of radio link protocol in a telecommunications system |
| US5570367A (en) * | 1994-07-29 | 1996-10-29 | Lucent Technologies Inc. | Asymmetric protocol for wireless communications |
| FI98027C (fi) * | 1995-01-10 | 1997-03-25 | Nokia Telecommunications Oy | Pakettiradiojärjestelmä ja päätelaitteisto pakettiradiojärjestelmää varten |
| FI98174C (fi) * | 1995-05-09 | 1997-04-25 | Nokia Telecommunications Oy | Datansiirtojärjestelmä, jossa on liukuvaan ikkunaan perustuva datavuonohjaus |
| FI97927C (fi) * | 1995-05-09 | 1997-03-10 | Nokia Telecommunications Oy | Ei-transparentti datansiirto digitaalisessa tietoliikennejärjestelmässä |
| US5729536A (en) * | 1996-04-10 | 1998-03-17 | Lucent Technologies | Cellular system architectures supporting data services |
| US5936965A (en) * | 1996-07-08 | 1999-08-10 | Lucent Technologies, Inc. | Method and apparatus for transmission of asynchronous, synchronous, and variable length mode protocols multiplexed over a common bytestream |
| US5708656A (en) * | 1996-09-11 | 1998-01-13 | Nokia Mobile Phones Limited | Method and apparatus for packet data transmission |
| KR100260516B1 (ko) * | 1997-04-01 | 2000-07-01 | 정선종 | 코드분할 다중접속 이동통신망에서의 비동기통신 데이터발신호 및 착신호 서비스 방법 |
| JPH10341487A (ja) * | 1997-04-09 | 1998-12-22 | Sony Corp | 情報端末装置、情報処理方法、情報提供装置および方法、情報ネットワークシステム、並びに提供媒体 |
| KR19990001580A (ko) * | 1997-06-16 | 1999-01-15 | 양승택 | Cdma 이동통신망을 이용한 g3 팩스 서비스 방법 |
| US6011796A (en) * | 1997-06-17 | 2000-01-04 | Qualcomm Incorporated | Extended range sequence numbering for selective repeat data transmission protocol |
| US6314101B1 (en) * | 1997-06-17 | 2001-11-06 | Qualcomm Incorporated | Method for detecting delayed data frames in a transport function |
| US6236647B1 (en) * | 1998-02-24 | 2001-05-22 | Tantivy Communications, Inc. | Dynamic frame size adjustment and selective reject on a multi-link channel to improve effective throughput and bit error rate |
| US5862452A (en) * | 1997-10-20 | 1999-01-19 | Motorola, Inc. | Method, access point device and peripheral devices for low complexity dynamic persistence mode for random access in a wireless communication system |
| US6226301B1 (en) * | 1998-02-19 | 2001-05-01 | Nokia Mobile Phones Ltd | Method and apparatus for segmentation and assembly of data frames for retransmission in a telecommunications system |
| US6112084A (en) * | 1998-03-24 | 2000-08-29 | Telefonaktiebolaget Lm Ericsson | Cellular simultaneous voice and data including digital simultaneous voice and data (DSVD) interwork |
| US6307867B1 (en) * | 1998-05-14 | 2001-10-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Data transmission over a communications link with variable transmission rates |
| US6310893B1 (en) * | 1998-06-17 | 2001-10-30 | Genuity Inc. | Method and system for connectionless communication in a cell relay satellite network |
| US6160804A (en) * | 1998-11-13 | 2000-12-12 | Lucent Technologies Inc. | Mobility management for a multimedia mobile network |
| US6169732B1 (en) * | 1999-06-29 | 2001-01-02 | Motorola, Inc. | Method and apparatus in a wireless communication system |
| US6301479B1 (en) * | 1999-07-08 | 2001-10-09 | Telefonaktiebolaget Lm Ericsson | Technique for providing a secure link in a mobile communication system |
| US6317224B1 (en) * | 1999-09-17 | 2001-11-13 | Motorola, Inc. | Method and apparatus for modifying facsimile data transfer rates based upon varying bit rates of a transport medium |
-
1998
- 1998-12-22 EP EP98124010A patent/EP1014641A1/de not_active Withdrawn
-
1999
- 1999-12-13 EP EP99965453A patent/EP1142263B1/en not_active Expired - Lifetime
- 1999-12-13 DE DE69932184T patent/DE69932184T2/de not_active Expired - Lifetime
- 1999-12-13 CA CA002356900A patent/CA2356900A1/en not_active Abandoned
- 1999-12-13 WO PCT/EP1999/009861 patent/WO2000038390A1/en active IP Right Grant
- 1999-12-13 AU AU20963/00A patent/AU760994B2/en not_active Ceased
- 1999-12-13 JP JP2000590357A patent/JP4594530B2/ja not_active Expired - Lifetime
- 1999-12-13 AT AT99965453T patent/ATE332051T1/de not_active IP Right Cessation
- 1999-12-13 CN CN99814939.XA patent/CN1287576C/zh not_active Expired - Fee Related
- 1999-12-13 ES ES99965453T patent/ES2270631T3/es not_active Expired - Lifetime
- 1999-12-21 US US09/468,042 patent/US6948108B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US6948108B1 (en) | 2005-09-20 |
| EP1014641A1 (de) | 2000-06-28 |
| DE69932184T2 (de) | 2007-06-14 |
| DE69932184D1 (de) | 2006-08-10 |
| JP2002534001A (ja) | 2002-10-08 |
| AU2096300A (en) | 2000-07-12 |
| CN1331877A (zh) | 2002-01-16 |
| CA2356900A1 (en) | 2000-06-29 |
| ATE332051T1 (de) | 2006-07-15 |
| CN1287576C (zh) | 2006-11-29 |
| EP1142263B1 (en) | 2006-06-28 |
| EP1142263A1 (en) | 2001-10-10 |
| JP4594530B2 (ja) | 2010-12-08 |
| AU760994B2 (en) | 2003-05-29 |
| WO2000038390A1 (en) | 2000-06-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2270631T3 (es) | Metodo y dispositivo para reducir el tiempo de proceso de datos en redes de comunicacion. | |
| ES2314534T3 (es) | Procedimiento y dispositivo para la señalizacion de segmentacion y concatenacion de paquetes en un sistema de telecomunicaciones. | |
| ES2610396T3 (es) | Un esquema de segmentación flexible para sistemas de comunicación | |
| US6795435B1 (en) | Method for transmitting data transmission flows | |
| ES2218389T3 (es) | Numeracion de paquetes de datos en una transmision de datos por conmutacion de paquetes. | |
| FI110831B (fi) | Menetelmä tiedonsiirron tehostamiseksi ja tiedonsiirtoprotokolla | |
| KR100878161B1 (ko) | 무선 패킷 데이터 서비스 접속에서 다중 품질의 서비스레벨을 제공하는 방법 및 장치 | |
| JP6025880B2 (ja) | データ伝送方法、装置及びシステム | |
| US7616639B2 (en) | Transmitting and receiving control protocol data unit having processing time information | |
| CN100411454C (zh) | 分组交换数据传输中的数据分组编号 | |
| ES2236319T3 (es) | Definicion de la compresion de campos de cabecera para conexiones de paquetes de datos. | |
| ES2235018T3 (es) | Metodo y sistema para tratamiento de datos erroneos en un sistema de comunicaciones comutado por paquetes, en el que los paquetes se subdividen y procesan por partes. | |
| EP1256213B1 (en) | Method and system for communicating data between a mobile and packet switched communications architecture | |
| TW200425690A (en) | A header format of transmission control protocol/Internet protocol | |
| ES2233866T3 (es) | Procedimiento y dispositivo para la comprension de la cabecera en redes orientadas a paquetes. | |
| EP2515491A1 (en) | Selective Forwarding of Damaged Packets | |
| CN1567915A (zh) | 一种无线传输控制协议/网际协议报头设定传输方法 | |
| ES2335571T3 (es) | Procedimiento para la transmision de paquetes de datos. | |
| KR100407356B1 (ko) | 부호분할다중접속 통신시스템의 데이터 송신장치 및 방법 | |
| ES2352850T3 (es) | Procedimiento para procesar datos en una capa de control de acceso al medio (mac). | |
| Rouskas | A Comparative Study of DOD and GOSIP Protocols | |
| MXPA06007429A (es) | Transmision y recepcion de unidades de datos de protocolo de control que tienen informacion de tiempo de procesamiento |