WO2011101576A1

WO2011101576A1 - Service access management in a network

Info

Publication number: WO2011101576A1
Application number: PCT/FR2011/050261
Authority: WO
Inventors: François Bougant
Original assignee: France Telecom
Priority date: 2010-02-16
Filing date: 2011-02-08
Publication date: 2011-08-25

Abstract

The invention relates to managing access to a service offered to a client entity in a communication network including at least one network entity. The service corresponds to a session for transmitting digital content in the form of a data stream. In the network entity, a comparison (414, 414b) is established between a first typical value indicating a charge level associated with the session and a second typical value indicating a charge level relative to the network entity. Then, the treatment to be applied to the session is decided according to said comparison.

Description

MANAGING ACCESS TO A SERVICE IN A NETWORK

The present invention relates to an Internet type of communication network, or IP for 'Internet Protocol', and more particularly to a service management offered in such a network.

This type of network makes it possible to offer different services such as, for example, telephone services (VoIP for 'Voice over IP'), video telephony (V2oIP for 'Voice and Video Internet Protocol') or video broadcasting. (IPTV for Internet Protocol TeleVision '). When implementing some of these services, it is possible that the IP network is overloaded, at least at certain locations. It is therefore interesting to try to manage the flows in networks of this type.

The implementation of some of these services may be based on application sessions consuming a high rate while the implementation of some others is based on low-speed consumer application sessions. It is then possible that the high-rate application sessions degrade each other or degrade the quality of the lower-rate application sessions, especially when a bottleneck occurs at certain nodes of the network.

In order to avoid such a situation, one can try to limit the bit rate that is used by the application sessions that consume the most bitrate. Such a limitation makes it possible to preserve a certain level of flow for other less consuming application sessions. It is thus possible to avoid excessive damage for these last sessions.

However, by doing so, all the application sessions for which the bit rate has been limited, that is to say the application sessions that consume the most bitrate, is degraded.

The present invention improves the situation.

A first aspect of the present invention provides a method of managing access to a service offered to a client entity in a communication network comprising at least one entity ^; network;

said service corresponding to a digital content transmission session in the form of a data stream;

said method comprising the following steps at said network entity, upon detecting a transmission session initialization of a digital content for the client entity:

/ a / performing a comparison between a first characteristic value indicating a charge level associated with the session and a second characteristic value indicating a charge level relating to the network entity; and / b / decide on a treatment to be applied to the session according to said comparison. The term "treatment" is understood to mean any type of treatment that may be decided to apply to a session on the basis of the comparison of the two characteristic values as stated. Such processing may include allowing or delaying the session (ie delaying it in time), or blocking the session, or rejecting the session for which a initialization is required.

The term 'a client entity' means any type of terminal in a communication network adapted to receive digital content via the network. Such an entity can be in particular a user terminal or a residential gateway or an enterprise gateway, etc., ...

The term 'network entity' is understood to mean any type of entity of the considered network. It should be noted that no limitation is attached to this aspect in the present context. It can easily be foreseen that this network entity is in charge of both the detection of the session, as well as the decision making of the treatment to be applied to this session and also the application of the decided treatment. It can also be provided that this entity is responsible only for the decision making of the processing, or that it is in charge of the decision-making and one of the session initialization detection and application. treatment decided at the session.

When the decided processing is a timer of the session, it is thus possible that the network entity is in charge of the decision of the processing to be applied. Then she marks all the packages in this session with a flag. Then, another network entity can then manage the timing itself tags so marked. In general, it should therefore be noted that the detection of a session initialization, the decision of a processing to be applied to this session and the effective application of the decided processing can be carried out by separate network entities or by one and the same network entity.

Here, it is therefore planned to decide to apply a treatment to a session for which an initialization is provided, this processing depending on the comparison of the characteristic values. Thus, it is possible to accept or refuse, or to delay (delay) a new digital content transmission session by taking into account both an indication of the load generated by the session in question and an indication relating to a level of load of the network entity that receives it, at the time this session is initialized. Thus, it is not a question here of systematically favoring low-consumption sessions at the expense of larger consumer sessions. It is a question of taking into account respective charge levels and which evolve in time, at the time of the initialization of a new session.

By doing so, it is possible to implement a management of access to a content transmission service at the level of a network entity that is performed on the basis of each session while taking into account a state of network load. Indeed, advantageously, this access management is a function of a load level associated with the session that is required. This level load represents in some way the load that would be induced by the required session if it was accepted. Thus, this first value represents a future load level in the event that the session is allowed.

It is also taken into account a load level at the network entity level. This second value may represent either an already existing charge level or a still available charge level, at the considered network entity.

By performing a comparison of these first and second values, one can decide to accept or not to accept the session. This decision being based on useful information, it can be relevant and effective to avoid overloads in the considered network. Thanks to these arrangements, it is possible to maintain a stability in the network by regulating the traffic at the network entity level, by delaying, that is to say by delaying, or by refusing, the sessions, which would represent a level of load that is too high compared to the already existing load level at the time the session is initialized.

At this stage, depending on the comparison, it is possible:

either accept (or "allow") the session and thus transmit the data stream of the session transparently to the client entity,

to deliberately slow down the transmission of the data stream of the session so as to regulate the bit rate in the network,

to refuse the session.

It is emphasized here that the network entity may be in charge, in the case of a timing process, of marking the data flow of the session to indicate that the transmission is slowed down and that the effective implementation the regulation can be performed at one or other entity (s) of the network.

In the case where it is decided to slow down or delay the transmission of the data stream, it is possible not to inform the sending client entity. This management is then transparent for the user and the client entity.

In the case of the refusal of the session, this refusal decision may be followed by the sending of a message to the client entity informing the latter of the decision taken. The client entity can then reiterate its session initialization later.

The term 'digital content' is understood to mean any type of content that can be transmitted in an IP network (for 'Internet Protocol'). Such content may correspond in particular to multimedia content, an image file, a soundtrack, audio visual content, etc. The initialization of the session is generally carried out by issuing a request sent by the entity client to a network server that is adapted to provide the required digital content and response from the server.

It should be noted that, thanks to these characteristics, it is advantageously possible to prevent a bottleneck from occurring at the level of the considered network entity. Indeed, this network entity is in charge of regulating this traffic appropriately. Such regulation can be performed at any network entity. It may therefore be advantageous to locate in the network the locations that are likely to generate a bottleneck so as to implement a work according to an embodiment of the present invention at these different locations.

The communication network considered here is of JP network type for illustrative purposes.

The term 'network entity' is understood to mean any entity of the network located in the considered network. It is indeed both easy and equally relevant to implement a method according to an embodiment of the present invention at any level of the network considered. The nature of the first and second characteristic values may depend on the type of the network entity on which this access management is implemented. Indeed, depending on the type of the network entity and / or its location in the network, it does not have the same information about the required application sessions.

Thus, for example, it is possible to implement this access management to a service at a network entity corresponding to a network access entity. In this case, all the data flows of the client entities connected to the communication network pass through the considered network entity. This entity can have a relatively complete view of the activity of each client entity for which it acts as a network access point. The second characteristic value indicating a charge level of the network entity can then be relative to a particular client entity. For example, a load threshold value may be provided for a given client entity, this threshold value may in particular vary according to its network access subscription, or depending on the type of server with which the required session will be established, or depending on the type of application associated with the required session, etc. ... The second characteristic value then represents the load still available for this client entity with regard to the threshold value associated with it at the level of the network entity. Then, when the second value associated with this client entity at the network entity level is too small relative to the first value associated with the new requested session, then the requested session may not be accepted.

In such a context, it is easy to offer customers different services according to their profile, for example according to their subscription, by defining different threshold values. These threshold values can also vary according to the type of applications, as well as suppliers, etc. ...

It is also easy to envisage implementing this management of access to a service at the level of a network entity corresponding to a network entity of the core network. In this case, the second characteristic value indicating a charge level of the network entity can then represent the charge at the network entity more generally. Thus, for example, this second characteristic value can be an indicator of the load available for new sessions of the service considered with regard to the already existing load of sessions transiting through this network entity and with regard to a maximum threshold value of load for example.

No limitation is attached to the type of the first and second values taken into account according to one embodiment of the present invention. The second value may be a function of one or more threshold values, used as a reference to define a level of load availability for the considered network entity.

In one embodiment of the present invention, the first characteristic value corresponds to a transmission rate associated with the session and the second characteristic value indicates a transmission rate available at the network entity.

The second characteristic value can then relate to a threshold value corresponding to a maximum rate that this entity has the capacity to receive and transmit.

As indicated above, this transmission rate available at the network entity can be determined by reference to a rate threshold value that can be managed at this entity. This embodiment is particularly suitable for sessions in which it is easy to recover an associated rate value.

In some sessions, it is easy to recover a size of the digital content associated with it. In this case, the response of the server to the request from the client entity indicates a required digital content size and the transmission rate can then be deduced from this indicated size.

This second characteristic value can then relate to a threshold value corresponding to a maximum number of sessions that the network entity can manage. In this case, it may be advantageous to weight this threshold value depending on the type of session or more specifically the load associated with the session in question. Thus, for example, it is possible to define a maximum number of sessions, per load range associated with these sessions. It is therefore possible to define a first maximum number of sessions that can be managed by the network entity for the sessions of transmission of heavy digital content, that is to say having a large size, and it is possible to define a second maximum number of sessions that can be managed by the network entity for relatively small digital content transmission sessions.

It can thus be provided that the network entity manages a session counter available per digital content size per session; the first characteristic value indicating a digital content size associated with the session and the second characteristic value corresponding to this counter.

By doing so, it is not useful to determine a rate value associated with the required session.

In one embodiment, the second characteristic value is updated, on the one hand, on acceptance of the session and, on the other hand, on a logoff. Thus, the second characteristic value is dynamic and indicates relevant information. It may be advantageous for the second characteristic value to be a function of a profile of the client entity. By doing so, the second characteristic value can be varied according to the client entity for which the session is required. In particular, depending on a type of subscription, for an identical session load, it is thus possible to privilege a client entity having a "premium" subscription offering it privileged treatment with respect to a client entity having subscribed to a "basic" subscription " for example. This embodiment is all the more powerful that it is implemented at the level of a network entity which is a network access point for the client entity concerned.

In step / b /, it can be decided to apply to the session one of the treatments among a session authorization, a session timer, a session lock, and a session rejection.

By deciding in a pertinent way a treatment adapted to the comparison of the two characteristic values, the traffic in the network can be advantageously adapted. ^r

One can easily predict that if, in step / b /, it is decided to process the session by timing, the flow data corresponding to the session are transmitted with a determined delay.

Thus, thanks to these characteristics, it is easy to implement a method of limiting flow that is efficient. For this purpose, the network entity can create an application context per session initialized. Then, when a particular treatment must be applied to the session, the network entity can then indicate this information in the application context by using a flag (or 'flag') in the application context associated with this session. When received data is identified as packets of this session, then they are delayed.

It is possible that the second characteristic value evolves between the moment when it is decided to delay a session and a moment when a packet of this session is transmitted. This is the case when during a delayed session, one or more other sessions are completed. Thus, in one embodiment of the present invention, it is expected that, on receipt of a packet belonging to the timed session, the comparison step / a / is again implemented and according to the new comparison. we decide not to delay the session.

We are thus able to no longer delay a session in progress when the evolution of the treatment decision-making context allows it.

In one embodiment of the present invention, if in step / b / it is decided to process the session by rejection, the data of the stream corresponding to the session is ignored and the network entity also transmits a message. to the client entity indicating that the session is rejected. Thanks to these characteristics, it is easy to implement an admission control at the level of the network entity. Indeed, here we can refuse the session. In this case, it is indicated to the client entity, which eventually reiterates its request later. A second aspect of the present invention provides a network entity adapted to implement a service access management method according to the first aspect of the present invention.

A third aspect of the present invention provides a service access management system comprising at least one network entity according to the second aspect of the present invention. It may be advantageous for such a system to comprise a plurality of network entities, thus making it possible to avoid possible traffic bottlenecks in the network in question.

Such a service access management system may further include another network entity adapted to apply to a session a processing decided by the network entity according to the second aspect of the present invention. This is the case when the network entity making the decision of the processing to be applied to the session is distinct from the network entity that will actually apply the decided processing.

A fourth aspect of the present invention provides a computer program including instructions for implementing the method according to the first aspect of the present invention, when the program is executed by a processor.

A fifth aspect of the present invention provides a recording medium on which the computer program according to the fourth aspect of the present invention is stored.

Other aspects, objects and advantages of the invention will appear on reading the description of one of its embodiments.

The invention will also be better understood with the aid of the drawings, in which:

Figures 1 and 2 illustrate architectures of a network according to embodiments of the present invention;

Figure 3 illustrates the main steps of a method of managing a service according to an embodiment of the present invention;

FIG. 4 illustrates a detailed implementation of an access management method according to an embodiment of the present invention at a network entity, in its application to a rate limitation; and

Fig. 5 illustrates a network entity according to one embodiment of the present invention.

Figures 1 and 2 illustrate architectures of a network according to embodiments of the present invention.

According to FIG. 1, the network comprises a plurality of servers 102 to 105, a network entity 100 and a client entity 101. The client entity 101 can be a terminal, a residential or enterprise gateway, etc. the example illustrated here, the network entity 100 corresponds to a network access entity for the client entity 101. Thus, in this network, the outgoing and incoming traffic, respectively transmitted by the client entity 101 and received by the client entity 101, passes through this entity The network further includes a core portion, or core network, located between the network entity 100 and the servers 102-105, which is not illustrated here.

It should be noted that this example is in no way limiting, the network entity 100 being able to correspond to any network entity of the considered network.

FIG. 2 illustrates an architecture according to which the network entity is an entity of the core part of the considered network.

This network comprises a core portion which is represented solely by a core network entity 200. It is easy to implement a management method according to an embodiment of the present invention at the network entity 200. case, it is not certain that all the traffic sent or received by the client entity 101 passes through the network entity 200. However, the present invention also finds a relevant application in this context. Indeed, it avoids the formation of traffic bottlenecks in the core network.

Figure 3 illustrates the main steps of a service access management method according to an embodiment of the present invention.

To manage access to a service offered to a client entity in a network such as that shown in Figure 1 or Figure 2, the following steps can be implemented.

The service is a digital content transmission session in the form of a data stream. At the network entity level, a transmission session initialization of a digital content is detected at a step 301. Specifically, a request is generally issued by the client entity 101 requesting the digital content to a destination. server adapted to transmit this digital content and the server transmits a response to this request, the session being initialized on positive response of the server.

Upon detection of such an initialization at a step 302, a comparison is made between a first characteristic value indicating a charge level associated with the required session and a second characteristic value indicating a charge level relative to the network entity.

This comparison step makes it possible to take into account on one side a future charge potentially generated by the acceptance of the access to the required service, that is to say by the required digital content transmission session. and on the other hand an existing load that is already associated with the network entity on which such access management is implemented. This comparison step makes it possible to take a relevant decision on the basis of load indicators which are the first and second characteristic values.

These first and second characteristic values may be of different types according to the embodiments of the present invention. No limitation is attached to the present invention as to the characteristic value associated with the required digital content transmission session or even the characteristic value associated with the network entity's load, even if the type of the first and second values match to allow comparison. Thus, any type of value that indicates a charge associated with the future transmission of the required digital content can advantageously be taken into account here. In particular, it can be provided that this first value indicates a bit rate required for the transmission of required content or a file size associated with this digital content, for example.

Then, any type of value that indicates a load associated with the network entity can be taken into account as well. In the case where the first value indicates a rate value, the second characteristic value may also indicate a level of bit rate still available with regard to the already existing load on the considered network entity.

In the case where the first value indicates a file size corresponding to the required digital content, the second value can then for example indicate a number of application contexts still available for such a file size, the network entity managing an application context by session accepted. This number of available contexts is then based on a previously defined maximum number of application contexts that can be managed without overloading the traffic at this network entity. Thus, such a characteristic value indicating a number of available contexts is an indicator of the already existing load on this network entity.

It should be noted that it may be advantageous to implement a method according to an embodiment of the present invention at a network entity that potentially represents a more sensitive traffic bottleneck than at a network entity. other network locations.

Indeed, it is possible to avoid at a strategic point of the network a possible problem of transmission rate by refusing, or at least delaying, a transmission session of digital content.

Then, in a step 303, a decision is made to allow or not the session based on this comparison of step 302.

This decision is taken on detection of a digital content transmission session initialization. Such a decision may consist of:

allow the session, and thereby transmit the data stream of the session into the network;

- block the session;

reject the session and thereby inform the client entity by sending a corresponding message (the latter two cases may correspond to the establishment of an admission control); or

delay the session by delaying the data flow of the session (this case may correspond to the implementation of a method of limiting the flow in the network). It is emphasized here that a session delayed during its initialization can then return to a normal or nominal processing, that is to say without slowing down, when the result of the comparison has evolved, for example when another authorized session ended. The session processing context remains preferably evolutionary over time on the basis of taking into account the two characteristic values defined according to the invention.

In a particular embodiment, in the case of a speed limit, it is then possible to mark the session required by a flag (or 'flag' in English) so that all the packets transmitted during this session , both to the client entity and the client entity, are delayed. It is simply necessary to provide a flag in the application context of the session. The session is thus timed. Then, the transmission of all the packets of this session is then delayed by one or more other entities of the network. In other words, a packet received during a session is first stored for a period of time before being transmitted either in the network or to the client entity.

It can be advantageously provided to pass from a timed session state to a nominal or normal session state, that is to say without delay, in the case where the second characteristic value has been modified and thus the comparison step no longer provides the same result. This may be particularly the case when one or more sessions have been released at the considered network entity.

By 'block session', we mean throwing or ignoring packages related to this session.

In a particular embodiment, it is also possible to send an end-of-session message to the client entity and to the server.

It should be noted that the client entity information is optional in the case of session blocking processing.

Access management according to an embodiment of the present invention is initiated upon detecting transmission session initialization of digital content. Other steps are planned thereafter to manage both the session itself and then the end of the session.

Figure 4 illustrates a detailed implementation of an access management method according to an embodiment of the present invention at a network entity, in its application to a rate limitation. It is easy to deduce from this an application to an admission control, that is to say when the data flow of a session is blocked and not slowed down or timed.

According to this FIG. 4, it is planned to apply the steps not only implemented at the time of initialization of the transmission session but also the steps implemented during the session itself, as well as when the session end.

In one embodiment of the present invention, the network entity in question manages an application context per digital content transmission session depending on the offered service under consideration. Such an application context may correspond to a set of information relating to the session. In the case where a flow rate limitation is implemented according to an embodiment of the the present invention, it is expected to slow down or delay certain sessions in some cases and thus manage a 'flag' per application context to indicate whether the session is slowed down or not.

This is to control any incoming packet at the network entity, whether this packet comes from the network or from the client entity.

At a step 401, waiting for the reception of a packet ΓΡ. We return to this step as soon as the received packet is transmitted.

On receiving such a packet, in step 402, it is determined whether it belongs to a session already known at the network entity level or whether it is a new session.

In the case of a new session, in step 403, it is intended to create an application context at the network entity level so as to manage this session. Then, it is planned in step 404 to check whether the received packet contains application data or not. If the received packet does not contain application data, it is then transferred to a step 421.

On the other hand, if it contains application data, the latter are analyzed at a step 411. More precisely, the nature of the application used in this session is determined. Thus, it can be predicted to determine that an application session is of "audiovisual content download" type based on a series of tests relating to the presence and the value of certain parameters contained in the application part of the IP packet.

No limitation is attached to the type of tests used to determine the nature of the application associated with the required session. For example, it is possible to determine the application from the network address of the server, or when the required session is according to an http protocol, it is possible to rely on the value of the field 'content- type ', as well as on file extensions corresponding to audiovisual type digital content.

Then, it is checked in a step 412 if the required session corresponds to a new session of transmission of digital content. In this case, at a step 413, a first characteristic value of the session is determined. This first value may correspond to a bit rate associated with the required session or to a size of the required digital content. This first value can be determined from the content of the first response of the server, for example the value of the field 'content-length ^* in http or the read rate contained in the header of the multimedia file.

If the first value relates to a rate (or 'rate' in English), then at a step 414b, this first value is compared with a second value which relates to an available rate (or 'available rate') at the the network entity. If the first value is less than the second value, the packet is transmitted (step 421). Otherwise, at a step 417, it is decided here that the packets in connection with this session are delayed. For this purpose, the session is marked with a corresponding flag, that is to say that the application context relating to this session stores the delay of the packets of this session. For the packet being received, it is stored at a step 410 for a period of time to be transmitted only at the end of this period of time at a step 421. It is possible that the first value is relative to the size of the digital content to be transmitted. In this case, it can be expected that a threshold value of a number of application contexts is defined at the level of the network entity. Thus, it is possible to limit the load at the level of the network entity, by limiting the number of application contexts that it manages.

No limitation is attached to the present invention in the manner of managing the relationship between the number of application contexts at the network entity level and the size of the digital content of the session. It may possibly be possible to weight the number of existing application contexts counted at the network entity level, by the load associated with each session to which these application contexts relate. This weighting can also be done more or less fine. Thus, an application context created for a session relating to a large digital content could for example count twice as much as an application context created for a session relating to a small digital content.

In the example illustrated here, it is planned to define at the network entity level a maximum value of application contexts for digital contents that have a size of between one and ten MB for example and a maximum value of application contexts for digital content that is larger than the maximum size of ten MB.

In this context, following step 413, especially when it is not easy to determine a rate associated with a session, it is possible in a step 414 to control the size of the digital content of the session. If this size is greater than a first value, here set as an example at 1 MB, then we go to step 415. At this step 415, we check if the size of the digital content is less than a second value, for example, ten MB. If so, proceed to step 416. At this step 416, if the number of application contexts already allocated for the sessions relating to small digital contents (i.e. say greater than 1 MB but less than 10 MB in the case illustrated) is greater than the maximum value of application contexts for this type of session, it is then decided to delay the session to a step 417. Thus, the flag of The application context of this session is set to a value meaning 'session to delay'. Packets in this session are delayed at step 410.

If the maximum value of application contexts of the small digital contents is not exceeded, then the counter of these application contexts already created is incremented from the value 1 to a step 418. Then the received packet is transmitted to step 421 .

If the size is smaller than the first value (step 414), the packet is transmitted (step 421). When the size is greater than the second value (step 415), if the number of application contexts already allocated for the sessions relating to large digital contents (that is to say greater than 10 MB in the case illustrated) is greater than the maximum value of application contexts for this type of session, it is then decided to delay the session at step 417. In the case where the number of application contexts already created is less than the maximum context value Session application with large digital content (ie greater than 10 Mo), then the number of application contexts already created for the sessions corresponding to large digital contents is incremented by the value 1. at a step 420 and the packet is transmitted at the step 421.

In step 412, in the case where it is not a new content transmission session, then it may be either a content transmission session already known by the network entity, a session which does not concern a transmission of content in the sense of the offered service in question. This last case can notably correspond to the case where the packet is related to an advertising content for example, which is not in the offered service for which one wishes to manage the access. Packets corresponding to content outside the service in question are transmitted by the network entity, step 412 being in this case connected to step 421.

If it has been determined in step 402 that the received packet belongs to a session already known, that is to say for which the network entity already manages an application context, then a step 405 succeeds step 402 In step 405, it is determined to which application context this packet belongs. This step is performed by analyzing the information contained in the headers of the network and transport layers (IP and then TCP or UDP).

Then, in a step 406, it is checked whether the received packet is detected as being a packet of a content transmission session already known by the network entity. If this is the case, it is expected in a step 407 to check if this packet corresponds to an end of the session. In the case of a TCP type protocol, this packet is then either an 'FTN' packet or an 'RST' packet.

If the packet is an end-of-session packet, then in a step 408, it is expected to:

release the managed application context for this session;

decrement value 1 the application context counter for this type of session; and or

decrement a level of available flow; and

- Possibly, plan to update one or more delay flags of existing application contexts in the case where the application context counter of this type of session falls below the corresponding maximum value. This update allows you to modify the processing applied to current sessions, in order to route their packets without applying a delay.

Then, this packet is transmitted as soon as possible to step 421.

In the case where the packet received for a known session is not an end-of-session packet (step 407), then it is determined in a step 409 whether the associated application context is marked by the flag indicating to delay the session. If this is not the case, the packet is transmitted without delay.

If not, it is stored for a period of time before being transmitted to delay the current session. This amounts to applying a delay to the transmission of the data stream.

One can plan to check whether another session has been completed to decide whether a packet marked with a delay flag can ultimately be transmitted without delay. If the received packet is not detected as a packet of a content transmission session already known by the network entity (step 406), proceed to step 411, already described.

The description was made in the context of a network entity 100 implementing the various steps of the method. It is emphasized here that certain steps can be implemented by a first network entity and others by a second network entity. For example, the first network entity may implement packet detection and tagging and the second network entity slow packetization. Still as an example, the first network entity may implement the detection of the initialization of a session, a control entity the decision to apply to the session, and the second network entity the processing.

In a particular embodiment, in step 408, the application context is not released immediately. Thus, when the client entity initiates a new transmission session relating to the same content, identified for example by the URL resource, it is authorized to access and benefits from the processing without delay of the previous session. This use case corresponds for example to the situation where the user wishes to access the same content but to a different sequence. In this case, the first session is released and a new session must be established. The method thus ensures that the new session is allowed, as the previous one. Sessions initiated by the client entity and relating to the same content therefore benefit from the same treatment.

In another embodiment, the application context stores an identifier of the client entity, for example its address in the network, an identifier of the content, for example the URL resource, and the flag. When the client entity initiates a new session, its previous session having been timed, this new session is not timed. This makes it possible to guarantee a correct quality of service to this client entity.

Fig. 5 illustrates a network entity according to an embodiment of the present invention.

Such a network entity comprises:

a detection unit 51 adapted to detect a transmission session initialization of a digital content for the client entity;

a comparison unit 52 adapted to perform a comparison between a first characteristic value indicating a charge level associated with the session and a second characteristic value indicating a charge level relative to the network entity; and

a decision unit 53 adapted to decide on a treatment to be applied to the session as a function of said comparison unit.

Claims

A method of managing access to a service offered to a client entity in a communication network comprising at least one network entity;

said method comprising the following steps at said network entity:

on detection of a transmission session initialization of a digital content for the client entity;

/ a / performing a comparison between a first characteristic value indicating a charge level associated with the session and a second characteristic value indicating a charge level relating to the network entity; and

/ b / decide on a treatment to be applied to the session according to said comparison.

A service access management method according to claim 1, wherein the first characteristic value corresponds to a transmission rate associated with the session and the second characteristic value indicates a transmission rate available at the communication entity. network.

The service access management method of claim 2, wherein the request indicates a required digital content size and wherein the transmission rate is derived from said indicated size.

The service access management method according to claim 1, wherein the network entity maintains a session counter available per digital content size per session; and wherein the first characteristic value indicates a digital content size associated with the session and the second characteristic value corresponds to said counter.

The service access management method according to claim 1, wherein the second characteristic value is a function of a profile of the client entity.

The service access management method according to claim 1, wherein, in step / b /, it is decided to apply to the session one of the treatments among a session authorization, a session timer. , session blocking, and session rejection.

7. Service access management method according to claim 6, wherein if, in step Ibl, it is decided to process the session by timing, the data of the flow corresponding to the session are transmitted with a determined delay.

8. Access management method according to claim 7, wherein on receipt of a packet belonging to the timed session, step / a / comparison is implemented again and according to the new comparison, decide not to delay the session.

A service access management method according to claim 1, wherein if in step Ibl it is decided to process the session by rejection, the data of the stream corresponding to the session is ignored and wherein the The network entity also sends a message to the client entity indicating that the session is rejected.

10. Network entity in a communication network providing a service to a client entity; said service corresponding to a digital content transmission session in the form of a data stream;

said network entity comprising:

a detection unit (51) adapted to detect a transmission session initialization of a digital content for the client entity;

a comparison unit (52) adapted to perform a comparison between a first characteristic value indicating a charge level associated with the session and a second characteristic value indicating a charge level relative to the network entity; and

a decision unit (53) adapted to decide a processing to be applied to the session based on said comparison unit.

A system for managing access to a service provided to a client entity in a communication network comprising at least one network entity according to claim 10;

said service corresponding to a digital content transmission session in the form of a data stream.

The service access management system according to claim 11, further comprising another network entity adapted to apply to a session a processing decided by the network entity according to claim 10.

13. Computer program comprising instructions for implementing the method according to claim 1, when the program is executed by a processor.

14. Recording medium on which the computer program according to claim 13 is stored.