PROCEDURE FOR MANAGING A REQUEST TO ACTIVATE A PACKAGE DATA SESSION FOR A END DEVICE

Description

Technical field

[0001] The invention lies in communication networks, and in particular in networks in which network slices are instantiated, allowing network equipment / functions / configurations to be dedicated to specific services and / or specific clients and / or specific terminals.

[0002] The invention is aimed more particularly at managing requests, from a user terminal, to activate a packet data session for a slice of such a network. Prior art

[0003] Some network architectures specified and deployed today are structured into network slices, allowing a user terminal, depending on the user's subscription, to benefit from specific functions (routing, processing, administration, etc.) adapted to one or more criteria such as terminal type, application type, access type, and so on. Thus, each slice provides a level of quality of service and security in accordance with one or more of the criteria mentioned above. It should also be noted that clients and terminals are increasingly diverse (IoT terminals, smartphones, robots, a variety of so-called communicating devices, etc.) and have quite different capabilities and needs.This evolution is further accompanied by the ability of at least some of these devices to access, simultaneously or not, a plurality of applications whose data may be routed over separate network segments. It should be noted that these developments apply to both fixed and mobile networks, and that the specifications for so-called fifth-generation (5G) networks incorporate this network segmentation.

[0004] According to the 5G network specifications, which will be the primary reference in this description, a user terminal locally stores the identifiers of the S-NSSAI (Single-Network Slice Selection Assistance Information) slices to which the user has subscribed (the subscribed S-NSSAIs are referenced in a data entry called Configured NSSAI). The user terminal also stores the identifiers of slices for which the terminal is authorized by the network, specifically via an AMF (Access and Mobility Function) entity, in a data entry called Allowed NSSAI, containing all or part of the subscribed S-NSSAIs. The user terminal also stores the identifiers of slices for which it is prohibited (by the network) in a data entry called Rejected NSSAI.These allowed / rejected slice identifiers are received by the terminal in the network's acceptance response during its registration procedure with the network.

[0005] Similarly, a network device stores context information associated with the user terminal (in English, UE Context), during the registration procedure, this context information containing in particular the identifiers of authorized slices (Allowed NSSAI) as well as a registration state of the user terminal (in English, RM State).

[0006] It can be noted that there is no consistency between the information stored at the terminal level and that stored at the network level, the rejected slice identifiers (Rejected NSSAI) for example not being stored at the network level, and the user terminal context information (UE Context) not being stored at the user terminal level.

[0007] Furthermore, during a subsequent registration, the user terminal first analyzes the Rejected NSSAI identifiers to avoid requesting registration for a slice rejected during the previous registration, for the same access type and registration area. Then, when activating a packet data session (PDU session for 5G, where PDU stands for Protocol Data Unit), the user terminal analyzes the Allowed NSSAI identifiers to activate PDU sessions only for authorized slices. Thus, according to the current specifications, the user terminal cannot activate a packet data session on a slice not present among the previously authorized slices.

[0008] Furthermore, when a packet data session is activated, the network, via an entity designated SMF (Session Management Function), checks the validity of the packet data session activation request against its local policy and the subscription rights associated with the user. However, the SMF does not check whether the requested bandwidth is authorized for the current access type and registration zone, as this check is performed at the time of registration by the aforementioned AMF network entity.

[0009] Thus, the use of slice information is also inconsistent, with some stored information never being used at the time of packet data session activation, such as the identifiers of allowed or rejected slices stored at the network level.

[0010] The specifications rely on correct terminal-level processing (to choose the slices to request in the registration request or an authorized slice to request in the packet data session activation request) and do not, for example, address the case of a misconfigured or misused user terminal requesting the activation of a packet data session for a slice that was not authorized during the registration procedure.

[0011] Furthermore, it is possible, according to the state of the art, that the use of a slice is actually authorized for the user terminal but that the network is not aware of it when it receives the request to activate a packet data session because the registration has not been done beforehand for that slice (the slices allowed / rejected are determined by the network during the registration procedure, from among the slices requested by the user terminal in its registration request).

[0012] The documents "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 15)", , vol. SA WG2, no. V15.12.0 December 17, 2020 (2020-12-17), pages 1-365, XP051999817, and "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16)", , March 20, 2020 (2020-03-20), XP051867360, form part of the relevant state of the art.

[0013] The main drawbacks of current specifications and techniques therefore lie in the fact that information relating to network slices, stored by the network and / or user equipment, is not all taken into account by the network, resulting in both unnecessary storage, insufficient control of slice usage and a limitation in uses by non-use of information which is nevertheless accessible.

[0014] There is therefore a need for a technique enabling better management of network slice information both at the user equipment level and at the network level, while allowing applicability in 5G as well as any future generation of networks using a structured network slice architecture. Exposition of the invention

[0015] The invention addresses this need by proposing a method for managing requests to activate a packet data session for a user terminal capable of sending and receiving data on a communications network organized into network slices, the user terminal including a subscription identifier for at least one of the network slices, the method being implemented by at least one network device, and comprising: a reception of a request to activate a packet data session from the user terminal for a slice of the network, the activation request including an identifier of the requested slice, obtained from a parameter including one or more identifiers of slice(s) subscribed to by the user, the activation request being independent of an authorization or rejection of the requested slice (Sli) determined during the registration of the user terminal with the network; an acquisition, from the subscription identifier, of at least one piece of information allowing the determination of an authorization of the requested slice; a verification of the authorization of the requested slice taking into account the at least one piece of information allowing the determination of an authorization of the requested slice obtained and, if the verification is negative, a rejection of the request to activate a packet data session for the requested slice.

[0016] Thus, the present technique is based on a completely new and inventive approach to the packet data session activation procedure for a user terminal within a communication network slice. It consists of performing an authorization check for a requested slice, and, if necessary, authenticating the requested slice, upon receipt of the packet data session activation request. In certain implementations, it eliminates the need for the authorization test required during the prior network registration procedure in prior art techniques. Furthermore, the authorization check is performed for only one slice, for which the user terminal has issued a packet data session activation request, and no longer for one or more slices as is the case when registering a user terminal according to prior art.

[0017] This approach allows, in particular, for a simplified user terminal registration procedure during which no slice authorization check is performed, either by the user equipment or by the network. This eliminates, in a first implementation, the need to store certain information relating to the slices that the user equipment wishes to access. Furthermore, by not managing this slice authorization information associated with a user device, particularly at the network level, the network, and specifically the access control equipment (for example, the Access and Mobility Management Function, according to the applicable standard), can receive and process more requests from a greater number of user devices.

[0018] Indeed, according to current specifications and previous technology, a user device cannot request a packet data session activation without first verifying that the desired slice has been authorized during a prior registration procedure. To do this, it must store this slice authorization / rejection information. Similarly, on the network side, a check must be performed regarding the authorization of each slice that a user device might potentially access, based on the user terminal's location at the time of its registration request. Therefore, the network must also inform the user device of any change in the state of a slice based on the user device's current location.All these steps and all these storages not carried out thanks to the proposed technique allow for energy and storage capacity savings, both at the level of the user equipment and at the network level, as well as time savings which have a positive impact directly on the user experience.

[0019] Thus, the network entity searches for subscription data using a subscription identifier associated with the user terminal, in order to retrieve at least the subscribed tariff blocks, or, depending on various implementations, directly information relating to the authorization or rejection of the requested block. Therefore, thanks to the subscription identifier, stored for example in the user terminal's SIM card, the network entity can obtain information enabling it to subsequently determine whether a block is authorized or rejected.

[0020] Thus, the subscription identifier (for example, the SUPI for Subscription Permanent Identifier) ​​stored in the user terminal (in their SIM card) allows access to a network equipment for managing subscription data (for example, the UDM entity according to the applicable standard, in English Unified Data Management, which itself stores this subscription data or is able to obtain it from one or more other entities such as UDR, in English Unified Data Repository, which ensures its storage) to obtain the subscribed tranches and thus verify their authorization, according to a first embodiment, or allows, according to other embodiments, access to a context parameter (for example, UE Context for User Equipment Context) associated with the user terminal,referencing the authorized and / or rejected tranches during the registration process or obtaining the authorized and / or rejected tranches from the subscription data management network equipment.

[0021] The network entity implementing the process steps can be either an access control network entity (e.g., an AMF entity) or a session control network entity, such as a Session Management Function (SMF). Some steps may be implemented by either of these entities, or all steps may be implemented by an AMF or an SMF entity.

[0022] According to one aspect of the process for managing a request to activate a packet data session, the reception of the activation request is implemented by an access control network device and the other steps are implemented by an access control network device or a session control network device.

[0023] According to one aspect of the process for managing a request to activate a packet data session, the authorization check of the requested slice also takes into account at least one piece of data relating to a current location of the user terminal and / or a type of access used by the user terminal.

[0024] Thus, the network entity also takes into account, in addition to subscription data, data relating to the location of the user terminal (for example when it is a mobile terminal) and / or the type of access used by the user terminal.

[0025] According to one aspect, the process for managing a request to activate a data packet session includes, if the authorization check of the slice is positive and if a subscription data item includes an indicator requiring authentication of the authorized slice, authentication of the authorized slice, and: If authentication is successful, the procedure for managing the activation request for the data packet session for the authorized tranche will continue; if authentication is unsuccessful, the request to activate a data packet session for the authorized tranche will be rejected.

[0026] Thus, according to this first embodiment, if the subscription data for the authorized slice requires authentication of that slice, the process performs this authentication before proceeding with the packet data session activation procedure. This avoids having to implement the step of selecting a Session Management Function (SMF) network device if the slice is not authenticated. If authentication fails, the packet data session activation request for the requested slice is rejected; otherwise, the packet data session activation procedure continues.

[0027] According to one aspect, the process for managing a request to activate a packet data session includes, before verifying the authorization of the slice and if a subscription data includes an indicator requiring authentication of the slice, an authentication of the requested slice, and if the authentication is negative, a rejection of the request to activate a packet data session for the requested slice.

[0028] Thus, according to this second embodiment, if the subscription data relating to the slice for which the user terminal requests a packet data session activation requires authentication of that slice, this authentication is implemented before the slice authorization check. This allows the slice activation request to be rejected directly if authentication fails, or for the slice authorization check to proceed if it is authenticated.

[0029] According to one aspect of the process for managing a request to activate a data packet session, obtaining it includes issuing a query request to a subscription data management network equipment, the query including the subscription identifier, and receiving a response from the subscription data management network equipment including at least one piece of information enabling authorization of the requested tranche to be determined.

[0030] Thus, the information necessary to verify authorization, and, where applicable, to authenticate, the data slice for which the user terminal requests the activation of a packet data session, is obtained by querying a network subscription data management system, for example, called UDM according to the applicable standard (Unified Data Management). This query is implemented if the network access control system (for example, the AMF) does not have this subscription data available, particularly if it did not store it locally during the registration process.This query of the subscription data management network equipment includes a subscription identifier (for example, the SUPI, or Subscription Permanent Identifier), stored by the user's terminal, in order to retrieve the user's subscription information for the requested tranche. In some variations, the network entity queries the subscription data management network equipment to directly retrieve the authorized / rejected tranches.

[0031] According to one aspect of the process for managing a request to activate a packet data session, the slice authorization check includes issuing a query request to a slice instance selection network equipment, the query including at least the identifier of the requested slice and subscription data including the identifiers of the subscribed slices, and receiving a response from the slice instance selection network equipment including information representative of an authorization or a rejection for the requested slice.

[0032] Thus, if the network equipment (e.g., AMF or SMF) does not have access to the data needed to authorize or reject the requested slice, a request is sent to another network entity, such as the NSSF (Network Slice Selection Function), providing it with the previously obtained subscription data (including the identifiers of the subscribed slices) and the identifier of the requested slice (note that current location information is also useful for authorization on a 3GPP connection). This variant makes it possible to implement authorization verification even when the AMF or SMF does not directly have the necessary data.

[0033] The response from the slice instance selection network equipment may, for example, contain the requested slice in a parameter such as the Allowed NSSAI variable or the Rejected NSSAI variable depending on whether the slice is allowed or rejected (in the case where it is rejected this may be for the entire public land mobile network (PLMN) or the current location of the user terminal).

[0034] According to one aspect of the process for managing a request to activate a packet data session, the authorization of the slice is followed by the selection of a session control network equipment and by the selected session control network equipment checking the validity of the request to activate a packet data session for the user terminal and the authorized slice, taking into account at least one subscription data and a local policy of the selected session control network equipment.

[0035] Thus, according to this embodiment, the procedure for activating a packet data session continues, once the requested slice has been authorized and, if applicable, authenticated, with the implementation of the classic step of selecting, by an access management device, a session control device. This step is therefore implemented either following the authorization verification of the requested slice or following the authentication of the authorized slice. However, conventionally, according to prior art, the slice authentication step is the last step of the registration procedure, and therefore not followed by any other step, and the authorization verification step, also implemented during the registration procedure, is likewise not followed by a step for selecting the session control device (SMF), this step being implemented during the packet data session activation procedure.

[0036] According to a first variant of the process for managing a request to activate a packet data session for a terminal, the authorization check of the requested slice includes a search for the identifier of the requested slice among a list of identifiers of previously authorized slices associated with the subscription data and If the search is positive, proceed with the packet data session activation procedure; if the search is negative, the verification result is negative.

[0037] According to a second variant of the method for managing a request to activate a packet data session for a terminal, the authorization check of the requested slice includes a search for the identifier of the requested slice among a list of identifiers of previously authorized slices associated with the subscription data and If the search is positive, proceed with the request management procedure to activate the data packet session; if the search is negative, proceed with the second authorization verification step as described above.

[0038] According to a third variant of the method for managing a request to activate a packet data session for a terminal, the authorization check of the requested slice includes a search for the identifier of the requested slice among a list of identifiers of previously rejected slices associated with the subscription data and If the search is positive, the verification result is negative; if the search is negative, a second search is performed for the requested slice identifier from a list of previously authorized slice identifiers associated with the subscription data; if the second search is positive, the procedure for managing the packet data session activation request continues; if the second search is negative, the verification result is negative.

[0039] According to a fourth variant of the method for managing a request to activate a packet data session for a terminal, the authorization check of the requested slice includes a search for the identifier of the requested slice among a list of identifiers of previously rejected slices associated with the subscription data and If the search is positive, negative verification result; if the search is negative, a second search for the requested slice identifier from a list of previously authorized slice identifiers associated with the subscription data; and if the second search is positive, continuation of the packet data session activation request management procedure; if the second search is negative, a second authorization verification step such as that described above.

[0040] According to a fifth variant of the method for managing a request to activate a packet data session for a terminal, the authorization check of the requested slice includes a search for the identifier of the requested slice among a list of identifiers of previously rejected slices associated with the subscription data and If the search is positive, the verification result is negative; if the search is negative, the second authorization verification step is as described above.

[0041] For all these variants, it does not matter whether the registration procedure is carried out according to the standard (where Allowed NSSAI is stored and not Rejected NSSAI) or according to the invention (where the different cases of storing Allowed NSSAI and / or Rejected NSSAI are considered).

[0042] Furthermore, for all these variants, if the tranche authorization result is positive, tranche authentication does not need to be done, even if it is required by the subscription, because it was done during the registration procedure.

[0043] The invention further relates to a computer program product comprising program code instructions for implementing a process as described above, when executed by a processor.

[0044] The invention also relates to a computer-readable recording medium on which is recorded a computer program comprising program code instructions for executing the steps of the process according to the invention as described above.

[0045] Such a recording medium can be any entity or device capable of storing the program. For example, the medium may include a storage means, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a USB flash drive or a hard drive.

[0046] On the other hand, such a recording medium can be a transmissible medium such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means, so that the computer program it contains can be executed remotely. The program according to the invention can, in particular, be uploaded to a network, for example, the Internet.

[0047] Alternatively, the recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the aforementioned display control method.

[0048] The invention further relates to a device for managing requests to activate a packet data session for a user terminal capable of sending and receiving data on a communications network organized into network slices, the user terminal comprising a subscription identifier for at least one of the network slices, the device being implemented by at least one network device, and comprising a receiver, a transmitter, a processor, and memory coupled to the processor with instructions intended to be executed by the processor for: receive a request to activate a packet data session from the user terminal for a slice of the network, the activation request including an identifier of the requested slice, obtained from a parameter including one or more identifiers of slice(s) subscribed to by the user, the activation request being independent of an authorization or rejection of the requested slice (Sli) determined during the registration of the user terminal with the network; obtain, from the subscription identifier, at least one piece of information allowing the determination of an authorization of the requested slice; verify the authorization of the requested slice taking into account the at least one piece of information allowing the determination of an authorization of the requested slice obtained and, if the verification is negative, a rejection of the request to activate a packet data session for the requested slice.

[0049] This device, capable of implementing in all its modes of embodiment the process of managing the request to activate a packet data session which has just been described, is intended to be implemented in a network entity.

[0050] This device and the corresponding computer program mentioned above offer at least the same advantages as those conferred by the method of managing a request to activate a packet data session according to the present technique.

[0051] The network entities described in this application may correspond to virtual entities, also called functions.

[0052] S-NSSAI slice identifiers are stored, for example, as variables containing one or more fields, as are the specific data Configured NSSAI, Allowed NSSAI or Rejected NSSAI.

[0053] The application, in an unclaimed implementation not covered by the invention, also relates to a method for registering a user terminal with a communications network organized into network slices, said user terminal being capable of transmitting and receiving data on the network, the method being implemented by network access control equipment capable of communicating with the user terminal via the network and comprising receiving a registration request issued by the user terminal to register with at least one of the network segments, the registration request including an identifier S - NSSAI of at least one slice, obtained from a parameter Configured NSSAIassociated with the user terminal and including one or more subscribed slice identifiers by the user without prior verification by the user terminal that the slice has been previously rejected by the network; an emission, to the user terminal, of an information message in response to the registration request including an acceptance information, without information of authorized and / or rejected slices, or a rejection information of the registration request for at least one slice; a generation for a context parameter of the user terminal of a binary registration status information associated with the user terminal without information relating to authorized or rejected slices.

[0054] Thus, the present technique is based on a completely new and inventive approach to the registration procedure for a user terminal for one or more segments of a communication network, notably eliminating the traditional steps of verifying the authorized or rejected status of the requested segments for both the user terminal and the network equipment. Furthermore, this simplified procedure also eliminates the need to store information relating to authorized or rejected segments, both at the user terminal level and at the network level. Therefore, following a registration request for one or more network segments issued by a user terminal, only the general registration context of the user terminal (accepted or rejected) is stored at the network level, without storing specific information relating to the authorized or rejected status of each of the requested segments.

[0055] To achieve this, the user terminal only uses information related to the user's subscriptions to the service blocks, which is available as configuration data containing the identifiers of the subscribed blocks. Similarly, the network equipment responsible for accepting or rejecting the user terminal's registration request does not store specific information about the authorized / rejected status of the requested blocks, but only general contextual information about the user terminal's accepted or rejected registration status. Therefore, unlike current specifications, no authorized / rejected block information is transmitted to the user terminal.

[0056] The registration procedure is therefore greatly simplified because it does not implement all the steps outlined in the current specifications and significantly limits the amount of information stored during or after the registration process. Furthermore, simplifying the registration procedure also simplifies the subsequent process of initiating a packet data session by the user terminal.

[0057] According to a particular aspect, the transmission includes a prior check that at least one network slice or at least one of the requested slices is authorized, based on data relating to a current location of the user terminal and a type of access requested by the user terminal, and where the information message includes an acceptance message if the result of the check is positive or a rejection message if the result of the check is negative.

[0058] Thus, according to this variant, the network equipment responsible for processing the registration request performs a check to reject the registration request if all the requested slices are rejected, for example, due to a location or access type prohibited for the user terminal. This informs the user terminal that it must, for example, renew its registration request when it has changed location, before initiating a packet data session activation procedure that would be denied if none of the subscribed slices are authorized at any given time.

[0059] According to a particular characteristic, the generation includes the generation of information relating either to the authorized tranches or to the rejected tranches.

[0060] According to another characteristic, information relating to authorized tranches and / or rejected tranches is stored in the subscription data management network equipment (or the latter is able to retrieve this information as mentioned previously; for simplification for the rest of the description, we assume the data is stored in the subscription data management network equipment, which does not exclude the case where the storage would be delegated to another entity).

[0061] Storing information about authorized / rejected tranches in the subscription data management network equipment makes it possible, in particular, to cover the case where the SMF will perform the authorization and authentication control. Presentation of figures

[0062] Other objects, features and advantages of the invention will become more apparent upon reading the following description, given by way of simple illustration and not limitation, in relation to the figures, among which: [ Figure 1 ] presents an example of a simplified architecture of a communications network in which the process for managing a request to activate a packet data session is implemented according to an embodiment of the invention; [ Figure 2 ] illustrates in block diagram form the recording process according to one embodiment of the invention; [ Fig. 3a ], [ Fig. 3b ], [ Fig. 3c ], [ Figure 3d ], [ Fig. 3e ], [ Fig. 3f ] And [ Fig. 3g ] illustrate in block diagram form the process of managing a request to activate a packet data session according to several embodiments of the invention and several situations. Detailed description of the modes of development of the invention

[0063] The present technique offers better management of slice information, both from the point of view of storage and from the point of view of use of this slice information, based on a compromise between the amount of slice information to be stored and the usefulness of this information by the user terminal and the network, while optimizing the procedures of registration of a user terminal and activation of packet data session for one or more network slices for a user terminal.

[0064] Therefore, knowing the identifiers of rejected slices (in the Rejected NSSAI variable) at the user terminal level is useful for the user terminal registration procedure: it prevents the user terminal from requesting registration again for a slice that was rejected during a previous registration. Conversely, knowing the identifiers of allowed slices (in the Allowed NSSAI variable) does not contribute to the registration procedure.

[0065] The user terminal's knowledge of the identifiers of the allowed and / or rejected slices is of interest for the PDU session activation procedure: indeed, knowing the identifiers of the allowed slices (in the Allowed NSSAI variable) allows the user terminal to activate a packet data session if the slice is allowed, and knowing the identifiers of the rejected slices (in the Rejected NSSAI variable) allows the user terminal not to request a packet data session if the slice is rejected.

[0066] However, it is possible that some subscriptions made by the user and configured as such may not be among the authorized or rejected subscriptions, because the registration procedure as currently defined by the standard only determines authorized and rejected subscriptions from those requested by the user terminal at the time of registration. Therefore, the user terminal's knowledge of the authorization and / or rejection information for the subscribed subscriptions is neither precise nor exhaustive.

[0067] Furthermore, knowledge at the network level, and particularly at the AMF entity level, via UE Context information, of the following information is relevant to the packet data session activation procedure: Knowing the identifiers of the allowed slices (in the Allowed NSSAI variable) allows the network to accept a packet data session request from a user terminal if the slice was previously allowed during registration; knowing the identifiers of the rejected slices (in the Rejected NSSAI variable) allows the network to reject a packet data session request if the slice was previously rejected during registration.

[0068] However, here again, it is possible that the network is not aware of the authorization or rejection for certain segments and in fact the network only knows the authorized segments among those that were requested by the user terminal during the registration procedure.

[0069] The main advantage of the proposed technique, according to one embodiment, is that no slice information is stored, either at the user terminal or at the network level, during the user terminal registration procedure. Only information representing the terminal's registered or unregistered state is stored at the network level.

[0070] Thus, this simplified user terminal registration procedure not only reduces the amount of information stored, both at the network level and on the user terminal itself—specifically, by avoiding the storage of information concerning the authorization or rejection of previously subscribed data slices—but also prevents the transmission of this information from the network to the user terminal at the end of the registration process. Furthermore, it eliminates the need for the user terminal to verify the authorization or rejection of the slice for which it requests the activation of a packet data session. The user terminal can request the activation of a packet data session for any of the slices to which the user has subscribed, without first checking whether these slices are authorized or rejected by the network.

[0071] Therefore, the proposed technique also relies, according to different embodiment variants, on the control carried out by the network during the activation procedure of a packet data session requested by the user terminal to know whether the slice requested by the terminal is authorized or not, and, where applicable when required, whether it is authenticated or not.

[0072] Finally, according to one variant of the proposed technique, the network does not manage (nor communicate to the user terminal) any slice information relating to authorization or rejection, thus facilitating its operation and that of the user terminal.

[0073] The proposed technique is now described, in relation to the figures 1 to 3a .

[0074] An example of a network architecture, in which the proposed technique can be implemented, is first illustrated, in a simplified manner, by figure 1One or more user terminals, noted UE1, UE2, access, via an access network A.N., to one or more DN1, DN2 or DN3 data networks, via one or more slices Sl1, Sl2 And Sl3.

[0075] We then turn our attention to a user terminal UE1 who wishes to receive data on one or more slices of a network as illustrated in figure 1 .

[0076] To do this, a user U1, for example the primary user of the user terminal UE1, subscribes, through their telecommunications operator, to one or more network segments, for example according to their habits or content consumption preferences, and the performance of their user terminal. UE1... Following his subscription, subscription data DSub, including, in particular, the identifiers of the slices to which the user U1Subscribers are created. In addition, a subscription identifier IdSub, For example, the SUPI variable (or Subscription Permanent Identifier) ​​allows access to this subscription data. DSub, For example, when they are stored in a network equipment for managing subscription data. This subscription identifier is notably stored in the user terminal's SIM card. UE1 and is representative of the subscription, a subscription containing one or more subscribed tranches, without being exclusively associated with the user U1 nor to the user terminal UE1. Indeed, another user U2 may have obtained the user's permission U1 to use their subscription, or the SIM card storing the subscription identifier can be transferred from the user's terminal UE1 to another user terminal UE2 For example.

[0077] According to the proposed technique, and as illustrated in figure 2 The user terminal then requests to register with the network (for example, via a referenced network entity). NE1 ) for one or more tranches subscribed by the user. This information about the subscribed tranches is notably available, as it is stored by the user terminal, in a data / parameter referencing the subscribed tranches and noted for example Configured NSSAI.

[0078] As previously mentioned, in this embodiment, the user terminal does not examine the status (authorized or rejected) of the slice(s) with which it requests registration, because it did not store this authorization or rejection information during a previous registration. Indeed, this embodiment is based on a simplified registration procedure that does not store information about authorized and / or rejected slices in the user terminal, unlike the current standard. Furthermore, as already mentioned and described in more detail below, the user terminal can request the activation of a packet data session for any subscribed slice (whose identifier is stored in the Configured NSSAI variable).

[0079] Thus, this registration procedure does not implement, in particular, the step provided for by the current specifications during which the user terminal examines the value of the Rejected NSSAI variable in order not to request the registration of a slice already rejected during the previous registration (for the same type of access and the same registration area).

[0080] At the network level, the equipment NE1 or for example the access control network entity or function, AMF, receives, during a reception step 200, the registration request issued by the user terminal, with one or more subscribed tranche identifiers, and the registration procedure continues according to several variants.

[0081] According to a first variant of this recording process, the network entity NE1does not check whether the slices referenced by the identifiers in the request are allowed or rejected, for the current location of the user terminal and the type of access requested, and accepts the registration request. The network entity NE1 informs the user terminal by issuing a 210 acceptance message, without information on the authorized or rejected slices.

[0082] According to a second variant of this recording method, the network entity NE1 checks if all slices requested in the registration request are rejected, for the current location of the user terminal and the type of access requested. If so, the network entity NE1The system rejects the registration request and informs the user terminal by issuing a rejection message (210). The user terminal can resubmit the registration request later, for example, if they have changed location. However, if at least one of the slices is authorized, the AMF accepts the registration request and informs the user terminal by issuing an acceptance message (210), without specifying which slices were authorized or rejected. According to this second variant, the network entity handles the verification of authorized / rejected slices. NE1 taking into account the subscription data, starting from the subscription identifier.

[0083] According to these two variants of this recording method, the binary recording state of the user terminal (for example, the RM State parameter) is updated, during a generation step 220, by the network entity NE1and stored in a user terminal context setting UE1 (for example, the UE Context data / variable). By default, the registration state corresponds to the unregistered state, and if the registration request is accepted, the parameter is updated with the registered state.

[0084] This registration status allows the network to know if the user terminal is properly registered with the network. However, this registration status is not communicated to the user terminal in the response to its registration request because the terminal is capable of updating its registration status according to the standard (specifically, changing to the registered state when it receives a registration acceptance response).

[0085] Thus, at the end of the user terminal registration procedure, the network entity NE1issues an information message including an acceptance or rejection message (depending on the second variant) of the registration, which does not include any information relating to the subscribed tranches or the registration status of the user terminal.

[0086] This procedure therefore differs greatly from the operation of the current standard, according to which the slices requested in the request are all checked, the allowed slices are listed in a parameter (Allowed NSSAI) stored both on the network side and on the user terminal side, and the rejected slices are listed in a parameter (Rejected NSSAI) stored on the user terminal side.

[0087] According to a third variant of this registration method, an authorization check is performed on all slice identifiers in the registration request, and the results of this check are stored respectively in a variable listing the identifiers of the allowed slices (for example, the Allowed NSSAI parameter) and in a variable listing the identifiers of the rejected slices (for example, the Rejected NSSAI parameter). Furthermore, these two variables are transmitted to the user terminal in the network's acceptance or rejection response. Thus, according to this third variant, the network is aware of the allowed and rejected slices, for example, by storing them in the user terminal's context parameter. UE1(for example, the UE Context data / variable) the Allowed NSSAI and Rejected NSSAI variables, or by contacting a subscription data management network device capable of storing one or both of these data. This information will be particularly useful for implementing the procedure for managing a request to activate a packet data session from the user terminal to the network, described below.

[0088] According to the proposed technique, and thanks to the simplified registration procedure, the user terminal can request the activation of a packet data session for any of the subscribed slices, i.e., for any of the slices referenced, for example, in the Configured NSSAI variable, regardless of the "authorized / rejected" status that might be associated with that slice, unlike current specifications. The proposed technique notably allows the user terminal to request the activation of a subscribed slice not yet requested by the user terminal but potentially authorized, whereas, according to prior art, the user terminal can only do so for a slice that has already been authorized and therefore already requested, and, most importantly, cannot do so for a slice that was rejected during a previous registration.

[0089] According to the proposed technique, the user terminal UE1requests the activation of a packet data session for a single slice, and therefore it is the network, and in particular the entity NE1 corresponding, for example, to the AMF entity or function, which performs a verification of the authorization of the requested tranche (and its authentication if required). This verification may take into account the type of access and the current location of the user's terminal, as subscription to certain tranches may be restricted to a given area or a given type of access (3GPP, non-3GPP). The entity NE1, For example, a network access control entity can also forward the request received from the user terminal to another network entity. NE2,for example a session control network entity such as the SMF entity or function, which then performs in place of NE1 one and / or the slice authorization verification and slice authentication steps, if required, as explained below (which requires a prior SMF selection step known from the standard).

[0090] Thus, the figure 3a first illustrates an initial reception stage 300, by a network entity NE1, of a request to activate a data packet session originating from the user terminal UE1 for a slice i of the network identified by an identifier Sli. The network entity NE1 obtains, during a retrieval step 310, from the subscription identifier IdSub, at least one piece of information enabling the determination of authorization for the requested tranche ( Sly ).

[0091] This information may correspond to subscription data (and in particular the identifiers of the subscribed tranches) stored in a subscription data management network equipment accessible via the subscription identifier. In this case, the subscription data is therefore obtained via a 311 query of the subscription data management network equipment. NE3, for example, called UDM according to the current standard (Unified Data Management). Then, from this subscription data, the network entity NE1 (Or NE2) can perform step 320 of the authorization of the tranche requested by the user terminal UE1.

[0092] To achieve this, according to an initial implementation, the network entity NE1 (Or NE2) performs this verification directly, using the subscription data retrieved, during step 320.

[0093] According to a second implementation, the network entity NE1 (Or NE2) does not have direct access to authorization information for the requested slice and performs a 312 query of another slice instance selection network entity NE4, for example the NSSF entity by providing it with a parameter containing the identifiers of the subscribed tranches (for example Subscribed NSSAI) and the identifier Sli (e.g., Requested NSSAI) corresponding to the requested tranche. The information used to determine authorization for the requested tranche ( Sli ) can also, according to a third implementation, correspond to data stored by the network entity NE1 in a user terminal context setting (for example EU Context) including in particular the registration status ( RM State) of the user terminal, but also the identifiers of the allowed (Allowed NSSAI) and / or rejected (Rejected NSSAI) tranche, or, according to a fourth implementation, this same data stored in the subscription data (during registration) obtained by the network entity via a 311 query of the subscription data management network equipment. Thus, from these identifiers of the allowed and / or rejected tranche, the network entity NE1 (Or NE2) can perform step 320 of the authorization of the tranche requested by the user terminal UE1.

[0094] According to some implementations (first and second), as previously stated, no authorized tranche and rejected tranche information is stored at the time of registration, unlike other implementations where authorized tranche and / or rejected tranche information may be stored in a user terminal context (third implementation) or in a subscription data management network equipment (fourth implementation).

[0095] It is therefore important to note that the authorization check only concerns the slice requested by the user terminal and this check is implemented only during the activation procedure of a packet data session (and no longer during the user terminal registration procedure as in the current standard) for the first two implementations, or for the last two implementations, when the slice requested during the activation of a packet data session is not in the list of authorized slices previously stored during registration in a user context or a subscription data management network equipment.

[0096] The authorization verification of the requested tranche may also take into account location information of the user terminal and / or information relating to the type of access used by the user terminal, as some tranches may be subscribed to with restrictions, including zones or type of access.

[0097] If the check returns a negative result, i.e., the requested slice is not authorized for the user terminal (perhaps due to its location or the type of access used), the network rejects the session PDU activation request (a specific error cause may be created, for example). rejected slice Or unauthorized slice and possibly an additional parameter indicating the relevant slice) and the packet data session activation procedure is completed for the requested slice.

[0098] Conversely, if the verification delivers a positive result, then the procedure for activating a packet data session continues, according to different embodiment variants described below.

[0099] Thus, the network then proceeds, according to a first embodiment, to authenticate the requested slice, if required by the subscription (unless the slice is present in the list of authorized slices stored in a user context or a network equipment for managing subscription data; in these cases, authentication was performed during registration). Indeed, the subscription data contains information indicating whether a slice must be authenticated before being considered authorized. Authentication of the authorized slice is performed, for example, according to a procedure similar to that implemented during the registration procedure described in the standard, except that it is implemented only during the activation procedure of a packet data session.Thus, the sequence of steps compared to the registration procedure described in the standard is different because the authentication of the slice is the last step of the registration procedure described in the standard (3GPP TS 23.502 v16.7.0 § 4.2.2.2.2 step 25) and is not followed by any other step.

[0100] If the authentication of the authorized slice is successful, then the procedure for activating a packet data session continues, according to different embodiments described below, and for example: with the session control network entity selection step by the access control network entity (for example, after executing a slice authorization and / or a slice authentication or neither of these steps), in order to forward the request from the user terminal to it; or with the session control network entity querying the subscription data management network equipment to obtain the subscription data related to session control if it does not already have it; or with the session control network entity responding step (for example, after executing a slice authorization and / or a slice authentication or neither of these steps) to the access control network entity.

[0101] These steps are known from the standard (3GPP v16.7.0 TS 23.502 § 4.3.2.2.1 steps 2, 4, and 5 respectively). However, if the session control entity queries the subscription data management network equipment to obtain the allowed / rejected slice information according to the invention, then this query is combined into a single query with the query to obtain the session control data (if this data is not already present).

[0102] Conversely, if authentication of the authorized slice is rejected, then the network rejects the PDU session activation request and the packet data session activation procedure is completed for the requested slice.

[0103] According to a second embodiment, slice authentication can be performed before the authorization check of the requested slice, provided the subscription data so requires. In this case, if the requested slice is not authenticated, the network rejects the session PDU activation request, and the packet data session activation procedure is completed for the requested slice. Conversely, if the requested slice is authenticated, the authorization check is performed as described above, and the packet data session activation procedure continues if the slice is authorized, or the network rejects the session PDU activation request if the authenticated requested slice is not authorized, and the packet data session activation procedure is completed for the requested slice.

[0104] The first two implementations of the packet data session activation procedure mentioned above represent a simplified solution in which no slice authorization or rejection information is stored during user terminal registration with the network, nor during packet data session activation, either at the user terminal or network level. This solution therefore has the following technical effects: a more scalable solution, as it is applicable in the same way regardless of the number of slices to which the user has subscribed (including if the maximum number were to increase compared to what the standard currently allows); an economical solution in terms of storage: it is not necessary to store information on allowed / rejected slices either at the user terminal level or at the network level, which allows energy savings at the user terminal level and at the network level; a simpler solution: not having to store information on allowed / rejected slices limits the processing at the user terminal and network level (for example, on the choice of slices when requesting registration and the request to activate a packet data session);Simpler solution for location management: the network does not need to inform the user terminal each time a slice changes state (allowed / rejected) according to its current location since the allowed / rejected slice state is not managed or stored; simpler solution for slice instance selection: the slice instance selection (NSI, in English Network Slice Instance) is not done when registering the user terminal but when activating the packet data session and this can be done at the same time as checking the authorization of the requested slice (a single query to the NSSF network entity for authorization checking and slice instance selection);A more economical solution in terms of processing time: the access control network entity (AMF for example) is potentially able to manage more user terminals since it no longer manages, for these terminals, information on authorized / rejected slices and therefore no longer implements the processing related to it.

[0105] For the two aforementioned implementations, certain rejected slice information is stored in addition to, or instead of, allowed slice information at the time of registration (whereas, according to the current standard, only allowed slice information is stored), specifically at the network level, in the user terminal's context setting, or in the subscription data management network equipment, and is used during the packet data session activation procedure. This was described earlier in relation to the third variant of the registration process.

[0106] As a reminder, according to this third variant of the registration process, the results of the slice verification required for user terminal registration are stored respectively in a variable listing the identifiers of the allowed slices (for example, the Allowed NSSAI parameter) and in a variable listing the identifiers of the rejected slices (for example, the Rejected NSSAI parameter). Thus, according to this third variant of the registration process, the network is aware of the allowed and rejected slices, for example, by storing them in the user terminal's context parameter. UE1(for example, the UE Context data / variable) the Allowed NSSAI and Rejected NSSAI variables, or by storing them in the subscription data management network equipment. This information is then used to implement the procedure for managing a request to activate a packet data session from the user terminal to the network, according to the different embodiments described below.

[0107] According to a first variant of the procedure for handling a request to activate a data packet session, the verification of the requested slice first includes a search for the identifier Slyof the requested slice in the list of authorized slices. If this search is successful, i.e., if the requested slice is authorized, then the packet data session activation procedure continues, for example, by implementing the session control network entity selection step described above. It should be noted that if the slice is present in the list of authorized slices, it has also been authenticated, so the authentication step described above is not implemented again. Conversely, according to this first variant, if the search is negative, i.e., if the requested slice has not been previously authorized, then the packet data session activation request is rejected for the requested slice.It should also be noted that this first variant of the procedure for managing a request to activate a packet data session can be implemented following a registration request according to the current standard, which does indeed store the list of authorized slices.

[0108] A second variant of the procedure for handling a packet data session activation request differs from the first variant above only in that, when the search is negative, a second authorization check of the requested slice is performed, according to the first or second implementation described above with steps 300, 310, and 320. This involves obtaining information from the subscription identifier to determine authorization. This second variant assumes that the requested slice may simply not have been part of the registration request, in which case it could not have been authorized during the registration procedure, which does not necessarily imply that it is rejected.

[0109] According to a third variant of the procedure for handling a request to activate a data packet session, the verification of the requested slice first includes a search for the identifier Sli of the requested slice in the list of rejected slices. If this search is positive, i.e., if the requested slice is rejected, then the packet data session activation request is rejected for the requested slice. Conversely, if the search is negative, i.e., if the requested slice has not been previously rejected, then a second search for the identifier SlyThe requested slice is checked against the list of allowed slices. If this second check is successful, i.e., if the requested slice is allowed, then the packet data session activation procedure continues, for example, by implementing the session control entity selection step described earlier. If the second check is unsuccessful, then the packet data session activation request is rejected for the requested slice.

[0110] According to a fourth variant, if this second search is negative, i.e., the requested tranche is neither in the list of authorized tranches nor in the list of rejected tranches, a second authorization check of the requested tranche is implemented, according to the first or second implementation described above with steps 300, 310, and 320; that is, by obtaining, from the subscription identifier, information enabling the determination of this authorization.

[0111] Finally, according to a fifth variant of the procedure for handling a request to activate a data packet session, the verification of the requested slice first includes, like the third variant, a search for the identifier Sly of the requested slice in the list of rejected slices. If this search is positive, i.e., if the requested slice is rejected, then the packet data session activation request is rejected for the requested slice. Conversely, according to this fifth variant, if the search is negative, i.e., if the requested slice has not been previously rejected, then the packet data session activation procedure continues, for example, by implementing the session control entity selection step described earlier.

[0112] Thus, these different variants make it possible to take advantage of the storage of certain slice information (authorized and / or rejected) to ensure better control of slice usage, simplify the procedure for managing a request to activate a packet data session and in particular to pool the authorization verification that it provides at the level of the session control entity.

[0113] Finally, as mentioned above, the procedure for managing a request to activate a packet data session can be implemented in two ways: the first involves verifying the authorization of a slice and then authenticating (if required) the authorized slice, and the second involves this authentication (if required) before verifying the authorization. These two ways of implementing can also be implemented by one or more network entities (in particular an access management entity such as AMF and a session control entity such as SMF), depending on the situation.

[0114] These different situations are described in particular below, in relation to the figures [ Fig. 3b ], [ Fig. 3c ], [ Figure 3d ] for the first embodiment and [ Fig. 3e ], [ Fig. 3f ] And [ Fig. 3g ] for the second embodiment.

[0115] In the first embodiment, the Fig. 3b illustrates the situation where the authorization verification of a slice, implemented before slice authentication, is performed by a network entity NE1, For example, an AMF access control entity. Thus, this AMF entity receives, at step 300, a request to activate a packet data session from the user terminal. (UE1) for a slice of the network and notably implements a 312 query of another slice instance selection network entity NE4, For example, the NSSF entity, in order to obtain information enabling the authorization of the requested tranche. Upon receipt of the NSSF entity's response, the AMF implements step 320 to verify the authorization of the requested tranche. The procedure then continues, notably with authentication of the authorized tranche if required.

[0116] There Fig. 3cillustrates the situation where the authorization verification of a slice is performed by a network entity NE1, for example an AMF access control entity, before slice authentication performed by another network entity NE2, For example, a network entity for SMF session control. To do this, the AMF receives a packet data session activation request from the user terminal. (UE1) for a slice of the network, is transmitted, during a step 300', to the SMF (previously selected) for the purpose of authenticating the slice, previously authorized by the AMF (via steps 312 and 320 described previously).

[0117] There Fig. 3d illustrates the situation where slice authorization verification and subsequent slice authentication are performed by a network entity NE2, For example, a network entity for SMF session control. To do this, however, the network entity NE1, For example, an AMF access control entity receives, during step 300, a request to activate a packet data session from the user terminal. (UE1) for a network slice and transmits it, during step 300', to the SMF (previously selected). The SMF then performs a query 312 to another network entity to select the slice instance. NE4, For example, the NSSF entity, in order to obtain information to determine the authorization of the requested tranche. Upon receiving the response from the NSSF entity, the SMF entity implements step 320 to verify the authorization of the requested tranche. The procedure then continues, including authentication of the authorized tranche if required.

[0118] In the second embodiment, the Fig. 3eillustrates the situation where the authorization verification of a slice is performed after slice authentication, by a network entity NE1, For example, an AMF access control entity. Thus, this AMF entity receives, at step 300, a request to activate a packet data session from the user terminal. (UE1) for a network slice and implements, if required, a 400 authentication of the requested slice, then a 312 query of another slice instance selection network entity NE4, For example, the NSSF entity, in order to obtain information to determine the authorization of the requested tranche. Upon receiving the response from the NSSF entity, the AMF implements step 320 to verify the authorization of the requested tranche. The procedure then continues, notably with the selection of the session control network entity. NE2 (for example SMF).

[0119] There Fig. 3f illustrates the situation where the authorization verification of a slice is performed by a network entity NE2, for example a network entity for SMF session control, after slice authentication performed by a network entity NE1, For example, an AMF access control entity. Thus, this AMF entity receives, at step 300, a request to activate a packet data session from the user terminal. (UE1) for a network slice and, if required, performs a 400 authentication of the requested slice. Then, in a 300 step, the AMF transmits the packet data session activation request to the (previously selected) SMF. The SMF then performs a 312 query of another network entity to select the slice instance. NE4,For example, the NSSF entity, in order to obtain information to determine the authorization of the requested tranche. Upon receiving the response from the NSSF entity, the SMF entity implements step 320 to verify the authorization of the requested tranche. The procedure then continues, notably with the SMF entity's response to request 300' transmitted by the AMF (i.e., acceptance or rejection of the activation request).

[0120] Finally, the Fig. 3g illustrates the situation where the authorization verification of a slice is performed by a network entity NE2, For example, a network entity for SMF session control, after slice authentication performed by the same SMF entity. To do this, the activation request for a data packet session originates from the user terminal. (UE1) for a slice of the network, received by the network entity NE1,For example, the AMF access control entity is transmitted during a 300' step to the (previously selected) SMF. The SMF then performs, if required, a 400 authentication of the requested slice, followed by a 312 query of another slice instance selection network entity. NE4, For example, the NSSF entity, in order to obtain information to determine the authorization of the requested tranche. Upon receiving the response from the NSSF entity, the SMF entity implements step 320 to verify the authorization of the requested tranche. The procedure then continues, notably with the SMF entity's response to request 300' transmitted by the AMF (i.e., acceptance or rejection of the activation request).

[0121] It is understood that in all modes and variants of the procedure for managing a packet data session activation request according to the invention, the activation request issued by a terminal triggers in a network equipment the verification of the authorization of the corresponding slice, unlike the prior art where only a registration request triggers such a verification.

Claims

1. Method of management of request for activation of a packet data session for a user terminal (UE1) capable of sending and receiving data over a communications network organized into network slices, the user terminal comprising a subscription identifier for at least one of the network slices, the method being implemented by at least one network equipment (NE1), and comprising - reception (300) of a request for activation of a packet data session from the user terminal (UE1) for a network slice, the activation request comprising an identifier of the requested slice (Sli), which identifier is obtained from a parameter comprising one or more identifiers of one or more slices subscribed to by the user, the activation request being independent of an authorization or rejection of the requested slice (Sli) determined during registration of the user terminal with the network; - obtainment (310), from the subscription identifier, of at least one piece of information making it possible to determine an authorization of the requested slice (Sli); - verification (320) of authorization of the requested slice (Sli) taking into account at least one piece of information making it possible to determine an authorization of the requested slice obtained and, if the verification is negative, rejection of the request for activation of a packet data session for the requested slice (Sli), the verification being triggered by the activation request.

2. Method of management of request for activation of a packet data session for a terminal according to Claim 1, wherein the verification of authorization of the requested slice also takes into account at least one datum relating to a current location of the user terminal and / or a type of access used by the user terminal.

3. Method of management of request for activation of a packet data session according to Claim 1, comprising, if the verification of authorization of the slice is positive and if a subscription datum comprises an indicator requiring authentication of the authorized slice, authentication of the authorized slice, and - if the authentication is positive, continuation of the procedure of management of request for activation of the packet data session for the authorized slice; - if the authentication is negative, rejection of the request for activation of a packet data session for the authorized slice.

4. Method of management of request for activation of a packet data session according to Claim 1, comprising, prior to verification of authorization of the slice and if a subscription datum comprises an indicator requiring authentication of the slice, authentication of the requested slice, and if the authentication is negative, rejection of the request for activation of a packet data session for the requested slice.

5. Method of management of request for activation of a packet data session according to Claim 1, wherein the obtainment comprises sending an interrogation request to a network equipment for subscription data management, the request comprising the subscription identifier, and receiving a response from the network equipment for subscription data management comprising the at least one piece of information making it possible to determine an authorization of the requested slice (Sli).

6. Method of management of request for activation of a packet data session according to Claim 1, wherein the verification of authorization of the slice comprises sending an interrogation request to a network equipment for slice instance selection, the request comprising at least the identifier of the requested slice and a subscription datum comprising the identifiers of the slices subscribed to, and receiving a response from the network equipment for slice instance selection comprising a piece of information representative of an authorization or rejection for the requested slice.

7. Method of management of request for activation of a packet data session according to Claim 1, wherein authorization of the slice is followed by selection of a network equipment for session control and by inspection, by the selected network equipment for session control, of the validity of the request for activation of a packet data session for the user terminal and the authorized slice, taking into account the at least one subscription datum and a local policy of the selected network equipment for session control.

8. Device for management of request for activation of a packet data session for a user terminal (UE1) capable of sending and receiving data over a communications network organized into network slices, the user terminal comprising a subscription identifier for at least one of the network slices, the device being implemented by at least one network equipment (NE1), and comprising a receiver, a sender, a processor and a memory that is coupled to the processor with instructions that are intended to be executed by the processor with a view to: - reception of a request for activation of a packet data session from the user terminal (UE1) for a network slice, the activation request comprising an identifier of the requested slice (Sli), which identifier is obtained from a parameter comprising one or more identifiers of one or more slices subscribed to by the user, the activation request being independent of an authorization or rejection of the requested slice (Sli) determined during registration of the user terminal with the network; - obtainment, from the subscription identifier, of at least one piece of information making it possible to determine an authorization of the requested slice (Sli); - verification of authorization of the requested slice (Sli) taking into account at least one piece of information making it possible to determine an authorization of the requested slice obtained and, if the verification is negative, rejection of the request for activation of a packet data session for the requested slice (Sli), the verification being triggered by the activation request.

9. Computer program comprising instructions that, when these instructions are executed by a processor, cause the latter to implement the steps of method of management of request for activation of a packet data session, according to Claim 1.

10. Information medium that is readable by a network equipment, and comprises instructions of a computer program according to Claim 9.