Method of accessing a service by a communication device via at least one communication network

Abstract

The invention relates to a method for managing a service by an application server (AS), said method comprising a step of transmitting to a communication device (UE) a token (amigos_token) generated for said communication device and a given access to a service via at least one network (Network), said token (amigos_token) being associated with a service level (service_level) selected for this access to said service, said token (amigos_token) being capable of triggering, when it is contained in a data packet (Data) relating to said service exchanged via said at least one network (Network), a processing of this data packet (Data) corresponding to said service level (service_level) by at least one entity (AN, BR) called processing of said at least one network (Network). Figure for the abstract: Fig.4

Description

Title of the invention: Method for accessing a service by a communication device via at least one communication network Technical field

[0001] The present invention relates to the field of telecommunications, and more particularly to that of value-added IP services. Previous Art

[0002] [Fig.l] illustrates a simplified architecture of all the entities involved in providing an IP service. These entities include a communication device, such as a terminal or user equipment (or UE for “User Equipment” in English), at least one application server, also called an application server (or AS for “Application Server” in English) and at least one communication network “Network” arranged between the communication device and the at least one application server. The communication device embeds different applications APP#1, APP#2, ..., APP#n (or applications) associated with different services and an operating system OS (“Operating System” in English) arranged between these different applications and the network.By "the communication device embeds an application", we mean that the communication device generally comprises the client side of an application, that is to say software adapted to display, for example, a graphical interface associated with the application in the environment of the communication device. However, the application can also comprise a "server" function. One or more application servers are requested by the applications APP#1, APP#2, ..., APP#n embedded in the communication device to deliver different services Service#1, Service#2, ..., Service#n, such as a gaming service (or "gaming" in English), a content broadcasting service (or "streaming" in English), or a conference service.

[0003] The APP applications present in this communication device allow access to the services (or applications) offered by an application server from said communication device. These APP applications can request specific processing or functions via an API (for "Application Programming Interface" in English) exposed by the operating system OS of the communication device.

[0004] Access to certain functions of the communication device may, however, be limited by the OS API. For example, a network socket application may be limited to searching for WLAN (Wireless Local Area Network) access points for a communication device to connect to the network or prohibit IPv6 communications.

[0005] In addition to the OS API, the network also exposes APIs so that "external" services that rely on network resources can invoke a differentiated traffic processing procedure for data packets associated with these services. The routing of service-specific traffic (provided by one or more application servers) can therefore be subject to differentiated traffic forwarding policies.

[0006] The deployment of mobile infrastructures has brought the concept of a "slice" back into fashion. A network slice can be defined as a network partition such as a virtual private network (VPN) deployed on a fixed or mobile infrastructure. The characteristics of a network slice are typically expressed in terms of capacity (bandwidth) and quality of service (e.g. latency, one-way transit time, etc.) or even security (e.g. preserving the confidentiality of information transmitted within the VPN through the use of encryption techniques). The document by A. Farrel et al. entitled "A framework for Network Slices in Networks Built from IETF Technologies", September 2023, provides additional details on the characteristics of a network slice.

[0007] The reference architecture of [Fig.2] mainly illustrates so-called "external" services (i.e., services offered by a provider distinct from the one that manages the "Network#" network). As illustrated in this [Fig.2], a communication device can subscribe to differentiated services that can be offered by an application server or AS, a service provider, etc. An AS operates a collection of service instances involved in providing the service exposed by the AS. The invocation of one or other of the instances can be conditioned by different parameters, such as the location of the communication device, the load of each of the instances, etc. The decision logic of each AS is specific to it. Thus, no assumption is made as to the number and chaining of these different instances, their exposure to terminals, the functional scope of each instance, etc.

[0008] Traffic that may be routed via a network slice must be authorized. Such authorization is typically based on traffic classification rules that are generally applied at the "entrance" of a network that offers network slices. In the case of a network slice, this entry point may be located at the interface connecting the packet gateway to the Internet. In this case, the classification function may be located at this interface. The entry point may also be located at the interface connecting a communication device to the radio access network (or RAN) in order in particular to optimize the use of radio resources depending on the type of the network slice and the profile of the traffic it is likely to carry. Classification and admission control rules are applied at the edge of the network. However, no limiting assumptions are made about which network nodes are configured with classification rules.

[0009] The 3GPP organization has defined several types of network slices, for example eMBB (enhanced Mobile BroadBand), mloT (massive Internet of Things) and URLLC (Ultra Reliable Low Latency Communications). Each of these types is associated with a set of characteristics documented by 3GPP. The choice to design and deploy one or other of these types of slice is conditioned by the nature of the traffic characteristic of the applications or services used or subscribed to by the user. For example, a so-called "immersive" service that uses augmented or virtual reality techniques is generally very demanding in terms of latency and reliability of data exchanges. The immersive service is therefore a "natural" client of a URLLC type slice.

[0010] Furthermore, traffic classification rules can be extremely complex because one of the major demands of 3GPP is the level of granularity associated with the engineering and deployment of a slice. This level can be macroscopic (e.g., a slice deployed to route traffic to the Internet) but also microscopic (e.g., application traffic exchanged between two mobile terminals and for which a dedicated slice has been deployed).

[0011] This granularity therefore generates an overall complexity of the engineering of the slices supported by the mobile infrastructure (difficulty in optimizing the use of the resources implemented by a slice, by a set of slices, by all the slices, difficulty in strictly guaranteeing the isolation of the traffic routed within a slice, difficulty in strictly guaranteeing the level of quality or security associated with a slice, or even the levels of availability and resilience of a given slice, etc.).

[0012] In particular, the complexity of issuing and applying traffic classification rules associated with the implementation of a given slice evolves with the diversity of traffic, the richness of the organization of the structure that operates the slice (for example: an accounting department, an R&D department or a production department) or even the mode of use of the slice (for example, management of traffic overloads during busy hours with principles of traffic load distribution). This complexity is particularly aggravated by the evolution of traffic classification rules over time, sometimes at a high frequency (for example, in the context of the deployment of a slice for the retransmission of a sporting or cultural event, the traffic classification rules may evolve with the number and profile of users in the tranche).

[0013] The configuration of such rules is therefore also complex and the risk of error during the process of configuring these rules is not zero.

[0014] There is therefore a need to improve the implementation of differentiated traffic routing policies in a communications network in order to optimize the provision of and access to applications for a communications device connected to said network. Summary of the invention

[0015] An object of the invention relates to a method for managing a service by an application server, said method comprising a step of transmitting to a communication device a token generated for said communication device and a given access to a service via at least one network, said token being associated with a level of service selected for this access to said service, said token being capable of triggering, when it is contained in a data packet relating to said service exchanged via said at least one network, a processing of this data packet corresponding to said level of service by at least one entity called processing of said at least one network.

[0016] The invention proposes a collaborative mechanism between a communication device, an application server and a network making it possible to optimize the provision of access to the service by the communication device via this network. This mechanism makes it possible to manage on demand the differentiated processing by the network of data packets sent to or by an application server. This optimizes the management of the connections of a communication device to the communication network and overcomes certain limitations imposed by the operating system (OS) of the communication device.

[0017] The token used to trigger such processing is a dynamic token selected per communication, i.e. for a given access to a service by the communication device, and specific to this communication device. This token is not used for aggregates. It is thus distinguished from usage marking based on DSCP coding (for "DiffServ Code Point" in English described by the RFC4594 standard), or the use of the Flow Label field of an IPv6 packet header (RFC6437), etc. It thus offers greater granularity concerning the differentiated processing policies that can be implemented, and in particular allows the implementation of personalized differentiated processing.

[0018] The application server may comprise several service instances. The steps of the management method may be implemented by the same service instance or by different service instances.

[0019] In an alternative embodiment, the management method further comprises a step providing at least one verification information to a so-called relay entity of said at least one network allowing said relay entity to verify that said communication device is authorized to access said service using said token.

[0020] This improves the overall security of the management process.

[0021] In an alternative embodiment, the at least one verification information comprises:

[0022] - said token and an identifier of said communication device allocated by the server of application; or

[0023] - a confirmation that said communication device is authorized to access said service using said token.

[0024] This allows the relay entity or the application server to carry out the verification. In the case of verification by the application server, the relay entity provides it with an identifier of the communication device and the token. This token was provided by the communication device to the relay entity in an announcement message.

[0025] The allocation by the application server of an identifier to the communication device and the use of this identifier in the procedures implemented with the network make it possible to mask the identity of the communication device when it accesses the service via the network. This avoids storing information that could infringe on the privacy of the user of the communication device.

[0026] In an alternative embodiment, the transmission step further comprises the transmission of an indication representative of a channel carried by the data packet in which said token must be contained to trigger said processing.

[0027] Such a channel makes it possible to insert metadata useful for implementing the invention, and in particular the token triggering the processing of data packets by the processing entities of the network according to the level of service associated with the token. This channel can be negotiated in advance with the network. Alternatively, the token can be included in a standardized dedicated field.

[0028] Either of these variants makes it possible to ensure that the network processing entities intercepting the data packets relating to the service are indeed able to detect the token included, where appropriate, in these data packets and to apply the processing corresponding to the level of service associated with this token.

[0029] In an alternative embodiment, the transmission step further comprises the transmission of at least one element among:

[0030] - a service identifier known to said at least one network;

[0031] - an identifier selected by said application server for said device communication; and

[0032] - information representative of said level of service.

[0033] This improves the network's processing of data packets exchanged between the communication device and the application server.

[0034] In an alternative embodiment, the management method comprises a step of sending at least one data packet relating to said service to said communication device containing said at least one token.

[0035] The token triggering processing by the network according to the service level determined for access to the service can thus be inserted into the data packets either by the communication device or by the application server. This ensures that differentiated processing corresponding to the desired service level is applied to the data packets sent and / or received by the communication device.

[0036] In an alternative embodiment, the management method comprises: - a step of deactivating said token; and

[0037] - a step of notifying at least one entity of said network of said deactivation.

[0038] The notified network entity may be a processing entity involved in the processing of data packets according to the level of service associated with the token or a network controller capable of configuring such a processing entity. This embodiment variant makes it possible to put an end to the differentiated processing applied by the processing entities of the network according to the level of service associated with the token.

[0039] Another object of the invention relates to a method of access, by a communication device, to a service via at least one network, said method comprising:

[0040] - a reception step from an application server associated with said service of a token generated for said communication device and a given access to said service, said token being associated with a level of service selected for this access to said service, said token being capable of triggering, when it is contained in a data packet relating to said service exchanged via said at least one network, a processing of this data packet corresponding to said level of service by at least one so-called processing entity of said at least one network; and

[0041] - a step of sending to a so-called relay entity of said at least one network, a message announcing a use of said token by the communication device during said access to the service, said announcement message containing said token.

[0042] Thus, it is possible to manage on demand the differentiated processing of certain data packets sent to or by an application server. This optimizes the management of the connections of a communication device via a communication network and overcomes certain limitations imposed by the operating system of the communication device.

[0043] The announcement message aims to trigger the configuration by the relay entity of the network entities involved in the differentiated processing of the data packets, so that the token inserted in the data packets can be duly interpreted and trigger the expected processing.

[0044] In an alternative embodiment, following receipt of confirmation from the relay entity of said use, a step of inserting the token into at least one data packet relating to said service sent by the communication device during said access given to the service.

[0045] This token allows differentiated processing of the data packet in the network because it allows the packets concerned to be identified and thus trigger the associated processing. The classification of packets of the same communication can be based exclusively on the token or on a hash of a packet containing said token. Said hash is calculated by a router which keeps it in a memory. The router will apply the differentiated processing to all packets whose hash is equal to a hash present in the memory.

[0046] Another object of the invention relates to a method of configuration by a so-called relay entity of a network, said method comprising:

[0047] - a step of receiving, from a communication device, a announcement message of a use by the communication device during a given access to the service via said network of a token contained in said announcement message, said token having been generated for said communication device and said access to the service, and being associated with a service level selected for said access to the service; and

[0048] - if the communication device is authorized to access the service, a step of configuration of at least one so-called network processing entity so that said processing entity implements processing corresponding to said level of service associated with said token when this processing entity intercepts a data packet relating to the service containing said token.

[0049] The configuration of the network processing entity can be carried out according to the instructions of a controller or locally at the entity by a set of declarative commands, in particular if the relay is located in said processing entity. The processing entity is typically placed at the edge of the network and is responsible for applying traffic classification rules. Alternatively, this processing entity is an intermediate entity of the access network managing access to wired or radio resources, for example. One or more processing entities can be requested during the routing of the same data packet. The information necessary for triggering the differentiated processing is preserved in the data packet.

[0050] In an alternative embodiment, the announcement message further comprises a service identifier known to said at least one network, said service identifier being used by the relay entity to request said application server to determine whether the communication device is authorized to access the service.

[0051] This service identifier can be generated by the network during a ne- initial negotiation with the service platform / application server. Assigning such an identifier by the network ensures its uniqueness across the network. Alternatively, the service identifier is generated by the application server.

[0052] In an alternative embodiment, the configuration step comprises the transmission to said at least one processing entity of at least one traffic management policy corresponding to said level of service associated with the token to be applied to data packets relating to said service transmitted by or intended for said communication device.

[0053] This traffic management policy includes at least one element among: - a traffic classification rule;

[0054] - a priority indication;

[0055] - a preference to preempt resources;

[0056] - access to (pre)reserved resources;

[0057] - a marking based on the use of the Traffic Class or Flow Label fields of the IP packet headers.

[0058] The traffic management policy may have a limited duration.

[0059] In an alternative embodiment, the configuration method comprises:

[0060] - a step of receiving, from said application server, a notification deactivation of said token; and

[0061] - a step of updating the configuration of said at least one entity of processing to disable said processing corresponding to the service level associated with the token.

[0062] The configuration method is thus adapted to manage the case of a deactivation of the token and thus prevent the network from maintaining obsolete classification data (“stale”, in English) which would allow fraudulent entities to use network resources. Also, this makes it possible not to expose the network entities to denial of service attacks (of the buffer overflow or “memory overflow” type, typically).

[0063] Another object of the invention relates to a method of processing, by a so-called network processing entity, at least one data packet associated with a service transmitted by or intended for a communication device, said method comprising:

[0064] - a step of receiving an element of a configuration activated by a so-called entity network relay for the processing entity to apply processing to at least one data packet relating to said service intercepted by the processing entity and comprising a token generated for said communication device and a given access to said service via said network, said token being associated with a service level selected for this access to the service, said applied processing corresponding to said service level; and

[0065] - following an interception of a data packet relating to said service comprising said token, a step of applying said processing to said data packet responding to the said level of service associated with the token.

[0066] The processing entity is for example a node located at the edge of the network, such as an access router or an ASBR (Autonomous System Border Router). The operation of such a border node makes it possible to manage the case where the token inserted in the data packets does not correspond to the URSP (for "UE Route Selection Policy") classification rules. The border node then applies the processing associated with the service level designated by the token. It will be noted that the element of a configuration is for example a traffic classification rule. It will also be noted that the configuration method can be local to the border node or based on instructions communicated by a controller. It will also be noted that "intercept" means that the processing entity is on the path used for routing ("forwarding" in English) packets.

[0067] In an alternative embodiment, the intercepted data packet comprises a marking indication corresponding to a service level different from the service level associated with the token.

[0068] Thus, in the case where the service level corresponding to the marking indication is different from the service level associated with the token, the data packets are processed according to the instructions indicated by the token.

[0069] In an alternative embodiment, following the step of applying the processing to said data packet, the processing method comprises a step of removing said token contained in the data packet.

[0070] The ability to remove the token from the data packet introduces flexibility and allows for device-specific policies to be applied that would not necessarily reflect the information recorded in a Traffic Class or Flow Label field of an IP packet header. Such policies can thus be applied to a set of flows.

[0071] Another object of the invention relates to an application server comprising at least one module configured to implement a transmission to a communication device of a token generated for said communication device and a given access to a service via at least one network, said token being associated with a level of service selected for this access to said service, said token being capable of triggering, when it is contained in a data packet relating to said service exchanged via said at least one network, a processing of this data packet corresponding to said level of service by at least one entity called processing of said at least one network.

[0072] Thus, it is possible to manage on demand the differentiated processing of certain data packets sent to or by an application server. This optimizes the management of the connections of a communication device to the communication network and overcomes certain limitations imposed by the operating system (OS). of the communication device.

[0073] Another object of the invention relates to a communication device configured to access a service via at least one network, said communication device comprising at least one module configured to:

[0074] - receive a token from an application server associated with said service generated for said communication device and a given access to said service, said token being associated with a level of service selected for this access to said service, said token being capable of triggering, when it is contained in a data packet relating to said service exchanged via said at least one network, a processing of this data packet corresponding to said level of service by at least one so-called processing entity of said at least one network; and

[0075] - sending to a so-called relay entity of said at least one network, an announcement message of a use of said token by the communication device during said access to the service, said announcement message containing said token.

[0076] Thus, it is possible to manage on demand the differentiated processing of certain data packets sent to or by an application server. This optimizes the management of the connections of a communication device to the communication network and overcomes certain limitations imposed by the operating system of the communication device.

[0077] Another object of the invention relates to a relay entity comprising at least one module configured to:

[0078] - receive, from a communication device, an announcement message of a use by the communication device during a given access to a service via said network of a token contained in said announcement message, said token having been generated for said communication device and said access to the service, and being associated with a service level selected for said access to the service; and

[0079] - if the communication device is authorized to access the service, configure at at least one network entity called a network processing entity so that said processing entity implements processing corresponding to said service level associated with said token when this processing entity intercepts a data packet relating to the service containing said token.

[0080] The configuration of the network processing entity is carried out locally at the entity or according to the instructions communicated by a controller, in particular if the relay is hosted in said processing entity. The processing entity is typically a node located at the edge of the communication network, called an “edge node” and it applies traffic classification rules. Alternatively, this processing entity is an intermediate entity of the network, for example an entity of the access network managing access to radio resources or an entity of the core network.

[0081] Another object of the invention relates to a processing entity comprising at least one module configured to:

[0082] - receive a configuration instruction activated by a so-called “relay” entity of the network for the processing entity to apply a processing to at least one data packet relating to a service intercepted by the processing entity and comprising a token generated for a communication device and a given access to said service via said network, said token being associated with a service level selected for this access to the service, said applied processing corresponding to said service level; and

[0083] - following an interception of a data packet relating to said service comprising said token, apply to said data packet said processing corresponding to said level of service associated with the token.

[0084] The processing entity is for example an edge node such as an access router or an edge router. An edge node is configured to handle the case where the token inserted in the data packets does not match the URSP classification rules. The edge node then applies the processing associated with the service level as designated by the token. It will be noted that said configuration of the edge node consists for example of applying a traffic classification rule. It will also be noted that said configuration can be performed locally at the edge node according to declarative commands or reflect the configuration instructions communicated by a controller.

[0085] Another object of the invention relates to a computer program comprising program code instructions for executing the steps of a method of accessing a service via at least one network.

[0086] Another subject of the invention relates to a computer-readable recording medium on which is recorded a computer program comprising program code instructions for executing the steps of a method of accessing a service via at least one network, when said program is executed by a processor. Description of the figures

[0087] Other characteristics and advantages of the invention will appear during the reading of the detailed description which follows for the understanding of which reference will be made to the appended drawings in which:

[0088] [Fig.l] illustrates a simplified example of interactions between different blocks involved in the provision of a service according to the prior art;

[0089] [Fig.2] illustrates an example of a reference architecture according to the prior art, in which a communication device accesses services via a communication network which provides it with connectivity;

[0090] [Fig.3] illustrates an activation of a method of differentiated access to a service according to the invention;

[0091] [Fig.4] illustrates a system for implementing a differentiated access method according to the invention;

[0092] [Fig.5] illustrates a message used in the method of [Fig.4], said message comprising a new PCP (for “Port Control Protocol” in English) option for the implementation of said method;

[0093] [Fig.6] illustrates messages used in the method of [Fig.4], said messages comprising new PCP options for implementing said method;

[0094] [Fig.7] illustrates a mechanism for modifying a context at the initiative of an application server in the case of the embodiment of the invention of [Fig.4];

[0095] [Fig.8] illustrates an application server used in the system of [Fig.4];

[0096] [Fig.9] illustrates a communication device used in the system of the [Fig.4] ;

[0097] [Fig. 10] illustrates a relay entity used in the system of [Fig.4];

[0098] [Fig. 11] illustrates an entity participating in the differentiated treatment used in the system of [Fig.4].

[0099] Description of embodiments

[0100] [Fig.3] illustrates an activation of a service access method, subsequently called the AMIGOS method (for “Advanced Management of Innovation, Global, and truly Operational Services” in English), between a Network communication network and an AS application server.

[0101] Firstly, the communication network (for example via a network controller) and the application server AS dynamically negotiate the implementation of the access method via a dedicated network API called AMIGOS API. A dynamic negotiation protocol CPNP (for "Connectivity Provisioning Negotiation Protocol" according to the RFC8921 standard) is activated for example in order to expose the AMIGOS API. The communication network then exposes a CPNP server and the AS behaves like a CPNP client.

[0102] Other protocols may be used to expose this AMIGOS API such as the RESTCONF protocol according to the RFC8040 standard.

[0103] In [Fig.3], the AS sends a Subscribe () message to the communication network in order to subscribe to the AMIGOS service which makes it possible to manage on demand the differentiated processing of Data packets sent to or by the AS application server.

[0104] The subscription message contains at least one IP address to contact the AS. This IP address is encoded in a “Contact_Locator” field of the message. Alternatively, the subscription message also contains a port number. Alternatively, the “Contact_Locator” field may contain a domain name intended for be presented to a name resolution library (e.g. DNS) to retrieve an IP address and / or port number.

[0105] In addition, the subscription message contains descriptive information of the service level (field "service_level") desired by PAS for access to the service (more particularly, for the provision of the service via this network). The service level indicates a class of service. The service level may also include performance parameters (for example, latency must not exceed 20 ms), a level of security, resilience, etc. The service level may also include a type of slice, for example, a URLLC type slice.

[0106] In one embodiment, the service level is the subject of a detailed description, for example, in the form of a list of attributes which results from the combination of different parameters such as those mentioned above.

[0107] Alternatively, the service level is described according to a single reference. In this case, the association of this reference with a detailed list of parameters is assumed to be known to PAS and the network. This association is for example recorded in a service catalog, as described in document TS28.541 in its version 16.6.0 in particular, published by the 3GPP, and which describes the different types of slices and the associated quality of service parameters.

[0108] Following acceptance of the subscription request, the AMIGOS network API returns a service identifier "as_id" to unambiguously identify PAS. It also provides PAS with at least one range of IP addresses ("IP address range" in English) or IP prefixes of said communication network. In a particular embodiment, ranges by address families (IPv4 / IPv6) are recorded in a response to a subscription request as part of the negotiation based on the example of CPNP negotiation. This service identifier "as_id" is allocated by the network.

[0109] Alternatively, PAS itself generates the service identifier "as_id". In this case, a procedure to ensure that the service identifier "as_id" is globally unique is supported by PAS. This is not necessary if the service identifier "as_id" is generated by the network because the uniqueness must be local to that network only.

[0110] In another variant, the service identifier “as_id” is allocated by a third-party entity (for example PIANA (for “Internet Assigned Numbers Authority” in English)).

[0111] It is assumed here that PAS exposes a PCP (Port Control Protocol) server in accordance with RFC6887. Thus, the "Contact_Locator" field contains information for contacting the PAS PCP server such as an IP address, a domain name, a port number, etc.

[0112] The AMIGOS API may also be used to negotiate the insertion channel of the AMIGOS metadata considered when implementing the invention in the packets exchanged in the context of this service. Such metadata including in particular, as described in more detail later, an amigos_token. Optionally, the API also indicates whether the insertion must be carried out for all packets eligible for the service or only for a part of the packets. The other packets may be identified on the basis of a digest calculation of all or part of the metadata (for example of the amigos_token) to be compared with the digest calculated for packets which have valid metadata (in the example envisaged, a valid amigos_token).Typically, this channel is used in the context of the invention to insert AMIGOS marking information (and in particular the aforementioned amigos_token token) into the packets which transport the data sent from a service instance of the application server to a communication device reachable via this network but also from a communication device connected to this network which sends packets to a service instance of the application server.

[0113] It will now be noted that such an amigos_token token is used in the context of the invention to identify a differentiated treatment to be applied to satisfy the needs of the service, typically to satisfy a service level. The amigos_token token is thus more particularly associated with a service level service_level selected for access to the service by the communication device. It should be noted that the service level negotiated between an AS and a network may be defined to indicate a treatment class and not the precise treatment to be applied to the packets received or destined for an AS. For example, a treatment class may indicate a level of granularity of the differentiated treatment to be implemented (e.g. invocation of a malware inspection function or covered channels for all or part of the packets which present a valid token).

[0114] The AMIGOS API can also be used to indicate the population mode of amigos_token-based classification tables. For illustration, if an "unsolicited" mode is indicated, then PAS informs the network when a new amigos_token is provided to a communication device. If a "solicited" mode is indicated, the network must contact the AS to verify the authenticity of the token presented by the communication device.

[0115] The information exchanged during the negotiation / subscription procedure is recorded by the network in a table “AS_AMIGOS_SUBSCRIBERS” and by the AS in a table “NTW_AMIGOS_SUBSCRIPTIONS”.

[0116] [Fig.4] illustrates a system SYS for implementing a method of differentiated access to a service according to a first embodiment of the invention.

[0117] This SYS system includes here:

[0118] - a UE communication device;

[0119] - an amigos_relay relay entity, an AN, BR processing entity and a controller Controller network located in the Network communication network;

[0120] - the AS application server.

[0121] The communication device here is a “User Equipment” UE. It can be a mobile terminal or a fixed terminal. Alternatively, the communication device can be a service instance, a CPE (for “Customer Promises Equipment”), etc. No assumption is made as to the nature of the communication device.

[0122] The UE communication device embeds, in the embodiment described here, a PCP client as described in the IETF RFC 6887 document edited by D. Wing et al. entitled “Port Control Protocol (PCP)”, April 2013. A PCP client is a software structure which has the ability to generate PCP requests to a PCP server. Other protocols than PCP can be used (e.g., HTTP); thus the invention is not limited to the sole embodiment described here.

[0123] Furthermore, the communication device UE is adapted to be connected to at least one communication network. This communication network may be a 5G mobile network, a WLAN (for “Wireless Local Area Network”) wireless network or a fixed network.

[0124] The communication device UE comprises at least one module configured to receive an amigos_token from the application server AS and access the service. The communication device UE is also adapted to send to the relay entity amigos_relay an announcement message MAI) of the use of the amigos_token by this device when accessing the service. This announcement message MAI) comprises the amigos_token.

[0125] The communication network Network can support several network slices. A network can be organized into several distinct networks which compose as many domains (for example, a communication network can be composed of an access network, a collection network, a core network and a transit network). Each of these domains supports network slices whose engineering and operation are characteristic of the domain (for example, a slice deployed on a 5G mobile core network will use traffic processing and operating functions characteristic of a 5G mobile core network). Thus, each domain uses technologies which can be specific to this network for the creation of the network slices (for example, depending on the local engineering choices of a network operator).Slices in a mobile network (5G) could be based on the implementation of slices in the following different segments: Radio Access Network (RAN), Core Network (CN) and Transport Network (TN).

[0126] The realization of a network slice that extends over several domains is not conditioned by the availability or activation of the same technologies used for the realization of the slices "local" to each domain. For example, a first domain can set up IPsec tunnels that are used to route traffic in the slices deployed in this domain, while another domain uses network-level virtual private network engineering (Layer 3 VPN or L3VPN) combined with traffic engineering (TE, Traffic Engineering) mechanisms, while a third domain uses the resources of segment routing based on the IPv6 protocol (Segment Routing IPv6 or SRv6 in English) to route traffic in the slices deployed in this domain.

[0127] A network slice may involve one or more service functions according to the terminology used by RFC7665, or “Network Functions” such as gNB (“gNodeB”) or UPF (“User Plane Function”) according to the terminology used by 3GPP). The same service function may be provided by one or more service instances.

[0128] A service instance may be hosted by the SSP (Slice Service Provider) or within another infrastructure.

[0129] Service chains (or Service Function Chains (SFCs) in English) can be set up in order to facilitate the routing of traffic of different nature and presenting different profiles for the needs of the realization of a slice or within a slice.

[0130] [Fig.4] also illustrates the implementation of the differentiated access method to a service in the situation of a communication network supporting three network slices T1, T2, T3 represented schematically by tubes. In this context, differentiated processing consists of associating certain messages with these slices T1, T2, T3.

[0131] It will be noted that the communication device is here adapted to negotiate with each SSP to which it is connected a list of slices that it is likely to use to send or receive traffic. For each slice, its type is also negotiated between the communication device and the network. Alternatively, network slice identifiers or suitable markers (“tags”, which are not identifiers actually used for marking the data of a slice but for classification purposes) are also communicated by the network to the communication device.

[0132] In the communication network Network of [Fig.4]:

[0133] - the relay entity comprises at least one PCP relay also called PCP Proxy or AMIGOS_relay;

[0134] - the processing entity comprises an access router AN (for “Access Network”) in English) and at least one border router BR (for "Border Router" in English).

[0135] The PCP relay is adapted to receive PCP requests from one or more PCP client(s) of the UE communication device. This relay is compatible with the RFC 7648 standard published in September 2015. It has the function of PCP request relay. This relay can be located with a CGN function (for "Carrier Grade NAT", for example a CGN NAT64 (Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers, RFC6146 published in April 2011), a firewall, an IPv6 prefix translation function NPTv6 (IPv6-toIPv6 Network Prefix Translation, RFC6296 published in June 2011). The relay processes the external address indicated in the relayed PCP messages according to the mechanism described in Section 3.3 of RFC 7648 (Port Control Protocol Proxy Function) published in September 2015.

[0136] The relay is configured with rules that make it possible to control the processing scope of a request sent by the UE communication device, whether such a request can be processed locally by the first relay requested by the UE communication device or whether it must be transmitted to another PCP server. Such rules may, for example, reflect the organization set up for the engineering of the AMIGOS service. They may be based on a regionalization principle that requires requesting a “national” PCP server that is the only one authorized to serve certain requests that would make it possible to benefit from an AMIGOS service in the case of an AS located in certain border regions of the network.

[0137] The PCP relay has a network slice manager function for routing Data packets via the network slice, which is chosen according to the required service level.

[0138] In a first mode, the communication device is configured by the communication network with the relay information. For this purpose, at least one IP address, one port number and one authentication identifier (ADN for "Authentication Domain Name" in English) to reach the relay are configured. The network configuration can use the resources of a dedicated protocol such as DHCP (for "Dynamic Host Configuration Protocol" in English) or an RA message (Router Advertisement message in an IPv6 environment).

[0139] In a second mode, the communication device uses an anycast or multicast address to send a discovery message (DISCOVER()). If an AMIGOS relay is available, it responds with an ACK message (IP Address(es), port number, ADN).

[0140] In a third mode, the communication device uses a SUDN domain name (Special-Use Domain Names RFC6761 published in February 2013) and then carries out SVCB resolutions (“Service binding and parameter specification via the DNS”, RFC 9460 published in November 2023) associated with this specific name. A new SvcParam, called "amigos" can be set to indicate support for the AMIGOS procedure.

[0141] The access router AN is deployed at the edge of the communication network Network. It comprises traffic classification and admission control rules for managing exchanges of data packets Data between the communication device UE and the communication network Network. The router AN is adapted to select, in a non-limiting exemplary embodiment, a network slice adapted to transmit the data packets sent by the communication device UE to an AS server.

[0142] The border router BR is deployed at the edge of the communication network Network. It applies traffic classification and admission control rules to manage exchanges of data packets Data between the communication network Network and an SFI instance of the application server AS (directly or indirectly via another interconnection network).

[0143] The access router AN and the border router BR are network entities that are involved in the differentiated processing of traffic. Each AN and BR router comprises at least one module configured to receive configuration instructions activated by the amigos_relay entity. Each router is adapted to apply a processing to at least one data packet Data comprising an amigos_token. This processing corresponds to the service level service_level associated with the amigos_token.

[0144] The Controller is arranged in the communication network NETWORK between the router AN and the router BR. It is adapted to transmit (including to update) the traffic classification rules in said router AN and said router BR. This controller is, for example, an SDN (Software-Defined Networking) controller.

[0145] Note that the traffic classification rules are instantiated for the validity period indicated by the PCP relay or by a PCP server belonging to the AS application server. The lifetime can also be controlled by a default value selected by the network operator.

[0146] The AS application server is a server adapted to enable the installation, operation and hosting of services. This AS application server comprises:

[0147] - the PCP server;

[0148] - at least one SFI instance.

[0149] The PCP server is adapted to exchange PCP requests with the PCP Proxy of the communication network.

[0150] The SFI (Service Function Instance) is involved in providing the service exposed by the AS. It is adapted to communicate with the PCP client of the UE communication device according to the PCP protocol. It is also suitable for exchanging Data packets with the UE communication device.

[0151] The PCP server and the at least one SFI instance make it possible to implement a transmission of the amigos_token token to the UE communication device for a given access to the service via the Network.

[0152] It will be noted here that the AS application server is the same server as the AS application server of [Fig.3] managing the subscription to the AMIGOS service. Alternatively, the AS application server of [Fig.4] is different from the application server of [Fig.3]. These application servers can then form two separate entities. Alternatively, these application servers are co-located, or it is possible to envisage having two service instances of the same application server.

[0153] [Fig.4] also illustrates the implementation of a process for differentiated access to a service.

[0154] In a first step, the communication device UE establishes a communication with the application server AS. More precisely, it is an application client embedded in the communication device UE which establishes this connection with the SFI instance of the AS. To establish this communication, the communication device UE sends a Req message to access a service. This message includes a source address associated with the communication device UE.

[0155] In a second step, upon receipt of this Req message, the application server AS extracts the source address of the packet and then consults the table "NTW_AMIGOS_SUBSCRIPTIONS" to check whether the UE communication device is eligible for differentiated access for a service. To this end, the SFI instance checks that the source address extracted from the Req message corresponds to an IP range in said table. If this is the case, said SFI instance sends a message to the communication device in response to its initial request with, in the embodiment described here, the following information elements:

[0156] - a service identifier as_id known to the network. This identifier is associated with the AS such that is entered in the “NTW_AMIGOS_SUBSCRIPTIONS” table and it corresponds to the known identifier of the network to which the communication device is connected;

[0157] - an identifier ue_id selected by the application server AS for the device of UE communication. Alternatively, this identifier may be generated by an entity other than the AS, for example an entity responsible for managing the connections of all terminals to the AS, all service instances combined. In another variant, the identifier is generated per service connection / session. In this case, a new identifier is allocated to each connection to the service even if the same external IP address is used to reach the service by the same communication device communication. This variant is, for example, motivated by the nature of the service, such as a transactional service.

[0158] - the service_level information which indicates the level of the service selected for the communication device. This information is maintained in the “NTW_AMIGOS_SUBSCRIPTIONS” table;

[0159] - an amigos_token, as described above, and intended to be inserted into packets sent by or to the UE. As already specified, this token is used to identify packets eligible for a service level corresponding to the “service_level” information in the communication network to which the communication device is connected. It is generated for the communication device and for a given access to the service via the network (in the embodiment described here, following receipt of the service access Req message sent by the communication device). This token is associated with a service level selected for this access. Thus, the token can introduce a certain granularity with respect to the “service_level” information making it possible to select a service level for the specific access to the service by the communication device.Other information, such as the channel negotiated with the communication network for the insertion of the AMIGOS metadata, and in particular the amigos_token token, may be communicated to the communication device in the response message as well as indications specifying whether the insertion must be carried out in all or part of the data packets.

[0160] Furthermore, it is noted that in order to optimize access to the service, in a particular embodiment, PAS (and more particularly its SFI instance) can communicate to the communication device UE, during a first access to the service, a list of tokens to be used for future accesses to the service. This embodiment makes it possible to apply differentiated processing even to the request for access to the service sent by the communication device UE.

[0161] The SFI instance records the descriptive information of the connection (for example: 4-tuple for TCP, QUIC connection identifier) ​​as well as the information sent to the UE. This information is recorded in a table called here ASAAC for AS_ACTIVE_AMIGOS_CONTEXTS. If the "unsolicited" mode is activated for this network, PAS informs the PCP relay of said network of the activation of the amigos_token for this communication.

[0162] Upon receipt of the information elements (“amigos_token”, “as_id”, “ue_id”, “service_level”, etc.) by the communication device, the APP#i application verifies whether an API exposed by the OS allows this information to be communicated to the OS for the purposes of classifying traffic associated with a service level.

[0163] If the API exposed by the OS actually allows the transmission of this information, This API is used to negotiate traffic classification by exploiting the information returned by the service instance. The API is then responsible for performing the checks and executing the operations described below for the APP#i application.

[0164] If the API exposed by the OS does not allow the transfer of this information, the APP#i application sends, via the PCP client, the Mad announcement message of the use of the amigos_token token, to the AMIGOS relay associated with the communication network (this relay is already configured by the network or discovered by the horn device described previously). This announcement message corresponds to a PCP request. The Mad announcement message can be a MAP or PEER message. In addition to a FILTER option, as described in Section 13.3 of RFC6887, the Mad announcement message contains, in a particular embodiment, an option called here SLICE_CLASS, as described in [Fig.5]. The FILTER option aims to only allow the sending of messages to the service instance to benefit from the AMIGOS service.The SLICE_CLASS option contains the information elements returned by the SFi service instance (“amigos_token”, “as_id”, “ue_id”, “service_level”, ...).

[0165] Alternatively, multiple PCP options may be defined as illustrated in [Fig.6]. Each of these options includes one information element from the list ("amigos_token", "as_id", "ue_id", and "service_level"). Other forms of encoding may be considered.

[0166] The PCP client of the UE communication device and the PCP Proxy of the AMIGOS relay authenticate each other. In particular, the PCP client uses the ADN parameter to authenticate said PCP Proxy and prevent the data from being intercepted by a malicious entity. The PCP Proxy authenticates the PCP client on the basis of information enriched by the communication network (for example the MSISDN number (for "Mobile Station International Subscriber Directory Number" in English), the internal IP address to which the communication device connects, a certificate presented by a communication device.

[0167] The AMIGOS relay consults the table “AS_AMIGOS_SUBSCRIBERS” to check whether the AS identified by the service identifier “as_id”, as communicated by the communication device, has subscribed to the AMIGOS service.

[0168] If an entry is found and the "unsolicited" mode is activated by this AS identified by "as_id", the AMIGOS relay checks whether a classification entry matches an "amigos_token" token communicated by the AS. If an entry is found, the AMIGOS relay sends a "SUCCESS" message to the communication device to confirm the establishment of a context (i.e. a state that allows classification to be carried out and thus triggers differentiated processing on packets that match the classification rules ("match", in English)). The communication device The communication UE can then mark the traffic eligible for the AMIGOS service using the token "amigos_token". If no entry is found, then an error message ("NOT_AUTHORIZED") is sent to the communication device. Requests from this communication device can be limited (via a "rate-limit" parameter) and optionally, the AMIGOS relay sends an alert message to a dedicated platform. In the following, it is assumed that the "solicited" mode is enabled.

[0169] If the “solicited” mode is activated, the AMIGOS relay retrieves the information allowing access to the PCP server associated with this AS (i.e., those recorded in the “Contact_Locator” attribute exchanged during the CPNP negotiation).

[0170] The initial request from the UE communication device is then sent by the AMIGOS relay to this server. The information contained in the request is adjusted by the relay (e.g., the internal address of the PCP client, removal of FILTER options, or removal of the "as_id" information).

[0171] Upon receipt of the request by the PCP server associated with PAS, the PCP server checks whether a context that matches the information contained in the PCP request is maintained in the ASAAC table.

[0172] If an entry is found, then a positive response ("SUCCESS") is sent to the relay to confirm this entry. The message indicates a validity period for this entry.

[0173] If no entry is found, then an error message (“NOT_AUTHORIZED”) is sent to the AMIGOS relay. Upon receipt of this message, the AMIGOS relay rejects the request from the UE communication device. Requests from this communication device can be limited (via a “rate-limit” parameter) and optionally, the relay sends an alert message to a dedicated platform.

[0174] Upon receipt of the “SUCCESS” message by the AMIGOS relay, it proceeds as follows.

[0175] It sends the message “SUCCESS” to the UE communication device to confirm the establishment of the context. The UE communication device can then mark the traffic eligible for the AMIGOS service using the token “amigos_token”.

[0176] The AMIGOS relay further installs at least one rule so that the traffic received from or destined for the UE communication device containing the amigos_token is processed according to the service level defined by the “service_level” parameter and selected for access to the service by the UE communication device. One or more rules may be installed in the network. These rules may be IP rules, radio rules, etc. The service level applied to the traffic of the UE communication device is thus defined by the indications conveyed by the token, and incidentally by the indications provided by the AMIGOS relay in the rules installed in the network intended to be applied by the network elements involved in processing the traffic of the UE communication device carrying the amigos_token. The exchange of Data packets can then take place between the UE communication device and the AS application server via the AN router and the BN router.

[0177] [Fig.7] illustrates a mechanism for modifying a context at the initiative of the application server in the case of the first embodiment of the invention of [Fig.4].

[0178] The PCP server can modify the context for the communication device. To do this, it sends an "ANNOUNCE" message to the PCP Proxy associated with a context stored in the ASAAC table, to update the corresponding entry. The PCP Proxy transmits this information to the Controller. The Controller then causes the relevant network entities, typically the AN and BR routers, to modify the various traffic classification rules.

[0179] With reference to [Fig.7], the modification is a deletion of the context for the UE communication device. The traffic emitted by this communication device with an “amigos_token” marking will then no longer be processed under the AMIGOS service as negotiated between the Network communication network and the AS application server. Concretely, the traffic presented with an expired AMIGOS token is processed according to a basic mode (“by default”) and therefore does not benefit from differentiated treatment.

[0180] The UE communication device may also participate in maintaining the PCP entry in the PCP Proxy in accordance with the validity period decreed by the SFI service instance. In the absence of refresh messages before the expiry of this validity period of the corresponding PCP entry, the classification rules of the traffic exchanged between the UE communication device and the SFI service instance in question will be deleted. The communication device may delete the context when the service session is closed.

[0181] In an alternative embodiment, the PCP entry is maintained even if the session has been closed. The advantage of this mode is to optimize the session establishment time when the communication device reconnects to the service during a time interval chosen by the service.

[0182] In the event of a modification of the external address of the communication device (by the UE or by a network element), this modification is notified to the PCP server by the PCP Proxy to update the traffic classification rules which will take into account the new external address where appropriate:

[0183] If the transport protocol used by the service allows the session to be maintained even if the IP address or port number changes (as in the case of the QUIC protocol specified in the RFC 9000 standard in its May 2021 publication), then the communication device does not need to close the current connection or establish a new connection (service continuity context). Otherwise, a new connection is established with the service instance. The AS application server can then maintain the same communication device identifier ("ue_id") even if the external IP address changes or not. This decision is local to each AS server.

[0184] In an alternative embodiment, the PCP procedure is performed during a first connection of the communication device to a service instance, and not per service session.

[0185] In another variant embodiment, if the communication device is located behind equipment such as a CPE, then the user terminal contacts the edge node to set up PCP rules managed by the PCP Proxy embedded in the CPE.

[0186] [Fig.8] illustrates an AS application server for service management, as used in the SYS system of [Fig.4].

[0187] This AS application server includes:

[0188] - at least one input / output interface E / SAs;

[0189] - a MemAS storage memory;

[0190] - a ProcAS processor.

[0191] The at least one input / output interface E / Sas is adapted to transmit to the communication device UE the amigos_token token generated for the communication device and a given access to a service via at least the Network network. As already specified, the amigos_token token is associated with the service level ("service_level" in English) selected for this access to the service. The amigos_token token is capable of triggering, when it is contained in a data packet relating to said service exchanged via the Network network. The processing of this data packet by at least one processing entity AN, BR corresponds to the ad hoc service level.

[0192] The storage memory MemASest is adapted to store information such as the amigos-token, the service level service_level associated with this token, the identifier “ue_id” of the communication device UE, the service identifier as_id.

[0193] The ProcAS processor is adapted to implement the steps of a method for managing a service by the application server AS. This management method comprises the step of transmitting to the communication device UE the amigos_token token generated by the communication device UE for a given access to the service via the network.

[0194] This management method further comprises a step of providing the information of verification that the UE communication device is authorized to access the service using the token. This verification information includes the amigos_token and the ue_id of the UE communication device. Alternatively, the verification information includes a SUCCESS confirmation that the UE communication device is authorized to access the service using the amigos_token.

[0195] The transmission step of the management method further comprises the transmission of an indication representative of the channel carried by the data packet Data in which the amigos_token token must be contained to trigger the processing of this packet.

[0196] The transmission step further comprises the transmission of at least one element such as the service identifier known to the network, the identifier ue_id selected by the application server AS for the communication device UE or the information representative of the service level service_level.

[0197] The management method further comprises the step of sending at least one data packet Data relating to the service to the communication device UE containing the amigos_token token.

[0198] The management method also comprises a step of deactivating the amigos_token token and a step of notifying at least one entity of the network (amigos_relay or controller) of this deactivation.

[0199] [Fig.9] illustrates a UE communication device as used in the system SYS of [Fig.4],

[0200] This UE communication device comprises:

[0201] - at least one input / output interface E / Sue;

[0202] - a storage memory MemUE;

[0203] - a ProcUE processor.

[0204] The at least one input / output interface E / Sue is adapted to receive from the application server AS associated with the service the amigos_token token generated for the communication device UE. This interface E / Sue is also adapted to send to the amigos_relay entity the Mad announcement message of a use of the amigos_token token by the communication device UE when accessing the service.

[0205] The storage memory MemUE is adapted to store information such as the amigos-token, the service level service_level associated with this token, the identifier ue_id of the communication device UE, the service identifier as_id.

[0206] The processor ProcUE is adapted to implement the steps of a method of accessing the service via the network. This access method comprises the step of receiving the amigos_token token and sending the Mad announcement message to the relay entity amigos_relay.

[0207] The access method further comprises a step of inserting the amigos_token token in a data packet relating to the service.

[0208] [Fig. 10] illustrates an amigos_relay relay entity as used in the SYS system of [Fig.4],

[0209] This relay entity includes:

[0210] - at least one input / output interface E / Sreiay;

[0211] - a storage memory Memæiay;

[0212] - a Procreiay processor.

[0213] The at least one input / output interface E / Sreiay is adapted to receive the Mad announcement message and to configure at least one processing entity of the AN, BR network.

[0214] The storage memory Memreiayest is adapted to store the announcement message Mad.

[0215] The Procreiay processor is adapted to implement a configuration method of at least one processing entity of the AN, BR network by the relay entity amigos_relay. This method comprises a step of receiving the Mad announcement message and a configuration step from the information contained in this Mad announcement message.

[0216] The Mad announcement message further comprises the service identifier used by the relay entity to request the application server to determine whether the communication device is authorized to access the service.

[0217] The configuration step further comprises transmitting a traffic management policy corresponding to the service level associated with the token.

[0218] The configuration method further comprises a step of receiving a notification of deactivation of the token from the application server AS and a step of updating the configuration to deactivate the processing corresponding to the service level associated with the token.

[0219] [Fig. 11] illustrates a network entity participating in differentiated processing. In the example of [Fig. 11], this network entity is the AN access router as used in the SYS system of [Fig. 4].

[0220] This AN access router includes:

[0221] - at least one E / San input / output interface;

[0222] - a storage memory Mem^;

[0223] - a ProcAX processor.

[0224] The at least one input / output interface E / San is adapted to receive the configuration instructions implemented by the relay entity amigos_relay so that the access router AN applies a processing to at least one data packet Data relating to the service intercepted by this router.

[0225] The storage memory MemAN is adapted to store the configuration element. This configuration element is, for example, a traffic classification rule.

[0226] The ProcAN processor is adapted to implement a method for processing at least one data packet Data associated with the service sent by or intended for the device. UE communication. This processing method comprises a step of receiving the configuration instructions implemented by the relay entity amigos_relay and a step of processing the Data packet according to the service level associated with the token.

[0227] The intercepted data packet may include a marking indication corresponding to a service level different from the service level associated with the token. In this case, the processing associated with the token is applied.

[0228] Following the step of applying the processing of the data packet, the processing method comprises a step of removing the token contained in the Data packet. Alternatively, the token is retained in the data packet. The possibility of retaining or removing the token from the data packet introduces a certain flexibility and makes it possible to trigger the application of device-specific policies that would not be triggered according to the information recorded in a Traffic Class or Flow Label field of an IP packet header, for example. Such device-specific policies can advantageously be applied to a set of data flows (also called aggregates) and not per flow transmitted or received by the communication device.

[0229] It should be noted that the differentiated processing is not only that activated locally in a processing entity but can cover the entire path used for the routing (“forwarding” in English) of traffic within a network.

[0230] The description of [Fig.l 1] also applies to the border router BR of [Fig.4],

Claims

Claims

1. Method for managing a service by an application server (AS), said method comprising a step of transmitting to a communication device (UE) a token (amigos_token) generated for said communication device and a given access to a service via at least one network (Network), said token (amigos_token) being associated with a service level (service_level) selected for this access to said service, said token (amigos_token) being capable of triggering, when it is contained in a data packet (Data) relating to said service exchanged via said at least one network (Network), a processing of this data packet (Data) corresponding to said service level (service_level) by at least one entity (AN, BR) called processing of said at least one network (Network).

2. Management method according to claim 1, further comprising a step of providing at least one verification information to a so-called relay entity (amigos_relay) of said at least one network allowing said relay entity (Relay amigos_relay) to verify that said communication device (UE) is authorized to access said service using said token (amigos_token).

3. Management method according to claim 2, wherein said at least one verification information comprises: - said token (amigos_token) and an identifier (ue_id) of said communication device (UE) allocated by the application server; or - a confirmation (SUCCESS) that said communication device (UE) is authorized to access said service using said token (amigos_token).

4. Management method according to any one of claims 1 to 3, in which the transmission step further comprises the transmission of an indication representative of a channel carried by the data packet (Data) in which said token (amigos_token) must be contained to trigger said processing.

5. Management method according to any one of claims 1 to 4, wherein the transmitting step further comprises transmitting at least one element from: - a service identifier (as_id) known to said at least one network; - an identifier (ue_id) selected by said application server (AS) for said communication device (UE); and - information representative of said service level (service_level).

6. Management method according to any one of claims 1 to 5, further comprising a step of sending at least one data packet (Data) relating to said service to said communication device (UE) containing said at least one token (amigos_token).

7. Management method according to any one of claims 1 to 6 comprising: - a step of deactivating said token (amigos_token); and - a step of notifying at least one entity (amigos_relay; Controller) of said network of said deactivation.

8. Method for accessing, by a communication device (UE), a service via at least one network (Network), said method comprising: - a step of receiving from an application server (AS) associated with said service a token (amigos_token) generated for said communication device (UE) and a given access to said service, said token (amigos_token) being associated with a service level (service_level) selected for this access to said service, said token (amigos_token) being capable of triggering, when it is contained in a data packet (Data) relating to said service exchanged via said at least one network (Network), a processing of this data packet (Data) corresponding to said service level by at least one entity (AN, BR) called processing of said at least one network (Network);and - a step of sending to an entity (amigos_relay) called a relay of said at least one network (Network), an announcement message (Mad) of a use of said token (amigos_token) by the communication device (UE) during said access to the service, said announcement message containing said token (amigos_token).;

9. Access method according to claim 8 further comprising, following receipt of a confirmation from the relay entity (Relais amigos) of said use, a step of inserting the token (amigos_token) into at least one data packet (Data) relating to said service emitted by the communication device (UE) during said given access to the service.

10. Method of configuration by an entity (amigos_relay) called a relay of a network, said method comprising: - a step of receiving, from a communication device (UE), a message announcing a use by the communication device (UE) during a given access to the service via said network of a token (AN, BR) contained in said announcement message (Mad ), said token (amigos_token) having been generated for said communication device and said access to the service, and being associated with a service level (service_level) selected for said access to the service; and - if the communication device (UE) is authorized to access the service, a step of configuring at least one entity (AN, BR) called network processing entity so that said processing entity (AN, BR) implements a processing corresponding to said service level (service_level) associated with said token (amigos_token) when this processing entity (AN, BR) intercepts a data packet (Data) relating to the service containing said token (amigos_token).

11. A configuration method according to claim 10, wherein said announcement message further comprises a service identifier (as_id) known to said at least one network (Network), said service identifier being used by the relay entity (amigos_relay) to request said application server (AS) to determine whether the communication device (UE) is authorized to access the service.

12. Configuration method according to claim 10 or 11, wherein the configuration step comprises transmitting to said at least one processing entity (AN, BR) at least one traffic management policy corresponding to said service level (service_level) associated with the token (amigos_token) to be applied to data packets (Data) relating to said service transmitted by or intended for said communication device (UE).

13. Configuration method according to any one of claims 10 to 12 comprising: - a step of receiving, from said application server (AS), a notification of deactivation of said token (amigos_token); and - a step of updating the configuration of said at least one processing entity (AN, BR) to deactivate said processing corresponding to the service level (service_level) associated with the token (amigos_token).

14. Method for processing, by a so-called network processing entity (AN, BR), at least one data packet (Data) associated with a service sent by or intended for a communication device (UE), said method comprising: - a step of receiving an element of a configuration activated by an entity (amigos_relay) called a network relay (Network) so that the processing entity (AN, BR) applies processing to at least one data packet (Data) relating to said service intercepted by the processing entity (AN, BR) and comprising a token (amigos_token) generated for said communication device (UE) and a given access to said service via said network, said token (amigos_token) being associated with a service level (service_level) selected for this access to the service, said applied processing corresponding to said service level (service_level); and - following an interception of a data packet (Data) relating to said service comprising said token (amigos_token), a step of applying to said data packet (Data) said processing corresponding to said service level (service_level) associated with the token (amigos_token).

15. A processing method according to claim 14, wherein said intercepted data packet comprises a marking indication corresponding to a service level different from the service level associated (service_level) with the token (amigos_token).

16. Processing method according to claim 14 or 15, comprising, following the step of applying the processing to said data packet, a step of removing said token (amigos_token) contained in the data packet.

17. Application server (AS) comprising at least one module configured to implement a transmission to a communication device (UE) of a token (amigos_token) generated for said communication device and a given access to a service via at least one network (Network), said token (amigos_token) being associated with a service level (service_level) selected for this access to said service, said token (amigos_token) being capable of triggering, when it is contained in a data packet (Data) relating to said service exchanged via said at least one network (Network), a processing of this data packet (Data) corresponding to said service level (service_level) by at least one entity (AN, BR) called processing of said at least one network (Network).

18. Communication device configured to access a service via at least one network (Network), said communication device (UE) comprising at least one module configured to: - receive from an application server (AS) associated with said service a token (amigos_token) generated for said communication device (UE) and a given access to said service, said token (amigos_token) being associated with a service level (service_level) se- selected for this access to said service, said token (amigos_token) being capable of triggering, when it is contained in a data packet relating to said service exchanged via said at least one network (Network), a processing of this data packet) corresponding to said level of service by at least one entity (AN, BR) called processing of said at least one network (Network); and - send to an entity (amigos_relay) called a relay of said at least one network (Network), an announcement message of use of said token (amigos_token) by the communication device (UE) during said access to the service, said announcement message containing said token (amigos_token).

19. Relay entity of a network (amigos_relay) comprising at least one module configured to: - receiving, from a communication device (UE), an announcement message of a use by the communication device (UE) during a given access to a service via said network of a token (AN, BR) contained in said announcement message, said token (amigos_token) having been generated for said communication device and said access to the service, and being associated with a service level (service_level) selected for said access to the service; and - following an authorization received for the communication device (UE) from an application server (AS) associated with said service, configure at least one entity (AN, BR) called network processing so that said processing entity (AN, BR) implements a processing corresponding to said service level (service_level) associated with said token (amigos_token) when this processing entity (AN, BR) intercepts a data packet (Data) relating to the service containing said token (AN, BR).

20. A network processing entity comprising at least one module configured to: - receive an element of a configuration activated by an entity (amigos_relay) called a network relay (Network) so that the processing entity (AN, BR) applies a processing to at least one data packet (Data) relating to a service intercepted by the processing entity (AN, BR) and comprising a token (amigos_token) generated for a communication device (UE) and a given access to said service via said network, said token (amigos_token) being associated with a service level (service_level) selected for this access to the service, said applied treatment corresponding to said service level (service_level); and - following interception of a data packet (Data) relating to said service comprising said token (amigos_token), apply to said data packet (Data) said processing corresponding to said service level (service_level) associated with the token (amigos_token).

Images