https://osmocom.org/https://osmocom.org/favicon.ico?16647414092019-11-17T21:18:11ZOpen Source Mobile CommunicationsOsmoBTS - Bug #4082: OML: Unknown/unhandled PCHAN type: 0 NONEhttps://osmocom.org/issues/4082?journal_id=164692019-11-17T21:18:11Zfixeria
<ul></ul><p>Here is what I can see from Wireshark:</p>
<pre>
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
</pre>
<p>My best guess is that OsmoBSC should never send any OML messages for disabled timeslots (i.e. set to NONE).<br /><a class="user active" href="https://osmocom.org/users/7">laforge</a>, what do you think? If my guess is correct, I will update the ticket and change project to OsmoBSC.</p> OsmoBTS - Bug #4082: OML: Unknown/unhandled PCHAN type: 0 NONEhttps://osmocom.org/issues/4082?journal_id=164752019-11-18T10:09:37Zlaforge
<ul></ul><p>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.</p>