# US 11,310,100 B1 · EMS resolution of split-brain virtual network function components > Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt - Number: US 11,310,100 B1 - Document ID: US11310100B1 - Status: Granted - Kind: B1 - Application number: 17/033,729 - Filed: 2020-09-26 - Granted: 2022-04-19 - Earliest claimed: 2018-01-05 - Assignees: Open Invention Network, LLC - Applicants: Open Invention Network LLC - Inventors: Keith William Melkild - Web page: https://patentgrep.com/patent/US11310100B1 ## CPC - H04L 12/4625: {Single bridge functionality, e.g. connection of two networks over a single bridge} - G06F 9/45558: {Hypervisor-specific management and integration aspects} - G06F 9/4856: {resumption being on a different machine, e.g. task migration, virtual machine migration (G06F9/5088 takes precedence)} - G06F 11/0709: {in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems} - G06F 11/0712: {in a virtual computing platform, e.g. logically partitioned systems} - G06F 11/0757: {by exceeding a time limit, i.e. time-out, e.g. watchdogs} - G06F 11/0772: {Means for error signaling, e.g. using interrupts, exception flags, dedicated error registers} - H04L 12/4641: {Virtual LANs, VLANs, e.g. virtual private networks [VPN] (LAN interconnection over a bridge based backbone H04L12/462; encapsulation techniques H04L12/4633; routing of packets H04L45/00; packet switches H04L49/00; virtual private networks for security H04L63/0272)} - H04L 41/06: Management of faults, events, alarms or notifications - H04L 41/0613: {based on the type or category of the network elements} - H04L 41/0654: using network fault recovery (ring fault isolation or reconfiguration in loop networks without recovery actions by a network management system H04L12/437) - H04L 41/0659: by isolating or reconfiguring faulty entities - H04L 41/0661: {by reconfiguring faulty entities} - H04L 41/0663: Performing the actions predefined by failover planning, e.g. switching to standby network elements - H04L 41/0668: by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure - H04L 41/0806: for initial configuration or provisioning, e.g. plug-and-play - H04L 41/0813: characterised by the conditions triggering a change of settings - H04L 41/0816: the condition being an adaptation, e.g. in response to network events - H04L 41/0873: Checking configuration conflicts between network elements - H04L 41/0895: Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements - H04L 41/342: between virtual entities, e.g. orchestrators, SDN or NFV entities - H04L 41/40: using virtualisation of network functions or resources, e.g. SDN or NFV entities - H04L 43/0817: by checking functioning - H04L 43/10: Active monitoring, e.g. heartbeat, ping or trace-route - H04L 43/20: the monitoring system or the monitored elements being virtualised, abstracted or software-defined entities, e.g. SDN or NFV - H04L 45/28: using route fault recovery - H04L 45/586: of virtual routers - H04L 45/64: using an overlay routing layer - H04L 47/746: {Reaction triggered by a failure} - H04L 49/70: {Virtual switches} - H04L 67/10: in which an application is distributed across nodes in the network (software deployment G06F8/60; multiprogramming arrangements G06F9/46) - H04L 67/104: Peer-to-peer [P2P] networks - H04L 67/1076: {Resource dissemination mechanisms or network resource keeping policies for optimal resource availability in the overlay network} - H04L 67/568: Storing data temporarily at an intermediate stage, e.g. caching - H04L 69/40: for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection (management of faults, events, alarms or notifications in data switching networks H04L41/06) - G06F 2009/4557: {Distribution of virtual machine instances; Migration and load balancing} - G06F 2009/45595: {Network integration; Enabling network access in virtual machine instances} - H04L 41/082: the condition being updates or upgrades of network functionality - H04L 43/0823: Errors, e.g. transmission errors - H04L: TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION (arrangements common to telegraphic and telephonic communication H04M) - G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N) ## Abstract An example operation may include a system, comprising one or more of receiving a virtual network function component instance (VNFCI) status notification resumption message with an active state when a peer VNFCI operational state is active, retrieving a timestamp of a VNFCI state change to an active state from an element VNFCI state database, retrieving a timestamp of a peer VNFCI state change to active from an element VNFCI state database, sending one or more of: a request to a virtual network function manager (VNFM) to determine if the VNFCI network is isolating while an operating state was active, and a request to the VNFM to determine if the peer VNFCI network is isolating while an operating state was active, sending a state change request with standby state to the peer VNFCI when the VNFCI is not network isolated and the peer VNFCI is network isolated, and a VNFM response is received regarding the VNFCI, a timeout response from the VNFM, and a VNFM response is received regarding the peer VNFCI, and sending a state change request with standby to the VNFCI with one or more of: the VNFCI network isolate and peer VNFCI is not network isolated, and the VNFCI is network isolated or the peer VNFCI is not network isolated, and the VNFCI is not network isolated and the peer VNFCI is network isolated and the VNFCI is in preferred standby. ## Claims ### Claim 1 A system, comprising: a server hosting an element management system (EMS) controlling a split-brain resolution process for one or more virtual network function component instances (VNFCI), wherein the EMS is configured to: retrieve, from an element VNFCI state database, a time that a VNFCI transitioned to an operational state of Active; retrieve, from the element VNFCI state database, a time that a peer VNFCI transitioned to an operational state of Active; and send a state change request with an attribute specifying a next state of Standby to the VNFCI in response to a virtual network function manager (VNFM) identifying that: when the VNFCI was in the Active state, the VNFCI was isolated from a network, and when the peer VNFCI was in the Active state, the peer VNFCI was not isolated from the network. ### Claim 2 (depends on 1) The system of claim 1, wherein the EMS is further configured to: send a request to the VNFM to identify that the VNFCI was isolating from the network while the peer VNFCI was in the operational state of Active. ### Claim 3 (depends on 1) The system of claim 1, wherein the EMS is further configured to: start a retry timer for the VNFCI based on the state change request being sent to the VNFCI. ### Claim 4 (depends on 3) The system of claim 3, wherein the EMS is further configured to: stop the retry timer when a state change acknowledgement is received from the VNFCI. ### Claim 5 (depends on 3) The system of claim 3, wherein the EMS is further configured to: resend the state change request to the VNFCI when the retry timer expires. ### Claim 6 (depends on 1) The system of claim 1, wherein, when the EMS is configured to retrieve a time that the VNFCI was transitioned to the operational state of Active, the EMS is further configured to: identify that the VNFCI is operating in a split-brain condition with the peer VNFCI; and retrieve the time that the VNFCI was transitioned to the operational state of Active based on the identification of the spilt-brain condition. ### Claim 7 (depends on 1) The system of claim 1, wherein, when the EMS is configured to retrieve a time that the peer VNFCI was transitioned to the operational state of Active, the EMS is further configured to: identify that the peer VNFCI is operating in a split-brain condition with the VNFCI; and retrieve the time that the peer VNFCI was transitioned to the operational state of Active based on the identification of the spilt-brain condition. ### Claim 8 A method implemented by an element management system (EMS) for controlling a split-brain resolution process for one or more virtual network function component instances (VNFCI), the method comprising: retrieving, from an element VNFCI state database, a time that a VNFCI transitioned to an operational state of Active; retrieving, from the element VNFCI state database, a time that a peer VNFCI transitioned to an operational state of Active; and sending a state change request with an attribute specifying a next state of Standby to the VNFCI in response to a virtual network function manager (VNFM) identifying that: when the VNFCI was in the Active state, the VNFCI was isolated from a network, and when the peer VNFCI was in the Active state, the peer VNFCI was not isolated from the network. ### Claim 9 (depends on 8) The method of claim 8, the method further comprising: sending a request to the VNFM to identify that the VNFCI was isolating from the network while the peer VNFCI was in the operational state of Active. ### Claim 10 (depends on 8) The method of claim 8, the method further comprising: starting a retry timer for the VNFCI based on the state change request being sent to the VNFCI. ### Claim 11 (depends on 10) The method of claim 10, the method further comprising: stopping the retry timer when a state change acknowledgement is received from the VNFCI. ### Claim 12 (depends on 10) The method of claim 10, the method further comprising: resending the state change request to the VNFCI when the retry timer expires. ### Claim 13 (depends on 8) The method of claim 8, wherein the retrieving a time that the VNFCI was transitioned to the operational state of Active further comprises: identifying that the VNFCI is operating in a split-brain condition with the peer VNFCI; and retrieving the time that the VNFCI was transitioned to the operational state of Active based on the identification of the spilt-brain condition. ### Claim 14 (depends on 8) The method of claim 8, wherein the retrieving a time that the peer VNFCI was transitioned to the operational state of Active further comprises: identifying that the peer VNFCI is operating in a split-brain condition with the VNFCI; and retrieving the time that the peer VNFCI was transitioned to the operational state of Active based on the identification of the spilt-brain condition. ### Claim 15 A non-transitory computer readable medium comprising one or more instructions that when read by a processor, of an element management system (EMS) that controls a split-brain resolution process for one or more virtual network function component instances (VNFCI), cause the processor to perform: retrieving, from an element VNFCI state database, a time that a VNFCI transitioned to an operational state of Active; retrieving, from the element VNFCI state database, a time that a peer VNFCI transitioned to an operational state of Active; and sending a state change request with an attribute specifying a next state of Standby to the VNFCI in response to a virtual network function manager (VNFM) identifying that: when the VNFCI was in the Active state, the VNFCI was isolated from a network, and when the peer VNFCI was in the Active state, the peer VNFCI was not isolated from the network. ### Claim 16 (depends on 15) The non-transitory computer readable medium of claim 15, wherein the one or more instructions further cause the processor to perform: sending a request to the VNFM to identify that the VNFCI was isolating from the network while the peer VNFCI was in the operational state of Active. ### Claim 17 (depends on 15) The non-transitory computer readable medium of claim 15, wherein the one or more instructions further cause the processor to perform: starting a retry timer for the VNFCI based on the state change request being sent to the VNFCI. ### Claim 18 (depends on 17) The non-transitory computer readable medium of claim 17, wherein the one or more instructions further cause the processor to perform: stopping the retry timer when a state change acknowledgement is received from the VNFCI. ### Claim 19 (depends on 17) The non-transitory computer readable medium of claim 17, wherein the one or more instructions further cause the processor to perform: resending the state change request to the VNFCI when the retry timer expires. ### Claim 20 (depends on 15) The non-transitory computer readable medium of claim 15, wherein the retrieving a time that the peer VNFCI was transitioned to the operational state of Active further comprises: identifying that the VNFCI is operating in a split-brain condition with the peer VNFCI, and retrieving the time that the VNFCI was transitioned to the operational state of Active based on the identification of the spilt-brain condition, and wherein the retrieving a time that the peer VNFCI was transitioned to the operational state of Active further comprises: identifying that the peer VNFCI is operating in a split-brain condition with the VNFCI and retrieving the time that the peer VNFCI was transitioned to the operational state of Active based on the identification of the spilt-brain condition.