Cellular Network Infrastructure » Radio Access Network » OsmoBTS

Unfortunately my assumption turned out to be wrong, the DSP still returns an error:

<0006> oml.c:813 Error activating L1 SAPI PTCCH on TS 7: Invalid parameter

but the error message itself ('Invalid parameter') probably means that MPH-ACTIVATE.req we're sending is incomplete or incorrect:

static int mph_send_activate_req(struct gsm_lchan *lchan, struct sapi_cmd *cmd)
{
        struct femtol1_hdl *fl1h = trx_femtol1_hdl(lchan->ts->trx);
        struct msgb *msg = l1p_msgb_alloc();
        int sapi = cmd->sapi;
        int dir = cmd->dir;
        GsmL1_MphActivateReq_t *act_req;
        GsmL1_LogChParam_t *lch_par;

        act_req = prim_init(msgb_l1prim(msg), GsmL1_PrimId_MphActivateReq,
                            fl1h, l1p_handle_for_lchan(lchan));
        lch_par = &act_req->logChPrm;
        act_req->u8Tn = lchan->ts->nr;
        act_req->subCh = lchan_to_GsmL1_SubCh_t(lchan); // <-- NOTE
        act_req->dir = dir; 
        act_req->sapi = sapi;
        act_req->hLayer2 = l1if_lchan_to_hLayer(lchan);
        act_req->hLayer3 = act_req->hLayer2;

        /* ... */

According to 3GPP TS 45.002, table 6, PTCCH/U has 16 sub-channels (TAI=0..15), and GsmL1_SubCh_t defines exactly 16 sub-channels!

typedef enum GsmL1_SubCh_t
{    
    GsmL1_SubCh_0 = 0,      ///< Sub-channel 0
    GsmL1_SubCh_1,          ///< Sub-channel 1
    GsmL1_SubCh_2,          ///< Sub-channel 2
    /* ... */
    GsmL1_SubCh_14,         ///< Sub-channel 14
    GsmL1_SubCh_15,         ///< Sub-channel 15

    GsmL1_SubCh_NA = 0x1F   ///< No sub-channel (not applicable)

} GsmL1_SubCh_t;

but currently we always send GsmL1_SubCh_NA (see lchan_to_GsmL1_SubCh_t()). We should either activate all 16 sub-channels in osmo-bts-{sysmo,oc2g,litecell15}, or do it directly from osmo-pcu as soon as we assign a TAI to a subscriber, i.e. on demand. This also needs to be tested though.

From experiments yesterday, I confirm that adding

if (sapi  GsmL1_Sapi_Ptcch && dir  GsmL1_Dir_RxUplink) 
            act_req->subCh = GsmL1_SubCh_0;

in mph_send_activate_req() for case GsmL1_Sapi_Ptcch

This results in Activation success, but immediately followed by:

Error activating L1 SAPI PACCH on TS 6: Invalid parameter

As if once we have set GsmL1_SubCh_0 on the PTCCH/U it no longer accepts the PACCH activation.

I tried to bypass the PACCH activation as you suggested on IRC (I faked an activation confirmation) but that just runs into more problems later.

Hi keith,

Error activating L1 SAPI PACCH on TS 6: Invalid parameter

do you see this message with GsmL1_Sapi_Pacch enabled on GsmL1_Dir_RxUplink? If so, let's comment it out (as it's done in the current master) and focus on GsmL1_Sapi_Ptcch for now. The "PACCH/U vs PRACH" problem to be discussed in #4501.

fixeria wrote:

Hi keith,

Error activating L1 SAPI PACCH on TS 6: Invalid parameter

do you see this message with GsmL1_Sapi_Pacch enabled on GsmL1_Dir_RxUplink?

Ah, now i see you mean in the struct sapi_dir pdtch_sapis[]

So yes, that's correct.

If so, let's comment it out (as it's done in the current master)

OK. Yes, now I can activate the PTCCH/U and phone can GPRS attach.

EDIT: and PCU logs now: (I know what to do, but got to go AFK for a few hours)

osmo-bts-sysmo/sysmo_l1_if.c:213 Rx PH-DATA.ind for unknown L1 SAPI PTCCH

will try to get more on this later today.

OK. Yes, now I can activate the PTCCH/U and phone can GPRS attach.

Yay! One more step towards the light in this SAPI-hell ;)
This also means that we can now (de)activate PTCCH/U for particular TAI on demand. Nice!

osmo-bts-sysmo/sysmo_l1_if.c:213 Rx PH-DATA.ind for unknown L1 SAPI PTCCH

Huh, I thought it would be PH-RA.ind. This is not a big problem though.
Would be nice to see the whole payload of this indication (using gdb).

$2 = {hLayer2 = 458939, hLayer1 = 2265448480, sapi = GsmL1_Sapi_Ptcch, dir = GsmL1_Dir_RxUplink, measParam = {fRssi = -112.541115, i16BurstTiming = 9,
fLinkQuality = -4.00558043, fBer = 0.111111112}, msgUnitParam = {u8Size = 2 '\002',
u8Buffer = "\205\003F", '\000' <repeats 16 times>, "FacchF\000\000\000\000\000\000\000\000\000\000 \000\b\207\034\365\037\207\000\000\000\000\260L\b\207 \000\b\207\000\000\000\000FacchH", '\000' <repeats 14 times>, "Nch", '\000' <repeats 17 times>, "Pdtch", '\000' <repeats 15 times>, "Pacch", '\000' <repeats 15 times>, "Pbcch", '\000' <repeats 15 times>, "P"}, u16Arfcn = 87, u8Tn = 7 '\a', subCh = GsmL1_SubCh_0, u32Fn = 679340, u8BlockNbr = 0 '\000'}

I wish I knew about the 'dsp-trace-flag' before. The DSP actually tells us (see /dev/rtfifo/dsp_trace) the exact cause of error:

MphActivateReq => [ hLayer1 = 0x87080020, hLayer2 = 0x600BB, u8Tn = 6, sapi = 21, dir = 2, subCh = 31, bfi = 0.00 dBm                                                    
                    cfgParam = 0000003F 00000000 00000000 00000000 ]          
[ERROR] : LogChMng_GetTypeXIIIBufAddr() => Invalid SubCh (31) Valid is [GsmL1_SubCh_0 to _15]                                                                            
[ERROR] : Device_ActivateLogCh()=> Unable to activate. [pPhyCh = 0x87089AB0, pLogChMngBuf = 0x870801FC, pi8Buffer = 0x87089F90]                                          
MphActivateCnf => [ hLayer3 = 0x600BB, hLayer1 = 0x87080020, TN = 6, sapi = 21, dir = 2, subCh = 31, status = -4 ]

achieved by adding the following to osmo-bts-sysmo.conf:

phy 0
  instance 0
    dsp-trace-flag error
    dsp-trace-flag debug
    dsp-trace-flag mph_req                                                                                                                                                 
    dsp-trace-flag mph_ind                                                                                                                                                 
    dsp-trace-flag mph_cnf

P.S. make sure to apply https://gerrit.osmocom.org/c/osmo-bts/+/17946 before using it.

what is the status here? I would love to help to resolve this. thanks!

Hi Harald,

what is the status here? I would love to help to resolve this. thanks!

now we know how to (de)activate PTCCH/U detection in DSP. The easiest solution would be to enable PTCCH/U for all 16 sub-channels, but I don't like this approach. My plan is to do it directly from osmo-pcu on demand, i.e. activate PTCCH/U when we allocate a TAI, and deactivate it on release. Given that continuous timing advance loop (see #1545) is not yet implemented in osmo-pcu, it's not critical for now I think.