Re: [dispatch] SIP and GSM/UMTS with OpenBTS

One could use GPRS as a control layer for SIP, but a key property here is
our ability to support existing phones, which couldn't use such a layer.

On Sat, Feb 15, 2014 at 1:08 AM, Michael Hammer <
michael.hammer@yaanatech.com> wrote:

> OK, let me add some protocol perspective.  Cut and paste courtesy of
> Wikipedia:
>
> ****
>
> The *Um interface* is the air interface<http://en.wikipedia.org/wiki/Air_interface>for the
> GSM <http://en.wikipedia.org/wiki/GSM> mobile telephone standard. It is
> the interface between the mobile station<http://en.wikipedia.org/wiki/Mobile_phone>(MS) and the Base
> transceiver station<http://en.wikipedia.org/wiki/Base_transceiver_station>(BTS). It is called Um because it is the mobile analog to the U
> interface <http://en.wikipedia.org/wiki/U_interface> of ISDN<http://en.wikipedia.org/wiki/ISDN>.
> Um is defined in the GSM 04.xx and 05.xx series of specifications. Um can
> also support GPRS <http://en.wikipedia.org/wiki/GPRS> packet-oriented
> communication.
>
> *Um layers[edit
> <http://en.wikipedia.org/w/index.php?title=Um_interface&action=edit&section=1>]*
>
> The layers of GSM are initially defined in GSM 04.01 Section 7 and roughly
> follow the OSI model <http://en.wikipedia.org/wiki/OSI_model>. Um is
> defined in the lower three layers of the model.
> Network Layer (L3)[edit<http://en.wikipedia.org/w/index.php?title=Um_interface&action=edit&section=7>
> ]
>
> The Um network layer <http://en.wikipedia.org/wiki/Network_layer> is
> defined in GSM 04.07 and 04.08 and has three sublayers. A subscriber
> terminal must establish a connection in each sublayer before accessing the
> next higher sublayer.
>
>    1. Radio Resource<http://en.wikipedia.org/wiki/Radio_Resource_Management>(RR). This sublayer manages the assignment and release of logical channels
>    on the radio link. It is normally terminated in the BSC<http://en.wikipedia.org/wiki/Base_station_controller>
>    .
>    2. Mobility Management<http://en.wikipedia.org/wiki/Mobility_management>(MM). This sublayer authenticates users and tracks their movements from
>    cell to cell. It is normally terminated in the VLR<http://en.wikipedia.org/wiki/GSM_core_network#Visitor_Location_Register>or
>    HLR<http://en.wikipedia.org/wiki/GSM_core_network#Home_Location_Register>
>    .
>    3. Call Control <http://en.wikipedia.org/wiki/Call_control> (CC). This
>    sublayer connects telephone calls and is taken directly from ITU-T
>    Q.931 <http://en.wikipedia.org/wiki/Q.931>. GSM 04.08 Annex E provides
>    a table of corresponding paragraphs in GSM 04.08 and ITU-T Q.931 along with
>    a summary of differences between the two. The CC sublayer is terminated in
>    the MSC <http://en.wikipedia.org/wiki/Mobile_switching_centre_server>.
>
> The access order is RR, MM, CC. The release order is the reverse of that.
>
> Note that none of these sublayers terminate in the BTS itself. The
> standard GSM BTS operates only in layers 1 and 2.
>
> ***
>
> So, the implementation appears to move the MSC to the BTS, along with a
> Q.931 to SIP GW, such as:
>
> ETSI TS 183 036 V3.4.1 (2011-02) Telecommunications and Internet converged
> Services and Protocols for Advanced Networking (TISPAN);
>
> ISDN/SIP interworking; Protocol specification
>
>
>
> Not sure how that saves battery, but that is an implementation question we
> don't need to answer.
>
>
>
> Note also that since Um supports GPRS, could the BTS not also support a
> packet relay for higher layer P2P SIP call control?
>
>
>
> Just asking.
>
>
>
> *Michael Hammer*
>
> *Principal Engineer*
>
> *michael.hammer@yaanatech.com <michael.hammer@yaanatech.com>*
>
> *Mobile: *+1 408-202-9291
>
> 500 Yosemite Drive Suite 120
>
> Milpitas, CA 95035 USA
>
>
>
> *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Kurtis
> Heimerl
> *Sent:* Friday, February 14, 2014 12:27 AM
> *To:* Dale R. Worley
>
> *Cc:* dispatch@ietf.org
> *Subject:* Re: [dispatch] SIP and GSM/UMTS with OpenBTS
>
>
>
> OpenBTS is an instance of an Um->SIP gateway. After this implementation,
> we've become aware that a broader view of the relative correctness of our
> design would be valuable...  and that's why this thread exists. We'd like
> the IETF to help standardize this gateway model and make sure that the
> decisions that were made are reasonable, scalable, and intelligent.
>
>
>
> At least that's my perception on why we're here. Jim may have another.
>
>
>
> On Fri, Feb 14, 2014 at 8:28 AM, Dale R. Worley <worley@ariadne.com>
> wrote:
>
> > From: "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx>
>
> (Is there a reason you insert so many blank lines?)
>
>
> > So imagine a village, a few hundred people living there, most of
> > them owning mobile phones for communication when they travel to the
> > town for work or for trading goods - but at home those phones are
> > useless.
>
> > So somebody is able to spent a few thousand dollars, puts an antenna
> > onto some tree, flips the switch, and a few hundred phones can (and
> > do) log on.
>
> > Now more and more of those low-cost networks grow up, and people
> > want to connect them. Internet is available in some places, cheap to
> > buy and install WiFi-links are established, the whole thing evolves,
> > some simple structure grows.
>
> This story makes sense to me.  The question seems to be how to
> interwork the GSM radio call-control protocol with SIP, so that a set
> of these base stations can operate as an integrated system.  You'd
> want some sort of SIP registrar/proxy to operate as an ITSP, and all
> of the base stations make SIP connections with it.
>
> The next step is for someone to start designing this use of SIP.  No
> doubt a lot of interesting questions will arise, and you may need to
> design some SIP extensions.  But until you've got the design started
> and can discuss the design decisions, you're not in a position to talk
> about what SIP extensions are needed.
>
> Dale
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
>