Technical Field

Embodiments disclosed herein relate to methods and apparatus for communicating between a network entity and a remote host using SCTP associations.

Background

The third-generation partnership (3GPP) is currently working on standardization of Long Term Evolution (LTE) and Fifth Generation New Radio (5G NR) technologies. These include improvement of the air interface in the radio access network (RAN) between terminal devices and RAN nodes such as Enhanced Node B (eNB) or 5G Node B (5G NB), together with mobile edge computing which enables cloud computing capabilities at the edge of the RAN in order to enhance performance.

The RAN nodes are connected to a core network by an S1 interface in order to communicate with packet core nodes such as Mobility Management Entities (MME) and Serving Gateways (SGW). The transport network layer is based on Internet Protocol (IP) transport with a Stream Control Transmission Protocol (SCTP) layer added on top of IP. The SCTP layer provides reliable transport of signaling messages.

SCTP multihoming is defined in the Internet Engineering Task Force (IETF) SCTP specification RFC 4960, section 6.4. An SCTP endpoint is considered multi-homed if there is more than one transport address that can be used as a destination address to reach that endpoint. In practice, during an SCTP association initialization, each endpoint may announce a list of additional IP addresses that can be used for communication. A typical SCTP multi-homing usage is to support redundancy links, one path being considered primary and the other(s) can be used when an upper layer implicitly requires messages to be sent to another IP address or if the primary link is down. SCTP multihoming is also used to address communication protocols for different radio technologies in a 5G environment. The 5G architecture is based on end-to-end network slices assignment per multi services deployment and virtual network functions (VNFs) deployment using a container-based technology. 5G and LTE functionality may coexist in the same network.

Summary

Problems may occur when establishing SCTP associations in certain types of network configurations, including those employing cloud computing arrangements using Kubernetes platforms and similar container orchestration systems. Some of these container-based orchestration systems do not support endpoints having multiple IP addresses and so do not support SCTP multihoming. This may result in loss of connectivity if a failure occurs on a single SCTP association.

According to certain embodiments described herein there is provided a method for communicating between a network entity and a remote host. The method comprises establishing a first SCTP association between a first socket and a first remote host socket in the remote host and translating a destination address in SCTP packets between the first socket and the first remote socket, to or from a local network address of the network entity or a second network entity. The method also comprises translating a port number in the SCTP packets between an SCTP port number and a port number dependent on the first socket.

According to certain embodiments described herein there is provided a method for communicating between a network entity and a remote host. The method comprises translating a destination address in a received SCTP packet to a remote socket address in response to determining that a port number of the received SCTP packet is a predetermined port number, and translating the port number to a SCTP port number. Otherwise the method comprises translating a destination address in the SCTP packet to local network address of another network entity and translating a port number in the SCTP packet to a predetermined port number dependent on the other network entity.

According to certain embodiments described herein there is provided a method for communicating between a local network and a remote host. The method comprises translating a destination address in a SCTP packet received from an external network from a first socket address of a first network entity to a local network address of a second network entity and translating a destination address in a SCTP packet received from the local network from the first socket address of the first network entity to a first remote socket address on the external network.

According to certain embodiments described herein there is provided a method of operating a Kubernetes cluster comprising first, second and third network entities. The method comprises establishing a first SCTP association between a first socket having a first socket address and a first remote host socket in a remote host and establishing a second SCTP association between a second socket having a second socket address and a second remote host socket in the remote host. The method exchanges SCTP packets of the first SCTP association with the second network entity by translating between the first socket address or the first remote socket address and a local network address of the second network entity and translating between a SCTP port number and a port number dependent on the first socket. The method exchanges SCTP packets of the second SCTP association with the third network entity by translating between the second socket address or the second remote socket address and a local network address of the third network entity and translating between a SCTP port number and a port number dependent on the second socket.

Certain embodiments provide support for SCTP multi-homing in network entities which do not natively support this, for example in Kubernetes pods which may be provided in 5G core networks and elsewhere.

According to certain embodiments described herein there is provided a network entity for communicating with a remote host, the network entity comprises a processor and memory containing instructions executable by the processor. The network entity is thereby operative to establish a first Stream Control Transmission Protocol (SCTP) association between a first socket and a first remote host socket in the remote host and to translate a destination address in SCTP packets between the first socket and the first remote socket, to or from a local network address of the network entity or a second network entity. The network entity is also operative to translate a port number in the SCTP packets between an SCTP port number and a port number dependent on the first socket.

According to certain embodiments described herein there is provided a network entity for communicating with a remote host, the network entity comprises a processor and memory containing instructions executable by the processor. The network entity is thereby operative to translate a destination address in a received SCTP packet to a remote socket address in response to determining that a port number of the received SCTP packet is a predetermined port number, and to translate the port number to a SCTP port number. Otherwise the network entity is operative to translate a destination address in the SCTP packet to local network address of another network entity and translate a port number in the SCTP packet to a predetermined port number dependent on the other network entity.

According to certain embodiments described herein there is provided a network address translator, NAT, for communicating with a remote host, the NAT comprises a processor and a memory containing instructions executable by the processor. The NAT is thereby operative to translate a destination address in a SCTP packet received from an external network from a first socket address of a first network entity to a local network address of a second network entity, and to translate a destination address in a SCTP packet received from the local network from the first socket address of the first network entity to a first remote socket address on the external network.

According to certain embodiments described herein there is provided a network comprising first, second and third network entities. The first network entity comprises a processor and memory containing instructions executable by the processor. The first network entity is thereby operative to establish a first SCTP association between a first socket having a first socket address and a first remote host socket in a remote host and to establish a second SCTP association between a second socket having a second socket address and a second remote host socket in the remote host. The first network entity is further operative to exchange SCTP packets of the first SCTP association with the second network entity by translating between the first socket address or the first remote socket address and a local network address of the second network entity and translating between a SCTP port number and a port number dependent on the first socket, and to exchange SCTP packets of the second SCTP association with the third network entity by translating between the second socket address or the second remote socket address and a local network address of the third network entity and translating between a SCTP port number and a port number dependent on the second socket.

Certain embodiments also provide corresponding computer programs and computer program products. Brief Description pf Drawings

For a better understanding of the embodiments of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:

Figure 1 is a schematic diagram illustrating a communications system according to some embodiments; Figure 2 is a schematic diagram illustrating a Kubernetes cluster communicating with a remote host according to some embodiments;

Figure 3 is a schematic diagram illustrating internal communications within the Kubernetes cluster according to some embodiments;

Figure 4 is a messaging flow diagram illustrating communication from a remote host to a Kubernetes pod according to some embodiments;

Figure 5 is a messaging diagram illustrating communication from a Kubernetes pod to a remote host according to some embodiments;

Figure 6A and 6B are flow diagrams illustrating methods implemented in a network entity according to some embodiments; Figure 7A and 7B are flow diagrams illustrating methods implemented in another network entity according to some embodiments; and

Figure 8A and 8B are flow diagrams illustrating methods implemented in yet another network entity according to some embodiments.

Description

Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

The following sets forth specific details, such as particular embodiments or examples for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other examples may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and/or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and/or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analogue) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions. Memory may be employed to storing temporary variables, holding and transfer of data between processes, non-volatile configuration settings, standard messaging formats and the like. Any suitable form of volatile memory and non-volatile storage may be employed including Random Access Memory (RAM) implemented as Metal Oxide Semiconductors (MOS) or Integrated Circuits (IC), and storage implemented as hard disk drives and flash memory. Embodiments described herein relate to methods and apparatuses to allow for SCTP multi-homing using endpoints which do not normally support this. A SCTP multi homing endpoint requires two or more IP addresses to establish respective SCTP associations with another SCTP multi-homing endpoint. Endpoints or network entities in certain container-based orchestration systems such as Kubernetes clusters for cloud-based computing support only one IP address. For example, pods in a Kubernetes cluster are allocated only one IP address each. Embodiments described herein provide message routing utilising other pods and address and port translation processes to emulate two or more IP addresses within the pod to allow an SCTP multi homing endpoint to establish multiple SCTP associations with a pod or other network entity which would normally only be associated with one IP address. The provision of SCTP multi-homing usage enables the efficient implementation of SCTP services in many environments where this might not otherwise be possible, including some multi tenant implementations of multiple radio technologies. Since it is possible to add or remove allowed IP addresses per SCTP multi-homing, SCTP usage can be readily scaled.

Kubernetes is an open source platform for managing containerised workload and services and is rapidly growing in usage for cloud computing applications. Its architecture is based on master-nodes separation, where a master acts as the primary control plane for Kubernetes while nodes are the “workers” of a Kubernetes cluster, running a minimal agent that manages the node itself and executing workloads as designed by the master. Kubernetes is a container based approach to computing resources or processes allowing these to be distributed across multiple hardware nodes in an efficient manner. Kubernetes defines pods which are groupings of containers or computing functions guaranteed to be on the same host machine but which may share some resources, such as the host’s operating system, with other pods on the same host machine. The pods are decoupled from the underlying hardware architecture allowing them to be portable across a cloud computing node cluster controlled by the Kubernetes platform. Containers within a pod communicate with each other using a localhost mechanism and Kubernetes allocates a single IP address per pod to allow communication between pods and remote hosts, terminals or other external resources or clients.

Embodiments described herein provide for the deployment of an SCTP multi-homing service in a Kubernetes pod by converting or translating IP addresses and port numbers associated with an SCTP multi-homing endpoint within the pod to use one or more other pods which together with a suitably configured network address translator (NAT) enables mapping of the SCTP multi-homing endpoint IP addresses to the Kubernetes pod. This solution has the advantage of enabling multi-homing usage even with only one IP address per pod without any patch to the standard implementation of the SCTP process making the arrangement transparent to both the SCTP multihoming process within the pod and within the corresponding endpoint in a remote host.

The term network entity used herein refers to any functional or computing process, software and/or hardware that is capable of performing the various network functions described. This may be implemented as a network element, a network node, software which may be tied to particular hardware or which may be portable across different hardware. This software may correspond to container-based groups of computing functions such as a Kubernetes pod which may be an example of a network entity. However, the term network entity is not limited to a Kubernetes pod or other container- based entities, nor to specific hardware.

Figure 1 illustrates a communication system 100 comprising a terminal device 105 and a cloud-computing cluster 110 for providing services to the device 105. The terminal device 105 is coupled to the cluster 110 via a first communications link which may comprise a cellular radio system including one or more radio access network (RAN) nodes 115, a core network 120 and depending on configuration an external network 125 such as the Internet. The terminal device 105 is also coupled to the cluster 110 using a different communications link which may be a different path through the cellular radio system 115, 120, 125 or through a different communications system such as a WiFi wireless link to an optical network 130.

The terminal device 105 may be a Smartphone, Tablet, laptop or any other user device, or an autonomous device embedded in appliances such as Smart Fridges or Electric Vehicles that may form part of the Internet of Things (loT). The cloud computing cluster 110 may comprise several network nodes or servers which host various cloud-computing services. The cloud-computing cluster 110 may be organised using Kubernetes pods and may be connected to the Internet or it may be implemented within the core network 120 of the cellular radio system.

The cellular radio system may be a 4G Long Term Evolution (LTE) network and/or a 5G New Radio (NR) network having a plurality of Enhanced Node B (eNB) and/or NR Node B (NR NB) 115 and a core network 120. The RAN nodes 115 are connected to the core network 120 by an S1 interface in order to communicate with packet core nodes such as Mobility Management Entities (MME) 140 and Serving Gateways (SGW). Two SCTP associations 150X and 150Y support communication between respective SCTP multi-homing endpoints in the terminal device 105 and the remote cluster 110. In an alternative arrangement two multi-homing SCTP associations 160X and 160Y are established between a RAN node 115 and the MME 140 which is provided as part of a Kubernetes orchestrated cluster within the core network 120.

Figure 2 illustrates a communications system 200 having a Kubernetes orchestrated cluster of cloud-computing nodes 210 and a remote host 205 external to the cluster 210. The remote host may be a RAN node 115 and comprises a SCTP process which provides a multihoming endpoint 280 having two sockets or connections 285X and 285Y each with a respective IP address.

The cluster 210 comprises a plurality of network nodes or network elements 260 each comprising processing circuitry 262, memory 264 and a communications interface 266 to communicate with other network elements 260 within the cluster 210 and nodes or other devices external to the cluster, such as the remote host 205. The network elements 260 are orchestrated or controlled by a Kubernetes platform 290 to provide a number of Kubernetes pods 270. The pods 270 are each associated with a single IP address to enable communication with all containers within the respective pod.

One of the pods (Pod A) comprises a SCTP process which provides a multihoming endpoint within the pod to establish multiple SCTP associations 250X and 250Y with the sockets 285X and 285Y of the remote host 205. These associations 250X, 250Y may be supported over an external network 225 such as the Internet 125 and/or a core network 120 of a cellular radio system 100. The multihoming endpoint within pod A requires two (or more) IP addresses but is only addressable from outside the pod 270 by a single IP address.

Figure 3 is a schematic illustrating communication between two multihoming SCTP sockets within pod A of figure 2 and an external network. Three Kubernetes pods are shown - pod A 370A, pod B 370B and pod C 370C and which form part of a local network 383. The local network is coupled to an external network 385 via a network address translator (NAT) 394.

Pod A 370A comprises an SCTP process 372 capable of establishing multiple associations using respective sockets 374X and 374Y. The SCTP process 372 may be software implemented functionality as known and is of a standard configuration transparently available to an external remote host. SCTP multihoming is defined in the IETF SCTP specification RFC 4960, section 6.4. Pod A also comprises a local network socket 387 having an IP address for connecting with the local network 383 and via the NAT 394 with the external network 385. Pod A also comprises a network translator 376 coupled between the local network socket 387 and the SCTP multihoming sockets 374X and 374Y. The network translator 376 is software implemented functionality and provides network translator sockets 378X and 378Y for connecting to respective SCTP multihoming sockets 374X and 374Y.

Pod B 370B and pod C 370C each comprise a local network socket having a respective IP address for connecting with the local network and are configured to support the network translator 376 to provide a network translator solution 392 which translates the IP addresses of the multihoming sockets 374X and 374Y to the IP addresses of pods B and C respectively. This provides for SCTP messages or packets directed to SCTP multihoming socket 374X to be forwarded through the NAT 394 to pod B 370B which, following a suitable translation, then forwards them to the socket 374X within pod A. Similarly packets from SCTP multihoming socket 374X to a remote host on the external network 385 are forwarded from pod A via pod B through the NAT 394. Packets to and from the other SCTP multihoming socket 374Y are similarly routed through pod C.

Other types of traffic addressed to pod A are routed normally using the IP address associated with pod A’s local network socket 387. The pods A, B, C 370 and NAT 394 recognize SCTP multihoming traffic using the port number of the SCTP packets which are then handled differently compared with packets of a single SCTP association or other non-SCTP traffic. Normally, SCTP packets have a single predetermined port number for example 62521. The port number of SCTP multihoming packets are translated in a predetermined way to enable them to be handled differently by pods A, B, C and NAT.

Figure 4 is a messaging diagram illustrating the flow of SCTP packets from a remote host 405 to SCTP multihoming sockets in a Kubernetes pod. The pods 370A, 370B, 370C and NAT 394 correspond with those of figure 3, the references for which are not repeated in figure 4 for simplicity of explanation. This flow of packets is also described with respect to the methods of figures 6B, 7B and 8B which illustrate operation of pod A 370A, pod B 370B and NAT 394 respectively. For simplicity of explanation only the process for handling SCTP packets 403i, 403j, 403k, 403I between socket 1 of the remote host and socket 1 of the SCTP multihoming process in pod A are shown. A corresponding process applies for packets between socket 2 of the remote host and SCTP multihoming socket 2 in pod A.

Figure 4 illustrates the IP addresses of the endpoint sockets of the two SCTP associations, together with the port number for the SCTP multihoming service. SCTP packets addressed to socket 1 374X of the multihoming SCTP process in pod A have a destination IP address and port number 198.127.35.12/24:62521, the port number being 62521 for a private network and 62521 assigned for SCTP multihoming. The IP address suffix “24” is the CIDR format and refers to the number of bits that are part of the network number, the subnet mask. SCTP packets addressed to socket 2 374Y of the multihoming SCTP process in pod A have 198.127.35.13/24:62521. SCTP packets addressed to socket 1 485X of the multihoming SCTP process in a remote host 405 have an IP address and port number 198.127.55.11/24:62521. SCTP packets addressed to socket 2 485Y of the multihoming SCTP process in the remote host 405 have an IP address and port number 198.127.55.12/24:62521. Pod A 370A has a local network address of 10.0.0.1, pod B 370B has a local network address of 10.0.0.2 and pod C has a local network address of 10.0.0.3.

An SCTP packet 403i is initially sent from socket 1 485X of the remote host 405 towards socket 1 374X of the SCTP multihoming process in pod A and has a destination address and port number of 198.127.35.12/24.62521 as shown in the upper part of the packet 403. The sender address and port number 198.127.55.11/24:62521 is shown in the lower part. Whilst not specifically indicated, as is known the SCTP packet will also comprise payload data and control data which is not shown for simplicity of explanation. The packet 403i will be routed towards the local network containing pod A as is known and will be received by the NAT 394. This is shown in step 855 in figure 8B.

The NAT is normally configured to forward received packets towards their final destination on the local network 383. However, packets having a destination address corresponding to the sockets 374X, 374Y of the SCTP multihoming process 372 within pod A 370A are recognized and handled differently. Instead of forwarding such packets towards pod A, packets destined for socket 1 374X are forwarded towards pod B 370B and packets destined for socket 2 374Y are forwarded towards pod C 370C. This is achieved by translating the destination address in the packet 403i from the destination IP address of socket 1 (198.127.35.12) to the local network address of pod B (10.0.0.2). Similarly, packets 403i having a destination IP address corresponding to socket 2 374Y (198.127.35.13) have this translated to the local network address of pod C (10.0.0.3). This translation is shown in step 865 in figure 8B. The translated packets 403j are then forwarded towards pods B and C respectively, as indicated in step 870 of figure 8B.

SCTP packets forwarded from the NAT towards pod B over the local network are received by pod B. Pod B 370B receives the translated packets 403j at step 755 of figure 7B. Pod B is configured to further translate the destination address as well as the port number of the received packets 403j. The destination address in the received packet 403j is translated from the local network address of pod B (10.0.0.2) to the local network address of pod A (10.0.0.1). The port number in the received translated packet 403j is translated from a standard SCTP port number to a port number (65001) dependent on the socket 374X towards which the packet is intended. Any suitable and free port number may be used. Were the packet intended for socket 2 374Y instead of socket 1 374X, a different port number (65002) would be used. This further translation is shown as step 765 in figure 7B. The further translated SCTP packet 403k is then forwarded towards pod A having local network address 10.0.0.1 at step 770.

A further translated packet 403k2 intended for socket 2 374Y is shown in dashed outline. This also includes the IP address of pod A (10.0.0.1) but with a different port number (65002) to differentiate this from SCTP packets intended for socket 1 374Y. For simplicity, only the STCP packet 403k2 associated with the second socket 374Y is shown, however it will be appreciated that packets corresponding to 403i, 403k and 403I will also be involved, with the sender address being 198.127.55.12/24:62521 instead of 198.127.55.11/24:62521.

Pod A receives the further translated SCTP packet 403k at step 655 of figure 6B. Pod A is configured to recognize SCTP packets 403k having a modified port number (65001 or 65002) at step 660 and to handle these differently. Other packets are handled as normal within pod A. The recognized packets 403k are further translated at step 665 by changing both their destination address and their port number. SCTP packets having a port number (65001) corresponding to socket 1 have their destination address translated in the local translator 376 from the local network address of pod A (10.0.0.1) to the destination address of socket 1 (198.127.35.12). Similarly, SCTP packets having a port number (65002) corresponding to socket 2 have their destination address translated in the local translator 376 from the local network address of pod A (10.0.0.1) to the destination address of socket 2 (198.127.35.13).

These SCTP packets also have their port numbers translated from the previously translated port numbers (65001 and65002) back to the standard port number for SCTP multihoming associations (62521). These further translated SCTP packets 403I (198.127.35.12/24:62521) may then be forwarded from an internal local translator socket 1 378X to the SCTP multihoming endpoint socket 1 374X within pod A 370A at step 670. Similarly, further translated SCTP packets 403I (198.127.35.13/24:62521) may be forwarded from an internal local translator socket 2 378Y to the SCTP multihoming endpoint socket 2 374Y within pod A 370A.

This completes the path and translations of the SCTP packets 403 from socket 1 485X of the remote host 405 via pod B to socket 1 374X of pod A 370A to form one SCTP association between the remote host and pod A. Similarly, the path and translations of the SCTP packets 403 from socket 2 485Y of the remote host 405 via pod C to socket 2 374Y of pod A 370A form another SCTP association between the remote host and pod A. This has the advantage of enabling SCTP multihoming between a remote host and a Kubernetes pod 370A even though the pod only has one IP address (10.0.0.1). Whilst the remote host 405 has been shown as having two IP addresses, the methods described may be applied to a remote host having only one IP address, for example another Kubernetes pod.

Figure 5 is a messaging diagram illustrating the flow of SCTP packets from pod A to the remote host 405. This flow of packets is also described with respect to the methods of figures 6A, 7A and 8A which illustrate operation of pod A 370A, pod B 370B and NAT 394 respectively. For simplicity of explanation, only the process for handling SCTP packets 503i, 503j, 503k, 503I between socket 1 of the socket 1 of the SCTP multihoming process in pod A and socket 1 of the remote host is shown. A corresponding process applies for packets between socket 2 in pod A and socket 2 of the remote host. Common references are not repeated in figure 5 for simplicity.

Figure 5 illustrates the IP addresses of the endpoint sockets of the two SCTP associations, together with the port number for the SCTP multihoming service. SCTP packets addressed to socket 1 485X of the remote host 405 have a destination IP address and port number 198.127.55.11/24:62521. SCTP packets addressed to socket 2 485Y of the remote host have 198.127.55.12/24:62521. SCTP packets addressed to socket 1 485X of the remote host from socket 1 in the SCTP multihoming process in pod A have a sender IP address and port number 198.127.35.12/24:62521. SCTP packets addressed to socket 2 485Y of the multihoming SCTP process in the remote host 405 have a sender IP address and port number 198.127.35.13/24:62521.

An SCTP multihoming association between the multihoming process 372 of pod A and that of the remote host 405 is established in known manner using signaling described in IETF RFC 4960 and transported over SCTP packets as described herein. The underlying transport mechanism to be described is transparent to the multihoming associations. This is illustrated in steps 605 and 610 in figure 6A. SCTP packets exchanged between the two endpoints 372 and 405 are handled seamlessly so that there is no modification to the SCTP multihoming process at either pod A or the remote host. Handling of SCTP packets from the remote host to pod A have already been described above. Handling of SCTP packets from pod A to the remote host are described below.

At step 615 SCTP packets 503i are initially sent from socket 1 374X of the SCTP multihoming process 372 in pod A 370A towards socket 1 485X of the SCTP multihoming process in the remote host. These have a destination address and port number of 198.127.55.11/24.62521 as shown in the upper part of the packet 503i. The sender address and port number 198.127.35.12/24:62521 is shown in the lower part. Whilst not specifically indicated, as is known the SCTP packet will also comprise payload data and control data which is not shown for simplicity of explanation. These packets 503i are received by the local translator 376 which has sockets 1 and 2 378Z and 378Y connected to socket 1 and 2 374X and 374Y respectively of the multihoming process 372.

Pod A is configured to translate the destination address of the packets from the IP address of the remote host endpoint socket 1 (198.127.55.11) to the local network address of pod B (10.0.0.2). Similarly, the destination address of packets intended for socket 2 of the remote host are translated from the IP address of the remote host socket (198.127.55.12) to the local network address of pod C (10.0.0.3). The port numbers of these packets are also translated from a standard SCTP port number to a predetermined port number depending on the socket number they were sent from. SCTP packets sent from socket 1 374X have their port number translated from 62521 to 65001 and SCTP packets sent from socket 2 374Y have their port number translated from 62521 to 65002. These translations correspond with step 620 of figure 6. The translated packets 503j and 503j2 are then forwarded from pod A to pod B (or pod C for packets sent from socket 2 374Y) at step 625. For simplicity, only the STCP packet 503j2 associated with the second socket 374Y is shown, however it will be appreciated that packets corresponding to 503i, 503k and 503I will also be involved, with the sender address being 198.127.35.13/24:62521 instead of 198.127.35.12/24:62521.

Figure 7A illustrates a method of operation of pod B (and pod C for handling packets sent from socket 2 374Y). At step 705 the translated packets 503j and 503j2 are received from pod A. Pod B is configured to determine whether the received packet has a predetermined port number at step 710. Received packets not having the predetermined port number may be handled normally. The predetermined port number (65001) corresponds to the socket (374X) of the SCTP multihoming process in pod A from which the packet was originally sent. The predetermined port number (65002) corresponds to the second socket (374Y) of the SCTP multihoming process in pod A from which the packet was originally sent. Suitably recognized packets are further translated at step 715. In this embodiment such packets have their destination address translated from the local network address of pod B (10.0.0.2) to the IP address of the sending SCTP endpoint socket 1 (198.127.35.12) or socket 2 (198.127.35.13) as appropriate, however any free and suitable predetermined address that can be recognized by the NAT may be used. The recognized packets 503j and 503j2 also have their port numbers translated back from the translated port number (65001 or 65002) to the standard port number for SCTP multihoming (24:62521). These further translated packets 503k are then forwarded from pod B onto the local network 383 at step 720.

These modified SCTP packets 503k are not received by pod A as this can only receive packets addressed to its local network address (10.0.0.1) and not the IP addresses of any internal sockets such as sockets 1 and 2 of the multihoming process (198.127.35.12 and 198.127.35.13). Instead the NAT 394 is configured to receive these modified packets 503k and further translate them. As illustrated in figure 8A, the NAT receives these modified packets at step 805 and translates their destination addresses at step 810. The destination address is translated from the IP address of the first or second socket (198.127.35.12 and 198.127.35.13) of the pod A multihoming process to the IP address of the respective socket (198.127.55.11 and 198.127.55.12) of the remote host. These further translated or modified SCTP packets 503I are then forwarded on the external network 385 towards the remote host at step 815. The packets are routed in known manner to their respective sockets 485X and 485Y.

This completes the path and translations of the SCTP packets 503 from socket 1 374X of the SCTP multihoming process of pod A via pod B to socket 1 485X of the remote host 405 to form one SCTP association between pod A and the remote host A. Similarly, the path and translations of the SCTP packets 503 from socket 2 374Y of the SCTP multihoming process of pod A via pod C to socket 2 485Y of the remote host 405 form another SCTP association between pod A and the remote host. This enables SCTP multihoming between a Kubernetes pod 370A and a remote host even though the pod only has one IP address (10.0.0.1). Whilst the remote host 405 has been shown as having two IP addresses, the methods described may be applied to a remote host only having one IP address, for example another Kubernetes pod.

Pods A, B, C and NAT may be configured in any suitable manner for example manually by an operator or using an exchange of signaling control messages.

Whilst the embodiments have been described supporting SCTP multihoming on a Kubernetes pod with two associations, different pluralities of associations can be supported using additional pods configured similarity to pods B and C and a suitably configured NAT. This provides the advantage of allowing seamless scaling of the solution as needed to provide multi IP addresses all whilst being completely transparent to the SCTP multihoming endpoints so that no modifications are needed within these processes. The pods may be part of a cloud computing cluster connected to the Internet or installed within a wireless communications system such as in a 5G core network. The container arrangement of Kubernetes pods used in some embodiments provides a number of advantages including allowing for efficient distribution and reconfiguration of processes across hardware resources as well as handling of maintenance, software updates and restarts without having to build this into the SCTP multihoming process software. Advantageously the translator of the embodiments is transparent to the Kubernetes pods allowing a simple and improved network solution without the need for additional configuration of the Kubernetes pods. This may advantageously be used to provide efficient implementation of SCTP service in a multi-tenant implementation of multiple radio technologies. In a further alternative, the methods and apparatus of the embodiments may be applied to network elements or other equipment not configured as a Kubernetes pod but also having only one IP address. Modifications and other variants of the described embodiment(s) will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is understood that the embodiment(s) is/are not limited to the specific examples disclosed and that modifications and other variants are intended to be included within the scope of this disclosure. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.