ES2260942T3 - Procedimiento para programacion de acciones de recursos en una red de comunicacion domestica. - Google Patents
Procedimiento para programacion de acciones de recursos en una red de comunicacion domestica.Info
- Publication number
- ES2260942T3 ES2260942T3 ES99955574T ES99955574T ES2260942T3 ES 2260942 T3 ES2260942 T3 ES 2260942T3 ES 99955574 T ES99955574 T ES 99955574T ES 99955574 T ES99955574 T ES 99955574T ES 2260942 T3 ES2260942 T3 ES 2260942T3
- Authority
- ES
- Spain
- Prior art keywords
- action
- manager
- resources
- preprogrammed
- resource
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40117—Interconnection of audio or video/imaging devices
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B1/00—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
- H04B1/06—Receivers
- H04B1/16—Circuits
- H04B1/20—Circuits for coupling gramophone pick-up, recorder output, or microphone to receiver
- H04B1/205—Circuits for coupling gramophone pick-up, recorder output, or microphone to receiver with control bus for exchanging commands between units
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/2805—Home Audio Video Interoperability [HAVI] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/2807—Exchanging configuration information on appliance services in a home automation network
- H04L12/2814—Exchanging control software or macros for controlling appliance services in a home automation network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/2807—Exchanging configuration information on appliance services in a home automation network
- H04L12/2809—Exchanging configuration information on appliance services in a home automation network indicating that an appliance service is present in a home automation network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L2012/2847—Home automation networks characterised by the type of home appliance used
- H04L2012/2849—Audio/video appliances
Abstract
Procedimiento para programación de acciones de recursos en una red de aparatos domésticos, caracterizado porque incluye las etapas de: - transmisión de una petición de programación de una acción por una aplicación cliente (15) a un gestor de acciones preprogramadas (21) de un aparato de la red (17), incluyendo dicha petición de programación un conjunto de parámetros que definen la acción y una lista de recursos implicados en la ejecución de la acción, - verificación por parte de dicho gestor de acciones (21) de la disponibilidad de recursos implicados en la ejecución de la acción, - transmisión a la aplicación cliente (15) de un mensaje de aceptación o de rechazo de la acción por parte del gestor de acciones preprogramadas en función del resultado de dicha verificación.
Description
Procedimiento para programación de acciones de
recursos en una red de comunicación doméstica.
La invención se refiere a un procedimiento para
programación de acciones de recursos, es decir de funciones de
dispositivos, en una red doméstica de comunicación, en especial una
red que incluya un bus serie IEEE 1394-1995.
En una red doméstica de comunicación a la cual
están conectados aparatos de audio/vídeo o nodos, un usuario debería
tener la posibilidad de programar una acción a llevar a cabo por uno
de los aparatos a partir de cualquier aparato que posea un
dispositivo de presentación. A modo de ejemplo, debería ser posible
programar la grabación de una emisión mediante cualquier dispositivo
de grabación, por ejemplo un magnetoscopio, en cualquier televisor
u otro medio de etapa conectado a la red.
El documento
EP-A-0535749 describe una red de
dispositivos tipo DLB.
La invención se refiere a un procedimiento para
programación de acciones de recursos en una red de dispositivos
domésticos, caracterizado porque incluye las siguientes etapas:
- la transmisión de una petición de programación
de una acción por una aplicación cliente a un gestor de acciones
preprogamadas de un dispositivo de la red, incluyendo dicha petición
de programación un conjunto de parámetros de definición de la
acción y una relación de recursos implicados en la ejecución de la
acción,
- verificación por parte de dicho gestor de
acciones de la disponibilidad de los recursos implicados en la
ejecución de la acción,
- transmisión a la aplicación cliente de un
mensaje de aceptación o de denegación de la acción por parte del
gestor de acciones preprogramadas en función del resultado de dicha
verificación.
De acuerdo con un modo de realización
específico, la aplicación cliente selecciona un gestor de acciones
preprogramadas situado en un aparato distinto del de la propia
aplicación cliente.
De acuerdo con un modo de realización
específico, el procedimiento incluye la etapa de almacenamiento en
memoria por parte de cada recurso en cuestión de su agenda en
relación con la acción.
De acuerdo con un modo de realización
específico, la etapa de verificación incluye una petición del
gestor de acciones preprogramadas a cada recurso implicado a fin de
conocer la disponibilidad de los recursos implicados a través de
sus respectivas agendas.
De acuerdo con un modo de realización
específico, a la hora de iniciar la acción, el gestor de acciones
preprogramadas lleva a cabo las siguientes tareas:
- reserva de los recursos implicados,
- establecimiento de las conexiones requeridas
entre los recursos implicados,
- lanzamiento de comandos para los recursos
implicados.
Otras características y ventajas de la invención
se observarán a través de la descripción de dos ejemplos de
realización no limitativos, ilustrados en las figuras adjuntas, en
las cuales:
- la figura 1 es un esquema de una parte de una
red doméstica que representa el funcionamiento de acuerdo con el
primer ejemplo de realización,
- la figura 2 es un esquema de una parte de una
red doméstica que representa el funcionamiento de acuerdo con el
segundo ejemplo de realización,
- la figura 3 es un diagrama que representa los
intercambios de datos de acuerdo con el primer ejemplo de
realización,
- la figura 4 es un diagrama que representa los
intercambios de datos de acuerdo con el segundo ejemplo de
realización.
La presente descripción se refiere a una red
doméstica basada en un bus serie de acuerdo con IEEE
1394-1995, así como en la arquitectura denominada
"HAVi", definida en el documento "The HAVi Architecture -
Specification of the Home Audio/Video interoperability
Architecture" de fecha 11 de mayo de 1998, versión 0.8, publicada
el 15 de mayo de 1998 en la página web de las empresas Sony,
Hitachi, Toshiba, Philips y Sharp. Entre la fecha de prioridad y la
fecha de depósito de la presente petición, se ha publicado una nueva
versión del documento HAVi (versión 1.0 beta+).
Dos solicitudes de patente presentadas a nombre
de la misma persona que la presente solicitud, abordan en mayor
detalle ciertos aspectos de la arquitectura de la red. Se trata de
la solicitud de patente francesa nº 9805110 del 23 de abril de 1998
que tiene por título "Procedimiento para gestión de objetos en una
red de comunicación y dispositivo para llevarlo a cabo] ", así
como una solicitud de patente francesa presentada en la misma fecha
que la solicitud de prioridad de la presente solicitud y titulada
"Procedimiento para gestión de prioridades de acceso a recursos en
una red doméstica y aparato para llevarlo a cabo". Esta última
solicitud tiene el número FR 9807186. La primera solicitud de
patente se refiere a la realización de un registro de objetos o de
recursos en los aparatos conectados a la red, manteniendo
actualizada dicho registro, la lista de recursos o módulos de
software disponibles a nivel local en un aparato, mientras que la
segunda solicitud se refiere a un gestor de recursos que administra
la reserva de los recursos disponibles a nivel local y participa en
la resolución de conflictos de acceso a
- o de reserva de - dichos recursos.
- o de reserva de - dichos recursos.
Para ejecutar una acción, como la grabación de
una emisión, una aplicación puede necesitar acceder a recursos
públicos. Por recursos públicos se entiende en el presente contexto
las funciones de los aparatos distintos del aparato en el cual se
ejecuta la aplicación, pero que son potencialmente accesibles por
parte de dicha aplicación. También forman parte de los recursos
públicos los recursos a los que puede acceder localmente la
aplicación, así como el ancho de banda. Una aplicación, en sí misma,
puede constituir un recurso. Los registros mencionados anteriormente
mantienen actualizada una lista de los recursos públicos
disponibles y una aplicación puede determinar cuáles son dichos
recursos, lanzando una petición a nivel de su registro local, que
puede transmitir dicha petición al resto de los registros.
La denominación "módulo de software" (de
acuerdo con la terminología del documento HAVi) designa igualmente
las aplicaciones, los recursos y los servicios de un aparato.
Se facilitarán dos ejemplos de realización. De
acuerdo con el primer ejemplo de realización, se efectúan ciertas
funciones relativas a la implementación de acciones preprogramadas
por lo que se denominará un "recurso principal" en los
siguientes párrafos, mientras que, de acuerdo con el segundo ejemplo
de realización, dichas funciones están garantizadas por un objeto
independiente de los recursos implicados en una acción
preprogramada, es decir el gestor de acciones preprogramadas
("GAP").
La realización de una acción preprogramada de
acuerdo con el primer ejemplo de realización implica:
- una aplicación cliente,
- un recurso principal denominado "recurso
objetivo" o simplemente "objetivo",
- en su caso, uno o varios recursos públicos
diferentes, denominados "recursos implicados", igualmente
necesarios para llevar a cabo la acción preprogramada.
En el marco de una petición de grabación, el
objetivo es, por ejemplo, la función de grabación de un aparato
grabador digital (magnetoscopio digital, DVD...), mientras que un
recurso implicado es un sintonizador. Pueden ser necesarios otros
recursos: por ejemplo un trans-codificador,
necesario para traducir el formato de los datos al del aparato de
grabación, un servicio de control de acceso para autorizar el acceso
a los programas protegidos,...
Se tendrá en cuenta la necesidad de que el
procedimiento de realización de la acción preprogramada funcione
normalmente aun cuando el dispositivo de presentación a través del
cual se ha programado la acción está inactivo (por ejemplo, el
usuario ha apagado el televisor que le ha servido para la
programación de un magnetoscopio). Nos situamos en la hipótesis de
que dicho dispositivo no incluye recursos implicados (al formar
parte el recurso principal de los recursos implicados).
El objetivo acepta o no la acción solicitada por
la aplicación. En el momento de programar dicha acción, el objetivo
debe identificar los recursos necesarios para el cumplimiento de la
acción y reservarlos durante el período de tiempo deseado. En el
mismo momento de ejecutar la acción, deben sincronizarse el objetivo
y los recursos implicados. Esto tiene como consecuencia que en la
red, deben almacenarse las informaciones relativas a la acción
preprogramada. De acuerdo con el primer ejemplo de realización, el
objetivo es el que almacena estas informaciones y ejecuta la acción,
mientras que de acuerdo con un segundo modo de realización, será
otro módulo el encargado de dichas funciones. Una acción
preprogramada puede ser definida por diversas informaciones
recopiladas de una estructura de datos particular implementada por
la aplicación que programa la acción y almacenada por el recurso
objetivo:
- el tipo de acción
- parámetros relativos a la acción (comandos a
ejecutar para cada recurso implicado, lista de conexiones a
establecer antes de iniciar la acción)
- una fecha
- una hora de inicio
- una hora de finalización
- la periodicidad de la acción
- un identificador del recurso objetivo
- los identificadores de los recursos
implicados
- los datos de usuario.
El tipo de acción depende de la naturaleza del
objetivo. A modo de ejemplo, la acción puede ser "GRABAR" o
"LECTURA" para un recurso que tenga una función de memoria de
masa, o "SELECCIONAR_SERVICIO" para un desmultiplexor
de
televisión digital.
televisión digital.
Los parámetros que dependen de la acción a
efectuar, sirven para definir la acción de forma más específica a
nivel de cada recurso. Un parámetro puede ser un evento o un
servicio en el sentido de las normas de difusión de vídeo digital
DVB ("Digital Video Broadcast"). En este caso, los parámetros
incluirán un identificador del tipo de parámetro, seguido por el
valor del parámetro.
Algunos aparatos de la red pueden no incluir
medios de procesamiento para suministrar un servicio de este nivel.
Por ejemplo, un aparato de grabación puede no aceptar parámetros
tras un comando "GRABAR", por lo que no puede controlar un
sintonizador, mientras que un aparato más complejo que disponga de
dicha posibilidad podrá aceptar un comando del tipo "GRABAR
servicio X".
La fecha, las horas de inicio y finalización y
la periodicidad de la acción son informaciones clásicas.
El identificador del recurso objetivo es
necesario para que una aplicación pueda modificar una acción ya
programada. Este campo no es necesario si el objetivo almacena en
memoria directamente la acción preprogramada (es decir, si dicho
recurso constituye el recurso principal de una acción
programada).
Si por ejemplo una aplicación desea conocer qué
acción programada está asociada a un recurso dado, ésta solicitará a
dicho recurso los identificadores de cada una de las acciones
programadas en las cuales está implicado este recurso. La
aplicación podrá entonces consultar la estructura de datos de la
acción programada seleccionada por ella y, después, podrá
modificarla (esta aplicación puede ser, por ejemplo, la de un
interfaz de usuario, eventualmente controlado por un usuario
diferente de aquel que ha programado la acción a modificar).
Los identificadores de los recursos implicados
son utilizados, de acuerdo con el primer ejemplo de realización, por
el objetivo. La lista permite al objetivo solicitar informaciones
relativas a los recursos implicados, por ejemplo mediante registros
o transmitiéndoles directamente mensajes.
Los datos de usuario incluyen, por ejemplo, en
modo de texto simple, la razón de ser de la acción, lo que puede
resultar importante en caso de conflicto con una acción programada
anteriormente. En este caso, cuando el conflicto debe ser resuelto
por un usuario, normalmente el que programa la acción más reciente,
estos datos pueden ofrecerle indicaciones sobre la importancia de
la acción.
Los recursos implicados contactados por el
recurso objetivo deberán también almacenar en memoria una parte del
contenido de la estructura de datos anterior: las informaciones
relativas a la hora y, eventualmente, al tipo de acción, los
parámetros y los datos de usuario.
El primer ejemplo de realización se muestra en
la figura 1. La parte de la red representada por esta figura incluye
cinco aparatos. El aparto 1 es un televisor situado en una cocina y
que incluye una aplicación 2 (por ejemplo, un interfaz de usuario
que permite la programación del conjunto de los aparatos de la red).
El aparato 3 es igualmente un televisor situado esta vez en el
dormitorio y equipado con una aplicación 4 similar a la aplicación
2. El aparato 5 es un decodificador de televisión digital vía
satélite que incluye un recurso de sintonizador 6 y un gestor de
recursos 7, mientras que el aparato 8 es un dispositivo de grabación
digital de tipo DVD, que incluye a este fin el recurso de grabación
9 y un gestor de recursos 10. Por último, el aparato 11 es por
ejemplo otro decodificador que posee una función de
trans-codificación de los datos de audio/vídeo
codificados según un primer formato (el del decodificador 5) en un
segundo formato (el del dispositivo de grabación 8). El aparato 11
posee, por consiguiente, un recurso de
trans-codificación 12 y un gestor de recursos 13.
Los diversos aparatos, que pueden incluir otros módulos de software
distintos de los aquí mostrados, están conectados a través de un
bus en serie, por ejemplo un bus IEEE 1394-1995.
De acuerdo con el primer ejemplo de realización,
el recurso objetivo, que en el caso que nos ocupa es la función de
grabación del dispositivo 8, integra una aplicación capaz de
gestionar la acción de grabación.
Supongamos que un usuario desea grabar una
emisión a través de un servicio X, a las 20 h 30 del 12 de diciembre
de 1999, durante un período de dos horas. Aunque en el ejemplo de
la figura 1 sólo existen en la red un solo recurso de tipo
sintonizador y un solo recurso de tipo transcodificación, el usuario
podría, en una red en la que coexistiesen diversos recursos del
mismo tipo, seleccionar entre varios recursos del mismo tipo
pertenecientes a la red aquel que prefiere que participe en la
ejecución de la acción.
Cuando el recurso objetivo 9 recibe la acción
programada por parte de la aplicación 2, efectúa una reserva
automática con el gestor de recursos local 10, procediendo de la
forma descrita en la segunda solicitud de patente mencionada al
comienzo de esta descripción. Por otra parte, efectúa la reserva de
los recursos implicados (sintonizador 6, transcodificador 12) con
los gestores de recursos remotos (respectivamente gestores 7 y 13).
Cada gestor de recursos almacena en memoria los datos relativos a la
reserva de los recursos asociados a él (es decir recursos con la
misma plataforma de ejecución que dicho gestor de recursos).
Una vez efectuadas las reservas, el objetivo
transmite un mensaje de confirmación a la aplicación 2 cuando se
origina la acción.
En caso de conflicto de reserva, por ejemplo en
caso de preferencia o negociación de un recurso ya reservado para
una acción dada por una aplicación que ha programado otra acción, el
gestor de recursos advierte al objetivo que ha programado la
primera acción mediante un mensaje apropiado. Efectivamente, cada
gestor de recursos almacena en memoria con esta finalizada el
identificador o la dirección del módulo de software que ha efectuado
una reserva.
En esta etapa, en caso de desconexión del
aparato 1, la acción preprogramada se seguirá ejecutando, pues todas
las informaciones relativas a la acción se encuentran almacenadas en
el objetivo.
Un usuario puede modificar o suprimir la acción
preprogramada a partir de otra aplicación, como la aplicación 4. Si
la aplicación 4 desea acceder a todas las acciones programadas
relativas a un recurso dado (hallado a través del registro local de
la aplicación), el recurso contactado por la aplicación puede
facilitar los identificadores de los recursos principales de cada
una de las acciones programadas en las cuales está implicada. La
totalidad de la estructura de datos que describe la acción
programada puede recuperarse a continuación contactando directamente
con cada recurso principal.
En el momento de iniciarse la acción, el
objetivo enlaza los diferentes recursos gracias al módulo de
software local denominado gestor de conexiones ("SM" o
"Stream Manager [administrador de flujo]" de acuerdo con la
terminología del documento HAVi).
Un recurso puede designarse mediante los
términos administrador de componente funcional ("FCM" o
"Function Component Manager" según la terminología HAVi). La
arquitectura puede entonces estar representada por el esquema de la
figura 3 en el que una aplicación transmite una programación de
acción al interfaz de programación de aplicación que forma parte del
objetivo.
Más generalmente, en el ámbito del HAVi existen
otros recursos aparte de los FCM. Por ejemplo existe otro tipo de
recurso denominado "DCM" o "Device Control Manager" o
gestor de control de aparato. Mientras que un FCM es la
representación lógica de una función de un aparato, un DCM es la
representación lógica de un aparato, pudiendo integrar varios FCM.
Un DCM será entonces un intermediario entre una aplicación principal
que efectúa una reserva y uno o varios FCM incluidos en el DCM.
El segundo ejemplo de realización se muestra en
la figura 2. En este caso se supone que los recursos no incluyen
aplicaciones capaces de gestionar las acciones preprogramadas como
en el primer ejemplo de realización. En este caso se hablará de
"recursos pasivos". No obstante, estos últimos pueden almacenar
en memoria una parte de estos datos (por ejemplo los horarios de las
acciones que deben efectuar y eventualmente parámetros y datos de
usuario) como se indica en el primer ejemplo de realización.
La aplicación cliente que inicia 15 la
programación de la acción es, al igual que en el primer ejemplo, un
interfaz situado en un televisor 16. El aparato de grabación 17
incluye el recurso de grabación digital 18, otros recursos 19 y un
gestor de recursos
20.
20.
Según el presente ejemplo de realización, el
aparato 17 incluye también un gestor de acciones preprogramadas 21
("GAP"). Este gestor de acciones 21 es un servicio de acuerdo
con el documento HAVi y efectúa todas las reservas necesarias para
la ejecución de la acción. Sólo existe una diferencia funcional
entre el gestor de acciones preprogramadas y el gestor de recursos.
Mientras que el gestor de acciones preprogramadas gestiona las
acciones preprogramadas, el gestor de recursos gestiona las reservas
correspondientes a las acciones y los eventuales conflictos que de
ellas se derivan. Estas dos funciones pueden estar integradas en un
mismo objeto de software, como se indica en la figura 2. La
representación distinta del GAP y del GR se utiliza simplemente por
cuestiones de coherencia con el primer ejemplo de realización, en el
que dichas funciones se llevan a cabo mediante objetos
independientes.
El gestor de acciones 21 gestiona los recursos
pasivos del aparato 17, pero también los del aparato 5.
La realización de una acción preprogramada de
acuerdo con el segundo ejemplo de realización implica:
- una aplicación cliente,
- un gestor de acciones preprogramadas
("GAP"),
- uno o varios recursos públicos, denominados
"recursos implicados", necesarios para la llevar a cabo la
acción preprogramada.
En el marco de una petición de grabación, los
recursos implicados son, por ejemplo:
- la función de grabación de una grabadora
digital (magnetoscopio digital, DVD.....),
- un sintonizador.
Pueden ser necesarios otros recursos: por
ejemplo un transcodificador, necesario para convertir el formato de
los datos al de la grabadora, un servicio de control de acceso para
autorizar el acceso a los programas protegidos....
Debe tenerse en cuenta la necesidad de que el
procedimiento de realización de la acción preprogramada funcione
normalmente aun cuando el dispositivo de presentación a través del
cual se ha programado la acción pase a la inactividad (por ejemplo,
el usuario ha apagado el televisor que le ha servido para la
programación del magnetoscopio). Por consiguiente, este dispositivo
no incluye preferentemente los recursos implicados.
El gestor de acciones preprogramadas acepta o no
la acción solicitada por la aplicación cliente. Esta última ha
identificado previamente los recursos necesarios para la ejecución
de la acción, los comandos a efectuar al inicio de la acción y las
conexiones requeridas entre los diversos recursos que deben
establecerse antes de la hora de inicio de la acción.
El GAP almacena en memoria todos estos datos de
la acción y reenvía un identificador de la acción a la aplicación
cliente. Por otra parte, todos los recursos implicados almacenan su
propia agenda relativa a las acciones a efectuar. Dicha agenda
incluye concretamente los horarios de las reservas pero no los
comandos y conexiones vinculados a las acciones. Esto exigiría
demasiado espacio en memoria. Gracias a esta agenda, cada recurso
puede informar a otros GAP que inicien acciones su disponibilidad o
falta de disponibilidad para dichas acciones.
Antes de aceptar o rechazar una petición de
acción, el GAP interroga a todos los recursos para saber si están
disponibles entre las horas de inicio y finalización de la acción. A
la hora de inicio de la acción, si se encuentran presentes todos
los recursos, el GAP reserva los recursos (en este caso se trata de
la reserva propiamente dicha en relación con las sencillas
indicaciones de agenda programadas anteriormente), establece las
conexiones necesarias e inicia los comandos. El establecimiento de
las conexiones se solicita al módulo de software local denominado
gestor de conexiones ("SM" o "Stream Manager" de acuerdo
con la terminología del documento HAVi).
Si uno de los recursos implicados en una acción
preprogramada desaparece con anterioridad a la hora de inicio de la
acción, esta última quedará suspendida hasta que el recurso se
encuentre nuevamente disponible en la red. Si el recurso que falta
reaparece, aunque sea con posterioridad a la hora de inicio de la
acción preprogramada, la acción se ejecutará, aunque esté desfasada
en el tiempo.
Una acción preprogramada puede ser definida por
un número determinado de informaciones recopiladas en una estructura
de datos específica recopilada por la aplicación que programa la
acción y almacenada en memoria de acuerdo con el segundo ejemplo de
realización por el gestor de acciones preprogramadas.
- el tipo de acción,
- los parámetros relativos a la acción (comandos
a efectuar para cada recurso implicado, lista de las conexiones que
deben establecerse antes del inicio de la acción),
- una fecha,
- una hora de inicio,
- una hora de finalización,
- la periodicidad de la acción,
- los identificadores de los recursos
implicados,
- los datos de usuario.
Los diferentes elementos tienen un significado
similar al que se ha descrito en relación con el primer ejemplo de
realización.
Si una aplicación desea conocer qué acción
preprogramada está asociada a un recurso dado, puede consultar todas
las acciones programadas que se encuentran registradas en un GAP.
También puede solicitar al recurso los identificadores de cada una
de las acciones preprogramadas en las cuales está implicado este
recurso. Por lo tanto, puede recuperar el identificador del GAP que
mantiene los datos de una acción preprogramada dada.
Una aplicación tiene también la posibilidad de
anular una acción preprogramada, o de modificar una acción de este
tipo, con el GAP encargado de dicha acción.
Los identificadores de los recursos implicados
son utilizados por el GAP de acuerdo con el segundo ejemplo de
realización. La lista permite al GAP solicitar informaciones
relativas a los recursos implicados, por ejemplo a través de los
registros o transmitiéndoles los mensajes directamente.
El GAP distribuye la acción preprogramada entre
los gestores de control de aparatos (DCM - véase más adelante) de
los recursos implicados, con todos los parámetros necesarios para
cada recurso. Cada recurso (o su DCM) debe determinar si pueden
efectuarse a la hora prevista las conexiones solicitadas y los
comandos previstos.
Si los recursos son capaces de satisfacer la
petición, lo advertirán al GAP que reenviará un identificador de la
acción a la aplicación cliente para indicarle que se ha hecho cargo
de la acción.
Si los recursos no son capaces de satisfacer la
petición, o si uno de los recursos requeridos no se encuentra
presente en la red o incluso si la preferencia de un recurso
implicado y ya reservado en el marco de otra acción no ha sido
posible, el GAP rechaza la acción preprogramada transmitiendo el
correspondiente mensaje a la aplicación cliente.
En caso de conflicto de reservas, por ejemplo en
caso de preferencia o negociación de un recurso no disponible, el
GAP lo notifica a la aplicación cliente que ha programado la acción
mediante un mensaje adecuado. Cada GAP almacena en memoria con este
fin el identificador o la dirección de la aplicación que ha
efectuado una reserva.
Un recurso puede designarse mediante los
términos gestor de componente funcional ("FCM" o "Function
Component Manager" según la terminología HAVi). La arquitectura
puede entonces estar representada por el esquema de la figura 3 en
el que una aplicación transmite una programación de acción al
interfaz de programación de aplicación que forma parte del
objetivo.
Más generalmente, en el ámbito del HAVi existen
otros recursos aparte de los FCM. Por ejemplo existe otro tipo de
recurso denominado "DCM" o "Device Control Manager" o
gestor de control de aparato. Mientras que un FCM es la
representación lógica de una función de un aparato, un DCM es la
representación lógica de un aparato, pudiendo integrar varios FCM.
Un DCM será entonces un intermediario entre una aplicación principal
que efectúa una reserva y uno o varios FCM incluidos en el DCM.
La figura 4 es un esquema simplificado del
principio del segundo ejemplo de realización. En resumen, para
programar una acción, una aplicación se dirige al gestor de acciones
preprogramadas que se encuentra obligatoriamente presente en el
aparato que incorpora el recurso objetivo. La aplicación actúa a
través del interfaz de programación del gestor de acciones que a su
vez actúa a través del interfaz de programación del objetivo. El
aparato que incluye el gestor y el objetivo puede ser un aparato de
funciones completas ("FAV") o bien un aparato de funciones
intermedias ("IAV").
Claims (13)
1. Procedimiento para programación de acciones
de recursos en una red de aparatos domésticos, caracterizado
porque incluye las etapas de:
- transmisión de una petición de programación de
una acción por una aplicación cliente (15) a un gestor de acciones
preprogramadas (21) de un aparato de la red (17), incluyendo dicha
petición de programación un conjunto de parámetros que definen la
acción y una lista de recursos implicados en la ejecución de la
acción,
- verificación por parte de dicho gestor de
acciones (21) de la disponibilidad de recursos implicados en la
ejecución de la acción,
- transmisión a la aplicación cliente (15) de un
mensaje de aceptación o de rechazo de la acción por parte del gestor
de acciones preprogramadas en función del resultado de dicha
verificación.
2. Procedimiento de acuerdo con la
reivindicación 1, caracterizado porque la aplicación cliente
selecciona un gestor de acciones preprogramadas situado en un
aparato distinto del de la propia aplicación cliente.
3. Procedimiento de acuerdo con una de las
reivindicaciones 1 ó 2, caracterizado porque incluye la etapa
de almacenamiento en memoria por cada recurso implicado de su
agenda en relación con la acción.
4. Procedimiento de acuerdo con una de las
reivindicaciones 1 a 3, caracterizado porque la etapa de
verificación comprende una petición del gestor de acciones
preprogramadas acerca de cada recurso implicado con el fin de
conocer la disponibilidad de recursos implicados a través de sus
respectivas agendas.
5. Procedimiento de acuerdo con una de las
reivindicaciones 1 a 4, caracterizado porque a la hora de
inicio de la acción, el gestor de acciones preprogramadas efectúa
las siguientes tareas:
- reserva de los recursos implicados,
- establecimiento de las conexiones requeridas
entre los recursos implicados,
- inicio de los comandos dirigidos a los
recursos implicados.
6. Procedimiento de acuerdo con una de las
reivindicaciones 1 a 5, caracterizado porque los parámetros
de definición de la acción incluyen una hora de inicio de la
acción.
7. Procedimiento de acuerdo con una de las
reivindicaciones 1 a 6, caracterizado porque los parámetros
de definición de la acción incluyen una hora de finalización de la
acción.
8. Procedimiento de acuerdo con una de las
reivindicaciones 1 a 7, caracterizado porque los parámetros
de definición de la acción incluyen un parámetro de periodicidad de
la acción.
9. Procedimiento de acuerdo con una de las
reivindicaciones 1 a 8, caracterizado porque los parámetros
de definición de la acción incluyen una lista de conexiones a
establecer con anterioridad al inicio de la acción.
10. Procedimiento de acuerdo con la
reivindicación 1, caracterizado porque la etapa de
verificación de la disponibilidad incluye la etapa de interrogación
a los recursos implicados para conocer su disponibilidad entre una
hora de inicio y una hora de finalización de la acción.
11. Procedimiento de acuerdo con una de las
reivindicaciones precedentes, caracterizado porque la etapa
de envío de un mensaje de aceptación viene precedida de una etapa de
reserva de los recursos implicados.
12. Aparato (17) de una red doméstica,
caracterizado porque incluye un gestor de acciones
preprogramadas (21) para recibir una petición de programación de una
acción transmitida por una aplicación cliente (15), incluyendo
dicha petición de programación un conjunto de parámetros de
definición de la acción y una lista de recursos implicados en la
ejecución de la acción, estando previsto el gestor de acciones
preprogramadas para verificar la disponibilidad de los recursos
implicados en la ejecución de la acción y para transmitir a la
aplicación cliente (15) un mensaje de aceptación o de rechazo de la
acción.
13. Aparato de acuerdo con la reivindicación 12,
caracterizado porque los parámetros incluyen la hora de
inicio y de finalización de la acción, y porque la verificación de
la disponibilidad incluye la verificación de la disponibilidad de
los recursos implicados entre dichas horas.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR9807187A FR2779596B1 (fr) | 1998-06-08 | 1998-06-08 | Procede de programmation d'actions de ressources dans un reseau de communication domestique |
FR9807187 | 1998-06-08 |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2260942T3 true ES2260942T3 (es) | 2006-11-01 |
Family
ID=9527141
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES99955574T Expired - Lifetime ES2260942T3 (es) | 1998-06-08 | 1999-06-08 | Procedimiento para programacion de acciones de recursos en una red de comunicacion domestica. |
Country Status (11)
Country | Link |
---|---|
US (1) | US8385718B1 (es) |
EP (1) | EP1095486B1 (es) |
JP (1) | JP4647097B2 (es) |
KR (1) | KR100689115B1 (es) |
CN (1) | CN1166121C (es) |
AU (1) | AU4268699A (es) |
DE (1) | DE69930663T2 (es) |
ES (1) | ES2260942T3 (es) |
FR (1) | FR2779596B1 (es) |
PL (1) | PL344692A1 (es) |
WO (1) | WO1999065189A1 (es) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU2001263075A1 (en) | 2000-05-12 | 2001-11-26 | Thomson Licensing S.A. | Apparatus and method for improved device interoperability |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4855730A (en) * | 1987-05-08 | 1989-08-08 | Rca Licensing Corporation | Component audio/video system with timed control of plural peripheral devices |
AU625293B2 (en) * | 1988-12-09 | 1992-07-09 | Tandem Computers Incorporated | Synchronization of fault-tolerant computer system having multiple processors |
US5065392A (en) * | 1990-04-10 | 1991-11-12 | Dsc Communications Corporation | Network controller scheduling system and method of operation |
GB9121203D0 (en) * | 1991-10-04 | 1991-11-20 | D2B Systems Co Ltd | Local communication bus system and apparatus for use in such a system |
JPH06261139A (ja) | 1993-01-08 | 1994-09-16 | Sony Corp | Av機器制御システム |
JPH0856352A (ja) | 1994-08-11 | 1996-02-27 | Matsushita Electric Ind Co Ltd | ビデオファイルサーバ及び録画制御装置 |
US6948070B1 (en) * | 1995-02-13 | 2005-09-20 | Intertrust Technologies Corporation | Systems and methods for secure transaction management and electronic rights protection |
JPH09233567A (ja) | 1996-02-22 | 1997-09-05 | Sharp Corp | インテリジェントリモコン装置 |
US5961623A (en) * | 1996-08-29 | 1999-10-05 | Apple Computer, Inc. | Method and system for avoiding starvation and deadlocks in a split-response interconnect of a computer system |
WO1998028915A2 (en) * | 1996-12-23 | 1998-07-02 | Koninklijke Philips Electronics N.V. | Method and system for supplying data streams |
US6151688A (en) * | 1997-02-21 | 2000-11-21 | Novell, Inc. | Resource management in a clustered computer system |
US6018816A (en) * | 1997-04-04 | 2000-01-25 | Canon Kabushiki Kaisha | Information processing system and method, image processing system and method, information processing apparatus and computer readable memory |
US6298370B1 (en) * | 1997-04-04 | 2001-10-02 | Texas Instruments Incorporated | Computer operating process allocating tasks between first and second processors at run time based upon current processor load |
US6425033B1 (en) * | 1997-06-20 | 2002-07-23 | National Instruments Corporation | System and method for connecting peripheral buses through a serial bus |
US6931430B1 (en) * | 1998-05-13 | 2005-08-16 | Thomas W. Lynch | Maintaining coherency in a symbiotic computing system and method of operation thereof |
-
1998
- 1998-06-08 FR FR9807187A patent/FR2779596B1/fr not_active Expired - Fee Related
-
1999
- 1999-06-08 US US09/719,182 patent/US8385718B1/en not_active Expired - Fee Related
- 1999-06-08 KR KR1020007013907A patent/KR100689115B1/ko not_active IP Right Cessation
- 1999-06-08 AU AU42686/99A patent/AU4268699A/en not_active Abandoned
- 1999-06-08 EP EP99955574A patent/EP1095486B1/fr not_active Expired - Lifetime
- 1999-06-08 JP JP2000554094A patent/JP4647097B2/ja not_active Expired - Lifetime
- 1999-06-08 ES ES99955574T patent/ES2260942T3/es not_active Expired - Lifetime
- 1999-06-08 CN CNB99807117XA patent/CN1166121C/zh not_active Expired - Lifetime
- 1999-06-08 DE DE69930663T patent/DE69930663T2/de not_active Expired - Lifetime
- 1999-06-08 PL PL99344692A patent/PL344692A1/xx not_active Application Discontinuation
- 1999-06-08 WO PCT/FR1999/001357 patent/WO1999065189A1/fr active IP Right Grant
Also Published As
Publication number | Publication date |
---|---|
EP1095486B1 (fr) | 2006-03-29 |
JP2002518718A (ja) | 2002-06-25 |
WO1999065189A1 (fr) | 1999-12-16 |
CN1304607A (zh) | 2001-07-18 |
FR2779596B1 (fr) | 2000-07-21 |
EP1095486A1 (fr) | 2001-05-02 |
FR2779596A1 (fr) | 1999-12-10 |
KR100689115B1 (ko) | 2007-03-08 |
DE69930663D1 (de) | 2006-05-18 |
US8385718B1 (en) | 2013-02-26 |
CN1166121C (zh) | 2004-09-08 |
KR20010052667A (ko) | 2001-06-25 |
DE69930663T2 (de) | 2006-11-09 |
AU4268699A (en) | 1999-12-30 |
JP4647097B2 (ja) | 2011-03-09 |
PL344692A1 (en) | 2001-11-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2348784T3 (es) | Procedimiento para gestion de prioridades de acceso a recursos en una red domestica y aparato para llevarlo a cabo. | |
ES2228979T3 (es) | Procedimiento para gestion de grabaciones de emisiones audiovisuales y dispositivos asociados. | |
US8607280B2 (en) | Resource and capability borrowing | |
CN1825823B (zh) | 家庭网络的业务框架 | |
US20020029271A1 (en) | Method to control a network device in a network comprising several devices | |
US6600868B2 (en) | Information processing system, information processing method, and recording medium | |
JP4166466B2 (ja) | 無線通信システム及び無線通信方法、無線通信装置及びその制御方法、並びにコンピュータ・プログラム | |
JP2007194974A (ja) | 映像表示装置、映像録画装置および映像配信制御方式 | |
US6252886B1 (en) | Bandwidth reservation | |
US20010026533A1 (en) | Method to perform a scheduled action of network devices | |
US7305002B1 (en) | Methods for controlling resources in a communication network | |
US20110185391A1 (en) | Systems and methods for connecting networked devices | |
ES2260942T3 (es) | Procedimiento para programacion de acciones de recursos en una red de comunicacion domestica. | |
CN101136819A (zh) | 管理家庭网络中的装置提供的服务的方法和设备 | |
WO2021017664A1 (zh) | 配对信息上传方法、配对连接方法和配对认证方法及终端和服务器 | |
EP0971509A1 (en) | Bandwidth reservation | |
WO2000002337A1 (en) | Bandwidth reservation | |
JP2004207864A (ja) | 電子番組ガイド画面生成装置、電子番組ガイド画面生成方法、デバイス/機能予約装置、デバイス/機能予約方法、デジタル放送受信システム、プログラム及び記録媒体 | |
US7643415B2 (en) | Method for controlling link connections in a communication system and corresponding communication system | |
MXPA00012221A (es) | Proceso para programar acciones de recursos en una red de comunicacion domestica | |
EP4311180A1 (en) | Connection configuration method and apparatus | |
CN117439839A (zh) | 基于跨域共享资源的异地组网协作系统、方法及设备 | |
WO2005050920A1 (ja) | 通信局、通信局の制御方法、通信システム、通信プログラム、記録媒体 | |
JP3910186B2 (ja) | 番組録画予約システム、およびそのシステムに用いられるデジタル記録再生装置 | |
CN107342919A (zh) | 终端设备服务关联方法 |