Patent Description:
To satisfy a wireless data traffic demand which is growing after a 4th generation (<NUM>) communication system is commercialized, efforts are exerted to develop an advanced 5th generation (<NUM>) communication system or a pre-<NUM> communication system. For this reason, the <NUM> communication system or the pre-<NUM> communication system is referred to as a beyond <NUM> network communication system or a post long term evolution (LTE) system.

To achieve a high data rate, the <NUM> communication system considers its realization in an extremely high frequency (mmWave) band (e.g., <NUM> or <NUM> band). To mitigate a path loss of propagation and to extend a propagation distance in the extremely high frequency band, the <NUM> communication system is discussing beamforming, massive multiple input multiple output (MIMO), full dimensional (FD)-MIMO, array antenna, analog beam-forming, and large scale antenna techniques.

Also, for network enhancement of the system, the <NUM> communication system is developing techniques such as evolved small cell, advanced small cell, cloud radio access network (RAN), ultra-dense network, device to device (D2D) communication, wireless backhaul, moving network, cooperative communication, coordinated multi-points (CoMP), and receive interference cancellation.

Besides, the <NUM> system is working on hybrid frequency shift keying and quadrature amplitude modulation (FQAM) and sliding window superposition coding (SWSC) as advanced coding modulation (ACM) schemes, and filter bank multi carrier (FBMC), non orthogonal multiple access (NOMA), and sparse code multiple access (SCMA) as advanced access technologies.

Network function virtualization (NFV) technology may be one solution for smoothly processing the data traffic rapidly growing. The NFV indicates the technology which virtualizes network equipment for performing a network function, and allows a general purpose server device to perform the network function using some of hardware resources abstracted and/or shared. In an NFV environment, since efficiency improvement of the network equipment and a quick respond to a service and/or a service change are required, management on a network malfunction is critical, and proper network resource management related to the malfunction may be required. <CIT> discloses an interface generating system, a drilling service layer device, and a data sending method. <CIT> relates to the field of autonomic computing and virtual network.

Based on the discussion as described above, the present disclosure provides an apparatus and a method for network resource management in a network function virtualization (NFV) environment.

Also, the present disclosure provides an apparatus and a method for associating physical layer information and virtual layer information in an NFV environment.

In addition, the present disclosure provides an apparatus and a method for providing alarms for virtual layer information related to a malfunction if a network malfunction occurs, and physical layer information corresponding to the virtual layer information.

An apparatus and a method according to various embodiments of the present disclosure, may provide alarms relating to virtual layer information related to a malfunction if a network malfunction occurs in a network function virtualization (NFV) environment, and physical layer information corresponding to the virtual layer information, and thus allow a user to easily identify a virtual layer element and/or a physical layer element causing the malfunction, and to quickly resolve the malfunction.

Effects obtainable from the present disclosure are not limited to the above-mentioned effects, and other effects which are not mentioned may be clearly understood by those skilled in the art of the present disclosure through the following descriptions.

Terms used in the present disclosure are used for describing particular embodiments, and are not intended to limit the scope of other embodiments. A singular form may include a plurality of forms unless it is explicitly differently represented. All the terms used herein, including technical and scientific terms, may have the same meanings as terms generally understood by those skilled in the art to which the present disclosure pertains. Among terms used in the present disclosure, the terms defined in a general dictionary may be interpreted to have the same or similar meanings with the context of the relevant art, and, unless explicitly defined in this disclosure, it shall not be interpreted ideally or excessively as formal meanings. In some cases, even terms defined in this disclosure should not be interpreted to exclude the embodiments of the present disclosure.

In various embodiments of the present disclosure to be described below, a hardware approach will be described as an example. However, since the various embodiments of the present disclosure include a technology using both hardware and software, the various embodiments of the present disclosure do not exclude a software-based approach.

Hereafter, the present disclosure relates to an apparatus and a method for network resource management in a network function virtualization (NFV) environment. Specifically, the present disclosure describes a technique for associating physical layer information and virtual layer information in the NFV environment, and providing alarms of virtual layer information related to a malfunction if a network malfunction occurs and physical layer information corresponding to the virtual layer information.

Hereinafter, definitions of terms used in the present disclosure are as follows.

'NFV' means virtualizing network equipment which perform a network function.

'virtualization' means abstracting hardware resources (e.g., computing resources, memory resources, network resources). By the virtualization, the hardware resources of the network equipment (e.g., general purpose server devices) are abstracted and/or shared, and some of the total hardware resources are used to perform a specific network function. For example, a plurality of network functions may be performed in one network equipment according to the virtualization.

'NFV environment' means an environment, a network and/or a system in which the network function is conducted at the virtualized network equipment.

'virtualized network function (VNF)' means the network function performed in the NFV environment.

'virtual machine (VM)' means a virtual logical entity which performs a unit VNF.

`physical layer' means the hardware resources, physical nodes using the hardware resources and/or a structure of the physical nodes.

`virtual layer' means the virtualized resources, virtual nodes using the virtualized resources and/or a function performed using the virtualized resources.

'virtual compute node' means a virtual logical entity for creating/deleting, changing, controlling or managing the VM. One virtual compute node may operate in one server device, and may correspond to one server device.

Terms indicating network entities, and terms indicating components of an apparatus, which are used in the following descriptions, are for the sake of explanations. Accordingly, the present disclosure is not limited to the terms to be described, and may use other terms having technically identical meaning.

<FIG> illustrates an NFV environment <NUM> according to various embodiments of the present disclosure.

Referring to <FIG>, the NFV environment <NUM> may include an operation support system (OSS)/business support system (BSS) <NUM>, a VNF <NUM>, an NFV infrastructure (NFVI) <NUM>, an NFV orchestrator (NFVO) device <NUM>, VNF manager (VNFM) device(s) <NUM>, virtual infrastructure manager (VIM) device(s) <NUM>, a physical infrastructure manager (PIM) device 144f and description <NUM>.

The OSSBSS <NUM> may manage communications equipment and the NFV environment <NUM>. For example, the OSSBSS <NUM> may support network management of an operator and provision and maintenance of a customer service, or may support billing for customers, customer relationship management, and call center business automation.

The VNF <NUM> may include VNF instances <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM>, and may further include element management systems (EMSs) <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> corresponding to them respectively. In some embodiments, the VNF may be a function of virtualized core network equipment. For example, the VFN may be a function of a virtualized mobility management entity (MEE), or a function of a virtualized service gateway (S-GW).

The NFVI <NUM> may include hardware resources <NUM> (e.g., computing hardware <NUM>, storage hardware <NUM>, and network hardware <NUM>), a virtual layer <NUM>, and virtualized resources <NUM> (e.g., virtual computing <NUM>, virtual storage <NUM>, and a virtual network <NUM>). In <FIG>, the virtual layer <NUM> and the virtualized resources <NUM> are separated, but the virtual layer <NUM> may include the virtualized resources <NUM>.

The NFVO device <NUM> may control and/or manage the NFV environment <NUM>. For example, the NFVO device <NUM> may manage the VNF <NUM> by controlling the VNFM device <NUM>, the virtual layer <NUM> and/ LEH may manage the virtualized resources <NUM> by controlling the VIM device <NUM>, and the NFV device <NUM> may manage the hardware resources <NUM> by controlling the PIM device <NUM>. For doing so, the NFVO device <NUM> may communicate with the VNFM device <NUM>, the VIM device <NUM> and the PIM device <NUM>, and exchange data. In addition, the NFVO device <NUM> may include a user interface (UI) for providing the received data to the user. According to various embodiments of the present disclosure, the `NFVO device' may be referred to as an 'NFV environment control device', a `control device', or an 'NFVO'.

The VNFM device <NUM> may manage the VNF <NUM> deployed in the NFV environment <NUM>, and communicate with the VIM device <NUM> to generate virtualized resources for the VNF <NUM>. For example, the VNFM device <NUM> may create and/or delete a VNF, or change, control or manage the VNF. The VNFM device <NUM> may transmit information relating to the VNF <NUM> to the NFVO device <NUM>. According to various embodiments of the present disclosure, the 'VNFM device' may be simply referred to as a 'VNFM'.

The VIM device <NUM> may manage the virtual layer <NUM> and/or the virtualized resources <NUM>. The VIM device <NUM> may receive from the NFVO device <NUM> and/or the VNFM device <NUM> a request for allocating the virtual resources for the VNF <NUM> and/or the virtual layer <NUM>. The VIM device <NUM> may provide the NFVO device <NUM> and/or the PIM device <NUM> with information relating to the virtual layer <NUM> and/or the virtualized resources <NUM>. The `VIM device' may be referred to simply as a 'VIM'.

The PIM device <NUM> may manage the physical layer and/or the hardware resources <NUM>. The PIM device <NUM> may provide the NFVO device <NUM> with information of the physical layer and/or the hardware resources <NUM>. According to various embodiments of the present disclosure, the PIM device <NUM> may receive information of the virtual layer <NUM> and/or the virtualized resources from the VIM device <NUM>. The `PIM device' may be referred to simply as a 'PIM'.

The description <NUM> may provide service information, VNF information, and infrastructure information to at least one of the NFVO device <NUM>, the VNFM device <NUM>, the VIM device <NUM> and the PIM device <NUM>.

The NFVO environment <NUM> may include a plurality of VNFM devices including the VNFM device <NUM>, a plurality of VIM devices including the VIM device <NUM>, and a plurality of PIM devices including the PIM device <NUM>. Each of the plurality of the VNFM devices may perform the same function as the VNFM device <NUM>, each of the plurality of the VIM devices may perform the same function as the VIM device <NUM>, and each of the plurality of the PIM devices may perform the same function as the PIM device <NUM>. The NFVO device <NUM> may manage a plurality of data centers (DCs), and each data center may include one PIM device, one or more VIM devices, and one or more VNFM devices. The NFVO device <NUM> may include VNFM devices, VIM devices and/or PIM devices included in the plurality of the DCs. In the following <FIG>, a hierarchical structure of the nodes (e.g., VNFM device(s), VIM device(s), PIM device(s)) managed by the NFVO device <NUM> is described.

<FIG> illustrates a hierarchical diagram <NUM> of nodes managed by a control device in an NFV environment according to various embodiments of the present disclosure. The hierarchical diagram <NUM> may be displayed at the NFVO device <NUM>. Referring to <FIG>, the NFVO <NUM> may manage a PIM group <NUM>, a VIM group <NUM> and a VNFM group <NUM>.

The PIM group <NUM> may include a plurality of PIM devices PIM201, PIM39, PIM86, PIM_MNM and PIM_SIZING. Since one PIM device and one DC correspond to each other, each PIM may represent a physical infrastructure of the DC corresponding to each PIM. For example, the DC corresponding to the PIM <NUM> may include a floor f1, the floor f1 may include a room room1, the room room1 may include a rack rack1, the rack rack1 may include a shelf shelf0, and the shelf0 may include a plurality of slots slot0, slot1, slot21, and slot <NUM>. Herein, the rack indicates a set of server devices, switches and/or storages, the shelf indicates one of rack's partitions (e.g., horizontal partitions), and the slot indicates one of the shelf's partitions (e.g., vertical partitions). A server device, a switch or a storage may be disposed in one slot. For example, a server device nova1 may be disposed in slot0, a server device nova2 may be disposed in slot2, a switch switch21 may be disposed in slot21, and a storage storage1 may be disposed in slot <NUM>. Herein, the expressions such as 'nova1' and 'nova2' may be an identifier of the server device, or a host name.

According to various embodiments of the present disclosure, the floor, the room, the rack, the shelf and/or the slot may indicate a location of a device. For example, the location of the server device nova1 may be expressed as f1-room1-rack1-shelf0-slot0 of PIM201, and the location of the server device nova2 may be expressed as f1-room1-rack1-shelf0-slot2 of PIM201. In other words, the location of the physical device may be expressed with at least one or a combination of the identifier, the floor, the room, the rack, the shelf and the slot of the PIM.

The VIM group <NUM> may include a VIM device VIM242. The VIM242 may include a plurality of virtual compute nodes nova1, nova2, nova3 and nova4. Herein, the expression such as 'nova1', 'nova2', 'nova3' or 'nova4' may be an identifier of the virtual compute node, or a host name. At least one VM may operate at each of the plurality of the virtual compute nodes. For example, in the virtual compute node nova1, a plurality of VMs VNF_YJ_TEST_NS_VECA0, VNF_YJ_TEST_NS_VIVA0, VNF_YJ_TEST_NS_VOMA0, VNF_YJ_TEST_NS_VOMA1, testtree_VOMA1 and treetest_VOMA1 may operate.

The VNFM group <NUM> may include a plurality of VNFM devices VNFM_ETSI and VNFM_local. For example, VNFM_ETSI may control and/or manage a VNF EDIT_ETSI_VNF. EDIT_ESTI_VNF may include a plurality of VNF components (VNFCs) EDIT_ETSI_VNF_VECA0, EDIT_ETSI-VNF_VIVA0, EDIT_ETSI_VNF_VOMA0 and EDIT_ETSI_VNF_VOMA1.

In <FIG>, the number and/or the name of the nodes depicted in the hierarchical diagram <NUM> are exemplary, and various modifications are possible. For example, the VIM group <NUM> may include a plurality of VIM devices including VIM 242fmf.

<FIG> illustrates a configuration of a control device in an NFV environment according to various embodiments of the present disclosure. The configuration illustrated in <FIG> may be understood as the configuration of the NFVO device <NUM>. A term such as 'portion' or '~ er' used hereafter indicates a unit for processing at least one function or operation, and may be implemented using hardware, software, or a combination of hardware and software.

Referring to <FIG>, the control device may include a communication unit <NUM>, a storage unit <NUM>, a control unit <NUM>, a display <NUM> and an input device <NUM>.

The communication unit <NUM> provides an interface for communicating with other nodes in the network. That is, the communication unit <NUM> converts a bit string transmitted from the server to other node, for example, a base station, a core network, an authentication server and so on, to a physical signal, and converts a physical signal received from other node to a bit string. That is, the communication unit <NUM> may transmit and receive a signal. Accordingly, the communication unit <NUM> may be referred to as a modem, a transmitter, a receiver, or a transceiver. In this case, the communication unit <NUM> enables the control device to communicate with other devices or systems via a backhaul connection (e.g., a wired backhaul or a wireless backhaul) or over the network.

The storage unit <NUM> stores a basic program for operating the server, an application program, and data such as setting information. In particular, the storage unit <NUM> may store information indicating a correspondence between the server device and the virtual compute node. For example, the correspondence between the server device and the virtual compute node may be represented by a mapping table, and the storage unit <NUM> may store the mapping table. The storage unit <NUM> provides the stored data according to a request of the control unit <NUM>.

The control unit <NUM> controls the overall operations of the control device. For example, the control unit <NUM> transmits and receives a signal through the communication unit <NUM>. In addition, the control unit <NUM> records and reads data in and from the storage <NUM>. For doing so, the control unit <NUM> may include at least one processor.

According to various embodiments, the control unit <NUM> may determine a virtual compute node corresponding to the server device, identify physical layer information related to the server device and virtual layer information related to the virtual compute node, and control the display <NUM> to display the physical layer information and the virtual layer information. For example, the control unit <NUM> may control the server to perform operations according to various embodiments to be described below.

The display <NUM> may display a screen including an image, graphics, text, and the like. For example, the display <NUM> may be formed of a liquid crystal, a light emitting diode display, or other material. The display <NUM> may display a screen corresponding to the data received through the control unit <NUM>. In addition, the display <NUM> may include a touch screen for detecting a user input.

The input device <NUM> may receive an input from the user. For doing so, the input device <NUM> may include an input interface. The input received through the input device <NUM> may be processed at the control unit <NUM>, and then transmitted to the display <NUM>, the storage unit <NUM> and the communication unit <NUM>. Thus, information corresponding to the input received through the input device <NUM> may be displayed on the display <NUM>, transmitted to other device through the communication unit <NUM>, or stored in the storage unit <NUM>.

<FIG> illustrates a configuration of a PIM device in an NFV environment according to various embodiments of the present disclosure. The configuration illustrated in <FIG> may be understood as the configuration of the PIM device <NUM>. A term such as 'portion' or '~ er' used hereafter indicates a unit for processing at least one function or operation, and may be implemented using hardware, software, or a combination of hardware and software.

Referring to <FIG>, the PIM device may include a communication unit <NUM>, a storage unit <NUM>, and a control unit <NUM>.

The communication unit <NUM> provides an interface for communicating with other nodes in the network. That is, the communication unit <NUM> converts a bit string transmitted from a server to other node, for example, a base station, a core network, an authentication server and so on, to a physical signal, and converts a physical signal received from other node to a bit string. That is, the communication unit <NUM> may transmit and receive a signal. Accordingly, the communication unit <NUM> may be referred to as a modem, a transmitter, a receiver, or a transceiver. In this case, the communication unit <NUM> may enable the control device to communicate with other devices or systems via a backhaul connection (e.g., a wired backhaul or a wireless backhaul) or over the network.

The storage unit <NUM> stores a basic program for operating the server, an application program, and data such as setting information. In particular, the storage unit <NUM> may store an identification key of each of server devices managed by the PIM device. The storage unit <NUM> provides the stored data according to a request of the control unit <NUM>.

According to various embodiments, the control unit <NUM> may control the communication unit <NUM> to receive identification information including an identifier of at least one virtual compute node from the VIM device, determine an identification key for at least one server device corresponding to at least one virtual compute node based on the identification information, and control the communication unit <NUM> to transmit the identification key of the at least one server device to the control device. For example, the control unit <NUM> may control the server to perform operations according to various embodiments to be described.

<FIG> and <FIG> illustrate connections between nodes displayed at a control device and a connection related to a node having a malfunction in an NFV environment according to various embodiments of the present disclosure.

Referring to <FIG> and <FIG>, the control device (e.g., the NFVO device <NUM>) may display nodes in the NFV environment and connection relationships between the nodes through a UI <NUM>. For example, the NFVO device <NUM> may display the NFVO device <NUM>, the VNFM device <NUM>, the VIM device <NUM> and the PIM device <NUM> which are the nodes in the NFV environment, and display the connection relationships between the nodes. The connection relationship between the nodes in <FIG> is expressed with a line, indicating that the corresponding nodes may exchange data. In addition, the NFVO device <NUM> may display an object managed and/or controlled by each of the nodes. For example, the NFVO device <NUM> may display the VNF <NUM> controlled and/or managed by the VNFM device <NUM>, the virtual resources <NUM> controlled and/or managed by the VIM device <NUM>, and the hardware resources <NUM> controlled and/or managed by the PIM device <NUM>. Herein, the VNF <NUM> and the virtual resources <NUM> belong to the virtual layer, and the hardware resources <NUM> belong to the physical layer. In the UI <NUM>, the correspondence between the management entity and the management object is indicated by a connecting line.

According to various embodiments of the present disclosure, the NFVO device <NUM> may display information indicating a malfunction occurred in the NFV environment. The NFVO device <NUM> may detect the malfunction, and display information indicating a node related to the malfunction. For example, if detecting a malfunction related to the VIM device <NUM> (e.g., communication disruption between the NFVO device <NUM> and the VIM device <NUM>) as shown in <FIG>, the NFVO device <NUM> may indicate the malfunction related to the VIM device <NUM>, by displaying a line connecting the NFVO device <NUM> and the VIM differently from other lines.

Malfunction types which may occur in the NFV environment and classification of nodes related to the malfunction are shown in the following Table <NUM>.

In Table <NUM>, the types of the malfunctions related to each node are exemplary, and the malfunction of a different type may occur to each node.

For example, if a malfunction occurs, the VNFM device <NUM>, the VIM device <NUM> and/or the PIM device <NUM> may provide an alarm of the malfunction to the NFVO device <NUM>, so that the NFVO device <NUM> may display information indicating the node related to the malfunction. As another example, the NFVO device <NUM> may monitor whether a malfunction related to each node occurs, and display information indicating the node related to the malfunction if the malfunction occurs. In this case, the NFVO device <NUM> may detect the malfunction for each node without receiving an alarm of the malfunction failure from the VNFM device <NUM>, the VIM device <NUM> and/or the PIM device <NUM>, and display information related to the malfunction.

Although not depicted, the NFVO device <NUM> may display information indicating the type of the malfunction, in addition to the information indicating the node related to the malfunction through the UI <NUM>. For example, if a malfunction `VM status error' related to the VIM device <NUM> occurs, the NFVO device <NUM> may display a message `VM status error' through the UI <NUM>.

<FIG> illustrates a malfunction and mapping between nodes in an NFV environment according to various embodiments of the present disclosure.

By receiving an alarm of a malfunction, or by monitoring a malfunction, the NFVO device <NUM> may detect the malfunction related to each of nodes (e.g., the VNFM devices <NUM>, the VIM <NUM> and the PIM <NUM>). Hence, the NFVO device <NUM> may map the detected malfunction, to a node related to the malfunction.

Further, the NFVO device <NUM> may identify a detailed element of each node causing the detected malfunction. For example, if the NFVO device <NUM> detects a malfunction related to the VNFM device <NUM>, the NFVO device <NUM> may identify the VNF <NUM> which causes the malfunction among the detailed elements (including EMS <NUM>, EMS <NUM>, VNF <NUM>, and VNF <NUM>) managed by the VNFM device <NUM>. As another example, if the NFVO device <NUM> detects a malfunction related to the VIM <NUM>, if the NFVO device <NUM> detects a malfunction related to the VIM device <NUM>, the NFVO device <NUM> may identify a VM <NUM> causing the malfunction among the detailed elements (including the VM <NUM>, a VM <NUM>) managed by the VIM <NUM>. As another example, if the NFVO device <NUM> detects a malfunction related to the PIM device <NUM>, the NFVO device <NUM> may identify a server device <NUM> causing the malfunction among the detailed elements (including a switch <NUM> and the server device <NUM>) managed by the PIM device <NUM>. As described above, the NFVO device <NUM> may identify the detailed element of each node causing the malfunction, and map the malfunction to the identified detailed element.

According to various embodiments of the present disclosure, each node related to the malfunction may identify the detailed element causing the malfunction, and provide information of the identified detailed element to the NFVO device <NUM>. For doing so, the NFVO device <NUM> may control each node, so that each node may identify the detailed element causing the malfunction.

If a malfunction occurs in the virtual layer, the NFVO device <NUM> may identify a detailed element of the virtual layer causing the malfunction. The NFVO device <NUM> may solve the malfunction by examining the identified detailed element, or display information indicating the type of the malfunction and the identified detailed element. However, even if the detailed element of the virtual layer is fully examined, the malfunction occurring in the virtual layer may not be resolved. For example, if a physical port (e.g., a physical port of the server device <NUM>) corresponding to the VM <NUM> is down, a malfunction may occur from the VM <NUM>, but the malfunction may not be resolved unless a cause of the physical port down is solved though the VM <NUM> is examined. In other words, the malfunction occurring in the virtual layer may be related to the physical layer, and accordingly even if the NFVO device <NUM> and/or the user examines the virtual layer, the malfunction may not be resolved unless the cause of the physical layer is resolved. By contrast, a malfunction in the physical layer may be related to the virtual layer, and accordingly even if the NFVO device <NUM> and/or the user examines the physical layer, the malfunction may not be resolved unless the cause of the virtual layer is resolved.

Thus, various embodiments of the present disclosure provide an apparatus and a method for associating the physical layer information and the virtual layer information. By associating the physical layer information and the virtual layer information, the NFVO device <NUM> may display the associated physical layer information and virtual layer information together. For example, the NFVO device <NUM> may display virtual layer information related to the VM <NUM>, and physical layer information related to the server device <NUM> corresponding to the VM <NUM>. In addition, if detecting a malfunction, the NFVO device <NUM> may display physical layer information related to the malfunction, together with virtual layer information related to the malfunction. Hence, the NFVO device <NUM> and/or the user may easily identify the physical layer element and the virtual layer element causing the malfunction, and quickly solve the malfunction.

In the following <FIG>, a specific method for displaying the physical layer information and the virtual layer information together shall be described.

<FIG> illustrates a flowchart of a control device in an NFV environment according to various embodiments of the present disclosure. <FIG> illustrates operations of the NFVO device <NUM>.

Referring to <FIG>, in step <NUM>, the control device determines a virtual compute node corresponding to a server device. Associating physical layer information and virtual layer information may start from determining a pair of corresponding virtual compute node and server device among a plurality of virtual compute nodes managed by a VIM device (e.g., the VIM device <NUM>) and a plurality of server devices managed by a PIM device (e.g., the PIM device <NUM>) in the NFV environment. In other words, the control device may determine a virtual compute node corresponding to each of the plurality of the server devices among the plurality of the virtual compute nodes. A specific method of determining the virtual compute node corresponding to the server device shall be described in more detail in <FIG>.

In step <NUM>, the control device identifies physical layer information related to the server device and virtual layer information related to the virtual compute node. The physical layer information may include at least one of a host name of the server device, a location of the server device, and at least one physical port disposed in the server device. The virtual layer information may include at least one of a host name of the virtual compute node, an identifier or a list of VM(s) running on the virtual compute node, an identifier or a list of VNF(s) performed by the VM, and an identifier of the VIM managing the virtual compute node, and information of the VNFM device managing the VNF(s).

In step <NUM>, the control device displays the physical layer information and the virtual layer information. For example, the control device may display the VM running on the virtual compute node as the virtual layer information related to the virtual compute node, and display the physical port of the server device corresponding to the VM as the physical layer information related to the server device. Further, the control device may display the correspondence between the VM and the physical port corresponding to the VM.

<FIG> illustrates a flowchart of a control device for determining a virtual compute node corresponding to a server device in an NFV environment according to various embodiments of the present disclosure. <FIG> illustrates operations of the NFVO device <NUM>.

Referring to <FIG>, in step <NUM>, the control device determines an identification key of a virtual compute node, based on identification information received from the VIM device. The identification key may also be referred to as a host key. The identification information may include at least one of an identifier of the virtual compute node and at least one user identifier of the VIM device. The identifier of the virtual compute node may be referred to as the host name of the virtual compute node. The user identifier of the VIM device may be referred to as a universally unique identifier (UUID) or a tenant identifier. For example, the control device may determine the identification key of the virtual compute node based on the identifier of the virtual compute node. As another example, the control device may determine the identification key of the virtual compute node by combining the identifier of the virtual compute node and at least one user identifier of the VIM device. As another example, the control device may determine the identification key of the virtual compute node by hashing the identifier of the virtual compute node and at least one user identifier of the VIM device. Herein, a hashing function SHA224 may be used for the hashing.

In step <NUM>, the control device receives an identification key of the server device from the PIM device. The identification information of step <NUM> may be transmitted from the VIM device also to the PIM device, and the PIM device may determine the identification key of the server device based on the identification information. A specific method for the PIM device to determine the identification key of the server device shall be described in detail in <FIG>.

In step <NUM>, the control device determines a virtual compute node corresponding to the server device, based on matching of the identification key of the virtual compute node and the identification key of the server device. If the identification key of the virtual compute node and the identification key of the server device match, the control device may determine that the virtual compute node and the server device correspond. If the identification key of the virtual compute node and the identification key of the server device do not match, the control device may determine that the virtual compute node and the server device do not correspond, and determine a corresponding virtual compute node by matching the identification key of the server device to an identification key of other virtual compute node.

<FIG> illustrates a flowchart of a PIM device in an NFV environment according to various embodiments of the present disclosure. <FIG> illustrates operations of the PIM device <NUM>.

Referring to <FIG>, in step <NUM>, the PIM device receives identification information including an identifier of at least one virtual compute node, from the VIM device. The identification information may include a list of virtual compute node(s) or a list of identifier(s) of the virtual compute node(s). The list of the virtual compute node(s) or the list of the identifier(s) of the virtual compute node(s) may be referred to as a hypervisor list or a compute node list. The identification information may further include a list of user identifier(s) of the VIM device. The list of the user identifier(s) of the VIM device may be referred to as a tenant list. To receive the identification information from the VIM device, the PIM device may transmit a message for requesting the identification information to the VIM device.

In step <NUM>, based on the identification information, the PIM device determines an identification key of at least one server device corresponding to the at least one virtual compute node. For doing so, the PIM device may determine a server device corresponding to each of the virtual compute nodes. The PIM device may determine the server device corresponding to the virtual compute node, based on matching of an internet protocol (IP) address of the virtual compute node with an IP address of the server device. In other words, the PIM device may determine that a server device having the same IP address as the IP address of each virtual compute node corresponds to each virtual compute node. As another example, the PIM device may determine a server device corresponding to the virtual compute node, based on matching a host name of the virtual compute node and a host name of the server device. In other words, the PIM device may determine that the server device having the same host name as the host name of each virtual compute node corresponds to each virtual compute node. As another example, to determine the server device corresponding to each virtual compute node, the PIM device may use the IP address and the host name. For example, if the PIM device may not determine the server device corresponding to each virtual compute node by using the IP address alone, the PIM device may complementarily use the host name. In addition, if the PIM device may not determine the server device corresponding to each virtual compute node by using the host name alone, the PIM device may complementarily use the IP address. In addition, the PIM device may determine a server device corresponding to the virtual compute node, based on matching the host name and the IP address of the virtual compute node with the host name and the IP address of the server device. In other words, the PIM device may determine that the server device having the same IP address and host name as the IP address and host name of each virtual compute node corresponds to each virtual compute node. According to an embodiment, the PIM device may determine an identification key for each server device, based on an identifier of the virtual compute node corresponding to each server device. As another example, the PIM device may determine the identification key of each server device, by combining the identifier of the virtual compute node corresponding to each server device and the user identifier of the VIM device. As another example, the PIM device may determine the identification key of each server device, by hashing the identifier of the virtual compute node corresponding to each server device and the user identifier of the VIM device. Herein, the hashing function SHA224 may be used for the hashing.

In step <NUM>, the PIM device transmits the identification key of at least one server device to the control device. The control device may determine the virtual compute corresponding to each server device, based on matching the identification key of the at least one server device received from the PIM device and the identification key of the at least one virtual compute node received from the VIM device.

<FIG> illustrates signal flows between nodes for determining a virtual compute node corresponding to a server device in an NFV environment according to various embodiments of the present disclosure. <FIG> illustrates the signal flows between the NFVO device <NUM>, the VIM device <NUM> and the PIM device <NUM>.

Referring to <FIG>, in step <NUM>, the PIM device <NUM> transmits a message requesting identification information to the VIM device <NUM>. The message requesting the identification information may be transmitted in a procedure for installing the PIM device <NUM>.

In step <NUM>, the VIM device <NUM> transmits the identification information to the PIM device <NUM>, in response to the identification information request. The identification information may include a list (or a hypervisor list) of virtual compute nodes managed by the VIM device <NUM> and/or a list (or a tenant list) of at least one user identifier of the VIM device <NUM>.

In step <NUM>, the PIM device <NUM> determines an identification key of each server device, based on an identifier of a virtual compute node corresponding to each of the server devices managed by the PIM device <NUM>. For doing so, the PIM device <NUM> may determine the virtual compute node corresponding to each server device, by matching the virtual compute nodes with server devices having the same IP address and/or the same host name. According to an embodiment, the number of the server devices may be greater than the number of the virtual compute nodes, and in this case, there may be no corresponding virtual compute nodes for some server device(s) among the server devices managed by the PIM device <NUM>. As another example, the PIM device <NUM> may determine an identification key of each server device, based on an identifier of a virtual compute node corresponding to each of the server devices managed by the PIM device <NUM>, and at least one user identifier of the VIM device <NUM>. In this case, for a plurality of of user identifiers of the VIM device <NUM>, a plurality of identification keys may also be determined for each server device. For example, the number of the user identifiers of the VIM device <NUM> and the number of the identification keys for each server device may be the same. As another example, the PIM device <NUM> may determine the identification key of each server device, by combining or hashing the identifier of the virtual compute node corresponding to each of the server devices managed by the PIM device <NUM> and at least one user identifier of the VIM device <NUM>. Herein, the hashing function SHA224 may be used for the hashing.

In step <NUM>, the PIM device <NUM> transmits the identification keys of the server devices to the NFVO device <NUM>. The identification keys of the server devices may be transmitted in a procedure for registering the PIM device <NUM>.

In step <NUM>, the VIM device <NUM> transmits the identification information to the NFVO device <NUM>. The identification information transmitted in step <NUM> may be the same as the identification information transmitted in step <NUM>. The VIM device <NUM> may transmit the identification information to the NFVO device <NUM> in a procedure for registering the VIM device.

In step <NUM>, the NFVO device <NUM> determines an identification key of each virtual compute node, based on the identifier of each of the virtual compute nodes managed by the VIM device <NUM>. As another example, the NFVO device <NUM> may determine the identification key of each virtual compute node, based on the identifier of each of the virtual compute nodes managed by the VIM device <NUM> and at least one user identifier of the VIM device <NUM>. In this case, for a plurality of of user identifiers of the VIM device <NUM>, a plurality of identification keys may also be determined for each virtual compute node. For example, the number of the user identifiers of the VIM device <NUM> and the number of the identification keys for each virtual compute node may be the same. As another example, the NFVO device <NUM> may determine the identification key for each virtual compute node, by combining or hashing the identifier of each of the virtual compute nodes and at least one user identifier of the VIM device <NUM>. Herein, the hashing function SHA224 may be used for the hashing.

In step <NUM>, the NFVO device <NUM> determines a pair of a virtual compute node and a server device of which the identification keys match. The NFVO device <NUM> may determine the pair of the virtual compute node and the server device of the matching identification keys, among the plurality of the virtual compute nodes managed by the VIM device <NUM> and the plurality of the server devices managed by the PIM device <NUM>. If a plurality of identification keys exists for each virtual compute node and each server device, it may be required to match at least some of the identification keys, or all the identification keys to determine that the server device and the virtual compute node correspond to each other. Based on matching the identification keys, the NFVO device <NUM> may determine the virtual compute node corresponding to each of the server devices managed by the PIM device <NUM>. Alternatively, the NFVO device <NUM> may determine the server device corresponding to each of the virtual compute nodes managed by the VIM device <NUM>, based on matching the identification keys.

Step <NUM> through step <NUM> may be carried out during the procedure for installing the PIM and/or the procedure for registering the PIM. In addition, step <NUM> may be performed during the procedure for registering the VIM. In <FIG>, the PIM installation and/or registration procedure is performed before the VIM registration procedure, which is exemplary, and the PIM installation and/or registration procedure may be performed after the VIM registration procedure.

<FIG> illustrates locations of DCs managed by a control device in an NFV environment according to various embodiments of the present disclosure.

Referring to <FIG>, the NFVO device <NUM> may display location information of DCs <NUM>, <NUM>, and <NUM> managed by the NFVO device <NUM> based on geographic information system (GIS) information through a UI <NUM>. The NFVO device <NUM> may display information of DCs and/or PIM devices (e.g., PIM86, PIM_SIZING, PIM201, PIM39, PIM_SIM, and PIM_MNM) managed by the NFVO device <NUM> in an area <NUM> of the UI <NUM>. The NFVO device <NUM> may receive an input for selecting at least one of the DCs <NUM>, <NUM> and <NUM> through the UI <NUM>. For example, if the DC <NUM> is selected according to the received input, the NFVO device <NUM> may display information of the selected DC <NUM> and/or information of the PIM device (e.g., PIM_SIM) corresponding to the selected DC <NUM> through an area <NUM> of the UI <NUM>. For example, as shown in the drawing, the area <NUM> may display information indicating that the DC <NUM> includes one floor, includes <NUM> racks, and includes <NUM> server devices.

<FIG> illustrates racks included in a DC in an NFV environment according to various embodiments of the present disclosure. In <FIG>, while the rack has the form of a rectangular pillar, which is exemplary, various modifications may be made to the shape of the rack.

Referring to <FIG>, the NFVO device <NUM> may display a plurality of racks including a rack <NUM> through a UI <NUM>. The plurality of the racks displayed through the UI <NUM> may be racks included in a room of one floor in the DC. The arrangement of the racks displayed through the UI <NUM> may correspond to an actual arrangement of the racks in the DC. The NFVO device <NUM> may receive an input for selecting at least one of the plurality of racks displayed through the UI <NUM>. For example, if the rack <NUM> is selected according to the received input, the NFVO device <NUM> may display information of the selected rack <NUM> as shown in <FIG>.

<FIG> illustrates physical layer information and virtual layer information of a rack in an NFV environment according to various embodiments of the present disclosure.

Referring to <FIG>, the NFVO device <NUM> may display physical layer information <NUM> related to the rack <NUM> selected according to an input received through a UI <NUM>, and virtual layer information <NUM> related to the rack <NUM>.

The physical layer information <NUM> may include information related to server devices, switches and/or storages included in the rack <NUM>. For example, the physical layer information <NUM> may include information indicating that the rack <NUM> includes <NUM> servers, does not include a storage and a switch, and includes one chassis.

The virtual layer information <NUM> may include information related to virtual compute nodes corresponding to the server devices included in the rack <NUM>. For example, the virtual layer information <NUM> may include a list of VNFs (e.g., vGW_TEST) performed by virtual compute nodes corresponding to the server devices included in the rack <NUM>, and information relating to a VNFM device (e.g., VNFM_2) managing the VNFs, and a VIM device (e.g., VIM242) managing the compute nodes.

In addition, the NFVO device <NUM> may display basic information of the DC including the rack <NUM> in an area <NUM> of the UI <NUM>. For example, the NFVO device <NUM> may display information indicating that a PIM device corresponding to the DC including the rack <NUM> is PIM_SIM, the DC includes VIM devices VIM242 and VIM_gtest, and the DC includes VNFM devices VNFM1_2, VNFM_LOCAL_3_0, and VNFM_2 in the area <NUM>.

<FIG> illustrates physical layer information and virtual layer information of a server device in an NFV environment according to various embodiments of the present disclosure.

Referring to <FIG>, the NFVO device <NUM> may display a rack including a server device <NUM> in an area <NUM> of a UI <NUM>. In the area <NUM>, a relative position of the server device <NUM> in the rack may be displayed.

The NFVO device <NUM> may display the server device <NUM>, physical ports (e.g., physical ports <NUM>, <NUM>, <NUM>) included in the server device <NUM>, and VMs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> operating at a virtual compute node corresponding to the server device <NUM> through the UI <NUM>. In addition, the NFVO device <NUM> may display through the UI <NUM> physnet1 <NUM> connected to the VMs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM>, phsynet3 <NUM> connected to the VMs <NUM>, <NUM>, <NUM> and <NUM>, and physnet2 not connected to the VM. In the present disclosure, the physnet (e.g., the physnet1 <NUM>, the physnet2 <NUM>, the physnet3 <NUM>) indicates a network layer mapped to a physical port in the virtual layer. For example, at least one physical port may correspond to one physnet, and at least one physnet may correspond to one physical port. As shown in <FIG>, the physnet1 <NUM> may correspond to the physical port <NUM>, the physnet2 <NUM> may correspond to the physical port <NUM>, and the physnet3 <NUM> may correspond to the physical port <NUM>.

According to various embodiments of the present disclosure, the NFVO device <NUM> may display a connection relationship between the VM and the physnet, may display correspondence between the physnet and the physical port, and thus may display correspondence between the VM and the physical port. For example, the NFVO device <NUM> may display that the VMs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> correspond to the physical port <NUM> via the physnet1 <NUM>, and the VMs <NUM>, <NUM>, <NUM> and <NUM> correspond to the physical port <NUM> via the physnet3 <NUM>. Hence, if a malfunction occurs to the VM, the NFVO device <NUM> and/or the user may easily identify the physical port corresponding to the malfunctioned VM, a server device including the physical port, and a switch connected to the physical port, and the malfunction may be resolved quickly. Specific scenarios for responding to the malfunction shall be described in more detail in <FIG> and <FIG>.

The NFVO device <NUM> may display information of the server device <NUM> in an area <NUM> of the UI <NUM>. The information displayed in the area <NUM> may include physical layer information related to the server device <NUM>, and virtual layer information related to a virtual compute node corresponding to the server device <NUM>. For example, the NFVO device <NUM> may display at least one of a location (e.g., rack41-shelf1-slot0) of the server device <NUM>, an identifier or host name (e.g., com. nova1) of the server device <NUM>, the number of CPUs and cores included in the server device <NUM>, sizes of a memory and a disk included in the server device <NUM>, the number of disks included in the server device <NUM>, and status information (e.g., health, performance, resource) of the server device <NUM> as the physical layer information related to the server device <NUM> in the area <NUM>. In addition, the NFVO device <NUM> may display at least one of an identifier or host name (e.g., nova1) of the virtual compute node, a list of VMs operating in the virtual compute node, a list of VNFs conducted by the VMs, a VNFM device managing the VNFs, and a VIM device managing the virtual compute node as virtual layer information related to the virtual compute node corresponding to the server device <NUM> in the area <NUM>.

Although not depicted, if detecting a malfunction, the NFVO device <NUM> may display virtual layer information related to the malfunction, together with physical layer information related to the malfunction. For example, if a malfunction occurs in the VM <NUM>, the NFVO device <NUM> may display information indicating the malfunction occurred in the VM <NUM>, and information indicating the physical port <NUM> and the physical port <NUM> corresponding to the VM <NUM> through the UI <NUM>. Further, the NFVO device <NUM> may display virtual layer information related to the malfunctioned VM <NUM>, and physical layer information (e.g., information of the server device <NUM> including the physical port <NUM> and the physical port <NUM>, information of a switch connected to each of the physical port <NUM> and the physical port <NUM>) related to the physical port <NUM> and the physical port <NUM> corresponding to the VN <NUM>.

<FIG> illustrates detailed information of a VM in an NFV environment according to various embodiments of the present disclosure.

The NFVO device <NUM> may display through the UI <NUM> the server device <NUM>, physical ports (e.g., physical ports <NUM>, <NUM>, <NUM>) included in the server device <NUM>, and VMs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> operating in the virtual compute node corresponding to the server device <NUM>. In addition, the NFVO device <NUM> may display physnet1 <NUM> connected to the VMs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM>, physnet2 <NUM> not connected to the VM, and physnet3 <NUM> connected to the VMs <NUM> and <NUM>. The Physnet1 <NUM> may correspond to the physical port <NUM>, the phsynet2 <NUM> may correspond to the physical port <NUM>, and the physnet3 <NUM> may correspond to the physical port <NUM>.

The NFVO device <NUM> may display a relationship between the VM and the physnet, display correspondence between the physnet and the physical port, and thus display correspondence between the VM and the physical port. For example, the NFVO device <NUM> may display that the VMs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> correspond to the physical port <NUM> via the phsynet1 <NUM>, and the VMs <NUM> and <NUM> corresponds to the port <NUM> via the physnet3 <NUM>.

The NFVO device <NUM> may receive an input for selecting a VM through the UI <NUM>. For example, if the VM <NUM> is selected according to the received input, the NFVO device <NUM> may display information of the VM <NUM> in an area <NUM> of the UI <NUM>. For example, the NFVO device <NUM> may display in the <NUM> at least one of a location (e.g., rack41-shelf0-slot2) of the server device <NUM> including the physical port <NUM> and the physical port <NUM> corresponding to the VM <NUM>, an identifier or host name (e.g., nova4) of the virtual compute node where the VM <NUM> operates, an identifier or host name (e.g., nova401)of the server <NUM>, a VIM device managing the VM <NUM>, a VNFM managing the VNF conducted by the VM <NUM>, at least one IP address assigned to the VM <NUM>, an amount of physical and/or virtual computing resources (e.g., the number of physical and/or virtual cores, the size of the physical and/or virtual memory) allocated to the VM <NUM>, a size and a name of the allocated physical and/or virtual storage allocated to the VM <NUM>, and a location of an external storage if the VM <NUM> uses the external storage.

<FIG> illustrates a list of VNFs on service in an NFV environment according to various embodiments of the present disclosure.

Referring to <FIG>, the NFVO device <NUM> may display information of the VNFs on service through a UI <NUM>. For example, the NFVO device <NUM> may display that the VNFs on service are vMMERest, KTvMME122 and KTvMME123_Flavor, and may display information of the respective VNFs. For example, the NFVO device <NUM> may display at least one of information of a VNFM device (may be referred to as a 'target VNFM') managing each VNF, information of a VIM device (may be referred to as a 'target VIM') managing a VM which conducts the VNF, a tenant having specific authorization on each VNF, a package name of each VNF, a scale option for each VNF, a scale mode for each VNF, flavor information for each VNF, a job status of each VNF, a VNF protocol for each VNF, and a time at which each VNF is created.

<FIG> illustrates a topology of VNFs deployed in an NFV environment according to various embodiments of the present disclosure.

Referring to <FIG>, the NFVO device <NUM> displays a list of VNFs on service, and a hierarchical structure of a VNFM which manages the VNFs in an area <NUM> of a UI <NUM>.

In an area <NUM>, the NFVO device <NUM> displays the topology of the VNFs deployed in the NFV environment. More specifically, the NFVO device <NUM> displays the deployment of the VNFs on service, and connection relationships between the VNFs in the area <NUM>. VNFs connected by a line in an area <NUM> may exchange data or control information with each other.

The NFVO device <NUM> may receive an input for selecting at least one of the VNFs displayed in the area <NUM> through the UI <NUM>. The NFVO device <NUM> may display information of the VNF selected according to the received input in an area <NUM>. For example, the VNFO device <NUM> may display in the area <NUM> at least one of an identifier of the VNFM device managing the selected VNF, a package name of the selected VNF, flavor information of the selected VNF, a scale option and/or a scale mode for the selected VNF, a job status of the selected VNF, status of the selected VNF and whether an auto scale policy is set for the selected VNF.

<FIG> and <FIG> illustrate scenarios for responding to a malfunction in an NFV environment according to various embodiments of the present disclosure. In <FIG>, since a malfunction is detected in a VM <NUM> regardless of a cause of the malfunction, examining for resolving the malfunction starts from examining a virtual layer <NUM>.

Referring to <FIG>, it is assumed that the cause of the malfunction is in the virtual layer <NUM>. The NFVO device <NUM> first detects a malfunction in the VM <NUM>. Next, the NFVO device <NUM> examines the virtual layer <NUM>. If a problem is identified in the service of the virtual layer <NUM>, the NFVO device <NUM> may perform an operation for solving the problem, or may notify through a UI that it is necessary to examine the virtual layer <NUM>.

Referring to <FIG>, it is assumed that the cause of the malfunction is in a server device <NUM>. NFVO device <NUM> first detects the malfunction in the VM <NUM>. Next, the NFVO device <NUM> examines the virtual layer <NUM>. If a problem is not identified in the service of the virtual layer <NUM>, the NFVO device <NUM> may examine whether the malfunction occurs in the server device <NUM> associated with the virtual layer <NUM> and/or a physical port of the server device <NUM>. If the malfunction is identified in the server device <NUM> and/or the physical port of the server device <NUM>, the NFVO device <NUM> may notifying through the UI that it is necessary to examine the server device <NUM>.

Referring to <FIG>, it is assumed that the cause of the malfunction is in a switch <NUM>. The NFVO device <NUM> first detects the malfunction in the VM <NUM>. Next, the NFVO device <NUM> examines the virtual layer <NUM>. If a problem is not identified in the service of the virtual layer <NUM>, the NFVO device <NUM> may examine whether the malfunction occurs in the server device <NUM> associated with the virtual layer <NUM> and/or the physical port of the server device <NUM>. If the malfunction is not identified in the server device <NUM> and/or the physical port of the server device <NUM>, the NFVO device <NUM> may examine whether the malfunction occurs in the switch <NUM> connected to the physical port of the server device <NUM> and/or the port of the switch <NUM>. If the malfunction is identified in the switch <NUM> and/or the port of the switch <NUM>, the NFVO device <NUM> may inform through the UI that it is necessary to examine the switch <NUM> and/or the port of the switch <NUM>.

Referring to <FIG>, it is assumed that the cause of the malfunction is in software operating in the VM <NUM>. The NFVO device <NUM> first detects the malfunction in the VM <NUM>. Next, the NFVO device <NUM> examines the virtual layer <NUM>. If a problem is not identified in the service of the virtual layer <NUM>, the NFVO device <NUM> may examine whether a malfunction occurs in the server device <NUM> associated with the virtual layer <NUM> and/or the physical port of the server device <NUM>. If the problem is not identified in the server device <NUM> and/or the physical port of the server device <NUM>, the NFVO device <NUM> may examine whether a malfunction occurs in the switch <NUM> connected to the physical port of the server device <NUM> and/or the port of the switch <NUM>. If the malfunction is not identified in the switch <NUM> and/or the port of the switch <NUM>, the NFVO device <NUM> may determine no malfunction in the infrastructure and the service, and notify through the UI that it is necessary to examine the software running on the VM.

According to various embodiments of the present disclosure, the association between the physical layer information and the virtual layer information is used to manage the QoS in the NFV environment. Hereinafter, scenarios for managing quality of service (QoS) is described in <FIG> and <FIG>.

<FIG> and <FIG> illustrate scenarios for managing QoS in an NFV environment according to various embodiments of the present disclosure.

Referring to <FIG>, traffic usage of a VM1 <NUM> is 7Gps which is <NUM>% of the maximum available traffic usage, and traffic usage of a VM2 <NUM> is 6Gbps which is <NUM>% of the maximum available traffic usage. The VM1 <NUM> and the VM2 <NUM> may correspond to a physical port <NUM> via a virtual network <NUM> (e.g., physnet). However, if a link speed supported by the physical port <NUM> is 10Gbps, the physical port <NUM> may not support 13Gbps which is the sum of the traffic usage (= 7Gbps) of the VM1 <NUM> and the traffic usage (= 6Gbps) of the VM2 <NUM>, and thus traffic overload may occur between the virtual network <NUM> and the physical port <NUM>. The NFVO device <NUM> may detect this traffic overload, and may instruct the user to change setting of the virtual network <NUM> through a UI. For example, if the setting of the virtual network <NUM> is changed such that the virtual network <NUM> corresponds to other physical port (for supporting the link speed above 3Gbps) in addition to the physical port <NUM>, the physical ports may support the link speed above 13Gbps, and thus the traffic overload occurring between the virtual network <NUM> and the physical port <NUM> may be resolved.

Referring to <FIG>, the traffic usage of the VM1 <NUM> is 7Gps which is <NUM>% of the maximum available traffic usage, and the traffic usage of the VM2 <NUM> is 6Gbps which is <NUM>% of the maximum available traffic usage. The VM1 <NUM> and the VM2 <NUM> may correspond to a physical port <NUM><NUM> and a physical port <NUM><NUM> via the virtual network <NUM> (e.g., physnet). That is, if the physical port <NUM><NUM> and the physical port <NUM><NUM> operate normally, the physical port <NUM><NUM> and the physical port <NUM><NUM> may support the link speed of 20Gbps, and may support 13Gbps which is the sum of the traffic usage(= 7Gbps) of the VM1 <NUM> and the traffic usage (= 6Gbps) of the VM2 <NUM>. However, if a malfunction (e.g., NICPortLinkDown) occurs in the physical port <NUM><NUM> and the physical port <NUM><NUM> is down, the physical port <NUM><NUM> alone may not support 13Gbps which is the sum of the traffic usage(= 7Gbps) of the VM1 <NUM> and the traffic usage (= 6Gbps) of the VM2 <NUM>, and thus a malfunction may occur. The NFVO device <NUM> detects this malfunction, and notifies through the UI that the physical port <NUM><NUM> is down. As another example, if the NFVO device <NUM> detects that the physical port <NUM><NUM> is down, the NFVO device <NUM> controls to stop the operation of one of the VM1 <NUM> and the VM2 <NUM> without notification, and thus control one VM to operate normally and automatically resolve the possibility of the malfunction. As another example, if the NFVO device <NUM> detects that the physical port <NUM><NUM> is down, the NFVO device <NUM> may resolve the possibility of the malfunction by performing a preset operation. For example, if the physical port <NUM><NUM> is down, the NFVO device <NUM> may resolve the possibility of the malfunction by changing the virtual compute node which manages the VM2 <NUM> (in this case, the VM2 <NUM> may correspond to a physical port different from the physical port <NUM><NUM> and the physical port <NUM><NUM>), or may enable the VM2 <NUM> to perform failover (e.g., temporarily reduce the traffic usage) and to resolve the possibility of the malfunction, by notifying the VM2 <NUM> of malfunction and/or possible malfunction failure information (e.g., information indicating that the physical port corresponding to the VM2 <NUM> is down).

The methods according to the embodiments described in the claims or the specification of the disclosure may be implemented in software, hardware, or a combination of hardware and software.

As for the software, a computer-readable storage medium storing one or more programs (software modules) may be provided. One or more programs stored in the computer-readable storage medium may be configured for execution by one or more processors of an electronic device. One or more programs may include instructions for controlling the electronic device to execute the methods according to the embodiments described in the claims or the specification of the disclosure.

Such a program (software module, software) may be stored to a random access memory, a non-volatile memory including a flash memory, a read only memory (ROM), an electrically erasable programmable ROM (EEPROM), a magnetic disc storage device, a compact disc (CD)-ROM, digital versatile discs (DVDs) or other optical storage devices, and a magnetic cassette. Alternatively, it may be stored to a memory combining part or all of those recording media. A plurality of memories may be included.

Also, the program may be stored in an attachable storage device accessible via a communication network such as Internet, Intranet, local area network (LAN), wide LAN (WLAN), or storage area network (SAN), or a communication network by combining these networks. Such a storage device may access a device which executes an embodiment of the present disclosure through an external port. In addition, a separate storage device on the communication network may access the device which executes an embodiment of the present disclosure.

Claim 1:
An operating method of a control device in a network function virtualization, NFV, environment, comprising:
determining (<NUM>) a virtual compute node corresponding to a server device;
identifying (<NUM>) physical layer information related to the server device, and virtual layer information related to the virtual compute node;
displaying (<NUM>) the physical layer information and the virtual layer information; and
examining a malfunction in a virtual layer to detect a malfunction in at least one virtual machine, VM, which operates in the virtual compute node;
wherein association between the physical layer information and the virtual layer information is used to manage quality of service, QoS, in the NFV environment,
wherein the physical layer information comprises information on at least one physical port disposed in the server device, and the at least one physical port includes a first physical port and a second physical port,
in case that a malfunction is not detected in the virtual layer, examining a malfunction in a server device associated with the virtual layer and the first physical port of the server device,
in case that a malfunction is not detected in the server device and the first physical port, examining a malfunction in a switch connected to the first physical port of the server device and a port of the switch,
in case that a malfunction is not detected in the switch and the port of the switch, determining no malfunction is occurred in an infrastructure and a service, and displaying that it is necessary to examine a software running on the at least one VM,
in case that a malfunction is detected in at least one of the virtual layer, the server device, the first physical port, the switch, and the port of the switch, displaying information indicating the malfunction of the at least one VM, information indicating the server device including the first physical port corresponding to the at least one VM, information of the switch connected to the first physical port, and virtual layer information related to the at least one VM,
in case that a malfunction is detected in the first physical port and a sum of traffic usage of the at least one VM exceeds a link speed supported by the second physical port of the server device, notifying through a user interface that the first physical port is down.