MX2012010363A

MX2012010363A - Metodo y aparato para soportar comunicaciones de maquina a maquina.

Info

Publication number: MX2012010363A
Application number: MX2012010363A
Authority: MX
Inventors: Ana Lucia Pinheiro; Rocco Digirolamo; Jean-Louis Gauvreau; Paul L Russell Jr; Nicholas J Podias; Michael F Starsinic; Dale N Seed; Chonggang Wang; Guang Lu
Original assignee: Interdigital Patent Holdings
Priority date: 2010-03-09
Filing date: 2011-03-09
Publication date: 2012-11-30
Also published as: US20130188515A1; KR101772412B1; JP2013522965A; CN104935669A; US10404542B2; JP2014241608A; KR20170098986A; EP3032849B1; CN102907068A; JP5589098B2; JP2018074611A; EP2545694A1; JP2016192787A; CN104935669B; AU2011224415B2; EP3032849A1; AU2011224415A1; KR101871642B1; JP5957490B2; KR20130004497A

Abstract

Se describen el método y aparato para soportar comunicaciones de máquina a máquina (M2M) en una arquitectura de red de computadoras jerárquica que incluye una vía de acceso M2M. Una entidad M2M, (tal como un dispositivo M2M, vía de acceso M2M, o entidad de red M2M), podrá llevar a cabo un procedimiento de descubrimiento de capacidad de servicio para descubrir una entidad de capacidad de servicio M2M que pueda proporcionar una capacidad de servicio M2M, y registrarse con la entidad de capacidad de servicio M2M descubierta. La dirección o la identidad de la entidad de capacidad de servicio podrá ser pre-configurada u obtenida del servidor despachador. La entidad M2M puede indicar un identificador de servicio M2M de soporte y recibir una identidad o dirección de la entidad de capacidad de servicio M2M que mapea el identificador de servicio. La vía de acceso podrá advertir a los identificadores de servicio M2M soportados por la vía de acceso, de tal manera que el dispositivo M2M podrá tener acceso a la vía de acceso si existe una sincronización. La dirección de las entidades de capacidad de servicio M2M podrá obtenerse de la red central.

Description

MÉTODO Y APARATO PARA SOPORTAR COMUNICACIONES DE MÁQUINA A MÁQUINA REFERENCIA CRUZADA A LAS SOLICITUDES RELACIONADAS Esta solicitud reclama el beneficio de las solicitudes provisionales de EE.UU. Nos. 61/311,971 presentada el 9 de Marzo de 2010, 61/326,069 presentada el 20 de Abril de 2010, y 61/415,633 presentada el 19 de Noviembre de 2010, los contenidos de las cuales se incorporan por la presente por referencia.

ANTECEDENTES Una comunicación de máquina a máquina (M2M) es una comunicación entre un grupo de dispositivos capaces de transmitir y recibir, de manera autónoma, datos sin intervención humana. El sistema de comunicación M2M incluye dispositivos, (tales como un sensor o medidor), para capturar la información (tal como temperatura, etc.), y retransmitirla sobre una red inalámbrica o con cable. Con una amplia variedad de aplicaciones potenciales, el número de dispositivos M2M permitidos se encuentra en aumento .

El Instituto Europeo de Normas de Telecomunicaciones (ETSI, por sus siglas en inglés) actualmente '¦ se encuentra intentando describir los requisitos del sistema fin a fin para soportar los servicios de comunicación M2M. Como parte de este esfuerzo, ETSI se encuentra describiendo la arquitectura funcional M2 para entregar servicios M2M a las aplicaciones. La principal meta de la arquitectura funcional M2M es presentar el total de las entidades funcionales M2M fin a fin, las relaciones entre estas entidades, asi como también la relación a las Telecomunicaciones y convergencia a Internet de Servicios y Protocolos de Redes Avanzadas, TISPAN y las redes de proyecto de colaboración de tercera generación (3GPP) .

BREVE DESCRIPCIÓN DE LA INVENCIÓN Se describen las modalidades para soportar las comunicaciones M2M en la arquitectura de red de computadoras jerárquica incluyendo una via de acceso M2M. Una entidad M2M, (tal como un dispositivo M2M, via de acceso M2M, o entidad de red M2M) , podrá llevar a cabo un procedimiento de descubrimiento de capacidad de servicio para descubrir una entidad de capacidad de servicio M2M que pueda proporcionar una capacidad de servicio M2 , y registrarse con la entidad de capacidad de servicio M2M descubierta. La dirección o la identidad de la entidad de capacidad de servicio podrán ser pre-conf igurada u obtenidas del servidor despachador. La entidad M2M puede indicar un ident i f i cado r de servicio M2M de soporte y recibir una identidad o dirección de la entidad de capacidad de servicio 2M que mapea el identif icador de servicio. La via de acceso podrá advertir a los identificadores de servicio M2 soportados por la via de acceso, de tal manera que el dispositivo M2M podrá tener acceso a la via de acceso si existe una sincronización. La dirección de las entidades de capacidad de servicio M2M podrá obtenerse de la red central. El dispositivo M2M podrá llevar a cabo un descubrimiento jerárquico de tal manera que las capacidades de servicio puedan distribuirse óptimamente.

La vía de acceso puede incluir capacidades de servicio de paridad de las capacidades de servicio en la red central. La vía de acceso M2M puede incluir al menos una de las funcionalidades relacionadas al descubrimiento de la capacidad de servicio a través de una arquitectura jerárquica, configuración de la capacidad de servicio a través de una arquitectura jerárquica, autorización de aplicación de dispositivo genérico M2M (GMDAE), a s equibi 1 idad , repositorio de aplicación de dispositivo y dirección (RADAR), selección de servicio de comunicación y red (NCSS) , historia y retención de datos (HDR), capacidad de seguridad (SC), autorización de aplicación de red genérica M2M (GMAE) , manejo de via de acceso M2M y dispositivo M2M (MDGM) , capacidad de mediación por compensación (CB), proxy de via de acceso M2M y dispositivo M2M (MDGP), o servicio de ubicación.

BREVE DESCRIPCIÓN DE LAS FIGURAS Un entendimiento más detallado podrá tenerse de la siguiente descripción, dada a manera de ejemplo junto con las figuras acompañantes, en donde: La FIG. 1A es un diagrama de sistema de un sistema de comunicaciones e j empl i ficat ivo en el cú'al podrá implementars una o más modalidades descritas; La FIG. IB es un diagrama de sistema de una unidad de transmisión/recepción inalámbrica (WTRU) e jemplificativa, que podrá utilizarse dentro del sistema de comunicaciones en la FIG. 1A; La FIG. 1C es un diagrama de sistema de una red de acceso a radio e j empli ficativa y una red central e j empl i fi cat iva que podrá utilizarse dentro del sistema de comunicaciones ilustrado en la FIG. 1A; La FIG. 2 muestra una arquitectura funcional M2M global ej empl i f i cativa ; Las FIGS. 3A y 3B muestran las capacidades de servicio M2M jerárquicas ej empli f icat ivas ; Las FIGS. 4 y 5 muestran las capacidades de servicios e j empl i f i ca t iva s en la vi a de acceso M2M y el núcleo 2M; La FIG. 6A es un flujo de llamada ej empl i f i cat ivo para la via de acceso a nivel bajo sin proxy de vía de acceso; La FIG. 6B es un flujo de llamada e j empl i fi cat ivo para la vía de acceso a nivel bajo con proxy de vía de acceso;'1 La FIG. 7A es un flujo de llamada e j empl i fi ca t ivo para la vía de acceso a nivel medio sin proxy de vía de acceso; La FIG. 7B es un flujo de llamada ej emplificativo para la vía de acceso a nivel bajo con proxy de vía de acceso y sin visibilidad; La FIG. 7C es un flujo de llamada e j empl i fi cat ivo para la vía de acceso a nivel bajo con proxy de vía de acceso y visibilidad parcial; La FIG. 8A es un flujo de llamada ej emplificativo para la vía de acceso a nivel alto sin proxy de vía de acceso; La FIG. 8B es un flujo de llamada ej emplificativo para la vía de acceso a nivel alto con proxy de vía de acceso y RADAR y soporte de movilidad; Las FIGS. 9A-9C son flujos de llamada ej emplificativos para soporte de movilidad; La FIG. 10 muestra flujos de nivel alto de los procedimientos operativos llevados a cabo para las comunicaciones 2M; La FIG. 11 es un diagrama de flujo e empl i fi cat ivo de un procedimiento para el descubrimiento de capacidad de servicio en una red local; La FIG. 12 es un diagrama de flujo ej emplif icat ivo de intercambio de capacidades entre las entidades en un sistema que incluye un dispositivo, dos vías de acceso, y dos operadores de red; La FIG. 13 es un flujo ej empli ficativo para registro; La FIG. 14 es un flujo de delegación de capacidad de servicio e empl i fi cativo basado en la clase de aplicación de acuerdo con una modalidad; La FIG. 15 es un flujo de señalización ej emplif icat ivo para la transferencia de capacidad de servicio cuando un dispositivo M2M entra a la cobertura de vía de acceso e inicia el cambio; La FIG. 16 es un flujo de señalización ej empl i f i cat i o para la transferencia de capacidad de servicio cuando un dispositivo M2M entra a la cobertura de vía de acceso y una red inicia el cambio; La FIG. 17 es un flujo de señalización e empl i ficativo para la transferencia de capacidad de servicio cuando un dispositivo M2M sale de la cobertura de vía de acceso en caso de visibilidad completa; La FIG. 18 es un flujo de señalización ej emplificativo para la transferencia de capacidad de servicio cuando un dispositivo M2M sale de la cobertura de vía de acceso en caso de no visibilidad; La FIG. 19 es un flujo de señalización ej emplificativo para la transferencia de capacidad de servicio cuando un dispositivo M2M entra a una nueva cobertura de vía da acceso en caso de visibilidad completa; La FIG. 20 es un flujo de señalización ej empl i fi cat i o para la transferencia de capacidad de servicio cuando un dispositivo M2M entra a una nueva cobertura de vía de acceso en caso de no visibilidad; La FIG. 21 es un flujo de señalización ej emplif icativo para el soporte de movilidad cuando un dispositivo M2M que no tiene capacidad de servicio, ingresa a la cobertura de vía de acceso e inicia el cambio; La FIG. 22 es un flujo de señalización ej emplificativo para' el soporte de movilidad cuando un dispositivo M2M que no tiene capacidad de servicio, ingresa a la cobertura de vía de acceso y una red inicia el cambio; La FIG. 23 es un flujo de señalización ej emplif icat ivo para la transferencia de capacidad de servicio cuando un dispositivo M2M que no tiene capacidad de servicio sale de la cobertura de vía de acceso en caso de visibilidad completa; La FIG. 24 es un flujo de señalización ej empli f icat ivo para la transferencia de capacidad de servicio cuando un dispositivo M2M que no tiene capacidad de servicio sale de la cobertura de via de acceso en caso de no visibilidad; La FIG. 25 es un flujo de señalización ej emplif icativo para la transferencia de capacidad de servicio cuando un dispositivo M2M que no tiene capacidad de servicio, ingresa a una nueva cobertura de via de acceso en caso de visibilidad completa; y La FIG. 26 es un flujo de señalización ej emplif icativo para la transferencia de capacidad de servicio cuando un dispositivo M2M que no tiene capacidad de ser icio, ingresa a una nueva cobertura de vía de acceso en caso de no visibilidad.

DESCRIPCIÓN DETALLADA La FIG. 1A es un diagrama de un sistema de comunicaciones 100 e j empl i fi cat ivo en el cual podrá implement arse una o más modalidades descritas. El sistema de comunicaciones 100 puede ser un sistema de múltiples accesos que proporcione contenido, tal como voz, datos, video, mensajería, transmisión, etc. a múltiples usuarios inalámbricos. El sistema de comunicaciones 100 puede autorizar a múltiples usuarios inalámbricos a tener acceso a tal contenido, a través de la participación de los recursos de sistema, incluyendo ancho de banda inalámbrica. Por ejemplo, los sistemas de comunicaciones 100 pueden emplear uno o más métodos de acceso a canal, tales como acceso múltiple por división de código (CDMA), acceso múltiple por división de tiempo (TDMA), acceso múltiple por división de frecuencia (FDMA), FMDA ortogonal (OFDMA) , FDMA de único portador ( SC- FDMA ) , y lo similar.

Según se muestra en la FIG. 1A, el sistema de comunicaciones 100 puede incluir unidades de t ransmi s i ón / re cepc ión inalámbricas (WTRUs) 102a, 102b, 102c, 102d, una red de acceso a radio (RAN) 104, una red central 106, una red telefónica pública conmutada (PSTN) 108, el Internet 110, y otras redes 112, a pesar de que se apreciará que las modalidades descritas contemplan cualquier número de WTRUs, estaciones base, redes, y/o elementos de red. Cada una de las WTRUs 102a, 102b, 102c, 102d podrán ser de cualquier tipo de dispositivo configurado para operar y/o comunicarse en un ambiente inalámbrico. A manera de ejemplo, las WTRUs 102a, 102b, 102c, 102d pueden configurarse para transmitir y/o recibir señales inalámbricas y pueden incluir equipo de usuario (UE), una estación móvil, una unidad suscriptora fija o móvil, un paginador, un teléfono celular, un asistente digital personal (PDA), un teléfono inteligente, una laptop, una netbook, una computadora personal, un sensor inalámbrico, electrónicos para consumidores, y lo similar.

Los sistemas de comunicaciones 100 también pueden incluir una estación base 114a y una estación base 114b. Cada una de las estaciones base 114a, 114b puede ser cualquier tipo de dispositivo configurado para interfase de manera inalámbrica con al menos una de las WTRUs 102a, 102b, 102c, 102d para facilitar el acceso a una o más redes de comunicación, tales como la red central 106, Internet 110, y/o las redes 112. A manera de ejemplo, las estaciones base 114a, 114b pueden ser una estación transceptora base (BTS), un Nodo B, un eNodo B, un Nodo B Local, un eNodo B Local, un controlador de sitio, un punto de acceso (AP) , un router inalámbrico, y lo similar. Aunque las estaciones base 114a, 114b se representan cada una como un elemento único, se apreciará que las estaciones base 114a, 114b pueden incluir cualquier número de estaciones base y/o elementos de red interconectados .

La estación base 114a puede ser parte de la RAN 104, que también puede incluir otras estaciones base y/o elementos de red (no mostrados), tales como un controlador de estación base (BSC), un controlador de red por radio (RNC), nodos de retransmisión, etc. La estación base 114a y/o la estación base 114b pueden configurarse para transmitir y/o recibir señales inalámbricas dentro de una región geográfica particular, que puede referirse como una celda {no mostrada) . La celda puede dividirse además en sectores de celda. Por ejemplo, la celda asociada con la estación base 114a puede dividirse en tres sectores. De esta manera, en una modalidad, la estación base 114a puede incluir tres transceptores, es decir, una para cada sector de la celda. En otra modalidad, la estación base 114a puede emplear tecnología múltiples entradas múltiples salidas (MIMO) y, por lo tanto, puede utilizar múltiples transceptores para cada sector de la celda .

Las estaciones base 114a, 114b pueden comunicarse con una o más de las WTRUs 102a, 102b, 102c, 102d sobre una interfase aérea 116, que puede ser cualquier enlace de comunicación inalámbrica adecuado (por ejemplo, radiofrecuencia (RF), microonda, infrarroja (IR) , ultravioleta (UV) , luz visible, etc. ) . La interfase aérea 116 puede establecerse utilizando cualquier tecnología de acceso por radio adecuada ( RA ) .

Más específicamente, como se observa arriba, el sistema de comunicaciones 100 puede ser un sistema de acceso múltiple y puede emplear uno o más esquemas de acceso al canal, tales como CDMA, T DMA, FDMA, OFDMA, SC-FDMA, y lo similar. Por ejemplo, la estación base 114a en la RAN 104 y las WTRUs 102a, 102b, 102c pueden implementar una tecnología por radio tal como Acceso por Radio Terrestre (UTRA) del Sistema de Telecomunicaciones Móvil Universal (UMTS), que puede establecer la interfase aérea 116 utilizando CDMA de banda ancha (WCDMA) . CDMA puede incluir protocolos de comunicación tales como Acceso a Paquete a Alta Velocidad (HSPA) y/o HSPA Evolucionado (HSPA+) . HSPA puede incluir Acceso a Paquete de Enlace Descendente a Alta Velocidad (HSDPA) y/o Acceso a Paquete de Enlace Ascendente a Alta Velocidad (HSUPA) .

En otra modalidad, la estación base 114a y las WTRUs 102a, 102b, 102c pueden implementar una tecnología por radio tal como Acceso por Radio Terrestre UMTS Evolucionado (E-UTRA), que puede establecer la interfase aérea 116 utilizando Evolución a Largo Plazo (LTE) y/o LTE-Avanzado (LTE-A) .

En otras modalidades, la estación base 114a y las WTRUs 102a, 102b, 102c pueden implementar tecnologías por radio tal como IEEE 802.16 (es decir, Interoperabilidad Mundial para Acceso por Microonda (WiMAX) ) , CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Sistema Global para Comunicaciones Móviles (GSM), Velocidades de Datos Mejoradas para Evolución GSM (EDGE), GSM EDGE (GERAN), y lo similar.

La estación base 114b en la FIG. 1A puede ser un router inalámbrico, Nodo B Local, eNodo B Local, o punto de acceso, por ejemplo, y puede utilizar cualquier RAT adecuada para facilitar la conectividad inalámbrica en un área localizada, tal como un lugar de negocios, un hogar, un vehículo, un campus, y lo similar. En una modalidad, la estación base 114b y las WTRUs 102c, 102d pueden implementar una tecnología por radio tal como IEEE 802.11 para establecer una red de área local inalámbrica (WLAN) . En otra modalidad, la estación base 114b 'y las WTRUs 102c, 102d pueden implementar una tecnología por radio tal como IEEE 802.15 para establecer una red de área personal inalámbrica (WPAN) . En todavía otra modalidad, la estación base 114b y las WTRUs 102c, 102d pueden utilizar una RAT de base celular (por ejemplo, WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) para establecer una picocelda o femtocelda. Como se muestra en la FIG. 1A, la estación base 114b puede tener una conexión directa a Internet 110. De esta manera, la estación base 114b no puede requerirse para acceso a Internet 110 a través de la red central 106.

La RAN 104 puede estar en comunicación con la red central 106, que puede ser cualquier tipo de red configurada para proporcionar servicios de voz, datos, aplicaciones, y/o voz sobre protocolo de internet (VoIP) a una o más de las WTRUs 102a, 102b, 102c, 102d. Por ejemplo, la red central 106 puede proporcionar control de llamada, servicios de facturación, servicios a base de ubicación móvil, llamada por pre-pago, conectividad a Internet, distribución de video, etc., y/o realizar funciones de seguridad de alto nivel, tal como autent i f icación del usuario. A pesar de que no se muestra en la FIG. 1A, se apreciará que la RAN 104 y/o la red central 106 puede estar en comunicación directa o indirecta con otras RANs que emplean la misma RAT que la RAN 104 o una RAT diferente. Por ejemplo, además de conectarse a la RAN 104, que puede estar utilizando una tecnología por radio E-UTRA, la red central 106 también puede estar en comunicación con otra RAN (no mostrada) empleando una tecnología por radio GSM.

La red central 106 también puede servir como una vía de acceso para las WTRUs 102a, 102b, 102c, 102d para acceder a la PSTN 108, Internet 110, y/u otras redes 112. PSTN 108 puede incluir redes telefónicas conmutadas por circuito que proporcionan servicio telefónico tradicional (POTS) . Internet 110 puede incluir un sistema global de dispositivos y redes computacionales interconectados que utilizan protocolos de comunicación comunes, tales como el protocolo de control de transmisión (TCP), protocolo de datagrama de usuario (ÜDP) y el protocolo de internet (IP) en el juego de protocolo de internet TCP IP.'· Las redes 112 pueden incluir redes de comunicaciones alámbricas o inalámbricas propietarias y/u operadas por otros proveedores del servicio. Por ejemplo, las redes 112 pueden incluir otra red central conectada a una o más RANs, que pueden emplear la misma RAT que la RAN 104 o una RAT diferente.

Algunas o todas las WTRUs 102a, 102b, 102c, 102d en el sistema de comunicaciones 100 puede incluir capacidades de multi-modo, es decir, las WTRUs 102a, 102b, 102c, 102d pueden incluir múltiples transceptores para comunicarse con diferentes redes inalámbricas sobre diferentes enlaces inalámbricos. Por ejemplo, la WTRU 102c mostrada en la Figura 1A puede configurarse para comunicarse con la estación base 114a, que puede emplear una tecnología por radio de base celular, y con la estación base 114b, que puede emplear una tecnología por radio IEEE 802.

La Fig. IB es un diagrama del sistema de un ejemplo de WTRU 102. Como se muestra en la FIG. IB, la WTRU 102 puede incluir un procesador 118, un transceptor 120, un elemento de t ransmi s i ón / re cepc i ón 122, un a 1 tavo z /mi eró fono 124, un teclado 126, una pantalla/tapete táctil 128, memoria no removible 106, memoria removible 132, una fuente de energía 134, un conjunto de chips del sistema de pos icionamiento global (GPS) 136, y otros periféricos 138. Se apreciará que la WTRU 102 puede incluir cualquier subcombinación de los elementos anteriores mientras permanece consistente con una modalidad.

El procesador 118 puede ser un procesador de propósito general, un procesador de propósito especial, un procesador convencional, un procesador de señal digital (DSP), una pluralidad de microprocesadores, uno o más microprocesadores en asociación con un núcleo DSP, un controlador, un microcont rolador , Circuitos Integrados de Aplicación Específica (ASICs), dispositivos de entrada programable por campo (FPGAs), cualquier otro tipo de circuito integrado (IC), una máquina de estado, y lo similar. El procesador 118 puede realizar codificación de señal, procesamiento de datos, control de energía, procesamiento de entrada/salida, y/o cualquier otra funcionalidad que permite que la TRU 102 opere en un ambiente inalámbrico. El procesador 118 puede acoplarse al transceptor 120, que puede acoplarse al elemento de transmisión/recepción 122. Mientras que la FIG. IB representa el procesador 118 y el transceptor 120 como componentes separados, se apreciará que el procesador 118 y el transceptor 120 pueden integrarse juntos en un chip o paquete electrónico.

El elemento de transmisión/recepción 122 puede configurarse para transmitir señales a, o recibir señales de, una estación base (por ejemplo, la estación base 114a) sobre la interfase aérea 116. Por ejemplo, en una modalidad, el elemento de transmisión/recepción 122 puede ser una antena configurada para transmitir y/o recibir señales RF. En otra modalidad, el elemento de transmisión/recepción 122 puede ser un emi sor /detector configurado para transmitir y/o recibir IR, UV, o señales de luz visibles, por ejemplo. En todavía otra modalidad, el elemento de transmisión/recepción 122 puede configurarse para transmitir y recibir tanto RF como señales de luz. Se apreciará que el elemento de transmisión/recepción 122 puede configurarse para transmitir y/o recibir cualquier combinación de señales inalámbricas.

Además, a pesar de que el elemento de transmisión/recepción 122 se representa en la FIG. IB como un elemento único, la TRU 102 puede incluir cualquier número de elementos de transmisión/recepción 122. Más específicamente, la WTRU 102 puede emplear tecnología MIMO. De esta manera, en una modalidad, la WTRU 102 puede incluir dos o más elementos de t ransmi s i ón / re cepc i ón 122 (por ejemplo, múltiples antenas) para transmitir y recibir señales inalámbricas sobre la interfase aérea 116.

El transceptor 120 puede configurarse para modular las señales que están por transmitirse por el elemento de transmisión/recepción 122 y para desmodular las señales que se reciben por el elemento de transmisión/recepción 122. Como se observa arriba, la WTRU 102 puede tener capacidades de mult i-modo . De esta manera, el transceptor 120 puede incluir múltiples t ransceptores para permitir que la WTRU 102 se comunique a través de múltiples RATs, tales como UTRA e IEEE 802.11, por ejemplo.

El procesador 118 de la WTRU 102 puede acoplarse a, y puede recibir datos de entrada del usuario del, altavoz /micrófono 124, teclado 126, y/o la pantal 1 a / tapete táctil 128 (por ejemplo, una unidad de vi sua 1 i z ac i ón con pantalla de cristal líquido (LCD) o unidad de visualización de diodo emisor de luz orgánico (OLED) ) . El procesador 118 también puede emitir datos del usuario al altavoz/micrófono 124, el teclado 126, y/o la pantalla/ tapete táctil 128. Además, el procesador 118 puede tener acceso a la información de, y almacenar datos en, cualquier tipo de memoria adecuada, tal como la memoria no removible 106 y/o la memoria removible 132. La memoria no removible 106 puede incluir memoria de acceso aleatorio (RAM), memoria de sólo lectura (ROM), un disco duro, o cualquier otro tipo de dispositivo de almacenamiento de memoria. La memoria removible 132 puede incluir una tarjeta del módulo de identidad del suscriptor (SIM), una tarjeta de memoria, una tarjeta de memoria digital; segura (SD), y lo similar. En otras modalidades, el procesador 118 puede tener acceso a información de, y almacenar datos en, la memoria que no se ubica físicamente en la WTRU 102, tal como en un servidor o una computadora para el hogar (no mostrada) .

El procesador 118 puede recibir energía de la fuente de energía 134, y puede configurarse para distribuir y/o controlar la energía a los otros componentes en la WTRU 102. La fuente de energía 134 puede ser cualquier dispositivo adecuado para energizar la WTRU 102. Por ejemplo, la fuente de energía 134 puede incluir una o más baterías de celda secas (por ejemplo, níquel-cadmio (NiCd), níquel-zinc (NiZn) , hidruro de metal de níquel (NiMH), litio-ion (Li-ion), etc.), celdas solares, celdas de combustible, y lo similar.

El procesador 118 también puede acoplarse al conjunto de chips GPS 136, que puede configurarse para proporcionar la información de ubicación (por ejemplo, longitud y latitud) considerando la ubicación actual de la WTRU 102. Además de, o en lugar de, la información del conjunto de chips GPS 136, la WTRU 102 puede recibir información de ubicación sobre la inferíase aérea 116 de una estación base (por ejemplo, estaciones base 114a, 114b) y/o determinar su ubicación en base a la t empori zación de las señales recibiéndose de dos o más estaciones base cercanas. Se apreciará que la WTRU 102 puede adquirir información de ubicación por medio de cualquier método de determinación de la ubicación adecuada mientras permanece consistente con una modalidad .

El procesador 118 puede acoplarse además a otros periféricos 138, que pueden incluir uno o más módulos de software y/o hardware que proporcionan características adicionales, funcionalidad y/o conectividad inalámbrica o alámbrica. Por ejemplo, los periféricos 138 pueden incluir un acelerómetro, un e-compás, un transceptor satelital, una cámara digital (para fotografías o video), un puerto de bus serial universal (USB), un dispositivo de vibración, un transceptor de televisión, unos audífonos manos libres, un módulo Bluetooth®, una unidad de radio de frecuencia modulada (FM), un reproductor de música 'digital, un reproductor1 de medios, un módulo reproductor de juegos de video, un explorador de Internet, y lo similar.

La FIG. 1C es un diagrama del sistema de la RAN 104 y la red central 106 de acuerdo a una modalidad. Como se observa arriba, la RAN 104 puede emplear una tecnología por radio UTRA para comunicarse con las TRUs 102a, 102b, 102c por la interfase aérea 116. La RAN 104 también puede estar en comunicación con la red central 106. Como se muestra en la FIG. 1C, la RAN 104 puede incluir Nodos-B 140a, 140b, 140c, los cuales pueden incluir uno o más transceptores para comunicarse con las WTRUs 102a, 102b, 102c sobre la interfase aérea 116. Los Nodos-B 140a, 140b, 140c cada uno puede asociarse con una celda particular (no mostrada) dentro de la RAN 104. La RAN 104 también puede incluir RNCs 142a, 142b. Se apreciará que la RAN 104 puede incluir cualquier número de Nodos-B y RNCs mientras permanece consistente con una modalidad.

Como se muestra en la FIG. 1C, los Nodos-B 140a, 140b pueden estar en comunicación con el RNC 142a. Adicionalmente, el Nodo-B 140c puéde estar en comunicación con el RNC 142b. Los Nodos-B 140a, 140b, 140c pueden comunicarse con los RNCs respectivos 142a, 142b a través de una interfase Iub. Los RNCs 142a, 142b pueden estar en comunicación con otra por medio de una interfase Iur. Cada uno de los RNCs 142a, 142b puede configurarse para controlar los Nodos-B respectivos 140a, 140b, 140c a los cuales se conecta. Además, cada uno de los RNCs 142a, 142b puede configurarse para llevar a cabo o soportar otra funcionalidad, tal como control de energía de ciclo exterior, control de carga, control de admisión, programación de paquetes, control de transferencia, macrodiversidad, funciones de seguridad, cifrado de datos, y lo similar.

La red central 106 mostrada en la FIG. 1C puede incluir una via de acceso de medios (MGW) 144, un centro de conmutación móvil (MSC) 146, un nodo de soporte GPRS servidor (SGSN) 148, y/o un nodo de soporte GPRS de vía de acceso (GGSN) 150. Mientras cada uno de los elementos anteriores se representa como parte de la red central 106, se apreciará que cualquiera de estos elementos puede ser propiedad de y/u operarse por una entidad diferente al operador de la red central.

El RNC 142a en la RAN 104 puede conectarse al MSC 146 en la red central 106 a través de una interfase IuCS. El MSC 146 puede conectarse a la MGW 144. El MSC 146 y la MGW 144 pueden proporcionar las WTRUs 102a, 102b, 102c con acceso a las redes conmutadas por circuito, tal como la PSTN 108, para facilitar las comunicaciones entre las WTRUs 102a, 102b, 102c y dispositivos de comunicaciones de linea terrestre tradicionales.

El RNC 142a en la RAN 104 también puede conectarse al SGSN 148 en la red central 106 a través de una interfase IuPS. El SGSN 148 puede conectarse al GGSN 150. El SGSN 148 y la GGSN 150 pueden proporcionar las WTRUs 102a, 102b, 102c con acceso a redes conmutadas por paquete, tales como Internet 110, para facilitar comunicaciones entre y las WTRUs 102a, 102b, 102c y dispositivos habilitados por IP .

Como se observa arriba, la red central 106 también puede conectarse a las redes 112, que pueden incluir otras redes alámbricas o inalámbricas que son propiedad de- y/o se operan por otros proveedores del servicio.

Deberá señalarse que las modalidades descritas en la presente, podrán implementarse en cualquier tipo de sistemas de comunicación inalámbrica incluyendo, pero no limitándose a, WCDMA, LTE, LTE-Avan z ado , cdma2000, WiMAX, y lo similar. Deberá señalarse que las modalidades descritas en la presente, podrán implementarse solas o en cualquier combinación.

La FIG. 2 muestra una arquitectura funcional M2M global e j empl i fi cat iva . El sistema M2M incluye un dominio de dispositivo 200 y un dominio de aplicaciones y red 250. El dominio de dispositivo 2M 200 comprende dispositivo (s) M2M 212, red (es) de área M2M 215, y vía (s) de acceso M2 (GWs) 220. La red de área M2M 215 es una red de dispositivos para comunicaciones M2M (por ejemplo, ZigBee, 61owPAN, etc.) . La red de área M2M 215 podrá referirse como una red capilar. Una red local, tal como una red de área local (LAN) o red de área personal (PAN), etc., puede formar la red de área M2 . Un dispositivo M2M 210 ejecuta aplicaciones 2M utilizando capacidades de servicio M2M y funciones de dominio de red. Los dispositivos M2M 210 pueden conectarse al núcleo M2M ya sea directamente o por medio de la vía de acceso M2M 220. La red de área M2M 215 proporciona conectividad entre los dispositivos M2M 210 y la vía de acceso M2M 220.

El dominio de aplicación y red 250 comprende una red de acceso 252, una red de transporte 254, y un núcleo M2 260. La red de acceso 252 se refiere a la parte del dominio de aplicación y red que proporciona los dispositivos M2M 210 y las vías de acceso 220 para conectarse a las capacidades de servicio de núcleo 2 . La red de acceso 252 permite al dominio de dispositivo M2M comunicarse con la red central 262. Los ejemplos de las redes de acceso 252 incluyen línea suscriptora x-digital (xDSL) , red de acceso a radio GPRS EDGE (GERAN), red de acceso a radio terrestre UMTS (UTRAN) , UTRAN evolucionado, red de área local inalámbrica ( LAN), WiMax, o lo similar. La red de transporte 254 permite el transporte de datos dentro del dominio de aplicación y red 250. El núcleo M2M 260 comprende una red central 262 y las capacidades de; servicio M2M 264. La red central 262 proporciona conectividad IP, o lo similar. Las capacidades de servicio 264 proporcionan funciones M2M que son para ser compartidas por diferentes aplicaciones .

Las aplicaciones M2M ejecutan la lógica de servicio y utilizan capacidades de servicio M2M accesibles por medio de una interfase abierta. Las aplicaciones M2M podrán ser aplicaciones basadas en servidor o aplicaciones basadas en cliente. Las aplicaciones basadas en servidor se refieren a las aplicaciones que se comunican localmente con y/o controlan los dispositivos M2M en la (s) red (es) de área M2M localmente conectada (s) . Las aplicaciones basadas en cliente se refieren a las aplicaciones que responden a las solicitudes de aplicación de red que vienen de la red central M2M.

El sistema M2M tiene funciones de manejo M2M que comprenden las funciones requeridas para manejar la red de acceso 252, red de transporte 254, y red central 262, tal como provisión, supervisión, manejo de averias, etc. Las funciones de manejo M2M comprenden las funciones requeridas para manejar funcionalidades genéricas de aplicaciones M2M y capacidades de servicio M2M en el dominio de aplicación y red 250. El manejo de los dispositivos M2M 210 y vías de acceso 220 puede utilizar capacidades de servicio 2M.

La red central 262 , la red de acceso 252, la via de acceso M2M 220 , y los dispositivos M2M 210 tienen capacidades de servicio M2M. Las capacidades de servicio M2M (o "capacidades de servicio") es una agrupación de funciones que autorizan la comunicación fin a fin entre las aplicaciones. Las capacidades de servicio proporcionan funciones que son para ser compartidas por diferentes aplicaciones. Las capacidades de servicio podrán utilizar funcionalidades de red central a través de un grupo de interfases expuestas (por ejemplo, interfases convencionales especificadas por 3GPP, 3GPP2, ETSI TISPAN, etc.) . Las capacidades de servicio pueden invocar otras capacidades de servicio. Las capacidades de servicio podrán estar en interfase hacia una o diversas redes centrales.

La vía de acceso M2M 220 proporciona una conexión entre la (s) red (es) de área M2M 215 y la aplicación de red M2M y/o capacidades de servicio. La vía de acceso M2M 220 tiene acceso a la red central M2M 262 por medio de la red de acceso 2M 252 y al (a los) coordinador (es) o dispositivo (s) de red M2M de la (s) red (es) de área M2M 215. El coordinador de red M2M se refiere a una entidad en la red de área 2M 215 que proporciona control de estrato inferior y el manejo de la red de área M2M 215. La interfase a la red central M2M 262 y la red de área M2M 215 pueden ser un enlace inalámbrico o con cable. Cuando una via de acceso M2M 220 está en interfase con múltiples redes de área M2M, la via de acceso M2M 220 puede permitirse para la comunicación entre las redes de área M2M 215 sin requerir acceso a la red de acceso M2 252.

La via de acceso 220 puede ser un dispositivo de via de acceso M2M autónomo que incluye una interfase al (a los) coordinador (es) de red M2M y el dominio de aplicaciones y red M2M. Alternativamente, la vía de acceso M2M 220 puede ser una vía de acceso M2M fusionada + dispositivo de coordinador de red de área M2M. De manera alternativa, la vía de acceso M2M 220 puede ser una entidad de software en una vía de acceso local centralizada o convergida. Las modalidades descritas en la presente pueden aplicarse sin considerar la implementación específica de la vía de acceso M2M 220.

Los dispositivos M2M 210 pueden comunicarse al dominio de aplicación y red 250 directamente por medio de la red de acceso 252 o a través de la vía de acceso M2M 220. Los dispositivos M2M 210 pueden llevar a cabo los procedimientos tales como el registro, autentificacion, autorización, manejo y provisión, etc. con el dominio de aplicación y red 250. El dispositivo M2M 210 puede tener otros dispositivos conectados a el que se encuentran ocultos del dominio de aplicación y red 250. Alternativamente, los dispositivos 2M 210 podrán conectarse al dominio de aplicación y red 250 por medio de la vía de acceso M2M 220 por medio de la red de área M2M 215, y la vía de acceso M2M 220 puede actuar como un proxy para el dominio de aplicación y red M2M 25? hacia los dispositivos1 M2M 210 que se conectan a ella. La vía de acceso M2M 220 puede llevar a cabo procedimientos tales como autentificación, autorización, registro, manejo y provisión de los dispositivos M2M 210 conectados a ella, y también puede ejecutar aplicaciones a nombre del dominio de aplicación y red M2M 250. La vía de acceso 2M 220 puede decidir sobre las solicitudes de estrato de servicio de ruteo que se originan de las aplicaciones sobre los dispositivos M2M 210 localmente o al dominio de aplicación y red 2M 250. Los dispositivos M2M 210 que se conectan a la vía de acceso 2M 220 pueden o no pueden ser direccionables por el dominio de aplicación y red M2M 250.

Las FIGS. 3A y 3B muestran capacidades de servicio M2M jerárquica. En las FIGS. 3A y 3B, NA se mantiene para la aplicación de red, GA se mantiene para la aplicación de vía de acceso, DA se mantiene para la aplicación de dispositivo, y SC se mantiene para la capacidad de servicio. Las vías de acceso M2M 220 pueden emplearse para la optimización de sistema, a medida que residen entre las aplicaciones de red y un número de dispositivos M2 conectados a través de la red de área M2M y enlazados por una via de acceso 2M común, según se muestra en la FIG. 3A. Esta relación podrá extenderse al remplazar uno de los dispositivos M2M conectados con otra via de acceso que tiene su propio grupo de dispositivos M2M enlazados y conectados, dando como resultado una arquitectura de via de acceso jerárquica, según se muestra en la FIG. 3B.

De acuerdo con una modalidad, la via de acceso 2M 220 puede tener una o más de las funcionalidades relacionadas al descubrimiento de la capacidad de servicio a través de una arquitectura jerárquica, configuración de capacidad de servicio a través de una arquitectura jerárquica, autorización de aplicación de dispositivo genérico M2M (GMDAE), as equibi 1 i dad , repositorio de aplicación de dispositivo y dirección (RADAR), selección de servicio de comunicación y red (NCSS), historia y retención de datos (HDR), capacidad de seguridad (SC), autorización de aplicación de red genérica M2M ( GMAE ) , manejo de vía de acceso M2M y dispositivo M2M (MDGM), capacidad de mediación por compensación (CB>, proxy de via de acceso M2 y dispositivo M2M ( DGP), servicio de ubicación, o lo similar. Estas capacidades de servicio residen en la via de acceso M2 y podrán implement ar se como llamadas de servicio de la via de acceso M2M y la (s) aplicación (es) de dispositivo.

Las FIGS. 4 y 5 muestran las capacidades de servicio ej emplificativas en la via de acceso M2M 220 y el núcleo M2M 260. Las capacidades de servicio son una agrupación de funciones que autorizan la comunicación fin a fin entre las aplicaciones. Las capacidades de servicio proporcionan funciones que son para ser compartidas por diferentes aplicaciones. Un estrato de capacidad de servicio (SCL) es un nombre genérico para el estrato responsable por las funciones de capacidad de servicio. La via de acceso M2 220 comprende paridades de diversas capacidades de servicio que existen en el dominio de aplicación y red. Las capacidades de servicio llevan a cabo funciones para facilitar el manejo, las comunicaciones, y la seguridad por si misma y los dispositivos M2M al que le sirve, o lo similar. Debería señalarse que la configuración mostrada en las FIGS. 4 y 5 es un ejemplo, y las interfases internas son de implement ación específica, y la agrupación de las funciones en las capacidades de servicio es arbitraria. Por ejemplo, las capacidades de servicio se encuentran comunicándose entre sí por medio de GMAE en la FIG. 4, pero podrá proporcionarse una función de ruteo interna y las capacidades de servicio pueden tener acceso entre sí por medio de la función de ruteo interno, según se muestra en la FIG. 5.

Las funcionalidades de que las capacidades de servicio se traen a la vía de acceso M2M, se explican de aquí en adelante. Deberá entenderse que la asignación de funcionalidades a una capacidad de servicio se permite para la agrupación de funciones similares pero este mapeo no es un requisito estricto. Algunas funciones podrán moverse a capacidades de servicio alternativas, y a pesar de que algunas funciones se encuentran enlazadas, podrán utilizarse en cualquier combinación .

La capacidad GMNAE en la vía de acceso M2M podrá exponer funcionalidades implement adas en las capacidades de servicio de vía de acceso. La capacidad GMNAE puede llevar a cabo el ruteo entre la aplicación de vía de acceso M2M y las capacidades. La capacidad GMNAE puede responder a las solicitudes de registro de carga de la capacidad GMNAE en el dominio de aplicación y red. La capacidad GMNAE puede permitir que una aplicación M2M se registre a las capacidades de servicio de vía de acceso M2M. La capacidad GMNAE puede llevar a cabo la autentificación y la autorización de las aplicaciones M2M antes de permitirles que tengan acceso a un grupo especifico de capacidades de via de acceso M2M. El grupo de capacidades a la que se autoriza a la aplicación M2M para tener acceso, asume un acuerdo previo entre el proveedor de aplicación M2M y el proveedor que ejecuta las capacidades de servicio. La capacidad GMNAE puede revisar si una solicitud especifica es válida antes de rutearla a otras capacidades. Si una solicitud o es válida, se reporta un error a la aplicación M2M.

La capacidad MGDM en la vía de acceso M2M puede actuar como un cliente de manejo de via de acceso M2M y llevar a cabo el manejo de configuración (CM), manejo de rendimiento (PM), manejo de averias (FM), funciones de actualización de software y firmware de la via de acceso M2M, etc. La capacidad MGDM puede actuar como un proxy de manejo de via de acceso M2M para llevar a cabo las funciones de manejo y permitir al servidor M2M suscribirse a las notificaciones que pudieran activarse por diversos eventos en la via de acceso M2M y dentro de la red capilar. Un servidor M2M se refiere a una entidad en el dominio de aplicación y red, que es capaz de alojar las capacidades de servicio M2M.

La capacidad MGDM puede tener la habilidad de valorar la calidad de servicio (QoS) y la solicitud de tiempo de espera en la red de área M2M. La capacidad MGDM puede tener la habilidad de valorar y manejar las oportunidades de agregación de ancho de banda potencial dentro de la red de área M2M. Por ejemplo, la vía de acceso M2M puede dividir o cargar el tráfico de datos de balance que tiene como objetivo un dispositivo específico al rutear los ; paquetes de datos a ¡través de múltiples rutas dentro la red capilar o sobre las múltiples tecnologías de acceso a radio (RATs), con la condición de que los dispositivos soporten la capacidad de múltiple RAT . La capacidad MGDM puede tener manejo de interferencia y espectro dentro de la red capilar, (por ejemplo, la habilidad de emitir solicitudes para utilizar espectro, y la habilidad para hacer reportes de medición a cierta entidad central), etc.) La capacidad de seguridad en la vía de acceso M2M puede manejar las claves de seguridad por medio de inicialización de claves de seguridad, (por ejemplo, claves de seguridad pre-compart idas , certificados, etc.), en el dispositivo M2M para autentif icación . La capacidad de seguridad en la vía de acceso M2M puede llevar a cabo la autent i f icación antes del establecimiento de sesión si se requiere por la aplicación. La capacidad de seguridad en la vía de acceso 2M puede llevar a cabo las funciones relacionadas a la seguridad de sesión tal como cifrado de tráfico y protección de integridad para mensajes de señalización.

La capacidad GMDAE en la vía de acceso M2M puede retransmitir mensajes recibidos de la capacidad GMDAE en el proveedor de servicios hacia los dispositivos M2M, retransmitir mensajes recibidos de los dispositivos M2M a la capacidad GMDAE en el proveedor- de servicios, y retransmitir los mensajes direccionados a las aplicaciones M2M u otras capacidades en la vía de acceso M2M. La capacidad GMDAE puede proporcionar la int ra-t ransmisión de red de área M2M de un mensaje enviado por un dispositivo M2M a otro dispositivo M2M conectado a la misma vía de acceso M2M. La capacidad GMDAE puede manejar la resolución de nombre para los mensajes enviados de la capacidad de mensajería de unidifusión (UM) en el proveedor de servicio hacia un dispositivo M2M. La capacidad GMDAE puede reportar errores, (por ejemplo, el identificador del recipiente no existe, la clase de servicio solicitada no se soporta por el recipiente, o lo similar), la capacidad GMDAE puede entregar mensajes utilizando una clase de servicio de averías o una solicitada.

La capacidad GMDAE puede almacenar y renviar la capacidad de proxy de tal manera que los datos que se destinan para un dispositivo en modo latente, puedan almacenarse por la vía de acceso M2M, y renviarse una vez que el dispositivo se despierta. La capacidad GMDAE puede comportarse como un proxy de comunicación grupal (muí t idi fus ión de soporte, cualquier difusión, unidifusión) . Por ejemplo, un paquete de datos que tiene como objetivo múltiples dispositivos bajo el control de la vía de acceso M2M, podrá recibirse una vez por la vía de acceso M2M y multidifundirse a múltiples dispositivos en una manera eficiente. Esto podrá depender de las capacidades avanzadas de transmisión que consideren el ciclo de deber de los dispositivos en la red capilar. La capacidad GMDAE puede responder a las solicitudes para inspeccionar el tráfico generador por un dispositivo M2M particular y verificar que esté sincronizándose a un patrón de tráfico dado. La capacidad de GMDAE puede tener funcionalidad de antememoria para permitir que la vía de acceso M2M de servicio a las solicitudes entrantes del núcleo M2M utilizando versiones con antememoria de la información del dispositivo M2M (por ejemplo, para el caso en donde un dispositivo puede estar en modo latente) . La capacidad GMDAE puede tener funcionalidad de programación para permitir que el dispositivo M2M programe, de manera inteligente, mensajes de los dispositivos M2M al núcleo M2M con base a los criterios tales como la clase de servicio del dispositivo. La capacidad GMDAE puede tener la funcionalidad de concatenación para permitir que la vía de acceso M2M consolide mensajes de dispositivo M2M más pequeños en mensajes más grandes que sean enviados al núcleo M2M. La capacidad GMDAE puede tener la funcionalidad de traducción de protocolo para permitir que la vía de acceso M2M traduzca entre los protocolos utilizados en la red de área y los protocolos utilizados en la red de acceso. Por ejemplo, la GMDAE puede traducir del protocolo de transporte de hipertexto (HTTP) al protocolo de aplicación restringido (CoAP) en el estrato de aplicación.

La vía de acceso M2M puede tener una capacidad RA DAR de proxy. La capacidad RA DAR de vía de acceso puede proporcionar un mapeo entre el nombre de un dispositivo M2M y una o más de las direcciones de red, proporcionar un mapeo entre el nombre de un grupo de dispositivos M2M y una o más direcciones de red para cada dispositivo M2M dentro del grupo, proporcionar estado de asequibilidad de un dispositivo M2M, proporcionar la siguiente hora de despertador planeada y la duración del despertador, si se encuentra disponible, utilizar un mecanismo para tener la tabla de mapeo actualizada cuando un dispositivo M2M llegue a ser asequible, proporcionar la notificación sobre eventos relacionados a los dispositivos M2M (por ejemplo, cuando un dispositivo M2M específico llega a ser asequible, ocurren los cambios sobre un grupo de información de registro de aplicaciones M2M, etc.), y permitir el crear, suprimir y enlistar un grupo de dispositivos M2M. ' La RA DAR de vía de acceso puede mantener el repositorio de la aplicación de dispositivo ( DA ) y la aplicación de vía de acceso ( GA ) , al almacenar en el repositorio DA y GA, la información de registro de la aplicación de vía de acceso M2M o dispositivo M2M y mantener esta información actualizada, al proporcionar una interfase de consulta a entidades autorizadas y autentificadas de manera adecuada para que ellas sean capaces de recuperar la información de GA y DA almacenada en el repositorio, al almacenar en el repositorio DA y GA un subgrupo de datos DA/GA que puedan ser leídos por las entidades autorizadas y autentificadas, o al proporcionar un mecanismo de sus cripc ión / not i fi ca c i ón que permita a una entidad autorizada y autentificada el ser notificada a la actualización de los datos DA/GA.

La capacidad NCSS en la vía de acceso M2M puede llevar a cabo la selección de red de acceso (red de retorno) basada en QoS, clase de servicio, energía disponible, costo de transmisión, o cualquier otra métrica. La capacidad NCSS puede determinar el servicio mínimo requerido con base a los dispositivos detrás de la vía de acceso M2M. La capacidad NCSS puede tomar en cuenta las necesidades variantes de los dispositivos M2M detrás del dispositivo M2M o la ubicación de los vecinos. La capacidad NCSS puede llevar a cabo la selección de red capilar basada en QoS. La capacidad NCSS puede elegir entre varias redes capilares o puede adaptar la red capilar para cumplir ciertos requisitos (tales como el tiempo de espera, rendimiento, etc.) . Por ejemplo, la capacidad NCSS puede decidir el dividir una red capilar por razones de equilibrio de carga. La capacidad NCSS puede llevar a cabo la selección de via de acceso y/o transferencia. La capacidad NCSS puede mantener la información de la via de acceso cercana (como la frecuencia utilizada, protocolo, el cuántos dispositivos, etc.) . Puede negociar con las vías de acceso cercanas a fin de forzar a un dispositivo a ir de una vía de acceso a otra, (es decir, transferencia) . La capacidad NCSS puede tener la habilidad de valorar y manejar las oportunidades de agregación de ancho de banda potencial dentro de la red de área M2M. Por ejemplo, la vía de acceso M2M puede dividir o cargar el tráfico de datos en equilibrio que tiene como objetivo un dispositivo especifico al rutear los paquetes de datos a través de múltiples rutas dentro de la red capilar o sobre múltiples RATs, con la condición de que los dispositivos soporten la capacidad multi-RAT . La capacidad NCSS puede llevar a cabo el manejo de interferencia y espectro en la red capilar. La capacidad NCSS puede tener la habilidad de emitir solicitudes para que el espectro se utilice, y la habilidad para hacer reportes de medición a cierta entidad central.

La vía de acceso M2M puede tener la capacidad de proxy HDR. La capacidad de proxy HDR puede ocultar el historial y las tareas de retención de datos de la aplicación M2M y los dispositivos en la red local. La capacidad proxy HDR puede archivar las transacciones relevantes, por ejemplo, en formato de mensaje en fila, (es decir, sin ninguna interpretación de carga útil), con base al perfil del dispositivo y/o aplicación. La capacidad proxy HDR puede interactuar con la función HDR que reside en la red central M2M y soportar HDR jerárquico para manejar los datos. La capacidad de proxy HDR puede interactuar con otras capacidades que residen en la via de acceso M2M para determinar si y qué información requiere ser retenida, u obtener la información a ser almacenada de la capacidad incluida, etc.

La via de acceso M2M puede tener una capacidad de proxy CB. La capacidad de proxy CB puede mantener la información de carga y facturación para la red central. La capacidad de proxy CB puede ser un punto de contacto único a la aplicación de la via de acceso M2M sobre el lado de la red o sobre el lado del cliente, y puede generar registros de carga pertenecientes al uso de capacidades.

La capacidad MDGP en la via de acceso M2M puede inter-t raba j ar con MDGM de via de acceso y el dispositivo o las funciones de manejo de via de acceso, y/o inter- traba j ar entre la GMDAE de via de acceso y el dispositivo o los medios de comunicación propietarios de la via de acceso. A fin de agregar señalización y tráfico en la via de acceso M2M, la via de acceso M2M puede manejar tanto los dispositivos M2M estándar no conformistas y los dispositivos 2M estándar conformistas (tales como dispositivos conformistas ETSI) . La entidad DGP puede estar en interfase con los dispositivos M2M no conformistas. La entidad MDGP puede estar en interfase directamente con la GMDAE. La función de las capacidades de servicio que reside en la vía de acceso M2M puede tener acceso a los dispositivos (dispositivos estándar conformistas y no conformistas) a través de la GMDAE, según se muestra en la FIG. 5. Alternativamente, la entidad MDGP puede estar en interfase a la GMAE, comportándose de ese modo idénticamente a una aplicación que se ejecuta en la via de acceso.

La via de acceso M2M puede tener una capacidad de servicio de ubicación. La capacidad de servicio de ubicación puede determinar la información de ubicación para los dispositivos detrás de la via de acceso, la cual podrá derivarse con base a la información del sistema de po s i ci onamiento global (GPS), tablas de ruteo de la red de área, triangulación de la via de acceso, etc. La capacidad de servicio de ubicación puede almacenar la información de la ubicación. La información puede ser relativa a la posición de la vía de acceso o puede ser absoluta. La capacidad de servicio de ubicación puede proporcionar una interfase a las entidades autentificadas para consultar la información de ubicación de los dispositivos M2M.

Las vías de acceso M2M podrán catalogarse en una pluralidad de clases en términos de un grupo mínimo de funcionalidades que ellas proporcionen. En una modalidad, las vías de acceso M2 podrán catalogarse en tres clases (vías de acceso de nivel bajo, medio y alto) . Por ejemplo, la vía de acceso a nivel bajo puede soportar GMDAE, SC, MDGM, MDGP, y alguna funcionalidad RADAR. La vía de acceso a nivel medio puede soportar funcionalidades GMDAE, SC, MDGM, MDGP, y RADAR permitidas para la total, limitada, o nula visibilidad a las entidades detrás de la vía de acceso. La vía de acceso a nivel alto puede soportar más funcionalidades, y tener la total funcionalidad RADAR, la cual permite la comunicación entre vías de acceso, permitiendo que las capacidades de servicio compartan información. Debería señalarse que las clasificaciones anteriores y funcionalidades para cada clase, se proporcionan como ejemplos, y las vias de acceso podrán catalogarse en cualquier número de clases y las funcionalidades requeridas para cada clase podrán definirse en una manera concebible .

La FIG. 6A es un flujo de llamada ej emplificativo para la vía de acceso a nivel bajo sin proxy de via de acceso. En este ejemplo, el dispositivo M2M es un dispositivo no conformista de tal manera que la MDGP en la red central, lleva a cabo un ínter- traba j o . La vía de acceso lleva a cabo el registro con la RADAR en la red central M2 (602) . El dispositivo M2M hace una conexión a la vía de acceso cuando esta se enciende (604) . La vía de acceso entonces registra el dispositivo con la RADAR en la red central (606, 608) . A medida que el dispositivo se registra, la información del dispositivo, (por ejemplo, la información de registro, capacidad de dispositivo, ciclo de modo latente, estado de asequibilidad, dirección de dispositivo, o lo similar), podrá almacenarse en la RADAR. Cuando el dispositivo se apaga, la vía de acceso lo detecta y actualiza la RADAR por medio de la DGP como la aplicación inasequible (610, 612) . Cuando el dispositivo se enciende nuevamente, la conexión entre el dispositivo y la via de acceso se restablece (614), y la vía de acceso actualiza la RADAR por medio de la MDGP como la aplicación asequible (616, 618) . Cuando los datos destinados a los dispositivos llegan a la RADAR (620) , la cual tiene la información del dispositivo, los datos se renvian al dispositivo por medio de la MDGP en la red central, y por medio de la via de acceso (622 , 624, 626) .

La FIG. 6B es un flujo de llamada e j emplif icativo para la via de acceso a nivel bajo con proxy de via de acceso. La via de acceso lleva a cabo el registro con la RADAR en la red central M2M (652) . El dispositivo M2M hace una conexión a la via de acceso cuando este se enciende (654) . En este ejemplo, el dispositivo M2M es un dispositivo no conformista de tal manera que la MDGP en la via de acceso, inter-t raba a con el dispositivo. Con el proxy de via de acceso, la via de acceso registra el dispositivo con la RADAR en la via de acceso (656) . A medida que el dispositivo es registrado, la información del dispositivo (por ejemplo, información del registro, capacidad del dispositivo, ciclo de modo latente, estado de asequibilidad, dirección del dispositivo, o lo similar), podrán almacenarse en la RADAR de la via de acceso. Cuando el dispositivo se apaga, la via de acceso lo detecta y actualiza la RADAR en la vía de acceso como la aplicación inasequible (658) . Cuando el dispositivo se enciende nuevamente, la conexión entre el dispositivo y la via de acceso se restablece (660), y la via de acceso actualiza la RADAR en la via de acceso como la aplicación asequible ( 662) . Cuando los datos destinados al dispositivo llegan a la RADAR en la red central (664), la RADAR en la red central envia una solicitud de información de la aplicación al proxy de RADAR en la via de acceso (666), y el proxy de RADAR en la via de acceso responde con la información de la aplicación (668) . Los datos entonces son renviados al dispositivo por medio de la DGP en la via de acceso (670 , 672) . Con el proxy de via de acceso, la carga de señalización podrá reducirse.

La FIG. 7A es un flujo de llamada e emplif icativo para la vía de acceso a nivel medio sin proxy de vía de acceso. En este ejemplo, los dispositivos M2M son dispositivos conformistas. La vía de acceso lleva a cabo el registro con la RADAR en la red central M2M (702) . El dispositivo M2M 1 lleva a cabo el registro con la RADAR en la red central por medio de la via de acceso (704 , 706) . El dispositivo M2M también lleva a cabo el registro con la RADAR en la red central por medio de la via de acceso (708 , 710) . A medida que los dispositivos son registrados, la información del dispositivo (por ejemplo, información del registro, capacidad de dispositivo, ciclo de modo latente, estado de asequibilidad, dirección del dispositivo, o lo similar), podrá almacenarse en la RADAR en la red central. Cuando la información del dispositivo M2M 1 cambia, los dispositivos 2M actualizan la RADAR en la red central por medio de la via de acceso (712, 714) . La aplicación en la red podrá solicitarse para la información del dispositivo de la RADAR (716) .

La FIG. 7B es un flujo de llamada e j emplif icativo para la vía de acceso a nivel bajo con proxy de vía de acceso y no visibilidad. En este ejemplo, los dispositivos M2M son dispositivos conformistas. La vía de acceso lleva a cabo el registro con la RADAR en la red central M2M (732) . Los dispositivos M2M 1 y K llevan a cabo el registro con la vía de acceso (734 , 736) . Ya que se utiliza el proxy de vía de acceso, la información del dispositivo (tal como la información del registro, capacidad del dispositivo, ciclo de modo latente, estado de asequibilidad, dirección del dispositivo, o lo similar), se almacena en el proxy de RADAR en la vía de acceso a medida que los dispositivos llevan a cabo el registro. Cuando la información del dispositivo M2M 1 cambia, tal cambio se actualiza con el proxy de RADAR en la vía de acceso (738) . Sin visibilidad, la red central no tiene información del dispositivo más allá de la vía de acceso. Cuando la aplicación en la red solicita la información del dispositivo a la RADAR en la red (740), la RADAR en la red recupera la información del dispositivo de la RADAR en la vía de acceso (742, 744) .

La FIG. 7C es un flujo de llamada ej emplificativo para la vía de acceso a nivel bajo con proxy de vía de acceso y visibilidad parcial. En este ejemplo, los dispositivos M2M son dispositivos conformistas. La via de acceso lleva a cabo el registro con la RADAR en la red central M2 (762) . La RADAR en la red central establece la información visible con el proxy de RADAR en la via de acceso de tal manera que la red central podrá tener información parcial acerca de los dispositivos más allá de la via de acceso (764) . Los dispositivos M2M 1 y K llevan a cabo el registro con la via de acceso (766, 768) . Ya que se utiliza el proxy de via de acceso, la información del dispositivo (tal como información del registro, capacidad del dispositivo, ciclo de modo latente, estado de asequibilidad, dirección del dispositivo, información visible, o lo similar), se almacena en el proxy de RADAR en la via de acceso a medida que los dispositivos llevan el registro. Cuando la información del dispositivo 2M cambia (dispositivo 1 en este ejemplo), tal cambio se actualiza con el proxy de RADAR en la vía de acceso (770) .

Si la información visible del dispositivo cambia, el proxy de RADAR en la vía de acceso la actualiza con la RADAR en la red central (772) . Cuando la aplicación solicita la información del dispositivo (Dispositivo K en este ejemplo) (774), la RADAR en la red podrá recuperar la información del dispositivo para el Dispositivo K del proxy de RADAR en la vía de acceso si la RADAR en la red no la tiene (776, 778 ) .

La FIG. 8A es un flujo de llamada ej emplif icativo para la via de acceso a nivel alto sin proxy de via de acceso. En este flujo de llamada ej emplificativo, el dispositivo soporta la movilidad detrás de una via de acceso. Debido a la movilidad, el dispositivo puede cambiar su via de acceso principal. En este ejemplo, el dispositivo 2M es un dispositivo estándar conformista. La via de acceso 1 y 2 llevan a cabo el registro con la RADAR en la red central M2M (802 , 804) . El dispositivo M2M actualmente se encuentra conectado a la via de acceso 1, y lleva a cabo el registro con la RADAR en la red central por medio de la vía de acceso 1 (806, 808) . A medida que los dispositivos se registran, la información del dispositivo (por ejemplo, la información del ¡ registro, capacidad del dispositivo, ciclo de modo latente, estado de asequibilidad, dirección del dispositivo, o lo similar), podrá almacenarse en la RADAR en la red central. El dispositivo 2M lleva a cabo el registro de aplicación con la RADAR en la red central por medio de la vía de acceso 1 (810-816) . El dispositivo podrá ejecutar múltiples aplicaciones, y podrá llevar a cabo múltiples registros de aplicación (dos en este e j emplo ) .

El dispositivo se mueve detrás de la via de acceso 2 y podrá derribar y restablecer el registro de dispositivo/aplicación (817), y lleva a cabo un procedimiento para registrar el dispositivo por medio de la via de acceso 2 (818 , 820) . Cuando la RADAR en la red central recibe el registro del dispositivo para el dispositivo por medio de la via central 2 (820), la RADAR borra del registro todas las aplicaciones del dispositivo y lo señala hacia la via de acceso 1 (821 , 822) . El dispositivo lleva a cabo el (los) registro (s) de aplicación por medio de la vía de acceso 2 (824-830) .

La FIG. 8B es un flujo de llamada ej emplificativo para la vía de acceso a nivel alto con el proxy de via de acceso y RADAR y soporte de movilidad. En este flujo de llamada ej emplificativo, el dispositivo soporta la movilidad detrás de una via de acceso. Debido a la movilidad, el dispositivo podrá cambiar su via de acceso principal. En este ejemplo, el dispositivo M2M es un dispositivo conformista. La via de acceso 1 y 2 llevan a cabo el registro con la RADAR en la red central M2M (852) . El dispositivo M2M actualmente se encuentra conectado a la via de acceso 1, y lleva a cabo el registro de dispositivo con la RADAR en la red central por medio de la vía de acceso 1 (856, 858) . A medida que los dispositivos se registran, la información del dispositivo (por ejemplo, información del registro, capacidad del dispositivo, ciclo de modo latente, estado de asequibilidad, dirección del dispositivo, o lo similar), podrá almacenarse en la RADAR en la red central. El dispositivo M2M lleva a cabo el registro de aplicación con la vía de acceso 1 a medida que el proxy de vía de acceso se utiliza (860, 862) . El dispositivo podrá ejecutar múltiples aplicaciones, y por lo tanto podrá llevar a acabo múltiples registros de aplicación (dos en este e j emplo ) .

El dispositivo se mueve detrás de la vía de acceso 2 (863) , y lleva a cabo un procedimiento para registrar el dispositivo con la red central por medio de la via de acceso 2 (864 , 866) . Cuando la RADAR en la red central recibe el registro de dispositivo para el dispositivo por medio de la via de acceso 2, la RADAR borra del registro el dispositivo con respecto a la via de acceso 1, y vuelve a registrar el dispositivo con respecto a la via de acceso 2 (868) . Los proxies de RADAR en la vía de acceso 1 y la vía de acceso 2 intercambian la información de RADAR de proxy para el dispositivo (870) . Por lo tanto, no existe la necesidad de derribar y restablecer las sesiones a medida que las RADAR de proxy se comunican y el dispositivo no tiene que llevar a cabo el registro de aplicación nuevamente después de moverse detrás de la vía de acceso 2.

Las FIGS. 9A-9C son flujos de llamada ej emplif icat ivos para el soporte de movilidad. En la FIG. 9A, el dispositivo descubre la vía de acceso 1 (901) y lleva a cabo el registro de aplicación con la vía de acceso 1 (902) ) . El dispositivo se mueve y sale de la cobertura de vía de acceso 1 y entra a la cobertura de la vía de acceso 2 (903) . El dispositivo descubre la via de acceso 2 (904) . La aplicación de dispositivo notifica a la capacidad de servicio de via de acceso 2 que el dispositivo ya está registrado con la via de acceso 1 (905) . La via de acceso 2 solicita la información de la aplicación del dispositivo de la via de acceso 1 (906) . La via de acceso 1 envía la información de aplicación del dispositivo a la vía de acceso 2 (907) . La aplicación de dispositivo podrá entonces iniciar la comunicación con la vía de acceso 2 (908) . En la FIG. 9A, la vía de acceso 1 comparte la información necesaria con respecto a la aplicación con la vía de acceso 2. Ya que la vía de acceso 2 ya tiene la información sobre la aplicación dada, la aplicación no necesita volverse a registrar.

En la FIG. 9B, el dispositivo descubre la vía de acceso 2 (931) y lleva a cabo el registro de aplicación con la via de acceso 1 (932) . La via de acceso 1 anuncia la información de aplicación del dispositivo a la via de acceso 2 ( 933) . El dispositivo se mueve y sale de la cobertura de la via de acceso 1 y entra a la cobertura de la via de acceso 2 (934) . El dispositivo descubre la via de acceso 2 (935) . Ya que la via de acceso 2 tiene la información de aplicación del dispositivo, la aplicación del dispositivo puede iniciar la comunicación con la via de acceso 2 (936) . La via de acceso 1 y la via de acceso 2 pueden intercambiar la señalización de manera que estén conscientes de que la aplicación del dispositivo ahora se encuentra en comunicación con la via de acceso 2.

En la FIG. 9C, la via de acceso 1 puede compartir la información parcial con respecto a la aplicación con la via de acceso 2. Esta información parcial puede ser suficiente de tal manera que la via de acceso 2 puede ser capaz de reconocer la aplicación cuando la aplicación inicia la comunicación con la via de acceso 2. Por ejemplo, esto puede ser la dirección IP y el número de puerto de la aplicación. Esto minimiza la cantidad de información que necesita mantenerse en las vias de acceso, permitiendo todavía la información de registro para ser compartida entre las vías de acceso. El dispositivo descubre la vía de acceso 1 (961) y lleva a cabo el registro de aplicación con la vía de acceso 1 (962) . La vía de acceso 1 anuncia la información de la aplicación del dispositivo parcial a la vía de acceso 2 (963) . El dispositivo se mueve y sale de la cobertura de la vía de acceso 1 y entra a la cobertura de la vía de acceso 2 (964) . El dispositivo descubre la vía de acceso 2 (965) . El dispositivo inicia la comunicación con la vía de acceso 2 (966) . La vía de acceso 2 solicita la información de la aplicación del dispositivo de la vía de acceso 1 (967) . La vía de acceso 1 proporciona la información de la aplicación del dispositivo a la vía de acceso 2 (968) . La comunicación bi-direccional entre el dispositivo y la vía de acceso 2 inicia entonces (969) . La aplicación no necesita volverse a registrar.

La FIG. 10 muestra los flujos de nivel altos de los procedimientos operativos llevados a cabo por las comunicaciones M2M. Debería señalarse que la FIG. 10 muestra una arquitectura jerárquica como un ejemplo para un dispositivo detrás de dos vías de acceso en un sistema M2M y con dos proveedores de servicio M2M, pero podrá generalizarse a cualquiera de las estructuras jerárquicas. El dispositivo, la vía de acceso, y la red tienen un grupo de capacidades de servicio (capacidad de servicio del dispositivo (DSC), capacidad de servicio de la vía de acceso (GSC), y capacidad de servicio de la red (NSC) ) , respectivamente.

Los procedimientos operativos incluyen iniciali zación de red de área y acceso, descubrimiento de nodo de red de área, registro de red de acceso/central /transporte , y etapas relacionadas a la capacidad de servicio. Las etapas relacionadas a la capacidad de servicio incluyen, pero no se limitan a, descubrimiento de capacidad de servicio, intercambio de capacidad de servicio, con fi gura ci ón / re - configuración de capacidad de servicio, descubrimiento jerárquico, registro de capacidad de servicio, registro de aplicación (aplicaciones de red, vía de acceso, 1 y dispositivo), anuncio de capacidad de servicio, solicitud de transferencia de contexto e registro de capacidad de servicio, transferencia de contexto de registro de capacidad de servicio, o lo similar.

El dispositivo y la vía de acceso pueden necesitar el inicializar la identidad de red de acceso, el parámetro de seguridad relacionado, los parámetros de red de área, et c .

En el procedimiento del descubrimiento del nodo de red de área, el dispositivo descubre y conecta a la vía de acceso. El procedimiento de descubrimiento de nodo de red de área puede ser consciente estándar a fin de ayudar al descubrimiento de la capacidad de servicio .

Durante el registro de red, la vía de acceso se registra con la red de acceso/núcleo. Como parte de este procedimiento, la vía de acceso podrá asignarse a una dirección IP de la red central. Un procedimiento de registro es un procedimiento mediante el cual un SCL de registro autentifica y autoriza a un SCL origen 0 a una aplicación a utilizar las capacidades de servicio dentro del SCL de registro. Un SCL de registro se refiere a un SCL que aloja al contexto de registro para un SCL origen o para una aplicación que ha llevado a cabo un procedimiento de registro. Un SCL origen es un SCL que inicia un procedimiento de registro. La entidad que aloja el SCL origen puede ser un dispositivo o un estrato de capacidad de servicio de la via de acceso. Los atributos de registro se refieren a las características de las entidades (es decir,- dispositivos, vías de acceso, etc.) a las que se les permite registrarse. Las características pueden relacionarse a las características físicas (energía disponible, capacidad disponible), identificación, clase de servicio, etc. Estos atributos forman parte del contexto de registro asociado con el SCL de la entidad.

Cada una de las etapas relacionadas a la capacidad de servicio se explica a detalle de aquí en adelante. Debería señalarse que en las siguientes secciones, numerosas funciones y mensajes, no se pretende que limiten el alcance de su uso, sino que puedan intercambiarse, combinarse o ejecutarse en otra etapa. Por ejemplo, el mensaje SC_de Publicidad podrá superponerse o combinarse, con el mensaje de indicación de capacidad, la operación de SC_Medidor podrá combinarse con la operación de solicitud de capacidad, y el mensaje rastreóse podrá emitirse simultáneamente con el de SC_Medidor, etc.

Las entidades (tales como dispositivos, vías de acceso, y redes centrales que puedan ser estándares, (por ejemplo, ETSI), conformistas), pueden llevar a cabo el descubrimiento de la capacidad de servicio y mantener una base de datos con la información acerca de las capacidades de servicio descubiertas. La cantidad de información en la base de datos puede depender del pape de la entidad. Por ejemplo, un SCL de registro puede necesitar una base de datos de SC muy detallada a fin de permitir la adecuada delegación de SC. En contraste, un dispositivo final M2M con baja potencia podrá necesitar el saber la ubicación de su SCL de registro. A fin de poblar la base de datos de SC, una entidad puede necesitar primero descubrir otras entidades que tengan capacidades de servicio por uno de los siguientes procedimientos de descubrimiento de capacidad de servicio.

De acuerdo con una modalidad, los SCLs pueden ser pre-configurados (en software o en hardware) con la identidad o la dirección de otros SCLs. Por ejemplo, un SCL en el proveedor de servicio de red puede saber la identidad o dirección del SCL de otro proveedor de servicio de red. Por ejemplo, la identidad o la dirección pueden ser dirección IP, número de puerto, o lo similar, y podrá ser dependiente de la implementación.

De acuerdo con otra modalidad, los SCLs pueden ser pre-conf igurados (en software o en hardware) con la identidad o dirección de un servidor despachador que responde a consultas de un SCL con una lista de capacidades de servicio potenciales que podrán utilizarse en la red. El SCL origen puede proporcionar información adicional al servidor despachador de tal manera que el servidor despachador puede adaptar la lista de las identidades o direcciones de SCL devuelto (lista de dirección de SCL) . Por ejemplo, una capacidad de servicio de via de acceso puede proporcionar una indicación de que se encuentra detrás de otra via de acceso. El servidor despachador puede entonces regresar la identidad o dirección de esa via de acceso, la cual podrá entonces ser utilizada para el intercambio de capacidad subsiguiente.

De acuerdo con otra modalidad, si una entidad se encuentra en una red local, puede apalancar la comunicación de red local y utilizar un procedimiento de conectar y reproducir para determinar la ubicación de las capacidades de servicio potenciales. El procedimiento autoriza a la entidad a ser aprovisionada y configurada sin ninguna intervención humana en el nivel del dispositivo (ya sea durante el servicio o durante la fabricación) . El procedimiento puede depender de: (1) la red local que se suscribe a las capacidades de servicio que se enlazan a los casos de uso de M2M específicos, con estos casos de uso identificados por los identi ficadores de servicio M2M conocidos, y (2) la entidad que conoce su identif icador de servicio M2M. La Tabla 1 muestra los ejemplos de los identi ficadores de servicio M2M. Se asume que la entidad (o las entidades) en la red local se suscribió (suscribieron) a los estratos de capacidad de servicio. Es decir, la entidad se ha registrado a un grupo de estratos de capacidad de servicio y ha asociado a cada una de estas capacidades de servicio el identi fi cado r de servicio M2M conocido, soportado. Esto puede ser una tabla simple del ident i fi cado r de servicio M2M y la identidad/dirección de SCL correspondiente etiquetada para ocuparse de las entidades de este tipo. La red local puede proporcionar esta dirección/identidad a la entidad, (por ejemplo, a través del SCL en la vía de acceso M2M) .

Tabla 1 La FIG. 11 es un diagrama de flujo e j empl i f i cat ivo de un procedimiento para el descubrimiento de la capacidad de servicio en una red local. Un dispositivo lleva a cabo la iniciali zación para utilizar la red de área y asociarse con la red local (1102) . El dispositivo puede enviar un mensaje, (de aqui en adelante referido como "mensaje SC_Medidor" como un ejemplo) , incluyendo su ident if icador de servicio M2M soportado (por ejemplo, "Yo soy un termostato") , a la via de acceso M2M con la que ya se ha asociado, (es decir, ya ha establecido un enlace de comunicación) (1104) . El dispositivo puede utilizar la dirección IP de la via de acceso (conocida después de la asociación con la via de acceso) y podrá escribir el mensaje SC_Medidor a un recurso de averia por el dispositivo. Estos identificadores de servicio M2M podrán haberse almacenado en el hardware o software, por ejemplo, al momento de la fabricación La Tabla 1 muestra un identificador de servicio M2M e j emplif icativo .

La vía de acceso M2M al cual se ha asociado el dispositivo, puede recibir el mensaje de SC_Medidor y mapear el identificador de servicio M2M recibido con los perfiles de suscripción actuales (1106) . Por ejemplo, si la via de acceso M2M se ha suscrito a un estrato de capacidad de servicio de retículo inteligente que permite el monitoreo y control del consumo de electricidad, la suscripción asociada puede aceptar cualquiera de los dispositivos con el identificador de servicio M2M primario = Utilidad de Electricidad. La suscripción puede definir los identificadores de servicio M2M secundario específicos que se soportan, (por ejemplo, medidores de electricidad, control de corriente, termostato, etc. ) . La misma vía de acceso puede suscribirse a los múltiples estratos de capacidad de servicio. Una vez que la vía de acceso M2M ha identificado bajo cuál suscripción podrá operar el dispositivo con base a los identificadores de servicio contenidos en el SC_Medidor , la vía de acceso M2M puede enviar un mensaje, (de aquí en adelante, referido como "mensaje SC_Configuración" como un ejemplo) (1108) . El mensaje SC_Conf iguración puede indicar al dispositivo a qué entidad o entidades el dispositivo le podría estar hablando. Como parte de la configuración conectar y reproducir, el mensaje SC_Configuración podrá seguirse por la actualización de software de la aplicación de la vía de acceso M2M para soportar la aplicación suscrita al nivel del dispositivo 2M. Como tal, la actualización de software podrá activarse por la aplicación ejecutándose sobre la vía de acceso o la aplicación en la red pero suscrita a la vía de acceso. El dispositivo fuera de la fábrica puede tener una versión de software desmontada con la mínima aplicación de cliente. Una vez que el dispositivo recibe el mensaje SC_Configuración , el dispositivo puede llevar a cabo el registro con la entidad SCL correcta (1110) .

De manera alternativa, la entidad puede transmitir el mensaje SC_Medidor en la red local (por ejemplo, una dirección IP de transmisión y un recurso de averias) . Cualquier dispositivo en la red local que se haya suscrito a una capacidad de servicio, puede responder a la entidad con el mensaje SC_Conf iguración . La entidad recolecta y puede combinar las respuestas de los nodos de red local que han respondido, y llevar a cabo cierto procesamiento sobre estas para prevenir el duplicado o las inconsistencias.

De manera alternativa, una entidad (por ejemplo, dispositivo M2M), puede enviar periódicamente un mensaje de transmisión, (de aqui en adelante referido como un mensaje SC_de Publicidad, como un ejemplo), en la red local. El mensaje SC_de Publicidad publica una lista de ident i f icadores de servicio M2M soportados por la entidad. El mensaje SC_de Publicidad podrá enviarse a una dirección IP de transmisión utilizando un recurso de averias conocido. Un dispositivo que recibe el mensaje SC_de Publicidad puede comparar su identi fi cado r de servicio M2M con aquellos contenidos en el mensaje SC_de Publicidad y responder con un mensaje SC_Medidor si uno de sus identificadores de servicio M2M sincroniza los identificadores de servicio publ i ci tado s . Alternativamente, la entidad puede incluir la lista de dirección SCL completa en el mensaje SC_de Publicidad. Al recibir este mensaje de transmisión, un dispositivo podrá cruzar su ident i fi cado r de servicio M2 con aquél incluido en la lista de transmisión para determinar los SCLs adecuados.

Con esta modalidad, los múltiples grupos de los dispositivos M2M podrán manejarse por diferentes operadores de servicio M2M y suscripción sin hacer ninguna configuración en el nivel de dispositivo. Por ejemplo, la via de acceso M2M podrá haberse suscrito a dos estratos de capacidad de servicio, uno proporcionando el servicio a una utilidad de electricidad y otro proporcionando un servicio a un sistema de seguridad de vigilancia. Los dispositivos M2M que necesitan acceso a uno de estos estratos de capacidad de servicio, pueden exhibir diferentes identificadores de servicio M2M, que podrían permitir al dispositivo M2M configurarlos de manera diferente, por ejemplo, asignando una lista diferente de SCs descubiertas, entidades de registro, diferentes actualizaciones de software de aplicación, o lo similar .

Los identificadores de servicio M2M podrán almacenarse en el hardware o software, por ejemplo, a la hora de la fabricación. El ident i fi cador de servicio M2M podrá cambiar dinámicamente en tiempo, ya que el mismo dispositivo podrá utilizarse para diferentes aplicaciones durante su tiempo de vida. Por ejemplo, podrá utilizarse un dispositivo como un dispositivo e-salud en la primera vez, y después utilizarse como un dispositivo electrónico de consumidor en otro momento.

El identificador de servicio M2M podrá ser cualquier identif icador que podrá ser utilizado para definir una clase o tipo de aplicación o dispositivo. Se utiliza para representar cualquier identi ficador que podrá utilizarse por el SCL para proporcionar una respuesta adaptada. Por ejemplo, el iden t i f i cado r de servicio M2M puede ser una clase de aplicación (por ejemplo, sensor de temperatura, detector de movimiento, manómetro) , una clase de servicio (por ejemplo, prioridad alta, menos tolerante, etc.) , una clase de caso de uso, (por ejemplo, dispositivo de calentamiento, dispositivo de seguridad) , o cualquier combinación.

La Tabla 2 muestra los contenidos e j empl i f i ca t i vo s de los mensajes SC_Medidor, SC_Conf iguración , y SC_de Publicidad.

Lista de Códigos para la lista Identifide Identificadores de cado re s Servicio de Por cada identificador Servicio de servicio M2M M2M primario la Entidad Pr imarios puede proporcionar una lista de Identificadores de Servicio M2M Secundarios Lista de Los Estratos de la Dirección capacidad de servicio de los podrán unirse a un Estratos Identificador de de Servicio M2M Primario - Capacidad Identificadores de de Servicio M2M Servicio Secundarios .

Tabla 2 La red local puede llevar la lista de dirección SCL como parte de un mensaje de estrato inferior. Por ejemplo, en una PAN inalámbrica, la información podrá llevarse en la transmisión de mensajes de control por el coordinador PAN (por ejemplo, en balizas de transmisión) . El SCL puede utilizar una interfase estandarizada a los estratos inferiores para autorizar la inserción y la extracción de la lista de dirección SCL y para configurar el estrato inferior, (por ejemplo, con la frecuencia de transmisión de la lista de dirección SCL) .

De acuerdo con otra modalidad, una entidad podrá depender de la red de acceso y un procedimiento de conectar y reproducir similar para ayudar en el descubrimiento de capacidad de servicio. Esto podrá integrarse con el proceso de registro de red de acceso/central o lograrse a través de un nuevo mensaje de solicitud (por ejemplo, mensaje de estrato de no acceso (ÑAS) ) . Por ejemplo, un nodo de soporte GPRS de via de acceso (GGSN) para el sistema global para comunicaciones móviles (GSM) y red de acceso a radio terrestre (UTRAN) y una via de acceso en paquete (P-GW) para UTRAN evolucionado (E-UTRAN) podrán configurarse con la lista de dirección SCL y mapeo a identificadores de servicio M2M primarios e identificadores de servicio M2M secundarios. Cuando una entidad lleva a cabo su registro de red central y acceso y la activación de contexto de protocolo de datos de paquete (PDP) , la entidad puede incluir su identi fi cado r de servicio M2M como parte de los mensajes intercambiados. Además de activar un contexto PDP y asignar una dirección IP a la entidad, la red central puede proporcionar la lista de dirección SCL. Esta información podrá enviarse a la entidad en el mensaje de activación de contexto PDP o de confirmación de r egi st ro .

Alternativamente, la entidad puede enviar un nuevo mensaje AS a la red central, y la red central puede responder con la lista de dirección SCL.

Alternativamente, la red de acceso puede llevar la lista de dirección SCL como parte de un mensaje de estrato inferior. Por ejemplo en una red celular, la información podrá llevarse a cabo en la transmisión de los mensajes de control por el punto de acceso o estación base, (por ejemplo, en los bloques de transmisión, bloques de sincronización, bloques de información de sistema, o lo similar) . El SCL puede utilizar una interfase estandarizada a los estratos inferiores para permitir la inserción y extracción de la lista de dirección SCL y para configurar el estrato inferior, (por ejemplo, con la frecuencia de transmisión de la lista de dirección SCL) .

Para casos en donde la entidad es móvil o las condiciones de canal son cambiantes, la entidad puede refrescar la base de datos de SC. La actualización puede ser periódica o activada por algún evento. Por ejemplo, si la entidad se mueve físicamente y se asocia a una nueva vía de acceso, y por lo tanto su punto de unión a la red y dominio de aplicación se cambia, la entidad puede depender de la nueva vía de acceso para algunas capacidades de servicio. Los estratos inferiores de la entidad pueden señalizar al SCL de la nueva vía de acceso. El SCL puede entonces iniciar un procedimiento de descubrimiento SC.

Una vez que los SCLs se han descubierto entre sí, podrán necesitar el llevar a cabo una interacción e intercambio de capacidad de servicio a fin de descubrir las funcionalidades de capacidad de servicio soportadas por el SCL de paridad y para configurar la participación de esta funcionalidad entre los dos SCLs. Esta interacción puede encontrarse entre los diferentes núcleos M2M, (es decir, capacidades de servicio de red (NSCs) ) , entre las vías de acceso y su núcleo M2 asociado, entre las diferentes vías de acceso, entre los dispositivos M2M y sus vías de acceso o central M2M asociado, o entre diferentes dispositivos M2M .

Las funcionalidades de capacidad de servicio podrán ser genéricas a cualquier elemento M2M (por ejemplo, dispositivo, via de acceso, redes centrales), de modo que podrán transmitirse a cualquier elemento que pueda recibirla. Esto podrá utilizarse para descubrimiento inicial. Alternativamente, las funcionalidades de capacidad de servicio podrán ser genéricas a un grupo de elementos M2M de modo que podrán multidi fundirse al grupo. Por ejemplo, una via de acceso soporta la retención y el almacenamiento de datos para un grupo de dispositivos M2M, y para otro grupo de dispositivos M2M, sus datos se almacenan a una via de acceso o central 2M de nivel más alto. Alternativamente, las funcionalidades de la capacidad de servicio podrán ser especificas a un elemento M2M de modo que podrán unidi fundi rse al elemento M2M especifico.

Las operaciones básicas para el intercambio SC pueden ser por consulta o por publicidad. En el procedimiento de consulta, el SCL en un elemento (llamado SCL1) puede enviar un mensaje de solicitud de capacidad a otro SCL (llamado SCL2) . Este mensaje solicita las capacidades de servicio que el SCL2 soporta. Otras capacidades más allá de las funcionalidades de SC, podrán intercambiarse. Después de recibir la solicitud, el SCL2 envía un mensaje de respuesta de capacidad incluyendo las funcionalidades que SCL2 soporta. Esta configuración SC inicial podrá ser un procedimiento autónomo, o la parte inicial del registro de SC, que se explica abajo.

En el procedimiento publicitario, un SCL envía la indicación de capacidad a uno o más SCL para indicar las funcionalidades de SC que soporta. Los otros SCLs pueden o no pueden tener conocimiento de las capacidades.

La FIG. 12 es un diagrama de flujo e j empl i fi cat ivo del intercambio de capacidad entre las entidades en un sistema que incluye un dispositivo, dos vías de acceso (GW1, GW2 ) , y dos operadores de red (NSC1, NSC2) . Las funcionalidades de la capacidad de servicio inicial, se crean en NSC1 y NSC2 (1202) . NSC1 y NSC2 intercambian la indicación de capacidad que incluye las capacidades de servicio soportadas (1204, 1206) . GSC1 se inicia (1208) . GSC1 lleva a cabo el descubrimiento de la capacidad de servicio (1210) . En este ejemplo, GSC1 descubre NSC1 y envía una solicitud de capacidad a NSC1 (1212) . NSC1 responde con una respuesta de capacidad (1214) . GSC1 lleva a cabo la configuración con base a la respuesta de capacidad (1216) . GSC2 se inicia (1218) . GSC2 lleva a cabo el descubrimiento de la capacidad de servicio (1220) . En este ejemplo, GSC2 descubre NSC2 y recibe una indicación de capacidad de NSC2 (1222) . GSC2 lleva a cabo la configuración con base a la indicación de capacidad (1224) . GSC2 también envía la indicación de capacidad a NSC2 (1226) . DSC1 se inicia (1228) . DSC1 lleva a cabo el descubrimiento de capacidad de servicio (1230) . En este ejemplo, DSC1 descubre GSC1 y envía una solicitud de capacidad a GSC1 (1232 ) . Dependiendo de la división de las capacidades de servicio, GSC1 puede registrarse con NSC1 para la división de las capacidades de servicio. Por lo tanto, GSC1 puede enviar una solicitud de capacidad a NSC1 y recibir una respuesta de capacidad (1234 , 1238) . GSC1 crea una instancia para DSC1 (1236) . GSC1 envía una respuesta de capacidad (1240) .

La solicitud de capacidad, respuesta, e intercambios de mensaje de indicación, se basan sobre la presunción de que los SCLs pueden tener acceso entre si utilizando las redes de área subyacente, acceso, núcleo, y/o transporte. Estos mensajes no se limitan a las funcionalidades de SC, pero podrán utilizarse para los propósitos generales de configuración, negociación y descubrimiento de funcionalidad de SC. La Tabla 3 muestra un ejemplo de los elementos de información (IEs) de la solicitud de capacidad, respuesta, y mensajes de indicación .

Tabla 3 Las capacidades de servicio podrán volverse a configurar. La re - configura c i ón de la capacidad de servicio pueden ser debido a la movilidad (por ejemplo, un dispositivo o vía de acceso M2 se ha movido) , el cambio de la capacidad SC (por ejemplo, una vía de acceso se ejecuta fuera del espacio de almacenamiento), el cambio de la distribución de la capacidad de servicio por el proveedor de servicio M2M para las vías de acceso y/o los dispositivos pertenecen al núcleo, activación periódica o regular, registro a un nuevo SCL, (por ejemplo, un dispositivo M2M puede descubrir un nuevo SCL y desear utilizar algunas de sus funciones de capacidad de servicio) , o lo similar. La reconfiguración podrá ser iniciada por red, iniciada por via de acceso, o iniciada por dispositivo. Los mensajes definidos en la Tabla 3 podrán utilizarse asi también para la reconfiguración.

Un SCL puede llevar a cabo un descubrimiento jerárquico para determinar la participación más eficiente de las capacidades de servicio para un SCL origen que se está tratando de registrar. Por ejemplo, un dispositivo podrá ubicarse detrás de varios niveles de vías de acceso, cada uno capaz de proporcionar las capacidades de servicio. Cuando se determina cómo asignar las capacidades de servicio al SCL origen, el SCL de registro necesita estar consciente de esta jerarquía como la funcionalidad de capacidad de servicio que cada una de las vías de acceso intermedias pueda proporcionar. Esto se determina por un procedimiento de descubrimiento jerárquico.

De acuerdo con una modalidad, si el SCL origen ya ha llevado a cabo un procedimiento de descubrimiento SC y mantiene una base de datos de SC, el SCL origen podrá incluir esta información en su mensaje de registro. Alternativamente, el SCL de registro puede solicitar que el de origen inicie un procedimiento de descubrimiento SC para determinar la conectividad de vía de acceso.

De acuerdo con otra modalidad, el SCL de registro puede activar el trazado en el SCL origen. El SCL origen puede enviar un mensaje especial al SCL de registro, que es interceptado por los SCLs intermedios a lo largo de la trayectoria hacia el SCL de registro. Cada uno de los SCLs intermedios anexa una identidad y una lista de capacidades de servicio soportadas en el mensaje especial. Por ejemplo, el SCL de registro puede enviar un comando de rastreo al SCL origen, y el SCL origen hace eco de este mensaje de regreso al SCL de registro. El SCL origen puede transmitir el mensaje de rastreo dentro de su red de área. Los dispositivos compatibles y las vías de acceso que reciben este mensaje y que están deseando ofrecer las capacidades de servicio, pueden interceptar este mensaje y anexar su identidad y una lista de funciones de capacidad de servicio que deseen ofrecer, y renviar este mensaje más arriba o más abajo en la jerarquía (por ejemplo, al transmitir otro mensaje de transmisión) . El mensaje eventualment e se propagará a una via de acceso de borde (via de acceso que proporciona conectividad al acceso y red central) . La via de acceso de borde puede anexar su propia identidad y las funciones de capacidad de servicio al mensaje de rastreo. La via de acceso de borde puede entonces decidir el renviar el mensaje directamente al SCL de registro (a través del acceso y red central) . Al recibir el mensaje de rastreo, el SCL de registro tiene una lista completa de nodos a la que puede hablar el SCL origen, asi como también las funciones de capacidad de servicio que estos nodos están deseosos de ofrecer. La Tabla 4 muestra un ejemplo de IEs del mensaje de rastreo .

Las modalidades para el registro de SCL se describen de aqui en adelante. El registro es un procedimiento mediante el cual el SCL de registro autentifica y autoriza a un SCL origen o una aplicación a utilizar las capacidades de servicio dentro del SCL de registro. Un SCL de registro se refiere a un SCL que aloja el contexto de registro para un SCL origen o para una aplicación que ha llevado a cabo un procedimiento de registro. Un SCL origen es un SCL que inicia un procedimiento de registro. La entidad que aloja el SCL origen puede ser un estrato de capacidad de servicio de via de acceso o dispositivo. Los atributos de registro se refieren a las características de las entidades (es decir, dispositivos, vías de acceso, etc.) que se permite sean registradas. Las características pueden relacionarse a las características físicas (energía disponible, capacidad disponible), identificación, clase de servicio, etc. Estos atributos forman parte del contexto de registro asociado con el SCL de la entidad.

Cuando un SCL sabe la identidad del SCL capaz de manejar el registro, lleva a cabo un registro a esa entidad. El registro puede ser precedido por una fase de pre-registro para determinar el SCL a registrar entre los SCLs descubiertos que soportan la función de registro. El SCL de registro puede saber la diagramación jerárquica de las capacidades de servicio que puede utilizar.

La FIG. 13 es un flujo e j empl i fi cat i vo de registro. Como precondiciones, GSC1, GSC2, NSC1, y NSC2 han descubierto por si mismos y negociado una participación de las capacidades de servicio, NSC2 ha delegado a NSC1 manejar la capacidad de servicio de seguridad por su parte, NA ya se ha registrado con NSC2 que manejará el registro para la aplicación, y el dispositivo se ha inicializado a la red de área, tiene conectividad a esta red, y ha descubierto su SCL de registro (NSC2 en este e j empl o ) .

DSC envía una solicitud de registro a su SC de registro (es decir, NSC2 en este ejemplo) (1302) . NSC2 envía una solicitud de seguridad a NSC1 de utilizar la capacidad de servicio de seguridad en NSC1 (1304) . NSC1 envía una respuesta de solicitud a NSC2 (1306) . Ya que NSC2 delega la capacidad RAR a GSC1, NSC2 configura esta capacidad de servicio y pasa el contexto de registro de DSC a GSC1 al enviar la solicitud de configuración SC (1308) . GSC1 responde con una respuesta de configuración SC (1310) . NSC2 informa a DSC a utilizar GSC1 para la funcionalidad RAR al enviar la respuesta de registro (1312) .

Un SCL puede registrarse con múltiples SCLs . Por ejemplo, un dispositivo podrá conectarse a múltiples vías de acceso locales y puede utilizar diferentes funciones de capacidad de servicio en cada una de las vías de acceso (por ejemplo, una para memoria inmediata y una para seguridad y direccionabilidad) . Un dispositivo podrá ser un dispositivo de roaming de modo que su SCL podrá registrarse tanto a núcleos de visita como locales.

De uno a un múltiple registro de SCL podrá suceder en un registro de SCL inicial (es decir, un SCL se registra con múltiples SCLs), o puede ocurrir de manera creciente (es decir, un SCL inicialmente se registra con un SCL, y se registra a otros SCLs después) . Un SCL origen puede enviar múltiples solicitudes de registro a múltiples SCLs objetivo. Los SCLs objetivo crean los recursos necesarios para el SCL origen. Alternativamente, el SCL objetivo puede solicitar al SCL origen el registrarse con otro SCL. Un SCL puede señalar un SCL de "anclaje" como su SCL de registro, y de esta manera otros SCLs podrán considerarse como SCLs "de ayuda". El registro de SCL puede ser independiente y transparente del registro de aplicación .

Una aplicación registra el comunicarse con SCLs y/u otras aplicaciones. Una aplicación puede registrarse con uno o múltiples SCLs u otra (s) aplicación (es) . Los parámetros relacionados a la aplicación, (por ejemplo, tipo de aplicación, espacio de almacenamiento, requerimiento de memoria inmediata, etc.), y las capacidades de servicio requeridas por la aplicación podrán incluirse en la solicitud de registro de aplicación.

La aplicación y SCL pueden intercambiar qué capacidad de servicio funciona que el SCL pueda proporcionar para la aplicación. No todas las funciones de capacidad de servicio podrán ser visibles y disponibles para todas las aplicaciones. La aplicación puede configurar las funciones de capacidad de servicio. Por ejemplo, para el almacenamiento de plano de usuario, la funcionalidad RADAR podrá configurarse para comunicación síncrona, comunicación asincrona, etc. La solicitud de registro de aplicación puede incluir un identi ficador de servicio M2 (o i dent i fi cador similar) para permitir que el SCL de registro delegue las funciones de capacidad de servicio a varios SCLs sobre una base por aplicación (por ejemplo, después de una reconfiguración o configuración SC) .

Cuando un origen, (por ejemplo, una aplicación del solicitante), envía una solicitud de registro de aplicación al objetivo, (por ejemplo, un SCL objetivo), podrá crearse un recurso de registro de aplicación, incluyendo la información incluida en la solicitud de registro de aplicación. La aplicación puede tener una copia local de las capacidades de servicio que ha registrado y las funcionalidades SC que puede recibir del SCL. Una aplicación registrada puede entonces utilizar las funcionalidades de capacidad de servicio del SCL que se ha registrado. El recurso creado proporciona una interfase por la cual la aplicación es capaz de utilizar el SCL.

En particular para una aplicación de red, la configuración del SCL de registro puede incluir una lista blanca de entidades que tienen permiso para registrarse al SCL de registro, una lista negra de entidades que podrán ser de registro negado (por ejemplo, para casos en que la aplicación se encuentra normalmente abierta a las entidades excepto las elegidas, tales como aquellas que están marcadas como de mal comportamiento), una indicación de si el SCL de registro tiene permitido llevar a cabo la delegación de capacidad de servicio. Por ejemplo, la aplicación puede solicitar que el almacenamiento de información de plano de usuario sea manejado en el SCL de registro, a pesar de que una aplicación de dispositivo puede estar detrás de una vía de acceso capaz de la funcionalidad RADAR.

Durante un registro de aplicación de dispositivo a un SCL de vía de acceso (referido como una ej emplif icación SC para aplicación), puede haber ya un acuerdo acerca de qué funcionalidades de capacidad de servicio el GSC puede proporcionar para la aplicación. Este acuerdo puede haber sido pre-determinado con base a un identif icador de servicio M2M o ident i f i cado r similar, (por ejemplo, clase de aplicación) . Para esta aplicación, la vía de acceso puede delegar las funcionalidades de capacidad de servicio al NSC conforme al acuerdo para el identif icador especifico.

La FIG. 14 es un flujo ej emplificativo de delegación SC con base a la clase de aplicación de acuerdo con una modalidad. En este ejemplo, dos dispositivos se conectan a la vía de acceso. La capacidad de servicio de red ha sido creada. Una via de acceso se enciende y se conecta a la red central (1402) . La via de acceso lleva a cabo la configuración SC inicial (1404) . Cuando la via de acceso se registra, se lleva a cabo un intercambio de capacidad de servicio entre la via de acceso (es decir, GSC), y la red central del proveedor de servicio M2M, (es decir, NSC) . El identi fi cado r de clase de aplicación puede ser un factor en decidir qué funcionalidades de capacidad de servicio la via de acceso puede proporcionarse para la aplicación. Por cada identi fi cado r de clase de aplicación, el NSC puede decidir cómo dividir o compartir las capacidades de servicio e informar la via de acceso de las capacidades que han sido delegadas. Por ejemplo, para una clase de aplicación de manejo de datos de medidor inteligente, la via de acceso puede proporcionar las funciones de almacenamiento RAR a la aplicación. Para una clase de ¡aplicación de sistema de seguridad, la red central puede proporcionar las funciones de almacenamiento RAR. Para ambas aplicaciones, la red central puede proporcionar funciones HDR. La clase de aplicación podrá utilizarse par decidir qué funciones de SC soporta para las diferentes aplicaciones en la via de acceso .

El dispositivo 1 se conecta a la via de acceso (1406), y envía una solicitud de registro junto con la clase de aplicación (1408) . Cuando el dispositivo inicia un registro de aplicación a la via de acceso (GSC), la vía de acceso, con base a la clase de aplicación incluida en el procedimiento de registro, configura las capacidades de servicio para esa aplicación específica. Esto también incluye el informar el SCL en la red (NSC) . La vía de acceso envía una solicitud de delegación de SC a NSC, y el NSC envía una respuesta de delegación de SC (1410, 1412) . La vía de acceso entonces envía una respuesta de registro al dispositivo 1 (1414) .

El dispositivo 2 se conecta a la vía de acceso (1416), y envía una solicitud de registro junto con la clase de aplicación (1418) . La diferente división SC podrá aplicarse para diferentes dispositivos debido a la diferente clase de aplicación. La vía de acceso envía una solicitud de delegación SC a NSC, y el NSC envía una respuesta de delegación de SC (1420, 1422) . La vía de acceso entonces envía una respuesta de registro al dispositivo 2 (1424 ) .

Una aplicación puede registrarse a múltiples SCLs . Una aplicación puede solicitar diferentes funcionalidades de SC de los SCLs con los que se registra. Diferentes SCLs pueden intercambiar la información de la aplicación (con la condición de que no origine ningún problema de seguridad) . La Tabla 5 muestra los casos de ejemplos de un registro de uno a múltiple para una aplicación (es decir, solicitante y objetivos para el registro de aplicación a múltiples SCLs) .

El "Dispositivo D" es un dispositivo M2M ETSI que puede comunicarse directamente a una red central M2M ETSI o a una vía de acceso M2M ETSI. El "Dispositivo D" es un dispositivo M2M ETSI que no implementa las capacidades de servicio M2M ETSI, pero interactúa indirectamente con el núcleo M2M por medio del uso de capacidades de servicio en la vía de acceso M2 . "mía" es un punto de referencia que ofrece los mecanismos genéricos y extensibles para las interacciones de aplicación con el núcleo M2M. "día" es un punto de referencia que ofrece mecanismos genéricos y extensibles para las interacciones de aplicación con las capacidades de servicio en el dispositivo M2M. "raid" es un punto de referencia que ofrece mecanismos genéricos y extensibles para las interacciones de dispositivo M2M y vía de acceso M2M con la capacidad NGC del núcleo M2M.

Tabla 5 Una aplicación (aplicación de origen) puede elegir el registrarse con otra aplicación (aplicación objetivo) . Por ejemplo, una aplicación de dispositivo puede registrarse con una aplicación de red. La aplicación podrá ser completamente transparente a SCLs de M2M. La aplicación puede o no puede mantener la información de registro. Por ejemplo, la información de registro podrá guardarse en un almacenamiento que sea local a la aplicación. Alternativamente, la transacción entre las aplicaciones de origen y objetivo podrá ser temporal. Si la aplicación objetivo se registra con un SCL, puede utilizar las funcionalidades de capacidad de servicio (por ejemplo, almacenamiento) , para manejar las aplicaciones que se han registrado directamente a ella. La aplicación objetivo puede actuar como un proxy para la aplicación de origen. Esto puede ser útil para ocuparse de los dispositivos que no tienen capacidades de servicio por si mismas y no se encuentran detrás de una vía de acceso o dispositivos de herencia .

Un SCL puede anunciar que una (s) aplicación (es) se registre (n) . El anuncio puede enviarse cuando el SCL desea hacer una aplicación visible a otro SCL. Informa aplicaciones con las que se registra, y en las que tiene recursos el SCL. La Tabla 6 es un ejemplo de IEs del mensaje de anuncio SC.

Tabla 6 Un SCL puede solicitar la transferencia de registro de capacidad de servicio. Esto se utiliza por un SCL solicitante para informar un SCL objetivo que desea utilizar los servicios del SCL objetivo, y ya se ha registrado con otro SCL (SCL origen) . El mensaje de solicitud de transferencia de registro de capacidad de servicio puede incluir el último punto de unión del SCL solicitante a fin de facilitar la transferencia eventual.

La solicitud de transferencia de registro de capacidad de servicio podrá utilizarse por el SCL solicitante para solicitar un SCL objetivo (SCL2) para transferir un contexto de registro de un tercer SCL registrado con SCL2, o un contexto de registro de una aplicación que se ha registrado con el tercer SCL. Una vez que el SCL solicitante solicita la transferencia, el SCL objetivo puede recuperar la información del SCL origen. Alternativamente, el SCL solicitante puede solicitar directamente al SCL origen el transferir la transferencia de registro de capacidad de servicio al SCL objetivo.

Un SCL origen puede transmitir o multidifundir a los SCLs vecinos, el contexto de registro de SCLs y las aplicaciones que se han registrado al SCL origen. La cantidad de información que se transmite, podrá adaptarse para reducir la carga de señalización. Por ejemplo, el SCL origen podrá transmitir la información parcial acerca de las aplicaciones registradas. Los SCLs interesados podrán entonces solicitar el contexto de registro completo .

A fin de decidir con qué SCLs la información podrá compartirse, los SCLs podrán tener una lista pre - con fi gurada de los SCLs vecinos para compartir la información. Por ejemplo, en un depósito, la lista puede ser una lista de vías de acceso en el depósito. Alternativamente, los SCLs pueden descubrir cuáles son los SCLs vecinos y determinar por si mismos con qué otros SCLs podrá compartirse la información. Alternativamente, una entidad central podrá conectarse a los SCLs y la entidad central puede informar a los SCLs el cómo compartir la información.

Los casos e j empl i fi cat ivo s para la transferencia de capacidad de servicio y el soporte de movilidad para los dispositivos M2M con y sin capacidades de servicio, se explican con referencia a las FIGS. 15-26.

La FIG. 15 es un flujo de señalización ej emplif icativo para la transferencia de capacidad de servicio cuando un dispositivo M2M entra a la cobertura de vía de acceso e inicia el cambio. La capacidad de servicio de dispositivo 2 se registra inicialmente con la capacidad de servicio de red (1501) . El dispositivo M2M se mueve y entra al área de cobertura de via de acceso (1502) . El dispositivo M2M descubre la capacidad de servicio (1503) . La capacidad de servicio de dispositivo M2M solicita utilizar la capacidad de servicio de via de acceso (1504) . La capacidad de servicio de via de acceso solicita la transferencia de información de registro de la capacidad de servicio de red (1505) . La capacidad de servicio de red empuja la información de registro a la via de acceso (1506) . La capacidad de servicio de via de acceso entonces otorga la solicitud de utilizar la capacidad de servicio (1507) .

La FIG. 16 es un flujo de señalización ej emplif icativo para la transferencia de capacidad de servicio cuando un dispositivo M2M entra a la cobertura de vía de acceso y una red inicia el cambio. La capacidad de servicio de dispositivo M2M se registra inicialmente con la capacidad de servicio de red (1601) . El dispositivo M2M se mueve y entra al área de cobertura de via de acceso (1602) . El dispositivo M2M descubre la capacidad de servicio de via de acceso (1603) . El dispositivo M2M notifica la red que se encuentra bajo el área de cobertura de la via de acceso (1604) . La red solicita al dispositivo M2M que se transfiera a la via de acceso (1605) . La capacidad de servicio de dispositivo M2M solicita utilizar la capacidad de servicio de via de acceso (1606) . La capacidad de servicio de via de acceso solicita la transferencia de información de registro de la capacidad de servicio de red (1607) . La capacidad de servicio de red empuja la información de registro a la via de acceso (1608) . La capacidad de servicio de via de acceso entonces otorga la solicitud para utilizar la capacidad de servicio (1609) .

La FIG. 17 es un flujo de señalización e empl i fi cat ivo para la transferencia de capacidad de servicio cuando un dispositivo M2M deja la cobertura de vía de acceso en caso de visibilidad completa. La capacidad de servicio de dispositivo M2M se registra con la capacidad de servicio de vía de acceso (1701) . La capacidad de servicio de via de acceso empuja la información de registro de dispositivo a la capacidad de servicio de red (1702) . El dispositivo M2M se mueve y sale del área de cobertura de via de acceso (1703) . El dispositivo 2M descubre la capacidad de servicio de red (1704) . La capacidad de servicio de dispositivo M2M solicita utilizar la capacidad de servicio de red (1705) . Ya que la información de dispositivo ya se encuentra en la red, la capacidad de servicio de red otorga la solicitud para utilizar la capacidad de servicio (1706) .

La FIG. 18 es un flujo de señalización e j empl i fi cat ivo para la transferencia de capacidad de servicio cuando un dispositivo M2M sale de la cobertura de via de acceso en caso de no visibilidad. La capacidad de servicio de dispositivo M2M se registra con la capacidad de servicio de via de acceso (1801) . El dispositivo M2M se mueve y sale del área de cobertura de vía de acceso (1802) . El dispositivo M2M descubre la capacidad de servicio de red (1803) . La capacidad de servicio de dispositivo M2M solicita utilizar la capacidad de servicio de red (1804) . El dispositivo M2M también informa la dirección del último punto de unión. La capacidad de servicio de red solicita la información de registro del dispositivo de la capacidad de servicio de via de acceso (1805) . La capacidad de servicio de via de acceso empuja la información de registro a la capacidad de servicio de red (1806) . La capacidad de servicio de red otorga la solicitud para utilizar la capacidad de servicio (1807) .

La FIG. 19 es un flujo de señalización ej empl i f i cat ivo para la transferencia de capacidad de servicio cuando un dispositivo M2M entra a una nueva cobertura de via de acceso en caso de total visibilidad. La capacidad de servicio de dispositivo M2M se registra con la capacidad de servicio de via de acceso 1 (1901) . La capacidad de servicio de via de acceso 1 empuja la información del registro de dispositivo a la capacidad de servicio de red (1902) . El dispositivo M2M se mueve y sale del área de cobertura de vía de acceso (1903) . El dispositivo M2M descubre la capacidad dé servicio de vía de acceso 2 (1904) . La capacidad de servicio de dispositivo 2M solicita utilizar la capacidad de servicio de vía de acceso 2 (1905) . La capacidad de servicio de via de acceso 2 solicita la información de registro del dispositivo M2M de la capacidad de servicio de red (1906) . La capacidad de servicio de red empuja la información de registro a la capacidad de servicio de via de acceso 2 (1907) . La capacidad de servicio de via de acceso 2 otorga la solicitud de utilizar la capacidad de servicio (1908) .

La FIG. 20 es un flujo de señalización ej emplificativo para la transferencia de capacidad de servicio cuando un dispositivo M2M entra a una nueva cobertura de via de acceso en caso de no visibilidad. La capacidad de servicio de dispositivo M2M se registra con la capacidad de servicio de via de acceso 1 (2001) . El dispositivo M2M se mueve y sale del área de cobertura de vía de acceso (2002) . El dispositivo M2M descubre la capacidad de servicio de vía de acceso 2 (2003) . La capacidad de servicio de dispositivo 2M solicita utilizar la capacidad de servicio de vía de acceso 2 (2004) . El dispositivo M2M también informa la dirección del último punto de unión. La capacidad de servicio de vía de acceso 2 solicita la información de registro del dispositivo M2M de la capacidad de servicio de red (2005) . La vía de acceso también informa la dirección del último punto de unión del dispositivo M2M. La capacidad de servicio de red solicita la información de registro del dispositivo M2M de la capacidad de servicio de vía de acceso 1 (2006) . La capacidad de servicio de vía de acceso 1 empuja la información de registro de dispositivo a la capacidad de servicio de red (2007) . La capacidad de servicio de red empuja la información de registro a la capacidad de servicio de vía de acceso 2 (2008) . La capacidad de servicio de vía de acceso 2 otorga la solicitud para utilizar la capacidad de servicio (2009) .

La FIG. 21 es un flujo de señalización ej emplificativo para el soporte de movilidad cuando un dispositivo M2M que no tiene capacidad de servicio ientra a la cobertura de; área e inicia el cambio. La aplicación de dispositivo M2M inicialmente se registra con la capacidad de servicio de red (2101) . El dispositivo M2M se mueve y entra al área de cobertura de vía de acceso (2102) . El dispositivo M2M descubre la capacidad de servicio de vía de acceso (2103) . La aplicación de dispositivo M2M se registra con la capacidad de servicio de via de acceso (2104) .

La FIG. 22 es un flujo de señalización e j empl i fi cat i o para el soporte de movilidad cuando un dispositivo M2M que no tiene capacidad de servicio entra a la cobertura de via de acceso y una red inicia el cambio. La aplicación de dispositivo M2M se registra inicialmente con la capacidad de servicio de red (2201) . El dispositivo M2M se mueve y entra al área de cobertura de via de acceso (2202) . El dispositivo M2 descubre la capacidad de servicio de via de acceso (2203) .

El dispositivo M2M notifica a la red que se encuentra bajo el área de cobertura de la vía de acceso (2204) . La red solicita al dispositivo M2M que se; transfiera a la via de; acceso (2205) . La aplicación de dispositivo M2 se registra con la capacidad de servicio de via de acceso (2206) . La capacidad de servicio de via de acceso empuja la información de registro a la capacidad de servicio de red en caso de completa visibilidad (2207) .

Alternativamente, la red puede empujar la información de aplicación de dispositivo a la via de acceso, y el dispositivo puede solicitar a la via de acceso que utilice la capacidad de servicio de la via de acceso, y ya que la información ya se encuentra disponible en la via de acceso, la via de acceso puede otorgar la solicitud del dispositivo.

La FIG. 23 es un flujo de señalización e j emplificativo para la transferencia de capacidad de servicio cuando un dispositivo M2M que no tiene capacidad de servicio sale de la cobertura de via de acceso en caso de completa visibilidad. La aplicación de dispositivo M2M se registra con la capacidad de servicio de via de acceso (2301) . La capacidad de servicio de via de acceso anuncia las aplicaciones de dispositivo a la capacidad de servicio de red (2302) . El dispositivo^ M2M se mueve y sale del área de cobertura de via de acceso (2303) . El dispositivo 2M descubre la capacidad de servicio de red (2304) . La aplicación de dispositivo M2M se registra con la capacidad de servicio de red (2305) . Alternativamente, la via de acceso puede empujar la información de aplicación de dispositivo a la red, y el dispositivo puede solicitar a la red que utilice la capacidad de servicio de red, y ya que la información ya se encuentra disponible en la red, la red puede otorgar la solicitud del dispositivo.

La FIG. 24 es un flujo de señalización e j empl i f i cat ivo para la transferencia de capacidad de servicio cuando un dispositivo M2M que no tiene capacidad de servicio sale de la cobertura de via de acceso en caso de no visibilidad. La aplicación de dispositivo M2M se registra con la capacidad de servicio de via de acceso (2401) . El dispositivo M2M se mueve y sale del área de cobertura de via de acceso (2402) . El dispositivo M2M descubre la capacidad de servicio de red (2403) . La aplicación de dispositivo M2M se registra con la capacidad de servicio de red (2404) .

La FIG. 25 es un flujo de señalización e j empl i ficat ivo para la transferencia de capacidad de servicio cuando un dispositivo M2M que no tiene capacidad de servicio entra a una nueva cobertura de via de acceso en caso de completa visibilidad. La aplicación de dispositivo M2M se registra con la capacidad de servicio de via de acceso (2501) . La capacidad de servicio de via de acceso 1 anuncia la aplicación de dispositivo a la red (2502) . El dispositivo M2M se mueve y sale del área de cobertura de via de acceso 1 (2503) . El dispositivo M2M descubre la capacidad de servicio de via de acceso 2 (2504) . La aplicación de dispositivo M2M se registra con la capacidad de servicio de via de acceso 2 (2505) . La capacidad de servicio de via de acceso 2 anuncia la aplicación de dispositivo a la red (2506) .

La FIG. 26 es un flujo de señalización e j emplif icativo para la transferencia de capacidad de servicio cuando un dispositivo M2M que no tiene capacidad de servicio ingresa a nueva cobertura de vía de acceso en caso de no visibilidad. La aplicación de dispositivo 2M se registra con la capacidad de servicio de vía de acceso 1 (2601) . El dispositivo M2M se mueve y sale del área de cobertura de vía de acceso 1 (2602). El dispositivo M2M descubre la capacidad de servicio de vía de acceso 2 (2603) . La aplicación de dispositivo M2M se registra con la capacidad de servicio de vía de acceso 2 (2604) .

Modalidades . 1. Un método para soportar las comunicaciones M2M. 2. El método de la modalidad 1 comprendiendo una entidad M2M que lleva a cabo un procedimiento de descubrimiento de capacidad de servicio para descubrir una entidad de capacidad de servicio M2M que proporciona una capacidad de servicio M2M. 3. El método de la modalidad 2 comprendiendo la entidad M2M que lleva a cabo el registro con al menos una entidad de capacidad de servicio M2M descubierta que utiliza una identidad o dirección obtenida durante el procedimiento de descubrimiento de capacidad de servicio. 4. El método de ! la modalidad 3 en donde el registro se lleva a cabo con una dirección o identidad pre-conf igurada . 5. El método según cualquiera de las modalidades 2-4, en donde el procedimiento de descubrimiento de capacidad de servicio comprende enviar una solicitud a un servidor despachador utilizando una dirección o identidad pre-conf igurada . 6. El método de la modalidad 5, en donde el procedimiento de descubrimiento de capacidad de servicio comprende recibir una lista de entidades de capacidad de servicio M2M del servidor despachador con identidades o direcciones de las entidades de capacidad de servicio M2M, en donde el registro se lleva a cabo con una entidad de capacidad de servicio M2 en la lista. 7. El método según cualquiera de las modalidades 2-6, en donde el procedimiento de descubrimiento de capacidad de servicio comprende enviar un primer mensaje en una via de acceso M2M, el primer mensaje incluyendo un identificador de servicio M2 soportado por la entidad M2M. 8. El método de la modalidad 7 en donde el procedimiento de descubrimiento de capacidad de servicio comprende recibir, de la via de acceso M2M, un segundo mensaje que indica una entidad de capacidad de servicio M2M y una identidad o dirección de la entidad de capacidad de servicio M2M. 9. El método de la modalidad 8, en donde el registro se lleva a cabo con la entidad de capacidad de servicio M2M indicada en el segundo mensaje. 10. El método según cualquiera de las modalidades 2-9, en donde el procedimiento de descubrimiento de capacidad de servicio comprende recibir un mensaje de publicidad de una via de acceso M2M, el mensaje de publicidad incluyendo una lista de identificadores de servicio M2M soportados por la via de acceso M2M . 11. El método de la modalidad 10 en donde el procedimiento de descubrimiento de capacidad de servicio comprende comparar un i denti fi cado r de servicio M2M soportado por la entidad M2M con la lista de identificadores de servicio M2M contenida en el mensaje de publicidad. 12. El método de la modalidad 11, en donde el primer mensaje se envía sobre una condición de que exista una sincronización entre el identificador de servicio M2M soportado por la entidad M2M y la lista de identificadores de servicio M2M. 13. El método según cualquiera de las modalidades 2-12, en donde el procedimiento de descubrimiento de capacidad de servicio comprende enviar un primer mensaje a una red central que incluye un identificador de servicio M2M soportado por la entidad M2M. 14. El método de la modalidad 13 en donde el procedimiento de descubrimiento de capacidad de servicio comprende recibir un segundo mensaje que incluye una lista de identidades o direcciones de las entidades de capacidad de servicio M2M. 15. El método de la modalidad 14, en donde el registro se lleva a cabo con una entidad de capacidad de servicio M2M incluida en el segundo mensaje. 16. El método según cualquiera de las modalidades 2-15, comprendiendo además llevar a cabo un intercambio de capacidad de servicio con la entidad de capacidad de s-ervicio M2M descubierta . 17. El método según cualquiera de las modalidades 2-16, comprendiendo además llevar a cabo un descubrimiento de jerarquía para determinar una jerarquía de una red a la cual pertenece la entidad M2M. 18. El método de la modalidad 17, en donde la entidad M2M incluye la información de jerarquía en un mensaje enviado para el registro. 19. El método según cualquiera de las modalidades 17-18, comprendiendo además enviar un mensaje de rastreo a la entidad de capacidad de servicio M2M a registrar, en donde las identidades de nodos intermediarios se registran en el mensaje de rastreo. 20. El método según cualquiera de las modalidades 2-19, en donde la entidad M2M es una vía de acceso M2M. 21. El método de la modalidad 20, en donde la vía de acceso M2M incluye al menos una de las funcionalidades relacionadas al descubierto de la capacidad de servicio a través de una arquitectura jerárquica, configuración de capacidad de servicio a través de una arquitectura jerárquica, GMDAE, RADAR, NCSS, HDR, SC, GMAE, MDGM, capacidad CB, MDGP, o servicio de ubicación. 22. Un dispositivo para soportar las comunicaciones M2M. 23. El dispositivo de la modalidad 22 comprendiendo un procesador configurador para llevar a cabo un procedimiento de descubrimiento de capacidad de servicio para descubrir una entidad de capacidad de servicio M2M que proporciona una capacidad de servicio M2M . 24. El dispositivo de la modalidad 23 en donde el procesador se configura para llevar a cabo el registro con al menos una entidad de capacidad de servicio 2M descubierto que utiliza una identidad o dirección obtenida durante el procedimiento de descubrimiento de capacidad de servicio. 25. El dispositivo de la modalidad 24 en donde el procesador se configura para llevar a cabo el registro con una dirección o identidad pre-conf igurada . 26. El dispositivo según cualquiera de las modalidades 24-25, en donde el procesador se configura para enviar una solicitud a un servidor despachador que utiliza una dirección o identidad pre-configurada , recibir una lista de entidades de capacidad de servicio M2M del servidor despachador con identidades o direcciones de las entidades de capacidad de servicio M2 , y llevar a cabo el registro con una entidad de capacidad de servicio M2M en la lista . 27. El dispositivo según cualquiera de las modalidades 24-26, en donde el procesador se configura para enviar un primer mensaje a una via de acceso M2M, el primer mensaje incluyendo un identificador de servicio M2M soportado por la entidad M2M, recibir, de la via de acceso M2M, un segundo mensaje indicando una entidad de capacidad de servicio M2M y una identidad o dirección de la entidad de capacidad de servicio 2M, y llevar a cabo el registro con la entidad de capacidad de servicio M2M indicada en el segundo mensaje. 28. El dispositivo según cualquiera de las modalidades 24-27, en donde el procesador se configura para recibir un mensaje de publicidad de una vía de acceso M2M, el mensaje de publicidad incluyendo una lista de identificadores de servicio M2M soportada por la vía de acceso 2M, comparar un identificador de servicio M2M soportado por la entidad M2M con la lista de identificadores de servicio 2M contenida en el mensaje de publicidad, y enviar el primer mensaje sobre una condición de que exista una sincronización entre el identificador de servicio M2 soportado por la entidad M2M y la lista de identificadores de servicio M2M. 29. El dispositivo según cualquiera de las modalidades 24-28, en donde el procesador se configura para enviar un primer mensaje a una red central incluyendo un identi ficador de servicio M2M soportado por la entidad M2M, recibir un segundo mensaje incluyendo una lista de identidades o direcciones de entidades de capacidad de servicio M2M, y llevar a cabo el registro con una entidad de capacidad de servicio M2M incluida en el segundo mensaje. 30. El dispositivo según cualquiera de las modalidades 24-29, en donde el procesador se configura para llevar a -cabo un intercambio de capacidad de servicio con la entidad de capacidad de servicio M2 descubierta. 31. El dispositivo según cualquiera de las modalidades 24-30, en donde el procesador se configura para llevar a cabo un descubrimiento de jerarquía para determinar una jerarquía de una red a la cual pertenece la entidad M2M. 32. El dispositivo de la modalidad 31 en donde el procesador se configura para incluir la información de jerarquía en un mensaje enviado para el registro. 33. El dispositivo según cualquiera e las modalidades 31-32, en donde el procesador se configura para enviar un mensaje de rastreo a la entidad de capacidad de servicio M2M a registrar, en donde las identidades de nodos intermedios se registran en el mensaje de ras t reo . 34. El dispositivo según cualquiera de las modalidades 24-33, en donde el dispositivo se encuentra en una vía de acceso M2M. 35. El dispositivo de la modalidad 34, en donde el dispositivo incluye al menos una de las ' funcionalidades relacionadas al descubrimiento de la capacidad de servicio a través de una arquitectura jerárquica, configuración de capacidad de servicio a través de una arquitectura jerárquica, GMDAE, RADAR, NCSS, HDR, SC, GMAE, MDGM, capacidad CB, MDGP, o servicio de ubicación.

A pesar de que las características y los elementos se describen anteriormente en combinaciones en particular, un experto en la materia apreciará que cada característica o elemento podrá utilizarse solo (a) o en cualquier combinación con las otras características y elementos. Además, los métodos descritos en la presente, podrán implement ar se en un programa de computadora, software, o firmware incorporado en un medio leíble por computadora para ejecución por una computadora o un procesador. Los ejemplos de medios leíbles por computadora incluyen señales electrónicas (transmitidas sobre conexiones inalámbricas o con cable) y medios de almacenamiento leíble por computadora. Los medios de almacenamiento leíbles por computadora incluyen, pero no se limitan a, una memoria de sólo lectura (ROM), una memoria de acceso aleatorio (RAM), un registrador, memoria asociada, dispositivo de memoria semiconductora, medios magnéticos tales como discos duros internos y discos removibles, medios magnet o -ópt i co s , y medios ópticos tales como discos CD-ROM, y discos versátiles digitales (DVDs) . Un procesador en asociación con el software, podrá utilizarse para implementar un transceptor de radiofrecuencia para uso en una WTRU, UE, terminal, estación base, RNC, o cualquier otra computadora huésped .

Claims

REIVINDICACIONES

1. Un método para soportar las comunicaciones máquina a máquina (M2M), el método comprendiendo: una entidad M2M que lleva a cabo un procedimiento de descubrimiento de capacidad de servicio para descubrir una entidad de capacidad de servicio M2M que proporciona una capacidad de servicio M2M, en donde la entidad M2M proporciona información con respecto a los servicios M2M que se soportan por la entidad M2M durante el procedimiento de descubrimiento de capacidad de servicio de tal manera que una lista de entidades de capacidad de servicio 2M que se adapta para la entidad M2M, se obtiene durante el procedimiento de descubrimiento de capacidad de servicio; y, la entidad M2M que lleva a cabo el registro con al menos una de las entidades de capacidad de servicio M2M descubiertas utilizando una identidad o dirección obtenida durante el procedimiento de descubrimiento de capacidad de servicio.

2. El método según la reivindicación 1, en donde el registro se lleva a cabo con una identidad o dirección pre - con fi gurada .

3. El método según la reivindicación 1, en donde el procedimiento de descubrimiento de capacidad de servicio, comprende: enviar una solicitud a un servidor despachador que utiliza una identidad o dirección pre-conf igurada ; y, recibir una lista de entidades de capacidad de servicio M2M del servidor despachador con identidades o direcciones de las entidades de capacidad de servicio M2M, en donde el registro se lleva a cabo con una entidad de capacidad de servicio M2M en la lista.

4. El método según la reivindicación 1, en donde el procedimiento de descubrimiento de capacidad de servicio comprende: enviar un primer mensaje a una via de acceso M2M, el primer mensaje incluyendo un ident i f icador de servicio M2M soportado por la entidad M2M; y, recibir, de la via de acceso M2M, un segundo mensaje que indica una entidad de capacidad de servicio M2M y una identidad o dirección de la entidad de capacidad de servicio M2M, en donde el registro se lleva a cabo con la entidad de capacidad de servicio M2 indicada en el segundo mensaje.

5. El método según la reivindicación 4, en donde el procedimiento de descubrimiento de capacidad de servicio comprende: recibir un mensaje de publicidad de una vía de acceso M2M, el mensaje de publicidad incluyendo una lista de identificadores de servicio M2M soportada por la vía de acceso M2M; y, comparar un identi ficador de servicio M2M soportado por la entidad M2M con la lista de identificadores de servicio M2M contenida en el mensaje de publicidad, en donde el primer mensaje se envía sobre una condición de que exista una sincronización entre el identi f icador de servicio M2 soportado por la entidad M2M y la lista de identificadores de servicio M2M.

6. El método según la reivindicación 1 en donde el procedimiento de descubrimiento de capacidad de servicio comprende: enviar un primer mensaje a una red central incluyendo un identificador de servicio M2M soportado por la entidad M2M; y, recibir un segundo mensaje que incluye una lista de identidades o direcciones de las entidades de capacidad de servicio M2M, en donde el registro se lleva a cabo con una entidad de capacidad de servicio M2M incluida en el segundo mensaje.

7. El método según la reivindicación 1, comprendiendo: llevar a cabo un intercambio de capacidad de servicio con la entidad de capacidad de servicio M2M descubierta.

8. El método según la reivindicación 1, comprendiendo además: llevar a cabo un descubrimiento de jerarquía para determinar una jerarquía de una red a la cual pertenece la entidad M2M.

9. El método según la reivindicación 8, en donde la entidad M2M incluye la información de jerarquía en un mensaje enviado para el registro.

10. El método según la reivindicación 8, comprendiendo además: enviar un mensaje de rastreo a la entidad de capacidad de servicio M2M a registrar, en donde las identidades de los nodos intermedios se registran en el mensaje de rastreo.

11. El método según la reivindicación 1, en donde la entidad M2M es una vía de acceso M2M, y la vía de acceso M2M incluye al menos una de las funcionalidades relacionadas al descubrimiento de la capacidad de servicio a través de una estructura jerárquica, la configuración de la capacidad de servicio a través de una arquitectura jerárquica, autorización de aplicación de dispositivo genérico' M2M (GMDAE), ¦ asequibilidad, repositorio de aplicación de dispositivo y dirección (RADAR), selección de servicio de comunicación y red (NCSS), historia y retención de datos (HDR), capacidad de seguridad (SC), autorización de aplicación de red genérica M2M (GMAE) , manejo de via de acceso M2M y dispositivo M2M (MDGM), capacidad de mediación por compensación (CB), proxy de via de acceso M2M y dispositivo M2M (MDGP) , o servicio de ubicación .

12. Un dispositivo para soportar las comunicaciones máquina a máquina (M2M), el dispositivo comprendiendo: un procesador configurado para llevar a cabo un procedimiento de descubrimiento de capacidad de servicio para descubrir una entidad de capacidad de servicio M2M que proporciona una capacidad de servicio M2M, y llevar a cabo el registro con al menos una de las entidades de capacidad de servicio M2M descubiertas utilizando una identidad o dirección obtenida durante el procedimiento de descubrimiento de capacidad de servicio, en donde el procesador se configura para proporcionar la información con respecto a los servicios M2M que se soportan por el dispositivo durante el procedimiento de descubrimiento de capacidad de servicio de tal manera que una lista de entidades de capacidad de servicio M2M que se adapta para el dispositivo, se obtiene durante el procedimiento de descubrimiento de capacidad de servicio .

13. El dispositivo según la reivindicación 12, en donde el procesador se configura para llevar a cabo el registro con una identidad o dirección pre-conf igurada .

14. El dispositivo según la reivindicación 12, en donde el procesador se configura para enviar una solicitud a un servidor despachador utilizando una identidad o dirección pre-conf igurada , recibir una lista de entidades de capacidad de servicio M2M del servidor despachador con identidades o direcciones de las entidades de capacidad de servicio M2M, y llevar a cabo el registro con una entidad de capacidad de servicio M2M en la lista .

15. El dispositivo según la reivindicación 12, en donde el procesador se configura para enviar un primer mensaje a una via de acceso M2M, el primer mensaje incluyendo un ident i fi cado r de servicio M2M soportado por la entidad M2M, recibir, de la via de acceso M2M, un segundo mensaje indicando una entidad de capacidad de servicio M2M y una identidad o dirección de la entidad de capacidad de servicio M2M, y llevar a cabo el registro con la entidad de capacidad de servicio M2M indicada en el segundo mensaje.

16. El dispositivo según la reivindicación 15, en donde el procesador se configura para recibir un mensaje de publicidad de una vía de acceso M2M, el mensaje de publicidad incluyendo una lista de identificadores de servicio M2M soportada por la vía de acceso M2M, comparar un identif icador de servicio M2M soportado por la entidad M2M con la lista de identificadores de servicio M2M contenida en el mensaje de publicidad, y enviar el primer mensaje sobre una condición de que exista una sincronización entre el i dent i fi cado r de servicio M2M soportado por la entidad 2M y la lista de identi icadores de servicio M2M.

17. El dispositivo según la reivindicación 12, en donde el procesador se configura para enviar un primer mensaje a una red central incluyendo un identif icador de servicio M2M soportado por la entidad M2M, recibir un segundo mensaje incluyendo una lista de identidades o direcciones de entidades de capacidad de servicio M2M, y llevar a cabo el registro con una entidad de capacidad de servicio M2M incluida en el segundo mensaje.

18. El dispositivo según la reivindicación 12, en donde el procesador se configura para llevar a cabo un intercambio de capacidad de servicio con la entidad de capacidad de servicio M2M descubierta.

19. El dispositivo según la reivindicación 12, en donde el procesador se configura para llevar a cabo un descubrimiento de jerarquía para determinar una jerarquía de una red a la cual pertenece la entidad M2M.

20. El dispositivo según la reivindicación 19, en donde el procesador se configura para incluir la información de jerarquía en un mensaje enviado para el registro.

21. El dispositivo según la reivindicación 19, en donde el procesador se configura para enviar un mensaje de rastreo a la entidad de capacidad de servicio M2M a registrar, en donde las identidades de los nodos intermedios se registran en el mensaje de rastreo.

22. El dispositivo según la reivindicación 12, en donde el dispositivo es una vía de acceso M2M, e incluye al menos una de las funcionalidades relacionadas al descubrimiento de la capacidad de servicio a través de una arquitectura jerárquica, configuración de capacidad de servicio a través de una arquitectura jerárquica, autorización de aplicación de dispositivo genérico M2M (G DAE), asequibilidad, repositorio de aplicación de dispositivo y dirección (RADAR), selección de servicio de comunicación y red (NCSS), historia y retención de datos (HDR), capacidad de seguridad (SC), autorización de aplicación de red genérica M2M (GMAE) , manejo de vía de acceso M2M y dispositivo M2M (MDGM), capacidad de mediación por compensación (CB), proxy de vía de acceso M2M y dispositivo M2M (MDGP) , o servicio de ubicación. RESUMEN Se describen el método y aparato para soportar comunicaciones de máquina a máquina (M2M) en una arquitectura de red de computadoras jerárquica que incluye una via de acceso M2M. Una entidad M2M, (tal como un dispositivo M2M, via de acceso M2M, o entidad de red 2M) , podrá llevar a cabo un procedimiento de descubrimiento de capacidad de servicio para descubrir una entidad de capacidad de servicio M2M que pueda proporcionar una capacidad de servicio 2M, y registrarse con la entidad de capacidad de servicio M2M descubierta. La dirección o la identidad de la entidad de capacidad de servicio podrá ser pre - con fi gurada u obtenida del servidor despachador. La entidad 2 puede indicar un ident i fi cado r de servicio M2M de soporte y recibir una identidad o dirección de la entidad de capacidad de servicio 2M que mapea el identif icador de servicio. La via de acceso podrá advertir a los identificadores de servicio M2M soportados por la via de acceso, de tal manera que el dispositivo M2M podrá tener acceso a la via de acceso si existe una sincronización. La dirección de las entidades de capacidad de servicio M2M podrá obtenerse de la red central .