WO2007119024A1 - Gestion de flux applicatifs dans des reseaux mobiles - Google Patents

Gestion de flux applicatifs dans des reseaux mobiles Download PDF

Info

Publication number
WO2007119024A1
WO2007119024A1 PCT/FR2007/051120 FR2007051120W WO2007119024A1 WO 2007119024 A1 WO2007119024 A1 WO 2007119024A1 FR 2007051120 W FR2007051120 W FR 2007051120W WO 2007119024 A1 WO2007119024 A1 WO 2007119024A1
Authority
WO
WIPO (PCT)
Prior art keywords
decision
terminal
field
identifier
message
Prior art date
Application number
PCT/FR2007/051120
Other languages
English (en)
Inventor
Servane Bonjour
Karine Guillouard
Lucian Suciu
Original Assignee
France Telecom
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 France Telecom filed Critical France Telecom
Priority to US12/297,463 priority Critical patent/US8271405B2/en
Priority to EP07731896.2A priority patent/EP2008489B1/fr
Publication of WO2007119024A1 publication Critical patent/WO2007119024A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/12—Protocol engines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Definitions

  • the field of the invention is that of decision graphs. More specifically, the invention relates to a decision graph construction technique for the management of application flows assigned to terminals, each application flow being established between a terminal and a correspondent (that is to say a device with which communicates the terminal), via at least one communication network.
  • the invention applies in particular, but not exclusively, to the implementation of a terminal mobility service between access networks (management of handovers).
  • the decision can also be applied to other types of decision, such as the distribution of quality of service resources (bandwidth for example).
  • the decision is a reservation decision, for a flow, of a particular class of service.
  • the object of the invention is to promote cooperation between the access networks making it possible to offer a mobility service between the different networks of technologies different from the operator. but also other operators. Indeed, in the context of the deployment of a mobility service between heterogeneous access networks, it is essential that the operator keeps control of the mobility of the terminals. However, it is also important that mobility is best suited to each application of each terminal to ensure a quality service that will be acclaimed by users. Thus, a compromise must be found between an efficient mobility and a limitation of the information exchanged between the different elements of the network managing the mobility (including the terminal). The invention goes in the direction of this compromise since it makes it possible to limit the number of parameters exchanged (in the taking into account locally and being permanently adapted to the applications and the users) while allowing an effective mobility (relevance of the information making it possible to anticipate the mobility).
  • the invention applies in all types of data network and is independent of the access network technology (GPRS ("General Packet Radio Service”, ie “general packet radio service”) , UMTS ("Uni versai Mobile Telecommunication System”, ie “universal mobile telecommunication system”), WLAN ("Wireless Local Area Network”, ie “wireless local area network” "), Ethernet ).
  • GPRS General Packet Radio Service
  • UMTS Uni versai Mobile Telecommunication System
  • WLAN Wireless Local Area Network
  • Ethernet Ethernet
  • Decision graph it represents a set of decision modules and their relationships (for example IPM (IP Multimedia Subsystem) PDP module). Each decision module executes a decision-making algorithm; - "decision tree”: it represents the description of decisions in the form of a tree whose elements are the parameters to be evaluated and the leaves the decisions; “Execution graph”: it represents a set of execution modules involved in the execution of a decision, as well as their relations (for example for Mobile IP, the Home Agent, the Foreign Agent and the terminal). Each execution module participates in the implementation of a decision
  • the radio measurements (received signal power, block error rate %) are distributed dynamically between the attachment points located in the same decision zone. From these measurements, an access point deduces the radio conditions from its neighbors but only for the same technology as it. To get measures relating to other technologies, links between access points are established manually. The handover decision is always made by either the terminal or the current attachment point.
  • GRRM centralize certain GRRM functions, such as load sharing, and to distribute others, such as handover.
  • the mobile terminal can be part of the distribution.
  • a specific node deals with a set of cells of the same technology.
  • a central multi-techno node coordinates several mono-techno nodes that can be of different technologies.
  • HMtP Hierarchical Mobile IP
  • NC-HMIP Network Controlled Hierarchical Mobile IP
  • a handover execution graph is represented by all the entities involved in the execution of the handover. In approaches proposed, this execution is carried out at the IP level by extension of the Mobile IPv ⁇ protocol.
  • the handover execution graph consists of entities such as: mobile terminal, access point, mobility anchor point (MAP) and "home agent" (special node responsible for tracking the position of the mobile terminal when of his movements).
  • MAP mobility anchor point
  • home agent special node responsible for tracking the position of the mobile terminal when of his movements.
  • the constructed graph is common to all applications and terminals under the coverage of the same access router. There is no dialogue between the different entities of the network to build this graph. Either it is the terminal alone that decides the decision graph (HMIPv ⁇ ) or it is a centralized network node (NC -HMIPv ⁇ ). There is also the same disadvantage as for the first and second known techniques. 3. STATEMENT OF THE INVENTION
  • a method for constructing at least one decision graph for managing at least one application flow allocated to a terminal and established between said terminal and a correspondent via the least a communication network comprises a step of dynamically constructing at least one possible decision graph for said at least one application flow assigned to said terminal, itself comprising a step of exchanging at least one configuration message between at least two modules of decision making belonging to a determined set of decision modules.
  • the general principle of the invention therefore consists of a mechanism, which can be iterated several times, according to which a decision module sends a configuration message to another decision module (intermediate) by which it tells it with which other (s) (s) decision modules he may himself exchange information.
  • the configuration message (s) are sent before the stream starts, when the stream starts, or even during the flow duration.
  • the invention allows the dynamic construction of possible decision graphs by configuration messages. As detailed below, once these possible decision graphs have been constructed, it is possible to dynamically construct an active decision graph, by exchange of one or more messages of decision between the decision modules, respecting the configuration created by the configuration messages.
  • the active decision graph is necessarily one of the possible decision graphs.
  • each configuration message comprises the following fields: a field containing an identifier of the source decision module of said configuration message; a field containing an identifier of the decision module receiving said configuration message; a field containing an identifier of at least said terminal, for which said configuration message applies; a field containing at least one distribution structure.
  • each configuration message further comprises a field containing an identifier of said at least one application flow allocated to the terminal.
  • each configuration message is specific to a terminal and an application flow.
  • each distribution structure comprises the following fields: a field containing an identifier of a third decision module, distinct from said recipient decision module; a field containing a role of said third party decision module; a field containing a character of a distribution method to be used between the recipient decision module and said third party decision module; a field containing a character of a decision method to be used by the recipient decision module.
  • each distribution structure further comprises at least one additional field belonging to the group comprising: a field containing a supported granularity; a field containing a distribution method to be used between the recipient decision module and said third party decision module; a field containing at least one parameter defining said distribution method; a field containing a decision method to be used by the recipient decision module; a field containing at least one parameter defining said decision method.
  • each configuration message further comprises an additional field containing at least one trigger structure of a decision method to be used by the recipient decision module.
  • each trigger structure comprises the following fields: a field containing an identifier of a given trigger; a field containing an identifier of the decision module containing the given trigger.
  • each configuration message further comprises an additional field containing at least one decision parameter structure to be used by the recipient decision module, each parameter structure comprising the following fields: a field containing an identifier of a given parameter; a field containing an identifier of the decision module containing the given parameter; a field containing an identifier of the decision module receiving the given parameter; a field containing a sending frequency of the given parameter.
  • said method further comprises a dynamic construction step of a single active decision graph for said at least one application flow allocated to said terminal, itself comprising a step of exchanging at least one decision message. between at least two decision modules, respecting a configuration previously created by the dynamic construction step of at least one possible decision graph, said single active decision graph being the one or one of the possible decision graphs previously constructed for said at least one application flow.
  • a decision module sends a partial or final decision message to another decision module, respecting the configuration created by the configuration messages.
  • each decision message comprises the following fields: a field containing an identifier of the source decision module of said decision message; a field containing an identifier of the decision module that is the recipient of the said decision message; a field containing a type of decision, partial or final; a field containing an identifier of at least said terminal, for which said decision message applies; - a field containing a decision.
  • each decision message further comprises a field containing an identifier of said at least one application flow allocated to the terminal.
  • each decision message is specific to a terminal and an application flow.
  • the solution proposed by the invention consists in dynamically creating an active mobility decision graph for each application of each user. Indeed, with the increasing complexity of network architectures implementing several types of access networks or even several operators, the decision to switch from one access network to another can be optimal only if it is dynamically defined for each application of a user. Indeed, depending on the characteristics of the application, mobility decision power is not necessarily located in the (or) same entities (network or terminal). Similarly, depending on the policies put in place by different operators, the same decision will not be distributed or prioritized in the same way. Finally, the parameters involved in decision-making may also depend on the application, the user and / or the network structure. The proposed solution defines the mechanisms necessary for the dynamic construction of such active decision graphs.
  • said method further comprises a preliminary step of obtaining a general decision graph comprising said determined set of decision modules from which the decision modules exchanging the configuration messages are chosen.
  • said determined set of decision modules belong to a distributed network architecture, since at least two decision modules belong to the same hierarchical level of said architecture, and or hierarchical, because at least two decision modules belong to two hierarchy levels distinct from said architecture.
  • the management of said at least one application flow assigned to said terminal belongs to the group comprising: mobility management; management of quality of service resources.
  • the invention relates to a communication equipment comprising a decision module, said equipment comprising first exchange means, for exchanging at least one configuration message with at least one other decision module belonging to to a determined set of decision modules, so as to participate in the dynamic construction of at least one possible decision graph for the management of at least one application flow allocated to a terminal and established between said terminal and a correspondent via the least a communication network.
  • said communication equipment further comprises second exchange means for exchanging at least one decision message with at least one other decision module belonging to said determined set of decision modules, respecting at least one previously determined possible decision graph, so as to participate in the dynamic construction of a single active decision graph for said at least one application flow assigned to said terminal.
  • said communication equipment belongs to the group comprising: said terminal, said correspondent and entities of said at least one communication network.
  • the communication equipment comprises means for implementing the method of constructing at least one decision graph, as described previously (in any one of its various embodiments).
  • the invention relates to a computer program product downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor, said computer program product comprising instructions program code for executing the steps of the aforementioned method of constructing at least one decision graph for managing at least one application flow allocated to a terminal, when said program is executed on a computer.
  • the invention relates to a signal exchanged between a source decision module and a destination decision module, as part of the dynamic construction of at least one possible decision graph for the management of at least one an application flow assigned to a terminal and established between said terminal and a correspondent via at least one communication network, said signal carrying a configuration message comprising: a field containing an identifier of said source decision module of said configuration message; a field containing an identifier of said decision module to which said configuration message is addressed; a field containing an identifier of at least said terminal, for which said configuration message applies; a field containing at least one distribution structure.
  • each configuration message further comprises a field containing an identifier of said at least one application flow allocated to the terminal.
  • each configuration message is specific to a terminal and an application flow.
  • the invention relates to a signal exchanged between a source decision module and a destination decision module, as part of the dynamic construction of a single active decision graph for the management of at least one an application flow assigned to a terminal and established between said terminal and a party via at least one communication network, said signal carrying a decision message comprising: a field containing an identifier of the source decision module of said decision message; a field containing an identifier of the decision module receiving said decision message; a field containing a type of decision, partial or final; a field containing an identifier of at least said terminal, for which said decision message applies; a field containing a decision.
  • each decision message further comprises a field containing an identifier of said at least one application flow allocated to the terminal.
  • each decision message is specific to a terminal and an application flow. 4. LIST OF FIGURES
  • FIG. 1 shows an example of a general decision graph according to FIG. invention for a single terminal
  • FIG. 2 shows an example of a general decision graph according to the invention, for two terminals
  • FIG. 1 shows an example of a general decision graph according to FIG. invention for a single terminal
  • FIG. 2 shows an example of a general decision graph according to the invention, for two terminals
  • FIG. 1 shows an example of a general decision graph according to FIG. invention for a single terminal
  • FIG. 2 shows an example of a general decision graph according to the invention, for two terminals
  • FIG. 1 shows an example of a general decision graph according to FIG. invention for a single terminal
  • FIG. 2 shows an example of a general decision graph according to the invention, for two terminals
  • FIG. 1 shows an example of a general decision graph according to the
  • FIG. 3 shows an example of possible decision graphs according to the invention, for two flows to a single terminal
  • FIG. 4 shows an example of possible decision graphs according to the invention, for two streams each to a separate terminal
  • FIG. 5 shows an example of active decision graphs according to the invention, for two streams to a single terminal
  • FIG. 6 shows an example of active decision graphs according to the invention, for two streams each to a separate terminal
  • FIG. 7 illustrates an example of a sequence of configuration and decision messages between decision modules, according to the invention
  • FIG. 8 shows an example of initial (possible and active) decision graphs, for two flows to a single terminal, in the case of mobility management of the applications of the user of the terminal, according to the invention
  • FIG. 9 shows an example of decision graphs (possible and active) after moving the terminal (compared to the situation of FIG. 8), for two flows to a single terminal, in the case of mobility management of the applications of the user of the terminal, according to the invention;
  • FIG. 10 illustrates an example of a message sequence of a complete decision-making process corresponding to the case of FIG. 9, in which the configuration and decision messages according to the invention are integrated;
  • FIG. 11 shows the structure of a communication equipment according to a particular embodiment of the invention, integrating a decision module capable of transmitting and / or processing configuration messages and / or decision messages;
  • Figure 12 shows the structure of a configuration message, according to a particular embodiment of the invention;
  • FIG. 13 shows the structure of a decision message, according to one particular embodiment of the invention. 5.
  • Figure 1 shows a decision architecture including six decision modules (sometimes referred to as MDs later) MD1 to MD6.
  • MD6 is located in the user's TM terminal (for Mobile Terminal).
  • a correspondent C may also contain a decision module. It is assumed that the decision modules, the mobile terminal and the correspondent are interconnected by means of communications allowing them to exchange messages. One or more application flows are established between the mobile terminal and the correspondent.
  • the general decision graph is known beforehand.
  • An example of a representation of such a general decision graph is given in FIG. 1, in the case of a single terminal TM.
  • FIG. 2 Another example of representation is given in FIG. 2, in the case of two terminals TM1 and TM2.
  • This general decision graph consists of the set of decision modules and links (represented in dashed lines) that connect them.
  • the configuration messages exchanged between the decision modules make it possible to define the possible decision graphs for each flow or group of flows of a user.
  • FIG. 3 An example of a representation of possible decision graphs is given in FIG. 3, in the case of a TM terminal and two streams.
  • the possible decision graphs for the first stream are represented in simple dashed lines and involve the decision modules referenced MD1, MD2, MD3 and MD4.
  • the possible decision graphs for the second stream are shown in double dashed lines and involve the decision modules referenced MD1, MD4, MD5 and MD6.
  • FIG. 4 Another example of a representation of possible decision graphs is given by FIG. 4, in the case of two terminals TM1 and TM2, and two streams.
  • the graphs of Possible decisions for the first stream to the first terminal TM1 are shown in simple dashed lines and involve the decision modules referenced MD1, MD2, MD3, MD4 and MD6.
  • the possible decision graphs for the second stream to the second terminal TM2 are shown in double dotted lines and involve the decision modules referenced MD1, MD4, MD5 and MD7.
  • an MD decision module accepts a configuration message, it must be part of the possible decision graphs.
  • the methods of distribution and decision indicated in the configuration messages are not necessarily obligatory, it depends on the field "character" conveyed by the messages of configuration.
  • the configuration messages contain at least the following fields: a field 121 containing an address of the source MD of the message (IP address for example); a field 122 containing an address of the MD destination of the message (IP address for example); a field 123 containing an identifier of the user, for which the graphs apply; and optionally a field 123 'containing an identifier of the flow associated with the user and for which the graphs apply. If this last field 123 'is not present, the graphs apply by default to all the flows associated with the user; a field 124 containing one or more distribution structures each containing at least the following fields:
  • IP address ... * the address or identifier of a third-party decision module (IP address ...); * the role of the third party MD; hierarchical or even (of the same level);
  • the user identifier may represent a group of users.
  • Configuration messages can also contain the following optional fields: for each distribution structure:
  • a field containing the parameters defining the decision method (utility function, coefficient of the utility function ...); a field 125 containing one or more trigger structures of the decision method each containing the following fields:
  • the active decision graph is dynamically constructed by exchanging the decision messages ( partial or final) depending on the needs (for example, during congestion of an access network, or following a displacement of the user). Decision modules can be reconfigured at any time.
  • FIG. 5 gives an example of active decision graphs in the case of a TM terminal and two flows.
  • the active decision graph for the first stream is represented in simple dotted lines and involves the decision modules referenced MD1, MD3 and
  • the active decision graph for the second stream is represented in double dotted lines and involves the decision modules referenced MD1, MD5 and MD6.
  • FIG . 6 shows an example of an active decision graph in the case of two terminals TM1 and TM2 and two streams.
  • the active decision graph for the first stream to the first terminal TM1 is shown in simple dotted lines and involves the decision modules referenced MD1, MD3, MD4 and MD6.
  • the active decision graph for the second stream to the second terminal TM2 is shown in double dotted lines and involves the decision modules referenced MD1, MD4, MD5 and MD7.
  • the decision messages contain at least the following fields: a field 131 containing an address of the source MD of the message (IP address for example); a field 132 containing an address of the destination MD of the message (IP address for example); a field 133 containing the type of decision (partial or final decision); a field 134 containing an identifier of the user, for which the decision applies; and optionally a field 134 'containing an identifier of the flow associated with the user and for which the decision applies. If this last field
  • a field 135 containing a decision (e.g. a final handover decision to a particular access point, or a partial handover decision to a particular access network).
  • the user identifier may represent a group of users.
  • the stream identifier may represent a set of streams.
  • the invention allows: the dynamic construction of possible decision graphs by configuration messages (peer decision modules, parameters to be exchanged between the modules, parameters to be evaluated, location of its parameters); dynamic construction of the active decision graphs by exchanging partial decision messages between the decision modules; an active graph is necessarily one of the possible graphs.
  • FIG. 7 shows a possible message exchange between the different decision modules in the case of a TM terminal and two flows already discussed above in relation with FIG. 3 (for the possible decision graphs for each of the flows) and Figure 5 (for the active decision graph for each flow).
  • the two configuration functions 71 and decision 72 are separate but in reality the messages corresponding to each function can be intercalated.
  • the configuration messages for the first stream are referenced 73 to 77 and represented in single lines; they involve the decision modules referenced MD1, MD2, MD3 and MD4. Configuration messages for the second stream are referenced
  • the decision messages for the first stream are referenced 712 to 714 and shown in single lines; they involve the decision modules referenced MD1, MD3, MD4 and MD6.
  • the decision messages for the second stream are referenced 715 and 716 and shown in double lines; they involve the referenced decision modules
  • MD1, MD5 and MD6 are identical to MD1, MD5 and MD6.
  • the invention is applied to manage the mobility of applications of users using mobile terminals.
  • mobility management is considered in the case of two streams assigned to a terminal: the first stream corresponds for example to an Email application, and the second stream to a Video on Demand (VoD) application.
  • the invention makes perfect sense, even if it is not limited to this case, in an architecture implementing several access networks, such as that represented by FIG. 8.
  • ACR Controller Access Router
  • AP Access Point
  • GANC Generic Access Network Controller
  • GGSN GPRS Support Gateway
  • MD Decision Module
  • PDG Packet Data Gateway
  • RAN Radio Access Network
  • RNC Radio Network Controller
  • SGSN GPRS Server Node
  • TM Mobile Terminal
  • VoD Video On Demand
  • WAG WAG
  • the first step is mutual recognition of communication equipment including a decision module that can participate in the decision. It is assumed that this is predefined, i.e. all possible decision modules are known.
  • the second step is to configure the decision modules and to develop the possible and active decision graphs for the applications that are starting up.
  • configuration messages are exchanged between the different entities (GGSN (GPRS Support Gateway) and RNC (Radio Network Controller) in this example) to arrive at the possible decision graphs of FIG. 8.
  • GGSN GPRS Support Gateway
  • RNC Radio Network Controller
  • the two possible and active graphs are merged and they are identical for both applications, they go through the GGSN and the RNC.
  • the active decision graph 82 for the first stream (Email application) is in thick solid line, while the 81 for the second stream (video on demand application) is in solid line end.
  • the GGSN is configured in such a way that it will make a partial decision, for each of the two declared applications, Email and VoD, taking into account parameters such as: the available credit, the right of access, the need for application security, and user preferences in terms of cost.
  • This partial decision will be sent to the RNC by means of a decision message defined by the invention.
  • the RNC is configured in such a way that it will make the final decision, for each of the two declared applications, Email and VoD, taking into account parameters such as: Node B load.
  • the RNC will communicate to the terminal its final decision for both applications by choosing Node B on the network. RAN 1 (still thanks to the decision message defined by the invention).
  • the two applications can be managed in accordance with the decision graphs put in place by the GGSN and the RNC.
  • the decision modules of the entities forming part of the decision graphs for the Email application are represented by black ovals, and the decision modules of the entities forming part of the decision graphs for the application of VoD. are represented by white ovals.
  • the terminal When the terminal moves, it will detect two new access points belonging to two new access networks: RAN2 (managed by the operator of the RAN1) and RAN3 (managed by another operator). The terminal will then inform the GGSN. The GGSN is reconsidering the possibility of creating different decision graphs. Regarding the Email application that requires great security, he decides not to modify the graph. It sends the terminal a final decision message to this effect (104,% 10).
  • the GGSN indicates to the GANC (Generic Access Network Controller), in a configuration message (101, fig.10), the possibility of exchanging information with the ACR (Router). controller access). It also tells him to consider user preferences in terms of cost.
  • the GGSN also indicates to the ACR, in a configuration message (102, fig.10), that it will be able to exchange information with the GANC.
  • the GGSN also sends a configuration message (103, fig.10) to the terminal to indicate that it will have to make a final decision based on a partial decision it has received in advance. All these messages are the configuration messages defined by the invention.
  • the GGSN tells the GANC (RAN 2), in a partial decision message (105, fig.10) to switch the application of VoD to RAN2; it's a partial decision.
  • the GANC takes a partial decision taking into account the following parameters: the user's preferences in terms of cost and the load of his access points. But his access points are too busy, he decides to give a partial decision to the CAB of the RAN3, in a partial decision message (106, fig.10), telling him to put the application of VoD on the RAN 3.
  • the CAB makes a partial decision taking into account the following parameters: the load of its access points.
  • L 1 ACR then sends a partial handover decision of the VoD application to the terminal, in a decision message (107, fig.10).
  • the active decision graph 82 for the first stream (Email application), represented in thick solid line, is unchanged with respect to FIG. 8 and remains merged with the possible decision graph (s) for this first flux. It involves the GGSN and the RNC.
  • the new active decision graph 91 for the second stream (VoD application), represented in solid line is different from the previous one (referenced 81 and shown in dashed lines in FIG. 9). It involves the GGSN, the GANC, the ACR and the TM terminal.
  • FIG. 10 shows how the new messages defined by the invention (represented in double lines) fit into a complete decision-making process (the case of FIG. 9).
  • the configuration messages are referenced 101 to 103, and the decision messages 104 to 107.
  • FIG. 11 shows the simplified structure of a communication equipment 110 according to one particular embodiment of the invention, integrating a module of decision capable of transmitting and / or processing configuration messages and / or decision messages according to at least one embodiment (for example that presented above in relation to FIGS. 8 and 9) of the method according to the invention constructing at least one decision graph for managing at least one application flow assigned to a terminal.
  • This equipment is for example the GGSN, the RNC, the GANC, the ACR or the TM terminal of FIGS. 8 and 9.
  • the code instructions of the computer program 112 are for example loaded into a RAM before being executed by the processor of the processing unit 11 to: generate a configuration message 115 and transmit it other equipment including a decision module; and / or - processing a configuration message 114 coming from another equipment comprising a decision module (and possibly generating another configuration message 115 and transmitting it to another equipment including a decision module); and / or generating a decision message 117 and transmitting it to another equipment including a decision module; and / or processing a decision message 116 from another piece of equipment including a decision module (and possibly generating another decision message
  • the corresponding instruction sequence can be stored in a removable storage means (such as for example a floppy disk, a CD-ROM or a DVD-ROM) or not, this storage means being readable partially or totally by a computer or a microprocessor .
  • Source MD address (decision module): GGSN IP address Destination MD address: GANC IP address Torque identification: (MAC ID, Stream ID) Two distribution structures in this case: Third party MD address: GGSN IP address
  • Role of the MD Hierarchical Character of the distribution method: by default Character of the decision method: suggested Decision method: utility function Supported granularity: by flow
  • Source MD address IP address Destination MD address: ACR IP address Torque ID: (MAC ID, all streams)
  • Flow type adaptive or not
  • Stream class conversational, interactive, (7)
  • Minimum quality of service bandwidth, delay, jitter, error rate,.

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 concerne notamment un procédé de construction d'au moins un graphe de décision pour la gestion d'au moins un flux applicatif affecté à un terminal mobile (TM) et établi entre ledit terminal mobile et un correspondant via au moins un réseau de communication. Ledit procédé comprend une étape (71) de construction dynamique d'au moins un graphe de décision possible pour ledit au moins un flux applicatif affecté audit terminal mobile, comprenant elle-même une étape d'échange d'au moins un message de configuration (73 à 711) entre au moins deux modules de décision appartenant à un ensemble déterminé de modules de décision (MDl à MD6).

Description

GESTION DE FLUX APPLICATIFS DANS DES RESEAUX MOBILES
1. DOMAINE DE L'INVENTION
Le domaine de l'invention est celui des graphes de décision. Plus précisément, l'invention concerne une technique de construction de graphes de décision pour la gestion de flux applicatifs affectés à des terminaux, chaque flux applicatif étant établi entre un terminal et un correspondant (c'est-à-dire un équipement avec lequel communique le terminal), via au moins un réseau de communication.
Dans la suite de la description, on suppose qu'un utilisateur utilise une ou plusieurs applications (par exemple une application « Email » et une application « Vidéo à la demande ») grâce à un terminal dont il dispose, et qu'un flux applicatif distinct est établi avec le terminal de l'utilisateur pour chacune de ces applications. En d'autres termes, on confond volontairement les notions de terminal et d'utilisateur de ce terminal.
L'invention s'applique notamment, mais non exclusivement, à la mise en œuvre d'un service de mobilité de terminaux entre réseaux d'accès (gestion des transferts intercellulaires (handovers)).
Elle peut aussi s'appliquer à d'autres types de décision, comme par exemple la répartition des ressources de qualité de service (bande passante par exemple). Dans ce dernier cas, la décision est une décision de réservation, pour un flux, d'une classe de service particulière.
Dans le cas particulier d'un service de mobilité, l'objet de l'invention est de favoriser la coopération entre les réseaux d'accès permettant l'offre d'un service de mobilité entre les différents réseaux de technologies différentes de l'opérateur mais également d'autres opérateurs. En effet, dans le cadre du déploiement d'un service de mobilité entre réseaux d'accès hétérogènes, il est primordial que l'opérateur garde le contrôle de la mobilité des terminaux. Or, il est aussi important que la mobilité soit la mieux adaptée à chaque application de chaque terminal pour assurer un service de qualité qui sera plébiscité par les utilisateurs. Ainsi, un compromis doit être trouvé entre une mobilité efficace et une limitation des informations échangées entre les différents éléments du réseau gérant la mobilité (terminal y compris). L'invention va dans le sens de ce compromis puisqu'elle permet de limiter le nombre de paramètres échangés (en les prenant en compte localement et en étant en permanence adapté aux applications et aux utilisateurs) tout en permettant une mobilité efficace (pertinence des informations permettant d'anticiper la mobilité).
L'invention s'applique dans tous types de réseau de données et est indépendante de la technologie des réseaux d'accès (GPRS (« General Packet Radio Service », c'est-à- dire « service général de radiocommunication par paquets »), UMTS (« Uni versai Mobile Télécommunication System », c'est-à-dire « système universel de télécommunication avec les mobiles »), WLAN (« Wireless Local Area Network », c'est-à-dire « réseau local sans fil »), Ethernet...). Dans la présente description, on utilise les définitions classiques suivantes :
« graphe de décision » : il représente un ensemble de modules de décision et leurs relations (par exemple module PDP (Policy Décision Point) de l'ÏMS (IP Multimedia Subsystem)). Chaque module de décision exécute un algorithme de prise de décision ; - « arbre de décision » : il représente la description de décisions sous forme d'un arbre dont les éléments sont les paramètres à évaluer et les feuilles les décisions ; « graphe d'exécution » : il représente un ensemble de modules d'exécution prenant part à l'exécution d'une décision, ainsi que leurs relations (par exemple pour Mobile IP, le Home Agent, le Foreign Agent et le terminal). Chaque module d'exécution participe à la mise en oeuvre d'une décision
.2. ART ANTÉRIEUR
On présente maintenant brièvement quelques techniques de l'art antérieur, avec leurs inconvénients respectifs.
2-1) Handover vertical utilisant une approche distribuée Une première technique connue est décrite dans le document suivant : Tobias
Hosfeld et al., "Supporting Vertical Handover by Using a Pastry Peer-to-Peer Overlay Network", Université de Wurtzburg - Rapport Technique n° 367, septembre 2005.
Dans cette approche, les mesures radio (puissance du signal reçu, taux d'erreur blocs...) sont distribués dynamiquement entre les points d'attachement situés dans une même zone de décision. A partir de ces mesures, un point d'accès déduit les conditions radio de ses voisins mais uniquement pour la même technologie que lui. Pour obtenir des mesures relatives aux autres technologies, des liens entre les points d'accès sont établis manuellement. La décision de handover est toujours prise soit par le terminal soit par le point d'attachement courant.
Dans cette solution, il n'y a pas de graphe de décision dynamique, seuls certains paramètres de décision sont distribués dynamiquement. Ceci ne permet donc pas d'adapter la décision aux applications et aux terminaux. 2-2) Gestion des ressources radio multi-accès (GRRM)
Une deuxième technique connue est décrite dans le document suivant : P. Magnussen, J. Lundsjo, J. Sachs and P. Wallentin, "Radio Resource Management Distribution in a Beyond 3G Multi-Radio Access Architecture", IEEE GLOBECOM'04.
Dans cette approche, on propose de centraliser certaines fonctions de GRRM, comme le partage de charge, et d'en distribuer d'autres, comme le handover. Le terminal mobile pouvant faire partie de la distribution. Dans les deux cas, un nœud spécifique s'occupe d'un ensemble de cellules d'une même technologie. Ainsi, dans l'approche centralisée, un nœud central multi-techno coordonne plusieurs nœuds mono-technos qui peuvent être de différentes technologies.
Dans cette solution, une sorte de graphe de décision est construit mais celui-ci est identique pour toutes les applications et tous les terminaux sous la coordination d'un nœud de gestion voisin. On retrouve le même problème que pour la première technique connue.
2-3) HMtP (Hierarchical Mobile IP) et NC-HMIP (Network Controlled Hierarchical Mobile IP)
Une troisième technique connue est décrite dans les documents suivants :
H. Soliman et al, "Hierarchical Mobile IPvό Mobility Management (HMIPvό)", IETF RFC 4140; et
K. Guillouard et al., "Network-controîîed Mobility within Radio Access
Networks Based on WLAN Technologies", Annales des Télécommunications, 3,
58, Mars 2003.
Ces deux approches permettent la construction dynamique d'un graphe d'exécution de handover. Un graphe d'exécution de handover est représenté par l'ensemble des entités prenant part à l'exécution du handover. Dans les approches proposée, cette exécution est réalisée au niveau IP par extension du protocole Mobile IPvό. Le graphe d'exécution du handover est constitué d'entités telles que : terminal mobile, point d'accès, point d'ancrage de la mobilité (MAP) et « home agent » (nœud spécial chargé de suivre la position du terminal mobile lors de ses déplacements). Dans cette troisième technique connue, il n'y a pas de graphe de décision mais un graphe d'exécution de handover (voir ci-dessus les définitions de ces deux types de graphe). De plus, le graphe construit est commun à toutes les applications et à tous les terminaux sous la couverture d'un même routeur d'accès. Il n'y a pas non plus de dialogue entre les différentes entités du réseau pour construire ce graphe. Soit c'est le terminal seul qui décide du graphe de décision (HMIPvό) soit c'est un nœud centralisé du réseau (NC -HMIPvό). On retrouve aussi le même inconvénient que pour les première et deuxième techniques connues. 3. EXPOSÉ DE L'INVENTION
Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de construction d'au moins un graphe de décision pour la gestion d'au moins un flux applicatif affecté à un terminal et établi entre ledit terminal et un correspondant via au moins un réseau de communication. Ledit procédé comprend une étape de construction dynamique d'au moins un graphe de décision possible pour ledit au moins un flux applicatif affecté audit terminal, comprenant elle-même une étape d'échange d'au moins un message de configuration entre au moins deux modules de décision appartenant à un ensemble déterminé de modules de décision.
Le principe général de l'invention consiste donc en un mécanisme, pouvant être itéré plusieurs fois, selon lequel un module de décision envoie un message de configuration à un autre module de décision (intermédiaire) par lequel il lui indique avec quel(s) autre(s) modules de décision il pourra lui-même échanger des informations. Le ou les messages de configuration sont envoyés avant le démarrage du flux, au démarrage du flux ou même pendant la durée du flux.
Ainsi, l'invention permet la construction dynamique de graphes de décision possibles par des messages de configuration. Comme détaillé par la suite, une fois ces graphes de décision possibles construits, il est possible de construire de façon dynamique un graphe de décision actif, par échange d'un ou plusieurs messages de décision entre les modules de décision, en respectant la configuration créée par les messages de configuration. Le graphe de décision actif est forcément l'un des graphes de décision possibles.
De façon avantageuse, chaque message de configuration comprend les champs suivants : un champ contenant un identifiant du module de décision source dudit message de configuration ; un champ contenant un identifiant du module de décision destinataire dudit message de configuration ; - un champ contenant un identifiant d'au moins ledit terminal, pour lequel ledit message de configuration s'applique ; un champ contenant au moins une structure de distribution. Avantageusement, chaque message de configuration comprend en outre un champ contenant un identifiant dudit au moins un flux applicatif affecté au terminal. Dans un mode de réalisation particulier de l'invention, chaque message de configuration est spécifique à un terminal et à un flux applicatif.
Avantageusement, chaque structure de distribution comprend les champs suivants : un champ contenant un identifiant d'un module de décision tiers, distinct dudit module de décision destinataire ; un champ contenant un rôle dudit module de décision tiers ; un champ contenant un caractère d'une méthode de distribution à utiliser entre le module de décision destinataire et ledit module de décision tiers ; un champ contenant un caractère d'une méthode de décision à utiliser par le module de décision destinataire.
Il est à noter que le module de décision tiers peut être confondu avec le module de décision source.
Selon une caractéristique avantageuse, chaque structure de distribution comprend en outre au moins un champ supplémentaire appartenant au groupe comprenant : un champ contenant une granularité supportée ; un champ contenant une méthode de distribution à utiliser entre le module de décision destinataire et ledit module de décision tiers ; un champ contenant au moins un paramètre définissant ladite méthode de distribution ; un champ contenant une méthode de décision à utiliser par le module de décision destinataire ; un champ contenant au moins un paramètre définissant ladite méthode de décision.
Avantageusement, chaque message de configuration comprend en outre un champ supplémentaire contenant au moins une structure de déclencheur d'une méthode de décision à utiliser par le module de décision destinataire.
Selon une caractéristique avantageuse, chaque structure de déclencheur comprend les champs suivants : un champ contenant un identifiant d'un déclencheur donné ; - un champ contenant un identifiant du module de décision contenant le déclencheur donné.
Dans un mode de réalisation avantageux de l'invention, chaque message de configuration comprend en outre un champ supplémentaire contenant au moins une structure de paramètres de décision à utiliser par le module de décision destinataire, chaque structure de paramètres comprenant les champs suivants : un champ contenant un identifiant d'un paramètre donné ; un champ contenant un identifiant du module de décision contenant le paramètre donné ; un champ contenant un identifiant du module de décision destinataire du paramètre donné ; un champ contenant une fréquence d'envoi du paramètre donné.
De façon avantageuse, ledit procédé comprend en outre une étape de construction dynamique d'un unique graphe de décision actif pour ledit au moins un flux applicatif affecté audit terminal, comprenant elle-même une étape d'échange d'au moins un message de décision entre au moins deux modules de décision, en respectant une configuration préalablement créée par l'étape de construction dynamique d'au moins un graphe de décision possible, ledit unique graphe de décision actif étant le ou l'un des graphes de décision possibles préalablement construits pour ledit au moins un flux applicatif.
Ainsi, en fonction des paramètres dont il dispose, un module de décision envoie un message de décision partielle ou finale à un autre module de décision, en respectant la configuration créée par les messages de configuration.
Avantageusement, chaque message de décision comprend les champs suivants : un champ contenant un identifiant du module de décision source dudit message de décision ; - un champ contenant un identifiant du module de décision destinataire dudit message de décision ; un champ contenant un type de décision, partielle ou finale ; un champ contenant un identifiant d'au moins ledit terminal, pour lequel ledit message de décision s'applique ; - un champ contenant une décision.
Avantageusement, chaque message de décision comprend en outre un champ contenant un identifiant dudit au moins un flux applicatif affecté au terminal.
Dans un mode de réalisation particulier de l'invention, chaque message de décision est spécifique à un terminal et à un flux applicatif. Ainsi, dans ce mode de réalisation particulier, la solution proposée par l'invention consiste à créer dynamiquement un graphe de décision actif de mobilité pour chaque application de chaque utilisateur. En effet, avec la complexité croissante des architectures de réseaux mettant en œuvre plusieurs types de réseaux d'accès voire même plusieurs opérateurs, la prise de décision de passage d'un réseau d'accès à un autre ne peut être optimale que si elle est définie dynamiquement pour chaque application d'un utilisateur. En effet, en fonction des caractéristiques de l'application, le pouvoir de décision de mobilité n'est pas forcément situé dans le (ou les) mêmes entités (réseau ou terminal). De même, en fonction des politiques mises en place par différents opérateurs, cette même décision ne sera pas distribuée ou hiérarchisée de la même façon. Enfin, les paramètres entrant dans la prise de décision peuvent aussi dépendre de l'application, de l'utilisateur et/ou de la structure du réseau. La solution proposée définit les mécanismes nécessaires à la construction dynamique de tels graphes de décision actifs.
Selon une caractéristique avantageuse, ledit procédé comprend en outre une étape préalable d'obtention d'un graphe de décision général comprenant ledit ensemble déterminé de modules de décision parmi lesquels sont choisis les modules de décision s'échangeant les messages de configuration.
Dans un mode de réalisation particulier de l'invention, ledit ensemble déterminé de modules de décision appartiennent à une architecture de réseaux : distribuée, du fait qu'au moins deux modules de décision appartiennent à un même niveau de hiérarchie de ladite architecture, et/ou hiérarchisée, du fait qu'au moins deux modules de décision appartiennent à deux niveaux de hiérarchie distincts de ladite architecture.
De façon avantageuse, la gestion dudit au moins un flux applicatif affecté audit terminal appartient au groupe comprenant : - des gestions de mobilité ; des gestions de répartition de ressources de qualité de service. Dans un autre mode de réalisation, l'invention concerne un équipement de communication comprenant un module de décision, ledit équipement comprenant des premiers moyens d'échange, permettant d'échanger au moins un message de configuration avec au moins un autre module de décision appartenant à un ensemble déterminé de modules de décision, de façon à participer à la construction dynamique d'au moins un graphe de décision possible pour la gestion d'au moins un flux applicatif affecté à un terminal et établi entre ledit terminal et un correspondant via au moins un réseau de communication. De façon avantageuse, ledit équipement de communication comprend en outre des seconds moyens d'échange, permettant d'échanger au moins un message de décision avec au moins un autre module de décision appartenant audit ensemble déterminé de modules de décision, en respectant au moins un graphe de décision possible préalablement déterminé, de façon à participer à la construction dynamique d'un unique graphe de décision actif pour ledit au moins un flux applicatif affecté audit terminal. Avantageusement, ledit équipement de communication appartient au groupe comprenant : ledit terminal, ledit correspondant et des entités dudit au moins un réseau de communication.
Plus généralement, l'équipement de communication selon l'invention comprend des moyens de mise en œuvre du procédé de construction d'au moins un graphe de décision, tel que décrit précédemment (dans l'un quelconque de ses différents modes de réalisation).
Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, ledit produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé précité de construction d'au moins un graphe de décision pour la gestion d'au moins un flux applicatif affecté à un terminal, lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation, l'invention concerne un signal échangé entre un module de décision source et un module de décision destinataire, dans le cadre de la construction dynamique d'au moins un graphe de décision possible pour la gestion d'au moins un flux applicatif affecté à un terminal et établi entre ledit terminal et un correspondant via au moins un réseau de communication, ledit signal portant un message de configuration comprenant : un champ contenant un identifiant dudit module de décision source dudit message de configuration ; un champ contenant un identifiant dudit module de décision destinataire dudit message de configuration ; - un champ contenant un identifiant d'au moins ledit terminal, pour lequel ledit message de configuration s'applique ; un champ contenant au moins une structure de distribution. Avantageusement, chaque message de configuration comprend en outre un champ contenant un identifiant dudit au moins un flux applicatif affecté au terminal. Dans un mode de réalisation particulier de l'invention, chaque message de configuration est spécifique à un terminal et à un flux applicatif. Dans un autre mode de réalisation, l'invention concerne un signal échangé entre un module de décision source et un module de décision destinataire, dans le cadre de la construction dynamique d'un unique graphe de décision actif pour la gestion d'au moins un flux applicatif affecté à un terminal et établi entre ledit terminal et un correspondant via au moins un réseau de communication, ledit signal portant un message de décision comprenant : un champ contenant un identifiant du module de décision source dudït message de décision ; un champ contenant un identifiant du module de décision destinataire dudit message de décision ; un champ contenant un type de décision, partielle ou finale ; un champ contenant un identifiant d'au moins ledit terminal, pour lequel ledit message de décision s'applique ; un champ contenant une décision. Avantageusement, chaque message de décision comprend en outre un champ contenant un identifiant dudit au moins un flux applicatif affecté au terminal. Dans un mode de réalisation particulier de l'invention, chaque message de décision est spécifique à un terminal et à un flux applicatif. 4. LISTE DES FIGURES D'autres caractéristiques et avantages de modes de réalisation de l'invention apparaîtront à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donné à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention ne sont pas limités aux caractéristiques et avantages de ce mode de réalisation préférentiel), et des dessins annexés, dans lesquels : - la figure 1 présente un exemple d'un graphe de décision général selon l'invention, pour un seul terminal ; la figure 2 présente un exemple d'un graphe de décision général selon l'invention, pour deux terminaux ; la figure 3 présente un exemple de graphes de décision possibles selon l'invention, pour deux flux vers un seul terminal ; la figure 4 présente un exemple de graphes de décision possibles selon l'invention, pour deux flux chacun vers un terminal distinct ; la figure 5 présente un exemple de graphes de décision actifs selon l'invention, pour deux flux vers un seul terminal ; - la figure 6 présente un exemple de graphes de décision actifs selon l'invention, pour deux flux chacun vers un terminal distinct ; la figure 7 illustre un exemple de séquence de messages de configuration et de décision entre des modules de décision, selon l'invention ; la figure 8 présente un exemple de graphes de décision (possibles et actifs) initiaux, pour deux flux vers un seul terminal, dans le cas d'une gestion de mobilité des applications de l'utilisateur du terminal, selon l'invention ; la figure 9 présente un exemple de graphes de décision (possibles et actifs) après déplacement du terminal (par rapport à la situation de la figure 8), pour deux flux vers un seul terminal, dans le cas d'une gestion de mobilité des applications de l'utilisateur du terminal, selon l'invention ; la figure 10 illustre un exemple de séquence de messages d'un processus complet de prise de décision correspondant au cas de la figure 9, dans lequel s'intègrent les messages de configuration et de décision selon l'invention ; la figure 11 présente la structure d'un équipement de communication selon un mode de réalisation particulier de l'invention, intégrant un module de décision capable d'émettre et/ou traiter des messages de configuration et/ou des messages de décision ; la figure 12 présente la structure d'un message de configuration, selon un mode de réalisation particulier de l'invention ; et - la figure 13 présente la structure d'un message de décision, selon un mode de réalisation particulier de l'invention. 5. DESCRIPTION DÉTAILLÉE
Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. 5-1) Identifications des éléments techniques essentiels d'un mode de réalisation particulier de T invention On suppose au préalable que les différents modules de décision se connaissent et sont capables d'échanger des messages entre eux par des moyens de communications connus.
Une application possible décrite dans la suite est la prise de décision de mobilité des flux d'un utilisateur.
Les éléments essentiels caractérisant un mode de réalisation particulier de l'invention par rapport à l'art antérieur sont décrits ci-après.
La figure 1 représente une architecture de décision comprenant six modules de décision (parfois appelés MD par la suite) MDl à MD6. MD6 est situé dans le terminal TM (pour Terminal Mobile) de l'utilisateur. Un correspondant C peut aussi contenir un module de décision. On suppose que les modules de décision, le terminal mobile et le correspondant sont reliés entre eux par des moyens de communications leur permettant d'échanger des messages. Un ou plusieurs flux applicatifs sont établis entre le terminal mobile et le correspondant. On suppose que le graphe de décision général est connu au préalable. Un exemple de représentation d'un tel graphe de décision général est donné par la figure 1, dans le cas d'un seul terminal TM. Un autre exemple de représentation est donné par figure 2, dans le cas de deux terminaux TMl et TM2. Ce graphe de décision général est constitué de l'ensemble des modules de décision et de liens (représentés en pointillés) qui les relient.
Les messages de configuration échangés entre les modules de décision permettent de définir les graphes de décision possibles pour chaque flux ou groupe de flux d'un utilisateur.
Un exemple de représentation de graphes de décision possibles est donné par la figure 3, dans le cas d'un terminal TM et deux flux. Les graphes de décision possibles pour le premier flux sont représentés en pointillés simples et impliquent les modules de décision référencés MDl, MD2, MD3 et MD4. Les graphes de décision possibles pour le second flux sont représentés en pointillés doubles et impliquent les modules de décision référencés MDl, MD4, MD5 et MD6. Un autre exemple de représentation de graphes de décision possibles est donné par la figare 4, dans le cas de deux terminaux TMl et TM2, et deux flux. Les graphes de décision possibles pour le premier flux vers le premier terminal TMl sont représentés en pointillés simples et impliquent les modules de décision référencés MDl, MD2, MD3, MD4 et MD6. Les graphes de décision possibles pour le second flux vers le second terminal TM2 sont représentés en pointillés doubles et impliquent les modules de décision référencés MDl, MD4, MD5 et MD7.
Il est à noter que lorsqu'un module de décision MD accepte un message de configuration, il fait obligatoirement partie des graphes de décision possibles. Par contre les méthodes de distribution et de décision indiquées dans les messages de configuration ne sont pas forcément obligatoires, cela dépend du champ "caractère" véhiculé par les messages de configuration.
Comme illustré sur la figure 12, dans un mode de réalisation particulier de l'invention, les messages de configuration contiennent au moins les champs suivants : un champ 121 contenant une adresse du MD source du message (adresse IP par exemple) ; - un champ 122 contenant une adresse du MD destination du message (adresse IP par exemple) ; un champ 123 contenant un identifiant de l'utilisateur, pour lequel les graphes s'appliquent ; et optionnellement un champ 123' contenant un identifiant du flux associé à l'utilisateur et pour lequel les graphes s'appliquent. Si ce dernier champ 123' n'est pas présent, les graphes s'appliquent par défaut à l'ensemble des flux associés à l'utilisateur ; un champ 124 contenant une ou plusieurs structures de distribution contenant chacune au moins les champs suivants :
* l'adresse ou l'identifiant d'un module de décision tiers (adresse IP ...) ; * le rôle du MD tiers; hiérarchique ou pair (de même niveau) ;
* le caractère de la méthode de distribution : obligatoire, suggérée ou "par défaut" ;
* le caractère de la méthode de décision : obligatoire, suggérée ou "par défaut". II est à noter que l'identifiant utilisateur peut représenter un groupe d'utilisateurs.
De même l'identifiant de flux peut représenter un ensemble de flux et même un terminal. Les messages de configuration peuvent aussi contenir les champs optionnels suivants : pour chaque structure de distribution :
* un champ contenant la granularité supportée (par flux, par application, par utilisateur...) ;
* un champ contenant la méthode de distribution à utiliser entre le MD destination et le MD tiers ("conflict free" (sans conflit), "Enforced team"
* un champ contenant les paramètres définissant la méthode de distribution (poids des objectifs par exemple) ;
* un champ contenant la méthode de décision à utiliser par le MD destination (logique floue, fonction d'utilité...) ;
* un champ contenant les paramètres définissant la méthode de décision (fonction d'utilité, coefficient de la fonction d'utilité...) ; - un champ 125 contenant une ou plusieurs structures de déclencheurs de la méthode de décision contenant chacune les champs suivants :
* un champ contenant le nom du déclencheur (cf. annexe 2) ;
* un champ contenant l'adresse du module contenant ce déclencheur ; un champ 126 contenant une ou plusieurs structures de paramètres de décision, contenant chacune les champs suivants :
* un champ contenant le nom du paramètre (cf. annexe 2) ;
* un champ contenant l'adresse du module contenant ce paramètre ;
* un champ contenant l'adresse du module destinataire du paramètre ;
* un champ contenant une fréquence d'envoi du paramètre. Une fois la configuration des modules de décision effectuée, c'est-à-dire après que tous les graphes de décision possibles sont établis pour un flux et un utilisateur donné, le graphe de décision actif est construit dynamiquement par échange des messages de décision (partielle ou finale) en fonction des besoins (par exemple, lors d'une congestion d'un réseau d'accès, ou suite à un déplacement de l'utilisateur). Les modules de décision peuvent être reconfigurés à tout moment. La figure 5 donne un exemple de graphes de décision actifs dans le cas d'un terminal TM et deux flux. Le graphe de décision actif pour le premier flux est représenté en pointillés simples et implique les modules de décision référencés MDl , MD3 et
MD4. Le graphe de décision actif pour le second flux est représenté en pointillés doubles et implique les modules de décision référencés MDl , MD5 et MD6,
La figureιm6 donne un exemple de graphe de décision actif dans le cas de deux terminaux TMl et TM2 et deux flux. Le graphe de décision actif pour le premier flux vers le premier terminal TMl est représenté en pointillés simples et implique les modules de décision référencés MDl, MD3, MD4 et MD6. Le graphe de décision actif pour le second flux vers le second terminal TM2 est représenté en pointillés doubles et implique les modules de décision référencés MDl, MD4, MD5 et MD7.
Comme illustré sur la figure 13, dans un mode de réalisation particulier de l'invention, les messages de décision contiennent au moins les champs suivants : un champ 131 contenant une adresse du MD source du message (adresse IP par exemple) ; un champ 132 contenant une adresse du MD destination du message (adresse IP par exemple) ; un champ 133 contenant le type de la décision (décision partielle ou finale) ; un champ 134 contenant un identifiant de l'utilisateur, pour lequel la décision s'applique ; et optionnellement un champ 134' contenant un identifiant du flux associé à l'utilisateur et pour lequel la décision s'applique. Si ce dernier champ
134' n'est pas présent, la décision s'applique par défaut à l'ensemble des flux associés à l'utilisateur ; un champ 135 contenant une décision (par exemple une décision finale de handover vers un point d'accès particulier, ou une décision partielle de handover vers un réseau d'accès particulier).
Il est à noter que l'identifiant utilisateur peut représenter un groupe d'utilisateurs. De même l'identifiant de flux peut représenter un ensemble de flux.
En résumé, l'invention permet : la construction dynamique de graphes de décision possibles par des messages de configuration (modules de décision pairs, paramètres à échanger entre les modules, paramètres à évaluer, localisation de ses paramètres) ; la construction dynamique des graphes de décision actifs par échange de messages de décision partielle entre les modules de décision; un graphe actif est forcément l'un des graphes possibles.
La figure 7 montre un échange possible de messages entre les différents modules de décision dans le cas d'un terminal TM et deux flux déjà discuté ci-dessus en relation avec la figure 3 (pour les graphes de décision possibles pour chacun des flux) et la figure 5 (pour le graphe de décision actif pour chacun des flux). Pour plus de clarté, sur la figure 7, les deux fonctions configuration 71 et décision 72 sont séparées mais en réalité les messages correspondant à chaque fonction peuvent s'intercaler.
Les messages de configuration pour le premier flux sont référencés 73 à 77 et représentés en traits simples ; ils impliquent les modules de décision référencés MDl , MD2, MD3 et MD4. Les messages de configuration pour le second flux sont référencés
78 à 711 et représentés en traits doubles ; ils impliquent les modules de décision référencés MDl, MD4, MD5 et MD6.
Les messages de décision pour le premier flux sont référencés 712 à 714 et représentés en traits simples ; ils impliquent les modules de décision référencés MDl, MD3, MD4 et MD6. Les messages de décision pour le second flux sont référencés 715 et 716 et représentés en traits doubles ; ils impliquent les modules de décision référencés
MDl, MD5 et MD6.
5-2) Description détaillée d'un mode particulier de réalisation dans le cas de la gestion de mobilité Dans l'exemple présenté ci-après en relation avec les figures 8 et 9, l'invention est appliquée pour gérer la mobilité des applications d'utilisateurs utilisant des terminaux mobiles. On considère à titre d'exemple la gestion de la mobilité dans le cas de deux flux affectés à un terminal : le premier flux correspond par exemple à une application Email, et le second flux à une application Vidéo à la demande (VoD). L'invention prend tout son sens, même si elle n'est pas limitée à ce cas, dans une architecture mettant en œuvre plusieurs réseaux d'accès, comme celle représentée par la figure 8.
Sur les figures 8 et 9, quand un graphe de décision possible et un graphe de décision actif sont confondus pour un flux donné, seul le graphe de décision actif apparaît.
Par ailleurs, sur les figures 8 et 9 et dans la suite de la description, on utilise les sigles suivants : ACR (Routeur d'accès contrôleur ), AP (Point d'accès), GANC (Contrôleur de réseau d'accès générique), GGSN (Passerelle de support GPRS), MD (Module de décision), PDG (Passerelle de données paquets), RAN (Réseau d'accès radio), RNC (Contrôleur de réseau radio), SGSN (Noeud serveur GPRS), TM (Terminal mobile), VoD (Vidéo à la demande) et WAG (Passerelle WLAN).
La première étape consiste à la reconnaissance mutuelle des équipements de communication comprenant un module de décision pouvant prendre part à la décision. On suppose que ceci est prédéfini, c'est-à-dire que tous les modules de décision possibles sont connus.
La deuxième étape consiste à configurer les modules de décision et à élaborer les graphes de décision possibles et actifs pour les applications qui démarrent.
Grâce à l'invention, des messages de configuration sont échangés entre les différentes entités (GGSN (Passerelle de support GPRS) et RNC (Contrôleur de réseau radio) dans cet exemple) pour aboutir aux graphes de décision possibles de la figure 8.
Dans cet exemple, les deux graphes possibles et actifs sont confondus et ils sont identiques pour les deux applications, ils passent par le GGSN et le RNC. Le graphe de décision actif 82 pour le premier flux (application Email) est en trait plein épais, tandis que celui 81 pour le second flux (application Vidéo à la demande) est en trait plein fin.
Suite à cette deuxième étape, le GGSN est configuré de telle sorte qu'il prendra une décision partielle, pour chacune des deux applications déclarées, Email et VoD, en tenant compte de paramètres tels que : le crédit disponible, le droit d'accès, le besoin de sécurité des applications, et les préférences de l'utilisateur en terme de coût. Cette décision partielle sera envoyée au RNC grâce à un message de décision défini par l'invention. De la même façon, le RNC est configuré de telle sorte qu'il prendra la décision finale, pour chacune des deux applications déclarées, Email et VoD, en tenant compte de paramètres tels que : la charge des Noeuds B. Le RNC communiquera au terminal sa décision finale pour les deux applications en choisissant le Nœud B sur le réseau RAN î (toujours grâce au message de décision défini par l'invention). Ainsi, les deux applications pourront être gérées en accord avec les graphes de décision mis en place par le GGSN et le RNC.
Sur les figures 8 et 9, les modules de décision des entités faisant partie des graphes de décision pour l'application Email sont représentés par des ovales noirs, et les modules de décision des entités faisant partie des graphes de décision pour l'application de VoD sont représentés par des ovales blancs.
Lorsque le terminal va se déplacer, il va détecter deux nouveaux points d'accès appartenant à deux nouveaux réseaux d'accès : RAN2 (géré par l'opérateur du RANl) et RAN3 (géré par un autre opérateur). Le terminal va alors en informer le GGSN. Le GGSN reconsidère la possibilité de créer des graphes de décision différents. Concernant l'application Email qui demande une grande sécurité, il décide de ne pas modifier le graphe. Il envoie au terminal un message de décision finale en ce sens (104, % 10).
Pour l'application de VoD, le GGSN indique au GANC (Contrôleur de réseau d'accès générique), dans un message de configuration (101, fig.10), la possibilité d'échanger des informations avec l'ACR (Routeur d'accès contrôleur). Il lui indique aussi de tenir compte des préférences utilisateur en terme de coût. Le GGSN indique aussi à l'ACR, dans un message de configuration (102, fig.10), qu'il pourra échanger des informations avec le GANC. Le GGSN envoie également un message de configuration (103, fig.10) au terminal pour lui indiquer qu'il devra prendre une décision finale à partir d'une décision partielle qu'il aura reçue au préalable. Tous ces messages sont les messages de configuration définis par l'invention.
Le GGSN indique au GANC (RAN 2), dans un message de décision partielle (105, fig.10) de basculer l'application de VoD sur le RAN2 ; c'est une décision partielle. Le GANC prend une décision partielle en tenant compte des paramètres suivants : les préférences de l'utilisateur en terme de coût et la charge de ses points d'accès. Or ses points d'accès sont trop chargés, il décide de donner une décision partielle à l'ACR du RAN3, dans un message de décision partielle (106, fig.10), lui indiquant de faire passer l'application de VoD sur le RAN 3.
L'ACR prend une décision partielle en tenant compte des paramètres suivants : la charge de ses points d'accès. L1ACR envoie alors une décision partielle de handover de l'application VoD au terminal, dans un message de décision (107, fig.10).
C'est le terminal qui prendra la décision finale en tenant compte des paramètres suivant : la qualité du signal radio sur les APs du RAN3. Le terminal exécutera alors le handover vers le RAN3, pour l'application VoD.
Les nouveaux graphes de décision (possibles et actifs) sont représentés sur la figure 9.
Le graphe de décision actif 82 pour le premier flux (application Email), représenté en trait plein épais, est inchangé par rapport à la figure 8 et reste confondu avec le(s) graphe(s) de décision possible(s) pour ce premier flux. Il implique le GGSN et le RNC. Le nouveau graphe de décision actif 91 pour le second flux (application VoD), représenté en trait plein fin est différent du précédent (référencé 81 et représenté en pointillés sur la figure 9). Il implique le GGSN, le GANC, l'ACR et le terminal TM.
Dans cet exemple, le nouveau graphe de décision actif 91 est confondu avec le(s) nouveau(x) graphe(s) de décision possible(s). Cet exemple d'implémentation montre bien que les graphes de décision
(possibles et actifs) sont construits dynamiquement pour chaque application de chaque terminal. Cet exemple montre aussi l'économie de signalisation qui est réalisée en évitant de transférer des paramètres entre les entités (cas de la charge du GANC par exemple). Enfin, le diagramme de séquence de messages de la figure 10 montre comment les nouveaux messages définis par l'invention (représentés en doubles traits) s'intègrent dans un processus complet de prise de décision (cas de la figure 9). Les messages de configuration sont référencés 101 à 103, et les messages de décision 104 à 107.
L'annexe 1 détaille un exemple de réalisation des messages suivants : - le message (101 ) de configuration envoyé par le GGSN-MD vers le GANC-MD ; le message (102) de configuration envoyé par le GANC-MD vers F ACR-MD ; et le message (107) de décision envoyé par l' ACR-MD vers le terminal TM-MD, La figure 11 présente la structure simplifiée d'un équipement de communication 110 selon un mode de réalisation particulier de l'invention, intégrant un module de décision capable d'émettre et/ou traiter des messages de configuration et/ou des messages de décision selon au moins un mode de réalisation (par exemple celui présenté ci-dessus en relation avec les figures 8 et 9) du procédé selon l'invention de construction d'au moins un graphe de décision pour la gestion d'au moins un flux applicatif affecté à un terminal.
Cet équipement est par exemple le GGSN, le RNC, le GANC, l'ACR ou le terminal TM des figures 8 et 9.
11 comprend une mémoire 1 13, une unité de traitement 11 1, équipée par exemple d'un microprocesseur, et pilotée par un programme d'ordinateur 1 12 d'émission et/ou traitement de messages de configuration et/ou des messages de décision selon l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 112 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 1 11 pour : générer un message de configuration 115 et le transmettre à un autre équipement comprenant un module de décision ; et/ou - traiter un message de configuration 114 provenant d'un autre équipement comprenant un module de décision (et éventuellement générer un autre message de configuration 115 et le transmettre à un autre équipement comprenant un module de décision) ; et/ou générer un message de décision 117 et le transmettre à un autre équipement comprenant un module de décision ; et/ou traiter un message de décision 116 provenant d'un autre équipement comprenant un module de décision (et éventuellement générer un autre message de décision
1 17 et le transmettre à un autre équipement comprenant un module de décision).
Dans le cas précité où l'invention est implantée partiellement ou totalement sous forme logicielle, dans chaque équipement comprenant un module de décision pouvant participer à la construction dynamique de graphes de décision possibles et actifs, la séquence d'instructions correspondante pourra être stockée dans un moyen de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce moyen de stockage étant lisible partiellement ou totalement par un ordinateur ou un microprocesseur.
AiNNEXE 1 : Exemple de messages de configuration et de décision
Message (101) de configuration GGSN-MD -> GANC-MD
Adresse du MD (module de décision) source: adresse IP GGSN Adresse du MD destination: adresse IP GANC Identification du couple: (identifiant MAC, identifiant de Flux) Deux structures de distribution dans ce cas: Adresse du MD tiers: adresse IP GGSN
Rôle du MD: Hiérarchique Caractère de la méthode de distribution: par défaut Caractère de la méthode de décision: suggérée Méthode de décision: fonction utilité Granularité supportée : par flux
Paramètre définissant la méthode de décision: a=3 Paramètre de la méthode de décision:
Nom du paramètre: Profil Utilisateur
Adresse du module contenant ce paramètre: adresse IP GGSN Adresse du MD tiers: adresse IP ACR
Rôle du MD: Pair
Caractère de la méthode de distribution: obligatoire Méthode de distribution: Conflict free Caractère de la méthode de décision: suggérée Méthode de décision: fonction utilité
Granularité supportée : par flux Paramètre définissant la méthode de décision: a=2 Paramètre de la méthode de décision
Nom du paramètre: Coût Adresse du module contenant ce paramètre: adresse IP ACR Message (102) de configuration GANC-MD -> ACR-MD
Adresse du MD source: adresse ÏP GANC Adresse du MD destination: adresse IP ACR Identification du couple: (identifiant MAC, tous les flux)
Une structure de distribution dans ce cas:
Adresse du MD tiers: adresse IP GANC
Rôle du MD: Pair
Caractère de la méthode de distribution: obligatoire Méthode de distribution: conflict free
Caractère de la méthode de décision: par défaut
Granularité supportée : par flux
Message (107) de décision ACR-MD -> TM-MD Adresse du MD source: adresse IP ACR
Adresse du MD destination: adresse IP TM
Type de décision: partielle
Identification du couple: (identifiant MAC, identifiant flux (VoD))
Décision: handover (identifiant AP (Point d'accès); identifiant RAN3)
ANNEXE 2 :
Exemple de déclencheurs et paramètres pouvant entrer dans la décision de mobilité
1 ) Exemples de paramètres
* Profil de description du terminal:
Carte réseau disponible et la qualité de service associée Support du multi-accès
* Profil de description des flux; Identifiant des flux pour îes applications en cours
Type de flux (adaptif ou pas) Classe de flux (conversationnel, interactif, ...) Qualité de service minimal (bande passante, délai, gigue, taux d'erreur ., .)
* Profil utilisateur: Identifiant
Réseau d'accès préféré par application Réseau d'accès interdit par application Préférence coût versus qualité Niveau de sécurité par application Priorité par application
* Profil opérateur:
Réseau préféré par utilisateur et par application Réseau interdit par utilisateur et par application Liste des réseaux avec lesquels un accord a été établit Priorité par application
Préférence de répartition de charge
* Profil réseau d'accès:
Identifiant Charge Niveau de signal par terminal
Qualité de signal par terminal Coût monétaire
Niveau de sécurité
Qualité de service disponible
Qualité de service typique ples de déclencheurs
Congestion
Décongestion
Lancement d'une application
Variation d'un paramètre de qualité de service Perte de couverture imminente
Découverte d'un nouveau point d'accès
Diminution de la qualité perçue
Modification d'un profil utilisateur
Modification d'une politique opérateur

Claims

REVENDICATIONS
1. Procédé de construction d'au moins un graphe de décision pour la gestion d'au moins un flux applicatif affecté à un terminal (TM) et établi entre ledit terminal et un correspondant (C) via au moins un réseau de communication, ledit procédé étant caractérisé en ce qu'il comprend une étape (71) de construction dynamique d'au moins un graphe de décision possible pour ledit au moins un flux applicatif affecté audit terminal, comprenant elle-même une étape d'échange d'au moins un message de configuration (73 à 711 ; 101 à 103) entre au moins deux modules de décision appartenant à un ensemble déterminé de modules de décision (MDl à MD7).
2. Procédé selon la revendication 1, caractérisé en ce que chaque message de configuration comprend les champs suivants : un champ (121) contenant un identifiant du module de décision source dudit message de configuration ; un champ (122) contenant un identifiant du module de décision destinataire dudit message de configuration ; un champ (123) contenant un identifiant d'au moins ledit terminal, pour lequel ledit message de configuration s'applique ; un champ (124) contenant au moins une structure de distribution.
3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que chaque message de configuration est spécifique à un terminal et à un flux applicatif.
4. Procédé selon l'une quelconque des revendications 2 et 3, caractérisé en ce que chaque structure de distribution comprend les champs suivants : un champ contenant un identifiant d'un module de décision tiers, distinct dudit module de décision destinataire ; - un champ contenant un rôle dudit module de décision tiers ; un champ contenant un caractère d'une méthode de distribution à utiliser entre le module de décision destinataire et ledit module de décision tiers ; un champ contenant un caractère d'une méthode de décision à utiliser par le module de décision destinataire.
5. Procédé selon l'une quelconque des revendications 2 à 4, caractérisé en ce que chaque structure de distribution comprend en outre au moins un champ supplémentaire appartenant au groupe comprenant : un champ contenant une granularité supportée ; - un champ contenant une méthode de distribution à utiliser entre le module de décision destinataire et ledit module de décision tiers ; un champ contenant au moins un paramètre définissant ladite méthode de distribution ; un champ contenant une méthode de décision à utiliser par le module de décision destinataire ; un champ contenant au moins un paramètre définissant ladite méthode de décision.
6. Procédé selon l'une quelconque des revendications 2 à 5, caractérisé en ce que chaque message de configuration comprend en outre un champ supplémentaire (125) contenant au moins une structure de déclencheur d'une méthode de décision à utiliser par le module de décision destinataire.
7. Procédé selon la revendication 6, caractérisé en ce que chaque structure de déclencheur comprend les champs suivants : un champ contenant un identifiant d'un déclencheur donné ; un champ contenant un identifiant du module de décision contenant le déclencheur donné.
8. Procédé selon l'une quelconque des revendications 2 à 7, caractérisé en ce que chaque message de configuration comprend en outre un champ supplémentaire (126) contenant au moins une structure de paramètres de décision à utiliser par le module de décision destinataire, chaque structure de paramètres comprenant les champs suivants : un champ contenant un identifiant d'un paramètre donné ; un champ contenant un identifiant du module de décision contenant le paramètre donné ; un champ contenant un identifiant du module de décision destinataire du paramètre donné ; un champ contenant une fréquence d'envoi du paramètre donné.
9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comprend en outre une étape (72) de construction dynamique d'un unique graphe de décision actif pour ledit au moins un flux applicatif affecté audit terminal, comprenant elle-même une étape d'échange d'au moins un message de décision (712 à 716 ;104 à 107) entre au moins deux modules de décision, en respectant une configuration préalablement créée par l'étape de construction dynamique d'au moins un graphe de décision possible, ledit unique graphe de décision actif étant le ou l'un des graphes de décision possibles préalablement construits pour ledit au moins un flux applicatif.
10. Procédé selon la revendication 9, caractérisé en ce que chaque message de décision comprend les champs suivants : un champ (131) contenant un identifiant du module de décision source dudit message de décision ; un champ (132) contenant un identifiant du module de décision destinataire dudit message de décision ; - un champ (133) contenant un type de décision, partielle ou finale ; un champ (134) contenant un identifiant d'au moins ledit terminal, pour lequel ledit message de décision s'applique ; un champ (135) contenant une décision.
11. Procédé selon l'une quelconque des revendications 9 et 10, caractérisé en ce que chaque message de décision est spécifique à un terminal et à un flux applicatif.
12. Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce qu'il comprend en outre une étape préalable d'obtention d'un graphe de décision général comprenant ledit ensemble déterminé de modules de décision parmi lesquels sont choisis les modules de décision s 'échangeant les messages de configuration.
13. Procédé selon l'une quelconque des revendications 1 à 12, caractérisé en ce que ledit ensemble déterminé de modules de décision (MDl à MD7) appartiennent à une architecture de réseaux : distribuée, du fait qu'au moins deux modules de décision appartiennent à un même niveau de hiérarchie de ladite architecture, et/ou - hiérarchisée, du fait qu'au moins deux modules de décision appartiennent à deux niveaux de hiérarchie distincts de ladite architecture.
14. Procédé selon l'une quelconque des revendications 1 à 13, caractérisé en ce que la gestion dudit au moins un flux applicatif affecté audit terminal appartient au groupe comprenant : des gestions de mobilité ; - des gestions de répartition de ressources de qualité de service.
15. Equipement de communication comprenant un module de décision (MDl à MD7), caractérisé en ce qu'il comprend des premiers moyens d'échange, permettant d'échanger au moins un message de configuration avec au moins un autre module de décision appartenant à un ensemble déterminé de modules de décision, de façon à participer à la construction dynamique d'au moins un graphe de décision possible pour la gestion d'au moins un flux applicatif affecté à un terminal et établi entre ledit terminai et un correspondant via au moins un réseau de communication.
16. Equipement de communication selon la revendication 15, caractérisé en ce qu'il comprend en outre des seconds moyens d'échange, permettant d'échanger au moins un message de décision avec au moins un autre module de décision appartenant audit ensemble déterminé de modules de décision, en respectant au moins un graphe de décision possible préalablement déterminé, de façon à participer à la construction dynamique d'un unique graphe de décision actif pour ledit au moins un flux applicatif affecté audit terminal,
17. Equipement de communication selon l'une quelconque des revendications 15 et
16, caractérisé en ce qu'il appartient au groupe comprenant : ledit terminal (TM) ; ledit correspondant (C) ; des entités (GGSN, RNC, GANC, ACR) dudit au moins un réseau de communication,
18. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes du procédé selon au moins une des revendications 1 à 13 de construction d'au moins un graphe de décision pour la gestion d'au moins un flux applicatif affecté à un terminal, lorsque ledit programme est exécuté sur un ordinateur.
19. Signal échangé entre un module de décision source et un module de décision destinataire, dans le cadre de la construction dynamique d'au moins un graphe de décision possible pour la gestion d'au moins un flux applicatif affecté à un terminal et établi entre ledit terminal et un correspondant via au moins un réseau de communication, ledit signal étant caractérisé en ce qu'il porte un message de configuration (73 à 711 ;
101 à 103) comprenant : un champ contenant un identifiant dudit module de décision source dudit message de configuration ; un champ contenant un identifiant dudit module de décision destinataire dudit message de configuration ; un champ contenant un identifiant d'au moins ledit terminal, pour lequel ledit message de configuration s'applique ; un champ contenant au moins une structure de distribution.
20. Signal échangé entre un module de décision source et un module de décision destinataire, dans le cadre de la construction dynamique d'un unique graphe de décision actif pour la gestion d'au moins un flux applicatif affecté à un terminal et établi entre ledit terminal et un correspondant via au moins un réseau de communication, ledit signal étant caractérisé en ce qu'il porte un message de décision (712 à 716 ;104 à 107) comprenant : - un champ contenant un identifiant du module de décision source dudit message de décision ; un champ contenant un identifiant du module de décision destinataire dudit message de décision ; un champ contenant un type de décision, partielle ou finale ; - un champ contenant un identifiant d'au moins ledit terminal, pour lequel ledit message de décision s'applique ; un champ contenant une décision.
PCT/FR2007/051120 2006-04-18 2007-04-17 Gestion de flux applicatifs dans des reseaux mobiles WO2007119024A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/297,463 US8271405B2 (en) 2006-04-18 2007-04-17 Management of applicative streams in mobile networks
EP07731896.2A EP2008489B1 (fr) 2006-04-18 2007-04-17 Gestion de flux applicatifs dans des réseaux mobiles

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0603411A FR2900014A1 (fr) 2006-04-18 2006-04-18 Procede de construction dynamique d'un graphe de decision, equipement de communication, produit programme d'ordinateur et signaux correspondants
FR0603411 2006-04-18

Publications (1)

Publication Number Publication Date
WO2007119024A1 true WO2007119024A1 (fr) 2007-10-25

Family

ID=37670865

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2007/051120 WO2007119024A1 (fr) 2006-04-18 2007-04-17 Gestion de flux applicatifs dans des reseaux mobiles

Country Status (4)

Country Link
US (1) US8271405B2 (fr)
EP (1) EP2008489B1 (fr)
FR (1) FR2900014A1 (fr)
WO (1) WO2007119024A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5035131B2 (ja) * 2008-06-19 2012-09-26 富士通株式会社 基地局装置、無線通信システム、無線通信制御方法および無線通信制御プログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6651101B1 (en) * 1998-12-04 2003-11-18 Cisco Technology, Inc. Method and apparatus for identifying network data traffic flows and for applying quality of service treatments to the flows
US6718380B1 (en) * 1998-10-26 2004-04-06 Cisco Technology, Inc. Method and apparatus for storing policies for policy-based management of network quality of service
EP1458148A1 (fr) * 2003-03-10 2004-09-15 Sony International (Europe) GmbH Procédure de transfert d'appel tenant compte de la Qualité de Service (QoS) pour réseaux ad hoc
US20040223602A1 (en) * 2003-05-05 2004-11-11 Zhi-Chun Honkasalo Method, system and network element for authorizing a data transmission

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6088804A (en) * 1998-01-12 2000-07-11 Motorola, Inc. Adaptive system and method for responding to computer network security attacks
US20020133586A1 (en) * 2001-01-16 2002-09-19 Carter Shanklin Method and device for monitoring data traffic and preventing unauthorized access to a network
FR2883997A1 (fr) 2005-04-04 2006-10-06 France Telecom Procede de gestion de decisions, procede de construction d'un arbre de decision, gestionnaire central, gestionnaire intermediaire, terminal et produits programmes d'ordinateur correspondants

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6718380B1 (en) * 1998-10-26 2004-04-06 Cisco Technology, Inc. Method and apparatus for storing policies for policy-based management of network quality of service
US6651101B1 (en) * 1998-12-04 2003-11-18 Cisco Technology, Inc. Method and apparatus for identifying network data traffic flows and for applying quality of service treatments to the flows
EP1458148A1 (fr) * 2003-03-10 2004-09-15 Sony International (Europe) GmbH Procédure de transfert d'appel tenant compte de la Qualité de Service (QoS) pour réseaux ad hoc
US20040223602A1 (en) * 2003-05-05 2004-11-11 Zhi-Chun Honkasalo Method, system and network element for authorizing a data transmission

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
D. DURHAM, J. BOYLE, R.COHEN, S. HERZOG, R. RAJAN, A.SASTRY: "RFC 2748: The COPS (Common Open Policy Service) protocol", REQUEST FOR COMMENTS, January 2000 (2000-01-01), pages 1 - 32, XP002421672, Retrieved from the Internet <URL:http://www.rfc-editor.org/rfc/rfc2748.txt> [retrieved on 20070223] *
R. BRADEN, L. ZHANG, S. BERSON, S. HERZOG: "RFC 2205: Resource ReSerVation Protocol", REQUEST FOR COMMENTS, September 1997 (1997-09-01), University of Michigan, pages 1 - 70, XP002421652, Retrieved from the Internet <URL:http://www.faqs.org/rfcs/rfc2205.html> [retrieved on 20070223] *

Also Published As

Publication number Publication date
FR2900014A1 (fr) 2007-10-19
US8271405B2 (en) 2012-09-18
EP2008489A1 (fr) 2008-12-31
EP2008489B1 (fr) 2018-06-06
US20090106175A1 (en) 2009-04-23

Similar Documents

Publication Publication Date Title
EP1767033B1 (fr) Procede de gestion des ressources radio dans un reseau d&#39;acces radio de type utran
EP1665661B1 (fr) Procede de differenciation de la qualite de service dans les reseaux de communication mobile en mode paquets
EP1792447B1 (fr) Procede de preemption pour la gestion des ressources radio dans un reseau de communication mobile
EP2504950B1 (fr) Controle d&#39;admission pour abonnement de service
FR3025387A1 (fr) Dispositif et procede de controle d&#39;un coeur de reseau ip
WO2017097576A1 (fr) Dispositif et procede de communication sans-fil dans un reseau ip
EP1598997B1 (fr) Routage au sein d&#39;un réseau de communication
EP3682600B1 (fr) Gestion de la connexion avec d&#39;autres passerelles residentielles d&#39;une passerelle residentielle mettant en oeuvre l&#39;agregation de liens
EP3580898A1 (fr) Procede et dispositif de determination de chemin de routage econome en energie
EP2008489B1 (fr) Gestion de flux applicatifs dans des réseaux mobiles
FR2896645A1 (fr) Procede de gestion de la qualite de service, entite de gestion, point d&#39;attachement, terminal mobile et programmes d&#39;ordinateur correspondants
EP1432210B1 (fr) Dispositif de contrôle de traitements associés a des flux au sein d&#39;un reseau de communications
EP2232816B1 (fr) Gestion d&#39;une communication dans un reseau heterogene
FR3058863A1 (fr) Equipement mandataire dans un systeme de telecommunication cellulaire
WO2023104724A1 (fr) Procédé d&#39;émission d&#39;un flux de données dans un réseau de communications, procédé de traitement d&#39;un flux de données, procédé de contrôle du traitement d&#39;un flux de données, dispositifs, équipement terminal, entité d&#39;exécution, entité de contrôle, système et programmes d&#39;ordinateur correspondants.
EP4366252A1 (fr) Procédé et dispositif de gestion de messages diffusés dans un réseau local
FR3105680A1 (fr) Procédé et dispositif de routage de flux de données
EP4335144A1 (fr) Parametrage d&#39;un terminal
CA3131239A1 (fr) Procede de basculement d&#39;une station mobile entre deux points d&#39;acces sans fil d&#39;un reseau de communication et dispositif gestionnaire de connexions associe
WO2014191686A1 (fr) Procédé de sélection de cellule dans un réseau sans-fil hétérogène
FR2954038A1 (fr) Gestion d&#39;itinerance en mode paquet dans un reseau de radiocommunication
FR3014281A1 (fr) Equipement de passerelle d&#39;acces de mobiles a internet
WO2005002147A1 (fr) Architecture de reseau local sans fil

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: 07731896

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2007731896

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 12297463

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE