WO2018234656A1 - Gestion de l'unicité des identifiants de modules de communication dans un réseau de communication - Google Patents

Gestion de l'unicité des identifiants de modules de communication dans un réseau de communication Download PDF

Info

Publication number
WO2018234656A1
WO2018234656A1 PCT/FR2018/051365 FR2018051365W WO2018234656A1 WO 2018234656 A1 WO2018234656 A1 WO 2018234656A1 FR 2018051365 W FR2018051365 W FR 2018051365W WO 2018234656 A1 WO2018234656 A1 WO 2018234656A1
Authority
WO
WIPO (PCT)
Prior art keywords
identifier
module
identifiers
rfpi
communication
Prior art date
Application number
PCT/FR2018/051365
Other languages
English (en)
Inventor
Fabrice Fontaine
Simon Gloanec
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2018234656A1 publication Critical patent/WO2018234656A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/725—Cordless telephones
    • H04M1/72502—Cordless telephones with one base station connected to a single line
    • H04M1/72505—Radio link set-up procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/725—Cordless telephones
    • H04M1/727—Identification code transfer arrangements

Definitions

  • the invention relates to the field of telecommunications.
  • the invention particularly relates to a method for managing the uniqueness of the communication module identifiers in a communication network.
  • the communication module referred to above relates to any module to which an identifier is assigned and more particularly to systems, or subsystems, in which a uniqueness of the identifiers between modules is desired.
  • Such a communication module can be integrated in a communication device such as a home gateway.
  • the module will be a DECT module (Digital Enhanced Cordless Telecommunications) and the device will be a home gateway.
  • the invention is not limited to DECT type identifiers but extends to all identifiers making it possible to identify an item of equipment in a system, or subsystem, for example an SSID type identifier (Service Set Identifier). a domestic gateway.
  • SSID type identifier Service Set Identifier
  • the operating principle of the DECT technology is based on a communication between a communication module called DECT base and terminals often called telephone handsets equipped with a DECT interface to communicate with the base.
  • the base receives signals from a telephone line and transmits these signals to the terminal or terminals concerned.
  • a DECT database is associated with a unique RFPI identifier (English acronym for "Radio Fixed Part Identity”).
  • the base and terminals are paired with each other at the base of this RFPI ID.
  • Existing standards require that this RFPI identifier must uniquely identify in time and space the DECT database in a given system.
  • One solution used to ensure uniqueness is to assign from the beginning, for example to manufacture, a unique identifier that can not be modified later. This solution guarantees the uniqueness of the identifiers; however, when a user changes the communication module, the latter is associated with a new identifier; the user must then re-pair the communication module with all the terminals. This operation is often long and tedious for a user, especially since the number of DECT type terminals tends to increase with the arrival of connected objects equipped with a DECT interface.
  • the invention offers a solution that does not have the drawbacks of the state of the art.
  • the subject of the invention is a method for managing identifiers in a system including communication modules, the communication modules being able to memorize several identifiers including a principal identifier and a secondary identifier, the main identifier being a modifiable identifier and used primarily with respect to the secondary identifier, the method comprising the following steps: a. receiving a first and a second identifier from a first and a second communication module, respectively, b. detecting a duplicate between the received identifiers, c. sending a command to modify the main identifier of one of the communication modules, the type of modification applied being a function of the value of the main identifier concerned.
  • a communication module has several identifiers including an editable main identifier.
  • the principal identifier being modifiable, the risk of duplicates is not null; therefore, the invention implements a Management module described below whose function is to detect duplicates between module identifiers.
  • the management module if a duplicate is detected, the management module triggers the sending of a modification command of the main identifier of one of the devices so as to ensure the uniqueness of the identifiers used by the communication modules in the system concerned.
  • the prioritization of the use of the identifiers means that, if the principal identifier is not given or if it has a null value, the identifier used is in this case the secondary identifier.
  • the invention ensures the uniqueness of the identifiers in the system under consideration while allowing a modification of the main identifiers of the communication modules. It should also be noted that the sending of a modification command of the main identifier of one of the modules does not exclude the possibility of sending a modification command of the main identifier to several communication modules.
  • the modification comprises a step of writing a principal identifier. in the second module, different from the main identifier of the first module.
  • This mode takes advantage of the fact that the main identifier is modifiable; in particular, the writing, in the second module, of a main identifier different from the main identifier of the first makes it possible to delete a duplicate between module identifiers.
  • the modification comprises a step of deleting the main identifier of the second communication module.
  • this mode still takes advantage of the fact that the main identifier can be modified to delete a duplicate; in this case, in this second mode, the main identifier of the second communication module is deleted so that the secondary identifier of the second module becomes the identifier used.
  • the modification comprises a step of writing a new principal identifier, in the second module, different from the previous one.
  • this third mode still takes advantage of the fact that the main identifier can be modified to delete a duplicate; in this mode, the writing of a new principal identifier in the second module makes priority the use of the new principal identifier written, the old identifier having been replaced by this new identifier.
  • the modification further comprises a step of writing a new principal identifier, in the first module, different from the previous one.
  • This variant completes the third mode.
  • the communication modules are able to communicate with at least one terminal; in this configuration, the choice of the communication module to which a change of identifier is applied is a function of the number of terminals paired with the communication module. With this fourth mode, the management module requires a modification of the identifier which is on the terminal having the least pairing to achieve after modification of the main identifier.
  • the communication modules are able to be paired with at least one terminal; in this configuration, the choice of the communication module to which a change of identifier is applied is a function of the date on which the identifiers received are put into service.
  • This variant takes into account the age of the identifiers, implied by the customers; this mode allows you to reward the oldest and most loyal customers.
  • the secondary identifiers are unique and are not modifiable after the commissioning of the module concerned, namely in our example of the base concerned.
  • This sixth is advantageous because when a main identifier is deleted following the detection of a duplicate, the remaining identifiers linked to the two communication modules concerned are two secondary identifiers, resulting in a unity between identifiers ensured.
  • the invention relates to a system including communication modules, the modules being able to memorize several identifiers including a principal identifier and a secondary identifier, the main identifier being a modifiable identifier and used in priority with respect to the secondary identifier, the system comprising the following modules: a. a receiving module of a first and a second identifier from a first and a second communication module, respectively, b. a module for detecting a duplicate between the identifiers received, c. a module for sending a command for modifying the main identifier of one of the communication modules, the type of modification applied being a function of the value of the main identifier concerned.
  • the invention relates to a module for managing identifiers (DM) of communication modules, the identifiers of a module including a main identifier (RFPI_SW) and a secondary identifier (RFPI_HW), the main identifier being a modifiable identifier and used primarily with respect to the secondary identifier, the management module comprising a. a receiving module of a first and a second identifier from a first and a second communication module, respectively, b. a module for detecting a duplicate between the received identifiers, c. a module for sending a command for modifying the main identifier of one of the communication modules, the type of modification applied being a function of the value of the main identifier concerned.
  • DM identifiers
  • the invention relates to a communication module in which are stored identifiers including a main identifier and a secondary identifier, the main identifier being a modifiable identifier and used primarily with respect to the secondary identifier.
  • the invention relates to a home gateway comprising a module as defined above.
  • the invention also relates to a computer program comprising code instructions which, when the program is executed by a processor, performs the steps of the method defined thereon.
  • the invention relates to a recording medium readable by a data processor on which is recorded a program comprising program code instructions for performing the steps of the method defined above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • FIG. 1 represents a computer system on which is illustrated an exemplary embodiment of the invention.
  • FIG. 2 illustrates steps of the method according to a particular embodiment of the invention.
  • FIGS. 3 and 4 illustrate certain steps of the method described with reference to FIG. 2.
  • FIG. 5 illustrates a device adapted for implementing the method according to a particular embodiment of the invention.
  • Figure 1 includes a SYS computer system including communication modules illustrated by DECTn databases (the index "n” represents the base number in the system under consideration) enabling wireless communication with DECT telephones (acronym for Digital Enhanced Cordless). telecommunications).
  • a DECT base is capable of receiving signals from a telephone line and transmits these signals to one or more DECT terminals (also called DECT handsets).
  • DECT technology allows telephone terminals to receive signals from the base in an extended area of about 100 meters.
  • Each DECTn base has an RFPIn identifier to distinguish it from other bases.
  • RFPIn (English abbreviation for "Radio Fixed Part Identity")
  • PARI (English acronym for "Primary Access Rights Identity”
  • Terminal Number (The format of the RFPI identifier being described in the document [ETS_300_175-06], we will not return in more detail in the present description on this identifier because without interest for the disclosure of the invention.
  • DECT1 and DECT2 bases are described;
  • the DECT1 and DECT2 bases are included in respective home gateways LB1 and LB2 connected to a telephone line (not shown in the figures).
  • Terminals have the hardware architecture of a computer. It conventionally comprises a processor, a read-only memory, a random access memory and means of communication with the gateway such as a DECT interface.
  • terminals TU, T12 are able to communicate with the base DECT1 of the gateway LB1.
  • a terminal T21 is able to communicate with the base DECT2 of the gateway LB2.
  • the number of terminals per gateway chosen above represents only one example; in general, this number of terminals is arbitrary.
  • the terminals are equipped with a DECTnm communication sub-module.
  • the sub-modules are referenced with two indices, the index "n" referencing the base n concerned and the index "m” referencing a particular terminal.
  • the DECT1 database is attached to DECT1 and DECT12 communication sub-modules installed in the terminals TU and T12, respectively.
  • the DECT2 base is attached to a DECT2 communication sub-module installed in the terminal T2.
  • the communication between a DECTn base and a terminal requires a pairing phase (the person skilled in the art also uses the term "pairing") during which the RFPIn identifier of the DECTn base is used.
  • a pairing phase the person skilled in the art also uses the term "pairing" during which the RFPIn identifier of the DECTn base is used.
  • an operator OP manages the park of the gateways LB1 and LB2 and thus DECT1 and DECT2 communication modules;
  • a DM management module installed in an SRV server, has the particular function of ensuring the uniqueness of the RFIPn identifiers in the system SYS considered; this so as to prevent a telephone terminal, for example the terminal TU, to be paired with two gateways at a time, namely its own gateway LB1 and for example the third gateway LB2 of a neighbor for example.
  • a terminal can not pair and communicate with two bases at the same time; the terminal uses the two bridges alternately; in other words, the terminal uses a first base DECT during x time; then if the first base is rebooted, the terminal is paired with a second base for y time, and so on.
  • the invention is not limited to DECT technology but applies to any system, or any subsystem, in which a uniqueness of communication module identifiers must be ensured, for example, the invention. also applies to DECT / CAT-iq compliant terminals (CAT-iq being the acronym for Cordless Advanced Telephony - Internet and Quality); the invention also applies to DELE DELE compliant terminals (DECT Ultra Low Energy)
  • a DECTn database stores two or more identifiers of which only one identifier is used at a time "t" to identify the concerned database DECTn.
  • the identifier used can also be modified over time as will be seen below.
  • a DECTn database stores two types of identifiers
  • RFPI_SW principal identifier
  • RFPI_HW secondary identifier
  • the main identifier RFPI_SW is modifiable and is read and used by the communication module associated with this identifier, in priority with respect to the secondary identifier. In this configuration, if the main identifier is filled in, that is to say it has a value, this identifier is used to identify the database concerned DECTn. On the other hand, if the principal identifier is not given, or if its value is zero, the secondary identifier is read and used to identify the DECTn database. In other words, the RFPI_SW always has priority with the RFPI_HW in the sense that the RFPI_SW is always read before the RFPI_HW.
  • the communication module receives a secondary identifier, it means that the main identifier of the communication module concerned is not indicated or at a value of zero, or any other value which makes that the chosen identifier will be the secondary identifier.
  • the main identifier has the same value as the secondary identifier, the chosen identifier may be the secondary identifier.
  • the identifier RFPI_HW is saved as read-only. This identifier RFPI_HW can not be modified when the associated gateway is in service.
  • a manager ensuring the uniqueness of the RFPI_HW identifiers may be authorized to modify this identifier; this can be the case when this manager has to reset a gateway and put it back in service at a new user.
  • This reset phase is also referred to as a refurbish phase.
  • the RFPI_HW identifiers being unique, it is understood that a duplicate can be deleted in all cases by removing the two RFPI_SW identifier of two concerned communication modules.
  • the identifier RFPI_SW modifiable, can be filled in by a user during a restoration of the gateway made or by the management module DM.
  • the identifier RFPI_HW is ideally updated and the identifier RFPI_SW is deleted.
  • the identifier RFPI_HW is not updated as explained below with reference to a first embodiment.
  • the gateway LB1 will be reused without updating the identifier RFPI_HW; this results in a risk of occurrence of duplicates as explained below.
  • the gateways LB1 and LB2 transmit their identifiers of the telephone line CULV1 and CULV2 (acronym of "Customer User Line Varchar" as well as the identifiers of the communication modules concerned DECT1, DECT2, respectively.
  • the DM management module receives the communication module identifiers and the line identifiers sent by the gateways and analyzes the DECTn / CULVn pairs received in order to detect possible duplicates between identifiers.
  • the two gateways LB1 and LB2 are connected to the management module DM and that this management module detects, during a step referenced ETl (DBL), a duplicate between identifiers.
  • the module DM checks the value of the identifier RFPI_SW of one of the gateways.
  • the module DM requires during a step ET211 (WR: RFPIx / RFPI_SW) a writing of an identifier RFPIx as the main identifier RFPI_SW.
  • a correspondence between the identifier RFPIx is created with a line number CULVn of the relevant gateway LBn.
  • the created correspondence is stored in a database BDD by the management module DM.
  • the DM management module requires a new RFPIx to be written as identifier
  • the identifier RFPI_SW is deleted during an ET222 step.
  • the write or delete request is a function of the value of the main identifier RFPI_SW concerned; indeed in our example: a. if the identifier RFPI_SW is empty, the management module DM requires the writing of an identifier RFPI_SW; b. if the identifier RFPI_SW is filled in but equal to the secondary identifier RFPI_HW, the management module DM requires the writing of a new principal identifier RFPI_SW; c. if the identifier RFPI_SW is filled in but different from the secondary identifier, the main identifier RFPI_SW is deleted.
  • FIG. 3 illustrates a state of the identifiers RFPI_SW and RFPI_HW as a function of time in each of two gateways LB1 and LB2, implied in each of the communication modules DECT1 and DECT2, during the implementation of the principle of the invention.
  • the gateway LB1 has as initial identifiers the following (time t1 of Figure 3):
  • RFPI_HW1 RFPI1
  • “Empty” meaning that the identifier is not filled, or that it has a value of zero, or more generally that the identifier has a value such that it is not taken into account and that consequently the secondary identifier is selected as the identifier of the communication module DECTn.
  • the identifier RFPI_SW1 of the communication module DECT1 not being filled (empty), in accordance with the above-described priority rule of the principal identifier on the secondary identifier, the secondary identifier RFPI_HW1 RFPI1 is the identifier used by the DECT1 communication module.
  • the identifier RFPI_HW1 possibly encryption keys necessary for pairing, are automatically saved in a BDD database of the remote server SRV network and / or in a local file for example in a memory of the LB1 gateway.
  • This backup makes it possible to reset the identifiers of the communication module at any time by copying the saved identifiers, namely
  • an RFPI1 / CULV1 pair is stored in the BDD database of the SRV server.
  • identifier CULV1 is a unique identifier of the telephone line of the user UT1 of the communication module DECT1.
  • a Restore runs with IDs saved in the DB database or local file;
  • the gateway LB2 writes the identifier RFPI1 in RFPI_SW2.
  • RFPI_HW2 RFPI2
  • the identifier RFPI_SW2 As the identifier RFPI_SW2 is read as a priority, the identifier RFPI1 becomes the identifier used by the gateway LB2.
  • the LB2 gateway When the LB2 gateway is connected to the management module DM, the latter reads the identifier RFPI_SW2 from the gateway LB2, and verifies that this identifier RFPI1 is equal to the identifier stored in the module and that this identifier corresponds to the CULV1 line identifier. Since this is the case, the LB2 gateway is allowed to connect to the network.
  • the management module DM When connecting the gateway LB1 to the management module DM, the management module DM analyzes the pair RFPI1 / CULV2 and note that the identifier RFPI1 is already used by another communication module associated with another identifier line to know CULV1 (RFPI1 / CULV1).
  • the identifier RFPI1 is therefore used twice in connection with two distinct line identifiers CULV1 and CULV2.
  • the management module DM detects the duplicate (step ET1, FIG. 2). Following the detection, in our example, the DM module requires the writing of an RFPI3 identifier in RFPI_SW1 (ET211, Figure 2). The identifier RFPI_SW1 being priority compared to RFPI_HW1, T 'identifying RFPI3 becomes now the new identifier to use (time t4, Figure 3). The association (RFPI3, CULV2) is stored in the DM management module.
  • RFPI_HW1 RFPI1
  • the main identifier RFPI_SW1 being modifiable, it is for example considered that a user uses the local file or the database BDD on the server SRV to reset / restore the identifiers of its gateway LBl and that it will then restore another gateway , for example the bridge of a friend.
  • the RFPI_HW1, and optionally the pairing encryption keys are saved in the local file or the database BDD.
  • the user restores the communication module DECT1; following the restoration of the communication module DECT1, the identifiers become (instant t2, FIG. 4):
  • the LB2 gateway initially has as identifiers:
  • RFPI_HW2 RFPI2.
  • RFPI_SW2 RFPI1
  • RFPI_HW2 RFPI2.
  • the DM module notes that the RFPI1 used by the LB2 gateway is already used by another communication module with a different CULV identifier.
  • the DM management module detects a duplicate and must remove this duplicate to ensure the uniqueness of the identifiers used (ET1, Figure 2) in the SYS system.
  • the management module DM requires the gateway LB2 to delete RFPI_SW2 (ET222, FIG. 2), and block any subsequent DECT restore using RFPI1.
  • the blocking is illustrated by a cross in the field associated with the RFPI_SW2 identifier.
  • an MBL blocking module blocks the restoration and may issue a message informing that a restoration is not allowed on the relevant gateway LB2.
  • the secondary identifier RFPI_HW is not modifiable when the concerned bridge is in service.
  • the uniqueness between secondary identifiers is ensured before commissioning; for example, these identifiers are created during manufacturing and are no longer modifiable thereafter.
  • a detected duplicate can be deleted by deleting the two principal identifiers stored on the relevant communication modules.
  • deletion of a duplicate can consist in writing a new principal identifier in a communication module.
  • a choice between two modules may be more appropriate to prevent the two communication modules require a new pairing with all terminals.
  • the communication module chosen for the identifier modification is a function of the number of terminals connected to the communication module.
  • the modified identifier corresponds to the communication module having the least pairing to achieve.
  • the choice of the communication module to which a modification of identifier is applied depends on the age of the identifiers received.
  • the actual use (which corresponds to the commissioning of the communication module implied by the gateway) of the identifiers is dated. This date makes it possible to establish which identifier is older than another.
  • FIG. 5 illustrates an example of a hardware structure of an SRV server according to one embodiment of the invention.
  • an SRV server comprises a random access memory MEMV (for example a RAM memory), a processing unit UT equipped for example with a processor PRO, and controlled by a computer program PG, stored in a read-only memory MEM (for example a ROM or a hard disk).
  • MEMV random access memory
  • PRO programmable gate array
  • PG read-only memory
  • the code instructions of the computer program PG are for example loaded into the memory MEMV before being executed by the processor of the processing unit UT.
  • RAM MEMV contains particular matches between identifiers RFPI / CULV and can detect duplicates between identifiers received according to the method described above.
  • module used in the present text can correspond as well to a software component as to a hardware component or a set of hardware and software components, a software component corresponding itself to one or more programs or under - Computer programs or more generally to any element of a program capable of implementing a function or a set of functions as described for the modules concerned.
  • a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention se rapport à un procédé de gestion d'identifiants dans un système incluant des modules de communication (DECT1, DECT2), les modules de communication étant aptes à mémoriser plusieurs identifiants dont un identifiant principal et un identifiant secondaire, l'identifiant principal étant un identifiant modifiable et utilisé prioritairement par rapport à l'identifiant secondaire, le procédé comprenant les étapes suivantes : a. réception d'un premier et d'un deuxième identifiant provenant d'un premier et d'un deuxième module de communication, respectivement, b. détection d'un doublon entre les identifiants reçus, c. envoi d'une commande de modification de l'identifiant principal d'un des modules, le type de modification appliqué étant fonction de la valeur de l'identifiant principal concerné.

Description

Gestion de l'unicité des identifiants de modules de communication dans un réseau de communication
Domaine technique
L'invention se rapporte au domaine des télécommunications. L'invention concerne tout particulièrement un procédé de gestion de l'unicité des identifiants de modules de communication dans un réseau de communication. Le module de communication visé ci-dessus se rapporte à tout module auquel un identifiant est attribué et plus particulièrement aux systèmes, ou sous-systèmes, dans lesquels une unicité des identifiants entre modules est souhaitée.
Un tel module de communication peut être intégré dans un dispositif de communication telle qu'une passerelle domestique. Dans l'exemple qui servira à l'illustration de l'invention, le module sera un module DECT (sigle anglo-saxon de Digital Enhanced Cordless Télécommunications) et le dispositif sera une passerelle domestique.
L'invention ne se limite pas aux identifiants de type DECT mais s'étend à tout identifiants permettant d'identifier un équipement dans un système, ou sous-système, par exemple un identifiant de type SSID (sigle de Service Set Identifier) d'une passerelle domestique. Etat de la technique
Le principe de fonctionnement de la technologie DECT repose sur une communication entre un module de communication appelé base DECT et des terminaux souvent appelés combinés téléphoniques équipés d'une interface DECT pour communiquer avec la base. Concrètement, la base reçoit des signaux d'une ligne téléphonique et transmet ces signaux vers le ou les terminaux concernés.
Actuellement, une base DECT est associée à un identifiant unique RFPI (sigle anglosaxon de « Radio Fixed Part Identity »). La base et des terminaux s'appairent entre eux à la base de cet identifiant RFPI. Les normes existantes imposent que cet identifiant RFPI doit identifier de manière unique dans le temps et dans l'espace la base DECT dans un système considéré. Une solution utilisée pour assurer l'unicité est d'attribuer dès l'origine, par exemple à la fabrication, un identifiant unique non modifiable par la suite. Cette solution garantit l'unicité des identifiants ; cependant, lorsqu'un utilisateur change de module de communication, ce dernier est associé à un nouvel identifiant ; l'utilisateur doit alors ré-appairer le module de communication avec tous les terminaux. Cette opération est souvent longue et fastidieuse pour un utilisateur, d'autant plus que le nombre de terminaux de type DECT a tendance à augmenter avec l'arrivée des objets connectés équipés d'une interface DECT.
L'invention offre une solution ne présentant pas les inconvénients de l'état de la technique.
L'invention A cet effet, selon un aspect fonctionnel, l'invention a pour objet un procédé de gestion d'identifiants dans un système incluant des modules de communication, les modules de communication étant aptes à mémoriser plusieurs identifiants dont un identifiant principal et un identifiant secondaire, l'identifiant principal étant un identifiant modifiable et utilisé prioritairement par rapport à l'identifiant secondaire, le procédé comprenant les étapes suivantes : a. réception d'un premier et d'un deuxième identifiant provenant d'un premier et d'un deuxième module de communication, respectivement, b. détection d'un doublon entre les identifiants reçus, c. envoi d'une commande de modification de l'identifiant principal d'un des modules de communication, le type de modification appliqué étant fonction de la valeur de l'identifiant principal concerné.
Selon l'invention, un module de communication a plusieurs identifiants dont un identifiant principal modifiable. L'identifiant principal étant modifiable, le risque de doublons n'est pas nul ; en conséquence, l'invention met en œuvre un module de gestion décrit ci-dessous qui a pour fonction de détecter les doublons entre identifiants de module. Dans cette configuration, si un doublon est détecté, le module de gestion déclenche l'envoi d'une commande de modification de l'identifiant principal d'un des dispositifs de manière à assurer l'unicité des identifiants utilisés par les modules de communication dans le système concerné.
Précisons que, la priorisation d'utilisation des identifiants fait que, si l'identifiant principal n'est pas renseigné ou s'il a une valeur nulle, l'identifiant utilisé est dans ce cas l'identifiant secondaire.
Plusieurs types de modifications sont possibles. On verra dans la suite quel type de modification s'applique en fonction de la valeur de l'identifiant principal concerné.
En définitive, l'invention assure l'unicité des identifiants dans le système considéré tout en autorisant une modification des identifiants principaux des modules de communication. Précisons aussi que l'envoi d'une commande de modification de l'identifiant principal d'un des modules n'exclut pas la possibilité d'envoyer une commande de modification de l'identifiant principal vers plusieurs modules de communication.
Selon un premier mode de mise en œuvre particulier de l'invention, lorsque les identifiants reçus sont un identifiant principal d'un premier module et un identifiant secondaire d'un deuxième module, la modification comprend une étape d'écriture d'un identifiant principal, dans le deuxième module, différent de l'identifiant principal du premier module. Ce mode tire profit du fait que l'identifiant principal est modifiable ; en particulier, l'écriture, dans le deuxième module, d'un identifiant principal différent de l'identifiant principal du premier permet de supprimer un doublon entre identifiants de module.
Selon un deuxième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent, lorsque les identifiants reçus sont deux identifiants principaux d'un premier et d'un deuxième module de communication, et lorsque l'identifiant principal et secondaire du deuxième module sont différents, la modification comprend une étape de suppression de l'identifiant principal du deuxième module de communication. Comme pour le premier mode, ce mode tire encore profit du fait que l'identifiant principal est modifiable pour supprimer un doublon ; en l'espèce, dans ce deuxième mode, l'identifiant principal du deuxième module de communication est supprimé de manière à ce que l'identifiant secondaire du deuxième module devienne l'identifiant utilisé.
Selon un troisième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, lorsque les identifiants reçus sont deux identifiants principaux d'un premier et d'un deuxième module de communication, et lorsque l'identifiant principal et secondaire du deuxième module de communication sont les mêmes, la modification comprend une étape d'écriture d'un nouvel identifiant principal, dans le deuxième module, différent du précédent. Comme pour les précédents modes, ce troisième mode tire encore profit du fait que l'identifiant principal est modifiable pour supprimer un doublon ; dans ce mode, l'écriture d'un nouvel identifiant principal dans le deuxième module rend prioritaire l'utilisation du nouvel identifiant principal écrit, l'ancien identifiant ayant été remplacé par ce nouvel identifiant.
Selon une variante du troisième mode de mise en œuvre particulier de l'invention, la modification comprend en outre une étape d'écriture d'un nouvel identifiant principal, dans le premier module, différent du précédent. Cette variante complète le troisième mode. Selon un quatrième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, les modules de communication sont aptes à communiquer avec au moins un terminal ; dans cette configuration, le choix du module de communication auquel on applique une modification d'identifiant est fonction du nombre de terminaux appairés au module de communication. Grâce à ce quatrième mode, le module de gestion requiert une modification de l'identifiant qui se trouve sur le terminal ayant le moins d'appairage à réaliser après modification de l'identifiant principal.
Selon un cinquième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, les modules de communication sont aptes à être appairés à au moins un terminal ; dans cette configuration, le choix du module de communication auquel on applique une modification d'identifiant est fonction de la date de mise en service des identifiants reçus. Cette variante prend en compte l'ancienneté des identifiants, sous-entendu des clients ; ce mode permet de récompenser les utilisateurs les plus anciens clients et donc les plus fidèles.
Selon un sixième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, les identifiants secondaires sont uniques et ne sont pas modifiables après la mise en service du module concerné, à savoir dans notre exemple de la base concernée. Ce sixième est avantageux car lorsqu'un identifiant principal est supprimé suite à la détection d'un doublon, que les identifiants restants liés aux deux modules de communication concernés sont deux identifiants secondaires, il en résulte une unicité entre identifiants assurée.
Selon un aspect matériel, l'invention se rapporte à un système incluant des modules de communication, les modules étant aptes à mémoriser plusieurs identifiants dont un identifiant principal et un identifiant secondaire, l'identifiant principal étant un identifiant modifiable et utilisé prioritairement par rapport à l'identifiant secondaire, le système comprenant les modules suivants : a. un module de réception d'un premier et d'un deuxième identifiant provenant d'un premier et d'un deuxième module de communication, respectivement, b. un module de détection d'un doublon entre les identifiants reçus, c. un module d'envoi d'une commande de modification de l'identifiant principal d'un des modules de communication, le type de modification appliqué étant fonction de la valeur de l'identifiant principal concerné.
Selon un autre aspect matériel, l'invention se rapporte à un module de gestion d'identifiants (DM) de modules de communication, les identifiants d'un module incluant un identifiant principal (RFPI_SW) et un identifiant secondaire (RFPI_HW), l'identifiant principal étant un identifiant modifiable et utilisé prioritairement par rapport à l'identifiant secondaire, le module de gestion comprenant a. un module de réception d'un premier et d'un deuxième identifiant provenant d'un premier et d'un deuxième module de communication, respectivement, b. un module de détection d'un doublon entre les identifiants reçus, c. un module d'envoi d'une commande de modification de l'identifiant principal d'un des modules de communication, le type de modification appliqué étant fonction de la valeur de l'identifiant principal concerné.
Selon un autre aspect matériel, l'invention se rapporte à un module de communication dans lequel sont stockés des identifiants dont un identifiant principal et un identifiant secondaire, l'identifiant principal étant un identifiant modifiable et utilisé prioritairement par rapport à l'identifiant secondaire.
Selon un autre aspect matériel, l'invention se rapporte à une passerelle domestique comprenant un module tel que défini ci-dessus.
Selon un autre aspect matériel, l'invention concerne également un programme d'ordinateur comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé défini dessus. Selon encore un autre aspect matériel, l'invention a trait à un support d'enregistrement lisible par un processeur de données sur lequel est enregistré un programme comprenant des instructions de code de programme pour l'exécution des étapes du procédé défini ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés sur lesquels :
La figure 1 représente un système informatique sur lequel est illustré un exemple de réalisation de l'invention.
La figure 2 illustre des étapes du procédé selon un mode particulier de réalisation de l'invention.
Les figures 3 et 4 illustrent certaines étapes du procédé décrit en référence à la figure 2. La figure 5 illustre un dispositif adapté pour la mise en œuvre du procédé selon un mode particulier de réalisation de l'invention.
Description détaillée d'un fou d') exemplefs) de réalisation illustrant l'invention La figure 1 comprend un système informatique SYS incluant des modules de communication illustrés par des bases DECTn (l'indice « n » représente le nombre de base dans le système considéré) permettant une communication sans fil avec des téléphones DECT (acronyme de Digital Enhanced Cordless Télécommunications).
Une base DECT est apte à recevoir des signaux d'une ligne téléphonique et transmet ces signaux vers un ou plusieurs terminaux DECT (aussi appelés combinés téléphoniques DECT). La technologie DECT permet aux terminaux téléphoniques de recevoir des signaux de la base dans un périmètre étendu, environ d'une centaine de mètres.
Chaque base DECTn a un identifiant RFPIn pour le distinguer d'autres bases. Rappelons qu'un identifiant RFPIn (sigle anglosaxon de « Radio Fixed Part Identity »), est l'identité unique de la base. Cette identité est composée d'un identifiant PARI (sigle anglo-saxon de « Primary Access Rights Identity») et d'un numéro de borne. Le format de l'identifiant RFPI étant décrit dans le document [ETS_300_175-06], nous ne rentrerons pas plus en détail dans la présente description sur cet identifiant car sans intérêt pour l'exposé de l'invention.
En référence à la figure 1, deux base DECT1 et DECT2 sont décrites ; Dans notre exemple, les bases DECT1 et DECT2 sont incluses dans des passerelles domestiques LB1 et LB2 respectives connectées à une ligne téléphonique (non représentée sur les figures).
Les terminaux ont l'architecture matérielle d'un ordinateur. Il comporte classiquement un processeur, une mémoire morte, une mémoire vive et des moyens de communication avec la passerelle tels que qu'une interface DECT. Dans notre exemple, des terminaux TU, T12 sont aptes à communiquer avec la base DECT1 de la passerelle LB1. De la même manière, un terminal T21 est apte à communiquer avec la base DECT2 de la passerelle LB2. Les nombres de terminaux par passerelle choisi ci-dessus ne représete, qu'un exemple ; d'une manière général, ce nombre de terminaux est quelconque. Les terminaux sont équipés d'un sous-module de communication DECTnm. Dans notre exemple, les sous-modules sont référencés avec deux indices, l'indice « n » référençant la base n concernée et l'indice « m » référençant un terminal en particulier. Dans notre exemple, la base DECTl est rattachée à des sous-modules de communication DECTl 1 et DECT12 installés dans les terminaux TU et T12, respectivement. La base DECT2 est rattachée à un sous-module de communication DECT2 installé dans le terminal T2.
La communication entre une base DECTn et un terminal, sous-entendu un sous-module de communication, requiert une phase d'appairage (l'homme du métier utilise aussi le terme « appariement ») au cours de laquelle l'identifiant RFPIn de la base DECTn est utilisé. Nous ne rentrerons pas dans les détails de cette phase d'appairage car elle est connue de l'homme du métier et n'est pas utile à la compréhension de l'invention. Ce n'est qu'après appairage qu'un terminal peut communiquer avec une base DECT.
Dans notre exemple, un opérateur OP gère le parc des passerelles LB1 et LB2 et donc des modules de communication DECTl et DECT2; un module de gestion DM, installé dans un serveur SRV, a notamment pour fonction d'assurer l'unicité des identifiants RFIPn dans le système SYS considéré; ce de manière à éviter qu'un terminal téléphonique, par exemple le terminal TU, s'appaire avec deux passerelles à la fois, à savoir sa propre passerelle LB1 et par exemple la passerelle tiers LB2 d'un voisin par exemple. Comme le plus souvent, un terminal ne peut s'appairer et communiquer avec deux bases en même temps ; le terminal utilise les deux passerelles alternativement ; en d'autres mots, le terminal utilise une première base DECT pendant x temps ; puis si la première base est rebootée, le terminal s'appaire à une deuxième base pendant y temps, et ainsi de suite.
Précisons ici que l'invention ne se limite pas à la technologie DECT mais s'applique à tout système, ou tout sous-système, dans lequel une unicité d'identifiants de modules de communication doit être assurée, par exemple, l'invention s'applique aussi aux terminaux conformes au standard DECT/CAT-iq ( CAT-iq étant le sigle de Cordless Advanced Telephony - Internet and Quality) ; l'invention s'applique aussi aux terminaux conformes au standard DECT ULE (sigle de DECT Ultra Low Energy)
Selon l'invention, une base DECTn stocke deux identifiants voire plus dont un seul identifiant est utilisé à un instant « t » pour identifier la base concernée DECTn. L'identifiant utilisé peut aussi être modifié au fil du temps comme on le verra ci-dessous.
Dans notre exemple, une base DECTn stocke deux types d'identifiants
RFPI :
- un identifiant principal RFPI_SW, - et un identifiant secondaire RFPI_HW.
L'identifiant principal RFPI_SW est modifiable et est lu et utilisé, par le module de communication associé à cet identifiant, prioritairement par rapport à l'identifiant secondaire. Dans cette configuration, si l'identifiant principal est renseigné, c'est-à-dire qu'il a une valeur, cet identifiant est utilisé pour identifier la base concernée DECTn. Par contre, si l'identifiant principal n'est pas renseigné, ou que sa valeur est nulle, l'identifiant secondaire est lu et utilisé pour identifier la base DECTn. En d'autres mots, le RFPI_SW est toujours prioritaire au RFPI_HW en ce sens que le RFPI_SW est toujours lu avant le RFPI_HW. Il faut aussi comprendre en référence à ce qui précède que si le module de communication reçoit un identifiant secondaire, cela signifie que l'identifiant principal du module de communication concerné n'est pas renseigné ou à une valeur nulle, ou toutes autres valeurs qui fait que l'identifiant choisi sera l'identifiant secondaire. Par exemple, si l'identifiant principal a la même valeur que l'identifiant secondaire, l'identifiant choisi peut être l'identifiant secondaire. Dans notre exemple, l'identifiant RFPI_HW est enregistré en lecture seule. Cet identifiant RFPI_HW n'est pas modifiable lorsque la passerelle associée est en service. Avantageusement seul un gestionnaire assurant l'unicité des identifiants RFPI_HW peut être autorisé à modifier cet identifiant ; cela peut être le cas lorsque ce gestionnaire doit réinitialiser une passerelle et la remettre en service chez un nouvel utilisateur. Cette phase de réinitialisation est appelée aussi phase de remise en état (refurbish en anglais). Les identifiants RFPI_HW étant uniques, on comprend qu'un doublon peut être supprimé dans tous les cas en supprimant les deux identifiant RFPI_SW de deux modules de communication concernés.
L'identifiant RFPI_SW, modifiable, peut être renseigné par un utilisateur lors d'une restauration de la passerelle faite ou par le module de gestion DM.
De préférence, lorsqu'une passerelle est réutilisée par une autre personne, l'identifiant RFPI_HW est idéalement mis à jour et l'identifiant RFPI_SW est supprimé. Il arrive cependant que, lors d'une réutilisation d'une passerelle, l'identifiant RFPI_HW ne soit pas mis à jour comme cela est expliqué ci-dessous en référence à un premier mode de réalisation.
Dans le premier mode de réalisation décrit ci-dessous, la passerelle LB1 va être réutilisée sans mise à jour de l'identifiant RFPI_HW; il en résulte un risque d'apparition de doublons comme expliqué ci-dessous.
Dans un premier temps, les passerelles LB1 et LB2 émettent leurs identifiants de la ligne téléphoniques CULV1 et ,CULV2 (sigle de « Customer User Line Varchar » ainsi que les identifiant des modules de communication concernés DECT1, DECT2, respectivement. Dans un second temps, le module de gestion DM reçoit les identifiants de module de communication et les identifiants de ligne émis par les passerelles et analyse les couples DECTn/CULVn reçus afin de détecter d'éventuels doublons entre identifiants.
Rappelons qu'on entend par doublon entre identifiants le fait que deux modules de communication utilisent le même identifiant. Les étapes relatives à la résolution de doublons sont décrites en référence à la figure 2.
Initialement, supposons que les deux passerelles LB1 et LB2 soient connectées au module de gestion DM et que ce module de gestion détecte, lors d'une étape référencée ETl(DBL), un doublon entre identifiants. A ce stade, lors d'une étape ET21 (RFPI_SW=0 ?), le module DM vérifie la valeur de l'identifiant RFPI_SW d'une des passerelles.
1. Si l'identifiant RFPI_SW n'est pas renseigné (cas 1), ou s'il a une valeur nulle, le module DM requiert lors d'une étape ET211 (WR : RFPIx/ RFPI_SW) une écriture d'un identifiant RFPIx comme identifiant principal RFPI_SW.
Enfin lors d'une étape ET2111 (ADD : RFPIx/CULV), une correspondance entre l'identifiant RFPIx est créé avec un numéro de ligne CULVn de la passerelle concernée LBn. la correspondance créée est stockée dans une base de données BDD par le module de gestion DM.
2. Si l'identifiant RFPI_SW est renseigné (cas 2), le module de gestion DM vérifie lors d'une étape ET22 (RFPI_SW=RFPI_HW ?) si l'identifiant principal et l'identifiant secondaire ont une même valeur.
- Dans l'affirmative, lors d'une étape ET221, le module de gestion DM requiert une écriture d'un nouveau RFPIx comme identifiant
RFPI-SW dans le module de communication concerné DECT ;
- dans la négative, l'identifiant RFPI_SW est supprimé lors d'une étape ET222.
On comprend donc que la requête d'écriture ou de suppression est fonction de la valeur de l'identifiant principal RFPI_SW concerné ; en effet dans notre exemple: a. si l'identifiant RFPI_SW est vide, le module de gestion DM requiert l'écriture d'un identifiant RFPI_SW ; b. si l'identifiant RFPI_SW est renseigné mais égal à l'identifiant secondaire RFPI_HW, le module de gestion DM requiert l'écriture d'un nouvel identifiant principal RFPI_SW ; c. si l'identifiant RFPI_SW est renseigné mais différent de l'identifiant secondaire, l'identifiant principal RFPI_SW est supprimé.
D'autres cas sont envisageables.
A ce stade le doublon n'existe plus. Les étapes précédentes s'exécutent à chaque réception d'un couple
RFPIn/CULVn par le module de gestion DM.
Le cas 1 décrit ci-dessus est illustré sur la figure 3. Dans cet exemple, on considère ici qu'un utilisateur va changer de passerelle domestique. On notera l'ancienne passerelle LBl, et la nouvelle LB2. La figure 3 illustre un état des identifiants RFPI_SW et RFPI_HW en fonction du temps dans chacune de deux passerelles LBl et LB2, sous-entendu dans chacun des modules de communication DECT1 et DECT2, lors de la mise en œuvre du principe de l'invention.
On considère aussi dans cet exemple que la passerelle LBl a comme identifiants initiaux les suivants (instant tl de la figure 3):
RFPI_SW1 = vide
RFPI_HW1= RFPI1
« vide » signifiant que l'identifiant n'est pas renseigné, ou qu'il a une valeur nulle, ou plus généralement que l'identifiant a une valeur telle qu'il n'est pas pris en compte et qu'en conséquence l'identifiant secondaire est sélectionné comme identifiant du module de communication DECTn.
Cette passerelle LBl va être réutilisée par un autre client ; cette passerelle réutilisée sera référencée LB1RF dans la suite ; pour sa réutilisation, on considère que les identifiants sont les mêmes que les identifiants initiaux : RFPI SW1 = vide
RFPI HW1 = RFPI1 Les étapes du mode de réalisation sont les suivantes :
L'identifiant RFPI_SW1 du module de communication DECT1 n'étant pas renseigné (vide), conformément à la règle décrite ci-dessus de priorité de l'identifiant principal sur l'identifiant secondaire, l'identifiant secondaire RFPI_HW1=RFPI1 est l'identifiant utilisé par le module de communication DECT1.
Dans notre exemple, après l'appairage, l'identifiant RFPI_HW1, éventuellement des clés de chiffrement nécessaires à l'appairage, sont automatiquement sauvegardés dans une base de données BDD du serveur distant SRV réseau et/ou dans un fichier local par exemple dans une mémoire de la passerelle LB1. Cette sauvegarde permet de réinitialiser les identifiants du module de communication à tout moment en recopiant les identifiants sauvegardés, à savoir
RFPI_SW1 = vide RFPIJHW1 = RFPI1.
Lors de la connexion du module de communication DECT1 au module de gestion (DM), un couple RFPI1/ CULV1 est mémorisé dans la base de données BDD du serveur SRV.
Rappelons que l'identifiant CULV1 est un identifiant unique de la ligne téléphonique de l'utilisateur UT1 du module de communication DECT1.
On suppose ensuite que l'utilisateur remplace la passerelle LB1 par une nouvelle passerelle LB2. On suppose aussi que cette nouvelle passerelle LB2 a comme identifiant
RFPI_SW2 = vide RFPI_HW2 = RFPI2
Pour ne pas ré-appairer une nouvelle fois ses terminaux TU et T12 avec le module de communication DECT2 de la nouvelle passerelle LB2, une restauration s'exécute avec les identifiants sauvegardés dans la base de données BDD ou dans le fichier local ; Lors de la restauration, la passerelle LB2 écrit l'identifiant RFPI1 dans RFPI_SW2. Les identifiants de la passerelle LB2 deviennent donc (instant t2 sur la figure 3): RFPI_SW2 = RFPI1
RFPI_HW2 = RFPI2
Comme l'identifiant RFPI_SW2 est lu prioritairement, l'identifiant RFPI1 devient l'identifiant utilisé par la passerelle LB2.
Lors de la connexion de la passerelle LB2 au module de gestion DM, ce dernier lit l'identifiant RFPI_SW2 de la passerelle LB2, et vérifie que cet identifiant RFPI1 est bien égal à l'identifiant stocké dans le module et que cet identifiant correspond à l'identifiant de ligne CULV1. Puisque, c'est le cas, la passerelle LB2 est autorisée à se connecter au réseau.
Ensuite, La passerelle LB1RF, réutilisée par un autre utilisateur UT2, se connecte sur le réseau avec l'identifiant secondaireRFPI_HWl=RFPIl, l'identifiant RFPI_SW1 étant vide (instant t3 figure 2).
A ce stade, Lors de la connexion de la passerelle LB1 au module de gestion DM, le module de gestion DM analyse le couple RFPI1/CULV2 et constatent que l'identifiant RFPI1 est déjà utilisé par un autre module de communication associé à un autre identifiant de ligne à savoir CULV1 (RFPI1/CULV1).
L'identifiant RFPI1 est donc utilisé deux fois en liaison avec deux identifiants de ligne distincts CULV1 et CULV2.
Le module de gestion DM détecte le doublon (étape ET1, figure 2). Suite à la détection, dans notre exemple, le module DM requiert l'écriture d'un identifiant RFPI3 dans RFPI_SW1 (ET211, figure 2). L'identifiant RFPI_SW1 étant prioritaire par rapport RFPI_HW1, T'identifiant RFPI3 devient désormais le nouvel identifiant à utiliser (instant t4, figure 3). L'association (RFPI3, CULV2) est mémorisée dans le module de gestion DM.
A ce stade, il n'y a plus de doublon, la passerelle LBl ayant comme identifiants : RFPI_SW1 = RFPI3 (prioritaire)
RFPI_HW1 = RFPI1 et la passerelle LB2 ayant comme identifiants : RFPI_SW2 = RFPI1 (prioritaire) RFPI_HW2 = RFPI2
Le cas 2 décrit ci-dessus est illustré sur la figure 4.
Dans ce deuxième mode de réalisation, on considère que, comme dans le premier exemple de réalisation, un utilisateur possède une passerelle LBl ayant comme identifiants (instant tl figure 4) : RFPI_SW1 = vide
RFPI_HW1= RFPI1
L'identifiant principal RFPI_SW1 étant modifiable, on considère par exemple qu'un utilisateur utilise le fichier local ou la base de données BDD sur le serveur SRV pour réinitialiser/restaurer les identifiants de sa passerelle LBl et qu'il va ensuite restaurer une autre passerelle, par exemple la passerelle d'un ami.
Les étapes de cet exemple sont les suivantes :
Tout d'abord, L'utilisateur appaire ses terminaux TU et T12 avec la passerelle LBl avec RFPI_HW1 = RFPI1. A chaque appairage, le RFPI_HW1, et éventuellement les clés de chiffrement d'appairage, sont sauvegardés dans le fichier local ou la base de données BDD.
L'utilisateur restaure le module de communication DECT1 ; suite à la restauration du module de communication DECT1, les identifiants deviennent (instant t2, figure 4) :
RFPI_SW1 = RFPI1 et RFPI_HW1= RFPI1
Les deux identifiants ont la même valeur.
On suppose ensuite que les identifiants sauvegardés dans le fichier ou la base de données BDD en liaison avec la passerelle LB1 sont copiés dans une autre passerelle LB2, par exemple celle d'un ami. La passerelle LB2 a initialement comme identifiants :
RFPI_SW2 = vide
RFPI_HW2 = RFPI2. Après copie (ou restauration), les identifiants deviennent (instant t3, figure 4)
RFPI_SW2=RFPI1 RFPI_HW2 = RFPI2.
Ensuite, lors de la connexion de la LB2 au module de gestion DM, le module DM constate que le RFPI1 utilisé par la passerelle LB2 est déjà utilisé par un autre module de communication avec un identifiant CULV différent. Le module de gestion DM détecte donc un doublon et doit supprimer ce doublon pour assurer l'unicité des identifiants utilisés (ET1, figure 2) dans le système SYS.
Dans notre exemple, avantageusement, le module de gestion DM requiert à la passerelle LB2 de supprimer RFPI_SW2 (ET222, figure 2), et de bloquer toute restauration DECT ultérieure utilisant RFPI1. Le blocage est illustré par une croix dans le champ associé à l'identifiant RFPI_SW2.
Suite à une nouvelle tentative de restauration du module de communication DECT2, un module de blocage MBL bloque la restauration et peut émettre un message informant qu'une restauration n'est pas autorisée sur la passerelle concernée LB2.
On a vu précédemment que l'identifiant secondaire RFPI_HW n'est pas modifiable lorsque la passerelle concernée est en service. Selon une variante, l'unicité entre identifiants secondaires est assurée avant la mise en service; par exemple, ces identifiants sont créés à la fabrication et ne sont plus modifiables par la suite. Dans cette configuration, un doublon détecté peut être supprimé en supprimant les deux identifiants principaux stockés sur les modules de communication concernés.
On a vu précédemment que la suppression d'un doublon peut consister à écrire un nouvel identifiant principal dans un module de communication. En variante, on peut aussi prévoir d'écrire un nouvel identifiant principal dans l'autre module. Cette variante évite d'effectuer un choix entre deux modules de communication.
Cependant, un choix entre deux modules peut s'avérer plus judicieux pour éviter que les deux modules de communication nécessitent un nouvel appairage avec l'ensemble des terminaux.
Selon une première variante, le module de communication choisi pour la modification d'identifiant est fonction du nombre de terminaux connectés au module de communication. Ainsi, l'identifiant modifié correspond au module de communication ayant le moins d'appairage à réaliser.
Selon une deuxième variante, le choix du module de communication auquel on applique une modification d'identifiant est fonction de l'ancienneté des identifiants reçus. Dans cette variante, l'utilisation effective (qui correspond à la mise en service du module de communication sous-entendu de la passerelle) des identifiants est datée. Cette date permet d'établir quel identifiant est plus ancien qu'un autre.
La figure 5 illustre un exemple de structure matérielle d'un serveur de SRV selon un mode de réalisation de l'invention. Un tel serveur SRV comprend une mémoire vive MEMV (par exemple une mémoire RAM), une unité de traitement UT équipée par exemple d'un processeur PRO, et pilotée par un programme d'ordinateur PG, stocké dans une mémoire morte MEM (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans la mémoire vive MEMV avant d'être exécutées par le processeur de l'unité de traitement UT. La mémoire vive MEMV contient notamment des correspondances entre identifiants RFPI/CULV et peut détecter des doublons entre identifiants reçus selon le procédé décrit ci-dessus.
Enfin, précisons ici que le terme module utilisé dans le présent texte peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous- programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).

Claims

Procédé de gestion d'identifiants (RFPI_SW,RFPI_HW) dans un système (SYS) incluant des modules de communication (DECT1, DECT2), les modules de communication étant aptes à mémoriser plusieurs identifiants dont un identifiant principal (RFPI_SW) et un identifiant secondaire (RFPI_HW), l'identifiant principal (RFPI_SW) étant un identifiant modifiable et utilisé prioritairement par rapport à l'identifiant secondaire (RFPI_HW), le procédé comprenant les étapes suivantes : a. réception d'un premier et d'un deuxième identifiant provenant d'un premier et d'un deuxième module de communication, respectivement, b. détection d'un doublon entre les identifiants reçus, c. envoi d'une commande de modification de l'identifiant principal d'un des modules de communication, le type de modification appliqué étant fonction de la valeur de l'identifiant principal concerné.
Procédé de communication selon la revendication 1, dans lequel lorsque les identifiants reçus sont un identifiant principal d'un premier module et un identifiant secondaire d'un deuxième module, la modification comprend une étape d'écriture d'un identifiant principal, dans le deuxième module, différent de l'identifiant principal du premier module.
Procédé de communication selon la revendication 1, dans lequel lorsque les identifiants reçus sont deux identifiants principaux d'un premier et d'un deuxième module de communication, et lorsque l'identifiant principal et secondaire du deuxième module sont différents, la modification comprend une étape de suppression de l'identifiant principal du deuxième module de communication.
4. Procédé de communication selon la revendication 1, dans lequel lorsque les identifiants reçus sont deux identifiants principaux d'un premier et d'un deuxième module de communication, et lorsque l'identifiant principal et secondaire du deuxième module de communication sont les mêmes, la modification comprend une étape d'écriture d'un nouvel identifiant principal, dans le deuxième module, différent du précédent.
5. Procédé selon l'une des revendications précédentes, dans lequel les modules sont aptes à être appairés à au moins un terminal, et dans lequel le choix du module de communication auquel on applique une modification d'identifiant est fonction du nombre de terminaux appairés au module de communication.
6. Procédé selon l'une des revendications précédentes, dans lequel les modules sont aptes à communiquer avec au moins un terminal, et dans lequel le choix du module de communication auquel on applique une modification d'identifiant est fonction de la date de mise en service des identifiant reçus.
7. Procédé selon l'une des revendications précédentes, dans lequel les identifiants secondaires sont uniques et ne sont pas modifiables après la mise en service du module concerné.
8. Système (SYS) incluant des modules de communication (DECT1, DECT2), les modules étant aptes à mémoriser plusieurs identifiants dont un identifiant principal (RFPI_SW) et un identifiant secondaire (RFPI_HW), l'identifiant principal étant un identifiant modifiable et utilisé prioritairement par rapport à l'identifiant secondaire, le système comprenant les modules suivants : a. un module de réception d'un premier et d'un deuxième identifiant provenant d'un premier et d'un deuxième module de communication, respectivement, b. un module détection d'un doublon entre les identifiants reçus, c. un module d'envoi d'une commande de modification de l'identifiant principal d'un des modules de communication, le type de modification appliqué étant fonction de la valeur de l'identifiant principal concerné.
9. Module de gestion d'identifiants (DM) de modules de communication (DECTl, DECT2), les identifiants d'un module incluant un identifiant principal (RFPI_SW) et un identifiant secondaire (RFPI_HW), l'identifiant principal étant un identifiant modifiable et utilisé prioritairement par rapport à l'identifiant secondaire, le module de gestion comprenant a. un module de réception d'un premier et d'un deuxième identifiant provenant d'un premier et d'un deuxième module de communication, respectivement, b. un module de détection d'un doublon entre les identifiants reçus, c. un module d'envoi d'une commande de modification de l'identifiant principal d'un des modules de communication, le type de modification appliqué étant fonction de la valeur de l'identifiant principal concerné.
10. Module de communication (DECTl, DECT2) dans lequel sont stockés des identifiants dont un identifiant principal (RFPI_SW) et un identifiant secondaire (RFPI_HW), l'identifiant principal étant un identifiant modifiable et utilisé prioritairement par rapport à l'identifiant secondaire.
11. Passerelle domestique comprenant un module (DECTl, DECT2) tel que défini dans la revendication 10.
12. Programme d'ordinateur comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé défini selon l'une des revendications 1 à 7.
13. Support d'enregistrement lisible par un processeur de données sur lequel est enregistré un programme comprenant des instructions de code de programme pour l'exécution des étapes du procédé défini selon l'une des revendications 1 à 7.
PCT/FR2018/051365 2017-06-20 2018-06-12 Gestion de l'unicité des identifiants de modules de communication dans un réseau de communication WO2018234656A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1755610A FR3067555A1 (fr) 2017-06-20 2017-06-20 Gestion de l'unicite des identifiants de modules de communication dans un reseau de communication
FR1755610 2017-06-20

Publications (1)

Publication Number Publication Date
WO2018234656A1 true WO2018234656A1 (fr) 2018-12-27

Family

ID=60138450

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2018/051365 WO2018234656A1 (fr) 2017-06-20 2018-06-12 Gestion de l'unicité des identifiants de modules de communication dans un réseau de communication

Country Status (2)

Country Link
FR (1) FR3067555A1 (fr)
WO (1) WO2018234656A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113923120A (zh) * 2021-09-29 2022-01-11 广州鲁邦通物联网科技股份有限公司 一种无线通信模块的模块id重命名方法以及终端设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5758282A (en) * 1995-06-19 1998-05-26 Sharp Kabushiki Kaisha Radio terminal using allocated addresses
EP1657950A2 (fr) * 2004-11-12 2006-05-17 NTT DoCoMo, Inc. Une station de base et procédé d'allocation de code de brouillage
EP3070993A1 (fr) * 2013-11-11 2016-09-21 Huawei Technologies Co., Ltd. Procédé d'activation de station de base et système d'activation de station de base

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5758282A (en) * 1995-06-19 1998-05-26 Sharp Kabushiki Kaisha Radio terminal using allocated addresses
EP1657950A2 (fr) * 2004-11-12 2006-05-17 NTT DoCoMo, Inc. Une station de base et procédé d'allocation de code de brouillage
EP3070993A1 (fr) * 2013-11-11 2016-09-21 Huawei Technologies Co., Ltd. Procédé d'activation de station de base et système d'activation de station de base

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Digital Enhanced Cordless Telecommunications (DECT); DECT access to IP networks; ETSI TS 101 xxx", TECHNICAL SPECIFICATION, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI), 650 ROUTE DES LUCIOLES, SOPHIA ANTIPOLIS CEDEX, F-06921, FRANCE, no. V0.0.5, 1 August 2003 (2003-08-01), XP014036949 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113923120A (zh) * 2021-09-29 2022-01-11 广州鲁邦通物联网科技股份有限公司 一种无线通信模块的模块id重命名方法以及终端设备
CN113923120B (zh) * 2021-09-29 2023-08-18 广州鲁邦通物联网科技股份有限公司 一种无线通信模块的模块id重命名方法以及终端设备

Also Published As

Publication number Publication date
FR3067555A1 (fr) 2018-12-14

Similar Documents

Publication Publication Date Title
WO2006053958A9 (fr) Support personnel de mémoire de masse portatif et système informatique d'accès sécurisé a un espace utilisateur via un réseau
FR2793053A1 (fr) Systeme et procede d'identification et d'acces a des services en ligne
FR2643478A1 (fr) Carte a circuit integre
WO2018234656A1 (fr) Gestion de l'unicité des identifiants de modules de communication dans un réseau de communication
EP2413233B1 (fr) Téléphone mobile sous android comprenant une chaîne de mise à disposition de contenus
WO2021079041A1 (fr) Technique de communication entre une application mettant en oeuvre un service et un serveur
CN111858487A (zh) 数据更新方法及设备
WO2015087019A1 (fr) Procédé de synchronisation de données entre un ensemble de terminaux
FR3021774A1 (fr) Procede de traitement automatique de la mise a jour d'une base de donnees
EP2510671A1 (fr) Procede de sauvegarde de donnees contenues dans un terminal communiquant portable
EP4239504A1 (fr) Procédé de gestion du mode de déverrouillage d'un objet
EP2531921B1 (fr) Gestion du lieu de stockage de donnees dans un systeme de stockage distribue
EP2304559B1 (fr) Procédé de basculement entre deux versions d'une même application au sein d'un dispositif de traitement de l'information et ledit dispositif
WO2015067892A1 (fr) Procédé de protection de métadonnées
FR2901381A1 (fr) Systeme informatique a gestion universelle et collaborative de fichiers utilisateurs
WO2023227386A1 (fr) Procédé de gestion de profils de service d'un élément sécurisé
FR2950991A1 (fr) Procede de synchronisation d'elements stockes par des dispositifs d'un systeme de communication de type paire a paire
FR3100351A1 (fr) connexion à chaîne de blocs de données
FR2901386A1 (fr) Support personnel de memoire de masse portatif et systeme informatique d'acces securise a un reseau par des utilisateurs.
WO2006027424A1 (fr) Dispositif de contrôle de communications
FR2901380A1 (fr) Support personnel de memoire de masse portatif et systeme informatique d'acces securise a un espace utilisateur via un reseau
FR3052620A1 (fr) Procede de gestion de l'acces a des contenus numeriques via une passerelle domestique
FR2862460A1 (fr) Procede d'acces a un document numerique dans un reseau de communication
FR2901387A1 (fr) Systeme informatique d'acces securise a un reseau par des utilisateurs
FR3013934A1 (fr) Procede de delegation d'un depot, dans un reseau de stockage distribue, d'un contenu multimedia

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18737000

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18737000

Country of ref document: EP

Kind code of ref document: A1