transceiver won't start; fpga build error

stephane at shimaore.net stephane at shimaore.net
Wed Mar 6 00:20:18 UTC 2013


Hi Alexander,

Hope you guys made some interesting contacts while in Spain.

> Though I should note that FPGA and ZPU compilation and flashing is not
> needed in most cases. UmTRX comes pre-flashed and should not need all
> those cumbersome steps.

Yup, changed my page to indicate that as well. (Although really I should
be updating the wiki.)

> Thank you for your patch to make it working with OpenSIPS :) Looking
> forward for more contributions to the SIP side of things.

My line of thought is to use OpenSIPS as registrar, with a Redis
backend. Then use OpenSIPS to route calls, SMS, .. based on the IMSI.

> I even thought about completely replacing oSIP with a library which
> already implements SIP state machines, like Sofia-SIP. But this requires
> research on whether we'll be able to implement things which require
> non-standard behavior, like handover.

If we are to keep the strong coupling (with OpenBTS a thin
layer between GSM and SIP), the SIP stack can remain pretty simple (with
some level of equivalence between GSM and SIP messages); in that case the
SIP call handling intelligence will be deported to other tools (OpenSIPS,
FreeSwitch, Yate, ...): OpenBTS won't be able to do things like handover
or roaming on its own, the call control will belong in those external
servers, but that's what they were designed to do (and OpenBTS remains
a manageable project).

However, in that case, SIP might not be the best protocol, since
the model is more of a call-agent / gateway relationship (so something
better suited to, e.g., MGCP). Or we need to defined a subset of SIP that
matches that call-agent / gateway relationship carefully.


On the other hand if OpenBTS is to be a full-flegde User-Agent (UA) this
will require a strong SIP stack like sofia-sip, and handling a lot of
"exception cases" inside OpenBTS (SIP is a piece of work). This means
an amount of work similar to that required to write Asterisk, FreeSwitch,
or Yate.

Maybe in that case it's simpler to (re)implement OpenBTS as, e.g., a
FreeSwitch "endpoint" than trying to re-invent a new SIP UA.


About handover:

With regards to Dmitri's handover proposal[1], I can imagine that in
some contexts (large cities?) handover might be a common occurrence and
keeping the call pinned in one (or more?) OpenBTS might cause scalability
or audio quality issues. (This would especially be the case if multiple
handovers mean traversing multiple OpenBTS.)

[1] http://wush.net/trac/rangepublic/wiki/Handover

Also I can imagine that we might eventually want to do GSM-to-WiFi
back to-GSM type of handovers (or is that what GSM would consider
roaming?). I don't know whether there are existing procedures to handle
this?

> RX1 (software) = RXn (PCB label)
> RX3 (software) = SCNn (PCB label)
> TX2 (software) = TXn (PCB label)

OK, that was the missing translation table. I guess I could look at the
hardware schematics when I have hardware questions. :)
S.




More information about the UmTRX mailing list