CN110061855B

CN110061855B - Service processing method, system and device

Info

Publication number: CN110061855B
Application number: CN201810691277.1A
Authority: CN
Inventors: 宛清
Original assignee: Hangzhou H3C Technologies Co Ltd
Current assignee: Hangzhou H3C Technologies Co Ltd
Priority date: 2018-06-28
Filing date: 2018-06-28
Publication date: 2021-01-26
Anticipated expiration: 2038-06-28
Also published as: WO2020001514A1; CN110061855A

Abstract

The application provides a service processing method, a system and a device, wherein the method comprises the following steps: receiving a handover command sent by a management device, wherein the handover command carries a device identifier of a second BRAS, and the handover command is sent when the management device determines that the second BRAS meets a handover condition; acquiring service data corresponding to the equipment identifier from a database server, wherein the service data is the service data backed up to the terminal equipment of the database server by the second BRAS; and carrying out service processing on the terminal equipment according to the service data. Through the technical scheme of the application, the processing resources of each BRAS can be fully utilized, and the number of the BRAS is reduced, so that the networking mode is more flexible, the cost is lower, and the energy consumption is lower.

Description

Service processing method, system and device

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method, a system, and an apparatus for processing a service.

Background

A BRAS (Broadband Remote Access Server) is a novel Access gateway for Broadband Network application, is located at the edge of a backbone Network, and can implement Broadband Internet Access, VPN (Virtual Private Network) service, enterprise intranet construction, support of ITMS (Integrated Terminal Management System), VoIP (Voice over Internet Protocol), and other services. In an actual networking environment, there may be a large number of terminals, that is, a BRAS needs to provide services for a large number of terminals, and therefore, a performance bottleneck may occur in the BRAS, and in order to improve the processing performance of the BRAS, a plurality of BRASs may be deployed, and all terminals are provided with services by a plurality of BRASs together.

In order to ensure high availability of each BRAS and thereby improve reliability, a backup BRAS may be provided for each BRAS (subsequently referred to as a primary BRAS), so that when the primary BRAS fails, the backup BRAS may be upgraded to the primary BRAS and serviced by the backup BRAS. For example, a backup BRAS12 may be provided for a primary BRAS11, a backup BRAS22 may be provided for a primary BRAS21, and a backup BRAS32 may be provided for a primary BRAS 31.

Obviously, in the above manner, each primary BRAS corresponds to one backup BRAS, and the number of the primary BRASs is the same as that of the backup BRASs, that is, a large number of backup BRASs need to be deployed, which wastes BRAS resources. Moreover, most of the backup BRAS may not be really used, and the processing resources of the backup BRAS cannot be fully utilized.

Disclosure of Invention

The application provides a service processing method, which is applied to a first BRAS, and the method comprises the following steps:

receiving a handover command sent by a management device, wherein the handover command carries a device identifier of a second BRAS, and the handover command is sent when the management device determines that the second BRAS meets a handover condition;

acquiring service data corresponding to the equipment identifier from a database server, wherein the service data is the service data backed up to the terminal equipment of the database server by the second BRAS;

and carrying out service processing on the terminal equipment according to the service data.

The application provides a business processing system, the system includes: the system comprises a management device, a database server and a BRAS resource pool, wherein the BRAS resource pool comprises a plurality of BRASs, and the method comprises the following steps:

when the management equipment determines that a second BRAS meets a handover condition, a first BRAS for bearing services of the second BRAS is selected from the BRAS resource pool;

the management equipment sends a switching command to the first BRAS, wherein the switching command carries the equipment identification of the second BRAS; the first BRAS is used for the service processing method.

The application provides a service processing device, is applied to first BRAS, the device includes:

a receiving module, configured to receive a handover command sent by a management device, where the handover command carries a device identifier of a second BRAS, and the handover command is sent when the management device determines that the second BRAS meets a handover condition;

an obtaining module, configured to obtain, from a database server, service data corresponding to the device identifier, where the service data is service data backed up by the second BRAS to a terminal device of the database server;

and the processing module is used for carrying out service processing on the terminal equipment according to the service data.

A first BRAS includes a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor; the processor is configured to execute machine executable instructions to implement the business process method steps described above.

A machine-readable storage medium is provided that stores machine-executable instructions that, when invoked and executed by a processor, may cause the processor to implement the business process method steps described above.

Based on the above technical solution, in the embodiment of the present application, when the second BRAS meets the handover condition (for example, the second BRAS fails, or the second BRAS is idle), the service of the second BRAS may be migrated to the first BRAS. For example, the second BRAS may back up the service data to the database server, and the first BRAS may obtain the service data from the database server, and then perform service processing on the terminal device according to the service data. In the foregoing manner, the BRAS resource pool may include a plurality of primary BRASs, or include a plurality of primary BRASs and one redundant BRAS, and the first BRAS may be a primary BRAS or a redundant BRAS, and therefore, it is not necessary to correspond one redundant BRAS to each primary BRAS, and it is possible to deploy no redundant BRAS or to deploy one and the same redundant BRAS to all primary BRASs, that is, it is not necessary to deploy a large number of redundant BRASs, thereby saving BRAS resources, and making full use of processing resources of each BRAS, and reducing the number of BRASs, so that the networking mode is more flexible, and is lower in cost and energy consumption. And moreover, tidal migration can be flexibly realized, when the service is busy, a plurality of main BRASs can be started, part of the service of the main BRAS with higher service pressure can be migrated to a new main BRAS, when the service is idle, all the services can be concentrated to a plurality of main BRASs, the main BRASs take over the services of other BRASs, and the other BRASs can be powered off to save energy.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments of the present application or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings can be obtained by those skilled in the art according to the drawings of the embodiments of the present application.

FIG. 1 is a schematic diagram of an application scenario in an embodiment of the present application;

FIG. 2 is a flow chart of a method for processing traffic in one embodiment of the present application;

fig. 3 is a flowchart of a service processing method according to another embodiment of the present application;

fig. 4 is a flowchart of a service processing method according to another embodiment of the present application;

fig. 5 is a block diagram of a service processing apparatus according to an embodiment of the present application;

fig. 6 is a hardware configuration diagram of a BRAS according to an embodiment of the present application.

Detailed Description

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein is meant to encompass any and all possible combinations of one or more of the associated listed items.

It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. Depending on the context, moreover, the word "if" is used may be interpreted as "at … …," or "when … …," or "in response to a determination.

The embodiment of the application provides a service processing method, which is applied to a system comprising management equipment, a database server, a BRAS and terminal equipment. As shown in fig. 1, which is a schematic view of an application scenario of this embodiment, taking a terminal device, a convergence switch, a gateway device, a BRAS, a management device, a core switch, a core router, and a database server as examples, of course, fig. 1 is only an example, and is not limited thereto. Taking 3 BRAS as an example for explanation, in practical application, the number of BRAS may be more, and the number is not limited.

The terminal device may be, for example, a virtual machine, a PC (Personal Computer), a notebook Computer, a mobile phone, a host, a home terminal, an E8C terminal, an IPTV (internet protocol television) set-top box, an enterprise terminal, and the like, and the type of the terminal device is not limited. The end devices may be coupled to the aggregation switch, such as by an OLT (Optical Line Terminal) to the aggregation switch.

The aggregation switch may be, for example, a POP (Point Of Presence) switch.

The gateway device is used as a gateway of the BRAS resource pool, can be connected with the aggregation switch, and is used for distributing the uplink message sent by the terminal device through the aggregation switch to the BRAS, receiving the downlink message sent by the BRAS, and sending the downlink message to the terminal device through the aggregation switch.

The Management device, which is a MANO (Management and organization) of the BRAS resource pool, may be a controller (e.g., SDN controller), and the type of the Management device is not limited, and the controller is taken as an example in the following. The controller can control the BRAS in the BRAS resource pool, and is used for realizing management and control of the BRAS, deployment of a BRAS resource pool networking architecture, daily operation and maintenance management and flexible service scheduling, and calling an Application Programming Interface (API) through a Network Configuration Protocol (Netconf) Protocol to complete interaction with the BRAS.

The database server is used for storing the service data generated by each BRAS, and can provide an inquiry interface for the BRAS and send the service data to the BRAS. In practical applications, the number of the database servers may be one or more, and for convenience of description, one database server is illustrated in fig. 1 as an example.

The BRAS can be a physical BRAS, and can also be a virtual BRAS (namely a vBRAS); the physical BRAS is a BRAS in a hardware form, such as a server with BRAS service processing capacity; a virtual BRAS is a BRAS in software, such as a virtual resource running on an X86 server with BRAS traffic handling capabilities. Of course, the above procedure only describes two expressions of BRAS, and the expression is not limited.

The BRAS may be a handover separated BRAS, i.e., composed of a BRAS-CP (BRAS Control Plane) and a BRAS-UP (BRAS User Plane, BRAS forwarding Plane). The BRAS-CP is a user control management component, and is used for realizing functions of user control management, user access control, user authentication authorization charging, address management, configuration management and the like. BRAS-UP is a network edge and user policy enforcement component, and is used to implement traffic forwarding, QoS, traffic statistics, ACL (Access Control List) Control, CAR (Committed Access Rate), route distribution, and the like. The BRAS can also be a BRAS with non-separated transfer control, namely an independent BRAS which is not composed of BRAS-CP and BRAS-UP and is used for realizing user control management, user access control, user authentication authorization charging, address management, configuration management, flow forwarding, QoS (quality of service), flow statistics, ACL control, CAR, route issuing and the like.

For convenience of description, the BRAS in this embodiment is illustrated by taking a virtual BRAS as an example, and the BRAS is an independent BRAS with non-separated transfer control. In order to implement a virtual BRAS, a BRAS resource pool may be deployed, and a plurality of BRASs may be partitioned in the BRAS resource pool by an NFV (Network Functions virtualization) technology, where the number of BRASs is not limited, and any number of BRASs may be partitioned according to experience, and in fig. 1, 3 BRASs are taken as an example for description.

In one example, all of the BRAS within the BRAS resource pool may be primary BRAS, which is a BRAS for servicing the terminal equipment, e.g., BRAS141, BRAS142, and BRAS143 may all be primary BRAS. Alternatively, one redundant BRAS may be included in all BRAS in the BRAS resource pool, and the remaining other BRASs are primary BRASs, where the primary BRAS is a BRAS for serving terminal devices, and the redundant BRAS is not currently required to serve any terminal device, and is only used for serving terminal devices after the redundant BRAS is upgraded to the primary BRAS, for example, BRAS141 and BRAS142 may be primary BRASs, and BRAS143 may be redundant BRAS. Of course, other numbers of redundant BRAS may also be included in the BRAS resource pool, and the number of redundant BRAS is not limited.

In a network (such as a data center) which needs to use a BRAS resource pool, in both a networking scenario (where a plurality of primary BRAS are included in the BRAS resource pool) of primary BRAS and a networking scenario (where a plurality of primary BRAS and one redundant BRAS are included in the BRAS resource pool) of N primary BRAS + one redundant BRAS, by using the method provided by the present disclosure, it is possible to implement that a redundant BRAS is not deployed or that the same redundant BRAS is deployed for all primary BRAS, that is, it is not necessary to deploy a large number of redundant BRAS, so that BRAS resources can be saved, processing resources of each BRAS are fully utilized, and the number of BRAS in the data center is reduced.

In the above application scenario, referring to fig. 2, a schematic flow diagram of a service processing method in the embodiment of the present application is shown, where the method may be applied to a first BRAS, and the method may include the following steps:

step 201, receiving a handover command sent by the controller, where the handover command carries the device identifier of the second BRAS, and the handover command is sent when the controller determines that the second BRAS meets the handover condition.

The second BRAS may be any primary BRAS in a BRAS resource pool, and when determining that the second BRAS satisfies a handover condition, the controller determines that the first BRAS carries a service of the second BRAS, and sends a handover command to the first BRAS, where the handover command may carry a device identifier of the second BRAS.

If the BRAS resource pool includes multiple BRASs that are active/standby with each other, the first BRAS may be any BRAS that satisfies a predetermined condition among the multiple BRASs that are active/standby with each other, as long as the first BRAS is different from the second BRAS. The multiple BRASs that are active and standby with each other may all be working BRASs, for example, each of BRAS141, BRAS142, and BRAS143 is a working primary BRAS, and when a BRAS141 is a second BRAS, the BRAS142 may be selected as a secondary BRAS of the BRAS141, that is, the BRAS142 may be used as a first BRAS, or the BRAS143 may be selected as a secondary BRAS of the BRAS141, that is, the BRAS143 may be used as a first BRAS.

Alternatively, if a plurality of primary BRAS and one redundant BRAS (i.e., a temporarily inoperative BRAS) are included in the BRAS resource pool, the first BRAS may be a redundant BRAS within the BRAS resource pool.

Step 202, obtaining the service data corresponding to the equipment identifier of the second BRAS from the database server, wherein the service data is the service data backed up to the terminal equipment of the database server by the second BRAS.

When the second BRAS provides service for the terminal equipment, the service data of the terminal equipment can be generated, and the service data and the equipment identifier of the second BRAS are backed up to the database server. For example, the second BRAS may periodically back up service data and a device identification to the database server, or may back up new service data and a device identification to the database server each time new service data is generated.

Furthermore, since the database server stores the corresponding relationship between the service data and the device identifier of the second BRAS, after receiving the handover command, the first BRAS can resolve the device identifier of the second BRAS from the handover command, and obtain the service data corresponding to the device identifier from the database server.

In one example, the obtaining of the service data corresponding to the device identifier of the second BRAS from the database server may include, but is not limited to: and acquiring basic configuration (such as an authentication password, an IP address, a port number and the like) corresponding to the database server, and sending a query request carrying the equipment identifier to the database server according to the basic configuration. Then, a query response returned by the database server for the query request may be received, where the query response carries the service data corresponding to the device identifier and obtained by the database server.

In an example, after obtaining the service data corresponding to the device identifier from the database server, the first BRAS may further send an update request to the database server, where the update message may carry the device identifier of the first BRAS and the device identifier of the second BRAS; the update request is used for requesting the database server to update the device identification of the second BRAS corresponding to the service data to the device identification of the first BRAS.

After the first BRAS acquires the service data corresponding to the equipment identifier from the database server, the first BRAS can also send a notification message of the service data which is recovered to the controller, so that the controller can transfer the uplink message of the terminal equipment from the second BRAS to the first BRAS, and the service transfer is realized.

Step 203, performing service processing on the terminal device according to the service data.

The service processing performed on the terminal device according to the service data may include, but is not limited to: acquiring charging information (such as online time and user flow) of the terminal equipment from the service data, and performing charging processing on the terminal equipment according to the charging information; and/or acquiring address information (such as an IP address) of the terminal equipment from the service data, and issuing a route carrying the address information, wherein the route is used for enabling the gateway equipment to transfer the downlink message which aims at the terminal equipment from the second BRAS to the first BRAS, so that the service transfer is realized.

In an example, the first BRAS may further receive a first VSI (Virtual Switch Instance) and a first service configuration of the first BRAS, which are sent by the controller, and perform service processing on a terminal device corresponding to the first VSI according to the first service configuration; and/or the first BRAS can also receive a second VSI and a second service configuration of the second BRAS, which are sent by the controller, and the second VSI and the second service configuration are sent when the controller determines that the second BRAS meets the handover condition; then, the terminal device corresponding to the second VSI may be subjected to service processing according to the second service configuration.

In one example, after the first BRAS performs service processing on the terminal device, the first BRAS may further generate service data of the terminal device, and backup a correspondence between the generated service data and the device identifier of the first BRAS to the database server. For example, the first BRAS may periodically back up the correspondence between the service data and the device identifier of the first BRAS to the database server, or, each time new service data is generated, back up the correspondence between the new service data and the device identifier of the first BRAS to the database server.

Based on the technical scheme, when the second BRAS meets the switching condition, the service of the second BRAS can be migrated to the first BRAS. For example, the second BRAS may back up the service data to the database server, and the first BRAS may obtain the service data from the database server, and then perform service processing on the terminal device according to the service data.

Because the BRAS resource pool comprises a plurality of main BRAS, or comprises a plurality of main BRAS and a redundant BRAS, and the first BRAS can be the main BRAS or the redundant BRAS, the redundant BRAS does not need to be respectively and correspondingly deployed for each main BRAS, the redundant BRAS does not need to be deployed or the same redundant BRAS can be deployed for all the main BRAS, namely a large number of redundant BRAS do not need to be deployed, BRAS resources are saved, processing resources of each BRAS are fully utilized, the number of BRAS is reduced, and therefore a networking mode is more flexible, lower cost and lower energy consumption are achieved.

And moreover, tide migration can be flexibly realized, when the service is busy, a plurality of main BRASs can be started, part of the service of the main BRAS with higher service pressure can be migrated to a new main BRAS, when the service is idle, all the services can be concentrated to a plurality of main BRASs, the main BRASs take over the services of other BRASs, and the other BRASs can be powered off to save energy.

Based on the same concept as the method, an embodiment of the present application further provides a service processing system, including: the method comprises the steps that management equipment, a database server and a BRAS resource pool are adopted, wherein the BRAS resource pool comprises a plurality of BRASs, and when the management equipment determines that a second BRAS meets a handover condition, a first BRAS used for bearing the service of the second BRAS is selected from the BRAS resource pool; the management equipment sends a switching command to the first BRAS, and the switching command carries the equipment identifier of the second BRAS; the first BRAS performs the service processing method of the above embodiment.

The management device selects a first BRAS for carrying a service of a second BRAS from a BRAS resource pool, and may specifically include several embodiments due to different networking forms:

the first implementation mode comprises the following steps: if the BRAS resource pool comprises a plurality of BRAS which are mutually active and standby, the management equipment selects one BRAS from the BRAS as a first BRAS according to the load condition of each BRAS.

Specifically, when a second BRAS exists in the BRAS resource pool and meets the handover condition, the management device may select one BRAS from other BRASs currently operating in the resource pool as a first BRAS, where the first BRAS is a backup BRAS of the second BRAS. For example, the BRAS with the lightest current load may be selected as the backup BRAS for the second BRAS.

The service processing method will be described in detail below with reference to the application scenario shown in fig. 1.

Assuming that the BRAS141, the BRAS142 and the BRAS143 are primary BRASs, the handover condition is a BRAS failure or a load of the BRAS is lower than a preset value.

In one scenario, if the BRAS141 fails, the management device may determine that the BRAS141 meets the handover condition, and if it is determined that the service of the BRAS142 is idle at this time, the BRAS142 may be selected as the first BRAS, that is, the BRAS142 may be selected as the backup BRAS of the BRAS141, so that the service of the BRAS141 may be migrated to the BRAS142, that is, the service of the failed BRAS may be migrated.

In another scenario, if the service of the BRAS141 is idle and the service of the BRAS142 is also idle, that is, the loads of the BRAS141 and the BRAS142 are both lower than a preset value, at this time, the BRAS141 may be selected as the second BRAS and the BRAS142 may be selected as the first BRAS, so that the service of the BRAS141 may be migrated to the BRAS142, so that one BRAS can handle the services of two BRASs, and the resources of the BRAS are saved.

The second embodiment: if the BRAS resource pool comprises a plurality of main BRASs and a redundant BRAS, the management equipment selects the redundant BRAS as a first BRAS; wherein the first BRAS is a backup BRAS for the second BRAS.

Specifically, when a second BRAS exists in the BRAS resource pool and meets the handover condition, the management device may select a currently non-operating redundant BRAS as the first BRAS, that is, select the redundant BRAS as a backup BRAS of the second BRAS.

The service processing method described above will be described in detail with reference to the application scenario shown in fig. 1.

If the BRAS141 and the BRAS142 are primary BRASs and the BRAS143 is redundant BRAS, the handover condition is a BRAS failure.

In one scenario, if the BRAS141 fails, the management device may determine that the BRAS141 satisfies a handover condition, that is, the BRAS141 is a second BRAS, and at this time, a redundant BRAS, that is, the BRAS143 may be selected as a first BRAS, so that the service of the BRAS141 may be migrated to the BRAS143, that is, the service of the failed BRAS may be migrated.

Of course, the selection manners of the first BRAS and the second BRAS are only a few examples, which are not limited to this, and for convenience of description, the BRAS141 is taken as the first BRAS, and the BRAS142 is taken as the second BRAS.

In the application scenario, as shown in fig. 3, the service processing method may include:

in step 301, the controller 151 sends a basic configuration (which may also be referred to as a global configuration, and is a configuration that does not need to be migrated after a BRAS fails) to all BRASs, and sends a service configuration (which may also be referred to as an interface configuration, and is a configuration that needs to be migrated after a BRAS fails) to the primary BRAS.

For example, if the BRAS141 and the BRAS142 are both primary BRAS, the basic configuration a and the service configuration a may be sent to the BRAS141, and the basic configuration B and the service configuration B may be sent to the BRAS 142. Or, if the BRAS141 is a redundant BRAS and the BRAS142 is a primary BRAS, the basic configuration a may be sent to the BRAS141, but the service configuration is not sent, and the basic configuration B and the service configuration B may be sent to the BRAS 142.

Wherein, the basic configuration may include but is not limited to one or any combination of the following: an authentication password, an IP address, a port number of the database server 181, a device identifier of the BRAS, a DHCP (Dynamic Host Configuration Protocol) address pool, and the like. Of course, the basic configurations described above are only a few examples of the present application, and the basic configurations may also include other contents, and the contents of the basic configurations are not limited. The basic configuration of different BRAS may be different, for example, basic configuration a may include an authentication password of database server 181, an IP address, a port number, a device identification of BRAS141, a DHCP address pool a, and a DHCP address pool B; base configuration B may include an authentication password of database server 181, an IP address, a port number, a device identification of BRAS142, DHCP address pool a, and DHCP address pool B.

The service configuration may include, but is not limited to, one or any combination of the following: an access mode (for example, an IPoE (Internet Protocol over Ethernet) mode, a PPPoE (Point to Point Protocol over Ethernet) mode, or the like), an authentication mode, and indication information of a DHCP address pool (for indicating which DHCP address pool is used to allocate an address). Of course, the service configurations described above are only a few examples of the present application, and the service configurations may include other contents, and the contents of the service configurations are not limited. The service configurations of different BRAS may be the same or different.

In one example, where the service profile is VSI dependent, e.g., BRAS141 corresponds to two VSIs, then the controller may send to BRAS141 the service profile corresponding to the first VSI, the service profile corresponding to the second VSI, which may be the same or different. To distinguish between traffic configurations of different VSIs, controller 151 may send the VSI and the traffic configuration to BRAS141/BRAS142 so that BRAS141/BRAS142 may distinguish between traffic configurations of different VSIs. For example, the controller 151 sends the VSI1 and the traffic profile a to the BRAS141 and the VSI2 and the traffic profile B to the BRAS 142.

In the above embodiment, the controller 151 may send the basic configuration to all the BRAS through the Netconf protocol, and send the service configuration to the primary BRAS through the Netconf protocol, which is not limited to this sending manner.

And step 302, the main BRAS processes the service of the terminal equipment corresponding to the VSI according to the service configuration. For example, BRAS142 performs service processing on the terminal device corresponding to VSI2 according to service configuration B.

The BRAS141 and the gateway device 131 may establish a VXLAN tunnel a, and the BRAS141 may establish a correspondence between the VXLAN tunnel a and the VSI 1. In addition, a VXLAN tunnel B may be established between the BRAS142 and the gateway device 131, and the BRAS142 may establish a correspondence relationship between the VXLAN tunnel B and the VSI 2. For the establishment process of the VXLAN tunnel A, VXLAN, the establishment process of the tunnel B is not limited in this embodiment, and may be established in a static manner or in a dynamic manner.

The correspondence between the VXLAN tunnel a and the VSI1 may be notified to the BRAS141 by the controller, and the correspondence between the VXLAN tunnel B and the VSI2 may be notified to the BRAS142 by the controller.

Further, after receiving the uplink message (such as a DHCP request message or an authentication request message) sent by the terminal device 111, the gateway device 131 may query a VXLAN tunnel corresponding to the VLAN of the uplink message, and if the VXLAN tunnel B is queried, may send the uplink message to the BRAS142 through the VXLAN tunnel B. After receiving the uplink message through the VXLAN tunnel B, the BRAS142 queries the VSI2 corresponding to the VXLAN tunnel B, and queries the service configuration B corresponding to the VSI 2.

Then, BRAS142 may perform service processing on terminal device 111 according to service configuration B.

For example, if the uplink message is a DHCP request message, BRAS142 may perform address assignment on terminal device 111 according to service configuration B. Specifically, BRAS142 parses information of the DHCP address pool from service configuration B, selects an available IP address from the DHCP address pool, allocates the IP address to terminal device 111, and then may send a DHCP response packet to terminal device through gateway device 131, where the DHCP response packet may carry the IP address, and the address allocation process is not limited. If the uplink message is an authentication request message, BRAS142 may perform authentication processing on terminal device 111 according to service configuration B. Specifically, the BRAS142 parses the access mode and the authentication mode from the service configuration B, and authenticates the terminal device 111 by using the access mode and the authentication mode, which is not limited to this authentication process.

Of course, the above-mentioned modes are only two examples of the BRAS142 performing service processing on the terminal device 111 according to the service configuration B, and there are other modes for service processing, for example, the BRAS142 may perform user control management, user access control, user authentication authorization charging, address management, configuration management, and the like according to the service configuration B.

In step 303, after the BRAS142 generates the service data of the terminal device 111, the corresponding relationship between the service data and the device identifier of the BRAS142 may be backed up to the database server 181.

In step 304, the database server 181 stores the correspondence between the service data and the device identifier.

In an example, after the BRAS142 performs service processing on the terminal device 111, service data of the terminal device 111, such as service data B, may be obtained, then, the BRAS142 may backup a correspondence between the service data B and the device identifier of the BRAS142 to the database server 181, and after the database server 181 receives the correspondence, store the correspondence between the service data B and the device identifier, as shown in table 1.

TABLE 1

Device identification	Service data
		Equipment identification of BRAS142	Service data B

In one example, the service data B of the terminal device 111 includes, but is not limited to, one or any combination of the following: IP address, Media Access Control (MAC) address, Virtual Local Area Network (VLAN) information, Virtual Private Network (VPN) information, VXLAN identifier, authorization information (such as QoS policy, speed limit policy, statistical policy, and ACL policy), user traffic, and online time.

In step 305, when the controller 151 determines that the BRAS142 meets the handover condition, the controller 151 sends the VSI2 and the service configuration B corresponding to the BRAS142 to the BRAS141, but does not send the basic configuration B, and sends a handover command to the BRAS141, where the handover command carries the device identifier of the BRAS 142.

In one example, the controller 151 may periodically send heartbeat messages to the BRAS142, and after sending a preset number (e.g., 10) of heartbeat messages, if no response message of the BRAS142 to the heartbeat message is received, determine that the BRAS142 has a fault, and determine that the BRAS142 meets the handover condition.

In another example, the controller 151 may monitor the load of the BRAS142 and the BRAS141, and if the load of the BRAS142 is light and the load of the BRAS141 is also light, determine that the BRAS142 may be released, that is, the traffic of the BRAS142 is migrated to the BRAS141, and determine that the BRAS142 satisfies the handover condition.

Of course, the foregoing is only an example that the BRAS142 satisfies the handover condition, and the handover condition is not limited.

When the BRAS142 meets the handover condition, the controller 151 may select a target BRAS for carrying traffic of the BRAS142 from within the BRAS resource pool, such as determining the target BRAS to be BRAS 141.

For example, if the BRAS resource pool includes redundant BRAS, the redundant BRAS is determined as the target BRAS, or one BRAS is selected from the BRAS resource pool according to the load condition of each primary BRAS, and the selected BRAS is determined as the target BRAS, for example, the BRAS with lighter load is determined as the target BRAS.

Controller 151 may then send VSI2 and traffic profile B corresponding to BRAS142 to BRAS141 and send a handover command to BRAS141, the handover command carrying the device identity of BRAS 142.

The controller 151 may maintain the device identifier, the service configuration, the basic configuration, the VSI, and other contents of all the BRAS, and therefore, when the BRAS142 meets the handover condition, the controller 151 may locally query the device identifier, the service configuration B, VSI2, and other information of the BRAS142, send the VSI2 and the service configuration B to the BRAS141, and send a handover command carrying the device identifier of the BRAS142 to the BRAS 141.

In step 306, BRAS141 receives VSI2 and service configuration B corresponding to BRAS142 sent by controller 151, and receives a handover command (carrying the device identifier of BRAS 142) sent by controller 151.

In step 307, the BRAS141 obtains the service data B corresponding to the equipment identifier of the BRAS142 from the database server 181. Referring to table 1, the database server 181 stores the correspondence between the device identifier of the BRAS142 and the service data B, and the BRAS141 can obtain the service data B from the database server 181.

In step 308, the BRAS141 sends a notification message that the recovery of the service data is completed to the controller 151, so that the controller 151 migrates the uplink message of the terminal equipment from the BRAS142 to the BRAS 141.

Before all the service data is acquired, the data recovery completion flag is set as the second identifier, and after all the service data of the BRAS142 is acquired from the database server 181 by the BRAS141 (for example, the BRAS142 may back up a large amount of service data to the database server 181, and the BRAS141 may acquire all the service data of the BRAS142 from the database server 181), the data recovery completion flag is set as the first identifier.

Further, after the controller 151 sends the handover command to the BRAS141, the controller 151 may periodically send an inquiry command to the BRAS141, after the BRAS141 receives the inquiry command, if the data recovery completion flag is the second flag, the BRAS141 sends the communication message of the service data that is not recovered to the controller 151, in this way, the controller 151 continues to send the inquiry command to the BRAS141 in the next period, if the data recovery completion flag is the first flag, the BRAS141 sends the notification message of the service data that has been recovered to the controller 151, in this way, the controller 151 knows that the service data has been recovered, stops sending the inquiry command, and migrates the uplink message of the terminal device from the BRAS142 to the BRAS 141.

In one example, in order to migrate the uplink message of the terminal device from the BRAS142 to the BRAS141, the following method may be adopted: the controller 151 modifies a destination address (such as an IP address, a MAC address, etc., and subsequently takes the IP address as an example) of the VXLAN tunnel B of the gateway device 131 to an address (such as an IP address, a MAC address, etc.) of the BRAS141, thereby migrating the upstream packet destined for the BRAS142 to the BRAS 141.

As described in the above embodiments, the gateway device 131 may establish VXLAN tunnel a with the BRAS141, and the gateway device 131 may establish VXLAN tunnel B with the BRAS 142. Based on this, if the controller 151 modifies the destination IP address of the VXLAN tunnel B of the gateway device 131 to the IP address of the BRAS141, when the gateway device 131 sends the uplink message (i.e., the message sent by the terminal device) through the VXLAN tunnel B, the uplink message is sent to the BRAS141 instead of the BRAS142, so that the uplink message destined for the BRAS142 is migrated to the BRAS141, that is, service migration is implemented.

Further, the controller 151 may also notify the BRAS141 to establish the VXLAN tunnel B with the gateway device 131, and record the corresponding relationship between the VXLAN tunnel B and the VSI 2.

For example, when the gateway device 131 receives an uplink message (such as an uplink data message) sent by an online terminal device, and the terminal device is online on the BRAS142, such as the terminal device 111, the gateway device 131 needs to send the uplink message through the VXLAN tunnel B, and since the destination IP address of the VXLAN tunnel B is the IP address of the BRAS141 (and is no longer the IP address of the BRAS 142), the gateway device 131 sends the uplink message to the BRAS141 through the VXLAN tunnel B.

For another example, after receiving an uplink message (such as an uplink DHCP request message or an uplink authentication request message) sent by a terminal device to be on-line, the gateway device 131 may query a VXLAN tunnel corresponding to a VLAN of the uplink message, and assuming that the VXLAN tunnel B is queried, since a destination IP address of the VXLAN tunnel B is an IP address of the BRAS141 (and is no longer an IP address of the BRAS 142), the gateway device 131 sends the uplink message to the BRAS141 through the VXLAN tunnel B.

In step 309, the BRAS141 performs service processing on the terminal device according to the service data B, and the BRAS141 performs service processing on the terminal device corresponding to the VSI2 according to the service configuration B of the BRAS 142.

In an example, for a terminal device on the BRAS142, such as the terminal device 111 described above, after acquiring the service data B of the terminal device 111, the BRAS141 may perform service processing on the terminal device 111 according to the service data B, and the service processing procedure is described below with reference to a specific example:

in the first case, the BRAS141 obtains the charging information (such as online time and user traffic) of the terminal device 111 from the service data B, and performs charging processing on the terminal device 111 according to the charging information.

Specifically, since the service data B may include charging information such as user traffic, online time, and the like, BRAS141 may obtain the user traffic and the online time of terminal device 111 from the service data B, and continuously count the user traffic and the online time of terminal device 111 on the basis of the user traffic and the online time, thereby charging terminal device 111 based on the user traffic and the online time.

In the second case, the BRAS141 may obtain the contents of the IP address, the MAC address, the VLAN information, the VPN information, the VXLAN identifier, and the like of the terminal device 111 from the service data B, and may generate a forwarding table entry by using the contents of the IP address, the MAC address, the VLAN information, the VPN information, the VXLAN identifier, and the like, and instruct the BRAS141 to forward the message through the forwarding table entry, which is not limited in the forwarding process.

In the third case, the BRAS141 can obtain the QoS policy of the terminal device 111 from the service data B, and guide the BRAS141 to implement QoS control on the terminal device 111 through the QoS policy; acquiring a speed limit strategy of the terminal equipment 111 from the service data B, and guiding the BRAS141 to realize CAR on the terminal equipment 111 through the speed limit strategy; acquiring a statistical strategy of the terminal equipment 111 from the service data B, and guiding the BRAS141 to realize traffic statistics on the terminal equipment 111 through the statistical strategy; and obtaining the ACL strategy of the terminal equipment 111 from the service data B, and guiding the BRAS141 to realize ACL control on the terminal equipment 111 through the ACL strategy.

And in the fourth case, the BRAS141 acquires address information (such as an IP address) of the terminal device 111 from the service data B, and publishes a route carrying the IP address, where the route is used for enabling the gateway device 131 to migrate the downlink message, which is destined for the terminal device 111, from the BRAS142 to the BRAS141, thereby implementing service migration.

In order to migrate the downlink message destined to the terminal device 111 from the BRAS142 to the BRAS141, the following method may be adopted: the BRAS141 issues a route carrying the IP address of the terminal device 111 to the gateway device 131, and after receiving the route, the gateway device 131 learns an outgoing interface corresponding to the IP address of the terminal device 111 to the BRAS141, so that a downlink message destined for the terminal device 111 is migrated to the BRAS 141.

For example, assume that the IP address of the terminal device 111 is the IP address 111, the interface where the gateway device 131 connects to the BRAS141 is 1311, and the interface where the gateway device 131 connects to the BRAS142 is 1312. When the BRAS142 provides service for the terminal device 111, the route carrying the IP address 111 may be issued to the gateway device 131, and the gateway device 131 may generate a route entry shown in table 2. When the downlink message of the terminal device 111 is migrated from the BRAS142 to the BRAS141, the BRAS141 may obtain the IP address 111 of the terminal device 111 from the service data B, and issue a route carrying the IP address 111 to the gateway device 131, after receiving the route, the gateway device 131 determines that the outgoing interface corresponding to the IP address 111 migrates from 1312 to 1311, and modifies the routing table entry shown in table 2 to table 3.

TABLE 2

Destination IP address	Outlet interface
		IP address
111	1312

TABLE 3

Destination IP address	Outlet interface
		IP address
111	1311

Further, as shown in table 3, when receiving a downlink packet (such as a downlink packet, which may be a data packet sent to the terminal device 111 by the internet) whose destination IP address is the IP address 111, the gateway device 131 may send the downlink packet to the BRAS141 through the outgoing interface 1311, so that the downlink packet destined to the terminal device 111 is migrated to the BRAS141, thereby implementing service migration. After receiving the downlink message, BRAS141 may also send the downlink message to terminal device 111, and the sending process is not limited.

Of course, the foregoing situations are only examples in which the BRAS141 performs service processing on the terminal device 111 according to the service data B, and the service processing procedure is not limited and may be implemented according to actual situations.

In an example, BRAS141 performs service processing on terminal equipment corresponding to VSI2 according to service configuration B of BRAS142, and may further include: for a terminal device to be on-line, such as the terminal device 112, after receiving an uplink message (such as a DHCP request message or an authentication request message) sent by the terminal device 112, the gateway device 131 may query a VXLAN tunnel corresponding to a VLAN of the uplink message, and if a VXLAN tunnel B is queried, may send the uplink message to the BRAS141 through the VXLAN tunnel B.

Further, after receiving the uplink message through the VXLAN tunnel B, the BRAS141 may query the VSI2 corresponding to the VXLAN tunnel B and query the service configuration B corresponding to the VSI 2.

If the uplink message is a DHCP request message, BRAS141 may perform address assignment on terminal device 112 according to service configuration B. For example, BRAS141 may parse the information of the DHCP address pool from service configuration B, select an available IP address from the DHCP address pool, and allocate the IP address to terminal device 112, which is not limited to this address allocation process. If the uplink message is an authentication request message, BRAS141 may perform authentication processing on terminal device 112 according to service configuration B. For example, the BRAS141 may parse out an access mode and an authentication method from the service configuration B, and authenticate the terminal device 112 using the access mode and the authentication method, which is not limited to this authentication process.

In an example, the BRAS141 may further perform service processing on the terminal device corresponding to the VSI1 according to the service configuration a of the BRAS141, specifically, for the terminal device to be on-line, after receiving the uplink message sent by the terminal device, the gateway device 131 may query a VXLAN tunnel corresponding to a VLAN of the uplink message, and if the VXLAN tunnel a is queried, may send the uplink message to the BRAS141 through the VXLAN tunnel a. After receiving the uplink message through VXLAN tunnel a, BRAS141 queries VSI1 corresponding to VXLAN tunnel a and queries service configuration a corresponding to VSI 1. Then, BRAS141 may perform service processing on the terminal device according to service configuration a, such as address assignment, authentication processing, and the like on the terminal device.

In step 310, after the BRAS141 performs service processing on the terminal device, the BRAS141 may generate service data of the terminal device, and backup a corresponding relationship between the service data and the device identifier of the BRAS141 to the database server 181. The database server 181 stores the correspondence between the service data and the device identifier.

Step 310 may refer to step 303 and step 304, and will not be described herein repeatedly.

In the above embodiment, each BRAS may include a database module (also referred to as a database process, such as a RedisDBM process running on the BRAS independently) and at least one service module (also referred to as a service process, such as an IPoE process, a PPPoE process, a DHCP process running on the BRAS independently, where the IPoE process is used to implement authentication of an IPoE access manner, the PPPoE process is used to implement authentication of a PPPoE access manner, and the DHCP process is used to implement address assignment).

The database module of the BRAS may establish a long connection with the database server 181 (for example, the database module may obtain basic configurations such as an authentication password, an IP address, and a port number of the database server 181, and establish a long connection with the database server 181 according to the basic configurations), and the service module of the BRAS may establish a connection with the database module. Based on this, the service module may generate the service data, and may write the service data into the database server 181 (as in the writing process of step 303 and step 304, and step 310 described above), and this embodiment does not limit the process of generating the service data by the service module.

Specifically, the service module may send the service data to the database module, and the database module may obtain the device identifier after receiving the service data, and store the service data and the device identifier in the database server 181 through the long connection. When the service data needs to be read from the database server 181 (as in

step

306 and 307, the service data is read after the handover command is received), the database module may read the service data from the database server 181 through the long connection and send the service data to the service module.

In the application scenario, for the step 307, the BRAS141 obtains the service data B from the database server 181, and an implementation flow thereof may be as shown in fig. 4, where the flow may include:

in step 401, after receiving a handover command (which may also be referred to as a data recovery start message) sent by the controller, the database module of the BRAS141 notifies each service module to start data recovery, that is, notifies the service module to prepare for recovering service data, and obtains the device identifier of the BRAS142 from the handover command.

Step 402, the database module sends a query request to the database server 181, where the query request carries the device identifier of the BRAS142, for example, the database module sends the query request through the long connection.

In step 403, after receiving the query request, the database server 181 parses the device identifier of the BRAS142 from the query request, and queries the service data B corresponding to the device identifier.

In step 404, the database server 181 returns a query response carrying the service data B to the BRAS 141.

In step 405, the database module receives the query response and obtains the service data B from the query response.

Step 406, the database module pushes the service data B to each service module.

The database module may obtain a plurality of service data from the database server 181, and each time one service data is obtained, the database module may push the service data to each service module.

After receiving the service data B, the service module may also reorganize the service data B. For example, if the service data B stored in the database server 181 is in the first format and the service data B required by the service module is in the second format, the service module may convert the received service data B into the second format, which is only an example of reorganizing the service data B, and the reorganizing manner is not limited.

Step 407, after the service data is pushed, the database module sends a data pushing completion message to the service module, where the data pushing completion message indicates that all the service data of the BRAS142 has been pushed.

Step 408, after receiving the service data B, the database module sends an update request to the database server 181, where the update request carries the device identifier of the BRAS141 and the device identifier of the BRAS 142.

In step 409, after receiving the update request, the database server 181 updates the device identifier corresponding to the service data B from the device identifier of the BRAS142 to the device identifier of the BRAS141 according to the update request.

Step 410, after receiving the data pushing completion message, the service module sends a data receiving completion message to the database module, where the data receiving completion message indicates that the service module has received and processed all the service data.

In step 411, the database module detects whether data reception completion messages of all the service modules are received.

If yes, it means that all service modules have received all service data, step 412 may be executed, and if no, it means that all service modules have not received all service data, and may continue to wait.

In step 412, the database module sends a synchronization completion message to all the service modules, which indicates that the data reception completion message of all the service modules has been received, and all the service modules have received all the service data.

In step 413, after receiving the synchronization completion message, the service module performs data smoothing operation of the service module.

Step 414, after the data smoothing is finished, the service module sends a smoothing completion message to the database module.

Step 415, after receiving the smoothing completion messages of all the service modules, the database module sends service processing messages to each service module, so that each service module performs service processing according to the service data.

In step 416, the database module sends a notification message that the recovery of the service data is completed to the controller 151, so that the controller 151 migrates the uplink message of the terminal equipment from the BRAS142 to the BRAS 141.

Based on the same application concept as the method, an embodiment of the present application further provides a service processing apparatus, applied to a first BRAS, as shown in fig. 5, which is a structural diagram of the apparatus, and the apparatus includes:

a receiving module 501, configured to receive a handover command sent by a management device, where the handover command carries a device identifier of a second BRAS, and the handover command is sent when the management device determines that the second BRAS meets a handover condition;

an obtaining module 502, configured to obtain, from a database server, service data corresponding to the device identifier, where the service data is service data of a terminal device that is backed up to the database server by the second BRAS;

a processing module 503, configured to perform service processing on the terminal device according to the service data.

The obtaining module 502 is specifically configured to, when obtaining the service data corresponding to the device identifier from the database server: acquiring a basic configuration corresponding to the database server;

sending a query request carrying the equipment identifier to a database server according to the basic configuration;

and receiving a query response returned by the database server aiming at the query request, wherein the query response carries the service data which is obtained by the database server and corresponds to the equipment identifier.

In one example, the apparatus further comprises (not shown in fig. 5):

a sending module, configured to send an update request to a database server after the obtaining module obtains service data corresponding to the device identifier from the database server, where the update request carries the device identifier of the first BRAS and the device identifier of the second BRAS;

the update request is used for requesting the database server to update the device identifier of the second BRAS corresponding to the service data to the device identifier of the first BRAS.

And the sending module is used for sending a notification message of the completion of the recovery of the service data to the management equipment after the acquisition module acquires the service data corresponding to the equipment identifier from the database server, so that the management equipment can transfer the uplink message of the terminal equipment from the second BRAS to the first BRAS.

The processing module 503 is specifically configured to, when performing service processing on the terminal device according to the service data: acquiring charging information of the terminal equipment from the service data, and performing charging processing on the terminal equipment according to the charging information; and/or acquiring address information of the terminal equipment from the service data, and issuing a route carrying the address information, wherein the route is used for enabling the gateway equipment to transfer the downlink message which aims at the terminal equipment from the second BRAS to the first BRAS.

In one example, the apparatus further comprises (not shown in fig. 5):

and the generating module is used for generating service data of the terminal equipment after the processing module performs service processing on the terminal equipment, and backing up the corresponding relation between the generated service data and the equipment identifier of the first BRAS to the database server.

For the BRAS provided in the embodiment of the present application (e.g. the first BRAS mentioned above), from a hardware level, a schematic diagram of a hardware architecture of the BRAS may be seen in fig. 6. The method comprises the following steps: a machine-readable storage medium and a processor, wherein:

a machine-readable storage medium: the instruction code is stored.

A processor: the instruction codes stored in the machine readable storage medium are read and executed by communicating with the machine readable storage medium, so as to realize the business processing operation disclosed by the above example of the application.

Specifically, a handover command sent by a management device may be received, where the handover command carries a device identifier of a second BRAS, and the handover command is sent when the management device determines that the second BRAS meets a handover condition; acquiring service data corresponding to the equipment identifier from a database server, wherein the service data is the service data backed up to the terminal equipment of the database server by the second BRAS; and carrying out service processing on the terminal equipment according to the service data.

Here, a machine-readable storage medium may be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and so forth. For example, the machine-readable storage medium may be: a RAM (random Access Memory), a volatile Memory, a non-volatile Memory, a flash Memory, a storage drive (e.g., a hard drive), a solid state drive, any type of storage disk (e.g., an optical disk, a dvd, etc.), or similar storage medium, or a combination thereof.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functionality of the units may be implemented in one or more software and/or hardware when implementing the present application.

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

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams 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.

Furthermore, 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.

The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A service processing method, which is applied to a first BRAS in a BRAS resource pool, where the BRAS resource pool includes multiple BRASs, the method comprising:

acquiring service data corresponding to the equipment identifier from a database server, wherein the service data is the service data backed up to the terminal equipment of the database server by the second BRAS; the service data is generated when the second BRAS provides service for the terminal equipment;

2. The method of claim 1,

the method comprises the steps that a BRAS resource pool comprises a plurality of BRASs which are mutually active and standby, and the first BRAS is any BRAS which meets a preset condition in the plurality of BRASs which are mutually active and standby; alternatively, the first and second electrodes may be,

the BRAS resource pool comprises a plurality of primary BRAS and a redundant BRAS, wherein the first BRAS is the redundant BRAS.

3. The method of claim 1,

the obtaining of the service data corresponding to the device identifier from the database server includes:

acquiring a basic configuration corresponding to the database server;

4. The method of claim 1, wherein after the obtaining the service data corresponding to the device identifier from the database server, the method further comprises:

sending an update request to the database server, wherein the update request carries the equipment identifier of the first BRAS and the equipment identifier of the second BRAS;

5. The method of claim 1, wherein after the obtaining the service data corresponding to the device identifier from the database server, the method further comprises:

and sending the notification message of the completion of the recovery of the service data to a management device so that the management device transfers the uplink message of the terminal device from the second BRAS to the first BRAS.

6. The method of claim 1,

the performing service processing on the terminal device according to the service data includes:

acquiring charging information of the terminal equipment from the service data, and performing charging processing on the terminal equipment according to the charging information; and/or acquiring address information of the terminal equipment from the service data, and issuing a route carrying the address information, wherein the route is used for enabling the gateway equipment to transfer the downlink message which aims at the terminal equipment from the second BRAS to the first BRAS.

7. The method according to any one of claims 1-6, further comprising:

and after the service processing is carried out on the terminal equipment, generating service data of the terminal equipment, and backing up the corresponding relation between the generated service data and the equipment identifier of the first BRAS to the database server.

8. A transaction system, the system comprising: the system comprises a management device, a database server and a BRAS resource pool, wherein the BRAS resource pool comprises a plurality of BRASs, and the method comprises the following steps:

the management equipment sends a switching command to the first BRAS, wherein the switching command carries the equipment identification of the second BRAS;

the first BRAS is configured to perform the method of any of claims 1-6.

9. The system according to claim 8, wherein said selecting a first BRAS from within the BRAS resource pool for carrying traffic of the second BRAS specifically comprises:

if the BRAS resource pool comprises a plurality of BRAS which are mutually active and standby, the management equipment selects one BRAS from the BRAS as a first BRAS according to the load condition of each BRAS;

if the BRAS resource pool comprises a plurality of primary BRASs and a redundant BRAS, the management equipment selects the redundant BRAS as a first BRAS;

wherein the first BRAS is a backup BRAS for a second BRAS.

10. A service processing apparatus, applied to a first BRAS in a BRAS resource pool, where the BRAS resource pool includes a plurality of BRASs, the apparatus comprising:

an obtaining module, configured to obtain, from a database server, service data corresponding to the device identifier, where the service data is service data backed up by the second BRAS to a terminal device of the database server; the service data is generated when the second BRAS provides service for the terminal equipment;

11. The apparatus according to claim 10, wherein the obtaining module, when obtaining the service data corresponding to the device identifier from a database server, is specifically configured to:

acquiring a basic configuration corresponding to the database server;

12. The apparatus of claim 10, further comprising:

13. The apparatus of claim 10, further comprising:

14. The apparatus of claim 10,

the processing module is specifically configured to, when performing service processing on the terminal device according to the service data: acquiring charging information of the terminal equipment from the service data, and performing charging processing on the terminal equipment according to the charging information; and/or acquiring address information of the terminal equipment from the service data, and issuing a route carrying the address information, wherein the route is used for enabling the gateway equipment to transfer the downlink message which aims at the terminal equipment from the second BRAS to the first BRAS.

15. The apparatus of any one of claims 10-14, further comprising: