Method for assigning identifiers to fronthaul traffic flows in O-RAN compliant radio access network

Abstract

A method of enabling enhanced Management Plane functions on the fronthaul interface between Open Radio Access Network Radio Unit (O-RU) and O-RAN Distributed Unit (O-DU) includes: identifying four subfields within 16-bit Extended Antenna Carrier Id (Eaxc-ID) field using a first set of four specified bitmasks including DU_Port_ID bitmask, BandSector_ID bitmask, CC_ID bitmask, and RU_Port_ID bitmask; and providing a second set of specified bitmasks including at least one of band-bitmask, sector-bitmask, channel-type-bitmask, and layer-antenna-port-bitmask, wherein: i) band bitmask defines which bits within the BandSector_ID bitmask subfield are used to indicate band; ii) sector bitmask defines which bits within the BandSector_ID bitmask subfield are used to indicate sector-id; iii) channel-type bitmask defines which bits within the RU_Port_ID bitmask subfield are used to indicate channel type; and iv) layer-antenna-port bitmask defines which bits within the RU_Port_ID bitmask subfield are used to indicate one of antenna port number or data layer number.

Claims

1. A method of enabling enhanced Management Plane (M-Plane) functions on the fronthaul interface between Open Radio Access Network Radio Unit (O-RU) and O-RAN Distributed Unit (O-DU) in an Open Radio Access Network (O-RAN)-compatible network, comprising: identifying four subfields within 16-bit Extended Antenna Carrier Id (Eaxc-ID) field using a first set of four specified bitmasks, wherein the four subfields include DU_Port_ID bitmask, BandSector_ID bitmask, CC_ID bitmask, and RU_Port_ID bitmask; and providing at least one additional bitmask to identify additional information regarding at least one individual bit within at least one of the BandSector_ID bitmask subfield and RU_Port_ID bitmask subfield; wherein the at least one additional bitmask identifies at least one individual bit conveying additional information regarding at least one of band, sector, channel type, antenna port and data layer, and wherein the at least one additional bitmask is part of a second set of specified bitmasks including at least one of a band-bitmask, a sector-bitmask, a channel-type-bitmask, and a layer-antenna-port-bitmask.

2. The method according to claim 1, wherein at least one of: i) the band bitmask defines which bits within the BandSector_ID bitmask subfield are used to indicate band; ii) the sector bitmask defines which bits within the BandSector_ID bitmask subfield are used to indicate sector-id; iii) the channel-type bitmask defines which bits within the RU_Port_ID bitmask subfield are used to indicate channel type; and iv) the layer-antenna-port bitmask defines which bits within the RU_Port_ID bitmask subfield are used to indicate one of antenna port number or data layer number.

3. The method according to claim 1, further comprising: providing an identification of at least one enumerated data type defining a specific set of values used in conjunction with the channel-type bitmask to indicate to O-RAN-compatible network functions how to interpret the values contained in the channel-type bitmask bits.

4. The method according to claim 3, wherein the at least one enumerated data type is defined by at least one of i) uplink (UL) Channel Type Enumerations, ii) downlink (DL) Channel Type Enumerations, iii) Layer Type Enumerations, and iv) Antenna Port Type Enumerations.

5. The method according to claim 1, wherein the at least one additional bitmask is provided within the 16-bit Eaxc-ID field.

6. The method according to claim 5, wherein the at least one additional bitmask overlaps the first set of four specified bitmasks.

7. The method according to claim 5, further comprising: providing an identification of at least one enumerated data type defining a specific set of values used in conjunction with the channel-type bitmask to indicate to O-RAN-compatible network functions how to interpret the values contained in the channel-type bitmask bits.

8. The method according to claim 7, wherein the at least one enumerated data type is defined by at least one of i) uplink (UL) Channel Type Enumerations, ii) downlink (DL) Channel Type Enumerations, iii) Layer Type Enumerations, and iv) Antenna Port Type Enumerations.

9. The method according to claim 2, wherein the at least one additional bitmask overlaps the first set of four specified bitmasks.

10. The method according to claim 9, further comprising: providing an identification of at least one enumerated data type defining a specific set of values used in conjunction with the channel-type bitmask to indicate to O-RAN-compatible network functions how to interpret the values contained in the channel-type bitmask bits.

11. The method according to claim 10, wherein the at least one enumerated data type is defined by at least one of i) uplink (UL) Channel Type Enumerations, ii) downlink (DL) Channel Type Enumerations, iii) Layer Type Enumerations, and iv) Antenna Port Type Enumerations.

Description

BRIEF DESCRIPTION OF THE FIGURES

(1) FIG. 1 illustrates Eaxc-ID in a low-level Tx endpoint according to the present disclosure.

(2) FIG. 2 illustrates Eaxc-ID in a low-level Rx endpoint according to the present disclosure.

(3) FIG. 3 illustrates augmentation of the field “e-axcid” under the low-level-Tx-endpoints and low-level-Rx-endpoints by adding new bitmasks.

(4) FIG. 4 illustrates definitions of a set of enumerated values to be used with the proposed new channel-type bitmask.

(5) FIG. 5 illustrate an example set of values of the various bitmasks.

(6) FIG. 6 illustrates example interpretations of various eaxc-id values.

(7) FIG. 7 illustrates an example O-RAN system architecture.

DETAILED DESCRIPTION

(8) The existing O-RAN specifications define different YANG files and YANG modules that describe the various data modules which are used to specify the system configuration to be used by the various network functions/modules such as O-DU and O-RU. YANG is a data modelling language which is used to describe how data is supposed to look. A YANG module defines a hierarchy of nodes that can be used for Network Configuration Protocol (NETCONF)-based operations. One of the Yang modules is o-ran-uplane-conf.yang which captures the information regarding the definition of endpoints to be used at the O-DU and O-RU. The o-ran-uplane-conf.yang module contains transmit (Tx) and receive (Rx) endpoints that define a list of endpoints to be configured and used on the DL and UL. Each endpoint defines its own Eaxc-ID bitmask and Eaxc-ID value, as shown in FIGS. 1 and 2. FIG. 1 illustrates Eaxc-ID in a low-level Tx endpoint. FIG. 2 illustrates Eaxc-ID in a low-level Rx endpoint. The qualifier “low-level” in the context of these endpoints is a terminology used by the ORAN specification in the context of standard YANG files.

(9) According to an example embodiment shown in FIG. 3, the present disclosure augments the field “e-axcid” under the low-level-Tx-endpoints and low-level-Rx-endpoints by adding new bitmasks. In addition to the existing bitmask fields 3001 and existing e-axcid value field 3003, new proposed bitmask fields 3002 are provided.

(10) In an example embodiment of the present disclosure, the four new bitmasks in the new bitmask fields 3002 are used along with the four existing bitmasks in the fields 3001 in the following manner. The <band-bitmask> and <sector-bitmask> are subset of the <band-sector-bitmask> and are used to define which bits within the band-sector subfield should be used to indicate band and which bits should be used to indicate sector-id. The <channel-type-bitmask> and <layer-antenna-port-bitmask> are subset of the <ru-port-bitmask> and are used to define which bits within the ru-port-id subfield should be used to indicate the channel type and which bits should be used to indicate antenna port/data layer number.

(11) In an example embodiment of the present disclosure, the <band-bitmask> and <sector-bitmask> need not add up to use all the bits defined for <band-sector-bitmask>.

(12) For example, the band-sector-id bitmask may have a value 16128, indicating six bits being used for band-sector-id (bits 3 to 8). Within these six bits (bits 3 to 8), only two bits may be used for indicating band (band-bitmask=12288, which means bits 3 and 4) and another two bits may be used for indicating sector (sector-bitmask=768, which means bits 7 and 8). The remaining two bits (bits 5 and 6) may be left unused.

(13) In an example embodiment of the present disclosure, the <channel-type-bitmask> and <layer-antenna-port-bitmask> need not add up to use all the bits defined for <ru-port-bitmask>. For example, the ru-port-bitmask may have a value 15, indicating four bits being used for ru-port-id (bits 13 to 16). Within these four bits, only one bit may be used for indicating channel-type (channel-type-bitmask=8, which means bit 13) and another two bits may be used for indicating antenna-port/data-layer (layer-antenna-port-bitmask=3, which means bits 15 and 16). The remaining one bit (bits 14) may be left unused.

(14) In an example embodiment of the present disclosure, any of the four new bitmasks in the new bitmask fields 3002 may be set to zero if the network function does not wish to identify the specific bits within the bit field. In addition, for supporting backward compatibility with network functions compliant with older versions of O-RAN specifications, the four new bitmask fields can be marked as “non-mandatory” in the YANG module.

(15) In an example embodiment of the present disclosure, an enumerated data type is introduced for incorporation into the O-RAN specifications, which enumerated data type defines a specific set of values that can be used with the proposed new channel-type bitmask to indicate to the network functions how to interpret the values contained in those channel-type bitmask bits. In this example embodiment, the set of enumerated values may be defined as shown in FIG. 4, which set of enumerated values may be further extended. The definitions (of enumerations) shown in FIG. 4 (which include UL Channel Type Enumerations (O-RU to O-DU); DL Channel Type Enumerations (O-DU to O-RU); Layer Type Enumerations (O-DU to O-RU); and Antenna Port Type Enumerations (O-DU to O-RU)), may be used for TDD/FDD, LTE/NR and Cat-A/Cat-B (as defined in ORAN-WG4.CUS.0-v02.00—O-RAN Fronthaul Working Group—“Control, User and Synchronization Plane Specification”) interfaces.

(16) FIG. 5 illustrate an example set of values of the various bitmasks (existing bitmasks as well as newly incorporated bitmasks) and how these should be interpreted. The set of values shown in FIG. 5 is just one example, and it should be noted that the method and the system according to the present disclosure allow other bitmask values to be used as per the O-RU capabilities and required configuration. In the example shown in FIG. 5, the channel-type bitmask uses one bit and the layer-antenna-port bitmasks use two bits, i.e., in total these bitmasks use only three out of four bits used by ru-port-id subfield. However, for RUs supporting more antenna ports (e.g., in Massive MIMO cases), the layer-antenna-port bitmask can be extended to use three bits and thus support up-to 8 antenna ports/layers.

(17) FIG. 6 illustrates example interpretations of various eaxc-id values, based on the enumerations definitions illustrated in FIG. 4 and the example bitmask values illustrated in FIG. 5.

(18) In an example embodiment according to the present disclosure, the existing o-ran-uplane-confyang module may be enhanced to include the new bitmask fields (e.g., 3002 shown in FIG. 3) and the enumerations definition (e.g., illustrated in FIG. 4) as follows:

(19) TABLE-US-00001 module o-ran-uplane-conf { ... ...  typedef ChannelType { type enumeration {  enum TYPE_PUCCH_PUSCH {  value 0;  }  enum TYPE_PRACH {  value 1;  }  enum TYPE_SRS {  value 2;  }  enum TYPE_NON_SSB {  value 0;  }  enum TYPE_SSB {  value 1;  } }  } typedef LayerType { type enumeration {  enum TYPE_LAYER_1{  value 0;  }  enum TYPE_LAYER_2 {  value 1;  }  } typedef AntennaPortType { type enumeration {  enum TYPE_ANTENNA_PORT_0{  value 0;  }  enum TYPE_ANTENNA_PORT_1{  value 1;  }  }  grouping eaxc { description  “One eAxC identifier (eAxC ID) comprises a band and sector  identifier (BandSector_ID), a component-carrier identifier  (CC_ID) and a spatial stream identifier (RU_Port_ID).  In this version of the specification, one eAxC contains only  one spatial stream (i.e. one beam per subcarrier) at a time.  Bit allocation is subdivided as follows:  * O_DU_Port_ID: Used to differentiate processing units  at O-DU  * BandSector_ID: Aggregated cell identifier  * CC_ID: distinguishes Carrier Components  * RU_Port_ID: Used to differentiate spatial streams or  beams on the O-RU  The bitwidth of each of the above fields is variable this model is supposed to check if we are occupying bits continuously but we do not have to occupy all 16 bits”; leaf o-du-port-bitmask {  type uint16;  mandatory true;  description “mask for eaxc-id bits used to encode O-DU Port ID”; } leaf band-sector-bitmask {  type uint16;  mandatory true;  description “mask for eaxc-id bits used to encode the band sector ID”; } leaf ccid-bitmask {  type uint16;  mandatory true;  description “mask for eaxc-id bits used to encode the component carrier id”; } leaf ru-port-bitmask {  type uint16;  mandatory true;  description “mask for eaxc-id bits used to encode the O-RU Port ID”; } leaf band-bitmask {  type uint16;  mandatory false;  description “mask for eaxc-id bits used to encode band number”; } leaf sector-bitmask {  type uint16;  mandatory false;  description “mask for eaxc-id bits used to encode the sector”; } leaf channel-type-bitmask {  type uint16;  mandatory false;  description “mask for eaxc-id bits used to encode the channel type (e.g., PRACH, SSB)”; } leaf layer-antenna-port-bitmask {  type uint16;  mandatory true;  description “mask for eaxc-id bits used to encode the data layer or antenna port/spatial stream number ”; } leaf eaxc-id {  type uint16;  mandatory true;  description “encoded value of eaxcid to be read by CU-Plane”; }  } ... ... }

(20) The above-listed values are merely exemplary, and other enumerated values may be defined for the bitmask.

(21) FIG. 7 illustrates an example O-RAN system architecture, in which the upper physical layer (U-PHY) blocks such as the scrambling, modulation, layer mapping, resource element (RE) mapping, and I/Q compression (as well as optional precoding, which may be bypassed in bypass mode) can be implemented in the O-DU 7001. The I/Q decompression, precoding, digital beamforming, inverse Fast Fourier Transform (iFFT), Cyclic Prefix (CP) addition, digital-to-analog conversion, and optionally analog beamforming can be implemented in the O-RU 7002. O-RAN fronthaul (FH) 7003 is shown between O-DU and O-RU. The example system architecture is illustrated in FIG. 7 merely for the purpose of providing a general system background for the example embodiments of the method according to the present disclosure, and the example system architecture of FIG. 7 should not be construed as limiting the present disclosure.

(22) The present disclosure provides a first example method of enabling enhanced Management Plane (M-Plane) functions on the fronthaul interface between Open Radio Access Network Radio Unit (O-RU) and O-RAN Distributed Unit (O-DU) in an Open Radio Access Network (O-RAN)-compatible network, which method includes: identifying four subfields within 16-bit Extended Antenna Carrier Id (Eaxc-ID) field using a first set of four specified bitmasks, wherein the four subfields include DU_Port_ID bitmask, BandSector_ID bitmask, CC_ID bitmask, and RU_Port_ID bitmask; and providing at least one additional bitmask to identify additional information regarding at least one individual bit within at least one of the BandSector_ID bitmask subfield and RU_Port_ID bitmask subfield.

(23) The present disclosure provides a second example method based on the above-discussed first example method, in which second example method the at least one additional bitmask identifies at least one individual bit conveying additional information regarding at least one of band, sector, channel type, antenna port and data layer.

(24) The present disclosure provides a third example method based on the above-discussed second example method, in which third example method the at least one additional bitmask is part of a second set of specified bitmasks including at least one of a band-bitmask, a sector-bitmask, a channel-type-bitmask, and a layer-antenna-port-bitmask.

(25) The present disclosure provides a fourth example method based on the above-discussed third example method, in which fourth example method at least one of: i) the band bitmask defines which bits within the BandSector_ID bitmask subfield are used to indicate band; ii) the sector bitmask defines which bits within the BandSector_ID bitmask subfield are used to indicate sector-id; iii) the channel-type bitmask defines which bits within the RU_Port_ID bitmask subfield are used to indicate channel type; and iv) the layer-antenna-port bitmask defines which bits within the RU_Port_ID bitmask subfield are used to indicate one of antenna port number or data layer number.

(26) The present disclosure provides a fifth example method based on the above-discussed first example method, in which fifth example method the at least one additional bitmask is provided within the 16-bit Eaxc-ID field.

(27) The present disclosure provides a sixth example method based on the above-discussed fifth example method, in which sixth example method the at least one additional bitmask overlaps the first set of four specified bitmasks.

(28) The present disclosure provides a seventh example method based on the above-discussed third example method, which seventh example method further includes: providing an identification of at least one enumerated data type defining a specific set of values used in conjunction with the channel-type bitmask to indicate to O-RAN-compatible network functions how to interpret the values contained in the channel-type bitmask bits.

(29) The present disclosure provides an eighth example method based on the above-discussed seventh example method, in which eight example method the at least one enumerated data type is defined by at least one of i) uplink (UL) Channel Type Enumerations, ii) downlink (DL) Channel Type Enumerations, iii) Layer Type Enumerations, and iv) Antenna Port Type Enumerations.

(30) The present disclosure provides a ninth example method based on the above-discussed third example method, in which ninth example method the at least one additional bitmask is provided within the 16-bit Eaxc-ID field.

(31) The present disclosure provides a tenth example method based on the above-discussed ninth example method, in which tenth example method the at least one additional bitmask overlaps the first set of four specified bitmasks.

(32) The present disclosure provides an eleventh example method based on the above-discussed ninth example method, which eleventh example method further includes: providing an identification of at least one enumerated data type defining a specific set of values used in conjunction with the channel-type bitmask to indicate to O-RAN-compatible network functions how to interpret the values contained in the channel-type bitmask bits.

(33) The present disclosure provides a twelfth example method based on the above-discussed eleventh example method, in which twelfth example method the at least one enumerated data type is defined by at least one of i) uplink (UL) Channel Type Enumerations, ii) downlink (DL) Channel Type Enumerations, iii) Layer Type Enumerations, and iv) Antenna Port Type Enumerations.

(34) The present disclosure provides a thirteenth example method based on the above-discussed fourth example method, in which thirteenth example method the at least one additional bitmask overlaps the first set of four specified bitmasks.

(35) The present disclosure provides a fourteenth example method based on the above-discussed thirteenth example method, which thirteenth example method further includes: providing an identification of at least one enumerated data type defining a specific set of values used in conjunction with the channel-type bitmask to indicate to O-RAN-compatible network functions how to interpret the values contained in the channel-type bitmask bits.

(36) The present disclosure provides a fifteenth example method based on the above-discussed fourteenth example method, in which fourteenth example method the at least one enumerated data type is defined by at least one of i) uplink (UL) Channel Type Enumerations, ii) downlink (DL) Channel Type Enumerations, iii) Layer Type Enumerations, and iv) Antenna Port Type Enumerations.

Glossary of Terms

(37) 3GPP: Third generation partnership project

(38) 4G: 4.sup.th Generation

(39) 5G; 5.sup.th Generation

(40) CC: Component Carrier

(41) CNF: Cloud Native Network Function

(42) C-plane: Control plane

(43) CU: Central unit

(44) DL: Downlink

(45) DU: Distributed unit

(46) Eaxc-id: Extended Antenna Carrier ID

(47) FDD: Frequency Division Duplex

(48) LTE: Long Term Evolution

(49) M-plane: Management plane

(50) MIMO: Multiple Input, Multiple Output

(51) NMS: Network Management System

(52) NR: New radio

(53) OAM: Operation and Management

(54) O-DU: ORAN-DU

(55) O-RU: ORAN-RU

(56) O-RAN: Open Radio Access Network

(57) PNF: Physical Network Function

(58) PRACH: Physical Random Access Channel

(59) PUCCH: Physical Uplink Control Channel

(60) PUSCH: Physical Uplink Shared Channel

(61) RAN: Radio Access Network

(62) RRU: Remote Radio Unit

(63) RU: Radio Unit

(64) Rx: Receive

(65) SRS: Sounding Reference Signal

(66) SSB: Synchronization Signal Block

(67) TDD: Time Division Duplex

(68) Tx: Transmit

(69) U-plane: User plane

(70) UL: Uplink