CN109391482B

CN109391482B - Network function upgrading method and upgrading management entity

Info

Publication number: CN109391482B
Application number: CN201710652237.1A
Authority: CN
Inventors: 武绍芸
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2017-08-02
Filing date: 2017-08-02
Publication date: 2021-01-29
Anticipated expiration: 2037-08-02
Also published as: WO2019024679A1; CN109391482A

Abstract

The embodiment of the invention relates to a network function upgrading method and an upgrading management entity. The method comprises the following steps that a plurality of NF instances to be upgraded of a network function NF exist in a network, and the method comprises the following steps: the upgrading management entity sends a first notification message to a first NF instance to be upgraded, wherein the first notification message is used for indicating the first NF instance to be upgraded to stop service; determining that a first NF instance to be upgraded has been out of service; sending a second notification message to the first NF example to be upgraded, wherein the second notification message is used for indicating the first NF example to be upgraded to obtain the upgraded first NF example; obtaining a test result of the upgraded first NF example; the test result of the upgraded first NF example is successful, and the second NF example to be upgraded is determined to be continuously appointed for upgrading; or determining to carry out upgrade rollback on the upgraded first NF example if the test result of the upgraded first NF example is unsuccessful. The embodiment of the invention has better flexibility and agility.

Description

Network function upgrading method and upgrading management entity

Technical Field

The present invention relates to the field of communications, and in particular, to a method for upgrading a network function and an upgrade management entity.

Background

The fifth Generation mobile phone mobile communication standard is also called the fifth Generation mobile communication technology (5th-Generation, 5G). The 5G standard is currently being developed with the goal of making the network more flexible and agile, in addition to consistently higher transmission bandwidth. As mobile network capabilities increase and demand increases, more and more applications place demands on network capabilities. Besides the daily access of people to resources through mobile phone Applications (APPs) or web pages, there are many other vertical markets, which have different requirements on networks, such as: the system comprises an internet of things with large connection and low power consumption, a low-delay and high-reliability internet of vehicles, a high-definition video or virtual reality network with ultrahigh bandwidth and the like. In order to meet the requirements of the above-mentioned various requirements, and the requirements are evolving, the 5G network has agility as a key target, and is embodied in various key technologies (network slice, service architecture), and the importance of the network is very important.

A Service-Oriented Architecture (SOA) is a component model that ties different functional units of an application (called services) through well-defined interfaces and contracts between these services. The requirements between services are loosely coupled. The interface is defined in a neutral manner and should be independent of the hardware platform, operating system and programming language in which the service is implemented. This allows services built into a wide variety of systems to interact in a uniform and versatile manner. In the service interaction process in the prior art, after a service is on-line, the service needs to be registered in a service registration center. When one service (consumer service) needs to communicate with other services (producer services), i.e. when interfaces of other services are used, the consumer service queries or subscribes to the service registry for information of producer services that meet the requirements.

In order to make 5G networks more flexible and agile, new business applications are brought online faster, a servitization architecture is defined and described in the standard. The 5G Network is composed of a plurality of Network Functions (NFs), each of which may be referred to as a service, and a service interface (e.g., Nnef, Nausf, etc.) is used between most of the Network functions. The NFs include Access and Mobility Management functions (AMFs), Session Management Functions (SMFs), User Plane Functions (UPFs), Policy functions (PCFs), Network open functions (NEFs), and NF Repository Functions (NRFs), and the Network further includes a Unified Data Management (UDM) entity, AN Authentication service Function (AUSF) entity, a User Equipment (UE), AN Access Network (Access Network, AN), and a Data Network (Network, DN). The NRF is used to support service discovery of a network, and corresponds to a service registry. The term "service" may refer to one NF, or may refer to a set of function partitions (NF-services) with smaller granularity in the NF, that is, one NF is composed of a plurality of NF-services, and this concept is different only in scope.

Software in the field of Communications Technology (CT) may consist of one or more NFs, and when an NF is upgraded, all NF instances of the NF are typically upgraded uniformly, and thus, flexibility and agility are poor.

Disclosure of Invention

The embodiment of the invention provides a network function upgrading method and an upgrading management entity, which improve the flexibility and agility of upgrading.

In a first aspect, a method for upgrading a network function is provided. The method comprises the steps that a plurality of NF instances to be upgraded of one NF exist in a network, an upgrade management entity sends a first notification message to a first NF instance to be upgraded, and the first notification message is used for indicating the first NF instance to be upgraded to stop service; the upgrade management entity determines that the first NF instance to be upgraded is out of service; the upgrade management entity sends a second notification message to the first NF instance to be upgraded, wherein the second notification message is used for indicating the first NF instance to be upgraded to obtain the upgraded first NF instance; the upgrade management entity obtains a test result of the upgraded first NF instance; the test result of the upgraded first NF instance is successful, and the upgrade management entity determines to continuously designate a second NF instance to be upgraded for upgrading; or, the upgraded first NF instance is tested unsuccessfully, and the upgrade management entity determines to upgrade and rollback the upgraded first NF instance.

In the embodiment of the invention, when a plurality of NF instances to be upgraded of one NF exist in the network, part of the NF instances to be upgraded can be upgraded firstly, for example, each NF instance to be upgraded is upgraded one by one, in the process of upgrading the NF instances, the service offline and the NF instance are tested, and corresponding processing is carried out according to the test result, so that the high-version NF instance and the low-version NF instance of one NF coexist, and the upgrading mode is more flexible and agile.

In one possible implementation, the first NF instance to be upgraded is registered with the NRF; the first notification message is used for indicating the first NF instance to be upgraded to register from the NRF; the upgrade management entity receives a third notification message from the first NF instance to be upgraded, wherein the third notification message is used for indicating that the first NF instance to be upgraded is completely unregistered from the NRF. According to the embodiment, the first NF instance to be upgraded is unregistered from the NRF, so that the first NF instance to be upgraded stops service.

In a possible implementation manner, before the upgrade management entity sends the second notification message to the first NF instance to be upgraded, the upgrade management entity sends a fourth notification message to the first NF instance to be upgraded, where the fourth notification message is used to instruct the first NF instance to be upgraded to migrate the carried service to a third NF instance; and the upgrade management entity receives a fifth notification message from the first NF instance to be upgraded, wherein the fifth notification message is used for indicating that the first NF instance to be upgraded finishes migrating the carried service to the third NF instance. According to the embodiment, the service carried by the NF instance to be upgraded is smoothly transferred to other peer NF instances, so that the upgrading process is completely lossless.

In a possible implementation manner, the upgrade management entity sends a test policy to the test coordination NF, where the test policy includes at least one of a test user range, a test flow, a test start mode, and a test exit condition; and the upgrading management entity receives the test result of the upgraded first NF instance from the test cooperation NF. According to the embodiment, the upgrade management entity sends the test policy to the test coordination NF, so that the test coordination NF tests the upgraded NF instance according to the test policy.

In a possible implementation manner, before the upgrade management entity receives a test result of the upgraded first NF instance from the test coordination NF, the upgrade management entity determines that a test trigger condition is satisfied; and the upgrade management entity sends a sixth notification message to the test coordination NF, wherein the sixth notification message is used for indicating the test coordination NF to start a test. According to the embodiment, the upgrading management entity controls the test to be performed in cooperation with the NF, so that the unified management of test starting is facilitated.

In one possible implementation, the NF instance to be upgraded is a service instance or a microservice instance. According to the embodiment, gray scale upgrading with different granularities can be realized, so that the flexibility and the agility are better.

On the other hand, an embodiment of the present invention provides an upgrade management entity, where the upgrade management entity may implement a function executed by the upgrade management entity in the above method design, where the function may be implemented by hardware, or may be implemented by hardware executing corresponding software. The hardware or software comprises one or more modules corresponding to the functions.

In one possible design, the upgrade management entity may be structured to include a processor and a communication interface, where the processor is configured to support the upgrade management entity to perform the corresponding functions of the above-described method. The communication interface is used for supporting communication between the upgrade management entity and the test coordination NF or other NFs. The upgrade management entity may also include a memory, coupled to the processor, that stores program instructions and data necessary for the upgrade management entity.

In another aspect, an embodiment of the present invention provides a computer storage medium for storing computer software instructions for the upgrade management entity, which includes a program designed to execute the first aspect.

In a further aspect, an embodiment of the present invention provides a computer program product, which contains instructions that, when the program is executed by a computer, cause the computer to perform the functions performed by the upgrade management entity in the method design of the first aspect.

Drawings

Fig. 1 is a communication diagram of an upgrade preparation phase according to an embodiment of the present invention;

fig. 2 is a communication diagram of an upgrade test phase according to an embodiment of the present invention;

fig. 3 is a communication schematic diagram of a network function upgrading method according to an embodiment of the present invention;

fig. 4 is a schematic structural diagram of an upgrade management entity according to an embodiment of the present invention;

fig. 5 is a schematic structural diagram of another upgrade management entity according to an embodiment of the present invention.

Detailed Description

The 5G network introduces a service architecture, and a service-oriented upgrading mode needs to be defined, so that the flexible and smooth service upgrading mode is supported, and the service customization required by an operator is met.

It should be noted that the "service" may refer to one NF, or may refer to a set of function partitions (NF-services) with smaller granularity in the NF, that is, one NF is composed of a plurality of NF-services, this concept is different only in scope, and there is no substantial difference in the present solution, and the following description is generally made with an NF.

The method for upgrading the network function provided by the embodiment of the invention can be divided into several stages: stage one: before upgrading, all NF to be upgraded in the network works in a low version at the moment. And a second stage: and (4) upgrading preparation, namely, starting upgrading preparation and planning, and performing service-related smoothing treatment, such as low-version offline, service migration and the like. And a third stage: and (5) upgrading the service, namely upgrading the NF to be upgraded. And a fourth stage: and (4) upgrading test, namely testing the upgraded NF. And step five, upgrading decision making, namely making a decision according to the test result of the upgraded NF, returning, keeping the current situation, or continuing upgrading. And a sixth stage: and (4) upgrading and returning, wherein if the test is unsuccessful after upgrading or other service problems exist, returning is carried out. Stage seven: and (4) completing the upgrade, wherein all objects to be upgraded are upgraded, or the user quits the upgrade manually, and then the whole upgrade process is completed.

The following describes these stages separately:

stage one, before upgrade, which is an existing implementation, NF is registered to the NRF in low version (version before upgrade). The registration information of the NRF includes a version number, and each NF may carry a specific version number for registration, but the NF may not carry a specific version number. In one example, the NF sends a registration request message to the NRF, and after registering with the NF, the NRF sends a registration response message to the NF, thereby completing the service registration. In one example, a first NF (i.e., a service consumer) sends a discovery request message to an NRF, the NRF processes and sends a discovery response message to the first NF, the first NF selects a second NF (i.e., a service producer) according to the discovery response message, and the first NF communicates with the second NF through a service interface.

Fig. 1 is a communication diagram of a phase two upgrade preparation phase according to an embodiment of the present invention. The upgrading preparation stage mainly comprises the following processing flows:

step 101, an upgrade management entity performs upgrade planning.

The upgrade management entity may be an entity of a management plane, such as a network manager, or an external third-party controller, or may be embedded into a service operation function to become an autonomous management entity. The specific objects and modalities do not affect the present solution.

The upgrade plan contains several parts:

and upgrading the object. The NF instances to be upgraded (a class of NFs may contain multiple instances) may include network Protocol (IP) addresses corresponding to the NFs. A single NF instance may be specified, the entire NF type (including all instances) may be specified, as well as multiple different NF instances or multiple different NFs.

And upgrading the previous and later versions. And for each upgrade object instance, specifying versions before and after upgrading. The version before upgrading is mainly used for checking, and the version after upgrading is used for specific upgrading.

The test synergizes NF. The NF to be tested after upgrading may not be specified (e.g., manual testing), or may be specified in multiple numbers (e.g., one process requires multiple NFs to be tested).

Step 102, the upgrade management entity notifies the NF to be upgraded to go offline.

The off-line means that the NF to be upgraded registers itself from the NRF, so that other services cannot find the NF to be upgraded again, and the issued service interface is not processed any more, but a certain error code is fed back.

And 103, preparing the NF to be upgraded for offline.

The NF to be upgraded may have some locally performed actions, such as releasing system resources, etc., before initiating a de-registration with the NRF. NF in communication system is hard to be completely stateless, so there are some connection information resources.

In addition, if a subsequent service migration is required, this step is usually not performed, because the subsequent service migration also requires that connections with upstream and downstream and users be maintained at this time.

Step 104, the NF to be upgraded initiates a deregistration request to the NRF.

And 105, the NRF performs deregistration processing on the NF to be upgraded.

And step 106, the NRF sends a deregistration response to the NF to be upgraded.

And step 107, the NF to be upgraded sends the upgrade management entity the completion of the offline.

And step 108, the upgrade management entity performs service migration planning.

The service migration refers to smoothly transferring the service carried on the NF to be upgraded to other peer NFs, so as to achieve complete lossless upgrading process.

Common service migration techniques can be adopted, which are the existing steps and are not described herein.

Step 109, the upgrade management entity notifies the NF to be upgraded to perform service migration.

Step 1010, migrating the NF to be upgraded.

Step 1011, the NF to be upgraded sends a migration completion notification message to the upgrade management entity.

Step 1012, the upgrade management entity performs test planning.

The test plan contains several parts.

The user range is tested. The range of users to be covered by the test is specified, such as an International Mobile Subscriber Identity (IMSI) of an end user or an Integrated Services Digital Network (ISDN) number (MSISDN) of a Mobile station, and the like, and may also be specified as all users, or a certain proportion or number of users.

And (5) testing process. The business process involved in the test is specified. Related to the specific upgrade object and business environment. For example, for an upgrade of an SMF (session management NF) entity, the signaling flow of the test may be designated as "bearer creation", i.e. the test is started when a "bearer creation" type signaling is sent or received.

And testing the starting mode. And designating a test starting mode. Such as manual triggering, automatic triggering, timed triggering, etc. When the test is designated as the automatic start test, the test cooperation NF immediately tries to find the upgrade object NF with high version, and if the upgrade object NF is found, the service test is carried out.

The exit conditions were tested. Conditions for the end of the test are specified. For example, the test duration, the number of test signaling, etc., and the report of the test result can be started after the export condition is reached.

Step 1013, the upgrade management entity sends a test policy notification message to the test collaboration NF.

The test strategy comprises the content of the previous step. If multiple test collaboration NFs are involved, all test collaboration NFs need to be notified.

Step 1014, the test collaboration NF stores the test data and the test policy.

The test coordinates the NF to save the test policy locally. Part of the information needs to refresh its own implementation policy, for example, service testing is performed on part of the user flow, and some local policies may need to be updated to capture the corresponding test scenario.

Step 1015, the testing cooperation NF sends a testing policy response message to the upgrade management entity.

And a third stage: and (5) upgrading the service, namely performing specific upgrading action on the NF to be upgraded at the stage. The NF to be upgraded re-registers with the NRF in a high version (upgraded version) after completing the upgrade action. Similarly, the registration information of the NRF may include a version number, and each NF may carry a specific version number for registration, but the NF may not carry a specific version number.

Fig. 2 is a communication diagram of a stage four upgrade test stage. The upgrading test stage mainly comprises the following processing flows:

step 201, the upgrade management entity performs test triggering judgment.

If the test starting mode in the test strategy is manual, the test can be triggered manually;

if the test starting mode in the test strategy is timing, the test can be triggered after the timer is reached;

if the test starting mode in the test strategy is automatic, the test is cooperated with NF to automatically process, and the step is not needed.

Step 202, the upgrade management entity sends a test start request to the NF.

Step 203, the test cooperates with the NF to judge the test condition.

And the test cooperation NF judges whether to test the upgraded NF according to the stored test strategies (including a test user range, a test flow and the like).

For example, testing and cooperating with nf (amf), only a user whose IMSI is XXXX is tested, and when bearer creation is performed, testing is started, and when a signaling flow meeting the user range and flow requirements is received, testing is started.

Step 204, the test collaboration NF initiates a service discovery request message to the NRF, carrying the high version.

The test is determined for the upgrade object using a high version query, or a determination of the IP address of the NF.

In step 205, the NRF sends a service discovery response message to the testing coordination NF.

And step 206, the test cooperates with the NF to carry out service flow interaction with the upgraded NF.

This step is a general signaling flow process, but the testing cooperation NF needs to identify the flag bit of "under test" in the local context and state machine for subsequent collection and judgment of the test result.

And step 207, recording the test result by the test cooperation NF, and judging whether the test exit condition is met.

After the signaling interaction with the upgraded NF is completed (the NF is identified according to the context and the zone bit of the state machine), the test cooperation NF records the signaling interaction result (such as success, failure, partial success, and corresponding detailed cause value and context).

And meanwhile, judging the test exit conditions (such as time length, signaling number and the like), and if the exit conditions are met, reporting the results.

And step 208, reporting the test result to the upgrade management entity by the test cooperation NF.

And the test cooperation NF sends all the test results recorded locally to the upgrade management entity.

And step 209, the upgrading management entity collects the test report and analyzes the test report.

The upgrade management entity reports the test reports, including one or more test reports sent by the NF in cooperation with the test reports, and the upgrade NF status information collected by the upgrade management entity itself, and performs summary analysis.

And stage five, upgrading decision making. After the upgrading management entity finishes NF upgrading in one stage, an upgrading decision is made according to a test result, and the upgrading decision comprises several possible results: testing successfully, continuing upgrading (finishing upgrading of one NF example and continuously appointing the next NF example); if the test is unsuccessful, upgrading and returning; successful or unsuccessful testing, and ending the upgrade (it is not necessary to wait until all NFs have been upgraded successfully, e.g., in some scenarios, the customer may also want to stay in an intermediate state for long-term results to be observed).

And a sixth stage: and (5) upgrading and returning. At this stage, a specific upgrade rollback action is performed on the NF to be rolled back. After the NF is rolled back, whether to retry the upgrading of the NF continuously or skip the upgrading of other NFs before the NF is determined by manual or preset strategies.

Stage seven: and finishing upgrading. There may be several reasons to enter the upgrade complete phase: all specified NF instances are upgraded; manual decision for any reason (even if only some NF instances complete the upgrade, or none of them complete the upgrade).

The method for upgrading the network function provided by the embodiment of the invention comprises the following steps: the method for upgrading the 5G service framework is provided, customization requirements of reliable and smooth classes such as service migration and service flow can be considered in the upgrading process, and no specific requirements are required for the service registration mode of the NRF (the NRF is realized in a Domain Name System (DNS) mode, most DNS does not have a complex service selection function, and only a simple DNS registration query function is provided).

In the following embodiments of the present invention, the main flow of the method for upgrading a network function provided in the embodiments of the present invention is summarized in combination with the phase analysis of the foregoing embodiments.

Fig. 3 is a communication schematic diagram of a network function upgrading method provided by an embodiment of the present invention, where a scenario addressed by the method may be multiple NF instances to be upgraded where one NF exists in a network, and the method includes:

step 301, an upgrade management entity sends a first notification message to a first NF instance to be upgraded, where the first notification message is used to indicate that the first NF instance to be upgraded stops service.

In one example, the first NF instance to be upgraded is registered to an NRF, and the first notification message is used to instruct the first NF instance to be upgraded to deregister from the NRF.

Prior to step 301, the upgrade management entity may determine a first NF instance to upgrade.

It is understood that the first NF instance may represent one NF instance or may represent multiple NF instances. That is to say, when there are multiple NF instances of one NF to be upgraded in the network, one NF instance to be upgraded may be upgraded first, or multiple NF instances to be upgraded may be upgraded first. For example, when there are 5 NF instances of one NF to be upgraded in the network, 1 NF instance of the NF to be upgraded may be upgraded first, or 2 NF instances of the NF to be upgraded may be upgraded first, or 3 or 4 NF instances of the NF to be upgraded may be upgraded first.

Step 302, the first NF instance to be upgraded stops the service according to the first notification message.

In one example, a first NF instance to be upgraded is brought down (unregistered) from the NRF according to a first notification message.

Step 303, the upgrade management entity determines that the first NF instance to be upgraded has been out of service.

In one example, the upgrade management entity receives a third notification message from the first NF instance to be upgraded, the third notification message indicating that the first NF instance to be upgraded has completed deregistering from the NRF.

Step 304, the upgrade management entity sends a second notification message to the first NF instance to be upgraded, where the second notification message is used to indicate that the first NF instance to be upgraded is upgraded to obtain the upgraded first NF instance.

In an example, before step 304, the upgrade management entity sends a fourth notification message to the first NF instance to be upgraded, where the fourth notification message is used to instruct the first NF instance to be upgraded to migrate the carried service to a third NF instance; and the upgrade management entity receives a fifth notification message from the first NF instance to be upgraded, wherein the fifth notification message is used for indicating that the first NF instance to be upgraded finishes migrating the carried service to the third NF instance.

And 305, upgrading the first NF instance to be upgraded according to the second notification message to obtain the upgraded first NF instance.

Step 306, the upgrade management entity obtains the test result of the upgraded first NF instance.

The upgraded first NF instance can be tested by the testing cooperation NF, and the test result is sent to the upgrade management entity, or manual testing can be adopted, and the test result is manually input to the upgrade management entity.

In one example, before step 306, the upgrade management entity sends a test policy to the test coordination NF, where the test policy includes at least one of a test user range, a test flow, a test start mode, and a test exit condition; and the upgrading management entity receives the test result of the upgraded first NF instance from the test cooperation NF.

In one example, prior to step 306, the upgrade management entity determines that a test trigger condition is satisfied; and the upgrade management entity sends a sixth notification message to the test coordination NF, wherein the sixth notification message is used for indicating the test coordination NF to start a test.

In one example, the testing coordination network function NF receives a test policy from the upgrade management entity, the test policy including at least one of a test user scope, a test flow, a test start-up manner, and a test exit condition; the test cooperation NF tests the upgraded first NF example according to the test strategy to obtain a test result of the upgraded first NF example; and the test cooperation NF sends the test result of the first NF instance after being upgraded to the upgrade management entity.

Step 307, if the test result of the upgraded first NF instance is successful, the upgrade management entity determines to continue to designate a second NF instance to be upgraded for upgrading;

the upgrade management entity may send a seventh notification message to the second NF instance to be upgraded, where the seventh notification message is used to indicate that the second NF instance to be upgraded stops serving. The process of upgrading the second NF instance to be upgraded may be the same as the process of upgrading the first NF instance to be upgraded, and is not described herein again.

Or, in step 308, if the test result of the upgraded first NF instance is unsuccessful, the upgrade management entity determines to perform upgrade fallback on the upgraded first NF instance.

In one example, the NF instance to be upgraded is a service instance or a microservice instance.

The above-mentioned embodiments of the present invention have been introduced mainly from the perspective of interaction between network elements. It is understood that each network element, such as the upgrade management entity, the test coordination NF, etc., includes a hardware structure and/or a software module corresponding to each function in order to implement the above functions. Those of skill in the art will readily appreciate that the present invention can be implemented in hardware or a combination of hardware and computer software, with the exemplary elements and algorithm steps described in connection with the embodiments disclosed herein. Whether a function is performed as hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The embodiment of the present invention may perform functional module division on the upgrade management entity, the test coordination NF, and the like according to the above method example, for example, each functional module may be divided corresponding to each function, or two or more functions may be integrated in one processing module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. It should be noted that, the division of the modules in the embodiment of the present invention is schematic, and is only a logic function division, and there may be another division manner in actual implementation.

In the case of integrated modules, fig. 4 shows a schematic diagram of a possible structure of the upgrade management entity involved in the above embodiments. Upgrade management entity 400 includes: a processing module 402 and a communication module 403. The processing module 402 is used to control and manage the actions of the upgrade management entity, e.g., the processing module 402 is used to support the upgrade management entity to perform the processes 101, 102, 108, 109, 1012, and 1013 in fig. 1, the processes 201 and 209 in fig. 2, the processes 301, 303, 304, 306 to 308 in fig. 3, and/or other processes for the techniques described herein. The communication module 403 is used to support the communication between the upgrade management entity and other network entities, for example, the communication between the test coordination NF. The upgrade management entity may further include a storage module 401 for storing program code and data of the upgrade management entity.

The Processing module 402 may be a Processor or a controller, such as a Central Processing Unit (CPU), a general purpose Processor, a Digital Signal Processor (DSP), an Application-Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable logic device, a transistor logic device, a hardware component, or any combination thereof. Which may implement or perform the various illustrative logical blocks, modules, and circuits described in connection with the disclosure. The processor may also be a combination of computing functions, e.g., comprising one or more microprocessors, DSPs, and microprocessors, among others. The communication module 403 may be a communication interface, a transceiver circuit, etc., wherein the communication interface is generally referred to and may include one or more interfaces. The storage module 401 may be a memory.

When the processing module 402 is a processor, the communication module 403 is a communication interface, and the storage module 401 is a memory, the upgrade management entity according to the embodiment of the present invention may be the upgrade management entity shown in fig. 5.

Referring to fig. 5, the upgrade management entity 500 includes: a processor 502, a communication interface 503, and a memory 501. Optionally, upgrade management entity 500 may also include a bus 504. The communication interface 503, the processor 502, and the memory 501 may be connected to each other by a bus 504; the bus 504 may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus 504 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in FIG. 5, but this is not intended to represent only one bus or type of bus.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied in hardware or in software executed by a processor. The software instructions may be comprised of corresponding software modules that may be stored in Random Access Memory (RAM), flash Memory, Read Only Memory (ROM), Erasable Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), registers, a hard disk, a removable disk, a compact disc Read Only Memory (CD-ROM), or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. Of course, the storage medium may also be integral to the processor. The processor and the storage medium may reside in an ASIC. Additionally, the ASIC may reside in a core network interface device. Of course, the processor and the storage medium may reside as discrete components in a core network interface device.

Those skilled in the art will recognize that, in one or more of the examples described above, the functions described in connection with the embodiments of the invention may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.

The above-mentioned embodiments are intended to illustrate the objects, technical solutions and advantages of the embodiments of the present invention in further detail, and it should be understood that the above-mentioned embodiments are only specific embodiments of the present invention, and are not intended to limit the scope of the embodiments of the present invention.

Claims

1. A method for upgrading a network function, wherein a plurality of NF instances to be upgraded of a network function NF exist in a network, the method comprising:

the upgrading management entity sends a first notification message to a first NF instance to be upgraded, wherein the first notification message is used for indicating the first NF instance to be upgraded to stop service;

the upgrade management entity determines that the first NF instance to be upgraded is out of service;

the upgrade management entity sends a fourth notification message to the first NF instance to be upgraded, wherein the fourth notification message is used for indicating the first NF instance to be upgraded to migrate the carried service to a third NF instance;

the upgrade management entity receives a fifth notification message from the first NF instance to be upgraded, wherein the fifth notification message is used for indicating that the first NF instance to be upgraded finishes migrating the carried service to the third NF instance;

the upgrade management entity sends a second notification message to the first NF instance to be upgraded, wherein the second notification message is used for indicating the first NF instance to be upgraded to obtain the upgraded first NF instance;

the upgrade management entity obtains a test result of the upgraded first NF instance;

the test result of the upgraded first NF instance is successful, and the upgrade management entity determines to continuously designate a second NF instance to be upgraded for upgrading; or, the upgraded first NF instance is tested unsuccessfully, and the upgrade management entity determines to upgrade and rollback the upgraded first NF instance.

2. The method of claim 1, wherein the first NF instance to be upgraded is registered with a network function repository function, NRF;

the first notification message is used for indicating the first NF instance to be upgraded to stop service, and comprises the following steps:

the first notification message is used for indicating the first NF instance to be upgraded to register from the NRF;

the upgrading management entity determines that the first NF instance to be upgraded is out of service, and the upgrading management entity comprises the following steps:

the upgrade management entity receives a third notification message from the first NF instance to be upgraded, wherein the third notification message is used for indicating that the first NF instance to be upgraded is completely unregistered from the NRF.

3. The method of any of claims 1-2, wherein prior to the upgrade management entity obtaining the test results for the upgraded first NF instance, the method further comprises:

the upgrade management entity sends a test strategy to the test cooperation NF, wherein the test strategy comprises at least one of a test user range, a test flow, a test starting mode and a test export condition;

the step of obtaining the test result of the upgraded first NF instance by the upgrade management entity comprises the following steps:

and the upgrading management entity receives the test result of the upgraded first NF instance from the test cooperation NF.

4. The method of claim 3, wherein prior to the upgrade management entity receiving the test results of the upgraded first NF instance from the test coordination NF, the method further comprises:

the upgrade management entity determines that a test trigger condition is met;

and the upgrade management entity sends a sixth notification message to the test coordination NF, wherein the sixth notification message is used for indicating the test coordination NF to start a test.

5. The method of any of claims 1-2 or 4, wherein the NF instance to be upgraded is a service instance or a microservice instance.

6. An upgrade management entity, wherein a plurality of NF instances to be upgraded of a network function NF exist in a network, the upgrade management entity comprising: a processing module and a communication module;

the processing module is used for sending a first notification message to a first NF instance to be upgraded, wherein the first notification message is used for indicating the first NF instance to be upgraded to stop service; determining that the first NF instance to be upgraded has been out of service; sending a second notification message to the first NF instance to be upgraded, wherein the second notification message is used for indicating the first NF instance to be upgraded to obtain the upgraded first NF instance; obtaining a test result of the upgraded first NF example; the test result of the upgraded first NF example is successful, and the second NF example to be upgraded is determined to be continuously appointed for upgrading; or, if the test result of the upgraded first NF example is unsuccessful, determining to carry out upgrade rollback on the upgraded first NF example;

the processing module is further configured to send a fourth notification message to the first NF instance to be upgraded through the communication module before sending a second notification message to the first NF instance to be upgraded through the communication module, where the fourth notification message is used to instruct the first NF instance to be upgraded to migrate the carried service to a third NF instance; receiving, by the communication module, a fifth notification message from the first NF instance to be upgraded, where the fifth notification message is used to indicate that the first NF instance to be upgraded has completed migrating the carried service to the third NF instance.

7. The upgrade management entity according to claim 6, wherein the first NF instance to be upgraded is registered with a network function repository function NRF;

the processing module is configured to determine that the first NF instance to be upgraded has been out of service, and includes: receiving a third notification message from the first NF instance to be upgraded, wherein the third notification message is used for indicating that the first NF instance to be upgraded is completely unregistered from the NRF.

8. The upgrade management entity according to any one of claims 6 to 7, wherein the processing module is further configured to send, through the communication module, a test policy to a test coordination NF before obtaining the test result of the upgraded first NF instance, where the test policy includes at least one of a test user range, a test flow, a test start manner, and a test exit condition;

the processing module is used for obtaining the test result of the upgraded first NF example through the communication module, and the test result of the upgraded first NF example is received from the test cooperation NF through the communication module.

9. The upgrade management entity of claim 8, wherein the processing module is further configured to determine that a test trigger condition is satisfied before receiving a test result of the upgraded first NF instance from the test orchestration NF through the communication module; and sending a sixth notification message to the test coordination NF through the communication module, wherein the sixth notification message is used for indicating the test coordination NF to start a test.

10. The upgrade management entity according to any one of claims 6 to 7 or claim 9, wherein the NF instances to be upgraded are service instances or microservice instances.