ES2657805T3 - Método, servidor de grupo y dispositivo miembro para acceder a recursos miembro - Google Patents

Método, servidor de grupo y dispositivo miembro para acceder a recursos miembro Download PDF

Info

Publication number
ES2657805T3
ES2657805T3 ES16158885.0T ES16158885T ES2657805T3 ES 2657805 T3 ES2657805 T3 ES 2657805T3 ES 16158885 T ES16158885 T ES 16158885T ES 2657805 T3 ES2657805 T3 ES 2657805T3
Authority
ES
Spain
Prior art keywords
group
resource
resources
access
member resources
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.)
Active
Application number
ES16158885.0T
Other languages
English (en)
Inventor
Yongjing Zhang
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Application granted granted Critical
Publication of ES2657805T3 publication Critical patent/ES2657805T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1877—Measures taken prior to transmission
    • 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/50—Address allocation
    • H04L61/5069—Address allocation for group communication, multicast communication or broadcast communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/08—User group management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Selective Calling Equipment (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un método para acceder a recursos miembro, que comprende: asignar un identificador virtual a al menos dos recursos miembro que tienen un trayecto de acceso diferente; asignar una dirección multidifusión al al menos un recurso miembro del recurso de grupo; establecer una relación de mapeo entre el identificador virtual y los recursos miembro del recurso de grupo; recibir una solicitud para acceder a recursos miembro, en donde la solicitud para acceder a recursos miembro lleva un identificador de recurso de grupo del recurso de grupo al cual pertenecen los recursos miembro; obtener, según el identificador de recurso de grupo, un identificador uniforme de recurso URI en abanico de salida correspondiente a los recursos miembro en el recurso de grupo y una dirección multidifusión, en donde el URI en abanico de salida es el URI en abanico de salida que se establece como un identificador de recurso virtual, y se usa para indicar trayectos de acceso de los recursos miembro en dispositivos miembro; y enviar, según la dirección multidifusión, una solicitud de acceso al recurso miembro a los dispositivos miembro que tienen los recursos miembro, en donde un URI de destino de la solicitud de acceso al recurso miembro comprende el URI en abanico de salida correspondiente a los trayectos de acceso de los recursos miembro.

Description

imagen1
imagen2
imagen3
imagen4
imagen5
imagen6
imagen7
imagen8
imagen9
imagen10
imagen11
5
10
15
20
25
30
35
40
45
50
55
miembro, y determina, según las características de los recursos miembro, si es necesario crear un grupo multidifusión. De manera específica, para determinar, por el primer servidor de grupo, si es necesario crear un grupo multidifusión, puede hacerse referencia a la descripción de la Figura 2-A. Se incluyen las siguientes etapas:
Etapa 202-1: el primer servidor de grupo analiza la solicitud de creación de recurso de grupo para obtener descripciones de características del recurso de grupo y descripciones de características de sus recursos miembro, incluidas, pero sin limitación, características como, por ejemplo, un atributo de tipo del recurso de grupo (siendo un grupo estático, dinámico o temporal o no), un propósito del recurso de grupo (que requiere una respuesta fiable para una solicitud o no), los trayectos de acceso de los recursos miembro en los dispositivos miembro, interfaces de acceso de los recursos miembro, los dispositivos miembro que tienen los recursos miembro, y sus características de red (que admiten la multidifusión o no).
Por ejemplo, las descripciones de las características del recurso de grupo pueden obtenerse del contenido de descripción del recurso de grupo transportado en la solicitud de creación de recurso de grupo. El contenido de descripción del recurso de grupo incluye el atributo de tipo y el propósito del recurso de grupo. Las descripciones de las características de los recursos miembro pueden obtenerse según la información URI de los recursos miembro incluida en la descripción de recurso de grupo, e incluyen estructuras URI de los recursos miembro, interfaces de acceso de los recursos miembro y similares. También puede accederse a los dispositivos miembro que tienen los recursos miembro según los URI de los recursos miembro, de modo que se obtienen además características como, por ejemplo, los dispositivos miembro que tienen los recursos miembro y características de red de los dispositivos miembro.
Etapa 202-2: determinar, según la descripción de grupo de la solicitud de creación de recurso de grupo, si el recurso de grupo que se creará es un grupo relativamente estático o un grupo dinámico que cambia con frecuencia; si el recurso de grupo que se creará es un grupo relativamente estático, llevar a cabo un proceso de determinación subsiguiente; si el recurso de grupo que se creará es un grupo dinámico, finalizar el proceso sin crear un grupo multidifusión para el recurso de grupo, y así evitar sobrecargas de creación de grupo multidifusión y el mantenimiento causado por los frecuentes cambios de grupo. El grupo relativamente estático puede ser: un grupo cuya descripción de grupo incluye una lista de recursos miembro específicos y cuyos cambios de miembro se controlan por el primer servidor de grupo según un comando de gestión de grupo (por ejemplo, añadir/eliminar un miembro). El grupo dinámico incluye, pero sin limitación: un grupo que incluye recursos miembro que son un conjunto de recursos que cumplen con condiciones particulares, por ejemplo, recursos miembro en un rango geográfico específico o recursos miembro que tienen otras características iguales, donde los cambios de miembros de grupo pueden activarse de forma automática según los cambios de las características de los recursos miembro (por ejemplo, un miembro abandona o ingresa en un rango geográfico o el grupo selecciona un canal).
Etapa 202-3: determinar, según las interfaces de acceso de los recursos miembro transportados en la solicitud de creación de recurso de grupo, si las interfaces de acceso de los recursos miembro son coherentes, y si las interfaces de acceso de los recursos miembro son coherentes, llevar a cabo un proceso de determinación subsiguiente o, de lo contrario, finalizar el proceso sin crear un grupo multidifusión para el recurso de grupo. Si las interfaces de acceso de los recursos miembro son coherentes es, de manera específica, si un mismo paquete de datos multidifusión (por ejemplo, un paquete de datos IPv4 o IPv6) puede usarse para el acceso. Por ejemplo, si URI para acceder a múltiples recursos miembro cumplen con un mismo protocolo y número de puerto de acceso, y los trayectos de acceso en los URI de los múltiples recursos miembro son iguales en diferentes dispositivos miembro, puede considerarse que los múltiples recursos miembro tienen una misma interfaz de acceso al recurso. En un sistema real, el URI puede representarse por un URL (Localizador Uniforme de Recursos), mientras una estructura básica del URL incluye:
<scheme>://<authority>:<port>/<path>?<query>#<fragment>
La parte <scheme> determina un protocolo usado para acceder a un recurso correspondiente al URL (por ejemplo, HTTP o CoAP); la parte <authority> determina una dirección de un dispositivo miembro que tiene el recurso miembro (por ejemplo, una dirección IP o un nombre de dominio); <port> es un artículo opcional, que indica un número de puerto de acceso al protocolo; y <path>?<query>#<fragment> indica un trayecto de acceso del recurso en el dispositivo miembro.
Por ejemplo, suponiendo que los nombres de dominio de una plataforma M2M N1, un dispositivo M2M D1, y una pasarela M2M G1 son, respectivamente, n1.example.com, d1.example.com, y g1.example.com, un URL de un recurso de grupo Grp1 en N1 es:
Grp1 = http://n1.example.com/groups/grp1
Los URL de los recursos miembro m11, m12, m13 y m14 allí incluidos son, respectivamente, como se describe a continuación:
m11 = coap://d1.example.com/xxx/temp1 13
5
10
15
20
25
30
35
40
45
50
55
m12 = coap://d1.example.com/yyy/temp2
m13 = coap://g1.example.com/xxx/temp1
m14 = http://n1.example.com/xxx/temp1
Entre los 4 recursos miembro, m11 y m13 tienen una misma interfaz de acceso al recurso, porque el mismo CoAP se usa en su <scheme> y ambos trayectos de acceso en los dispositivos miembro (d1 y g1 en la presente memoria) son /xxx/temp1; en cambio, m12 y m14 tienen diferentes interfaces de acceso al recurso con respecto a otros recursos miembro, porque el trayecto de acceso de m12 en el dispositivo miembro d1 es /yyy/temp2, mientras <scheme> de m14 es el HTTP. En el presente ejemplo, un grupo multidifusión puede crearse para m11 y m13, pero m12 y m14 no se incluyen.
Etapa 202-4: el primer servidor de grupo determina si los recursos miembro, los dispositivos miembro que tienen los recursos miembro, y una red a la cual pertenecen los dispositivos miembro admiten la multidifusión, y si la multidifusión se admite, llevar a cabo un proceso de determinación subsiguiente o, de lo contrario, finalizar el proceso sin crear un grupo multidifusión para el recurso de grupo. Si los recursos miembro admiten la multidifusión puede determinarse según si los URL correspondientes a los recursos miembro admiten el acceso al protocolo multidifusión (por ejemplo, no admitido por el HTTP, pero admitidos por el CoAP). El primer servidor de grupo puede además necesitar obtener información de representación de recurso relacionada como, por ejemplo, información de registro, de los recursos miembro y los dispositivos miembro que tienen los recursos miembro, y determinar, según la información de representación de recurso como, por ejemplo, la información de registro, si los dispositivos miembro que tienen los recursos miembro y la red a la cual pertenecen los dispositivos miembro admiten la multidifusión.
Por ejemplo, en la plataforma M2M N1, puede accederse a la información de registro del dispositivo miembro D1 que tiene el recurso miembro m11 según el siguiente URL: http://n1.example.com/scls/d1.
El primer servidor de grupo puede enviar una solicitud HTTP GET a N1 para obtener contenido de representación de recurso correspondiente al URL. En el contenido de representación de recurso, si D1 admite la multidifusión puede indicarse por un atributo especial (por ejemplo, "multicastEnabled"). Si el valor del atributo es TRUE (VERDADERO), ello indica que la multidifusión se admite. Si el valor es FALSE (FALSO), ello indica que la multidifusión no se admite.
De manera opcional, incluso si el dispositivo miembro que tiene el recurso miembro no admite la multidifusión, cuando necesita accederse al recurso miembro a través de otro dispositivo que admite la multidifusión, puede también determinarse que el dispositivo miembro que tiene el recurso miembro admite la multidifusión. Como se muestra en la Figura 2-B, el primer servidor de grupo es un dispositivo M2M D1, y un recurso de grupo Grp2 incluye un recurso miembro m21 en una plataforma M2M, pero D1 accede a m21 a través de una pasarela M2M G1.
Si un enlace de comunicación entre D1 y G1 admite la multidifusión (por ejemplo, el CoAP), D1 puede enviar una solicitud a G1 en modo multidifusión, y luego G1 convierte la solicitud en modo unidifusión (por ejemplo, el HTTP) para acceder a m21 en N1. En el presente caso, puede considerarse que la multidifusión se admite para acceder al recurso miembro m21.
Etapa 202-5: el primer servidor de grupo determina si una cantidad de dispositivos miembro que tienen los recursos miembro que cumplen con las anteriores condiciones alcanza una cantidad particular, y si la cantidad de dispositivos miembro que tienen los recursos miembro que cumplen con las anteriores condiciones alcanza la cantidad particular, lleva a cabo una etapa subsiguiente o, de lo contrario, finaliza el proceso sin crear un grupo multidifusión para el recurso de grupo. En la presente memoria, una cantidad determinada según una política o parámetro preconfigurados puede usarse como un umbral para crear un grupo multidifusión. Cuando no se alcanza el umbral, no es necesario crear un grupo multidifusión para los anteriores recursos miembro, de modo que una sobrecarga de gestión del grupo multidifusión se ahorra.
Debe notarse que la secuencia temporal de las etapas 202-2 a 202-5 no se encuentra estrictamente limitada, y que el primer servidor de grupo puede llevar a cabo solamente una o más etapas de 202-2 a 202-5 según una política o capacidad configurada, la cual no se encuentra limitada en la presente memoria por la realización de la presente invención. Asimismo, el primer servidor de grupo puede además determinar si la solicitud para acceder a recursos miembro del recurso de grupo requiere una respuesta fiable, y si el acceso al miembro para el recurso de grupo requiere una respuesta fiable, finaliza el proceso sin crear un grupo multidifusión para el recurso de grupo o, de lo contrario, lleva a cabo un proceso de determinación subsiguiente.
Requerir una respuesta fiable significa que un mensaje de respuesta que indica el éxito o fallo de la función debe devolverse después de que los dispositivos miembro que tienen los recursos miembro reciben una solicitud de acceso al recurso miembro. De manera específica, un mensaje de solicitud de tipo Confirmable (CON) en el CoAP es una solicitud de acceso al recurso miembro que requiere una respuesta fiable, y un receptor de la solicitud de
14
imagen12
5
10
15
20
25
30
35
40
45
50
N1 devuelve una respuesta de éxito, una dirección multidifusión global solicitada por el primer servidor de grupo puede obtenerse de un cuerpo de mensaje del mensaje de respuesta. Si N1 devuelve una respuesta de fallo, ello significa que la plataforma M2M N1 no puede asignar una dirección multidifusión global a los dispositivos miembro.
En realidad, el primer servidor de grupo puede también usar un método similar para solicitar que una dirección multidifusión remota o global se asigne por otra entidad (por ejemplo, otro servidor de grupo) que es responsable de gestionar la asignación de direcciones multidifusión locales o remotas. La manera de implementación es similar a la manera de solicitud de una dirección multidifusión global de la plataforma M2M N1, y no se describe en detalle en la presente invención.
203-3. El primer servidor de grupo determina si puede accederse a dispositivos miembro que no pertenecen al dominio multidifusión local (dispositivos miembro no locales) a través del segundo servidor de grupo, y si puede accederse a dispositivos miembro que no pertenecen al dominio multidifusión local a través del segundo servidor de grupo, ejecuta la etapa 203-6 o, de lo contrario, ejecuta la etapa 203-7. Por ejemplo, se supone que el primer servidor de grupo es una primera pasarela M2M G1, y que un recurso de grupo Grp3 incluye los siguientes recursos miembro no locales m31, m32, m33 y m34:
m31 = http://d2.example.com/xxx/temp1
m32 = http://d2.example.com/xxx/temp2
m33 = coap://d3.example.com/xxx/temp1
m34 = coap://d4.example.com/xxx/temp1
Luego, el dispositivo miembro que tiene m31 y m32 es un dispositivo M2M D2, mientras los dispositivos miembro m33 y m34 son, respectivamente, dispositivos M2M D3 y D4, y ninguno de D2, D3 y D4 pertenece a un dominio multidifusión local de G1. Se supone que puede accederse a D3 y D4 a través de una segunda pasarela M2M G2, y que su relación de conexión se muestra en la Figura 2-D. Por lo tanto, puede considerarse que puede accederse a los recursos miembro (m31, m32) a través del segundo servidor de grupo (dispositivo M2M D2 en la Figura 2-D), mientras que puede accederse a los recursos miembro (m33, m34) a través de un tercer servidor de grupo (pasarela M2M G2 en la Figura 2-D). Sin embargo, si D2 o G2 no pueden actuar como un servidor de grupo debido a razones como, por ejemplo, capacidades del dispositivo, puede considerarse que no puede accederse a los recursos miembro (m31, m32) o (m33, m34) a través de otro servidor de grupo, de manera específica, el primer servidor de grupo en la realización de la presente invención (pasarela M2M G1 en la Figura 2-D).
Debe notarse que incluso si solo puede accederse a un recurso miembro (por ejemplo, solo existe m31, y m32 no existe) a través de otro servidor de grupo, la etapa 203-6 puede aún llevarse a cabo para crear un recurso de grupo para el recurso miembro m31. Desde una perspectiva de mejora de la eficacia, el primer servidor de grupo puede determinar un umbral de cantidad de miembros según una política o parámetro preconfigurados. Cuando no se alcanza el umbral, se considera que no se cumplen las anteriores condiciones de determinación. Por lo tanto, la etapa 203-7 diferente de la etapa 203-6 se lleva a cabo para ahorrar una sobrecarga de gestión de grupo.
203-4. El primer servidor de grupo asigna una dirección multidifusión local a dispositivos miembro locales que admiten la multidifusión.
203-5. El primer servidor de grupo asigna una dirección multidifusión global a todos los dispositivos miembro que admiten la multidifusión.
203-6. El primer servidor de grupo solicita, según un resultado de determinación en la etapa 203-3, al segundo servidor de grupo que cree un segundo recurso de grupo en el segundo servidor de grupo, donde el segundo recurso de grupo incluye recursos miembro que no se gestionan por el primer servidor de grupo y a los que puede accederse a través del segundo servidor de grupo. Luego, el segundo servidor de grupo comienza a ejecutar un proceso relacionado a partir de la etapa 201 en la Figura 2 según el método descrito por la presente invención, el cual no se describe en la presente memoria en la realización de la presente invención.
203-7. El primer servidor de grupo graba una lista de recursos miembro no locales a los que no puede accederse a través del segundo servidor de grupo, para acceder a dichos recursos miembro en un modo unidifusión más adelante.
203-8. Determinar si el segundo servidor de grupo (por ejemplo, G2 en la Figura 2-D) es un dispositivo de dominio multidifusión local (es decir, si el acceso se lleva a cabo a través del primer servidor de grupo), y si el segundo servidor de grupo es un dispositivo de dominio multidifusión local, llevar a cabo la etapa 203-9. El primer servidor de grupo puede además asignar una dirección multidifusión local al segundo servidor de grupo y llevar a cabo la etapa 203-10. De lo contrario, establecer una relación de mapeo entre los recursos miembro y el segundo servidor de grupo, y acceder al segundo servidor de grupo en un modo unidifusión por defecto. En el ejemplo que se muestra en
16 5
10
15
20
25
30
35
40
45
50
la Figura 2-D, el segundo servidor de grupo D2 o G2 no es un dispositivo multidifusión local del primer servidor de grupo G1.
Etapa 203-10: establecer una relación de mapeo para el recurso de grupo en el primer servidor de grupo según un resultado de asignación de dirección multidifusión en la etapa 203-4, 203-5 o 203-9, o una dirección de acceso del segundo servidor de grupo en 203-8, o direcciones de dispositivos miembro en 203-7.
De manera específica, los recursos miembro en el mismo dominio multidifusión pueden compartir una dirección multidifusión; sin embargo, varios tipos de relaciones de mapeo pueden establecerse para el recurso de grupo según si las interfaces de acceso de los recursos miembro son coherentes. De manera específica, independientemente de si las interfaces de acceso de los recursos miembro son iguales, es necesario asociar el identificador de recurso de grupo a la dirección multidifusión asignada y establecer una relación de mapeo entre la dirección multidifusión y el "URI en abanico de salida". El URI en abanico de salida es el URI de destino de la solicitud de acceso al recurso miembro enviada a los dispositivos miembro por el primer servidor de grupo cuando recibe la solicitud para acceder a los recursos miembro del recurso de grupo. De manera específica, cuando los URI de los recursos miembro cumplen con el mismo protocolo y número de puerto de acceso, y los trayectos de acceso de los recursos miembro en los dispositivos miembro son iguales, el URI en abanico de salida es el trayecto de acceso de los recursos miembro en los dispositivos miembro. Cuando los URI cumplen con el mismo protocolo y número de puerto de acceso, pero los trayectos de acceso en los dispositivos miembro son diferentes, el URI en abanico de salida se establece en un identificador de recurso virtual (que puede ser un identificador de recurso de grupo o un identificador de recurso en otra forma). Para establecer la relación de mapeo entre la dirección multidifusión y el URI en abanico de salida, puede hacerse referencia a los siguientes casos:
Primer caso: los trayectos de acceso de los recursos miembro del recurso de grupo en los dispositivos miembro son iguales.
Por ejemplo, se supone que un recurso de grupo Grp4 en la pasarela M2M G1 es Grp4 = http://g1.example.org/groups/grp4.
Los recursos miembro allí incluidos son m41 en un dispositivo M2M D1 y m42 en un dispositivo M2M D5:
m41 = coap://d1.example.org/xxx/temp1
m42 = coap://d5.example.org/xxx/temp1
Una dirección multidifusión IPv6 asignada por el primer servidor de grupo (pasarela M2M G1 en el presente ejemplo) a los recursos miembro m41 y m42 en el recurso de grupo Grp4 es [FF32:30:3FFE:FFFF:1::1231], y la relación de conexión de red entre dispositivos se muestra en la Figura 2-E (es decir, ambos dispositivos miembro D1 y D2 que tienen los recursos miembro m41 y m42 pertenecen a la pasarela M2M G1). La relación de mapeo entre el URI en abanico de salida (/xxx/temp1) y la dirección multidifusión ([FF32:30:3FFE:FFFF:1::1231]) del recurso de grupo Grp4 y la relación de mapeo entre el URI en abanico de salida (/xxx/temp1) y los recursos miembro (m41 y m42) del recurso de grupo Grp4 son como se muestra en la Tabla 1. Ciertamente, en el presente caso, dado que los trayectos de acceso de todos los dispositivos miembro que tienen el recurso de grupo en los dispositivos miembro son iguales, todos los recursos miembro corresponden a una dirección multidifusión y un URI en abanico de salida. Por lo tanto, la relación de mapeo puede además ser solo una relación de mapeo entre el URI en abanico de salida y la dirección multidifusión del recurso de grupo Grp4, y no es necesario grabar la relación de mapeo entre el URI en abanico de salida y los recursos miembro del recurso de grupo. Sin embargo, el mismo servidor de grupo en general incluye múltiples recursos de grupo, mientras las características de recurso miembro de cada recurso de grupo son incoherentes. Por lo tanto, para la coherencia de registro, incluso si no es necesario grabar la relación de mapeo entre el URI en abanico de salida y los recursos miembro, los recursos miembro pueden grabarse en la relación de mapeo en la lista o los atributos relacionados pueden reservarse, de modo que se asegura la coherencia de registro.
Segundo caso: los recursos miembro del recurso de grupo representan los dispositivos miembro que tienen los recursos miembro.
Por ejemplo, se supone que un recurso de grupo Grp5 en la pasarela M2M G1 es Grp5 = http://g1.example.org/groups/grp5, donde los recursos miembro incluidos son m51, m52 y m53 en los dispositivos M2M D1, D5 y D6 respectivamente.
m51 = coap://d1.example.org/
m52 = coap://d5.example.org/
m53 = coap://d6.example.org/
17 5
10
15
20
25
30
35
40
45
50
Una dirección multidifusión IPv6 asignada es [FF32:30:3FFE:FFFF:1::1232], y la relación de conexión de red entre los dispositivos es aún como se muestra en la Figura 2-E (es decir, todos los dispositivos miembro D1, D5 y D6 respectivamente que tienen los recursos miembro m51, m52 y m53 pertenecen a la pasarela M2M G1). Por lo tanto, el URI en abanico de salida correspondiente a los recursos miembro m51, m52, y m53 es un símbolo de raíz "/"; y la relación de mapeo entre el URI en abanico de salida (/) y la dirección multidifusión ([FF32:30:3FFE:FFFF:1 ::1232]) del recurso de grupo Grp5 y la relación de mapeo entre el URI en abanico de salida (/) y los recursos miembro (m51, m52 y m53) son como se muestra en la Tabla 2. En el presente caso, la información de URI en abanico de salida puede también omitirse en aras de la simplicidad. Además, en el presente caso, también puede hacerse referencia a la relación de mapeo como la relación de mapeo entre la dirección multidifusión ([FF32:30:3FFE:FFFF:1::1232]), el URI en abanico de salida (/), y los recursos miembro (m51, m52 y m53) del recuro de grupo. A menos que se establezca especialmente lo contrario en la realización de la presente invención, la relación de mapeo se refiere a la relación de mapeo entre la dirección multidifusión, los recursos miembro y el URI en abanico de salida.
Tercer caso: los trayectos de acceso de los recursos miembro del recurso de grupo en los respectivos dispositivos miembro son diferentes.
Por ejemplo, se supone que un recurso de grupo Grp6 en la pasarela M2M G1 es Grp6 = http://g1.example.org/groups/grp6, donde los recursos miembro del recurso de grupo Grp6 son m61 en un dispositivo M2M D5 y (m62, m63) en un dispositivo M2M D6 respectivamente:
m61 = coap://d5.example.org/xx
m62 = coap://d6.example.org/yy
m63 = coap://d6.example.org/zz
Una dirección multidifusión IPv6 asignada por el primer servidor de grupo (pasarela M2M G1 en la Figura 2-E en el presente ejemplo) a Grp6 es [FF32:30:3FFE:FFFF:1::1233], y la relación de conexión de red entre los dispositivos se muestra en la Figura 2-E (tanto el dispositivo miembro D5 que tiene el recurso miembro m61 como el dispositivo miembro D6 que tiene los recursos miembro m62 y m63 pertenecen a la pasarela M2M G1). Por lo tanto, el primer servidor de grupo necesita asignar un URI en abanico de salida virtual a cada recurso miembro del recurso de grupo Grp6 (el método de asignación específico puede determinarse por el primer servidor de grupo, y no se encuentra limitado en la presente memoria en la realización de la presente invención), por ejemplo, "/well-know/grp6". El URI en abanico de salida virtual (/well-know/grp6) no corresponde directamente a recursos miembro en cualquier dispositivo miembro, sino que cada dispositivo miembro necesita asociar el URI en abanico de salida virtual al recurso miembro correspondiente al URI en abanico de salida virtual y que pertenece al dispositivo miembro en el recurso de grupo. Para el método de asociación específico, puede hacerse referencia a la descripción relacionada subsiguiente de la Figura 2-G. Además, para evitar un conflicto de nombre de los URI en abanico de salida virtuales asignados por diferentes servidores de grupo, lo cual puede ocurrir en el mismo dispositivo miembro, puede adoptarse una división espacial de nombre adecuada entre diferentes servidores de grupo, o un único URI de grupo (por ejemplo, /g1.example.org/groups/grp6) se usa directamente como una parte o una totalidad del URI en abanico de salida virtual. Para la relación de mapeo entre el URI en abanico de salida (/well-know/grp6) y los recursos miembro m61, m62, y m63 del recurso de grupo Grp6 y la relación de mapeo establecida entre el URI en abanico de salida (well-know/grp6) y la dirección multidifusión ([FF32:30:3FFE:FFFF:1::1233]), puede hacerse referencia a la Tabla 2.
Cuarto caso: las interfaces de acceso de una parte de los recursos miembro son iguales.
Por ejemplo, cuando las interfaces de acceso de una parte de los recursos miembro son iguales, mientras las interfaces de acceso de otros recursos miembro son diferentes, aparte del uso del método anterior, los recursos miembro que tienen la misma interfaz de acceso pueden agruparse en un primer grupo (puede haber múltiples grupos), los recursos miembro que tienen diferentes interfaces de acceso se agrupan en un segundo grupo, y luego cada grupo de recursos miembro, direcciones multidifusión y URI en abanico de salida se mapean según el método anterior para formar múltiples grupos de relaciones de mapeo. Para cada grupo de recursos miembro, el servidor de grupo puede asignar diferentes direcciones multidifusión de forma separada o asignar la misma dirección multidifusión. Para esta última, se requiere que el "URI en abanico de salida" de cada grupo sea diferente.
Por ejemplo, se supone que un recurso de grupo Grp7 en la pasarela M2M G1 es Grp7 = http://g1.example.org/groups/grp7, donde los recursos miembro incluidos en el recurso de grupo Grp7 son respectivamente m71 en un dispositivo M2M D1, m72 en D5, m73 en D6, m74 en D7, m75 en D8, m76 en D9 y m77 en N1:
m71 = coap://d1.example.org/xx/aa
m72 = coap://d5.example.org/xx/aa
18
imagen13
imagen14
imagen15
imagen16
imagen17
imagen18
imagen19
imagen20
imagen21
imagen22
imagen23
imagen24
imagen25
imagen26
imagen27
imagen28
imagen29
imagen30
imagen31
imagen32
imagen33
imagen34
imagen35
imagen36
imagen37

Claims (1)

  1. imagen1
    imagen2
    imagen3
ES16158885.0T 2012-01-06 2012-07-12 Método, servidor de grupo y dispositivo miembro para acceder a recursos miembro Active ES2657805T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201210004135 2012-01-06
CN201210004135.6A CN103200209B (zh) 2012-01-06 2012-01-06 成员资源的访问方法、群组服务器和成员设备

Publications (1)

Publication Number Publication Date
ES2657805T3 true ES2657805T3 (es) 2018-03-06

Family

ID=48722566

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16158885.0T Active ES2657805T3 (es) 2012-01-06 2012-07-12 Método, servidor de grupo y dispositivo miembro para acceder a recursos miembro

Country Status (10)

Country Link
US (1) US9450772B2 (es)
EP (3) EP3367709A1 (es)
JP (1) JP5891551B2 (es)
KR (1) KR101571376B1 (es)
CN (1) CN103200209B (es)
CA (1) CA2859059C (es)
ES (1) ES2657805T3 (es)
IN (1) IN2014CN04375A (es)
RU (1) RU2598582C2 (es)
WO (1) WO2013102346A1 (es)

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI125254B (en) 2012-07-17 2015-08-14 Arm Finland Oy Method and device in a network service system
EP3958591B1 (en) * 2013-09-20 2023-05-24 Convida Wireless, LLC Enhanced m2m content management based on interest
KR102035359B1 (ko) * 2013-10-14 2019-10-24 전자부품연구원 리소스 접근 방법 및 이를 적용한 시스템
CN103605480B (zh) * 2013-10-29 2016-08-17 新浪网技术(中国)有限公司 Web服务器及其磁盘资源访问控制方法
CN105745867B (zh) * 2013-12-01 2019-05-31 Lg电子株式会社 用于在无线通信系统中管理特定资源的方法和设备
CN104936199A (zh) * 2014-03-20 2015-09-23 中兴通讯股份有限公司 一种资源通告管理的方法及公共业务实体
US9887939B2 (en) * 2015-03-11 2018-02-06 International Business Machines Corporation Transmitting multi-destination packets in overlay networks
WO2016008102A1 (zh) * 2014-07-15 2016-01-21 华为技术有限公司 对群组资源中成员资源的操作请求的处理方法及装置
WO2016011373A1 (en) * 2014-07-18 2016-01-21 Convida Wireless, Llc Enhanced operations between service layer and management layer in an m2m system by allowing the execution of a plurality of commands on a plurality of devices
JP5844440B1 (ja) * 2014-08-08 2016-01-20 ソフトバンク株式会社 通信端末装置及び通信システム
US10362577B2 (en) 2014-09-23 2019-07-23 Lg Electronics Inc. Method and apparatus for re-arrangement of group resource in wireless communication system
EP3001704A1 (en) * 2014-09-29 2016-03-30 Alcatel Lucent Method, network node, distributed system and communication network for providing data from machine devices to a first network node
CN105577564B (zh) * 2014-10-15 2019-02-01 青岛海尔智能家电科技有限公司 一种信令高效传输的方法和装置
WO2016064235A2 (ko) * 2014-10-24 2016-04-28 엘지전자 주식회사 무선 통신 시스템에서 그룹 멤버의 자식 자원을 관리하기 위한 방법 및 이를 위한 장치
EP3213205A1 (en) 2014-10-31 2017-09-06 Convida Wireless, LLC Managing application relationships in machine-to-machine systems
US10375593B2 (en) * 2014-11-04 2019-08-06 Telefonaktiebolaget Lm Ericsson (Publ) Analysis of connection patterns in a communication network
US11088893B2 (en) 2014-11-12 2021-08-10 Telefonaktiebolaget Lm Ericsson (Publ) Methods and devices for negotiating session descriptor parameters
WO2016090577A1 (zh) * 2014-12-10 2016-06-16 华为技术有限公司 计算机及设备访问方法
US10193788B2 (en) * 2014-12-19 2019-01-29 Disrupter LLC Systems and methods implementing an autonomous network architecture and protocol
CN104717132B (zh) * 2015-02-13 2017-10-13 腾讯科技（深圳）有限公司 消息发送方法、装置和系统
CN106034281B (zh) 2015-03-17 2018-08-14 中兴通讯股份有限公司 一种基于m2m网关的末梢网络建立方法、装置和系统
CN104955153B (zh) * 2015-05-29 2022-03-11 青岛海尔智能家电科技有限公司 一种发现资源的方法、装置及设备
US20160381136A1 (en) * 2015-06-24 2016-12-29 Futurewei Technologies, Inc. System, method, and computer program for providing rest services to fine-grained resources based on a resource-oriented network
CN107836103B (zh) * 2015-07-10 2021-02-19 瑞典爱立信有限公司 本地网络中的资源发现
JP6561656B2 (ja) * 2015-07-29 2019-08-21 株式会社リコー 端末およびマルチキャスト・アドレス配布サーバ
JP6661931B2 (ja) * 2015-09-17 2020-03-11 沖電気工業株式会社 情報配信装置、情報配信プログラム及び情報配信システム
CN106790323B (zh) * 2015-11-19 2020-02-14 华为软件技术有限公司 一种资源发现的方法及装置
US10708885B2 (en) 2015-12-15 2020-07-07 Convida Wireless, Llc Methods and nodes for enabling context-awareness in CoAP
CN111885508B (zh) 2015-12-15 2022-04-12 华为云计算技术有限公司 一种群组多播和群组创建的方法以及移动网络平台
CN106937240B (zh) * 2015-12-31 2020-10-09 华为技术有限公司 一种获取资源的方法和装置
US11722456B2 (en) * 2016-07-01 2023-08-08 Intel Corporation Communications in internet-of-things devices
EP3282618A1 (en) * 2016-08-09 2018-02-14 Panasonic Intellectual Property Corporation of America Improved initial and retransmissions of data for v2x transmissions
WO2018067939A1 (en) * 2016-10-07 2018-04-12 Convida Wireless, Llc Service layer resource management for generic interworking and extensibility
WO2018071773A2 (en) * 2016-10-13 2018-04-19 Convida Wireless, Llc Enabling multicast for service layer group operation
CN108075908B (zh) * 2016-11-11 2023-01-17 京东方科技集团股份有限公司 处理操作请求的方法及装置
CN106873553B (zh) * 2017-02-09 2020-01-21 北京东土科技股份有限公司 基于工业互联网操作系统的现场设备控制管理方法及装置
CN109874113B (zh) * 2017-12-05 2022-03-18 中兴通讯股份有限公司 一种多播组信息的处理方法、装置和系统
CN108206992B (zh) * 2017-12-05 2022-07-15 中兴通讯股份有限公司 一种多播组信息的传递方法、装置和系统
CN109905431B (zh) 2017-12-08 2021-01-26 京东方科技集团股份有限公司 消息处理方法及系统、存储介质、电子设备
CN112189360B (zh) * 2018-03-20 2024-03-22 瑞典爱立信有限公司 用于操作和管理网络内的受限设备的方法和装置
CN108762950A (zh) * 2018-05-23 2018-11-06 山东浪潮商用系统有限公司 一种规范化RESTful微服务交互方法
US11424961B2 (en) * 2018-09-14 2022-08-23 Hewlett Packard Enterprise Development Lp Exporting the device sharing attribute for host devices from a wireless controller to a switch
CN110472378B (zh) * 2019-04-22 2020-04-17 山东汇佳软件科技股份有限公司 共享大数据现场保护平台
US11032093B2 (en) * 2019-07-17 2021-06-08 Juniper Networks, Inc. Multicast group membership management
KR102137914B1 (ko) * 2019-11-20 2020-07-24 전자부품연구원 IoT/M2M 플랫폼에서 그룹 통지 취합 방법
EP4136531A1 (en) * 2020-04-15 2023-02-22 Telefonaktiebolaget LM ERICSSON (PUBL) Orchestrating execution of a complex computational operation
KR20210128096A (ko) * 2020-04-16 2021-10-26 세종대학교산학협력단 사물인터넷 플랫폼 간 연동 방법 및 장치
CN111988298B (zh) * 2020-08-13 2023-05-30 山东伏羲智库互联网研究院 数据处理方法、装置及设备

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2118051C1 (ru) * 1996-04-30 1998-08-20 Лихачев Александр Геннадьевич Способ доступа к ресурсам "всемирной паутины" через шлюзы-представители
US6654796B1 (en) * 1999-10-07 2003-11-25 Cisco Technology, Inc. System for managing cluster of network switches using IP address for commander switch and redirecting a managing request via forwarding an HTTP connection to an expansion switch
US6917626B1 (en) * 1999-11-30 2005-07-12 Cisco Technology, Inc. Apparatus and method for automatic cluster network device address assignment
TW472208B (en) * 2000-07-03 2002-01-11 Nat Science Council An indexing method for mapping multiple segments of coded fields into a table-structure field
KR100445226B1 (ko) 2002-07-24 2004-08-21 한국전력공사 분류형 데이터 구조를 이용한 원격 검침 시스템
BRPI0514454A (pt) * 2004-08-16 2008-06-10 Qualcomm Flarion Tech método e aparelho para gerenciamento de afiliação de grupo para comunicações de grupo
FI20041169A0 (fi) * 2004-09-08 2004-09-08 Nokia Corp Ryhmäpalveluiden ryhmätiedot
US8014321B2 (en) 2004-10-22 2011-09-06 Microsoft Corporation Rendezvousing resource requests with corresponding resources
WO2006086939A1 (de) * 2005-02-17 2006-08-24 Infineon Technologies Ag Verwaltung dynamischer gruppen in einem push-to-talk over cellular kommunikationssystems
US8230435B2 (en) * 2008-02-12 2012-07-24 International Business Machines Corporation Authenticating a processing system accessing a resource
CN101827309A (zh) * 2009-03-06 2010-09-08 华为技术有限公司 一种推送消息的发送方法、终端、服务器及系统
CN101959133A (zh) 2009-07-15 2011-01-26 华为技术有限公司 M2m用户设备的操作控制方法、系统和m2m用户设备
CN102111741B (zh) * 2009-12-23 2014-04-30 中兴通讯股份有限公司 计费实现方法及装置
US20110201365A1 (en) * 2010-02-15 2011-08-18 Telefonaktiebolaget L M Ericsson (Publ) M2m group based addressing using cell broadcast service
US20120066396A1 (en) * 2010-09-10 2012-03-15 Samsung Electronics Co. Ltd. Apparatus and method for supporting periodic multicast transmission in machine to machine communication system
CN102136933B (zh) * 2010-09-30 2013-08-28 华为技术有限公司 设备管理方法、中间件及机器通信平台、设备和系统
KR101682956B1 (ko) * 2010-10-14 2016-12-07 삼성전자주식회사 기기 간 통신 시스템에서 페이징된 기기에서의 억세스 오버헤드를 감소하기 위한 방법 및 장치
TWI642290B (zh) * 2011-02-11 2018-11-21 美商ＩｏＴ控股公司 用於管理機器對機器（ｍ２ｍ）實體的ｍ２ｍ伺服器、以及在ｍ２ｍ伺服器中實施的方法
CN102130773B (zh) * 2011-02-25 2012-12-19 华为技术有限公司 群组通信的方法和用于群组通信的装置
WO2013066384A1 (en) * 2011-11-04 2013-05-10 Intel Corporation Techniques for traffic delivery to a group of devices
FI20116299A (fi) * 2011-12-21 2013-06-22 Sensinode Oy Menetelmä, laite ja järjestelmä resurssien osoittamiseksi
US10057173B2 (en) * 2013-05-28 2018-08-21 Convida Wireless, Llc Load balancing in the Internet of things

Also Published As

Publication number Publication date
RU2598582C2 (ru) 2016-09-27
JP2015511417A (ja) 2015-04-16
US9450772B2 (en) 2016-09-20
IN2014CN04375A (es) 2015-09-04
CA2859059C (en) 2016-09-06
EP3094117A1 (en) 2016-11-16
CA2859059A1 (en) 2013-07-11
KR20140095571A (ko) 2014-08-01
EP2782367A1 (en) 2014-09-24
CN103200209B (zh) 2018-05-25
EP2782367A4 (en) 2015-03-25
EP3367709A1 (en) 2018-08-29
EP3094117B1 (en) 2017-12-13
WO2013102346A1 (zh) 2013-07-11
JP5891551B2 (ja) 2016-03-23
CN103200209A (zh) 2013-07-10
KR101571376B1 (ko) 2015-11-24
EP2782367B1 (en) 2016-06-15
US20140369251A1 (en) 2014-12-18
RU2014131902A (ru) 2016-02-20

Similar Documents

Publication Publication Date Title
ES2657805T3 (es) Método, servidor de grupo y dispositivo miembro para acceder a recursos miembro
US10044816B2 (en) Location-based domain name system service discovery
CN106060180B (zh) 一种针对IPv6的基于地理位置和应用信息的寻址方法
US11025585B2 (en) Enhanced content route selection in content delivery networks
US11018976B2 (en) Enhanced infrastructure routing with prefixed network addressing in content delivery networks
CN102014043B (zh) 名址映射系统、数据传输方法及名址映射维护方法
US9825861B2 (en) Packet forwarding method, apparatus, and system
WO2016091009A1 (zh) 一种地址分配、获取方法及装置
CN111866201B (zh) IPv6组播地址的生成方法和装置
US8250189B1 (en) Employing IP version fields to determine data-link layer addresses
CN108600074A (zh) 组播数据报文的转发方法及装置
WO2018019216A1 (zh) Ap接入控制
CN103618801A (zh) 一种p2p资源共享的方法、设备及系统
US20170180311A1 (en) Systems and methods for managing network address information
US20140189082A1 (en) Local Partitioning in a Distributed Communication System
WO2011147351A1 (zh) 生成转发表项、报文转发、地址获取的方法及边缘装置
CN101924698B (zh) 基于ip单播路由的二层域负载均衡方法、系统和设备
CN106027354A (zh) Vpn客户端的回流方法及装置
Fan et al. Address allocation scheme based on local MAC address
US9622029B2 (en) Methods and arrangements in location servers
Ohara et al. Off-Path Caching for File Versioning in Named Data Networking