Routable application protocol messages between network nodes or functions

Abstract

Embodiments include methods performed by a second network node or function (NNF) to communicate with a first NNF in a communication network. Such methods include receiving a routable message from the first NNF. The routable message includes the following: a message body that includes a message of an application protocol (AP) used for communication between the first and second NNFs, and a header including a first field with an identifier of a function associated with the AP. Such methods include, by a routing function of the second NNF, selecting a function decoder of the second NNF based on the first field and forwarding the routable message to a function handler of the second NNF via the selected function decoder. Such methods include, by the function handler, selecting a message processor of the second NNF for processing the AP message and forwarding the routable message to the selected message processor.

Description

[0001] ROUTABLE APPLICATION PROTOCOL MESSAGES BETWEEN NETWORK NODES OR FUNCTIONS

[0002] TECHNICAL FIELD

[0003] The present disclosure relates generally to communication networks, and more specifically to techniques for improving routability of application-layer messages between network nodes or functions of a communication network, such as for distributed network node implementations.

[0004] BACKGROUND

[0005] The fifth generation (5G) of cellular systems has been standardized within the Third- Generation Partnership Project (3GPP). 5G was developed for maximum flexibility to support many different use cases including enhanced mobile broadband (eMBB), machine type communications (MTC), ultra-reliable low latency communications (URLLC), side-link device- to-device (D2D), and several other use cases. 5G was initially specified in Release 15 (Rel-15) and continues to evolve through subsequent releases.

[0006] Figure 1 shows an exemplary 5G network architecture, including a next generation radio access network (NG-RAN, 199) and a 5G core network (5GC, 198). The NG-RAN may include one or more gNodeB’s (gNBs) connected to the 5GC via one or more NG interfaces, such as gNBs (100, 150) connected via respective interfaces (102, 152). More specifically, the gNBs can be connected to one or more Access and Mobility Management Functions (AMFs) in the 5GC via respective NG-C interfaces and to one or more User Plane Functions (UPFs) in 5GC via respective NG-U interfaces. The 5GC may include various other network functions (NFs), such as Session Management Functions (SMFs).

[0007] In addition, the gNBs can be connected to each other via one or more Xn interfaces, such as Xn interface (140) between gNBs (100, 150). The radio technology for the NG-RAN is often referred to as “New Radio” (NR). Similar to the NG interface, the Xn interface includes the Xn- C control plane interface and the Xn-U user plane interface. With respect to the NR interface to UEs, each of the gNBs can support frequency division duplexing (FDD), time division duplexing (TDD), or a combination thereof. Each of the gNBs can serve a geographic coverage area including one or more cells and, in some cases, can also use various directional beams to provide coverage in the respective cells.

[0008] NG RAN logical nodes (e.g., gNB 100) include a Central Unit (CU or gNB-CU, e.g., 110) and one or more Distributed Units (DU or gNB-DU, e.g., 120, 130). CUs are logical nodes that host higher-layer protocols and perform various gNB functions such controlling the operation of DUs. DUs are decentralized logical nodes that host lower layer protocols and can include, depending on the functional split option, various subsets of the gNB functions. Each CU and DU can include various circuitry needed to perform their respective functions, including processing circuitry, communication interface circuitry (e.g., transceivers), and power supply circuitry.

[0009] A gNB-CU connects to one or more gNB-DUs over respective Fl logical interfaces (e.g., 122 and 132 shown in Figure 1). However, each gNB-DU can be connected to only one gNB-CU. The gNB-CU and its connected gNB-DU(s) are only visible to other gNBs and the 5GC as agNB. In other words, the Fl interface is not visible beyond gNB-CU. Similar to Xn and NG interfaces, the Fl interface includes the Fl-C control plane interface and the Fl-U user plane interface.

[0010] Figure 2 shows a logical architecture for an NG-RAN node (e.g., gNB or ng-eNB) arranged in the split CU / DU architecture, such as gNB 100 in Figure 1. This logical architecture separates the CU into CP and UP functionality, called CU-C (or CU-CP) and CU-U (or CU-UP) respectively. Furthermore, each of the NG, Xn, and Fl interfaces is split into a CP interface (e.g., NG-C) and a UP interface (e.g., NG-U). Moreover, the CU-U and CU-C can communicate via an El interface. Each DU may be connected to only one CU-C, and each CU-U may be connected to only one CU-C. However, a single DU may be connected to multiple CU-Us under the control of the same CU-C, or a single CU-U may be connected to multiple DUs under the control of the same CU-C. Note that the terms “Central Entity” and “Distributed Entity” in Figure 2 refer to physical network nodes.

[0011] Figure 3 shows protocol stacks used on NG-C, Xn-C, and Fl-C control plane interfaces. Each of these protocol stacks includes Internet Protocol (IP)-based transport protocols, including a physical layer, a data link layer, and an IP layer. For the reliable transport of control messages, stream control transmission protocol (SCTP, as defined in IETF RFC 4690) is used above the IP layer. Above the transport protocols are the respective application protocols, known as NGAP, XnAP, and Fl AP. Note that the respective IP layers only support point-to-point transmission (i.e., between two nodes) for delivering the respective application protocol messages. The application protocols may also be considered part of a radio network layer while the transport protocols may also be considered part of a transport network layer. Although not shown in Figure 3, a similar protocol stack is used on the El interface shown in Figure 2.

[0012] The application protocol messages (e.g., for NGAP) do not include information about which protocol a message belongs to. Rather, SCTP associations are used to establish control plane connectivity between two logical nodes (e.g., two gNBs), and each application protocol is bound to an SCTP association using port numbers and SCTP payload protocol (or “stream”) identifiers. Each association between two logical nodes is used for only one application protocol.

[0013] Some application protocol messages include additional information indicating the entities on which a procedure operates. For example, the NGAP protocol which uses identifiers RAN UE NG AP ID and the AMF UE NGAP ID to uniquely identify a particular user equipment (UE) over the NG-C interface. This identity pair can be reused in later procedures addressing the same UE across the same interface for the duration the UE stays connected to the same logical node. However, each UE has a unique identity pair for each network control plane interface, e.g., a first identity pair over NG-C and a second identity pair over Fl-C.

[0014] SUMMARY

[0015] Even so, these application protocols are not designed to be routed efficiently. Conventionally, this has not been a problem since SCTP is for connectivity between two logical nodes and IP is used (as in Figure 3) only for point-to-point transmission. This is due to the conventional 3 GPP architectural view of a node as a single, monolithic entity that performs protocol termination and message processing together, such that there is no need for routing.

[0016] However, message routing is becoming necessary due to the increasing use of distributed node implementations. When a router (or routing function) is used in a distributed implementation, it must decode the application message and extract the routing identity (e.g., UE AP ID pair), use that information to find the correct message processor, then send the application message to the message processor. If the application message is encoded, the message processor must decode it again before processing. This need for multiple decodings of a single application message may increase network energy use and message latency, and may decrease network processing and / or routing capacity. Better solutions are needed.

[0017] An object of embodiments of the present disclosure is to improve application message routing for distributed node implementations in a communication network, such as by providing, enabling, and / or facilitating solutions to overcome exemplary problems summarized above and described in more detail below.

[0018] Embodiments include methods (e.g., procedures) for a second network node configured to communicate with a first network node in a communication network.

[0019] These exemplary methods include receiving from the first network node a routable message that includes the following:

[0020] • a message body that includes a message of an application protocol (AP) used for communication between the first and second network nodes, and

[0021] • a header including a first field that comprises an identifier of a function associated with the AP.

[0022] These exemplary methods also include a routing function of the second network node selecting a function decoder of the second network node based on the first field, and forwarding the routable message to a function handler of the second network node via the selected function decoder. These exemplary methods also include the function handler of the second network node selecting a message processor for processing the AP message and forwards the routable message to the selected message processor.

[0023] In some embodiments, a second field of the header comprises an identifier of the AP. In some of these embodiments, the second field includes one of a plurality of different second predefined values that identify respectively a plurality of different APs used for communication between the first and second network nodes. Also, the first field includes one of a plurality of different first predefined values that identify respectively a plurality of different functions associated with the AP identified by the second field.

[0024] In some embodiments, a third field of the header comprises a source node session identifier and these exemplary methods also includes the following operations:

[0025] • assigning, by the function handler, a target node session identifier to be associated with the source node session identifier; and

[0026] • adding, by the function handler, the target node session identifier to a fourth field of the header before forwarding the routable message to the message processor.

[0027] In some of these embodiments, the fourth field of the header is empty prior to receipt of the routable message by the function handler.

[0028] In some of these embodiments, these exemplary methods also include the function handler receiving from the message processor a second routable message that indicates an outcome of processing the AP message. A header of the second routable message includes the first, second, third, and fourth fields of the header of the routable message forwarded to the message processor. In some variants of these embodiments, these exemplary methods also include the function handler forwarding the second routable message to the routing function via the function decoder.

[0029] In some embodiments, the routable message is received from the first network node in the body of a transport layer protocol message and these exemplary methods also include extracting, by an end-point hander of the second network node, the routable message from the body of the transport layer protocol message. In some of these embodiments, these exemplary methods also include the following operations:

[0030] • establishing, by the end-point handler, a transport layer connection between the first and second network nodes and an association between the transport layer connection and the first network node; and

[0031] • sending, by the end-point handler to the routing function, an indication that the end-point handler is part of a routing path for AP messages between the first and second network nodes.

[0032] In some embodiments, the first and second network nodes are respective gNBs and the AP is XnAP. In other embodiments, the first network node is a core network node or function, the second network node is a gNB, and the AP is NGAP. In other embodiments, the first network node is a gNB centralized unit (gNB-CU), the second network node is a gNB distributed unit (gNB-DU), and the AP is F1AP. In other embodiments, the first network node is a gNB-CU control plane (gNB-CU-C) function, the second network node is a gNB-CU user plane (gNB-CU- U) function, and the AP is El AP.

[0033] In some embodiments, the header of the routable message also includes the following fields: a second field that comprises an identifier of the AP; a third field that comprises a source node session identifier; and a fourth field that comprises a target node session identifier, or is empty. In some of these embodiments, the header of the routable message also includes a fifth field that comprises a source node identifier and a sixth field that comprises a target node identifier. In some variants of these embodiments, the combination of the source node session identifier and the target node session identifier is unique for the combination of the source node identifier, the target node identifier, and the function identifier.

[0034] Other embodiments include network nodes (e.g., base stations, eNBs, gNBs, AMFs, CUs, DUs, etc.) configured to perform operations corresponding to any of the exemplary methods described herein. Other embodiments include non-transitory, computer-readable media storing program instructions that, when executed by processing circuitry, configure such network nodes to perform operations corresponding to any of the exemplary methods described herein.

[0035] These and other embodiments described herein may provide various advantages, benefits, and / or solutions to problems. For example, by removing the need to decode AP messages during routing, embodiments facilitate disaggregation between transport and application protocols. Moreover, by removing the need to decode AP messages during routing, embodiments may reduce energy consumption and latency as well as increase routing / processing capacity. Furthermore, embodiments may facilitate use of end-to-end security on AP message payloads by removing the need for an intermediate decoding of such payloads for routing purposes. Embodiments may also improve distributed implementation of logical nodes or functions in a communication network (e.g., 5G network), thereby promoting and / or facilitating scalability.

[0036] These and other objects, features, and advantages of embodiments of the present disclosure will become apparent upon reading the following Detailed Description in view of the Drawings briefly described below.

[0037] BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 shows an exemplary 5G network architecture.

[0039] Figure 2 shows a logical architecture for an NG-RAN node. Figure 3 shows protocol stacks used on NG-C, Xn-C, and Fl-C control plane interfaces in a 5G network.

[0040] Figure 4 shows an ASN.1 protocol data unit (PDU) definition for NG-AP.

[0041] Figures 5-6 show example implementations of a logical node or function of a communication network.

[0042] Figures 7-8 show two message header variants according to various embodiments of the present disclosure.

[0043] Figure 9 shows an exemplary architecture for a logical node or function, according to some embodiments of the present disclosure.

[0044] Figure 10 (including parts A and B) illustrates message routing based on the exemplary architecture shown in Figure 9, according to some embodiments of the present disclosure.

[0045] Figure 11 (including parts A and B) illustrates connection setup followed by AP signaling based on header variant “A”, according to some embodiments of the present disclosure.

[0046] Figure 12 illustrates connection setup followed by AP signaling based on header variant “B”, according to other embodiments of the present disclosure.

[0047] Figure 13 (including parts A and B) illustrates direct message routing according to some embodiments of the present disclosure.

[0048] Figure 14 shows a flow diagram of an exemplary method for a second network node (e.g., gNB, AMF, CU, DU, etc.), according to various embodiments of the present disclosure.

[0049] Figure 15 shows a communication system according to various embodiments of the present disclosure.

[0050] Figure 16 shows a network node according to various embodiments of the present disclosure.

[0051] Figure 17 shows a virtualization environment in which some embodiments of the present disclosure may be virtualized.

[0052] DETAILED DESCRIPTION

[0053] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided as examples to convey the scope of the subject matter to those skilled in the art.

[0054] In general, all terms used herein are to be interpreted according to their ordinary meaning to a person of ordinary skill in the relevant technical field, unless a different meaning is expressly defined and / or implied from the context of use. 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 or clearly implied from the context of use. The operations of any methods and / or procedures disclosed herein do not have to be performed in the exact order disclosed, unless an operation is explicitly described as following or preceding another operation and / or where it is implicit that an operation must follow or precede another operation. Any feature of any embodiment disclosed herein can apply to any other disclosed embodiment, as appropriate. Likewise, any advantage of any embodiment described herein can apply to any other disclosed embodiment, as appropriate.

[0055] Furthermore, the following terms are used throughout the description given below:

[0056] • Radio Access Node: As used herein, a “radio access node” (or equivalently “radio network node,” “radio access network node,” or “RAN node”) can be any node in a radio access network (RAN) that operates to wirelessly transmit and / or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., gNB in a 3GPP 5G / NR network or an enhanced or eNB in a 3GPP LTE network), base station distributed components (e.g., CU and DU), a high-power or macro base station, a low-power base station (e.g., micro, pi co, femto, or home base station, or the like), an integrated access backhaul (IAB) node, a transmission point (TP), a transmission reception point (TRP), a remote radio unit (RRU or RRH), and a relay node.

[0057] • Core Network Node: As used herein, a “core network node” is any type of node in a core network. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a serving gateway (SGW), aPDN Gateway (P-GW), a Policy and Charging Rules Function (PCRF), an access and mobility management function (AMF), a session management function (SMF), a user plane function (UPF), a Charging Function (CHF), a Policy Control Function (PCF), an Authentication Server Function (AUSF), a location management function (LMF), or the like.

[0058] • Wireless Device: As used herein, a “wireless device” (or “WD” for short) is any type of device that is capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other wireless devices. Communicating wirelessly can involve transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information through air. Unless otherwise noted, the term “wireless device” is used interchangeably herein with the term “user equipment” (or “UE” for short), with both of these terms having a different meaning than the term “network node”.

[0059] • Radio Node: As used herein, a “radio node” can be either a “radio access node” (or equivalent term) or a “wireless device.” • Network Node: As used herein, a “network node” is any node that is either part of the radio access network (e.g., a radio access node or equivalent term) or of the core network (e.g., a core network node discussed above) of a cellular communications network. Functionally, a network node is equipment capable, configured, arranged, and / or operable to communicate directly or indirectly with a wireless device and / or with other network nodes or equipment in the cellular communications network, to enable and / or provide wireless access to the wireless device, and / or to perform other functions (e.g., administration) in the cellular communications network.

[0060] • Node: As used herein, the term “node” (without prefix) can be any type of node that can in or with a wireless network (including RAN and / or core network), including a radio access node (or equivalent term), core network node, or wireless device. However, the term “node” may be limited to a particular type (e.g., radio access node, IAB node) based on its specific characteristics in any given context.

[0061] The above definitions are not meant to be exclusive. In other words, various ones of the above terms may be explained and / or described elsewhere in the present disclosure using the same or similar terminology. Nevertheless, to the extent that such other explanations and / or descriptions conflict with the above definitions, the above definitions should control.

[0062] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system and can be applied to any communication system that may benefit from them.

[0063] In a 5G network, each network control plane interface includes various logical functions. For example, the Fl-C interface includes an interface management function, a system information (SI) management function, a UE context management function, a radio resource control (RRC) message transfer function, etc. Additionally, various procedures are defined to implement the logical functions of the respective control plane interfaces.

[0064] The various application protocols shown in Figure 3 also include messages of three types: an initiating message, a successful outcome message, and an unsuccessful outcome message. Figure 4 shows an ASN. 1 protocol data unit (PDU) definition for NG-AP that illustrates these three messages. In particular, each NG-AP PDU includes a choice between one of these three message types, with each message type include a procedure code, a criticality indicator, and a further indication of the message type (i.e., initiating, successful outcome, or unsuccessful outcome).

[0065] As briefly mentioned above, the messages of the application protocols (e.g., NGAP) do not include information about which protocol a message belongs to. Rather, SCTP associations are used to establish control plane connectivity between two logical nodes (e.g., two gNBs), and each application protocol is bound to an SCTP association using port numbers and SCTP payload protocol (or “stream”) identifiers. Each association between two logical nodes is used for only one application protocol.

[0066] Some application protocol messages include additional information indicating what entities a procedure operates on. For example, some NGAP messages include identifiers RAN UE NG AP ID and AMF UE NGAP ID to uniquely identify a particular UE over the NG-C interface. This identity pair can be reused in later procedures addressing the same UE across the same interface for the duration the UE stays connected to the same logical node. However, each UE has a unique identity pair for each network control plane interface, e.g., a first identity pair over NG- C and a second identity pair over Fl-C.

[0067] In an initial application protocol (AP) message used to set up a UE over one of the network control plane interfaces, the source node (e.g., gNB) can only provide a source UE AP ID since the target UE AP ID is assigned by the target node in response to receiving the initial AP message. The target node reports the target UE AP ID to the source node in the successful outcome response message, at which point the UE is uniquely identifiable with the pair across the interface.

[0068] In modem communication networks (e.g., 5G), it is common practice to divide system functionality into a set of (often many) software components. Each software component is responsible for specific functionality, e.g., a first set of software components for UE-centric functionality and a second set of software components for network node-centric functionality. Taken together, the entirety of software components implement a logical node or function of the network (e.g., RAN node, CN network function, etc.).

[0069] The various software components are executed on compute resources provided by various compute nodes, such as multi-core CPUs in various computing servers. Each software component typically instantiates one or more processes (or threads) that utilize these compute resources. Moreover, multiple compute nodes are typically interconnected by a fast data bus or network (e.g., Ethernet) to form a compute farm. In this manner, a single logical node or function may access a wider range / larger amount of compute resources than provided by a single compute node. Typically, multiple instances of each software component are instantiated and deployed onto the different compute nodes.

[0070] Figure 5 shows one example implementation of a logical node or function of a communication network (e.g., gNB-CU-CP in a 5G network). In this example, the logical node or function includes two software components, each of which includes multiple processes. These are deployed onto two compute nodes (i.e., servers) interconnected by an Ethernet switch. Each compute server utilizes one or more multi-core CPUs to execute the deployed processes of the software components. The example shown in Figure 5 may be typical of a “cloud computing” implementation.

[0071] Figure 6 shows another example implementation of a logical node or function of a communication network (e.g., gNB-CU-CP in a 5G network). In this example, the logical node or function is part of a multi-standard radio base station (MS-RBS) and includes two software components, each of which includes multiple processes. The MS-RBS includes one or more multicore CPUs to execute the deployed processes of the software components. The example shown in Figure 6 may be typical of an integrated / purpose-built implementation.

[0072] Routing of AP messages is becoming necessary due to the increasing use of distributed implementations such as shown in Figures 5-6. Regardless of the specific implementation, it is desirable to efficiently route AP messages to the correct processing instance (e.g., CPU) with minimal latency, energy consumption, and use of compute resources. By doing so, the available compute resources may be better used for compute tasks that maximize and / or increase business value.

[0073] Even so, the APs shown in Figure 3 are not designed to be routed efficiently. Conventionally, this has not been a problem since SCTP is for connectivity between two logical nodes and IP (as used in Figure 3) is used only for point-to-point transmission. This is due to the conventional 3 GPP architectural view of a node as a single, monolithic entity that performs protocol termination and message processing together, such that there is no need for routing.

[0074] When a router (or routing function) is used in a distributed implementation, it must decode the AP message and extract the routing identity (e.g., UE AP ID pair), use that information to find the correct message processor, then send the application message to the message processor. If the application message is encoded, the message processor must decode it again before processing. In other words, each AP message needs to be decoded where the transport protocols are terminated (i.e., for routing) as well as at the computing node destination (i.e., for processing). Decoding and parsing the AP message content to find the routing information consumes compute resources (e.g., CPU and memory), reduces energy efficiency, increases average message latency, and decreases the compute throughput (i.e., for fixed compute resources).

[0075] Moreover, another drawback with the need to decode AP messages for routing is that the message content cannot be secured using end-to-end encryption. For example, a routing function typically does not have the security information needed to decrypt and / or integrity check an AP message that it routes to compute resources.

[0076] Accordingly, embodiments of the present disclosure address these problems and / or issues with flexible and efficient techniques by which a fixed-size routing header is added to each AP message, enabling each AP message to be routed efficiently to the correct message processor (e.g., in a compute node) without decoding and / or parsing the message payload during the routing. In this manner, the router (or routing function) used may be generic without any AP knowledge required. As such, hardware and / or software solutions for accelerating the routing function may be more easily applied, such as extended Berkeley Packet Filter (eBPF) technology.

[0077] Embodiments of the present disclosure may provide various advantages and / or benefits. For example, by removing the need to decode AP messages during routing, embodiments facilitate disaggregation between transport and application protocols, such that embodiments may be utilized with various transport protocols including SCTP, TCP (as defined in IETF RFC9392), QUIC (as defined in IETF RFC9000), and UDP (as defined in IETF RFC768). Moreover, by removing the need to decode AP messages during routing, embodiments may reduce energy consumption and latency as well as increase routing / processing capacity.

[0078] Furthermore, embodiments may facilitate use of end-to-end security on AP message payloads by removing the need for an intermediate decoding of such payloads for routing purposes. Moreover, embodiments may facilitate multi-protocol endpoints in which a single transport connection may be used for multiple AP protocols. At a high level, embodiments improve distributed implementation of logical nodes or functions in a communication network (e.g., 5G network), thereby promoting and / or facilitating scalability.

[0079] In general, embodiments can be based on two different header variants, referred to below as “A” (or HA) and “B” (or HB). Header variant A is more beneficial with respect to inter-node bandwidth requirements while Header variant B is more beneficial for reduced transport protocol state management. These two header variants have different sizes, with each header variant including multiple mandatory fields of fixed sizes. Thus, each header variant also has a fixed size, i.e., of all headers according to that variant.

[0080] Both header variants add an envelope / container structure that encapsulates an AP message payload, similar to an IP header. Alternately, both header variants may be viewed as adding a thin routing layer above the transport protocols.

[0081] Figure 7 shows a diagram of a message (700) that includes a header (710) of variant A and a payload (720), according to some embodiments of the present disclosure. The payload (720) may contain a message of any of the APs discussed above, to be delivered to a destination. The header includes the following fields:

[0082] • Protocol identifier (711) - identifies the AP included in the payload, e.g., Fl-AP. Fixed size field according to the number of different values needed, e.g., two bits to identify one of four AP options.

[0083] • Function identifier (712) - identifies a function in the AP indicated by the protocol identifier, e.g., UE mobility function, cell modification function, etc. Fixed size field according to the number of different values needed for each AP. For example, the same values of the function identifier field may correspond to different functions in Xn-AP and Fl-AP.

[0084] • Target session identifier (ID, 713) - a target node internal identity, e.g., of a resourceobject (UE Context) or a message processor. Fixed size field with values that may be node- and / or function-dependent.

[0085] • Source session ID (714): a source node internal identity, e.g., of a resource-object (UE Context) or a message processor. Fixed size field with values that may be node- and / or function-dependent.

[0086] Note that the header in Figure 7 does not include fields for target node and source node identifiers. Thus, before any AP messaging, an association needs to be created by having the source and target nodes exchange their node identities (and possible more). In this manner, a connection becomes associated with a pair of communicating peer nodes.

[0087] Figure 8 shows a diagram of a message (800) that includes a header (810) of variant B and a payload (820), according to other embodiments of the present disclosure. The payload may contain a message of any of the APs discussed above, to be delivered to a destination. In addition to the fields of header variant A listed above, the header in Figure 8 includes the following fields:

[0088] • Target node ID (815) - target node identifier, e.g., gNB ID, DU ID, etc.

[0089] • Source node ID (816) - source node identifier, e.g., AMF ID, CU ID, etc.

[0090] Given these additional fields, an implicit association may be created as the first AP message is received, in a similar manner as done for network address translation (NAT) routing.

[0091] Both header variants facilitate more efficient architectures for routing AP messages in communication networks (e.g., 5G networks), especially for distributed node implementations. Figure 9 shows an exemplary architecture for a logical node or function (900) that facilitates efficient routing of AP messages, according to some embodiments of the present disclosure. The exemplary architecture includes the following logical elements:

[0092] • End-point handlers (910) - responsible for setup and shutdown of connections, data packet handling, and segmenting of data flows into messages for stream-based transport (e.g., SCTP or TCP). May

[0093] • Routers (920, also referred to as “routing functions”) - responsible for mapping between end-point handlers and pairs of node IDs, in order to route messages between end-point handlers and function handlers (described below).

[0094] • Function decoders (930) - responsible for managing a pool of function handlers, e.g., for workload balancing and / or handler-specific functionality. • Function handlers (940) - responsible for managing a pool of function processors (described below), including load balancing and message routing.

[0095] • Processors (950) - responsible for processing AP message content.

[0096] In the exemplary architecture shown in Figure 9, each logical element is shown as a separate elementary component that is responsible for specific functionality. However, this arrangement may result in several inter-component hops to route a single message to its processor, which increase latency.

[0097] Figure 10 (including parts A and B) illustrates message routing based on the exemplary architecture shown in Figure 9, according to some embodiments of the present disclosure. In particular, Figure 10 shows how routing of certain messages from a source node (1020) require multiple hops between elements within a target node (1010), e.g., from end-point handler El to router R1 to function decoder F3 to function handler HB1 to processor HBla, and in the reverse order in return.

[0098] Figure 11 (including parts A and B) illustrates connection setup followed by AP signaling based on header variant A, according to some embodiments of the present disclosure. The elementary architecture shown in Figure 9 is assumed to be used in these embodiments, such that the target node (1010) is arranged in the same manner as logical node or function (900). Initially, the source node (1020) and the target node exchange messages to set up a transport layer protocol (e.g., TCP, SCTP, etc.) connection. Subsequently, the source node sends an association setup request message to the target node, whose end-point handler El retrieves the {SourceNode-1, TargetNode-1} pair from the header and binds the established transport connection to the {TargetNode-1, SourceNode-1} pair.

[0099] Next end-point handler El instructs target node routers R1 and R2 to associate El as a path to the source node. At this point, R1 and R2 know the path for AP messages to the source node. Subsequently, upon receipt of an AP message from the source node, target node end-point handler El maps the transport layer connection to the {SourceNode-1, TargetNode-1} pair. El then forwards the AP message to Rl, which then forwards the message to Fl for processing.

[0100] In the exemplary architecture illustrated by Figure 11, multiple transport layer connections may be established and associated with the same {TargetNodelD, SourceNodelD} pair. However, the association setup procedure must be performed with each new connection established. Moreover, all transport layer connections are treated equally and AP messages may be received on one connection and responded to on another connection.

[0101] Figure 12 illustrates connection setup followed by AP signaling based on header variant B, according to other embodiments of the present disclosure. The elementary architecture shown in Figure 9 is assumed to be used in these embodiments, such that the target node (1010) is arranged in the same manner as logical node or function (900). Unlike the embodiments based on header variant A described above, no explicit association signaling is used in these embodiments.

[0102] Initially, the source node (1020) and the target node exchange messages to set up a transport layer protocol (e.g., TCP, SCTP, etc.) connection. Subsequently, the source node sends an AP message to the target node, whose end-point handler El binds the source node (e.g., based on source node ID in the AP message) to the interface by which the message was received, and forwards the message to router Rl. Next, router R1 retrieves the {SourceNode-1, TargetNode-1} pair from the header and associates El with {TargetNode-1, SourceNode-1 } pair, i.e., as a routing path between the target node and the source node.

[0103] Rl instructs router R2 to perform the same association between El and the {TargetNode- 1, SourceNode-1 } pair, based on which both Rl and R2 are aware of the routing path between the target node and the source node without any knowledge of the underlying transport layer details. Rl then forwards the message to Fl for processing.

[0104] Each time a message with an unrecognized / new {SourceNodelD, TargetNodelD} pair is received, a new association is created by Rl and R2. On the other hand, a single connection may be used to provide service for multiple nodes (e.g., gNBs).

[0105] The procedure shown in Figure 12 may be repeated for every new connection between the source and target nodes. For example, whenever an initial message is received on a new connection, its path is added to the list of paths that can be used for communication between the target node and the source node. Either the source node or the target node may initiate a new connection and each path is treated equally, such that AP messages may be received on one connection path and responded to on another connection path. This is consistent with the objective of transport layer disaggregation or independence.

[0106] The fields Target Session ID and Source Session ID in Figures 7-8 uniquely identify a session with respect to the source and target nodes, respectively. In general, the duration of a session may be relatively short (e.g., for a procedure) or relatively long (e.g., validity of a UE context or a cell context). These IDs may be assigned according to node implementations but the allocation of Target Session ID and Source Session ID should be done uniquely for each {TargetNodelD, SourceNodelD, FunctionlD} tuple. When a {TargetSessionlD, SourceSessionlD} pair is reused in multiple such tuples, it is not a globally unique identifier.

[0107] Additionally, in all initial AP messages, the TargetNodelD field is set to a predefined value of <empty>. The actual value for the TargetNodelD is assigned by a target node function handler or message processor that receives the initial AP message. For example, in Figure 10B, function handler HB1 sets the actual value TargetNodeID=456 and includes it in subsequent messages. In some embodiments, a direct path to the appropriate message processor for an AP message may be registered once the target routing ID has been assigned. This allows subsequent AP messages to bypass various inter-component routing hops in the target node, thereby reducing latency. Figure 13 (including parts A and B) illustrates direct message routing according to some embodiments of the present disclosure. The elementary architecture shown in Figure 9 is assumed to be used in these embodiments, such that the target node (1010) is arranged in the same manner as logical node or function (900).

[0108] Initially, the source node (1020) sends an AP message that includes a function ID that is associated with target node function decoder F3. End-point handler El forwards the message to router Rl, which selects F3 and forwards the message to that function decoder. F3 then selects function handler HB1 for the message and forwards the message to that function handler, which assigns a TargetNodeID=456 and then forwards the message to processor HBla.

[0109] HB1 also sends a direct route setup message to end-point handler El, based on which El determines to route subsequent AP messages for tuple {TargetNodeID=456, SourceNodeID=123, FunctionID=F3} directly to processor HBla for processing. When the next AP message arriving from the source node identifies F3, end-point handler El identifies that a direct route to HBla exists for {TargetNodeID=456, SourceNodeID=123, FunctionID=F3}, and routes the AP message directly to processor HBla accordingly.

[0110] Various embodiments described herein are applicable for cloud computing deployments, e.g., based on computing resources housed in data centers. For example, the inter-element signaling shown in various figures discussed above could be over new or existing node interfaces. Embodiments are equally applicable to single node deployments (e.g., Figure 6), where the interelement signaling shown in various figures discussed above could be used to select a process on the same CPU or even a CPU core.

[0111] Various features of the embodiments summarized above correspond to various operations illustrated in Figure 14, which shows an exemplary method (e.g., procedure) for a second network node or function (NNF) configured to communicate with a first NNF in a communication network. In other words, various features of the operations described below correspond to various embodiments summarized above. The exemplary method can be performed by any appropriate NNF (e.g., gNB, AMF, CU, DU, etc.) such as described elsewhere herein. Although Figure 14 shows specific blocks in particular orders, the operations of the exemplary method can be performed in different orders than shown and can be combined and / or divided into blocks having different functionality than shown. Optional blocks or operations are indicated by dashed lines.

[0112] The exemplary method includes the operations of block 1420, where the second NNF receives from the first NNF a routable message that includes the following: • a message body that includes a message of an application protocol (AP) used for communication between the first and second NNFs, and

[0113] • a header including a first field that comprises an identifier of a function associated with the AP.

[0114] The exemplary method also includes the operations of block 1430, where a routing function of the second NNF selects a function decoder of the second NNF based on the first field, and forwards the routable message to a function handler of the second NNF via the selected function decoder. The exemplary method also includes the operations of block 1450, where the function handler of the second NNF selects a message processor of the second NNF for processing the AP message and forwards the routable message to the selected message processor.

[0115] In some embodiments, the header also includes a second field that comprises an identifier of the AP. In some of these embodiments, the second field includes one of a plurality of different second predefined values that identify respectively a plurality of different APs used for communication between the first and second NNFs. Also, the first field includes one of a plurality of different first predefined values that identify respectively a plurality of different functions associated with the AP identified by the second field. In some variants of these embodiments, the plurality of different APs include at least two of the following: F1AP, El AP, NGAP, and XnAP.

[0116] In some embodiments, the header also includes third and fourth fields and the exemplary method also includes the following operations, labelled with corresponding block numbers:

[0117] • (1435) assigning, by the function handler, a target session identifier to be associated with a source session identifier included in the third field; and

[0118] • (1440) adding, by the function handler, the target session identifier to the fourth field before forwarding the routable message to the message processor.

[0119] Header variant A discussed above in relation to Figure 7 is an example of these embodiments. In some of these embodiments, the fourth field of the header is empty prior to receipt of the routable message by the function handler.

[0120] In some of these embodiments, the exemplary method also includes the operations of block 1455, where the function handler receives from the message processor a second routable message that indicates an outcome of processing the AP message. A header of the second routable message includes the first, second, third, and fourth fields of the header of the routable message forwarded to the message processor. Figure 10 (including parts A-B) and Figure 13 (including parts A-B) show examples of these embodiments. In some variants of these embodiments, the exemplary method also includes the operations of block 1460, where the function handler forwards the second routable message to the routing function via the function decoder.

[0121] In some of these embodiments, the exemplary method also includes the operations of block 1470 where the function handler sends, to an end-point handler of the second NNF, a direct route setup request that includes the following: an identifier of the function handler, an identifier of the selected message processor, the source session identifier, and the target session identifier. Figure 13 (including parts A-B) shows an example of these embodiments.

[0122] In some variants of these embodiments, the exemplary method also includes the following operations, labelled with corresponding block numbers:

[0123] • (1480) receiving, by the end-point handler from the first NNF, a further routable message comprising: a further message body that includes a further message of the AP, and a further header including the first field that comprises the identifier of the function associated with the AP; and

[0124] • (1490) based on the direct route setup request, forwarding the further routable message directly to the message processor without handling by the routing function, the function decoder, and the function handler (e.g., as done for the original routable message).

[0125] In some embodiments, the routable message is received from the first NNF in the body of a transport layer protocol message, and the exemplary method also includes the operations of block 1425, where an end-point hander of the second NNF extracts the routable message from the body of the transport layer protocol message. In some of these embodiments, the exemplary method also includes the following operations, labelled with corresponding block numbers:

[0126] • (1405) establishing, by the end-point handler, a transport layer connection between the first and second NNFs and an association between the transport layer connection and the first NNF; and

[0127] • (1410) sending, by the end-point handler to the routing function, an indication that the endpoint handler is part of a routing path for AP messages between the first and second NNFs. In some variants of these embodiments, the header of the routable message comprises a fifth field that includes an identifier of the first NNF and a sixth field that includes an identifier of the second NNF, and the association is established based on the fifth and sixth fields of the header. Figure 12 shows an example of these variants, based on header variant B discussed above in relation to Figure 8.

[0128] In other variants of these embodiments, establishing the association between the transport layer connection and the first NNF in block 1405 includes the operations of sub-block 1406, where after establishing the transport layer connection, the end-point handler receives from the first NNF an association setup request that includes an identifier of the first NNF and an identifier of the second NNF. In these variants, the association is established based on the identifiers in the association setup request. Figure 11 shows an example of these variants, based on header variant A discussed above in relation to Figure 7. In some embodiments, the first and second NNFs are respective gNBs in a RAN and the AP is XnAP. In other embodiments, the first NNF is a core NF, the second NNF is a gNB in a RAN, and the AP is NGAP. In other embodiments, the first NNF is a gNB centralized unit (gNB- CU), the second NNF is a gNB distributed unit (gNB-DU), and the AP is F1AP. In other embodiments, the first NNF is a gNB-CU control plane (gNB-CU-C) function, the second NNF is a gNB-CU user plane (gNB-CU-U) function, and the AP is El AP.

[0129] In some embodiments, the header of the routable message also includes the following fields:

[0130] • a second field that comprises an identifier of the AP;

[0131] • a third field that comprises a source session identifier; and

[0132] • a fourth field that comprises a target session identifier, or is empty.

[0133] In some of these embodiments, the header of the routable message also includes a fifth field that comprises a source node identifier and a sixth field that comprises a target node identifier. In some variants of these embodiments, the combination of the source session identifier and the target session identifier is unique for the combination of the source node identifier, the target node identifier, and the function identifier.

[0134] In some embodiments, the routing function, the function handler, the function decoder, and the message processor are implemented as processes in a cloud computing environment.

[0135] Although various embodiments are described above in terms of methods, techniques, and / or procedures, the person of ordinary skill will readily comprehend that such methods, techniques, and / or procedures can be embodied by various combinations of hardware and software in various systems, communication devices, computing devices, control devices, apparatuses, non-transitory computer-readable media, computer program products, etc.

[0136] Figure 15 shows an example of a communication system 1500 in accordance with some embodiments. In this example, communication system 1500 includes a telecommunication network 1502 that includes an access network 1504 (e.g., RAN) and a core network 1506, which includes one or more core network nodes 1508. Access network 1504 includes one or more access network nodes, such as network nodes 1510a-b (one or more of which may be generally referred to as network nodes 1510), or any other similar 3GPP access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, telecommunication network 1502 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in telecommunication network 1502 that supports an ORAN specification (e.g., published by the O-RAN Alliance or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in telecommunication network 1502, including one or more network nodes 1510 and / or core network nodes 1508.

[0137] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU- CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e. g. , r App), or any combination thereof (the adj ective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the O-RAN Alliance or comparable technologies. Network nodes 1510 facilitate direct or indirect connection of UEs, such as by connecting UEs 1512a-d (one or more of which may be generally referred to as UEs 1512) to core network 1506 over one or more wireless connections.

[0138] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, communication system 1500 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. Communication system 1500 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0139] UEs 1512 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with network nodes 1510 and other communication devices. Similarly, network nodes 1510 are arranged, capable, configured, and / or operable to communicate directly or indirectly with UEs 1512 and / or with other network nodes or equipment in telecommunication network 1502 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in telecommunication network 1502.

[0140] In the depicted example, core network 1506 connects network nodes 1510 to one or more hosts, such as host 1516. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. Core network 1506 includes one or more core network nodes (e.g., 1508) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of core network node 1508. Example core network nodes include functions of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0141] Host 1516 may be under the ownership or control of a service provider other than an operator or provider of access network 1504 and / or telecommunication network 1502, and may be operated by the service provider or on behalf of the service provider. Host 1516 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0142] As a whole, communication system 1500 of Figure 15 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.15 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox. In some examples, telecommunication network 1502 is a cellular network that implements 3GPP standardized features. Accordingly, telecommunication network 1502 may support network slicing to provide different logical networks to different devices that are connected to telecommunication network 1502. For example, telecommunication network 1502 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0143] In some examples, UEs 1512 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to access network 1504 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from access network 1504. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e., being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0144] In the example, hub 1514 communicates with access network 1504 to facilitate indirect communication between one or more UEs (e.g., 1512c and / or 1512d) and network nodes (e.g., 1510b). In some examples, hub 1514 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, hub 1514 may be a broadband router enabling access to core network 1506 for the UEs. As another example, hub 1514 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1510, or by executable code, script, process, or other instructions in hub 1514. As another example, hub 1514 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, hub 1514 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, hub 1514 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which hub 1514 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, hub 1514 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0145] Hub 1514 may have a constant / persistent or intermittent connection to network node 1510b. Hub 1514 may also allow for a different communication scheme and / or schedule between hub 1514 and UEs (e.g., 1512c and / or 1512d), and between hub 1514 and core network 1506. In other examples, hub 1514 is connected to core network 1506 and / or one or more UEs via a wired connection. Moreover, hub 1514 may be configured to connect to an M2M service provider over access network 1504 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with network nodes 1510 while still connected via hub 1514 via a wired or wireless connection. In some embodiments, hub 1514 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to network node 1510b. In other embodiments, hub 1514 may be a non-dedicated hub - that is, a device capable of routing communications between the UEs and network node 1510b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0146] In some embodiments, core network node 1108 and / or one or more network nodes 1110 may be configured to perform various operations attributed to a second NNF (or target node) in various embodiments described above, including the exemplary method shown in Figure 14.

[0147] Figure 16 shows a network node 1600 in accordance with some embodiments. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (e.g., radio base stations, Node Bs, eNBs, gNBs), and O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU).

[0148] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0149] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSRBSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0150] Network node 1600 includes processing circuitry 1602, memory 1604, communication interface 1606, and power source 1608. Network node 1600 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which network node 1600 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, network node 1600 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1604 for different RATs) and some components may be reused (e.g., a same antenna 1610 may be shared by different RATs). Network node 1600 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1600, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 1600.

[0151] Processing circuitry 1602 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 1600 components, such as memory 1604, to provide network node 1600 functionality.

[0152] In some embodiments, processing circuitry 1602 includes a system on a chip (SOC). In some embodiments, processing circuitry 1602 includes one or more of radio frequency (RF) transceiver circuitry 1612 and baseband processing circuitry 1614. In some embodiments, RF transceiver circuitry 1612 and baseband processing circuitry 1614 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1612 and baseband processing circuitry 1614 may be on the same chip or set of chips, boards, or units.

[0153] Memory 1604 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by processing circuitry 1602. Memory 1604 may store any suitable instructions, data, or information, including a computer program, software, an application including logic, rules, code, tables, and / or other instructions (collectively denoted computer program 1604a, which may be in the form of a computer program product) capable of being executed by processing circuitry 1602 and utilized by network node 1600. Memory 1604 may be used to store any calculations made by processing circuitry 1602 and / or any data received via communication interface 1606. In some embodiments, processing circuitry 1602 and memory 1604 is integrated.

[0154] Communication interface 1606 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, communication interface 1606 comprises port(s) / terminal(s) 1616 to send and receive data, for example to and from a network over a wired connection. Communication interface 1606 also includes radio frontend circuitry 1618 that may be coupled to, or in certain embodiments a part of, antenna 1610. Radio front-end circuitry 1618 comprises filters 1620 and amplifiers 1622. Radio front-end circuitry 1618 may be connected to an antenna 1610 and processing circuitry 1602. The radio front-end circuitry may be configured to condition signals communicated between antenna 1610 and processing circuitry 1602. Radio front-end circuitry 1618 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. Radio front-end circuitry 1618 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1620 and / or amplifiers 1622. The radio signal may then be transmitted via antenna 1610. Similarly, when receiving data, antenna 1610 may collect radio signals which are then converted into digital data by radio front-end circuitry 1618. The digital data may be passed to processing circuitry 1602. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0155] In certain alternative embodiments, network node 1600 does not include separate radio front-end circuitry 1618, instead, processing circuitry 1602 includes radio front-end circuitry and is connected to antenna 1610. Similarly, in some embodiments, all or some of RF transceiver circuitry 1612 is part of communication interface 1606. In still other embodiments, communication interface 1606 includes one or more ports or terminals 1616, radio front-end circuitry 1618, and RF transceiver circuitry 1612, as part of a radio unit (not shown), and communication interface 1606 communicates with baseband processing circuitry 1614, which is part of a digital unit (not shown).

[0156] Antenna 1610 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. Antenna 1610 may be coupled to radio front-end circuitry 1618 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, antenna 1610 is separate from network node 1600 and connectable to network node 1600 through an interface or port. Antenna 1610, communication interface 1606, and / or processing circuitry 1602 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, antenna 1610, communication interface 1606, and / or processing circuitry 1602 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0157] Power source 1608 provides power to the various components of network node 1600 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). Power source 1608 may further comprise, or be coupled to, power management circuitry to supply the components of network node 1600 with power for performing the functionality described herein. For example, network node 1600 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of power source 1608. As a further example, power source 1608 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0158] Embodiments of network node 1600 may include additional components beyond those shown in Figure 16 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, network node 1600 may include user interface equipment to allow input of information into network node 1600 and to allow output of information from network node 1600. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for network node 1600.

[0159] In some embodiments, one or more network nodes 1600 may be configured to perform various operations attributed to a second NNF (or target node) in various embodiments described above, including the exemplary method shown in Figure 14.

[0160] Figure 17 is a block diagram illustrating a virtualization environment 1700 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1700 hosted by one or more hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 1700 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface.

[0161] Applications 1702 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 1700 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. In some embodiments, one or more virtual nodes 1702 may be configured to perform various operations attributed to a second NNF (or target node) in various embodiments described above, including the exemplary method shown in Figure 14.

[0162] Hardware 1704 includes processing circuitry, memory that stores software and / or instructions (collectively denoted computer program 1704a, which may be in the form of a computer program product) executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1706 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1708a and 1708b (one or more of which may be generally referred to as VMs 1708), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. Virtualization layer 1706 may present a virtual operating platform that appears like networking hardware to the VMs 1708.

[0163] VMs 1708 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1706. Different embodiments of the instance of a virtual appliance 1702 may be implemented on one or more of VMs 1708, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0164] In the context of NFV, each VM 1708 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each VM 1708, and that part of hardware 1704 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1708 on top of the hardware 1704 and corresponds to the application 1702.

[0165] Hardware 1704 may be implemented in a standalone network node with generic or specific components. Hardware 1704 may implement some functions via virtualization. Alternatively, hardware 1704 may be part of a larger cluster of hardware (e.g., such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration function 1710, which, among others, oversees lifecycle management of applications 1702. In some embodiments, hardware 1704 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1712 which may alternatively be used for communication between hardware nodes and radio units.

[0166] The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the spirit and scope of the disclosure. Various embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

[0167] The term unit, as used herein, can have conventional meaning in the field of electronics, electrical devices and / or electronic devices and can include, for example, electrical and / or electronic circuitry, devices, modules, processors, memories, logic solid state and / or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and / or displaying functions, and so on, as such as those that are described herein.

[0168] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0169] As described herein, device and / or apparatus can be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of a device or apparatus, instead of being hardware implemented, be implemented as a software module such as a computer program or a computer program product comprising executable software code portions for execution or being run on a processor. Furthermore, functionality of a device or apparatus can be implemented by any combination of hardware and software. A device or apparatus can also be regarded as an assembly of multiple devices and / or apparatuses, whether functionally in cooperation with or independently of each other. Moreover, devices and apparatuses can be implemented in a distributed fashion throughout a system, so long as the functionality of the device or apparatus is preserved. Such and similar principles are considered known to a skilled person.

[0170] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0171] In addition, certain terms used in the present disclosure, including the specification and drawings, can be used synonymously in certain instances (e.g., “data” and “information”). Although such terms may be used synonymously herein, there may also be instances where such terms are not intended to be used synonymously.

[0172] Embodiments of the techniques and apparatus described herein also include, but are not limited to, the following enumerated examples:

[0173] Al. A method performed by a second network node to communicate with a first network node in a communication network, the method comprising: receiving, from the first network node, a routable message comprising: a message body that includes a message of an application protocol (AP) used for communication between the first and second network nodes, and a header including a first field that comprises an identifier of a function associated with the AP; selecting, by a routing function of the second network node, a function decoder of the second network node based on the first field, and forwarding the routable message to a function handler of the second network node via the selected function decoder; and selecting, by the function handler, a processor for processing the AP message and forwarding the routable message to the selected processor.

[0174] Ala. The method of embodiment Al, wherein a second field of the header comprises an identifier of the AP.

[0175] Alb. The method of embodiment Ala, wherein: the second field includes one of a plurality of different second predefined values that identify respectively a plurality of different APs used for communication between the first and second network nodes; and the first field includes one of a plurality of different first predefined values that identify respectively a plurality of different functions associated with the AP identified by the second field.

[0176] Ale. The method of embodiment Alb, wherein the plurality of different APs include at least two of the following: Fl AP, E1AP, NGAP, and XnAP.

[0177] A2. The method of any of embodiments Al -Ale, wherein a third field of the header comprises a source node session identifier and the method further comprises: assigning, by the function handler, a target node session identifier to be associated with the source node session identifier; and adding, by the function handler, the target node session identifier to a fourth field of the header before forwarding the routable message to the processor.

[0178] A2a. The method of embodiment A2, wherein the fourth field of the header is empty prior to receipt of the routable message by the function handler.

[0179] A3. The method of any of embodiments A2-A2a, further comprising receiving, by the function handler from the processor, a second routable message that indicates an outcome of processing the AP message, wherein a header of the second routable message includes the first, second, third, and fourth fields of the header of the routable message forwarded to the processor.

[0180] A3a. The method of embodiment A3, further comprising forwarding, by the function handler, the second routable message to the routing function via the function decoder.

[0181] A4. The method of any of embodiments A2-A3a, further comprising sending, by the function handler to an end-point handler of the second network node, a direct route setup request that includes the following: an identifier of the function handler, an identifier of the selected processor, the source node session identifier, and the target node session identifier.

[0182] A4a. The method of embodiment A4, further comprising: receiving, by the end-point handler from the first network node, a further routable message comprising: a further message body that includes a further message of the AP, and a further header including the first field that comprises the identifier of the function associated with the AP; based on the direct route setup request, forwarding the further routable message directly to the processor without handling by the routing function, the function decoder, and the function handler.

[0183] A5. The method of any of embodiments Al-A4a, wherein the routable message is received from the first network node in the body of a transport layer protocol message, and the method further comprises extracting, by an end-point handler of the second network node, the routable message from the body of the transport layer protocol message.

[0184] A5a. The method of embodiment A5, further comprising: establishing, by the end-point handler, a transport layer connection between the first and second network nodes and an association between the transport layer connection and the first network node; and sending, by the end-point handler to the routing function, an indication that the end-point handler is part of a routing path for AP messages between the first and second network nodes.

[0185] A5b. The method of embodiment A5a, wherein the header of the routable message comprises a fifth field that includes an identifier of the first network node and a sixth field that includes an identifier of the second network node, and the association is established based on the fifth and sixth fields of the header.

[0186] A5c. The method of embodiment A5a, wherein establishing the association between the transport layer connection and the first network node comprises, after establishing the transport layer connection, receiving, by the end-point handler from the first network node, an association setup request that includes an identifier of the first network node and an identifier of the second network node, wherein the association is established based on the identifiers in the association setup request.

[0187] A6. The method of any of embodiments Al-A5c, wherein one of the following applies: the first and second network nodes are respective gNBs and the AP is XnAP; the first network node is a core network node or function, the second network node is a gNB, and the AP is NGAP; the first network node is a gNB centralized unit (gNB-CU), the second network node is a gNB distributed unit (gNB-DU), and the AP is Fl AP; or the first network node is a gNB-CU control plane (gNB-CU-C) function, the second network node is a gNB-CU user plane (gNB-CU-U) function, and the AP is E1AP.

[0188] A7. The method of any of embodiments A1-A6, wherein the header of the routable message also includes the following fields: a second field that comprises an identifier of the AP; a third field that comprises a source node session identifier; and a fourth field that comprises a target node session identifier, or is empty.

[0189] A7a. The method of embodiment A7, wherein the header of the routable message also includes a fifth field that comprises a source node identifier and a sixth field that comprises a target node identifier.

[0190] A7b. The method of embodiment A7a, wherein the combination of the source node session identifier and the target node session identifier is unique for the combination of the source node identifier, the target node identifier, and the function identifier.

[0191] A8. The method of any of embodiments Al-A7b, wherein the routing function, the function handler, the function decoder, and the processor are implemented as processes in a cloud computing environment.

[0192] Bl . A second network node configured to communicate with a first network node in a communication network, the second network node comprising: communication interface circuitry configured to communicate with the first network node; and processing circuitry operatively coupled to the communication interface circuitry, wherein the processing circuitry and the communication interface circuitry are configured to perform operations corresponding to the methods of any of embodiments A1-A8.

[0193] B2. A second network node configured to communicate with a first network node in a communication network, the second network node being further configured to perform operations corresponding to the methods of any of embodiments A1-A8.

[0194] B3. A non-transitory, computer-readable medium storing computer-executable instructions that, when executed by processing circuitry of a second network node configured to communicate with a first network node in a communication network, configure the second network node to perform operations corresponding to the methods of any of embodiments Al- A8.

[0195] B4. A computer program product comprising computer-executable instructions that, when executed by processing circuitry of a second network node configured to communicate with a first network node in a communication network, configure the second network node to perform operations corresponding to the methods of any of embodiments A1-A8.

Claims

CLAIMS1. A method performed by a second network node or function, NNF, to communicate with a first NNF in a communication network, the method comprising: receiving (1420), from the first NNF, a routable message comprising: a message body that includes a message of an application protocol (AP) used for communication between the first and second NNFs, and a header including a first field that comprises an identifier of a function associated with the AP; by a routing function of the second NNF, selecting (1430) a function decoder of the second NNF based on the first field and forwarding the routable message to a function handler of the second NNF via the selected function decoder; and by the function handler, selecting (1450) a message processor of the second NNF for processing the AP message and forwarding the routable message to the selected message processor.

2. The method of claim 1, wherein the header also includes a second field that comprises an identifier of the AP.

3. The method of claim 2, wherein: the second field includes one of a plurality of different second predefined values that identify respectively a plurality of different APs used for communication between the first and second NNFs; and the first field includes one of a plurality of different first predefined values that identify respectively a plurality of different functions associated with the AP identified by the second field.

4. The method of claim 3, wherein the plurality of different APs include at least two of the following: F1AP, E1AP, NGAP, and XnAP.

5. The method of any of claims 1-4, wherein the header also includes third and fourth fields, and the method further comprises: assigning (1435), by the function handler, a target session identifier to be associated with a source session identifier included in the third field; andadding (1440), by the function handler, the target session identifier to the fourth field before forwarding (1450) the routable message to the selected message processor.

6. The method of claim 5, wherein the fourth field of the header is empty prior to receipt of the routable message by the function handler.

7. The method of any of claims 5-6, further comprising receiving (1455), by the function handler from the message processor, a second routable message that indicates an outcome of processing the AP message, wherein a header of the second routable message includes the first, second, third, and fourth fields of the header of the routable message forwarded to the message processor.

8. The method of claim 7, further comprising forwarding (1460), by the function handler, the second routable message to the routing function via the function decoder.

9. The method of any of claims 5-8, further comprising sending (1470), by the function handler to an end-point handler of the second NNF, a direct route setup request that includes the following: an identifier of the function handler, an identifier of the selected message processor, the source session identifier, and the target session identifier.

10. The method of claim 9, further comprising: receiving (1480), by the end-point handler from the first NNF, a further routable message comprising: a further message body that includes a further message of the AP, and a further header including the first field that comprises the identifier of the function associated with the AP; based on the direct route setup request, forwarding (1490) the further routable message directly to the message processor without handling by the routing function, the function decoder, and the function handler.

11. The method of any of claims 1-10, wherein the routable message is received from the first NNF in a transport layer protocol message body, and the method further comprises extracting (1425), by an end-point handler of the second NNF, the routable message from the transport layer protocol message body.

12. The method of claim 11, further comprising: establishing (1405), by the end-point handler, a transport layer connection between the first and second NNFs and an association between the transport layer connection and the first NNF; and sending (1410), by the end-point handler to the routing function, an indication that the end-point handler is part of a routing path for AP messages between the first and second NNFs.

13. The method of claim 12, wherein: the header of the routable message also includes the following: a fifth field that comprises an identifier of the first NNF, and a sixth field that comprises an identifier of the second NNF; and the association is established based on the fifth and sixth fields of the header.

14. The method of claim 12, wherein establishing (1405) the association between the transport layer connection and the first NNF comprises, after establishing the transport layer connection, receiving (1406), by the end-point handler from the first NNF, an association setup request that includes an identifier of the first NNF and an identifier of the second NNF, wherein the association is established based on the identifiers in the association setup request.

15. The method of any of claims 1-14, wherein one of the following applies: the first and second NNFs are respective gNBs of a radio access network, RAN, and the AP is XnAP; the first NNF is a core network function, NF, the second NNF is a gNB of the RAN, and the AP is NGAP; the first NNF is a gNB centralized unit, gNB-CU, the second NNF is a gNB distributed unit, gNB-DU, and the AP is F1AP; or the first NNF is a gNB-CU control plane, gNB-CU-C, function, the second NNF is a gNB-CU user plane, gNB-CU-U, function, and the AP is E1AP.

16. The method of any of claims 1-15, wherein the header of the routable message also includes the following fields: a second field that comprises an identifier of the AP; a third field that comprises a source session identifier; and a fourth field that comprises a target session identifier, or is empty.

17. The method of claim 16, wherein the header of the routable message also includes a fifth field that comprises a source node identifier and a sixth field that comprises a target node identifier.

18. The method of claim 17, wherein the combination of the source session identifier and the target session identifier is unique for the combination of the source node identifier, the target node identifier, and the function identifier.

19. The method of any of claims 1-18, wherein the routing function, the function handler, the function decoder, and the message processor are implemented as processes in a cloud computing environment.

20. Network equipment (1600, 1702) arranged to implement a second network node or function, NNF (900, 1010, 1508, 1510) configured to communicate with a first NNF (1020, 1508, 1510) in a communication network (198, 199, 1502), the network equipment comprising: communication interface circuitry (1606, 1704) and processing circuitry (1602, 1704) that operatively coupled and configured to implement a routing function (920), one or more function decoders (930), a function handler (940), and one or more message processors (950), wherein the processing circuitry and the communication interface circuitry are further configured to: receive, from the first NNF, a routable message comprising: a message body that includes a message of an application protocol, AP, used for communication between the first and second NNFs, and a header including a first field that comprises an identifier of a function associated with the AP; by the routing function, select one of the function decoders based on the first field and forward the routable message to the function handler via the selected function decoder; and by the function handler, select one of the message processors for processing the AP message and forward the routable message to the selected message processor.

21. The network equipment of claim 20, wherein the processing circuitry and the communication interface circuitry are further configured to perform operations corresponding to the methods of any of claims 2-19.

22. Network equipment (1600, 1702) arranged to implement a second network node or function, NNF (900, 1010, 1508, 1510) configured to communicate with a first NNF (1020, 1508, 1510) in a communication network (198, 199, 1502), wherein the network equipment is further arranged to implement a routing function (920), one or more function decoders (930), a function handler (940), and one or more message processors (950), wherein the network equipment is further arranged to: receive, from the first NNF, a routable message comprising: a message body that includes a message of an application protocol, AP, used for communication between the first and second NNFs, and a header including a first field that comprises an identifier of a function associated with the AP; by the routing function, select one of the function decoders based on the first field and forward the routable message to the function handler via the selected function decoder; and by the function handler, select one of the message processors for processing the AP message and forward the routable message to the selected message processor.

23. The network equipment of claim 22, being further arranged to perform operations corresponding to the methods of any of claims 2-19.

24. Non-transitory, computer-readable medium () storing computer-executable instructions that, when executed by processing circuitry (1602, 1704) of network equipment (1600, 1702) arranged to implement a second network node or function, NNF (900, 1010, 1508, 1510) configured to communicate with a first NNF (1020, 1508, 1510) in a communication network (198, 199, 1502), configure the network equipment to perform operations corresponding to the methods of any of claims 1-19.

25. Computer program product comprising computer-executable instructions that, when executed by processing circuitry (1602, 1704) of network equipment (1600, 1702) arranged to implement a second network node or function, NNF (900, 1010, 1508, 1510) configured to communicate with a first NNF (1020, 1508, 1510) in a communication network (198, 199,1502), configure the network equipment to perform operations corresponding to the methods of any of claims 1-19.

Images