Methods and apparatuses for transmitting a message within a transport packet between a transmitting radio access network entity and a receiving radio access network entity

Abstract

Embodiments described herein relate to methods and apparatuses for transmitting messages between a transmitting radio access network, RAN, entity and a receiving RAN entity. A method performed by a transmitting RAN entity comprises transmitting a message to the receiving RAN entity, wherein the message comprises: an extended carrier identifier, eAxC-ID, and a format indication indicating a format of the eAxC-ID.

Description

[0001] METHODS AND APPARATUSES FOR TRANSMITTING A MESSAGE WITHIN A TRANSPORT PACKET BETWEEN A TRANSMITTING RADIO ACCESS NETWORK ENTITY AND A RECEIVING RADIO ACCESS NETWORK ENTITY

[0002] TECHNICAL FIELD

[0003] Embodiments described herein relate to methods and apparatuses for transmitting a message within a transport packet between a transmitting radio access network, RAN entity and a receiving RAN entity.

[0004] BACKGROUND

[0005] Mobile networks are starting to move towards Open RAN, ORAN alliance specifications. Both RAN and Fronthaul transport requirements are evolving towards Network Reliability, Availability and Redundancy (NRAR) driving for closer interaction between RAN and Transport systems.

[0006] Radio access Network (RAN) communication between a RAN Processing unit and Radio unit, called Fronthaul, is evolving to packet communication. The Processing unit may be a complete Baseband (BB) or a Distributed Unit (DU) I virtual Distributed Unit (vDU). The evolved RAN packet protocol (eCPRI) is defined in CPRI-Forum (see for example eCPRI_v_2.0_2019_05_10c) and Open RAN (O-RAN) Alliance (see for example, O- RAN.WG4.CUS.0-R003-v12.00 June 2023).

[0007] RAN Products, such as O-DU and O-RU, implementations today are large multiprocessor I multi-processing systems, being both hardware (HW) and software (SW) defined processing systems and in some examples having internal switching systems to handle internal traffic forwarding. RAN and Transport addressing is one area with challenges, e.g. how to address and handle forwarding between the multi- processor / multi-processing systems, both internally within RAN equipment and in the Fronthaul transport networks. A specific detail in the area of packet / eCPRI message addressing and internal RAN equipment forwarding is the fact that packets might be encrypted such that RAN application headers, thus eCPRI message headers, can’t be read even if an optional switching function in a receiving RAN entity has Deep Packet Inspection (DPI) capability. Furthermore, even if packet / eCPRI message is not encrypted there is a challenge in reading / parsing the message as eCPRI messages can have different format such that header fields are defined differently.

[0008] Figure 1 illustrates a transport packet 100. It can be seen that the transport packet 100 comprises a plurality of payload units 101 (eCPRI messages). Each eCPRI message 101 comprises a common header 102, and an eCPRI payload 103. Each eCPRI payload 103 comprises an eCRPI address header 104 and eCPRI payload data 105. Two eCPRI messages (101a and 101b) are illustrated in this example but it will be appreciated that any number of eCPRI messages may be comprised within a single transport packet 100.

[0009] In some cases, the common header 102 and the address header 104 may together be referred to as the eCPRI transport header.

[0010] It will be appreciated that in order to read the information contained within the payload units 101 deep packet inspection (DPI) may need to be performed. In contrast, the Network Layer header 106 (e.g. the layer 2 or layer 3 header of the entire transport packet), may be read without performing DPI.

[0011] Figure 2 illustrates the information contained within the eCPRI common header 102 and the eCPRI address header 104.

[0012] An eCPRI common header may comprise information relating to “IQ data / real-time control / delay measurement and an indication of the payload size.

[0013] The address header 104 may comprise an indication of the eCPRIrtcid or ecpriPcid which is extended antenna carrier (eAxC) identifier (eAxC ID) and identifies the specific data flow associated with each control Plane or User plane.

[0014] One eAxC identifier (eAxC ID) comprises a band and sector identifier (BandSectorJD), a component-carrier identifier (CCJD) a spatial stream identifier (RU_Port_ID) and a Distributed Unit identifier (DU_Port_ID).

[0015] The eCPRI common header also comprises the eCPRI concatenation bit. The eCPRI concatenation bit will be set to 1 if there is another message to follow the present message within the same transport packet. The eCPRI concatenation bit will be set to 0 if there is no further eCPRI message within the same transport packet.

[0016] In the example of Figure 1 therefore, the eCPRI concatenation bit will be set to 1 in the common header 102a, but will be set to 0 in the common header 102b.

[0017] Figure 3 illustrates an example of the ecpriRtcid I ecpriPcid field (eAxC-ID field) in the address header 104. This is further divided into 4 different subfields associated to the following parameters:

[0018] Open Distributed Unit port identifier, DU_Port_ld;

[0019] Band Sector Identifier, BandSectorJD, Component Carrier Identifier, CC_ID; and Open Radio unit port identifier, RU_Port_ID.

[0020] SUMMARY

[0021] The ORAN eCPRI eAxC-ID header subfields have been given flexibility in size, such that the order of the fields is always the same, but the size of each field may be different for different applications. This introduces a large challenge for any parsing function that need to understand exactly how to parse each subfield.

[0022] Figure 4 illustrates some of the variations in field lengths that have been defined in the ORAN interoperability and Test specification.

[0023] The total size of the eAxC-ID field is 2 Bytes, it has been identified that this total size may limit the possible results in some solutions / deployments.

[0024] In order to address this issue, embodiments described herein provide a format indication within a transport packet, e.g. within the message or a network layer header of the transport packet. For example, an eAxC-ID format indication may be comprised within the eCPRI message transport header. In some examples, eCPRI message addressing (e.g. the eAxC-ID) including eAxC-ID format info may be comprised in a Network Layer header such that only the Network Layer would be needed to forward the packet / eCPRI message all the way to the destination processing unit, including the information on the eAxC-ID format used. This enables internal RAN equipment forwarding (e.g. utilising a switching function) using only Network Layer addressing.

[0025] According to some embodiments there is therefore provided a method performed by a transmitting radio access network, RAN, entity for transmitting, a message within a transport packet to a receiving RAN entity. The method comprises transmitting the message to the receiving RAN entity. The message comprises: an extended carrier identifier, eAxC-ID, and a format indication indicating a format of the eAxC-ID.

[0026] According to some embodiments there is provided a method performed by a receiving radio access network, RAN, entity for receiving, a message within a transport packet from a transmitting RAN entity. The method comprises receiving, from the transmitting RAN entity, the message. The message comprises: an extended carrier identifier, eAxC, and a format indication of a format of the eAxC-ID.

[0027] According to some embodiments there is provided a transmitting radio access network, RAN, entity for transmitting, a message within a transport packet to a receiving RAN entity, the transmitting RAN entity comprising processing and a memory. The memory containing instructions executable by the processing circuitry whereby the transmitting RAN entity is operable to: transmit the message to the receiving RAN entity, wherein the message comprises: an extended carrier identifier, eAxC-ID, and a format indication indicating a format of the eAxC-ID.

[0028] According to some embodiments there is provided a receiving radio access network, RAN, entity for receiving, a message within a transport packet from a transmitting RAN entity. The receiving RAN entity comprises processing and a memory, the memory containing instructions executable by the processing circuitry whereby the receiving RAN entity is operable to: receive the message from the transmitting RAN entity, wherein the message comprises: an extended carrier identifier, eAxC-ID, and a format indication indicating a format of the eAxC-ID.

[0029] According to some embodiments there is provided a computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out any of the methods described above. According to some embodiments there is provided a carrier containing the computer program described above, wherein the carrier comprises one of an electronic signal, optical signal, radio signal or computer readable storage medium.

[0030] According to some embodiments there is provided a computer-readable medium comprising instructions that, when executed on at least one processor, cause the at least one processor to perform any of the methods described above.

[0031] According to some embodiments there is provided a computer program product comprising non transitory computer readable media having stored thereon a computer program as described above.

[0032] BRIEF DESCRIPTION OF THE DRAWINGS

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

[0034] Figure 1 illustrates a transport packet;

[0035] Figure 2 illustrates the information contained within the eCPRI common header 102 and the eCPRI address header;

[0036] Figure 3 illustrates an example of the ecpriRtcid I ecpriPcid field (eAxC-ID field) in the address header;

[0037] Figure 4 illustrates some of the variations in field lengths that have been defined in the ORAN interoperability and Test specification;

[0038] Figure 5 illustrates a system comprising a transmitting RAN entity 501 and a receiving RAN entity 502;

[0039] Figure 6 illustrates a method, performed by a transmitting RAN entity for transmitting, a message within a transport packet to a receiving RAN entity; Figure 7 illustrates a method performed by a receiving RAN entity 502, for receiving a message within a transport packet from a transmitting RAN entity;

[0040] Figure 8 illustrates an example of an eCPRI message header (e.g. common header 102 and address header 104) according to some embodiments;

[0041] Figure 9 illustrates an example ecpriMessage field comprising a format indication according to some embodiments;

[0042] Figure 10 illustrates an example of part of a common eCPRI header 102 and a eCPRI message type field value according to some embodiments.

[0043] Figure 11 illustrates an example of an eCPRI message header (e.g. common header 102 and address header 104) according to some embodiments;

[0044] Figure 12 illustrates an example of an ecpriMessage field according to the embodiment of Figure 11 ;

[0045] Figure 13 illustrates an example of the eAxCidFormat field according to the embodiment of Figure 11 ;

[0046] Figure 14 illustrates an example implementation of the embodiments in Figures 11 to 13.;

[0047] Figure 15 illustrates an example of an eCPRI message header (e.g. common header 102 and address header 104) according to some embodiments;

[0048] Figure 16 illustrates an example of an ecpriMessage field according to the embodiment of Figure 15;

[0049] Figure 17 illustrates an example implementation of the embodiment of Figure 15 and 16;

[0050] Figure 18 illustrates an example of an eCPRI message header (e.g. common header 102 and address header 104) according to some embodiments; Figure 19 illustrates an example ecpriExteaxcid field according to the embodiment of Figure 18;

[0051] Figure 20 illustrates an example implementation of the embodiment of Figures 19 and 20;

[0052] Figure 21 illustrates an example of a transport packet in which a format indication is included in the Network layer header of the transport packet;

[0053] Figure 22 illustrates an example of a format indication being comprised within a Flow Label in a IPv6 Network layer header;

[0054] Figure 23 shows a network node 2300 in accordance with some embodiments;

[0055] Figure 24 is a block diagram illustrating a transmitting RAN entity according to some embodiments; and

[0056] Figure 25 is a block diagram illustrating a receiving RAN entity according to some embodiments.

[0057] DETAILED DESCRIPTION

[0058] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description The following sets forth specific details, such as particular embodiments or examples for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other examples may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and / or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and / or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Nodes that communicate using the air interface may have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer- readable memory, such as (ROM, EEPROM, Flash memory, a memory disc, RAM etc.) solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

[0059] Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analogue) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and / or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.

[0060] Certain aspects of the present disclosure and their embodiments may provide solutions to these or other challenges.

[0061] Particular embodiments are 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 by way of example to convey the scope of the subject matter to those skilled in the art.

[0062] Figure 5 illustrates a system comprising a transmitting RAN entity 501 and a receiving RAN entity 502. The transmitting RAN entity and the receiving RAN entity may each comprise for example any one of: a radio unit (Rll), a baseband unit (BBU), a distributed unit (DU) or a virtual distributed unit (vDU).

[0063] The receiving RAN entity may comprise a network function 503 which is capable of reading the network layer header of the transport packet.

[0064] The receiving RAN entity then further comprises a plurality of processing units 504a to 504d. The processing units may be hardware, software or a combination of the two. For example, in a cloud system the processing unit may be a virtualised SW function. In this example four processing units are illustrated, but it will be appreciated that there may be any number of processing units. The processing units may comprise processing elements as described in the ORAN standard documents (e.g. O-RAN.WG4.CUS.0- R003-V14.00 and 0-RAN.WG4.MP.0-R003-v14.00)

[0065] In some examples, the network function 503 may comprise a switching function capable of directing traffic received from the RAN entity 501 to the different processing units 504a to 504bb. In some embodiments, the network function 503 (e.g. switching function) may be capable of performing DPI (e.g. reading / parsing the common header and / or address header of the eCPRI message)).

[0066] In other examples, the network function comprises external ports at the receiving RAN entity, where each external port is directly connected to a respective processing unit.

[0067] The AxC-ID Indicates which of the processing units (e.g. 504a to5 504d) is the destination processing unit for a particular eCPRI message. For example, the eAxC-ID may comprise information for determining the destination RAN function, it may also indicate which of the processing units (e.g. 504a to5 504d) is the destination processing unit for a particular eCPRI message. The ORAN parameter Processing Element (PE) may alternatively indicate which of the processing units (e.g. 504a to 504d) is the destination processing unit for a particular eCPRI message.

[0068] However, different transport packets and / or eCPRI messages may have different eAxC- ID formats. For example, there may be transport packets and / or eCPRI messages with different eAxC-ID formats sent to a single receiving RAN entity, or indeed to a single processing unit within a RAN entity. As previously mentioned, the transport packets and / or eCPRI messages may be encrypted such that eCPRI message can’t be read (even utilising DPI) by the receiving RAN entity, e.g. by then optional switching function.

[0069] Additionally, the receiving RAN entity (e.g. the switching function) may not have DPI capability, and thus may not be able to read the eCPRI message even if it’s not encrypted.

[0070] Figure 6 illustrates a method, performed by a transmitting RAN entity for transmitting, a message within a transport packet to a receiving RAN entity.

[0071] For example, the method of Figure 6 may be performed by the transmitting RAN entity

[0072] 501 illustrated in Figure 5. The receiving RAN entity may be the receiving RAN entity

[0073] 502 illustrated in Figure 5.

[0074] The transmitting RAN entity may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud or fog deployment. It will be appreciated that the transmitting RAN entity may be deployed in an O-RAN scenario.

[0075] It will be appreciated that the transport packet referred to in embodiments described herein may be structured similarly to as illustrated in Figure 1 , although different information may be comprised within the various parts of the structure, as will be described in more detail below. The reference numerals from Figure 1 will therefore be used herein to indicate the different portions of the transport packet 100. For example, the transport packet 100 may comprise a plurality of payload units 101 each comprising a common header 102 and a payload 103, where the payload comprises an address header 104 and payload data 105. The transport packet may also comprise a network layer header 106.

[0076] In step 601 the method comprises transmitting the message to a receiving RAN entity, wherein the transport packet comprises: an extended carrier identifier, eAxC-ID, and a format indication of a format of the eAxC-ID. As illustrated in Figure 4, the eAxC-l D may have various formats. The format of the eAxC- ID may defined by the number of bits assigned to each of the following parameters within the eAxC identifier: DU_Port_ID, BandSectorJD, CCJD, and RU_Port_ID.

[0077] It will be appreciated that the format indication may comprise a value, flag or some other indication of which format is being used. For example, a format indication having the value 0001 may indicate the format 4:4:4:4, where each number in the format indicates the number of bits assigned to the parameters DU_Port_ID, BandSectorJD, CCJD, RU_Port_ID respectively.

[0078] The transmitting RAN entity (and equivalently the receiving RAN entity) may be configured with a mapping of the values for the format indication to the various formats.

[0079] For example, the transmitting and / or receiving RAN entities may be configured during installation or set-up with one or more possible formats that can be utilized, and or with the mapping of the formats to the respective format indications. Alternatively, the mapping may be communicated to the transmitting and / or receiving RAN entities after installation or set-up, for example, one or other of the transmitting and receiving RAN entities may determine the mapping (e.g. based on configuration of the formats themselves), and may communicate (e.g. via the M-plane) the mapping to the other of the transmitting and receiving RAN entities.

[0080] In other words, the management plane (M-Plane) may be used to configure how to interpret the format indication. For example, the M-plane may determine eCPRI message / eAxC-ID format capabilities in the transmitting and receiving RAN entities, then based on these capabilities may configure the mapping between format indications and formats. For example, the M-Plane may configure the use of values 1 to 15 as format indications.

[0081] For example, a format indication of value 1 may represent a 4:4:4:4 format, and format indication of value 2 may represent a 3:3:5:5 format.

[0082] For example, the transmitting and / or receiving RAN entities may be capable of supporting one or more of the embodiments described below with respect to where and how the format indication and / or inclusion indication may be included with the transport packet.

[0083] In some examples, the format indications relate to ORAN defined and publicly known formats (the loT profiles in ORAN spec) such that M-plane relates the format bits value with the specific format, thus the size of DU_Port_ID, BandSectorJD, CC_ID, RU_Port_ID

[0084] In some examples, the format indications relate to operator / vendor defined formats (e.g. communicated via M-plane) such that M-plane relates the format bits value with the specific format, thus the size of DU_Port_ID, BandSectorJD, CCJD, RU_Port_ID.

[0085] In some examples, the transport packet may further comprise an inclusion indication. The inclusion indication may indicate whether or not the format indication is included within the message.

[0086] In some examples, for instance where all messages within the transport packet are to be process by the same processing unit in the receiving RAN entity, the eAxC-ID may be comprised within a network layer header 106 of the transport packet 100. In these examples, the format indication of step 601 may also be comprised within the network layer header 106.

[0087] In other examples, the eAxC identifier may be comprised within the eCPRI message. In these examples, the format indication may be comprised within the eCPRI message or within the network layer header 106. In these examples, the different messages within the transport packet may be addressed to different processing units at the receiving RAN entity.

[0088] Figure 7 illustrates a method performed by a receiving RAN entity 502, for receiving a message within a transport packet from a transmitting RAN entity.

[0089] The receiving RAN entity may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud or fog deployment. It will be appreciated that the receiving RAN entity may be deployed in an O-RAN scenario. In step 701 the method comprises receiving, from the transmitting RAN entity, the message, wherein the transport packet comprises: an extended carrier identifier, eAxC- ID, and a format indication of a format of the eAxC-ID.

[0090] Step 701 corresponds to step 601 of Figure 6.

[0091] In some examples, the receiving RAN entity may not comprise a switching function and / or DPI function. In these examples, all of the reading and parsing of the addressing information (e.g. eAxC-ID or RAN addressing) is performed at the processing units. In other examples, the network function may comprise a switching function having DPI capabilities, and the reading and parsing of the RAN addressing information may be performed at the switching function. Alternatively, the network function may comprise external ports of the receiving RAN entity and the DPI capabilities may be performed at the external ports.

[0092] The following examples may assume that the receiving RAN entity does comprise a network function. In particular, these examples avoid use of any DPI capabilities at the network function, and address the issue of if encryption has been utilised and the network function is therefore unable to read the RAN addressing information (eAxC-ID and / or format indication) regardless of whether it has DPI capabilities. Both the format indication and the eAxC-ID are comprised within the network layer header 106.

[0093] This example may be useful where all of the eCPRI messages within the transport packet are intended for the same processing unit.

[0094] In this example, the method of Figure 7 may further comprise receiving the message at a network function of the receiving RAN entity.

[0095] The method may then further comprise, reading the eAxC-ID from the network layer header based on the format indication comprised in the network layer header, and forwarding the message to a processing unit associated with the eAxC-ID. Alternatively the network address identifies the destination processing unit. Each of the one or more processing units may then assume that the eAxC-l Ds within the eCPRI messages will have the format indicated by the network function.

[0096] In this example, the eAxC-IDs within the eCPRI messages in the transport packet may be required to have the same format.

[0097] The format indication is comprised in the network layer header 106, however, the eAxC-ID are comprised within the eCPRI messages.

[0098] In this example, the method of Figure 7 may further comprise determining, at the network function, the format of the eAxC-ID from the format indication, and indicating the format (e.g. in metadata) to the one or more processing units. Each of the one or more processing units may then assume that the eAxC-IDs within the eCPRI messages will have the format indicated by the switching function.

[0099] In this example, the eAxC-IDs within the eCPRI messages in the transport packet may be required to have the same format. Both the format indication and the eAxC-ID are comprised within the eCPRI messages.

[0100] In this example, the reading and parsing of the format indication and the eAxC-ID is performed by the processing units.

[0101] The embodiments described herein may be separated into two main principles:

[0102] I) including the format indication in within an eCPRI message

[0103] I I) including the format indication in a Network Layer header of the transport packet

[0104] Figures 8 to 20 illustrate examples of principle (I) and Figures 21 and 22 illustrate examples of principle (II)

[0105] Figure 8 illustrates an example of an eCPRI message header (e.g. common header 102 and address header 104) according to some embodiments. In this example, the format indication, ecpriFormat, is comprised within the common header 102 of the message. In particular the format indication, ecpriFormat is comprised within a message type field, ecpriMessage, within the common header 102.

[0106] Figure 9 illustrates an example ecpriMessage field comprising a format indication according to some embodiments.

[0107] Currently the ecpriMessage field in the eCPRI message header has the format illustrated in Figure 9. In other words, the epcriMessage field comprises a 1 Byte field (256 possible values). However, currently only 3 of these values are used in ORAN, representing three different message types. The values that are currently used are as follows:

[0108] IQ data, value 0

[0109] Real time control data, value 2

[0110] Delay measurement message, value 5

[0111] The concept of message types has been defined in CPRI Forum eCPRI specification and defines 12 specific message type (value 0-11). The message type values 12-63 have been defined as reserved, message type values 64-255 have been defined as vendor specific.

[0112] It can be seen from Figure 9, that the four most significant bits (msb) of this ecpriMessage field are currently unused. These bits would only be used if the reserved or “vendor specific” message type values are defined.

[0113] In this example, the four msb (marked “n”) of the ecpriMessage field therefore comprise the format indication.

[0114] The 4-bit msb value 0 (e.g. all zeros 0:0:0:0) may not be used for a format indication as it’s already part of the defined message type 0 (IQ data). The CPRI Forum specification already defined specific message types with values 0-11 , and as described above these are all represented with the four least significant bits (Isb), shown in Figure 10 as Message type in the 4 Isb.

[0115] For the example illustrated in Figure 9 therefore, ecpriMessage field is designed to be read in two parts thereby providing two sets of information:

[0116] 1 . Specific message type (Isb 4-bit) 2. eAxC-ID format indication (msb 4-bit)

[0117] Returning to Figure 8, the common header 102 further comprises an inclusion indication, ecpriFid. In this example, the inclusion indication comprises a 1 bit identifier, in one of the reserved bit positions in the eCPRI message header. The ecpriFid may indicate whether there is an ecpriFormat (e.g. format indication) field included in the ecpriMessage field.

[0118] For example, if ecpriFid=1 then it may be determined that the ecpriFormat identifier is part of the ecpriMessage field. If ecpriFid=O then it may be determined that there is no ecpriFormat identifier part of the ecpriMessage field

[0119] Figure 10 illustrates an example of part of a common eCPRI header 102 and a eCPRI message type field value according to some embodiments.

[0120] In this example, as ecpriFid = 1 it is determined that the 4 msb of the ecpriMessage field will comprise the format indication, ecpriFormat.

[0121] For the ecpriMessage field: a) The 4 Isb have value 2 = Message type: Real time control data b) The 4 msb have value 1 = ecpriFormat 1

[0122] M-plane have earlier configured various ecpriFormat values to represent Operator defined eAxC-ID formats, and ecpriFormat 1 in this example represents the format: 4:4:4:4 (4 bit DU_Port_ID, 4 bit BandSectorJD, 4bit CCJD, 4 bit RU_Port_ID)

[0123] Figure 11 illustrates an example of an eCPRI message header (e.g. common header 102 and address header 104) according to some embodiments.

[0124] In this example the format indication is comprised within a eAxC format message field, exCidFormat, in the address header or common header of the ecpri message. In this example, an inclusion indication may is comprised within the message type field, ecpriMessage field, of the common header. Figure 12 illustrates an example of an ecpriMessage field according to the embodiment of Figure 11.

[0125] As described above, in this example, the ecpriMessage field comprises the inclusion indication. In this example, the inclusion indication may comprise at least one of the four msb bits of the ecpriMessage field. For example, any one of the 4mbs may be set to 1 to indicate the presence of the eAxCidFormat field.

[0126] For the example illustrated in Figure 12 therefore, ecpriMessage field is designed to be read in two parts thereby providing two sets of information:

[0127] 1 . Specific message type (Isb 4-bit)

[0128] 2. Inclusion indication (one of the msb 4-bits, e.g. Bit 0)

[0129] It will be appreciated that in some examples, the one bit inclusion indication in the reserved bits of the common header of the ecpri message may be used instead.

[0130] Figure 13 illustrates an example of the eAxCidFormat field according to the embodiment of Figure 11.

[0131] In this example, the eAxCidFormat field may comprise 8 bits and may be added before the eAxCJD field in the eCPRI header. Similarly to as described above eAxCidFormat filed comprises the format indication which identifies the format of eAxC_ID filed so it can be read.

[0132] Figure 14 illustrates an example implementation of the embodiments in Figures 11 to 13.

[0133] In this example, the common header 102 comprises the format indication in bit 0 of the ecpriMessage field. In this example this bit is set to 1 indicating that the eAxCidFormat field is present in the header. The four Isb will be read separately to determine the message type which in this example is Real time control data.

[0134] The eAxCidFormat field that has the value 00000001 which indicates ecpriFormat 1 that represented the format 4:4:4:4 (4 bit DU port id, 4 bit BandSector id, 4bit CC id, 4 bit RU port id)). Figure 15 illustrates an example of an eCPRI message header (e.g. common header 102 and address header 104) according to some embodiments.

[0135] In this example both the inclusion indication and the format indication are comprise within the eCPRI message header. In particular, in this example both the format indication and the inclusion indication are comprised within the ecpriMessage field, as will be described in more detail with reference to Figure 16.

[0136] This would allow a processing unit to first identify the eAxC-ID format used and then parse the packet headers for further RAN processing.

[0137] Figure 16 illustrates an example of an ecpriMessage field according to the embodiment of Figure 15.

[0138] In this example, the 4msb of the ecprMessage field comprise the eAxCidFormat. In this example the eAxCidFormat is separated into a one bit inclusion indication and a 3 bit format indication. It will be appreciated that the 4 msb may be divided between the inclusion indication and the format indication in any suitable way.

[0139] When the inclusion indication is set to 1 (e.g. msb, Bit 0 = 1) this may indication that the following three bits (Bit 1-3) comprise the format indication.

[0140] In the example of Figure 16 therefore, the ecpriMessage field is defined such that the the first msb, Bit 0, the next three bits, Bit 1-3, and Isb 4-bit values are read separately but concurrently, and thereby giving three sets of information.

[0141] 1 . Inclusion indication (first msb, Bit 0)

[0142] 2. Format indication (bits 1 to 3)

[0143] 3. Specific message type (Isb 4-bit)

[0144] It will be appreciated that the M-Plane may configures format indication values 1 to 8 as mapping to specific formats.

[0145] Figure 17 illustrates an example implementation of the embodiment of Figure 15 and 16. In this example, the inclusion indication is msb, Bit 0 of the ecpri Message field. As bit 0 = 1 this indicates that the following three following bits (Bit 1-3) comprise the format indication. The four Isb of the ecpriMessage field still represent the CPRI Forum defined message type values 0 to 11

[0146] The bits 1 to 3 have the value 1 which represents a specific format. The ecpriMessage four Isb have value 2 = message type: Real time control data.

[0147] In this example, the format indication value of 1 may represent format: 4:4:4:4 (4 bit DU_Port_ID, 4 bit BandSectorJD, 4 bit CCJD, 4 bit RU_Port_ID).

[0148] Figure 18 illustrates an example of an eCPRI message header (e.g. common header 102 and address header 104) according to some embodiments.

[0149] In this example, the common header 102 comprises the inclusion indication and the transport header 104 comprises the format indication. This would allow a processing unit to first identify the eAxC-ID format used and then as a second step parse the packet headers for further RAN processing.

[0150] In this example, the inclusion indication comprises a new eCPRI message type added to range of ecpriMessage values. This message type is referred to as ecpri Exteaxcid.

[0151] The previous eAxC-ID field may then be replaced by the ecpri Exteaxcid which may comprise both the format indication and the eAxC-ID data itself.

[0152] The Message type value for ecpri Exteaxcid in the ecpriMessage field may be any one of the Reserved range 12-63 or Vendor specific range 64-255.

[0153] Figure 19 illustrates an example ecpri Exteaxcid field according to the embodiment of Figure 18.

[0154] The ecpri Exteaxcid (eCPRI Extended eAxC-ID) field may itself comprise two fields: for example a format indication field (e.g. an 8 Bit (1 Byte) eaxcidFormat field) and a, for example, variably sized eaxcidData field (comprising eAxC-ID data). The format indication field indicates the format of the eaxcidData field, and thus the size of each part DU_Port_ID, BandSector D, CCJD, RU_Port_ID of the eAxC-ID data. In this example the ecpriExteaxcid field is variably sized in order to allow for larger and flexible sized eAxC-ID values, (e.g. within the eaxcidData field), compared to the currently defined Message type ecpriRtcid / ecpriPcid (eAxC-ID value).

[0155] In some examples, the eaxcidData field total size may be an integer number of Bytes, e.g. N x Sbits. In some examples, the format indication having a value=0, may be considered a default value representing the format 8:8:8:8 (8-bit DU_Port_ID, 8-bit BandSectorJD, 8-bit CCJD, 8-bit RU_Port_ID).

[0156] In this example, the M-Plane may configure values 0 to 255 using the eaxcidFormat (Bit 0-7) to represent specific eAxC-ID formats.

[0157] Figure 20 illustrates an example implementation of the embodiment of Figures 19 and 20.

[0158] In this example, the eaxcidFormat field has a value = 8 which represented a specific eAxC-ID format, say the format 4:4:8:8 (4 bit DU_Port_ID, 4 bit BandSectorJD, 8 bit CCJD, 8 bit RU_Port_ID).

[0159] The eaxcidData field may therefore be read according to this format, and therefore it has the values:

[0160] • DU_Port_ID = 1

[0161] • BandSectorJD = 4

[0162] • CCJD = 80

[0163] • RU_Port_ID = 10

[0164] As described above, Figures 21 and 22 illustrate example implementations of the second principle (II).

[0165] It will be appreciated that there may be many possible ways to implement a format indication using a Network layer headers.

[0166] With Ethernet networking the parameters that could be used to encompass a format indication may be:

[0167] • MAC-address • VLAN-ID

[0168] • Ethernet stream-ID (for example as described in to PCT / SE2023 / 051114)

[0169] For IP networking the typical parameters to use to encompass a format indication may be

[0170] • IP, IPv6-address

[0171] • II DP-port

[0172] • IPv6 Flow label

[0173] Figure 21 illustrates an example of a transport packet in which a format indication is included in the Network layer header of the transport packet. Including the format indication in the network layer header enables an internal RAN equipment network function to determine the format (e.g. without needing to decrypt anything in the payload or utilize DPI).

[0174] The network function may then inform a RAN processing unit of the format of the eAxC- ID contained within the payload of the transport packet (e.g. in metadata). The processing unit can then parse the headers in the payload for further RAN processing according to the format.

[0175] In this example, the transport packet comprises an Ethernet frame header, which utilised a VLAN as a format indication. In this example, VLAN-ID value would be used as the format indication. The internal RAN equipment network function may determine the format indication from the VLAN-ID to create internal metadata identifier for eAxC-ID format, and may then send this internal metadata with the eCPRI message(s) in the payload to a processing unit for parsing. The processing unit may then parse the eCPRI message appropriately using the format indicated in the metadata.

[0176] Each of the one or more processing units may then assume that the eAxC-l Ds within the eCPRI messages will have the format indicated by the network function.

[0177] In this example, the eAxC-IDs within the eCPRI messages in the transport packet may be required to have the same format.

[0178] Figure 22 illustrates an example of a format indication being comprised within a Flow Label in a IPv6 Network layer header. In this example the IPv6 Flow Label value, or a part of the Flow Label, may be used as the format indication.

[0179] The internal RAN equipment network function may determine the format indication from the format indication in the IPv6 Flow Label to create internal metadata identifier for the eAxC-ID format, and may then send this internal metadata with the eCPRI message(s) in the payload to a processing unit for parsing. The processing unit may then parse the eCPRI message appropriately using the format indicated in the metadata.

[0180] Each of the one or more processing units may then assume that the eAxC-l Ds within the eCPRI messages will have the format indicated by the network function.

[0181] In this example, the eAxC-IDs within the eCPRI messages in the transport packet may be required to have the same format.

[0182] Figure 23 shows a network node 2300 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O- CU).

[0183] The network node 2300 includes a processing circuitry 2302, a memory 2304, a communication interface 2306, and a power source 2308. The network node 2300 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 the network node 2300 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, the network node 2300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 2304 for different RATs) and some components may be reused (e.g., a same antenna 2310 may be shared by different RATs). The network node 2300 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 2300, 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 2300.

[0184] The processing circuitry 2302 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 2300 components, such as the memory 2304, to provide network node 2300 functionality. For example, the processing circuitry 2302 may be configured to cause the network node to perform the methods as described with reference to Figures 4, 5, 7 and / or 8.

[0185] In some embodiments, the processing circuitry 2302 includes a system on a chip (SOC). In some embodiments, the processing circuitry 2302 includes one or more of radio frequency (RF) transceiver circuitry 2312 and baseband processing circuitry 2314. In some embodiments, the radio frequency (RF) transceiver circuitry 2312 and the baseband processing circuitry 2314 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 2312 and baseband processing circuitry 2314 may be on the same chip or set of chips, boards, or units.

[0186] The memory 2304 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), readonly 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 computerexecutable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 2302. The memory 2304 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 2302 and utilized by the network node 2300. The memory 2304 may be used to store any calculations made by the processing circuitry 2302 and / or any data received via the communication interface 2306. In some embodiments, the processing circuitry 2302 and memory 2304 is integrated.

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

[0188] In certain alternative embodiments, the network node 2300 does not include separate radio front-end circuitry 2318, instead, the processing circuitry 2302 includes radio frontend circuitry and is connected to the antenna 2310. Similarly, in some embodiments, all or some of the RF transceiver circuitry 2312 is part of the communication interface 2306. In still other embodiments, the communication interface 2306 includes one or more ports or terminals 2316, the radio front-end circuitry 2318, and the RF transceiver circuitry 2312, as part of a radio unit (not shown), and the communication interface 2306 communicates with the baseband processing circuitry 2314, which is part of a digital unit (not shown). The antenna 2310 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 2310 may be coupled to the radio front-end circuitry 2318 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 2310 is separate from the network node 2300 and connectable to the network node 2300 through an interface or port.

[0189] The antenna 2310, communication interface 2306, and / or the processing circuitry 2302 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, the antenna 2310, the communication interface 2306, and / or the processing circuitry 2302 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.

[0190] The power source 2308 provides power to the various components of network node 2300 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 2308 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 2300 with power for performing the functionality described herein. For example, the network node 2300 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 the power source 2308. As a further example, the power source 2308 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. Embodiments of the network node 2300 may include additional components beyond those shown in Figure 23 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, the network node 2300 may include user interface equipment to allow input of information into the network node 2300 and to allow output of information from the network node 2300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 2300. In some embodiments providing a core network node, some components, such as the radio front-end circuitry 2318 and the RF transceiver circuitry 2312 may be omitted.

[0191] The network node 2300 may be configured operate in the manner described herein in respect of a transmitting RAN entity or a receiving RAN entity.

[0192] Figure 24 is a block diagram illustrating an transmitting RAN entity 2400 according to some embodiments. The transmitting RAN entity 2400 is for entity for transmitting, a message within a transport packet to a receiving RAN entity. The transmitting RAN entity 2400 comprises a transmitting module 2402 configured to transmit the message to the receiving RAN entity, wherein the message comprises: an extended carrier identifier, eAxC-ID, and a format indication indicating a format of the eAxC-ID. The transmitting RAN entity 2400 may operate in the manner described herein in respect of a transmitting RAN entity.

[0193] Figure 25 is a block diagram illustrating a receiving RAN entity 2500 according to some embodiments. The receiving RAN entity 2500 is for entity for receiving, a message within a transport packet from a transmitting RAN entity. The receiving RAN entity 2500 comprises a receiving module 2502 is configured to receive the message from the transmitting RAN entity, wherein the message comprises: an extended carrier identifier, eAxC-ID, and a format indication indicating a format of the eAxC-ID. The receiving RAN entity 2500 may operate in the manner described herein in respect of a receiving RAN entity.

[0194] There is also provided a computer program comprising instructions which, when executed on a least one processor (such as the processing circuitry 2302 of the network node 2300 described earlier), cause the processor to carry out at least part of the method(s) described herein. According to some embodiments there is provided a carrier containing the computer program. In some embodiments, the carrier can be any one of an electronic signal, an optical signal, an electromagnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable medium. There is also provided a (for example, tangible and / or non-transient) computer-readable medium comprising instructions which, when executed by at least one processor, cause the at least one processor to perform at least part of the method(s) described herein.

[0195] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

[0196] Embodiments described herein enable simultaneous use of multiple different eCPRI message eAxC-ID formats towards one receiving RAN entity or even towards a single processing unit as the eCPRI protocol itself may comprise the format indication. The embodiments described herein also enable use of only Network Layer addressing between processing resources in a transmitting and receiving RAN entity, this includes forwarding of encrypted packet / eCPRI messages and simplifies the implementation of RAN equipment internal switching function.

[0197] Some embodiments also enable the capturing of a larger and more flexibly sized eAxC- I D header which addresses problems associated with scaling of the eAxC-l D header and the sub-fields it contains.

Claims

CLAIMS1. A method performed by a transmitting radio access network, RAN, entity for transmitting, a message within a transport packet to a receiving RAN entity, the method comprising: transmitting the message to the receiving RAN entity, wherein the message comprises: an extended carrier identifier, eAxC-ID, and a format indication indicating a format of the eAxC-ID.

2. The method as claimed in claim 1 wherein the format of the eAxC-ID is defined by a number of bits assigned to at least the following parameters within the eAxC-ID:Open Distributed Unit port identifier, DU_Port_ld;Band Sector Identifier, BandSectorJD, Component Carrier Identifier, CC_ID; and Open Radio unit port identifier, RU_Port_ID.

3. The method as claimed in claim 1 or 2, wherein the format indication comprises a value, wherein the transmitting RAN entity is configured with a mapping of the value to the format.

4. The method of any one of claims 1 to 3, further comprising: receiving the mapping from the receiving RAN entity.

5. The method of any one of claims 1 to 4, wherein the message further comprises an inclusion indication indicating that the format indication is included in the message.

6. The method of any one of claims 1 to 5, wherein the format indication is comprised within a common header of the message.

7. The method of claim 6, wherein the format indication is comprised within a message type field of the common header.

8. The method of claim 7, wherein the format indication comprises four most significant bits of the message type field of the common header.

9. The method of claim 7 or 8 when dependent on claim 5, wherein the inclusion indication is comprised within the common header of the message.

10. The method of claim 8, wherein the inclusion indication is comprised within the 4 most significant bits of the message type field of the common header.

11. The method of claim 6, wherein the format indication is comprised within an eAxC format message field within the common header.

12. The method of claim 11 when dependent on claim 5, wherein the inclusion indication is comprised within the message type field of the common header.

13. The method of claim 12, wherein the inclusion indication comprises at least one of the 4 most significant bits of the message type field of the common header.

14. The method of any one of claims 1 to 5, wherein the format indication is comprised within an address header of the message.

15. The method of claim 14 when dependent on claim 5, wherein the inclusion indication comprises a message type in a message type field of a common header of the message.

16. The method of any one of claims 1 to 4, wherein the format indication is comprised within a network layer header of the transport packet.

17. The method of claim 16, wherein the format indication is comprised within an IPv6 Flow Label.

18. The method of claim 16, wherein the format indication is comprised within a VLAN identifier.

19. The method of claim 16, wherein the format indication is comprised within a stream identifier.

20. A method performed by a receiving radio access network, RAN, entity for receiving, a message within a transport packet from a transmitting RAN entity, the method comprising: receiving, from the transmitting RAN entity, the message, wherein the message comprises: an extended carrier identifier, eAxC, and a format indication of a format of the eAxC-ID.

21. The method as claimed in claim 20 wherein the format of the eAxC-ID is defined by a number of bits assigned to at least the following parameters within the eAxC-ID:Open Distributed Unit port identifier, DU_Port_ld;Band Sector Identifier, BandSectorJD,Component Carrier Identifier, CCJD; andOpen Radio unit port identifier, RU_Port_ID.

22. The method as claimed in claim 20 or 21 , wherein the format indication comprises a value, wherein the transmitting RAN entity is configured with a mapping of the value to the format.

23. The method of any one of claims 20 to 22, further comprising: receiving the mapping from the transmitting RAN entity.

24. The method of any one of claims 20 to 23, wherein the message further comprises an inclusion indication indicating that the format indication is included in the message.

25. The method of any one of claims 20 to 24, wherein the format indication is comprised within a common header of the message.

26. The method of claim 25, wherein the format indication is comprised within a message type field of the common header.

27. The method of claim 26, wherein the format indication comprises 4 most significant bits of the message type field of the common header.

28. The method of claim 26 or 27 when dependent on claim 24, wherein the inclusion indication is comprised within the common header of the message.

29. The method of claim 27, wherein the inclusion indication is also comprised within the 4 most significant bits of the message type field of the common header.

30. The method of claim 25, wherein the format indication is comprised within an eAxC format message field within the common header.

31. The method of claim 30 when dependent on claim 24, wherein the inclusion indication is comprised within the message type field of the common header.

32. The method of claim 31, wherein the inclusion indication comprises at least one of the four most significant bits of the message type field of the common header.

33. The method of any one of claims 20 to 24, wherein the format indication is comprised within an address header of the message.

34. The method of claim 33 when dependent on claim 24, wherein the inclusion indication comprises a message type in a message type field of a common header of the message.

35. The method of any one of claims 20 to 24, wherein the format indication is comprised within a network layer header of the transport packet.

36. The method of claim 35, wherein the format indication is comprised within anIPv6 Flow Label.

37. The method of claim 35, wherein the format indication is comprised within a VLAN identifier.

38. The method of claim 35, wherein the format indication is comprised within a stream identifier.

39. The method of any one of claims 20 to 38 further comprising: receiving the message at a switching function of the receiving RAN entity; and forwarding the message to one or more processing units of the receiving RAN entity.

40. The method of claim 39 when further comprising: determining, at the switching function, the format of the eAxC from the format indication, and indicating the format to the one or more processing units.

41. A transmitting radio access network, RAN, entity for transmitting, a message within a transport packet to a receiving RAN entity, the transmitting RAN entity comprising processing and a memory, the memory containing instructions executable by the processing circuitry whereby the transmitting RAN entity is operable to: transmit the message to the receiving RAN entity, wherein the message comprises: an extended carrier identifier, eAxC-ID, and a format indication indicating a format of the eAxC-ID.

42. The transmitting RAN entity as claimed in claim 41 wherein the memory further contains instructions executable by the processing circuitry whereby the transmitting RAN entity is operable to perform the method as claimed in any one of claims 2 to 19.

43. A receiving radio access network, RAN, entity for receiving, a message within a transport packet from a transmitting RAN entity, the receiving RAN entity comprising processing and a memory, the memory containing instructions executable by the processing circuitry whereby the receiving RAN entity is operable to: receive the message from the transmitting RAN entity, wherein the message comprises: an extended carrier identifier, eAxC-ID, and a format indication indicating a format of the eAxC-ID.

44. The receiving RAN entity as claimed in claim 43 wherein the memory further contains instructions executable by the processing circuitry whereby the transmitting RAN entity is operable to perform the method as claimed in any one of claims 21 to 40.

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

46. A carrier containing the computer program according to claim 45, wherein the carrier comprises one of an electronic signal, optical signal, radio signal or computer readable storage medium.

47. A computer-readable medium comprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method according to any of claims 1 to 4048. A computer program product comprising non transitory computer readable media having stored thereon a computer program according to claim 45.

Images