CN109474522B

CN109474522B - Service routing method, device and storage medium

Info

Publication number: CN109474522B
Application number: CN201710799280.0A
Authority: CN
Inventors: 张书兵; 孙艳; 黄泽旭; 尤光瑞; 徐日东
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2017-09-07
Filing date: 2017-09-07
Publication date: 2021-02-23
Anticipated expiration: 2037-09-07
Also published as: CN109474522A; WO2019047821A1

Abstract

The application discloses a method, a device and a storage medium for service routing, and belongs to the technical field of communication. The method is applied to a VNF, wherein the VNF comprises different non-upgraded and upgraded subsystem modules with the same function, and the method comprises the following steps: when a service request from a user is received, determining whether the user is a gray-scale user, and if the user is determined to be the gray-scale user, routing the service requested by the service request to the upgraded subsystem module in the VNF. Therefore, the VNF determines the gray-scale user when receiving the service request from the user, and gray-scale verification of the upgraded subsystem module is realized.

Description

Service routing method, device and storage medium

Technical Field

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

Background

In recent years, with the rapid development of communication technology, Network Function Virtualization (NFV) technology has been widely applied in the field of telecommunications. The NFV technology is to use a general hardware platform to carry software, and implement various telecommunication network functions, for example, a call session function, etc., through the software, so as to avoid the dependence of the telecommunication network functions on dedicated physical devices (e.g., chassis, rack, dedicated server).

The system framework of NFV mainly includes NFV MANagement and Orchestration (MANO), multiple Virtual Network Functions (VNF), multiple Element MANagement (EM), and the like, where the NFV-MANO includes NFV Orchestrator (NFV organizer, NFVO) and VNF Manager (VNF Manager, VNFM). The NFVO, VNFM and EM may all be used to manage VNF. Each VNF may be configured to implement a network Function of a network element in a communication network, for example, the network element may be a Call Session Control Function (CSCF), a Home Subscriber Server (HSS), or the like, and in practical applications, a plurality of VNFs with different network functions are usually required to cooperate with each other to implement a network service.

In an actual application scenario, due to business requirements and other reasons, the VNF generally needs to be upgraded, and in order to ensure the stability of the system, the VNF generally may be upgraded in a grayscale upgrading manner. The gray scale upgrade refers to performing gray scale verification while upgrading, that is, upgrading a part of the cells in each VNF or a part of the VNFs in a plurality of VNFs having the same network function, and then performing gray scale verification, and when the gray scale verification passes, continuing to perform the part of the upgrade and the gray scale verification. The gray scale verification refers to that the services of a part of users are migrated to the upgraded VNF according to a certain strategy, the part of users are called gray scale users, so that the upgraded VNF is subjected to gray scale verification through the gray scale users, and when the service operation condition of the upgraded VNF is determined to meet the expected requirement, the gray scale verification is determined to be passed. When a plurality of different VNFs perform service processing in cooperation with each other, how to implement grayscale verification becomes an urgent problem to be solved.

Disclosure of Invention

The application provides a service routing method, a service routing device and a storage medium, which are used for solving the problem of how to perform gray level verification in the prior art. The technical scheme is as follows:

in a first aspect, a traffic routing method is provided, and is applied in a VNF, where the VNF includes different subsystem modules with the same function that are not upgraded and that have been upgraded, and the method includes:

when a service request from a user is received, determining whether the user is a gray level user;

and if the user is determined to be the gray-scale user, routing the service requested by the service request to the upgraded subsystem module in the VNF.

In the embodiment of the present invention, in order to determine which users need to select to use the upgraded subsystem modules in the VNF, when a service request is received from a user, the VNF needs to determine whether the user is a grayscale user. In practical implementation, the VNF may determine whether the user is a grayscale user according to a grayscale policy description file issued by a grayscale policy control center.

The front-end network element VNF determines the gray-scale user when receiving the service request from the user, and gray-scale verification of the upgraded subsystem module is realized.

Optionally, before the determining whether the user is a grayscale user, the method further includes:

receiving a gray strategy description file issued by a gray strategy control center, wherein the gray strategy description file comprises gray percentage;

accordingly, the determining whether the user is a grayscale user includes:

and determining whether the user is a gray user according to the gray percentage.

That is, in a specific implementation, in order to determine which users need to be determined as grayscale users by the VNF, a grayscale policy description file is generally issued to the VNF in advance by a grayscale policy control center, so as to inform the VNF of the determined grayscale policy through the grayscale policy description file. In one possible implementation, if the grayscale policy profile includes a grayscale percentage, the VNF determines whether the user is a grayscale user according to the grayscale percentage.

In this way, the grayscale policy control center issues a grayscale policy description file to the VNF in advance to notify the determined grayscale policy of the VNF through the grayscale policy description file, and when the grayscale policy description file includes a grayscale percentage, the VNF can determine whether the user is a grayscale user according to the grayscale percentage.

Optionally, the determining whether the user is a grayscale user according to the grayscale percentage includes:

according to the gray scale percentage, selecting the ith user from every preset number of users, wherein i is an integer greater than 1;

determining the selected user as the grayscale user.

That is, in a specific implementation, the VNF may determine, as a grayscale user, an ith user of every preset number of online users, so as to determine whether the user is a grayscale user according to the grayscale percentage.

Optionally, after determining whether the user is a grayscale user, the method further includes:

when the user is determined to be the gray-scale user, adding a gray-scale identifier in the service request;

sending the service request to a next VNF, wherein the service request is used for instructing the next VNF to determine the user as the gray-scale user.

In a practical application scenario, interaction between multiple VNFs is usually required to enable network communication. Here, in order to notify that the next VNF is determined to be a gray-scale user, the VNF may add a gray-scale identifier to the service request before sending the service request to the next VNF, and send the service request to the next VNF to instruct the next VNF to determine the user as the gray-scale user. Thus, the problem that different VNFs can cooperate in gray scale verification when communication is performed across the different VNFs is solved.

Optionally, after sending the service request to the next VNF, the method further includes:

when the next VNF is an unequipped VNF and there is an upgraded VNF having the same function, the next VNF re-routes traffic requested by the user's registration request from the unequipped VNF to the upgraded VNF.

In this way, the next VNF routes the same user traffic to the upgraded VNF, thereby implementing the grayscale verification of the upgraded VNF.

when the next VNF includes different subsystem modules that are not upgraded and have the same function, the next VNF routes the service requested by the service request to the upgraded subsystem module in the next VNF.

Therefore, each VNF routes the same user service to the upgraded subsystem module, and the collaborative gray scale verification among the VNFs is achieved.

receiving a gray strategy description file issued by a gray strategy control center, wherein the gray strategy description file comprises a user range belonging to a gray user; accordingly, the determining whether the user is a grayscale user includes:

determining whether the user is the grayscale user based on the user range.

In this implementation, the grayscale policy control center has directly specified which users belong to grayscale users. In a specific implementation, when the VNF receives a service request from a user, it is determined whether the user is a grayscale user according to a user range included in the grayscale policy description file. For example, the service request may carry user identity information of the user, for example, the user identity information may include a phone number used by the user or location information of the user currently located. Then, the VNF queries whether the user identity information belongs to the user range, and if so, determines that the user is a grayscale user. Thus, the problem that different VNFs can cooperate in gray scale verification when communication is performed across the different VNFs is solved.

Optionally, the user range includes a location range, a number segment, or a number list.

The location range refers to a range of locations where the user is located, for example, the location range may be a city a; the number segment is used to indicate that a certain digit or digits in the telephone number used by the user meet a certain rule, for example, the number segment may indicate that the fourth digit to the seventh digit of the telephone number are in the range of 0100 to 0112, and for example, the number segment may also indicate that the last digit of the telephone number is an even number, etc.; the number list may be used to store telephone numbers of users belonging to greyscale users.

Therefore, the gray scale policy control center can directly specify and inform the VNFs which users are gray scale users through the position range, the number segment or the number list, so that each VNF cooperatively realizes gray scale verification.

In a second aspect, an apparatus for traffic routing configured in a VNF, the VNF including different subsystem modules with the same functionality that are not upgraded and that have been upgraded, the apparatus comprising:

the system comprises a determining module, a judging module and a judging module, wherein the determining module is used for determining whether a user is a gray user when receiving a service request from the user;

and the routing module is used for routing the service requested by the service request to the upgraded subsystem module in the VNF when the user is determined to be the gray-scale user.

Optionally, the apparatus further comprises:

the first receiving module is used for receiving a gray strategy description file issued by a gray strategy control center, wherein the gray strategy description file comprises gray percentage;

accordingly, the determining module is further configured to:

Optionally, the determining module is configured to:

determining the selected user as the grayscale user.

Optionally, the apparatus further comprises:

the adding module is used for adding a gray mark in the service request when the user is determined to be the gray user;

a sending module, configured to send the service request to a next VNF, where the service request is used to instruct the next VNF to determine the user as the grayscale user.

Optionally, when the next VNF is an unequipped VNF and there is an upgraded VNF having the same function, the next VNF re-routes traffic requested by the user's registration request from the unequipped VNF to the upgraded VNF.

Optionally, after sending the service request to the next VNF, when the next VNF includes different subsystem modules that are not upgraded and have the same function, the next VNF routes the service requested by the service request to the upgraded subsystem module in the next VNF.

Optionally, the apparatus further comprises:

the second receiving module is used for receiving a gray strategy description file issued by a gray strategy control center, wherein the gray strategy description file comprises a user range belonging to a gray user;

accordingly, the determining module is further configured to:

determining whether the user is the grayscale user based on the user range.

In a third aspect, a service routing apparatus is provided, where the structure of the service routing apparatus includes a processor and a memory, where the memory is used to store a program that supports the service routing apparatus to execute the service routing method provided in the first aspect, and store data used to implement the service routing method provided in the first aspect. The processor is configured to execute programs stored in the memory. The operating means of the memory device may further comprise a communication bus for establishing a connection between the processor and the memory.

In a fourth aspect, a computer-readable storage medium is provided, which has instructions stored therein, and when the instructions are executed on a computer, the instructions cause the computer to execute the traffic routing method according to the first aspect.

In a fifth aspect, there is provided a computer program product containing instructions which, when run on a computer, cause the computer to perform the traffic routing method of the first aspect.

The technical effects obtained by the above second, third, fourth and fifth aspects are similar to the technical effects obtained by the corresponding technical means in the first aspect, and are not described herein again.

The beneficial effect that technical scheme that this application provided brought is: the service routing method provided by the embodiment of the invention is applied to the VNF, and the VNF comprises different subsystem modules which are not upgraded and are upgraded and have the same function. When a service request is received from a user, the VNF determines whether the user is a grayscale user in order to determine whether to choose to route the user's service to an upgraded subsystem module in the VNF. If the user is a grayscale user, the user's traffic is routed to the upgraded subsystem module in the VNF. Therefore, the VNF determines the gray-scale user when receiving the service request from the user, and gray-scale verification of the upgraded subsystem module is realized.

Drawings

FIG. 1 is a schematic diagram illustrating an NFV system architecture in accordance with an exemplary embodiment;

FIG. 2 is a schematic diagram illustrating a system architecture in accordance with an exemplary embodiment;

FIG. 3 is a schematic structural diagram of a computer device according to an embodiment of the present invention;

FIG. 4 is a flow diagram illustrating a method of traffic routing according to an exemplary embodiment;

FIG. 5 is a flow diagram illustrating a method of traffic routing according to another exemplary embodiment;

FIG. 6 is a flow diagram illustrating a method of traffic routing according to another exemplary embodiment;

FIG. 7A is a schematic diagram illustrating the structure of a traffic routing apparatus in accordance with an illustrative embodiment;

FIG. 7B is a schematic block diagram illustrating another traffic routing apparatus in accordance with an illustrative embodiment;

FIG. 7C is a schematic block diagram illustrating another traffic routing apparatus in accordance with an illustrative embodiment;

fig. 7D is a schematic structural diagram illustrating another traffic routing apparatus according to an example embodiment.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

The embodiment of the present invention mainly implements network communication services through an NFV system architecture, and therefore, before describing the method for service routing related to the embodiment of the present invention in detail, the NFV system architecture is briefly described.

Referring to fig. 1, fig. 1 is a schematic diagram illustrating an NFV system architecture according to an exemplary embodiment, where the NFV system architecture can be applied to various types of networks, such as an operator communication network or a local area network.

The System architecture mainly includes an NFV MANO 110, an NFV Infrastructure (NFV) layer 120, multiple VNFs 130, multiple Element Managers (EM) 140, and an Operation Support Management System (Operation Support System/Business Support System, OSS/BSS) 150. The NFV MANO 110 further includes an NFVO 110a, one or more VNFMs 110b, and a Virtualized Infrastructure Manager (VIM) 110 c.

The VNFs 130 are mainly used to implement the method for routing traffic provided by the embodiment of the present invention. Each VNF130 may be configured to provide network functions for different network elements of a communication network (e.g., the communication network is an IP Multimedia System (IMS)), such AS, but not limited to, a Proxy Call Session Control Function (P-CSCF), an access Call Session Control Function (I-CSCF), a Serving Call Session Control Function (S-CSCF), an HSS, and an Application Server (AS). In practical implementation, the S-CSCF and the I-CSCF may be implemented by different VNFs, respectively, or the S-CSCF and the I-CSCF may also be combined in the same VNF, which is not limited in this embodiment of the present invention.

Further, according to the deployed position of each VNF130 in the communication network and the type of the system, the VNFs 130 may be further divided into a front-end network element and a back-end network element, for example, in the calling session system, the front-end network element may be a P-CSCF, and the back-end network element may include an S-CSCF, an I-CSCF, an AS, and the like. For another example, in the called session system, the front-end network element may be an I-CSCF, and the back-end network element may include an S-CSCF, an AS, and the like.

The NFV MANO 110 is mainly configured to perform monitoring and management of VNFs 130 and NFVI 120, and the EM 140 may be configured to manage one or more VNFs 130. In the embodiment of the present invention, the NFVO 110a and the VNFM 110b included in the NFV MANO 110 and the EM 140 are mainly used to implement a gray policy control center, and the gray policy control center is mainly used to send a gray policy description file to each VNF 130. That is, in the embodiment of the present invention, a grayscale policy description file may be sent to the VNFs 130 by the NFVO 110a, the VNFM 110b, or the EM 140, so that the VNFs 130 determine the grayscale policy, which is specifically implemented as the following embodiments shown in fig. 4 to fig. 6.

Additionally, the NFVI 120 described above primarily includes hardware resources, software resources, or a combination of both to complete the deployment of a virtualized environment, i.e., the hardware resources and virtualization layer are used to provide virtualized resources, e.g., as virtual machines and other forms of virtual containers, for the VNF 130. The VIM 110c described above is primarily used to perform resource management functions, such as managing the allocation and operation of infrastructure resources. In summary, the NFVI 120 and VIM 110c may be used to implement communication network services in cooperation with the VNF130, and will not be described herein in a too-extensive manner.

Next, a system architecture according to an embodiment of the present invention will be briefly described.

Referring to fig. 2, fig. 2 is a schematic diagram illustrating a system architecture according to an example embodiment. The system architecture mainly includes a front-end network element 210 and a back-end network element 220, and the front-end network element 210 and the back-end network element 220 can be connected through a communication network. As described above, the front-end network element 210 and the back-end network element 220 may both be implemented by the VNF130 described above.

In an actual application scenario, the front-end network element 210 and the back-end network element 220 each include different subsystem modules that are not upgraded and are upgraded and have the same function, for example, the different subsystem modules include a Load Balance (LB), a Service processing module (SRV), a database (Data Base, DB), and the like.

In addition, in a possible implementation manner, for the backend network element 220, an uneupgraded backend network element and an upgraded backend network element having the same network function may also exist in the network at the same time, where the upgraded backend network element means that all the subsystem modules included in the backend network element are upgraded.

The front-end network element 210 is mainly configured to determine whether a user is a grayscale user when receiving a service request from the user, where the service request may include, but is not limited to, a registration request, a calling session request, and a called session request. Further, the front-end network element 210 may determine whether the user is a grayscale user according to the grayscale policy description file. That is, the front-end network element 210 selects which users' services are routed to the upgraded subsystem module in the VNF according to the grayscale policy description file, so as to perform grayscale verification on the upgraded subsystem module.

In addition, the front-end network element 210 may further add a gray scale identifier in the service request after determining the gray scale user to notify the back-end network element 220 of which users are the gray scale users, so that when the back-end network element 220 receives the service request from the user, it may be determined whether the service of the user needs to be routed to the upgraded subsystem module in the back-end network element 220, thereby ensuring that each network element routes the services of the same gray scale user to the upgraded subsystem module, which is specifically implemented as shown in the following embodiments shown in fig. 4 to fig. 6.

It should be noted that, in an actual application scenario, the front-end network element 210 and the back-end network element 220 may be provided by the same provider or different providers, which is not limited in this embodiment of the present invention.

Further, the system architecture further includes a gray policy control center 230, where the gray policy control center 230 is mainly used to send the gray policy description file to the front-end network element 210, and certainly, in an actual implementation, the gray policy control center 230 may also be used to send the gray policy description file to the back-end network element 220. As described above, in practical implementation, the gray policy control center 230 may be the NFVO 110a, the VNFM 110b, or the EM 140, which is not limited in this embodiment of the invention.

Fig. 3 is a schematic structural diagram of a computer device according to an embodiment of the present invention. VNF130 in fig. 2 may be implemented by a computer device as shown in fig. 3. Referring to fig. 3, the computer device comprises at least one processor 301, a communication bus 302, a memory 303 and at least one communication interface 304.

The processor 301 may be a general-purpose Central Processing Unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more ics for controlling the execution of programs in accordance with the present invention.

The communication bus 302 may include a path that conveys information between the aforementioned components.

The Memory 303 may be a Read-Only Memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that can store information and instructions, an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Compact Disc Read-Only Memory (CD-ROM) or other optical Disc storage, optical Disc storage (including Compact Disc, laser Disc, optical Disc, digital versatile Disc, blu-ray Disc, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to these. The memory 303 may be separate and coupled to the processor 301 through a communication bus 302. The memory 303 may also be integrated with the processor 301.

Communication interface 304, using any transceiver or the like, is used for communicating with other devices or communication Networks, such as ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), etc.

In particular implementations, processor 301 may include one or more CPUs such as CPU0 and CPU1 shown in fig. 3 for one embodiment.

In particular implementations, a computer device may include multiple processors, such as processor 301 and processor 305 shown in FIG. 3, as one embodiment. Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (e.g., computer program instructions).

In particular implementations, the computer device may also include an output device 306 and an input device 307, as one embodiment. An output device 306 is in communication with the processor 301 and may display information in a variety of ways. For example, the output device 306 may be a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display device, a Cathode Ray Tube (CRT) display device, a projector (projector), or the like. The input device 307 is in communication with the processor 301 and may receive user input in a variety of ways. For example, the input device 307 may be a mouse, a keyboard, a touch screen device, a sensing device, or the like.

The computer device may be a general purpose computer device or a special purpose computer device. In a specific implementation, the computer device may be a desktop computer, a laptop computer, a network server, a Personal Digital Assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device, or an embedded device. The embodiment of the invention does not limit the type of the computer equipment.

The memory 303 is used for storing program codes for executing the scheme of the application, and is controlled by the processor 301 to execute. The processor 301 is operable to execute program code 308 stored in the memory 303. One or more software modules may be included in program code 308. VNF130 shown in fig. 2 may determine data for developing an application through one or more software modules in program code 308 in processor 301 and memory 303.

Next, a method for service processing according to an embodiment of the present invention is described in detail, specifically referring to several embodiments shown in fig. 4 to fig. 6 below.

Fig. 4 is a flow chart illustrating a method of traffic routing in accordance with an exemplary embodiment. Referring to fig. 4, the method for routing traffic may be applied to the system shown in fig. 2, where the VNF in this embodiment refers to a front-end network element in the system shown in fig. 2, and the next VNF refers to a back-end network element in the system shown in fig. 2. The method for service routing can comprise the following implementation steps:

step 401: and the VNF receives a gray strategy description file issued by the gray strategy control center.

In an actual implementation, in order to facilitate the VNF to determine which users need to be determined as grayscale users, a grayscale policy control center generally issues a grayscale policy description file to the VNF in advance, so as to inform the VNF of the determined grayscale policy through the grayscale policy description file.

It should be noted that, here, it is only described by taking an example that the grayscale policy control center issues the grayscale policy description file to the VNFs, in an actual implementation, in order to ensure that each VNF can acquire the grayscale policy, the grayscale policy control center may also issue the grayscale policy description file to each VNF, which is not limited herein.

In an actual application scenario, according to different gray strategies determined by a gray strategy control center, the content included in the gray strategy description file is also different, and the following specific cases may be included:

in the first case: the grayscale policy description file includes a grayscale percentage.

In this case, the gradation strategy determined by the gradation strategy control center is a manner of gradation percentage. That is, the grayscale policy control center only notifies the VNF how many users need to be determined as grayscale users, but the grayscale policy control center does not specify which users are specifically determined as grayscale users. At this time, it is required to determine which users need to be determined as grayscale users according to the grayscale percentage by the VNF, and for a specific implementation, see the first implementation in step 402 below.

In the second case: the grayscale policy description file includes a user range belonging to grayscale users.

In this case, the grayscale policy determined by the grayscale policy control center directly specifies which users are grayscale users, and issues the specified user range belonging to the grayscale users to the VNF through the grayscale policy description file.

The user range may include, but is not limited to, a location range, a number segment, or a number list. The location range refers to a range of locations where the user is located, for example, the location range may be a city a; the number segment is used to indicate that a certain digit or digits in the telephone number used by the user meet a certain rule, for example, the number segment may indicate that the fourth digit to the seventh digit of the telephone number are in the range of 0100 to 0112, and for example, the number segment may also indicate that the last digit of the telephone number is an even number, etc.; the number list may be used to store telephone numbers belonging to greyscale users.

It should be noted that, in the embodiment of the present invention, the user scope is only described as an example where the user scope includes a location scope, a number segment, or a number list, and in another embodiment, the user scope may further include other information, for example, the user scope may further include a user rating, where the user rating may be used to indicate whether the user is a honored guest (VIP) user, or the like; for another example, the user range may also include prepaid or postpaid users, and the like, which is not limited in this embodiment of the present invention.

Further, in the process of performing grayscale upgrading on the VNF, the grayscale policy control center may divide the entire grayscale upgrading into N batches, and assign different users to different batches according to different grayscale policies. Therefore, in practical implementation, the grayscale policy control center may further add a batch value to the grayscale policy description file, where the batch value is used to indicate a batch determined to be corresponding to the grayscale user this time. Therefore, in the subsequent processing process, if a certain batch finds that the upgraded VNF has a problem after the gray scale verification, batch rollback processing can be performed on the gray scale user corresponding to the batch value. Wherein N is an integer greater than 1.

In practical implementation, the grayscale policy control center may issue grayscale policy description files of all batches to the VNF at one time, or the grayscale policy control center may also issue grayscale policy description files to the VNF in batches step by step.

It should also be noted that, as described above, since each VNF may come from different vendors, the semantics defined by different vendors for the grayscale policy description file may be different. In addition, in actual implementation, before issuing the grayscale policy description file to each VNF, the grayscale policy control center needs to read the grayscale policy description files provided by different vendors, present the grayscale policy description files on a display interface, and submit the grayscale policy description files to storage after editing and modifying the content in the grayscale policy description files in a customized manner. And then, the gray strategy control center issues the edited and modified and stored gray strategy description file to the VNFs corresponding to different suppliers, so that each VNF can analyze the gray strategy description file defined by the VNF and acquire the gray strategy indicated by the gray strategy description file. Therefore, in order to ensure that the gray scale policy control center can manage the gray scale policy description files provided by different VNFs and having different semantics, so that the VNFs can cooperatively and consistently understand the contents included in the gray scale policy description files, it is necessary to uniformly specify the attributes of the gray scale policy description files themselves.

For this reason, in the embodiment of the present invention, the grayscale policy description file adopts a uniform and universal standard format and supports editable, for example, the grayscale policy description file may be in a hypertext Markup Language (HTML) format, and the filename of the grayscale policy description file and the directory location stored in the software package generally need to be fixed and uniform. In addition, the API event interfaces triggered when the contents of the grayscale policy description file are submitted for storage after being edited and modified are the same, for example, javascript: form.

Step 402: when the VNF receives a service request from a user, it determines whether the user is a grayscale user.

In order to determine which users need to be selected to use the upgraded subsystem modules in the VNF, when a service request is received from a user, it needs to be determined by the VNF whether the user is a grayscale user.

In practical implementation, the VNF may determine whether the user is a grayscale user according to a grayscale policy description file issued by a grayscale policy control center. Wherein, according to different contents included in the grayscale policy description file, the VNF determining whether the user is a grayscale user may include the following possible implementation manners:

the first implementation mode comprises the following steps: when the grayscale policy profile includes a grayscale percentage, the VNF can determine whether the user is a grayscale user based on the grayscale percentage.

Further, the VNF specifically determining whether the user is a grayscale user according to the grayscale percentage may include the following processes: the VNF selects an ith user from every preset number of users according to the gray scale percentage, and determines the selected user as a gray scale user, wherein i is an integer greater than 1.

The preset number may be set by a user according to actual needs in a user-defined manner, or may be set by the default of the VNF, which is not limited in the embodiment of the present invention.

For example, if the preset number is 10, the above grayscale percentage is 10%, and i is 1, in a specific implementation, the VNF may select a first user from every 10 users who come on line, and determine the selected user as a grayscale user. That is, the first user of every 10 online users is determined as the grayscale user.

It should be noted that, in an actual implementation, some grayscale users may be offline due to shutdown or logout of the user, and at this time, the VNF may increase the number of the selected grayscale users in each subsequent preset number of users according to the number of the grayscale users currently offline, so as to compensate until the number of the online grayscale users is substantially corresponding to the grayscale percentage.

In addition, the above description is given by taking an example in which the VNF selects the ith user from every preset number of users according to the grayscale percentage, and determines the selected user as the grayscale user. In practical implementations, the VNF may also determine the gray user by other means based on the gray percentage. For example, the VNF may further select a jth service from every preset number of services according to the gray percentage, and use the selected service as a gray object, and further determine a user corresponding to the selected service as a gray user. Wherein j is an integer greater than 1.

The second implementation mode comprises the following steps: when the grayscale policy profile includes a user range belonging to a grayscale user, the VNF may determine whether the user is a grayscale user according to the user range.

In this implementation, the grayscale policy control center has directly specified which users belong to grayscale users. In a specific implementation, when the VNF receives a service request from a user, it is determined whether the user is a grayscale user according to a user range included in the grayscale policy description file. For example, the service request may carry user identity information of the user, for example, the user identity information may include a phone number used by the user or location information of the user currently located. Then, the VNF queries whether the user identity information belongs to the user range, and if so, determines that the user is a grayscale user.

For example, assuming that the user identity information carried by the service request is a telephone number, and the user range includes a number segment, where the number segment indicates that the fourth bit to the seventh bit of the telephone number are between 0100 and 0112, the VNF queries whether the fourth bit to the seventh bit of the telephone number belong to the number segment. If the fourth to seventh digits of the phone number belong to the number segment, the VNF determines that the user is a grayscale user, otherwise, determines that the user is not a grayscale user.

Step 403: and if the VNF determines that the user is the gray-scale user, routing the service requested by the service request to the upgraded subsystem module in the VNF.

As mentioned above, the VNF includes different subsystem modules with the same function that are not upgraded and upgraded, and if it is determined that the user is a grayscale user, it indicates that the service requested by the user needs to be routed to the upgraded subsystem module in the VNF.

Further, if the grayscale policy description file includes a batch value, it is determined whether the user is a grayscale user, and it is also necessary to determine whether the batch value is smaller than or equal to a grayscale release batch to which the current grayscale upgrading task is performed, and only when the batch value is smaller than or equal to the grayscale release batch to which the current grayscale upgrading task is performed, the VNF routes the service requested by the user to the upgraded subsystem module in the VNF.

Further, when the VNF determines that the user is a grayscale user, a grayscale identifier may be set for the user or the current service, for example, the grayscale identifier may be an ABTest, and further, a value corresponding to the ABTest may be the batch value, for example, when the ABTest is equal to 1, the batch value is 1.

In a possible implementation manner, the VNF may store the grayscale identifier in the user registration data of the DB, so that when the user initiates other services subsequently, the VNF may determine whether the user is a grayscale user directly according to the stored user registration data.

In another possible implementation manner, the VNF may further store the grayscale identifier in session data of the DB, so that when other messages of the service are processed subsequently, it is determined whether the service is a grayscale object directly by querying the session data, and thus, it is determined whether the user initiating the service request is a grayscale user.

Further, if it is determined that the user is a grayscale user, in order to ensure that each of the other VNFs uniformly identifies the user as a grayscale user, so that each VNF routes the service of the user to the upgraded subsystem module, the embodiment of the present invention further includes the following implementation steps.

Step 404: when the VNF determines that the user is a gray-scale user, a gray-scale identifier is added to the service request.

It is to be understood that in a practical application scenario, interaction between multiple VNFs is usually required to enable network communication. Here, in order to inform the next VNF that the user currently making the service request is determined to be a gray-scale user, the VNF may add a gray-scale identifier to the service request before sending the service request to the next VNF.

It should be noted that, in an actual implementation, there is no sequential execution order between the step 403 and the step 404, that is, the step 404 may be executed before the step 403, or may be executed after the step 403, or the step 404 may also be executed simultaneously with the step 403, which is not limited in this embodiment of the present invention.

Step 405: the VNF sends the service request to a next VNF, where the service request is used to instruct the next VNF to determine the user as the grayscale user.

As shown in step 404, the service request carries a gray scale identifier, so that after receiving the service request, the next VNF can determine that the user is a gray scale user based on the gray scale identifier.

It should be noted that, since each VNF may come from different vendors, it is considered that the definitions of the grayscale markers may be different from vendor to vendor, for example, the grayscale marker provided by the a vendor may be ABTest, the grayscale marker provided by the B vendor may be BCTest, and so on. In this case, in order to improve the compatibility of the VNF, uniform grayscale identification information may be included in the grayscale policy description file, for example, the grayscale identification information is "grayscale identification parameter", that is, the grayscale policy description file may actually include: the gray scale identification parameter is ABTest: and (4) BCtest. In this way, even if the service request sent by the VNF corresponding to the a-provider to the VNF corresponding to the B-provider is the ABTest, the VNF corresponding to the B-provider may determine that the ABTest is the grayscale identifier based on the content of the grayscale policy description file.

Further, if the next VNF includes different subsystem modules with the same function that are not upgraded and upgraded, the next VNF routes the service requested by the service request of the user to the upgraded subsystem module in the next VNF after determining that the user is a grayscale user.

Further, when the next VNF is an un-upgraded VNF and there is an upgraded VNF with the same functionality, the next VNF routes traffic requested by the user's traffic request from the un-upgraded VNF to the upgraded VNF.

As mentioned before, in some cases, for the next VNF, there are an un-upgraded VNF and an upgraded VNF with the same functionality in the network, where the upgraded VNF is referred to herein as all included subsystem modules being upgraded. In this case, the traffic of the grayscale user needs to be redirected by the VNF from the non-upgraded VNF to the upgraded VNF for grayscale verification of the upgraded VNF. The specific implementation thereof will be illustrated by the following embodiment shown in fig. 6.

It should be noted that, in the implementation process, the front-end network element makes the back-end network element determine the user as a grayscale user by carrying the grayscale identifier in the service request sent to the back-end network element, so that the problem that different VNFs can perform grayscale verification in cooperation when communication is performed across different VNFs is solved.

It should be noted that, in the above embodiment, the grayscale policy control center issues the grayscale policy description file to each VNF, and at this time, when the grayscale policy description file includes a specific user range, each VNF already knows which users are grayscale users, so that the front-end network element may not carry the grayscale identifier when sending the service request to the back-end network element. In this case, for the back-end network element, when receiving the service request sent by the front-end network element, it may directly determine whether the user is a grayscale user according to the grayscale policy description file issued by the grayscale policy control center, and thus, the problem that different VNFs can perform grayscale verification in cooperation when performing communication across different VNFs is also solved.

The service routing method provided by the embodiment of the invention is applied to the VNF, and the VNF comprises different subsystem modules which are not upgraded and are upgraded and have the same function. When a service request is received from a user, the VNF determines whether the user is a grayscale user in order to determine whether to choose to route the user's service to an upgraded subsystem module in the VNF. If the user is a grayscale user, the user's traffic is routed to the upgraded subsystem module in the VNF. Therefore, the VNF determines the gray-scale user when receiving the service request from the user, and gray-scale verification of the upgraded subsystem module is realized.

For convenience of understanding, the method for service routing according to the embodiment of the present invention is described in detail with reference to a registration procedure, taking the above-described system AS an example where the system is applied in an IMS network, and the front-end network element is a P-CSCF and the back-end network element includes an I/S-CSCF and an AS. The I/S-CSCF refers to a VNF after the I-CSCF and the S-CSCF are combined, and this embodiment is exemplified by the following VNF including different subsystem modules with the same function that are not upgraded and that are upgraded. Referring to fig. 5, fig. 5 is a flowchart illustrating a method for service routing according to another exemplary embodiment, where the method for service routing may be applied to the system illustrated in fig. 2, and the method for service routing may include the following implementation steps:

step 501: and the P-CSCF receives a gray level strategy description file issued by a gray level strategy control center.

As described in step 401 of the embodiment of fig. 4, the grayscale policy description file may include a grayscale percentage according to the grayscale policy determined by the grayscale policy control center, or the grayscale policy description file may further include a user range belonging to a grayscale user. The user range may include, but is not limited to, a location range, a number segment, and a number list. Further, the grayscale policy description file may also include a batch value.

It should be noted that, here, it is only described by taking an example that the grayscale policy control center issues the grayscale policy description file to the P-CSCF, and in an actual implementation, the grayscale policy control center may actually issue the grayscale policy description file to each VNF, so that each VNF may acquire the grayscale policy, for example, each VNF includes an I/S-CSCF and an AS.

Step 502: when the P-CSCF receives a registration request from a user, it determines whether the user is a greyscale user.

In a specific implementation, the P-CSCF determines whether the user is a grayscale user according to the received grayscale policy description file, and a specific implementation thereof may refer to step 402 in the embodiment of fig. 4, which is not repeated herein.

It should be noted that, here, the description is only given by taking an example that the P-CSCF receives a grayscale policy description file issued by a grayscale policy control center, and determines whether the user is a grayscale user according to the grayscale policy description file. In another possible embodiment, when the gray policy determined by the gray policy control center is in a gray percentage mode, the gray policy control center may send the gray policy description file to the HSS, and then the HSS determines the gray user according to the gray percentage and adds the gray identifier to the corresponding user data. Thus, after downloading the user data from the HSS, each VNF may determine whether the user is a grayscale user according to the grayscale identifier in the user data, where each VNF includes a P-CSCF.

Further, the gray scale policy control center may also directly modify the user data of the corresponding user in the HSS after determining which users need to be determined as gray scale users, that is, unlike the above implementation, the gray scale policy control center may also determine which users are gray scale users according to the gray scale percentage without the HSS, and directly modify the user data of the corresponding user in the HSS by extending the service delivery interface, and add the gray scale identifier. Similarly, in this case, after downloading the user data from the HSS, each VNF may determine whether the user is a grayscale user according to the grayscale identifier in the user data, where the VNF includes the P-CSCF.

Step 503: and when the P-CSCF determines that the user is a gray-scale user, the service requested by the registration request of the user is routed to the upgraded subsystem module in the P-CSCF.

Further, if the grayscale policy description file includes a batch value, it is determined whether the user is a grayscale user, and it is also necessary to determine whether the batch value is less than or equal to a grayscale release batch to which the current grayscale upgrade task is performed, and only when the batch value is less than or equal to the grayscale release batch to which the current grayscale upgrade task is performed, the P-CSCF routes a service requested by the user to the upgraded subsystem module in the P-CSCF.

Further, when the P-CSCF determines that the user is a gray-scale user, a gray-scale flag may be set for the user, and then the P-CSCF stores the gray-scale flag in the user registration data of the DB, so that when the user initiates another service (e.g., a session service), the P-CSCF may determine whether the user is a gray-scale user directly according to the stored user registration data. Or, the P-CSCF stores the gray scale identifier in the session data of the DB, so that when other messages (e.g., response messages) of the service are processed later, the P-CSCF determines whether the service is a gray scale object by directly querying the session data, thereby determining whether the user who initiated the service request is a gray scale user.

It should be noted that the gray level user determined here is only the gray level user in the current service, but in the next service, the user may not be the gray level user any more depending on the determined gray level object.

Further, if it is determined that the user is a grayscale user, in order to ensure that each of the other network elements uniformly identifies the user as a grayscale user, so that each network element routes the service of the user to the upgraded subsystem module, the embodiment of the present invention further includes the following implementation steps.

Step 504: when the P-CSCF determines that the user is a gray-scale user, a gray-scale identifier is added in the registration request.

The specific implementation of this step can be referred to as step 404 in the above-mentioned embodiment of fig. 4, and will not be described in detail here.

Step 505: the P-CSCF sends the registration request to the I/S-CSCF.

And after receiving the registration request, the I/S-CSCF routes the service of the user to the upgraded subsystem module in the I/S-CSCF when determining that the user is a gray-scale user according to the gray-scale identifier.

Further, the I/S-CSCF may also store the gray scale identifier in the user registration data of the DB of the I/S-CSCF, so that when the user initiates other services, the I/S-CSCF may determine whether the user is a gray scale user by directly querying the user registration data of the DB.

Further, the I/S-CSCF may store the gray scale identifier not in the user registration data of the local DB but through the P-CSCF. Specifically, the I/S-CSCF may carry the grayscale identification in a specified parameter of a 200OK message returned to the P-CSCF, so that the P-CSCF stores the specified parameter carrying the grayscale identification in the user registration data of the DB of the P-CSCF. For example, the specified parameter is a Service-route parameter.

Thus, in the subsequent session service, the P-CSCF may carry the specified parameter in the calling session request, so that the I/S-CSCF determines whether the user is a grayscale user according to the specified parameter.

Further, the I/S-CSCF may also carry the grayscale identifier in a Multimedia Authentication Request (MAR)/Service Allocation Request (SAR) message sent to the HSS, so that the HSS stores the grayscale identifier. Thus, for the I-CSCF in the called system, because the gray scale identifier of the called user is not stored in the I-CSCF, after receiving the called session Request, the I-CSCF sends a Location Immediate Request (LIR) to the HSS, and acquires the information of the S-CSCF where the user is located. Correspondingly, when the Location Immediate Answer (LIA) sent to the VNF responds, the HSS returns the gray scale identifier carried to the HSS in the MAR/SAR message during user registration to the I-CSCF, and after the I-CSCF receives the LIA response, it finds that the user is a gray scale user, and then the subsequent I/S-CSCF routes the service of the user to the upgraded subsystem module.

Further, the I/S-CSCF may also continue to send the gray scale identifier to a next VNF interacting with the I/S-CSCF, for example, the next VNF is an AS, which is described in the following steps.

Step 506: and the I/S-CSCF sends a registration request to the AS, wherein the registration request carries the gray scale identifier.

Step 507: and when the AS determines that the user is the gray-scale user, the AS routes the service requested by the user to the upgraded subsystem module in the AS.

Further, the AS may also store the grayscale identifier in the user registration data of the DB of the AS, so that when the user initiates another service, the AS may determine whether the user is a grayscale user by directly querying the user registration data of the DB.

The embodiment shown in fig. 5 is illustrated by taking as an example the following VNF includes different subsystem modules with the same functionality, which are not upgraded and which are upgraded. As mentioned before, in an actual implementation, there may also be an un-upgraded VNF and an upgraded VNF with the same functionality in the network. In this case, when sending a service request to the next VNF, the front-end network element needs to redirect and route the service from the non-upgraded VNF to the upgraded VNF. For ease of understanding, the presence of both the upgraded S-CSCF1 and the non-upgraded S-CSCF2 in the network is illustrated below in connection with the registration procedure.

Referring to fig. 6, fig. 6 is a flowchart illustrating a method for service routing according to another exemplary embodiment, where the method for service routing may be applied to the system illustrated in fig. 2, and the method for service routing may include the following implementation steps:

step 601: and the P-CSCF receives a gray level strategy description file issued by a gray level strategy control center.

The specific implementation of this method can be seen in step 501 in fig. 5, and details are not repeated here.

Step 602: when the P-CSCF receives a session request from a user, it determines whether the user is a grayscale user.

The specific implementation of this method can be seen in step 502 in fig. 5, and details are not repeated here.

Step 603: and when the P-CSCF determines that the user is a gray-scale user, the service requested by the session request is routed to the upgraded subsystem module in the P-CSCF.

The specific implementation of this method can be seen in step 503 in fig. 5, and details are not repeated here.

Step 604; when the P-CSCF determines that the user is a gray-scale user, a gray-scale identifier is added in the registration request.

Step 605: the P-CSCF sends the registration request to the I-CSCF.

Step 606: after receiving the registration Request, the I-CSCF sends a first User Authentication Request (UAR) message to the HSS.

The first UAR message is used for acquiring the information of the S-CSCF where the user is currently located.

Step 607: the HSS returns to the I-CSCF the information of the S-CSCF where the user is located.

In practical implementations, before the S-CSCF1 is upgraded, the user is migrated from the S-CSCF1 without being upgraded to the S-CSCF2, and then the S-CSCF1 is upgraded. Thus, here, the HSS returns to the I-CSCF the information of the S-CSCF where the user is located is that of the S-CSCF 2.

The information of the S-CSCF may be used to uniquely identify an S-CSCF, for example, the identity of the S-CSCF, etc.

Step 608: the I-CSCF sends a registration request to the S-CSCF2 based on the information of the S-CSCF2 returned by the HSS.

Wherein, the registration request carries a private extension parameter, and the private extension parameter is used to indicate whether the I-CSCF supports 305 redirection messages. Further, the registration request carries a gray scale identifier.

Step 609: when the S-CSCF2 determines that the user is a greyscale user, a 305 redirect message is returned to the I-CSCF instructing the I-CSCF to register the user' S traffic redirection to the upgraded S-CSCF 1.

Step 610: after receiving the 305 redirect message, the I-CSCF sends a second UAR message to the HSS again, where the second UAR message is used to instruct the HSS to allow the user to change the registration from the current S-CSCF2 to the S-CSCF 1.

In practical implementations, the HSS, after receiving the second UAR message, opens the association pending flag switch to allow the user to change the registration from the current S-CSCF2 to the S-CSCF 1.

Step 611: the HSS returns a User Authorization Request (UAA) message to the I-CSCF.

Step 612: the I-CSCF, after receiving the UAA message, sends a registration request to the S-CSCF 1.

In one possible implementation, the registration request may carry a grayscale identifier.

Step 613: the S-CSCF1, upon receiving the registration request, adds the grayscale identification to the user registration data in the DB when the user is determined to be a grayscale user.

In practical implementation, the S-CSCF1 may determine that the user is a grayscale user according to the grayscale identifier carried in the registration message, or the S-CSCF1 may determine that the user is a grayscale user according to a grayscale policy description file issued by a grayscale policy control center. For determining that the user is a grayscale user according to the grayscale policy description file issued by the grayscale policy control center, reference may be made to the above embodiments, and details are not described here.

Further, when the registration procedure is completed and the registration is successful, the P-CSCF may store information about the S-CSCF1 with which the user is newly registered. Thus, when the user initiates a calling session request, the calling session request is sent to the S-CSCF1 if the P-CSCF determines that the user is registered with the upgraded S-CSCF 1.

Further, after the S-CSCF1 receives the calling session request and determines that the user is a grayscale user, it may perform individual statistics on Key Performance Indicators (KPIs) of the service of the user. The KPI may include, but is not limited to, call completing rate, answering rate, and connection duration. More greyscale users may be migrated from the S-CSCF2 back to the S-CSCF1 for greyscale verification of the new version if the KPI statistics are normal, and the migration and greyscale verification processes may be terminated if the KPI statistics are abnormal.

The service routing method provided by the embodiment of the invention is applied to the VNF, and the VNF comprises different subsystem modules which are not upgraded and are upgraded and have the same function. When a service request is received from a user, the VNF determines whether the user is a grayscale user in order to determine whether to choose to route the user's service to an upgraded subsystem module in the VNF. If the user is a grayscale user, the user's traffic is routed to the upgraded subsystem module in the VNF. Therefore, the VNF determines the gray-scale user when receiving the service request from the user, and gray-scale verification of the upgraded subsystem module is realized. In addition, after the VNF determines the grayscale user, a grayscale identifier may be added to a service request sent to the next VNF to notify the next VNF that the user is a grayscale user, thereby implementing collaborative grayscale verification among multiple VNFs.

Referring to fig. 7A, fig. 7A is a schematic structural diagram illustrating a traffic routing apparatus according to an exemplary embodiment, where the apparatus is configured in a VNF, and the apparatus includes:

a determining module 710, configured to perform step 402 in the embodiment of fig. 4, step 502 in the embodiment of fig. 5, or step 602 in the embodiment of fig. 6;

the routing module 720 is configured to execute step 403 in the embodiment of fig. 4, step 503 in the embodiment of fig. 5, or step 603 in the embodiment of fig. 6.

Optionally, referring to fig. 7B, the apparatus further includes:

the first receiving module 730 is configured to execute step 401 in the embodiment of fig. 4, step 501 in the embodiment of fig. 5, or step 601 in the embodiment of fig. 6.

Accordingly, the determining module 710 is configured to determine whether the user is a grayscale user according to the grayscale percentage.

Optionally, the determining module 710 is configured to:

determining the selected user as the grayscale user.

Optionally, referring to fig. 7C, the apparatus further includes:

an adding module 740, configured to perform step 404 in the embodiment of fig. 4, step 504 in the embodiment of fig. 5, or step 604 in the embodiment of fig. 6;

a sending module 750, configured to execute step 405 in the embodiment of fig. 4, step 505 in the embodiment of fig. 5, or step 605 in the embodiment of fig. 6.

Optionally, referring to fig. 7D, the apparatus further includes:

a second receiving module 760, configured to perform step 401 in the embodiment of fig. 4, step 501 in the embodiment of fig. 5, or step 601 in the embodiment of fig. 6.

In summary, the service routing method provided in the embodiment of the present invention is applied to a VNF, where the VNF includes different subsystem modules with the same function that are not upgraded and are upgraded. When a service request is received from a user, the VNF determines whether the user is a grayscale user in order to determine whether to choose to route the user's service to an upgraded subsystem module in the VNF. If the user is a grayscale user, the user's traffic is routed to the upgraded subsystem module in the VNF. Therefore, the VNF determines the gray-scale user when receiving the service request from the user, and gray-scale verification of the upgraded subsystem module is realized.

It should be noted that: in the service routing apparatus provided in the foregoing embodiment, when implementing the service routing method, only the division of each functional module is illustrated, and in practical applications, the function distribution may be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules, so as to complete all or part of the functions described above. In addition, the service routing apparatus and the service routing method provided by the foregoing embodiments belong to the same concept, and specific implementation processes thereof are described in the method embodiments and are not described herein again.

In the above embodiments, the implementation may be wholly or partly realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with embodiments of the invention, to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored on a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website, computer, server, or data center to another website, computer, server, or data center via wire (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., Digital Versatile Disk (DVD)), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, where the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The above-mentioned embodiments are provided not to limit the present application, and any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A method for traffic routing, applied to a Virtual Network Function (VNF), wherein the VNF includes different subsystem modules with the same functions that are not upgraded and that have been upgraded, the method comprising:

when a service request from a user is received, determining whether the user is a gray level user, wherein the gray level user is determined based on a gray level strategy description file issued by a gray level strategy control center, or the gray level user is determined based on a gray level identifier in the service request;

if the user is determined to be the gray-scale user, routing the service requested by the service request to the upgraded subsystem module in the VNF;

sending the service request to a next VNF, wherein the service request is used for instructing the next VNF to determine the user as the gray-scale user;

2. The method of claim 1, wherein prior to determining whether the user is a grayscale user, further comprising:

accordingly, the determining whether the user is a grayscale user includes:

3. The method of claim 2, wherein said determining whether the user is a grayscale user based on the grayscale percentage comprises:

determining the selected user as the grayscale user.

4. The method of claim 2, wherein after determining whether the user is a grayscale user, further comprising:

and when the user is determined to be the gray-scale user, adding a gray-scale identifier in the service request.

5. The method of claim 1, wherein after sending the traffic request to the next VNF, further comprising:

6. The method of claim 1, wherein prior to determining whether the user is a grayscale user, further comprising:

receiving a gray strategy description file issued by a gray strategy control center, wherein the gray strategy description file comprises a user range belonging to a gray user;

accordingly, the determining whether the user is a grayscale user includes:

determining whether the user is the grayscale user based on the user range.

7. The method of claim 6, wherein the user scope comprises a location scope, a number segment, or a list of numbers.

8. An apparatus for traffic routing, configured in a VNF, wherein the VNF comprises different subsystem modules with the same functionality that are not upgraded and that have been upgraded, the apparatus comprising:

the system comprises a determining module, a judging module and a judging module, wherein the determining module is used for determining whether a user is a gray user when receiving a service request from the user, and the gray user is determined based on a gray strategy description file issued by a gray strategy control center or is determined based on a gray mark in the service request;

a routing module, configured to route, when it is determined that the user is the grayscale user, a service requested by the service request to an upgraded subsystem module in the VNF;

a sending module, configured to send the service request to a next VNF, where the service request is used to instruct the next VNF to determine the user as the grayscale user;

the apparatus is configured to, when the next VNF is an unequipped VNF and there is an upgraded VNF having the same function, redirect, by the next VNF, traffic requested by the user's registration request from the unequipped VNF to the upgraded VNF.

9. The apparatus of claim 8, wherein the apparatus further comprises:

accordingly, the determining module is further configured to:

10. The apparatus of claim 9, wherein the determination module is to:

determining the selected user as the grayscale user.

11. The apparatus of claim 9, wherein the apparatus further comprises:

and the adding module is used for adding a gray mark in the service request when the user is determined to be the gray user.

12. The apparatus of claim 8, wherein after the sending the service request to the next VNF, when the next VNF includes different subsystem modules that are not upgraded and have the same functionality, the next VNF routes the service requested by the service request to the upgraded subsystem modules in the next VNF.

13. The apparatus of claim 8, wherein the apparatus further comprises:

accordingly, the determining module is further configured to:

determining whether the user is the grayscale user based on the user range.

14. The apparatus of claim 13, wherein the user scope comprises a location scope, a number segment, or a list of numbers.

15. A computer-readable storage medium having instructions stored thereon, wherein the instructions, when executed by a processor, implement the steps of any of the methods of claims 1-7.