Patent Application
20190173681
The present invention relates to the communications field, and in particular, to a charging method and apparatus and a system.
A Network Function Virtualization (NFV) for technology may be simply understood as migration of functions of network elements used in a telecommunications network from a current dedicated hardware platform to a general-purpose commercial off-the-shelf (COTS) server. The network elements used in the telecommunications network are transformed into independent applications by using the NFV technology, so that the functions of the network elements can be flexibly deployed on an all-in-one infrastructure platform constructed based on standard servers, storages, and other devices such as switches. In addition, a virtualization technology is used for resource pooling and virtualization of infrastructure hardware devices, so that virtual resources can be provided to upper-layer applications, thereby decoupling the applications from hardware. In this way, virtual resources can be rapidly added for each application to expand system capacity rapidly or virtual resources can be rapidly reduced to reduce system capacity, thereby greatly improving network flexibility. General-purpose COTS servers are used to form a shared resource pool, so that it is not necessary to deploy hardware devices separately for a newly developed service, thereby greatly shortening a period of time required to launch a new service.
The basis of the NFV technology includes a cloud computing technology and a virtualization technology. General-purpose COTS hardware devices such as computing devices, storage devices, and network devices may be divided into a variety of virtual resources by using the virtualization technology for use by various upper-layer applications. The applications are decoupled from hardware by using the virtualization technology, so that a speed of providing virtual resources is greatly increased. Applications can be flexibly scaled up or down by using the cloud computing technology to enable virtual resources to match service load, so that efficiency of utilizing virtual resources is improved and a response speed of a system is increased.
There is no NFV architecture-based charging method at present.
Embodiments of the present invention provide a charging method and apparatus, so that NFV architecture-based charging can be implemented.
A first aspect provides a system, the system being applied to NFV architecture-based charging, and including: an NFVO and a charging system, where the NFVO receives a quota from the charging system, when a trigger event occurs, obtains charging information from a virtual network function manager VNFM and charging information from a virtualized infrastructure manager VIM, where the charging information from the VNFM includes usage information of the quota, and sends the charging information from the VNFM and the charging information from the VIM to the charging system, and the charging system performs charging based on the received charging information.
A second aspect provides a charging method, where the method is applied to NFV architecture-based charging, and includes: receiving, by an NFVO, a quota from a charging system, where the quota is used by the NFVO to control use by a network service NS or use by a virtual network function VNF instance; when a trigger event occurs, obtaining, by the NFVO, charging information from a virtual network function manager VNFM and charging information from a virtualized infrastructure manager VIM, where the trigger event includes an internal trigger event or an external trigger event, occurrence of the internal trigger event is actively detected by the NFVO, occurrence of the external trigger event is actively reported by the VNFM or the VIM to the NFVO, and the charging information from the VNFM includes usage information of the quota; and sending, by the NFVO, the charging information from the VNFM and the charging information from the VIM to the charging system.
The charging information from the VNFM and the charging information from the VIM are reported to the charging system, so that the charging system can perform charging based on the usage information of the quota, and NFV architecture-based charging is implemented.
With reference to the second aspect, in a first possible implementation of the second aspect, the quota includes a duration quota or an event quota, and specifically includes at least one of a duration quota corresponding to the NS, a duration quota corresponding to a VNF, or an event quota corresponding to the VNF. For the event quota corresponding to the VNF, for example, the VNF is a virtualized short message service, and a corresponding event quota may be sending 100,000 short message service messages.
Flexibility of NFV architecture-based charging is improved by performing duration or event charging.
With reference to any one of the second aspect or the first possible implementation of the second aspect, in a second possible implementation, before the sending, by the NFVO, the charging information from the VNFM and the charging information from the VIM to the charging system, the NFVO associates the charging information from the VNFM and the charging information from the VIM, and the sending, by the NFVO, the charging information from the VNFM and the charging information from the VIM to the charging system is: sending, by the NFVO, the associated charging information to the charging system.
With reference to any one of the second aspect or the first and the second possible implementations of the second aspect, in a third possible implementation, the NFVO associates the charging information from the VNFM and the charging information from the VIM based on a correspondence between a VNF instance identifier and a VM identifier.
With reference to any one of the second aspect or the first to the third possible implementations of the second aspect, in a fourth possible implementation, the charging information from the VNFM further includes a VNF instance identifier, and the NFVO associates a VNF instance in the charging information from the VNFM with a corresponding NS based on the VNF instance identifier and a correspondence between an NS identifier and a VNF instance identifier.
VNF related parameters may further include a VNF vendor, VNF abnormality information, and the like.
Charging information of the NS may be obtained after the charging information is associated, so that the charging system may charge use of the NS.
With reference to any one of the second aspect or the first to the fourth possible implementations of the second aspect, in a fifth possible implementation, the internal trigger event includes a network service NS state change or a VNF state change, the NS state change includes at least one of NS instance update, NS instance scaling out, NS instance scaling in, NS instance scaling up/down, NS instantiation, or NS instance termination, and the VNF state change includes at least one of VNF scaling out, VNF scaling in, VNF scaling up/down, VNF instantiation, VNF instance termination, a required-resource allocation request for a VNF, or a required-resource release request for a VNF.
With reference to any one of the second aspect or the first to the fifth possible implementations of the second aspect, in a sixth possible implementation, the external trigger event includes status information reported by the VNFM or status information reported by the VIM, the status information reported by the VNFM includes at least one of a change in a quantity of virtual machines VMs used in a VNF instance, a VNF abnormality event, or a state change of a reserved VNF instance, and the status information reported by the VIM includes a change in an area to which a resource used in the VNF belongs or a change in a state of a resource reserved by the VIM.
An event report mechanism that includes the internal trigger event and the external trigger event enables the NFVO to determine more accurately and comprehensively moments of obtaining and reporting the charging information, thereby enhancing charging accuracy.
With reference to any one of the second aspect or the first to the sixth possible implementations of the second aspect, in a seventh possible implementation, the charging information from the VIM includes resource usage information of the VM.
A third aspect provides a charging method, where the method is applied to NFV architecture-based charging, and includes: sending, by a charging system, a quota to an NFVO, where the quota is used by the NFVO to control use by a network service NS or use by a virtual network function VNF instance; receiving, by the charging system, charging information from the NFVO, where the charging information carries usage information of the quota, and the charging information includes charging information from a VNFM and charging information from a VIM; and performing, by the charging system, charging based on the received charging information.
The charging information from the VNFM and the charging information from the VIM are received, so that the charging system can perform charging based on the usage information of the quota, and NFV architecture-based charging is implemented.
With reference to the third aspect, in a first possible implementation of the third aspect, after the charging system receives the charging information from the VNFM and the charging information from the VIM, the charging system associates the charging information from the VNFM and the charging information from the VIM, and the performing, by the charging system, charging based on the received charging information is: performing, by the charging system, charging based on the associated charging information.
With reference to any one of the third aspect or the first possible implementation of the third aspect, in a second possible implementation, the charging system associates the charging information from the VNFM and the charging information from the VIM based on a correspondence between a VNF instance identifier and a VM identifier.
With reference to any one of the third aspect or the first and the second possible implementations of the third aspect, in a third possible implementation, the charging information from the VNFM further includes a VNF instance identifier, and the charging system associates a VNF instance in the charging information from the VNFM with a corresponding NS based on the VNF instance identifier and a correspondence between an NS identifier and a VNF instance identifier.
Charging information of the NS may be obtained after the charging information is associated, so that the charging system may charge use of the NS.
A fourth aspect provides a computing device, the device being applied to NFV architecture-based charging, and including: a processor, a memory, a bus, and a communications interface, where the memory is configured to store a computing device execution instruction, the processor and the memory are connected by using the bus, and when the computing device is run, the processor executes the computing device execution instruction stored in the memory, to enable the computing device to perform the method according to the second aspect or any possible implementation of the second aspect.
A fifth aspect provides a computing device, the device being applied to NFV architecture-based charging, and including: a processor, a memory, a bus, and a communications interface, where the memory is configured to store a computing device execution instruction, the processor and the memory are connected by using the bus, and when the computing device is run, the processor executes the computing device execution instruction stored in the memory, to enable the computing device to perform the method according to the third aspect or any possible implementation of the third aspect.
A sixth aspect provides a computer readable storage medium, storing executable program code, where the program code is used to implement the method according to the second aspect or any possible implementation of the second aspect.
A seventh aspect provides a computer readable storage medium, storing executable program code, where the program code is used to implement the method according to the third aspect or any possible implementation of the third aspect.
An eighth aspect provides a charging apparatus, including modules configured to perform the method according to the second aspect or any possible implementation of the second aspect.
A ninth aspect provides a charging apparatus, including modules configured to perform the method according to the third aspect or any possible implementation of the third aspect.
According to the technical solutions provided in the embodiments of the present invention, the NFVO reports the charging information from the VNFM and the charging information from the VIM to the charging system, and the charging system performs charging based on the received charging information, so that NFV architecture-based charging is implemented. In addition, an event report mechanism that includes an internal trigger event and an external trigger event enables the NFVO to determine more accurately and comprehensively moments of obtaining and reporting the charging information, thereby enhancing charging accuracy.
A tenth aspect provides a charging method, including: when a first trigger event occurs, sending, by an NFVO, first charging information to a charging system; when a second trigger event occurs, sending, by a VNFM, second charging information to the charging system; when a third trigger event occurs, sending, by a VIM, third charging information to the charging system; and associating, by the charging system, the first charging information, the second charging information, and the third charging information to perform charging, where the first trigger event includes a periodic report or an NS state change, the second trigger event includes a periodic report or a VNF state change, the third trigger event includes a periodic report or a change in a state of a resource required by a VNF, the first charging information includes: an identifier of an NS, an identifier of a VNF instance included in the NS, an identifier of a VM used in the VNF instance, and usage information of the NS, the second charging information includes an identifier of a VNF instance, and usage information of the VNF instance, and the third charging information includes an identifier of a VM and usage information of the VM.
The NFVO, the VNFM, and the VIM send the first charging information, the second charging information, and the third charging information to the charging system respectively, so that the charging system can associate the received charging information and perform charging, and NFV architecture-based charging is implemented.
With reference to the tenth aspect, in a first possible implementation of the tenth aspect, the VNFM sends the second charging information to the charging system by using the NFVO, and the VIM sends the third charging information to the charging system by using the NFVO. In this way, it can be avoided to define new interfaces between the VNFM, the VIM, and the charging system, thereby reducing complexity.
An eleventh aspect provides a charging method, including: when a second trigger event occurs, sending, by a VNFM, second charging information to an NFVO; when a third trigger event occurs, sending, by a VIM, third charging information to the NFVO; associating, by the NFVO, the second charging information and the third charging information, to obtain the associated charging information; and when a first trigger event occurs, sending, by the NFVO, the associated charging information to the charging system, where the first trigger event includes a periodic report or an NS state change, the second trigger event includes a periodic report or a VNF state change, the third trigger event includes a periodic report or a change in a state of a resource required by a VNF, the NFVO stores an identifier of an NS, an identifier of a VNF instance included in the NS, and an identifier of a VM used in the VNF instance, the second charging information includes an identifier of a VNF instance, and usage information of the VNF instance, and the third charging information includes an identifier of a VM and usage information of the VM.
The NFVO sends the associated second charging information and third charging information to the charging system, so that the charging system can perform charging based on the received charging information, and NFV architecture-based charging is implemented.
To describe the technical solutions in the embodiments of the present invention more clearly, the following briefly describes the accompanying drawings required for describing the embodiments. Apparently, the accompanying drawings in the following description show merely some embodiments of the present invention, and persons of ordinary skill in the art may still derive other drawings from these accompanying drawings without creative efforts.
In the following description, to illustrate rather than limit, specific details such as a particular system structure, an interface, and a technology are provided to make a thorough understanding of the present invention. However, persons skilled in the art should know that the present invention may be practiced in other embodiments without these specific details. In other cases, detailed descriptions of well-known apparatuses, circuits, and methods are omitted, so that the present invention is described without being obscured by unnecessary details.
The NFV MANO system 101 is configured to perform supervision and management on the VNFs 108 and the NFVI 130.
The NFVO 102 may implement a network service (NS) on the NFVI 130, or may execute a resource related request from the one or more VNFMs 104, send configuration information to the VNFM 104, and collect status information of the VNFs 108. In addition, the NFVO 102 may communicate with the VIM 106 to implement resource allocation or reservation and exchange virtualized hardware resource configuration and status information.
The VNFM 104 may manage one or more VNFs 108. The VNFM 104 may perform a variety of management functions such as instantiating, updating, querying, scaling, and terminating the VNFs 108.
The VIM 106 may perform a function of managing a resource such as managing allocation of infrastructure resources (for example, adding a resource to a virtual container), or may perform an operation function such as collecting NFVI failure information. The VNFM 104 and the VIM 106 may communicate with each other to perform resource allocation and exchange virtualized hardware resource configuration and status information.
The NFVI 130 includes hardware resources, software resources, or a combination of both to complete deployment of a virtualized environment. In other words, the hardware resources and the virtualization layer are used to provide virtualized resources such as virtual machines and another form of virtual containers for the VNFs 108. The hardware resources include the computing hardware 112, the storage hardware 114, and the network hardware 116. The computing hardware 112 may be commercial off-the-shelf hardware or custom hardware used to provide processing and computing resources. The storage hardware 114 may be storage capacity that is provided in a network or storage capacity (a local memory located in a server) that resides in the storage hardware 114 itself. In an implementation solution, the resources from the computing hardware 112 and the storage hardware 114 may be pooled together. The network hardware 116 may be a switch, a router, or any other network device configured to perform a switching function. The network hardware 116 may span a plurality of domains and may include a plurality of networks that are interconnected via one or more transport networks.
The virtualization layer in the NFVI 130 may abstract the hardware resources and decouple the VNFs 108 from a physical layer to provide virtualized resources to the VNFs 108. The virtualization layer includes the virtual computing 110, the virtual storage 118, and the virtual network 120. The virtual computing 110 and the virtual storage 118 may be provided to the VNFs 108 in a form of virtual machines or other virtual containers. For example, one or more VNFs 108 may be deployed on a virtual machine. The virtualization layer abstracts the network hardware 116 to form the virtual network 120. The virtual network 120 may include a virtual switch. The virtual switch is used to provide a connection between virtual machines. In addition, the transport network in the network hardware 116 may be virtualized using a centralized control plane and a separate forwarding plane (for example, software defined networking, SDN).
An NFVO may be implemented in a form of a computer device. A charging system is included in the BSS, and may be implemented in a form of a computer device.
The processor 202 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, to execute a related program to implement the technical solution provided in this embodiment of the present invention.
The memory 204 may be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random-access memory (RAM). The memory 204 may store an operating system 2041 and another application program 2042. During implementation of the technical solution provided in this embodiment of the present invention by using software or firmware, program code for implementing the technical solution provided in this embodiment of the present invention is stored in the memory 204 and is executed by the processor 202.
The communications interface 206 uses a transmit and receive apparatus, for example, but not limited to a transceiver, to implement communication between the interface and another device or communications network.
The bus 208 may include a channel, through which information is delivered between parts (for example, the processor 202, the memory 204, and the communications interface 206).
When the computer device 200 is an NFVO, the processor 202 is configured to: receive a quota from the charging system; when a trigger event occurs, obtain charging information from a virtual network function manager VNFM and charging information from a virtualized infrastructure manager VIM, where the trigger event includes an internal trigger event or an external trigger event, occurrence of the internal trigger event is actively detected by the processor 202, occurrence of the external trigger event is actively reported by the VNFM or the VIM to the processor 202, and the charging information from the VNFM includes usage information of the quota; and send the charging information from the VNFM and the charging information from the VIM to the charging system.
When the computer device 200 is a charging system, the processor 202 is configured to: send the quota to the NFVO; receive charging information from the NFVO, where the charging information carries the usage information of the quota, and the charging information includes the charging information from the VNFM and the charging information from the VIM; and perform charging based on the received charging information.
VNF instances in an NFV architecture are usually not provided by a same vendor, and it is difficult to collect and jointly use charging information. In this embodiment, the NFVO reports the charging information from the VNFM and the charging information from the VIM to the charging system, and the charging system performs charging based on the received charging information, so that NFV architecture-based charging is implemented.
S301: The NFVO sends a quota request message to the charging system.
S302: The charging system receives the quota request message from the NFVO.
Specifically, the NFVO sends the quota request message by extending an existing interface Os-Ma-nfvo between the NFVO and the BSS, or may send the quota request message by defining a new interface (for example, by defining a new interface based on a requirement of the Diameter protocol).
S303: The charging system sends a quota to the NFVO.
Optionally, the quota has a granularity of an NS or a granularity of a VNF. The quota is used by the NFVO to control use by a network service NS or use by a virtual network function VNF instance.
S304: The NFVO receives the quota from the charging system.
S305: When a trigger event occurs, the NFVO obtains charging information from the virtual network function manager VNFM and charging information from the virtualized infrastructure manager VIM, where the trigger event includes an internal trigger event or an external trigger event, and the charging information from the VNFM includes usage information of the quota.
Specifically, the charging information from the VNFM further includes VNF related parameters. The VNF related parameters include a VNF instance identifier, a VNF vendor, VNF abnormality information, and the like.
For example, the charging information reported by the VNFM may include the following information shown in Table 1:
One network service NS includes one or more VNF instances. The VNF instance is a concept in the prior art, means a run-time instantiation of VNF software, and is a result of completing instantiation of virtualization deployment units (VDU) of the run-time instance and connection between the VDUs, VNF deployment and operation information captured during use of a VNF description (VNFD) 126, and additional run-time-instance-specific information and constraints.
When the quota has a granularity of a VNF, the charging information sent by the VNFM carries quota usage information of the VNF instance. When the quota has a granularity of an NS, the charging information sent by the VNFM carries quota usage information of the VNF instance, and the NFVO determines quota usage information of the NS based on the quota usage information of the VNF instance. For example, the quota is that use of the NS is allowed for 10 hours. The NS includes three VNF instances: a VNF 1, a VNF 2, and a VNF 3. After the charging system delivers the quota, the VNF 1, the VNF 2, and the VNF 3 are instantiated at different time. The VNF 1, the VNF 2, and the VNF 3 have operated for 8 hours, 5 hours, and 1 hour, respectively. The charging information sent by the VNFM carries quota usage information being 8 hours of the VNF 1, quota usage information being 5 hours of the VNF 2, and quota usage information being 1 hour of the VNF 3. The NFVO uses the longest duration being 8 hours as the quota usage information of the NS.
When the quota has a granularity of a VNF, the NFVO applies for the quota for the VNF instances separately. For example, the NS includes three VNF instances: a VNF 1, a VNF 2, and a VNF 3. If the quota of the VNF 1 is used up, regardless of whether the quotas of the VNF 2 and the VNF 3 are used up, the NFVO applies for the quota again for the VNF 1. When the quota has a granularity of an NS, the NFVO applies for the quota together for all the VNF instances. For example, the NS includes three VNF instances: a VNF 1, a VNF 2, and a VNF 3. The NFVO applies for the quota again for the VNF 1, the VNF 2, and the VNF 3, provided that quota usage of one of the VNF instances reaches the delivered quota.
Specifically, the charging information from the VIM includes resource usage information of a virtual machine (VM).
For example, the charging information reported by the VIM may include the following information shown in Table 2:
The resource usage information of the VM may be: for example, within two hours, a CPU usage ratio of 30%, a memory usage ratio of 40%, storage usage of 50 G, and a network bandwidth data amount of 300 G.
For example, the internal trigger event includes a network service NS state change or a VNF state change. The NS state change includes at least one of NS instance update, NS instance scaling out, NS instance scaling in, NS instance scaling up/down, NS instantiation, or NS instance termination. The VNF state change includes at least one of VNF scaling out, VNF scaling in, VNF scaling up/down, VNF instantiation, VNF instance termination, a NFVI resources allocation request for a VNF, or a required-resource release request for a VNF.
For example, the external trigger event includes status information reported by the VNFM or status information reported by the VIM, the status information reported by the VNFM includes at least one of a change in a quantity of virtual machines VMs used in a VNF instance, a VNF abnormality event, and a state change of a reserved VNF instance, or the status information reported by the VIM includes a change in an area to which a resource used in the VNF belongs or a change in a state of a resource reserved by the VIM. The state change of the reserved VNF instance includes a change of the VNF instance from an active state to a waiting state, or a change from a waiting state to an active state. The change in the state of the resource reserved by the VIM includes a change of the reserved resource from an active state to a waiting state, or a change from a waiting state to an active state. The VNF abnormality event includes VNF re-instantiation, alarm, and that a quantity of times of calls per second CPS is less than or exceeds a threshold.
Occurrence of the internal trigger event may be actively detected by the NFVO. For example, the NFVO may request regularly a state of the NS or a state of the VNF. Occurrence of the external trigger event may be actively reported by the VNFM or the VIM to the NFVO. For example, when the VNF is re-instantiated, the VNFM reports this event to the NFVO.
An event report mechanism that includes the internal trigger event and the external trigger event enables the NFVO to determine more accurately and comprehensively moments of obtaining and reporting the charging information, thereby enhancing charging accuracy.
When the trigger event occurs, the NFVO obtains the charging information from the VNFM and the VIM. For example, when detecting NS instance scaling in, the NFVO obtains the charging information from the VNFM and the VIM. Specifically, the charging information obtained from the VNFM may include a VNF instance identifier, a VNF operation start time, and operation duration. The charging information obtained from the VIM may include a VM identifier, a VM use start time, and usage information of a CPU resource, a memory resource, a storage resource, a network resource, and the like. Alternatively, for example, when receiving information that is reported by the VNFM and that is about a change of the reserved VNF instance from a waiting state to an active state, the NFVO obtains the charging information from the VNFM and the VIM.
S306: The NFVO sends the charging information from the VNFM and the charging information from the VIM to the charging system.
S307: The charging system receives charging information from the NFVO, where the charging information carries the usage information of the quota, and the charging information includes the charging information from the VNFM and the charging information from the VIM.
S308. The charging system performs charging based on the received charging information.
Specifically, the NFVO sends the charging information by using the extended existing interface Os-Ma-nfvo between the NFVO and the BSS in the foregoing step 302, or sends the charging information by using the new interface defined in the foregoing step 302.
Optionally, before the sending, by the NFVO, the charging information from the VNFM and the charging information from the VIM to the charging system, the NFVO associates the charging information from the VNFM and the charging information from the VIM, and the sending, by the NFVO, the charging information from the VNFM and the charging information from the VIM to the charging system is: sending, by the NFVO, the associated charging information to the charging system.
For example, the associated charging information may include the following information shown in Table 3:
Charging information of the NS may be obtained after the charging information is associated, so that the charging system may charge use of the NS.
Optionally, the NFVO associates the charging information from the VNFM and the charging information from the VIM based on a correspondence between a VNF instance identifier and a VM identifier. The correspondence between a VNF instance identifier and a VM identifier may be configured in the NFVO in advance.
Optionally, the NFVO stores an identifier of an NS and an identifier of a VNF instance included in the NS (or a correspondence between an NS identifier and a VNF instance identifier). The NFVO associates a VNF instance in the charging information from the VNFM with a corresponding NS based on the identifier of the VNF instance included in the NS and a VNF instance identifier in the charging information from the VNFM, so that the charging information of the NS can be obtained. The charging information of the NS is sent to the charging system, and the charging system charges use of the NS based on the charging information.
For example, the charging information is sent to the charging system during the foregoing NS instance scaling in. The NFVO associates the charging information from the VNFM and the charging information from the VIM. The obtained charging information of the NS includes an identifier of the NS, a use start time of the NS, use duration of the NS, a VNF list, and a VM list. The VM list includes the usage information of a CPU resource, a memory resource, a storage resource, and a network resource.
Optionally, the NFVO may not associate the charging information from the VNFM and the charging information from the VIM, but send the charging information to the charging system instead. After the charging system receives the charging information from the VNFM and the charging information from the VIM, the charging system associates the charging information from the VNFM and the charging information from the VIM, and the performing, by the charging system, charging based on the received charging information is: performing, by the charging system, charging based on the associated charging information.
The received charging information is associated by the charging system instead of the NFVO, so that load and complexity of the NFVO can be reduced.
Optionally, the charging system associates the charging information from the VNFM and the charging information from the VIM based on a correspondence between a VNF instance identifier and a VM identifier, and associates a VNF instance in the charging information from the VNFM with a corresponding NS based on the identifier of the VNF instance included in the NS, so that the charging information of the NS can be obtained, the charging system charges use of the NS based on the charging information. The correspondence between a VNF instance identifier and a VM identifier (or the identifier of the VM used in the VNF instance) may be configured in the charging system in advance, or may be sent by the NFVO to the charging system. The identifier of the NS and the identifier of the VNF instance included in the NS may be configured in the charging system in advance, or may be sent by the NFVO to the charging system.
Optionally, the charging system may charge use of the VNF based on the charging information from the VNFM and the charging information from the VIM.
Specifically, the charging information from the VNFM may further include operation start time of VNF instances and use duration of the VNF instances. The charging information from the VIM may further include VM use start time and usage information of a CPU resource, a memory resource, a storage resource, a network resource, and the like. The charging system may charge use of the VNF based on the information.
According to the charging method provided in this embodiment of the present invention, the NFVO reports the charging information from the VNFM and the charging information from the VIM to the charging system, and the charging system performs charging based on the received charging information, so that NFV architecture-based charging is implemented.
S401: When a first trigger event occurs, the NFVO sends first charging information to the charging system.
Specifically, the NFVO sends the first charging information by using an existing interface Os-Ma-nfvo between the NFVO and the BSS, or may send the first charging information by defining a new interface (for example, by defining a new interface based on a requirement of the Diameter protocol).
Specifically, the first trigger event includes a periodic report (which may be implemented in a manner of setting a timer) or an NS state change. The NS state change includes at least one of NS instance update, NS instance scaling out, NS instance scaling in, NS instance scaling up/down, NS instantiation, or NS instance termination.
The first trigger event may be configured in the NFVO in advance. The NFVO stores the collected first charging information before the first trigger event occurs, and sends the first charging information to the charging system when the first trigger event occurs.
Specifically, the first charging information includes: an identifier of an NS, an identifier of a VNF instance included in the NS, an identifier of a VM used in the VNF instance, and usage information of the NS. The usage information of the NS may be use duration of the NS or a quantity of times of using the NS.
Optionally, the first charging information may include the following information, as shown in Table 4:
S402: When a second trigger event occurs, the VNFM sends second charging information to the charging system.
Specifically, the VNFM may send the second charging information by using a new interface defined between the VNFM and the charging system.
Specifically, the second trigger event includes a periodic report or a VNF state change. The VNF state change includes at least one of VNF scaling out, VNF scaling in, VNF scaling up/down, VNF instantiation, or VNF instance termination. The second trigger event may be configured in the VNFM in advance. The VNFM stores the collected second charging information before the second trigger event occurs, and sends the second charging information to the charging system when the second trigger event occurs.
Specifically, the second charging information includes an identifier of a VNF instance and usage information of the VNF instance. The usage information of the VNF instance includes use duration of the VNF instance or a quantity of times of using the VNF instance.
Optionally, the second charging information may include the following information shown in Table 5:
S403: When a third trigger event occurs, the VIM sends third charging information to the charging system.
Specifically, the VIM may send the third charging information by using a new interface defined between the VIM and the charging system.
Specifically, the third trigger event includes a periodic report or a change in a state of a resource required by a VNF. The change in the state of the resource required by the VNF includes a required-resource allocation request for a VNF or a required-resource release request for a VNF.
The third trigger event may be configured in the VIM in advance. The VIM stores the collected third charging information before the third trigger event occurs, and sends the third charging information to the charging system when the third trigger event occurs.
Specifically, the third charging information includes an identifier of a VM and usage information of the VM. The usage information of the VM includes information about a resource used by the VM or duration of the VM.
Optionally, the third charging information may include the following information shown in Table 6:
S404: The charging system associates the first charging information, the second charging information, and the third charging information to perform charging.
Specifically, the charging system associates the first charging information and the second charging information based on a VNF instance identifier in the first charging information and a VNF instance identifier in the second charging information; and associates the first charging information and the third charging information based on a correspondence between a VNF instance identifier and a VM identifier in the first charging information and a VM identifier in the third charging information. The first charging information includes an identifier of a VNF instance included in an NS. Therefore, charging information of the NS can be obtained after the association. The charging system charges use of the NS. Because the second charging information includes the usage information of the VNF instance, use of the VNF can also be charged after the association.
Optionally, in S402, the VNFM sends the second charging information to the charging system by using the NFVO. Specifically, when the second trigger event occurs, the VNFM sends the second charging information to the NFVO. When the first trigger event occurs, the NFVO sends the second charging information to the charging system. Specifically, the VNFM sends the second charging information by using an existing interface Or-vnfm between the NFVO and the VNFM, or may send the second charging information by defining a new interface.
Optionally, in S403, the VIM sends the third charging information to the charging system by using the NFVO. Specifically, when the third trigger event occurs, the VIM sends the third charging information to the NFVO. When the first trigger event occurs, the NFVO sends the third charging information to the charging system. Specifically, the VIM sends the third charging information by using an existing interface Or-Vi between the NFVO and the VIM, or may send the third charging information by defining a new interface.
The foregoing description manner of using the order “S401, S402, S403” is used to clearly describe this embodiment of the present invention, but is not used to limit an order in which the NFVO, the VNFM, and the VIM send the charging information to the charging system. When the respective trigger events occur, the charging information is correspondingly sent to the charging system.
According to the charging method provided in this embodiment of the present invention, the first charging information, the second charging information, and the third charging information are sent to the charging system, so that the charging system can associate the received charging information and perform charging, and NFV architecture-based charging is implemented.
S501: When a second trigger event occurs, the VNFM sends the second charging information to the NFVO.
Specifically, the VNFM sends the second charging information by using an existing interface Or-vnfm between the NFVO and the VNFM, or may send the second charging information by defining a new interface.
Specifically, for related content of the second trigger event and the second charging information, refer to the related content in S402 in the embodiment in
S502: When a third trigger event occurs, the VIM sends the third charging information to the NFVO.
Specifically, the VIM sends the third charging information by using an existing interface Or-Vi between the NFVO and the VIM, or may send the third charging information by defining a new interface.
Specifically, for related content of the third trigger event and the third charging information, refer to the related content of S403 in the embodiment in
S503: The NFVO associates the second charging information and the third charging information, to obtain the associated charging information.
Specifically, the NFVO stores an identifier of an NS, an identifier of a VNF instance included in the NS, and an identifier of a VM used in the VNF instance (or a correspondence between a VNF instance identifier and a VM identifier).
The NFVO associates usage information of the VNF instance in the second charging information with a corresponding NS based on the identifier of the VNF instance included in the NS and the identifier of the VNF instance included in the second charging information; and associates usage information of the VM in the third charging information with a corresponding VNF based on the correspondence between a VNF instance identifier and a VM identifier and the identifier of the VM in the third charging information. Charging information of the NS can be obtained after the association.
S504: When a first trigger event occurs, the NFVO sends the associated charging information to the charging system.
S505: The charging system performs charging based on the received charging information.
Specifically, the NFVO sends the charging information of the NS to the charging system, and the charging system charges use of the NS. Because the charging information of the NS includes the usage information of the VNF instance, the charging system may charge use of the VNF.
The foregoing description manner of using the order “S501, S502” is used to clearly describe this embodiment of the present invention, but is not used to limit an order in which the VNFM and the VIM send the charging information to the NFVO. When the respective trigger events occur, the charging information is correspondingly sent to the NFVO.
According to the charging method provided in this embodiment of the present invention, the associated second charging information and third charging information are sent to the charging system, so that the charging system can perform charging based on the received charging information, and NFV architecture-based charging is implemented.
In another implementation of the embodiments of the present invention, the embodiment in
In another implementation of the embodiments of the present invention, the embodiment in
In another implementation of the embodiments of the present invention, the embodiment in
The receiving module 802 is configured to receive a quota from a charging system.
The processing module 804 is configured to: when a trigger event occurs, obtain charging information from a virtual network function manager VNFM and charging information from a virtualized infrastructure manager VIM, where the trigger event includes an internal trigger event or an external trigger event, occurrence of the internal trigger event is actively detected by the processing module 804, occurrence of the external trigger event is actively reported by the the VNFM or the VIM to the processing module 804, and the charging information from the VNFM includes usage information of the quota.
The sending module 806 is configured to send the charging information from the VNFM and the charging information from the VIM to the charging system.
Optionally, before the sending module 806 sends the charging information from the VNFM and the charging information from the VIM to the charging system, the processing module 804 is further configured to associate the charging information from the VNFM and the charging information from the VIM, and that the sending module 806 sends the charging information from the VNFM and the charging information from the VIM to the charging system is: sending, by the sending module 806, the associated charging information to the charging system.
Specifically, the processing module 804 associates the charging information from the VNFM and the charging information from the VIM based on a correspondence between a VNF instance identifier and a VM identifier.
The charging information from the VNFM further includes a VNF instance identifier, and the processing module 804 associates a VNF instance in the charging information from the VNFM with a corresponding NS based on the VNF instance identifier and a correspondence between an NS identifier and a VNF instance identifier.
Optionally, the charging information from the VIM includes resource usage information of the VM.
For specific content about the internal trigger event and the external trigger event, refer to the description in S305 in the embodiment in
The sending module 902 is configured to send a quota to an NFVO.
The receiving module 904 is configured to receive charging information from the NFVO, where the charging information carries usage information of the quota, and the charging information includes charging information from a VNFM and charging information from a VIM.
The processing module 906 is configured to perform charging based on the received charging information.
Optionally, after the receiving module 904 receives the charging information from the VNFM and the charging information from the VIM, the processing module 906 is further configured to associate the charging information from the VNFM and the charging information from the VIM, and that the processing module 906 performs charging based on the received charging information is:
performing, by the processing module 906, charging based on the associated charging information.
Specifically, the processing module 906 associates the charging information from the VNFM and the charging information from the VIM based on a correspondence between a VNF instance identifier and a VM identifier.
The charging information from the VNFM further includes a VNF instance identifier, and the processing module 906 associates a VNF instance in the charging information from the VNFM with a corresponding NS based on the VNF instance identifier and a correspondence between an NS identifier and a VNF instance identifier.
According to the charging method provided in this embodiment of the present invention, the charging information from the VNFM and the charging information from the VIM are reported to the charging system, and the charging system performs charging based on the received charging information, so that NFV architecture-based charging is implemented.
The “modules” in the embodiments in
It should be noted that although only the processor 202, the memory 204, the communications interface 206, and the bus 208 are shown in the computer device 200 shown in
In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units are integrated into one unit. The integrated unit may be implemented in a form of hardware, or may be implemented in a form of a software functional unit.
When the integrated unit is implemented in a form of a software functional unit and sold or used as an independent product, the integrated unit may be stored in a computer-readable storage medium. Based on such an understanding, the technical solutions of the present invention essentially, or the part contributing to the prior art, or all or a part of the technical solutions may be implemented in a form of a software product. The software product is stored in a storage medium and includes several instructions for instructing a computer device (which may be a personal computer, a server, or a network device) or a processor to perform all or a part of the steps of the methods described in the embodiments of the present invention. The foregoing storage medium includes: any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory (ROM), a random-access memory (RAM), a magnetic disk, or an optical disc.
The foregoing descriptions are merely specific implementations of the present invention, but are not intended to limit the protection scope of the present invention. Any variation or replacement readily figured out by persons skilled in the art within the technical scope disclosed in the present invention shall fall within the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 201610671813.2 | Aug 2016 | CN | national |
This application is a continuation of International Application No. PCT/CN2017/090611, filed on Jun. 28, 2017, which claims priority to Chinese Patent Application No. 201610671813.2, filed on Aug. 15, 2016. The disclosures of the aforementioned applications are hereby incorporated by reference in their entireties.
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/CN2017/090611 | Jun 2017 | US |
| Child | 16271868 | US |
