Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD AND NODES FOR HANDLING UPDATES OF THE NODES
Document Type and Number:
WIPO Patent Application WO/2016/062355
Kind Code:
A1
Abstract:
The embodiments herein relate to a method for handling updates of the first node (100a) and a second node (200b). The first node (100a) detects that the replica (GW2(b)) of the second gateway node (GW2(a)) has been updated to a second version (V2). When the different versions have been detected, the first node (100a) moves PDN connections from the first gateway node (GW1(a)) to the updated replica (GW2(b)) of the second gateway node (GW2(a)). When all PDN connections have been moved, the first node is updated from to the second version (V2). The first node detects that that second gateway node (GW2(a)) and the replica (GW2(b)) of the second gateway node (GW2(a)) are both of the same second version (V2). The first node (100a) replicates at the second gateway node (GW2(a)), at least one PDN connection from the replica (GW2(b)) of the second gateway node (GW2(a)).

Inventors:
KANDERHOLM PETER (SE)
Application Number:
PCT/EP2014/072877
Publication Date:
April 28, 2016
Filing Date:
October 24, 2014
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
ERICSSON TELEFON AB L M (SE)
International Classes:
H04L45/02
Foreign References:
US20130051219A12013-02-28
US20140313881A12014-10-23
US20140018064A12014-01-16
Other References:
LUCA MARTINI SAMER SALAM ALI SAJASSI CISCO SATORU MATSUSHIMA SOFTBANK: "Inter-Chassis Communication Protocol for L2VPN PE Redundancy; draft-ietf-pwe3-iccp-16.txt", INTER-CHASSIS COMMUNICATION PROTOCOL FOR L2VPN PE REDUNDANCY; DRAFT-IETF-PWE3-ICCP-16.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 27 March 2014 (2014-03-27), pages 1 - 83, XP015098412
Attorney, Agent or Firm:
VEJGAARD, Christian (Patent Unit GLLindholmspiren 11, Göteborg, SE)
Download PDF:
Claims:
CLAIMS

1 . A method performed by a first node (100a) for handling updates of the first node (100a) and a second node (200b) in a communications system,

wherein the first node (100a) comprises a first gateway node (GW1 (a)) and a second gateway node (GW2(a)),

wherein the first gateway node (GW1 (a)) in the first node (100a) and a replica (GW1 (b)) of the first gateway node (GW1 (a)) comprised in the second node (200b) are Inter Chassis Redundancy, ICR, peer nodes defining a first ICR pair,

wherein the second gateway node (GW2(a)) and a replica (GW2(b)) of the second gateway node (GW2(a)) in the second node (200b) are ICR peer nodes defining a second ICR pair,

wherein the first gateway node (GW1 (a)) is an ICR active node and the replica (GW1 (b)) of the first gateway node (GW1 (a)) is an ICR standby node in the first ICR pair, the method comprising:

detecting (405, 515, 607, 706) that the replica (GW2(b)) of the second gateway node (GW2(a)) which is in a same pool of gateways as the first gateway node (GW1 (a)) has been updated to a second version (V2), wherein the second version (V2) is different than a first version (V1 ), and wherein the first gateway node GW1 (a)) is of the first version (V1 );

when the different versions have been detected, moving (407, 517, 609, 707) at least one Packet Data Network, PDN, connection from the first gateway node (GW1 (a)) to the updated replica (GW2(b)) of the second gateway node (GW2(a)) in the second node (200b);

when substantially all PDN connections have been moved away from the first gateway node (GW1 (a)), updating (408, 518, 610, 708) the first node (100a) from the first version (V1 ) to the second version (V2);

detecting (409, 523, 612, 71 1 ) the ICR peer node of the second gateway node (GW2(a)) in the second ICR pair, and that second gateway node (GW2(a)) and the replica (GW2(b)) of the second gateway node (GW2(a)) defining the second ICR pair are both of the same second version (V2); and

replicating (410, 524, 614, 713), at the second gateway node (GW2(a)), at least one PDN connection from the replica (GW2(b)) of the second gateway node (GW2(a)).

2. The method according to claim 1 , further comprising:

receiving (401 , 505, 601 , 701 ) instructions to update from the first version (V1 ) to the second version (V2); and

transmitting (402, 506, 507, 602, 702) the instructions to update to the second node (200b).

3. The method according to any one of claims 1 -2, wherein the first gateway node (GW1 (a)) refuses or forwards any new PDN connections after the detection of the update to the second version (V2) of the second node (200b).

4. The method according to any one of claims 1 -3, wherein the first gateway node (GW1 (a)) and the second gateway node (GW2(a)) are gateway node configurations which are both activated at the same time in the first node (100a). 5. The method according to any one of claims 1 -4, wherein the first gateway node (GW1 (a)) and the second gateway node (GW2(a)) are different gateway node

configurations between which the first node (100a) can switch such that the first gateway node (GW1 ) configuration is activated and the second gateway node (GW2) configuration is deactivated or the second gateway node (GW2) configuration is activated and the first gateway node configuration (GW1 ) is deactivated.

6. The method according to claim 5, further comprising:

activating (61 1 , 709) the second gateway node (GW2) configuration; and deactivating (61 1 , 710) the first gateway node (GW1 ) configuration.

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

if the ICR peer node of the second gateway node (GW2(a)) is not detectable, switching over (509, 703) the second gateway node (GW2(a)) from being the ICR standby node to become the ICR active node.

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

if it has been detected that both the second gateway node (GW2(a)) and the replica (GW2(b)) of the second gateway node (GW2(a)) defining the second ICR pair are ICR active nodes, receiving (512, 704) instructions from the second node (200b) to switchover the second gateway node (GW2(a)) from being the ICR active node to become the ICR standby node; and

switching over (512, 705) the second gateway node (GW2(a)) from being the ICR active node to become the ICR standby node.

9. The method according to any one of claims 1 -8, further comprising:

if it has been detected that both the first gateway node (GW1 (a)) and the replica (GW1 (b)) of the first gateway node (GW1 (a)) defining the first ICR pair are ICR active nodes, sending (522, 712) instructions to the second node (200b) to switchover the replica (GW1 (b)) of the first gateway node (GW1 (a)) from being the ICR active node to become the ICR standby node.

10. The method according to any one of claims 1 -9, wherein the wherein the at least one PDN connection is moved from the first gateway node (GW1 (a)) to the replica (GW2(b)) of the second gateway node (GW2(a)) using a pool of gateways function or using a Serving GateWay, SGW, relocation function.

1 1. The method according to any one of claims 1 -10, wherein at least one of hardware and software comprised in the first node (100a) is updated from the first version (V1 ) to the second version (V2).

12. A method performed by a second node (200a) for handling updates of the second node (200b) and a first node (100a) in a communications system,

wherein the second node (200b) comprises a replica (GW1 (b)) of a first gateway node (GW1 (a)) and a replica (GW2(b)) of a second gateway node (GW2(a)),

wherein the replica (GW1 (b)) of the first gateway node (GW1 (a)) in the second node (200b) and a first gateway node (GW1 (a)) in the first node (100a) are Inter Chassis Redundancy, ICR, peer nodes defining a first ICR pair,

wherein the replica (GW2(b)) of the second gateway node (GW2(a)) in the second node (200b) and a second gateway node (GW2(a)) in the first node (100a) are ICR peer nodes defining a second ICR pair,

wherein the replica (GW1 (b)) of the first gateway node (GW1 (a)) is an ICR standby node and the first gateway node (GW1 (a)) is an ICR active node in the first ICR pair, the method comprising: updating (403, 508, 603) the second node (200b) from a first version (V1 ) to a second version (V2);

when the second node (200b) has been updated to the second version (V2), handling (404, 513, 606) at least one new Packet Data Network, PDN, connection;

5 detecting (405, 515, 607) that the first gateway node (GW1 (a)) which is in a same pool of gateways as the replica (GW2(b)) of the second gateway node (GW2(a)) is of the first version (V1 ) which is different than the second version (V2) of the replica (GW2(b)) of the second gateway node (GW2(a));

when the different versions have been detected, receiving (407, 517, 609), at the 10 updated replica (GW2(b)) of the second gateway node (GW2(a)), at least one Packet Data Network, PDN, connection from the first gateway node (GW1 (a)) in the first node (100a);

detecting (409, 523, 612) the ICR peer node of the replica (GW2(b)) of the second gateway node (GW2(a)) in the second ICR pair, and that the replica (GW2(b)) of the 15 second gateway node (GW2(a)) and the second gateway node (GW2(a)) defining the second ICR pair are both of the same second version (V2); and

replicating (410, 524, 614) at least one PDN connection from the replica (GW2(b)) of the second gateway node (GW2(a)) to the second gateway node (GW2(a)).

20 13. The method according to claim 12, further comprising:

receiving (402, 506, 507, 602), from the first node (100a) instructions to update from the first version (V1 ) to the second version (V2).

14. The method according to any one of claims 12-13, wherein the replica (GW2(b) of the 25 second gateway node (GW2(a)) handles substantially all existing and new PDN

connections after the detection of the different versions.

15. The method according to any one of claims 12-14, wherein the replica (GW1 (b)) of the first gateway node (GW1 (a)) and the replica (GW2(b)) of the second gateway node

30 (GW2(a)) are gateway node configurations which both activated at the same time in the second node (200b).

16. The method according to any one of claims 12-15, wherein the replica (GW1 (b)) of the first gateway node (GW1 (a)) and the replica (GW2(b)) of the second gateway node (GW2(a)) are different gateway node configurations between which the second node (200b) can switch such that the first gateway node (GW1 ) configuration is activated and the second gateway node (GW2) configuration is deactivated or the second gateway node (GW2) configuration is activated and the first gateway node configuration (GW1 ) is deactivated.

17. The method according to claim 16, further comprising:

activating (604) the second gateway node (GW2) configuration; and

deactivating (604) the first gateway node (GW1 ) configuration.

18. The method according to any one of claims 12-17, further comprising:

if it has been detected that both the second gateway node (GW2(a)) and the replica (GW2(b)) of the second gateway node (GW2(a)) defining the second ICR pair are ICR active nodes, sending (512) instructions to the second node (200b) to switchover the second gateway node (GW2(a)) from being the ICR active node to become the ICR standby node.

19. The method according to any one of claims 12-18, further comprising:

if the ICR peer node of the replica (GW1 (b)) of the first gateway node (GW1 (a)) is not detectable, switching over (519) the replica (GW1 (b)) of the first gateway node (GW1 (a)) from being the ICR standby node to become the ICR active node.

20. The method according to any one of claims 12-19, further comprising:

if it has been detected that both the first gateway node (GW1 (a)) and the replica (GW1 (b)) of the first gateway node (GW1 (a)) defining the first ICR pair are ICR active nodes, recieving (522) instructions from the first node (100a) to switchover the replica (GW1 (b)) of the first gateway node (GW1 (a)) from being the ICR active node to become the ICR standby node; and

switching over (522) the replica (GW1 (b)) of the first gateway node (GW1 (a)) from being the ICR active node to become the ICR standby node.

21. The method according to any one of claims 12-20, wherein the wherein the at least one PDN connection is received from the first gateway node (GW1 (a)) using a pool of gateways function or using a Serving GateWay, SGW, relocation function.

22. The method according to any one of claims 12-21 , wherein at least one of hardware and software comprised in the first node (100a) is updated from the first version (V1 ) to the second version (V2).

23. A first node (100a) for handling updates of the first node (100a) and a second node (200b) in a communications system,

wherein the first node (100a) comprises a first gateway node (GW1 (a)) and a second gateway node (GW2(a)),

wherein the first gateway node (GW1 (a)) in the first node (100a) and a replica (GW1 (b)) of the first gateway node (GW1 (a)) comprised in the second node (200b) are Inter Chassis Redundancy, ICR, peer nodes defining a first ICR pair,

wherein the second gateway node (GW2(a)) and a replica (GW2(b)) of the second gateway node (GW2(a)) in the second node (200b) are ICR peer nodes defining a second ICR pair,

wherein the first gateway node (GW1 (a)) is an ICR active node and the replica (GW1 (b)) of the first gateway node (GW1 (a)) is an ICR standby node in the first ICR pair, the first node (100a) being configured to:

detect that the replica (GW2(b)) of the second gateway node (GW2(a)) which is in a same pool of gateways as the first gateway node (GW1 (a)) has been updated to a second version (V2), wherein the second version (V2) is different than a first version (V1 ), and wherein the first gateway node GW1 (a)) is of the first version (V1 );

when the different versions have been detected, move at least one Packet Data Network, PDN, connection from the first gateway node (GW1 (a)) to the updated replica (GW2(b)) of the second gateway node (GW2(a)) in the second node (200b);

when substantially all PDN connections have been moved away from the first gateway node (GW1 (a)), update the first node (100a) from the first version (V1 ) to the second version (V2);

detect the ICR peer node of the second gateway node (GW2(a)) in the second ICR pair, and that second gateway node (GW2(a)) and the replica (GW2(b)) of the second gateway node (GW2(a)) defining the second ICR pair are both of the same second version (V2); and

replicate, at the second gateway node (GW2(a)), at least one PDN connection from the replica (GW2(b)) of the second gateway node (GW2(a)).

24. The first node (100a) according to claim 23, being further configured to: receive instructions to update from the first version (V1 ) to the second version (V2); and to

5 transmit the instructions to update to the second node (200b).

25. The first node (100a) according to any one of claims 23-24, wherein the first gateway node (GW1 (a)) is configured to refuse or forward any new PDN connections after the detection of the update to the second version (V2) of the second node (200b).

10

26. The first node (100a) according to any one of claims 23-25, wherein the first gateway node (GW1 (a)) and the second gateway node (GW2(a)) are gateway node configurations which are both activated at the same time in the first node (100a).

15 27. The first node (100a) according to any one of claims 23-26, wherein the first gateway node (GW1 (a)) and the second gateway node (GW2(a)) are different gateway node configurations between which the first node (100a) can switch such that the first gateway node (GW1 ) configuration is activated and the second gateway node (GW2) configuration is deactivated or the second gateway node (GW2) configuration is activated and the first

20 gateway node configuration (GW1 ) is deactivated.

28. The first node (100a) according to claim 27, being further configured to:

activate the second gateway node (GW2) configuration; and

deactivate the first gateway node (GW1 ) configuration.

25

29. The first node (100a) according to any one of claims 23-28, being further configured to:

if the ICR peer node of the second gateway node (GW2(a)) is not detectable, switchover the second gateway node (GW2(a)) from being the ICR standby node to 30 become the ICR active node.

30. The first node (100a) according to any one of claims 23-29, being further configured to: if it has been detected that both the second gateway node (GW2(a)) and the replica (GW2(b)) of the second gateway node (GW2(a)) defining the second ICR pair are ICR active nodes, receive instructions from the second node (200b) to switchover the second gateway node (GW2(a)) from being the ICR active node to become the ICR standby node; and to

switchover the second gateway node (GW2(a)) from being the ICR active node to become the ICR standby node.

31. The first node (100a) according to any one of claims 23-30, being further configured to:

if it has been detected that both the first gateway node (GW1 (a)) and the replica (GW1 (b)) of the first gateway node (GW1 (a)) defining the first ICR pair are ICR active nodes, send instructions to the second node (200b) to switchover the replica (GW1 (b)) of the first gateway node (GW1 (a)) from being the ICR active node to become the ICR standby node.

32. The first node (100a) according to any one of claims 23-31 , wherein the wherein the at least one PDN connection is moved from the first gateway node (GW1 (a)) to the replica (GW2(b)) of the second gateway node (GW2(a)) using a pool of gateways function or using a Serving GateWay, SGW, relocation function.

33. The first node (100a) according to any one of claims 23-32, wherein at least one of hardware and software comprised in the first node (100a) is updated from the first version (V1 ) to the second version (V2).

34. A second node (200a) for handling updates of the second node (200b) and a first node (100a) in a communications system,

wherein the second node (200b) comprises a replica (GW1 (b)) of a first gateway node (GW1 (a)) and a replica (GW2(b)) of a second gateway node (GW2(a)),

wherein the replica (GW1 (b)) of the first gateway node (GW1 (a)) in the second node (200b) and a first gateway node (GW1 (a)) in the first node (100a) are Inter Chassis Redundancy, ICR, peer nodes defining a first ICR pair, wherein the replica (GW2(b)) of the second gateway node (GW2(a)) in the second node (200b) and a second gateway node (GW2(a)) in the first node (100a) are ICR peer nodes defining a second ICR pair,

wherein the replica (GW1 (b)) of the first gateway node (GW1 (a)) is an ICR standby node and the first gateway node (GW1 (a)) is an ICR active node in the first ICR pair, the second node (200b) is configured to:

update the second node (200b) from a first version (V1 ) to a second version (V2); when the second node (200b) has been updated to the second version (V2), handle at least one new Packet Data Network, PDN, connection;

detect that the first gateway node (GW1 (a)) which is in a same pool of gateways as the replica (GW2(b)) of the second gateway node (GW2(a)) is of the first version (V1 ) which is different than the second version (V2) of the replica (GW2(b)) of the second gateway node (GW2(a));

when the different versions have been detected, receive, at the updated replica (GW2(b)) of the second gateway node (GW2(a)), at least one Packet Data Network, PDN, connection from the first gateway node (GW1 (a)) in the first node (100a);

detect the ICR peer node of the replica (GW2(b)) of the second gateway node (GW2(a)) in the second ICR pair, and that the replica (GW2(b)) of the second gateway node (GW2(a)) and the second gateway node (GW2(a)) defining the second ICR pair are both of the same second version (V2); and to

replicate at least one PDN connection from the replica (GW2(b)) of the second gateway node (GW2(a)) to the second gateway node (GW2(a)).

35. The second node (200a) according to claim 34, being further configured to:

receive, from the first node (100a) instructions to update from the first version (V1 ) to the second version (V2).

36. The second node (200a) according to any one of claims 34-35, wherein the replica (GW2(b) of the second gateway node (GW2(a)) is configured to handle substantially all existing and new PDN connections after the detection of the different versions.

37. The second node (200a) according to any one of claims 34-36, wherein the replica (GW1 (b)) of the first gateway node (GW1 (a)) and the replica (GW2(b)) of the second gateway node (GW2(a)) are gateway node configurations which both activated at the same time in the second node (200b).

38. The second node (200a) according to any one of claims 34-37, wherein the replica 5 (GW1 (b)) of the first gateway node (GW1 (a)) and the replica (GW2(b)) of the second gateway node (GW2(a)) are different gateway node configurations between which the second node (200b) can switch such that the first gateway node (GW1 ) configuration is activated and the second gateway node (GW2) configuration is deactivated or the second gateway node (GW2) configuration is activated and the first gateway node configuration 10 (GW1 ) is deactivated.

39. The second node (200a) according to claim 38, being further configured to:

activate the second gateway node (GW2) configuration; and to

deactivate the first gateway node (GW1 ) configuration.

15

40. The second node (200a) according to any one of claims 34-39, being further configured to:

if it has been detected that both the second gateway node (GW2(a)) and the replica (GW2(b)) of the second gateway node (GW2(a)) defining the second ICR pair are 20 ICR active nodes, send instructions to the second node (200b) to switchover the second gateway node (GW2(a)) from being the ICR active node to become the ICR standby node.

41. The second node (200a) according to any one of claims 34-40, being further

25 configured to:

if the ICR peer node of the replica (GW1 (b)) of the first gateway node (GW1 (a)) is not detectable, switchover the replica (GW1 (b)) of the first gateway node (GW1 (a)) from being the ICR standby node to become the ICR active node.

30 42. The second node (200a) according to any one of claims 34-41 , being further

configured to:

if it has been detected that both the first gateway node (GW1 (a)) and the replica (GW1 (b)) of the first gateway node (GW1 (a)) defining the first ICR pair are ICR active nodes, receive instructions from the first node (100a) to switchover the replica (GW1 (b)) of the first gateway node (GW1 (a)) from being the ICR active node to become the ICR standby node; and to

switchover the replica (GW1 (b)) of the first gateway node (GW1 (a)) from being the ICR active node to become the ICR standby node.

5

43. The second node (200a) according to any one of claims 34-42, wherein the wherein the at least one PDN connection is configured to be received from the first gateway node (GW1 (a)) using a pool of gateways function or using a Serving GateWay, SGW, relocation function.

10

44. The second node (200a) according to any one of claims 34-43, wherein at least one of hardware and software comprised in the first node (100a) is updated from the first version (V1 ) to the second version (V2).

15 45. A first computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 1 -1 1 .

46 A first carrier comprising the first computer program of claim 45, wherein the carrier is 20 one of an electronic signal, optical signal, radio signal or computer readable storage

medium.

47. A second computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any

25 one of claims 12-22.

48. A second carrier comprising the second computer program of claim 47, wherein the carrier is one of an electronic signal, optical signal, radio signal or computer readable storage medium.

30

Description:
METHOD AND NODES FOR HANDLING UPDATES OF THE NODES

TECHNICAL FIELD Embodiments herein relate generally to a first node, a method in the first node, a second node and a method in the second node. More particularly the embodiments herein relate to handling updates of the first node and the second node.

BACKGROUND

In a communications system, User Equipments (UEs) communicate with one or more Core Networks (CNs) via one or more Radio Access Network(s) (RAN). The

communications system may also be referred to as e.g. a wireless communications network, a wireless communications system, a communications network, a network or a system.

The UE may be a device by which a subscriber may access services offered by an operator's network and services outside operator's network to which the operator's radio access network and core network provide access, e.g. access to the Internet. The UE may be any device, mobile or stationary, enabled to communicate over a radio channel in the communications network, for instance but not limited to e.g. user equipment, mobile phone, smart phone, sensors, meters, vehicles, household appliances, medical appliances, media players, cameras, Machine to Machine (M2M) device, Internet of Things (loT) device or any type of consumer electronic, for instance but not limited to television, radio, lighting arrangements, tablet computer, laptop or Personal Computer (PC). The UE may be portable, pocket storable, hand held, computer comprised, or vehicle mounted devices, enabled to communicate voice and/or data, via the radio access network, with another entity, such as another UE or a server.

The RAN covers a geographical area which may be divided into cell areas, with each cell area being served by a RAN node. In some RANs, the RAN node is e.g. called base station, NodeB, B node, enhanced NodeB (eNB, eNodeB), Radio Network Controller (RNC), Base Station Controller (BSC) etc. A cell may be described as a geographical area where radio coverage is provided by the equipment of a RAN node at a RAN node site. Each cell may be identified by an identity within the local radio area, which may be broadcasted in the cell. The RAN nodes communicate via an air interface with UEs within range of the RAN nodes.

The CN, to which the UEs communicate via the RAN, comprises a number of core network nodes. One such CN node is a network gateway node. The network gateway node provides connectivity for the UEs of the communication network to one or more external Packet Data Networks (PDNs). A UE may have simultaneous connectivity with more than one network gateway node for accessing multiple PDNs. The network gateway node may e.g. be a Gateway GPRS Support Node (GGSN) or a PDN Gateway (PGW).

Typically the network gateway provides PDN connectivity by creating a PDN connection for a radio terminal to a PDN served by the network gateway. The PDN connection may be requested by the UE, e.g. by sending a message to the network gateway, e.g. a PDN Connectivity Request message or similar.

An Access Point Name (APN) is used to identify the PDN to which the PDN connection is to be created for the UE. Thus, a PDN connection is a connection for a UE to a PDN identified by an APN.

The CN may also comprise other types of gateway nodes such as e.g. a Serving

GateWay (SGW), a Mobilty Management Entity (MME), a Policy and Charging Rules Function (PCRF) node etc.

As more high-priority voice and video traffic is carried on a communications network, Inter-Chassis Redundancy (ICR) is a feature which has become a valuable for providing redundancy on network nodes such as e.g. routers, gateways, servers etc. With ICR, pairs of nodes may be configured to act as standbys for each other. For example, one network node functions as an active ICR node while another network node functions as a standby ICR node that is configured to take over at least some operations (e.g., traffic routing operations) of the active ICR node. The taking over of by the standby ICR node may be referred to as a switchover and may be triggered by e.g. failure of a network link or component of the active ICR node and/or by a network operator (e.g. taking an active ICR node off-line to perform a software/hardware update or other maintenance). The active ICR node handles routing of Internet Protocol (IP) network traffic until it becomes non-functional, at which time switchover occurs with the standby ICR node taking over at least some functionality that was performed by the non-functional ICR node (with the standby ICR node then becoming an active ICR node).

As mentioned above, a standby ICR node may take over at least some operations of an active ICR node in when software/hardware update is to be performed. In Service Software Upgrade (ISSU) is a term used for updating software on a network node without taking that node offline and thereby disrupting network services.

SUMMARY An objective of embodiments herein is therefore to obviate at least one of the above disadvantages and to provide improved handling of upgrading of nodes.

According to a first aspect, the object is achieved by a method performed by a first node for handling updates of the first node and a second node in a communications system. The first node comprises a first gateway node and a second gateway node. The first gateway node in the first node and a replica of the first gateway node comprised in the second node are ICR peer nodes defining a first ICR pair. The second gateway node and a replica of the second gateway node in the second node are ICR peer nodes defining a second ICR pair. The first gateway node is an ICR active node and the replica of the first gateway node is an ICR standby node in the first ICR pair. The first node detects that the replica of the second gateway node which is in a same pool of gateways as the first gateway node has been updated to a second version. The second version is different than a first version. The first gateway node is of the first version. When the different versions have been detected, the first node moves at least one PD, connection from the first gateway node to the updated replica of the second gateway node in the second node. When substantially all PDN connections have been moved away from the first gateway node, the first node updates the first node from the first version to the second version. The first node detects the ICR peer node of the second gateway node in the second ICR pair, and that second gateway node and the replica of the second gateway node defining the second ICR pair are both of the same second version. The first node replicates, at the second gateway node, at least one PDN connection from the replica of the second gateway node. According to a second aspect, the object is achieved by a method performed by a second node for handling updates of the second node and a first node in a communications system. The second node comprises a replica of a first gateway node and a replica of a second gateway node. The replica of the first gateway node in the second node and a first gateway node in the first node are ICR peer nodes defining a first ICR pair. The replica of the second gateway node in the second node and a second gateway node in the first node are ICR peer nodes defining a second ICR pair. The replica of the first gateway node is an ICR standby node and the first gateway node is an ICR active node in the first ICR pair. The second node updates the second node from a first version to a second version. When the second node has been updated to the second version, the second node handles at least one new PDN connection. The second node detects that the first gateway node which is in a same pool of gateways as the replica of the second gateway node is of the first version which is different than the second version of the replica of the second gateway node. When the different versions have been detected, the second node receives, at the updated replica of the second gateway node, at least one PDN connection from the first gateway node in the first node. The second node detects the ICR peer node of the replica of the second gateway node in the second ICR pair, and that the replica of the second gateway node and the second gateway node defining the second ICR pair are both of the same second version. The second node replicates at least one PDN connection from the replica of the second gateway node to the second gateway node.

According to a third aspect, the object is achieved by a first node for handling updates of the first node and a second node in a communications system. The first node comprises a first gateway node and a second gateway node. The first gateway node in the first node and a replica of the first gateway node comprised in the second node are ICR peer nodes defining a first ICR pair. The second gateway node and a replica of the second gateway node in the second node are ICR peer nodes defining a second ICR pair. The first gateway node is an ICR active node and the replica of the first gateway nod is an ICR standby node in the first ICR pair. The first node is configured to detect that the replica of the second gateway node which is in a same pool of gateways as the first gateway node has been updated to a second version. The second version is different than a first version. The first gateway node is of the first version. The first node is configured to move at least one PDN connection from the first gateway node to the updated replica of the second gateway node in the second node when the different versions have been detected. The first node is further configured to update the first node from the first version to the second version when substantially all PDN connections have been moved away from the first gateway node. The first node is configured to detect the ICR peer node of the second gateway node in the second ICR pair, and that second gateway node and the replica of the second gateway node defining the second ICR pair are both of the same second version. The first node is configured to replicate, at the second gateway node, at least one PDN connection from the replica (GW2(b)) of the second gateway node.

According to a fourth aspect, the object is achieved by a second node for handling updates of the second node and a first node in a communications system. The second node comprises a replica of a first gateway node and a replica of a second gateway node. The replica of the first gateway node in the second node and a first gateway node in the first node are ICR peer nodes defining a first ICR pair. The replica of the second gateway node in the second node and a second gateway node in the first node are ICR peer nodes defining a second ICR pair. The replica of the first gateway node is an ICR standby node and the first gateway node is an ICR active node in the first ICR pair. The second node is configured to update the second node from a first version to a second version. The second node is configured to handle at least one new PDN connection when the second node has been updated to the second version. The second node is configured to detect that the first gateway node which is in a same pool of gateways as the replica of the second gateway node is of the first version which is different than the second version of the replica of the second gateway node. The second node is further configured to receive, at the updated replica of the second gateway node, at least one PDN connection from the first gateway node in the first node when the different versions have been detected. The second node is configured to detect the ICR peer node of the replica of the second gateway node in the second ICR pair, and that the replica of the second gateway node and the second gateway node defining the second ICR pair are both of the same second version. The second node is configured to replicate at least one PDN connection from the replica of the second gateway node to the second gateway node. Since the embodiments herein combines the ICR functionality with wither the pool of gateways functionality or the SGW relocation functionality within the same node, the upgrading of nodes is improved because the upgrade of the nodes does not expose the internal data structures, architecture and hardware changes between version releases.

Embodiments herein afford many advantages, of which a non-exhaustive list of examples follows: An advantage of the embodiments herein is that they may make it possible for network operators that are running their network with geo-redundant 1 +1 ICR gateway nodes to upgrade their nodes in service (ISSU) without the need to purchase, install and maintain additional standby gateway hardware nodes. A further advantage of the embodiments herein is that they may make it possible for the Gateway development organization to save development resources and money by not having to develop, test and maintain internal data conversion functionality for every software release. Another advantage of the embodiments herein is that they may reduce the risk of failing upgrades due to data conversion errors.

Yet a further advantage of the embodiments herein is that they do not put any restriction on what changes of internal data structures, architecture and hardware is possible between releases.

The embodiments herein are not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS The embodiments herein will now be further described in more detail in the following detailed description by reference to the appended drawings illustrating the embodiments and in which: Fig. 1 is a schematic block diagram illustrating example embodiments of a

communication system.

Fig. 2 is a schematic block diagram illustrating example embodiments for

upgrading using an ICR pair (alternative 1 ).

Fig. 3 is a schematic block diagram illustrating example embodiments for

upgrading using an ICR pair and one or more external gateway pool node (alternative 2). Fig. 4 is a signaling diagram illustrating example embodiments of a method for upgrading nodes.

Fig. 5a-c are signaling diagrams illustrating example embodiments of a method for upgrading nodes using ICR and a gateway pool in the same node at the same time (alternative 3).

Fig. 6 is a signaling diagram illustrating example embodiments of a method for upgrading nodes using ICR and a gateway pool in the same node but not at the same time (alternative 4).

Fig. 7 is a signaling diagram illustrating embodiments of a method performed by a first node.

Fig. 8 is a schematic block diagram illustrating embodiments of a first node.

Fig. 9 is a signaling diagram illustrating embodiments of a method performed by a second node.

Fig. 10 is a schematic block diagram illustrating embodiments of a second node. The drawings are not necessarily to scale and the dimensions of certain features may have been exaggerated for the sake of clarity. Emphasis is instead placed upon illustrating the principle of the embodiments herein.

DETAILED DESCRIPTION

When studying a solution for In Service Software Upgrades (ISSU) for gateway nodes, it is determined that a solution for upgrading geo-redundant gateways, using the Inter Chassis Redundancy (ICR) 1 +1 setup with one active and one standby ICR gateway, is needed. Especially in the near future with frequent software deliveries (i.e. On Demand Software Delivery (ODSD)) and the introduction of Voice over Long Term Evolution (VoLTE) functionality will require ISSU support in the gateway nodes.

The embodiments herein present a solution for upgrading ICR nodes by combining the ICR functionality with the Pool of Gateway functionality or the SGW relocation

functionality. A pool of gateways is a pool which comprises a plurality of gateway nodes. Each gateway node is configured to operatively serve one or more APNs so as to create a PDN connection for a UE served by a gateway to a PDN identified by an APN. In relation to a pool of gateways, there are a number of functions which are applied. One such function may be referred to as pool move which refers to that existing PDN connections is moved from one gateway node to another gateway node in the gateway pool. Another such function may be referred to as pool forward, which refers to that any creation of a new PDN connection is forwarded from one gateway node to another gateway node in the gateway pool. SGW relocation is a function triggered by a MME/SGSN. In case that a SGW does not support ISSU, there is a need to relocate subscribers to another SGW before the SGW upgrades. Not doing so may result in service impact during SGW upgrade which is seen a problem for VoLTE launch (especially for ongoing emergency calls). To be able to empty an SGW, the SGW must be blocked in SGSN-MME, to avoid that new UEs are added to the SGW. A SGW relocation may take place in parallel with a pool move.

Bearers, on UE level, may be relocated from a Source SGW to a Target SGW.

A schematic overview of a communications system implementing ICR is shown in Figure 1. A first node 100a is located at site A and a second node 200b is located at site B. Site A is at some geographical distance from site B, i.e. the first and second nodes 100a, 200b are located at different geographical locations. The first node 100a and the second node 200b are redundant nodes, i.e. they are identical except from that they are located at different geographical locations. These nodes may therefore be described as being duplicates, copies, replicas etc.

In some embodiments, the first node 100a and the second node 200b may each be e.g. a Serving GateWay (SGW) or a Packet data network GateWay (PGW) or a combined SGW and PGW node (SGW/PGW) or a Gateway GPRS Support Node (GGSN). GPRS is short for General Packet Radio Service. In other embodiments, the first node 100 and the second node 200b may each be a hardware chassis without being any specific type of hardware. An overview of some example embodiments of the first and second nodes 100a, 200b is illustrated in Table 1 below. Note that any other suitable embodiments of the first and second nodes 100a, 200b not shown in the table below are also applicable.

Table 1

First node 100a Second node 200b

SGW SGW

SGW PGW

SGW SGW/PGW

SGW GGSN

PGW PGW

PGW SGW

PGW SGW/PGW

PGW GGSN

SGW/PGW SGW/PGW

SGW/PGW SGW

SGW/PGW PGW SGW/PGW GGSN

GGSN GGSN

GGSN SGW

GGSN PGW

GGSN SGW/PGW

The first node 100a comprises at least one of a first gateway node GW1(a) and a second gateway node GW1(a). The letter a in the reference numbers indicates that they are located at site A. The second node 200b comprises at least one of a replica GW1 (b) of the first gateway node GW1 (b) and a replica GW2(b) of the second gateway node GW2(a). The letter b in the reference numbers indicates that they are located at site B. Sites A and B are different geographical locations

The replica GW1 (b) of the first gateway node GW1 (a) may be substantially identical to the first gateway node GW1 (a) except from that it is located at a different geographical location, e.g. site B. When using the reference number GW1 it refers to any of the first gateway nodes, i.e. either the one located in the first node 100a or the replica located in the second node 200b. The replica GW2(b) of the second gateway node GW2(a) may be substantially identical to the second gateway node GW2(a) except from that it is located at a different geographical location, e.g. site B. When using the reference number GW2 it refers to any of the second gateway nodes, i.e. either the one located in the first node 100a or the replica located in the second node 200b.

In one embodiment, the first gateway node GW1 (a) and the second gateway node GW2(a) are two gateway nodes configured within the same node (e.g. the first node 100a) at the same time, e.g. in one hardware chassis. The replica GW1 (b) of the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) may also be seen as two gateway nodes configured within another node at the same time (e.g. the second node 200b), such as e.g. the same hardware chassis. In such embodiment, all four gateway nodes are configured and activated at the same time in each respective node 100a, 200b.

In another embodiment, the first gateway node GW1 (a) and the second gateway node GW2(a) are different gateway configurations. The first node 100a can switch between these two configurations such that the first gateway node GW1 (a) configuration is activated and the second gateway node GW2(a) configuration is deactivated or blocked, or opposite. Similar for the second node 200b, where the replica GW1 (b) of the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) are different gateway configurations which the second node 200b can switch between. In such embodiment, the replica GW1 (b) of the first gateway node GW1 (a) is activated and the replica GW2(b) of the second gateway node GW2(a) is deactivated or blocked, or opposite. Only one gateway node configuration is activated in a node, i.e. either the first or second gateway node configuration. Both gateway node configurations will never be activated at the same time in such embodiment.

The first gateway node GW1 (a) may be a SGW or a PGW or a combined SGW and PGW or a GGSN. The replica GW1 (b) of the first gateway node GW1 (a) may be a SGW or a PGW or a combined SGW and PGW node or a GGSN. The second gateway node GW2(a) may be a SGW or a PGW or a combined SGW and PGW node or a GGSN. The replica GW2(b) of the second gateway node GW2(a) may be a SGW or a PGW or a combined SGW and PGW node or a GGSN. Table 2 below shows some example embodiments of the first gateway node GW1 (a), the replica GW1 (b) of the first gateway node GW1 (a), the second gateway node GW2(a) and the replica GW2(b) of the second gateway node GW2(a). If some of the examples in Table 2 are implemented, the first node 100a and the second node 200b may each be a hardware chassis not representing any particular type of node. Note that any other implementations of the gateway nodes are also applicable instead of the ones exemplified in Table 2. Table 2

First gateway node Replica GW1 (b) of Second gateway Replica GW2(b) of GW1 (a) first gateway node node GW2(a) second gateway

GW1 (a) node GW2(a)

SGW SGW SGW SGW

PGW PGW PGW PGW

SGW/PGW SGW/PGW SGW/PGW SGW/PGW

GGSN GGSN GGSN GGSN ICR may be enabled between the first gateway node GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a) and between the second gateway node GW2(a) and the replica GW2(b) of the second gateway node GW2(a). For example, the first gateway node GW1 (a) may be an ICR active gateway node and the replica GW1 (b) of the first gateway 5 node GW1 (a) may be an ICR standby gateway node in an ICR pair, i.e. the gateway nodes are ICR peer nodes. For example, the second gateway node GW2(a) may be an ICR standby gateway node and the replica GW2(b) of the second gateway node GW2(a) may be an ICR active gateway node in another ICR pair, i.e. the gateway nodes are ICR peer nodes. There may only be one ICR active gateway node in each of the first node 10 100a and the second node 200b at a time, i.e. there is never two ICR active gateway nodes in either of the first node 100a or the second node 200b. There may also be only one ICR standby gateway node in each of the first node 100a and the second node 200b at a time i.e. there is never two ICR standby gateway nodes in either of the first node 100a or the second node 200b.

15

An ICR active gateway node may also be referred to as a gateway node in ICR active mode and an ICR standby gateway node may also be referred to as a gateway node in ICR standby mode.

20 In ICR active gateway node may run PDN connections and its peer ICR standby gateway node may comprise a replica of at least some of the PDN connections in the ICR active gateway node.

The first gateway node GW1 (a) and the replica GW2(b) of the second gateway node 25 GW2(a) may both be comprised in a pool of gateways, e.g. they are gateway pool peer nodes.

The first gateway node GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a) have the same IP address, e.g. IP X. The second gateway node GW2(a) and the replica 30 GW2(b) of the second gateway node GW2(a) may have the same IP address, e.g. IP Y.

IP X and IP Y are different IP addresses. Thus, the gateway nodes in one ICR pair have the same IP address and the gateway nodes in a pool of gateways have different IP addresses. The two ICR pairs illustrated in Figure 1 have different IP addresses. The first node 100a and the second node 200b may be of a certain Version (V). In some embodiments, at least part of the first node 100a and the second node 200b is of a certain version. In other embodiments, at least part of software comprised in the first node 100a and the second node 200b may be of a certain version. In other embodiments, at least part of hardware comprised in the first node 100a and the second node 200b may be of a certain version. In some embodiments, the version is related to both the hardware and the software of both nodes 100a, 200b.

In the following the term update is used when describing the update from one version to another version. The term upgrade may be used interchangeably with the term update. An update is from one version to another version (e.g. the software version, the hardware version or both the software and the hardware version of a node). The update may be from an old version to a new version or from a new version to an old version. For example, when updating software of a node from one version to another version, the current software may be replaced by software of the other version.

The first node 100a and the second node 200b may be connected to a mobility management node 105 such as e.g. a Mobility Management Entity (MME), a Serving General packet radio service Support Node (SGSN) or a combined MME and SGSN node. The mobility management node 105 manages session states, authentication, paging, mobility with 3GPP, 2G and 3G nodes, roaming, and other bearer management functions. The mobility management node 105 may be connected to a database 110 such as e.g. a Domain Name Server (DNS). The database 1 10 comprises information associated with the at least one of first gateway node GW1 (a), the replica GW1 (b) of the first gateway node GW1 (b), the second gateway node GW2(a) and the replica GW2(b) of the second gateway node GW2(a).

It should be noted that the communication links in the network seen in figure 1 may be of any suitable kind including either a wired or wireless link. The link may use any suitable protocol depending on type and level of layer (e.g. as indicated by the Open Systems Interconnection (OSI) model) as understood by the person skilled in the art.

The scenario illustrated in figure 1 may be referred to as a 1 +1 ICR setup, which indicates that there are one plus one ICR nodes, e.g. the first node 100a and the second node 200b. A 1 +1 ICR setup, with one active and one standby gateway node placed on two different geo-redundant sites A and site B, may use the ICR functionality for upgrades of e.g. at least one of the software and hardware comprised in the first and second nodes 100a, 200b.

Alternative 1

Figure 2 illustrates an example embodiment for doing software upgrades of at least some software comprised in both the first node 100a and the second node 200b. The example embodiment illustrated in figure 2 may be referred to as alternative 1 . The example embodiment in figure 2 uses one ICR-pair for performing the upgrade. The ICR-pair comprises the first gateway node GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a). The first gateway node GW1 (a) is the ICR active gateway node and the replica of the first gateway node GW1 (b) is the ICR standby gateway node in the ICR pair. The ICR standby gateway node (e.g. the replica GW1 (b) of the first gateway node

GW1 (a)) comprises a replica of at least some of the Packet Data Network (PDN) connections handled by the ICR active gateway node (e.g. the first gateway node

GW1 (a)).

The first gateway node GW1 (a) has an IP address X (IP X) and the replica GW1 (b) of the first gateway node GW1 (a) has the same IP address IP X. The database 1 10 comprises information associated with the first node 100a, e.g. information indicating the IP X.

Note that only the first gateway node GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a) is present in the embodiment illustrated in figure 2. In other words, the second gateway node GW2(a) and the replica GW2(b) of the second gateway node GW2(b) are not present in the embodiment illustrated in figure 2.

In the example embodiment shown in figure 2, the first node 100a and the second node 200b are initially of version 1 (V1 ) and is to be updated to version 2 (V2). When at least part of the software of a node is to be updated, it is indicated to the node to be updated that the new software version (e.g. V2) is located in a boot register. Then, the node to be updated is restarted and a lookup in the boot register is performed in order to see where the new software version is located. The software is loaded into the node, and the node is started on the loaded new software (e.g. V2). An example sequence for doing software upgrade for alternative 1 may be as follows:

1 ) Disconnect the ICR replication functionality between the first gateway node

GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a).

2) Upgrade the ICR standby gateway node on site B, e.g. the replica GW1 (b) of the first gateway node GW1 (a), from version V1 to version V2.

3) Enable the ICR replication functionality between the first gateway node GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a) and replicate at least some of the PDN connections from the ICR active gateway node to the ICR standby gateway node.

4) Do an ICR switchover so that the former ICR standby gateway node on site B

becomes the ICR active gateway node and so that the former ICR active gateway node on site A becomes the ICR standby gateway node (first gateway node GW1 (a)=ICR standby gateway node, replica GW1 (b) of the first gateway node GW1 (a)=ICR active gateway node).

5) Disconnect the ICR replication functionality again.

6) Upgrade the ICR standby gateway node on site A, e.g. the first gateway node GW1 (a), from version V1 to version V2.

7) Enable the ICR replication functionality between the first gateway node GW1 (a) (ICR standby gateway node) and the replica GW1 (b) of the first gateway node GW1 (a) (ICR active gateway node) again.

The embodiments shown in figure 2 for software upgrade requires the ICR protocol between the nodes and the internal session data that is sent between the nodes to be both backward (from V1 to V2) and forward (from V2 to V1 ) compatible. An upgraded V2 node has to be able to understand V1 session data, and if the upgrade needs to be reversed (fallback) the V1 node needs to understand V2 data.

The embodiment shown in figure 2 works fine with a few upgrades a year, e.g. one or two. But in an On Demand Software Delivery (ODSD) future with at least one new software release each month, and additional Trouble Report (TR) corrections in between from a common Latest Software Version (LSV) branch, it may mean a minimum of 36 releases during a 36 month period. All releases, including TR corrections, must be able to handle conversion of session data between any-to-any release like from Vn to Vm (Vn -> Vm) and from Vm to Vn (e.g. Vm->Vn), where -> indicates to, and where m and n are positive integers indicating a version number. For example, e.g. [V1 ->V2, V2->V1 ], [V1 ->Vn, Vn->V1 ], [V2->V3, V3->V2], [V2->Vn, Vn->V2], V3->..., etc. The obstacle of converting internal session data between releases and verifying with testing that any-to-any upgrades are working is regarded as a problem very hard and expensive to solve in a complex product, with many development teams continuously integrating software fault corrections and new features to a common LSV branch each month.

Alternative 2

Figure 3 illustrates an example embodiment for doing software upgrades of at least some software comprised in both the first node 100a and the second node 200b which aims at avoiding the problem with backward compatibility between internal session data. The embodiment illustrated in figure 3 may be referred to as alternative 2. Such example embodiment uses a Pool of Gateway functionality or a SGW relocation functionality when upgrading the ICR nodes. With the Pool of Gateways functionality, the internal session data within the nodes and node internal architecture may be changed freely without any problem with software upgrades. The Pool of Gateways only relies on external 3GPP signaling standard (messages such as e.g. session create request, session delete request etc.). Since external 3GPP signaling is used to empty and fill the first and second nodes 100a, 200b, the internal architecture and hardware of the first node 100a and the second node 100b may be different during the update. In figure 3, an ICR pair is defined by the first gateway node GW1 (a) in the first node 100a and the replica GW1 (b) of the first gateway node GW1 (a) in the second node 200b. The first gateway node GW1 (a) is the ICR active gateway node and the replica GW1 (b) of the first gateway node GW1 (a) is the ICR standby gateway node. In addition to the first and second nodes 100a, 200b seen in figure 1 , figure 3 also illustrates additional nodes, e.g. a third node 300 and an n'th node 400, where n is a positive integer. All nodes seen in figure 3 may be at any suitable geographical location. The third node 300 comprises a third gateway node GW3 and the n'th node 400 comprises an n'th gateway node GWn. The third gateway node GW3 and the n'th gateway node GWn may be comprised in a gateway pool together with the first gateway node GW1 (a). All nodes seen in figure 3 are initially of version V1 and to be upgraded to version V2. Both the first gateway node GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a) have the same IP address, e.g. IP X. The third gateway node GW3 has an IP address IP Y (IP Y may be different from IP X) and the n'th gateway node GWn has an IP address IP N (N may be different from X and Y). The replica GW1 (b) of the first node GW1 (a) (and possibly also the complete second node 200b) is not visible to the third gateway node GW3 (and possibly also the complete third node 300) and the n'th gateway node GWn (and possibly also the complete n'th node 400) because the replica GW1 (b) of the first gateway node GW1 (a) has the same IP address as the first gateway node GW1 (a), i.e. the replica GW1 (b) of the first gateway node GW1 (a) is considered to be the same node as the first gateway node GW1 (a). Data packets addressed to IP X will arrive at the gateway node which has the lowest cost for IP X, e.g. the active ICR node.

The third gateway node GW3 may be a SGW or a PGW or a combined SGW and PGW node or a GGSN. The n'th gateway node GWn may be a SGW or a PGW or a combined SGW and PGW node or a GGSN. Table 3 below shows an overview of some example embodiments of the first gateway node GW1 (a), the replica GW1 (b) of the first gateway node GW1 (a), the third gateway node GW3 and the n'th gateway node GWn.

Table 3

The third node 300 and the n'th node 400 are standalone nodes running their own data traffic. However, both the third node 300 and the n'th node 400 may handle PDN connections if necessary. In such case, the first gateway node GW1 (a) moves its PDN connections to selected members of the gateway pool, e.g. the third gateway node GW2 and the n'th gateway node GWn, until the first gateway node GW1 (a) is substantially empty from PDN connections and is ready to be upgraded. The third gateway node GW3 and the n'th gateway node GWn may even be empty reserve nodes waiting for receiving PDN connections from the first gateway node GW1 (a) or other nodes which needs to move their PDN connections before upgrading. The third gateway node GW3 and the n'th gateway node GWn may be ICR active gateway nodes with their own ICR standby gateway nodes, or the third gateway node GW3 and the n'th gateway node GWn may run without ICR. If the third gateway node GW3 and the n'th gateway node GWn are reserve nodes, they are not in used, but costs money. If the third gateway node GW3 and the n'th gateway node GWn runs their own traffic, reserve capacity in these nodes are necessary in order to be able to receive PDN connections from the first gateway node GW1 (a), which costs money. The mobility management node 105 in figure 4 is configured to be connected to at least one of the first gateway node GW1 (a) and the third gateway node GW3. The database 1 10 comprises information associated with at least the first and third gateway nodes GW1 (a), GW3, e.g. the IP X and IP Y. With the example embodiments in figure 3, the network operator may need to purchase one or more additional gateway node(s) (e.g. the third gateway node GW3 and the n'th gateway node GWn) to be used only for software and hardware upgrades. The procedure for upgrading according to the embodiments exemplified in figure 3 may be as follows:

1 ) The active ICR node, e.g. the first gateway node GW1 (a), may be emptied by moving all PDN connections (e.g. using the Pool of Gateways functionality) to the additional gateway node, e.g. the third gateway node GW3.

2) When the active ICR node, e.g. the first gateway node GW1 (a), is substantially empty, both the first gateway node GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a) is upgraded from V1 to V2.

3) The PDN connections are moved back from the third gateway node GW3 to the first gateway node GW1 (a) again after the upgrade.

When a node is substantially empty it does not handle any PDN connections and does not receive any new PDN connections. An Access Point Name (APN) is used to identify the PDN to which the PDN connection is to be created for a particular UE. Thus, a PDN connection is a connection for a UE to a PDN identified by an APN.

A problem with the example embodiment in figure 3 may be that the network operator 5 needs to buy at least one additional standby gateway node only for upgrade when the operator already has a gateway that is in ICR standby mode. The network operator would then have one ICR active gateway node and two ICR standby gateway nodes. This may imply increase in costs, complexity of the system etc.

10 The method for handling updates of the first node 100a and a second node 100b,

according to some embodiments will now be described with reference to the signaling diagram depicted in Figure 4. At start of the method in figure 4, both the first node 100a and the second node 200b are of the same version, e.g. V1. No gateway node is illustrated in the first node 100a or the second node 200b in figure 4. However, the skilled

15 person will understand that the first node 100a comprises at least one of the first gateway node GW1 (a) and the second gateway node GW2(a) and that the second node 200b comprises at least one of the replica GW1 (b) of the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a). Note that the first and second gateway nodes GW1 (a), GW2(a) may be both present and configured in the first node

20 100a at the same time or that either the first or the second gateway node GW1 (a),

GW2(a) is present and configured in the first node 100a (they are not there at the same time). Similarly for the second node, where the replica GW1 (b) of the first gateway node GW1 (a) and the replica GW2(b) of the second gateway nodes GW2(a) may be both present and configured in the second node 100b at the same time or that either the

25 replica GW1 (b) of the first gateway node GW1 (a) or the replica GW2(b) of the second gateway node GW2(a) which is present and configured in the second node 200b (they are not there at the same time).

At start of the method in figure 4, the first gateway node GW1 (a) is the ICR active

30 gateway node which runs all PDN connections in the communications system and the replica GW1 (b) of the first node GW1 (a) is the ICR standby gateway node and comprises a replica of all the first gateway node's GW1 (a) PDN connections, but does not run any data traffic. The ICR replication functionality is enabled between the first gateway node GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a) at the start of the method illustrated in figure 4. The second gateway node GW1 (b) and the replica GW2(b) of the second gateway node GW2(a) are either not active at start of the method or they are configured but not handling any PDN connections. The first gateway node GW1 (a) and the replica of the first gateway node GW1 (b) both have the same IP address, e.g. IP X.

The method in figure 4 comprises the following steps, which steps may as well be carried out in another suitable order than described below. Step 401

The first node 100a receives instructions to perform an update from the current version to another version, e.g. from V1 to V2. Version V2 may be an earlier or later version compared to V1 . These instructions may be received from an external node or from a network operator or any other suitable entity.

Step 402

The first node 100a sends the instructions received in step 401 to the second node 200b. The instructions may be sent from the first node 100a to the second node 200b using e.g. an ICR functionality (described in alternative 4 below) or using a pool of gateways functionality or using both (described in alternative 3 below). The instructions may be sent from the first gateway node GW1 (a) to at least one of the replica GW1 (b) of the first gateway node GW1 (a) (e.g. between ICR peer nodes) and the replica GW2(b) of the second gateway node GW2(a) comprised in the second node 200b. Step 403

Before the update is to be done, the ICR replication functionality between first gateway node GW1 (a) and replica GW1 (b) of the first gateway node GW1 (a) may be disabled. The second node 200b is upgraded from the first version V1 to the second version V2. It may be at least part of the hardware in the second node 200b that is updated or it may be at least part of the software in the second node 200b that is updated or it may be at least part of both the hardware and the software in the second node 200b that is updated. It may be the replica GW1 (b) of the first gateway node GW1 (a) that is updated or the replica GW2(b) of the second gateway node GW2(a) that is updated or both. When the second node 200b is to be upgraded it may be restarted and comprises the second version V2 after the restart. The second node 200b is empty from PDN connections after the update, i.e. it does not have any PDN connections. In case the second node 200b comprises the first version V1 after the restart, the updating has failed.

Since the replica GW1 (b) of the first gateway node GW1 (a) is the ICR standby gateway node, the update to the other version is not any problem since it is the ICR active gateway node (i.e. the first gateway node GW1 (a)) which has and runs all PDN connections. The first gateway node GW1 (a) in ICR active mode may detect that it does not have any ICR peer node anymore (since the ICR peers periodically checks that its peer exist), but no PDN connections will be disturbed or affected due to this.

Step 404

After the update to the second version V2, the second node 200b (e.g. the replica GW2(b) of the second gateway node GW2(a)) starts to handle any new PDN connections. In some embodiments, the replica GW2(b) of the second gateway node GW2(a) starts taking the new PDN connections because it is the ICR active gateway node (alternative 3 where all configurations are active at the same time). In other embodiments, the replica GW2(b) of the second gateway node GW2(a) starts handling the new PDN connections because when the second node 200b was updated to the second version V2 it involved

deactivating the replica GW1 (b) of the first gateway node GW1 (a) configuration and activating the replica GW2(b) of the second gateway node GW2(a) configuration

(alternative 4 where only one configuration is active at a time in a node). The replica GW2(b) of the second gateway node GW2(a) is an ICR active gateway node and has the IP address IP Y.

After step 404, the replica GW2(b) of the second gateway node GW2(a) in the second node 200b is the ICR active gateway node, it is of version V2, has IP address IP Y and is the gateway node which takes PDN connections

Step 405

Both the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) detect that they are in the same gateway pool and that they have different versions, V1≠V2. The first gateway node GW1 (a) have the first version V1 and the replica GW2(b) of the second gateway node GW2(a) have the second version V2.

Step 406

When the first gateway node GW1 (a) have detected that it does not have the same version as the other node in the same pool of gateways, it stops handling any new PDN connections, i.e. it refuses or forwards any new PDN connections.

Step 407

When the first gateway node GW1 (a) have detected that it does not have the same version as the node in the same pool of gateways and has stopped taking new PDN connections, it moves existing PDN connections, it forwards or refuses any new incoming PDN connections. The move of the PDN connections may be done either using a pool of gateways functionality or using a Serving GateWay (SGW) relocation functionality.

After step 407, the first gateway node GW1 (a) has no PDN connections and the replica GW2(b) of the second gateway node GW2(a) has PDN connections.

Step 408

When the first gateway node GW1 (a) does not have any PDN connections after the move in step 407 (it is substantially empty), the first node 100a is updated from the first version V1 to the second version V2. It may be at least some of the hardware comprised in the first node 100a which is updated, or it may be at least some of the software comprised in the first node 100a which is updated or it may be at least some of both the hardware and the software in the first node 100a which is updated. The update may be of at least one of the first gateway node GW1 (a) and the second gateway node GW2(a). The first gateway node GW1 (a) may inform (e.g. via the pool of gateways function) the replica GW2(b) of the second gateway node GW2(a) that it is substantially empty, e.g. that substantially all PDN connections have been moved away from the first gateway node GW1 (a). In some embodiments, the first node 100a may restart when it should be updated to the second version. After the restart, the first node 100a has the second version V2.

If the first node 100a comprises the first version V1 after the restart, the update has failed. The first node 100a comprises information indicating that the second node 200b

5 comprises version V2, and may in case of a failure of the update try to update again or interrupt the update with errors. However, no PDN connections are lost because the first node 100a has moved substantially all its PDN connections to the second node 200b.

In some embodiments, the update to the second version V2 involves that the first node 10 200b switches to using the second gateway node GW2(a) (alternative 4 where only one configuration is active at a time). In other words, the first gateway node GW1 (a) configuration is deactivated and the second gateway node GW2(a) configuration is activated. The second gateway node GW2(a) is the ICR standby gateway node, it has the IP address IP Y and is of version V2.

15

After step 410, both the first node 100a and the second node 200b are of the same version, V2.

Step 409

20 The second gateway node GW2(a) in the first node 100a and the replica GW2(b) of the second gateway node GW2(a) in the second node 200b detect each other because they are ICR peer nodes. The second gateway node GW2(a) is the ICR standby gateway node and the replica GW2(b) of the second gateway node GW2(a) is the ICR active gateway node. Both gateway nodes GW2(a), GW2(b) are of the same version V2.

25

Step 410

Since the ICR active gateway node (e.g. the replica GW2(b) of the second gateway node GW2(a)) has found its peer ICR standby gateway node (e.g. the second gateway node GW2(a) in the first node 100a), the PDN connections of the replica GW2(b) of the second 30 gateway node GW2(a) can be replicated to the second gateway node GW2(a) in the first node 100a.

Different example embodiments of the method illustrated in figure 4 will now be described in more detail with reference to figures 5a-c (alternative 3) and figure 6 (alternative 4). Alternative 3

Figures 5a-c illustrate example embodiments of a method for upgrading the first and second nodes 100a, 200b where the first gateway node GW1 (a) and the second gateway 5 node GW2(a) are configured and activated in the same node (e.g. the first node 100a) at the same time and where the replica GW1 (b) of the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) are configured and activated in another node (e.g. the second node 200b) at the same time.

10 Figure 5a comprises steps 501 -512, figure 5b comprises steps 513-520 and figure 5c comprises steps 521 -525. Figure 5b is a continuation of figure 5a and figure 5c is a continuation of figure 5b.

Figures 5a-c illustrates the first node 100a and the second node 200b. The first node 15 100a and the second node 200b may also be referred to as gateway nodes. The first node 100a and the second node 200b are located at geo-redundant sites, site A and site B, respectively. Both sites are running the same software version V1 . The example embodiment illustrated in figures 5a-c may be referred to as alternative 3.

20 The first node 100a comprises two gateway nodes (the first gateway node GW1 (a) and the second gateway node GW2(a)) configured within the same node (e.g. the first node 100a) at the same time. These two gateway nodes GW1 (a), GW2(a) may be logical nodes. The configuration of the first gateway node GW1 (a) and the second gateway node GW2(a) may be substantially identical except for their external IP addresses (IP X and IP

25 Y) for their respective logical interfaces.

The second node 200b comprises two gateway nodes which are replicas of the gateway nodes in the first node 100a (a replica GW1 (b) of the first gateway node GW1 (a) and a replica GW2(b) of the second gateway node GW2(a)) configured within the same node 30 (e.g. the second node 200b) at the same time. These two gateway nodes GW1 (b),

GW2(b) may be logical nodes. The configuration of the replica GW1 (b) of the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) may be substantially identical except for their external IP addresses (IP X and IP Y) for their logical interfaces. At start of the method in figure 5a, the first gateway node GW1 (a) is an ICR active gateway node, it has the IP address IP X and is of version V1. The second gateway node GW2(a) is an ICR standby gateway node, it has the IP address Y and is of version V1 . The replica GW1 (b) of the first gateway node GW1 (a) is an ICR standby gateway node, it has IP address X and is of version V1 . The replica GW2(b) of the second gateway node GW2(a) is an ICR active gateway node, it has IP address Y and is of version V1.

A first ICR pair may be defined by the first gateway node GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a) and a second ICR pair may be defined by the second gateway node GW2(a) and the replica GW2(b) of the second gateway node GW2(a). The first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) are comprised in the same pool of gateways. An overview of the nodes 100a, 200b before the start of the method in figure 5 are as seen in Table 4 below:

Table 4

The method in figures 5a-c comprises the following steps, which steps may be performed in any suitable order than described below. Figure 5a will be described first, then figure 5b will described and finally figure 5c will be described Step 501

This step is seen in figure 5a. The first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) detects that they are comprised in the same pool of gateway and that they have the same version, V1. At initial startup of the method in figures 5a-c, one node is elected to take PDN connections. This node is elected e.g. via configuration or the first started node or the one already having PDN connections. In the example illustrated in figure 5a, the first gateway node GW1 (a) is elected to take new PDN connections. Step 502

This step is seen in figure 5a. The first gateway node GW1 (a) elected in step 501 starts handling at least one PDN connection.

Step 503

This step is seen in figure 5a. The replica GW2(b) of the second gateway node GW2(a) does not handle any PDN connections because it is the first gateway node GW1 (a) that has been elected to handle PDN connections in step 501 . This may involve that the replica GW2(b) of the second gateway node GW2(a) moves at least one existing PDN connection (if any) to the first gateway node GW1 (a), it forwards at least one new PDN connection (if any) to the first gateway node GW1 (a) (which is in the same pool of gateways) or it refuses new PDN connections (if any). After a while, the replica GW2(b) has substantially no PDN connections.

Step 504

This step is seen in figure 5a. The first gateway node GW1 (a) which is an ICR active gateway node replicates its PDN connections to the replica GW1 (b) of the first gateway node GW1 (a) being the IRC standby node in the first ICR pair. This step 504 may be performed before or after step 503. The ICR replication is done continuously as soon as PDN connections are created, modified or removed in the first gateway node GW1 (a).

Step 505

This step is seen in figure 5a. This step corresponds to step 401 in figure 4. The first node 100a receives (at the first gateway node GW1 (a) or at the second gateway node GW2(a) or at both gateway nodes GW1 (a), GW2(a)) instructions to perform an update from the current version to another version, e.g. from V1 to V2. Version V2 may be an earlier or later version compared to V1. These instructions may be received from an external node or from a network operator or any other suitable entity.

Step 506 This step is seen in figure 5a. This step corresponds to step 402 in figure 4. The first gateway node GW1 (a) sends the instructions to update to version V2 to its ICR peer node, e.g. the replica GW1 (b) of the first gateway node GW1 (a). Step 507

This step is seen in figure 5a. This step corresponds to step 402 in figure 4. The first gateway node GW1 (a) sends the instructions to update to version V2 to the node which is the same pool of gateways, e.g. the replica GW2(b) of the second gateway node GW2(a). Step 507a

In some embodiments, the replica GW2(b) of the second gateway node GW2(a) sends information to the second gateway node GW2(a) in the first node 100. This information may be that the second node 200b is to be updated. The information may also be instructions about that the second gateway node GW2(a) shall switchover to become an ICR active node when the replica GW2(b) of the second gateway node GW2(a) is in an updating sequence and is therefore not detectable by the second gateway node GW2(a). The instruction may also be that another switchover shall take place after the second node 200b has been updated and when it is detectable by the first node 100a again and that the second gateway node GW2(a) shall send instructions to the replica GW2(b) of the second gateway node GW2(a) to switchover to become an ICR active node after the ICR peer nodes of the second ICR pair has detected each other. The second gateway node GW2(a) shall also switchover itself to become an ICR standby node.

Step 508

This step is seen in figure 5a. This step corresponds to step 403 in figure 4. As instructed in steps 506 and 507, the second node 200b is updated to the second version V2.

It may be at least some of the hardware comprised in the second node 200b which is updated, or it may be at least some of the software comprised in the second node 200b which is updated or it may be at least some of both the hardware and the software in the second node 200b which is updated. The update may be of at least one of the replica GW1 (b) of the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a). Since neither of the replica GW1 (b) of the first gateway node GW1 (a) nor the replica GW2(b) of the second gateway node GW2(a) have any PDN connections, the update will not have any effect on the existing or new PDN connections.

All nodes (i.e. the first gateway node GW1 (a), the replica GW1 (b) of the first gateway node GW1 (a), the second gateway node GW2(a) and the replica GW2(b) of the second gateway node GW2(a)) comprise information about any upgrade and they may send information about this to each other.

The ICR status of the replica GW1 (b) of the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) after the update to the second version V2 will be described below with reference to steps 51 1 and 514.

Step 509

This step is seen in figure 5a. During and possibly also some time after the update of the second node 200b, the replica GW1 (b) of the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) are not detectable by the gateway nodes in the first node 100a. Since the second gateway node GW2(a) in the first node 100a cannot detect its ICR peer node (e.g. the replica GW2(b) of the second gateway node GW2(a)), it switches over from being the ICR standby gateway node to being the ICR active gateway node.

In some embodiments, the second gateway node GW2(a) receives instructions to switchover to become the ICR active gateway node. Such instructions may be received from e.g. the second node 200b some time before step 509.

After step 509, the first node 100a comprises two ICR active nodes which is acceptable because the two ICR active nodes are different nodes with different IP addresses, e.g. IP X and IP Y. Step 510

This step is seen in figure 5a. Because the first gateway node GW1 (a) is the one which is elected to handle PDN connections, the second gateway node GW2(a) (the ICR active gateway node) in the first node 100a forwards at least one new PDN connection (if any) to the first gateway node GW1 (a) or refuses at least one new PDN connection (if any). New PDN connections may be forwarded to the first gateway node GW1 (a) e.g. using the Pool of Gateways forward functionality.

Step 51 1

This step is seen in figure 5a. The replica GW2(b) of the second gateway node GW2(a) searches for and detects its ICR peer node during a period of time after the update to the second version V2 (e.g. after start-up with the second version V2 after the update). The replica GW2(b) of the second gateway node GW2(a) finds that its ICR peer node is the second gateway node GW2(a) which is an ICR active node with version V1 , i.e. the versions of the ICR peer nodes are different. Since the replica GW2(b) of the second gateway node GW2(a) detects that its ICR peer node is an ICR active node, the replica GW2(b) of the second gateway node GW2(a) determines that it should be an ICR standby gateway node. At the same time, the second gateway node GW2(a) may also search for its ICR peer node and detects the replica GW2(b) of the second gateway node GW2(a) after it has been updated to the second version V2.

Step 512

This step is seen in figure 5a. An ICR switchover takes place between the second gateway node GW2(a) and the replica GW2(b) of the second gateway node GW2(a). An ICR switchover involves that the two gateway nodes switches ICR roles, e.g. that the ICR active gateway node becomes the ICR standby gateway node and that the ICR standby gateway node becomes the ICR active gateway node.

In some embodiments, the second gateway node GW2(a) has received information from the replica GW2(b) of the second gateway node GW2(a) in step 507a that the replica GW2(b) of the second gateway node GW2(a) shall be updated to a new version, e.g. V2. After the update, the second gateway node GW2(a) in the first node 100a may detect that the replica GW2(b) of the second gateway node GW2(a) has been updated to a new version, e.g. V2. Then the second gateway GW2(a) may receive instructions from the replica GW2(b) of the second gateway node GW2(a) in step 512 to switchover to become an ICR standby gateway node. The replica GW2(b) of the second gateway node GW2(a) is already from step 51 1 the ICR active gateway node. The forced switchover to become the ICR standby node may be due to that an ICR pair cannot have two ICR active nodes; it may only have one ICR active node and one ICR standby node.

In another embodiment, the replica GW2(b) of the second gateway node GW2(a) may know that it is in an upgrade sequence and that it has just updated to a new version, e.g. V2. The replica GW2(b) of the second gateway node GW2(a) may also know that the second gateway node GW2(a) is empty of PDN connections. In such embodiment, the replica GW2(b) of the second gateway node GW2(a) may send instructions to the second gateway node GW2(a) to switchover to become an ICR standby gateway node. The replica GW2(b) of the second gateway node GW2(a) should switchover to become the ICR active gateway node at the same time.

Since the ICR peer nodes have different versions, there is no replication of PDN connections between the replica GW2(b) of the second gateway node GW2(a) and the second gateway node GW2(a).

Step 513

This step is seen in figure 5b. This step corresponds to step 404 in figure 4. From step 502, the first gateway node GW1 (a) has PDN connections. Since the replica GW2(b) of the second gateway node GW2(a) knows that it has been updated to the second version V2 and since the replica GW2(b) of the second gateway node GW1 (a) is the ICR active gateway node in the ICR pair with the second gateway node GW2(a), the replica GW2(b) of the second gateway node GW2(a) starts handling new PDN connections. Since the gateway nodes in this ICR pair are of different versions, there will be no replication of the PDN connections from the replica GW2(b) of the second gateway node GW2(a) (ICR active gateway node) to the second gateway node GW2(a) (ICR standby gateway node).

Step 514

This step is seen in figure 5b. The replica GW1 (b) of the first gateway searches for and detects its ICR peer node during some time after the update to the second version V2 in step 508. The replica GW1 (b) of the first gateway node GW1 (a) finds that its ICR peer node is the first gateway node GW1 (a) which is an ICR active node which handles PDN connections and which is of version V1 , i.e. the versions of the ICR peer nodes are different. Since the replica GW1 (b) of the first gateway node GW1 (a) has found an ICR peer node which is an ICR active gateway node, it determines that it should be the ICR standby node.

Both the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) has PDN connections.

An overview of the statuses of the gateway nodes after step 514 are seen in the Table 5 below. Table 5

Step 515

This step is seen in figure 5b. The first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) detects each other because that they are in the same pool of gateways. They also detect that they have different versions V1 and V2.

Step 516

This step is seen in figure 5b. This step corresponds to step 405 in figure 4. The first gateway node GW1 (a) stops handling at least one new PDN connection (if any) since it detected in step 515 that the node in its pool of gateways has a different version, V1≠V2.

Step 517

This step is seen in figure 5b. This step corresponds to step 407 in figure 4. When the first gateway node GW1 (a) has detected that the node in the same pool of gateways has a different version, it may be seen as an indication of that the first node 100a should start preparing for an update to the same version as the other node in the pool of gateways. Thus, the first gateway node GW1 (a) knows that it has initiated and is in an upgrade sequence. The first gateway node GW1 (a) therefore stops taking at least one new PDN connection (if any) (step 516) and moves at least one existing PDN connection, forward at least one new PDN connection (if any) to the replica GW2(b) of the second gateway node GW2(a) or refuses at least one new PDN connection (if any).

After step 517, the first gateway node GW1 (a) has substantially no PDN connections and the replica GW2(b) of the second gateway node GW2(a) has at least one PDN

connection. Step 517a

In some embodiments, the first gateway node GW1 (a) sends information to the replica GW1 (b) of the first gateway node GW1 (a) in the second node 200b. This information may be that the first node 100a is to be updated. The information may also be instructions about that the replica GW1 (b) of the first gateway node GW1 (a) shall switchover to become an ICR active node when the first gateway node GW1 (a) is in an updating sequence and is therefore not detectable by the replica GW1 (b) of the first gateway node GW1 (a). The instruction may also be that another switchover shall take place after the first node 100a has been updated and when it is detectable by the second node 200b again and that the replica GW1 (b) of the first gateway node GW1 (a) shall send instructions to the first gateway node GW1 (a) to switchover to become an ICR active node after the ICR peer nodes of the first ICR pair has detected each other after the update of the first node 100a. The replica GW1 (a) of the first gateway node GW1 (a) shall also switchover itself to become an ICR standby node. Step 518

This step is seen in figure 5b. This step corresponds to step 408 in figure 4. When the first gateway node GW1 (a) has substantially no PDN connections, the first node 100a is updated from the first version V1 to the second version V2. It may be at least some of the hardware comprised in the first node 100a which is updated, or it may be at least some of the software comprised in the first node 100a which is updated or it may be at least some of both the hardware and the software in the first node 100a which is updated. The update may be of at least one of the first gateway node GW1 (a) and the second gateway node GW2(a). Step 519

This step is seen in figure 5b. During the update of the first node 100a, the first gateway node GW1 (a) and the second gateway node GW2(a) are not detectable by the gateway nodes in the second node 200a. Since the replica GW1 (b) of the first gateway node GW1 (b) in the second node 200b cannot detect its ICR peer node (e.g. the first gateway node GW1 (a)), it switches over from being the ICR standby gateway node to being the ICR active gateway node.

After step 519 there are two ICR active gateway nodes in the second node 200b but this is acceptable since they are two different gateway nodes with different IP addresses, IP X and IP Y.

Step 520

This step is seen in figure 5b. The replica GW1 (b) of the first gateway node GW1 (a) (the ICR active gateway node) in the second node 200b forwards at least one new PDN connection (if any) or refuses at least one new PDN connection (if any).

Step 521

This step is seen in figure 5c. This step corresponds to step 409 in figure 4.

The first gateway node GW1 (a) will, during some time, search for its ICR peer node after the update to the second version V2 (e.g. after start-up with the second version V2 after the update). The ICR peer node of the first gateway node GW1 (a) is the replica GW1 (b) of the first gateway node GW1 (a). Since the replica GW1 (b) of the first gateway node GW1 (a) is detected to be an ICR active gateway node, the first gateway node GW1 (a) determines that it should be an ICR standby gateway node.

At the same time, the replica GW1 (b) of the first gateway node GW1 (a) also searches for its ICR peer node and detects the first gateway node GW1 (a). Step 522

This step is seen in figure 5c. An ICR switchover takes place between the first gateway node GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a). An ICR switchover involves that the two gateway nodes switches ICR roles, e.g. that the ICR active gateway node becomes the ICR standby gateway node and that the ICR standby gateway node becomes the ICR active gateway node.

In some embodiments, the replica GW1 (b) of the first gateway node GW1 (b) has received information from first gateway node GW1 (a) in step 517a that the first gateway node GW1 (a) shall be updated to a new version, e.g. V2. Later on, the replica GW1 (b) of the first gateway node GW1 (a) may detect that the first gateway node GW1 (a) has been updated to a new version, e.g. V2. Then the replica GW1 (b) of the first gateway node GW1 (a) may send instructions to the first gateway node GW1 (a) to switchover to become an ICR active gateway node. The replica GW1 (b) of the first gateway node GW1 (a) is also switched over from being an ICR active gateway node to be and ICR standby gateway node.

In another embodiment, the first gateway node GW1 (a) may know that it is in an upgrade sequence and that it has just updated to a new version, e.g. V2. The replica GW1 (b) of the first gateway node GW1 (a) may also know that the first gateway node GW1 (a) is empty of PDN connections. In such embodiment, the replica GW1 (b) of the first gateway node GW1 (a) may send instructions to the first node 100a to switchover the first gateway node GW1 (a) to become an ICR active gateway node. The replica GW1 (b) of the first gateway node GW1 (a) is also switched from being the ICR active gateway node to becoming the ICR standby gateway node.

The ICR peer nodes now have the same versions, but the ICR active gateway node (e.g. the first gateway node GW1 (a)) has no PDN connections. Therefore, there are no PDN connections to be replicated to the ICR standby gateway node (e.g. the replica GW1 (b) of the first gateway node GW1 (a)).

Step 523

This step is seen in figure 5c. After the update to the second version V2, the second gateway node GW2(a) searches for and detects its ICR peer node, e.g. the replica GW2(b) of the second gateway node GW2(a) in the second node 200b. The second gateway node GW2(a) detects that its ICR peer node is an ICR active gateway node and determines that it should be an ICR standby gateway node. Both nodes in the second ICR pair are now of the second version V2. An overview of the statuses of the gateway nodes after step 523 are seen in Error! Reference source not found, below. Table 6

Step 524

This step is seen in figure 5c. This step corresponds to step 410 in figure 4. Since the second gateway node GW2(a) and the replica GW2(b) of the second gateway node GW2(a) are of the same version V2, the second gateway node GW2(a) replicates the PDN connections of the replica GW2(b) of the second gateway node GW2(a).

Step 525

This step is seen in figure 5c. The first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) detects that they are in the same pool of gateways and that they have the same version, V2. If both the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) are substantially empty (i.e. they have no PDN connections, then one of the gateway nodes is elected to take new PDN connections. If one of the gateway nodes already has PDN connections, then this gateway node is elected to continue to take new PDN connections. In the example illustrated in figure 5c, the replica GW2(b) of the second gateway node GW2(a) is elected to take new PDN connections since it already has PDN connections. Alternative 4

Figure 6 illustrates an example embodiment of a setup for upgrade of the first node 100a and the second node 200b which may be referred to as alternative 4. In figure 6, ICR and pool of gateway are used for upgrading in the same node but never at the same time. Alternative 4 is similar to alternative 3 except that a node is reconfigured between upgrades (manually or automatically). Thus, there is no need for having two gateway nodes active at the same time within the same node.

In figure 4, the first node 100a and the second node 200b are located at geo-redundant sites, site A and site B, respectively. Both the first node 100a and the second node 200b are running the same software version V1.

In figure 6, only one gateway node configuration is active at a time in each node 100a, 200b. This means that either the first gateway node GW1 (a) configuration or the second gateway node GW2(a) configuration is active in the first node 100a, and that either the replica GW1 (b) of the first gateway node GW1 (a) configuration or the replica GW2(b) of the second gateway node GW2(a) configuration is active in the second node 100b.

Both the first node 100a and the second node 200b are configured in the database 1 10 and are known by the mobility management node 105.

Table 7 below shows some example embodiments of alternative active configurations. The left column comprises active configurations in the first node 100a and the right column comprises active configurations in the second node 200b.

Table 7

At the start of the method shown in figure 6, the first gateway node GW1 (a) configuration and the replica GW1 (b) of the first gateway node GW1 (a) configuration are activated. In other words, the second gateway GW2(a) configuration and the replica GW2(b) of the second gateway node GW2(a) configuration are deactivated. The first gateway node GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a) are ICR peer nodes and define an ICR pair. The method illustrated in figure 6 comprises the following steps, which steps may be performed in any suitable order than described below: Step 601

This step corresponds to step 401 in figure 4 and step 505 in figure 5a. The first node 100a (e.g. the first gateway node GW1 (a) which is activated) receives instructions to perform an update from the current version to another version, e.g. from V1 to V2.

Version V2 may be an earlier or later version compared to V1 . These instructions may be received from an external node or from a network operator or any other suitable entity.

Step 602

This step corresponds to step 402 in figure 4 and to step 506 in figure 5a. The first node 100a sends the instructions to the second node 200b to update to version V2 . The instructions are sent over the communication path between ICR peer nodes.

Step 603

This step corresponds to step 403 in figure 4 and step 508 in figure 5a. As instructed in step 602, the second node 200b is updated to the second version V2.

It may be at least some of the hardware comprised in the second node 200b which is updated, or it may be at least some of the software comprised in the second node 200b which is updated or it may be at least some of both the hardware and the software in the second node 200b which is updated. The update may be of at least one of the replica GW1 (b) of the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a).

Step 604

After the update to the second version V2, the second node 200b switches to the replica GW2(b) of the second gateway node GW2(a) configuration. In other words, the replica GW1 (b) of the first gateway node GW1 (a) is deactivated and the replica GW2(b) of the second gateway node GW2(a) is activated. The replica GW2(b) of the second gateway node GW2(a) is of version V2 and has the IP address IP Y. Step 605

In some embodiments, the replica GW2(b) of the second gateway node GW2(a) tries to detect an ICR peer node without any success. The first gateway node GW1 (a) in the first node 100a is not the ICR peer node because it has a different IP address, e.g. IP X. Since the replica GW2(b) of the second gateway node GW2(a) does not find any ICR peer node, it determines that it should become the ICR active gateway node.

In other embodiments, the replica GW2(b) of the second gateway node GW2(a) is always the ICR active gateway node, i.e. the replica GW2(b) of the second gateway node GW2(a) does not need to determine its own ICR status (e.g. active or standby).

The statuses of the activated gateway node configurations in the first node 100a and the second node 200b are illustrated in Table 8 below. Table 8

Step 606

This step corresponds to step 404 in figure 4 and step 513 in figure 5a. The replica GW2(b) of the second gateway node GW2(a) starts handling at least one new PDN connection since has been updated to version V2 and since it is the ICR active gateway node.

Step 607

This step corresponds to step 405 in figure 4. The first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) detects each other because they are part of the same pool of gateways. The gateway nodes also detects that they have different versions, V1 and V2.

Step 608 This step corresponds to step 406 in figure 4 and step 516 in figure 5b. When the different versions, V1 and V2 have been detected in step 607, the first node 100a (e.g. the first gateway node GW1 (a)) stops handling at least one new PDN connection (if any). Step 609

This step corresponds to step 407 in figure 4 and step 517 in figure 5b. When the first gateway node GW1 (a) has detected that the gateway node in the same pool of gateways has a different version, it is an indication of that the first node 100a should start to prepare for update to the same version as the node in the same pool of gateways. The first gateway node GW1 (a) therefore stops taking at least one new PDN connection (step 608) and moves at least one existing PDN connection (if any) and forward at least one new PDN connection (if any) to the replica GW2(b) of the second gateway node GW2(a) or refuses at least one new PDN connection (if any). After step 609, the first gateway node GW1 (a) has no PDN connections and the replica GW2(b) of the second gateway node GW2(a) has PDN connections.

Step 610

This step corresponds to step 408 in figure 4 and step 518 in figure 5b. When the first gateway node GW1 (a) is substantially empty from PDN connections, the first node 100a is updated from the first version V1 to the second version V2.

It may be at least some of the hardware comprised in the first node 100a which is updated, or it may be at least some of the software comprised in the first node 100a which is updated or it may be at least some of both the hardware and the software in the first node 100a which is updated. The update may be of at least one of the first gateway node GW1 (a) and the second gateway node GW2(a).

Step 61 1

After the update to the second version V2, the first node 100a switches to the second gateway node GW2(a) configuration. In other words, the first gateway node GW1 (a) is deactivated and the second gateway node GW2(a) is activated. The second gateway node GW2(a) is of version V2 and has the IP address IP Y. Step 612

This step corresponds to step 409 in figure 4 and step 521 in figure 5b. The second gateway node GW2(a) detects its ICR peer node, e.g. the replica GW2(b) of the second gateway node GW2(a). The second gateway node GW2(a) in the first node 100a and the replica GW2(b) of the second gateway node GW2(a) are ICR peer nodes having the same IP address, e.g. IP Y.

Step 613

In some embodiments, since the second gateway node GW2(a) has found an ICR peer node which is an ICR active gateway node, it determines that it should become the ICR standby gateway node.

In other embodiments, the second gateway node GW2(a) is always the ICR active gateway node, i.e. the second gateway node GW2(a) does not need to determine its own ICR status (e.g. active or standby).

The statuses of the activated gateway node configurations in the first node 100a and the second node 200b are illustrated in Table 9 below. Table 9

Step 614

This step corresponds to step 410 in figure 4 and step 524 in figure 5c. Since the second gateway node GW2(a) and the replica GW2(b) of the second gateway node GW2(a) are of the same version V2, the second gateway node GW2(a) replicates the PDN connections of the replica GW2(b) of the second gateway node GW2(a). The method described above will now be described seen from the perspective of the first node 100a. Figure 7 is a flowchart describing the present method performed by the first node 100a, for handling version updates of the first node 100a and the second node 200b in a communications system. The first node 100a comprises a first gateway node GW1 (a) and a second gateway node GW2(a). The first gateway node GW1 (a) in the first node 100a and a replica GW1 (b) of the first gateway node GW1 (a) comprised in the second node 200b are ICR peer nodes defining a first ICR pair. The second gateway node GW2(a) and a replica GW2(b) of the second gateway node GW2(a) in the second node 200b are ICR peer nodes defining a second ICR pair. The first gateway node GW1 (a) is an ICR active node and the replica GW1 (b) of the first gateway node GW1 (a) is an ICR standby node in the first ICR pair.

In some embodiments, the first gateway node GW1 (a) and the second gateway node GW2(a) are gateway node configurations which are both activated at the same time in the first node 100a. In other embodiments, the first gateway node GW1 (a) and the second gateway node GW2(a) are different gateway node configurations between which the first node 100a can switch such that the first gateway node GW1 configuration is activated and the second gateway node GW2 configuration is deactivated or the second gateway node GW2 configuration is activated and the first gateway node configuration GW1 is deactivated.

The method comprises at least some of the following steps to be performed by the first node 100a: Step 701

This step corresponds to step 401 in figure 4, step 505 in figure 5a and step 601 in figure 6. In some embodiments, the first node 100a receives instructions to update from the first version V1 to the second version V2. Step 702

This step corresponds to step 402 in figure 4, steps 506 and 507 in figure 5a and step 602 in figure 6. In some embodiments, the first node 100a transmits the instructions to update to the second node 200b. Step 703

This step corresponds to step 509 in figure 5a. In some embodiments, if the ICR peer node of the second gateway node GW2(a) is not detectable by the first node 100a, the first node 100a switches over the second gateway node GW2(a) from being the ICR standby node to become the ICR active node.

Step 704

This step corresponds to step 512 in figure 5a. In some embodiments, if it has been detected that both the second gateway node GW2(a) and the replica GW2(b) of the second gateway node GW2(a) defining the second ICR pair are ICR active nodes, the first node 100a receives instructions from the second node 200b to switchover the second gateway node GW2(a) from being the ICR active node to become the ICR standby node.

Step 705

This step corresponds to step 512 in figure 5a. In some embodiments, the first node 100a switches over the second gateway node GW2(a) from being the ICR active node to become the ICR standby node.

Step 706

This step corresponds to step 405 in figure 4, step 515 in figure 5b and step 607 in figure 6. The first node 100a detects that the replica GW2(b) of the second gateway node GW2(a) which is in a same pool of gateways as the first gateway node GW1 (a) has been updated to a second version V2. The second version V2 is different than a first version V1. The first gateway node GW1 (a) is of the first version V1 .

In some embodiments, the first gateway node GW1 (a) refuses or forwards any new PDN connections after the detection of the update to the second version V2 of the second node 200b. Step 707

This step corresponds to step 407 in figure 4, step 517 in figure 5b and step 609 in figure 6. When the different versions have been detected, the first node 100a moves at least one PDN connection from the first gateway node GW1 (a) to the updated replica GW2(b) of the second gateway node GW2(a) in the second node 200b. In some embodiments, the at least one PDN connection is moved from the first gateway node GW1 (a) to the replica GW2(b) of the second gateway node GW2(a) using a pool of gateways function or using a SGW relocation function.

Step 708

This step corresponds to step 408 in figure 4, step 518 in figure 5b and step 610 in figure 6. When substantially all PDN connections have been moved away from the first gateway node GW1 (a), the first node 100a updates the first node 100a from the first version V1 to the second version V2.

At least one of hardware and software comprised in the first node 100a may be updated from the first version V1 to the second version V2. Step 709

This step corresponds to step 61 1 in figure 6. In some embodiments, the first node 100a activates the second gateway node GW2 configuration.

Step 710

This step corresponds to step 61 1 in figure 6. In some embodiments, the first node 100a deactivates the first gateway node GW1 configuration.

Step 71 1

This step corresponds to step 409 in figure 4, step 523 in figure 5c and step 612 in figure 6. The first node 100a detects the ICR peer node of the second gateway node GW2(a) in the second ICR pair, and that second gateway node GW2(a) and the replica GW2(b) of the second gateway node (GW2(a)) defining the second ICR pair are both of the same second version V2. Step 712

This step corresponds to step 522 in figure 5c. In some embodiments, if it has been detected that both the first gateway node GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a) defining the first ICR pair are ICR active nodes, the first node 100a sends instructions to the second node 200b to switchover the replica GW1 (b) of the first gateway node GW1 (a) from being the ICR active node to become the ICR standby node.

Step 713

This step corresponds to step 410 in figure 4, step 524 in figure 5c and step 614 in figure 6. The first node 100a replicates, at the second gateway node GW2(a), at least one PDN connection from the replica GW2(b) of the second gateway node GW2(a).

Embodiments of the first node node 100a configured to perform the method actions for handling updates of the first node 100a and a second node 200b in a communications system, as described above in relation to Figure 7, is depicted in Figure 8.

As mentioned above, the first node 100a comprises a first gateway node GW1 (a) and a second gateway node GW2(a). The first gateway node GW1 (a) in the first node 100a and a replica GW1 (b) of the first gateway node GW1 (a) comprised in the second node 200b are ICR peer nodes defining a first ICR pair. The second gateway node GW2(a) and a replica GW2(b) of the second gateway node GW2(a) in the second node 200b are ICR peer nodes defining a second ICR pair. The first gateway node GW1 (a) is an ICR active node and the replica GW1 (b) of the first gateway node GW1 (a) is an ICR standby node in the first ICR pair.

The first node 100a is configured to, e.g. by means of a detecting module 801 , detect that the replica GW2(b) of the second gateway node GW2(a) which is in a same pool of gateways as the first gateway node GW1 (a) has been updated to a second version V2. The second version V2 is different than a first version V1. The first gateway node GW1 (a) is of the first version V1. The detecting module 801 may also be referred to as a detecting unit, a detecting means, a detecting circuit, means for detecting etc. The detecting module 801 may be a processor 803 of the first node 100a. The first node 100a is configured to, e.g. by means of a moving module 805, move, when the different versions have been detected, at least one PDN connection from the first gateway node GW1 (a) to the updated replica GW2(b) of the second gateway node GW2(a) in the second node 200b. The moving module 805 may also be referred to as a moving unit, a moving means, a moving circuit, means for moving etc. The moving module 805 may be the processor 803 of the first node 100a. The at least one PDN connection may be moved from the first gateway node GW1 (a) to the replica GW2(b) of the second gateway node GW2(a) using a pool of gateways function or using a SGW relocation function.

The first node 100a is configured to, e.g. by means of an updating module 808, update the first node 100a from the first version V1 to the second version V2 when substantially all PDN connections have been moved away from the first gateway node GW1 (a). The updating module 808 may also be referred to as an updating unit, a updating means, a updating circuit, means for updating etc. The updating module 808 may be the processor 803 of the first node 100a. At least one of hardware and software comprised in the first node 100a may be updated from the first version V1 to the second version V2.

The first node 100a is configured to, e.g. by means of the detecting module 801 , detect the ICR peer node of the second gateway node GW2(a) in the second ICR pair, and that second gateway node GW2(a) and the replica GW2(b) of the second gateway node GW2(a) defining the second ICR pair are both of the same second version V2.

The first node 100a is configured to, e.g. by means of a replicating module 810, replicate, at the second gateway node GW2(a), at least one PDN connection from the replica GW2(b) of the second gateway node GW2(a). The replicating module 810 may also be referred to as an replicating unit, a replicating means, a replicating circuit, means for replicating etc. The replicating module 810 may be the processor 803 of the first node 100a.

In some embodiments, the first node 100a is configured to, e.g. by means of a receiving module 813, receive instructions to update from the first version V1 to the second version V2. The receiving module 813 may also be referred to as a receiving unit, a receiving means, a receiving circuit, means for receiving, input unit etc. The receiving module 813 may be a receiver, a transceiver etc. The receiving module 813 may be a wireless receiver of the first node 100a of a wireless or fixed communications system.

In some embodiments, the first node 100a is configured to, e.g. by means of a

transmitting module 815, transmit the instructions to update to the second node 200b. The transmitting module 815 may also be referred to as a transmitting unit, a transmitting means, a transmitting circuit, means for transmitting, output unit etc. The transmitting module 815 may be a transmitter, a transceiver etc. The transmitting module 815 may be a wireless transmitter of the first node 100a of a wireless or fixed communications system.

In some embodiments, the first gateway node GW1 (a) is configured to, e.g. by means of the moving module 805, refuse or forward any new PDN connections after the detection of the update to the second version V2 of the second node 200b. In some embodiments, the first gateway node GW1 (a) and the second gateway node GW2(a) may be gateway node configurations which are both activated at the same time in the first node 100a.

In some embodiments, the first gateway node GW1 (a) and the second gateway node GW2(a) are different gateway node configurations between which the first node 100a can switch such that the first gateway node GW1 configuration is activated and the second gateway node GW2 configuration is deactivated or the second gateway node GW2 configuration is activated and the first gateway node configuration GW1 is deactivated. In some embodiments, the first node 100a is configured to, e.g. by means of an

activating module 818, activate the second gateway node GW2 configuration. The activating module 818 may also be referred to as a activating unit, a activating means, a activating circuit, means for activating etc. The activating module 818 may be the processor 803 of the first node 100a.

In some embodiments, the first node 100a is configured to, e.g. by means of an

deactivating module 820, deactivate the first gateway node GW1 configuration. The deactivating module 820 may also be referred to as a deactivating unit, a deactivating means, a deactivating circuit, means for deactivating etc. The deactivating module 820 may be the processor 803 of the first node 100a.

In some embodiments, the first node 100a is configured to, e.g. by means of a

switchover module 823, switchover the second gateway node GW2(a) from being the ICR standby node to become the ICR active node if the ICR peer node of the second gateway node GW2(a) is not detectable. The switchover module 823 may also be referred to as a switchover unit, a switchover means, a switchover circuit, means for switchover etc. The switchover module 823 may be the processor 803 of the first node 100a. In some embodiments, the first node is configured to, e.g. by means of the receiving module 813, receive instructions from the second node 200b to switchover the second gateway node GW2(a) from being the ICR active node to become the ICR standby node if it has been detected that both the second gateway node GW2(a) and the replica GW2(b) of the second gateway node GW2(a) defining the second ICR pair are ICR active nodes.

In some embodiments, the first node 100a is configured to, e.g. by means of the switchover module 823, switchover the second gateway node GW2(a) from being the ICR active node to become the ICR standby node. In some embodiments, the first node 100a is configured to, e.g. by means of the transmitting module 815, send instructions to the second node 200b to switchover the replica GW1 (b) of the first gateway node GW1 (a) from being the ICR active node to become the ICR standby node if it has been detected that both the first gateway node GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a) defining the first ICR pair are ICR active nodes.

The first node 100a may further comprise a memory 825 comprising one or more memory units. The memory 825 is arranged to be used to store data, received data streams, power level measurements, threshold values, information about the first version and the second version, ICR peer node information, pool of gateways information, information about PDN connections, information about activated and deactivated gateway node configurations, time periods, configurations, schedulings etc. and applications to perform the methods herein when being executed in the first node 100a. A first computer program may comprise instructions which, when executed on at least one processor, e.g. the processor 803 cause the at least one processor to carry out the method as described in figure 7. A first carrier may comprise the first computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal or computer readable storage medium. The method described above will now be described seen from the perspective of the second node 200b. Figure 9 is a flowchart describing the present method in the second node 200b for handling updates of the second node 200b and a first node 100a in a communications system. The second node 200b comprises a replica GW1 (b) of a first gateway node GW1 (a) and a replica GW2(b) of a second gateway node GW2(a). The replica GW1 (b) of the first gateway node GW1 (a) in the second node 200b and a first gateway node GW1 (a) in the first node 100a are ICR peer nodes defining a first ICR pair. The replica GW2(b) of the second gateway node GW2(a) in the second node 200b and a second gateway node GW2(a) in the first node 100a are ICR peer nodes defining a second ICR pair. The replica GW1 (b) of the first gateway node GW1 (a) is an ICR standby node and the first gateway node GW1 (a) is an ICR active node in the first ICR pair.

In some embodiments, the replica GW1 (b) of the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) are gateway node configurations which both activated at the same time in the second node 200b.

In some embodiments, the replica GW1 (b) of the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) are different gateway node configurations between which the second node 200b can switch such that the first gateway node GW1 configuration is activated and the second gateway node GW2 configuration is deactivated or the second gateway node GW2 configuration is activated and the first gateway node configuration GW1 is deactivated. The method comprises at least one of the following steps to be performed by the second node 200b:

Step 901

This step corresponds to step 402 in figure 4, steps 506 and 507 in figure 5a and step 602 in figure 6. In some embodiments, the second node 200b receives, from the first node 100a instructions to update from the first version V1 to the second version V2.

Step 902 This step corresponds to step 403 in figure 4, step 508 in figure 5a and step 603 in figure 6. The second node 200b updates the second node 200b from a first version V1 to a second version V2.

5 At least one of hardware and software comprised in the first node 100a may be updated from the first version V1 to the second version V2.

Step 903

This step corresponds to step 404 in figure 4, step 513 in figure 5a and step 606 in figure 10 6. When the second node 200b has been updated to the second version V2, the second node 200b handles at least one new PDN connection.

Step 904

This step corresponds to step 405 in figure 4, step 515 in figure 5b and step 607 in figure 15 6. The second node 200b detects that the first gateway node GW1 (a) which is in a same pool of gateways as the replica GW2(b) of the second gateway node GW2(a) is of the first version V1 which is different than the second version V2 of the replica GW2(b) of the second gateway node GW2(a).

20 The replica GW2(b) of the second gateway node GW2(a) may handles substantially all existing and new PDN connections after the detection of the different versions.

Step 905

25 This step corresponds to step 604 in figure 6. In some embodiments, the second node 200b activates the second gateway node GW2 configuration.

Step 906

This step corresponds to step 604 in figure 6. In some embodiments, the second node 30 200b deactivates the first gateway node GW1 configuration.

Step 907

This step corresponds to step 512 in figure 5a. In some embodiments, if it has been detected that both the second gateway node GW2(a) and the replica GW2(b) of the second gateway node GW2(a) defining the second ICR pair are ICR active nodes, the second node 200b sends instructions to the second node 200b to switchover the second gateway node GW2(a) from being the ICR active node to become the ICR standby node. Step 908

This step corresponds to step 407 in figure 4, step 517 in figure 5b and step 609 in figure 6. When the different versions have been detected, the second node 200b receives, at the updated replica GW2(b) of the second gateway node GW2(a), at least one PDN connection from the first gateway node GW1 (a) in the first node 100a.

The at least one PDN connection may be received from the first gateway node GW1 (a) using a pool of gateways function or using a SGW relocation function.

Step 909

This step corresponds to step 409 in figure 4, step 523 in figure 5c and step 612 in figure 6. The second node 200b detects the ICR peer node of the replica GW2(b) of the second gateway node GW2(a) in the second ICR pair, and that the replica GW2(b) of the second gateway node GW2(a) and the second gateway node GW2(a) defining the second ICR pair are both of the same second version V2.

Step 910

This step corresponds to step 519 in figure 5b. In some embodiments, if the ICR peer node of the replica GW1 (b) of the first gateway node GW1 (a) is not detectable, the second node 200b switches over the replica GW1 (b) of the first gateway node GW1 (a) from being the ICR standby node to become the ICR active node.

Step 91 1

This step corresponds to step 522 in figure 5c. In some embodiments, if it has been detected that both the first gateway node GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a) defining the first ICR pair are ICR active nodes, the second node 200b receives instructions from the first node 100a to switchover the replica GW1 (b) of the first gateway node GW1 (a) from being the ICR active node to become the ICR standby node. Step 912

This step corresponds to step 522 in figure 5c. In some embodiments, the second node 200b switches over the replica GW1 (b) of the first gateway node GW1 (a) from

being the ICR active node to become the ICR standby node.

Step 913

This step corresponds to step 410 in figure 4, step 524 in figure 5c and step 614 in figure 6, the second node 200b replicates at least one PDN connection from the replica GW2(b) of the second gateway node GW2(a) to the second gateway node GW2(a).

Embodiments of the second node 200b configured to perform the method actions for handling updates of the second node 200b)and a first node 100a in a communications system as described above in relation to Figure 9, is depicted in Figure 10. As mentioned earlier, the second node 200b comprises a replica GW1 (b) of a first gateway node GW1 (a) and a replica GW2(b) of a second gateway node GW2(a). The replica GW1 (b) of the first gateway node GW1 (a) in the second node 200b and a first gateway node GW1 (a) in the first node 100a are ICR peer nodes defining a first ICR pair. The replica GW2(b) of the second gateway node GW2(a) in the second node 200b and a second gateway node GW2(a) in the first node 100a are ICR peer nodes defining a second ICR pair. The replica GW1 (b) of the first gateway node GW1 (a) is an ICR standby node and the first gateway node (GW1 (a)) is an ICR active node in the first ICR pair, The second node 200b is configured to, e.g. by means of an updating module 1001 , update the second node 200b from a first version V1 to a second version V2. The updating module 1001 may also be referred to as a updating unit, a updating means, a updating circuit, means for updating etc. The updating module 1001 may be a processor 1003 of the second node 200b.

The second node 200b is configured to, e.g. by means of a handling module 1005, handle at least one new PDN connection when the second node 200b has been updated to the second version V2. The handling module 1005 may also be referred to as a handling unit, a handling means, a handling circuit, means for handling etc. The handling module 1005 may be the processor 1003 of the second node 200b. The second node 200b is configured to, e.g. by means of a detecting module 1008, detect that the first gateway node GW1 (a) which is in a same pool of gateways as the replica GW2(b) of the second gateway node GW2(a) is of the first version V1 which is different than the second version V2 of the replica GW2(b) of the second gateway node GW2(a). The detecting module 1008 may also be referred to as a detecting unit, a detecting means, a detecting circuit, means for detecting etc. The detecting module 1008 may be the processor 1003 of the second node 200b.

The second node 200b is configured to, e.g. by means of a receiving module 1010, receive, at the updated replica GW2(b) of the second gateway node GW2(a), at least one PDN connection from the first gateway node GW1 (a) in the first node 100a when the different versions have been detected. The receiving module 1010 may also be referred to as a receiving unit, a receiving means, a receiving circuit, means for receiving, input unit etc. The receiving module 1010 may be a receiver, a transceiver etc. The receiving module 1010 may be a wireless receiver of the second node 200b of a wireless or fixed communications system.

The second node 200b is configured to, e.g., by means of the detecting module 1008, detect the ICR peer node of the replica GW2(b) of the second gateway node GW2(a) in the second ICR pair, and that the replica GW2(b) of the second gateway node GW2(a) and the second gateway node GW2(a) defining the second ICR pair are both of the same second version V2.

The second node 200b is configured to, e.g. by means of a replicating module 1013, replicate at least one PDN connection from the replica GW2(b) of the second gateway node GW2(a) to the second gateway node GW2(a). The replicating module 1013 may also be referred to as a replicating unit, a replicating means, a replicating circuit, means for replicating etc. In some embodiments, the second node 200b is configured to, e.g. by means of the receiving module 1010, receive, from the first node 100a instructions to update from the first version V1 to the second version V2. In some embodiments, the replica GW2(b of the second gateway node GW2(a) is configured to handle substantially all existing and new PDN connections after the detection of the different versions. In some embodiments, the replica GW1 (b) of the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) are gateway node configurations which both activated at the same time in the second node 200b.

In some embodiments, the replica GW1 (b) of the first gateway node GW1 (a) and the replica GW2(b) of the second gateway node GW2(a) are different gateway node configurations between which the second node 200b can switch such that the first gateway node GW1 configuration is activated and the second gateway node GW2 configuration is deactivated or the second gateway node GW2 configuration is activated and the first gateway node configuration GW1 is deactivated.

In some embodiments, the second node 200b is configured to, e.g. by means of an activating module 1015, activate the second gateway node GW2 configuration. The activating module 1015 may also be referred to as a activating unit, a activating means, a activating circuit, means for activating etc. The activating module 1015 may be the processor 1003 of the second node 200b.

In some embodiments, the second node 200b is configured to, e.g. by means of a deactivating module 1018, deactivate the first gateway node GW1 configuration.

In some embodiments, the second node 200b is configured to, e.g. by means of a transmitting module 1020, send instructions to the second node 200b to switchover the second gateway node GW2(a) from being the ICR active node to become the ICR standby node if it has been detected that both the second gateway node GW2(a) and the replica GW2(b) of the second gateway node GW2(a) defining the second ICR pair are ICR active nodes. The transmitting module 1020 may also be referred to as a transmitting unit, a transmitting means, a transmitting circuit, means for transmitting, output unit etc. The transmitting module 1020 may be a transmitter, a transceiver etc. The transmitting module 1020 may be a wireless transmitter of the second node 200b of a wireless or fixed communications system.

In some embodiments, the second node 200b is configured to, e.g. by means of a switchover module 1023, switchover the replica GW1 (b) of the first gateway node GW1 (a) from being the ICR standby node to become the ICR active node if the ICR peer node of the replica GW1 (b) of the first gateway node GW1 (a) is not detectable. The switchover module 1023 may also be referred to as a switchover unit, a switchover means, a switchover circuit, means for switchover etc. The switchover module 1023 may be the processor 1003 of the second node 200b.

In some embodiments, the second node 200b is configured to, e.g. by means of the receiving module 1010, receive instructions from the first node 100a to switchover the replica GW1 (b) of the first gateway node GW1 (a) from being the ICR active node to become the ICR standby node if it has been detected that both the first gateway node GW1 (a) and the replica GW1 (b) of the first gateway node GW1 (a) defining the first ICR pair are ICR active nodes.

In some embodiments, the second node 200b is configured to, e.g. by means of the switchover module 1023, switchover the replica (W1 (b) of the first gateway node GW1 (a) from being the ICR active node to become the ICR standby node.

In some embodiments, the at least one PDN connection is configured to be received from the first gateway node GW1 (a) using a pool of gateways function or using a SGW relocation function.

In some embodiments, at least one of hardware and software comprised in the first node 100a is updated from the first version V1 to the second version V2. The second node 200b may further comprise a memory 1025 comprising one or more memory units. The memory 1025 is arranged to be used to store data, received data streams, power level measurements, threshold values, information about the first version and the second version, ICR peer node information, pool of gateways information, information about PDN connections, information about activated and deactivated gateway node configurations, time periods, configurations, schedulings etc. and applications to perform the methods herein when being executed in the second node 200b.

A second computer program may comprise instructions which, when executed on at least one processor, e.g. the processor 1003 cause the at least one processor to carry out the method as described in figure 9. A second carrier may comprise the second computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal or computer readable storage medium.

The present mechanism for handling updates of the first node 100a and the second node 200b may be implemented through one or more processors, such as a processor 803 in the first node arrangement depicted in Figure 8 and a processor 1003 in the second node arrangement depicted in Figure 10, together with computer program code for performing the functions of the embodiments herein. The processor may be for example a Digital Signal Processor (DSP), Application Specific Integrated Circuit (ASIC) processor, Field- programmable gate array (FPGA) processor or micro processor. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the

embodiments herein when being loaded into at least one of the first node 100a and the second node 200b. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code can furthermore be provided as pure program code on a server and downloaded to at least one of the first node 100a and the second node 200b.

Summarized, the following four different alternatives have been described above:

- Alternative 1 : Use an ICR-pair for upgrade.

Alternative 2: Use ICR-pair and one or more external gateway pool node for upgrade.

Alternative 3: Use ICR and Pool in the same node at the same time.

Alternative 4: Use ICR and Pool in the same node but never at the same time.

This the embodiments herein describes how to use the existing 1 +1 ICR hardware (the ICR active and ICR standby gateway node) and still avoid the problem of exposing and being backward compatibility of internal node session data, internal architecture and hardware when doing an In Service Software Upgrade.

The embodiments herein combines the ICR functionality with the Pool of Gateways functionality or the SGW relocation functionality within the same hardware to allow upgrade of the hardware nodes without exposing the internal data structures, architecture and hardware changes between releases.

Two gateway nodes, the first gateway GW1 and the second gateway GW2, are configured within the same node. One is running ICR (the first gateway GW1 ) and one is substantially empty (the second gateway GW2) and running as a normal gateway but is blocked from taking new sessions.

To upgrade an ICR node setup the sequence may be the following.

1 ) First, the standby site B is upgraded to version V2.

2) The sessions on the ICR active gateway node (e.g. GW1 (a) on site A) is moved to the upgraded node on site B (e.g. the replica GW2(b) of the second gateway node GW2(a)) using the Pool of Gateways functionality or the SGW relocation functionality.

3) When the first gateway node GW1 (a) is substantially empty from sessions, the first node 100a at site A may be upgraded to version V2.

4) When both nodes 100a, 200b are upgraded, the replica GW2(b) of the second gateway node GW2(a) may become the active ICR node and the first gateway node GW1 (a) may become a normal gateway node blocked for new sessions in the same manner as the replica GW2(b) of the second gateway node GW2(a) was before the upgrade. The first gateway node GW1 (a) may continue to be substantially empty and may be able to handle a software upgrade the next time.

The embodiments herein are not limited to the above described embodiments. Various alternatives, modifications and equivalents may be used. Therefore, the above

embodiments should not be taken as limiting the scope of the embodiments, which is defined by the appending claims. It should be emphasized that the term "comprises/comprising" when used in this specification is taken to specify the presence of stated features, integers, steps or components, but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof. It should also be noted that the words "a" or "an" preceding an element do not exclude the presence of a plurality of such elements.

The term "configured to" used herein may also be referred to as "arranged to", "adapted to", "capable of" or "operative to".

It should also be emphasized that the steps of the methods defined in the appended claims may, without departing from the embodiments herein, be performed in another order than the order in which they appear in the claims.