EP1402715A1 - Procede d'echange de donnees entre un appareil de service et un serveur de gestion selon un protocole de gestion sur ip - Google Patents

Procede d'echange de donnees entre un appareil de service et un serveur de gestion selon un protocole de gestion sur ip

Info

Publication number
EP1402715A1
EP1402715A1 EP02755077A EP02755077A EP1402715A1 EP 1402715 A1 EP1402715 A1 EP 1402715A1 EP 02755077 A EP02755077 A EP 02755077A EP 02755077 A EP02755077 A EP 02755077A EP 1402715 A1 EP1402715 A1 EP 1402715A1
Authority
EP
European Patent Office
Prior art keywords
server
recovery
protocol
session
exchange
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02755077A
Other languages
German (de)
English (en)
Inventor
Rodolphe Grunenwald
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SPT PUBLICOM
Original Assignee
Schlumberger Systemes SA
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 Schlumberger Systemes SA filed Critical Schlumberger Systemes SA
Publication of EP1402715A1 publication Critical patent/EP1402715A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
    • H04M17/02—Coin-freed or check-freed systems, e.g. mobile- or card-operated phones, public telephones or booths

Definitions

  • the present invention relates to the exchange of data between a service appliance and a management server according to a management protocol based on an Internet type protocol, also called "IP” for "Internet Protocol”.
  • IP Internet type protocol
  • a management server relates to the exchange and / or transfer of data such as files or alarms between a management server and service devices such as telephones of a public telephone network, payment terminals, terminals applications, parking meters, automatic dispensers or the like.
  • a public telephone network generally includes one (or more) central computer or management server, hereinafter called PMS server (acronym of the English term "Payphone Management System”), allowing the operator of the network to operate the supervision of the various public telephones distributed over a given territory of the network.
  • PMS server central computer or management server
  • the PMS server has the function of exchanging data with the fleet of public telephones via the telephone network.
  • public telephones send the PMS server an activity report detailing, for example, the number and amount of transactions.
  • Public telephones also communicate in the form of an alarm the eventual occurrence of an event (breakdown, act of vandalism, etc.) requiring the intervention of a maintenance agent.
  • the PMS server transfers files, price tables or even program updates to the public telephones operating microprocessors of the telephones, updates improving the programs already in use. place, or even introducing new services for users.
  • the present invention overcomes these drawbacks.
  • It relates to a method for exchanging data between at least one service appliance and at least one remote management server in accordance with a chosen management protocol.
  • the management protocol is based on IP and includes at least one initiation rule to initiate each exchange session and at least one recovery rule to launch a possible recovery in the event of non- outcome of the exchange.
  • the management protocol by virtue of its operation over IP, allows sealing against the network and thus allows a client / server dialogue on different types of networks (PSTN, ISDN, Internet). Connection is possible to various and varied networks without changing or adapting the communication protocol between the service devices and the server. Modification of the data structure at the protocol level is easy and avoids modifications to other layers of the IP protocol.
  • such a protocol makes it possible to control the exchange of data, in particular with regard to the initiation of the sessions and their possible resumption in the event of failure of the exchange.
  • the protocol also makes it possible to work online (on-line) or offline (off-line).
  • Such a protocol is advantageously capable of being implemented in a wireless environment of the GSM, CDMA or TDMA type.
  • the recovery rule comprises a step according to which the transfer is completely resumed when the device status changes.
  • the recovery rule comprises a step according to which the session exchange is resumed at the point of rupture without resuming the part of the exchange already carried out before the rupture.
  • the recovery rule is adapted to the work to be carried out by the service device, the importance of the task and its impact.
  • the recovery procedure can comprise a step consisting in repeating the recovery attempt indefinitely until the service apparatus is put back into operation and / or a step consisting in delaying the resumption by a chosen period of time and / or a step consisting in resuming the exchange after a triggering of the service device.
  • the initiation rule includes the following steps: - i) at the service device, issue a "CONNECT" connection request to the server in accordance with the protocol;
  • the management protocol includes a termination procedure comprising the following steps:
  • the data to be exchanged between the device and the server are determined by the server.
  • FIG. 1 is a schematic view of a public telephone network used for the implementation of the method according to one invention
  • FIG. 2 schematically illustrates the hardware architecture of the service devices and of the server into which the management protocol according to the invention is inserted;
  • Figure 3 illustrates the steps of initiating a session according to the protocol over IP according to the invention;
  • FIG. 4 illustrates the steps of downloading a status file on FTP from the device to the server according to the invention
  • FIG. 5 illustrates the steps of uploading files to FTP from the device to the server and downloading files to FTP from the server to the device according to the invention
  • FIG. 6 illustrates the steps of a download of alarm files on FTP from the device to the server and a download of configuration files on FTP from the server to the device according to the invention
  • FIG. 7 illustrates the steps of uploading files to FTP from the device to the server according to the invention
  • FIGS. 11 to 13 represent examples of termination of a session according to the invention.
  • a public telephone network 1 which includes a fleet of public telephones 10 (the same fleet may comprise from several tens to several thousand telephones, or even several tens of thousands, depending on the territorial coverage of the network).
  • the telephones 10 are intended for use by users, in self-service and are therefore installed for this purpose in public places, such as the street, or semi-public such as shopping centers, airports, hotel halls , restaurants, shops, etc.
  • Network 2 can also be constituted by a mobile radiotelephony network, whatever its nature, or by the Internet network or more generally by any communication network capable of transmitting data as well as by any combination of such networks.
  • These public telephones 10 can also be adapted to access information or service servers for Web and Internet services as well as information or service servers for service residing on private networks. Such access allows the operator operating network 1, to offer users a wide range of services ranging, for example, and without limitation, from reading their e-mails to consulting local information (list of doctors of the public telephone area, etc.). Obviously, the invention is not limited to public telephones offering such access to the Internet and to private servers.
  • PMS Payment Management System
  • the PMS server 5 has the function of exchanging with the fleet of public telephones 10 information concerning their operation and more generally the operation of the public telephone system.
  • the PMS server 5 manages the initialization sessions of public telephones and establishes statistical data from information received from public telephones 10 (alarms, operating counters, etc.).
  • the exchanges between the service devices 10 and the server 5 are in the form REQ request REQ response.
  • the public telephones 10 and the PMS server 5 are provided with appropriate means of supervision and of reception / transmission of information. These supervision and reception / transmission means are responsible for organizing the exchange of information between the public telephones 10, the PMS server 5 and an FTP server 4 (File Transfer Protocol), that is to say "protocol of file transfer ".
  • FTP server 4 File Transfer Protocol
  • the PMS server 5 transfers to the public telephones 10 the files necessary for their operation such as tariff tables, configuration parameters, such as the type of dialing, the characteristics of the line, etc. opposition or monitoring of means of payment used.
  • the public telephones 10 transmit information relating to their use, namely a daily report comprising data relating to the transactions carried out, to the traffic, an alarm report which makes it possible to report to the PMS server 5 the occurrence of incidents or damage to their integrity, such as a breakdown on the card reader or a handset torn off, so as to provide for the intervention of a surveillance agent, a status file characterizing the content of the telephone (such as the indications of the different versions of programs used by the microprocessor).
  • an FTP server 4 is specifically designed and adapted to file transfers called FTP. From orders received by the PMS server 5, each public telephone 10 which includes an FTP client entity, will connect to the FTP server 4 and download or download appropriate files.
  • the public telephones 10 can connect to a PROXY server 6 serving as a communication interface between the public telephones and the PMS server 5.
  • the service devices 10 are equipped with communication protocols 12 of the type TCP / IP, and 14 UDP / IP compliant with the technical recommendations of the IETF (Internet Engineering Task Force).
  • Each public telephone 10 comprises an operating system 16, a standard interface 18 of "socket” type, a protocol 20 of terminal type or TELNET for "Network Terminal Protocol” and a protocol 22 of FTP client type.
  • the client-side PFSP management protocol (for Payphone session protocol) according to the invention is housed in layer 24.
  • the service appliance 10 is dedicated to an application 26 of the public telephone type
  • the PMS 5 server is equipped with communication protocols 32 of the TCP / IP type, and 34 UDP / IP conforming to technical recommendations from the Internet Engineering Task Force (IETF).
  • IETF Internet Engineering Task Force
  • the PMS server 5 further comprises an operating system (not shown), a standard interface 38 of "socket” type, a protocol 40 of terminal type or TELNET for "Network Terminal Protocol” and a protocol 42 of FTP server type.
  • the server-side PFSP management protocol according to the invention is housed in layer 44.
  • the PMS server 5 is dedicated to an application 46 of the public telephone type.
  • the PROXY 6 server combines different functions, in particular directing requests from public telephones 10, depending on the nature of these requests, to corresponding servers; if necessary translate the data or instructions transmitted by the telephones 10 into the format of the destination servers; check the syntax of the requests sent by the telephones 10 before retransmission and thus authorize authenticated accesses to the network in order to confer an additional degree of security.
  • PROXY server Another function of the PROXY server is to establish reliable and authenticated information exchange sessions which consist, for example, in certain identification of the telephones 10 during an exchange of information with the servers or even in encrypting the data. in order to secure the communication in case of need.
  • PROXY 6 server Another function of the PROXY 6 server is to control and regulate the information exchanges carried out via standard file transfers and in accordance with the Internet protocol.
  • the PROXY 6 server also has the function of directing requests from public telephones to backup servers, in particular in the event of a server unavailability and ensuring thus a redundancy of architecture.
  • the PROXY 6 server is inaccessible as a result in particular of maintenance operations, it is then possible to direct the daily reports of the corresponding public telephones 10 to another management server then available.
  • PROXY server 6, the PMS server 5 and the FTP file server 4 instead of being separate machines as in FIG. 1, can be grouped together in a single PC type computer for example, as with reference to Figure 2.
  • the establishment of a session managed according to the PFSP management protocol according to the invention is advantageously a session of the TCP / IP type.
  • the session is initiated (or initialized) by the device 10 which sends an S-Connect.req message to the PMS server 5 generated by specific programs implemented by the microprocessors equipping the device 10.
  • This S-Connect message. req constitutes the connection request, also called "CONNECT”.
  • the S-Connect message. req is routed to server 5 via network 2, and interpreted as an S-Connect .ind message.
  • the server analyzes the S-Connect message. ind. After analysis, the server 5 sends an S-Connect.res message, which constitutes the server's response to the connection request, also called "ACCEPT", in the event of a positive response.
  • the S-Connect.res message is sent to telephone 10 via network 2, and interpreted as an S-Connect .cnf message, confirming the establishment of the TCP / IP session.
  • the event triggering the connection of the telephone 10 to the PMS server 5 can be of different types.
  • the connection can be initiated manually by a maintenance agent, for example during the installation of a new telephone 10 in the network 1.
  • the connection can be triggered automatically following, for example, the occurrence of an alarm (coin meter full , breakdown, vandalism, etc.).
  • the alarm can be generated by appropriate monitoring programs.
  • the connection can also be triggered automatically for activity reports generated by appropriate supervision programs, reports providing statistics on the activity of the telephone 10 and of the operator signal of the network 1 in order to improve the operation of the latter.
  • These supervision programs can publish their activity report at predetermined dates and times or even at times defined by the PMS 5.
  • the telephone can also connect to the PMS server 5 following the express request of the latter which has given the order, during a previous call to phone 10 to connect for a given reason: for example for downloading files.
  • the CONNECT connection message essentially contains the following information:
  • the type of session that is to say the context of the call: remote collection (activity report), downloading (transfer of files to the phone, in general this is a given prior order by the PMS server 5), alarm, etc;
  • this signature can be obtained by encryption by means of a DES type cryptographic algorithm or of any other type (RSA for example).
  • Telephone 10 then has a list of standard sessions which define a priori the reason for calling telephone 10.
  • this call was scheduled during a previous session.
  • the PMS server 5 which receives this CONNECT call first of all analyzes it and in particular verifies the authenticity of this call, then sends back an ACCEPT acceptance message which includes, among other data, the date and time. current in order to re-synchronize between the two devices, as well as the time and date of the next scheduled call.
  • the PMS server 5 then sends a first request for work to be carried out.
  • This demand for work is mainly of three types:
  • the PFST protocol for "payphone session protocol” allows according to the invention to initiate an exchange (a communication session) between a telephone 10 and a server using a protocol in TCP / IP format.
  • This protocol allows the installation of a data exchange session between a client and a server on any type of network.
  • the CONNECT connection message allows the initialization of the session.
  • the server in order to initialize a service device from the server, the server must recover a configuration file called "STATUTES" from the service device. This configuration file must always be sent before the order to disconnect the communication at the end of the session.
  • the service appliance can recover a file containing the active tariff table or a file containing the passive tariff table.
  • the service device can retrieve a parameter file, a black list, a gray list, a file containing segmented software and an object configuration file.
  • an actual FTP session can begin. It can either be a UPLOAD file upload or a DOWNLOAD file upload.
  • the server issues an S.File request. req. This request is routed through the network to the corresponding phone.
  • the first order received by a telephone 10 from the server 5 relates to the transfer of a file also called STATUTS specifying the references of the set or of the main files constituting the software resources of the telephone.
  • This STATUTES file subsequently enables the PMS 5 server, in the event of a malfunction, to determine the different versions of software used by the telephone 10.
  • the PMS 5 server In exchanges between the server 5 and the telephones 10, the PMS 5 server is always responsible for the file transferred, it's the master.
  • the PMS server 5 is able, on analysis of the precise call context of each telephone 10, to ask the latter for a given job, freely modifiable and adaptable, in particular according to the wishes of the of the network. Such flexibility is also without effect on telephones 10 which operate in slave mode.
  • the list of files to be transferred in one direction or another is therefore dynamically communicated to the telephone 10 by the PMS server 5 and this after identification of the connection, through specific requests: CONNECT, ACCEPT, UPLOAD, DOWNLOAD,
  • the telephones therefore do not know in advance the files to be transferred, it is only the PMS server which chooses the files to be transferred.
  • the telephone 10 sends a response of type S. File. res. This information is sent to the server via network 2. Once received, this message constitutes a confirmation of the S.File.Cnf type.
  • the file loading operation (UPLOAD) is initiated by the S.File.Req request according to the format described above.
  • the telephone 10 interprets this request and issues the message S. FILE. IND.
  • the telephone can, in FTP format, load into the server various files which may relate to transactions, operating counters, current alarms, alarm LOG files, counters relating to lists. black.
  • the loading of files is terminated by the request S.
  • File res emanating from the service device. This response is interpreted as confirmation after receipt by the server.
  • the telephone 10 After receiving an UPLOAD or DOWNLOAD type order, the telephone 10 opens an FTP session with the FTP server 4 whose address has been notified to it. The connection to the FTP server 4 in parallel to the current session is established with the PMS server 5 via the PROXY server 6. The telephone then performs the requested file transfer to the FTP server which has been notified to it. Once the transfer of the file (s) is complete, the phone sends an acknowledgment message by which it confirms to the PMS server that the work has been done well or badly. Then he waits for a new order. If a new order is not received after a predetermined period of time, the telephone cuts off the communication as described in more detail below.
  • the downloaded files include configuration files if at least one of the parameters has changed. This file is always sent before the communication termination order at the end of the session.
  • the PMS server 5 can take advantage of the call from each telephone 10 for its daily activity report (also called telecollect) to operate the downloading of a program update.
  • the commissioning agent when initializing a new telephone 10 to the public telephone network 1, the commissioning agent will systematically request certain information linked to the configuration of the telephone 10 (for example a configuration file) and this by launching a dedicated session.
  • the PMS server can not only transfer the requested file but also obtain other return files such as an active price table, a passive price table, a parameter table, a black list, a gray list, software , etc.
  • the PMS 5 will not only be able to recover the transaction files, the operating counters and the alarms but also it will be able to download in return an active tariff table, a passive tariff table, a parameter table, a black list, a gray list, software.
  • the session relating to the alarm reporting comprises, as taught above, a request of the UPLOAD type at the end of which an FTP file is downloaded to the server.
  • the downloaded files can be a configuration file, alarm files present, the so-called alarm log file as well as transactions.
  • a DOWNLOAD order can be followed and carried out in order to download a configuration file from the server to the service device.
  • the invention can also provide a remote diagnostic session in which files are downloaded to the server.
  • These downloaded files can include a configuration file, a transaction file, a file of operating counters, a present alarm file, the alarm log, a blacklist counter and a gray list counter file.
  • the server can also initiate a download session in which files are downloaded from the server to the corresponding service appliance.
  • the downloaded files are for example active or passive tariff table files, a parameters file, a black or gray list file, a segmented software file and, if necessary, an object configuration file.
  • the actual download session includes downloading a configuration file, etc.
  • the protocol also makes it possible to manage sessions for requests for content and for emails or e-mail.
  • the establishment of the session is initiated according to the protocol mentioned above with the CONNECT and ACCEPT orders.
  • the phone sends a S.Methodinvoke.req request.
  • This request corresponds to the GET / POST order in messaging under TCP / IP.
  • the server receives this request via the telephone network and interprets it as a S.Methodinvoke.ind request.
  • the server analyzes this request and sends in response the S.Methodinvoke.- res message which constitutes a replica or response from the server.
  • the telephone or service device confirms this response with the message S.Methodinvoke.cnf.
  • the session ends according to the protocol mentioned above with the order DISCONNECT.
  • the content transfer may contain one or more content and transfer requests.
  • the protocol provides for several treatment rules.
  • the PFSP protocol provides several rules for dealing with abnormal sessions.
  • a session can be considered abnormal when the request format is incorrect.
  • a "DISCONNECT" message is sent accompanied by a PROTERR type code via the PROXY server to the PMS server and the corresponding service device.
  • the establishment of the connection or of the TCP / IP type session can be refused by the PROXY communication server, for example when the service is not available.
  • the PROXY communication server sends a DISCONNECT message to the destination of the service device which, once received by the service device, is interpreted in S.DISCONNECT. IND with the corresponding code CONNECT.
  • the establishment of the connection can be refused by the PMS server.
  • the server sends a S.DISCONNECT.REQ message containing the corresponding code which may have the definition REDIAL CONGESTION or PEERREQ depending on the event causing the refusal.
  • the DISCONNECT message is sent to the service device.
  • a time delay for example of the order of 30 seconds, may be provided following a first connection request that was not successful.
  • the service device sends a termination request S.DISCONNECT.REQ with the code PEERREQ to the server, after a timeout of 30 seconds compared to its first connection request S .CONNECT.REQ.
  • a termination request is provided from the server with the message S. DISCONNECT.REQ and the code PEERREQ during a download- or a download that does not succeed after a chosen period.
  • This TX period has a value which depends on the number of files transferred and the size of each of these files. This TX period can be calculated by the server.
  • the service device can send a session termination message S.DISCONNECT.REQ with the code CONGESTION to the server when, for example, internal errors are detected or when problems management files in RAM are detected at the service device.
  • the consistency of the coding, in particular its syntax, is checked by the PROXY communication server. The reason for the termination request can be found in the corresponding code, here CONGESTION.
  • a session termination request is sent by the server with the code corresponding to DISCONNECT REDIAL in the case of a DOWNLOAD.
  • This termination request can take place at the end of a time delay, the departure of which is formed by the result of the transfer.
  • the present invention also provides a protocol which manages the resumption of sessions, after breaks thereof.
  • a protocol which manages the resumption of sessions, after breaks thereof.
  • the recovery management can intervene in the case of a PFSP transaction, of the TCP / IP type, like that described with reference to FIG. 3.
  • the recovery procedure provides for renewing the connection request S .CONNECT.REQ.
  • the resumption of the session can also take place after reception of the connection request with establishment of the connection at the server level but before the reception of the ACCEPT message at the level of the service device.
  • the management of the resumption of the session can take place at the level of the file download operation.
  • the protocol according to the invention manages such a break.
  • the management of the recovery can take place at the level of a download of a file of the UPLOAD type.
  • the management of the recovery can also take place when the session is interrupted before reception of the DISCONNECT message at the service device.
  • the causes which trigger the management of takeovers can be of different nature:
  • no recovery management is planned during an initialization carried out at the request of the operator.
  • a first attempt to resume connection RI is planned, for example, after 5 minutes of the break in the event of a fault in the value of a parameter.
  • This RI attempt in the event of failure is repeated a certain number of times, for example 2 (individualized here in R2 and R3).
  • the recovery policy does not provide for new attempts here and the session is definitively interrupted.
  • This recovery policy is for example implemented during a remote initialization or a remote diagnosis.
  • a special recovery rule is provided in the case of a daily telecollection.
  • the recovery rule comprises two branches of intervention.
  • the break C of the telecollect for example due to a defect in the value of a parameter emanating from the server
  • the telecollect can be resumed at the end of a procedure which begins with waking up of the device (for example a communication request from a public telephone user or the introduction of a payment card), followed by a sleep and which ends with the attempt to resumed 5 minutes after being put to sleep.
  • This recovery attempt is preferably limitless, that is to say until the end of the telecollect.
  • the telecollect is deferred RD by a chosen period of time, for example 12 hours.
  • This second branch is implemented when there is no awakening of the device by a user as described above in the first branch.
  • the attempt to resume the first branch is successful, the programming of the delayed recovery is deleted until the next remote collection.
  • an attempt to resume is made within 5 minutes of the break.
  • the number of attempts can be limited to 3.
  • the recovery rule plans to initialize the alarm procedure again until the alarm procedure works properly.
  • a recovery procedure is provided during the download of several objects or even during the initialization procedure after the download session.
  • this recovery procedure there is the short recovery cycle (5 minutes) and a long cycle (15 minutes) which can be triggered automatically by a parking meter.
  • the service device initiates the recovery procedure and the server always plays the same scenario after correct identification of the service device.
  • the service device finds the missing files after a correct analysis. In other words, the recovery takes place at the point of rupture without resuming the part of the exchange already carried out before the rupture.
  • the device reil de service can try to initiate a resumption of communication (as of course, at any other moment of rupture).
  • the server then sends the scheduled scenarios.
  • the service appliance sends only a correct acknowledgment to the server, signaling the subsequent placement of the objects, and waits only for the message from the server. of S.Disconnect termination, this in order to save time and avoid unnecessary repetitions.
  • Tables A and B form an integral part of the present invention. They include elements of a certain nature which can be used to define the invention if necessary.
  • recovery management can distinguish a delayed recovery which preferably occurs after a short immediate cycle to allow the operator to restore the system before repetition (thus avoiding unnecessary exchanges) and an immediate resumption which constitutes the resumption of the initial session.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)
  • Communication Control (AREA)

Abstract

L'invention concerne un procédé d'échange de données entre au moins un appareil de service (10) et au moins un serveur de gestion (5) distant conformément ô un protocole de gestion choisi. Le protocole de gestion est sur IP et comprend au moins une règle d'initiation de chaque session d'échange et au moins une règle de reprise pour lancer une éventuelle reprise en cas de non-aboutissement de l'échange.

Description

Procédé d'échange de données entre un appareil de service et un serveur de gestion selon un protocole de gestion sur IP
La présente invention concerne l'échange de données entre un appareil de service et un serveur de gestion selon un protocole de gestion basé sur un protocole de type Internet, appelé encore "IP" pour "Internet Protocol".
Plus particulièrement, elle concerne l'échange et/ou transfert de données tels que des fichiers ou des alarmes entre un serveur de gestion et des appareils de service tels que des téléphones d'un réseau de téléphonie public, des terminaux de paiement, des terminaux applicatifs, des horodateurs, des distributeurs automatiques ou analogues.
D'une manière générale, un réseau de téléphonie public comporte généralement un (ou plusieurs) ordinateur central ou serveur de gestion, ci-après appelé serveur PMS (acronyme du terme anglo-saxon "Payphone Management System" ) , permettant à l'opérateur du réseau d'opérer la supervision des différents téléphones publics répartis sur un territoire donné du réseau. Le serveur PMS a pour fonction d'échanger des données avec le parc de téléphones publics via le réseau de téléphonie.
En pratique, les téléphones publics communiquent au serveur PMS un rapport d'activité détaillant par exemple le nombre et montant des transactions. Les téléphones publics communiquent également sous forme d'alarme l'éventuelle survenue d'un événement (panne, acte de vandalisme, etc..) nécessitant l'intervention d'un agent de maintenance.
Le serveur PMS, quant à lui, transfère aux téléphones publics des fichiers, des tables de tarifs ou encore des mises à jour de programmes faisant fonctionner les microprocesseurs des téléphones, mises à jour améliorant les programmes déjà en place, ou bien encore introduisant de nouvelles prestations pour les usagers.
Aujourd'hui, les transferts de fichiers entre les téléphones publics et le serveur PMS sont gérés selon un protocole de gestion qui est devenu obsolète, et en décalage avec les exigences de rapidité et d'évolution d'aujourd'hui. De plus, chaque nouvelle fonction ayant un impact sur le protocole actuel engendre des tests complets sur le protocole. De même, une modification protocolaire implique le plus souvent une modification de l'ensemble des sous-systèmes (publiphones, serveurs bancaires). Il en résulte que le protocole actuel n'est pas adapté aux évolutions du marché et/ou des services (messageries électroniques de type e-mail, SMS, ou des services Internet de type e-commerce ou analogue).
La présente invention remédie à ces inconvénients.
Elle porte sur un procédé d'échange de données entre au moins un appareil de service et au moins un serveur de gestion distant conformément à un protocole de gestion choisi.
Selon une définition générale de l'invention, le protocole de gestion est basé sur IP et comprend au moins une règle d'initiation pour initier chaque session d'échange et au moins une règle de reprise pour lancer une éventuelle reprise en cas de non-aboutissement de l'échange.
Ainsi, le protocole de gestion selon l'invention, de par son fonctionnement sur IP, permet une étanchéité par rapport au réseau et permet ainsi un dialogue client/serveur sur différents types de réseaux (PSTN,ISDN, Internet). Une connexion est possible à des réseaux divers et variés sans changer ou adapter le protocole de communication entre les appareils de service et le serveur. Une modification sur la structure des données au niveau du protocole est aisée et évite des modifications sur d'autres couches du protocole IP. De plus, un tel protocole permet le pilotage des échanges de données notamment en ce qui concerne 1 ' initiation des sessions et leur éventuelle reprise en cas de non-aboutissement de l'échange. Le protocole permet aussi de travailler en ligne (on-line) ou hors-ligne (off-line). Un tel protocole est avantageusement susceptible d'être mis en oeuvre dans un environnement sans fil de type GSM, CDMA ou TDMA.
Selon une autre caractéristique de l'invention, en cas de rupture d'une session d'échange au cours duquel des données sont transférées de l'appareil vers le serveur, la règle de reprise comprend une étape selon laquelle le transfert est repris en totalité en cas de changement de statut de l'appareil.
Selon encore une autre caractéristique de l'invention, en cas de rupture d'une session d'échange au cours duquel les données sont transférées du serveur vers l'appareil de service, la règle de reprise comprend une étape selon laquelle la session d'échange est reprise à l'endroit de la rupture sans reprendre la partie de l'échange déjà réalisé avant la rupture.
De préférence, la règle de reprise est adaptée au travail à réaliser par l'appareil de service, à l'importance de la tâche et à son impact.
Selon l'invention, la procédure de reprise peut comprendre une étape consistant à répéter la tentative de reprise indéfiniment jusqu'à remettre en fonctionnement l'appareil de service et/ou une étape consistant à différer la reprise d'une période de temps choisie et/ou une étape consistant à reprendre l'échange après un déclenchement de l'appareil de service.
En pratique, la règle d'initiation comprend les étapes suivantes : - i) au niveau de l'appareil de service, émettre une requête de connexion "CONNECT" au serveur conformément au protocole ;
- ii) au niveau du serveur, recevoir la requête de connexion "CONNECT", analyser les informations contenues dans ladite requête de connexion et émettre une réponse en fonction du résultat de l'analyse ; et
- iii) au niveau de l'appareil, recevoir la réponse, et en cas de réponse positive "ACCEPT", synchroniser le terminal et le serveur et établir la session d'échange.
En pratique, le protocole de gestion comprend une procédure de terminaison comprenant les étapes suivantes :
- iv) au niveau du serveur, à l'issue de la session d'échange, émettre un ordre de déconnexion "DISCONNECT" à destination de l'appareil de service ; et
- v) au niveau de l'appareil, recevoir l'ordre de déconnexion "DISCONNECT" et arrêter la session d'échange.
Selon un autre aspect de l'invention, les données à échanger entre l'appareil et le serveur sont déterminées par le serveur.
D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description détaillée ci- après et des dessins dans lesquels :
- la figure 1 est une vue schématique d'un réseau de téléphonie public utilisé pour la mise en oeuvre du procédé selon 1 ' invention ;
la figure 2 illustre schématiquement l'architecture matérielle des appareils de service et du serveur dans lequel s'insère le protocole de gestion selon l'invention ; - la figure 3 illustre les étapes de l'initiation d'une session selon le protocole sur IP conforme à l'invention ;
- la figure 4 illustre les étapes d'un téléchargement d'un fichier statuts sur FTP de l'appareil vers le serveur conformément à l'invention ;
- la figure 5 illustre les étapes d'un téléchargement de fichiers sur FTP de l'appareil vers le serveur et d'un télédéchargement de fichiers sur FTP du serveur vers l'appareil conformément à l'invention ;
- la figure 6 illustre les étapes d'un téléchargement de fichiers alarmes sur FTP de l'appareil vers le serveur et d'un télédéchargement de fichiers de configuration sur FTP du serveur vers l'appareil conformément à l'invention ;
- la figure 7 illustre les étapes d'un téléchargement de fichiers sur FTP de l'appareil vers le serveur conformément à l'invention ;
- les figures 8 et 9 illustrent les étapes d'exemples de télédéchargement de fichiers sur FTP du serveur vers l'appareil conformément à l'invention ;
- la figure 10 illustre les étapes d'un échange de messages de l'appareil vers le serveur conformément à l'invention ;
- les figures 11 à 13 représentent des exemples de terminai- son d'une session selon l'invention ;
- les figures 14 à 17 représentent d'autres exemples de terminaison d'une session selon l'invention ;
- les figures 18 à 23 représentent des exemples de politiques de reprise de session conformément au protocole de l'invention ; - les figures 24 à 28 représentent d'autres exemples de politiques de reprise de session conformément au protocole de l'invention.
En référence à la figure 1, on a représenté un réseau 1 de téléphonie public qui comprend un parc de téléphones publics 10 (un même parc peut comprend de plusieurs dizaines à plusieurs milliers de téléphones, voire plusieurs dizaines de milliers, suivant la couverture territoriale du réseau).
Les téléphones 10 sont destinés à être utilisés par les usagers, en libre service et sont donc installés à cette fin dans des lieux publics, tels que la rue, ou semi-publics tels que des centres commerciaux, des aéroports, des halls d'hôtels, des restaurants, des magasins, etc..
Ces téléphones 10 permettent aux usagers d'effectuer des communications téléphoniques, en utilisant un réseau téléphonique approprié référencé 2 qui peut être de type commuté, analogique, ou de type commuté numérique. Le réseau 2 peut également être constitué par un réseau de radiotéléphonie mobile et ce, quelle que soit sa nature, ou encore par le réseau Internet ou plus généralement par tout réseau de communication apte à transmettre des données ainsi que par toute combinaison de tels réseaux.
Ces téléphones publics 10 peuvent être également adaptés pour accéder à des serveurs d'informations ou de fourniture de services Web et de l'Internet ainsi qu'à des serveurs d'informations ou de fourniture de services résidant sur des réseaux privés. De tels accès permettent à l'opérateur exploitant le réseau 1, de proposer aux usagers une large palette de services allant par exemple, et à titre non limitatif, de la lecture de leurs courriers électroniques à la consultation d'informations locales (liste des médecins de garde de la zone du téléphone public, etc..). Bien évidemment, l'invention n'est pas limitée aux téléphones publics offrant de tels accès à Internet et à des serveurs privés.
Ces téléphones publics 10 sont par ailleurs adaptés pour communiquer avec un serveur 5 appelé PMS (Payphone Management System) , dédié au fonctionnement et à la gestion du réseau de téléphonie public 1. Le serveur PMS 5 a pour fonction d'échanger avec le parc de téléphones publics 10 des infor- mations concernant leur fonctionnement et plus généralement le fonctionnement du système de téléphonie publique. En particulier, le serveur PMS 5 gère les sessions d'initialisation des téléphones publics et établit des données statistiques à partir des informations reçues des téléphones publics 10 (alarmes, compteurs d'exploitation,...). Les échanges entre les appareils de service 10 et le serveur 5 sont sous la forme requête REQ réponse REQ.
Les téléphones publics 10 et le serveur PMS 5 sont munis de moyens appropriés de supervision et de réception/émission d'informations. Ces moyens de supervision et de réception/émission sont chargés d'organiser les échanges d'informations entre les téléphones publics 10, le serveur PMS 5 et un serveur FTP 4 (File Transfert Protocol), c'est-à-dire "protocole de transfert de fichier".
Entre autres fonctions, le serveur PMS 5 transfère vers les téléphones publics 10 les fichiers nécessaires à leur fonctionnement tels que des tables de tarifs, des paramètres de configuration, comme le type de numérotation, les caractéristiques de la ligne, etc.., des listes d'opposition ou de surveillance de moyens de paiement utilisés.
De leur côté, les téléphones publics 10 transmettent des informations relatives à leur utilisation, à savoir un rapport journalier comportant des données relatives aux transactions effectuées, au trafic, un rapport d'alarme qui permet de signaler au serveur PMS 5 la survenue d'incidents ou des atteintes à leur intégrité, comme une panne sur le lecteur de carte ou un combiné arraché, de manière à prévoir l'intervention d'un agent de surveillance, un fichier de statuts caractérisant le contenu du téléphone (telles que les indications des différentes versions de programmes utilisés par le microprocesseur).
Pour faciliter les échanges de données, on utilise un serveur FTP 4 spécifiquement conçu et adapté aux transferts de fichiers appelé FTP. A partir de commandes reçues par le serveur PMS 5, chaque téléphone public 10 qui intègre une entité FTP client, va se connecter au serveur FTP 4 et télécharger ou télédécharger des fichiers appropriés.
Par ailleurs, les téléphones publics 10 peuvent se connecter à un serveur PROXY 6 servant d'interface de communication entre les téléphones publics et le serveur PMS 5.
En référence à la figure 2, pour permettre la connexion aux différents serveurs et notamment au serveur PROXY 6, au serveur PMS 5 ou au serveur FTP 4, les appareils de service 10 (ici des téléphones) sont équipés de protocoles de communication 12 de type TCP/IP, et 14 UDP/IP conformes aux recommandations techniques de l'IETF (Internet Engineering Task Force) .
Chaque téléphone public 10 comprend un système d'exploitation 16, une interface standard 18 de type "socket", un protocole 20 de type terminal ou TELNET pour "Network Terminal Protocol" et un protocole 22 de type FTP client.
Le protocole de gestion PFSP côté client (pour Payphone session protocol) selon l'invention est logé dans la couche 24.
Par exemple, l'appareil de service 10 est dédié à une application 26 de type téléphone public
De son côté, le serveur PMS 5 est équipé de protocoles de communication 32 de type TCP/IP, et 34 UDP/IP conformes aux recommandations techniques de l'IETF (Internet Engineering Task Force) .
Le serveur PMS 5 comprend en outre un système d'exploitation (non représenté), une interface standard 38 de type "socket", un protocole 40 de type terminal ou TELNET pour "Network Terminal Protocol" et un protocole 42 de type FTP serveur.
Le protocole de gestion PFSP côté serveur selon l'invention est logé dans la couche 44.
Par exemple, le serveur PMS 5 est dédié à une application 46 de type téléphone public.
Le serveur PROXY 6 combine différentes fonctions, notamment orienter les requêtes des téléphones publics 10, suivant la nature de ces requêtes, vers des serveurs correspondants ; le cas échéant traduire les données ou instructions émises par les téléphones 10 au format des serveurs destinataires ; contrôler la syntaxe des requêtes émises par les téléphones 10 avant retransmission et autoriser ainsi des accès authentifiés au réseau afin de conférer un degré de sécurité supplémentaire.
Une autre fonction du serveur PROXY est d'établir des sessions d'échanges d'informations fiables et authentifiées qui consistent par exemple à identifier de façon certaine les téléphones 10 lors d'un échange d'informations avec les serveurs ou encore à chiffrer les données afin de sécuriser la communication en cas de besoin.
Une autre fonction du serveur PROXY 6 est de piloter et réguler les échanges d'informations réalisés via les transferts de fichiers standard et conformes au protocole Inter- net.
Le serveur PROXY 6 a également pour fonction de diriger les requêtes des téléphones publics vers des serveurs de secours, notamment en cas d'indisponibilité d'un serveur et assurer ainsi une redondance d'architecture. Ainsi, dans l'hypothèse où le serveur PROXY 6 se trouve inaccessible par suite notamment d'opérations de maintenance, il est alors possible de diriger les compte-rendus journaliers des téléphones publics 10 correspondants vers un autre serveur de gestion alors disponible.
Ce basculement d'un serveur vers un autre est alors totalement transparent pour les téléphones publics 10 qui n'ont pas à gérer ainsi eux-mêmes des adresses de secours mais seulement l'adresse du serveur PROXY 6. La redondance du serveur PROXY 6 lui-même est également possible, évitant ainsi des ruptures de communication en cas de pannes constatées. Toute requête de connexion à un serveur parvient sur le port d'entrée de l'ordinateur qui est écouté en permanence par le serveur PROXY 6, puis est re-dirigée vers un port de travail. La requête est ensuite analysée par une application logicielle, par exemple en langage JAVA® permettant le contrôle et l'établissement d'une session au sens protocolaire du terme. Une interface standard (SOCKET) est alors ouverte et la requête est émise vers le serveur de destination, et inversement.
Bien évidemment, le mode de réalisation illustré n'a été donné qu'à titre d'exemple et n'est absolument pas limitatif de l'ensemble des solutions pouvant être mis en oeuvre grâce à la présente invention.
Ainsi, le serveur PROXY 6, le serveur PMS 5 et le serveur de fichiers FTP 4, au lieu d'être des machines séparées comme sur la figure 1 , peuvent être regroupées dans un seul ordinateur de type PC par exemple, comme en référence à la figure 2.
En référence à la figure 3, l'établissement d'une session gérée selon le protocole de gestion PFSP conforme à l'invention est avantageusement une session de type TCP/IP. La session est initiée (ou initialisée) par l'appareil 10 qui envoie un message S-Connect.req au serveur PMS 5 généré grâce à des programmes spécifiques mis en oeuvre par les microprocesseurs équipant l'appareil 10. Ce message S-Connect .req constitue la requête de connexion, appelée encore "CONNECT".
Le message S-Connect. req est acheminé au serveur 5 via le réseau 2, et interprété en message S-Connect .ind. Le serveur analyse le message S-Connect. ind. Après analyse, le serveur 5 émet un message S-Connect.res, qui constitue la réponse du serveur à la demande de connexion, appelée encore "ACCEPT" , en cas de réponse positive.
Le message S-Connect.res est acheminé au téléphone 10 via le réseau 2, et interprété en message S-Connect .cnf, confirmant l'établissement de la session TCP/IP.
L'événement déclenchant la connexion du téléphone 10 au serveur PMS 5 peut être de différents types . La connexion peut être initiée manuellement par un agent de maintenance par exemple lors de l'installation d'un nouveau téléphone 10 dans le réseau 1. La connexion peut être déclenchée automatiquement suite par exemple à la survenue d'une alarme (mon- nayeur plein, panne, vandalisme, etc). L'alarme peut être générée par des programmes de surveillance appropriés. La connexion peut également être déclenchée automatiquement pour des rapports d'activité générés par des programmes de supervision appropriés, rapports fournissant des statistiques sur l'activité du téléphone 10 et du signal exploitant du réseau 1 afin d'améliorer le fonctionnement de ce dernier. Ces programmes de supervision peuvent éditer leur rapport d'activité à des dates et des heures prédéterminées ou bien encore à des instants définis par le PMS 5. Le téléphone peut également se connecter au serveur PMS 5 suite à la demande expresse de ce dernier qui a donné l'ordre, lors d'un appel précédent au téléphone 10 de se connecter pour un motif donné: par exemple pour le téléchargement de fichiers. Le message de connexion CONNECT comporte essentiellement les informations suivantes :
- l'identifiant du téléphone 10 par exemple son numéro d'appel ;
- le type du téléphone 10, c'est-à-dire son code produit ;
- le type de session, c'est-à-dire le contexte de l'appel : télécollecte (rapport d'activité), téléchargement (transfert de fichiers vers le téléphone, en général il s'agit là d'un ordre préalable donné par le serveur PMS 5), alarme, etc ;
- la signature authentifiant ce téléphone 10, cette signature peut être obtenue par le cryptage au moyen d'un algorithme de cryptologie de type DES ou de tout autre type (RSA par exemple) .
Le téléphone 10 dispose alors d'une liste de sessions types qui définissent a priori la raison de l'appel du téléphone 10.
En général, et à l'exception des alarmes, cet appel a été programmé lors d'une session précédente.
Le serveur PMS 5 qui reçoit cet appel CONNECT procède tout d'abord à son analyse et notamment à la vérification de l'authenticité de cet appel puis renvoie un message d'acceptation ACCEPT qui comprend, entre autres données, la date et l'heure courante afin de procéder à une re-synchronisation entre les deux appareils, ainsi que l'heure et la date du prochain appel programmé.
Le serveur PMS 5 adresse ensuite une première demande de travail à réaliser. Cette demande de travail est principale ment de trois types :
- ordre de transfert de fichiers du serveur FTP 4 vers le téléphone 10 (download au format FTP) ; - ordre de transferts de fichiers du téléphone 10 vers le serveur FTP 4 (upload au format FTP) ; et
- ordre d'arrêt de la communication au format TCP/IP (dis- connect) .
Le protocole PFST pour "payphone session protocole" permet selon l'invention d'initier un échange (une session de communication) entre un téléphone 10 et un serveur en utilisant un protocole au format TCP/IP.
Ce protocole permet l'installation d'une session d'échange de données entre un client et un serveur sur n'importe quel type de réseau.
Comme décrit en référence à la figure 3, le message de connexion CONNECT permet l'initialisation de la session.
En référence à la figure 4, afin d'initialiser un appareil de service à partir du serveur, le serveur doit récupérer un fichier de configuration dit "STATUTS" de l'appareil de service. Ce fichier de configuration doit toujours être envoyé avant l'ordre de terminaison (disconnect) de la communication à la fin de la session.
Si le serveur 5 le souhaite, l'appareil de service peut récupérer un fichier contenant la table de tarifs actifs ou un fichier contenant la table de tarifs passifs. De même, si le serveur le souhaite, l'appareil de service peut récupérer un fichier de paramètres, une liste noire, une liste grise, un fichier contenant des logiciels segmentés et un fichier de configuration objet.
Après l'ordre ACCEPT, une session FTP proprement dite peut commencer. Elle peut être soit un chargement de fichiers dit UPLOAD ou bien un télédéchargement de fichiers de type DOWNLOAD.
En ce qui concerne l'ordre de téléchargement UPLOAD, le serveur émet une requête S.File. req. Cette requête est acheminée à travers le réseau à destination du téléphone correspondant .
Le premier ordre reçu par un téléphone 10 de la part du serveur 5 concerne le transfert d'un fichier encore appelé STATUTS précisant les références de l'ensemble ou des principaux fichiers constituant les ressources logicielles du téléphone. Ce fichier STATUTS permet ultérieurement au serveur PMS 5, en cas de dysfonctionnement, de déterminer les différentes versions de logiciels utilisées par le téléphone 10. Dans les échanges entre le serveur 5 et les téléphones 10, le serveur PMS 5 est toujours décisionnaire quant au fichier transféré, c'est le maître. De par l'architecture décrite, le serveur PMS 5 est à même, sur analyse du contexte précis d'appel de chaque téléphone 10, de demander à ce dernier un travail donné, modifiable et adaptable librement et facilement notamment en fonction des souhaits de l'exploitation du réseau. Une telle souplesse est par ailleurs sans incidence sur les téléphones 10 qui fonctionnent en mode esclave. La liste des fichiers à transférer dans un sens ou dans un autre se trouve donc communiquée dynamiquement au téléphone 10 par le serveur PMS 5 et ce après identification de la connexion, au travers de requêtes précises : CONNECT, ACCEPT, UPLOAD, DOWNLOAD, DISCONNECT.
Les téléphones ne connaissent donc pas à l'avance les fichiers à transférer, c'est uniquement le serveur PMS qui choisit les fichiers à transférer.
Une fois que le fichier STATUTS est acheminé par le réseau vers le serveur, le téléphone 10 émet une réponse de type S.File. res. Cette information est acheminée au serveur via le réseau 2. Une fois reçu, ce message constitue une confirmation du type S.File.Cnf .
En référence à la figure 5, l'opération de chargement de fichiers (UPLOAD) est initiée par la requête S.File.Req selon le format décrit ci-avant. Après réception de cette requête, le téléphone 10 interprète cette requête et délivre le message S. FILE. IND. A la suite de cette interprétation, le téléphone peut, sous le format FTP, charger dans le serveur différents fichiers qui peuvent être relatifs aux transactions, aux compteurs d'exploitation, aux alarmes courantes, aux fichiers LOG des alarmes, aux compteurs relatifs aux listes noires.
Le chargement de fichiers est terminé par la requête S. File,res émanant de l'appareil de service. Cette réponse est interprétée comme une confirmation après réception par le serveur.
Après avoir reçu un ordre de type UPLOAD ou DOWNLOAD, le téléphone 10 ouvre une session FTP avec le serveur FTP 4 dont l'adresse lui a été notifiée. La connexion au serveur FTP 4 en parallèle à la session courante est établie avec le serveur PMS 5 via le serveur PROXY 6. Le téléphone exécute ensuite le transfert de fichier demandé auprès du serveur FTP qui lui a été notifié. Une fois le transfert du ou des fichier(s) achevé, le téléphone adresse un message d'acquittement par lequel il confirme au serveur PMS que le travail a été bien ou mal fait. Puis il se met en attente d'un nouvel ordre. En cas de non réception d'un nouvel ordre après un laps de temps prédéterminé, le téléphone coupe la communica- tion comme on le décrira plus en détail ci-après.
Il est à remarquer que dans la phase de chargement UPLOAD, les fichiers téléchargés comprennent des fichiers de configuration si au moins l'un des paramètres a changé. Ce fichier est toujours envoyé avant l'ordre de terminaison de la communication à la fin de la session. Par exemple, le serveur PMS 5 peut profiter de l'appel de chaque téléphone 10 pour son rapport d'activité quotidien (encore appelé télécollecte) pour opérer le téléchargement d'une mise à jour de program- mes.
Par exemple, lors de l'initialisation d'un nouveau téléphone 10 au réseau de téléphonie publique 1, l'agent de mise en service va demander systématiquement certaines informations liées à la configuration du téléphone 10 (par exemple un fichier de configuration) et ce à travers le lancement d'une session dédiée. En retour, le serveur PMS peut non seulement transférer le fichier demandé mais également obtenir d'autres fichiers en retour de type table de tarif active, une table de tarif passive, une table de paramètres, une liste noire, une liste grise, un logiciel, etc..
De même, lors d'une session de télécollecte du rapport journalier d'activité, le PMS 5 pourra non seulement récupérer les fichiers des transactions, les compteurs d'exploitation et les alarmes mais également il pourra télécharger en retour une table de tarif active, une table de tarif passive, une table de paramètres, une liste noire, une liste grise, un logiciel.
En référence à la figure 6, la session relative au report d'alarme comprend comme enseigné ci-avant une requête de type UPLOAD à l'issue de laquelle un fichier FTP est téléchargé dans le serveur.
Les fichiers téléchargés peuvent être un fichier de configuration, des fichiers d'alarme présente, le fichier dit alarme Log ainsi des transactions.
A la suite de ce fichier ainsi téléchargé, un ordre DOWNLOAD peut être suivi et effectué afin de télédécharger un fichier de configuration du serveur vers l'appareil de service.
II est à noter que dans la session de report d'alarme, il est obligatoire de ne pas envoyer, dans le message S.CONNECT.RES la date de report quotidien.
En référence à la figure 7, l'invention peut prévoir égale- ment une session de télédiagnostic dans laquelle des fichiers sont téléchargés dans le serveur. Ces fichiers téléchargés peuvent comprendre un fichier de configuration, un fichier de transaction, un fichier des compteurs d'exploitation, un fichier d'alarme présente, le Log des alarmes, un fichier de compteur de liste noire et un fichier de compteur de liste grise.
En référence aux figures 8 et 9, le serveur peut également initier une session de télédéchargement dans laquelle des fichiers sont télédéchargés du serveur vers l'appareil de service correspondant. Les fichiers télédéchargés sont par exemple des fichiers de table de tarif active, ou passive, un fichier de paramètres, un fichier de liste noire ou grise, un fichier de logiciels segmentés et, le cas échéant, un fichier de configuration objet.
La session de téléchargement proprement dite comprend le télédéchargement d'un fichier de configuration, etc..
En référence à la figure 10, le protocole permet également de gérer des sessions de requêtes de contenus et de courriels ou e-mail. L'établissement de la session est initié selon le protocole mentionné ci-avant avec les ordres CONNECT et ACCEPT. Après établissement de la connexion, le téléphone émet une requête S.Methodinvoke.req. Cette requête correspond à l'ordre GET/POST en messagerie sous TCP/IP. Le serveur reçoit cette requête via le réseau de téléphonie et il interprète en requête S.Methodinvoke.ind. Le serveur analyse cette requête et émet en réponse le message S.Methodinvoke.- res qui constitue une réplique ou réponse du serveur. Le téléphone ou appareil de service confirme cette réponse avec le message S.Methodinvoke.cnf.
La session se termine selon le protocole mentionné ci-avant avec l'ordre DISCONNECT.
Le transfert de contenu peut contenir une ou plusieurs requête(s) de contenu et de transfert.
En cas de session anormale, le protocole prévoit plusieurs règles de traitement. Selon l'invention, le protocole PFSP prévoit plusieurs règles permettant de traiter des sessions anormales.
En premier lieu, une session peut être considérée comme anormale lorsque le format de la requête est incorrect. Dans ce cas, un message "DISCONNECT" est envoyé accompagné d'un code de type PROTERR par l'intermédiaire du serveur PROXY à destination du serveur PMS et de l'appareil de service correspondant .
En référence à la figure 11, l'établissement de la connexion ou de la session de type TCP/IP peut être refusé par le serveur de communication PROXY, par exemple lorsque le service n'est pas disponible. Dans ce cas, le serveur de communication PROXY émet à la destination de l'appareil de service un message DISCONNECT qui, une fois reçu par l'appareil de service, est interprété en S.DISCONNECT. IND avec le code correspondant CONNECTERR.
En référence à la figure 12, l'établissement de la connexion peut être refusé par le serveur PMS. Dans ce cas, après la demande de connexion émanant de l'appareil de service, le serveur émet un message S.DISCONNECT.REQ contenant le code correspondant qui peut avoir la définition REDIAL CONGESTION ou PEERREQ en fonction de l'événement provoquant le refus.
Le message DISCONNECT est envoyé à l'appareil de service.
En référence a la figure 13, une temporisation par exemple de l'ordre de 30 secondes peut être prévue à la suite d'une première demande de connexion n'ayant pas aboutie. Ainsi, l'appareil de service émet une requête de terminaison S.DISCONNECT.REQ avec le code PEERREQ à destination du serveur, après une temporisation de 30 secondes par rapport à sa première demande de connexion S .CONNECT.REQ.
De même, en référence à la figure 14, il est prévu une demande de terminaison émanant du serveur avec le message S. DISCONNECT.REQ et le code PEERREQ lors d'un télédécharge- ment ou d'un téléchargement qui n'aboutit pas à l'issue d'une période choisie. Cette période TX a une valeur qui dépend du nombre de fichiers transférés et de la taille de chacun de ces fichiers. Cette période TX peut être calculée par le serveur.
En référence à la figure 15, l'appareil de service peut émettre un message de terminaison de session S.DISCONNECT.REQ avec le code CONGESTION à l'attention du serveur lorsque, par exemple, des erreurs internes sont détectées ou bien lorsque des problèmes de gestion des fichiers en mémoire vive sont détectés au niveau de l'appareil de service. La cohérence du codage, notamment sa syntaxe est vérifiée par le serveur PROXY de communication. Le motif de la demande de terminaison se trouve dans le code correspondant, ici CONGESTION.
En référence à la figure 16, une demande de terminaison de session est émise par le serveur avec le code correspondant à DISCONNECT REDIAL dans le cas d'un télédéchargement (DOWNLOAD).
De même, en référence à la figure 17, une demande de terminaison requise par l'appareil de service avec le message S.DISCONNECT.REQ et le code PEERREQ après une temporisation par exemple de 30 secondes.
Cette demande de terminaison peut avoir lieu à l'issue d'une temporisation dont le départ est formé par le résultat du transfert.
La présente invention prévoit également un protocole qui gère les reprises de sessions, après ruptures de celles-ci. Ainsi, en réponse à une rupture d'une session, il est prévu une règle de reprise de la session jusqu'à ce que la connexion soit ré-établie afin d'être correctement traitée.
En référence à la figure 18, la gestion de reprise peut intervenir dans le cas d'une transaction PFSP, de type TCP/IP, comme celle décrite en référence à la figure 3. Dans ce cas, la procédure de reprise prévoit de renouveler la demande de connexion S .CONNECT.REQ.
En référence à la figure 19, la reprise de la session peut intervenir également après réception de la demande de connexion avec établissement de la connexion au niveau du serveur mais avant la réception du message ACCEPT au niveau de l'appareil de service.
En référence à la figure 20, la gestion de la reprise de la session peut intervenir au niveau de l'opération de téléchargement de fichier. Par exemple en cas de difficulté dans le fichier de statut de l'appareil de service, le protocole selon l'invention gère une telle rupture.
De même, en référence à la figure 21, la gestion de la reprise peut intervenir au niveau d'un téléchargement d'un fichier du type UPLOAD.
II en est de même en référence à la figure 22 de l'opération de télédéchargement de type DOWNLOAD. Dans ce cas, une politique de reprise est prévue selon l'invention.
En référence à la figure 23, la gestion de la reprise peut intervenir également lors de la rupture de la session avant réception du message DISCONNECT au niveau de l'appareil de service.
Selon l'invention, les causes qui déclenchent la gestion des reprises peuvent être de différente nature :
- coupure de la ligne, expiration de la temporisation ou bien encore des problèmes techniques au niveau du serveur, du modem de l'appareil de service.
En référence à la figure 24, aucune gestion des reprises n'est prévue lors d'une initialisation réalisée à la demande de l'opérateur. En référence à la figure 25, une première tentative de reprise RI de connexion est prévue, par exemple, après 5 minutes de la rupture en cas d'un défaut dans la valeur d'un paramètre. Cette tentative RI en cas d'échec est recommencée un certain nombre de fois, par exemple 2 (individualisées ici en R2 et R3). Dans le cas d'un échec à l'issue des trois tentatives, la politique de reprise ne prévoit pas ici de nouvelles tentatives et la session est définitivement interrompue. Cette politique de reprise est par exemple mise en oeuvre lors d'une téléinitialisation ou d'un télédiagnostic.
En référence à la figure 26, une règle de reprise particulière est prévue dans le cas d'une télécollecte quotidienne.
La règle de reprise comprend deux branches d'interventions. Dans la première branche, la rupture C de la télécollecte (par exemple en raison d'un défaut dans la valeur d'un paramètre émanant du serveur), la télécollecte peut être reprise à l'issue d'une procédure qui débute par le réveil de l'appareil (par exemple une demande de communication de la part d'un usager du téléphone public ou encore l'introduction d'une carte de paiement), suivi d'une mise en sommeil et qui se termine par la tentative de la reprise 5 minutes après la mise en sommeil. Cette tentative de reprise est de préférence sans limites, c'est-à-dire jusqu'à l'aboutissement de la télécollecte.
Dans la seconde branche, la télécollecte est différée RD d'un laps de temps choisi, par exemple 12 heures. Cette seconde branche est mise en oeuvre lorsqu'il n'y a pas de réveil de l'appareil par un usager tel que décrit ci-avant dans la première branche.
En pratique, si la tentative de reprise de la première branche est un succès, la programmation de la reprise différée est supprimée jusqu'à la prochaine télécollecte. En référence à la figure 27, en cas de rupture de communica tion lors de la procédure d'alarme, une tentative de reprise est mise en oeuvre dans les 5 minutes qui suivent la rupture. Par exemple, le nombre de tentatives peut être limité à 3. Par contre, en cas de réveil de l'appareil par une opération manuelle telle que l'introduction d'une carte ou un décroché de l'appareil téléphonique, la règle de reprise prévoit d'initialiser à nouveau la procédure d'alarme jusqu'à ce que la procédure d'alarme fonctionne correctement.
En référence à la figure 28, une procédure de reprise est prévue lors du télédéchargements de plusieurs objets ou bien encore lors de la procédure d'initialisation après la session de télédéchargement. Dans cette procédure de reprise, on retrouve le cycle court des reprises (5 minutes) et un cycle long (15 minutes) qui peut être déclenché automatiquement par un horodateur.
Dans le cas de l'opération de télédéchargement (DOWNLOADING) , l'appareil de service initialise la procédure de reprise et le serveur joue toujours le même scénario après identification correcte de l'appareil de service. Dans ce cas, l'appareil de service retrouve les fichiers manquants après une analyse correcte. En d'autres termes, la reprise s'effectue à l'endroit de la rupture sans reprendre la partie de l'échange déjà réalisé avant la rupture.
Comme vu ci-avant, il n'en est pas de même dans l'opération de téléchargement de fichiers (UPLOADING). En effet, pendant la période de rupture, l'appareil de service peut modifier ou avoir changé ses statuts. Dans ces conditions, une reprise de la session de téléchargement partielle engendre une incorrection au niveau du statut de l'appareil de service. Dans ce cas-là, il convient selon l'invention de prévoir une politi- que de reprise qui reprend complètement le chargement de l'ensemble des fichiers.
En pratique, dans le cas d'une coupure d'une ligne intervenant lors de l'émission du signal S.Disconnect .req, l'appa- reil de service peut tenter d'initialiser une reprise de communication (comme bien sûr, à tout autre instant de rupture). En réponse, le serveur envoie alors les scénarios prévus. Toutefois, parce qu'il a déjà l'ensemble des objets, l'appareil de service envoie à l'attention du serveur uniquement un acquittement correct, signalant la mise en place ultérieure des objets, et attend de la part du serveur uniquement le message de terminaison S.Disconnect, ceci à des fins de gain de temps et d'éviter des répétitions inutiles.
Dans les tableaux A et B ci-contre, on a représenté les différentes règles de reprise des sessions en présence d'événements prédéterminés.
tableau A
tableau B
Les tableaux A et B font partie intégrante de la présente invention. Ils comprennent des éléments de caractère certain qui peuvent servir à la définition de l'invention le cas échéant.
Dans ces tableaux, on distingue 5 types de sessions, à savoir initiation, télécollecte quotidienne, alarme, télédéchargement (download), et appel serveur PMS. Pour ces différentes sessions, on prévoit 8 types d'événements, à savoir erreur de protocole, validation, encombrement, abandon ou échec, erreur de réseau, rappel, erreur de connexion, et coupure de ligne.
Par exemple, il n'est pas prévu de reprise dans le cas d'une d'une erreur de protocole en procédure de télédéchargement (download) . En revanche, en télédéchargement, une politique de reprise est prévue en cas d'erreur de réseau, comme indiquée ci-avant.
Par ailleurs, la gestion des reprises peut distinguer une reprise différée qui intervient de préférence après un cycle immédiat court pour permettre à l'opérateur de rétablir le système avant répétition (évite ainsi les échanges inutiles) et une reprise immédiate qui constitue la reprise de la session initiale.
Bien entendu, l'invention n'est pas limitée aux formes de réalisation décrites précédemment à titre d'exemple et s'étend à d'autres variantes.

Claims

Revendications
1. Procédé d'échange de données entre au moins un appareil de service (10) et au moins un serveur de gestion (5) distant conformément à un protocole de gestion choisi, caractérisé en ce que le protocole de gestion est sur IP et comprend au moins une règle d'initiation de chaque session d'échange et au moins une règle de reprise pour lancer une éventuelle reprise en cas de non-aboutissement de l'échange.
2. Procédé selon la revendication 1 , caractérisé en ce qu'en cas de rupture d'une session d'échange au cours duquel les données sont transférées de l'appareil (10) vers le serveur (5) (UPLOAD), la règle de reprise comprend une étape selon laquelle le transfert est repris en totalité en cas de changement de statut de l'appareil.
3. Procédé selon la revendication 1, caractérisé en ce qu'en cas de rupture d'une session d'échange au cours duquel les données sont transférées du serveur (5) vers l'appareil de service (10) (DOWNLOAD), la règle de reprise comprend une étape selon laquelle la session d'échange est reprise à l'endroit de la rupture sans reprendre la partie de l'échange déjà réalisé avant la rupture.
4. Procédé selon la revendication 1, caractérisé en ce que la règle de reprise est adaptée au travail à réaliser par l'appareil de service, à l'importance de la tâche et à son impact.
5. Procédé selon la revendication 4, caractérisé en ce que la procédure de reprise comprend une étape consistant à répéter la tentative de reprise indéfiniment jusqu'à remettre en fonctionnement l'appareil de service.
6. Procédé selon la revendication 4, caractérisé en ce que la règle de reprise comprend une étape consistant à différer la reprise d'une période de temps choisie.
7. Procédé selon la revendication 4, caractérisé en ce que la règle de reprise comprend une étape consistant à reprendre l'échange après un déclenchement de l'appareil de service.
8. Procédé selon la revendication 1, caractérisé en ce que la règle d'initiation comprend les étapes suivantes : -i) au niveau de l'appareil de service, émettre une requête de connexion (CONNECT) au serveur conformément au protocole, -ii) au niveau du serveur, recevoir la requête de connexion (CONNECT), analyser les informations contenues dans la requête et émettre une réponse en fonction du résultat de l'analyse, et
-iii) au niveau de l'appareil, recevoir la réponse et en cas de réponse positive (ACCEPT), synchroniser l'appareil et le serveur et établir la session d'échange.
9. Procédé selon la revendication 1, caractérisé en ce que le protocole de gestion comprend en outre une procédure de terminaison sur IP comprenant les étapes suivantes : -iv) au niveau du serveur, à l'issue de la session d'échange, émettre un ordre de déconnexion (DISCONNECT) à la destination de l'appareil de service, et
-v) au niveau de l'appareil de service, recevoir l'ordre de déconnexion (DISCONNECT) et arrêter la session d'échange.
10. Procédé selon l'une des revendications précédentes, caractérisé en ce que le protocole de gestion prévoit en outre une politique pour le téléchargement de fichiers de l'appareil vers le serveur sur FTP.
11. Procédé selon l'une des revendications précédentes, caractérisé en ce que le protocole de gestion prévoit en outre une politique pour le télédéchargement de fichiers du serveur vers l'appareil sur FTP.
12. Procédé selon l'une des revendications précédentes, caractérisé en ce que le protocole de gestion prévoit une politique pour le transfert de message sur IP entre l'appareil et le serveur et réciproquement.
13. Appareil de service pour la mise en oeuvre du procédé selon l'une des revendications 1 à 12.
14. Serveur pour la mise en oeuvre du procédé selon l'une des revendications 1 à 12.
EP02755077A 2001-07-02 2002-06-21 Procede d'echange de donnees entre un appareil de service et un serveur de gestion selon un protocole de gestion sur ip Withdrawn EP1402715A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0108751 2001-07-02
FR0108751A FR2826751B1 (fr) 2001-07-02 2001-07-02 Procede d'echange de donnees entre un appareil de service et un serveur de gestion selon un protocole de gestion sur ip
PCT/FR2002/002159 WO2003005694A1 (fr) 2001-07-02 2002-06-21 Procede d'echange de donnees entre un appareil de service et un serveur de gestion selon un protocole de gestion sur ip

Publications (1)

Publication Number Publication Date
EP1402715A1 true EP1402715A1 (fr) 2004-03-31

Family

ID=8865025

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02755077A Withdrawn EP1402715A1 (fr) 2001-07-02 2002-06-21 Procede d'echange de donnees entre un appareil de service et un serveur de gestion selon un protocole de gestion sur ip

Country Status (4)

Country Link
EP (1) EP1402715A1 (fr)
CO (1) CO5550511A2 (fr)
FR (1) FR2826751B1 (fr)
WO (1) WO2003005694A1 (fr)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6118860A (en) * 1997-09-12 2000-09-12 Nortel Networks Corporation Public communications services vending method and apparatus
FR2782436B1 (fr) * 1998-08-14 2000-10-13 Schlumberger Ind Sa Reseau de telephonie publique connecte a un systeme de transport d'informations
WO2000062523A1 (fr) * 1999-04-08 2000-10-19 Powerphone Network Limited Systeme de publiphone multimedias interactif combinant la technologie de reseau et de telephonie
FR2796233B1 (fr) * 1999-07-09 2001-08-31 Schlumberger Systems & Service Systeme de telephonie a architecture ouverte

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Free FTP/Download Software", 5 June 2001 (2001-06-05), Retrieved from the Internet <URL:http://web.archive.org/web/20010605231938/http://www.tech-sol.net/interlinks/ftp-soft.htm> [retrieved on 20050912] *

Also Published As

Publication number Publication date
WO2003005694A1 (fr) 2003-01-16
CO5550511A2 (es) 2005-08-31
FR2826751B1 (fr) 2003-10-03
FR2826751A1 (fr) 2003-01-03

Similar Documents

Publication Publication Date Title
FR2893803A1 (fr) Methode de communication entre une cartre (u)sim en mode serveur et un client
WO2004068809A1 (fr) Procede de presentation d’etat d’un utilisateur utilisant plusieurs equipements de communication
EP2210396B1 (fr) Système d&#39;interconnexion entre au moins un appareil de communication et au moins un système d&#39;information distant et procédé d&#39;interconnexion
US6954791B2 (en) Time-based network connections
FR2946164A1 (fr) Procede de telechargement de donnees de grande taille vers un grand nombre de machines clientes en reseau a partir d&#39;un serveur unique
WO2004002179A1 (fr) Procede de fourniture de donnees de configuration de service a un dispositif de telephonie mobile, par un terminal informatique
EP1192796A1 (fr) Gestion de telephones publics
EP1595371A1 (fr) PROCEDE DE GESTION DE PRESENCE SELECTIVE POUR SERVICE DE MESSAGERIE INSTANTANEE AU SEIN D&amp;rsquo;UN RESEAU DE TELECOMMUNICATION TEL QUE LE RESEAU INTERNET
EP1484859B1 (fr) Procédé de contrôle avec gestion d&#39;un identifiant opaque d&#39;utilisateur de la livraison complète d&#39;un service utilisant un ensemble de serveurs
EP1402715A1 (fr) Procede d&#39;echange de donnees entre un appareil de service et un serveur de gestion selon un protocole de gestion sur ip
FR2951898A1 (fr) Procede d&#39;etablissement d&#39;une session applicative, dispositif et notification correspondante
FR2843847A1 (fr) Systeme permettant d&#39;etablir une connexion telnet avec un dispositif eloigne depourvu de modem
EP1344411B1 (fr) Interface de communication entre pcs et plates-formes auxiliaires dans un reseau ri
FR2841720A1 (fr) Procede d&#39;individualisation d&#39;un terminal relie a au moins un serveur a travers un reseau
FR2816784A1 (fr) Procede de transfert de fichiers entre des appareils de service et un serveur de gestion a distance
EP1523832B1 (fr) Procédé pour connexion à un système électronique par l&#39;intermédiaire d&#39;un fournisseur d&#39;accès à un réseau de communication
FR2820261A1 (fr) Procede de transfert de donnees entre un appareil de service et un serveur de gestion a distance
EP1744508A2 (fr) Procédé de mise en relation interpersonnelle
FR2847405A1 (fr) Procede de gestion de messages, systeme et entites de communication pour la mise en oeuvre du procede
FR3050892A1 (fr) Procede de controle d&#39;une passerelle residentielle d&#39;un reseau de communication, procede de supervision, procede d&#39;execution d&#39;une action, dispositifs et programme d&#39;ordinateur correspondants.
EP1239647A1 (fr) Procédé et dispositifs de sécurisation d&#39;une session de communication
FR2846821A1 (fr) Dispositif et procede de controle de donnees de gestion d&#39;equipements de reseau, pour un systeme de gestion de reseau de communications
WO2006072688A1 (fr) Procede et systeme de surveillance d’une ligne d’acces a un service
EP1512301A1 (fr) Procede d envoi de messages courts par un reseau de telephonie publique
WO2001091432A1 (fr) Procede de gestion d&#39;un reseau de telephonie publique permettant d&#39;acceder a internet, telephone public et serveur de gestion pour sa mise en oeuvre

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20031230

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: AXALTO S.A.

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SCHLUMBERGER SYSTEMES

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SCHLUMBERGER PAYPHONES S.A.S

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SPT PUBLICOM

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20080103