Bhargava, This answer only applies to platforms that use the NuRAN PHY (SuperFemto, LiteCell 1.x, ...). 1. For 11 bit RACH, in PH-RA-IND sent from layer 1. · Whether 'u8Size' will be 2 in case of 11 bit RACH ? [YGOD] Yes it will. · What is the alignment of 11 bits inside 'u8Buffer ? [YGOD] Data is packed LSB first 2. How osmo-bts can distinguish between types of 11 bit RACH based on received layer 1 message ? (spec 44.060 section 11.2.5a) · is burst type GsmL1_BurstType_Access_0 equivalent to GPRS_8_BIT_RACH/ GPRS_11_BIT_RACH · is burst type GsmL1_BurstType_Access_1 equivalent to EGPRS_8_PSK_11_BIT_RACH · is burst type GsmL1_BurstType_Access_2 equivalent to EGPRS_NO_8_PSK_11_BIT_RACH [YGOD] Yes, you are correct. GsmL1_BurstType_Access_0 is for the "normal" access bursts, GsmL1_BurstType_Access_1 is for TS1 and GsmL1_BurstType_Access_2 is for TS2. Best Regards, Yves De : osmocom-net-gprs [mailto:osmocom-net-gprs-bounces@lists.osmocom.org] De la part de Bhargava Abhyankar Envoyé : March-22-16 10:53 AM À : osmocom-net-gprs(a)lists.osmocom.org Objet : Queries regarding L1 interface to osmo-bts for 11 bit RACH Hello, We have planned to support 11 bit RACH in osmo-pcu and osmo-bts. In this regard, we have a query related to layer 1 to osmo-bts interface, as described below. 1. For 11 bit RACH, in PH-RA-IND sent from layer 1. · Whether 'u8Size' will be 2 in case of 11 bit RACH ? · What is the alignment of 11 bits inside 'u8Buffer ? 2. How osmo-bts can distinguish between types of 11 bit RACH based on received layer 1 message ? (spec 44.060 section 11.2.5a) · is burst type GsmL1_BurstType_Access_0 equivalent to GPRS_8_BIT_RACH/ GPRS_11_BIT_RACH · is burst type GsmL1_BurstType_Access_1 equivalent to EGPRS_8_PSK_11_BIT_RACH · is burst type GsmL1_BurstType_Access_2 equivalent to EGPRS_NO_8_PSK_11_BIT_RACH Regards Bhargava Abhyankar

Hi Bhargava, On Tue, Mar 22, 2016 at 02:53:19PM +0000, Bhargava Abhyankar wrote: given that the current format relates to the history of the omso-bts project and the first PHY that we interfaced it with, I think if we make some changes now to the L1 interface (including L1SAP), we could actually clean things up. To do so, I would suggest to a) on L1SAP, extend ph_rach_ind_param with * a uint16_t for 'ra' * add a member 'is_11bit' to indicate 8/11 bit * an enum to indicate the different burst types (and change the osmo-bts-* implementations as well as common code to use that updated definition) b) on the PCU socket, perform similar changes to gsm_pcu_if_rach_ind After performing above-mentioned changes, the formatting of the data should be self-explanatory. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)