Mecanismo y método de detección de colisión de Protocolo Ligero de Acceso a Directorios (LDAP).

Un método para detectar y evitar colisiones en una entrada en un directorio con Protocolo Ligero de Acceso a Directorios (LDAP”

(Lightweight Director y Access Protocol, en inglés), mediante operaciones de actualización desde el ordenador frontal de más de un cliente (FE DE HSS, FE DE HLR), comprendiendo el citado método las etapas de:

- recibir en el directorio una solicitud del ordenador frontal de un cliente de leer datos en una entrada al directorio;

- asignar en el directorio al menos un valor de detección de colisión dado para al menos un subconjunto de los datos en la entrada al directorio, donde al al menos un valor de detección de colisión dado se le proporciona un atributo de contador de detección de colisión, CDC (Collision Detection Counter, en inglés), que tiene un valor (x) en la entrada al directorio;

- enviar hacia el ordenador frontal del cliente los datos solicitados junto con el al menos un valor de detección de colisión dado;

- recibir en el directorio una solicitud desde el ordenador frontal de un cliente de modificar el al menos un subconjunto de los datos en la entrada al directorio, teniendo la solicitud al menos un valor de detección de colisión actualizado para cada al menos un valor de detección de colisión dado, donde la solicitud que tiene el al menos un valor de detección de colisión actualizado incluye:

(i) una o más operaciones de AÑADIR como sigue AÑADIR: CDC ≥ (x) + 1, AÑADIR: CDC ≥ (x) + 2…AÑADIR: CDC ≥ (x) + Número de Colisiones para Detectar, NCD, donde NCD tiene un valor igual o mayor que el número de clientes concurrentes que podrían posiblemente leer y modificar los datos de la entrada al directorio;

(ii) datos modificados; y

(iii) una operación de REEMPLAZAR como sigue: REEMPLAZAR: CDC ≥ (x) + 1; determinando en el directorio si la solicitud incluye una operación de AÑADIR que intente operar en un atributo de CDC actual asignado al al menos un subconjunto de datos y que tiene un valor diferente dentro de la entrada al al menos un valor de atributo de CDC (x) dado enviado al ordenador frontal del cliente;

- si el resultado de la etapa de determinación es negativo, enviar hacia el ordenador frontal del cliente una aceptación de la solicitud de modificar el al menos un subconjunto de los datos en la entrada al directorio y asignar al valor de detección de colisión actual en la entrada un valor siguiente (x) +1, y si no enviar la denegación de la solicitud hacia el ordenador frontal del cliente.

Mecanismo y método de detección de colisión de Protocolo Ligero de Acceso a Directorios (LDAP)

RIVINDICACIÓN DE SOLICITUD DE U.S. ANTERIORMENTE ENVIADA Esta solicitud reclama la Solicitud de Patente Provisional de U.S. de Nº de Serie 60/985.710, que fue presentada el 6 de Noviembre de 2007.

CAMPO TÉCNICO La presente invención se refiere a un mecanismo de detección de colisión de LDAP y a un método para permitir que un cliente de LDAP detecte y evite una colisión de operación de actualización en una entrada dentro de un directorio de LDAP.

ANTECEDENTES Se definen aquí las siguientes abreviaturas, a algunas de las cuales se hace referencia en la siguiente descripción de la técnica anterior y de la presente invención.

AAA Autenticación, Autorización y Contabilidad (Authentication, Authorization and Accounting, en inglés)

CAS Sistema de Administración de Abonados (Customer Administration System, en inglés)

CDC Contador de Detección de Colisiones (Collision Detection Counter, en inglés)

CS Circuitos Conmutados (Circuit Switched, en inglés)

DIT Árbol de Información de Directorios (Director y Information Tree, en inglés)

DN Nombre Distinguido (Distinguished Name, en inglés)

FE Ordenador Frontal (Front End, en inglés)

EMA Multi Activación de Ericsson (Ericsson Multi Activation, en inglés)

GSM Sistema Global para Comunicaciones mediante Telefonía Móvil (Global System for Mobile Communications, en inglés)

HLR Registro de Ubicación Local (Home Location Register, en inglés)

HSS Servidor de Abonados Local (Home Subscriber Server, en inglés)

IT Tecnología de la Información (Information Technology, en inglés)

LDAP Protocolo Ligero de Acceso a Directorios (Lightweight Director y Access Protocol, en inglés)

MAP Parte de Aplicación de Móviles (Mobile Application Part, en inglés)

NDC Número de Colisiones para ser Detectadas

PS Paquetes Conmutados (Packet Switched, en inglés)

En el campo de las comunicaciones, la arquitectura de la base de datos de abonados actual está siendo retada por una arquitectura que está apareciendo de tecnología de IT de corriente principal donde los datos del abonado se guardan en una o más bases de datos separadas de los nodos que proporcionan el servicio específico. Este planteamiento se denomina una arquitectura de multicapa y un dibujo de ejemplo que ilustra gráficamente este tipo de arquitectura que se utiliza en el campo de las comunicaciones de telecomunicaciones inalámbricas se muestra en la FIGURA 1.

En referencia a la FIGURA 1, se ilustra una red de comunicaciones 100 que tiene una red de IMS 101 que incluye un FE de HSS 102 y un FE de aprovisionamiento 104 y una red de núcleo 106 de CS/PS que incluye un FE de HLR/AuC 108 y un FE de AAA 110. El FE de HSS 102, el FE de aprovisionamiento 104, el FE de HLR/AuC 108 y el FE de AAA 110 se comunican todos ellos con una base de datos centralizada 112, que puede estar acoplada a un EMA 114 (por ejemplo, un dispositivo de aprovisionamiento de suscripción) , que a su vez está acoplado a un CAS convencional 116. La red de IMS 101 y la red de núcleo 106 de CS/PS etc... incluyen más componentes que los mostrados en esta memoria, pero en aras de la claridad sólo los componentes que son relevantes para la presente explicación se han descrito en esta memoria.

Esta arquitectura de multicapa proporciona varias ventajas, la no menor de las cuales es la menos costosa escalabilidad en la capa lógica de servicio o la capacidad para consolidar los datos del abonado de manera que la administración de los abonados es más fácil y menos costosa en comparación con las redes de comunicación mediante telefonía móvil tradicionales. En esta arquitectura de multicapa, los nodos monolíticos tradicionales (incluyendo la lógica tanto de datos como de procesamiento) tales como el HSS, el HLR y el AAA han evolucionado para procesar ordenadores frontales (FE – Front Ends, en inglés) como el FE de HSS 102, el FE de aprovisionamiento 104, el FE de HLR/Auc 108 y el FE de AAA 110, mientras que los datos residen ahora en la base de datos centralizada 112 ó en una base de datos distribuida accesible para los ordenadores frontales anteriores, 102, 104, 108 y 110.

En esta arquitectura de multicapa, el FE de HLR/AuC 108 (por ejemplo) tras recibir algún evento externo (es decir, un mensaje de MAP) desde la red de núcleo de CS/PS 106, tiene que leer datos relativos al abonado de la base de datos centralizada 112, procesar esos datos leídos a la vista de los datos recibidos de la red de núcleo de CS/PS

106, y dependiendo del resultado de este procesamiento interno puede desear modificar los datos relativos al abonado que están actualmente almacenados dentro de la base de datos centralizada 112. Una explicación detallada acerca de este proceso se proporciona a continuación con respecto a la FIGURA 2 (TÉCNICA ANTERIOR) donde la base de datos centralizada 112 es un directorio de LDAP 112 y el FE de HLR/AuC 108 es un cliente de LDAP 108.

En referencia a la FIGURA 2 (TÉCNICA ANTERIOR) , hay un diagrama de flujo de señal que ilustra cómo un cliente de LDAP 108 tradicional lee datos 202 de una entrada a un directorio de LDAP 112 tradicional (o servidor de LDAP 112) y modifica a continuación los datos 202 que están almacenados en la entrada del directorio de LDAP 112 tradicional. Las etapas asociadas con dónde lee el cliente 108 y a continuación modifica los datos son como sigue:

1a-1b. Lee algunos datos 202 de una entrada (o entradas) en el directorio de LDAP 112 en las que el cliente 108 está interesado, con cualquier propósito. Esto requiere que el cliente 108 envíe una operación de Solicitud de Búsqueda de LDAP al directorio de LDAP 112 (etapa 1a) . El servidor de LDAP 112 envía a continuación una copia de los datos 202 de la entrada (o entradas) utilizando una o más respuestas Respuesta a Búsqueda de LDAP (etapa 1b) .

2. El cliente 108 puede utilizar lógica de aplicación para procesar los datos leídos 202 con cualquier propósito, como por ejemplo, extraer información, procesar los datos leídos frente a algún otro dato internos, enviar los datos leídos a otro nodo/proceso, imprimir algunos resultados, evaluar algunas condiciones…. En este caso, el cliente 108 ha actualizado los datos 202’.

3a-3b. El cliente 108 desea llevar a cabo algunas actualizaciones en los datos 202 guardados en la entrada (o entradas) leída (o leídas) previamente en el directorio de LDAP 112. Esto requiere que el cliente 108 envíe una operación de Modificar Solicitud de LDAP con los datos actualizados 202’ al directorio de LDAP 112 (etapa 3a) (nota: una operación de Modificar Solicitud de LDAP sería necesaria para cada entrada al directorio cuya actualización se solicita) . El directorio de LDAP 112 actualiza la entrada para tener los datos 202’ y envía al cliente 108 un mensaje de éxito en una operación de Modificar Respuesta de LDAP (Resultado éxito) (etapa 3b) . Una sola operación de Modificar de LDAP aplica sólo a la entrada de objetivo, pero puede contener tantas operaciones de modificación (añadir/borrar/reemplazar) como se desee en el conjunto de tipos de atributos que se guardan en esa entrada particular.

Por desgracia, si hay más de uno o concurrentes clientes de LDAP 102 y 108 (por ejemplo) que pueden interactuar con el directorio de LDAP 112, entonces puede darse una situación problemática, como se muestra en la FIGURA 3 (TÉCNICA ANTERIOR) , en la que el cliente 102 (cliente 2) sobrescribe los datos 202 que fueron leídos previamente por el cliente de LDAP 108 (cliente 1) , pero que no fueron todavía modificados por el cliente de LDAP 108 (cliente 1) . Las etapas son como sigue:

1a. El cliente 1 solicita leer algunos datos 202 del directorio de LDAP 112. Este mensaje podría ser una solicitud de lectura de cualquier cantidad de datos, y cualquier BÚSQUEDA de LDAP estándar puede ser aplicable y ser utilizada para solicitar los datos 202.

1b. El cliente 1 recibe estos datos 202 solicitados del directorio de LDAP 112. Esto puede ser llevado a cabo por medio de uno o de varios mensajes de LDAP (Entrada de Resultado de Búsqueda de LDAP) , incluyendo un mensaje para indicar que toda la información solicitada ha sido enviada (Resultado de Búsqueda de LDAP Realizada) . En este momento, el cliente 1 puede tomarse algún tiempo para llevar a cabo alguna lógica interna, con cualquier propósito, como por ejemplo llevar a cabo alguna comprobación de consistencia de los datos leídos, conectarse a otro nodo para solicitar algún otro dato basándose en algo leído… En este caso, el cliente ha actualizado los datos 202’.

2a. El cliente 2 solicita la... [Seguir leyendo]

1. Un método para detectar y evitar colisiones en una entrada en un directorio con Protocolo Ligero de Acceso a Directorios (LDAP” (Lightweight Director y Access Protocol, en inglés) , mediante operaciones de actualización desde el ordenador frontal de más de un cliente (FE DE HSS, FE DE HLR) , comprendiendo el citado método las etapas de:

- recibir en el directorio una solicitud del ordenador frontal de un cliente de leer datos en una entrada al directorio;

- asignar en el directorio al menos un valor de detección de colisión dado para al menos un subconjunto de los datos en la entrada al directorio, donde al al menos un valor de detección de colisión dado se le proporciona un atributo de contador de detección de colisión, CDC (Collision Detection Counter, en inglés) , que tiene un valor (x) en la entrada al directorio;

- enviar hacia el ordenador frontal del cliente los datos solicitados junto con el al menos un valor de detección de colisión dado;

- recibir en el directorio una solicitud desde el ordenador frontal de un cliente de modificar el al menos un subconjunto de los datos en la entrada al directorio, teniendo la solicitud al menos un valor de detección de colisión actualizado para cada al menos un valor de detección de colisión dado, donde la solicitud que tiene el al menos un valor de detección de colisión actualizado incluye:

(i) una o más operaciones de AÑADIR como sigue AÑADIR: CDC = (x) + 1, AÑADIR: CDC = (x) + 2…AÑADIR: CDC = (x) + Número de Colisiones para Detectar, NCD, donde NCD tiene un valor igual o mayor que el número de clientes concurrentes que podrían posiblemente leer y modificar los datos de la entrada al directorio;

(ii) datos modificados; y

(iii) una operación de REEMPLAZAR como sigue: REEMPLAZAR: CDC = (x) + 1; determinando en el directorio si la solicitud incluye una operación de AÑADIR que intente operar en un atributo de CDC actual asignado al al menos un subconjunto de datos y que tiene un valor diferente dentro de la entrada al al menos un valor de atributo de CDC (x) dado enviado al ordenador frontal del cliente;

- si el resultado de la etapa de determinación es negativo, enviar hacia el ordenador frontal del cliente una aceptación de la solicitud de modificar el al menos un subconjunto de los datos en la entrada al directorio y asignar al valor de detección de colisión actual en la entrada un valor siguiente (x) +1, y si no enviar la denegación de la solicitud hacia el ordenador frontal del cliente.

2. El método de la reivindicación 1, en el que el ordenador frontal del cliente inicia una transacción con el directorio antes de enviar la solicitud de modificar los datos.

3. El método de la reivindicación 1, en el que el atributo de CDC es un atributo mandatorio en una clase de objetos de estructura deseados o en una nueva clase de objeto.

4. El método de la reivindicación 1, en el que el atributo de CDC es un contador cíclico.

5. Un directorio al que acceden un número de clientes con un Protocolo Ligero de Acceso a Directorios “LDAP” (Lightweight Director y Access Protocol, en inglés) para leer y actualizar los datos en él, y dispuesto para detectar y evitar una colisión de operación de actualización en una entrada al directorio, comprendiendo el directorio:

un medio de lectura de entrada que recibe una solicitud desde un ordenador frontal del cliente para leer datos en una entrada al directorio; un medio de procesamiento que asigna al menos un valor de detección de colisión dado a al menos un subconjunto de los datos en la entrada al directorio, donde el al menos un valor de detección de colisión dado es un atributo de contador de detección de colisión dado, CDC, que tiene un valor (x) en la entrada al directorio; un medio de lectura de salida que presenta hacia el ordenador frontal del cliente los datos solicitados junto con el al menos un valor de detección de colisión dado; un medio de actualización de entrada que recibe una solicitud desde el ordenador frontal del cliente para modificar el al menos un subconjunto de los datos en la entrada al directorio, teniendo la solicitud al menos un valor de detección de colisión actualizado para cada al menos un valor de detección de colisión dado, donde la solicitud que tiene el al menos un valor de detección de colisión actualizado incluye:

(i) una o más operaciones de AÑADIR como sigue AÑADIR: CDC = (x) + 1, AÑADIR: CDC = (x) + 2… AÑADIR: CDC = (x) + Número de Colisiones para Detectar, NCD, donde NCD tiene un valor igual o mayor que un número de clientes concurrentes que podrían posiblemente leer y modificar los datos desde la entrada al directorio;

(ii) datos modificados; y

(iii) una operación de REEMPLAZAR como sigue: REEMPLAZAR CDC = (x) + 1;

determinando un detector de colisión si la solicitud incluye una operación de AÑADIR que intenta operar sobre un atributo de CDC actual asignado al menos a un subconjunto de datos y que tiene un valor diferente dentro de la entrada al al menos un valor (x) de atributo de CDC dado enviado al ordenador frontal del cliente; si el resultado de la determinación mediante el detector de colisión es negativo, aceptando y ejecutando un medio de actualización de salida la solicitud de modificar el al menos un subconjunto de los datos en la entrada al directorio, y asignando un medio de procesamiento al valor de detección de colisión actual un valor siguiente; y si no, denegando y rechazando el medio de actualización de salida la solicitud hacia el ordenador frontal del cliente.

6. El directorio de la reivindicación 5, en el que el medio de lectura de entrada está adaptado para recibir desde el ordenador frontal del cliente una solicitud de iniciar una transacción antes de enviar la solicitud de modificar los datos.

7. El directorio de la reivindicación 5, en el que el atributo de CDC es un atributo mandatorio en una clase de objeto de estructura deseada o en una nueva clase de objeto auxiliar.

8. El directorio de la reivindicación 5, en el que el atributo de CDC es un contador cíclico.

9. Un ordenador frontal (FE DE HSS, FE DE HLR) de cliente para acceder a un directorio con un Protocolo Ligero de Acceso a Directorios “LDAP” (Lightweight Director y Access Protocol, en inglés) para leer y actualizar los datos en él, y que comprende:

un medio de lectura de salida para enviar una solicitud de leer datos en una entrada al directorio; un medio de lectura de entrada para recibir los datos solicitados junto con al menos un valor de detección de colisión dado para al menos un subconjunto de los datos en la entrada al directorio, donde el al menos un valor de detección de colisión dado es un atributo de contador de detección de colisión dado, CDC, que tiene un valor (x) en la entrada al directorio; un procesador para procesar los datos recibidos; un medio de actualización de salida para enviar una solicitud de modificar el al menos un subconjunto de los datos en la entrada al directorio, teniendo la solicitud al menos un valor de detección de colisión actualizado para cada al menos un valor de detección de colisión dado, donde la solicitud que tiene el al menos un valor de detección de colisión actualizado incluye:

(i) una o más operaciones de AÑADIR: CDC = (x) + 1, AÄDIR: CDC = (x) + 2… AÑADIR: CDC = (x) + Número de Colisiones para Detectar, NCD, donde NCD tiene un valor igual o mayor que un número de clientes concurrentes que podrían posiblemente leer y modificar los datos desde la entrada al directorio;

(ii) datos modificados; y

(iii) una operación de REEMPLAZAR como sigue: REEMPLAZAR CDC = (x) + 1; y

un medio de actualización de entrada para recibir la denegación de la solicitud, si la solicitud incluye una operación de AÑADIR que intenta operar en un atributo de CDC actual asignado al al menos un subconjunto de datos que tienen un valor diferente dentro de la entrada que el al menos un valor de atributo de CDC (x) dado recibido en el medio de lectura de entrada; y para recibir, si no, la aceptación de la solicitud para modificar el al menos un subconjunto de los datos en la entrada al directorio.

10. El ordenador frontal de cliente de la reivindicación 9, en el que el medio de lectura de salida está también adaptado para enviar hacia el directorio una solicitud de inicio de una transacción antes de enviar la solicitud de modificar los datos.

11. El ordenador frontal de cliente de la reivindicación 9, en el que el atributo de CDC es un atributo mandatorio en una clase de objeto de estructura o en una nueva clase de objeto auxiliar.

12. El ordenador frontal de cliente de la reivindicación 9, en el que el atributo de CDC es un contador cíclico.

13. Un método para detectar y evitar colisiones en una entrada a un directorio a la que se accede con un Protocolo Ligero de Acceso a Directorios “LDAP” (Lightweight Director y Access Protocol, en inglés) , mediante una operación de actualización desde el ordenador frontal (FE DE HSS, FE DE HLR) de un ordenador frontal de un cliente, comprendiendo el citado método las etapas de:

enviar una solicitud desde el ordenador frontal de un cliente para leer datos en una entrada al directorio;

recibir en el ordenador frontal del cliente los datos solicitados junto con al menos un valor de detección de colisión dado para al menos un subconjunto de los datos, en el que el al menos un valor de detección de colisión dado es un atributo de contador de detección de colisión, CDC, que tiene un valor (x) en la entrada al directorio;

procesar los datos obtenidos en el ordenador frontal del cliente; enviar una solicitud desde el ordenador frontal del cliente para modificar el al menos un subconjunto de los datos en la entrada al directorio, teniendo la solicitud al menos un valor de detección de colisión actualizado para cada al menos un valor de detección de colisión dado, donde la solicitud que tiene el al menos un valor de detección de colisión incluye:

(i) una o más operaciones de AÑADIR como sigue: AÑADIR: CDC = (x) + 1, AÑADIR: CDC = (x) + 2… AÑADIR: CDC = (x) + Número de Colisiones para Detectar, NCD, donde NCD tiene un valor igual

o mayor que el número de clientes concurrentes que podrían posiblemente leer y modificar los datos

desde la entrada al directorio;15 (ii) datos modificados; y

(iii) una operación de REEMPLAZAR como sigue: REEMPLAZAR CDC = (x) + 1; y

recibir en el ordenador frontal del cliente la denegación de la solicitud, si la solicitud incluye una operación deAÑADIR que intenta operar en un atributo de CDC actual asignado al al menos un subconjunto de datos y

que tiene un valor diferente dentro de la entrada del al menos un valor de atributo de CDC (x) dado recibido en el ordenador frontal del cliente, y para recibir, si no, la aceptación de la solicitud de modificar el al menos un subconjunto de los datos en la entrada al directorio.