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

[Michael Hammer <[e-mail]>]

Correct.  I was just suggesting the possibility of giving phones a direct
packet connection and then let them run a P2P app on top.

However, if this is for lame 2G feature phones, then that might not be
possible.

 

Michael Hammer

Principal Engineer

 <mailto:[e-mail]> [e-mail]

Mobile: [phone]

500 Yosemite Drive Suite 120

Milpitas, CA 95035 USA

 

From: DRAGE, Keith (Keith) [mailto:[e-mail]] 
Sent: Friday, February 14, 2014 8:44 PM
To: Kurtis Heimerl; Michael Hammer
Cc: [e-mail]
Subject: RE: [dispatch] SIP and GSM/UMTS with OpenBTS

 

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]> 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]

Mobile: [phone]

500 Yosemite Drive Suite 120

Milpitas, CA 95035 USA

 

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


Cc: [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]> wrote:

> From: "Ralph A. Schmid, dk5ras" <[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]
https://www.ietf.org/mailman/listinfo/dispatch