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

["DRAGE, Keith (Keith)" <[e-mail]>]

GPRS is not a control layer in the way I understand it - it is a mechanism for providing IP transport, essentially the equivalent functionality of mobile IP.

Keith

________________________________
From: dispatch [mailto:[e-mail]] On Behalf Of Kurtis Heimerl
Sent: 14 February 2014 16:54
To: Michael Hammer
Cc: [e-mail]
Subject: 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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
Mobile: [phone]<tel:[phone]>
500 Yosemite Drive Suite 120
Milpitas, CA 95035 USA

From: dispatch [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Kurtis Heimerl
Sent: Friday, February 14, 2014 12:27 AM
To: Dale R. Worley

Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:
> From: "Ralph A. Schmid, dk5ras" <[e-mail]<mailto:[e-mail]>>

(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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dispatch