METHOD FOR IDENTIFYING AN INTERCONNECTION MODEL BETWEEN TWO COMMUNICATION NETWORKS

Abstract

The invention relates to a method for identifying an interconnection pattern between a first communication network (LNET) and a second communication network (ANET), said identification method being implemented by a network equipment (AMF) of one of the two communication networks during a network procedure relating to at least one user terminal (UE) having a subscription with a third network (HNET), said method comprising: - receiving a signaling message associated with said network procedure, and - obtaining at least one data point representing said interconnection pattern between said first and second communication networks, said at least one data point being an identifier of said interconnection pattern extracted from said signaling message or being obtained from a lookup table between at least one identification information of said third network extracted from said signaling message and said at least one data point.Figure for the abridged version: Fig. 5.

Description

Title of the invention: METHOD FOR IDENTIFYING AN INTERCONNECTION MODEL BETWEEN TWO COMMUNICATION NETWORKS Technical field of the invention

[0001] The field of the invention is that of communication networks. More specifically, the invention relates to a solution for improving the interconnection between two communication networks. The present invention thus relates to a method for identifying an interconnection pattern between a first communication network and a second communication network, an identification device and a referencing device for such an interconnection pattern, as well as a user terminal capable of transmitting and receiving signaling messages and user data on the first communication network, taking into account an interconnection pattern between the first and second communication networks. Technological background

[0002] In communication networks, and in particular within wireless communication networks, a mobile terminal is capable not only of connecting to a communication network operated by the operator with whom the user has subscribed, also called the home network (in English "home network" for roaming or the network of the "participating operator" for network sharing according to the terminology of the 3GPP TS 23.501 standard for example in version V19.1.0), but also to one or more networks operated by operators with whom the user has not subscribed, also called local networks (for example in English "visited network" for roaming or the network of the "hosting operator" for network sharing according to the terminology of the 3GPP TS 23.501 standard).An operator can be, but not limited to, a public network operator (in English "Public Land Mobile Network", PLMN) or a private network operator (in English "Non-Public Network").

[0003] For this reason, there are commercial agreements, known as roaming agreements, between operators of different communication networks so that a mobile terminal can connect to both its home network and a local network.

[0004] These roaming agreements assume that the local network and the home network are technically interconnected so that signaling messages and user data can be exchanged between the two networks.

[0005] Within the framework of so-called fifth-generation or 5G mobile telecommunications networks, according to the 3GPP TS 23.501 standard, roaming (term (English) is possible according to a so-called LBO (Local Breakout) model or an HR (Home Routing) model, which limits the scope of roaming agreements that can be considered between the local network operator and the home network operator. Thus, a given operator is led to enter into interconnection agreements that can be numerous and / or lack the flexibility to meet the diverse needs of the different partner networks.

[0006] There is therefore a need for a technique to overcome all or part of the aforementioned disadvantages. Summary of the invention

[0007] According to a first aspect of the invention, a method for identifying an interconnection pattern between a first communication network and a second communication network is therefore proposed, said identification method being implemented by network equipment of one of the two communication networks during a network procedure relating to at least one user terminal having a subscription with a third network, said method comprising: - the reception of a signaling message associated with said network procedure, and - obtaining at least one data point representative of said interconnection model between said first and second network, said at least one data point being an identifier of said interconnection model extracted from said signaling message or being obtained from a lookup table between at least one identification information of said third network extracted from said signaling message and said at least one data point.

[0008] The invention applies in a context where there is a subscription associated with a user terminal (the user of the terminal is not necessarily the one who subscribed, as the terminal may be loaned or allocated by the subscriber to a third party) with a third network (i.e., a home network), the third network being either identical or different from the first or second network. Thus, the first, second, and third networks may, in some cases, belong to the same operator.

[0009] By "interconnection model between two networks," we mean an information structure that allows the distribution between these two networks of the network functions necessary for the joint use of these two networks in order to provide a service to a user terminal to be identified. Such a method for identifying an interconnection model can be implemented by network equipment that can host one or more network functions, for example, an AMF function (for "Access and Mobility Management Function" (SMF), or "Session Management Function" (UPF), according to the terminology of the 3GPP TS 23.501 standard, as presented later. Such a network function can, for example, be containerized (cloud-native network function), virtual (virtual network function), or physical (physical network function), and / or shared (network sharing).

[0010] It is noted that although illustrative examples are provided with reference to networks as defined or envisaged by the 3GPP standard, the invention also applies to other network architectures.

[0011] The proposed solution is thus based on the use of interconnection models referenced by an identifier contained in at least one signaling message or identifiable from an identifier of the network with which the user terminal has a subscription.

[0012] Thus, thanks to the invention, it is possible to interconnect two communication networks according to an interconnection model to which is associated a distribution of network functions between these networks. This distribution is variable according to the interconnection agreements concluded between the operators of these two networks.

[0013] In this way, for example, when the first network is a local network while the second and third networks are the same home network, it is possible to allocate network functions between the interconnected networks not in a fixed manner but flexibly, according to such roaming agreements. The advantage is thus to give operators more flexibility in their roaming agreements, allowing them, for example, to reduce their costs or improve their carbon footprint. Therefore, an operator can implement multiple different interconnection models with another operator and / or can implement distinct interconnection models with different operators, depending on the interconnection agreements concluded and the expectations of their respective customers.Furthermore, this implementation can be carried out in a very agile manner by an operator and its partner operators, particularly to quickly introduce new models and respond to new needs.

[0014] Furthermore, the invention is not limited to the direct interconnection between two networks but allows interconnection via one (or more) intermediate network(s), referred to as aggregator network(s). For example, with a single aggregator, the third network is the home network, and the invention applies between a first network, for example a local network, and a second network, for example an aggregator network, and then between a first network, for example an aggregator network, and a second network, for example a home network.

[0015] The invention may further include one or more of the following optional features, according to any technically possible combination.

[0016] According to a first characteristic, said at least one data representative of the interconnection model between said first and second network is obtained from said at least one identification information of the third network and at least one network slice identifier extracted from the signaling message.

[0017] A network slice is for example identified by an S-NSSAI (in English "Single Network Slice Selection Assistance Information") according to the TS 23.501 standard. It can be seen as a logical network supporting specific characteristics related for example to quality of service (e.g. latency or unidirectional transit time).

[0018] According to another feature, obtaining said at least one representative data point of the interconnection model includes: - the issuance of a request to identify the interconnection model to a second network device, the second network device including the lookup table, said request including at least one identification piece of information, and - the receipt of a response message to said identification request from the second network equipment, the response message including said at least one data representative of the interconnection model.

[0019] According to another feature, the signaling message is: - a registration message issued by said user terminal, or - a message regarding the establishment, modification, or deletion of a session data emitted by said terminal, or - a message configuring a data session, or - an authentication message, or - a message requesting service usage for said network equipment.

[0020] In particular, the configuration message for a data session can be received by the network equipment. Similarly, the message for establishing, modifying, or deleting a data session can be sent by the terminal.

[0021] According to another feature, the identification method further comprises: - the storage by the network equipment in a user context of said at least one data point representative of the interconnection model, or - the selection of a third network device from said at least one representative data point of the interconnection model and the issuance of another signaling message to the third network device,

[0022]

[0023]

[0024]

[0025]

[0026]

[0027]

[0028] said other signaling message including said at least one data representative of the interconnection model. According to another characteristic, the third network device belongs to the second communication network. According to another characteristic, said at least one representative data point of the interconnection model is included in the group comprising: - an identifier for a type of network equipment, - a location for a type of network equipment within a communication network, - an identifier of said interconnection model, - priority information for said interconnection model, - a condition for the validity of said interconnection model, and - an identifier of another interconnection model compatible with said interconnection model. For example, and without limitation, the validity condition may be an applicability date of the interconnection model, one or more network slices applicable to the interconnection model, one or more identifiers or a range of identifiers of a user terminal. According to another characteristic, when said at least one representative data point corresponds to an interconnection pattern not supported by the network equipment, the identification process further includes: - the sending of a failure message to the user terminal, or - the selection of alternative network equipment supporting the interconnection model. According to another characteristic, the identification process further includes the sending, to the user terminal, of a response message to the signaling message including an interconnection pattern identifier. According to another characteristic, the network equipment implementing said identification process is: - an access and mobility management entity, or - a network interconnection management entity, or - a session management entity. Correspondingly, according to a second aspect of the invention, the invention also relates to a device for identifying an interconnection pattern between a first communication network and a second communication network, this identification device comprising at least one processor configured to: - receive a signaling message associated with a network procedure relating to at least one user terminal with a subscription to a third network, and - obtain at least one data point representative of the interconnection model between said networks, said at least one data point being an identifier of the interconnection model extracted from the signaling message or being obtained from a lookup table between at least one identification information of the third network extracted from the signaling message and said at least one data point.

[0029] The invention also relates, according to a third aspect of the invention, to a referencing device for at least one interconnection model between a first communication network and a second communication network, this referencing device comprising a lookup table between at least one identification piece of information of a third network with which a user terminal has a subscription and at least one data point representing the interconnection model, the referencing device comprising at least one processor configured to: - receive a request to identify the interconnection model, this identification request including the identification information, - to obtain, from the lookup table, at least one representative piece of data for the interconnection model, and - issue a response message to said request, the response message including said at least one data representative of the interconnection model.

[0030] The invention also relates, according to a fourth aspect of the invention, to a user terminal capable of sending and receiving signaling messages and user data on a first communications network, this terminal comprising at least one processor configured to send a signaling message to a network equipment of the first communication network, this signaling message comprising at least one identifier of an interconnection pattern between the first network and a second communication network.

[0031] The invention further relates, according to a fifth aspect of the invention, to a system comprising a device for identifying an interconnection pattern between a first communication network and a second communication network according to the second aspect of the invention, this system also comprising a referencing device according to the third aspect of the invention and / or a terminal according to the fourth aspect of the invention.

[0032] The invention further relates to a computer program comprising instructions for implementing an identification process as described above, when this program is executed by a processor, as well as at least one computer-readable information carrier comprising instructions for a computer program as mentioned above.

[0033] The method according to the invention can be implemented in various ways, including in wired or software form. Brief description of the figures

[0034] The invention will be better understood with the aid of the following description, given solely by way of example and made with reference to the accompanying drawings in which: - [Fig.1] is an example of interconnection between a local communication network and a remote network according to a first embodiment of the invention; - [Fig.2] illustrates the main steps of an identification process, according to the first embodiment of the invention, implemented by an AMF function during a network procedure for registering a user terminal; - [Fig.3] illustrates the main network messages exchanged during the network registration procedure according to the first embodiment of the invention; - Fig. 4 illustrates two examples of a lookup table associating identifiers of an interconnection model between two communication networks with a list of network functions; - [Fig.5] is an example of interconnection between a local communication network and a remote network via an aggregator network according to a second embodiment of the invention; - [Fig.6] illustrates an example of a correspondence table between at least one network identification piece of information and at least one representative data point of an interconnection model between communication networks; - [Fig.7] illustrates the main steps of an identification process, according to the second embodiment of the invention, implemented by an AMF function during a network procedure for registering a user terminal; - [Fig.8] illustrates the main network messages exchanged during the network registration procedure according to the second embodiment of the invention; - Figure 9 illustrates an example of a lookup table associating identifiers from an interconnection model between an aggregator network and a remote network with a list of network functions; and - [Fig. 10] illustrates the main network messages exchanged during the network procedure for establishing a data session according to the second embodiment of the invention. Detailed description of the invention

[0035] The following description presents examples of several embodiments based on a 5G mobile network architecture, but the invention also applies to other prior or future architectures, such as, for example, a 4G or 6G architecture. The example of a mobile access network is not limiting, and any type of access remains applicable, including mobile or non-mobile access, for example, satellite access. The access network is not necessarily within the local network and may, in particular, be a network shared between different operators ("network sharing").

[0036] Fig. 1 is an example of interconnection between a local communication network LNET and a remote communication network HNET according to a first embodiment of the invention.

[0037] In the example described, the user of a user equipment (UE) wishes to access a service via a local communication network (LNET) operated by an operator having an interconnection agreement with the operator of a remote network, for example the remote network (HNET), with which the user of the UE has subscribed.

[0038] The LNET and HNET networks are interconnected via a data exchange network, for example of the IP (“Internet Protocol”) type, the LNET and HNET networks being connected to the exchange network via SEPP proxies (in English “Security Edge Protection Proxy”), noted in the example presented here as 1SEPP for the local network and hSEPP for the remote network, in accordance with the 3GPP TS 23.501 standard. In this way, data exchanges between the local LNET network and the remote HNET network are secured.

[0039] The local communication network LNET comprises: - an access network (AN), for example of the radio access network (RAN) type, - an access and mobility management function, or AMF (Access and Mobility Management Function), and - an XDMXid lookup table, two illustrative examples of which are shown in [Fig.4].

[0040] In the example described here, the AMF function includes the XDMXid lookup table. Alternatively, this XDMXid lookup table can be hosted in another function of the local LNET communication network.

[0041] The XDMXid lookup table associates a Xid identifier of an interconnection model between the local communication network LNET and another communication network with an NF_type list of network function types, each network function in this NF_type list being itself associated with an NF_NI location within one of the interconnected networks. Each network function is located, according to the NF_NI location, either in the local network LNET, in the remote network HNET, or in an aggregator network ANET through which the local communication network LNET and the remote communication network HNET are interconnected. An example of interconnection with such an aggregator network is presented later with reference to the second embodiment of the invention.

[0042] In this example, the XDMXid table contains the network functions in each relevant network, namely the local network, the aggregator network (if applicable), and the remote network. Alternatively, the XDMXid table may contain only the network functions located in the first network and those located in the second network directly connected to it. For models without an aggregator, the XDMXid table in the local network contains the network functions of both the local and remote networks. For models with an aggregator, the XDMXid table in the local network contains the network functions of both the local and aggregator networks, while the XDMXid table in the aggregator network contains the network functions of both the aggregator network and the remote network. Furthermore, for models without an aggregator, the table may contain either the functions of the local network, the functions of the remote network, or both.By default, in the case where a network function is not contained in the table, it is assumed to be in the same network as the network function that consults the table.

[0043] It is noted that in the example considered here, it is assumed that the network repository function or NRF function (from the English "Network Repository Function") is never represented in the table because any network function that needs to select another network function can use the NRF function according to the TS 23.501 standard.

[0044] Furthermore, in the example described here, the XDMXid lookup table is consulted based on a single criterion, namely the model identifier, with the assumption that the naming of interconnection models has the same meaning for all operators. Alternatively, the XDMXid lookup table can be consulted using both the model identifier and a network identifier simultaneously. In this way, it is possible to interconnect networks whose operators use the same model naming to identify different models (i.e., with a different distribution of network functions). Thus, the Mod_l model can, according to the network identifiers associated with it refer to different function distributions as is apparent for the Op_A and Op_B operators in the TAB table of [Fig.6] described later.

[0045] To subsequently access at least one service via the local communication network LNET, the user terminal UE initiates a network procedure, in this case a registration procedure, during which the AMF function implements a method for identifying an interconnection pattern between the local communication network LNET and the remote network HNET, according to the invention.

[0046] The main steps implemented by the AMF function according to this first embodiment of the invention are now presented in relation to [Fig. 2]. Furthermore, [Fig. 3] presents a flow diagram illustrating the messages exchanged between the user terminal UE, the various functions of the local communication network LNET, and the various functions of the remote network HNET during the implementation of the user terminal UE registration procedure.

[0047] It is assumed here that the user of the user terminal (UE) wishes to access a service using a particular network slice identified, for example, by means of an S-NSSAI identifier as defined in the 3GPP TS 23.501 standard. It is further assumed in the example described here that this S-NSSAI identifier has the value S-NSSAI_2 at the time of the service request, that is, at the time of the subsequent activation of a data session. Moreover, during the registration request, the user terminal (UE) provides a set of network slice(s) in a Requested NSSAI as defined in the 3GPP TS 23.501 standard. It is assumed in the example described here that: Requested NSSAI = {S-NSSAI 1, S-NSSAI 2, S-NSSAI 3}

[0048] The user terminal UE transmits a ReReg registration request to the AMF function via a base station (not shown) of the radio access network RAN ​​of the local communication network LNET. This ReReg registration request is a signaling message associated with the user terminal UE registration procedure.

[0049] This ReReg registration request is, in the example described here, similar to a Registration Request, as defined by the 3GPP TS 23.502 standard (e.g., version 19.1.0) and TS 24.501 standard (e.g., version 19.0.0), but differs from it in that, in addition to the fields defined by this standard, it includes a XidP identifier, representing a proposed interconnection model between the local communication network LNET and the remote network HNET, which the user terminal UE wishes to use. In the example described here, the XidP identifier is, for example, equal to the value Mod_3.

[0050] Indeed, the user terminal UE can be configured with interconnection model identifiers, here named XidS, to which it has subscribed, for example, via OAM (Operations And Maintenance) or OTA (Over The Air) mechanisms, or via a "UE configuration update" type procedure according to the TS 23.502 standard, except that the configuration request contains a field for model identifiers and that a model identifier can be associated with at least one type of S-NSSAI network slice, for example, for 4 slices as follows: S-NSSAI_1, XidS= (Mod_l, Mod_2, Mod_3, Mod_15) S-NSSAI_2, XidS= (Mod_3, Mod_4, Mod_5, Mod_7) S-NSSAI_3, XidS= (Mod_6) S-NSSAI 4, XidS=(Mod_10)

[0051] During a step 100, the ReReg query is received by the AMF function.

[0052] During step 110, the AMF function retrieves its internal configuration The information on its support for the method of identifying an interconnection model according to the invention. In the example described here, the AMF function includes a binary identifier X_Supp indicating whether it supports the identification method (state "ON") or not (state "OFF"). The absence of a value for this parameter is equivalent here to a value "OFF". Alternatively, a tag present (equivalent to X_Supp="ON") or absent (equivalent to X_Supp="OFF") can be used. Alternatively, the LNET local network is such that all the functions of the LNET local network support the identification method according to the invention. In this case, step 110 is an optional step that is not performed.According to another variant, the trigger point for implementing the identification process is not just a single criterion such as the presence of the identifier X_Supp or a value of this identifier but a combination of criteria such as this identifier and for example the type of signaling message, for example a registration request.

[0053] The AMF function then checks the status of its support for the method of identifying an interconnection model according to the invention in step 120. If the identification method is not supported by the AMF function (X_Supp identifier state “OFF”) in step 120, the function sends, during step 125, a failure message X_Supp_KO to the user terminal (UE). This failure message X_Supp_KO is received by the user terminal, which is therefore not registered.

[0054] Alternatively (instead of rejecting the request), the AMF function can continue the registration procedure according to a default registration procedure, for example, typically according to the roaming registration procedure described by the 3GPP TS 23.502 standard.

[0055] In another variant (where only certain network functions support the process), the AMF function can select, if it exists, a new AMF function supporting the identification process according to the invention, and transmitting the ReReg request to him.

[0056] If the AMF function supports the method of identifying an interconnection pattern according to the invention, then during a step 130, the AMF function detects that the ReReg request includes a XidP identifier and extracts this XidP identifier from this ReReg request.

[0057] During a step 140, the AMF function optionally verifies that it supports the XidP interconnection model according to the invention.

[0058] In the example described here, the AMF function includes a binary identifier Xid_Supp indicating whether the interconnection model is currently supported (state "ON") or not (state "OFF") for the model proposed by the terminal, i.e. XidP= Mod_3 in our example or includes information on the interconnection model(s) it supports, for example AMF supports the following interconnection models Mod_l, Mod_2, Mod_3 (Xid_Supp=Mod_l, Mod_2, Mod_3).

[0059] Alternatively, the LNET local area network can be configured so that all the AMF functions of the LNET local area network support all interconnection patterns according to the identification method of the invention. In this case, step 140 is an optional step that is not performed. According to another embodiment, the trigger point for implementing the identification method is not only a single criterion such as the presence of the identifier Xid_Supp or a value of this identifier, but a combination of criteria such as this identifier and, for example, the type of signaling message, for example, a registration request. If the XidP interconnection pattern is not supported by the AMF function (state “OFF” of the identifier Xid_Supp), the latter sends, during step 150, a failure message XidP_KO to said user terminal. This failure message XidP_KO is received by the user terminal, which is therefore not registered.

[0060] Alternatively (instead of rejecting the request), the AMF function can select, if it exists, a new AMF function supporting the XidP model according to the identification process, and forward the ReReg request to it.

[0061] According to another variant, the AMF function can continue the registration procedure according to a default registration procedure, for example, typically according to the roaming registration procedure described by the 3GPP TS 23.502 standard.

[0062] If the XidP interconnection model is supported by the AMF function, the AMF function identifies, during step 160, the network functions necessary to continue the registration procedure. This identification is performed by consulting the XDMXid lookup table. If the interconnection model Since XidP is absent from the XDMXid table, the AMF function, during step 165, sends a XidP_KO failure message to the user terminal (UE). This XidP_KO failure message is received by the user terminal, which is therefore not registered.

[0063] Thus, in the example described here (see [Fig. 4]), consulting the XDMXid lookup table allows the AMF function to identify that the Mod_3 interconnection model to be implemented comprises, for recording purposes, three functions located in the local communication network LNET and one function located in the remote network HNET, namely the AUSF, UDM, and PCF functions (note that the SMF and UPF functions are not involved in recording). In a variant, the functions useful for recording and the functions useful for the data session are separated in the XDMXid table, the table being consulted both on a model identifier criterion and a query type. The data format presented in this table is given for illustrative purposes only.Thus, the format for the NF_NI parameter identifying the network location (local network versus remote network) in which the function should be located can take, for example, the form of a string of characters ("local" versus "remote") or a network identifier, for example in the standard format of a domain name (as defined in the IETF RFC 7542 document), the latter being able to take a specific format for the identification of an aggregator network.

[0064] In the Mod_3 model example, the function located in the remote HNET is a unified data repository, referred to as the UDR (Unified Data Repository). This UDR is a database storing the user profile of the UE (User Terminal). This profile includes the UE's subscription rights, including service access data and access and mobility data, such as the identifiers of the authorized XidS interconnection models for each subscribed network slice. Thus, the user profile includes, for example, the following associations between subscribed network slices and authorized interconnection models: S-NSSAI_1, XidS= (Mod_l, Mod_2, Mod_3, Mod_15) S-NSSAI_2, XidS= (Mod_3, Mod_4, Mod_5, Mod_7) S-NSSAI_3, XidS= (Mod_6) S-NSSAI4, XidS=(Mod_10).

[0065] As mentioned previously, the three functions located in the local LNET communication network involved in the registration procedure are: - an authentication server function, known as the AUSF function (from the English "Authentication Server Function"), - a unified data management function, known as UDM (Unified Data Management), and - a policy control function, known as the PCF function (from the English "Policy Control Function").

[0066] After identifying the interconnection model to be implemented, the AMF function selects, in step 170 and in accordance with the Mod_3 interconnection model, the AUSF function of the local communication network LNET in order to authenticate the user terminal UE. This selection is made, for example, in accordance with the 3GPP TS 23.501 standard, except that the AUSF function is selected here (using the NF NI="local" information from the XDMXid table for the Mod_3 model) in the local network LNET and not in the remote network HNET.

[0067] During step 180, the AMF function communicates, via authentication messages, with the AUSF function and the user terminal UE to authenticate the latter. To do this, at least one authentication message to the AUSF function contains the identifier of the identified model Mod_3. During this authentication, the AUSF function selects the UDM function of the local communication network LNET (and not in the remote network HNET) according to the identified model Mod_3, and obtains authentication data from this UDM function. This authentication is, for example, performed in accordance with the so-called AKA (Authentication and Key Agreement) procedure as described in the 3GPP TS 33.501 standard (version 19.0.0).

[0068] Following authentication of the user terminal UE, during a step 190, the AMF function selects, in accordance with the Mod_3 interconnection model, the UDM function of the local communication network LNET.

[0069] The AMF function verifies with the UDM function, in step 200, that the user's UE subscription allows them to register according to the desired Mod_3 interconnection model. In this step 200, the AMF function obtains, in particular, the user profile describing the UE's DR subscription rights, including the network slice identifiers of the XidS models subscribed to by the user. This is obtained through the exchange of signaling messages between the AMF function and the UDM function (which itself interacts with the UDR database), at least one of these signaling messages including the XidP identifier of the Mod_3 interconnection model. In this step 200, the UDM function selects the UDR function in the remote HNET and not in the local LNET, in accordance with the Mod_3 model.

[0070] If the user profile does not indicate authorization to use the Mod_3 interconnection model for at least one of the network slices requested in the Requested NSSAI (i.e., for all network slices in the Requested NSSAI, the XidS identifier cannot take the value Mod_3), then the AMF function transmits a failure message to the UE user terminal during step 210. XidP_NSo is being sent to the user terminal UE. This XidP_NSo failure message indicates that the Mod_3 model has not been subscribed to for any of the requested tranches and therefore the user terminal UE is not registered.

[0071] Optionally, this failure message may also contain the identifiers of the subscribed XidS models per subscribed network slice to inform the terminal of the possible models supported per slice. This failure message may optionally be followed by a message transmitted to the user terminal (UE) (for example, of the type UE configuration update) informing this UE of the subscribed XidS models per network slice. It is assumed in the invention that the UE can interpret the XidS fields received per network slice and that it stores the model identifiers with the network slice identifiers (the slice identifiers being sent by the AMF function and stored by the terminal as described in the 3GPP TS 23.501 standard).Alternatively (instead of rejecting the request), the AMF function can restart a registration procedure according to a default registration procedure, for example, typically according to the roaming registration procedure described by the 3GPP TS 23.502 standard.

[0072] Otherwise, if the terminal is authorized by its subscription to use the Mod_3 model for at least one network slice of the Requested NSSAI (in the example described here, these are the slices identified as S-NSSAI 1 and S-NSSAI 2), the AMF function saves, during step 220, in a UE_C user context, the XidP identifier of the Mod_3 interconnection model as well as the identifiers S-NSSAI_1 and S-NSSAI_2 of the subscribed network slices associated with this model. Alternatively, the AMF function also saves the other identifiers of the interconnection models that are supported by these slices. S-NSSAI_1, XidP= Mod_3, XidS= (Mod_l, Mod_2, Mod_3, Mod_15) S-NSSAI_2, XidP= Mod_3, XidS= (Mod_3, Mod_4, Mod_5, Mod_7).

[0073] The preceding representation is given by way of example, but others, for example the representation below, are possible, for example to avoid repetition of the proposed model: XidP= Mod_3 S-NSSAI_1, XidS= (Mod_l, Mod_2, Mod_3, Mod_15) S-NSSAI_2, XidS= (Mod_3, Mod_4, Mod_5, Mod_7).

[0074] In another variant, the AMF function saves the XidP model identifier as well as all subscribed interconnection models for all subscribed tranches: S-NSSAI_1, XidP= Mod_3, XidS= (Mod_l, Mod_2, Mod_3, Mod_15) S-NSSAI_2, XidP= Mod_3, XidS= (Mod_3, Mod_4, Mod_5, Mod_7) S-NSSAI_3, XidS= (Mod_6). S-NSSAI_4, XidS= (Mod_10).

[0075] The above representation is given by way of example, but others, for example the representation below, are possible, for example to avoid repeating the proposed model: XidP= Mod_3 S-NSSAI_1, XidS= (Mod_l, Mod_2, Mod_3, Mod_15) S-NSSAI_2, XidS= (Mod_3, Mod_4, Mod_5, Mod_7) S-NSSAI_3, XidS= (Mod_6). S-NSSAI_4, XidS= (Mod_10).

[0076] The AMF function also saves in the UE_C user context the network slice identifiers from the Requested NSSAI that are rejected (Rejected NSSAI according to the TS 23.501 standard; in the example above, a Rejected NSSAI is S-NSSAI 3), those that are allowed (Allowed NSSAI according to the TS 23.501 standard; in the example, S-NSSAI 1, S-NSSAI 2), those that are pending authorization (Pending NSSAI according to the TS 23.501 standard; not shown in the example), and those that are partially allowed (Partially Allowed NSSAI) or partially rejected (Partially Rejected NSSAI) (not shown in the example). Thus, we have: Allowed NSSAI = {S-NSSAI 1, S-NSSAI 2} Rejected NSSAI = {S_NSSAI 3} - Pending NSSAI ={}, Partially Allowed NSSAI={}, Partially Rejected NSSAI={}

[0077] During step 230, the AMF function selects, if necessary and in accordance with the Mod_3 interconnection model, the PCF function of the local communication network LNET. The interaction between the AMF function and the PCF function is then carried out, for example, in accordance with the 3GPP TS 23.501 standard.

[0078] Finally, during step 240, the AMF function transmits a Reg_OK registration acceptance message to the user terminal, including the Allowed NSSAI identifiers, which in our example are the S-NSSAI 1 and S-NSSAI 2 identifiers, possibly with the XidP Mod_3 identifier. The Reg_OK message also includes any Rejected NSSAI, as well as any Pending NSSAI, Partially Allowed NSSAI, and Partially Rejected NSSAI. Alternatively, the AMF function provides all subscribed interconnection models for all subscribed tranches requested in the Requested NSSAI. Therefore, in our example, the AMF function transmits: Allowed NSSAI = {S-NSSAI 1, S-NSSAI 2} Rejected NSSAI = {S_NSSAI 3} - Pending NSSAI ={}, Partially Allowed NSSAI={}, Partially Rejected NSSAI={} S-NSSAI_1, XidP= Mod_3, XidS= (Mod_1, Mod_2, Mod_3, Mod_15) S-NSSAI_2, XidP= Mod_3, XidS= (Mod_3, Mod_4, Mod_5, Mod_7) - S-NSSAI_3, XidS= (Mod_6). This last line is optional as explained previously.

[0079] Furthermore, the line "S-NSSAI_4, XidS= (Mod_10)" is optional because the identifier S-NSSAI 4 is not present in the Requested NSSAI requested.

[0080] Upon receipt of this registration acceptance message, the user terminal UE is registered on the network. An example of data session establishment is described later in the second embodiment.

[0081] We will now describe, with reference to [Fig. 5], an example of interconnection between a local communication network LNET and a remote network HNET according to a second embodiment of the invention. In the description of this second embodiment, the elements already described with reference to the preceding figures retain the same reference numerals.

[0082] In the example described in [Fig.5], the local communication network LNET and the remote network HNET are interconnected via an aggregator network ANET and communicate with each other via SEPPs.

[0083] . It is also assumed in this example that the AMF function supports the process identification according to the invention. Therefore, steps 110, 120, and 125 described previously are not applied in this example. It is also assumed that the AMF function supports all types of models, which implies that steps 140 and 150 described previously are not applied in this example.

[0084] The local communication network LNET further includes a network interconnection pattern referencing device, called the XDMF function, hosting a lookup table T AB between at least one ID_Res identifier of the remote network HNET and at least one representative data point of a network interconnection pattern. Figure 6 shows an excerpt from an example of such a T AB table.

[0085] The main steps implemented by the AMF function according to this second embodiment of the invention are now presented in relation to [Fig. 7]. Furthermore, [Fig. 8] presents a flow diagram illustrating the messages exchanged between the user terminal UE, the various functions of the local communication network LNET, the various functions of the aggregator network ANET, and the various functions of the remote network HNET when the AMF function implements the steps described in [Fig. 7].

[0086] As in the first embodiment of the invention, the user terminal (UE) transmits a ReReg' registration request to the AMF function via a base station (not shown) of the radio access network (RAN) of the local area network (LNET). In the example described here, this ReReg' registration request is a Registration Request, as defined by the 3GPP TS 23.502 and TS 24.501 standards, notably with a Requested NSSAI. However, it differs from the ReReg request of the first embodiment in that it does not include a field for transmitting a XidP identifier of the interconnection model that the user terminal (UE) wishes to use, even though it has subscribed to certain model(s) with certain network slice(s).

[0087] During a step 1000, the AMF function therefore receives the ReReg' registration request.

[0088] During a step 1010, the AMF function determines, from this ReReg' query, an ID_Res identifier of the remote HNET from an ID_UE identifier of the user terminal. For example, the AMF function determines an ID_Res identifier of the remote HNET of type HNI (Home Network Identifier) ​​from an ID_UE identifier of type SUPI (Subscription Permanent Identifier) ​​or SUCI (Subscription Concealed Identifier) ​​of type as defined by the 3GPP TS 23.003 standard (for example, version 19.0.0). In the example described here, it is assumed that the ID_Res identifier of the remote HNET has the value "Op_A".

[0089] During a step 1020, the AMF function transmits a Rid identification request of the interconnection model to the XDMF function on the basis of the ID_Re identifier.

[0090] Upon receiving this Rid identification request, the XDMF function identifies the interconnection model and the location (local network, aggregator, remote) of the network functions to be implemented to register the user terminal (UE). This identification is performed by consulting the XDMF function's TAB lookup table. In other words, the TAB lookup table is queried based on the remote network identifier (HNET) extracted from the Rid identification request.

[0091] Thus, in the example described here, consulting the TAB lookup table allows the XDMF function to identify that the interconnection model to be implemented, based on the ID_Res identifier of the remote network HNET with the value Op_A, may be the Mod_1, Mod_3, Mod_4 or Mod_5 model, representing the possible models for reaching the remote network HNET of the operator Op_A from the local network LNET according to the agreements concluded between the operators of the local, aggregator and remote networks.

[0092] The XDMF function then selects a particular model from among these possible models. For example, the XDMF function can choose the first model listed in the lookup table TAB (model Mod_1). Alternatively, the XDMF function can choose the model based on the ID_Res identifier of the remote network HNET and at least one other model validity criterion, called an additional criterion, for example, a Xid_Prio priority value contained in the lookup table TAB. Thus, the XDMF function can choose the model with the highest Xid_Prio priority (model Mod_3) or the lowest (model Mod_5). The priority data can be replaced by data indicating the default model (for example, with a Xid_default value in the table or a Xid_default value, for example Mod_3, placed in place of the priority values). This default model will be used, for example, when the user does not provide a XidP model.Another piece of data contained in the table could be consulted in addition to the Xid_Prio priority, namely, in this example, the validity of the model in terms of date (Xid_Date), for example, the days of the week (or alternatively, it could be a time slot on a regular day, for example, every Saturday evening or a single Saturday evening, for example, 20 / 11 / 24 from 8 PM to 11 PM). For example, in the lookup table TAB, we detect that the Mod_3 model is applicable from Monday to Friday (J1-J5) while it is currently Saturday. We then examine priority 2 and find that the Mod_l model, with priority 2, is not applicable for the same reason. We examine priority 3 and the Mod_4 model, being valid on Saturdays, is retained.

[0093] In another variant, the model is chosen based on a maximum number of slices supporting the model from among the slices received in the Rid request from the Requested NSSAI (slices requested by the user terminal UE). In the example with slices S-NSSAI_1, 2, and 3 requested during registration, the model with priority 1 is not valid for slice S-NSSAI_3. The search continues with priority 2, i.e., model Mod_l. Since all three slices are applicable, this model Mod_l is selected. The chronology is not mandatory, and variants can be considered where the order of examination of the selection criteria is different. For example, one can search for the set of models that cover all three slices.Thus, if we assume that the Mod_l model includes slices S-NSSAI_1 to 3 with priority 2 and the Mod_6 model (not shown in the table) includes slices S-NSSAI_1 to 3, S-NSSAI_5, S-NSSAI_8 with priority 5, then we choose the Mod_l model which has a higher priority than the Mod_6 model.

[0094] It should be noted that the additional criterion can be selected by the XDMF function or optionally passed by the AMF function to the XDMF function via the Rid identification query. In addition to the criteria previously As described, the additional criterion can also be chosen from the following non-exhaustive list: - a type of access, for example radio access, used by the user terminal UE, - the location of the user terminal UE, for example its location within certain cells or areas covered (in English, "tracking areas") by the local LNET network, - a private network identifier such as the DNN (Data Network Name), - a service identifier or service type requested by the user terminal (UE), - a requested network slice identifier (for example, an S-NSSAI identifier as described in the NSSAI column of the TAB table) and / or a network slice instance (for example, of type NSI for "Network Slice Instance"). - the date indicating, for example, the day (indicated, for example, by a Jl-J7 index of the day of the week and / or the time in a Xid_Date column of the TAB table) upon receipt of the signaling message, - network data as it exists at the time of receiving the signaling message, such as the load state of certain network functions (NFs), the energy consumption of NFs in the local network, aggregator network and / or remote network, which would imply the implementation of one model rather than another, - the type of query (e.g., record, data session configuration) and the type of function that queries the table (e.g., in the example described here, the AMF function), - a value or range of values ​​of SUPI (for example "range 068") in which the terminal identifier is located if the interconnection agreements provided for the use of different networks for a certain range of terminals, for example IoT terminals (for "Internet of Things") - a type of terminal for example IoT terminals or smartphone or headset etc... or a class of terminals, and economic information such as a financial cost that varies according to the interconnection models between networks.

[0095] Thus, the XDMF function can select the model based on the ID_Res identifier of the remote HNET network and a combination of at least two of the additional criteria described above. In the example described here, the XDMF function selects the Mod_4 model based on 2 additional criteria (Xid_Prio and Xid_Date).

[0096] In the described example, since the XDMF function has selected the Mod_4 model, the lookup table T AB also allows this XDMF function to identify that the implementation of this model requires the use of a PCF function located in the local communication network LNET, an XNF function (described later) located in the aggregator network ANET, and three other functions, namely the AUSF, UDM, and UDR functions, located in the remote network HNET. It should be noted that the SMF and UPF functions of the local network LNET, the aggregator network ANET, and the remote network HNET are not involved in the registration.

[0097] After consulting the TAB lookup table, the XDMF function then transmits a Rep response message to the AMF function in response to the Rid identification query.

[0098] During a step 1030, the AMF function receives the Rep. response message.

[0099] This response message includes, in the example described here, the Xid identifier of the Mod_4 interconnection model to be implemented and the LIST(NF) list of network functions (associated with the NF_type and NF_NI data) identified by the XDMF function as necessary for the implementation of the Mod_4 model and to be consulted by the AMF function.

[0100] In an alternative not described in [Fig. 7], the XDMF function may not select a particular model from among the possible models Mod_1, Mod_3, Mod_4, or Mod_5 and may instead transmit, in the Rep response message, the list of possible models (as well as the LIST(NF) list for each of these possible models) to the AMF function, which then selects the model to be applied locally. Alternatively, if the Rep response contains no interconnection data, for example, no model, the AMF function may continue the registration procedure according to a default registration procedure, for example, typically according to the roaming registration procedure described by the 3GPP TS 23.502 standard (and therefore without an aggregator).

[0101] To continue the registration of the user terminal UE, the AMF function must authenticate it by interacting with the AUSF function of the remote communication network HNET.

[0102] To this end, the AMF function identifies that the Mod_4 model is an aggregator network model since the LIST(NF) list includes an XNF function and / or an NF_NI identifier = "ANET" for at least one function (thus located in an ANET aggregator network). Indeed, the XNF function is an interconnection function in the aggregator network whose role is to transmit messages between LNET and HNET networks that are not directly interconnected. The AMF function then selects, in step 1040 and in accordance with the Mod_4 interconnection model, the XNF function of the ANET aggregator network to interact with the functions of the HNET network, including with an AUSF function selected based on the fact that it supports the Mod_4 model.

[0103] Thus, during a step 1050, the AMF function communicates, via the XNF function of the aggregator network, with the AUSF function of the remote HNET network and the user terminal UE to authenticate the latter.

[0104] In other words, the AMF function of the LNET network exchanges with the functions of the HNET network in accordance with the 3GPP TS 23.501 standard, except that the messages exchanged between the AMF function and the functions of the HNET network transit through the XNF function of the aggregator network. For this transit through the XNF function to be possible, at least some messages transmitted by the AMF function to the XNF function contain the Xid identifier of the interconnection model determined in the LNET network (Mod_4 in the example described here).

[0105] Thus, for example, during step 1050, the XNF function receives the authentication vector request message sent by the AMF function. This authentication vector request message differs from the Nausf_UEAuthenticate_authenticate Request message described in the 3GPP TS 33.501 standard in that it also includes a field to transmit the Xid identifier of the interconnection model used.

[0106] After receiving this modified Nausf_UEAuthenticate_authenticate Request message, the XNF function extracts from this message the Xid identifier of the interconnection model to be used and identifies the network functions necessary to continue the procedure. This identification is performed by consulting a lookup table XDMXid' shown in [Fig. 9], said lookup table XDMXid' associating a Xid identifier of an interconnection model between the ANET communication network and another communication network, for example the remote HNET network, with a list of network function types NF_type, each of the network functions in this NF_type list being itself associated with an NF_NI location within one of the interconnected networks.

[0107] Thus, in the example described here, consulting the XDMXid' lookup table makes it possible to identify that the implementation of this Mod_4 model requires, for registration, the use of three functions, namely the AUSF, UDM and UDR functions, located in the remote HNET network (it is noted that the SMF and UPF functions of the remote HNET network are not involved during registration).

[0108] Once the AUSF function in the remote HNET network is selected, the XNF function of the aggregator network forwards it the modified Nausf_UEAuthenticate_authenticate Request message.

[0109] Following authentication of the user terminal UE, during a step 1060, the AMF function communicates, in accordance with the Mod_4 interconnection model identified in the local network LNET and in the aggregator network ANET, with the UDM function of the remote communication network HNET via the XNF function of the aggregator network ANET.

[0110] During this step 1060, the AMF function obtains, in particular, the user profile describing the DR access and mobility rights, including the subscribed model identifiers (XidS) of the user by subscribed network slice type. This is obtained by exchanging signaling messages between the AMF function of the local network (LNET) and the UDM function of the remote network (HNET) via the XNF function of the aggregator network. Some of these signaling messages include the Xid identifier of the Mod_4 interconnection model. During this step 1060, the AMF function obtains the following profile in our example: S-NSSAI_1, XidS= (Mod_l, Mod_2, Mod_3, Mod_15) S-NSSAI_2, XidS= (Mod_3, Mod_4, Mod_5, Mod_7) S-NSSAI_3, XidS= (Mod_6) S-NSSAI 4, XidS= (Mod_10)

[0111] The AMF function verifies, during a step 1070, that the user's subscription of the UE user terminal allows him to use the Mod_4 interconnection model for at least one of the slices of the Requested NSSAI, namely S-NSSAI_1 to 3 in our example.

[0112] If the user profile does not indicate authorization to use the Mod_4 interconnection model for a network slice requested in the Requested NSSAI (i.e., for all network slices in the Requested NSSAI, the XidS identifier cannot take the value Mod_4), then the AMF function transmits, at step 1080, a Xid_NSo failure message to the UE. This Xid_NSo failure message indicates that the Mod_4 model has not been subscribed to and the UE is therefore not registered.

[0113] Optionally, this failure message may also contain the identifiers of the subscribed XidS models per authorized network slice to inform the terminal of the possible models supported per slice,

[0114] Optionally, this failure message can also be followed by a message transmitted to the UE user terminal (for example, of the type UE configuration update) informing the UE user terminal of the XidS models subscribed to per network slice. It is assumed in the invention that the UE terminal knows how to interpret the XidS fields received per network slice and that it stores the model identifiers with the network slice identifiers (the slice identifiers being sent by the AMF function and stored by the terminal as described in the 3GPP TS 23.501 standard).

[0115] Otherwise, if the terminal is authorized by its subscription to use the Mod_4 model for at least one network slice of the Requested NSSAI (in the example described here, this is S-NSSAI 2), the AMF function saves, during step 1090, in a UE_C user context, the Xid identifier of the Mod_4 interconnection model as well as the S-NSSAI_2 identifier. Alternatively, the AMF function also saves the other identifiers (Mod_3, Mod_4, Mod_5, Mod_7) of the interconnection models that are supported by this network slice whose identifier is S-NSSAI_2: S-NSSAI_2, XidP= Mod_4, XidS= (Mod_3, Mod_4, Mod_5, Mod_7).

[0116] Alternatively, the AMF function saves the Xid model identifier as well as all subscribed interconnection models for all subscribed tranches: S-NSSAI_1, XidS= (Mod_l, Mod_2, Mod_3, Mod_15) S-NSSAI_2, Xid= Mod_4, XidS= (Mod_3, Mod_4, Mod_5, Mod_7) S-NSSAI_3, XidS= (Mod_6). S-NSSAI_4, XidS= (Mod_10).

[0117] The AMF function also saves in the UE_C user context the network slices from the Requested NSSAI that are rejected (Rejected NSSAI according to the TS 23.501 standard; in the example above, a Rejected S-NSSAI is S-NSSAI 1 and 3), those that are allowed (Allowed NSSAI according to the TS 23.501 standard; in the example, S-NSSAI 2), and those (not shown in the example) that are pending authorization (Pending NSSAI), partially allowed (Partially Allowed NSSAI), or partially rejected (Partially Rejected NSSAI). Thus: Allowed NSSAI = {S-NSSAI 2} Rejected NSSAI = {S-NSSAI 1, S_NSSAI 3} - Pending NSSAI ={}, Partially Allowed NSSAI={}, Partially Rejected NSSAI={}

[0118] Then, in step 1100, the AMF function selects, if necessary and in accordance with the Mod_4 interconnection pattern identified in the LNET network, the PCF function of the LNET local communication network. The interaction between the AMF function and the PCF function is then carried out in accordance with the TS 23.501 standard.

[0119] Finally, during step 1110, the AMF function transmits a Reg_OK registration acceptance message to the user terminal, including the Allowed NSSAIs, which in our example include S-NSSAI 2, possibly with the XidP Mod_4 identifier. The Reg_OK message also includes any Rejected NSSAIs, as well as any Pending NSSAIs, Partially Allowed NSSAIs, and Partially Rejected NSSAIs. Alternatively, the AMF function transmits all interconnection models. subscribed for all tranches subscribed and requested in the Requested NSSAI. The AMF function therefore transmits in our example: Allowed NSSAI = {S-NSSAI2} Rejected NSSAI = {S_NSSAI 1, S_NSSAI 3} - Pending NSSAI ={}, Partially Allowed NSSAI={}, Partially Rejected NSSAI={} S-NSSAI_2, XidP= Mod_4, XidS= (Mod_3, Mod_4, Mod_5, Mod_7) - S-NSSAI_1, XidS= (Mod_1, Mod_2, Mod_3, Mod_15). This line is optional, as seen previously, because S-NSSAI_1 is not part of the Allowed NSSAI (Mod_4 is not supported for S-NSSAI_1). - S-NSSAI_3, XidS= (Mod_6). This line is optional as seen previously (Mod_4 not supported for S-NSSAI_3). - S-NSSAI_4, XidS= (Mod_10) » This line is optional because S-NSSAI 4 is not present in the requested NSSAI.

[0120] Upon receipt of this registration acceptance message, the user terminal UE is registered on the network.

[0121] In a first variant of this second embodiment, the XNF function does not include an XDMXid' lookup table, but the ANET aggregator network includes a network function XDMF' that hosts the XDMXid' lookup table. For example, the XDMF' function includes a lookup table between an interconnection pattern identifier, a network identifier ID_Res, and at least one representative data point of an interconnection pattern between the ANET and HNET communication networks.

[0122] In this first variant, during step 1050, the XNF function receives the modified messages (containing the Xid model identifier) ​​sent by the AMF function and, after receiving these messages, the XNF function extracts from them the Xid identifier of the interconnection model to be used. From this Xid identifier of the interconnection model, the XNF function queries the XDMF' function to identify the network functions necessary to continue the procedure.

[0123] In a second variant of this second embodiment, the XDMXid' lookup table or the XDMF' function lookup table includes, instead of the NF_NI locations of the network functions within the interconnected networks, the NRF_ID identifiers of the network function discovery network functions, known as NRF (Network Repository Function) functions, of the ANET aggregator network and the HNET remote network. These network function discovery network functions, as defined in the 3GPP TS 23.501 standard, then allow the identification of the network functions useful for contacting during the network procedure in each of the interconnected networks to be obtained. This discovery This can possibly be done by indicating to the NRF function a need for interconnection process support and / or interconnection model support, the AMF, XNF, SMF functions at least needing such support to interact with the XDMF or XDMXid functions.

[0124] In the various described variants of the second embodiment, the lookup table XDMXid' and the lookup table of the function XDMF' may also include a mapping of an interconnection model identifier between the local network and the aggregator network with an interconnection model identifier between the aggregator network and the remote network (replacement Xid data denoted Xid_Remp). In this way, it is possible to use different naming conventions between different networks to identify the same interconnection model. Thus, for example, a model identified as Mod_4 by the local network LNET for interconnecting with the remote network HNET via the aggregator network ANET can be identified by the aggregator network ANET as the model referenced Mod_4' for interconnecting with the remote network HNET.

[0125] In the case of different model naming conventions in the local LNET and remote HNET networks, as mentioned previously, the aggregator network, and in particular the XNF function, will be responsible for associating the identifiers of the two models. Thus, the XNF function will replace Mod_4 with Mod_4' for messages destined for the remote HNET network, and the XNF function will replace Mod_4' with Mod_4 in messages destined for the local LNET network. In this example, the XNF function will also have to modify the XidS subscription identifiers returned by the UDM to the AMF function, since the UDM function is located in the remote HNET network, by associating them with the corresponding models valid in the local LNET network.Thus, if XidS= Mod_4' in the remote HNET network then the XNF function will return to the AMF function of the local LNET network the associated identifier (called Xid_Remp stored in the XDMXid' table) i.e. XidS'= Mod_4 (to be used by the UE user terminal in the local LNET network) and XidS=Mod_4' (to be used by the UE user terminal if it connects from its home network).

[0126] Following the registration of the user terminal UE on the network, we will now describe, with reference to [Fig. 10], the establishment of a data session, called a PDU session (in English "Packet Data Unit") so that this user terminal can receive or transmit data on the local LNET network.

[0127] To this end, the user terminal UE transmits, during step 1200, a PDU session establishment request denoted PDU_EST to the AMF function via a base station (not shown) of the RAN radio access network of the LNET local communication network. This PDU_EST request is The example described here is a PDU Session Establishment Request, as defined by the 3GPP TS 23.502 and TS 24.501 standards, but modified to include an additional field for transmitting a XidP identifier for an interconnection model that the UE (User Endpoint) wishes to use. In this example, the XidP identifier is assumed to be Mod_5, and the requested network slice is S-NSSAI_2.

[0128] Upon receipt of the PDU_EST request, during a step 1201, the AMF function of the local network LNET detects that the PDU_EST request includes a XidP identifier and extracts, during a step 1202, from this PDU_EST request this XidP identifier.

[0129] According to one variant, the AMF function retains the Mod_4 pattern stored in the UE_C user context for the S-NSSAI_2 network slice (without considering the proposed Mod_5 pattern) and proceeds with the establishment of the PDU session using the Mod_4 pattern. As a reminder, in our example, the AMF function saved, during terminal registration, the Xid=Mod_4 pattern and the information for allowed, rejected, pending, partially allowed, or partially rejected slices (Allowed NSSAI, Rejected NSSAI, Pending NSSAI, Partially Allowed NSSAI, and Partially Rejected NSSAI), and optionally the subscribed slices with their patterns: Allowed NSSAI = {S-NSSAI 2} Rejected NSSAI = {S-NSSAI 1, S_NSSAI 3} - Pending NSSAI ={}, Partially Allowed NSSAI={}, Partially Rejected NSSAI={} S-NSSAI-l, XidS= (Mod_l, Mod_2, Mod_3, Mod_15) S-NSSAI_2, Xid= Mod_4, XidS= (Mod_3, Mod_4, Mod_5, Mod_7) S-NSSAI_3, XidS= (Mod_6). S-NSSAI_4, XidS= (Mod_10).

[0130] According to another embodiment, the AMF function verifies, during step 1203, that this identifier XidP=Mod_5 is possible for the requested network slice S-NSSAI_2 and compatible with the registration model Mod_4. Two interconnection models are said to be compatible if the functions implemented according to these two models during the user terminal registration procedure are located in the same networks. To perform this compatibility search, the AMF function can, for example, first query a compatibility table listing the compatible interconnection models for each interconnection model supported by the network. This compatibility table can, for example, be located locally within the AMF function and be included in the XDMXid table. Alternatively, the compatibility table can be located within the XDMF function and be included in the T AB table described previously in connection with [Fig. 6]. In the example described here and illustrated in [Fig. 6], the TAB table includes a column titled Xid_Comp listing the compatible models, and the Mod_5 model is compatible with the Mod_4 model. Subsequently, the AMF function can verify that the network slice requested in step 1200, S-NSSAI 2, supports the Mod_5 compatible interconnection model, which is the case in our example. Alternatively, the verification is performed with a single query of the TAB table to check that the S-NSSAI_2 network slice is authorized with the proposed Mod_5 model, or failing that, that a model compatible with the Mod_5 model exists, specifically the Mod_4 model stored during registration.

[0131] If the network slice requested in step 1200 does not support the requested interconnection pattern, or an interconnection pattern compatible with the requested one, or the pattern stored in the UE_C user context, the AMF function issues a XidP_KO failure message to the said UE user terminal in step 1205. The XidP_KO failure message may contain pattern information stored in the UE_C user context (with different variants as seen previously during registration).

[0132] In the case where the AMF function has not taken into account the proposed XidP pattern, or in the variant where the AMF function associates a Mod_4 pattern compatible with the Mod_5 pattern for the S-NSSAI_2 network slice, the AMF function continues the procedure for establishing a PDU session for the user terminal UE based on the network slice requested in step 1200 and an interconnect pattern identified by a pattern identifier Xid (equal to the proposed XidP identifier = Mod_5, or to the identifier of an interconnect pattern compatible with the pattern identified by the proposed XidP identifier, or the pattern stored during the Mod_4 registration). In the remainder of the example described here, it will be assumed that the Xid identifier is equal to the Mod_4 identifier.

[0133] Thus, the AMF function identifies the location (local network, aggregator, remote) of the functions to be implemented to establish a PDU session for the user terminal UE. This identification is performed, for example, during step 1206, by consulting the lookup table TAB by querying the XDMF function based on the interconnection model identifier Xid (Mod_4). In other words, the AMF function obtains, by querying the XDMF function, the list LIST(NF) (also containing the NF_type and NF_NI data) of network functions to be implemented to establish the PDU session.

[0134] In the example described here, the LIST(NF) list allows the AMF function to identify that the Mod_4 interconnection model to be implemented includes an SMF function and a UPF function located in the local communication network LNET, referenced respectively by SMF-L and UPF-L on the [Fig.5].

[0135] Based on this information, the AMF function selects, in step 1207, the SMF-L function of the local network LNET and transmits to it, in step 1208, a PDU session configuration message named in the example described here PDU_RCS. This request is, for example, of type Nsmf_PDUSession_CreateSMContext as described in the 3GPP TS 23.502 standard, modified to include a field corresponding to the Xid identifier of the Mod_4 interconnection model to be implemented.

[0136] Upon receipt, during a step 1209, of this PDU_RCS message, the SMS-L function selects, during a step 1210, a UPF-L function supporting the Mod_4 interconnection model, then dialogues, during a step 1211, with this UPF-L function to establish an N4 session between SMF-L and UPF-L.

[0137] Then, in step 1212, the SMF-L function identifies the function(s) to be selected in the aggregator network to continue establishing the PDU session. For example, this identification is done by querying the XDMF function based on the Xid identifier transmitted to the SMF-L function by the AMF function using the PDU_RCS message.

[0138] Thus, in the example described here, the XDMF function indicates to the SMF-L function that the implementation of the Mod_4 pattern to establish a PDU session requires the use of the XNF function located in the ANET aggregator network.

[0139] Based on this information, the SMF-L function selects, in a step 1213, the XNF function of the ANET aggregator network and transmits to it, in a step 1214, the PDU_RCS message for configuring the PDU session.

[0140] Upon receipt, during a step 1215, of this PDU_RCS message, the XNF function extracts, during a step 1216 not shown in [Fig.10], from this message the Xid identifier of the interconnection model to be used and identifies the network functions necessary to continue the procedure by querying the XDMXid' table during a step 1217.

[0141] In the example described here, this query enables the XNF function to identify that the Mod_4 interconnection model to be implemented includes an SMF function and a UPF function located in the ANET aggregator communication network (referenced respectively by SMF-A and UPF-A) as well as an SMF function and a UPF function located in the HNET remote network (referenced respectively by SMF-H and UPF-H).

[0142] The XNF function then selects, in a step 1218, the SMF-A function of the ANET aggregator network and transmits to it, in a step 1219, the PDU_RCS message of configuration of the PDU session with the Xid interconnection model.

[0143] Upon receipt, during step 1220, of this PDU_RCS message, the SMF-A function selects, during step 1221, the UPF-A function of the ANET aggregator network, then dialogue, during a step 1222, with this UPF-A function to establish an N4 session between SMF-A and UPF-A.

[0144] Then, in step 1223, the SMF-A function sends a PDU_RCS configuration message to the XNF function to continue establishing the PDU session

[0145] Upon receiving this PDU_RCS message at step 1224, the XNF function selects the SMF-H function in the remote HNET network at step 1225 and transmits the PDU_RCS message to it at step 1226. Alternatively, at step 1225, the XNF function can query the XDMXid' table to retrieve a replacement identifier called Xid_Remp for Mod_4 in the case of different model naming conventions in the local LNET and the remote HNET network. If the Xid_Remp is present for Mod_4, then the XNF function selects the SMF-H function in the remote HNET network based on the Xid_Remp and transmits the PDU_RCS message with the Xid_Remp to it at step 1226.

[0146] Upon receipt, during a step 1227, of the PDU_RCS message, the SMF-H function selects, during a step 1228, a UPF-H function in the remote HNET network supporting the Mod_4 interconnection model and dialogues, during a step 1229, with this UPF-H function to establish an N4 session between SMF-H and UPF-H.

[0147] Finally, the SMF-H function transmits, at a step 1230, to the XNF function a PDU_RCS_OK message confirming the establishment of the PDU session between the ANET aggregator network and the HNET remote network, a PDU_RCS_OK message which the XNF function relays to the SMF-A function which, in turn, relays it to the XNF function, the latter relaying it, at a step 1231, to the SMF-L function, this SMF-L function itself relaying, at a step 1232, this message to the AMF function.

[0148] Upon receipt, during a step 1233 of this PDU_RCS_OK message, the AMF function transmits, during a step 1234, to the user terminal UE a message confirming the establishment of the PDU session.

[0149] It is noted that steps 1201 to 1208 and 1233 to 1234 implemented by the AMF function correspond to steps of a method for identifying an interconnection pattern according to the invention.

[0150] Similarly, it is noted that steps 1209 to 1214 and step 1232 implemented by the SMF-L function also correspond to steps of a method for identifying an interconnection pattern according to the invention.

[0151] Furthermore, during a network procedure, for example the registration procedure or the procedure for establishing or modifying a data session, or after the establishment of a data session, the AMF, XNF, SMF and UPF functions can then generate billing messages in accordance with the procedure described in the 3GPP standard TS 32.255 (for example V19.1.0) or TS 32.290 (V19.1.0), except that they incorporate interconnection model identification information between the local network LNET, the aggregator network ANET (if present), and the remote network HNET. These messages are addressed to a CHF (Charging Function) billing function in their respective networks, this function being selected according to the 3GPP standard. Alternatively, the ANET aggregator network can be considered the guarantor of billing information collection due to the presence of a CHF function within it.

[0152] In the embodiments described above, the identification process implemented by the XNF function upon receipt of a message establishing or modifying a data session may alternatively be implemented by the SMF-L and SMF-A functions, particularly in cases where the XNF function is not present in the ANET aggregator network. In cases where no function is requested in the ANET aggregator network (SMF-A and UPF-A in the embodiment described above), but the model relates to a model with an aggregator, then the XNF function will be present in the ANET aggregator network by default. Alternatively, the XNF function may be co-located with another network function or with the SEPP function.

[0153] Up to this point, we have assumed that, in this second embodiment, the network slices were subscribed with XidS interconnection model identifiers. We will now describe a variant of this second embodiment in which the subscribed network slices do not include a XidS interconnection model. Because there is no subscription, the terminal does not send a XidP interconnection model proposal resulting from the subscription, and the network does not send a XidS interconnection model to the terminal.

[0154] In this variant of the second embodiment, certain steps of the process described with reference to [Fig.7] are modified as follows.

[0155] During step 1020, the AMF function transmits in the Rid identification request not only the ID_Res identifier but also the network slices extracted from the Requested NSSAI sent by the user terminal UE.

[0156] The XDMF function returns in the Rep response message, in addition to the interconnection data mentioned in the second embodiment (i.e. the Xid identifier of the interconnection model to be implemented and the LIST(NF) list of network functions to be consulted by the AMF function), the network slices supported by the Mod_4 model which are among the network slices of the Requested NSSAI (namely in the example described, the S-NSSAI 2).

[0157] During step 1060, the AMF function obtains the user profile without the subscribed XidS model identifiers for the subscribed network slices.

[0158] During step 1070, the AMF function verifies that at least one of the network slices listed in the Rep response message received during step 1030 is authorized by the user subscription of the UE user terminal.

[0159] If none of the listed network slices are authorized by the subscription, a failure message is sent to the UE user terminal during step 1080, indicating that there are no supported network slices among those requested in the Requested NSSAI, and no model transmission is returned to the terminal in this failure message. Otherwise (i.e., at least one listed network slice is authorized in the subscription), the AMF function saves, during step 1090 in the UE_C user context, the interconnect model identifier Xid=Mod_4 as well as the identifiers of the network slices provided by the XDMF function and authorized by the subscription, namely, in the example described here, the identifier S-NSSAI 2. During this step 1090, no subscribed model identifier XidS is stored in the UE_C user context.

[0160] During step 1110, the AMF function returns the Reg_OK registration acceptance message to the user terminal (UE), including the Allowed NSSAI and any Rejected NSSAI, Pending NSSAI, Partially Allowed NSSAI, and Partially Rejected NSSAI. It should be noted that this Reg_OK registration acceptance message does not contain any interconnect pattern identifier. In the example described, the AMF function therefore transmits the following to the user terminal (UE): Allowed NSSAI = {S-NSSAI 2} Rejected NSSAI = {S_NSSAI 1, S_NSSAI 3} - Pending NSSAI ={}, Partially Allowed NSSAI={}, Partially Rejected NSSAI={}

[0161] Similarly, in this variant of the second embodiment, certain steps of the process described with reference to [Fig. 10] are modified as follows.

[0162] The request issued by the user terminal UE at step 1200 contains a network slice proposal according to the standard but does not add a XidP pattern proposal.

[0163] Steps 1202 and 1203 are not executed.

[0164] According to one variant, upon receiving the PDU_EST request, the AMF function of the LNET local network verifies that the requested network slice (S-NSSAI 2 in the example) is possible with the model used during registration and stored in the user context UE_C, or with a model compatible with that of the registration. In the example, the user context UE_C contains a reference to the Mod_4 interconnection model. The verification is performed by consulting the lookup table of the XDMF function, which indicates that for the operator Op_A and the Mod_4 model, it is possible to use the slices S-NSSAI_2, S-NSSAI_4, S- NSSAI_7. Therefore, session establishment for the S-NSSAI_2 network slice is possible with the Mod_4 record model, and it is thus unnecessary to search for a model compatible with the Mod_4 model. Thus, the AMF function identifies, during step 1206, the location (local network, aggregator, remote) of the functions to be implemented to establish a PDU session for the user terminal (UE). In other words, the AMF function obtains, through this query of the XDMF function, the LIST(NF) list (also containing the NF_type and NF_NI data) of network functions to be implemented to establish the PDU session.

[0165] The conditions for applying step 1205 are modified. If it is impossible to establish the data session with the S-NSSAI_2 network slice with the model selected during registration Mod_4 (or a model compatible with Mod_4), the AMF function sends, during step 1205, a failure message to said user terminal UE possibly with an indication specifying that the network slice is not authorized.

[0166] In addition, the roaming patterns of the standard can be integrated as patterns in the XDMF table.

[0167] In the above embodiment, we assumed that registration was performed according to the invention. In another embodiment, registration is assumed to be performed according to the TS 23.502 standard. In this case, no model identifier information is present in the UE_C user context. The interconnect model is then selected during data session establishment by consulting XDMF based on the network identifier and the network slice requested for the PDU session. The PDU session will be established for the requested network slice using TS 23.502 roaming in HR mode or LBO mode, or on a model compatible with one of these two models. The PDU session establishment request will be rejected otherwise.

[0168] It should also be noted that the invention is not limited to the embodiments described above. Indeed, it appears to those skilled in the art that various modifications can be made to the embodiments described above, in light of the information that has just been disclosed to them.

[0169] For example, other decision criteria can be added to identify an interconnection pattern, and this does not preclude other exchanges between the network function hosting the lookup table (XDMF, XDMXid) and the network function querying it (AMF, XNF, SMF), such as iterative queries. In other words, the network function can, upon receiving a response, consult the lookup table again by adding one or more additional criteria to the query.

[0170] For example, in the embodiments described above, the identification process is implemented by an AMF function and / or by an SMF function and / or by an XNF function upon receipt of a message to register, activate, modify, or delete a data session issued by said user terminal and / or a message to configure a data session issued by a network function. Obviously, the identification process can be implemented by other network functions and / or upon receipt of other signaling messages, such as authentication messages, or service request messages for said network equipment, and any signaling message using the NAS (Non-Access Stratum) protocol or any signaling message for services rendered by a network function (NF services) using a protocol of the HTTP family.

[0171] It should be noted that the order of the messages is not imperative and may be different in other embodiments of the invention.

[0172] Furthermore, the storage during recording of Allowed NSSAI, Rejected NSSAI, Pending NSSAI, Partially Allowed NSSAI and Partially Rejected NSSAI is optional.

[0173] According to another example, in the embodiments described above, the XDMF function can also select the interconnection pattern based on the ID_Res identifier of the remote HNET network and the type of request (e.g., data session registration, activation or modification) and / or the type of function that queries the XDMF function.

[0174] In the detailed presentation of the invention given above, the terms used shall not be interpreted as limiting the invention to the embodiments set forth in this description, but shall be interpreted as including all equivalents which can be foreseen by a person skilled in the art by applying their general knowledge to the implementation of the teaching which has just been disclosed to them.

Claims

Demands

1. A method for identifying an interconnection pattern between a first communication network (LNET) and a second communication network (HNET, ANET), said identification method being implemented by a network equipment (AMF) of one of the two communication networks during a network procedure relating to at least one user terminal (UE) having a subscription with a third network (HNET), said method comprising: - receiving (100, 1000) a signaling message (ReReg, ReReg') associated with said network procedure, and - obtaining at least one representative data point (XidP, Xid) of said interconnection pattern between said first and second communication networks,said at least one data point being an identifier of said interconnection pattern (XidP) extracted from said signaling message (ReReg) or being obtained from a lookup table between at least one identification information (ID_Res) of said third network (HNET) extracted from said signaling message (ReReg) and said at least one representative data point.

2. Identification method according to the preceding claim wherein said at least one data representative of said interconnection pattern between said first and second communication network is obtained from said at least one identification information of said third network and at least one network slice identifier extracted from said signaling message.

3. An identification method according to any one of the preceding claims, wherein said obtaining of at least one representative data point of said interconnection pattern comprises: - the sending of an identification request for said interconnection model to a second network equipment, said second network equipment including said lookup table, said request including said at least one identification information, and - the receiving of a response message to said identification request from said second network equipment, said response message including said at least one data representative of said interconnection model.

4. Identification method according to any one of the preceding claims wherein said signaling message is: - a registration message issued by said user terminal, or - a message establishing, modifying, or deleting a data session, or - a message configuring a data session, or - an authentication message, or - a message requesting use of service for said network equipment.

5. An identification method according to any one of the preceding claims further comprising: - the storage by the network equipment in a user context of said at least one data representative of said interconnection pattern, or - the selection of a third network equipment from said at least one data representative of said interconnection pattern and the issuance of another signaling message to said third network equipment, said other signaling message comprising said at least one data representative of said interconnection pattern.

6. Identification method according to the preceding claim wherein said third network equipment belongs to said second communication network.

7. An identification method according to any one of the preceding claims, wherein said at least one representative data of said interconnection pattern is included in the group comprising: - an identifier of a type of network equipment (NF_type), - a location of a type of network equipment in a communication network (NF_NI), - an identifier of said interconnection pattern (Xid), - priority information of said interconnection pattern (Xid_Prio), - a validity condition of said interconnection pattern, - an identifier of another interconnection pattern compatible with said interconnection pattern, and - another identifier of said interconnection pattern.

8. Identification method according to any one of the preceding claims further comprising, where said at least one representative data corresponds to an interconnection pattern not supported by said network equipment, - the sending of a failure message to said user terminal, or - the selection of an alternative network equipment supporting said interconnection pattern.

9. Identification method according to any one of the preceding claims further comprising sending to the user terminal a reply message to said signaling message comprising an identifier of said interconnection pattern.

10. An identification method according to any one of the preceding claims, wherein said network equipment implementing said identification method is: - an access and mobility management entity, or - a network interconnection management entity, or - a session management entity.

11. Device for identifying an interconnection pattern between a first communication network and a second network of communication, said identification device comprising at least one processor configured for: - receive a signaling message associated with a network procedure relating to at least one user terminal with a subscription to a third network, and - obtain at least one data point representative of said interconnection model between said networks, said at least one data point being an identifier of said interconnection model extracted from said signaling message or being obtained from a lookup table between at least one identification information of said third network extracted from said signaling message and said at least one data point.

12. A referencing device (XDMF) for at least one interconnection pattern between a first communication network and a second communication network, said referencing device comprising a lookup table between at least one identification piece of information of a third network with which a user terminal has a subscription and at least one representative piece of data of said interconnection pattern, said referencing device comprising at least one processor configured to: - receive a request to identify said interconnection model, said identification request including said identification information, - to obtain, from said lookup table, at least one representative piece of data from said interconnection model, and - issue a response message to said request, said response message including said at least one data representative of said interconnection model.

13. A user terminal (UE) capable of transmitting and receiving signaling messages and user data on a first communications network, said terminal comprising at least one processor configured to transmit a signaling message to a network device on said first communications network, said signaling message comprising at least one identifier of an interconnection model between said first network and a second communication network.

14. System comprising a device for identifying an interconnection pattern between a first communication network and a second communication network according to claim 11, said system also comprising a referencing device according to claim 12 and / or a terminal according to claim 13.

15. Computer program comprising instructions for carrying out a method according to any one of claims 1 to 10 when this program is executed by a processor.

Images