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 
http://trac.tools.ietf.org/wg/dispatch/trac/wiki for info about the DISPATCH 
group and https://www.ietf.org/mailman/listinfo/dispatch to join the list.  

  -- Jim

Range Networks

Begin forwarded message:

> From: Jim Forster <[email protected]>
> Subject: [dispatch] SIP and GSM/UMTS with OpenBTS
> Date: February 5, 2014 at 12:09:45 PM GMT+5:30
> To: "[email protected]" <[email protected]>
> 
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/dispatch

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to