IT202000022147A1

IT202000022147A1 - FRONTHAUL INTERFACE FOR ADVANCED SPLIT-RADIO ACCESS NETWORK (RAN) SYSTEMS

Info

Publication number: IT202000022147A1
Application number: IT102020000022147A
Authority: IT
Inventors: Balaji B Raghothaman; Calogero Armao; Irfaan Ahamed Salahuddeen
Original assignee: Commscope Technologies Llc
Priority date: 2020-12-07
Filing date: 2020-12-07
Publication date: 2022-06-07

Description

DESCRIZIONE del brevetto per modello industriale di utilit?: ?INTERFACCIA FRONTHAUL PER SISTEMI DI RETE DI ACCESSO SPLIT-RADIO AVANZATI (RAN)? DESCRIPTION of the industrial utility model patent: ?FRONTHAUL INTERFACE FOR ADVANCED SPLIT-RADIO ACCESS NETWORK SYSTEMS (RAN)?

DESCRIZIONE DESCRIPTION

[0001] L?Alleanza O-RAN ha pubblicato specifiche definenti un?architettura per implementare infrastrutture RAN di prossima generazione. ?O-RAN? si riferisce a una rete di accesso radio (RAN) aperta. L?architettura O-RAN impiega un?unit? distribuita (DU) (anche denominata ?O-RAN DU? o ?O-DU?) e un?unit? remota (RU) (anche denominata ?O-RAN RU? o ?O-RU?). Ciascuna DU implementa le funzioni di Strato 2 e Strato superiore 1 per l?interfaccia senza fili usata per comunicare in modalit? senza fili con il terminale utente (UE), e ciascuna RU implementa le funzioni di Strato inferiore 1 per tale interfaccia senza fili. Ciascuna DU ? accoppiata a ciascuna RU su un collegamento di fronthaul (per esempio, implementato usando una rete Ethernet commutata). [0001] The O-RAN Alliance has published specifications defining an architecture for implementing next generation RAN infrastructures. ?O-RAN? refers to an open radio access network (RAN). The O-RAN architecture employs a unit? distributed (DU) (also denominated ?O-RAN DU? or ?O-DU?) and a?unit? remote (RU) (also referred to as ?O-RAN RU? or ?O-RU?). Each DU implements Layer 2 and Upper Layer 1 functions for the wireless interface used to communicate in wireless mode. wireless with the user equipment (UE), and each RU implements Lower Layer 1 functions for that wireless interface. Each DU ? coupled to each RU over a fronthaul link (for example, implemented using a switched Ethernet network).

[0002] L?alleanza O-RAN ha pubblicato specifiche definenti un?interfaccia di fronthaul aperta per comunicazioni tra DU e RU sul fronthaul. Per esempio, il Gruppo di lavoro di Fronthaul di O-RAN (Gruppo di lavoro 4) ha prodotto una ?Specifica di piano di controllo, utente e sincronizzazione? che specifica la divisione funzionale che occorre usare tra le funzioni implementate nella DU e le funzioni implementate nella RU. Questa specifica di fronthaul di O-RAN specifica che una cosiddetta divisione funzionale ?7-2x? pu? essere usata con due varianti che differiscono su dove la funzione di precodifica ? implementata. [0002] The O-RAN alliance has published specifications defining an open fronthaul interface for communications between DU and RU on fronthaul. For example, the O-RAN Fronthaul Working Group (Working Group 4) produced a ?Control Plan, User and Synchronization Specification? which specifies the functional division to be used between the functions implemented in the DU and the functions implemented in the RU. This O-RAN fronthaul specification specifies that a so-called ?7-2x? can? be used with two variants that differ on where the precoding function ? implemented.

[0003] La Figura 1 illustra la divisione funzionale 7-2x usata per il collegamento discendente in cui la funzione di precodifica viene implementata nella DU 104. Come mostrato nella Figura 1, la funzione di precodifica 102 per l?interfaccia senza fili viene implementata nella DU 104, mentre la funzione di formazione di fascio 106 ? implementata nella RU 108. Come indicato sopra, la DU 104 e la RU 108 comunicano tra loro sul fronthaul di O-RAN 110. La variante della divisione funzionale 7-2x mostrata nella Figura 1 ? anche denominata divisione funzionale 7-2x di ?Categoria A?, e una RU 108 che supporta la divisione funzionale 7-2x di Categoria A ? anche denominata RU di ?Categoria A? 108. [0003] Figure 1 illustrates the 7-2x functional division used for the downlink where the precoding function is implemented in the DU 104. As shown in Figure 1 , the precoding function 102 for the wireless interface is implemented in the DU 104, while the beam forming function 106 ? implemented in RU 108. As noted above, DU 104 and RU 108 communicate with each other on the fronthaul of O-RAN 110. The 7-2x functional split variant shown in Figure 1 ? also referred to as ?Category A? 7-2x functional division, and an RU 108 supporting Category A 7-2x functional division ? also called RU of ?Category A? 108.

[0004] La Figura 2 illustra la divisione funzionale 7-2x usata per il collegamento discendente in cui la funzione di precodifica viene implementata nella RU 108. Come mostrato nella Figura 2, sia la funzione di precodifica 202 sia la funzione di formazione di fascio 206 per l?interfaccia senza fili sono implementate nella RU 208. Come indicato sopra, la DU 204 e la RU 208 comunicano tra loro sul fronthaul di O-RAN 210. La variante della divisione funzionale 7-2x mostrata nella Figura 2 ? anche denominata divisione funzionale 7-2x di ?Categoria B?, e una RU 208 che supporta la divisione funzionale 7-2x di Categoria B ? anche denominata RU di ?Categoria B? 208. [0004] Figure 2 illustrates the 7-2x functional division used for the downlink in which the precoding function is implemented in the RU 108. As shown in Figure 2 , both the precoding function 202 and the beamforming function 206 for the wireless interface are implemented in RU 208. As indicated above, DU 204 and RU 208 communicate with each other on the fronthaul of O-RAN 210. The 7-2x functional division variant shown in Figure 2 ? also referred to as ?Category B? 7-2x functional division, and an RU 208 supporting Category B 7-2x functional division ? also called RU of ?Category B? 208.

DESCRIZIONE DETTAGLIATA DETAILED DESCRIPTION

[0005] Nelle prime versioni delle specifiche O-RAN, viene usata una configurazione punto-punto in cui ciascuna entit? DU ? accoppiata a una singola entit? RU per servire una singola cella fisica, con un?interfaccia di fronthaul di O-RAN separata istanziata per tale coppia di DU e RU. L?interfaccia di fronthaul di O-RAN viene usata per comunicare messaggi di piano di controllo e piano utente che sono esclusivi per tale coppia di DU e RU. [0005] In the first versions of the O-RAN specifications, a point-to-point configuration is used in which each entity? DU ? coupled to a single entity? RU to service a single physical cell, with a separate O-RAN fronthaul interface instantiated for that pair of DU and RU. The O-RAN fronthaul interface is used to communicate control plane and user plane messages that are unique to that DU and RU pair.

[0006] Una nuova specifica O-RAN ? in fase di sviluppo, la quale definisce configurazioni aggiuntive che possono essere usate per implementare una ?cella condivisa? in cui una singola DU ? accoppiata a molteplici RU per servire una singola cella fisica. Questa specifica di cella condivisa O-RAN descrive due di tali topologie. La Figura 3 illustra una prima configurazione di cella condivisa 300. Nella configurazione di cella condivisa 300 mostrata nella Figura 3, una singola DU 302 ? accoppiata a molteplici RU 304. La DU 302 e le RU 304 comunicano tra loro su un fronthaul 306 che include un multiplatore di fronthaul (FHM) 308. Questa configurazione ? anche ivi denominata ?configurazione di FHM?. Nel collegamento discendente, la DU 302 comunica una singola copia di ciascun messaggio di piano di controllo e piano utente all?FHM 308, il che duplica ciascun messaggio di piano di controllo e piano utente e comunica una rispettiva copia a ciascuna delle molteplici RU 304. Nel collegamento ascendente, ciascuna RU 304 comunica messaggi di piano utente all?FHM 308. L?FHM 308 combina gli elementi di risorsa (RE) ricevuti da tutte le RU 304 per ciascuno slot e in seguito invia un singolo messaggio di piano utente che include i RE combinati per tale slot alla DU 302. [0006] A new O-RAN specification? under development, which defines additional configurations that can be used to implement a ?shared cell? in which a single DU ? coupled to multiple RUs to serve a single physical cell. This O-RAN shared cell specification describes two such topologies. Figure 3 illustrates a first shared cell configuration 300. In the shared cell configuration 300 shown in Figure 3 , a single DU 302 ? coupled to multiple RUs 304. The DU 302 and the RUs 304 communicate with each other over a fronthaul 306 which includes a fronthaul multiplexer (FHM) 308. This configuration is coupled to multiple RUs 304. also referred to therein as ?FHM configuration?. On the downlink, the DU 302 communicates a single copy of each control plane and user plan message to the FHM 308, which duplicates each control plane and user plan message and communicates a respective copy to each of the multiple RUs 304. In the uplink, each RU 304 communicates user plan messages to the FHM 308. The FHM 308 combines the resource elements (REs) received from all RU 304 for each slot and then sends a single user plan message which includes the combined Ds for that slot to DU 302.

[0007] La Figura 4 illustra una seconda configurazione di cella condivisa. Nella configurazione di cella condivisa 400 mostrata nella Figura 4, una singola DU 402 ? accoppiata a molteplici RU 404 per servire una singola cella fisica. In questa configurazione, viene usata una topologia a cascata per implementare il fronthaul 406 su cui la DU 402 e le RU 404 comunicano tra loro. In questa topologia, la DU 402 comunica direttamente con la prima RU 404 nella cascata. Ciascuna RU 404 comunica direttamente con l?unit? (la DU 402 o la RU 404) che immediatamente la precede nella cascata e la RU 404 che immediatamente la segue nella cascata. Nel collegamento discendente, la DU 402 comunica una singola copia di ciascun messaggio di piano di controllo e piano utente alla prima RU 404 nella cascata. Ciascuna RU 404 nella cascata usa ciascun messaggio comunicato ad essa dall?unit? precedente nella cascata e inoltra anche una copia del messaggio alla RU 404 successiva nella cascata. Nel collegamento ascendente, l?ultima RU 404 nella cascata trasmette messaggi di piano utente di collegamento ascendente alla RU 404 che immediatamente la precede nella cascata. Ciascuna RU 404 riceve i messaggi di piano utente di collegamento ascendente trasmessi ad essa dalla RU 404 che immediatamente la segue nella cascata. Per ciascun messaggio di piano utente che una RU 404 riceve dalla RU 404 che immediatamente la segue nella cascata, la RU 404 combina i RE inclusi nel messaggio ricevuto con i RE generati in corrispondenza di tale RU 404 dai segnali di radiofrequenza (RF) di collegamento ascendente che essa riceve per lo slot corrispondente e inoltra un messaggio di piano utente che include i RE combinati all?unit? (la DU 402 o la RU 404) che immediatamente precede tale RU 404 nella cascata. [0007] Figure 4 illustrates a second shared cell configuration. In the shared cell configuration 400 shown in Figure 4 , a single DU 402 ? coupled to multiple RU 404s to serve a single physical cell. In this configuration, a cascade topology is used to implement the fronthaul 406 on which the DU 402 and RU 404 communicate with each other. In this topology, DU 402 communicates directly with the first RU 404 in the cascade. Each RU 404 communicates directly with the unit? (the DU 402 or the RU 404) which immediately precedes it in the waterfall and the RU 404 which immediately follows it in the waterfall. On the downlink, DU 402 communicates a single copy of each control plane and user plane message to the first RU 404 in the cascade. Each RU 404 in the cascade uses each message communicated to it by the unit? previous in the cascade and also forwards a copy of the message to the next RU 404 in the cascade. In the uplink, the last RU 404 in the cascade transmits uplink user plan messages to the RU 404 immediately preceding it in the cascade. Each RU 404 receives the uplink user plan messages transmitted to it by the RU 404 which immediately follows it in the cascade. For each user plan message that a RU 404 receives from the RU 404 which immediately follows it in the cascade, the RU 404 combines the REs included in the received message with the REs generated at that RU 404 by the radio frequency (RF) link signals ascending that it receives for the corresponding slot and forwards a user plan message that includes the combined REs to the unit? (the DU 402 or the RU 404) which immediately precedes this RU 404 in the cascade.

[0008] In entrambe queste configurazioni di cella condivisa, gli stessi dati di piano utente di collegamento discendente sono trasmessi da tutte le RU per ciascun elemento di risorsa, e i dati di piano utente di collegamento ascendente da tutte le RU sono combinati per ciascun elemento di risorsa prima di eseguire l?elaborazione del ricevitore nella DU. Vale a dire che anche se impiegano molteplici RU, queste configurazioni di cella condivisa non supportano il riuso di frequenza. Come usato in questo caso, ?riuso di frequenza? si riferisce a situazioni in cui dati di collegamento discendente separati destinati a differenti UE sono trasmessi simultaneamente agli UE che usano gli stessi blocchi di risorse fisiche (PRB) per la stessa cella. Per tali PRB in cui viene usato il riuso di frequenza, ciascuno dei molteplici UE di riuso viene servito da una differente sottoserie delle RU che servono la cella, in cui nessuna RU viene usata per servire pi? di una UE per tali PRB riusati. Tipicamente, queste situazioni emergono quando gli UE di riuso sono separati fisicamente tra loro in misura sufficiente, in modo che l?interferenza co-canale risultante dalle differenti trasmissioni di collegamento discendente sia sufficientemente bassa. Quanto segue descrive tecniche che permettono di usare il riuso di frequenza impiegando al contempo interfacce di fronthaul di O-RAN altrimenti standard. In both of these shared cell configurations, the same downlink user plan data is transmitted from all RUs for each resource item, and the uplink user plan data from all RUs is combined for each resource item. resource before executing receiver processing in the DU. That is, even though they employ multiple RUs, these shared cell configurations do not support frequency reuse. As used here, ?frequency reuse? refers to situations where separate downlink data destined for different UEs is transmitted simultaneously to UEs using the same physical resource blocks (PRBs) for the same cell. For such PRBs where frequency reuse is used, each of the multiple reuse UEs is served by a different subset of the RUs serving the cell, where no RU is used to serve multiple frequency reuses. of a UE for such reused PRBs. Typically, these situations arise when the reuse UEs are sufficiently physically separated from each other, such that the co-channel interference resulting from the different downlink transmissions is low enough. The following describes techniques that allow frequency reuse to be used while employing otherwise standard O-RAN fronthaul interfaces.

[0009] I messaggi comunicati sul fronthaul di O-RAN possono essere categorizzati in quattro tipi: messaggi di piano di gestione (piano M), messaggi di piano di controllo (piano C), messaggi di piano utente (piano U), e messaggi di piano di sincronizzazione (piano S). I messaggi di piano M comprendono messaggi che si riferiscono all?istanziazione, alla configurazione e alla gestione della RU. I messaggi di piano M sono comunicati di rado, tipicamente durante la configurazione iniziale e il richiamo e durante le riconfigurazioni di sistema. I messaggi di piano U sono inviati in ciascuno slot e sono usati per comunicare sezioni di dati utente (vale a dire i dati RE per i PRB da trasmettere nel collegamento discendente e i dati RE per i PRB ricevuti nel collegamento ascendente). I messaggi di piano U di collegamento discendente sono inviati dalla DU a ciascuna RU per fornire alla RU le sezioni di dati utente da trasmettere da tale RU durante ciascuno slot. I messaggi di piano S sono inviati alla e dalla DU e ciascuna RU al fine di sincronizzare la DU e RU. [0009] The messages communicated on the O-RAN fronthaul can be categorized into four types: management plan messages (M plan), control plan messages (C plan), user plan messages (U plan), and of synchronization plan (Plan S). M-plan messages include messages that relate to RU instantiation, configuration, and management. Plan M messages are communicated infrequently, typically during initial configuration and recall and during system reconfigurations. Floor U messages are sent in each slot and are used to communicate sections of user data (i.e. RE data for PRBs to be transmitted on the downlink and RE data for PRBs received on the uplink). Downlink plan U messages are sent by the DU to each RU to provide the RU with user data sections to be transmitted from that RU during each slot. Plan S messages are sent to and from the DU and each RU in order to synchronize the DU and RU.

[0010] I messaggi di piano C sono inviati in ciascuno slot. I messaggi di piano C di collegamento discendente sono inviati dalla DU a ciascuna RU per fornire alla RU informazioni riguardanti la configurazione dei dati utente inclusi nei messaggi di piano U associati per tale slot. Le informazioni trasportate dai messaggi di piano C di collegamento discendente includono: informazioni che specificano a quale porta di antenna ? destinata la sezione di dati utente associata, la serie di PRB su cui la sezione associata di dati utente deve essere trasmessa, una maschera di elemento di risorsa (RE) per indicare una sottoserie di RE all?interno di ciascun PRB per l?uso con differenti fasci trasmessi durante lo stesso PRB, informazioni di formazione di fascio, e informazioni di esecuzione duplex a divisione tempo (TDD) (per esempio, un bit di direzione di collegamento discendente/collegamento ascendente). [0010] Plan C messages are sent in each slot. Downlink plan C messages are sent by the DU to each RU to provide the RU with information regarding the user data configuration included in the associated plan U messages for that slot. Information carried by downlink plan C messages includes: information specifying at which antenna port ? intended for the associated user data section, the set of PRBs over which the associated user data section is to be transmitted, a resource element (RE) mask to indicate a subset of REs within each PRB for use with different beams transmitted during the same PRB, beam forming information, and time division duplex (TDD) execution information (e.g., a downlink/uplink direction bit).

[0011] Ciascun messaggio di piano C pu? corrispondere a molteplici messaggi di piano U. Ci? viene effettuato al fine di consentire la frammentazione di ciascuna sezione di dati utente in molteplici pacchetti per rispettare le limitazioni dimensionali dei pacchetti IP ed Ethernet per il fronthaul associato. ? richiesto almeno un messaggio di piano U per simbolo. [0011] Each message of plan C can? correspond to multiple messages of plan U. Ci? it is done in order to allow each section of user data to be fragmented into multiple packets to meet the IP and Ethernet packet size limitations for the associated fronthaul. ? at least one U floor message per symbol required.

[0012] La Figura 5 illustra un esempio di un messaggio di piano C 500 per una sezione di dati utente che ? frammentata in molteplici messaggi di piano U 502. In generale, ad eccezione di come descritto di seguito, i messaggi di piano C e piano U sono formattati in conformit? con la specifica di fronthaul di O-RAN. [0012] Figure 5 illustrates an example of a C-plan message 500 for a section of user data which ? fragmented into multiple 502 plan U messages. In general, except as described below, plan C and plan U messages are formatted in accordance with with O-RAN's fronthaul specification.

[0013] Come mostrato nella Figura 5, ciascun messaggio di piano C 500 e messaggio di piano U 502 include un?intestazione di strato di trasporto di interfaccia radio pubblica comune migliorata (eCPRI) 504 e un carico utile di strato di trasporto eCPRI 506. L?intestazione di strato di trasporto eCPRI 504 include, tra gli altri campi, un identificatore 508 che identifica lo specifico flusso di dati associato a tale messaggio. Per ciascun messaggio di piano C 500, questo identificatore 508 ? denominato identificatore di serie di messaggio di dati di controllo in tempo reale eCPRI (ecpriRtcid) 508. Per ciascun messaggio di piano U 502, questo identificatore 508 ? denominato identificatore di serie di messaggio di trasferimento dati eCPRI IQ (ecpriPcid) 508. L?ecpriRtcid 508 del messaggio di piano C 500 deve corrispondere all?ecpriPcid 508 dei corrispondenti messaggi di piano U 502. As shown in Figure 5 , each C-plan message 500 and U-plan message 502 includes an enhanced common public radio interface (eCPRI) transport layer header 504 and an eCPRI transport layer payload 506. The eCPRI transport layer header 504 includes, among other fields, a 508 identifier that identifies the specific data stream associated with that message. For each 500 plan C message, this identifier 508 ? called eCPRI real-time control data message set identifier (ecpriRtcid) 508. For each U plan message 502, this identifier 508 ? called eCPRI IQ data transfer message set identifier (ecpriPcid) 508. The 508 ecpriRtcid of the 500 C plan message must match the 508 ecpriPcid of the 502 corresponding U 502 plan messages.

[0014] Il carico utile di strato di trasporto eCPRI 506 di ciascun messaggio di piano C e piano U 500 e 502 viene usato per comunicare dati di strato applicativo. Questi dati di strato applicativo comprendono campi di intestazione comune 510 per comunicare informazioni che si applicano a tutte le sezioni (per esempio informazioni di riferimento temporale), campi di sezione 512 per descrivere una serie di PRB per una data sezione di dati utente e, nel caso dei messaggi di piano U, i dati di elemento di risorsa (RE) 514 che comprendono i dati RE per i particolari PRB descritti nei campi di sezione 512. The eCPRI transport layer payload 506 of each C-plan and U-plan message 500 and 502 is used to communicate application layer data. This application layer data includes common header fields 510 for communicating information that applies to all sections (e.g. timestamp information), section fields 512 for describing a set of PRBs for a given user data section, and, in case of U-plan messages, the resource element (RE) data 514 which includes the RE data for the particular PRBs described in section fields 512.

[0015] Di particolare rilievo, i campi di sezione 512 di entrambi i messaggi di piano C e piano U 500 e 502 includono un campo identificatore di sezione (SectionID) 516 che ? usato per identificare la particolare sezione di dati utente a cui ? associata la serie di PRB descritti, un campo PRB di avvio (startPrbc) 518 che ? usato per specificare il PRB di avvio della serie di PRB descritti, e un campo numero PRB (numPrbc) 520 che ? usato per specificare il numero di PRB contigui per la serie di PRB descritti. [0015] Of particular note, the section fields 512 of both the C-plan and U-plan messages 500 and 502 include a section identifier (SectionID) field 516 which ? used to identify the particular section of user data to which ? associated with the series of PRBs described, a start PRB field (startPrbc) 518 which ? used to specify the starting PRB of the described PRB series, and a PRB number field (numPrbc) 520 which ? used to specify the number of contiguous PRBs for the set of described PRBs.

[0016] Il SectionID 516 del messaggio di piano C 500 deve corrispondere al SectionID 516 dei corrispondenti messaggi di piano U 502. [0016] The SectionID 516 of floor message C 500 must match the SectionID 516 of the corresponding floor messages U 502.

[0017] Nell?esempio particolare mostrato nella Figura 5, il messaggio di piano C 500 e i messaggi di piano U 502 sono associati a una sezione di dati utente che comprende 66 PRB. La serie di PRB descritti dai campi di sezione 512 del messaggio di piano C 500 include tutti i 66 PRB per tale sezione di dati utente. Pertanto, il campo startPrbc 518 del messaggio di piano C 500 ha il valore ?0?, e il campo numPrbc 520 del messaggio di piano C 500 ha il valore ?66?. [0017] In the particular example shown in Figure 5 , the C floor message 500 and the U floor messages 502 are associated with a user data section comprising 66 PRBs. The set of PRBs described by the fields of section 512 of the C-plan message 500 includes all 66 PRBs for that user data section. Therefore, the startPrbc field 518 of the plan C 500 message has the value ?0?, and the numPrbc field 520 of the plan C 500 message has the value ?66?.

[0018] Nell?esempio mostrato nella Figura 5, la sezione di dati utente ? frammentata in due messaggi di piano U 502. Il primo messaggio di piano U 502 viene usato per comunicare una serie di PRB partendo dal primo PRB (indicato nel campo startPrbc 518 con il valore ?0?) e includente 33 PRB contigui (indicati nel campo numPrbc 520 con il valore ?33?). Il secondo messaggio di piano U 502 viene usato per comunicare una serie di PRB partendo dal trentaquattresimo PRB (indicato nel campo startPrbc 518 con il valore ?33?) e includente 33 PRB contigui (indicati nel campo numPrbc 520 con il valore ?33?). [0018] In the example shown in Figure 5, the user data section ? fragmented into two floor messages U 502. The first floor message U 502 is used to communicate a series of PRBs starting from the first PRB (indicated in the startPrbc 518 field with the value ?0?) and including 33 contiguous PRBs (indicated in the numPrbc 520 with the value ?33?). The second floor message U 502 is used to communicate a series of PRBs starting from the thirty-fourth PRB (indicated in the startPrbc 518 field with the value ?33?) and including 33 contiguous PRBs (indicated in the numPrbc 520 field with the value ?33?) .

[0019] Come mostrato nella Figura 5, i campi di sezione 512 del messaggio di piano C 500 includono anche un campo flag di estensione (ef) 522 e un campo identificatore di formazione di fascio (beamID) 524. Ciascuna RU memorizza varie configurazioni di formazione di fascio esclusive per tale RU. Ciascuna configurazione di formazione di fascio memorizzata in una data RU ha un rispettivo beamID che pu? essere usato per identificare tale configurazione particolare al fine di usare la configurazione associata per effettuare la formazione di fascio o per sostituire la configurazione di formazione di fascio associata a tale beamID con una nuova configurazione di formazione di fascio (per esempio, memorizzando nuovi pesi di formazione di fascio e/o attributi di formazione di fascio comunicati a tale RU in un messaggio di piano C). Il campo ef 522 ? un bit che indica se la descrizione di sezione includer? soltanto il beamID memorizzato nel campo beamID 524 oppure includer? un?altra estensione di sezione 526 dopo il campo beamID 524. Un valore di ?0? nel campo ef 522 indica il primo caso, mentre un valore di ?1? nel campo ef 522 indica il secondo caso. As shown in Figure 5 , section fields 512 of plan C message 500 also include an extension flag (ef) field 522 and a beam forming identifier (beamID) field 524. Each RU stores various configurations of beamforming unique to this RU. Each beamforming configuration stored in a given RU has a respective beamID which can be be used to identify that particular configuration in order to use the associated configuration to perform beamforming or to replace the beamforming configuration associated with that beamID with a new beamforming configuration (for example, by storing new beamforming weights beam pattern and/or beam forming attributes communicated to this RU in a plan C message). The field ef 522 ? a bit that indicates if the section description will include? only the beamID stored in the field beamID 524 or include? another section extension 526 after the beamID field 524. A value of ?0? in the field ef 522 indicates the first case, while a value of ?1? in the field ef 522 indicates the second case.

[0020] Si noti che laddove la nuova estensione di sezione 600 descritta di seguito viene usata per specificare la formazione di fascio da effettuare su una base per RU, il campo beamID 524 viene ignorato. [0020] Note that where the new section extension 600 described below is used to specify the beamforming to be performed on a per RU basis, the beamID field 524 is ignored.

[0021] Le estensioni di sezione 526 sono usate per convogliare informazioni speciali per particolari tipi di dati di sezione. Esempi di estensioni di sezione includono pesi di formazione di fascio, attributi di formazione di fascio, parametri e indicazioni di configurazione di precodifica (applicabili per alcune modalit? di trasmissione (TM) di evoluzione a lungo termine (LTE)), e informazioni di compressione della modulazione. [0021] Section extensions 526 are used to convey special information for particular types of section data. Examples of section extensions include beamforming weights, beamforming attributes, parameters and precoding configuration indications (applicable for some long-term evolution (LTE) transmission modes (TM), and compression information of the modulation.

[0022] Informazioni aggiuntive riguardanti le estensioni di sezione e il formato dei messaggi di piano C e piano U possono essere reperite nella specifica di fronthaul di O-RAN. [0022] Additional information regarding section extensions and the format of plan C and plan U messages can be found in the O-RAN fronthaul specification.

[0023] Inoltre, sebbene la Figura 5 illustri un esempio che usa campi per il Tipo di Sezione 1, occorre comprendere che la nuova estensione di sezione 600 descritta di seguito pu? essere usata con messaggi che usano altri Tipi di Sezione (incluso, per esempio, il Tipo di Sezione 3 per una numerologia mista). Pi? informazioni riguardanti questi differenti Tipi di Sezione (e i campi associati) possono essere reperite nella specifica di fronthaul di O-RAN. [0023] Also, although Figure 5 illustrates an example using fields for Section Type 1, it should be understood that the new section extension 600 described below can be used with messages that use other Section Types (including, for example, Section Type 3 for mixed numerology). Pi? information regarding these different Section Types (and associated fields) can be found in the O-RAN fronthaul specification.

[0024] La Figura 6 illustra una nuova estensione di sezione 600 per l?uso con la specifica di fronthaul di O-RAN. Questa nuova estensione di sezione 600 pu? essere usata per consentire il riuso di frequenza di collegamento discendente da usare in configurazioni in cui una DU ? accoppiata a molteplici RU per servire una singola cella. Questa nuova estensione di sezione 600 pu? essere usata con RU di Categoria A (vale a dire laddove la precodifica viene effettuata nella DU). Questa nuova estensione di sezione 600 pu? essere usata per comunicare differenti dati di sezione a differenti RU. [0024] Figure 6 illustrates a new section extension 600 for use with the O-RAN fronthaul specification. This new section 600 extension can? be used to allow reuse of downlink frequency for use in configurations where a DU ? coupled to multiple RUs to serve a single cell. This new section 600 extension can? be used with Category A RU (i.e. where pre-coding is done in the DU). This new section 600 extension can? be used to communicate different section data to different RUs.

[0025] La nuova estensione di sezione 600 include un campo flag di estensione (ef) 602 che indica se la descrizione di estensione di sezione data ? la descrizione di estensione di sezione finale (indicata con un valore di ?0?) oppure se vi ? un?altra descrizione di estensione di sezione dopo quella corrente (indicata con un valore ?1?). La nuova estensione di sezione 600 mostrata nella Figura 6 include anche un campo tipo di estensione (extType) 604 che ? usato per indicare che il nuovo tipo di estensione di sezione ivi definito deve essere usato memorizzando un valore in questo campo che ? stato assegnato alla nuova estensione di sezione 600. La nuova estensione di sezione 600 mostrata nella Figura 6 include anche un campo lunghezza di estensione (extLen) 606 che ? usato per memorizzare la lunghezza della particolare estensione di sezione definita. Il campo ef 602, il campo extType 604 e il campo extLen 606 della nuova estensione di sezione 600 mostrata nella Figura 6 sono implementati e usati nella modalit? standard come specificato nella specifica di fronthaul di O-RAN. [0025] The new section extension 600 includes an extension flag field (ef) 602 which indicates whether the given section extension description ? the final section extension description (indicated with a value of ?0?) or if there ? another section extension description after the current one (indicated with a value ?1?). The new section extension 600 shown in Figure 6 also includes an extension type field (extType) 604 which ? used to indicate that the new section extension type defined therein is to be used by storing a value in this field which ? been assigned to the new section extension 600. The new section extension 600 shown in Figure 6 also includes an extension length (extLen) field 606 which ? used to store the length of the particular defined section extent. The ef field 602, the extType field 604 and the extLen field 606 of the new section extension 600 shown in Figure 6 are implemented and used in the mode? standard as specified in the O-RAN fronthaul specification.

[0026] La nuova estensione di sezione 600 mostrata nella Figura 6 include un campo di maschera di RU 608, che ? una maschera di bit avente una lunghezza che ? uguale al numero di RU servite dalla DU nella configurazione corrente. Ciascuna RU ? associata a uno dei bit nella maschera di bit memorizzata nel campo di maschera di RU 608. I dati di sezione descritti nel messaggio di piano C associato (e comunicati nell?uno o pi? messaggi di piano U associati a tale messaggio di piano C) sono destinati a una data RU se la posizione di bit nel campo di maschera di RU 608 associata a tale RU ha un valore di ?1? memorizzato al suo interno, e non sono destinati a una data RU se la posizione di bit nel campo di maschera di RU 608 associata a tale RU ha un valore di ?0? memorizzato al suo interno. Vale a dire che la posizione di bit #m nel campo di maschera di RU 608 ha il valore ?1? memorizzato al suo interno se i dati di sezione descritti nel messaggio di piano C associato (e comunicato nell?uno o pi? messaggi di piano U associati a tale messaggio di piano C) sono destinati a RU#m. La posizione di bit #m nel campo di maschera di RU 608 ha il valore di ?0? memorizzato al suo interno se i dati di sezione descritti nel messaggio di piano C associato (e comunicato nell?uno o pi? messaggi di piano U associati a tale messaggio di piano C) non sono destinati a RU#m. Ciascuna RU#m che ha un valore ?1? memorizzato nella posizione di bit #m corrispondente del campo di maschera di RU 608 che ? associato a tale RU#m viene ivi indicata come ?contrassegnata? nel campo di maschera di RU 608, e ciascuna RU#m che ha un valore ?0? memorizzato nella posizione di bit #m corrispondente del campo di maschera di RU 608 che ? associato a tale RU#m viene ivi indicata come ?non contrassegnata? nel campo di maschera di RU 608. [0026] The new section extension 600 shown in Figure 6 includes a mask field of RU 608, which ? a bitmask having a length that ? equal to the number of RUs served by the DU in the current configuration. Each RU ? associated with one of the bits in the bitmask stored in the mask field of RU 608. The section data described in the associated C-plan message (and communicated in the one or more U-plan messages associated with that C-plan message) are intended for a given RU if the bit position in the mask field of RU 608 associated with that RU has a value of ?1? stored therein, and are not intended for a given RU if the bit position in the mask field of RU 608 associated with that RU has a value of ?0? stored within it. That is, the bit position #m in the mask field of RU 608 has the value ?1? stored therein if the section data described in the associated C-plan message (and communicated in one or more U-plan messages associated with this C-plan message) are destined for RU#m. Does the bit position #m in the mask field of RU 608 have the value ?0? stored within it if the section data described in the associated C-plan message (and communicated in one or more U-plan messages associated with this C-plan message) are not destined for RU#m. Each RU#m that has a value ?1? stored in the corresponding bit position #m of the mask field of RU 608 which ? associated with this RU#m is indicated there as ?marked? in the mask field of RU 608, and each RU#m which has a value ?0? stored in the corresponding bit position #m of the mask field of RU 608 which ? associated with this RU#m is indicated there as ?unmarked? in the mask field of RU 608.

[0027] La mappatura di ciascuna RU rispetto a una particolare posizione di bit nel campo di maschera di RU 608 pu? essere configurata tramite una procedura di piano M. [0027] The mapping of each RU to a particular bit position in the mask field of RU 608 can be configured via an M plan procedure.

[0028] Il resto della nuova estensione di sezione 600 viene usato per specificare come ciascuna RU che ? contrassegnata nel campo di maschera di RU 608 deve effettuare la formazione di fascio per i dati di sezione descritti nel messaggio di piano C associato (e comunicato nell?uno o pi? messaggi di piano U associati a tale messaggio di piano C). [0028] The remainder of the new section extension 600 is used to specify how each RU that ? tagged in the mask field of RU 608 must perform beamforming for the section data described in the associated C-plan message (and communicated in the one or more U-plan messages associated with that C-plan message).

[0029] Una prima opzione per come ci? viene effettuato ? mostrata nella Figura 6. Con questa prima opzione, una serie di beamID 610 segue il campo di maschera di RU 608, in cui la serie di beamID 610 include un rispettivo beamID 610 per ciascuna RU contrassegnata nel campo di maschera di RU 608. Vale a dire che il numero di beamID 610 inclusi nella serie di beamID 610 deve essere uguale al numero di RU contrassegnate nella maschera di RU 608. [0029] A first option for how there? is it done? shown in Figure 6. With this first option, a set of beamID 610 follows the mask field of RU 608, where the set of beamID 610 includes a respective beamID 610 for each RU marked in the mask field of RU 608. say that the number of beamID 610 included in the beamID 610 set must be equal to the number of RU marked in the mask of RU 608.

[0030] L?ordine in cui i beamID 610 compaiono nella serie di beamID 610 corrisponde all?ordine in cui le RU si presentano nel campo di maschera di RU 608 (per esempio, letto nell?ordine dal bit pi? a sinistra al bit pi? a destra). Vale a dire che, come mostrato nella Figura 6, la prima posizione di bit nel campo di maschera di RU 608 (posizione di bit #0) corrisponde a RU#0 e il primo beamID nella serie di beamID (beamID#0) corrisponde a tale RU#0. Pi? in generale, la posizione di bit #m nel campo di maschera di RU 608 corrisponde a RU#m e beamID#m nella serie di beamID corrisponde a tale RU#m. Ciascun beamID 610 ? formattato e ha la stessa lunghezza descritta nella specifica di fronthaul di O-RAN. [0030] The order in which the beamIDs 610 appear in the array of beamIDs 610 corresponds to the order in which the RUs appear in the mask field of RU 608 (for example, read in order from the leftmost bit to the bit further right). That is, as shown in Figure 6, the first bit position in the mask field of RU 608 (bit position #0) corresponds to RU#0 and the first beamID in the set of beamIDs (beamID#0) corresponds to such RU#0. Pi? in general, the bit position #m in the mask field of RU 608 corresponds to RU#m and beamID#m in the set of beamIDs corresponds to this RU#m. Each beamID 610 ? formatted and has the same length as described in the O-RAN fronthaul specification.

[0031] Con questa prima opzione, il beamID specificato viene usato per tutti i PRB inclusi nei dati di sezione descritti nel messaggio di piano C associato (e comunicati nell?uno o pi? messaggi di piano U associati a tale messaggio di piano C). [0031] With this first option, the specified beamID is used for all PRBs included in the section data described in the associated C-plan message (and communicated in the one or more U-plan messages associated with that C-plan message) .

[0032] In una seconda opzione per specificare come ciascuna RU che ? contrassegnata nel campo di maschera di RU 608 serve ad effettuare la formazione di fascio per i dati di sezione descritti nel messaggio di piano C associato (e comunicati nell?uno o pi? messaggi di piano U associati a tale messaggio di piano C), viene usata una variante della prima opzione mostrata nella Figura 6. In questa seconda opzione, i pesi di fascio e/o gli attributi di fascio possono essere convogliati insieme al beamID 610 nello stesso modo descritto nella specifica di fronthaul di O-RAN per i tipi di estensione 1 e 2. In un?implementazione di questa seconda opzione, la configurazione di formazione di fascio memorizzata in corrispondenza della RU associata usando il beamID specificato viene aggiornata con i pesi e/o attributi di formazione di fascio che sono convogliati con il beamID. [0032] In a second option to specify how each RU that ? marked in the mask field of RU 608 is used to perform beamforming for the section data described in the associated C-plan message (and communicated in one or more U-plan messages associated with this C-plan message), is used a variant of the first option shown in Figure 6. In this second option, beam weights and/or beam attributes can be piped together with beamID 610 in the same way as described in the O-RAN fronthaul specification for beam types extension 1 and 2. In an implementation of this second option, the beamforming configuration stored at the associated RU using the specified beamID is updated with the beamforming weights and/or attributes that are conveyed with the beamID.

[0033] Una terza opzione per specificare come ciascuna RU che ? contrassegnata nel campo di maschera di RU 608 deve eseguire la formazione di fascio per i dati di sezione descritti nel messaggio di piano C associato (e comunicati nell?uno o pi? messaggi di piano U associati a tale messaggio di piano C) viene mostrata nella Figura 7. Con questa terza opzione, un beamID differente pu? essere specificato per differenti sottoserie dei PRB inclusi nei dati di sezione descritti nel messaggio di piano C associato. Ciascuna differente sottoserie di PRB ha una ?sezione di beamID? corrispondente che include un campo 612 che specifica il numero di PRB inclusi in tale sottoserie e un campo beamID 614 che specifica il beamID da usare per i PRB inclusi in tale sottoserie. Il campo 612 ? anche ivi indicato come campo NumPRBs 612. Le varie sezioni di beamID sono precedute da un campo 616 che specifica il numero di sezioni di beamID che sono specificate per la RU associata. Il campo 616 ? anche ivi indicato come campo nBeamSections 616. [0033] A third option to specify how each RU which ? tagged in the mask field of RU 608 must perform beamforming for the section data described in the associated C-plan message (and communicated in one or more U-plan messages associated with that C-plan message) is shown in the Figure 7. With this third option, a different beamID can? be specified for different subsets of the PRBs included in the section data described in the associated plan C message. Each different PRB subset has a ?beamID section? which includes a 612 field specifying the number of PRBs included in that subset and a 614 beamID field specifying the beamID to use for the PRBs included in that subset. Field 612 ? also referred to therein as NumPRBs field 612. The various beamID sections are preceded by a field 616 which specifies the number of beamID sections that are specified for the associated RU. Field 616? also referred to there as nBeamSections field 616.

[0034] Come mostrato nella Figura 7, per ciascuna RU contrassegnata nel campo di maschera di RU 608 (che usa lo stesso ordine usato nel campo di maschera di RU 608), ? incluso un campo nBeamSections 616 corrispondente seguito dalla serie di sezioni di ID di fascio per tale RU. Le sezioni di beamID sono presentate nello stesso ordine specificato dall?intestazione di sezione 512, in cui i PRB sono contati partendo dal PRB specificato nel campo startPrbc 518 dell?intestazione di sezione 512 e contati in blocchi contigui fino al numero di PRB specificato nel campo NumPRBs 612. La somma del numero di PRB specificato nei campi NumPRBs 612 per tutte le sezioni di beamID per una data RU deve equivalere al numero di PRB specificato nel campo numPrbc 520 dell?intestazione di sezione 512 (vale a dire che la somma deve equivalere a numPRBc). [0034] As shown in Figure 7 , for each RU marked in the mask field of RU 608 (which uses the same order used in the mask field of RU 608), ? including a corresponding nBeamSections 616 field followed by the section set of beam IDs for that RU. Sections of beamID are presented in the same order specified by section header 512, where PRBs are counted starting from the PRB specified in the startPrbc field 518 of section header 512 and counted in contiguous blocks up to the number of PRBs specified in the field NumPRBs 612. The sum of the number of PRBs specified in the NumPRBs 612 fields for all beamID sections for a given RU must equal the number of PRBs specified in the numPrbc field 520 of the section header 512 (i.e. the sum must equal to numPRBc).

[0035] In una quarta opzione per specificare come ciascuna RU che ? contrassegnata nel campo di maschera di RU 608 serve ad effettuare la formazione di fascio per i dati di sezione descritti nel messaggio di piano C associato (e comunicati nell?uno o pi? messaggi di piano U associati a tale messaggio di piano C), viene usata una variante della terza opzione mostrata nella Figura 7. In questa quarta opzione, i pesi di fascio e/o gli attributi di fascio possono essere convogliati insieme al beamID 614 in ciascuna sezione di beamID. I pesi di fascio e/o gli attributi di fascio possono essere convogliati (dopo il corrispondente beamID 614) nello stesso modo descritto nella specifica di fronthaul di O-RAN per i tipi di estensione 1 e 2. In un?implementazione di questa quarta opzione, la configurazione di formazione di fascio memorizzata in corrispondenza della RU associata usando il beamID specificato viene aggiornata con i pesi e/o attributi di formazione di fascio che sono convogliati con il beamID. [0035] In a fourth option to specify how each RU which ? marked in the mask field of RU 608 is used to perform beamforming for the section data described in the associated C-plan message (and communicated in one or more U-plan messages associated with this C-plan message), is A variant of the third option shown in Figure 7 is used. In this fourth option, beam weights and/or beam attributes can be piped together with beamID 614 in each beamID section. Beam weights and/or beam attributes can be piped (after the corresponding beamID 614) in the same way as described in the O-RAN fronthaul specification for extension types 1 and 2. In an implementation of this fourth option , the beamforming configuration stored at the associated RU using the specified beamID is updated with the beamforming weights and/or attributes that are conveyed with the beamID.

[0036] Come indicato sopra, laddove la nuova estensione di sezione 600 viene usata per specificare la formazione di fascio da effettuare su una base per RU, il campo beamID generale 524 descritto sopra viene ignorato. [0036] As noted above, where the new section extension 600 is used to specify the beamforming to be performed on a per RU basis, the general beamID field 524 described above is ignored.

[0037] Un problema con la nuova estensione di sezione 600 descritta sopra in relazione alle Figure 5-7 consiste nel fatto che il campo di maschera di RU 608 ? incluso all?interno della nuova estensione di sezione 600 che ? comunicata soltanto nei messaggi di piano C. Ne risulta che la determinazione in merito al fatto che un messaggio di piano U 502 debba o meno essere usato o scartato da una particolare RU (o inoltrato a una particolare RU) richiede che il messaggio di piano C corrispondente (e la nuova estensione di sezione 600 inclusa al suo interno) sia decodificato e analizzato, che sia effettuata una determinazione in merito al fatto che il campo di maschera di RU 608 incluso nella nuova estensione di sezione 600 indichi o meno che i messaggi di piano U corrispondenti devono essere usati o scartati (o inoltrati), e che le informazioni riguardanti tale determinazione e il SectionID corrispondente siano tracciate per un uso successivo quando i messaggi di piano U corrispondenti vengono ricevuti. Questa decodifica, questa analisi e questo tracciamento di ciascun tale messaggio di piano C devono essere effettuati anche se il messaggio di piano C e i messaggi di piano U associati non sono destinati alla RU in questione. Una forma di realizzazione alternativa della nuova estensione di sezione che affronta questo problema viene descritta di seguito in relazione alle Figure 8-10. [0037] A problem with the new section extension 600 described above in relation to Figures 5-7 consists in the fact that the mask field of RU 608 ? included within the new extension of section 600 which ? communicated only in plan C messages. As a result, the determination whether or not a plan U 502 message should be used or discarded by a particular RU (or forwarded to a particular RU) requires that the plan C message correspondent (and the new section extension 600 included therein) is decoded and parsed, that a determination is made as to whether or not the mask field of RU 608 included in the new section extension 600 indicates that corresponding plan U are to be used or discarded (or forwarded), and that information regarding that determination and the corresponding SectionID is tracked for later use when corresponding plan U messages are received. This decoding, parsing and tracing of each such plan C message must be performed even if the plan C message and associated plan U messages are not destined for the RU in question. An alternative embodiment of the new section extension that addresses this problem is described below in relation to Figures 8-10 .

[0038] La Figura 8 illustra un esempio di un messaggio di piano C 800 per una sezione di dati utente che ? frammentata in uno o pi? messaggi di piano U 802 (di cui uno soltanto viene illustrato nella Figura 8). In generale, ad eccezione di come descritto di seguito, i messaggi di piano C 800 e i messaggi di piano U 802 sono rispettivamente identici ai messaggi di piano C 500 e ai messaggi di piano U 502 mostrati nella Figura 5, la cui descrizione non viene generalmente ripetuta per motivi di concisione. [0038] Figure 8 illustrates an example of a C-plan 800 message for a user data section which ? fragmented into one or more floor messages U 802 (only one of which is shown in Figure 8). In general, except as described below, the 800 C-plan messages and 802 U-plan messages are respectively identical to the 500 C-plan messages and 502 U-plan messages shown in Figure 5 , the description of which is not generally given. repeated for the sake of conciseness.

[0039] Nell?esempio mostrato nella Figura 8, un campo di maschera di RU 808 ? incluso nei campi di intestazione comune 810 che sono comunicati nei dati di strato applicativo del messaggio di piano C 800 e dei messaggi di piano U 802. Il campo di maschera di RU 808 si applica a tutte le sezioni incluse nei dati di strato applicativo (ciascuna sezione essendo definita da una serie corrispondente di campi di sezione 512). [0039] In the example shown in Figure 8, a mask field of RU 808 ? included in the common header fields 810 which are communicated in the application layer data of the C-plan message 800 and U-plan messages 802. The mask field of RU 808 applies to all sections included in the application layer data (each section being defined by a corresponding set of section fields 512).

[0040] Pi? specificatamente, come mostrato nella Figura 8, una nuova versione di carico utile ? definita e usata per comunicare il campo di maschera di RU 808 nei campi di intestazione comune 810 dei dati di strato applicativo. Per esempio, come mostrato nella Figura 8, a questa nuova versione di carico utile pu? essere assegnato il numero 2. La versione di carico utile appena definita viene memorizzata nel campo di versione di carico utile (payloadVer) 840 dei campi di intestazione comune 810 e il campo di maschera di RU 808 ? incluso nei campi di intestazione comune 810 tra il campo di indice di filtro 842 e il campo di identificatore di frame 844. In questo esempio, poich? ? incluso nei campi di intestazione comune 810 dei dati di strato applicativo, il campo di maschera di RU 808 non ? incluso nella nuova estensione di sezione 600 (come mostrato nelle Figure 9-10). Occorre comprendere che si tratta di un esempio di come il campo di maschera di RU 808 pu? essere incluso nei campi di intestazione comune 810 dei dati di strato applicativo e che ci? pu? essere effettuato in altri modi (per esempio, la nuova estensione di sezione 600 pu? anche includere un campo di maschera di RU 608 in cui ? anche memorizzata la stessa maschera di RU memorizzata nel campo di maschera di RU 808 dei campi di intestazione comune 810). [0040] More specifically, as shown in Figure 8, a new payload version ? defined and used to communicate the mask field of RU 808 in the common header fields 810 of the application layer data. For example, as shown in Figure 8, this new payload version can be assigned the number 2. The newly defined payload version is stored in the payload version (payloadVer) field 840 of the common header fields 810 and the mask field of RU 808 ? included in the common header fields 810 between the filter index field 842 and the frame identifier field 844. In this example, since? ? included in the common header fields 810 of the application layer data, the mask field of RU 808 is not ? included in the new section extension 600 (as shown in Figures 9-10). It should be understood that this is an example of how the mask field of RU 808 can? be included in the common header fields 810 of the application layer data and that there? can? be done in other ways (for example, the new section extension 600 may also include a RU mask field 608 in which the same RU mask stored in the RU mask field 808 of the common header fields 810 is also stored ).

[0041] La maschera di RU memorizzata nel campo di maschera di RU 808 stesso ? formattata (e usata) come la maschera di RU memorizzata nel campo di maschera di RU 608 descritto sopra in relazione alle Figure 5-7. [0041] The RU mask stored in the RU mask field 808 itself? formatted (and used) as the RU mask stored in the RU mask field 608 described above in relation to Figures 5-7 .

[0042] Come indicato sopra, a differenza dell?esempio descritto sopra in relazione alle Figure 5-7, lo stesso campo di maschera di RU 808 ? incluso nel messaggio di piano C 800 e nei messaggi di piano U 802 corrispondenti. Ne risulta che la determinazione in merito al fatto che una particolare RU debba o meno usare o scartare un messaggio di piano C 800 o un messaggio di piano U 802 (o avere il messaggio 800 o 802 inoltrato a una particolare RU) richiede soltanto che i campi di intestazione comune 810 di tale particolare messaggio 800 o 802 siano decodificati e che la maschera di RU memorizzata nel campo di maschera di RU 808 incluso al suo interno sia verificata, il che pu? rivelarsi pi? semplice da implementare rispetto all?approccio descritto sopra in relazione alle Figure 5-7. [0042] As indicated above, unlike the example described above in relation to Figures 5-7, the same mask field of RU 808 ? included in floor message C 800 and corresponding floor messages U 802. As a result, a determination as to whether or not a particular RU should use or discard a plan C 800 or plan U 802 message (or have the 800 or 802 message forwarded to a particular RU) requires only that the common 810 header fields of that particular 800 or 802 message are decoded and that the RU mask stored in the 808 RU mask field included therein is verified, which may turn out to be more simpler to implement than the approach described above in relation to Figures 5-7.

[0043] La Figura 11 comprende un diagramma di flusso di livello elevato che illustra una forma di realizzazione esemplificativa di un metodo 1100 per generare e trasmettere messaggi di piano C e piano U che includono la nuova estensione di sezione descritta sopra. Figure 11 comprises a high level flowchart illustrating an exemplary embodiment of a method 1100 for generating and transmitting plane C and plane U messages including the new section extension described above.

[0044] La forma di realizzazione del metodo 1100 mostrato nella Figura 11 ? ivi descritta come implementata in un sistema O-RAN del tipo descritto sopra in cui una DU ? accoppiata a molteplici RU per servire una singola cella (sebbene occorra comprendere che altre forme di realizzazione possono essere implementate in altri modi). Pi? specificatamente, l?elaborazione del metodo 1100 ? ivi descritta come effettuata dalla DU. [0044] The embodiment of method 1100 shown in Figure 11 ? described therein as implemented in an O-RAN system of the type described above in which a DU ? coupled to multiple RUs to serve a single cell (although it should be understood that other embodiments may be implemented in other ways). Pi? specifically, the elaboration of the method 1100 ? described therein as performed by the DU.

[0045] I blocchi del diagramma di flusso mostrato nella Figura 11 sono stati disposti in modo generalmente sequenziale per facilitare la spiegazione; tuttavia, occorre comprendere che questa disposizione ? soltanto esemplificativa, e occorre riconoscere che l?elaborazione associata al metodo 1100 (e ai blocchi mostrati nella Figura 11) pu? avvenire in un ordine differente (per esempio, in cui almeno parte dell?elaborazione associata ai blocchi viene effettuata in parallelo e/o in un modo guidato dagli eventi). Inoltre, per facilitare la spiegazione, la maggior parte della gestione di eccezioni standard non viene descritta; tuttavia, occorre comprendere che il metodo 1100 pu? includere e tipicamente include tale gestione delle eccezioni. [0045] The blocks of the flowchart shown in Figure 11 have been arranged generally sequentially for ease of explanation; however, it must be understood that this provision ? only exemplary, and it must be recognized that the processing associated with the method 1100 (and with the blocks shown in Figure 11) can? occur in a different order (for example, where at least some of the processing associated with the blocks is done in parallel and/or in an event-driven manner). Also, for ease of explanation, most of the standard exception handling is not described; however, it must be understood that the 1100 method pu? include and typically includes such exception handling.

[0046] Il metodo 1100 comprende determinare, per ciascuno slot, l?allocazione di PRB a differenti UE (blocco 1102) e la corrispondente allocazione di una sottoserie di RU da cui gli UE riceveranno trasmissioni senza fili dei PRB allocati (blocco 1104). In una forma di realizzazione esemplificativa, queste determinazioni sono effettuate dal pianificatore di controllo di accesso ai mezzi (MAC) implementato nella DU. [0046] The method 1100 comprises determining, for each slot, the allocation of PRBs to different UEs (block 1102) and the corresponding allocation of a subset of RUs from which the UEs will receive wireless transmissions of the allocated PRBs (block 1104). In an exemplary embodiment, these determinations are made by the media access control (MAC) planner implemented in the DU.

[0047] Il metodo 1100 comprende inoltre generare, per tale slot, messaggi di piano C e piano U per ciascun UE che ha allocato i PRB durante tale slot (blocco 1106). In una forma di realizzazione esemplificativa, questa funzione viene implementata nella DU. Come parte di ci?, la DU determina come raggruppare i dati in modo efficiente al fine di ridurre la duplicazione dei dati comunicati sul fronthaul e ridurre il numero di pacchetti usati per comunicare i messaggi di piano C e piano U. La nuova estensione di sezione 600 descritta sopra viene usata a tale scopo. Pi? specificatamente, il campo di maschera di RU 608 incluso nella nuova estensione di sezione 600 del messaggio di piano C 500 descritto sopra in relazione alle Figure 5-7 o il campo di maschera di RU 808 incluso nei campi di intestazione comune 810 sia dei messaggi di piano C 800, sia dei messaggi di piano U 802 descritti sopra in relazione alle Figure 8-10 viene usato per identificare ciascuna RU a cui sono destinati i dati di sezione associati. [0047] The method 1100 further comprises generating, for this slot, C-plan and U-plan messages for each UE that has allocated the PRBs during this slot (block 1106). In an exemplary embodiment, this function is implemented in the DU. As part of this, the DU determines how to group the data efficiently in order to reduce duplication of data communicated on fronthaul and reduce the number of packets used to communicate plan C and plan U messages. The new section extension 600 described above is used for this purpose. Pi? specifically, the RU mask field 608 included in the new section extension 600 of the C plan message 500 described above in connection with Figures 5-7 or the RU mask field 808 included in the common header fields 810 of both the C plan 800, and U plan messages 802 described above in connection with Figures 8-10 is used to identify each RU to which the associated section data is intended.

[0048] Il metodo 1100 comprende inoltre trasmettere i messaggi di piano C e piano U generati per tale slot (blocco 1108). In una forma di realizzazione, la DU radiotrasmette i messaggi di piano C e piano U a tutte le RU, nel qual caso le RU determinano se i messaggi sono destinati ad esse usando il campo di maschera di RU 608 incluso nella nuova estensione di sezione 600 del messaggio di piano C 500 descritto sopra in relazione alle figure 5-7 come descritto di seguito in relazione alla Figura 12A o il campo di maschera di RU 808 incluso nei campi di intestazione comune 810 sia dei messaggi di piano C 800, sia dei messaggi di piano U 802 descritti sopra in relazione alle Figure 8-10 come descritto di seguito in relazione alla Figura 12B. In una forma di realizzazione alternativa, la DU trasmette in modo ristretto ciascuno dei messaggi di piano C e piano U a una sottoserie delle RU. In tale forma di realizzazione alternativa, ciascuna tale sottoserie di RU ? associata a un rispettivo gruppo multicast e la DU ? configurata per selezionare un gruppo multicast (e la sottoserie di RU associata) che include tutte le RU a cui ? destinato il messaggio includendo anche al contempo il numero pi? basso di altre RU alle quali il messaggio non ? destinato. Se non esiste alcun gruppo multicast idoneo (e una sottoserie di RU associata), il messaggio pu? essere radiotrasmesso a tutte le RU. [0048] The method 1100 further comprises transmitting the C-plan and U-plan messages generated for that slot (block 1108). In one embodiment, the DU broadcasts plan C and plan U messages to all RUs, in which case the RUs determine whether the messages are intended for them using the RU mask field 608 included in the new section extension 600 of the C-plan message 500 described above in relation to Figs. 5-7 as described below in relation to Fig. 12A or the RU mask field 808 included in the common header fields 810 of both the C-plan messages 800, and the plan U 802 described above in relation to Figures 8-10 as described below in relation to Figure 12B . In an alternative embodiment, the DU narrowly transmits each of the C-plan and U-plan messages to a subset of the RUs. In this alternative embodiment, each such subset of RU ? associated with a respective multicast group and the DU ? configured to select a multicast group (and associated RU subset) that includes all RUs to which ? intended for the message also including at the same time the number pi? low of other RUs to which the message is not ? intended. If no suitable multicast group (and associated subset of RUs) exists, the message may be broadcast to all UK.

[0049] I messaggi di piano C e piano U possono essere generati e trasmessi in una modalit? disaggregata in cui ciascun messaggio di piano C e piano U convoglia soltanto una singola nuova estensione di sezione (con un singolo campo di maschera di RU 608 o 808). I messaggi di piano C e piano U possono essere formattati e comunicati in una modalit? raggruppata usando l?approccio descritto sopra in relazione alle Figure 5-7. Con tale modalit? raggruppata, ciascun piano C convoglia molteplici descrizioni di dati di sezione (definite da molteplici serie di campi di sezione 512) e molteplici nuove estensioni di sezione 600 (aventi ciascuna una differente maschera di RU 608). Nella modalit? raggruppata, anche i corrispondenti messaggi di piano U possono convogliare molteplici descrizioni di dati di sezione (definite da molteplici serie di campi di sezione 512) e molteplici nuove estensioni di sezione 600 (aventi ciascuna una differente maschera di RU 608). Ciascuna descrizione di dati di sezione (definita da una serie di campi di sezione 512 corrispondente) e ciascuna nuova estensione di sezione 600 sono elaborate separatamente come descritto sopra. Si noti che questa modalit? raggruppata viola l?ipotesi corrente espressa nella O-RAN secondo cui non vi sono serie in conflitto di dati RE per lo stesso PRB all?interno dello stesso messaggio di piano U. [0049] The messages of plan C and plan U can be generated and transmitted in a mode? disaggregated in which each plan C and plan U message carries only a single new section extension (with a single mask field of RU 608 or 808). Can Plan C and Plan U messages be formatted and communicated in one way? grouped using the approach described above in relation to Figures 5-7. With this mode? grouped, each plane C carries multiple section data descriptions (defined by multiple sets of section fields 512) and multiple new section extensions 600 (each having a different RU mask 608). In the mode grouped, the corresponding U-plan messages may also carry multiple section data descriptions (defined by multiple sets of section fields 512) and multiple new section extensions 600 (each having a different RU mask 608). Each section data description (defined by a corresponding set of section fields 512) and each new section extension 600 are processed separately as described above. Note that this mode grouped violates the current assumption expressed in the O-RAN that there are no conflicting sets of RE data for the same PRB within the same U plan message.

[0050] La Figura 12A comprende un diagramma di flusso di livello elevato che illustra una forma di realizzazione esemplificativa di un metodo 1200 per ricevere ed elaborare messaggi di piano C e piano U di collegamento discendente che includono nuove estensioni di sezione. La forma di realizzazione del metodo 1200 mostrato nella Figura 12A ? idonea per l?uso con l?approccio descritto in relazione alle Figure 5-7. Figure 12A includes a high level flowchart illustrating an exemplary embodiment of a method 1200 for receiving and processing downlink plane C and plane U messages that include new section extensions. The embodiment of method 1200 shown in Figure 12A ? suitable for use with the approach described in relation to Figures 5-7.

[0051] La forma di realizzazione del metodo 1200 mostrato nella Figura 12A ? ivi descritta come implementata in un sistema O-RAN del tipo descritto sopra in cui una DU ? accoppiata a molteplici RU per servire una singola cella (sebbene occorra comprendere che altre forme di realizzazione possono essere implementate in altri modi). Pi? specificatamente, l?elaborazione del metodo 1200 ? ivi descritta come effettuata da ciascuna RU. [0051] The embodiment of method 1200 shown in Figure 12A ? described therein as implemented in an O-RAN system of the type described above in which a DU ? coupled to multiple RUs to serve a single cell (although it should be understood that other embodiments may be implemented in other ways). Pi? specifically, the elaboration of the method 1200 ? described therein as performed by each RU.

[0052] I blocchi del diagramma di flusso mostrato nella Figura 12A sono stati disposti in modo generalmente sequenziale per facilitare la spiegazione; tuttavia, occorre comprendere che questa disposizione ? soltanto esemplificativa, e occorre riconoscere che l?elaborazione associata al metodo 1200 (e ai blocchi mostrati nella Figura 12A) pu? avvenire in un ordine differente (per esempio, in cui almeno parte dell?elaborazione associata ai blocchi viene effettuata in parallelo e/o in un modo guidato dagli eventi). Inoltre, per facilitare la spiegazione, la maggior parte della gestione di eccezioni standard non viene descritta; tuttavia, occorre comprendere che il metodo 1200 pu? includere e tipicamente include tale gestione delle eccezioni. [0052] The blocks of the flowchart shown in Figure 12A have been arranged generally sequentially for ease of explanation; however, it must be understood that this provision ? only exemplary, and it must be recognized that the processing associated with the method 1200 (and with the blocks shown in Figure 12A) can? occur in a different order (for example, where at least some of the processing associated with the blocks is done in parallel and/or in an event-driven manner). Also, for ease of explanation, most of the standard exception handling is not described; however, it must be understood that the 1200 method pu? include and typically includes such exception handling.

[0053] Il metodo 1200 viene effettuato da ciascuna RU per ciascun messaggio di piano C di collegamento discendente che viene radiotrasmesso dalla DU per ciascuno slot che include una nuova estensione di sezione 600 usando l?approccio descritto sopra in relazione alle Figure 5-7. Method 1200 is performed by each RU for each downlink plan C message that is broadcast by the DU for each slot including a new section extension 600 using the approach described above in relation to Figures 5-7 .

[0054] Nella seguente descrizione, la particolare RU, il messaggio di piano C di collegamento discendente e la nuova estensione di sezione 600 a cui ? correlato il metodo 1200 descritto di seguito vengono ivi denominati rispettivamente RU ?corrente?, messaggio di piano C di collegamento discendente ?corrente? e nuova estensione di sezione 600 ?corrente?. [0054] In the following description, the particular RU, the downlink plan C message and the new section extension 600 to which ? related method 1200 described below are referred to therein respectively as RU ?current?, downlink plan C message ?current? and new extension of section 600 ?current?.

[0055] Il metodo 1200 comprende identificare la maschera di RU memorizzata nel campo di maschera di RU 608 e il SectionID memorizzato nel campo SectionID 516 della nuova estensione di sezione 600 corrente (blocco 1202). Vale a dire che la RU corrente riceve e decodifica il messaggio di piano C corrente e lo analizza al fine di identificare la maschera di RU memorizzata nel campo di maschera di RU 608 e il SectionID memorizzato nel campo SectionID 516 della nuova estensione di sezione 600 corrente. [0055] Method 1200 comprises identifying the RU mask stored in the RU mask field 608 and the SectionID stored in the SectionID field 516 of the current new section extension 600 (block 1202). That is, the current RU receives and decodes the current C-plan message and parses it in order to identify the RU mask stored in the RU mask field 608 and the SectionID stored in the SectionID field 516 of the current new section extension 600 .

[0056] Il metodo 1200 comprende inoltre determinare se la maschera di RU indica che la nuova estensione di sezione 600 corrente e il messaggio di piano C corrente sono destinati alla RU corrente (blocco 1204). Pi? specificatamente, la posizione di bit nella maschera di RU che corrisponde alla RU corrente viene verificata per vedere se include il valore di bit che indica che la nuova estensione di sezione corrente e il messaggio di piano C corrente sono destinati alla RU corrente (per esempio, un valore di ?1?) o se include il valore di bit che indica che la nuova estensione di sezione corrente e il messaggio di piano C corrente non sono destinati alla RU corrente (per esempio, un valore di ?0?). [0056] The method 1200 further comprises determining whether the RU mask indicates that the current new section extension 600 and the current plan C message are destined for the current RU (block 1204). Pi? Specifically, the bit position in the RU mask that corresponds to the current RU is checked to see if it includes the bit value that indicates that the current new section extension and the current plan C message are intended for the current RU (for example, a value of ?1?) or if it includes the bit value indicating that the current new section extent and the current plan C message are not intended for the current RU (for example, a value of ?0?).

[0057] Se la maschera di RU indica che la nuova estensione di sezione 600 corrente e il messaggio di piano C corrente sono destinati alla RU corrente, la RU corrente usa il messaggio di piano C corrente per l?elaborazione di piano C effettuata per tale slot temporale (blocco 1206), identifica i messaggi di piano U che corrispondono alla nuova estensione di sezione corrente 600 (e al messaggio di piano C corrente) usando il SectionID per la nuova estensione di sezione 600 corrente (blocco 1208), e usa i messaggi di piano U corrispondenti per l?elaborazione di piano U effettuata per tale slot temporale (blocco 1210). [0057] If the RU mask indicates that the current new section extension 600 and the current plan C message are intended for the current RU, the current RU uses the current plan C message for the plan C processing performed for that time slot (block 1206), identify the U-plan messages that match the current new section extent 600 (and the current C plan message) using the SectionID for the current new 600 section extent (block 1208), and use the corresponding U-plan messages for U-plan processing carried out for that time slot (block 1210).

[0058] La Figura 12B comprende un diagramma di flusso di livello elevato che illustra una forma di realizzazione esemplificativa di un metodo 1250 per ricevere ed elaborare messaggi di piano C e piano U di collegamento discendente che includono nuove estensioni di sezione. La forma di realizzazione del metodo 1250 mostrato nella Figura 12B ? idonea per l?uso con l?approccio descritto in relazione alle Figure 8-10. Figure 12B includes a high level flowchart illustrating an exemplary embodiment of a method 1250 for receiving and processing plane C and plane U downlink messages that include new section extensions. The method 1250 embodiment shown in Figure 12B ? suitable for use with the approach described in relation to Figures 8-10.

[0059] La forma di realizzazione del metodo 1250 mostrato nella Figura 12B ? ivi descritta come implementata in un sistema O-RAN del tipo descritto sopra in cui una DU ? accoppiata B molteplici RU per servire una singola cella (sebbene occorra comprendere che altre forme di realizzazione possono essere implementate in altri modi). Pi? specificatamente, l?elaborazione del metodo 1250 ? ivi descritta come effettuata da ciascuna RU. [0059] The embodiment of method 1250 shown in Figure 12B ? described therein as implemented in an O-RAN system of the type described above in which a DU ? coupled B multiple RUs to serve a single cell (although it should be understood that other embodiments may be implemented in other ways). Pi? specifically, the elaboration of the method 1250 ? described therein as performed by each RU.

[0060] I blocchi del diagramma di flusso mostrato nella Figura 12B sono stati disposti in modo generalmente sequenziale per facilitare la spiegazione; tuttavia, occorre comprendere che questa disposizione ? soltanto esemplificativa, e occorre riconoscere che l?elaborazione associata al metodo 1250 (e ai blocchi mostrati nella Figura 12B) pu? avvenire in un ordine differente (per esempio, in cui almeno parte dell?elaborazione associata ai blocchi viene effettuata in parallelo e/o in un modo guidato dagli eventi). Inoltre, per facilitare la spiegazione, la maggior parte della gestione di eccezioni standard non viene descritta; tuttavia, occorre comprendere che il metodo 1250 pu? includere e tipicamente include tale gestione delle eccezioni. [0060] The blocks of the flowchart shown in Figure 12B have been arranged generally sequentially for ease of explanation; however, it must be understood that this provision ? only exemplary, and it must be recognized that the processing associated with method 1250 (and with the blocks shown in Figure 12B) can? occur in a different order (for example, where at least some of the processing associated with the blocks is done in parallel and/or in an event-driven manner). Also, for ease of explanation, most of the standard exception handling is not described; however, it must be understood that the 1250 method pu? include and typically includes such exception handling.

[0061] Il metodo 1250 viene effettuato da ciascuna RU per ciascun messaggio di piano C o piano U di collegamento discendente che viene radiotrasmesso dalla DU per ciascuno slot che include una nuova estensione di sezione 600 usando l?approccio descritto sopra in relazione alle Figure 8-10. Method 1250 is performed by each RU for each downlink plan C or plan U message that is broadcast by the DU for each slot that includes a new section extension 600 using the approach described above in relation to Figures 8 -10.

[0062] Nella seguente descrizione, la particolare RU e il messaggio di piano C o piano U di collegamento discendente a cui ? correlato il metodo 1250 descritto di seguito vengono ivi denominati rispettivamente RU ?corrente? e messaggio di piano C o piano U di collegamento discendente ?corrente?. [0062] In the following description, the particular RU and the downlink plan C or plan U message to which ? related method 1250 described below are referred to here respectively as RU ?current? and ?current? downlink plan C or plan U message.

[0063] Il metodo 1250 comprende identificare la maschera di RU memorizzata nei campi di intestazione comune 810 del messaggio corrente (blocco 1252). Vale a dire che la RU corrente riceve e decodifica il messaggio di piano C o piano U corrente e analizza i campi di intestazione comune 810 al fine di confermare che la versione di carico utile memorizzata nel campo di versione di carico utile 840 ? appropriata e al fine di identificare la maschera di RU memorizzata nel campo di maschera di RU 808. [0063] The method 1250 comprises identifying the RU mask stored in the common header fields 810 of the current message (block 1252). That is, the current RU receives and decodes the current plan C or plan U message and parses the common header fields 810 in order to confirm that the payload version stored in the payload version field 840 ? and in order to identify the RU mask stored in the RU mask field 808.

[0064] Il metodo 1250 comprende inoltre determinare se la maschera di RU indica che il messaggio di piano C o piano U corrente e tutte le nuove estensioni di sezione 600 incluse nel messaggio di piano C o piano U corrente sono destinati alla RU corrente (blocco 1254). Pi? specificatamente, la posizione di bit nella maschera di RU che corrisponde alla RU corrente viene verificata per vedere se include il valore di bit che indica che il messaggio di piano C o piano U corrente e tutte le nuove estensioni di sezione 600 incluse nel messaggio di piano C o piano U corrente sono destinati alla RU corrente (per esempio, un valore di ?1?) o se include il valore di bit che indica che il messaggio di piano C o piano U corrente e tutte le nuove estensioni di sezione 600 incluse nel messaggio di piano C o piano U corrente non sono destinati alla RU corrente (per esempio, un valore di ?0?). The method 1250 further comprises determining whether the RU mask indicates that the current plan C or plan U message and all new section extensions 600 included in the current plan C or plan U message are destined for the current RU (block 1254). Pi? Specifically, the bit position in the RU mask that corresponds to the current RU is checked to see if it includes the bit value that indicates that the current plan C or plan U message and any new section extensions 600 included in the plan message current C or plan U are intended for the current RU (for example, a value of ?1?) or if it includes the bit value indicating that the current plan C or plan U message and all new section 600 extensions included in the current plan C or plan U message is not intended for the current RU (for example, a value of ?0?).

[0065] Se la maschera di RU indica che il messaggio di piano C o piano U corrente e tutte le nuove estensioni di sezione 600 incluse nel messaggio di piano C o piano U corrente sono destinati alla RU corrente, la RU corrente usa il messaggio di piano C o piano U corrente per l?elaborazione effettuata per tale slot temporale (blocco 1256). Diversamente, se la maschera di RU indica che il messaggio di piano C o piano U corrente e tutte le nuove estensioni di sezione 600 incluse nel messaggio di piano C o piano U corrente non sono destinati alla RU corrente, la RU corrente scarta il messaggio di piano C o piano U corrente e non lo usa per l?elaborazione effettuata per tale slot temporale (blocco 1258). [0065] If the RU mask indicates that the current plan C or plan U message and all new section extensions 600 included in the current plan C or plan U message are destined for the current RU, the current RU uses the current plan C or plan U for the processing performed for that time slot (block 1256). Otherwise, if the RU mask indicates that the current plan C or plan U message and all new section extensions 600 included in the current plan C or plan U message are not destined for the current RU, the current RU discards the RU mask. current plan C or plan U and does not use it for the processing performed for that time slot (block 1258).

[0066] La nuova estensione di sezione 600 e i metodi 1100, 1200 e 1250 delle Figure 11, 12A e 12B possono essere usati per inviare differenti serie di dati a differenti RU (per supportare la trasmissione senza fili da esse). Ci? pu? essere usato per consentire il riuso di frequenza in una RAN in cui una DU ? accoppiata a molteplici RU per servire una singola cella. Anche quando il riuso di frequenza non viene usato in tale RAN multi-RU, la nuova estensione di sezione 600 e i metodi 1100, 1200 e 1250 delle Figure 11, 12A e 12B possono essere usati per la trasmissione senza fili a un UE usando un numero inferiore di RU anzich? tutte. Inoltre, occorre comprendere che la nuova estensione di sezione 600 e i metodi 1100, 1200 e 1250 delle Figure 11, 12A e 12B possono anche essere usati per inviare gli stessi dati a tutte le RU. Ci? pu? essere usato per consentire un ?simulcast completo? in tale RAN multi-RU, in cui tutte le RU trasmettono gli stessi dati in modalit? senza fili. The new section extension 600 and methods 1100, 1200 and 1250 of Figures 11 , 12A and 12B can be used to send different data sets to different RUs (to support wireless transmission therefrom). There? can? be used to allow frequency reuse in a RAN where a DU ? coupled to multiple RUs to serve a single cell. Even when frequency reuse is not used in such a multi-RU RAN, the new section extension 600 and methods 1100, 1200 and 1250 of Figures 11 , 12A and 12B can be used for wireless transmission to a UE using a number lower than RU instead? all. Furthermore, it should be understood that the new section extension 600 and methods 1100, 1200 and 1250 of Figures 11 , 12A and 12B can also be used to send the same data to all RUs. There? can? be used to allow a ?full simulcast? in such a multi-RU RAN, where all RUs transmit the same data in mode? wireless.

[0067] La Figura 13 illustra un caso di utilizzo esemplificativo per la nuova estensione di sezione 600 descritta sopra in cui viene usato l?approccio descritto sopra in relazione alle Figure 5-7. Nell?esempio mostrato nella Figura 13, la DU ? accoppiata a quattro RU (RU#1, RU#2, RU#3, e RU#4) per servire una singola cella che ? usata dai due UE (UE#1 e UE#2). [0067] Figure 13 illustrates an exemplary use case for the new section extension 600 described above in which the approach described above in relation to Figures 5-7 is used. In the example shown in Figure 13, the DU ? coupled to four RUs (RU#1, RU#2, RU#3, and RU#4) to serve a single cell that ? used by the two UEs (UE#1 and UE#2).

[0068] In questo esempio, UE#1 viene servito da RU#1 e RU#2, e UE#2 ? servito da RU#3 e RU#4. Per questo motivo, il pianificatore nella DU determina che il riuso di frequenza di collegamento discendente pu? essere usato con UE#1 e UE#2 e che tutti i PRB vengono allocati sia a UE#1 sia a UE#2, in cui i dati di collegamento discendente trasmessi all?UE#1 da RU#1 e RU#2 durante tali PRB riusati differiscono dai dati di collegamento discendente trasmessi all?UE#2 da RU#3 e RU#4 durante tali PRB riusati. [0068] In this example, UE#1 is served by RU#1 and RU#2, and UE#2 ? served by RU#3 and RU#4. For this reason, the planner in the DU determines that downlink frequency reuse can be used with UE#1 and UE#2 and that all PRBs are allocated to both UE#1 and UE#2, where the downlink data transmitted to UE#1 by RU#1 and RU#2 during such reused PRBs differ from the downlink data transmitted to UE#2 by RU#3 and RU#4 during such reused PRBs.

[0069] Usando le tecniche descritte sopra, la DU genera e radiotrasmette due messaggi di piano C di collegamento discendente con la nuova estensione di sezione descritta sopra. Un primo messaggio di piano C di collegamento discendente include un SectionID di #xy1 memorizzato nel campo SectionID 516 e una maschera di RU di ?1100? nel campo di maschera di RU 608 dell?estensione di sezione 600. Il primo messaggio di piano C di collegamento discendente ? destinato a RU#1 e RU#2 (che corrispondono rispettivamente alla prima e alla seconda posizione di bit nella maschera di bit memorizzata nel campo di maschera di RU 608) e viene usato per comunicare con UE#1. Using the techniques described above, the DU generates and broadcasts two downlink plan C messages with the new section extension described above. A first descendant link plan C message includes a SectionID of #xy1 stored in SectionID field 516 and an RU mask of ?1100? in the mask field of RU 608 of the section extension 600. The first downlink plan C message ? intended for RU#1 and RU#2 (which correspond respectively to the first and second bit positions in the bitmask stored in the mask field of RU 608) and is used to communicate with UE#1.

[0070] Il secondo messaggio di piano C di collegamento discendente include un SectionID di #xy2 memorizzato nel campo SectionID 516 e una maschera di RU di ?0011? nel campo di maschera di RU 608 della nuova estensione di sezione 600. Il secondo messaggio di piano C di collegamento discendente ? destinato a RU#3 e RU#4 (che corrispondono rispettivamente alla terza e alla quarta posizione di bit nella maschera di bit memorizzata nel campo di maschera di RU 608) e viene usato per comunicare con UE#2. [0070] The second downlink plan C message includes a SectionID of #xy2 stored in SectionID field 516 and an RU mask of ?0011? in the mask field of RU 608 of the new section extension 600. The second downlink plan C message ? intended for RU#3 and RU#4 (which correspond respectively to the third and fourth bit positions in the bitmask stored in the mask field of RU 608) and is used to communicate with UE#2.

[0071] Usando le tecniche descritte sopra, la DU genera e radiotrasmette due messaggi di piano U di collegamento discendente corrispondenti con la nuova estensione di sezione. Using the techniques described above, the DU generates and broadcasts two corresponding downlink plan U messages with the new section extent.

Un primo messaggio di piano U di collegamento discendente include un SectionID di #xy1 memorizzato nel campo SectionID 516 e dati RE per UE#1. Il secondo messaggio di piano U di collegamento discendente include un SectionID di #xy2 memorizzato nel campo SectionID 516 e dati RE per UE#2. A first downlink floor U message includes a SectionID of #xy1 stored in SectionID field 516 and RE data for UE#1. The second downlink floor U message includes a SectionID of #xy2 stored in SectionID field 516 and RE data for UE#2.

[0072] La DU trasmette entrambi i messaggi di piano C ed entrambi i messaggi di piano U al commutatore, che in seguito radiotrasmette i messaggi a tutte le RU. [0072] The DU transmits both floor C messages and both floor U messages to the switch, which then radios the messages to all RUs.

[0073] Quando ricevono e decodificano il primo messaggio di piano C di collegamento discendente, RU#1 e RU#2 determinano che il primo messaggio di piano C ? destinato ad essi poich? vi ? un valore di ?1? memorizzato nella prima e nella seconda posizione di bit della maschera di RU memorizzata nel campo di maschera di RU 608 (che corrispondono rispettivamente a RU#1 e RU#2). In risposta a tale determinazione, quando ricevono e decodificano il primo messaggio di piano U di collegamento discendente, RU#1 e RU#2 determinano che il SectionID di #xy1 memorizzato nel campo SectionID 516 del primo messaggio di piano U di collegamento discendente corrisponde al SectionID di #xy1 memorizzato nel campo SectionID 516 del primo messaggio di piano C di collegamento discendente e, di conseguenza, usano i dati RE memorizzati nel primo messaggio di piano U come specificato nel primo messaggio di piano C. [0073] When they receive and decode the first downlink plan C message, RU#1 and RU#2 determine that the first plan C message ? intended for them since? there ? a value of ?1? stored in the first and second bit positions of the mask of RU stored in the mask field of RU 608 (corresponding to RU#1 and RU#2, respectively). In response to this determination, when they receive and decode the first downlink plan U message, RU#1 and RU#2 determine that the SectionID of #xy1 stored in SectionID field 516 of the first downlink plan U message matches the SectionID of #xy1 stored in SectionID field 516 of the first downlink plan C message and, therefore, use the RE data stored in the first plan U message as specified in the first plan C message.

[0074] Quando ricevono e decodificano il secondo messaggio di piano C di collegamento discendente, RU#1 e RU#2 determinano che il secondo messaggio di piano C non ? destinato ad essi poich? vi ? un valore di ?0? memorizzato nella prima e nella seconda posizione di bit della maschera di RU memorizzata nel campo di maschera di RU 608 (che corrispondono rispettivamente a RU#1 e RU#2). In risposta a tale determinazione, quando ricevono e decodificano il secondo messaggio di piano U di collegamento discendente, RU#1 e RU#2 determinano che il SectionID di #xy2 memorizzato nel campo SectionID 516 del secondo messaggio di piano U di collegamento discendente corrisponde al SectionID di #xy2 memorizzato nel campo SectionID 516 del secondo messaggio di piano C di collegamento discendente e, di conseguenza, scartano i secondi messaggi di piano C e piano U. [0074] When receiving and decoding the second downlink plan C message, RU#1 and RU#2 determine that the second plan C message is not ? intended for them since? there ? a value of ?0? stored in the first and second bit positions of the mask of RU stored in the mask field of RU 608 (corresponding to RU#1 and RU#2, respectively). In response to this determination, when receiving and decoding the second downlink plan U message, RU#1 and RU#2 determine that the SectionID of #xy2 stored in SectionID field 516 of the second downlink plan U message matches the SectionID of #xy2 stored in SectionID field 516 of the second downlink plan C message and, consequently, discard the second plan C and plan U messages.

[0075] Quando ricevono e decodificano il primo messaggio di piano C di collegamento discendente, RU#3 e RU#4 determinano che il secondo messaggio di piano C non ? destinato ad essi poich? vi ? un valore di ?0? memorizzato nella terza e nella quarta posizione di bit della maschera di RU memorizzata nel campo di maschera di RU 608 (che corrispondono rispettivamente a RU#3 e RU#4). In risposta a tale determinazione, quando ricevono e decodificano il primo messaggio di piano U di collegamento discendente, RU#3 e RU#4 determinano che il SectionID di #xy1 memorizzato nel campo SectionID 516 del primo messaggio di piano U di collegamento discendente corrisponde al SectionID di #xy1 memorizzato nel campo SectionID 516 del primo messaggio di piano C di collegamento discendente e, di conseguenza, scartano i primi messaggi di piano C e piano U. [0075] When receiving and decoding the first downlink plan C message, RU#3 and RU#4 determine that the second plan C message is not ? intended for them since? there ? a value of ?0? stored in the third and fourth bit positions of the mask of RU stored in the mask field of RU 608 (corresponding to RU#3 and RU#4, respectively). In response to this determination, when receiving and decoding the first downlink plan U message, RU#3 and RU#4 determine that the SectionID of #xy1 stored in SectionID field 516 of the first downlink plan U message matches the SectionID of #xy1 stored in the SectionID field 516 of the first downlink plan C message and consequently discard the first plan C and plan U messages.

[0076] Quando ricevono e decodificano il secondo messaggio di piano C di collegamento discendente, RU#3 e RU#4 determinano che il secondo messaggio di piano C ? destinato ad essi poich? vi ? un valore di ?1? memorizzato nella terza e nella quarta posizione di bit della maschera di RU memorizzata nel campo di maschera di RU 608 (che corrispondono rispettivamente a RU#3 e RU#4). In risposta a tale determinazione, quando ricevono e decodificano il secondo messaggio di piano U di collegamento discendente, RU#3 e RU#4 determinano che il SectionID di #xy2 memorizzato nel campo SectionID 516 del secondo messaggio di piano U di collegamento discendente corrisponde al SectionID di #xy2 memorizzato nel campo SectionID 516 del secondo messaggio di piano C di collegamento discendente e, di conseguenza, usano i dati RE memorizzati nel secondo messaggio di piano U come specificato nel secondo messaggio di piano C. [0076] When receiving and decoding the second downlink plan C message, RU#3 and RU#4 determine that the second plan C message ? intended for them since? there ? a value of ?1? stored in the third and fourth bit positions of the mask of RU stored in the mask field of RU 608 (corresponding to RU#3 and RU#4, respectively). In response to this determination, when receiving and decoding the second downlink plan U message, RU#3 and RU#4 determine that the SectionID of #xy2 stored in SectionID field 516 of the second downlink plan U message matches the SectionID of #xy2 stored in SectionID field 516 of the second downlink plan C message and, therefore, use the RE data stored in the second plan U message as specified in the second plan C message.

[0077] La Figura 14 illustra un altro caso di utilizzo esemplificativo per la nuova estensi un altro di sezione 600 descritta sopra in cui viene usato l?approccio descritto sopra in relazione alle Figure 5-7. L?esempio mostrato nella Figura 14 ? analogo al caso di utilizzo mostrato nella Figura 13 tranne per il fatto che vi ? un terzo UE (UE#3) che viene servito da RU#2 e RU#3. Figure 14 illustrates another exemplary use case for the new Estensi Another Section 600 described above where the approach described above in relation to Figures 5-7 is used. The example shown in Figure 14 ? analogous to the use case shown in Figure 13 except that there ? a third EU (EU#3) which is served by RU#2 and RU#3.

[0078] Come con il caso di utilizzo descritto sopra in relazione alla Figura 13, il pianificatore nella DU determina che il riuso di frequenza di collegamento discendente pu? essere usato con UE#1 e UE#2 e che tutti i PRB vengono allocati sia a UE#1 sia a UE#2. Tuttavia, poich? UE#3 viene servito da RU#2 (che ? inclusa nella sottoserie di RU che serve UE#1) e RU#3 (che ? inclusa nella sottoserie di RU che serve UE#2), la DU non pu? posizionare l?UE#3 in riuso con UE#1 o UE#2 e per contro deve effettuare un?allocazione di PRB separata per UE#3. In questo caso di utilizzo, un terzo messaggio di piano C e un terzo messaggio di piano U destinati a RU#2 e RU#3 sono generati e comunicati a tutte le RU. RU#2 e RU#3 determineranno che questi terzi messaggi di piano C e piano U sono destinati ad esse e useranno i dati RE memorizzati nel terzo messaggio di piano U come specificato nel terzo messaggio di piano C per comunicare con UE#3. Analogamente, RU#1 e RU#4 determineranno che questi terzi messaggi di piano C e piano U non sono destinati ad esse e scarteranno i terzi messaggi di piano C e piano U. As with the use case described above in relation to Figure 13 , the planner in the DU determines that downlink frequency reuse can be used with UE#1 and UE#2 and that all PRBs are allocated to both UE#1 and UE#2. However, since EU#3 is served by RU#2 (which is included in the subset of RU serving EU#1) and RU#3 (which is included in the subset of RU serving EU#2), the DU cannot? place UE#3 in reuse with UE#1 or UE#2 and conversely must make a separate PRB allocation for UE#3. In this use case, a third plan C message and a third plan U message destined for RU#2 and RU#3 are generated and communicated to all RUs. RU#2 and RU#3 will determine that these third plan C and plan U messages are intended for them and will use the RE data stored in the third plan U message as specified in the third plan C message to communicate with UE#3. Similarly, RU#1 and RU#4 will determine that these third plan C and plan U messages are not intended for them and will discard the third plan C and plan U messages.

[0079] Come indicato sopra, negli esempi mostrati nelle Figure 13 e 14, viene usato l?approccio descritto sopra in relazione alle Figure 5-7. Con questo approccio, il campo di maschera di RU 608 viene comunicato nell?estensione di sezione 600 del messaggio di piano C, e i messaggi di piano U che corrispondono a tale estensione di sezione 600 vengono determinati in base al SectionID memorizzato nel campo SectionID 516 dei messaggi di piano C e piano U. Tuttavia, se fosse usato l?approccio descritto sopra in relazione alla Figure 8-10, la determinazione in merito al fatto che un particolare messaggio di piano C o piano U ? o meno destinato a ciascuna RU potrebbe essere effettuata in base al campo di maschera di RU 808 incluso nei campi di intestazione comune 810 dei dati di strato applicativo di ciascun messaggio di piano C e messaggio di piano U. [0079] As indicated above, in the examples shown in Figures 13 and 14 , the approach described above in relation to Figures 5-7 is used. With this approach, the RU mask field 608 is communicated in the section extension 600 of the floor C message, and the floor U messages that correspond to this section extension 600 are determined based on the SectionID stored in the SectionID field 516 of the plan C and plan U messages. However, if the approach described above in relation to Figure 8-10 were used, the determination as to whether a particular plan C or plan U message ? or less intended for each RU could be made based on the RU mask field 808 included in the application layer data common header fields 810 of each plan C message and plan U message.

[0080] La Figura 15 ? un diagramma a blocchi che illustra una forma di realizzazione esemplificativa di un sistema di rete di accesso radio (RAN) 1500 in cui possono essere usati la nuova estensione di sezione 600 e i metodi 1100 e 1200 descritti sopra. Il sistema RAN 1500 mostrato nella Figura 15 implementa una stazione base. Il sistema RAN 1500 pu? anche essere ivi denominato ?stazione base? o ?sistema di stazione base?. [0080] Figure 15 ? a block diagram illustrating an exemplary embodiment of a radio access network (RAN) system 1500 in which the new section extension 600 and methods 1100 and 1200 described above can be used. The RAN 1500 system shown in Figure 15 implements a base station. The RAN 1500 system can? also be referred to therein as a ?base station? or ?base station system?.

[0081] Nella forma di realizzazione esemplificativa mostrata nella Figura 15, il sistema 1500 ? implementato almeno in parte usando un?architettura RAN centralizzata o cloud (C-RAN) che impiega, per ciascuna cella (o settore) 1502 servita dal sistema 1500, almeno un?unit? distribuita (DU) 1504 e molteplici unit? remote (RU) 1506. Il sistema 1500 ? anche ivi denominato ?sistema C-RAN? 1500. Ciascuna RU 1506 ? collocata a distanza da ciascuna DU 1504 che la serve. Inoltre, in questa forma di realizzazione esemplificativa, almeno una delle RU 1506 ? collocata a distanza da almeno un?altra RU 1506 che serve tale cella 1502. [0081] In the exemplary embodiment shown in Figure 15 , the system 1500 is implemented at least in part using a centralized RAN or cloud architecture (C-RAN) which employs, for each cell (or sector) 1502 served by system 1500, at least one unit? distributed (DU) 1504 and multiple units? remote (RU) 1506. The 1500 system ? also referred to therein as the ?C-RAN system? 1500. Each RU 1506 ? placed at a distance from each DU 1504 that serves it. Furthermore, in this exemplary embodiment, at least one of the RU 1506 ? located at a distance from at least one other RU 1506 serving this cell 1502.

[0082] Il sistema RAN 1500 pu? essere implementato in conformit? con uno o pi? standard e specifiche pubblici. Per esempio, il sistema RAN 1500 pu? essere implementato usando un?architettura RAN e/o interfacce di fronthaul RAN definite dall?Alleanza O-RAN. In tale esempio di O-RAN, la DU 1504 e le RU 1506 possono essere implementate rispettivamente come unit? distribuite (DU) di O-RAN e unit? remote (RU) di O-RAN secondo le specifiche O-RAN. Pi? specificatamente, la DU 1504 e le RU 1506 sono configurate per usare la specifica di fronthaul ORAN in combinazione con la nuova estensione di sezione 600 e i metodi 1100 e 1200 descritti sopra. [0082] The RAN 1500 system can be implemented in accordance? with one or more public standards and specifications. For example, the RAN 1500 system can? be implemented using a RAN architecture and/or RAN fronthaul interfaces defined by the O-RAN Alliance. In this O-RAN example, can DU 1504 and RU 1506 be implemented as units respectively? distributed (DU) of O-RAN and unit? remote control (RU) of O-RAN according to O-RAN specifications. Pi? Specifically, DU 1504 and RU 1506 are configured to use the ORAN fronthaul specification in combination with the new section extension 600 and methods 1100 and 1200 described above.

[0083] Ciascuna RU 1506 include o ? accoppiata a una o pi? antenne 1508 tramite le quali i segnali RF di collegamento discendente sono irradiati a vari elementi del terminale utente (UE) 1510 e tramite le quali i segnali RF di collegamento ascendente trasmessi dall?UE 1510 vengono ricevuti. [0083] Each RU 1506 includes or ? coupled to one or more antennas 1508 through which the downlink RF signals are radiated to various elements of the user terminal (UE) 1510 and through which the uplink RF signals transmitted by the UE 1510 are received.

[0084] Il sistema 1500 ? accoppiato a una rete centrale 1512 dell?operatore di rete senza fili associato su un backhaul appropriato 1514 (come internet). Inoltre, ciascuna DU 1504 ? accoppiata in modo comunicativo alle RU 1506 servite da essa usando un fronthaul 1516. Ciascuna tra la DU 1504 e le RU 1506 include una o pi? interfacce di rete (non mostrate) al fine di consentire alla DU 1504 e alle RU 1506 di comunicare sul fronthaul 1516. [0084] The 1500 system ? coupled to an associated wireless network operator core network 1512 over an appropriate backhaul 1514 (such as the internet). Furthermore, each DU 1504 ? coupled communicatively to the RU 1506 served by it using a fronthaul 1516. Each of the DU 1504 and RU 1506 includes one or more? network interfaces (not shown) in order to allow the DU 1504 and RU 1506 to communicate on the 1516 fronthaul.

[0085] In un?implementazione, il fronthaul 1516 che accoppia in modo comunicativo la DU 1504 alle RU 1506 viene implementato usando una rete ETHERNET commutata 1518. In tale implementazione, ciascuna DU 1504 e le RU 1506 includono una o pi? interfacce ETHERNET per comunicare sulla rete ETHERNET commutata 1518 usata per il fronthaul 1516. Tuttavia, occorre comprendere che il fronthaul tra ciascuna DU 1504 e le RU 1506 servite da essa pu? essere implementato in altri modi. [0085] In one implementation, the fronthaul 1516 which communicatively couples the DU 1504 to the RUs 1506 is implemented using a switched ETHERNET network 1518. In such an implementation, each DU 1504 and the RUs 1506 include one or more? ETHERNET interfaces to communicate on the 1518 switched ETHERNET network used for the 1516 fronthaul. However, it should be understood that the fronthaul between each DU 1504 and the RU 1506 served by it can be implemented in other ways.

[0086] In generale, per ciascuna cella 1502 implementata dal sistema RAN 1500, ciascuna DU 1504 che serve la cella 1502 effettua le funzioni di STRATO-3 e STRATO-2 per la particolare interfaccia senza fili usata per tale cella 1502. Inoltre, per ciascuna cella 1502 implementata dal sistema RAN 1500, ciascuna DU 1504 corrispondente che serve la cella 1502 effettua alcune delle funzioni di STRATO-1 per la particolare interfaccia senza fili usata per tale cella 1502. Ciascuna delle RU 1506 che servono tale cella 1502 effettua le funzioni di STRATO-1 non effettuate dalla DU 1504, implementando anche le funzioni RF e di antenna di base. [0086] In general, for each cell 1502 implemented by the RAN system 1500, each DU 1504 serving the cell 1502 performs the LAYER-3 and LAYER-2 functions for the particular wireless interface used for that cell 1502. Furthermore, for each cell 1502 implemented by the RAN system 1500, each corresponding DU 1504 serving the cell 1502 performs some of the functions of STRATO-1 for the particular wireless interface used for that cell 1502. Each of the RUs 1506 serving that cell 1502 performs the functions of STRATO-1 not carried out by DU 1504, also implementing the RF and basic antenna functions.

[0087] Ciascuna DU 1504 e le RU 1506 (e la funzionalit? descritta come inclusa al loro interno), nonch? il sistema 1500 pi? in generale, e una qualsiasi delle specifiche caratteristiche ivi descritte come implementate da uno qualsiasi dei precedenti, possono essere implementati in un hardware, un software o combinazioni di hardware e software, e le varie implementazioni (se hardware, software o combinazioni di hardware e software) possono anche essere denominate in generale ?circuiteria? o ?circuito? o ?circuiti? configurati per implementare almeno una parte della funzionalit? associata. Quando implementati in un software, tale software pu? essere implementato in un software o firmware in esecuzione su uno o pi? processori programmabili idonei o che configura un dispositivo programmabile (per esempio, processori o dispositivi inclusi in o usati per implementare un hardware speciale, un hardware generico e/o una piattaforma virtuale). Tale hardware o software (o relative porzioni) pu? essere implementato in altri modi (per esempio, in un circuito integrato specifico per l?applicazione (ASIC), eccetera). Inoltre, la funzionalit? RF pu? essere implementata usando uno o pi? circuiti integrati RF (RFIC) e/o componenti distinti. Ciascuna DU 1504, RU 1506 e il sistema 1500 pi? in generale possono essere implementati in altri modi. [0087] Each DU 1504 and RU 1506 (and the functionality described as included therein), as well as the 1500 plus system? generally, and any of the specific features described herein as implemented by any of the foregoing, may be implemented in hardware, software, or combinations of hardware and software, and the various implementations (whether hardware, software, or combinations of hardware and software ) can also be called in general ?circuitry? or ?circuit? or ?circuits? configured to implement at least a part of the functionality? associated. When implemented in software, that software can be implemented in software or firmware running on one or more? suitable programmable processors or that configures a programmable device (for example, processors or devices included in or used to implement special hardware, generic hardware and/or a virtual platform). Such hardware or software (or portions thereof) can? be implemented in other ways (for example, in an application specific integrated circuit (ASIC), etc.). Furthermore, the functionality RF can? be implemented using one or more? RF integrated circuits (RFIC) and/or separate components. Each DU 1504, RU 1506 and system 1500 pi? in general they can be implemented in other ways.

FORME DI REALIZZAZIONE ESEMPLIFICATIVE EXAMPLE EMBODIMENTS

[0088] L?Esempio 1 include un sistema comprendente: un?unit? distribuita (DU) per l?accoppiamento in modo comunicativo a una rete centrale, la DU configurata per implementare almeno alcune funzioni di STRATO 2 per un?interfaccia senza fili e almeno alcune funzioni di STRATO 1 per l?interfaccia senza fili; una pluralit? di unit? remote (RU) per trasmettere e ricevere in modalit? senza fili segnali di radiofrequenza al e dal terminale utente usando l?interfaccia senza fili, ciascuna delle RU associata ad almeno un?antenna e collocata a distanza dalla DU e almeno un?altra RU, in cui ciascuna RU ? configurata per implementare le funzioni di STRATO 1 per l?interfaccia senza fili che non sono implementate nella DU; in cui la DU e le RU sono accoppiate tra loro in modo comunicativo su un fronthaul e sono configurate per comunicare sul fronthaul usando un?interfaccia di fronthaul di O-RAN; e in cui la DU e le RU sono configurate per comunicare messaggi di piano di controllo e piano utente di O-RAN che includono una nuova estensione di sezione di O-RAN per l?uso nella comunicazione di differenti dati di sezione a differenti RU. [0088] Example 1 includes a system comprising: a unit? distributed (DU) for communicative coupling to a core network, the DU configured to implement at least some LAYER 2 functions for a wireless interface and at least some LAYER 1 functions for the wireless interface; a plurality? of units remote (RU) to transmit and receive mode? wireless radio frequency signals to and from the user terminal using the wireless interface, each of the RUs associated with at least one? antenna and located at a distance from the DU and at least one? other RU, in which each RU ? configured to implement LAYER 1 features for the wireless interface that are not implemented in the DU; wherein the DU and the RUs are communicatively coupled to each other on a fronthaul and are configured to communicate on the fronthaul using an O-RAN fronthaul interface; and wherein the DU and RUs are configured to communicate O-RAN user plane and control plane messages which include a new O-RAN section extension for use in communicating different section data to different RUs.

[0089] L?Esempio 2 include il sistema dell?Esempio 1, in cui la DU e le RU sono configurate per usare la nuova estensione di sezione di O-RAN per supportare il riuso di frequenza. [0089] Example 2 includes the system from Example 1, where the DU and RU are configured to use the new O-RAN section extension to support frequency reuse.

[0090] L?Esempio 3 include il sistema di uno qualsiasi degli Esempi 1-2, in cui la DU e le RU sono configurate per usare la nuova estensione di sezione di O-RAN per supportare il simulcast completo in cui i dati sono trasmessi in modalit? senza fili da tutte le RU a un UE. [0090] Example 3 includes the system of any of Examples 1-2, where the DU and RU are configured to use the new O-RAN section extension to support full simulcast where data is transmitted in mode? wireless from all UK to EU.

[0091] L?Esempio 4 include il sistema di uno qualsiasi degli Esempi 1-3, in cui la DU e le RU sono configurate per usare un campo di maschera di RU per memorizzare una maschera di bit comprendente una pluralit? di posizioni di bit, ciascuna posizione di bit associata a una rispettiva delle RU, in cui ciascuna posizione di bit viene impostata se i messaggi di piano di controllo e utente di O-RAN associati sono destinati alla rispettiva RU che ? associata a tale posizione di bit. [0091] Example 4 includes the system of any of Examples 1-3, wherein the DU and RU are configured to use an RU mask field to store a bit mask comprising a plurality of? of bit positions, each bit position associated with a respective RU, wherein each bit position is set if the associated O-RAN user and control plane messages are destined for the respective RU which ? associated with that bit position.

[0092] L?Esempio 5 include il sistema dell?Esempio 4, in cui il campo di maschera di RU viene comunicato nella nuova estensione di sezione di O-RAN comunicata nei messaggi di piano di controllo di O-RAN. [0092] Example 5 includes the system of Example 4, wherein the RU mask field is communicated in the new O-RAN section extension communicated in the O-RAN control plane messages.

[0093] L?Esempio 6 include il sistema di uno qualsiasi degli Esempi 4-5, in cui il campo di maschera di RU viene comunicato in entrambi i messaggi di piano di controllo e piano utente di O-RAN. [0093] Example 6 includes the system of any of Examples 4-5, wherein the RU mask field is communicated in both O-RAN user plan and control plan messages.

[0094] L?Esempio 7 include il sistema dell?Esempio 6, in cui ciascuno dei messaggi di piano di controllo e piano utente di O-RAN include dati di strato applicativo che includono campi di intestazione comune, in cui il campo di maschera di RU viene comunicato nei campi di intestazione comune dei dati di strato applicativo di entrambi i messaggi di piano di controllo e piano utente di O-RAN. [0094] Example 7 includes the system of Example 6, wherein each of the O-RAN control plane and user plane messages includes application layer data including common header fields, wherein the mask field of RU is communicated in the application layer data common header fields of both control plane and user plane messages of O-RAN.

[0095] L?Esempio 8 include il sistema di uno qualsiasi degli Esempi 1-7, in cui la nuova estensione di sezione di O-RAN include campi per memorizzare differenti informazioni di formazione di fascio per ciascuna RU. Example 8 includes the system of any of Examples 1-7, wherein the new O-RAN section extension includes fields for storing different beamforming information for each RU.

[0096] Altre forme di realizzazione possono essere implementate in altri modi. [0096] Other embodiments may be implemented in other ways.

[0097] ? stato descritto un certo numero di forme di realizzazione dell?invenzione definita dalle seguenti rivendicazioni. Ciononostante, si comprender? la possibilit? di apportare varie modifiche alle forme di realizzazione descritte senza discostarsi dallo spirito e dall?ambito dell?invenzione rivendicata. Di conseguenza, altre forme di realizzazione rientrano nell?ambito delle seguenti rivendicazioni. [0097] ? A number of embodiments of the invention defined by the following claims have been described. Nonetheless, will you understand? the possibility? to make various modifications to the described embodiments without departing from the spirit and scope of the claimed invention. Accordingly, other embodiments are within the scope of the following claims.

Claims

1. System including:

a?unit? distributed (DU) to communicatively couple to a core network, the DU configured to implement at least some LAYER 2 functions for a wireless interface and at least some LAYER 1 functions for the wireless interface;

a plurality? of units remote (RU) to transmit and receive mode? wireless radio frequency signals to and from the user terminal using the wireless interface, each of the RUs associated with at least one? antenna and located at a distance from the DU and at least one? other RU, in which each RU ? configured to implement LAYER 1 features for the wireless interface that are not implemented in the DU;

wherein the DU and the RUs are communicatively coupled to each other on a fronthaul and are configured to communicate on the fronthaul using a fronthaul interface of O-RAN; and wherein the DU and RUs are configured to communicate O-RAN user plane and control plane messages which include a new O-RAN section extension for use in communicating different section data to different RUs.

The system according to claim 1, wherein the DU and RU are configured to use the new O-RAN section extension to support frequency reuse.

The system according to claim 1, wherein the DU and RU are configured to use the new O-RAN section extension to support full simulcast in which data is transmitted in synchronous mode. wireless from all UK to EU.

The system according to claim 1, wherein the DU and RU are configured to use an RU mask field to store a bit mask comprising a plurality of bits. of bit positions, each bit position associated with a respective RU, wherein each bit position is set if the associated O-RAN user and control plane messages are destined for the respective RU which ? associated with that bit position.

The system according to claim 4, wherein the mask field of RU is communicated in the new O-RAN section extension communicated in the O-RAN control plane messages.

The system according to claim 4, wherein the mask field of RU is communicated in both O-RAN user plan and control plan messages.

The system according to claim 6, wherein each of the O-RAN control plane and user plane messages includes application layer data including common header fields, wherein the mask field of RU is communicated in the header fields application layer data of both O-RAN user plane and control plane messages.

The system according to claim 1, wherein the new O-RAN section extension includes fields for storing different beamforming information for each RU.