Patent Description:
<FIG> schematically shows a high level architecture in the next generation network such as <NUM>. The system architecture of <FIG> may comprise some exemplary elements such as UE (User Equipment), AMF (Access and Mobility Management Function), SMF (Session Management Function), AUSF (Authentication Server Function), UDM (Unified Data Management), PCF (Policy Control Function), AF (Application Function), NSSF (Network Slice Selection Function), NEF (Network Exposure Function), UPF (User plane Function) and NRF (NF Repository Function), (R)AN ((Radio) Access Network), SCP (Service Communication Proxy), DN (Data Network), etc..

In accordance with an exemplary embodiment, the UE can establish a signaling connection with the AMF over the reference point N1, as illustrated in <FIG>. This signaling connection may enable NAS (Non-access stratum) signaling exchange between the UE and the core network, comprising a signaling connection between the UE and the (R)AN and the N2 connection for this UE between the (R)AN and the AMF. The (R)AN can communicate with the UPF over the reference point N3. The UE can establish a protocol data unit (PDU) session to the DN (data network, e.g. an operator network or Internet) through the UPF over the reference point N6.

As further illustrated in <FIG>, the exemplary system architecture also contains the service-based interfaces such as Nnrf, Nnef, Nausf, Nudm, Npcf, Namf and Nsmf exhibited by NFs such as the NRF, the NEF, the AUSF, the UDM, the PCF, the AMF and the SMF. In addition, <FIG> also shows some reference points such as N1, N2, N3, N4, N6 and N9, which can support the interactions between NF services in the NFs. For example, these reference points may be realized through corresponding NF service-based interfaces and by specifying some NF service consumers and providers as well as their interactions in order to perform a particular system procedure.

In third Generation Partnership Project (3GPP) Technical Specification (TS) <NUM> V16. <NUM>, service communication proxy (SCP) as a network element is introduced in service framework. Routing of the service based interface (SBI) messages for network function (NF) interaction mechanisms may be direct as shown in model A and model B of <FIG>, or indirect in model C and model D of <FIG>. In case of indirect communication, the SCP is employed by the NF service consumer. The SCP routes messages between NF service consumers and NF service producers and may do discovery and associated selection of the NF service producer on behalf of a NF service consumer.

In fifth generation system (5GS), the SCP can be deployed distributed, redundant, and scalable. SCPs can be deployed at PLMN (public land mobile network) level, shared-slice level and slice-specific level.

As shown in <FIG>, in Model A - Direct communication without network repository function (NRF) interaction, neither NRF nor SCP are used. NF consumers are configured with NF producers' "NF profiles" and directly communicate with a producer of their choice.

In Model B - Direct communication with NRF interaction, NF consumers do discovery by querying the NRF. Based on the discovery result, the NF consumer does the selection. The NF consumer sends the request to the selected NF producer.

In Model C - Indirect communication without delegated discovery, NF consumers do discovery by querying the NRF. Based on discovery result, the NF consumer does the selection of a NF Set or a specific NF instance of NF instance set. The NF consumer sends the request to the SCP containing the address of the selected service producer pointing to a NF service instance or a set of NF service instances. In the latter case, the SCP selects a NF service instance. If possible, the SCP interacts with NRF to get selection parameters such as location, capacity, etc. The SCP routes the request to the selected NF service producer instance.

In Model D - Indirect communication with delegated discovery: NF consumers do not do any discovery or selection, the NF consumer adds any necessary discovery and selection parameters required to find a suitable producer to the service request. The SCP uses the request address and the discovery and selection parameters in the request message to route the request to a suitable producer instance. The SCP can perform discovery with an NRF and obtain a discovery result.

As described in clause <NUM>. <NUM> of 3GPP TS <NUM> V16. <NUM>, the SCP may include one or more of the following functionalities. Some or all of the SCP functionalities may be supported in a single instance of an SCP:.

In current 5GS architecture, there are some problems. For example, when one NF instance in NF Set fails, the network can't automatically re-direct the request to other equivalent NF instance without service break, and without NF consumer intervention.

For the NF consumer, the discovery result can be cached locally. The NF consumer can use the local cache to shorten the end to end service operation latency. But the cache is for NF instances, NF consumer needs to monitor all instances separately to secure the cache information is valid, the process is complicated.

For the NF producer, sometimes the traffic load between all instances in the same NF set is not balanced, so there needs a method to improve the utilization of network resource.

To overcome or mitigate at least one above mentioned problems or other problems or provide a useful solution, the embodiments of the present disclosure propose an improved flow control solution.

Aspects of the invention are set out in the independent claims appended hereto.

Many advantages may be achieved by applying the proposed solution according to embodiments of the present disclosure. For example, some embodiments of the present disclosure can provide the way for NF consumer to customize and optimize its service operation. For example, for the High frequency access service, the consumer can customize the query parameters one time, and create the service entry in SCP. After then, all subsequent similar operation can be sent directly to that service entry URI (Uniform Resource Identifier) instead of doing discovery first. And the service entry can be used to introduce the new installation to share traffic without any NF consumer awareness. And also, it provides a new way to balance the network workload.

As used herein, the term "network" refers to a network following any suitable communication standards such as new radio (NR). In the following description, the terms "network" and "system" can be used interchangeably. Furthermore, the communications between two devices in the network may be performed according to any suitable communication protocols, including, but not limited to, the communication protocols as defined by a standard organization such as 3GPP. For example, the communication protocols may comprise the fifth generation (<NUM>) communication protocols, and/or any other protocols either currently known or to be developed in the future.

The term "network device" or "network node" used herein refers to a network entity such as a core network device in a communication network. For example, in a wireless communication network such as a 3GPP-type cellular network, the network node may implement various network functions, which may offer numerous services to customers who are interconnected by an access network device. Each access network device is connectable to the core network device over a wired or wireless connection.

The term "network function (NF)" refers to any suitable function which can be implemented in a network node (physical or virtual) of a communication network. For example, the <NUM> system (5GS) may comprise a plurality of NFs such as AMF (Access and Mobility Management Function), SMF (Session Management Function), AUSF (Authentication Server Function), UDM (Unified Data Management), PCF (Policy Control Function), AF (Application Function), NEF (Network Exposure Function), UPF (User plane Function) and NRF (NF Repository Function), (R)AN ((radio) access network), SCP (service communication proxy), etc. In other embodiments, the network function may comprise different types of NFs for example depending on a specific type of network.

The term "terminal device" refers to any end device that can access a communication network and receive services therefrom. By way of example and not limitation, the terminal device refers to a mobile terminal, user equipment (UE), or other suitable devices. The UE may be, for example, a Subscriber Station (SS), a Portable Subscriber Station, a Mobile Station (MS), or an Access Terminal (AT). The terminal device may include, but not limited to, a portable computer, an image capture terminal device such as a digital camera, a gaming terminal device, a music storage and a playback appliance, a mobile phone, a cellular phone, a smart phone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet, a wearable device, a personal digital assistant (PDA), a portable computer, a desktop computer, a wearable terminal device, a vehicle-mounted wireless terminal device, a wireless endpoint, a mobile station, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a USB dongle, a smart device, a wireless customer-premises equipment (CPE) and the like. In the following description, the terms "terminal device", "terminal", "user equipment" and "UE" may be used interchangeably. As one example, a terminal device may represent a UE configured for communication in accordance with one or more communication standards promulgated by the 3GPP, such as 3GPP' LTE (long term evolution) standard or NR (new radio) standard. As used herein, a "user equipment" or "UE" may not necessarily have a "user" in the sense of a human user who owns and/or operates the relevant device. In some embodiments, a terminal device may be configured to transmit and/or receive information without direct human interaction. For instance, a terminal device may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the communication network. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but that may not initially be associated with a specific human user.

As yet another example, in an Internet of Things (IOT) scenario, a terminal device may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another terminal device and/or network equipment. The terminal device may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as a machine-type communication (MTC) device. As one particular example, the terminal device may be a UE implementing the 3GPP narrow band internet of things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances, for example refrigerators, televisions, personal wearables such as watches etc. In other scenarios, a terminal device may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation.

It is noted that these terms as used in this document are used only for ease of description and differentiation among nodes, devices or networks etc. With the development of the technology, other terms with the similar/same meanings may also be used.

As used herein, the NF consumer may be any suitable NF or NF instance which needs to use one or more services provided by another NF. The NF producer may be any suitable NF or NF instance which can provide one or more services to one or more NF consumers. For example, NRF can provide service discovery function to any other NF instance or SCP. In this case, NRF is the NF producer and said any other NF instance or SCP is the NF consumer. As another example, if a NF can provide one or more services to any other NFs, it will register its NF profile in the NRF. In this case the NF is the NF consumer of NRF and the NF producer of said any other NFs.

As used herein, SCP can register, de-register, and update its profile in NRF, e.g. similar as a NF. A NF consumer can discover the appropriate SCP(s) for different purpose via NRF. To make SCP to register itself into NRF, the SCP can register, de-register, update its profile in NRF, e.g. similar as a NF. The profile of SCP may include its function/feature capability, deployment topology, and/or query parameters for discovery. For example, the parameters can be locality of SCP, the capacity, the priority etc. NF consumer can discover the appropriate SCP(s) for different purpose. For example, to find a default forwarding proxy in the same data center, the NF consumer can use the locality as query parameter to do discovery. NF consumer can subscribe interested SCP(s) status, and it can take action based on status notification. For example, NF consumer can change to a new SCP when the previous serving SCP is down, or busy etc..

In <NUM> SA (Stand Alone) network, NF Set is an important logical concept. It indicates a group of interchangeable NF instances, supporting the same services and the same Network Slice(s). The NF instances in the same NF Set may be geographically distributed but have access to the same context data.

If NF consumer wants to employ a NF service belonging to such NF Set, NF consumer needs to find and select one NF instance in NF Set to communicate with. NF consumer needs to care about the health of that specific selected NF instance in NF set. In case the selected NF instances fails, the NF consumer needs to re-select a new instance, and could cause the request failure due to one target in NF set failure.

The NF Set is deployed in network for redundancy, and load balancer etc., but due to that the target is selected by NF consumer (client side), this kind of selections are decided independently by each NF consumer itself.

<FIG> shows a flowchart of a method according to an embodiment of the present disclosure, which may be performed by an apparatus implemented in/at or communicatively coupled to a SCP. As such, the apparatus may provide means for accomplishing various parts of the method <NUM> as well as means for accomplishing other processes in conjunction with other components.

At block <NUM>, the SCP receives a first request for creating a service entry, wherein the first request includes at least one parameter to build the service entry context. The SCP may provide service communication proxy function similar to the SCP as described in clause <NUM>. <NUM> of 3GPP TS <NUM> V16. In other embodiments, the SCP may be any suitable service communication proxy in other communication network. The SCP may be triggered to create the service entry in various ways. In one embodiment, the first request may be transmitted from a NF consumer. For example, NF consumer sends the first request to create the service entry for various reasons, e.g.: to improve the efficiency of service usage or anchor the NF set via service entry. In another embodiment, the first request may be transmitted from a NF producer. For example, the NF producer can send the first request to SCP for various reasons, e.g.: canary upgrading.

The at least one parameter in the first request may be of different types depending on the purpose. For example, if the NF consumer wants to create a service entry for "NF SET A" on the SCP, the parameters can be the "NF set= NF set A" to indicate the specific NF set. In another example, if the NF consumer wants to create a service entry to avoid the high frequent NRF discovery request, the parameters can be as following: NF type = UDM, target-plmn-list = local PLMN, in which the parameter "NF type" is to define the NF instance type, and the parameter "target-plmn-list" is to define the scope of the NF instances is the PLMN (public land mobile network).

And the parameters can also be policies related parameters indicating the policies needed to be applied to the SCP. For example, the policy may be for workload balance to protect the NF producer instance from overload. In another example, the policy may be for quick response to choose the NF producer instance which has the smallest latency. And further, these parameters can be updated according to request of the creator of the service entry (for example, by the NF consumer or the NF producer).

In one embodiment, after SCP receives the first request, it sends a second request for discovering related NF instances, to network repository function, NRF. And when NRF receives the second request, it will determine the related NF instances, and send the list of the related NF instances to the SCP. The list of the NF instances can be determined based of the request. For example, if the first request is for creating a service entry for one NF set, in which the NF instances in the one NF set provide the same service capability, the NRF will determine the list of the NF instances of the same set. In another example, if the first request is for creating a service entry for NF instances of the same type, e.g.: UDM, the NRF will determine the list of the NF instances of the same type, herein the NF instances of the same type may be not in the same set. In another example, if the first request is for creating a service entry for NF instances which have at least one same commonality, herein the NF instances of the same commonality may not of the same set nor of the same type, the NRF will determine the list of theses specific NF instances.

At block <NUM>, the SCP creates the service entry based on the parameters in the first request. The service entry can be created in various ways. For example, SCP creates the service entry context for the NF set A based on the list of the NF instance of NF set A, SCP prepares corresponding resources, monitors those instance statuses, and the SCP establishes the corresponding connections in advance and is prepared to receive external service requests. In another example, SCP establishes a mapping between the UE identifiers and the NF instances of the same type in the PLMN, then SCP prepares the corresponding resources, and the SCP establishes connection with all selected NF instances and monitors their status.

The method further comprises sending a first response to the first request to the NF consumer, wherein the first response includes an address of the service entry. The address of the service entry may be in various format that can make the NF find the service entry. For example, the address of the service entry may be the resource URI of the service entry.

In an embodiment, the method may further comprise sending a first message to the NRF to update the repository of NRF, and the first message includes the service entry context information as part of NF profile of the SCP, so that other NF can find the address of the service entry via NRF.

At block <NUM>, the SCP applies the service entry to process a service request from a network function (NF) consumer. This step can be implemented in various ways. In one embodiment, if the SCP received a service request for NF set A, including the address of the service entry, it will select a NF instance according to the policies in service entry context, and then send the service request to the selected NF instance. The policies herein can be various, e.g.: if the policy is for workload balance to protect the NF producer instance from overload, the SCP will choose a NF producer which has a lower workload; if the policy maybe for quick response, the SCF will choose the NF producer instance which has the shortest end-to-end delay. In another example, if receiving a service request for the same type instances, the SCP will determine a NF instance based on the mapping, and then send the service request to the NF instance.

<FIG> shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in/at or communicatively coupled to a NF. As such, the apparatus may provide means for accomplishing various parts of the method <NUM> as well as means for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, and detailed description thereof is omitted here for brevity.

At block <NUM>, the NF determines at least one parameter for creating a service entry by a service communication proxy, SCP. The NF herein can be NF consumer or NF producer. For example, NF consumer sends the first request to create the service entry for various reasons, e.g.: to improve the efficiency of service usage or anchor the NF set via service entry. In another embodiment, the first request may be transmitted from a NF producer. For example, the NF producer can send the first request to SCP for various reasons, e.g.: canary upgrading.

The at least one parameter in the first request may be of different types depending on the purpose. For example, if the NF consumer wants to create a service entry for "NF SET A" on the SCP, the parameters can be the "NF set= NF set A" to indicate the specific NF set. In another example, if the NF consumer wants to create a service entry to avoid the high frequent NRF discovery request, the parameters can be as following: NF type = UDM, target-plmn-list = local PLMN, in which the parameter "NF type" is to define the NF instance type, and the parameter "target-plmn-list" is to define the scope of the NF instances is the PLMN (public land mobile network). And the parameters can also be policies related parameters indicating the policies needed to be applied to the SCP.

At block <NUM>, the NF sends a first request for creating the service entry to the service communication proxy, SCP. After NF sends the first request to the SCP, the SCP will create the service entry. The process of the creating has been described in the above embodiments, and detailed description thereof is omitted here for brevity.

In an embodiment, the method further comprises receiving a first response to the first request from the SCP, and the first response includes an address of the service entry.

In an embodiment, the method further comprises discovering the SCP via a network repository function, NRF.

In an embodiment, the method further comprises sending a service request to the SCP, and the service request includes the address of the service entry. After sending the service request to the SCP, the SCP will apply service entry to process the service request. The process of the applying has been described in the above embodiments, and detailed description thereof is omitted here for brevity.

The advantages of the above embodiment are as following: the service entry is provided for a set of NF producers to create logic anchor point to attract the service requests to a gateway, and the network level load balancing, policy enforcement can be implemented in that. The polices on the service entry can be diverse and rich enough to meet specific application scenarios. For example, as to a time-based policy, the service entry can be set to: which NF instance shall be avoided to be used in busy hour by which NF producer.

<FIG> shows a flowchart of a method according to another embodiment of the present disclosure. In this embodiment, the service entry creation is triggered by the NF producer.

In step <NUM>, the SCP is registered as a NF to the NRF.

In step <NUM>, the SCP is configured in NF Producer #<NUM> for SBI intermediate communication. NF producer #<NUM> sends a registration message with its profile to NRF via the SCP.

In step <NUM>, the SCP profile is updated. Particularly, the step <NUM> may include step S503a, and step S503b. In step 503a, the SCP creates a Service Entry to anchor the services for this NF producer #<NUM>.

In step 503b, if in this SCP, a service entry for NF Set A is already there, and the NF producer #<NUM> belongs to the NF Set A, SCP will add NF producer #<NUM> as one instance of a NF Set into the existing service entry for NF Set A.

SCP sends Nnrf profile update message to the NRF with added Service Entry context.

In step <NUM>, by querying NRF, the NF consumer makes discovery to find the NF Set A. The NRF responds to all matching NF instances and service entry for NF Set A.

In step <NUM>, the NF consumer selects the service entry as target, and sends the service request to the address of service entry. SCP receives and forwards this request to the real selected backend NF producer instance. For all subsequent requests to NF Set A can be sent to the service entry URI instead of selecting the NF instance.

<FIG> shows a flowchart of a method according to another embodiment of the present disclosure. In this embodiment, the service entry creation is triggered by the NF consumer.

In step S601, the NF consumer creates a service entry for "NF SET A" on the SCP. The request can also comprise some policies related parameters (e.g. load balancer model) which are used to build the service entry context in SCP.

In step S602, the SCP create a service entry according to the request from NF consumer. This service entry will anchor all requests to NF Set A, and the policies in request will be also applied.

The SCP discovers all NF instances belonging to NF set A through the NRF.

In step S603, the NRF responds with a list of service instances belonging to NF SET A.

In step S604, the SCP creates the service entry context for the NF set A, SCP prepares corresponding resources, monitors those instance statuses, and the SCP establishes the corresponding connections in advance and is prepared to receive external service requests. The SCP acts as a service entry to proxy requests for NF Set A.

In step S605, the SCP updates its profile on the NRF using the context of the relevant service entry. So, any NF consumer can discover the service entry of NF Set A, and can use the service entry URI for service request towards NF Set A.

In step S606, the NRF responds with <NUM> OK, including the resource URI of the service entry.

In step S607, when NF consumer wants to employ the service provided by NF Set A, it uses the Service Entry URI as the Resource URI in the corresponding request.

For other NF consumers, the service Entry URI also can be found through a discovery request to NRF.

In step S608, the SCP receives requests on service entry that process these requests according to the policies of the service entry, for example, selecting the shortest end-to-end delay NF producer instance (e.g., NF <NUM>). The SCP forwards the request to the selected NF producer.

In step S609, the communication between the NF consumer and NF producer is via the Service entry forwarding.

Through creating the service entry for the same NF set in SCP, all subsequent similar operation can be sent directly to that service entry URI instead of doing discovery first, thus redundant signaling are avoided and the NF discovery process for the same NF set is simplified.

In step S701, the NF consumer wants to create a service entry to avoid the high frequent NRF discovery request caused by finer granularity selection parameter, e.g. UDM selection for different SUPI.

The NF consumer creates a service entry on the SCP with the parameter: "NF type = UDM, target-plmn-list = local PLMN". This is a thicker granularity for UDM selection.

In step S702, to create the requested service entry above, the SCP needs to build the context for it. At first, the SCP discovers the NF instance matching the query parameter "NF type = UDM, target-plmn-list = local PLMN" through the NRF.

In step S703, the NRF responds with a list of UDM instances serving the local PLMN subscriber.

In step S704, based on those NF profile from NRF, and policies from the request, the SCP creates the relevant context, prepares the corresponding resources, and the SCP establishes connection with all selected NF instances and monitors their status. The SCP acts as a service entry to proxy requests for UDMs serving local PLMN subscribers.

For example, for context and resources, a subscriber in a PLMN can be divided into multiple UDM groups, each serving a subset of users, and each group having several equivalent UDM instances.

To look up a service/UDM instance from SUPI, the service entry needs to build an internal mapping table between SUPI, Group ID, and UDM instances for selection.

In step S705, after all those contexts and resource prepared, the SCP updates its profile on the NRF with the information of service entry, e.g. by using the context of the relevant service entry.

In step S706, the NRF responds with <NUM> OK, including the resource URI of the service entry.

In step S707, when an AMF needs to talk with UDM for specific subscriber (identified by SUPI), AMF can discover through the NRF with thicker granularity filter parameter (i.e. NF type = UDM, target-plmn-list = local PLMN) to find the service entry, and send the request to that service entry directly instead of selecting a UDM instance. And this service entry can be cached locally, and can be used for any subsequent similar request.

In step S708, the SCP receives service entry requests based on the policy of the service entry to process the requests, for example, a policy "choose one located in the same data center. " The SCP forwards the request to the UDM instance serving SUPI = XXXX and it is in the same data center as the AMF.

In step S709, the communication between the NF consumer and NF producer is via the Service entry forwarding.

Through creating the service entry for the same type NF instance, UDM, in SCP, all subsequent similar operation can be sent directly to that service entry URI instead of doing discovery at first, thus redundant signaling are avoided and the UDM discovery process can be simplified.

<FIG> is a block diagram showing an apparatus suitable for use in practicing some embodiments of the disclosure. For example, any one of the SCP or the NF such as NF service consumer as described above may be implemented through the apparatus <NUM>.

The apparatus <NUM> comprises at least one processor <NUM>, such as a DP (data processor/digital processor), and at least one memory MEM <NUM> coupled to the processor <NUM>. The apparatus <NUM> may further comprise a transmitter TX and receiver RX <NUM> coupled to the processor <NUM>. The MEM <NUM> stores a program PROG <NUM>. The PROG <NUM> may include instructions that, when executed on the associated processor <NUM>, enable the apparatus <NUM> to operate in accordance with the embodiments of the present disclosure. A combination of the at least one processor <NUM> and the at least one MEM <NUM> may form processing means <NUM> adapted to implement various embodiments of the present disclosure.

Various embodiments of the present disclosure may be implemented by computer program executable by one or more of the processor <NUM>, software, firmware, hardware or in a combination thereof.

The MEM <NUM> may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memories and removable memories, as non-limiting examples.

The processor <NUM> may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors DSPs and processors based on multicore processor architecture, as non-limiting examples.

According to an aspect of the disclosure it is provided a computer program product being tangibly stored on a computer readable storage medium and including instructions which, when executed on at least one processor, cause the at least one processor to carry out any of the methods related to the SCP as described above.

According to an aspect of the disclosure it is provided a computer program product being tangibly stored on a computer readable storage medium and including instructions which, when executed on at least one processor, cause the at least one processor to carry out any of the methods related to the NF as described above.

According to an aspect of the disclosure it is provided a computer-readable storage medium storing instructions which when executed by at least one processor, cause the at least one processor to carry out any of the methods related to the SCP as described above.

According to an aspect of the disclosure it is provided a computer-readable storage medium storing instructions which when executed by at least one processor, cause the at least one processor to carry out any of the methods related to the NF as described above.

The techniques described herein may be implemented by various means so that an apparatus implementing one or more functions of a corresponding apparatus described with an embodiment comprises not only prior art means, but also means for implementing the one or more functions of the corresponding apparatus described with the embodiment and it may comprise separate means for each separate function or means that may be configured to perform one or more functions. For example, these techniques may be implemented in hardware (one or more apparatuses), firmware (one or more apparatuses), software (one or more modules), or combinations thereof. For a firmware or software, implementation may be made through modules (e.g., procedures, functions, and so on) that perform the functions described herein.

Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the subject matter described herein, but rather as descriptions of features that may be specific to particular embodiments.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any implementation or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular implementations. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.

Claim 1:
A method at a service communication proxy, SCP, comprising:
receiving (<NUM>) a first request for creating a service entry, wherein the first request includes at least one parameter to build a context for the service entry;
creating (<NUM>) the service entry based on the at least one parameter in the first request;
applying (<NUM>) the service entry to process a service request from a network function, NF, consumer; and
sending a first response to the first request to the NF consumer, wherein the first response includes an address of the service entry.