Patent Description:
In a communication system, an edge computing technology has been known, which deploys a function regarding network user data near equipment. This enables reduction in communication latency, and also enables decentralization of load in a system. For example, it has been proposed to use an edge server for managing a wireless resource of a base station in accordance with characteristics of equipment (refer to, for example, Patent Document <NUM>).

In the conventional art described above, deployment of a desired function near equipment enables low latency of a network and management of a wireless resource between the equipment and a base station. However, there is a problem that it is impossible for a service provider to flexibly control deployment of a network function in edge computing, and it is difficult to achieve satisfactory performance.

The present technology has been conceived in view of such a circumstance, and an object of the present technology is to flexibly control deployment of a network function in edge computing.

The present technology has been made to solve the problems described above. There is provided a network deployment control apparatus and a corresponding method according to the appended claims.

Hereinafter, a description will be given of a mode for carrying out the present technology (hereinafter, referred to as an embodiment). The description is given in the following order.

<FIG> is a diagram that illustrates an overall configuration example of a communication system according to an embodiment of the present technology. This communication system includes a core network <NUM> conforming to the third generation partnership project (3GPP) standard, and a base station apparatus <NUM>.

The core network <NUM> is a backbone that constitutes a public network, and examples thereof may include an evolved packet core (EPC) and a <NUM> next generation core. This core network <NUM> is dividable into a control plane <NUM> and a user plane <NUM>. The control plane <NUM> is a functional group for control processing such as line connection. The user plane <NUM> is a functional group for user data exchange processing.

The base station apparatus <NUM> is a base station that constitutes a radio access network (RAN) and provides a network connection to equipment <NUM>. This base station apparatus <NUM> is connected to the core network <NUM> via a backhaul line <NUM>.

The backhaul line <NUM> is a line that relays an access line of the base station apparatus <NUM> and a backbone line of the core network <NUM> in a wireless or wired manner.

The equipment <NUM> is user equipment (UE) which a user uses.

In the 3GPP, new radio access (NR) for a fifth generation cellular communication system (<NUM>) has been taken into consideration as a successor to a RAN called long term evolution (LTE). The NR has two features. One of the features is to achieve high-speed and large-capacity communication, using a frequency band from <NUM> or more to <NUM>. The other feature is to efficiently accommodate communication forms of various use cases. Here, various use cases involve high-speed and large-capacity communication, low-latency communication, and machine type communication (MTC). Moreover, it is required to simultaneously accommodate device to device (D2D). It is required to accommodate these various communications in one network.

There has conventionally been an EPC as a technology on the core network side connected to a RAN.

A new core has currently been taken into consideration as a successor to the EPC. It is required for the new core to efficiently accommodate various communication forms, such as mobile broad band, low latency communication, MTC, and D2D, which the NR provides and to reduce capital expense and operating expense (CAPEX/OPEX). It is difficult to provide the various communication forms while keeping the CAPEX/OPEX low, if separate communication networks are prepared. It is therefore necessary to achieve the operation using a single network and to flexibly change the capacity of the network in response to the importance of the communication amount of each communication form.

<FIG> is a diagram that illustrates a functional configuration example of the communication system according to the embodiment of the present technology. UE <NUM> corresponds to the equipment <NUM> described above. An RAN <NUM> corresponds to the base station apparatus <NUM> described above.

As described above, the core network <NUM> is dividable into the control plane <NUM> and the user plane <NUM>. In this example, the control plane <NUM> includes an NEF <NUM>, a PCF <NUM>, a UDM <NUM>, an AF <NUM>, an AUSF <NUM>, an SMF <NUM>, an NSSF <NUM>, an NRF <NUM>, an AMF <NUM>, and an ECMF <NUM>. Here, the ECMF <NUM> is a new function in this embodiment, and the remaining functions are existing network functions of the 3GPP.

These network functions are connected to a bus. These network functions receive a response to a request, thereby receiving a predetermined service (SBA: Service Based Architecture). A protocol in this SBA is based on HTTP/<NUM>, and information is exchangeable using a file format of a JavaScript object notation (JSON) format (JavaScript is registered trademark).

The application function (AF) <NUM> exchanges information with the core network <NUM> in order to supply a service. The AF <NUM> is capable of transmitting a service request and receiving a response from each network function via the NEF <NUM>. Basically, it is used in order that the AF <NUM> acquires the information of each network function. The AF <NUM> is capable of acquiring from the core network <NUM> information, such as a position, a time zone, and a connection state (an idling state/an RRC connection state), concerning the UE <NUM>. Note that this AF <NUM> can be deployed inside or outside the core network <NUM>.

The network exposure function (NEF) <NUM> is an interface that provides information of each function in the core network <NUM> to the AF <NUM> inside or outside the core network <NUM>.

The policy control function (PCF) <NUM> provides a quality of service (QoS) policy.

The unified data management (UDM) <NUM> performs control for storing data in the core network <NUM>.

The authentication server function (AUSF) <NUM> has a function of authenticating whether or not the UE <NUM> is reliable equipment in an attach request.

The session management function (SMF) <NUM> has a function of processing the attach request of the UE <NUM>.

The network slice selection function (NSSF) <NUM> has a function of allocating a network slice to the UE <NUM>.

The network repository function (NRF) <NUM> performs service discovery.

The access and mobility management function (AMF) <NUM> performs control on handover.

The edge computing management function (ECMF) <NUM> is a new function in this embodiment, and manages the deployment of the network function in the core network <NUM>.

The user plane <NUM> includes a UPF <NUM> and a DN <NUM>. The user plane function (UPF) <NUM> is a connection point with the data network (DN) <NUM>. In edge computing, the UPF <NUM> is deployed nearer to the UE <NUM> as much as possible. That is, the deployment of the part including the UPF <NUM> and the DN <NUM> in the network near the UE <NUM> and the RAN <NUM> connected with the UE <NUM> in terms of distance enables reduction in transfer latency between the UE <NUM> and the DN <NUM>.

<FIG> is a diagram that illustrates a functional configuration example of the AF <NUM> according to the embodiment of the present technology. This AF <NUM> includes an acquisition unit <NUM>, a fixing unit <NUM>, and a setting request unit <NUM>.

The acquisition unit <NUM> acquires information regarding performance corresponding to a deployment position of a predetermined partial function of the core network <NUM>. It is mainly assumed in this first embodiment that the acquisition unit <NUM> acquires information regarding performance corresponding to a deployment position of the UPF <NUM>.

The fixing unit <NUM> fixes the deployment position of the partial function on the basis of the information regarding the performance and acquired by the acquisition unit <NUM>. It is mainly assumed in this first embodiment that the fixing unit <NUM> fixes the deployment position of the UPF <NUM>.

The setting request unit <NUM> issues a request of setting the partial function for the deployment position fixed by the fixing unit <NUM>, to the ECMF <NUM> of the core network <NUM>.

In general, it is often difficult for the AF <NUM> to designate the deployment position of the UPF <NUM>. This is because even when the actual location of the network is designated with latitude and longitude, the perspective of the actual location may be meaningless depending on the topology of the network. It is therefore desirable that the core network <NUM> gives a plurality of configurations that enable deployment of the UPF <NUM>, to the AF <NUM> in advance. For each configuration, a latency time between the base station apparatus <NUM> and the UPF <NUM> is disclosed as information.

Furthermore, in a case where it is desired to issue a request of deploying the UPF <NUM> in consideration of a latency between the AF <NUM> and the UPF <NUM>, the AF <NUM> issues a request of measuring a latency between the AF <NUM> and a supposed location of the UPF <NUM>. The fixing may of course be made in consideration of both the latency between the base station apparatus <NUM> and the UPF <NUM> and the latency between the UPF <NUM> and the AF <NUM>.

<FIG> is a sequence diagram that illustrates a first example of a processing procedure according to the first embodiment of the present technology.

The core network <NUM> acquires information regarding a latency time from the base station apparatus <NUM> for each deployment position of the UPF <NUM> (<NUM>). That is, the core network <NUM> is capable of acquiring information regarding a latency time in advance.

The AF <NUM> issues a request of the information regarding the latency time to the core network <NUM> (<NUM>). In response to this, the core network <NUM> gives the information regarding the latency time to the AF <NUM> (<NUM>).

The AF <NUM> fixes the deployment position of the UPF <NUM> in consideration of the information regarding the latency time (<NUM>), and issues a request of setting the deployment position of the UPF <NUM> to the core network <NUM> (<NUM>).

The core network <NUM> deploys the UPF <NUM> in response to the request from the AF <NUM> (<NUM>).

<FIG> is a diagram that illustrates a first example of information given to the AF <NUM> according to the first embodiment of the present technology.

This first example concerns information regarding a latency time between the base station apparatus <NUM> and the UPF <NUM>. That is, "<NUM>", "<NUM>", and "<NUM>" are indicated for a setting number "<NUM>", a setting number "<NUM>", and a setting number "<NUM>", respectively. The AF <NUM> selects one from these alternatives, and issues a request of setting the deployment position of the UPF <NUM> to the core network <NUM>, using the setting number.

<FIG> is a sequence diagram that illustrates a second example of the processing procedure according to the first embodiment of the present technology.

In this second example, in order to deploy the UPF <NUM> in consideration of a latency between the AF <NUM> and the UPF <NUM>, the AF <NUM> issues a request of measuring a latency between the AF <NUM> and the supposed location of the UPF <NUM>, to the core network <NUM> (<NUM>).

The core network <NUM> measures an assumed latency time between the UPF <NUM> and the AF <NUM> (<NUM>).

The AF <NUM> issues a request of the information regarding the latency time between the UPF <NUM> and the AF <NUM> to the core network <NUM> (<NUM>). In response to this, the core network <NUM> gives the information regarding the latency time to the AF <NUM> (<NUM>).

<FIG> is a diagram that illustrates a second example of the information given to the AF <NUM> according to the first embodiment of the present technology.

This second example concerns information regarding a latency time between the AF <NUM> and the UPF <NUM>. That is, "<NUM>", "<NUM>", and "<NUM>" are indicated for a setting number "<NUM>", a setting number "<NUM>", and a setting number "<NUM>", respectively. The AF <NUM> selects one from these alternatives, and issues a request of setting the deployment position of the UPF <NUM> to the core network <NUM>, using the setting number.

<FIG> is a sequence diagram that illustrates a third example of the processing procedure according to the first embodiment of the present technology.

In this third example, the UPF <NUM> is deployed in consideration of both information regarding a latency time between the base station apparatus <NUM> and the UPF <NUM> and information regarding a latency time between the AF <NUM> and the UPF <NUM>. Therefore, the core network <NUM> measures information regarding an assumed latency time between the UPF <NUM> and the base station apparatus <NUM> (<NUM>).

Furthermore, the AF <NUM> issues a request of measuring a latency between the AF <NUM> and a supposed location of the UPF <NUM>, to the core network <NUM> (<NUM>).

The AF <NUM> fixes the deployment position of the UPF <NUM> in consideration of both the information regarding the latency time between the base station apparatus <NUM> and the UPF <NUM> and the information regarding the latency time between the AF <NUM> and the UPF <NUM> (<NUM>), and issues a request of setting the deployment position of the UPF <NUM> to the core network <NUM> (<NUM>).

The foregoing examples each exemplify information regarding a latency time, as the information regarding the performance of the deployment position of the UPF <NUM>. In addition to the latency described above, a cost, a resistance to congestion, an assumed throughput, and the like are assumed as the information regarding the performance, and a combination including at least one of them may be made.

<FIG> is a diagram that illustrates a third example of the information given to the AF <NUM> according to the first embodiment of the present technology.

This third example concerns information regarding a resistance to congestion. That is, a "low" resistance, a "high" resistance, and a "middle" resistance are indicated for a setting number "<NUM>", a setting number "<NUM>", and a setting number "<NUM>", respectively. The AF <NUM> selects one from these alternatives, and issues a request of setting the deployment position of the UPF <NUM> to the core network <NUM>, using the setting number.

Note that in a case where the UPF <NUM> is deployed near the base station apparatus <NUM> and the AF <NUM> is deployed near the UPF <NUM>, an influence of congestion on the depth side of the core network <NUM> is less likely to be caused since the path is short.

<FIG> is a diagram that illustrates a fourth example of the information given to the AF <NUM> according to the first embodiment of the present technology.

This fourth example concerns information regarding a charging cost which a service provider pays. That is, a "low" cost, a "high" cost, and a "middle" cost are indicated for a setting number "<NUM>", a setting number "<NUM>", and a setting number "<NUM>", respectively. The AF <NUM> selects one from these alternatives, and issues a request of setting the deployment position of the UPF <NUM> to the core network <NUM>, using the setting number.

<FIG> is a diagram that illustrates a fifth example of the information given to the AF <NUM> according to the first embodiment of the present technology.

This fifth example concerns information regarding a throughput. That is, a "low" throughput, a "high" throughput, and a "middle" throughput are indicated for a setting number "<NUM>", a setting number "<NUM>", and a setting number "<NUM>", respectively. The AF <NUM> selects one from these alternatives, and issues a request of setting the deployment position of the UPF <NUM> to the core network <NUM>, using the setting number.

When the distance is short depending on the deployment position of the UPF <NUM>, a retransmission time by ACK/NACK of a transmission control protocol (TCP) is reduced. The latency is therefore reduced, so that the throughput is improved. An application of fixing the deployment position of the UPF <NUM> in accordance with the information of the throughput is therefore assumed.

As described above, in the first embodiment of the present technology, the AF <NUM> fixes the deployment position of the UPF <NUM> on the basis of the information regarding the performance, and issues the request of the setting to the core network <NUM>. With this configuration, the service provider is able to flexibly control the position of the UPF <NUM>. Since the network configuration is settable as the service provider desires, the service for the user's request can be customized in detail. For example, an advantageous effect of readily securing the quality of a communication path to be provided to a user can be expected.

Next, a description will be given of an implementable example corresponding to the first embodiment. More specifically, a description will be given of a case where a service to be provided to the equipment <NUM> in the first embodiment is a cloud game using augmented reality (AR) or virtual reality (VR).

In <NUM> New Radio (NR), some services have been studied as use cases. Among them, AR/VR services have been expected as killer contents of the <NUM> NR. For a cloud game using AR/VR, requirements about rendering of a game image are specified in "3GPP TR <NUM> v17. <NUM>" and "TS <NUM> v17. More specifically, these technical report and technical specification specify a "motion-to-photon" latency and a "motion-to-sound" latency as an allowable latency at a level giving no sense of discomfort to an AR/VR user, in rendering of a game image.

The "motion-to-photon" latency is defined as a latency between a physical motion of a user's head and an updated image in an AR/VR headset (e.g., a head mount display (HMD)). The foregoing technical report specifies that the "motion-to-photon" latency falls within a range from <NUM> to <NUM> while maintaining a required data rate (<NUM> Gbps). The "motion-to-sound" latency is defined as a latency between a physical motion of a user's head and an updated sound wave from a head mount speaker to user's ears. The foregoing technical report specifies that the "motion-to-sound" latency is less than <NUM>. Here, the AR/VR headset or the head mount speaker may be the equipment <NUM> according to the first embodiment.

In order to satisfy the conditions about these latencies, the foregoing technical report and technical specification specify that the following two requirements are satisfied for rendering, as a <NUM> system. First, it is specified as the first requirement that a "Max Allowed End-to-end latency" (maximum allowable latency) is <NUM>. This means that, for example, a total allowable latency at the uplink and downlink between equipment (e.g., the equipment <NUM>) and an interface to a data network (e.g., the network where the AF <NUM> is deployed) is <NUM>. Furthermore, it is specified as the second requirement that a "Service bit rate: user-experienced data rate" is <NUM> Gbps (<NUM> Mbps). This is a throughput capable of supporting an AR/VR content.

Note that the rendering in this implementable example includes cloud rendering, edge rendering, or split rendering. In the cloud rendering, AR/VR data is subjected to rendering on a cloud of a network. Here, the cloud refers to a network including a certain entity or a plurality of entities, based on a core network (including a UPF) deployment and a data network (including an application server and an AF) deployment in which a user's position is not taken into consideration. In the edge rendering, AR/VR data is subjected to rendering on an edge of a network. Here, the edge refers to a network including a certain entity or a plurality of entities, based on a core network (including a UPF) deployment and a data network (including an application server and an AF) deployment near a user's position. For example, an edge computing server that is an application server in a data network in a network deployment for edge computing corresponds to the edge. Furthermore, the split rendering means rendering a part of which is performed on a cloud, and the remaining part of which is performed on an edge.

<FIG> is a diagram that illustrates a configuration example of a cloud rendering system as an implementable example according to the first embodiment of the present technology. Here, images of a cloud render server <NUM> and an AR/VR client <NUM> about rendering, which are described in the foregoing technical report, are assumed.

The cloud render server <NUM> subjects a RAW video to rendering in accordance with a request from the AR/VR client <NUM>. This cloud render server <NUM> communicates with the AR/VR client <NUM> by a real-time transport protocol (RTP) <NUM> via a Web socket <NUM>. The RAW video received from the AR/VR client <NUM> is once held in a RAW video memory <NUM>, and is processed by a graphics processing unit (GPU) <NUM>. The GPU <NUM> subjects the RAW video to rendering through respective procedures of an AR/VR capture <NUM>, an application stage <NUM>, a geometry stage <NUM>, and a rasterizer stage <NUM>. The video (or the image) <NUM> subjected to rendering by the GPU <NUM> is supplied to the AR/VR client <NUM> again by the RTP <NUM>.

The AR/VR client <NUM> communicates with the cloud render server <NUM> by the RTP <NUM>. The video supplied from the cloud render server <NUM> is decoded by a video decoder <NUM>, and is displayed on a video display <NUM>. Furthermore, audio is decoded by an audio decoder <NUM>, and is output from an audio display <NUM>.

Here, the AR/VR client <NUM> may correspond to the equipment <NUM> according to the foregoing first embodiment. Furthermore, the cloud render server <NUM> may be the AF <NUM> according to the foregoing first embodiment, or may be an application server for edge computing (e.g., an edge computing server) that operates in cooperation with the AF <NUM>. Furthermore, the cloud render server <NUM> may be called an edge render server or a split render server.

In the foregoing first embodiment, a latency time between the UPF and another node (e.g., the AF <NUM>) and a throughput are taken into consideration in fixing the UPF deployment. In this implementable example, a determination as to whether or not the foregoing two requirements "Max Allowed End-to-end latency" and "Service bit rate: user-experienced data rate" are satisfied is additionally used for fixing the UPF deployment as will be described below.

<FIG> is a sequence diagram that illustrates one example of a processing procedure as an implementable example according to the first embodiment of the present technology. In this example, both the information regarding the latency time between the base station apparatus <NUM> and the UPF <NUM> and the information regarding the latency time between the AF <NUM> and the UPF <NUM> are compared with the foregoing "Max Allowed End-to-end latency" of <NUM>, and a UPF in which a latency between the UPF <NUM> and another node falls below the allowable latency is deployed as the UPF <NUM> for the equipment <NUM>.

First, the AF <NUM> fixes a service to be supplied to the equipment <NUM> as an AR/VR service (<NUM>). Before and after that, the core network <NUM> measures information regarding an assumed latency time between the UPF <NUM> and the base station apparatus <NUM> (<NUM>).

The AF <NUM> compares both the information regarding the latency time between the base station apparatus <NUM> and the UPF <NUM> and the information regarding the latency time between the AF <NUM> and the UPF <NUM> with the foregoing "Max Allowed End-to-end latency" of <NUM> (<NUM>). The AF <NUM> thus fixes the UPF in which the latency between the UPF <NUM> and the other node falls below the allowable latency as a deployment position of the UPF <NUM> for the equipment <NUM> (<NUM>), and issues a request of setting the deployment position of the UPF <NUM> to the core network <NUM> (<NUM>).

Note that in this example, the latency time between the UPF <NUM> and the other node is compared with "Max Allowed End-to-end latency"; however, the present technology is not limited thereto. An assumed throughput in the case of using the UPF <NUM> is compared with the foregoing "Service bit rate: user-experienced data rate", and the assumed throughput may fix the UPF that satisfies this as the deployment position of the UPF <NUM> for the equipment <NUM>.

In the foregoing first embodiment, the deployment position of the UPF <NUM> in the core network <NUM> is controlled. In this second embodiment, on the other hand, a deployment position is controlled for each part of a network slice.

<FIG> is a diagram that illustrates an example of a network slice according to a second embodiment of the present technology.

The core network <NUM> includes a plurality of network slices for efficiently accommodating communication forms of various use cases. For example, it can be assumed that the network slice #<NUM> (<NUM>) is used for a low latency network, the network slice #<NUM> (<NUM>) is used for MTC that facilitates communication with a network function, and the network slice #<NUM> (<NUM>) is used for facilitation of device-to-device communication.

A multi-protocol label switch (MPLS) which has been used for achieving a virtual private network (VPN) is used with regard to the independence of each network slice of the core network <NUM>. In a normal case, each switch performs routing while referring to an IP header of a destination. The MPLS applies a label, and an MPLS-compatible switch performs routing on the basis of the label. With this configuration, it is possible to explicitly designate a path passing a network for each VPN. Likewise, in achieving network slicing, it is possible to virtually deploy a plurality of networks by applying labels passing different paths for each network slice. Since networks that are not physically separated from each other are used, it is possible to isolate the network slices from each other by the control that ensures a bandwidth between VPNs for each network slice.

<FIG> is a diagram that illustrates a functional configuration example of a communication system according to the second embodiment of the present technology. In this second embodiment, two network slices are assumed, and a common control function <NUM> for both the network slices is also assumed.

The common control function <NUM> is a functional group common to two network slices (#<NUM> and #<NUM>). An NSSF <NUM>, an NRF <NUM>, and an AMF <NUM> included in this common control function <NUM> are similar to those of the control plane <NUM> according to the foregoing first embodiment. Hereinafter, this common control function <NUM> is referred to as a "part A".

The network slice #<NUM> is divided into a control plane <NUM> and a user plane <NUM>. An NEF <NUM>, a PCF <NUM>, a UDM <NUM>, an AF <NUM>, an AUSF <NUM>, and an SMF <NUM> included in the control plane <NUM> are similar to those of the control plane <NUM> according to the foregoing first embodiment. A UPF <NUM> and a DN <NUM> included in the user plane <NUM> are similar to those of the user plane <NUM> according to the foregoing first embodiment.

Hereinafter, the control plane <NUM> or <NUM> is referred to as a part B". Furthermore, the user plane <NUM> or <NUM> is referred to as a part C".

Since one service provider has a plurality of network slices exclusively for its service, the core network <NUM> is requested as to which one of the parts A, B, and C of each network slice is deployed nearby. Network slices that are different in nature from one another can be achieved depending on which one of the parts of each network slice is deployed nearby. Furthermore, since this designation designates a network slice identifier as will be described later, edge computing having a different characteristic can be achieved for each network slice.

<FIG> is a diagram that illustrates a first example of a deployment request from an AF <NUM> according to the second embodiment of the present technology.

In this first example, a designation is made as to whether or not each of the parts A, B, and C is deployed. Furthermore, with regard to the parts B and C, a designation with a network slice identifier is made as to which network slice relates to the designation.

In response to a deployment request from the AF <NUM>, the ECMF <NUM> in the core network <NUM> mainly deploys the respective parts of each network slice in a manner similar to that described in the foregoing first embodiment. Before the AF <NUM> sends the deployment request to the ECMF <NUM> of the core network <NUM>, the AF <NUM> needs to know each of how many network slices is possibly created and an identifier of each network slice.

<FIG> is a diagram that illustrates a second example of the deployment request from the AF <NUM> according to the second embodiment of the present technology.

In this second example, with regard to a plurality of network slices, a designation is made as to whether or not the respective parts are deployed while the respective network slice identifiers are designated. That is, a deployment request is issued in a state in which the number of network slices which the AF <NUM> needs is set at "<NUM>", and identifiers "#<NUM>", "#<NUM>",. are allocated to the respective network slices.

<FIG> is a diagram that illustrates a third example of the deployment request from the AF <NUM> according to the second embodiment of the present technology.

In this third example, a designation of a resistance to congestion is made as to each of the parts A, B, and C. Furthermore, with regard to the parts B and C, a designation with a network slice identifier is made as to which network slice relates to the designation.

A resistance to congestion is particularly problematic for the network slices. The independence of each network slice depends on how to achieve the network slices. The level differs depending on whether the network slices are separated by another server or separated by a virtual machine in one server. That is, congestion is less likely to occur when a server itself is disposed separately from a server at which another congestion occurs, so as not to be affected by the other congestion. The AF <NUM> intends to control the degree of a resistance to congestion as to the core network <NUM>. It is therefore important to notify and request, from the AF <NUM>, the core network <NUM> of the resistance level to congestion for each network slice and for each part of the network slice.

<FIG> is a sequence diagram that illustrates an example of a processing procedure according to the second embodiment of the present technology.

The AF <NUM> designates the deployment of a function of each of the parts A, B, and C in accordance with the example of the foregoing deployment request (<NUM>), and issues a request to the core network <NUM> (<NUM>).

The core network <NUM> gives a response to the deployment request from the AF <NUM> as to whether or not the deployment is possible (<NUM>). Then, if possible, the core network <NUM> performs the function deployment at the designated part (<NUM>), and notifies the AF <NUM> of the completion of the deployment, after the completion of the deployment (<NUM>).

Note that the deployment position may be fixed on the basis of the information regarding the performance for each part of the network slice in a manner similar to that described in the foregoing first embodiment.

As described above, according to the second embodiment of the present technology, it is possible to control the characteristics of the partial function in the network slice in detail by a combination of the network slice with the edge computing.

Note that the foregoing embodiments exemplify one example for embodying the present technology, and the matters in the embodiment and the matters specifying the invention in the claims have a correspondence relationship. Likewise, the matters specifying the invention in the claims and the matters in the embodiments of the present technology, the matters having the identical names to those of the matters specifying the invention, have a correspondence relationship. However, the present technology is not limited to the embodiment, and can be embodied in such a manner that various modifications are made to the embodiments within a range not departing from the scope of the present technology.

Claim 1:
A network deployment control apparatus in edge computing comprising:
an acquisition unit (<NUM>) configured to acquire information regarding performance corresponding to a supposed deployment position of a predetermined function of a network, wherein the function comprises a user plane function of performing user data exchange processing, or a predetermined plane in a predetermined network slice, wherein the information regarding the performance contains at least one of a latency, a cost, a resistance to congestion, or an assumed throughput;
a fixing unit (<NUM>) configured to fix the supposed deployment position as a fixed deployment position of the function on a basis of the information regarding the performance; and
a setting request unit (<NUM>) configured to issue a request of setting the function for the fixed deployment position, to the network,
wherein the fixing unit (<NUM>) is further configured to fix the deployment position of the function from among a plurality of alternatives given in advance.