CN113766441B

CN113766441B - Mobile edge computing charging method, equipment, device and medium

Info

Publication number: CN113766441B
Application number: CN202010484106.9A
Authority: CN
Inventors: 王青; 刘婧雯
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Communications Ltd Research Institute
Current assignee: China Mobile Zijin Jiangsu Innovation Research Institute Co ltd; China Mobile Communications Group Co Ltd; China Mobile Communications Ltd Research Institute
Priority date: 2020-06-01
Filing date: 2020-06-01
Publication date: 2023-05-05
Anticipated expiration: 2040-06-01
Also published as: CN113766441A

Abstract

The invention discloses a mobile edge computing charging method, equipment, a device and a medium, comprising the following steps: after determining the user to be charged, the mobile edge calculation uploads the service use information of the user to a blockchain and/or acquires the service use information of the user from the blockchain, wherein the service use information is information for charging, and the blockchain is a alliance chain formed by a service operation support system and each mobile edge calculation service node; after determining the user needing to be charged, the service operation support system issues account information and service use information of the user to the block chain to acquire service use information of the user synchronizing among block chain nodes through a consensus mechanism; updating the user's service usage information through the smart contract, and updating the user account cost. By adopting the invention, charging can be performed even if the flow is locally unloaded at the edge, and meanwhile, a central charging system is not needed in a distributed charging mode due to the adopted blockchain technology.

Description

Mobile edge computing charging method, equipment, device and medium

Technical Field

The present invention relates to the field of wireless communications technologies, and in particular, to a mobile edge computing charging method, device, apparatus, and medium.

Background

MEC (mobile edge computing ) technology is to provide computing, storage, etc. infrastructure in close proximity to data sources or users, and to provide cloud services and IT (information technology ) environment services for edge applications. The network service is "sunk" to the radio access network side closer to the user, so that the advantages of low time delay, high speed, blocking prevention and the like are achieved.

The BOSS (business operations support system, business operation support system) system is the primary service system for operators to manage subscriber telephone charge balances.

In the future 5G networks, the service types are rich, and many services require the network to provide requirements of larger bandwidth, low delay, high speed and the like, for example, in the fields of live video, AR (augmented reality ) games, internet of vehicles and the like. Edge computing technology is an important means of providing quality-improving network services, which can be provided at the network edge side. However, a large amount of traffic will be locally offloaded at the network edge, and as the traffic increases, there may be multiple edge services used by one user at the same time, which presents challenges for traditional core network-based charging approaches. Operators need to consider how to implement charging of edge services, even simultaneous charging of single-user multi-edge services.

However, the disadvantage of the prior art is that the existing charging method cannot cope with the MEC deployment method under the 5G architecture.

Disclosure of Invention

The invention provides a mobile edge computing charging method, equipment, a device and a medium, which are used for solving the problem that the existing charging mode can not cope with an MEC deployment mode under a 5G architecture.

The embodiment of the invention provides an MEC charging method, which comprises the following steps:

MEC determines users to be charged;

the MEC uploads the service usage information of the user to the blockchain and/or acquires the service usage information of the user from the blockchain, wherein the service usage information is information for charging, and the blockchain is a alliance chain formed by the BOSS and each MEC service node.

In practice, further comprising:

triggering a Leader MEC selection flow when the edge business which is accessed by the user simultaneously is more than or equal to two kinds;

when the MEC determines that the MEC is a Leader MEC, acquiring service use information of a user from a blockchain, and carrying out blockchain charging statistics and monitoring; and when the MEC determines that the MEC is a non-Leader MEC, uploading service use information of the user to the blockchain.

In the implementation, the Leader MEC selection procedure determines whether the Leader MEC is the Leader MEC after executing the Leader MEC selection rule through the intelligent contract.

In implementation, the Leader MEC selection rule includes one or a combination of the following rules:

selecting according to MEC node use resource conditions determined by MEC states acquired from the blockchain platform;

selecting according to the service type currently used by the user determined by the MEC state acquired from the blockchain platform;

depending on whether the MEC last accessed by the user.

In practice, further comprising:

and if the service used by the user on the Leader MEC is ended, triggering a Leader MEC selection flow.

In practice, the MEC queries account information and service usage information of the user via the smart contract.

In practice, the service usage information of the users acquired from the blockchain is synchronized among the blockchain nodes through a consensus mechanism.

In practice, further comprising:

when the MEC is a Leader MEC, if a Leader MEC node connected with the user monitors that the balance of the user account is 0, sending a service stop notification to the MEC for providing service for the user; and/or if the residual flow of the user is 0 or the service use of the user edge is stopped, feeding back the service use information of the user to the block chain;

when the MEC is a non-Leader MEC, stopping the service after receiving a notification of service stop.

the BOSS determines a user needing charging;

the BOSS issues account information and service use information of a user to a blockchain, wherein the service use information is information for charging, and the blockchain is a alliance chain formed by the BOSS and each MEC service node;

the BOSS acquires service use information of users synchronizing among the block chain nodes through a consensus mechanism;

the bos updates the user's service usage information through the smart contract and updates the user account costs.

The embodiment of the invention provides an MEC, which comprises the following steps:

a processor for reading the program in the memory, performing the following process:

determining a user needing to be charged;

uploading service usage information of a user to a blockchain and/or acquiring the service usage information of the user from the blockchain, wherein the service usage information is information for charging, and the blockchain is a alliance chain formed by a BOSS and each MEC service node;

and a transceiver for receiving and transmitting data under the control of the processor.

In practice, further comprising:

triggering a Leader MEC selection process when the edge service accessed by the user is more than or equal to two types;

When the user is determined to be a Leader MEC, acquiring service use information of the user from the blockchain, and carrying out blockchain charging statistics and monitoring; and when the self is determined to be the non-Leader MEC, uploading the service use information of the user to the blockchain.

depending on whether the MEC last accessed by the user.

In practice, further comprising:

The embodiment of the invention provides an MEC charging device, which comprises:

the MEC determining module is used for determining the user needing charging;

and the MEC receiving and transmitting module is used for uploading service use information of the user to the blockchain and/or acquiring the service use information of the user from the blockchain, wherein the service use information is information for charging, and the blockchain is a alliance chain formed by the BOSS and each MEC service node.

In practice, further comprising:

the Leader MEC selection module is used for triggering a Leader MEC selection flow when the edge business which is accessed by the user simultaneously is more than or equal to two types;

the MEC receiving and transmitting module is further used for acquiring service use information of the user from the blockchain when the MEC determines that the MEC is a Leader MEC, and carrying out blockchain charging statistics and monitoring; and when the MEC determines that the MEC is a non-Leader MEC, uploading service use information of the user to the blockchain.

In an implementation, the Leader MEC selection module is further configured to determine whether the Leader MEC is the Leader MEC after executing the Leader MEC selection rule through the smart contract.

In practice, the Leader MEC selection module is further configured to select according to a Leader MEC selection rule that includes one or a combination of the following rules:

depending on whether the MEC last accessed by the user.

In implementation, the Leader MEC selection module is further configured to trigger a Leader MEC selection procedure if the service used by the user on the Leader MEC ends.

In an implementation, the MEC transceiver module is further configured to query account information and service usage information of the user through the smart contract.

In practice, the MEC transceiver module is further configured to obtain service usage information from the blockchain for users synchronized between blockchain nodes through a consensus mechanism.

In practice, further comprising:

the notification processing module is used for sending a service stop notification to the MEC providing service for the user if the user account balance is monitored to be 0 by the Leader MEC node connected with the user when the MEC is the Leader MEC; and/or if the residual flow of the user is 0 or the service use of the user edge is stopped, feeding back the service use information of the user to the block chain; when the MEC is a non-Leader MEC, stopping the service after receiving a notification of service stop.

The embodiment of the invention provides a BOSS, which comprises the following steps:

determining a user needing to be charged;

issuing account information and service use information of a user to a blockchain, wherein the service use information is information for charging, and the blockchain is a alliance chain formed by a BOSS and each MEC service node;

acquiring service use information of users synchronizing among block chain nodes through a consensus mechanism;

updating the service usage information of the user through the intelligent contract and updating the account cost of the user;

the BOSS determining module is used for determining the user needing charging;

the system comprises a BOSS issuing module, a block chain and a service management module, wherein the BOSS issuing module is used for issuing account information and service use information of a user to the block chain, the service use information is information for charging, and the block chain is a alliance chain formed by the BOSS and each MEC service node;

the BOSS acquisition module is used for acquiring service use information of users synchronizing among the block chain nodes through a consensus mechanism;

And the BOSS account management module is used for updating the service use information of the user and updating the account cost of the user through the intelligent contract.

In an embodiment of the present invention, a computer-readable storage medium is provided, where a computer program for executing the MEC charging method on the MEC side and/or the MEC charging method on the BOSS side is stored.

The embodiment of the invention provides a charging system, which comprises: MEC and/or MEC billing means as MEC service node, and BOSS and/or MEC billing means, wherein:

a alliance chain consisting of BOSS and each MEC service node;

the MEC is used for uploading service use information of the user to the blockchain after the user to be charged is determined, and/or acquiring the service use information of the user from the blockchain, wherein the service use information is information for charging, and the blockchain is a alliance chain formed by a BOSS and each MEC service node;

the system comprises a BOSS, a block chain and a service management server, wherein the BOSS is used for releasing account information and service use information of a user to a block chain after determining the user to be charged, the service use information is information for charging, and the block chain is a alliance chain formed by the BOSS and each MEC service node; acquiring service use information of users synchronizing among block chain nodes through a consensus mechanism; updating the user's service usage information through the smart contract, and updating the user account cost.

The invention has the following beneficial effects:

in the scheme provided by the embodiment of the invention, since the charging information is transmitted by adopting the block chain technology through the alliance chain formed by the BOSS and each MEC service node, the charging based on the core network is not needed, the charging can be performed even if the traffic is locally unloaded at the edge, and meanwhile, the distributed charging mode does not need a central charging system due to the adopted block chain technology.

Furthermore, by adopting the scheme of the invention, the defect of the edge service charging mode in the 5G environment is made up;

the method solves the problem that the realization of the central charging system is complex under the condition of multi-service and multi-MEC in the future.

Further, the scheme of the invention is adopted:

the interface docking and service processing pressure of the central system is reduced by adopting a distributed block chain architecture;

the service utilization condition of the user flow is monitored and counted through a Leader MEC (main MEC) node, and the counted result is synchronized to other block chain nodes, so that the real-time charging and arrearage reminding of the edge service are realized; the consumed resource is a certain edge node, and the wheel value of each node is not fixed;

because the BOSS platform does not need to be in system butt joint with each MEC platform, the BOSS platform and each MEC platform only need to realize interfaces of the block chain SDK, and the system transformation is small.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the invention and do not constitute a limitation on the invention. In the drawings:

fig. 1 is a schematic diagram of the deployment of MEC in a 5G architecture according to an embodiment of the present invention;

fig. 2 is a schematic flow chart of an implementation of an MEC charging method on the MEC side in the embodiment of the invention;

fig. 3 is a schematic flow chart of an implementation of a MEC charging method on the BOSS side in an embodiment of the present invention;

FIG. 4 is a schematic diagram of a process flow for selecting a Leader MEC according to an embodiment of the present invention;

fig. 5 is a schematic diagram of a header MEC charging implementation flow in an embodiment of the present invention;

FIG. 6 is a schematic diagram of a non-Leader node information synchronization implementation flow in an embodiment of the present invention;

FIG. 7 is a schematic diagram of a user account information uplink implementation flow in an embodiment of the present invention;

fig. 8 is a schematic view of the MEC structure according to an embodiment of the invention;

fig. 9 is a schematic structural diagram of an MEC charging device on the MEC side in the embodiment of the invention;

FIG. 10 is a schematic diagram of an edge server architecture according to an embodiment of the present invention;

FIG. 11 is a schematic diagram of a BOSS structure according to an embodiment of the present invention;

fig. 12 is a schematic structural diagram of an MEC billing device according to an embodiment of the present invention;

FIG. 13 is a schematic diagram of a billing system according to an embodiment of the present invention;

FIG. 14 is a schematic diagram of an account blockchain service platform in accordance with an embodiment of the present invention;

fig. 15 is a schematic diagram of a block chain real-time charging system architecture according to an embodiment of the present invention.

Detailed Description

The inventors noted during the course of the invention that:

under the 5G architecture, MEC servers are deployed in a machine room in the municipality and lower. The data service is closer to the user side, and the interaction time delay is reduced. Fig. 1 is a schematic deployment diagram of the MEC under a 5G architecture, and as shown by a thick solid line from a terminal to the Internet (network) in fig. 1, a data service initiated by a UE (User Equipment) is connected to the MEC server 1 through a gNode B (5G base station), through a UPF (User plane function) of a base station room/zone room, and in this way, how to implement real-time charging needs to be further solved. Meanwhile, the MEC server can reach the MEC server 2 after passing through the local market level UPF, and the deployment method is faster than the mode of reaching the Internet after passing through the core network at the cost of sacrificing a part of time delay.

For real-time charging, people consider charging schemes in a packet domain network at one time, for example, the following schemes are disclosed: receiving a continuous checking request sent by a gateway node, wherein the continuous checking request carries user information and service state information; determining the expected quota amount of the user according to the service state information; and distributing the flow according to the expected quota amount. According to the scheme, the size of the quota fragments is calculated dynamically and intelligently according to the actual demands of user service use.

The prior art has the following defects:

the edge computing platform moves down the service during deployment, so that the flow is locally unloaded at the edge, and the charging function is not easy to realize. The existing 5G edge calculation charging mode has hysteresis, and real-time evaluation and judgment cannot be performed. The existing charging mode in the packet domain is aimed at the ever used network, and the network element function cannot be suitable for the future 5G.

Aiming at the 5G network, most schemes are prolonged by the past thought, and the central charging system is required to periodically allocate the quota, so that on one hand, the scheme increases the operation burden of the central system in the future multi-service development, and on the other hand, the periodical interaction of the central server and the edge server is required, and the time delay is increased.

Based on the above, the embodiment of the invention provides an MEC charging scheme, which is used for solving the problem that the existing charging mode can not cope with the MEC deployment mode under the 5G architecture. The following describes specific embodiments of the present invention with reference to the drawings.

In the description, the implementation of the MEC and the BOSS side will be described separately, and then an example of the implementation of the two in cooperation will be given to better understand the implementation of the scheme given in the embodiment of the present invention. Such a description does not mean that the two must be implemented cooperatively or separately, and in fact, when the MEC is implemented separately from the BOSS, each solves one side problem, and when the two are used in combination, a better technical effect is obtained.

Fig. 2 is a schematic flow chart of implementation of an MEC charging method on the MEC side, and as shown in the drawing, may include:

step 201, MEC determines the user to be charged;

step 202, the MEC uploads the service usage information of the user to the blockchain, and/or obtains the service usage information of the user from the blockchain, wherein the service usage information is information for charging, and the blockchain is a federation chain formed by the BOSS and each MEC service node.

In practice, the method may further comprise:

Fig. 3 is a schematic flow chart of implementation of the MEC charging method on the BOSS side, and as shown in the drawing, may include:

step 301, a BOSS determines a user needing charging;

Step 302, the BOSS issues account information and service usage information of a user to a blockchain, wherein the service usage information is information for charging, and the blockchain is a alliance chain formed by the BOSS and each MEC service node;

step 303, the BOSS acquires service use information of users synchronizing among the blockchain nodes through a consensus mechanism;

step 304, the BOSS updates the service usage information of the user and updates the account cost of the user through the intelligent contract.

The proposal provides a scheme based on blockchain and capable of being used for real-time charging, which can support the statistics and reporting of the user real-time flow at a network edge node (MEC server and the like), and realize real-time synchronization with the user account information of a BOSS system at a blockchain platform, thereby realizing the statistics and updating of the user real-time flow and telephone charge balance and solving the charging problem of the current flow in a local unloading scene of the network edge node. A more specific description is given below.

The implementation on the MEC side will be described first.

1. The Leader MEC selects rules and flow implementation description.

In practice, it may further comprise:

In specific implementation, the Leader MEC selection procedure determines whether the Leader MEC is present after executing the Leader MEC selection rule by the smart contract.

Specifically, when the edge service accessed by a certain user is more than or equal to two kinds of edge services, a Leader MEC node selection process is triggered, block chain charging statistics and monitoring are initiated by the selected Leader MEC node, and when the user has no available flow or balance, a reminder is sent to the user.

In specific implementation, the Leader MEC selection rule includes one or a combination of the following rules:

depending on whether the MEC last accessed by the user.

Specifically, in a single-user multi-edge service scenario, there may be a plurality of rules for selecting a Leader MEC, including but not limited to:

(1) MEC node resource usage (provided to the blockchain platform by MEC state needs).

(2) Users currently use service categories (provided to the blockchain platform by user information), for example, service categories that are stable for a longer period of time, such as high definition movies.

(3) The MEC that the user last accessed.

In a specific implementation, the method may further include:

Specifically, if the service used by the user on the Leader MEC node is finished first, the Leader MEC is replaced by the same principle.

The following is an example.

FIG. 4 is a schematic diagram of a process flow for selecting a Leader MEC, which may include:

step 401. User networking application (simultaneous access to more than 2 edge services).

Step 402, a leader MEC selection request is initiated to provide MEC status information and user information.

Step 403. Initiate a loadermec selection request to provide MEC status information and user information (encryption).

Step 404, the MEC state is recorded, the Leader MEC selection rule is executed through the intelligent contract, and the current Leader MEC selection result of the user is returned.

Step 405. Return the Leader MEC selection result.

Step 406, returning a Leader MEC selection result.

Step 407, returning a Leader MEC selection result.

2. And (5) implementing and describing a header MEC charging flow.

Fig. 5 is a schematic diagram of a header MEC charging implementation flow, which may include:

step 501, obtaining user account information and service information request.

Step 502, obtaining account information and service information request.

Step 503. Query user account information and business information through intelligent contracts.

Step 504. User account information (residual traffic, etc.), other MEC's service usage information is returned.

Step 505. User account information (residual traffic, etc.), service usage information of other MECs are returned.

Step 506, monitoring and counting the use condition of the user flow, and feeding back the blockchain platform when the available flow is 0 or all edge services of the user are stopped.

Step 507. Send a traffic alert to the user.

Step 508, updating the account residual flow information.

Step 509, updating account residual flow information.

Step 510, recording the latest account balance information of the user, and synchronizing information among the blockchain nodes through a consensus mechanism.

Step 511. Return the result.

Step 512. Returning the result.

3. The non-leader node information synchronization flow implementation description.

FIG. 6 is a schematic diagram of a non-Leader node information synchronization implementation process, which may include:

Wherein the real-time loop upload part comprises steps 601-605.

And 601, uploading MEC information and user service usage information.

Step 602. The MEC information and user service usage information are uploaded.

Step 603. Record MEC information and user service usage information.

Step 604. Returning the result.

Step 605. Return the result.

Step 606. User up-to-date account information is synchronized between blockchain nodes (consensus mechanism).

Step 607, if the user connected Leader MEC node monitors the user account balance to be 0, a notification is sent to the MEC.

Step 608. Notify the traffic to stop.

Step 609, notifying the service stop.

For the BOSS side, the user account information uplink flow may be as follows:

fig. 7 is a schematic diagram of a user account information uplink implementation procedure, and as shown in the drawing, the user account information uplink procedure may include:

step 701, number account information is uplink.

Step 702, encrypting the number account information.

Step 703. Number account information is uploaded (smart contract).

Step 704, the node synchronizes transaction information (consensus).

Step 705, returning the result.

Step 706. Returning the result.

Based on the same inventive concept, the embodiment of the invention also provides a MEC, BOSS, MEC charging device, a computer-readable storage medium and a charging system, and because the principle of solving the problems of the devices is similar to that of MEC and BOSS side MEC charging methods, the implementation of the devices can be referred to the implementation of the methods, and the repetition is omitted.

In implementing the technical scheme provided by the embodiment of the invention, the method can be implemented as follows.

Fig. 8 is a schematic structural diagram of an MEC, as shown in the figure, where the MEC includes:

processor 800, for reading the program in memory 820, performs the following processes:

determining a user needing to be charged;

a transceiver 810 for receiving and transmitting data under the control of the processor 800.

In practice, further comprising:

depending on whether the MEC last accessed by the user.

In practice, further comprising:

Wherein in fig. 8, a bus architecture may comprise any number of interconnected buses and bridges, and in particular, one or more processors represented by processor 800 and various circuits of memory represented by memory 820, linked together. The bus architecture may also link together various other circuits such as peripheral devices, voltage regulators, power management circuits, etc., which are well known in the art and, therefore, will not be described further herein. The bus interface provides an interface. Transceiver 810 may be a plurality of elements, i.e., including a transmitter and a receiver, providing a means for communicating with various other apparatus over a transmission medium. The processor 800 is responsible for managing the bus architecture and general processing, and the memory 820 may store data used by the processor 800 in performing operations.

Fig. 9 is a schematic structural diagram of an MEC charging device on the MEC side, including:

the MEC determining module 901 is configured to determine a user to be charged;

the MEC transceiver module 902 is configured to upload service usage information of a user to a blockchain and/or obtain service usage information of the user from the blockchain, where the service usage information is information for charging, and the blockchain is a federation chain formed by a bos and each MEC service node.

In practice, further comprising:

the Leader MEC selection module 903 is configured to trigger a Leader MEC selection procedure when two or more edge services accessed by the user simultaneously;

depending on whether the MEC last accessed by the user.

In practice, further comprising:

the notification processing module 904 is configured to, when the MEC is a Leader MEC, send a service stop notification to a MEC that provides a service for the user if a Leader MEC node connected to the user monitors that a balance of the user account is 0; and/or if the residual flow of the user is 0 or the service use of the user edge is stopped, feeding back the service use information of the user to the block chain; when the MEC is a non-Leader MEC, stopping the service after receiving a notification of service stop.

For convenience of description, the parts of the above apparatus are described as being functionally divided into various modules or units, respectively. Of course, the functions of each module or unit may be implemented in the same piece or pieces of software or hardware when implementing the present invention.

The MEC is described below by way of example only.

FIG. 10 is a schematic diagram of an edge server architecture, as shown in the following:

in order to implement the solution proposed in the embodiment of the present invention, the edge MEC server needs to have an edge charging service, and four functional modules may be added:

blockchain SDK (software development kit ): providing a block chain link point interface service, and interfacing with a block chain platform;

user and usage service management: recording user information, service identification, service type, service state, service use flow rate and the like of the current use of the user, and if the edge server node is a Leader MEC node, recording the information of the current residual usable flow rate and the like of the user and the service use information on other MECs. And if the residual flow of the user is 0 or the service use of the user edge is stopped, feeding back the latest service use condition of the user to the block chain.

MEC state management: and monitoring MEC resource use conditions.

Flow usage calculation:

(1) If the service is the Leader MEC node, the available flow of the user and the current speed of the service used by the user are obtained, and the current residual flow of the user is calculated.

(2) If the user is a non-Leader MEC node, the rate of each service of the user on the MEC needs to be counted in real time.

FIG. 11 is a schematic diagram of a BOSS structure, where the BOSS structure includes:

the processor 1100, configured to read the program in the memory 1120, performs the following procedures:

determining a user needing to be charged;

a transceiver 1110 for receiving and transmitting data under the control of the processor 1100.

Wherein in fig. 11, a bus architecture may comprise any number of interconnected buses and bridges, and in particular one or more processors represented by processor 1100 and various circuits of memory represented by memory 1120, linked together. The bus architecture may also link together various other circuits such as peripheral devices, voltage regulators, power management circuits, etc., which are well known in the art and, therefore, will not be described further herein. The bus interface provides an interface. The transceiver 1110 may be a number of elements, i.e., include a transmitter and a receiver, providing a means for communicating with various other apparatus over a transmission medium. The processor 1100 is responsible for managing the bus architecture and general processing, and the memory 1120 may store data used by the processor 1100 in performing operations.

Fig. 12 is a schematic structural diagram of an MEC charging device, as shown in the drawing, may include:

a BOSS determining module 1201, configured to determine a user to be charged;

a bos publishing module 1202, configured to publish account information and service usage information of a user to a blockchain, where the service usage information is information for charging, and the blockchain is a federation chain formed by a bos and each MEC service node;

a BOSS obtaining module 1203, configured to obtain service usage information of a user that performs synchronization between blockchain nodes through a consensus mechanism;

the BOSS account management module 1204 is configured to update the service usage information of the user and update the user account cost through the smart contract.

The embodiment of the invention also provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program for executing the MEC charging method on the MEC side and/or the MEC charging method on the BOSS side.

The implementation of the MEC charging method on the MEC side and/or the implementation of the MEC charging method on the BOSS side can be referred to in the specific implementation.

Fig. 13 is a schematic diagram of a billing system, as shown in the drawing, which may include: MEC and/or MEC-side MEC billing means (denoted MEC in the figure) as a MEC service node, and bos and/or bos-side MEC billing means (denoted bos in the figure), wherein:

a alliance chain consisting of BOSS and each MEC service node;

An example is described below.

FIG. 14 is a schematic diagram of an account blockchain service platform, including blockchain base functions, management functions, and MEC operation functions. Wherein:

Blockchain base function: and the functions of distributed account book function, intelligent contract management, consensus mechanism, encryption and decryption mechanism and the like are provided.

Management function: the system management capability of the block chain is provided, and the system management capability comprises functions of operation and maintenance monitoring, intelligent contract deployment management and the like.

Operation function: the system operation capability of the blockchain is provided, and system management, user management, node network access management, SDK management, authority management and the like are supported.

Fig. 15 is a schematic diagram of a blockchain-based real-time charging system architecture, where the blockchain-based real-time charging system is composed of BOSS and edge MEC service nodes to form a federation chain. The blockchain real-time charging system comprises an account blockchain service platform, a BOSS node, a plurality of MEC service nodes, a blockchain SDK and the like.

BOSS node: and the service node of the operation management system realizes user account management and charging. The system comprises an OCS real-time charging service system and an OFCS non-real-time charging service system. This patent focuses on the real-time billing part. And the BOSS platform distributes balance information such as user account information, flow, telephone charge and the like to the blockchain, and updates the balance information in real time through intelligent contracts according to the agreed flow and telephone charge service conditions.

Each MEC node: and realizing the edge processing of each service, and carrying out flow statistics and charging based on the service flow. Each MEC node can access the blockchain network without being independently in butt joint with the BOSS platform and only by realizing the SDK interface of the blockchain, so as to inquire the balance of a user account and realize real-time charging service.

Account blockchain service platform: realizing the basic capability of a block chain bottom layer, including a distributed account book, intelligent contract management, a consensus mechanism, an encryption and decryption mechanism and the like; and support the operation of the MEC real-time billing application and related management functions.

In summary, in the technical solution provided in the embodiment of the present invention, a scheme for performing edge charging in real time based on blockchain is provided, which includes selecting a Leader MEC node rule, a Leader MEC charging scheme, a non-Leader MEC matching scheme, etc. under single-user multi-edge service.

And a real-time charging system based on block chain, comprising a BOSS node, an edge MEC node and an account block chain service platform.

By adopting the scheme in the embodiment of the invention, the real-time charging of MEC service is realized, and the defect of the edge service charging mode in the 5G environment is made up;

the MEC increases the real-time charging capability and interacts with the central account information;

And realizing real-time charging through block chain information sharing.

The method solves the problem of complex realization of a central charging system under the condition of multi-service and multi-MEC in the future.

the user traffic service condition is monitored and counted through the Leader MEC node, and the counting result is synchronized to other block chain nodes, so that the real-time charging and arrearage reminding of the edge service are realized. The consumed resource is a certain edge node, and the wheel value of each node is not fixed;

It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, magnetic disk storage, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

It will be apparent to those skilled in the art that various modifications and variations can be made to the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention also include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.

Claims

1. A mobile edge computing MEC charging method, comprising:

MEC determines users to be charged;

the MEC uploads service use information of the user to a blockchain and/or acquires the service use information of the user from the blockchain, wherein the service use information is information for charging, and the blockchain is a alliance chain formed by a service operation support system BOSS and each MEC service node;

The method further comprises:

triggering a main mobile edge computing Leader MEC selection flow when edge services accessed by a user simultaneously are more than or equal to two types;

2. The method of claim 1, wherein the Leader MEC selection process determines whether a Leader MEC is present after execution of a Leader MEC selection rule by the smart contract.

3. The method of claim 2, wherein the Leader MEC selection rule comprises one or a combination of the following rules:

depending on whether the MEC last accessed by the user.

4. A method as claimed in any one of claims 1 to 3, further comprising:

5. The method of claim 1, wherein the MEC queries the user's account information and service usage information via smart contracts.

6. The method of claim 1, wherein the service usage information of the users obtained from the blockchain is synchronized among blockchain nodes by a consensus mechanism.

7. The method as recited in claim 1, further comprising:

8. A MEC billing method comprising:

the BOSS determines a user needing charging;

9. A MEC, comprising:

determining a user needing to be charged;

a transceiver for receiving and transmitting data under the control of the processor;

the processor is also configured to perform the following:

10. A MEC billing apparatus, comprising:

the MEC determining module is used for determining the user needing charging;

the MEC receiving and transmitting module is used for uploading service use information of a user to the blockchain and/or acquiring the service use information of the user from the blockchain, wherein the service use information is information for charging, and the blockchain is a alliance chain formed by a BOSS and each MEC service node;

11. A BOSS, comprising:

determining a user needing to be charged;

12. A MEC billing apparatus, comprising:

the BOSS determining module is used for determining the user needing charging;

13. A computer readable storage medium, characterized in that the computer readable storage medium stores a computer program for executing the method of any one of claims 1 to 7.

14. A billing system, comprising: the MEC of claim 9 and/or the MEC billing device of claim 10, and the bos of claim 11 and/or the MEC billing device of claim 12, as MEC service nodes, wherein:

a alliance chain consisting of BOSS and each MEC service node;