Dear list members,
I posted the following message to the IETF DISPATCH mailing list earlier today. It's
got a bit of a lengthy intro, as that community is not familiar with OpenBTS (and probably
not OpenBSC either), and in preliminary discussions with them it was clear that it needed
a good explanation.
I invite you all to join the IETF DISPATCH list, and participate in the discussion. Tim
Panton has already raised some good points. See
to join the list.
-- Jim
Range Networks
Begin forwarded message:
From: Jim Forster
<jim.forster(a)rangenetworks.com>
Subject: [dispatch] SIP and GSM/UMTS with OpenBTS
Date: February 5, 2014 at 12:09:45 PM GMT+5:30
To: "dispatch(a)ietf.org" <dispatch(a)ietf.org>
Dear DISPATCH group,
OpenBTS and OpenBSC are projects are combining GSM phones and SIP in new and interesting
ways. I think there is some value to the community in discussing these in the DISPATCH
mailing list and having an related meeting at the London IETF. There is both some
short-term, relatively straightforward work to be done to agree on the usage of SIP in
these existing implementations. There may also be some very interesting work to be done on
more advanced approaches.
First, some background: OpenBTS is an open source project started by the founders of
Range Networks to make a 'GSM system in a box', by implementing a system which
supports the air interface for GSM phones (Um) using a Software Defined Radio (SDR) for
the RF. While the GSM & 3GPP defined air interface to the phones is supported,
OpenBTS diverges from these standards by immediately gatewaying the call to SIP. Each GSM
or UMTS phone can then appear on the Internet as a SIP endpoint. A local SIP switching
decision is made to route the call; Asterix, Freeswitch, Yate have been. The call is then
sent to another local connected phone or to some other SIP service point on the Internet.
With this in place, because the air interface to the phones is supported with no changes,
standard GSM/UMTS phones can make calls to other phones on the same OpenBTS system or to
any SIP endpoint on the Internet, and thence to the PSTN via any of the many SIP-PSTN
gateways in operation.
A fair question would be "Why do all this? What's wrong with GSM & 3GPP
systems?". One reason is that the OpenBTS approach allows very small, stand alone
systems, which efficiently connect GSM and UMTS phones to the Internet based SIP systems
with a minimum of other systems. Certainly GSM/3GPP based micro cells exist, but are tied
to the 3GPP 'Core' which is usually beyond the means of smaller users. OpenBTS
aspires to be the simplest way for a GSM/UMTS phone to make phone calls to the SIP &
PSTN world.
At least several hundred, and likely several thousand of these systems are deployed
already. Many are in labs, but others are production usage on all continents.
Universities find these systems very attractive for teaching and researching: all the code
from RF to Signaling is visible and may be changed as desired.
Furthermore, additional SDRs are popping up all the time. There are 3-4 separate SDR
based systems that run OpenBTS and more are coming. Right now they range from $2000 up,
but it's easy to see them dropping to $500 or so this year; even Kickstarter campaigns
are funding some of them. There's no natural floor below that; adding GSM/UMTS to a
home router and making it a micro-cell running SIP to the Internet could conceivably be a
$10 HW delta and some more SW. Secondly, there are several countries that have unlicensed
GSM band (Sweden, Netherlands, UK?) so some efforts are underway to do exactly that.
When facing the Internet, OpenBTS is simply a SIP client. However, to assure
interoperability, there may be value in standardized behavior, including these issues:
* Which elements of SIP are needed for this operation?
* Should these be documented in a profile of SIP usage to be OpenBTS Ready?
* Should ICE be recommended or possibly be required for operation behind NATs?
* What about BTS-BTS neighbor discovery
* Use of SIP Re-invite for hand-over when a mobile phone moves from one BTS to a
neighbor
* For somewhat different use cases: one could separate signaling from media transport and
thus might support WebRTC or other such systems. E.164 addresses are used in phones, but
temporary numbers can be assigned as needed (as done in Roaming) and not surfaced to the
WebRTC level.
* What Changes required for IPv6?
* Required and recommended security provisions
* Is IETF an appropriate forum for this, or should it be in 3GPP, or
Sipforum.org, or a
separate industry group formed?
I look forward to discussion on the mailing list, and hopefully meeting and discussing in
London.
Yours,
Jim Forster
Range Networks
_______________________________________________
dispatch mailing list
dispatch(a)ietf.org
https://www.ietf.org/mailman/listinfo/dispatch