Project

General

Profile

Bug #4082

OML: Unknown/unhandled PCHAN type: 0 NONE

Added by fixeria 6 months ago. Updated 27 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
07/01/2019
Due date:
% Done:

0%

Spec Reference:

Description

If at least one time-slot in OsmoBSC is configured as NONE:

network
 ...
 bts 0
  ...
  trx 0
   ...
   timeslot 0
    phys_chan_config CCCH
    hopping enabled 0
   ...
   timeslot 7
    phys_chan_config NONE
    hopping enabled 0

OsmoBTS fails to start:

...
DOML DEBUG oml.c:877 OC=CHANNEL(03) INST=(00,00,06): Rx SET CHAN ATTR
DOML INFO oml.c:941 OC=CHANNEL(03) INST=(00,00,06): OC=CHANNEL INST=(00,00,06) SET CHAN ATTR (TSC=7 pchan=TCH/H)
DL1C NOTICE scheduler.c:948 Configuring multiframe with TCH/H+SACCH trx=0 ts=6
DOML DEBUG oml.c:454 OC=CHANNEL(03) INST=(00,00,06): Sending FOM ACK.
DOML DEBUG oml.c:981 OC=CHANNEL(03) INST=(00,00,06): Rx CHG ADM STATE
DOML DEBUG oml.c:144 OC=CHANNEL(03) INST=(00,00,06): Tx Change Administrative State Ack
DOML DEBUG oml.c:144 OC=CHANNEL(03) INST=(00,00,06): Tx State Changed Event Report
DOML DEBUG oml.c:954 OC=CHANNEL(03) INST=(00,00,06): Rx OPSTART
DOML DEBUG oml.c:964 OC=CHANNEL(03) INST=(00,00,06): ... automatic ACK, OP state already was Enabled
DOML DEBUG oml.c:144 OC=CHANNEL(03) INST=(00,00,06): Tx Opstart Ack
DTRX NOTICE trx_if.c:487 phy0.0: Using legacy TRXD header format version
DL1C DEBUG l1_if.c:177 phy0.0: (bts=0,trx=0,ts=6) l1if_setslot_cb(as_pchan=TCH/H), calling cb_ts_connected(rc=0)

DOML DEBUG oml.c:877 OC=CHANNEL(03) INST=(00,00,07): Rx SET CHAN ATTR
DOML ERROR oml.c:863 Unknown/unhandled PCHAN type: 0 NONE
DOML ERROR oml.c:924 OC=CHANNEL(03) INST=(00,00,07): SET CHAN ATTR: invalid Chan Comb 0xff (pchan=NONE, conf_lchans()->-14)
DOML NOTICE oml.c:446 OC=CHANNEL(03) INST=(00,00,07): Sending FOM NACK with cause Parameter value outside permitted range.
DLINP ERROR input/ipa.c:65 127.0.0.1:3002 connection closed with server
DABIS ERROR abis.c:144 Signalling link down
DABIS FATAL abis.c:158 OML link was closed early within 1 seconds. If this situation persists, please check your BTS and BSC configuration files for errors.
                       A common error is a mismatch between unit_id configuration parameters of BTS and BSC.
DOML NOTICE bts.c:285 Shutting down BTS 0, Reason Abis close
DL1C NOTICE scheduler.c:597 Exit scheduler for trx=0
...

History

#1 Updated by fixeria 28 days ago

Here is what I can see from Wireshark:

IPA protocol ip.access, type: OML
    DataLen: 13
    Protocol: OML (0xff)
GSM A-bis OML, Radio Channel(00,00,02) Set Channel Attributes 
    Message Discriminator: Formatted O&M (0x80)
    Placement Indicator: Only (0x80)
    Sequence Number: 0x00
    Length Indicator: 9
    FOM Message Type: Set Channel Attributes
        FOM Object Class: Radio Channel (0x03)
        FOM Object Instance BTS: 0
        FOM Object Instance TRX: 0
        FOM Object Instance TS: 2
        FOM Attribute ID: Channel Combination
            FOM Attribute Length: 1
            Channel Combination: Unknown (0xff)  <----- Is it legal?!?
        FOM Attribute ID: Training Sequence Code
            FOM Attribute Length: 1
            TSC: 0x07

My best guess is that OsmoBSC should never send any OML messages for disabled timeslots (i.e. set to NONE).
laforge, what do you think? If my guess is correct, I will update the ticket and change project to OsmoBSC.

#2 Updated by laforge 27 days ago

I Think it is useful to send auch messages, as they could happen at runtime of a bts. What if the TS was previously configured as TCH and now you disable it in the config and restart the oml link. On a BTS that doesn't reboot (like all non-osmobts BTS) you would keep that timeslot in TCH rather than disabling it. In the best case, the behavior of non-osmo bts should be tested. If they support NONE, so should osmobts.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)