Patent Description:
The 5GC (<NUM> Core network) has been defined as a Service Based Architecture (SBA), with NF service producers (NFp) exposing services to NF service consumers (NFc). NF service producers register their NF profile in an Network Repository Function (NRF). The NF profile contains NF level specific information and the list of NF service instances supported by the NF with their associated attributes.

When an NFc (e.g. AMF) creates a resource (e.g. a SM context resource, i.e. a PDU session) at the NFp (e.g. SMF), the NFp returns the URI of the created resource to the NFc. This URI is used by the NFc to send subsequent requests to the NFp targeting the specific resource, e.g. to modify or delete the resource. Routing of HTTP messages in the 5GC relies on Request URIs as specified in clause <NUM>. of 3GPP TS <NUM>.

The structure of a resource URI is defined in clause <NUM>. <NUM> of 3GPP TS <NUM>. In short, it is structured as follows:.

For inter-PLMN signaling, the authority in the apiRoot shall be encoded as an FQDN terminating by the home network domain of the NFp as defined in clause <NUM> of 3GPP TS <NUM> and clause <NUM> of 3GPP TS <NUM>. This is required to allow the routing of the message towards the target PLMN. This means that the URI shall take the form of:
<one or more labels identifying the NFp>. 3gppnetwork. org where the MCC and MNC identify the PLMN of the NFp.

The authority of the NFp used for intra-PLMN signaling is not constrained by 3GPP and is left to the choice of operators. For instance, the authority may take the form of an IP address (rather than an FQDN), or an FQDN freely determined by the operator (as also configured in the operator's network DNS):
<one or more labels identifying the NFp>. <operator name>.

An operator may want to use different HTTP schemes for intra-PLMN and inter-PLMN signalling (e.g. http for intra-PLMN traffic but https for inter-PLMN).

The NF profile registered in the NRF allows to register intra-PLMN and inter-PLMN authority information. A requester NF from a different PLMN than the NFp retrieves the NFp profile from the NRF including only the inter-PLMN authority information.

Table <NUM> shows part of the PDU session context information exchanged during inter-AMF mobility.

Table <NUM> shows part of the SM context information exchanged between V-/I-SMFs in scenarios with a change of V-SMF or I-SMF.

Note on 3GPP terminology used for contexts created in SMF for a PDU session:.

When the UE is outside of the SMF Service Area, or current SMF cannot serve the target DNAI for the traffic routing towards Local DN, an I-SMF is inserted between the SMF and the AMF. The I-SMF has a N11 interface with the AMF and a N16a interface with the SMF and is responsible of controlling the UPF(s) that the SMF cannot directly control. The exchange of the SM context and forwarding of tunnel information if needed are done between two SMFs directly without involvement of AMF.

Depending on scenario, a PDU Session in non-roaming case or local breakout is either served by a single SMF or served by an SMF and an I-SMF. When a PDU Session is served by both an SMF and an I-SMF, the SMF is the NF instance that has the interfaces towards the PCF and CHF.

Further relevant prior art documents are 3GPP TS <NUM> v16. <NUM>, "Session Management Services"; 3GPP C4-<NUM> "Event subscriptions with Inter PLMN and Intra PLMN callback URIs", and 3GPP CP-<NUM> "Returning the interPlmnFqdn attribute in NFProfile in NF Discovery response".

According to a aspects of the invention, there are provided apparatuses according to the claims.

According to some embodiments of the invention, at least one of the following advantages may be achieved:.

Further details, features, objects, and advantages are apparent from the following detailed description of the preferred embodiments of the present invention which is to be taken in conjunction with the appended drawings, wherein:.

Herein below, certain embodiments of the present invention are described in detail with reference to the accompanying drawings, wherein the features of the embodiments can be freely combined with each other unless otherwise described. However, it is to be expressly understood that the description of certain embodiments is given by way of example only, and that it is by no way intended to be understood as limiting the invention to the disclosed details.

When the UE moves between its Home PLMN (HPLMN) and a Visited PLMN (VPLMN), the target AMF (T-AMF) in the target PLMN receives resource URIs (e.g. for the PDU sessions of the UE being transferred from the source PLMN) as if they had been received by the source AMF (S-AMF) in the source PLMN. This can result in the target PLMN being unable to reach the NFp because it receives URIs with a format that does not comply with 3GPP requirements and that does not allow the routing of signaling towards the NFp.

Taking the example of an inter-PLMN handover, the I-SMF is to be substituted by the V-SMF in the call flow of <FIG> (Figure <NUM>. <NUM>-<NUM> of 3GPP TS <NUM>). IN the call flow of <FIG>, for the above described example use case <NUM>), the following issues arise:.

During UE mobility from VPLMN to HPLMN, the T-AMF either inserts an I-SMF (replacing the V-SMF in the source PLMN) or sends a Create SM Context to the anchor SMF (removing the V-SMF from the source PLMN). In the former case, the new I-SMF needs to retrieve the SM context from the V-SMF in the source PLMN (action 4a of <FIG>). In either case, the anchor SMF invokes Nsmf_PDUSession_UpdateSMContext Request to the source V-SMF in order to establish the indirect forwarding tunnel (action <NUM> of <FIG>) (the SMF uses the SM Context ID received from T-AMF for this service operation).

The S-AMF in the Source PLMN may have received an SM context reference from the V-SMF with an intra-PLMN URI. However, to be able to retrieve the SM context from the V-SMF or setup a forwarding tunnel, the new I-SMF or anchor SMF in the HPLMN needs to send a Retrieve SM Context Request or an Update SM Context Request to the old V-SMF with a request URI with an inter-PLMN format. This means that the procedure in action 4a or action <NUM> fails due to the smContextReference received from the S-AMF having an intra PLMN apiRoot.

Note: Additionally, if no I-SMF needs to be inserted in the HPLMN, the T-AMF should send a Create SM Context request to the anchor SMF using an intra-PLMN format. This requires the T-AMF to do an NF Discovery Request to the NRF to retrieve the anchor SMF profile and gets in the response the intra-PLMN authority to use for contacting the anchor SMF.

<NUM>) Similar considerations apply to other use cases with an inter-PLMN mobility, when NFs in the target PLMN need to send requests targeting resources in the HPLMN. An example is the AMF interacting with the V-PCF or H-PCF for UE policy. During inter-AMF mobility, the S-AMF sends to the T-AMF the URI of the PCF for UE Policy, which may result in the same problem of the T-AMF receiving a URI that it cannot use to reach the PCF.

Some example embodiments of the invention enable an inter-PLMN mobility of a UE according to the following parts:.

For each inter-PLMN mobility of a UE, parts <NUM>) and <NUM>) are alternative approaches. Thus, some involved NFs may be configured to perform only one of part <NUM>) and part <NUM>). However, in some example embodiments, some or all of the involved network functions may be configured to perform each of parts <NUM>) and <NUM>), e.g. according to some criterion. For instance, if the target VPLMN does not receive the intra-PLMN and an inter-PLMN apiRoot of a resource URI during the inter-PLMN mobility scenario (due to e.g. the source PLMN not supporting corresponding protocol extensions), the target PLMN may proceed with the part <NUM>) to discover and construct a suitable apiRoot for sending a request targeting the resource of the NFp. For example, each involved NF may perform a respective one of these parts <NUM>) and <NUM>) as a default, but if one of the involved NFs does not support the default part of another involved NF, the other part may be chosen. The NFs may inform each other about their respective capability by signalling.

Hereinafter, parts <NUM>) to <NUM>) are described at greater detail.

An NFc in the target PLMN (e.g. AMF or V-/I-SMF) sends a service request targeting an existing resource of an NFp (e.g. a PDU session of an anchor SMF), using a request URI that the NFc constructs with an intra-PLMN or an inter-PLMN apiRoot, depending on whether the NFc is in the same or a different PLMN than the NFp.

The invention enables for instance (taking the example use cases of depicted in <FIG> and <FIG>, respectively):.

The NFc in the target PLMN overwrites the apiRoot of the Resource URI it has received from the source PLMN, if necessary. For instance, if the Resource URI of an SM context received from the source AMF contains an intra-PLMN apiRoot, and the NFc is not in the same PLMN as the anchor SMF, the NFc overwrites the apiRoot of the resource URI with the inter-PLMN apiRoot. As another example, if the Resource URI of an SM context received from the source AMF contains an inter-PLMN apiRoot, and the NFc is in the same PLMN as the anchor SMF, the NFc overwrites the apiRoot of the resource URI with the intra-PLMN apiRoot. See further details in <NUM>) and <NUM>) below.

The NFc determines the intra-PLMN or inter-PLMN apiRoot to use for building the request URI using the principles of <NUM>) or <NUM>).

An NFp signals an intra-PLMN and an inter-PLMN apiRoot of a resource URI, in response to a resource creation request. In some example embodiments, NFp signals these apiRoots only when the resource may be accessed by NF service consumers in the HPLMN and VPLMN during the lifetime of the resource.

The NFp may signal the intra-PLMN and inter-PLMN apiRoot to the NFc during the creation of the resource by signaling them in an HTTP custom header (e.g. extending the 3gpp-Sbi-Response-lnfo header) and/or in the JSON payload of the resource creation response. These options are described as Option 2A and Option 2B further below. The options may be combined.

The intra-PLMN and inter-PLMN apiRoot are signalled within an HTTP header that is returned in the resource creation response (i.e. HTTP <NUM> Created response). The HTTP header may be a 3GPP custom header and could for instance correspond to the 3gpp-Sbi-Response-Info header defined in 3GPP TS <NUM>, extended as indicated in bold:.

Note that a <NUM> response already includes a Location header with the resource URI. So in a variant, the 3gpp-Sbi-Response-Info (or any other header used to signal the above extensions) may only include one of the intra-PLMN and inter-PLMN apiRoot, i.e. the format that is not already included in the Location header. Note also that in another variant, the 3gpp-Sbi-Response-Info (or any other header used to signal the above extensions) contains new interPImnURI and intraPlmnURI, i.e. not only the apiRoot.

In this option, the SMF PDUSession API (defined in 3GPP TS <NUM>) is extended such as to enable the SMF to return an inter-PLMN and an intra-PLMN apiRoot during the creation of an SM context or a PDU session, e.g. with extensions to 3GPP TS <NUM> (shown in bold in Tables <NUM> and <NUM>):.

For both options 2A and 2B:
The NFc in the source PLMN stores the intra-PLMN root and inter-PLMN root of the resource URI and transfers them to the target PLMN during inter-PLMN mobility.

This includes transferring the information between AMFs (e.g. transfer of the I-SMF/V-SMF SM context reference) and between V-/I-SMFs (e.g. transfer of the anchor SMF PDU session context reference).

- the AMF stores the intra and inter PLMN apiRoot received for the SM context from the I-SMF, V-SMF or (if no V/I-SMF) from the anchor SMF, and during an inter-AMF mobility, the S-AMF shall transfer both apiRoots to the T-AMF (per SM context), e.g. relying on the AMF Communication service extensions, explained as an extension of 3GPP TS <NUM> in Table <NUM> (in bold).

- The SMF, V-SMF and I-SMF may store the intra PLMN apiRoot and inter PLMN apiRoot received for the PDU session context from the SMF, and during a scenario with an I-SMF or V-SMF insertion/change/removal, the new I-SMF, V-SMF or the anchor SMF retrieves them in the SM context in the SM Context retrieval service operation, e.g. by extending the SmContext data type as shown in Table <NUM> in TS <NUM> as follows:.

For both options 2A and 2B, upon inter-PLMN mobility:.

In some example embodiments, S-AMF decides on the appropriate apiRoot (intra-PLMN apiRoot or inter-PLMN apiRoot) and forwards only this apiRoot to target AMF. In this case, target AMF may not check for the appropriate apiRoot.

An NFc (e.g. V/I-SMF) in the target PLMN may discover the intra-PLMN or inter-PLMN apiRoot it should use for sending a request targeting the resource of the NFp, by interacting with the NRF.

More specifically, upon inter-PLMN mobility, the target V-SMF or I-SMF discovers the NF profile of the anchor SMF and optionally of the old I-SMF / V-SMF, from the NRF, by sending an NF Discovery Request request with query parameters identifying the anchor SMF or the old I-SMF/V-SMF. The NF (i.e. SMF) profile returned by the NRF contains information that allows to construct an inter-PLMN apiRoot (for a target V-SMF) or an intra-PLMN apiRoot (for a target I-SMF, if involved). The constructed apiRoot is then used for sending requests targeting the SM context or PDU session resource of the NFp.

The target V-SMF/I-SMF should then behave as described in <NUM>).

<FIG> illustrate an example inter-PLMN mobility from an HPLMN to a VPLMN, without and with an I-SMF in the HPLMN. <FIG> and <FIG> use parts <NUM>&<NUM>, <FIG> and <FIG> use parts <NUM>&<NUM>. In detail,.

In addition, in the examples of <FIG> and <FIG> (without I-SMF),.

In addition, in the examples of <FIG> and <FIG> involving I-SMF of HPLMN,.

The message flow in <FIG> is as follows:.

For action <NUM> in <FIG> and <FIG>, the Create SM Context Request of 3GPP TS <NUM> may be extended as shown in bold in Table <NUM>.

For action <NUM> in <FIG> and <FIG> and action <NUM> in <FIG>, the NRF of the network of the NFp (anchor SMF) to inquire the respective NRF may be determined e.g. by one of the following ways:.

- by checking the received apiRoot if it is an inter-PLMN apiRoot; or
- by separate information passed from the source PLMN to the target PLMN identifying the MCC/MNC of the producer network (e.g. storing the MCC/MNC of the producer network (e.g. anchor SMF) in the SM context);
- by the T-AMF knowing the MCC/MNC of the S-AMF, for when the producer is an old I-/V-SMF holding the SM context in the source PLMN.

<FIG> shows an apparatus according to an example embodiment of the invention. The apparatus may be a network function (in particular: network function consumer), such as a SMF, or AMF, or PCF, or an element thereof. <FIG> shows a method according to an example embodiment of the invention. The apparatus according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the apparatus of <FIG> but is not limited to being performed by this apparatus.

The apparatus comprises means for monitoring <NUM>, means for identifying <NUM>, means for deciding <NUM>, first means for sending <NUM>, and second means for sending <NUM>. The means for monitoring <NUM>, means for identifying <NUM>, means for deciding <NUM>, first means for sending <NUM>, and second means for sending <NUM> may be a monitoring means, identifying means, deciding means, first sending means, and second sending means, respectively. The means for monitoring <NUM>, means for identifying <NUM>, means for deciding <NUM>, first means for sending <NUM>, and second means for sending <NUM> may be a monitor, identifier, decider, first sender, and second sender, respectively. The means for monitoring <NUM>, means for identifying <NUM>, means for deciding <NUM>, first means for sending <NUM>, and second means for sending <NUM> may be a monitoring processor, identifying processor, deciding processor, first sending processor, and second sending processor, respectively.

The means for monitoring <NUM> monitors whether a consumer belonging to a target network receives a specific identifier of a resource, a first apiRoot identifying a producer, and a second apiRoot identifying the producer and a producer network (S110). The first apiRoot is suitable for routing a first service request within the producer network to the producer. The second apiRoot is suitable for routing a second service request from the target network to the producer in the producer network if the target network is different from the producer network. The first apiRoot is different from the second apiRoot. The second apiRoot comprises MCC and MNC of the producer network, while the first apiRoot does not comprise at least one of MCC and MNC of the producer network. The first service request requests a service related to the resource. The second service request requests the service (i.e., the same service) related to the resource.

If the consumer receives the specific identifier, the first apiRoot, and the second apiRoot (S110 = yes), the means for identifying <NUM> identifies the producer network based on the second apiRoot (S120). The means for deciding <NUM> decides whether the target network is different from the producer network (S130).

If the target network is not different from the producer network (S130 = no), the first means for sending sends the first service request (S140). In the first service request, the resource is identified by the first apiRoot and the specific identifier.

If the target network is different from the producer network (S130 = yes), the second means for sending <NUM> sends the second service request (S150). In the second service request, the resource is identified by the second apiRoot and the specific identifier.

The apparatus comprises means for monitoring <NUM>, means for inquiring <NUM>, means for identifying <NUM>, means for deciding <NUM>, first means for constructing <NUM>, first means for sending <NUM>, second means for constructing <NUM>, and second means for sending <NUM>. The means for monitoring <NUM>, means for inquiring <NUM>, means for identifying <NUM>, means for deciding <NUM>, first means for constructing <NUM>, first means for sending <NUM>, second means for constructing <NUM>, and second means for sending <NUM> may be a monitoring means, inquiring means, identifying means, deciding means, first constructing means, first sending means, second constructing means, and second sending means, respectively. The means for monitoring <NUM>, means for inquiring <NUM>, means for identifying <NUM>, means for deciding <NUM>, first means for constructing <NUM>, first means for sending <NUM>, second means for constructing <NUM>, and second means for sending <NUM> may be a monitor, inquirer, identifier, decider, first constructor, first sender, second constructor, and second sender, respectively. The means for monitoring <NUM>, means for inquiring <NUM>, means for identifying <NUM>, means for deciding <NUM>, first means for constructing <NUM>, first means for sending <NUM>, second means for constructing <NUM>, and second means for sending <NUM> may be a monitoring processor, inquiring processor, identifying processor, deciding processor, first constructing processor, first sending processor, second constructing processor, and second sending processor, respectively.

The means for monitoring <NUM> monitors whether a consumer belonging to a target network receives a specific identifier of a first resource and a single one of a first apiRoot of a first producer and a second apiRoot of the first producer (S210). , the means for monitoring <NUM> monitors whether the consumer receives the specific identifier and either the first apiRoot of the first producer or the second apiRoot of the first producer.

The first apiRoot of the first producer identifies the first producer and is suitable for routing a first service request within a first producer network to the first producer. The second apiRoot of the first producer identifies the first producer, comprises an identification of the first producer network, and is suitable for routing a second service request from the target network to the first producer in the first producer network if the target network is different from the first producer network. The second apiRoot comprises MCC and MNC of the producer network, while the first apiRoot does not comprise at least one of MCC and MNC of the producer network. The first apiRoot of the first producer is different from the second apiRoot of the first producer. The first service request requests a service related to the first resource. The second service request requests the service (i.e., the same service) related to the first resource.

If the consumer receives the specific identifier of the first resource, and the single one of the first apiRoot of the first producer and the second apiRoot of the first producer (S210 = yes), the means for identifying (S220) identifies a second repository function storing a network function profile of the second producer (S220). The identification may be performed by existing inter-PLMN NF discovery procedures, e.g. as explained with respect to action <NUM> of <FIG> and <FIG> and action <NUM> of <FIG>. The means for inquiring <NUM> inquires a first repository function for the network function profile of the first producer (S230). The network function profile of the first producer comprises the identification of the first producer network and information allowing to construct the first apiRoot of the first producer and the second apiRoot of the first producer. The means for deciding <NUM> decides if the target network is different from the first producer network (S240).

If the target network is different from the first producer network (S240 = yes) and the consumer receives the first apiRoot of the first producer in S210, the second means for constructing <NUM> constructs the second apiRoot of the first producer based on the network function profile of the first producer (S270). Then, the second means for sending <NUM> sends the second service request (S280). In the second service request, the first resource is identified by the second apiRoot of the first producer and the specific identifier of the first resource.

If the target network is not different from the first producer network (S240 = no, i.e., the target network is the same as the first producer network) and the consumer receives the second apiRoot of the first producer in S210, the first means for constructing <NUM> constructs the first apiRoot of the first producer based on the network function profile of the first producer. Then, the first means for sending <NUM> sends the first service request
(S260). In the first service request, the first resource is identified by the first apiRoot of the first producer and the specific identifier of the first resource.

<FIG> shows an apparatus according to an example embodiment of the invention. The apparatus may be a network function (in particular: network function producer), such as a SMF or a PCF, or an element thereof. <FIG> shows a method according to an example embodiment of the invention. The apparatus according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the apparatus of <FIG> but is not limited to being performed by this apparatus.

The apparatus comprises means for monitoring <NUM> and means for providing <NUM>. The means for monitoring <NUM> and means for providing <NUM> may be an monitoring means and providing means, respectively. The means for monitoring <NUM> and means for providing <NUM> may be an monitor and provider, respectively. The means for monitoring <NUM> and means for providing <NUM> may be an monitoring processor and providing processor, respectively.

The means for monitoring <NUM> monitors whether a producer belonging to a producer network produced a resource due to a received request to produce the resource (S310).

If the resource is produced (S310 = yes), the means for providing <NUM> provides a response to the received request (S320). The response indicates that the resource is produced. The response comprises a specific identifier of the resource, a first apiRoot, and a second apiRoot.

The first apiRoot is suitable for routing a first service request within the producer network to the producer. The second apiRoot is suitable for routing a second service request from another network different from the producer network to the producer in the producer network. The second apiRoot comprises MCC and MNC of the producer network, while the first apiRoot does not comprise at least one of MCC and MNC of the producer network. The first apiRoot is different from the second apiRoot. The first service request requests a service related to the resource. The second service request requests the service (i.e., the same service) related to the resource.

<FIG> shows an apparatus according to an example embodiment of the invention. The apparatus may be a network function (in particular: network function consumer), such as an AMF, or a SMF, or a PCF, or an element thereof. <FIG> shows a method according to an example embodiment of the invention. The apparatus according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the apparatus of <FIG> but is not limited to being performed by this apparatus.

The means for monitoring <NUM> monitors whether a response to a request from a source network function belonging to a source network to a producer belonging to a producer network comprises a specific identifier of a resource, a first apiRoot, and a second apiRoot (S410). The request requests to produce the resource.

The first apiRoot is suitable for routing a first service request within the producer network to the producer. The second apiRoot is suitable for routing a second service request from the target network to the producer in the producer network if the target network is different from the producer network. The second apiRoot comprises MCC and MNC of the producer network, while the first apiRoot does not comprise at least one of MCC and MNC of the producer network. The first apiRoot is different from the second apiRoot. The first service request requests a service related to the resource. The second service request requests the service (i.e., the same service) related to the resource.

If the response comprises the specific identifier of the resource, the first apiRoot, and the second apiRoot (S410 = yes), the means for providing <NUM> provides the specific identifier, the first apiRoot, and the second apiRoot to a consumer belonging to a target network (S420).

The apparatus comprises means for monitoring <NUM>, means for identifying <NUM>, means for deciding <NUM>, first means for providing <NUM>, and second means for providing <NUM>. The means for monitoring <NUM>, means for identifying <NUM>, means for deciding <NUM>, first means for providing <NUM>, and second means for providing <NUM> may be a monitoring means, identifying means, deciding means, first providing means, and second providing means, respectively. The means for monitoring <NUM>, means for identifying <NUM>, means for deciding <NUM>, first means for providing <NUM>, and second means for providing <NUM> may be a monitor, identifier, decider, first provider, and second provider, respectively. The means for monitoring <NUM>, means for identifying <NUM>, means for deciding <NUM>, first means for providing <NUM>, and second means for providing <NUM> may be a monitoring processor, identifying processor, deciding processor, first providing processor, and second providing processor, respectively.

The means for monitoring <NUM> monitors whether a response to a request from a source network function belonging to a source network to a producer belonging to a producer network comprises a specific identifier of a resource, a first apiRoot, and a second apiRoot (S510). The request requests to produce the resource.

If the response comprises the specific identifier of the resource, the first apiRoot, and the second apiRoot (S510 = yes), the means for identifying <NUM> identifies the producer network based on the second apiRoot (S515). The means for deciding <NUM> decides whether a target network is different from the producer network (S520).

If the target network is not different from the producer network (S520 = no, i.e., the target network is the same as the producer network), the first means for providing <NUM> provides the specific identifier and the first apiRoot to a consumer belonging to the target network (S530). The first means for providing <NUM> does not provide the second apiRoot to the consumer.

If the target network is different from the producer network (S520 = yes), the second means for providing <NUM> provides the specific identifier and the second apiRoot to the consumer belonging to the target network (S540). The second means for providing <NUM> does not provide the first apiRoot to the consumer.

<FIG> shows an apparatus according to an embodiment of the invention. The apparatus comprises at least one processor <NUM>, at least one memory <NUM> including computer program code, and the at least one processor <NUM>, with the at least one memory <NUM> and the computer program code, being arranged to cause the apparatus to at least perform at least the method according to at least one of <FIG>, <FIG>, <FIG>, and <FIG> and related description.

Some example embodiments of the invention are explained for a case that a UE moves from a source network to a target network. However, the invention is not limited to such a case. It may be adopted in any case if a second network (e.g. target network) retrieves a resource from a first network (e.g. source network).

In some example embodiments, such as those of <FIG>, the producer provides, to identify the resource, a URI comprising an apiRoot of one type (inter-PLMN or intra-PLMN), and in addition two apiRoots of different types (inter-PLMN and intra-PLMN). In some example embodiments, the producer provides, to identify the resource, the URI comprising the apiRoot of one type and in addition the apiRoot of the other type but not the apiRoot of the one type.

Some example embodiments are explained with respect to a <NUM> network. However, the invention is not limited to <NUM>. It may be used in other service based networks providing mobility, too, e.g. in previous of forthcoming generations of 3GPP networks such as <NUM>, <NUM>, or <NUM>, etc. It may be used in non-3GPP mobile communication networks, too.

Names of network elements, network functions, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or network functions and/or protocols and/or methods may be different, as long as they provide a corresponding functionality.

If not otherwise stated or otherwise made clear from the context, the statement that two entities are different means that they perform different functions. It does not necessarily mean that they are based on different hardware. That is, each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each of the entities described in the present description may be based on different software, or some or all of the entities may be based on the same software. Each of the entities described in the present description may be deployed in the cloud.

According to the above description, it should thus be apparent that example embodiments of the present invention provide, for example, a network function (such as a NFp or NFc, in particular: an AMF or SMF) or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).

Implementations of any of the above described blocks, apparatuses, systems, techniques or methods include, as non-limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof. Each of the entities described in the present description may be embodied in the cloud.

It is to be understood that what is described above is what is presently considered the preferred example embodiments of the present invention. However, it should be noted that the description of the preferred example embodiments is given by way of example only and that various modifications may be made without departing from the scope of the invention as defined by the appended claims.

Claim 1:
Apparatus comprising:
one or more processors (<NUM>), and memory (<NUM>) storing instructions that, when executed by the one or more processors, cause the apparatus to perform:
monitoring (S110) whether a network function service consumer belonging to a target network receives a specific identifier of a resource, a first apiRoot identifying a network function service producer, and a second apiRoot identifying the network function service producer and a network function service producer network; wherein
the first apiRoot is suitable for routing a first service request within the network function service producer network to the network function service producer,
the second apiRoot is suitable for routing a second service request from the target network to the network function service producer in the network function service producer network if the target network is different from the network function service producer network;
the second apiRoot comprises a mobile country code and a mobile network code of the network function service producer network;
the first apiRoot does not comprise at least one of the mobile country code and the mobile network code of the network function service producer network;
the first service request requests a service related to the resource;
the second service request requests the service related to the resource; and
the instructions, when executed by the one or more processors, further cause the apparatus to perform:
identifying (S120) the network function service producer network based on the second apiRoot if the network function service consumer receives the specific identifier, the first apiRoot, and the second apiRoot;
deciding (S130) whether the target network is different from the network function service producer network;
if the target network is not different from the network function service producer network: sending (S140) the first service request, wherein, in the first service request, the resource is identified by the first apiRoot and the specific identifier;
if the target network is different from the network function service producer network: sending (S150) the second service request, wherein, in the second service request, the resource is identified by the second apiRoot and the specific identifier.