ES2353489T3 - Provisión de servicios con un servidor en una red tcp/ip. - Google Patents

Provisión de servicios con un servidor en una red tcp/ip. Download PDF

Info

Publication number
ES2353489T3
ES2353489T3 ES01925614T ES01925614T ES2353489T3 ES 2353489 T3 ES2353489 T3 ES 2353489T3 ES 01925614 T ES01925614 T ES 01925614T ES 01925614 T ES01925614 T ES 01925614T ES 2353489 T3 ES2353489 T3 ES 2353489T3
Authority
ES
Spain
Prior art keywords
application
service
server
information
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
ES01925614T
Other languages
English (en)
Inventor
Risto Makipaa
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.)
Domiras Oy
Original Assignee
Domiras Oy
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 Domiras Oy filed Critical Domiras Oy
Application granted granted Critical
Publication of ES2353489T3 publication Critical patent/ES2353489T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • 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/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H04N21/4431—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB characterized by the use of Application Program Interface [API] libraries
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/76—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
    • H04H60/81—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself
    • H04H60/82—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself the transmission system being the Internet
    • H04H60/83—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself the transmission system being the Internet accessed over telephonic networks
    • H04H60/85—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself the transmission system being the Internet accessed over telephonic networks which are mobile communication networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4541—Directories for service discovery
    • 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/10—Architectures or entities
    • H04L65/1059—End-user terminal functionalities specially adapted for real-time 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/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • 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]
    • 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/163—In-band adaptation of TCP data exchange; In-band control procedures
    • 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/164—Adaptation or special uses of UDP protocol
    • 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/24—Negotiation of communication capabilities
    • 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/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • 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/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • 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/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • 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/65—Transmission of management data between client and server
    • H04N21/654—Transmission by server directed to the client
    • 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/65—Transmission of management data between client and server
    • H04N21/654—Transmission by server directed to the client
    • H04N21/6547—Transmission by server directed to the client comprising parameters, e.g. for client setup
    • 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/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • 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/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6582—Data stored in the client, e.g. viewing habits, hardware capabilities, credit card number
    • 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/18—Multiprotocol handlers, e.g. single devices capable of handling multiple 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/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/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Library & Information Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Computer And Data Communications (AREA)
  • Circuits Of Receivers In General (AREA)
  • Medicines Containing Antibodies Or Antigens For Use As Internal Diagnostic Agents (AREA)
  • Saccharide Compounds (AREA)
  • Telephonic Communication Services (AREA)
  • Stored Programmes (AREA)

Abstract

Un método para poner en práctica un servicio de un servidor (S1-3) a dispositivos de cliente (TE) que tienen diferentes características, comprendiendo el método las operaciones de: un dispositivo cliente (TE) que transmite un paquete de protocolo de Internet (IP) que comprende un encabezamiento IP, un encabezamiento de capa de protocolo de transporte y datos de capa de aplicación, encaminar el paquete IP hacia el servidor (S1-3) de acuerdo con una dirección de destino de dicho encabezamiento IP, transferir, en el servidor, el encabezamiento de capa de transporte y los datos de capa de aplicación desde la capa IP al protocolo de capa de transporte de acuerdo con un identificador de protocolo de dicho encabezamiento IP, transferir, en el servidor, los datos de capa de aplicación desde la capa de protocolo del transporte a la capa de aplicación de acuerdo con un número de puerto contenido en dicho encabezamiento de capa de protocolo de transporte, caracterizado porque el dispositivo de cliente (TE) incluye, en el paquete IP que transmite, informaciones sobre una interfaz de programación por debajo de una aplicación utilizada para presentar el servicio en el dispositivo de cliente que solicita el servicio, dicha información es usada en el servidor (S1-3) para seleccionar y/o configurar un archivo solicitado por el dispositivo de cliente o una aplicación que interactúa con el dispositivo de cliente de tal modo que el servicio sea proporcionado en la forma requerida por las características del dispositivo de cliente (TE) particular que ha solicitado el servicio.

Description

El invento se refiere a la proporción de servicios desde un servidor en una red TCP/IP a diferentes terminales de abonado.
Internet es simplemente la red de redes, que soporta aplicaciones basadas en el TCP/IP (Protocolo de Control de Transporte/Protocolo de Internet), tales como una World Wide Web (WWW), un Protocolo de Transporte de Mensaje Simple (SMTP) un correo electrónico o un Protocolo de Transferencia de Archivos (FTP). Las partes de Internet son usualmente llamadas subredes que han sido interconectadas por pasarelas o encaminadores (“routers”). Los ordenadores conectados a la red son llamados anfitriones. Un anfitrión es usualmente un cliente mientras que otro es un servidor. Un ordenador que solicita o recibe servicios desde un ordenador en otra red he llamado un cliente. Un servidor es un ordenador que proporciona servicios a otros ordenadores en la red. El documento US 5.956.509 describe un cliente situado remotamente o a distancia que envía a una solicitud remota a un servidor a través de una pasarela. El documento EP 0786728 describe un servicio que proporciona un sistema con una pluralidad de ordenadores que adquieren información y ordenadores que proporcionan información conectados a una red. La fig. 1 ilustra una estructura de protocolo TCP/IP (de acuerdo con un modelo OSI) y las subredes, un encaminador y ordenadores anfitriones.
En la parte inferior de un apilamiento de protocolo hay prevista una capa física, que se refiere al medio de transferencia real sobre el que los datos son transferidos como impulsos eléctricos u otras señales adecuadas. Un ordenador anfitrión está conectado al medio de transferencia por un adaptador de red. Una capa de enlace de datos comprende una interfaz al adaptador de red y mantiene un enlace lógico a una subred. Cada adaptador de red tiene una dirección física única y permanente. En el nivel más bajo, los protocolos dependientes del equipo entregan datos dentro de la red física, usando las direcciones físicas de los adaptadores. Ejemplos de arquitecturas de red de la capa de enlace de datos física incluyen Ethernet, Modo de Transferencia Asíncrono (ATM) y Protocolo de conexión a Internet mediante Circuito Virtual Permanente (“Frame Relay”).
Una capa de red, o una capa de Internet, es una capa en la que el protocolo IP proporciona el tratamiento de la dirección lógica, independiente del equipo de modo que permite que los datos sean transferidos desde una subred a otra incluso aunque se hubieran usado diferentes tecnologías en las capas inferiores de las subredes. El protocolo IP es un protocolo de paquetes conmutados que es responsable principalmente de encaminar los paquetes de IP sobre Internet a su destino final y para informar del destino de la fuente. Por ello, un encabezamiento de un paquete IP comprende una dirección de fuente IP y una dirección de destino IP para identificar inequívocamente la fuente original y el destino final. Las direcciones de la fuente y del destino permanecen sin cambios mientras el paquete IP se desplaza desde la fuente al destino. Las redes TCP/IP usan direcciones de 32 bits para identificar el ordenador anfitrión y la red a la que el anfitrión está conectado. En otras palabras, la dirección IP comprende la dirección de la red y la dirección del anfitrión. El protocolo TCP/IP usa el denominado Protocolo de Resolución de Dirección (ARP) y el Protocolo de Resolución de Dirección Inverso (RARP) para enlazar estas direcciones lógicas de IP a las direcciones físicas reales de los adaptadores de red. Un paquete IP (datagrama) comprende también la dirección (número) del protocolo (TCP, UDP, ICMP) de la capa de transporte a la que el ordenador receptor ha de enviar una carga útil.
Una capa de transporte se encuentra entre una red y las aplicaciones de la capa de la aplicación. Los protocolos más importantes de la capa de transporte incluyen un Protocolo de Control de Transporte (TCP) y un Protocolo de Datagrama de Usuario (UDP), que permite que una aplicación particular sea configurada como el destino de los datos en los paquetes de IP. Para ser más preciso, las aplicaciones están conectadas a módulos de protocolos TCP y UDP a través de "puertos", estando previsto cada puerto con un número único, como se ha ilustrado en la fig. 2. Los puertos son asignados de manera fija a ciertas aplicaciones populares de cliente/servidor en el servidor final, estando estandarizada la ubicación para cubrir todo Internet. Tales puertos son denominados puertos bien conocidos, y permiten que una aplicación de servicio sea obligada a publicitar su número de puerto antes de que la comunicación sea evitada. Cuando un cliente trasmite un paquete IP, simplemente inserta el número de puerto conocido de la aplicación de destino (servidor) al campo del puerto de destino del encabezamiento de UDP o TCP y el número de puerto desconocido, libre del cliente al campo de puerto fuente. Cuando el servidor recibe el primer paquete, el servidor es así informado del número de puerto asociado con la aplicación de cliente. Las diferentes corrientes de tráfico de las aplicaciones finales que comunican entre sí pueden así ser distinguidas unas de otras usando una combinación de cinco identificadores diferentes; dirección de fuente IP, puerto fuente, dirección de destino IP, puerto de destino y protocolo de capa de transporte (TCP, UDP). Cuando se examinan dos paquetes, si uno o más de estos identificadores son diferentes, los paquetes pertenecen a diferentes corrientes de tráfico. Ejemplos de puertos TCP conocidos para las aplicaciones más comunes incluyen el puerto 21 para aplicaciones de FTP, el puerto 80 para servicios de WWW (Lenguaje de Marcado de Hipertexto HTML), el puerto 23 para servicios Telenet y el puerto 25 para el protocolo de correo electrónico SMTP. Los puertos UDP conocidos incluyen el puerto 42 para un servicio de nombre y el puerto 69 para un servicio de TFTP (Trivial FTP). En conexión con los puertos, también son normalmente mencionados los zócalos o bases. Un zócalo o base es una dirección que está formada por la combinación de una dirección IP y un número de puerto. Por ejemplo, el zócalo o base 111.121.131.141.80 se refiere al puerto 80 de un ordenador cuya dirección IP es
111.121.131.141. Una dirección de zócalo o base es así un identificador inequívoco de una aplicación que funciona en un servidor.
Ha de observarse que un ordenador anfitrión puede también ser un puesto de trabajo remoto conectado a través de una conexión por módem o similar a un servidor de marcación conectado a la red TCP/IP. Los protocolos de marcación, tales como un Protocolo de Internet de Línea en Serie (SLIP) y el Protocolo Punto a Punto (PPP), son a continuación generalmente usados en la capa de red entre el puesto de trabajo remoto y el servidor de marcación. En tanto en cuanto la capa IP y las capas superiores están concernidas, esta, sin embargo, es una situación muy similar a la de la fig. 1. Cuando el servidor de marcación es considerado como funcionando como un encaminador y una subred 1 es la conexión por módem.
Una capa de aplicación comprende aplicaciones para detectar fallos, transferir archivos, controlar a distancia una red y para funciones de Internet. La capa de aplicación comprende también interfaces de programación de aplicación (API), que permiten el funcionamiento de los programas de aplicación por encima de un cierto sistema operativo para usar la red. Sin embargo, las aplicaciones y los diferentes sistemas operativos y/o API requeridos desde las aplicaciones por diferentes dispositivos y terminales de cliente causan problemas particularmente al proveedor de servicios. A continuación, se examinarán nuevas aplicaciones multimedia a modo de ejemplo.
Nuevas redes de transmisión digital han sido desarrolladas en todo el mundo para entregar emisiones de radio y televisión. Tales redes incluyen por ejemplo una red de radio digital llamada Retrasmisión de Audio Digital (DAB) y una red de televisión digital llamada Retransmisión de Video Digital (DVB). Los sistemas DAB Y DVB comprenden también servicios bidireccionales, interactivos que permiten por ejemplo que servicios de cargo sean suscritos o que la información de realimentación sobre un servicio sea transmitida desde un terminal en una red. Tales servicios interactivos incluyen por ejemplo comercio electrónico, diferentes juegos y servicios de vídeo a petición o bajo demanda. Esto requiere que el terminal comprenda también medios para transmitir datos sobre una conexión de retorno, es decir transmitir datos a una red de retrasmisión. Típicamente, un terminal es a continuación provisto con una conexión con cables a una red fija, tal como una Red de Telefonía Conmutada Pública (PSTN), desde la cual otra conexión está prevista a una red DAB o DVB. La conexión de retorno puede también preverse usando una conexión con cables o inalámbrica, tal como una red de área local inalámbrica o una red de comunicación móvil. La conexión de retorno permite que diferente información, que puede ser cualesquiera datos, sea seleccionada para ser transmitida. Típicamente, la información de imagen o de voz que ha de ser trasmitida es obtenida desde los servidores de la red del proveedor de servicios, tal como una compañía de emisión de televisión. El documento WO9907152 describe un método para formar datos de selección de servicio, tal como una guía de programas, desde una identificación de servicio y datos de control situados en marcos multiplexados usados para trasmitir los servicios respectivos.
Como las tecnologías de transferencia de datos inalámbrica avanzan, cada vez más servicios son desplazados para ser realizados a través de diferentes redes de telecomunicación inalámbricas. Las limitaciones técnicas de la transferencia de datos inalámbrica explican por qué han sido típicamente desarrolladas diferentes redes para diferentes servicios. Por ejemplo, es razonable poner en práctica la transferencia de datos inalámbrica de banda ancha dirigida a un terminal técnicamente como una red de corto alcance solamente. Con el fin de utilizar los servicios de cada red, se han desarrollado típicamente aplicaciones específicas de red que pueden ser usadas típicamente solo por terminales diseñados por separado para la red. Además, cada red está típicamente provista con interfaces únicas entre terminales y diferentes elementos de red. La reciente tendencia con el fin de hacer convergir diferentes servicios con cables e inalámbricos ha introducido nuevas soluciones para integrar diferentes terminales. Por ejemplo, una tarjeta de extensión conectada a un ordenador personal (PC) permite que servicios de retrasmisión digital, tales como DAB o DVB, sean recibidos. Se conocen también soluciones en las que un ordenador y una tarjeta de interfaz para una Red de Área Local Inalámbrica (WLAN) están conectados a un terminal único. También se han proporcionado soluciones para conectar una tarjeta de red de área local para un puesto móvil en una red de radio celular, tal como una red GSM. El terminal para recibir retransmisiones puede ser por ejemplo un "Descodificador" (STB). El dispositivo STB permite que las retransmisiones digitales o los servicios de Internet sean recibidos por los receptores de televisión y radio analógicos existentes. La retrasmisión recibida es desmodulada, descodificada y desmultiplexada en el terminal. La señal codificada de fuente así obtenida típicamente puede ser además desestructurada a información real por ejemplo descodificando la codificación MPEG-2.
La convergencia de diferentes redes y servicios de telecomunicación y la integración de terminales permiten que los servicios proporcionados convencionalmente por una cierta red sean recibidos a través de otra red. Por ejemplo, un ordenador es capaz de recibir transmisiones de radio y televisión digitales a través de una conexión a Internet por medio de las tarjetas de acceso antes mencionadas. De manera similar, la conexión de una tarjeta de red de área local inalámbrica de retrasmisión a una estación móvil permite que la imagen de video sea recibida a través de una estación móvil convencional. Una tendencia que puede ser claramente discernida en este proceso es proporcionar, en el futuro, servicios proporcionados por diferentes redes a través de Internet, con cables o sin ellos.
En la transferencia de datos digital, el audio y el video constituyen corrientes de paquetes entrelazados entre sí en términos de tiempo por multiplexado. En la retrasmisión de video digital (DVB), estas corrientes de paquetes son denominadas corrientes elementales. Algunos de los paquetes DVB pueden contener marcas de tiempo, que son utilizadas para construir el tiempo real original imagen por imagen, es decir la relación entre la presentación y el tiempo. Por ejemplo, una mera señal de audio necesita una “marca de tiempo de presentación" mientras la imagen y la voz sincronizadas requieren “sincronización de labios” (“lip sync”) sincronizado con el mismo reloj maestro. En la transmisión DVB, los paquetes de corriente elemental son colocados en un canal de transmisión de emisión, es decir un canal de distribución por satélite o terrestre. Antes de la codificación de acuerdo con el canal de transmisión, los paquetes de corriente elemental son paquetes "normales" que tienen un número fijo de bits, que pueden ser transmitidos a través de una red de transmisión. A la red solo se le requiere que sea capaz de proporcionar una capacidad de transmisión suficiente para reconstruir el eje de tiempo en tiempo real en un receptor.
Una norma MPEG4 es un sistema para disponer presentaciones multimedia que contienen imagen y voz en movimiento. La norma está provista con suficiente información de modo que inicialice un terminal para un evento multimedia y también con especificaciones para inicializar la memoria y la interfaz de trayecto de transmisión necesarias para el evento. En las corrientes elementales, una presentación multimedia es separada en partes, conteniendo cada corriente elemental un aspecto diferente de información. Los tipos de información incluyen descripción del objeto, datos de imagen y voz de un objeto, descripción de la etapa e información del contenido de un objeto. Un MHEG2 (Grupo de Expertos Hipermedia Multimedia) ha especificado un lenguaje hipermedia más simple, que es también opcionalmente capaz de utilizar un descodificador de hardware de MPEG2. Un SMIL (Lenguaje de Integración Multimedia Sincronizado) es una recomendación del consorcio WWW internacional para construir una presentación multimedia. Puede ser una alternativa al MHEG en interfaces de programación basadas en HTML (API). Se puede decir que el MPEG2 es un formato de almacenamiento multimedia como lo son MID, WAV, MP3 o AVI y MPEG4. La presentación de un archivo de MPEG requiere un programa de presentación. El programa de presentación para un navegador Internet Explorer es Microsoft Media Player (“Reproductor de Medios de Microsoft”). Este, sin embargo, requiere que el archivo completo sea descargado a la memoria del terminal antes de que el programa sea capaz de desestructurarlo en una presentación multimedia.
Sin embargo, los formatos de corriente mencionados antes permiten que se presenten multimedia de acuerdo a cuando un dispositivo de cliente recibe datos. Por ejemplo, el software Stream Works por Xing Technologies Inc. está basado en el MPEG4, soportando también un servicio de transferencia múltiple de IP. Como la capacidad de transmisión de la redes de información aumenta, la capacidad de transmisión requerida por video y audio de MPEG2 ya no será problemática.
Por lo que se refiere a los terminales (generalmente dispositivos de cliente), el problema con los formatos de presentación multimedia descritos antes es la elevada capacidad de tratamiento que requieren. Un terminal en una red de banda ancha fija es capaz de procesar presentaciones multimedia descodificadas por software. En terminales inalámbricos usualmente, pequeños y portátiles, por el otro lado, la capacidad limitada presenta un problema. Una pantalla de presentación pequeña, por ejemplo, es ya una limitación especial. De manera similar, la pantalla de presentación impone limitaciones en soluciones de Internet en las que un receptor de televisión convencional funciona como pantalla de presentación.
Como la telecomunicación móvil y los servicios de DVB se desarrollan, se introducirán nuevos servicios multimedia que funcionan por ejemplo en la parte superior de una máquina Java o de una máquina MPEG (API), mientras que en ordenadores personales (PC) el sistema operativo más común es Windows. Los nuevos sistemas operativos para estaciones móviles incluyen EPOC y Windows CE. Un protocolo WAP de tipo WWW (Protocolo de Aplicación Inalámbrico) y un WML (lenguaje de Marcado Inalámbrico) han sido también proporcionados para dispositivos inalámbricos. Las características de los terminales varían por ejemplo en redes de comunicación móvil y en una red de telecomunicación con cable, y es así natural desarrollar sistemas operativos únicos e interfaces de programación (API) que están mejor adecuados cada uno para su propio entorno. Los sistemas operativos y las interfaces de aplicación (API) para dispositivos móviles optimizan el acceso de aplicación a los recursos de un dispositivo. En dispositivos de cliente, el API del dispositivo funciona como una interfaz de software para la telecomunicación y otros recursos del dispositivo. En lo que se refiere a las aplicaciones, estas son interfaces de programación similares (API) por ejemplo a los receptores de televisión digital de Java y MHEG, cuya versión del tiempo de ejecución funciona en el dispositivo de cliente cuando los servicios están siendo usados. Los paquetes IP proporcionan información sobre la aplicación que ha de ser usada de acuerdo con el número de puerto TCP. Las aplicaciones de HTTP o FTP, por ejemplo, tienen sus propios números de puerto, siendo las aplicaciones en sí mismas responsables para soportar presentaciones multimedia. Las mismas aplicaciones y métodos de presentación multimedia son, sin embargo, usados en diferentes sistemas operativos y entornos de interfaz de software. Las características de los terminales difieren mucho entre ellos, con el fin de ser capaces de utilizar servicios, el formato de almacenamiento de archivos que ha de ser seleccionado y trasmitido en respuesta a solicitudes de servicio tiene que estar de acuerdo con el entorno de software del dispositivo de cliente. En lo que se refiere al proveedor de servicios, sin embargo, la situación es más problemática. El propósito es proporcionar a los usuarios de diferentes redes de telecomunicaciones con los mismos servicios de contenido, más preferiblemente incluso desde el mismo servidor y una única dirección de Internet. En principio, esto es factible ya que los terminales cada vez en más redes tienen capacidad de Internet, siendo capaces de comunicar con un servidor conectado a Internet. Es simple, como tal, por ejemplo transferir una presentación multimedia desde un servidor a un terminal de acuerdo con los principios de encaminamiento TCP/IP descritos antes. El problema es, sin embargo, el modo en que una presentación multimedia puede ser transmitida a terminales móviles o terminales fijos equipados con codificadores multimedia puestos en práctica por diferente software o hardware de tal manera que la presentación multimedia transmitida es presentada por una norma apropiada que permite que un terminal particular procese la presentación. Las soluciones actuales no permiten por ningún medio que el servidor encuentre la norma o tecnología de capa de aplicación usada por el terminal y conforme su transmisión con ella. El único modo es usar diferentes direcciones o servidores de IP para diferentes tipos de terminales, para lo cual los propios terminales deben ser capaces de transmitir una solicitud de servicio. Podría ser también posible identificar paquetes suministrados desde diferentes redes y encaminarlos a los servidores o aplicaciones correctos analizando los identificadores de red de las direcciones de fuente o los paquetes IP.
Un objeto del invento es permitir que un servicio sea transmitido desde un servidor a un dispositivo de cliente en la forma seleccionada de acuerdo con las características del dispositivo de cliente.
Esto es conseguido por un método para implantar un servicio desde un servidor a dispositivos de cliente que tienen diferentes características, comprendiendo el método las operaciones de un dispositivo de cliente que transmite un paquete de Protocolo de Internet (IP) que comprende un encabezamiento IP, un encabezamiento de capa de protocolo de transferencia y datos de la capa de aplicación; encaminar el paquete IP al servidor de acuerdo con una dirección de destino de dicho encabezamiento IP; transferir, en el servidor, el encabezamiento de capa de transporte y los datos de capa de aplicación desde la capa IP al protocolo de capa de transporte de acuerdo con un identificador de protocolo de dicho encabezamiento IP; transferir, en el servidor, los datos de la capa de aplicación desde la capa de protocolo de transferencia a la capa de aplicación de acuerdo con un número de puerto contenido en dicho encabezamiento de capa de protocolo de transferencia. El método está caracterizado porque el dispositivo de cliente (TE) incluye, en el paquete IP que transmite, información sobre una interfaz de software (API) usada por las aplicaciones del dispositivo de cliente que solicita un servicio, y dicha información es usada en el servidor para seleccionar y/o configurar o bien un archivo solicitado por el dispositivo de cliente o bien una aplicación que interactúa con el dispositivo de cliente de tal manera que el servicio es proporcionado de la forma requerida por las características del dispositivo de cliente particular que solicitó el servicio.
Este objeto es también conseguido por un terminal y un servidor de acuerdo con las reivindicaciones 8 y 9.
La idea subyacente del invento es que un dispositivo de cliente, tal como un terminal en una red de telecomunicaciones, incluye, en un paquete IP que transmite, información sobre las características del dispositivo de cliente que solicita un servicio. Esta información puede revelar por ejemplo qué tipo de sistema operativo o interfaz de programación de aplicación (API) utiliza el dispositivo de cliente. En una realización preferida del invento, la información es un identificador del que ciertos valores están dispuestos para referirse a una cierta característica o a una combinación de características del dispositivo de cliente o de la aplicación. Esta información es enviada en el paquete IP al servidor para ser utilizada en la selección de una aplicación adecuada para la configuración de tal manera que el servicio es proporcionado en la forma requerida por las características y/o aplicación del dispositivo de cliente particular que solicita el servicio. Gracias al invento, en lo que se refiere al proveedor de servicios, están integradas diferentes redes en una única total de tal manera que cuando el operador conecta un servidor a una red, el servidor, basado en el IP, es capaz de dar servicio a solicitudes suministradas a través de la misma conexión a Internet fija ya que la carga útil de los servicios pues ser transmitida en una forma estándar comprendida por un terminal particular. No hay necesidad de que el proveedor de servicios configure ninguna interfaz de servicio de red extra con el fin de alcanzar a los clientes que acceden al mundo IP a través de diferentes redes.
Cuando la información del identificador de acuerdo con el invento es utilizada en el paquete IP además de los números de puertos y números de protocolo conocidos, el servidor es también capaz de dar servicio a clientes "convencionales", que no soportan la funcionalidad del invento. Si el paquete IP recibido por el servidor no contiene información del identificador, el servidor proporciona el servicio al que se hace referencia típicamente por el número de puerto o el número de protocolo conocidos del paquete IP. Si el paquete contiene la información de identificador, el cliente recibirá un servicio personalizado según sus deseos. El terminal, a su vez, puede siempre añadir la información del identificador al paquete IP y asegurarse de que recibirá, sin embargo, el servicio al menos en la forma de acuerdo con el número de puerto "conocido" si el servidor no debería soportar el formato especial deseado por el terminal. En otras palabras, algún tipo de servicio será siempre asegurado.
La información o el identificador de acuerdo con el invento pueden, en principio, ser incluido en cualquier parte del paquete IP. Puede estar incluido por ejemplo en el encabezamiento IP, en el encabezamiento de capa de transporte o en los propios datos de la capa de aplicación. El encabezamiento IP o el encabezamiento de capa de transporte pueden emplear posiciones o campos de bits indeterminados adecuados, o a parámetros que ya están siendo utilizados pueden dárseles nuevos valores.
En una realización del invento, cuando la información del identificador en la interfaz de software por debajo de la aplicación está incluida en los datos de la aplicación, la propia capa de la aplicación puede ser configurada para soportar la provisión del servicio y al selección del archivo que ha de ser transmitido al cliente de una forma adecuada para el dispositivo de cliente que ha transmitido la solicitud de servicio. En una realización del invento, se usa un SLP (Protocolo de Posición de Servicio) o similar para hacer un servidor que proporcione un servicio adecuado más fácil de encontrar para el terminal. Los servicios disponibles, sus formatos diferentes y números de puerto, números de protocolo y/o identificadores que han de ser usados para solicitar diferentes servicios y diferentes formatos de servicio son almacenados en conexión con un agente de directorio. Cuando un usuario del terminal ha de establecer una conexión a un servicio particular, emite, directa o indirectamente, una solicitud de servicio al agente del directorio. El usuario del terminal no necesita conocer ninguna información detallada en dicho servicio, tal como en qué dirección de red está disponible el servicio o los parámetros de telecomunicaciones usados. En la solicitud de servicio emitida, el usuario del terminal puede especificar atributos diferentes del servicio deseado, tales como el tipo de servicio, los protocolos de red y los formatos de servicio soportados por el terminal, y cierta información relativa a las características de la interfaz de software del terminal que afecta a la selección del formato de servicio. El agente del directorio busca a través de los servicios registrados en él para la descripción del servicio especificada por la solicitud del servicio. Si hay disponible un servicio de acuerdo con la solicitud de servicio, el agente del directorio devuelve la información del servicio, tal como la dirección URL, a los servidores que proporcionan el servicio particular. Este método para encontrar un servidor es particularmente adecuado cuando un terminal debería conocer un cierto número de puerto o un número de protocolo con el fin de recibir un servicio de una forma correcta desde el servidor.
Otro objeto del invento es permitir que un servicio de transferencia múltiple o emisión sea transmitido en una forma sobre la base de que un dispositivo de cliente es capaz de descargar una interfaz de aplicación correcta y la aplicación de modo que presente el servicio al cliente de una forma correcta.
Esto se consigue mediante un método según la reivindicación 15, un servidor según la reivindicación 17, y un terminal según la reivindicación 18.
Aquí, el principio básico del invento, es decir un identificador de interfaz de programación de aplicación, es aplicado en una dirección opuesta, es decir para controlar un dispositivo de cliente desde un servidor. Cuando el servidor trasmite sus servicios en la forma de emisión o transferencia múltiple, el servidor incluye, en el paquete IP que transmite, información sobre la interfaz de software por debajo de la aplicación usada para presentar el servicio, y esa dicha información es usada en un dispositivo de cliente para configurar y/o descargar la aplicación y la interfaz de programación de aplicación desde el dispositivo de cliente o la red.
Cuando la transmisión es llevada a cabo directamente desde un servidor de medios de una red de emisión, por ejemplo en un multiplexado de DVB o DAB, el identificador de interfaz de software puede también ser colocado en la información del identificador en un marco de emisión multiplexado, en cuyo caso el dispositivo de cliente (receptor de emisión) es capaz de descargar una interfaz de software y la aplicación correctas o un programa de protocolo desde su memoria o la red.
Mientras se recibe el servicio, el dispositivo de cliente puede así seleccionar un entorno de software de acuerdo con el servicio tanto para el API como para la aplicación también. Por ejemplo, un mensaje de solicitud suministrado desde una red de protocolo de Aplicación Inalámbrico (WAP) a un servidor de Internet WWW a través de un proxy WAP o una pasarela puede ser suministrado desde un terminal móvil que tiene una apilamiento de protocolo WAP estandarizado de por si, pero como los terminales WAP móviles emplean diferentes interfaces de software y por ello también diferentes aplicaciones, la solicitud debería contener preferiblemente información que indique qué interfaz de software (por ejemplo EPOC o Windows CE) o incluso qué versión de interfaz de software usa el dispositivo. Cuando esta interfaz de software es conocida, también es posible descargar “plug-ins” necesarios, es decir módulos de software adecuados para la interfaz de software del dispositivo de cliente, desde servidores en Internet utilizando el identificador de interfaz de software de acuerdo con el inventote modo que presenten el propio contenido del servicio.
Aún otro aspecto del invento es un método de encaminamiento según la reivindicación 19 y un encaminador según la reivindicación 21.
La información del identificador de acuerdo con el invento también puede ser usada para encaminar un paquete IP en una red. Dependiendo de la información del identificador, un paquete IP que tiene la misma dirección IP puede ser encaminado de diferentes modos en una realización del invento: En la propia red de área local del proveedor de servicios, dos o más servidores (posiblemente virtuales) pueden ser accedidos usando la misma dirección de IP. El encaminamiento a un servidor correcto dentro de una red es determinado de acuerdo con la información del identificador del invento.
A continuación, el invento será explicado por medio de las realizaciones preferidas y con referencia a los dibujos adjuntos, en los que
La fig. 1 ilustra una estructura de protocolo TCP/IP y subredes, un encaminador y ordenadores anfitriones,
La fig. 2 muestra un apilamiento de protocolo que ilustra cómo una capa de transporte es dividida en módulo de protocolo TCP y UDP, y puertos a través de los cuales estos son conectados a aplicaciones de la capa de aplicación.
La fig. 3 muestra un sistema de telecomunicaciones al que puede ser aplicado el invento,
La fig. 4 es un apilamiento de protocolo de acuerdo con una realización preferida del invento,
La fig. 5 es un apilamiento de protocolo de acuerdo con una realización preferida del invento, en el que un puerto desde la capa de transporte a la capa de aplicación es seleccionado sobre la base de un identificador de acuerdo con el invento y un número de puerto recibido,
La fig. 6 es un diagrama de flujo que ilustra un proceso de acuerdo con el invento, que opera en la capa de transporte en la realización de la fig. 4,
La fig. 7 es un apilamiento de protocolo de acuerdo con otra realización del invento, en el que una capa de red selecciona un identificador de protocolo y un módulo de protocolo de capa de transporte sobre la base de información de acuerdo con el invento, y
La fig. 8 es un diagrama de flujo de un proceso que pone en práctica la operación de una capa de red del invento en la realización de la fig. 7.
El presente invento es adecuado para usar en todos los sistemas de telecomunicaciones en los que un dispositivo de cliente, típicamente un terminal en una red de telecomunicaciones, es capaz de comunicar a través de un apilamiento de protocolo TCP/IP con un servidor conectado a la misma o a otra red. El servidor puede ser por ejemplo un servidor que proporciona generalmente servicios de Internet, y el cliente un terminal en una red de telecomunicaciones con cables o inalámbrica.
La fig. 3 ilustra un sistema de telecomunicaciones que comprende un BN de red que proporciona emisiones a un terminal TE, y un RN de red que proporciona una conexión de retorno al terminal. La información es entregada al terminal TE como una emisión mediante Internet desde los servidores S1 y S2 o desde los servidores S3 y S3’ conectados a una red de área local LAN.
El terminal TE recibe emisiones desde el BN de la red de emisión. Típicamente, una emisión comprende información presentada por medio de una guía de programación electrónica (EPG) sobre servicios y programas que pueden ser seleccionados por un usuario. El terminal TE muestra preferiblemente la información por medio de una interfaz de usuario de tipo navegador en que diferentes fuentes de información están enlazadas (por ejemplo Hiperenlaces en un navegador WWW). La información puede ser dividida en servicios que no requieren configurar una conexión de retorno y a servicios que requieren que una conexión de retorno sea configurada. Una conexión de retorno debe ser también configurada si el usuario desea recibir servicios en cualquier otro sitio distinto del BN de la red.
Cuando el usuario ha de transferir información, tal como una presentación multimedia, desde el servidor S1, S2 o S3 conectado a Internet mediante una emisión de alta velocidad, el TE entrega una solicitud para que una conexión de retorno sea configurada mediante Internet a un servidor particular S1, S2 o S3 sobre la base de un identificador URL (dirección IP) que identifica el servicio.
La conexión de retorno puede estar dispuesta de forma inalámbrica por ejemplo mediante una red GSM (Sistema Global para comunicaciones Móviles) o una red de área local inalámbrica. Por otro lado, la conexión de retorno puede estar dispuesta también mediante una red con cables, tal como una red con cables, una red PSTN (Red de Telefonía Conmutada Pública) o una red ISDN (Red Digital de Servicios Integrados). El terminal TE comprende las funciones necesarias tanto para configurar una conexión de retorno como para recibir emisiones, preferiblemente integradas en un dispositivo único. El identificador del BN de la red es almacenado en el terminal TE, por ejemplo, en una tarjeta inteligente. Una BSP es por ejemplo una red de televisión digital (TV digital). En el futuro en particular, cuando la tasa de transmisión de las redes inalámbricas también sea suficientemente elevada (sistemas de comunicación móviles de tercera generación), la red de retorno y la red de emisión pueden ser una única red, y la transmisión puede tener lugar en ambas direcciones a través de la misma conexión.
Si la configuración de la conexión al servidor S1 o S2 es satisfactoria, la información es entregada desde el servidor a la dirección IP especificada por la solicitud. La información puede comprender por ejemplo un archivo que ha de ser transmitido usando una página WWW o un protocolo FTP. La información es entregada al terminal TE como una emisión mediante el BN de la red. Preferiblemente, la información de emisión, es cifrada de tal manera que el cifrado puede ser descifrado solamente por el terminal TE que ha seleccionado la información a través de la conexión de retorno. Esto puede ponerse en práctica por ejemplo entregando las claves necesarias para descifrar el cifrado al terminal TE. Las claves necesarias para el descifrado son preferiblemente almacenadas en una tarjeta inteligente, lo que facilita al usuario cambiar su terminal. Cuando la información es emitida al terminal TE, el BN de la red cifrará la información, usando una clave de cifrado que coincide con la clave de descifrado del TE.
Un terminal TE para recibir emisiones puede ser por ejemplo un “codificador” (STB). El dispositivo STB permite que las emisiones digitales o servicios de Internet sean recibidos por los receptores de TV y radio analógicos existentes. El terminal TE puede estar integrado también en un ordenador por ejemplo por medio de diferentes tarjetas receptoras de PC. Además, el terminal puede ser una estación móvil o puede estar integrado en una estación móvil. En el terminal TE, la emisión recibida es desmodulada, descodificada y desmultiplexada. La señal fuente típicamente codificada así obtenida puede ser además desestructurada en información real por ejemplo descodificando la codificación MPEG2.
Antes se ha descrito un entorno que está notablemente bien adecuado al invento. El invento no está, sin embargo restringido a estas redes; a continuación, el invento será
descrito generalmente, sin estar conectado a redes particulares.
El principio básico del invento es que un dispositivo de cliente, por ejemplo un anfitrión A en la fig. 1 o el terminal TE en la fig. 3, añade un identificador que proporciona información sobre una interfaz de software del dispositivo de cliente a un paquete IP que transmite a un servidor (por ejemplo anfitrión B en la fig. 1 o el servidor S1 en la fig. 3), sobre la base de cuya información el servidor conoce de qué forma deberían ser transmitidos al dispositivo de cliente los datos asociados con un servicio. En principio, es irrelevante para el invento en qué punto del paquete IP o en qué forma es transmitida la información. En la práctica, sin embargo, es seleccionada una manera que complica o cambia el funcionamiento usual de los protocolos TCP/IP tan poco como sea posible. Usualmente es preferible seleccionar un campo o una posición de bit que no ha sido usado antes. La nueva facilidad del invento es a continuación invisible a dispositivos que no lo soportan. Es también factible proporcionar campos que ya han sido usados con nuevos valores, pero esto puede causar problemas con servidores que no conocen el nuevo valor y su significado. La posición en que la información está colocada es algunas veces afectada también por el hecho de en qué capa de protocolo utiliza el servidor la información. Por ejemplo, no es necesaria una buena idea para colocar la información en el encabezamiento IP si la información no será usada hasta la capa TCP/UDP ya que el encabezamiento IP no será transmitido a la capa de transporte. La información debe ser a continuación transmitida desde una capa inferior a una capa superior de algún otro modo. En las realizaciones preferidas del invento que se han de describir a continuación, se sugerirán algunas alternativas para colocar la información en un paquete IP, pero el invento no está restringido a estos ejemplos.
En el dispositivo de cliente, el apilamiento de protocolo (anfitrión A o el terminal TE) es de acuerdo con la fig. 1. Además, un nuevo proceso es necesario en la parte del programa que añade la información del identificador de acuerdo con el invento. Por ejemplo, si la información del identificador es añadida en un IP de capa de red, el nuevo proceso debe ser a continuación añadido al programa de IP, que compone un paquete IP. El programa puede ser configurado para adjuntar un cierto identificador a los paquetes de una aplicación particular mientras la aplicación está siendo instalada. Un identificador puede ser añadido basado por ejemplo en un número de puerto. Cuando la capa de transporte TCP/UDP recibe datos desde un puerto de aplicación particular, un identificador predeterminado es añadido a un paquete IP correspondiente.
Dos versiones de paquetes de IP han sido actualmente especificadas, la versión 4 (IPv4) y la versión 6 (IPv6). Un encabezamiento IPv6 puede emplear encabezamientos de extensión y particularmente un encabezamiento de opciones de destino. No se ha especificado aún un uso exacto para este encabezamiento de extensión, pero es un propósito para transferir información que ha de ser examinada por un nodo de destino (dispositivo). Es así bien adecuado para el propósito del invento. Un encabezamiento IPv4 comprende también un campo de opciones de una longitud variable, que puede usarse para trasmitir la información del identificador del invento. Un encabezamiento de TCP comprende un campo de 6 bits reservado para un uso posterior; parte del campo podría posiblemente ser usada para la información del identificador del invento.
En una realización preferida del invento, un proceso de interfaz de software de aplicación es seleccionado o descargado en la parte superior de una capa de protocolo de la capa de transporte (TCP o UDP) usando un identificador de interfaz de software de aplicación (identificador API). Un módulo de software de TCP o UDP puede adaptar el módulo de software de IP y la interfaz de software de aplicación entre sí, es decir el software del protocolo TCP/UDP es descargado en el servidor de acuerdo con la interfaz del software. Alternativamente, la interfaz del software está prevista para el módulo de software de TCP/UDP, en cuyo caso el módulo de software del protocolo de TCP/UDP permanece igual, independientemente de la interfaz de software de aplicación.
La realización preferida del invento está ilustrada en la fig. 4 que muestra una estructura de protocolo en un servidor final. Las interfaces de módulo de protocolo de TCP y UDP a las aplicaciones son proporcionadas por puertos, que son especificados por los números de puerto x e y. Las capas de protocolo inferiores de TCP, UDP, IP y una capa de enlace de datos y una capa física pueden a continuación ser completamente estandarizadas (véase la fig. 2). Un módulo de software de aplicación que comprende dos aplicaciones diferentes 1 y 3 y dos interfaces de software diferentes API1 y API2 que han de ser seleccionadas o descargadas de acuerdo con el identificador API del invento está conectado al puerto Y de TCP. Una aplicación y una interfaz de programación de aplicación API1 pueden ser seleccionadas o descargadas a través del puerto X de TCP. De manera similar, el puerto X de UDP comprende la aplicación 4 y las interfaces de software de la aplicación API1 y API2 que han de ser seleccionadas o descargadas. Un proceso de selección, ilustrado por API MUX en la figura, lleva a cabo la selección sobre la base del identificador API recibido. Si el terminal trasmite el identificador API en un paquete IP en los datos de la capa de aplicación, por ejemplo en el encabezamiento de una unidad de datos de protocolo (un paquete o un marco) de acuerdo con el servicio particular, el API MUX recibe el identificador API directamente en los datos de la aplicación. Si, de nuevo, el identificador API es recibido en los campos de encabezamiento de la capa de IP o de transporte, un módulo de protocolo inferior extrae el identificador API desde el paquete IP y lo envía al módulo API MUX. Hablando en términos generales, el software de aplicación y “el software API” relacionado, posiblemente incluso un módulo de TCP/UDP, son seleccionados, descargados o configurados de acuerdo con un identificador API recibido.
En la presente aplicación, el término "interfaz de programación de aplicación API" debería ser entendido en amplio sentido. Puede contener una interfaz de programación de aplicación (API), también un sistema operativo en la parte superior del cual ha sido implantada la aplicación, y otras facilidades relacionadas con el tratamiento de señal, el uso de servicios de capa de protocolo inferior o un formato de servicio adecuado para el dispositivo de cliente. En el presente ejemplo, se ha supuesto que la API1 es una interfaz adecuada para un terminal en una red fija y la API2 es una interfaz adecuada para un terminal en una red inalámbrica. Otro ejemplo posible es que la API1 está diseñada para terminales en una red de banda ancha fija que son capaces de procesar presentaciones multimedia descodificadas por software mientras la API2 está diseñada para terminales que son capaces de procesar presentaciones multimedia descodificadas por hardware. Las versiones de API pueden también diferir porque son capaces de soportar diferentes objetos multimedia y/o diferentes descripciones de estado.
Cuando la información del identificador de API está en los datos de la aplicación (el campo de datos del paquete IP), los datos de la capa de aplicación del paquete IP recibido pueden ser transmitidos de una manera usual a un puerto particular a la capa de aplicación de acuerdo con el número de protocolo y el número de puerto recibidos. En la fig. 4, dos bases de datos DB1 y DB2 están conectadas a la aplicación 2, seleccionando la capa de aplicación un archivo que ha de ser transmitido de acuerdo con el identificador API desde una de las bases de datos. Las bases de datos proporcionan por ejemplo diferentes objetos multimedia o descripciones de estado. La aplicación examina si los datos recibidos contienen un identificador ID, y sobre la base del identificador selecciona qué tipo de archivo ha de ser transmitido al cliente. Por ejemplo, un identificador ID1 puede hacer que un archivo sea trasmitido desde la base de datos DB1 mientras que un identificador ID2 hace que un archivo sea transmitido desde la base de datos DB2. Si los datos del usuario no contienen identificador ID, se selecciona la base de datos DB1 por defecto.
La aplicación 2 de la fig. 4 puede por ejemplo ser una aplicación que proporciona un servicio WWW (puerto 80 de TCP conocido). Cuando la capa de API o la aplicación 2 recibe el identificador de API en los datos de la aplicación desde el puerto x (puerto 80) sobre la base del identificador de API selecciona desde su jerarquía de archivos un archivo correspondiente a la interfaz de software de la aplicación del cliente, y así la aplicación, que ha de ser trasmitida al cliente. Este principio básico del invento puede también ser aplicado en sentido opuesto transmitiendo un servicio de transferencia múltiple y de emisión en una forma sobre la base de que el dispositivo de cliente es capaz de descargar una interfaz de aplicación y la aplicación correctas de modo que presente un servicio en una forma correcta al cliente. Por ejemplo, cuando el servidor S1 trasmite su servicio en la forma de emisión o transferencia múltiple, el servidor incluye, en el paquete IP que transmite, información sobre la interfaz de software API1 o API2 por debajo de la aplicación usada para presentar el servicio. El dispositivo de cliente TE que recibe el paquete IP utiliza esta información para configurar y/o descargar la aplicación y la interfaz de programación de la aplicación o el módulo de programa de protocolo (tal como el TCP o UDP) bien desde la memoria del programa del dispositivo del cliente o bien desde la red. Esto puede tener lugar como se ha explicado en conexión con el servidor con referencia a la fig. 4. Las soluciones descritas a continuación con referencia a las figs. 5 a 8 pueden también ser aplicadas al terminal. Un ejemplo de una interfaz de programación de aplicación adecuada es una versión de tiempo de ejecución para una máquina Java, que es descargada después de que el terminal ha identificado la información de interfaz de software procedente del paquete IP recibido. Una aplicación que soporta la máquina Java, tal como una aplicación HTTP, es descargada sobre la parte superior de la máquina Java de acuerdo con el número de puerto de la aplicación.
Si el servidor está situado en una red de emisión, como la BN en la fig. 3, el servidor puede incluir, en la información del identificador sobre marcos de emisión, información sobre la interfaz de software por debajo de la aplicación usada para presentar el servicio. El dispositivo de cliente TE utiliza esta información para configurar y/o descargar la aplicación y la interfaz de programación de aplicación o el programa de protocolo como se ha descrito antes.
La fig. 5 ilustra una estructura de protocolo en un servidor final en una realización del invento en la que el identificador de API es transmitido en el encabezamiento IP del paquete IP y la información del identificador es utilizada en la capa de red en el módulo de programa de protocolo IP. La capa de transporte comprende dos o más módulos TCP1 y TCP2 de programa de protocolo TCP, y dos o más módulos UDP1 y UDP2 de programa de protocolo UDP. El módulo TCP1 de TCP comprende el puerto Y, al que está conectada la aplicación 1 equipada con la interfaz de programación de aplicación API1. El puerto Y del módulo 2 de programa de TCP está conectado a la aplicación 1’ equipada con una interfaz diferente API2. Las aplicaciones 1 y 1’ proporcionan el mismo servicio, aunque en diferentes formatos, lo que es fundamentalmente determinado por las funciones ilustradas en las interfaces API1 y API2. En su forma más sencilla, las aplicaciones 1 y 1’ pueden ser similares excepto para las interfaces de API, pero en la práctica las diferencias pueden ser mayores. Los puertos X de los módulos 1 y 2 de programa de TCP están conectados a través de las diferentes interfaces API1 y API2 a diferentes versiones 2 y 2’ de la misma aplicación. El mismo servicio es así proporcionado a través de los puertos, solamente adecuado para diferentes tipos de dispositivo de cliente o aplicaciones de cliente. De manera similar, los puertos X de los módulos 1 y 2 de programa de UDP están conectados a diferentes versiones 3 y 3’ de la misma aplicación a través de las diferentes interfaces API1 y API2, en cuyo caso proporcionan el mismo servicio adecuado para diferentes dispositivos de cliente o aplicaciones de cliente. En la arquitectura de protocolo de la fig. 5, el módulo de programa de IP transmite el encabezamiento de TCP o el encabezamiento de UDP y los datos de la capa de aplicación al módulo de programa de TCP o de UDP correcto sobre la base de la información del identificador ID del invento y el número de protocolo en el encabezamiento IP (TCP = 6, UDP = 17). Este número de protocolo está en el campo de protocolo en el encabezamiento IPv4 y en el siguiente campo de encabezamiento en el encabezamiento IPv6. Las unidades de TCP y UDP son seleccionadas por ejemplo como se ha descrito en el diagrama de flujo de la fig. 6. El programa de IP recibe el paquete IP en la operación 41 y examina el encabezamiento IP. En la operación 42, se examina si el número de protocolo es el número determinado para el protocolo de TCP. Si es así, el proceso se mueve a la operación 43 para examinar si el número de identificador del invento es el mismo que el número de identificador ID1 del módulo de programa TCP1. Si es así, el módulo de programa TCP1 es seleccionado en la operación 44, y el encabezamiento TCP y los datos de aplicación son transmitidos al mismo. A continuación, el módulo TCP1 del programa de TCP transmite los datos de la capa de aplicación al puerto Y o X, de acuerdo con el número de puerto en el encabezamiento de TCP recibido. Si el identificador ID recibido no ha correspondido con el identificador ID1 en la operación 43, se examina en la operación 45 si el identificador recibido corresponde con el identificador ID2 de otro módulo TCP2 de programa de TCP. Si es así, el TCP2 es seleccionado y el encabezamiento de TCP y los datos de la capa de aplicación son transmitidos al mismo. Si el ID y el ID2 recibidos no coinciden en la operación 45, el proceso se mueve para comprobar un siguiente identificador IDn en la operación 47, y un módulo de programa correspondiente TCPn es seleccionado si los identificadores coinciden. Si el ID recibido no coincide con ningún identificador ID usado en el servidor, el identificador recibido es definido como desconocido, y se selecciona un módulo de programa de TCP por defecto. Este podría ser típicamente un TCP conectado a una aplicación que soporta un terminal en una red de banda ancha fija, ya que es más probable que un terminal que usa características especiales conozca también como usar el identificador ID. Si el paquete IP recibido no contiene el identificador ID en absoluto, será también seleccionado un módulo de TCP por defecto ya que el paquete ha sido entonces probablemente suministrado desde un dispositivo de cliente en una red fija.
Si, en la operación 42, el número de protocolo no corresponde al número de protocolo de TCP, se ha supuesto que el protocolo es de UDP, y el proceso se mueve a las operaciones 50, 52 y 54 para comprobar si el ID recibido corresponde con cualquiera de los identificadores ID1, ID2,… IDn, y un módulo UDP1…n de programa de UDP correspondiente es seleccionado en las operaciones 51, 53 y 55. Si no se ha recibido el ID
o es desconocido, un UDP por defecto es seleccionado de nuevo en la operación 56. En los módulos 1 y 2 de programa de UDP, los datos de la capa de aplicación son también transmitidos a un puerto indicado por el número de puerto en el encabezamiento de UDP recibido.
La fig. 7 muestra una segunda arquitectura de protocolo que comprende solo un módulo de programa de TCP y un módulo de programa de UDP, como es usual. Una nueva característica, sin embargo, es que el módulo de programa de TCP comprende dos puertos designados por el número de puerto X y dos puertos designados por el número de puerto Y. De manera similar, el módulo de programa de UPD comprende dos puertos designados por el número de puerto X recibido. El módulo de programa de TCP selecciona un puerto correcto sobre la base tanto del número de puerto recibido como del identificador ID recibido. Si el identificador recibido es ID1 y el número de puerto recibido es X, los datos de la capa de aplicación son dirigidos al puerto X, que está conectado a la aplicación 2 a través de la interfaz API1. Si el identificador recibido es ID2 y el número de puerto es X, los datos de la capa de aplicación son dirigidos al puerto X’, que está conectado a la aplicación 2 de un tipo similar a través de la interfaz diferente API2. De manera similar, el puerto Y es seleccionado si el número de puerto Y, y el identificador ID1 son recibidos. El puerto Y’ es seleccionado si el número de puerto Y, y el identificador ID2 son recibidos. Si no hay ID en absoluto o es desconocido, el puerto es seleccionado sobre la base del número del puerto recibido solamente. Las operaciones 61, 62 y 63 del método en el diagrama de flujo de la fig. 8 ilustran el funcionamiento de un módulo de programa de TCP. El módulo de programa de TCP puede obtener el identificador recibido a partir del encabezamiento de TCP. Otra alternativa es que el módulo de programa de IP haya recibido el identificador ID en el encabezamiento IP de un paquete y transmita el identificador al módulo de programa de TCP como un parámetro, como se ha ilustrado por la flecha 71 en la fig. 6.
El módulo de programa de UDP funciona de una manera similar. Si el número de puerto X y el identificador ID1 son recibidos, el puerto X es seleccionado, que está conectado a la aplicación 4 a través de la interfaz API1. Si el número de puerto X y el identificador ID2 son recibidos, el puerto X’ es seleccionado, que está conectado a la aplicación 4 a través de la interfaz API2. De nuevo, el módulo de programa de UDP puede recibir el identificador ID bien desde el encabezamiento de UDP o como un parámetro 72 separado desde la capa de IP.
Una ventaja de las realizaciones descritas anteriormente es que permiten que se usen números de puerto conocidos generalmente para diferentes servicios y números de protocolo conocidos que han de ser usados para protocolos de TCP y UDP. En tal caso, un terminal que añade un identificador ID a un paquete de datos pero usa el número de puerto común, conocido recibirá siempre un servicio al menos en una forma menos adecuada incluso aunque el servidor no haya soportado la versión del servicio que se adecuaría del mejor modo posible al terminal. La situación en el servidor específico solo corresponde a la situación en que el terminal se encuentra actualmente en la técnica anterior. Esto es preferible ya que el usuario es capaz ahora de ver diferentes “sitios” en Internet sin que todo el tiempo esté obligado a conocer qué versión de servicio ha de usar.
En la arquitectura de la fig. 7, el terminal puede en principio directamente en el encabezamiento de TCP del paquete IP indicar el número de puerto Y’ o X’. Este debería, sin embargo, trabajar también en paralelo con el número de identificador ID a fin de conseguir compatibilidad con el uso de los números de puerto conocidos. De otra manera el problema es que si el servidor no soporta el uso del puerto particular, el terminal no recibirá ningún servicio en absoluto. En tal caso, el módulo de programa de TCP convierte por ejemplo el número de puerto recibido Y en el número de puerto Y’ si el identificador ID2 es también recibido en el mismo paquete IP; de otro modo el paquete de suministrado al puerto Y.
De una manera similar, los módulos 1 y 2 del TCP y los módulos 1 y 2 de UDP podrían ser indicados por un número de protocolo predeterminado de su propiedad en la arquitectura de la fig. 5. Esta, cuando se desee, también debería trabajar en paralelo con la realización de la fig. 4 de tal modo que si el módulo de programa de IP recibe el número de protocolo corriente relativo al protocolo de TCP o UDP, y por ejemplo el identificador ID1, selecciona aún el módulo de protocolo TCP1, como se ha descrito en conexión con la fig.
5. Si por otro lado, se recibe un número de protocolo que apunta directamente al módulo de protocolo TCP1, el encabezamiento de TCP y los datos de la capa de aplicación son transmitidos a este módulo.
Sería preferible así si el terminal pudiera encontrar servidores que proporcionen un cierto servicio en un formato deseado y posiblemente incluso los números de puerto del mismo sin intentar cada servidor por separado. Un Protocolo de Posición de Servicio (SLP) estandarizado en conexión con Internet puede ser usado preferiblemente con este propósito. El protocolo SLP está diseñado para hacer que se encuentren recursos de red diferentes y servicios más simples. El SLP es un proceso de entrega de servicios basado en cliente-servidor con base en la tecnología de agente conocida de por sí, que permite que los servicios deseados por un usuario sean unidos dinámicamente a la dirección de red que entrega el servicio. La estructura del SLP está descrita con referencia a la fig. 3. Un usuario emite una solicitud de servicios desde la aplicación A en el terminal de usuario TE a un agente de usuario UA en la red, siendo el agente de usuario un procedimiento de programa que funciona independientemente en la red para el usuario, buscando a través de la red un servicio según los atributos definidos por el usuario. Los servidores S1, S2 y S3 en la red presentan información de servicios sobre los servicios que proporcionan, tal como información de dirección de acceso y configuración sobre los servicios. Los agentes de directorio DA recogen información de servicio proporcionada por los servidores en un solo lugar, lo que significa que los agentes de directorio DA son provistos con información en todos los servicios disponibles.
Cuando un usuario en una red inalámbrica desea usar un cierto servicio, el usuario emite una solicitud de servicio desde la aplicación en su terminal TE a un agente de usuario UA en la red para la información de servicio sobre el servicio particular que ha de ser encontrado. Si el agente de usuario UA conoce la dirección del agente de directorio DA, el agente de usuario UA puede presentar una solicitud de servicio de transferencia unívoca al agente de directorio DA. Si de nuevo, el agente de usuario UA no conoce la dirección del agente de directorio DA, el agente de usuario UA puede presentar solicitudes de servicio de transferencia múltiple a una pluralidad de servidores definidos específicamente por el servicio. Los servidores S1, S2 y S3 registran la información de servicio sobre los servicios contenidos en el agente de directorio DA, que reconoce la información recibida. Los servidores S1 a S3 han de registrar y actualizar su información de servicio a intervalos determinados; de otro modo la información de servicio es retirada de los directorios del agente de directorio DA. Los servidores S1 a S3 informan también al agente de directorio DA si los servicios particulares ya no son usados, en cuyo caso, el agente de directorio DA elimina la información de servicio sobre los servicios particulares de sus directorios. Los agentes de directorio DA están siempre así provistos con información actualizada sobre los servicios disponibles. En respuesta a la solicitud de servicio de transferencia unívoca emitida por el agente de usuario UA, el agente de directorio DA examinan si un servicio de acuerdo con la solicitud de servicio puede ser encontrado en los directorios e informa al agente de usuario UA de que la información de servicio sobre un servicio ha sido encontrada posiblemente, enviando el agente de usuario UA la información de dirección sobre el servicio al terminal TE. Sobre la base de la información de dirección, el terminal TE es capaz de configurar al servicio deseado. Similarmente, los servidores S1 a S3 replican a la solicitud de servicio de transferencia múltiple emitida por el agente de usuario UA si la solicitud de servicio emitida corresponde a la información de servicio sobre los servicios entregados por el servidor. Los agentes de usuario están siempre así provistos con información actualizada sobre la información de dirección y configuración de los servicios disponible, y el terminal es capaz de conectar al servicio en una dirección correcta. El protocolo SLP está descrito con mayor detalle en la solicitud de cambio de Internet RFC2165.
El protocolo SLP puede también ser utilizado preferiblemente en las diferentes realizaciones del presente invento de tal modo que la dirección de red, preferiblemente la dirección de IP, de los servidores que proporcionan servicios especiales de acuerdo con el invento es almacenada en conexión con un agente de directorio DA de acuerdo con el protocolo SLP. Además de la dirección de red, servicios disponibles y formatos diferentes de los mismos y números de puerto, números de protocolo y/o identificadores que han de ser usados para solicitar diferentes servicios y diferentes formatos de un servicio están almacenados en conexión con el agente de directorio. El servidor particular puede actualizar esta información para el agente de directorio sobre una base regular. Además, la red comprende agentes de usuario y/o procedimientos de programa para crear agentes de usuario UA para terminales inalámbricos IT. Como los terminales IT se mueven en áreas diferentes, no es necesario crear agentes de usuario permanentes para cada terminal en un área definida sino que los terminales se registran en un agente de usuario cada vez que entra en una cierta área definida por el agente de directorio DA. Cuando el dispositivo de usuario ha sido registrado en el agente de usuario UA, el usuario del terminal puede emitir solicitudes de servicio al agente de directorio DA a través del agente de usuario UA.
Cuando el usuario del terminal ha de configurar una conexión a un cierto servicio, el terminal entrega una solicitud de servicio a su agente de usuario UA en la red. El usuario del terminal no necesita tener ninguna información detallada sobre el servicio particular, tal como la de en qué dirección de red está disponible el servicio o los parámetros de telecomunicación usados. En la solicitud de servicio emitida, el usuario del terminal puede especificar diferentes atributos del servicio deseado, tales como el tipo de servicio, protocolos de red y formatos de servicio soportados por el terminal, y cierta información relacionada con la aplicación y/o características del terminal que afecta a la selección del formato de servicio. Si el terminal es uno móvil, la solicitud de servicio puede también especificar preferiblemente la posición aproximada del terminal sobre la base de la posición de su punto nodal a través del cual el terminal ha sido conectado a la red con cables. El agente de usuario UA presenta preferiblemente la solicitud de servicio especificada por el usuario del terminal al agente de directorio DA, que busca a través de los servicios registrados en el agente de directorio DA por agentes de servicio SA para la descripción de servicio de especificada por la solicitud de servicio particular. Si un servicio de acuerdo con la solicitud de servicio está disponible, el agente de directorio DA devuelve la información del servicio sobre el servicio o servicios particulares al agente de usuario UA. De acuerdo con una realización del invento, esta también comprende números de puerto y/o números de protocolo a través de los cuales están disponibles ciertos formatos de servicio. El agente de usuario UA entrega además la información al terminal TE, que es capaz de configurar una conexión a la red que proporciona el servicio y el servicio deseado por medio de los parámetros de telecomunicación recibidos. Si el terminal usa en el paquete IP que transmite un cierto número de protocolo o número de puerto así obtenido, correspondiente al formato de servicio deseado, el paquete es automáticamente suministrado a una aplicación que proporciona el servicio en la forma deseada y que soporta las características del terminal. Si el terminal solamente transmite un número de protocolo conocido normal y un identificador de acuerdo con el invento, el paquete también terminará en una aplicación correcta en el servidor.
La información de identificador del invento puede también ser usada para encaminar un paquete IP en la red. Dependiendo de la información del identificador, un paquete IP que tiene la misma dirección puede ser encaminado de diferentes modos en una realización del invento; dos o más servidores (posiblemente virtuales) pueden ser accedidos en la propia red de área local de los proveedores de servicios usando la misma dirección de IP. La fig. 3 muestra un ejemplo en el que dos servidores S3 y S3’ que proporcionan el mismo servicio, solamente adecuado para terminales ligeramente diferentes, están conectados a una LAN del proveedor de servicios. A los servidores S3 y S3’, bases de datos DB1 y DB2 están también conectadas, que comprenden archivos en formato ligeramente diferentes. Como el servicio debería parecer uniforme a los clientes, los servidores tienen la misma dirección de IP, al menos fuera de la LAN. Sobre la base de la dirección de IP, el paquete IP llega a un encaminador R1, que dirige el paquete a un servidor correcto S3 o S3’ por medio de la información de identificador ID en el paquete.
Por ejemplo, si el paquete IP comprende el ID1 o no comprende ningún identificador, el paquete IP es encaminado al servidor S3. Si el paquete comprende el identificador ID2, el paquete es encaminado al servidor S3’. Este encaminamiento puede estar basado por ejemplo en la conversión de dirección de IP sobre la base del identificador ID. La
5 información del identificador ID puede ser utilizada en encaminamiento también en cualquier lugar sobre Internet. El encaminamiento a un servidor correcto dentro de la red es determinado de acuerdo con la información de identificador del invento.
Las figuras y la descripción relacionada están solamente destinadas a ilustrar el invento. La puesta en práctica del invento puede variar dentro del marco de las 10 reivindicaciones adjuntas.

Claims (21)

  1. REIVINDICACIONES
    1.-Un método para poner en práctica un servicio de un servidor (S1-3) a dispositivos de cliente (TE) que tienen diferentes características, comprendiendo el método las operaciones de: un dispositivo cliente (TE) que transmite un paquete de protocolo de Internet (IP) que comprende un encabezamiento IP, un encabezamiento de capa de protocolo de transporte y datos de capa de aplicación, encaminar el paquete IP hacia el servidor (S1-3) de acuerdo con una dirección de destino de dicho encabezamiento IP, transferir, en el servidor, el encabezamiento de capa de transporte y los datos de capa de aplicación desde la capa IP al protocolo de capa de transporte de acuerdo con un identificador de protocolo de dicho encabezamiento IP, transferir, en el servidor, los datos de capa de aplicación desde la capa de protocolo del transporte a la capa de aplicación de acuerdo con un número de puerto contenido en dicho encabezamiento de capa de protocolo de transporte, caracterizado porque el dispositivo de cliente (TE) incluye, en el paquete IP que transmite, informaciones sobre una interfaz de programación por debajo de una aplicación utilizada para presentar el servicio en el dispositivo de cliente que solicita el servicio, dicha información es usada en el servidor (S1-3) para seleccionar y/o configurar un archivo solicitado por el dispositivo de cliente o una aplicación que interactúa con el dispositivo de cliente de tal modo que el servicio sea proporcionado en la forma requerida por las características del dispositivo de cliente (TE) particular que ha solicitado el servicio.
  2. 2.-Un método según la reivindicación 1, caracterizado porque el servidor (S1-3) comprende una pluralidad de unidades de capa de protocolo de transporte que tienen el mismo protocolo, estando conectada cada unidad a la capa de aplicación a través de una interfaz de aplicación diferente cuando cada interfaz de aplicación soporta el servicio solicitado en una forma diferente, los datos de capa de aplicación son transferidos en el servidor desde la capa de IP a una de dichas unidades de protocolo de capa de transporte de acuerdo con dicho identificador de protocolo del encabezamiento IP y de dichas informaciones.
  3. 3.-Un método según la reivindicación 1, caracterizado porque el servidor (S1-3) comprende una pluralidad de puertos en la capa de protocolo de transporte, estando cada puerto conectado a la capa de aplicación a través de una interfaz de aplicación diferente cuando cada interfaz de aplicación soporta el servicio solicitado en una forma diferente, los datos de capa de aplicación son transferidos al servidor desde la capa de protocolo de transporte a la capa de aplicación a través del número de puerto contenido en dicho encabezamiento de protocolo de capa de transporte y un puerto seleccionado de acuerdo con dicha información.
  4. 4.-Un método según la reivindicación 1, 2 o 3, caracterizado porque dicha información está situada en el encabezamiento IP del paquete IP, el encabezamiento de capa de transporte o los datos de aplicación.
  5. 5.-Un método según la reivindicación 1, 2, 3 ó 4, caracterizado porque el dispositivo de cliente incluye dicha información en los datos de capa de aplicación del paquete IP, la capa de aplicaciones está configurada de acuerdo con dicha información.
  6. 6.-Un método según la reivindicación 5, caracterizado porque la capa de aplicación selecciona el tipo de archivo que se ha de transmitir al dispositivo de cliente (TE) sobre la base de dicha información.
  7. 7.-Un método según una cualquiera de las reivindicaciones 1 a 6, caracterizado porque el dispositivo de cliente (TE) recupera la información acerca de los servidores (S13) que proporcionan el servicio en una forma deseada desde un agente de repertorio (DA).
  8. 8.-Un terminal capaz de solicitar y de recibir servicios desde un servidor (S1-3) en una red TCP/IP, caracterizado porque el terminal (TE) incluye, en un paquete IP que transmite, datos de la capa de aplicación e información sobre una interfaz de software por debajo de una aplicación utilizada para presentar el servicio en el dispositivo de cliente que solicita el servicio de manera que permita, en el servidor (S1-3) que un archivo o una aplicación sea seleccionado o configurado por medio de dicha información de tal modo que el servicio sea proporcionado en la forma requerida por las características y/o aplicación del terminal (TE).
  9. 9.-Un servidor en una red TCP/IP, que proporciona servicios a dispositivos de cliente (TE) que tienen diferentes características, comprendiendo el servidor (S1-3) medios de Protocolo de Internet (IP) para recibir un paquete IP transmitido por un dispositivo de cliente (TE) y provisto de un encabezamiento IP, de un encabezamiento de capa de protocolo de transporte y de datos de capa de aplicación, al menos una unidad de protocolo de capa de transporte a la que el encabezamiento de capa de transporte y los datos de capa de aplicación son transferidos desde los medios IP de acuerdo con un identificador de protocolo de dicho encabezamiento IP, al menos una aplicación a la que los datos de capa de aplicación son transferidos desde la unidad de protocolo de capa de transporte de acuerdo con un número de puerto contenido en dicho encabezamiento de capa de protocolo de transporte, caracterizado porque el servidor (S1-3) está dispuesto para examinar si el dispositivo de cliente (TE) ha incluido, en el paquete IP que transmite, información acerca de una interfaz de software por debajo de una aplicación utilizada para presentar el servicio en el dispositivo de cliente que solicita el servicio, el servidor (S1-3) está dispuesto para usar dicha información para seleccionar o configurar el archivo o la aplicación de tal modo que el servicio sea proporcionado en la forma requerida por las características y/o la aplicación del dispositivo de cliente (TE) particular que ha solicitado el servicio.
  10. 10.-Un servidor según la reivindicación 9, caracterizado porque el servidor (S1-3) comprende una pluralidad de unidades de capa de protocolo de transporte que tienen el mismo protocolo, estando conectada cada unidad a la capa de aplicación a través de una interfaz de aplicación diferente cuando cada interfaz de aplicación soporta el servicio solicitado en una forma diferente, encaminando dichos medios de protocolo de IP los datos de capa de aplicación y el encabezamiento de capa de transporte a una de dichas unidades de protocolo de capa de transporte en función de un identificador de protocolo de dicho encabezamiento IP y de dichas informaciones.
  11. 11.-Un servidor según la reivindicación 9, caracterizado porque el servidor (S1-3) comprende una pluralidad de puertos en la capa de protocolo de transporte, estando conectado cada puerto a la capa de aplicación a través de una interfaz de aplicación diferente cuando cada interfaz de aplicación soporta el servicio solicitado en una forma diferente, una unidad de protocolo de la capa de protocolo de transporte está dispuesta para entregar los datos de capa de aplicación a la capa de aplicación a través del número de puerto contenido en dicho encabezamiento de capa de protocolo de transporte y un puerto seleccionado de acuerdo con dicha información.
  12. 12.-Un servidor según la reivindicación 9, 10 u 11, caracterizado porque dicha información se encuentra en el encabezamiento IP del paquete IP, el encabezamiento de capa de transporte o los datos de aplicación.
  13. 13.-Un servidor según la reivindicación 9, 10, 11 o 12, caracterizado porque dicha información se encuentra en los datos de capa de aplicación del paquete IP, y porque la capa de aplicación está configurada o selecciona el formato de los datos que han de ser transmitidos de acuerdo a dicha información.
  14. 14.-Un servidor según la reivindicación 12, caracterizado porque la capa de aplicación selecciona el tipo de archivo a transmitir al dispositivo cliente (TE) sobre la base de dicha información.
  15. 15.-Un método para proporcionar un servicio desde un servidor (S1-3) a dispositivos de cliente, comprendiendo el método las operaciones del servidor (S1-3) que emite o transfiere de un emisor a varios receptores un paquete de protocolo Internet (IP) que comprende un encabezamiento IP, un encabezamiento de capa de protocolo de transporte y datos de capa de aplicación, encaminar el paquete IP a los dispositivos de cliente, transferir, en el dispositivo de cliente, el encabezamiento de capa de transporte y los datos de capa de aplicación desde una capa IP a una capa de protocolo de transporte de acuerdo con un identificador de protocolo de dicho encabezamiento IP, transferir, en el dispositivo de cliente, los datos de capa de aplicación de la capa de protocolo de transporte a la capa de aplicación de acuerdo con un número de puerto contenido en dicho encabezamiento de capa de protocolo de transporte, caracterizado porque el servidor (S13) incluye, en el paquete IP que transmite, información sobre una interfaz de software por debajo de una aplicación usada para presentar el servicio, y porque, dicha información es usada en el dispositivo de cliente para configurar y/o descargar la aplicación y la interfaz de programación de aplicación.
  16. 16.-Un procedimiento según la reivindicación 15, caracterizado porque el dispositivo de cliente descarga, sobre la base de dicha información, módulos de programa necesarios apropiados para la interfaz de software del dispositivo de cliente desde servidores sobre Internet para presentar el contenido del servicio propiamente dicho.
  17. 17.-Un servidor (S1-3) en una red TCP/IP o una red de emisión, que proporciona servicios a dispositivos de cliente que tienen diferentes características, comprendiendo el servidor medios para transmitir paquetes de IP en forma de emisión o transferencia múltiple, o en marcos de emisión a los dispositivos de cliente, caracterizado porque el servidor (S1-3) está dispuesto para incluir, en un paquete IP que transmite, o en información de identificador un paquete IP de marco de emisión, datos de capa de aplicación e información sobre una interfaz de software por debajo de una aplicación utilizada para presentar un servicio de tal modo que permita que un dispositivo de cliente use dicha información para configurar y/o descargar la aplicación y la interfaz de software de aplicación o un programa de protocolo.
  18. 18.-Un terminal capaz de solicitar y de recibir servicios de una red de emisión o de un servidor (S1-3) en una red TCP/IP, caracterizado porque el terminal configura y/o descarga una aplicación y una interfaz de software de aplicación sobre la base de la información situada en un paquete de protocolo de Internet (IP) recibido del servidor (S1-3),
    o en información de identificador sobre un marco de emisión recibido desde la red de emisión, dicha información relativa a una interfaz de software por debajo de la aplicación usada para presentar un servicio, conteniendo el paquete IP además datos de capa de aplicación.
  19. 19.-Un método para encaminar una solicitud de servicio a un servidor (S1-3) de dispositivos de cliente que tienen diferentes características, comprendiendo el método las operaciones de recibir de un dispositivo de cliente (TE) que transmite un paquete de Protocolo de Internet (IP) que comprende un encabezamiento IP, un encabezamiento de capa de protocolo de transporte y datos de capa de aplicación, encaminar el paquete IP al servidor (S1-3) de acuerdo con una dirección de destino de dicho encabezamiento IP, caracterizado porque el paquete IP incluye información sobre una interfaz de software por debajo de la aplicación usada para presentar el servicio en el dispositivo de cliente que
    5 solicita el servicio, usar dicha información, con la dirección de IP para encaminar el paquete IP hacia un servidor (S1-3) que proporciona un servicio en la forma requerida por las características y/o la aplicación del dispositivo de cliente (TE) particular que ha solicitado el servicio.
  20. 20.-Un método según la reivindicación 19, caracterizado porque dos o más 10 servidores que proporcionan diferentes formas de un servicio único tienen la misma dirección de IP.
  21. 21.-Un encaminador que encamina paquetes de Protocolo de Internet (IP) que contienen datos de capa de aplicación, caracterizado porque, en el encaminamiento, el encaminador utiliza no solamente una dirección de destino de IP sino también una
    15 información de identificador, que ha sido incluida en un paquete IP por un dispositivo de cliente que ha transmitido el paquete IP, refiriéndose dicha información a una interfaz de software por debajo de una aplicación usada para presentar el servicio en el dispositivo de cliente que solicita el servicio.
ES01925614T 2000-04-07 2001-04-06 Provisión de servicios con un servidor en una red tcp/ip. Expired - Lifetime ES2353489T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI20000837A FI109854B (fi) 2000-04-07 2000-04-07 Palvelun tuottaminen TCP/IP-verkon palvelimelta
FI20000837 2000-04-07

Publications (1)

Publication Number Publication Date
ES2353489T3 true ES2353489T3 (es) 2011-03-02

Family

ID=8558155

Family Applications (1)

Application Number Title Priority Date Filing Date
ES01925614T Expired - Lifetime ES2353489T3 (es) 2000-04-07 2001-04-06 Provisión de servicios con un servidor en una red tcp/ip.

Country Status (8)

Country Link
EP (1) EP1410595B1 (es)
AT (1) ATE483309T1 (es)
AU (1) AU2001252314A1 (es)
DE (1) DE60143170D1 (es)
DK (1) DK1410595T3 (es)
ES (1) ES2353489T3 (es)
FI (1) FI109854B (es)
WO (1) WO2001078350A1 (es)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE526634C2 (sv) * 2003-03-25 2005-10-18 Airnet Holding Ab Förfarande för överförande av stora informationsmängder via digitalt radionät
GB0328249D0 (en) * 2003-12-05 2004-01-07 Nokia Corp Data reception in a multi-function receiving device
CA2577087A1 (en) * 2004-08-13 2006-02-23 Cmware, Inc. Systems and methods for remotely controlling computer applications
DE102007007158A1 (de) 2007-02-09 2008-08-14 Deutsche Telekom Ag Verfahren und Vorrichtung für mobile kontextbezogene Telekommunikationsdienste auf verschiedenen Endgeräten
WO2010093831A1 (en) * 2009-02-11 2010-08-19 Social Gaming Network Apparatuses, methods and systems for an interactive proximity display tether with remote co-play
GB2520976A (en) 2013-12-05 2015-06-10 Ibm Correct port identification in a network host connection
KR102318279B1 (ko) * 2014-02-18 2021-10-28 삼성전자주식회사 무선 통신 시스템에서 인증 정보 송수신 방법 및 장치
CN110769005B (zh) * 2019-11-11 2022-03-08 交控科技股份有限公司 一种轨道交通多专业多系统多协议数据采集方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5832219A (en) * 1994-02-08 1998-11-03 Object Technology Licensing Corp. Distributed object networking service
WO1997003404A1 (fr) * 1995-07-11 1997-01-30 Hitachi, Ltd. Systeme serveurs
US5956509A (en) * 1995-08-18 1999-09-21 Microsoft Corporation System and method for performing remote requests with an on-line service network
US5987480A (en) * 1996-07-25 1999-11-16 Donohue; Michael Method and system for delivering documents customized for a particular user over the internet using imbedded dynamic content
FI104770B (fi) * 1997-07-17 2000-03-31 Domiras Oy Menetelmä ja päätelaite palvelujen tarjoamiseksi tietoliikenneverkossa
FI111317B (fi) * 1999-06-28 2003-06-30 Domiras Oy Tietoliikenneparametrien keskitetty hallinta

Also Published As

Publication number Publication date
FI20000837A (fi) 2001-10-08
DK1410595T3 (da) 2011-01-24
DE60143170D1 (de) 2010-11-11
WO2001078350A1 (en) 2001-10-18
ATE483309T1 (de) 2010-10-15
EP1410595A1 (en) 2004-04-21
EP1410595B1 (en) 2010-09-29
FI20000837A0 (fi) 2000-04-07
FI109854B (fi) 2002-10-15
AU2001252314A1 (en) 2001-10-23

Similar Documents

Publication Publication Date Title
EP1397900B1 (en) Packet-oriented data communications between mobile and fixed data networks
US6049826A (en) Method and system for cable modem initialization using dynamic servers
US8605738B2 (en) Method and system for redirecting networked traffic
US6170061B1 (en) Method and system for secure cable modem registration
US6058421A (en) Method and system for addressing network host interfaces from a cable modem using DHCP
US6657991B1 (en) Method and system for provisioning network addresses in a data-over-cable system
US7965722B2 (en) Communication of active data flows between a transport modem termination system and cable transport modems
US6351773B1 (en) Methods for restricting access of network devices to subscription services in a data-over-cable system
US6070246A (en) Method and system for secure cable modem initialization
US6065049A (en) Method and system for resolving addresses for network host interfaces from a cable modem
US6018767A (en) Method and system for managing subscription services with a cable modem
US7519081B2 (en) Multi-carrier frequency-division multiplexing (FDM) architecture for high speed digital service in local networks
US6370147B1 (en) Method for addressing of passive network hosts in a data-over-cable system
US8213387B2 (en) Method, system and device for transmitting a media independent handover message
US6185624B1 (en) Method and system for cable modem management of a data-over-cable system
FI106763B (fi) Menetelmä käytössä olevan protokollan tiedottamiseksi protokollapinon muille kerroksille
US8180911B2 (en) Method of distributing real time data streams across a multimedia network as well as a mediation device and a multimedia network therefore
JPH11289352A (ja) 一方向式ケーブル／無線／衛星モデムでのリンク層転送のためのパケット処理リレーエージェント
CN101822022A (zh) 用户设备中对三重播放服务的支持
ES2353489T3 (es) Provisión de servicios con un servidor en una red tcp/ip.
EP1388993B1 (en) IP-based communication system using uni- and bi-directional networks
JP3584694B2 (ja) Ｉｐアドレス値とｐｉｄ値との変換方式、変換装置及びビデオ配信システム
WO2002035348A1 (en) Method and apparatus for sending information in a communication system
JP2004511136A (ja) 通信ネットワークのためのインターネット・プロトコル・ヘッダ
KR20000047263A (ko) 멀티미디어 위성통신시스템에서 서비스 가입자에대한 멀티캐스트 서비스 정보 제공시스템