UNITS FOR PROVIDING AN EXTERNAL SERVICE TO A NETWORK

DE602019064520T2Active Publication Date: 2025-01-01HUAWEI TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
DE602019064520
Authority / Receiving Office
DE · DE
Patent Type
Patents
Current Assignee / Owner
Filing Date
2019-02-18
Publication Date
2025-01-01
Estimated Expiration
2039-02-18

AI Technical Summary

Technical Problem

Current 5G systems have limited capability exposure from external network entities, leading to inflexible parameter provisioning, inefficient communication, high latency, and restricted service exposure, which hinders the integration of external services into the network, particularly in cases requiring real-time data and service optimization.

Method used

A mechanism is introduced to enable external network entities to register and expose their services within the 5G network, using a network entity as an agent to create a clone service interface, allowing for registration and transfer of service traffic, thereby facilitating the integration of external services into the 5G Service-Based Architecture.

Benefits of technology

This solution enhances the flexibility and efficiency of service exposure, reduces latency, and enables real-time communication, allowing 5G networks to effectively utilize external services for improved resource management and service quality optimization.

✦ Generated by Eureka AI based on patent content.
Patent Text Reader
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present invention relates to external services provided to a network. In particular, the invention proposes devices (network entities) that are involved in one or more services provided by the external network entity at another network entity. Further, the invention proposes devices (network entities) that are involved in the bridging of service traffic between an external network entity providing one or more services and another network entity consuming the one or more services.BACKGROUND

[0002] An external network entity, like a 3 rd< party (3P) Application Function (AF), may have additional capabilities, which can help a network to provide better services or improve the network operation efficiency. For instance, a Vehicle-to-anything (V2X) application (e.g., a navigation application) may provide User Equipment (UE) trajectory information to a 5G System (5GS). The 5GS can use this information to manage / plan network resources, in order to better satisfy V2X communication service requirements, and to make more efficient usage of network resources. The information could also be used by the 5GS to access the network capability, and to notify the V2X application in advance, if the expected service quality for a V2X communication service is in risk to be degraded. Furthermore, in industry communication use cases, a time monitoring capability from a 3P AF (e.g., a Time Sensitive Network (TSN), real time application) may provide a reference to the 5GS for a better end-to-end latency control.

[0003] However, in the current 3GPP Rel. 15 there is foreseen only limited capability exposure from an external AF to the 5GS. In particular, the 5GS supports external exposure of network capabilities, comprising [see TS 23.502 v.1.4.1 section 4.15.1]: Exposure of network events externally as well as internally towards core network NFs; Exposure of provisioning capability towards external functions; Exposure of policy and charging capabilities towards external functions; Exposure of core network internal capabilities for analytics. Exposure of provisioning capability towards external functions allows external party to provision of information which can be used for the UE in 5GS.

[0004] Further, Network Exposure Function (NEF) services cover only very specific cases (e.g.., parameter provision, UE trigger from the AF, etc.) as shown below in Table 1. Table 1: TR 23.501 v. 1.4.1 Table 7.2.8-1 Network Function (NF) Services provided by NEF.Service Name Description Reference in TS 23.502 [3] Nnef_EventExposureProvides support for event exposure5.2.6.2Nnef_PFDManagementProvides support for PFDs management5.2.6.3Nnef_ParameterProvisionProvides support to provision information which can be used for the UE in 5GS5.2.6.4Nnef_TriggerProvides support for device triggering5.2.6.5Nnef_BDTPNegotiationProvides support for negotiation about the transfer policies for the future background data transfer5.2.6.6Nnef_TrafficInfluenceProvide the ability to influence traffic routing .5.2.6.7Nnef_ChargeablePartyRequests to become the chargeable party for a data session for a UE.5.2.6.8Nnef_AFsessionWithQoSRequests the network to provide a specific QoS for an AS session.5.2.6.9

[0005] For external parameter provision, there are also severe limitations (see e.g. the detailed procedure in TS 23.502 V 1.4.1 section 4.15.6 "External Parameter Provisioning"), in particular: 1. Lack of flexibility: External parameters need to be pre-configured (e.g., by OAM). Currently they are limited to the information related to a single UE or a group of UE. There is no support for service / slice related information. There is also no general procedure to discover newly added external (3P AF) services. A dedicated service definition for different exposure cases is not provided (for complicity of service design). 2. Inefficient communication between 3P AF and 5GS: The 5GS cannot actively ask for the parameters for a certain time period (e.g., working days), with certain granularities (e.g., per UE / per service) and a certain format (e.g., average, maximum, STD variation) per use case of the parameters. Current solutions only include a valid time as parameter of the external parameters. 3. Long latency between information provider and information consumer: In the current procedures, the external parameters are stored at Unified Data Management (UDM) or a Unified Data Storage (UDR), before they go to the actual consumers of external parameters. This is not suitable for cases, in which real time external information is needed. 4. Limited service exposure from 3P AF: External parameter provision is a limited capability of 3P AF. The 3P could provide services to the 5GS, such as to adjust its traffic pattern / configuration, in order to achieve joint optimization with the 5GS consideration End-to-End (e2e) service requirements, and expose 3P events to the 5GS.

[0006] In one special case of a Network Data Analytic Function (NWDAF), TR 23.791 defines that data from AFs (3P AFs) can be collected by the NWDAF. However, it is left for further study to define, how the NWDAF may actually know, which 3P AF can be used for data collection, and which data and / or services such AFs offer.

[0007] SAMSUNG, "A solution to provide the available analytic information metadata", vol. SA WG2, no. Sophia Antipolis, France; 26 August 2018, 3GPP DRAFT; S2-188511_NEW SOLUTION TO PROVIDE A SET OF AVAILABLE ANALYTICS, discloses a solution to provide analytic information to 5GS NFs and AFs. INTEL CORPORATION (RAPPORTEUR), "Email discussion report on [104#35][NR] Positioning SI (Intel)", vol. RAN WG2, no. Athens, Greece; 15 February 2019, 3GPP DRAFT; R2-1900753_EMAILDISC-104-35_REPORT-V02, discloses Service and System Aspects (SA) progress, and potential Radio Access Network (RAN) impacts.SUMMARY

[0008] In view of the above, embodiments of the present invention aim to improve the current implementations. An objective is in particular to provide a mechanism that enables an external network entity, e.g. a 3P AF, to expose its service(s) to a network, e.g. to a 5GS. A specific goal is thereby to enable a network entity, e.g. a 5G NF, to discover the service(s) provided by an external network entity. Another specific goal is to enable a network entity, e.g. a 5G NF, to use (consume) the service(s) provided by an external network entity.

[0009] The objective is achieved by the embodiments of the invention as described in the enclosed independent claims. Advantageous implementations of the present invention are further defined in the dependent claims.

[0010] In particular, embodiments of the invention propose network entities and methods, which support / enable the integration of one or more external services into a network, particularly into a 5GC Service Based Architecture (SBA). Here the external services refers to both services and information provided by the external network entities. A main embodiment is a network entity, e.g. a NEF, which interacts between another network entity and an external network entity.

[0011] A "service" also includes "information" provided by the external network entity. Thus, the external network entity may also provide "information".

[0012] The clone of the service is a service interface towards the other network entity and also towards the external network entity.

[0013] It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof, without departing from the scope of the invention as defined by the appended claims.BRIEF DESCRIPTION OF DRAWINGS

[0014] The above described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which FIG. 1shows network entities not covered by the claimed invention. FIG. 2shows network entities according to embodiments of the invention. FIG. 3shows a procedure between network entities according to embodiments of the invention. DETAILED DESCRIPTION OF EMBODIMENTS

[0015] FIG. 1 shows a network entity 100, an external network entity 101, and another network entity 102, which are not covered by the claimed invention. The network entity 100 is configured to support registration of the external network entity 101 and / or one or more services of the external network entity 101 at the other network entity 102. The external network entity 101 is configured to provide a service 108 to the network entity 100. The other network entity 102 is configured to register the external entity 101 and / or the one or more services 108 of the external network entity 101 (via a clone service 107). The network entities 100, 101 and 102 may be, or may be implemented by, processing circuitry or devices. In particular, the network entities 100, 101, and 102 may be implemented by network devices (e.g. one or more base stations or access nodes) and / or by wireless communication devices (e.g. UEs).

[0016] The network entity 100 of FIG. 1 may be a NF, in particular a NEF. The external network entity 101 may be a NF configured to communicate with the other network entity 102 only via the network entity 100, in particular may be an AF. The other network entity 102 may be a NF, in particular a NRF.

[0017] The external network entity 101 is configured to provide a first registration information 103 to the network entity 100, wherein the first registration information 103 includes a service profile of the service 108 provided by the external network entity 101. Accordingly, the network entity 100 may obtain the first registration information 103 of the external network entity 101 including the service profile of the service 108. The network entity 100 is then configured to create a clone 107 of the service 108, i.e. a clone service 107, based on the first registration information 103. Further, it is configured to provide a second registration information 104 to the other network entity 102, wherein the second registration information 104 includes a clone service profile of the clone service 107.

[0018] Accordingly, the other network entity 102 is configured to receive the second registration information 104 including the clone service profile. The other network entity 102 is configured to register the clone service 107 based on the second registration information 104, and to provide a first registration response 105 to the network entity 100.

[0019] The network entity 100 is configured to obtain the first registration response 105 from the other network entity 102, and to provide a second registration response 106 to the external network entity 101. Accordingly, the external network entity 101 is configured to obtain the second registration response 106 from the network entity 100. The second registration response 106 may include correlation information between the network entity 100 and the at least one service 108 of the external network entity 101 and / or the external network entity 101.

[0020] In the procedure described with respect to FIG. 1, the network entity 100 may thus serve as an agent for the external network entity 101.

[0021] FIG. 2 shows a network entity 200 according to an embodiment of the invention, an external network entity 201 according to an embodiment of the invention, and another network entity 202 according to an embodiment of the invention. The network entity 200 may be the network entity 100 shown in FIG. 1. The external network entity 201 may be the external network entity 101 shown in FIG. 1. The network entity 100 is configured to support transfer of service traffic from the external network entity 201 to the other network entity 202. The external network entity 201 is configured to provide a service 208 to the network entity 200. The service 208 may be the service 108. The other network entity 202 is configured to consume the service 208 (via clone service 207, which may be the same as clone service 107) provided by the external network entity 201. The network entities 200, 201 and 202 may be, or may be implemented by, processing circuitry or devices. In particular, the network entities 200, 201, and 202 may be implemented by network devices (e.g. one or more base stations or access nodes) and / or by wireless communication devices (e.g. UEs).

[0022] The network entity 200 of FIG. 2 may be a NF, in particular a NEF. The external network entity 201 may be a NF, particularly an AF. The other network entity 202 may be an NF.

[0023] The other network entity 202 is configured to provide a clone service invocation request 203 to the network entity 200, wherein the clone service invocation request 203 includes clone service invocation information of the clone service 207 of the service 208 provided by the external network entity 201. Accordingly, the network entity 200 obtains the clone service invocation request 203 from the other network entity 202.

[0024] The network entity 200 is configured to provide a service invocation request 204 to the external network entity 201, wherein the service invocation request 204 includes service invocation information for the service 207. The service invocation request 204 may further include correlation information between the network entity 200 and the service 207 provided by the external network entity 201 and / or the external network entity 201. The external network entity 201 is configured to obtain the service invocation request 204 from the network entity 200.

[0025] The external network entity 201 may then be configured to process the service invocation information, and to send service invocation response 205 to the network entity 200. The network entity 200 may accordingly be configured to receive the service invocation response 205 from the external network entity 201, to translate the service invocation response 205 to a clone service invocation response 206, and to provide the clone service invocation response 206 to the other network entity 202. The other network entity 202 is configured to obtain the clone service invocation response 206 from the other network entity 200, and to consume the clone service 207 based on the clone service invocation response 206.

[0026] In the procedure described with respect to FIG. 2, the network entity 200 may thus serve as an agent for the external network entity 201.

[0027] By means of the above-described network entities 100 / 200, 101 / 201, 102 and 202, respectively, the integration of at least one external service 108 / 208 into a network, e.g. a 5GC SBA, is enabled. In particular, this may be realized by providing a "registration service" (FIG. 1) and a "transfer service" (FIG. 2) at the network entity 100 / 200, which is connected directly to the other network entities 102 and / or 202 in the network, e.g. located in the 5GC SBA, and is also connected to the external network entity 101 / 201, which hosts the external service(s).

[0028] The "registration service" (Nnef_Registration) and the "transfer service" (Nnef_Transfer) can be provided by the network entity 100 / 200 as shown in the below Table 2. The external network entity 101 / 201 may, for instance, function to connect a V2X application or a TSN to the 5GC control plane through the network entity 100 / 200. Table 2: Nnef_Registration and Nnef_Transfer servicesService Name Description Reference in TS 23.502 [3] .........Nnef_AFsessionWithQoSRequests the network to provide a specific QoS for an AS session.5.2.6.9Nnef_RegistrationProvides the service for 3 rd< party AF to register at NRFNnef_TransferProvide the service for 5GS to communication with 3 rd< party AF using SBI

[0029] The "registration service" may be considered a service of the network entity 100 / 200, in order to register the external entity 101 / 201 and / or its service(s) on behalf of the external entity 101 / 201, and to provide the external service(s) to other network entities 202. External service(s) thereby means that the service(s) is not connected directly to the other network entities 202 consuming the service(s), e.g. network entities in the 5GC SBA framework, and / or that it may have a different service management system / format.

[0030] The registration service (service operation "Nnef_Registration") that may be provided by the network entity 100 / 200 to the external entity 101 is similar to the one provided by NRF described in TS23.501 section 6.2.6 and TS 23.502 Section 5.2.7. The service operation may allow the external network entity 101 / 201 to register (e.g. via request / response), or to ask for an update (e.g. via request / response), or to deregister (e.g. via request / response). The service operation may be implemented according to the following Table 3: Table 3: Nnef_Registration serviceService Name Service Operations Operation Semantics Example Consumer(s) Nnef_Registration RegisterRequest / ResponseAFUpdateRequest / ResponseAFDeregisterRequest / ResponseAF

[0031] There are envisaged two specific implementation modes for the registration service shown in Table 2 at the network entity 100 / 200 for registering the external network entity 101 / 201 and / or its service(s) at the (registration) network entity 102: proxy mode and agent mode. The agent mode is described in this document in detail.

[0032] In the agent mode, the network entity 100 / 200 receives the first registration information 103 from the external entity 101 / 201, applies the necessary mapping steps (e.g., cloning service(s) 207 / 207 and mapping information from the first registration information 103 into its own registration information), and creates the second registration information 104 that masks the external service(s) 108 / 208 as the own (clone) services 107 / 207 of the network entity 100 / 200. The effect is that any allowed further network entity 202 (e.g.NF) in the 5GS can discover and invoke service(s) 108 / 208 from the external entity 101 / 201 by invoking the clone service 107 / 207. It will, however, only be able to reach to the network entity 100 / 200 and will not be able to explicitly distinguish which service(s) (107 / 207 or 108 / 208) it is offered by the network entity 100 / 200, and which ones are exposed by the network entity 100 / 200 but belong to the external entity 101 / 201.

[0033] The "transfer service" is a service provided by the network entity 100 / 200 to bridge the communication (e.g. service request / response) between the external network entity 101 / 201 and a further network entity 202, which is a service consumer (e.g. connected to 5GC SBA framework). There are again two implementation modes for the transfer service at the network entity 100 / 200: proxy mode and agent mode. The agent mode is described in this document in detail.

[0034] In case of the clone of service is implemented as a clone service at the network entity 100 / 200 / 300, the network entity 100 / 200 / 300 receives a transfer request, i.e. the clone service invocation request 203 (e.g., subscribe / request / notification, etc.) from the further network entity 202 for a cloned service 107 / 207, which is a clone of a service 108 / 208 provided by the external network entity 101 / 201 and is generated during the registration procedure as described above. And the network entity 100 / 200 further sends the correspondent transfer request, i.e. the service invocation request 204 to the external network entity101 / 201.

[0035] In case of the clone of service is implemented as an update of existing service at the network entity 100 / 200, the network entity 100 / 200 / 300 receives a transfer request, i.e. the correspondent network service invocation request 303 (e.g., subscribe / request / notification, etc.) from the further network entity 302 for a service 307, which includes a clone of a service 108 / 208 / 308 provided by the external network entity 101 / 201 / 301 and is updated during the registration procedure as described above. And the network entity 100 / 200 / 300 further sends the correspondent transfer request, i.e. the service invocation request 204 to the external network entity 101 / 201 / 301. Table 4: Nnef_NEFcloneserviceTable 4 shows the agent mode implementation of the "transfer service" (service operation "Nnef_NEFcloneservice") and related options at the network entity 100 / 200.Service Name Service Operations Operation Semantics Example Consumer(s) Nnef_EventExposure SubscribeSubscribe / NotifyAF, NFsUnsubscribeAF, NFsNotifyAF, NFsNnef_NEFcloneservice requestRequest / Response5GS NFssubscribeSubscribe / Notify5GS NFsunsubscribe5GS NFsNotifyAF

[0036] FIG. 3 shows a procedure between various network entities according to embodiments of the invention. In particular, the procedure involves the network entity 100 / 200 (here a NEF), the external entity 101 / 201 (here an AF / 3P AF), the other network entity 102 (here a NRF), and the other network entity 202 (here a NF). In particular, FIG. 3 shows the procedure in agent mode as described in this document: The "registration service" (request / response) allows the 3P AF 101 / 201 to request the NEF 101 / 200 to register the 3P AF service(s) at the NRF 102, and the NEF 100 / 200 to register NEF Cloned Services 107 / 207 at the NRF 102, not including the 3P AF profile. "NEF Cloned Service" refers to a service identical to the service provided by the 3P AF 101 / 201, but for which the service provider appears to be the NEF 100 / 200. The 5GS NFs 202 will then be able to discover NEF Cloned Services 107 / 207 as provided by NEF 100 / 200. Upon service discovery, the "transfer service" allows the 5GS NFs 202 to access NEF Cloned Services 107 / 207, and the NEF 100 / 200 to relay the service invocation 204 (e.g. request / response or subscribe / notify) to the 3P AF 101 / 201.

[0037] A detailed description of the NEF agent mode embodiment follows. The NEF "registration service" corresponds to steps 1 - 6 in FIG. 3. The NEF "transfer service" corresponds to the steps 8 - 13 or messages in FIG. 3. 1. The 3P AF 101 / 201 requests the registration of its service(s) at the 5GS invoking the Nnef_Registration_Register, including the 3P AF profile in the request (first registration information 103). 2. The NEF 100 / 200 creates an NEF Clone Service 107 / 207, i.e. a dummy service produced by the NEF 100 / 200 replicating the interfaces of the services 108 / 208 being registered by 3P AF 101 / 201, and an AF-NEF bound allowing the NEF 100 / 200 to act as an agent translating the NEF Clone Service 107 / 207 invocations 203 (received from 5GS NFs 202) into 3P AF service invocations 204, and the 3P AF 101 / 201 service invocation responses 205 into NEF Clone Service invocation responses 206 (sent to 5GS NFs 202). 3. The NEF 100 / 200 requests the registration of the NEF Clone Service 107 / 207 at NRF 102 invoking the Nnrf_NFManagement_NFRegister / NFUpdate_request (second registration information 104), In the NF profile field (service profile), all the AF related info are replaced with NEF related info comparing to the original 3P AF profile, in order to create the clone service profile. 4. The NRF 102 stores the close service profile (e.g. a NEF profile). 5. The NRF 102 acknowledges the NEF request of step 3 sending the Nnrf_NFManagement_NFRegister / NFUpdate _response (first registration response 105) to NEF 100 / 200. 6. The NEF 100 / 200 acknowledges the 3P AF request of step 1 sending the Nnef_Registration_Register_Response (second registration response 106) to 3P AF 101 / 201. This completes the 3P AF service registration at the 5GS, and the corresponding NEF Clone Service registration at the NRF 102. The 5GS NFs 202 may discover the NEF Clone Service 107 / 207. 7. 5GS NFs 202 may execute a (NEF Clone) Service Discovery procedure. The 5GS NFs 202 may now invoke clone service 107 / 207 provided by NEF 100 / 200. 8. The 5GS NF 202 needs to invoke the clone service 107 / 207 provided by the NEF 100 / 200. The service request / subscription is created and the 5GS NF 202 invokes the NEF Clone Service 107 / 207 sending Nnef NEFCloneService_Invocation message (clone service invocation request 203, e.g. subscribe or request), including NEF Clone Service arguments (clone service invocation information). 9. The NEF 100 / 200 translates the NEF Clone Service invocation 203 into the corresponding 3P AF Service invocation (service invocation request 204). 10. The NEF 100 / 200 invokes the 3P AF service 108 / 208 sending the Naf_Service_Invocation message (service invocation request 203, e.g. subscribe or request), including service arguments derived from NEF Clone Service arguments (service invocation information). 11. The 3P AF 101 / 201 responds to the service invocation sending the Naf_Service_Reply (service invocation response 205, e.g. response for the subscribe or request) to the NEF 100 / 200. 12. The NEF 100 / 200 translates the 3P AF response to service invocation into the NEF Clone Service invocation response (clone service invocation response 206) to be sent to the 5GS NF 202. 13. The NEF 100 / 200 responds to the NEF Clone Service invocation sending the NEF Clone Service invocation response 206 to the 5GS NF 202, with the Nnef_NEFCloneService_Reply (e.g. response for the subscribe or request) message.

[0038] In case of notification from the 3P AF 101 / 201, similar steps 11a-13a may be triggered from the AF as follows: 11a. The 3P AF 101 / 201 sends the Naf_Service_Reply (service notification) to the NEF 100 / 200. 12a. The NEF 100 / 200 translates the 3P AF notification to NEF Clone Service invocation (close service notification) to be sent to the 5GS NF 202. 13a. The NEF 100 / 200 sends the NEF Clone Service invocation to the 5GS NF 202, with the Nnef_NEFCloneService_Notify message.

[0039] If the NEF 100 / 200 is implemented as an agent (agent mode), the NFs 202 consider 3P services 108 / 208 as a service 107 / 207 provided by the NEF 100 / 200. The NEF 100 / 200 generates a clone service 107 / 207 of the 3P service 108 / 208 locally. The cloned service 107 / 207 is invoked instead of the transfer service at the NEF 100 / 200 to bridge the communication between the 3P AF 101 / 201 and 5GC NFs 202. The rolls of the NEF 100 / 200 in the agent option are: Register the services 108 / 208 from the 3P AF 101 / 201 as its own services 107 / 207 to the NRF 102. Take care of the service request / subscription from the 5GS NFs 202 for services 108 / 208 provided by the 3P AF 101 / 201, and bridge to the 3P AF 101 / 201. Take care of the service message from the 3P AF 101 / 202 and bridge to the 5GS NFs 202 as service response / notification.

[0040] The registration operations for the agent mode are similar to the current one for 5GN NF. The difference is just the service profile used in the registration information 104. All the fields indicating NF-related information should be replaced with corresponding NEF-related information. The NEF 100 / 200 needs to keep the service profile (and e.g. NF profile) of the 3P AF 101 / 201 locally and map it to the clone service 107 / 207 by the NEF 100 / 200 to the NRF 102.

[0041] The NEF 100 / 200 needs to provide the same operation of the service(s) as provided by the 3P party AF 101 / 201, and forward the service message between the 3P party AF 101 / 201 and 5GC NFs 202. In case of SBA frameworks being different between the one used by 5GC and the one used by 3 rd< party AF 101 / 201, the exchanged service message needs to be converted.

[0042] The agent mode provides the following advantages: Changes only at NEF 100 / 200. Reusable service registration / consuming procedure. No NF service profile extension.

[0043] In the following, different data structures that are used by embodiments of the invention, e.g. as shown in FIG. 3, are explained. AF Transaction ID (service ID): The ID that uniquely identifies an external service is the AF Transaction ID. This is a coded ID based at least on one of information: on the owner of the 3P AF 101 / 201 and its service(s), the AF and / or service instance. NEF-AF Correlation ID (NEF-AF communication channel): Unique identifier for identifying the communications associated with one specific NEF instance and one specific instance of an external service from and AF and / or AF instance. AF Profile: Contains the same fields as NF Profile (including NS Service): ▪ In the proxy mode, the NF profile may be extended to support the extra information associated with the NF being an AF, which is defined as "AFInfo", which is information that contains at least one of: A list of designated NEFs 100 / 200 that are serving as proxy of the 3P AF 101 / 201 to the SBI. Associated S-NSSAI with external service(s). Associated DNNs with external service(s=. Identification of UE IDs (e.g. list of SUPIs) that are associated with the AF 101 / 201. Registration Mapping: NEF 100 / 200, if necessary is configured by OAM with the information to map allowed NF Profile fields to the specific AFs. For instance, in case the AF profile does not contain the allowed S-NSSAI information, the NEF 100 / 200 may use the registration mapping configuration to further subscribe to NRF 102 with the proper fields of the NF Profile. MID: Identifier of the message to be exchanged between a 5G NF 202 and external service(s). It is generated by the 5G NF 202 willing to invoke the external service(s) and should uniquely identify the communication associated with the specific container between NF ID, NEF ID, AF Transaction ID. MRespID: Uniquely identify any message from external service to the NEF 100 / 200 associated with NEF-AF Correlation ID, Mid. Mapping for controlling all communications between NF-AF via NEF 100 / 200: Such a table keeps the mapping (using above described IDs) of NF requests and responses to AF at the level of each Container. If the request from NF triggers multiple Containers from AF 101 / 201 to NF 202, the NEF 100 / 200 is able to uniquely identify each one of the answers with the MID and MRespID.

[0044] The Nnef_Registration service operation described above can be further extended to include Proxy Status Un / Subscribe / Notify service operations. These service operations enable the external network entity 101 / 201 to discover services provided by the network entities 202 via the network entity 100 / 200. This is shown below in Table 5. Table 5: Extended Nnef_Registration serviceService Name Service Operations Operation Semantics Example Consumer(s) Nnef_Registration AFRegisterRequest / ResponseAFAFUpdateRequest / ResponseAFAFDeregisterRequest / ResponseAFStatus SubscribeSubscribe / NotifyAFStatusNotifyAFStatusUnSubscribeAF

[0045] For each Nnef_Registration_Register_Req, the NEF 100 / 200 may perform authorization based on the external entity 101 / 201, which may result in the restriction of using the service(s) according to preconfigured policy, which is called Registration Mapping. The restriction is reflected in the AFinfo registered in the network entity 102.

[0046] For each Nnef_ProxyTransfer_req / subscription, the NEF 100 / 200 may perform authorization based on the NF / AF pair, which may result in the restriction of using the transfer service (e.g., period of time, maximum transfer amount of data, maximum transfer amount of data per time period, etc.) according to preconfigured policy. The restriction is reflected in the service admission control of the NEFcloneService in the proxy mode.

[0047] In summary, an example not covered by the claimed invention provides a network entity 100 / 200 for a 5GS that is configured to: Support the registration of one or more external services 108 / 208 (external network entity 101 / 201) inside the 5GS at a registration network entity 102. The registration can be provided to: ▪ Allow the information of the external service(s) 108 / 208 to be explicitly available to other network entities 202; or ▪ Make the information hidden / masked from other network entities 202. Register, at the registration network entity 102, the information to support the other network entities 202 to discover external service(s) 108 / 208 provided by the external network entity 101 / 201.

[0048] Support the exchange of communication(s) between the network entities 202 and the external network entity 101 / 201, wherein the exchange of communication can be performed in: ▪ Agent Mode: The other network entities 202 communicate with the network entity 100 / 200 without using reference ID of the external service(s) 108 / 208 or entity 101 / 201, wherein: The other network entities 202 directly communicate with the network entity 100 / 200 without any knowledge of the external service(s) 108 / 208. The network entity 100 / 200 receives communications from the other network entities 202, maps any reference ID to the external service(s) 108 / 208, keeps the parameters of the requests / communications from the network entities 202, and forwards the mapped communication to the external network entity 101 / 201. The network entity 100 / 200 receives a communication from the other external entity 101 / 202, maps the reference ID to the internal network entities 202, keeps the parameter of the communication from the external entity 101 / 201, and forwards the mapped communication to the network entities 202.

[0049] The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims, the scope of the invention is however defined by the appended claims. In the claims as well as in the description the word "comprising" does not exclude other elements or steps and the indefinite article "a" or "an" does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. Network entity (200) for supporting invocation by another network entity (202) of a service (208) provided by an external network entity (201), wherein the network entity (100) is configured to: obtain a clone service invocation request (203) from the other network entity (202), wherein the clone service invocation request (203) includes clone service invocation information of a clone of the service (208) provided by the external network entity (201), and wherein the clone of the service (208) is a service interface towards the other network entity (202) and also towards the external network entity (201), translate the clone service invocation information (203) into service invocation information, and provide a service invocation request (204) to the external network entity (201), wherein the service invocation request (204) includes the service invocation information, wherein the network entity (200) and the other network entity (202) are comprised in a network, and the external network (201) entity is external to the network.

2. Network entity (200) according to claim 1, wherein: the network entity (200) is a Network Exposure Function, NEF, the other network entity (202) is a Network Function, NF, and / or the external network entity (201) is a Network Function, NF, particularly an Application Function, AF.

3. Network entity (200) according to one of the claims 1 to 2, further configured to: obtain a service invocation response (205) from the external network entity (201), translate the service invocation response (205) to a clone service invocation response (206), and provide the clone service invocation response (206) to the other network entity (202).

4. A system comprises a network entity (200) according, to one of the claims 1 to 3, and an external network entity (201), in particular a NF, for providing a service (208) to a network entity (202), wherein the external network entity (201) is external to the network and is configured to: obtain a service invocation request (204) from the network entity (200), in particular from a NEF, wherein the service invocation request (204) includes service invocation information, process the service invocation information, and provide a service invocation response (205) to the network entity (200).

5. A method performed by a network entity for supporting invocation by another network entity of a service provided by an external network entity, wherein the method comprises: obtaining a clone service invocation request from the other network entity, wherein the clone service invocation request includes clone service invocation information of a clone of the service provided by the external network entity, and wherein the clone of the service is a service interface towards the other network entity and also towards the external network entity, translating the clone service invocation information into service invocation information, and providing a service invocation request to the external network entity, wherein the service invocation request includes the service invocation information, wherein the network entity and the other network entity are comprised in a network, and the external network entity is external to the network.

6. A method according to claim 5, wherein: the network entity (200) is a Network Exposure Function, NEF, the other network entity (202) is a Network Function, NF, and / or the external network entity (201) is a Network Function, NF, particularly an Application Function, AF.

7. A method according to one of the claims 5 to 6, further comprising: obtaining a service invocation response (205) from the external network entity (201), translating the service invocation response (205) to a clone service invocation response (206), and providing the clone service invocation response (206) to the other network entity (202).

8. A computer program product for storing program code for performing at least one of the methods according to claims 5 to 7, when the program code is run by a processor of a network entity.