Network function redundancy using binding header enhancements

Patent metadata

Field	Value
Publication number	US-2022303793-A1
Application number	US-202117204374-A
Country	US
Kind code	A1
Filing date	Mar 17, 2021
Priority date	Mar 17, 2021
Publication date	Sep 22, 2022
Grant date	—

Abstract

A first network function (NF) instance sends a request for a session to a second NF instance. The first NF instance receives a response, from the second NF instance, that includes a binding header that includes a failover mode identifier, a designated number of retry attempts, and a retry mode. The first NF instance sends a second request for the session to the second NF instance. The first NF instance determines if an error or a timed out response has occurred subsequent to sending the second request to the second NF instance, and re-sends, in response to the error or timed out response, the second request based on the failover mode identifier, the designated number of retry attempts and the retry mode from the binding header.

First claim

What is claimed is:

1 . A method, comprising:
sending, from a first network function (NF) instance, a first request for a session to a second NF instance; receiving a response, at the first NF instance from the second NF instance, that includes a binding header, wherein the binding header comprises a failover mode identifier, a designated number of retry attempts, and a retry mode; sending, from the first NF instance, a second request for the session to the second NF instance; determining, by the first NF instance, if an error or a timed out response has occurred subsequent to sending the second request; and re-sending, in response to the error or timed out response, the second request based on the failover mode identifier, the designated number of retry attempts, and the retry mode from the binding header.

2 . The method of claim 1 , wherein the failover mode identifier identifies whether the second NF instance operates in active-active failover mode or active-standby failover mode.

3 . The method of claim 1 , wherein the retry mode indicates a particular sequence of messaging retry attempts to be performed by the first NF instance upon an occurrence of an error or a timed out response.

4 . The method of claim 1 , wherein re-sending the second request or the command comprises:
when the retry mode comprises a first retry mode:
determining a different transport route to the second NF instance as a target NF instance for a first retry and re-sending the second request to the second NF instance via the different transport route for the first retry, and
selecting a new NF instance as the target NF instance for second and subsequent retries that do not exceed the designated number of retry attempts and re-sending the second request to the new NF instance; or
when the retry mode comprises a second retry mode:
determining a different transport route from the first NF instance to the second NF instance and re-sending the second request to the second NF instance via the different transport route.

5 . The method of claim 1 , wherein the second NF instance is a member of a NF set and wherein the retry mode indicates a particular sequence of messaging retry attempts to re-send the second request to the second NF instance or to other NF instances within the NF set.

6 . The method of claim 1 , wherein the second NF instance and a third NF instance are members of a NF set and wherein each member of the NF set is considered equivalent and interchangeable for performing a function, operation, or a service.

7 . The method of claim 6 , wherein the binding header further comprises at least one of a NF instance identifier or a NF set identifier and wherein the NF set identifier uniquely identifies the NF set.

8 . The method of claim 1 , further comprising:
extracting the failover mode identifier, the designated number of retry attempts and the retry mode, as binding header data, from the binding header; storing, by the client NF instance, the binding header data in memory for the session; and using the stored binding header data for re-sending the second request and subsequent requests or commands for the session.

9 . A device implementing a first network function (NF) instance, comprising:
a communication interface coupled to a network to:
send, by the first NF instance, a first request for a session to a second NF instance;
receive a response, from the second NF instance, that includes a binding header, wherein the binding header comprises a failover mode identifier, a designated number of retry attempts, and a retry mode;
send, by the first NF instance, a second request for the session to the second NF instance; and
a processor or logic configured to:
determine if an error or a timed out response has occurred subsequent to sending the second request or the command to the second NF instance; and
re-send, via the communication interface in response to the error or timed out response, the second request based on the failover mode identifier, the designated number of retry attempts and the retry mode from the binding header.

10 . The device of claim 9 , wherein the failover mode identifier identifies whether the second NF instance operates in active-active failover mode or active-standby failover mode.

11 . The device of claim 9 , wherein the retry mode indicates a particular sequence of messaging retry attempts to be performed by the first NF instance upon an occurrence of an error or a timed out response.

12 . The device of claim 9 , wherein, when re-sending the second request or the command, the processor or logic is further configured to:
when the retry mode comprises a first retry mode:
determine a different transport route to the second NF instance as a target NF instance for a first retry and re-send the second request to the second NF instance via the different transport route for the first retry, and
select a new NF instance as the target NF instance for second and subsequent retries that do not exceed the designated number of retry attempts and re-send the second request to the new NF instance; or
when the retry mode comprises a second retry mode:
determine a different transport route from the first NF instance to the second NF instance and re-send the second request to the second NF instance via the different transport route.

13 . The device of claim 9 , wherein the second NF instance is a member of a NF set and wherein the retry mode indicates a particular sequence of messaging retry attempts to re-send the second request to the second NF instance or to other NF instances within the NF set.

14 . The device of claim 9 , wherein the second NF instance and a third NF instance are members of a NF set and wherein each member of the NF set is considered equivalent and interchangeable for performing a function, operation, or a service.

15 . The device of claim 14 , wherein the binding header further comprises at least one of a NF instance identifier or a NF set identifier and wherein the NF set identifier uniquely identifies the NF set.

16 . The device of claim 9 , wherein the process or logic is further configured to:
extract the failover mode identifier, the designated number of retry attempts and the retry mode, as binding header data, from the binding header; store, by the client NF instance, the binding header data in memory for the session; and use the stored binding header data for re-sending the second request, and subsequent requests or commands, for the session.

17 . A non-transitory storage medium storing instructions executable by a device implementing a first network function (NF) instance, wherein the instructions comprise instructions to cause the device to:
send, from the first NF instance, a first request for a session to a second NF instance; receive a response, from the second NF instance, that includes a binding header, wherein the binding header comprises a failover mode identifier, a designated number of retry attempts, and a retry mode; send, from the first NF instance, a second request for the session to the second NF instance; determine, by the first NF instance, if an error or a timed out response has occurred subsequent to sending the second request; and re-send, in response to the error or timed out response, the second request based on the failover mode identifier, the designated number of retry attempts and the retry mode from the binding header.

18 . The non-transitory storage medium of claim 17 , wherein the failover mode identifier identifies whether the sec

Assignees

• Verizon Patent & Licensing Inc

Inventors

• PATIL Sudhakar Reddy
• Mathison James

Classifications

• H04L69/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) · CPC title

• H04L69/22 Primary

  Parsing or analysis of headers · CPC title

• H04W36/26

  by agreed or negotiated communication parameters · CPC title

• H04W76/19

  Connection re-establishment · CPC title

• H04W24/04 Primary

  Arrangements for maintaining operational condition · CPC title