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

From: Jim Forster <[email-masked]>
Date: Wed, 5 Feb 2014 06:39:45 +0000

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

---

From: Tim Panton new <[email-masked]>
Date: Wed, 5 Feb 2014 10:47:19 +0000

> When facing the Internet, OpenBTS is simply a SIP client.  However, to assure interoperability, there may be value in standardized behavior, including these issues:

It may be a SIP client, but in some ways it is a non-traditional one, a single BTS may well present as multiple phones (possibly thousands) like a giant ATA bank of old.

> * Which elements of SIP are needed for this operation?

We need to go through the uM (GSM air interface) and document how that maps to SIP, this will give us a 
list of SIP actions that need to be supported to make a working UM cell

> * Should these be documented in a profile of SIP usage to be OpenBTS Ready?

Yes, but we need a better name - UMSIP  perhaps? 

> * Should ICE be recommended or possibly be required for operation behind NATs?

My experience of trying to install these things is that NAT is a persistent problem, getting an internet connection into
a village in the middle of nowhere is hard enough, expecting it to have an unfiltered public IP address is too much to ask.
Fall back methods of running a VPN or using rfc5456 are both unsatisfactory. ICE will help with the RTP streams, 
but we need to get the SIP flowing too - perhaps SIP over TCP or even websockets is a better fit?

> * What about BTS-BTS neighbor discovery

In order to handover a moving call to the next cell, a BTS need to know where the next cells are, at the moment
openBTS uses a private protocol/config. It would be great if we could use a suitable pre-existing SIP mechanism and document that
usage.

> * Use of SIP Re-invite for hand-over when a mobile phone moves from one BTS to a neighbor

Or some other mechanism.

> * Is IETF an appropriate forum for this, or should it be in 3GPP, or Sipforum.org,  or a separate industry group formed?
I think the IETF has solved most of these problems in other cases, so it makes sense to try and leverage that knowledge in this space, 
and try to produce a document that lets multiple UMSIP vendors interoperate and SIP trunk/PBX  vendors know what they need to do to support these new devices.

Tim.

---

From: Jim Forster <[email-masked]>
Date: Wed, 5 Feb 2014 12:06:25 +0000

> It may be a SIP client, but in some ways it is a non-traditional one, a single BTS may well present as multiple phones (possibly thousands) like a giant ATA bank of old.

Yes, you're right.

> but we need to get the SIP flowing too - perhaps SIP over TCP or even websockets is a better fit?

Very good point!  It would be wonderful to have a good solution the NAT issues.  I don't have the experience to know what's the best approach for SIP.

> openBTS uses a private protocol/config. It would be great if we could use a suitable pre-existing SIP mechanism and document that usage.

For instance?

  -- Jim

---

From: Gullik Webjörn <[email-masked]>
Date: Wed, 05 Feb 2014 15:00:14 +0100

On 02/05/2014 11:47 AM, Tim Panton new wrote:
>
> On 5 Feb 2014, at 06:39, Jim Forster <[email-masked] 
> <mailto:[email-masked]>> wrote:
>>
>> When facing the Internet, OpenBTS is simply a SIP client.  However, 
>> to assure interoperability, there may be value in standardized 
>> behavior, including these issues:
>
> It may be a SIP client, but in some ways it is a non-traditional one, 
> a single BTS may well present as multiple phones (possibly thousands) 
> like a giant ATA bank of old.
>
>>
> My experience of trying to install these things is that NAT is a 
> persistent problem, getting an internet connection into
> a village in the middle of nowhere is hard enough, expecting it to 
> have an unfiltered public IP address is too much to ask.
> Fall back methods of running a VPN or using rfc5456 are both 
> unsatisfactory. ICE will help with the RTP streams,
> In order to handover a moving call to the next cell, a BTS need to 
> know where the next cells are, at the moment
> openBTS uses a private protocol/config. It would be great if we could 
> use a suitable pre-existing SIP mechanism and document that
> usage.
>
Here is room for some enhancements, adding to preconfigured handover / 
roaming.

A simple mechanism to propagate and apply a ruleset, such that each BTS 
responsible for the registration
can indicate whether a) A foreign MS is allowed to handover / roam to 
this BTS, and b) A local MS is allowed to request its information via a 
foreign
BTS. This will allow policy based mobility, i.e. bilateral agreements 
between BTS's. My 2 c worth.

Gullik

>
>> * 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.
>> * Is IETF an appropriate forum for this, or should it be in 3GPP, or 
>> Sipforum.org <http://sipforum.org/>,  or a separate industry group 
>> formed?
> I think the IETF has solved most of these problems in other cases, so 
> it makes sense to try and leverage that knowledge in this space,
> and try to produce a document that lets multiple UMSIP vendors 
> interoperate and SIP trunk/PBX  vendors know what they need to do to 
> support these new devices.
>
> Tim.
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Feb 2014 10:01:57 -0500

Jim,

I'd be interested in hearing more about this.
But you are tardy in bringing this up for London.
The deadline for scheduling BOFs has passed. (And you would have need to 
do quite a bit more to stimulate interest to get one scheduled.)

In principle you could ask for agenda time in dispatch. But that is 
typically only granted for subjects that have had discussion and 
interest on the dispatch mailing list.

So you are doing the right thing to get started, by beginning discussion 
on the dispatch list. But it is unlikely that you can do anything about 
it *formally* in live sessions in London. You might want to set yourself 
a goal to generate sufficient interest to do something at the following 
ietf in Toronto.

For the London meeting you could make an effort to set up something 
informal, such as a "Bar BOF". But the main thing, even for that, is to 
develop a set of interested followers via email.

	Best wishes,
	Paul

On 2/5/14 1:39 AM, Jim Forster wrote:
> 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:
>
> assigned as needed (as done in Roaming) and not surfaced to the WebRTC
> level.
> Sipforum.org <http://Sipforum.org>,  or a separate industry group formed?
>

---

From: Mary Barnes <[email-masked]>
Date: Wed, 5 Feb 2014 09:17:48 -0600

He is just a couple days  late for the DISPATCH process:
http://tools.ietf.org/wg/dispatch/trac/wiki
The chairs were aware of this request within the required timeframe.  Jim
had originally contact ADs about a Bof and they referred JIm to the
DISPATCH chairs.

There is no requirement whatsoever that work goes through an official IETF
Bof prior to being chartered.  Depending upon how this mailing list
discussion goes, the DISPATCH chairs will decide whether this topic gets
agenda time in DISPATCH or whether a less formal discussion would be
optimal (although, scheduling time for that in a venue that will be
expeditious will be difficult given the current RAI schedule).

Mary.
DISPATCH WG co-chair

On Wed, Feb 5, 2014 at 9:01 AM, Paul Kyzivat <[email-masked]> wrote:

> typically only granted for subjects that have had discussion and interest
> on the dispatch mailing list.
>
> on the dispatch list. But it is unlikely that you can do anything about it
> *formally* in live sessions in London. You might want to set yourself a
> goal to generate sufficient interest to do something at the following ietf
> in Toronto.
>

---

From: Michael Hammer <[email-masked]>
Date: Wed, 5 Feb 2014 15:18:11 +0000

Jim,

Is the end result of this improvements to the SIP or other IETF protocols?
Or, does this attempt to standardize an architecture?

Also, is there any IPR attached to this?

Michael Hammer
Principal Engineer
[email-masked]
Mobile: +1 408-202-9291
500 Yosemite Drive Suite 120
Milpitas, CA 95035 USA

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, February 05, 2014 10:02 AM
To: [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

Jim,

I'd be interested in hearing more about this.
But you are tardy in bringing this up for London.
The deadline for scheduling BOFs has passed. (And you would have need to do
quite a bit more to stimulate interest to get one scheduled.)

In principle you could ask for agenda time in dispatch. But that is
typically only granted for subjects that have had discussion and interest on
the dispatch mailing list.

So you are doing the right thing to get started, by beginning discussion on
the dispatch list. But it is unlikely that you can do anything about it
*formally* in live sessions in London. You might want to set yourself a goal
to generate sufficient interest to do something at the following ietf in
Toronto.

	Best wishes,
	Paul

On 2/5/14 1:39 AM, Jim Forster wrote:
> 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 
> 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.
> aspires to be the simplest way for a GSM/UMTS phone to make phone 
> calls to the SIP & PSTN world.
>
> 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.
>

---

From: tim panton <[email-masked]>
Date: Wed, 5 Feb 2014 15:39:01 +0000

> Is the end result of this improvements to the SIP or other IETF protocols?

Speaking entirely for myself (as one does in the IETF) I’d guess that the outcome might
be some small improvements in SIP and other protocols (SDP or RTP perhaps) due to the fact
that the usage is slightly out of the ordinary so may well trip an edge case or something.

> Or, does this attempt to standardize an architecture?

I’d like it to standardise an _interface_ so that multiple architectures can interoperate.

> Also, is there any IPR attached to this?

I’ll let Jim answer that when he wakes up in India, but as an old (but lapsed) IETF hand I’m sure 
he’s aware of the IPR rules.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 5 Feb 2014 15:56:28 +0000

A good question for you to answer would be as to which of the requirements of 3GPP TS 22.228 you would support and which you would not support.

http://www.3gpp.org/DynaReport/22228.htm

These requirements led to the development of IMS as it is now, and the IMS architecture is as it is because of those requirements.

How much are you trying to design something new, versus integrating a P-CSCF and a BTS economically in the same box, which network virtualisation will ultimately do?

regards

Keith Drage

________________________________
From: dispatch [mailto:[email-masked]] On Behalf Of Jim Forster
Sent: 05 February 2014 06:40
To: [email-masked]
Subject: [dispatch] SIP and GSM/UMTS with OpenBTS

Dear DISPATCH group,

* Is IETF an appropriate forum for this, or should it be in 3GPP, or Sipforum.org<http://Sipforum.org>,  or a separate industry group formed?

Yours,

Jim Forster
Range Networks

---

From: Jim Forster <[email-masked]>
Date: Wed, 5 Feb 2014 17:58:50 +0000

> I’d like it to standardise an _interface_ so that multiple architectures can interoperate.

Agreed.

> he’s aware of the IPR rules.

Yes, lapsed IETF hand and certainly older now, so I should review the rules, etc.  I certainly believe there's no lurking patent issues from Range Networks.  I'll double check on that as well.

 -- Jim

---

From: Jim Forster <[email-masked]>
Date: Wed, 5 Feb 2014 18:16:03 +0000

> http://www.3gpp.org/DynaReport/22228.htm

Wow, that would be quite a job!  Well, I guess it should be looked at.

Yes, but it starts out with the title:

> Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS); Stage 1

Offhand, I don't immediately see the need to have such a thing as an "Internet Protocol (IP) multimedia core network subsystem". OK, certainly a large community (3GPP) does, which is fine and I use that stuff all the time on my phone and so am happy/grateful that it works, but does the rest of the Internet community accept those requirements for other things? What's the boundary for those requirements?  Are they a part of some RTAI or other IETF spec?  I think lots of interesting multimedia activity and specs happen without conformance to those particular requirements.  I'll readily admit to a lot of ignorance and naiveté, but it doesn't seem SIP or WebRTC aspires to support those requirements.  To some degree, OpenBTS is just trying to connect a bunch of nice phones with an OK air interface, to the Internet architecture, which another large set of people seem to like.

OK, I'll duck while the missiles fly overhead :-)
.
>  How much are you trying to design something new, versus integrating a P-CSCF and a BTS economically in the same box, which network virtualisation will ultimately do?

Umm, I don't  know what a P-CSCF is, so I'll have to look into it, or please help me/us.

 -- Jim

---

From: Harvind Samra <[email-masked]>
Date: Wed, 5 Feb 2014 19:00:40 +0000

I’ve run into very few mobile folks who think IMS was a good idea.  One of the chief reasons is that SIP, upon which IMS was developed, is a verbose/chatty protocol that occupies way too much bandwidth.

Some of the alternatives may be webRTC, DIAMETER…

On Feb 5, 2014, at 10:16 AM, Jim Forster <[email-masked]<mailto:[email-masked]>> wrote:

 -- Jim

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

Harvind Samra
Founder, CTO
Range Networks
San Francisco, CA
____________________________________________

Cellular networks made simple and affordable.
http://www.rangenetworks.com<http://www.rangenetworks.com/>
____________________________________________

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 5 Feb 2014 20:13:32 +0000

I've run into very few mobile folks who think IMS was a good idea.  One of the chief reasons is that SIP, upon which IMS was developed, is a verbose/chatty protocol that occupies way too much bandwidth.
[Raju] I am not sure what these "mobile folks" think about alternatives like XMPP?! :) Not knowing XMPP I think it is complicated!

Some of the alternatives may be webRTC, DIAMETER...

[Raju] WebRTC is NOT a signaling protocol!! Neither Diameter is!! WebRTC only deals with bearer representation (via SDP) and transport while diameter is an "authentication, authorization, and accounting" protocol and not suitable for signaling. That's pretty much leaves us with, whether we like it or not, SIP. Trying to come up with another protocol (and architecture) is like reinventing the SIP/IMS-wheel in another form, which may not please the same folks who don't like IMS/SIP.
We can surely debate on chatty nature of SIP, which I really don't think that chatty. SIP does many things like routing, signaling NAT traversal facilitation, topology hiding, SDP transport etc.  I believe, the SDP is the one which makes it look "chatty", rest of them are headers just like HTTP headers (they are even designed after HTTP/SMTP).
Btw, though it is not signaling, WebRTC is far from simple!! Basically, "it's the devil you know vs. the angel you don't now!"!! :)

-Raju

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 5 Feb 2014 21:43:08 +0000

The requirements cover things like whether you support subscriptions, support roaming between operators, support charging of sessions as opposed to just charging for bandwidth or whatever. That is what you need to identify in order to design a system.

Core network is a 3GPP definition. It is all equipment that is not part of the access network (i.e. not GERAN or UTRAN or E-UTRAN). For what you are talking about, the access network provides an means of communicating using IP, nothing more. So you need a core network. 3GPP may not define it, but as soon as you say something is an activity above IP, a call/session control entity of some sort, that is a core network.

The P-CSCF is an inbound and outbound proxy. It also provides an endpoint for security mechanisms. It also provides the endpoint for policy control for the access network - with restricted bandwidth you may well need that policy control. The definitions are in 3GPP TS 23.228.

http://www.3gpp.org/DynaReport/23228.htm

but you can find a summary (incomplete) in

https://datatracker.ietf.org/doc/rfc4083/

regards

Keith

________________________________
From: Jim Forster [mailto:[email-masked]]
Sent: 05 February 2014 18:16
To: DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: SIP and GSM/UMTS with OpenBTS

 -- Jim

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 5 Feb 2014 21:43:09 +0000

I believe it was someone from rangenetworks that said:

"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. "

If you meant something else, then perhaps...

But in any case, the questions I asked about requirements apply to any protocol. The key parts of 3GPP TS 22.228 were written before SIP was identified as a protocol to support the requirements. amd H.323 was still in the frame.

regards

Keith Drage

________________________________
From: Harvind Samra [mailto:[email-masked]]
Sent: 05 February 2014 19:01
To: Jim Forster
Cc: DRAGE, Keith (Keith); [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

 -- Jim

Harvind Samra
Founder, CTO
Range Networks
San Francisco, CA

---

From: James Winterbottom <[email-masked]>
Date: Thu, 6 Feb 2014 09:21:35 +1100

DIAMETER is used to carry signalling information through out IMS.

On 6 Feb 2014, at 7:13 am, Makaraju, Maridi Raju (Raju) <[email-masked]> wrote:

> 
>  
> [Raju] WebRTC is NOT a signaling protocol!! Neither Diameter is!! WebRTC only deals with bearer representation (via SDP) and transport while diameter is an “authentication, authorization, and accounting“ protocol and not suitable for signaling. That’s pretty much leaves us with, whether we like it or not, SIP. Trying to come up with another protocol (and architecture) is like reinventing the SIP/IMS-wheel in another form, which may not please the same folks who don’t like IMS/SIP.
> We can surely debate on chatty nature of SIP, which I really don’t think that chatty. SIP does many things like routing, signaling NAT traversal facilitation, topology hiding, SDP transport etc.  I believe, the SDP is the one which makes it look “chatty”, rest of them are headers just like HTTP headers (they are even designed after HTTP/SMTP).
> Btw, though it is not signaling, WebRTC is far from simple!! Basically, “it’s the devil you know vs. the angel you don’t now!”!! J
>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 5 Feb 2014 22:31:30 +0000

DIAMETER is used to carry signalling information through out IMS.
[Raju] Which interface? and what kind of signaling? To the best of my knowledge, diameter is only used for "authentication, authorization, and accounting". The Rx diameter interface used between P-CSCF and PCRF is not really call processing related signaling but rather used for "authorization" of the media flow.

-Raju

---

From: James Winterbottom <[email-masked]>
Date: Thu, 6 Feb 2014 09:32:37 +1100

Check out SLh.
Check out SLg

On 6 Feb 2014, at 9:31 am, Makaraju, Maridi Raju (Raju) <[email-masked]> wrote:

> [Raju] Which interface? and what kind of signaling? To the best of my knowledge, diameter is only used for “authentication, authorization, and accounting“. The Rx diameter interface used between P-CSCF and PCRF is not really call processing related signaling but rather used for “authorization” of the media flow.
>  
> -Raju

---

From: Michael Hammer <[email-masked]>
Date: Wed, 5 Feb 2014 22:34:01 +0000

Could we take debates about 3GPP off-line?

Seems to be getting off-topic.

Michael Hammer

Principal Engineer

 <mailto:[email-masked]> [email-masked]

Mobile: +1 408-202-9291

Milpitas, CA 95035 USA

From: dispatch [mailto:[email-masked]] On Behalf Of James
Winterbottom
Sent: Wednesday, February 05, 2014 5:33 PM
To: Makaraju, Maridi Raju (Raju)
Cc: [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

Check out SLh.

Check out SLg

On 6 Feb 2014, at 9:31 am, Makaraju, Maridi Raju (Raju)
<[email-masked]> wrote:

[Raju] Which interface? and what kind of signaling? To the best of my
knowledge, diameter is only used for "authentication, authorization, and
accounting". The Rx diameter interface used between P-CSCF and PCRF is not
really call processing related signaling but rather used for "authorization"
of the media flow.

-Raju

---

From: Mary Barnes <[email-masked]>
Date: Wed, 5 Feb 2014 17:00:11 -0600

I don't necessarily think 3GPP is out of scope in that I think it's very
important that if IETF decides that we will be documenting or even defining
protocol elements to support OpenBTS, it needs to be clear why 3GPP Call
control/SIP specifications aren't being used.

In offline in discussions with the proponents, it's my understanding that
OpenBTS is being used in very specific environments where there is no full
MSC deployments (i.e., remote locations that have no deployed IMS
networks).  The intent isn't to replicate a full IMS system, but rather to
provide basic connectivity to the Internet and use SIP in a non-IMS context
to complete the calls.   So, I think more detail about this context would
be very helpful.

I think it would really help if there were some diagrams showing what IMS
protocols are being used.  My understanding is that current implementations
have various ways in which they are interworking the Radio Layer Call
Control messages to SIP messages.  I think the motivation is to improve
interop by defining a consistent "mapping" if you will.  It's not clear to
me how exactly registration is being handled - perhaps mapping some of the
Radio Layer mobility management messages.   My understanding is that there
can be no change to the existing messages from the cell phone to the BTS
for obvious reasons, so all the interworking needs to happen in the BTS.

Regards,
Mary.

On Wed, Feb 5, 2014 at 4:34 PM, Michael Hammer <[email-masked]
> wrote:

> *Michael Hammer*
> *Principal Engineer*
> [email-masked] <[email-masked]>*
>
> *Mobile: *+1 408-202-9291
>
> *From:* dispatch [mailto:[email-masked]] *On Behalf Of *James
> Winterbottom
> *Sent:* Wednesday, February 05, 2014 5:33 PM
> *To:* Makaraju, Maridi Raju (Raju)
> *Cc:* [email-masked]
> *Subject:* Re: [dispatch] SIP and GSM/UMTS with OpenBTS
>
>
>
> Check out SLh.
>
> Check out SLg
>
>
>
> *[Raju] Which interface? and what kind of signaling? To the best of my
> really call processing related signaling but rather used for
> "authorization" of the media flow.*
>
>
>
> *-Raju*
>
>
>

---

From: Michael Hammer <[email-masked]>
Date: Wed, 5 Feb 2014 23:19:35 +0000

Mary,

What I was hoping to avoid was full-blown tutorials on 3GPP and IMS.

As well as discussion about what parts of 3GPP are signaling versus
something else.

Distinguishing what the impacts of OpenBTS on SIP are versus what is in use
for 3GPP 

could clarify if we would be doing the same thing but with redundant
headers, for example, would be useful.

Just didn't want to lose sight of the touchstone (how does this impact SIP).

Michael Hammer

Principal Engineer

Mobile: +1 408-202-9291

Milpitas, CA 95035 USA

From: Mary Barnes [mailto:[email-masked]] 
Sent: Wednesday, February 05, 2014 6:00 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

In offline in discussions with the proponents, it's my understanding that
OpenBTS is being used in very specific environments where there is no full
MSC deployments (i.e., remote locations that have no deployed IMS networks).
The intent isn't to replicate a full IMS system, but rather to provide basic
connectivity to the Internet and use SIP in a non-IMS context to complete
the calls.   So, I think more detail about this context would be very
helpful.  

I think it would really help if there were some diagrams showing what IMS
protocols are being used.  My understanding is that current implementations
have various ways in which they are interworking the Radio Layer Call
Control messages to SIP messages.  I think the motivation is to improve
interop by defining a consistent "mapping" if you will.  It's not clear to
me how exactly registration is being handled - perhaps mapping some of the
Radio Layer mobility management messages.   My understanding is that there
can be no change to the existing messages from the cell phone to the BTS for
obvious reasons, so all the interworking needs to happen in the BTS.  

Regards,

Mary. 

On Wed, Feb 5, 2014 at 4:34 PM, Michael Hammer
<[email-masked]> wrote:

Michael Hammer

Principal Engineer

Mobile: +1 408-202-9291

Milpitas, CA 95035 USA

Check out SLh.

Check out SLg

 

-Raju

---

From: Mary Barnes <[email-masked]>
Date: Wed, 5 Feb 2014 17:21:18 -0600

On Wed, Feb 5, 2014 at 5:19 PM, Michael Hammer <[email-masked]

> As well as discussion about what parts of 3GPP are signaling versus
[MB] Yes, I totally agree. Thanks for that clarification. [/MB]

>
>
> Distinguishing what the impacts of OpenBTS on SIP are versus what is in
> use for 3GPP
>
> *From:* Mary Barnes [mailto:[email-masked]]
> *Sent:* Wednesday, February 05, 2014 6:00 PM
> *To:* Michael Hammer
> *Cc:* [email-masked]; [email-masked];
> [email-masked]
>
> On Wed, Feb 5, 2014 at 4:34 PM, Michael Hammer <
> [email-masked]> wrote:
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 6 Feb 2014 00:18:38 +0000

To impact SIP we need some clearer requirements. Use of GERAN as an access technology hardly allows to concept of a network architecture.

That is where my points have been going.

3GPP started with a set of requirements, many of which will be applicable here, and we need to know which, and any additional ones.

Keith

________________________________
From: dispatch [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: 05 February 2014 23:21
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

On Wed, Feb 5, 2014 at 5:19 PM, Michael Hammer <[email-masked]<mailto:[email-masked]>> wrote:
Mary,

What I was hoping to avoid was full-blown tutorials on 3GPP and IMS.
As well as discussion about what parts of 3GPP are signaling versus something else.
[MB] Yes, I totally agree. Thanks for that clarification. [/MB]

Distinguishing what the impacts of OpenBTS on SIP are versus what is in use for 3GPP
could clarify if we would be doing the same thing but with redundant headers, for example, would be useful.

Michael Hammer
Principal Engineer
[email-masked]<mailto:[email-masked]>
Mobile: +1 408-202-9291<tel:408-202-9291>
500 Yosemite Drive Suite 120
Milpitas, CA 95035 USA

From: Mary Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, February 05, 2014 6:00 PM
To: Michael Hammer
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

I don't necessarily think 3GPP is out of scope in that I think it's very important that if IETF decides that we will be documenting or even defining protocol elements to support OpenBTS, it needs to be clear why 3GPP Call control/SIP specifications aren't being used.

In offline in discussions with the proponents, it's my understanding that OpenBTS is being used in very specific environments where there is no full MSC deployments (i.e., remote locations that have no deployed IMS networks).  The intent isn't to replicate a full IMS system, but rather to provide basic connectivity to the Internet and use SIP in a non-IMS context to complete the calls.   So, I think more detail about this context would be very helpful.

I think it would really help if there were some diagrams showing what IMS protocols are being used.  My understanding is that current implementations have various ways in which they are interworking the Radio Layer Call Control messages to SIP messages.  I think the motivation is to improve interop by defining a consistent "mapping" if you will.  It's not clear to me how exactly registration is being handled - perhaps mapping some of the Radio Layer mobility management messages.   My understanding is that there can be no change to the existing messages from the cell phone to the BTS for obvious reasons, so all the interworking needs to happen in the BTS.

Regards,
Mary.

On Wed, Feb 5, 2014 at 4:34 PM, Michael Hammer <[email-masked]<mailto:[email-masked]>> wrote:
Could we take debates about 3GPP off-line?
Seems to be getting off-topic.

Michael Hammer
Principal Engineer
[email-masked]<mailto:[email-masked]>
Mobile: +1 408-202-9291<tel:408-202-9291>
500 Yosemite Drive Suite 120
Milpitas, CA 95035 USA

From: dispatch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of James Winterbottom
Sent: Wednesday, February 05, 2014 5:33 PM
To: Makaraju, Maridi Raju (Raju)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

Check out SLh.
Check out SLg

On 6 Feb 2014, at 9:31 am, Makaraju, Maridi Raju (Raju) <[email-masked]<mailto:[email-masked]>> wrote:

-Raju

---

From: Jim Forster <[email-masked]>
Date: Thu, 6 Feb 2014 01:46:26 +0000

Mary, all,

Lots to read and consider.  I'll be offline for 12 hours as we drive to Delhi.

> I don't necessarily think 3GPP is out of scope in that I think it's very important that if IETF decides that we will be documenting or even defining protocol elements to support OpenBTS, it needs t…

Umm, one possible reason but I need to read and think, would be the question of whether 3GPP Call control/SIP is in some ways tied to 4G/LTE in some way.  OpenBTS puts 2G/3G phones on the Internet.

> In offline in discussions with the proponents, it's my understanding that OpenBTS is being used in very specific environments where there is no full MSC deployments (i.e., remote locations that hav…

Yes, that's correct.  No full MSC; in fact only Asterix or Freeswitch or Yate, usually embedded in the same device as the RF and signaling.

The goal was and is to make really small, low power, devices that can be deployed where classic systems don't fit, usually because they cost too much and take too much power.  Small islands, Antarctic research stations, the jungle of Paupua Indonesia, etc. 

This very reduced system, which might possibly be called IMS Lite for 2G/3G phones, seems to be very useful to people that want to make calls and send SMS in those places.  It's not clear (largely because of my ignorance) how a full IMS benefits those scenarios, while the simple OpenBTS translation/gateway of 2G & 3G calls to SIP is a package that people want.  Well, to be clear, people with phones don't care what protocols are used, they care about other aspects, like power and cost.

> I think it would really help if there were some diagrams showing what IMS protocols are being used.

Well, I can certainly provide some diagrams that show how the system works.

>  My understanding is that current implementations have various ways in which they are interworking the Radio Layer Call Control messages to SIP messages.  I think the motivation is to improve interop by defining a consistent "mapping" if you will.

Correct.

>  It's not clear to me how exactly registration is being handled - perhaps mapping some of the Radio Layer mobility management messages.   My understanding is that there can be no change to the existing messages from the cell phone to the BTS for obvious reasons, so all the interworking needs to happen in the BTS.  

Correct.

  -- Jim

---

From: Michael Hammer <[email-masked]>
Date: Thu, 6 Feb 2014 02:39:34 +0000

Interesting.  But, the 4G/LTE network is an IP internet of sorts.
The SIP/IMS components do not need to be in the radio network, 
and thus not at the locations where the power is constrained.

But, I'll mind my own suggestion and not go there.

Michael Hammer
Principal Engineer

-----Original Message-----
From: Jim Forster [mailto:[email-masked]] 
Sent: Wednesday, February 05, 2014 8:46 PM
To: Mary Barnes
Cc: Michael Hammer; [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

Mary, all,

Lots to read and consider.  I'll be offline for 12 hours as we drive to
Delhi.

Umm, one possible reason but I need to read and think, would be the question
of whether 3GPP Call control/SIP is in some ways tied to 4G/LTE in some way.
OpenBTS puts 2G/3G phones on the Internet.

Yes, that's correct.  No full MSC; in fact only Asterix or Freeswitch or
Yate, usually embedded in the same device as the RF and signaling.

The goal was and is to make really small, low power, devices that can be
deployed where classic systems don't fit, usually because they cost too much
and take too much power.  Small islands, Antarctic research stations, the
jungle of Paupua Indonesia, etc. 

This very reduced system, which might possibly be called IMS Lite for 2G/3G
phones, seems to be very useful to people that want to make calls and send
SMS in those places.  It's not clear (largely because of my ignorance) how a
full IMS benefits those scenarios, while the simple OpenBTS
translation/gateway of 2G & 3G calls to SIP is a package that people want.
Well, to be clear, people with phones don't care what protocols are used,
they care about other aspects, like power and cost.

> I think it would really help if there were some diagrams showing what IMS
protocols are being used.

>  My understanding is that current implementations have various ways in
which they are interworking the Radio Layer Call Control messages to SIP
messages.  I think the motivation is to improve interop by defining a
consistent "mapping" if you will.

Correct.

>  It's not clear to me how exactly registration is being handled - perhaps
mapping some of the Radio Layer mobility management messages.   My
understanding is that there can be no change to the existing messages from
the cell phone to the BTS for obvious reasons, so all the interworking needs
to happen in the BTS.  

Correct.

  -- Jim

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 6 Feb 2014 14:14:57 -0500 (EST)

It's certainly an interesting project.

It looks to me like you're looking for support in regard to which SIP
standards the user agent should support.  The best practices of
implementing SIP user agents, as it were.  If you are making an
organized project of this, I can see the value of clearly documenting
it.

> Use of SIP Re-invite for hand-over when a mobile phone moves from
> one BTS to a neighbor

In practice, I would expect INVITE-with-Replaces to be used for
handovers.  But I suspect that you haven't designed how to do
handovers yet.  That's going to be an interesting problem...

Dale

---

From: Tim Panton new <[email-masked]>
Date: Fri, 7 Feb 2014 12:45:45 +0000

> and thus not at the locations where the power is constrained.

One of the nice properties of an openBTS install in a remote location is that it
can still function as a local 'pbx' at times when the internet link is down. This turns out to 
be fabulously useful in a crisis. If you delegate all the logic out to a cloud service that stops being true.

Tim.

---

From: Gullik Webjörn <[email-masked]>
Date: Fri, 07 Feb 2014 15:11:48 +0100

> be fabulously useful in a crisis. If you delegate all the logic out to a cloud service that stops being true.
I agree violently, the challenge here is to design the distributed 
protocol(s) add-ons that would enable
building a sip/GSM network out of hundreds or more autonomous BTS's.

Gullik

---

From: Jim Forster <[email-masked]>
Date: Fri, 7 Feb 2014 18:56:20 +0000

> I agree violently, the challenge here is to design the distributed protocol(s) add-ons that would enable

I agree mostly with both of you:

 * Standalone/disconnected OpenBTS's have good value in emergency response or remote work environments.  Turn it on phones in the footprint can call each other; no backhaul or Core Network.  In some cases that are connected, over a thin link, there is a great bandwidth savings, and reliability improvement, by having a local switch.  I believe the Antarctic research station paid for its OpenBTS in a few months of operation, due to savings in satellite bandwidth over the GSM standard approach with the BSC/MSC on the other side of the satellite link. Plus, solar storms would knock out the link and and disable even local calls.

 * There are indeed challenges (and value) in large networks

I still owe the list a diagram which would facilitate understanding and discussion.

  -- JIm

---

From: Jim Forster <[email-masked]>
Date: Mon, 10 Feb 2014 04:34:43 +0000

> Well, I can certainly provide some diagrams that show how the system works.

Much delayed; apologies.  It's a bit simplified, and where it calls out Asterix, one should read "any SIP switching module".

For those of you that are inclined to read code, it's all available, as well as web site, mailing list, and wiki.  OpenBTS.org, [email-masked], https://wush.net/trac/rangepublic.  We plan on bringing a Dev Kit and can demo somewhere.

  -- Jim

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 10 Feb 2014 14:25:51 +0000

I suspect one problems with your ideas is that GSM operates in licensed spectrum. Is your idea that some individuals, rather than an operator owning the spectrum, should set up the network? If so, I expect you will face regulatory issues in less remote places than the Antarctic.

Regards, Thomas

----------------------------------
Dr. Thomas Belling 
3GPP Standardisation
NSN

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of ext Jim Forster
Sent: Friday, February 07, 2014 7:56 PM
To: Gullik Webjörn
Cc: [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

>>> The SIP/IMS components do not need to be in the radio network, and 
>>> thus not at the locations where the power is constrained.
>> One of the nice properties of an openBTS install in a remote location 
>> is that it can still function as a local 'pbx' at times when the 
>> internet link is down. This turns out to be fabulously useful in a crisis. If you delegate all the logic out to a cloud service that stops being true.
>> 
>> Tim.
> protocol(s) add-ons that would enable building a sip/GSM network out of hundreds or more autonomous BTS's.
> 
> Gullik

  -- JIm

---

From: Jim Forster <[email-masked]>
Date: Mon, 10 Feb 2014 15:07:25 +0000

> I suspect one problems with your ideas is that GSM operates in licensed spectrum. Is your idea that some individuals, rather than an operator owning the spectrum, should set up the network? If so,…

I suspect one problem with standard 3GPP IMS equipment is that it's too expensive and power hungry for smaller locations. :-) 

By all means conformance with laws is required.  In some cases (Sweden, UK? Netherlands?) there are unlicensed bands, which used to be DECT guard bands.  But more typically carriers with spectrum licenses are looking for an economical way to get into rural areas.

 -- Jim

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 10 Feb 2014 08:20:09 -0700

One quick question on the figure, I understand that SMQueue forward SMS as SIP Messages messages, and I understand Asterisk but can you give me the one line version of what SAS does?

On Feb 9, 2014, at 9:34 PM, Jim Forster <[email-masked]> wrote:

> <OpenBTS Diagram for DISPATCH.pdf>
> 
>

---

From: Jim Forster <[email-masked]>
Date: Mon, 10 Feb 2014 15:35:39 +0000

> One quick question on the figure, I understand that SMQueue forward SMS as SIP Messages messages, and I understand Asterisk but can you give me the one line version of what SAS does?

SIP Authentication Services.

 -- Jim

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 10 Feb 2014 17:56:40 +0000

If I follow this diagram correctly, you claim to have collapsed the HLR into your BTS. Your BTS apparently have no communication shown with each other. This means you each subscriber is limited to a single BTS with no roaming between them.

To sumamrise, this diagram tells us nothing about what you want to do with your architecture, unless you really want no service capabilities at all.

Can you please start answering some of the questions I asked earlier.

Keith Drage

> Sent: 10 February 2014 04:35
> To: Mary Barnes
> Cc: [email-masked]
> >> I think it would really help if there were some diagrams 
> showing what IMS protocols are being used.
> > 
> Much delayed; apologies.  It's a bit simplified, and where it 
> calls out Asterix, one should read "any SIP switching module".
> 
> For those of you that are inclined to read code, it's all 
> available, as well as web site, mailing list, and wiki.  
> OpenBTS.org, [email-masked], 
> https://wush.net/trac/rangepublic.  We plan on bringing a Dev 
> Kit and can demo somewhere.
> 
> 
>   -- Jim
> 
>

---

From: Tim Panton new <[email-masked]>
Date: Mon, 10 Feb 2014 18:28:00 +0000

> If I follow this diagram correctly, you claim to have collapsed the HLR into your BTS. Your BTS apparently have no communication shown with each other. This means you each subscriber is limited to…

I think you are assuming a specific solution to a specific problem. 
Many ITSPs allow SIP  registrations to a DID/account to come from dynamic IPs. So the necessary 'communication' can be 
implemented via the ITSP's normal functions. So when a user moves from the BTS in village A to the BTS  in village B 
their DID travels with them.

Sure you wouldn't get the ability for an arbitrary GSM SIM to roam into the network
and be billed to their home network. 

But realistically that sort of roaming isn't really a technical problem, it is predominantly a legal/commercial one.

Tim.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 10 Feb 2014 18:43:46 +0000

I am not assuming a specific solution - what we are all trying to find out is how much of 3GPP GERAN is actually being used, and what identities relate to what.

So you will have a UICC - because it is a 3GPP GERAN access network, but will not have any roaming that relates to the UICC, or the identities on that UICC.

But as far as I can see from the architecture given, the service is limited to a single BTS. That means that (for the solution you identify below) an operator with multiple BTSs will assign their users to a single BTS and the collation of charging/accounting will have to be from each individual BTS, back to some central entity (not shown). 

You will not be running the 3GPP mobility management protocols between BTS.

Keith Drage

> From: Tim Panton new [mailto:[email-masked]] 
> Sent: 10 February 2014 18:28
> To: DRAGE, Keith (Keith)
> Cc: Jim Forster; Mary Barnes; [email-masked]
> > If I follow this diagram correctly, you claim to have 
> collapsed the HLR into your BTS. Your BTS apparently have no 
> communication shown with each other. This means you each 
> subscriber is limited to a single BTS with no roaming between them.
> 
> Many ITSPs allow SIP  registrations to a DID/account to come 
> from dynamic IPs. So the necessary 'communication' can be 
> implemented via the ITSP's normal functions. So when a user 
> moves from the BTS in village A to the BTS  in village B 
> Sure you wouldn't get the ability for an arbitrary GSM SIM to 
> roam into the network and be billed to their home network. 
> 
> But realistically that sort of roaming isn't really a 
> technical problem, it is predominantly a legal/commercial one.
> 
> Tim.

---

From: Kurtis Heimerl <[email-masked]>
Date: Tue, 11 Feb 2014 04:04:46 +0900

You're misreading the diagram. As can be seen, multiple OpenBTS instances
can talk to a single instance of the SAS. This allows for centralized
charging and accounting for multiple BTS instances wherever the SAS is
hosted.

As far as the 3GPP mobility management protocols (if I know which ones you
are speaking of), those are converted to SIP (as is everything) and sent to
the SAS. So I would say we are using these protocols between BTSs,
especially for handover.

On Tue, Feb 11, 2014 at 3:43 AM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> I am not assuming a specific solution - what we are all trying to find out
> is how much of 3GPP GERAN is actually being used, and what identities
> relate to what.
>
> So you will have a UICC - because it is a 3GPP GERAN access network, but
> will not have any roaming that relates to the UICC, or the identities on
> that UICC.
>
> But as far as I can see from the architecture given, the service is
> limited to a single BTS. That means that (for the solution you identify
> below) an operator with multiple BTSs will assign their users to a single
> BTS and the collation of charging/accounting will have to be from each
> individual BTS, back to some central entity (not shown).
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 10 Feb 2014 21:19:05 +0000

I'd contend that there is not enough information in the diagram to identify either point of view.

What I am beginning to understand is that the SIP registrar is not colocated with the BTS, and therefore the subscriber records for the GERAN usage are physically seaparate and distinct from those of the SIP usage. Therefore to add a subscriber to the system, tou have to update the HLR records in the BTS (and every BTS that is serving that user) and the records at the SIP registrar / location server.

Is there a requirement to correlate accounting records between the two usages?

Mobility management is not I assume converted to SIP. The original description said they would use REFER to do such functions. It has not been clear whether that is supported by a centralised function (at or distinct from the registrar / location server) or whether this is performed UE to UE. This needs to be clarified. I would very much suspect this is going to need the definition of some new protocol to indicate support of various capabilities (This is a special REFER because it comes from my other registration over a different proxy, and not any old REFER).

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kurtis Heimerl
Sent: 10 February 2014 19:05
To: DRAGE, Keith (Keith)
Cc: Tim Panton new; [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

You're misreading the diagram. As can be seen, multiple OpenBTS instances can talk to a single instance of the SAS. This allows for centralized charging and accounting for multiple BTS instances wherever the SAS is hosted.

As far as the 3GPP mobility management protocols (if I know which ones you are speaking of), those are converted to SIP (as is everything) and sent to the SAS. So I would say we are using these protocols between BTSs, especially for handover.

On Tue, Feb 11, 2014 at 3:43 AM, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:
I am not assuming a specific solution - what we are all trying to find out is how much of 3GPP GERAN is actually being used, and what identities relate to what.

Keith Drage

> From: Tim Panton new [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Jim Forster; Mary Barnes; [email-masked]<mailto:[email-masked]>
> On 10 Feb 2014, at 17:56, DRAGE, Keith (Keith)
> <[email-masked]<mailto:[email-masked]>> wrote:
>

---

From: Tim Panton new <[email-masked]>
Date: Tue, 11 Feb 2014 19:03:20 +0000

Here is an interesting presentation by Kurtis that will give you some feel for what these systems do:

https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/heimurl

It isn't directly related to the standardisation effort but is a great background info.

Tim.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 11 Feb 2014 19:55:24 +0000

This is interesting and useful research.

But, I would note that there are other power solutions for the BS.

But, I have to ask the question, 

why is this directed toward the IETF and not 3GPP or GSMA?

Looking forward to seeing the IETF protocol nexus.

Michael Hammer

Principal Engineer

Mobile: +1 408-202-9291

Milpitas, CA 95035 USA

From: dispatch [mailto:[email-masked]] On Behalf Of Tim Panton
new
Sent: Tuesday, February 11, 2014 2:03 PM
To: DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

Here is an interesting presentation by Kurtis that will give you some feel
for what these systems do:

https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/hei
murl

It isn't directly related to the standardisation effort but is a great
background info.

Tim.

---

From: Kurtis Heimerl <[email-masked]>
Date: Wed, 12 Feb 2014 06:31:12 +0900

Comments in line:

> identify either point of view.

This is not a "point of view". This is how the system is architected, as
shown in the diagram with the boxes under the OpenBTS box.

> What I am beginning to understand is that the SIP registrar is not
> colocated with the BTS, and therefore the subscriber records for the GERAN
> usage are physically seaparate and distinct from those of the SIP usage.
> Therefore to add a subscriber to the system, tou have to update the HLR
> records in the BTS (and every BTS that is serving that user) and the
> records at the SIP registrar / location server.
>
>

They can be physically separate, though they need not be. In most PBX
setups the subscriber records are read by the HLR (for authentication) and
PBX (for routing) from the same database. Again, this database and HLR
serves multiple BTSs, so each BTS does not need to be updated.

> Is there a requirement to correlate accounting records between the two

For the PBX and HLR, probably. It's definitely good practice.

>
> Mobility management is not I assume converted to SIP. The original
> description said they would use REFER to do such functions. It has not been
> clear whether that is supported by a centralised function (at or distinct
> from the registrar / location server) or whether this is performed UE to
> UE. This needs to be clarified. I would very much suspect this is going to
> need the definition of some new protocol to indicate support of various
> capabilities (This is a special REFER because it comes from my other
> registration over a different proxy, and not any old REFER).
>

In OpenBTS, the BTS itself acts as the UE within the network, as it bridges
between Um and SIP. For Handover, the current solution has the UEs forward
packets between BTSs when a phone is roaming. I believe it's not possible
to do through the PBX, though I can't remember why.

>
> regards
>
> Keith
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Kurtis
> Heimerl
> *Sent:* 10 February 2014 19:05
> *To:* DRAGE, Keith (Keith)
> *Cc:* Tim Panton new; [email-masked]
>
>  You're misreading the diagram. As can be seen, multiple OpenBTS
> instances can talk to a single instance of the SAS. This allows for
> centralized charging and accounting for multiple BTS instances wherever the
> SAS is hosted.
>
>  As far as the 3GPP mobility management protocols (if I know which ones
> you are speaking of), those are converted to SIP (as is everything) and
> sent to the SAS. So I would say we are using these protocols between BTSs,
> especially for handover.
>
>
>> I am not assuming a specific solution - what we are all trying to find
>> out is how much of 3GPP GERAN is actually being used, and what identities
>> relate to what.
>>
>> > <[email-masked]> wrote:
>> >

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 12 Feb 2014 11:01:52 -0500 (EST)

> From: Tim Panton new <[email-masked]>

> https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/heimurl

Though he's incorrect that the first cellular network was in 1991, it
was in 1979.  1991 is the first GSM cellular network.

> It isn't directly related to the standardisation effort but is a

It's interesting work, but I don't see its connection with SIP at all.

My assumption is that you're asking, "How do we mate the GSM
over-the-air protocol with SIP for backhaul?", that is, how do we
disconnect the cellular system from IMS and all that.  But if your
goal is to deploy base stations commercially, you're going to need the
call accounting infrastructure of IMS.

Dale

---

From: Tim Panton new <[email-masked]>
Date: Wed, 12 Feb 2014 16:45:34 +0000

> It's interesting work, but I don't see its connection with SIP at all.

As I said it isn't related to the standardisation, but rather to give some background
to the usage.

> call accounting infrastructure of IMS.

That's assuming a currently popular billing model. If all your customers were (for example) on an
all-you-can-eat tariff then you might not need IMS. Likewise if you only had 1000 customers, the
standard IMS solution is overkill. If you don't need roaming, then you may not want the full IMS stack.

So to take Kurtis's example there might be significant value in a phone service that allowed users to:
1) call within network (that's a potential 20 mile radius even for a single cell)
2) make emergency calls
3) receive external calls
4) all bound to a specific sim
5) sms to the world

- That could be associated with a small monthly fee to cover the infrastructure costs. 

Sure they'd like the full LTE experience - but (a - wifi probably does that better (b - LTE is too expensive.

The point is these systems don't attempt to replace existing services - they are generally put into
places and scenarios where the IMS 3gpp model doesn't work (for one reason or another). This is evidenced
by the fact that these places _aren't_ served yet.

I'm hoping we'll standardise the SIP interface towards the ITSP, either in the form of a set of recommendations
and possibly a new header field or two.
I'd also like see a standard (SIP? SCTP? SNMP?) interface between cells to help with handoff etc.

The point of standardisation is to allow many vendors to interoperate and ITSPs to offer service,
but not to restrict the use-case so much that
it exactly replicates something we _know_ isn't practical for these environments.

Tim.

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 13 Feb 2014 10:06:51 +0000

Hello Tim and all,

if I understood the proposal correctly, in comparison to 3GPP architecture you propose:

- UEs are unchanged

- BTS

                - uses regular Um reference point towards UEs

                - has a new SIP based interface replacing ABis reference point

- BSC, MSC, HSS, SM-SC, ... collapse into one functional entity "SAS/Asterisk/SMQueue". This new functional entity:

                - uses the new SIP based interface replacing ABis reference point towards BTS

                - uses another SIP based interface towards remote networks

Can you please clarify what's the intended business case where the proposed solution is supposed to be superior over the existing 3GPP solution?

E.g. can you please clarify whether you indent to specify a solution for:

a) carriers with license to use the licensed GSM bands?

b) individuals/corporates without license to use the licensed GSM bands?

c) anyone else?

The original mail suggested b) but then you referred to a) in your mail stating "But more typically carriers with spectrum licenses are looking for an economical way to get into rural areas."

If a), such solution can be deployed anywhere where there are existing GSM bands in use. However, it will likely require implementation of the full 3GPP feature set which carriers offer today, including supporting regulator's requirements, support of handovers, integration with other operator subsystems (e.g. billing, operation & maintenance subsystems, ...). Or do you believe that some existing requirements are unnecessary for deployments in carrier networks?

You seem to claim above that your proposal can be more economical than existing solution. Given that new protocol would need to be defined and functional entities newly developed and tested, I fail to see how this can be more economical than deployment of existing products which are already developed, tested, mass produced and mass deployed. Can you provide some numbers supporting your view?

https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/heimurl just proposes new functionality to be added, unrelated to any potential replacement of ABis reference point with SIP based interface.

If b), then such solution can be deployed only in countries where there is no license needed. You list Sweden as one with UK and Netherlands with question marks. Also Antarctica was mentioned.

Can you please provide a reference to regulators' document enabling usage of GSM bands without license in each of those countries?

How will interferences be avoided if several individuals/corporates start using the same GSM band in the same location, particularly if each starts using power enabling "potential 20 mile radius even for a single cell"?

Furthermore, even if all of Sweden, UK, Netherlands and Antarctica enable usage of GSM bands without license, this is still quite limited market. If the solution is limited only to those countries, even if the required feature set is smaller, there is little economies of scale.

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: Jim Forster <[email-masked]>
Date: Thu, 13 Feb 2014 11:46:22 +0000

Ivan, all,

Sorry for the relative quiet from me after starting what seems to be a vigorous discussion.

Yes, that's pretty much it.  Also noting that we are currently using this model with 2G & 3G phones.

Um, I thought that was pretty well covered.  No?  I can repeat what's been said if that will help.

Yes.

No.

c) anyone else?

If a), such solution can be deployed anywhere where there are existing GSM bands in use.

Right.

However, it will likely require implementation of the full 3GPP feature set which carriers offer today, including supporting regulator's requirements, support of handovers, integration with other operator subsystems (e.g. billing, operation & maintenance subsystems, ...).

It's not clear to me how all of that follows.

Or do you believe that some existing requirements are unnecessary for deployments in carrier networks?

Evidence indicates entities operating legally are willing to use this approach.  I don't know the definition of a carrier, or if that's relevant in this forum.   You probably see other evidence indicating a different conclusion.

 You seem to claim above that your proposal can be more economical than existing solution. Given that new protocol would need to be defined and functional entities newly developed and tested,

This is largely done already. See working code, at previously mentioned places.

We seek to document what has been done, while looking to the IETF community for guidance on additional aspects of the Internet usage today, such as IPv6, ICE, Security, etc.  I believe many of those, which are variously recommended or required on the Internet, will be quite useful in this case.

...more further down...

I fail to see how this can be more economical than deployment of existing products which are already developed, tested, mass produced and mass deployed. Can you provide some numbers supporting your view?

Kind regards

Ivo Sedlacek

Hmm?: is this policy consistent with IETF policies?   I will take it on good faith that it is, in which case it is unnecessary,  but going forward a positive affirmation would be useful.  Please affirm.

Yours,

Jim Forster

Range Networks.

This email is not confidential.  It is intended to used as part of the community discussion, and I recognize that all such discussion are a matter of public record.

---

From: Harvind Samra <[email-masked]>
Date: Thu, 13 Feb 2014 12:37:14 +0000

Hi Ivo,

I have to ask…why are the questions regarding frequency licensing and economics relevant?  This is a discussion regrading augmenting SIP.

On Feb 13, 2014, at 2:06 AM, Ivo Sedlacek <[email-masked]<mailto:[email-masked]>> wrote:

Hello Tim and all,

Kind regards

Ivo Sedlacek

Harvind Samra
Founder, CTO
Range Networks
San Francisco, CA

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 13 Feb 2014 14:34:15 +0000

Jumping in here, they are relevant in as much as there is no point in IETF working on this if there is no known market for it.

Usually those type of projects are published only on April 1st.

So all Ivo is asking is for you to justify that it is worth other people working on this as well as yourselves.

Perhaps if you identified the spectrum you believe is available for use in the the countries identified, that would be useful.

regards

Keith Drage

________________________________
From: dispatch [mailto:[email-masked]] On Behalf Of Harvind Samra
Sent: 13 February 2014 12:37
To: Ivo Sedlacek
Cc: [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

Hi Ivo,

I have to ask...why are the questions regarding frequency licensing and economics relevant?  This is a discussion regrading augmenting SIP.

Hello Tim and all,

Harvind Samra
Founder, CTO
Range Networks
San Francisco, CA

---

From: Tim Panton new <[email-masked]>
Date: Thu, 13 Feb 2014 14:49:30 +0000

> Perhaps if you identified the spectrum you believe is available for use in the the countries identified, that would be useful.

Ivo's employer seems to see a market for small cells, but looks to tie them to existing operator IMS's through 
internet connections "owned by themselves or a partner".
http://www.telecomlead.com/enterprise-networking/mwc-2014-ericsson-announce-small-cell-service-20233/
Perhaps that's an April fools joke too (I can't see any avian carriers mentioned though)?

It isn't up to the IETF to crown specific solutions. That's the market's job.

T.

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 13 Feb 2014 14:59:38 +0000

(the mail below is resent without the final line)

Hello Tim and all,

- UEs are unchanged

- BTS

c) anyone else?

Kind regards

Ivo Sedlacek

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 13 Feb 2014 15:00:02 +0000

Hello Jin and Samra,

> > b) individuals/corporates without license to use the licensed GSM bands?

OK, thanks for clarification.

> Evidence indicates entities operating legally are willing to use this approach.  I don't know the definition of a carrier,
> or if that's relevant in this forum.   You probably see other evidence indicating a different conclusion.

Can you please point me to such evidence indicating "entities operating legally are willing to use this approach"?

Can you please indicate which existing requirements defined for the existing 3GPP solution you believe are not necessary in your solution, when deployed by an operator with a license to use the licensed GSM bands? If no such unnecessary requirement is identified, your solution will end up with the same complexity as the existing 3GPP solution.

You stated "But more typically carriers with spectrum licenses are looking for an economical way to get into rural areas.".  Can you please provide any numbers or other justification proving that your proposal is more economical than the existing 3GPP solution which is already developed, tested, mass produced and mass deployed and thus benefits from economies of scale?

Note that there is no preclusion in the existing 3GPP solution to provide one node encompassing BSC, MSC, HSS, SM-SC, ... so if that was considered useful, it could have been done with the existing 3GPP solution too.

> I have to ask...why are the questions regarding frequency licensing and economics relevant?  This is a discussion regrading augmenting SIP.

The point is to identify whether there is a relevant business case for the solution augmenting SIP. If there is none, why to spend meeting time and effort to standardize the solution?

Kind regards

Ivo Sedlacek

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 13 Feb 2014 15:28:37 +0000

Ericsson is not the only vendor that sees a market for small cells, but the expectation is that the products are built to the completed 3GPP standards will be deployed in licensed spectrum by owners of that spectrum, although the boxes may well be owned by 3rd parties.

These deployments already exist.

I see Jim has now identified that this proposal is for licensed GSM operators in licensed GSM space.

Personally, I would suggest if you believe the operators should be picking this up, you take it to 3GPP where the operators are actually present. That is the only way you will see it taken up by GSMA, which you will need to obtain interoperator agreements to use this (e.g. roaming, shared networks). 3GPP them works with IETF on any SIP extensions needed.

I would only see IETF having any direct part in this if the proposal was only to use unlicensed spectrum by enterprises rather than licensed operators, which Jim has negated.

regards

Keith

________________________________
From: Tim Panton new [mailto:[email-masked]]
Sent: 13 February 2014 14:50
To: DRAGE, Keith (Keith)
Cc: Harvind Samra; Ivo Sedlacek; [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:

regards

Keith Drage

T.

---

From: "Ralph A. Schmid, dk5ras" <[email-masked]>
Date: Thu, 13 Feb 2014 16:28:23 +0100

I see the purpose of such systems in not-so-developed countries, and
especially in very remote areas of those.

Usually the commercial providers have no interest in covering those, as
there is no revenue from doing so, and 

especially in such countries often the government is not willing to force
operators to cover an area, and/or they 

are not willing/able to enforce such a rule.

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.

Now there are two possibilities - the government does not care about
licenses, or they give a license to operate 

a local network. This is not our problem here, we are techs, no bureaucrats.

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. 

Very nice, people can call each other, can call the doctor when they are ill
and injured, the system runs locally 

just fine. 

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 is the time were some standards are needed. Open standards, cheap
standards, not a 3GPP IMS monster. We 

are not talking here about a nice and clean data center with racks full of
BSCs, MSCs and all that, we are talking 

about simple to maintain structures. It must be some technology a normal
computer guy everywhere in the world 

can understand after reading some manuals. SIP family of procedures was
chosen.

As far as I understand (don't blame when I'm wrong, I'm RF engineer, not a
SIP guy) at the moment the possible  

procedures are not standardized, some extensions or modifications need to be
defined, for being able to cope 

with this kind of mobility (handover etc.) and distributed network control.
This is the scope of this mail thread.

Such systems like described above are not dreams, such systems do exist,
they bring a large benefit to those 

people, micro economics evolve, emergency communication is established,
social interaction is improved.

Now imagine an earthquake or a similar catastrophe - the almost non-existent
infrastructure breaks down 

completely. Emergency teams show up, have no oversight what is happening.
But hey, they unload some 

boxes on top of a hill, fire up their BTS, link it to the headquarter, many
phones log into the system, and 

people can call for assistance, can tell what kind of help is needed in what
place, first responder teams can 

be sent to those places.

No fancy and shiny business, just live saving communication somewhere out in
the mud and dirt. Normal 

phone companies do not do this kind of work, but someone needs to. IETF may
be a small gear that makes 

this thing move a bit smoother - it is already moving, that is for sure,
with or without IETF  :-)

But I may be wrong...then just hit the DEL-button.

Ralph.

 

From: dispatch [mailto:[email-masked]] On Behalf Of DRAGE, Keith
(Keith)
Sent: Thursday, February 13, 2014 3:34 PM
To: Harvind Samra; Ivo Sedlacek
Cc: [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

Jumping in here, they are relevant in as much as there is no point in IETF
working on this if there is no known market for it.

So all Ivo is asking is for you to justify that it is worth other people
working on this as well as yourselves.

Perhaps if you identified the spectrum you believe is available for use in
the the countries identified, that would be useful.

regards

Keith Drage

  _____  

Hi Ivo, 

I have to ask.why are the questions regarding frequency licensing and
economics relevant?  This is a discussion regrading augmenting SIP.

On Feb 13, 2014, at 2:06 AM, Ivo Sedlacek <[email-masked]> wrote:

Hello Tim and all,

if I understood the proposal correctly, in comparison to 3GPP architecture
you propose:

- UEs are unchanged

- BTS

                - has a new SIP based interface replacing ABis reference
point

- BSC, MSC, HSS, SM-SC, ... collapse into one functional entity
"SAS/Asterisk/SMQueue". This new functional entity:

                - uses the new SIP based interface replacing ABis reference
point towards BTS

Can you please clarify what's the intended business case where the proposed
solution is supposed to be superior over the existing 3GPP solution?

c) anyone else?

The original mail suggested b) but then you referred to a) in your mail
stating "But more typically carriers with spectrum licenses are looking for
an economical way to get into rural areas."

If a), such solution can be deployed anywhere where there are existing GSM
bands in use. However, it will likely require implementation of the full
3GPP feature set which carriers offer today, including supporting
regulator's requirements, support of handovers, integration with other
operator subsystems (e.g. billing, operation & maintenance subsystems, ...).
Or do you believe that some existing requirements are unnecessary for
deployments in carrier networks?

You seem to claim above that your proposal can be more economical than
existing solution. Given that new protocol would need to be defined and
functional entities newly developed and tested, I fail to see how this can
be more economical than deployment of existing products which are already
developed, tested, mass produced and mass deployed. Can you provide some
numbers supporting your view?

<https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/he
imurl>
https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/hei
murl just proposes new functionality to be added, unrelated to any potential
replacement of ABis reference point with SIP based interface.

If b), then such solution can be deployed only in countries where there is
no license needed. You list Sweden as one with UK and Netherlands with
question marks. Also Antarctica was mentioned.

Can you please provide a reference to regulators' document enabling usage of
GSM bands without license in each of those countries?

How will interferences be avoided if several individuals/corporates start
using the same GSM band in the same location, particularly if each starts
using power enabling "potential 20 mile radius even for a single cell"?

Furthermore, even if all of Sweden, UK, Netherlands and Antarctica enable
usage of GSM bands without license, this is still quite limited market. If
the solution is limited only to those countries, even if the required
feature set is smaller, there is little economies of scale.

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the
basis of the terms set out at  <http://www.ericsson.com/email_disclaimer>
www.ericsson.com/email_disclaimer

_______________________________________________
dispatch mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/dispatch>
https://www.ietf.org/mailman/listinfo/dispatch

Harvind Samra

Founder, CTO

Range Networks

San Francisco, CA  

http://www.rangenetworks.com <http://www.rangenetworks.com/>

---

From: Jim Forster <[email-masked]>
Date: Thu, 13 Feb 2014 15:41:12 +0000

Keith,

Responding only one part for a clarification; it's late here and I don't want make any more mistakes.

And license-free space; see below.

OK, probably incorrectly, i read 'unlicensed' as ignoring licensing policy.  So to clarify:

Licensed Spectrum  -- Yes

License free (ex-DECT Guard bands in Sweden, etc.)  -- Yes

Illegal -- No

  -- Jim

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 13 Feb 2014 16:00:22 +0000

So you propose that IETF should write standards solely for an illegal activity?

One separate point I would make is that telecommunications represents a significant source of government income in 3rd world countries. Therefore any such activities would be rapidly cracked down on.

Keith

________________________________
From: Ralph A. Schmid, dk5ras [mailto:[email-masked]]
Sent: 13 February 2014 15:28
To: DRAGE, Keith (Keith); 'Harvind Samra'; 'Ivo Sedlacek'
Cc: [email-masked]
Subject: RE: [dispatch] SIP and GSM/UMTS with OpenBTS

I see the purpose of such systems in not-so-developed countries, and especially in very remote areas of those.

Usually the commercial providers have no interest in covering those, as there is no revenue from doing so, and
especially in such countries often the government is not willing to force operators to cover an area, and/or they
are not willing/able to enforce such a rule.

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.

Now there are two possibilities - the government does not care about licenses, or they give a license to operate
a local network. This is not our problem here, we are techs, no bureaucrats.

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.

Very nice, people can call each other, can call the doctor when they are ill and injured, the system runs locally
just fine.

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 is the time were some standards are needed. Open standards, cheap standards, not a 3GPP IMS monster. We
are not talking here about a nice and clean data center with racks full of BSCs, MSCs and all that, we are talking
about simple to maintain structures. It must be some technology a normal computer guy everywhere in the world
can understand after reading some manuals. SIP family of procedures was chosen.

As far as I understand (don't blame when I'm wrong, I'm RF engineer, not a SIP guy) at the moment the possible
procedures are not standardized, some extensions or modifications need to be defined, for being able to cope
with this kind of mobility (handover etc.) and distributed network control. This is the scope of this mail thread.

Such systems like described above are not dreams, such systems do exist, they bring a large benefit to those
people, micro economics evolve, emergency communication is established, social interaction is improved.

Now imagine an earthquake or a similar catastrophe - the almost non-existent infrastructure breaks down
completely. Emergency teams show up, have no oversight what is happening. But hey, they unload some
boxes on top of a hill, fire up their BTS, link it to the headquarter, many phones log into the system, and
people can call for assistance, can tell what kind of help is needed in what place, first responder teams can
be sent to those places.

No fancy and shiny business, just live saving communication somewhere out in the mud and dirt. Normal
phone companies do not do this kind of work, but someone needs to. IETF may be a small gear that makes
this thing move a bit smoother - it is already moving, that is for sure, with or without IETF  :-)

Ralph.

From: dispatch [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: Thursday, February 13, 2014 3:34 PM
To: Harvind Samra; Ivo Sedlacek
Cc: [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

regards

Keith Drage

Hello Tim and all,

Harvind Samra
Founder, CTO
Range Networks
San Francisco, CA

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 13 Feb 2014 16:00:52 +0000

Hello Jim,

I am confused with your responses.

> > b) individuals/corporates without license to use the licensed GSM bands?

If your intention is to provide a solution for individuals/corporates to be used in GSM bands where no license is needed, can you please answer the questions below:

Can you please provide a reference to regulators' document enabling usage of GSM bands without license in each of those countries where license is supposed to be not necessary? As far as I remember, you listed Sweden, UK with question mark, Netherlands with question mark, and Antarctica was also mentioned. I could have missed something.

Kind regards

Ivo Sedlacek

From: dispatch [mailto:[email-masked]] On Behalf Of Jim Forster
Sent: 13. února 2014 16:41
To: DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

Keith,

Licensed Spectrum  -- Yes

Illegal -- No

  -- Jim

---

From: Tim Panton new <[email-masked]>
Date: Thu, 13 Feb 2014 16:03:43 +0000

> License free (ex-DECT Guard bands in Sweden, etc.)  -- Yes

The Um radio protocol depends on having a working spectrum policy that isn't infringed. So it isn't possible to do a pure wifi-like
collision avoidance trick. Unlicensed in this context is a dirty word.

See 
http://babyis60.wordpress.com/2010/03/10/the-benefits-of-a-managed-spectrum/

T.

---

From: Tim Panton new <[email-masked]>
Date: Thu, 13 Feb 2014 16:16:41 +0000

> The point is to identify whether there is a relevant business case for the solution augmenting SIP. If there is none, why to spend meeting time and effort to standardize the solution?

It is unusual for the IETF to do a market analysis and business case before even discussing a possible standard.
I didn't see one about msrp-websocket for example.

Tim.

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 13 Feb 2014 17:26:37 +0100

> Jumping in here, they are relevant in as much as there is no point in IETF working on this if there is no known market for it.

Hi Keith,

are you suggesting that IETF processes shall only allow work on technologies
for which there is a known market?

I'm glad this was not the case in the past, otherwise I would not be able
to send a single email. At least I don't have memory of IETF business case
criteria for the SNMP protocol. If that shall change in the future, I would
like to know what is the specific IETF criteria for market existence. Can
you elaborate what these are supposed to be?

-jiri

p.s. one more question here: I understand your point that I'm eligible to read
emails to this WG mailing list that carry confidentiality notice on the grounds
of group memership. What I don't understand is whether I'm also permitted
(in departure from the notice) to forward such an email to some other email
address than that of the working group.

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 13 Feb 2014 16:57:52 +0000

The question should be:

	Should IETF work on a new solution for a market where a solution exists and the existing solution is equal or superior to the newly proposed one?

Argument for statement "the existing solution is equal or superior to the newly proposed one" is:
- the existing 3GPP solution is already developed, tested, mass produced and mass deployed and thus benefits from economies of scale.
- no existing 3GPP requirement was identified as unnecessary for the new solution so complexity of the existing solution and new solution is the same.

If you believe that statement "the existing solution is equal or superior to the newly proposed one" is incorrect, please prove it.

Kind regards

Ivo Sedlacek

-----Original Message-----
From: Jiri Kuthan [mailto:[email-masked]] 
Sent: 13. února 2014 17:27
To: DRAGE, Keith (Keith); Harvind Samra; Ivo Sedlacek
Cc: [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

Hi Keith,

are you suggesting that IETF processes shall only allow work on technologies for which there is a known market?

I'm glad this was not the case in the past, otherwise I would not be able to send a single email. At least I don't have memory of IETF business case criteria for the SNMP protocol. If that shall change in the future, I would like to know what is the specific IETF criteria for market existence. Can you elaborate what these are supposed to be?

-jiri

p.s. one more question here: I understand your point that I'm eligible to read emails to this WG mailing list that carry confidentiality notice on the grounds of group memership. What I don't understand is whether I'm also permitted (in departure from the notice) to forward such an email to some other email address than that of the working group.

---

From: Tim Panton new <[email-masked]>
Date: Thu, 13 Feb 2014 17:19:04 +0000

> 	Should IETF work on a new solution for a market where a solution exists and the existing solution is equal or superior to the newly proposed one?

Actually, yes, on the off-chance the person making that evaluation could be wrong.

> If you believe that statement "the existing solution is equal or superior to the newly proposed one" is incorrect, please prove it.

Apples and oranges - If I want a continent spanning, roaming capable billion dollar GSM network, then I need an IMS system.
If I want an Um to SIP gateway I can run off solar power and hang in a tree, I'll go for an openBTS like solution.

They aren't comparable goals.

Tim.

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 13 Feb 2014 19:00:07 +0100

> 	Should IETF work on a new solution for a market where a solution exists and the existing solution is equal or superior to the newly proposed one?

A quick opinion of mine: I don't think the IETF should bother about this much.

There is a long record of technologies developed in the IETF that either
didn't have a business plan attached with them, or  did crash someone
else's business plan, or competed with other established or not-established
technologies  or even among each other. I think that's a good thing even
if some of the technologies turn not to be adopted later.

> - no existing 3GPP requirement was identified as unnecessary for the new solution so complexity of the existing solution and new solution is the same.

I'm afraid that business arguments are forward-looking, which in plain language
doesn't mean novel or futuristic but just uncertain and subjective. I suspect that
if we used such to restrict proposals when debating what to do in the IETF, we
would be on analog phones today :)

-jiri

---

From: Mary Barnes <[email-masked]>
Date: Thu, 13 Feb 2014 14:18:21 -0600

On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

>  Ericsson is not the only vendor that sees a market for small cells, but
> the expectation is that the products are built to the completed 3GPP
> standards will be deployed in licensed spectrum by owners of that spectrum,
> although the boxes may well be owned by 3rd parties.
>
> Personally, I would suggest if you believe the operators should be picking
> this up, you take it to 3GPP where the operators are actually present. That
> is the only way you will see it taken up by GSMA, which you will need to
> obtain interoperator agreements to use this (e.g. roaming, shared
> networks). 3GPP them works with IETF on any SIP extensions needed.
>
[MB] One big problem with this proposal is that you must be a member of
3GPP/GSMA to make contributions and to participate in meetings.

And, I think having to first do the work in 3GPP and then bring it to IETF
would introduce a tremendous delay for something that's already been
implemented/deployed.  While they are proposing to reuse elements and
protocols that are part of an IMS network, the core issue they have is with
interworking SIP with the radio layer protocols.  Certainly, one could
implement all the protocols that IMS uses and then use the 3GPP based specs
and proprietary headers to interwork with SIP in the Internet, but that
would be terribly inefficient.
[/MB]

>
> I would only see IETF having any direct part in this if the proposal was
> only to use unlicensed spectrum by enterprises rather than licensed
> operators, which Jim has negated.
>
> regards
>
> Keith
>
> *From:* Tim Panton new [mailto:[email-masked]]
> *Sent:* 13 February 2014 14:50
> *Cc:* Harvind Samra; Ivo Sedlacek; [email-masked]
>
>  Jumping in here, they are relevant in as much as there is no point in
> IETF working on this if there is no known market for it.
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Feb 2014 21:06:41 +0000

Mary,

I haven't followed this discussion, but: if this has "already been implemented/deployed", what is IETF expected to do? Have some problems, or additional requirements, come up from those implementations/deployments, that IETF is asked to help solving?

Also, if I understood Keith correctly, he didn't suggest going to GSMA just because he thinks it's a good thing to do - his claim was that one MUST go to GSMA in order to get certain things done :)

Regards,

Christer

Lähettäjä: dispatch [mailto:[email-masked]] Puolesta Mary Barnes
Lähetetty: 13. helmikuuta 2014 22:18
Vastaanottaja: DRAGE, Keith (Keith)
Kopio: [email-masked]
Aihe: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:
Ericsson is not the only vendor that sees a market for small cells, but the expectation is that the products are built to the completed 3GPP standards will be deployed in licensed spectrum by owners of that spectrum, although the boxes may well be owned by 3rd parties.

Personally, I would suggest if you believe the operators should be picking this up, you take it to 3GPP where the operators are actually present. That is the only way you will see it taken up by GSMA, which you will need to obtain interoperator agreements to use this (e.g. roaming, shared networks). 3GPP them works with IETF on any SIP extensions needed.
[MB] One big problem with this proposal is that you must be a member of 3GPP/GSMA to make contributions and to participate in meetings.

And, I think having to first do the work in 3GPP and then bring it to IETF would introduce a tremendous delay for something that's already been implemented/deployed.  While they are proposing to reuse elements and protocols that are part of an IMS network, the core issue they have is with interworking SIP with the radio layer protocols.  Certainly, one could implement all the protocols that IMS uses and then use the 3GPP based specs and proprietary headers to interwork with SIP in the Internet, but that would be terribly inefficient.
[/MB]

regards

Keith

________________________________
From: Tim Panton new [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 13 February 2014 14:50
To: DRAGE, Keith (Keith)
Cc: Harvind Samra; Ivo Sedlacek; [email-masked]<mailto:[email-masked]>

regards

Keith Drage

T.

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 13 Feb 2014 18:27:13 -0500 (EST)

> From: Jim Forster <[email-masked]>
> Date: Thu, 13 Feb 2014 11:46:22 +0000
> Accept-Language: en-US
> Cc: "[email-masked]" <[email-masked]>

Note that this e-mail was essentially unreadable because it is
difficult to keep straight what is being quoted (from whom?) and what
is Jim's new text.  Use the ">" convention for quoting previous
messages!

However, this does lead me to be able to phrase what I am still
unclear about:  What is it that you're trying to accomplish?  In what
way does SIP form a part of this project?

I notice that your messages are written from the point of view of
someone who is immersed in OpenBTS.  Remember, to a first
approximation, nobody here knows *anything* about OpenBTS, and a large
majority know little or nothing about IMS, 3GPP, or anything else
about the cellular infrastructure.

Have you settled on a technological structure for this project, or are
you at the stage of having business goals and still exploring
technologies?

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 13 Feb 2014 18:28:00 -0500 (EST)

> From: "Ralph A. Schmid, dk5ras" <[email-masked]>

(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

---

From: Kurtis Heimerl <[email-masked]>
Date: Fri, 14 Feb 2014 14:23:43 +0900

I've been traveling and there's a lot more thread, but I just wanted to
note that spectrum licenses aren't that difficult to acquire when the
primary carriers are unwilling to cover an area. Our research group (TIER)
had one for testing and the Rhizomatica network has one in rural Oaxaca
Mexico, as examples. Saying all of these networks are illegal is a gross
miscategorization and completely unfair.

On Fri, Feb 14, 2014 at 1:00 AM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> One separate point I would make is that telecommunications represents a
> significant source of government income in 3rd world countries. Therefore
> any such activities would be rapidly cracked down on.
>
> Keith
>
> *From:* Ralph A. Schmid, dk5ras [mailto:[email-masked]]
> *Sent:* 13 February 2014 15:28
> *To:* DRAGE, Keith (Keith); 'Harvind Samra'; 'Ivo Sedlacek'
> *Cc:* [email-masked]
> *Subject:* RE: [dispatch] SIP and GSM/UMTS with OpenBTS
>
> with this kind of mobility (handover etc.) and distributed network
> control. This is the scope of this mail thread.
>
>
>
> *From:* dispatch [mailto:[email-masked]] *On Behalf Of *DRAGE,
> Keith (Keith)
> *Sent:* Thursday, February 13, 2014 3:34 PM
> *To:* Harvind Samra; Ivo Sedlacek
> *Cc:* [email-masked]
> *From:* dispatch [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Harvind Samra
> *Sent:* 13 February 2014 12:37
> *To:* Ivo Sedlacek
> *Cc:* [email-masked]
> I have to ask...why are the questions regarding frequency licensing and
>   Hello Tim and
> all,
> Can you please clarify what's the intended business case where the
> proposed solution is supposed to be superior over the existing 3GPP
> solution?
>
> operator subsystems (e.g. billing, operation & maintenance subsystems,
> ...). Or do you believe that some existing requirements are unnecessary for
>  just proposes new functionality to be added, unrelated to any potential
> Can you please provide a reference to regulators' document enabling usage
> of GSM bands without license in each of those countries?
>
> basis of the terms set out at www.ericsson.com/email_disclaimer
>
> http://www.rangenetworks.com
>

---

From: Kurtis Heimerl <[email-masked]>
Date: Fri, 14 Feb 2014 14:27:24 +0900

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.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Feb 2014 07:02:24 +0000

Hi,

Simple mapping between two protocols is one thing. IETF has done that in the past, e.g. between ISUP and SIP.

However, my understanding is that you want more than that. You are looking at an architecture (or, you want to define one), and you want to define the SIP procedures etc within that architecture to achieve certain things. Or, am I wrong?

Regards,

Christer

From: dispatch [mailto:[email-masked]] On Behalf Of Kurtis Heimerl
Sent: 14. helmikuuta 2014 7:27
To: Dale R. Worley
Cc: [email-masked]
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.

On Fri, Feb 14, 2014 at 8:28 AM, Dale R. Worley <[email-masked]<mailto:[email-masked]>> wrote:
> From: "Ralph A. Schmid, dk5ras" <[email-masked]<mailto:[email-masked]>>

Dale

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 14 Feb 2014 07:57:39 +0000

Hello Tim and all,

> If I want an Um to SIP gateway I can run off solar power and hang in a tree, I'll go for an openBTS like solution.

If you want an Um to SIP gateway (for whatever purpose), you need a license.  To get a license, you will need to satisfy regulator's requirements. 

You still have not provided any references to regulators' document stating that a GSM band is free in any country.

You still have not explain how such BTS "running off solar power and hanging in a tree" does not interfere with other BTSs hanging on the next tree.

So, I am afraid, the BTS and Um To SIP gateway hanging will be switched off pretty quickly due to being illegal or causing interferences with other GSM nodes.

Kind regards

Ivo Sedlacek

---

From: Tom Taylor <[email-masked]>
Date: Fri, 14 Feb 2014 07:11:44 -0500

Your interventions in particular smack of an attempt to suppress 
potential competition through intimidation. I'll let you deal with the 
legalities of that. My personal opinion is that this sort of discussion 
does not belong on IETF lists. I support Mary's viewpoint that our role 
is technical only. Let the application find its own place after we do 
our job.

Tom Taylor

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 14 Feb 2014 13:13:48 +0000

Dear Tom,

your proposal for technical work seems to be that you want to describe interworking between 3GPP radio protocols and SIP?

Would IETF or 3GPP be a more appropriate organization for that?
IETF owns SIP but lacks expertise for the radio protocols.
3GPP knows their own protocols, and also has a certain SIP expertise by now.
3GPP also has experience with regulatory issues and interference problems that have been mentioned, and works based on operator requirements (that are your target customers based on your last explanations?). My conclusion thus is that 3GPP appears to be the more appropriate forum for such discussions.

By the way, there is already a comparable 3GPP spec, TS 29.292, although it was written for a more specific IMS related use case.

BR, Thomas

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of ext Tom Taylor
Sent: Friday, February 14, 2014 1:12 PM
To: [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

Your interventions in particular smack of an attempt to suppress potential competition through intimidation. I'll let you deal with the legalities of that. My personal opinion is that this sort of discussion does not belong on IETF lists. I support Mary's viewpoint that our role is technical only. Let the application find its own place after we do our job.

Tom Taylor

---

From: Tom Taylor <[email-masked]>
Date: Fri, 14 Feb 2014 08:50:55 -0500

If the WG runs into a dead end for lack of expertise, so be it. 
Otherwise, this is the IETF, an open forum, and interesting technical 
problems are surely always welcome.

Tom Taylor

> By the way, there is already a comparable 3GPP spec, TS 29.292, although it was written for a more specific IMS related use case.
...,

---

From: Michael Hammer <[email-masked]>
Date: Fri, 14 Feb 2014 16:08:35 +0000

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

Mobile: +1 408-202-9291

Milpitas, CA 95035 USA

From: dispatch [mailto:[email-masked]] On Behalf Of Kurtis
Heimerl
Sent: Friday, February 14, 2014 12:27 AM
To: Dale R. Worley
Cc: [email-masked]
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 14 Feb 2014 11:26:37 -0500 (EST)

> From: Tom Taylor <[email-masked]>

> I support Mary's viewpoint that our role is technical only. Let the
> application find its own place after we do our job.

It does help to know that there is actual demand for a certain
functionality before one invests much time figuring out how to provide
the functionality.

In this case, I expect the OpenBTS people have good contact with the
businesses/NGOs/whatever that intend to deploy such systems, and they
could report on the demand that has been expressed.

Given the complexities of the law in the 230 or so nations of the
world -- in all cases, the de-facto rules are different from the
official rules -- I would trust local organizations to have a better
understanding of whether and how such a system could be deployed in
practice than anyone sitting in another country.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 14 Feb 2014 11:26:08 -0500 (EST)

> From: Kurtis Heimerl <[email-masked]>

> decisions that were made are reasonable, scalable, and intelligent.

That makes sense.

But do take into account that the IETF does not standardize gateways.
SIP is a protocol, and various messages are defined to operate in
certain ways.  Your gateway is "correct" if it gets the desired
results using the standardized facilities provided by SIP.

It sounds like what you're looking for is a thorough review of the
design's use of SIP.  That's not something that the IETF does, though
the IETF is a good place to find SIP experts who can assess your
design.

The first step is to provide a reference to the design documentation.
A design can't be reviewed if it isn't documented.

Dale

---

From: Kurtis Heimerl <[email-masked]>
Date: Sat, 15 Feb 2014 01:54:01 +0900

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

> 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>]*
>
> follow the OSI model <http://en.wikipedia.org/wiki/OSI_model>. Um is
> Network Layer (L3)[edit<http://en.wikipedia.org/w/index.php?title=Um_interface&action=edit&section=7>
> ]
>
>    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>
>    .
>    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>.
>
> Note that none of these sublayers terminate in the BTS itself. The
> standard GSM BTS operates only in layers 1 and 2.
>
> ***
>
> *From:* dispatch [mailto:[email-masked]] *On Behalf Of *Kurtis
> Heimerl
> *Sent:* Friday, February 14, 2014 12:27 AM
> *To:* Dale R. Worley
>
> *Cc:* [email-masked]

---

From: Kurtis Heimerl <[email-masked]>
Date: Sat, 15 Feb 2014 01:55:36 +0900

As I mentioned earlier, there are operators with licenses. It's relatively
easy to get in some countries for small installations and low-power
operation is straight-up unlicensed in others. I'm not sure why you're
harping on this.

On Fri, Feb 14, 2014 at 4:57 PM, Ivo Sedlacek <[email-masked]>wrote:

> Hello Tim and all,
>
> > Apples and oranges - If I want a continent spanning, roaming capable
> billion dollar GSM network, then I need an IMS system.
> > If I want an Um to SIP gateway I can run off solar power and hang in a
> tree, I'll go for an openBTS like solution.
>
> If you want an Um to SIP gateway (for whatever purpose), you need a
> license.  To get a license, you will need to satisfy regulator's
> requirements.
>
> You still have not explain how such BTS "running off solar power and
> hanging in a tree" does not interfere with other BTSs hanging on the next
> tree.
>
> So, I am afraid, the BTS and Um To SIP gateway hanging will be switched
> off pretty quickly due to being illegal or causing interferences with other
> GSM nodes.
>
> Kind regards
>
> Ivo Sedlacek
>

---

From: Jim Forster <[email-masked]>
Date: Fri, 14 Feb 2014 16:57:12 +0000

All -- so much to catch up every evening, after every day this week with people that want OpenBTS. :-)

Michael,

> OK, let me add some protocol perspective.  Cut and paste courtesy of Wikipedia:

Thanks.

> ****
> The Um interface is the air interface for the GSM mobile telephone standard. It is the interface between the mobile station (MS) and theBase transceiver station (BTS). It is called Um because it is the mobile analog to the U interface of ISDN. Um is defined in the GSM 04.xx and 05.xx series of specifications. Um can also support GPRS packet-oriented communication.
> Um layers[edit]
> The layers of GSM are initially defined in GSM 04.01 Section 7 and roughly follow the OSI model. Um is defined in the lower three layers of the model.
> Network Layer (L3)[edit]
> The Um 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.
> 
> Radio Resource (RR). This sublayer manages the assignment and release of logical channels on the radio link. It is normally terminated in the BSC.
> Mobility Management (MM). This sublayer authenticates users and tracks their movements from cell to cell. It is normally terminated in the VLR or HLR.
> Call Control (CC). This sublayer connects telephone calls and is taken directly from ITU-T 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.
> Note that none of these sublayers terminate in the BTS itself. The standard GSM BTS operates only in layers 1 and 2.
> 
Right. 

OpenBTS isn't quite a standard BTS (but that should have been clear already, no?). In our case, we terminate all of those locally  Well, call control also involves subscriber authorization (which can be local or not), and a switching component, such as Freeswitch, Asterix, Kazoo, etc. These functions have clear implementations in the IETF protocols. And we go the IETF protocols for these as soon as possible in this system.
> ***
> 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);

Yes

> Not sure how that saves battery, but that is an implementation question we don’t need to answer.

True, it's not a protocol issue, but the result of a set of similar things make it interesting to customers, especially in off-grid and uncovered area use cases. That's why we've done it.  We seek to document this different sort of thing.  By ridiculous hyperbole, one could argue that the Avian Carrier RFC is also suitable for IP transport, so why do (Ethernet, GPRS..).  Efficiency matters.

>  Note also that since Um supports GPRS, could the BTS not also support a packet relay for higher layer P2P SIP call control?

I guess, but that's hat's not what has been implemented, seems convoluted, and would break the interesting use case of isolated operation, as well as likely impacting the local call reliability if the backhaul is unreliable.  It would also likely increase the required backhaul bandwidth, which is sometimes precious resource.  tWe care about those things. 

If power usage, backhaul bandwidth and reliability impact on the system performance are all considered irrelevant and out of scope by 3GPP, then now I have a better understanding why customers like this solution over the standard approach for places that don't now have coverage.

Lots more emails, and I like discussion, but I think the proponents will have to avoid spending all available time responding to them, and will have to spend time making a document that pulls some of the discussion together.

  -- Jim

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Feb 2014 13:53:09 -0500

On 2/14/14 12:27 AM, Kurtis Heimerl wrote:
> 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.

I have a *little*, old, knowledge of IMS at the sip layer, and almost no 
understanding of the remainder of 3gpp. I'm trying to make sense of this 
discussion.

IIUC, you have (or plan) a box that talk to 3gpp-compatible UEs over the 
radio link. This box is sufficient so that the phones connected to it 
can talk to one another. And your goal is to put a SIP interface on the 
box so that:
1) several of your boxes can interconnect and establish calls
    between themselves using SIP over the internet
2) so that these boxes can call other E.164 numbers using SIP
    over the internet.

Do I have the right idea? Are both (1) and (2) goals?

	Thanks,
	Paul

>     [email-masked] <mailto:[email-masked]>

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 14 Feb 2014 23:27:40 +0100

/* loosely answering to several other emails */

my esthetic preference is to leave policing spectrum to other more skilled
organizations in the area than IETF. I mean whether someone's deployment of
a BTS of any kind is  legitimate in a region or not seems to me way far
beyond protocol  design.

I think the "usual IETF question" which Michael H. has reiterated few times
is if there is some IETF protocol design  work to be  done on the subject.
It is my impression that this is not clear  yet, neither to the  openbts
folks nor to the IETF folks. Not meaning to be critical -- many  of most
good things emerge of some degree of initial chaos :)

Perhaps openbts works just perfect out of the box, and a useful contribution
would be a "gateway BCP" like RFC3666 which helped especially in the early
SIP adoption days. Maybe there are some hand-over aspects, authentication
aspects -- I think it is worth trying to find it out.

-jiri

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 15 Feb 2014 01:36:55 +0000

As regards membership of 3GPP and GSMA.

What I was suggesting is that 3GPP would be used. This allows you to get access to more operators and regulators than you would have in IETF, and more specifically the correct representatives of the operators and regulators.

GSMA will follow automatically if you get the operators interest.

Membership of 3GPP for small organisations (annual) is not necessarily that much more expensive that IETF (meeting fees). GSMA membership is not needed, and would be very expensive.

Keith

Sent: 13 February 2014 20:18

regards

Keith

regards

Keith Drage

T.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 15 Feb 2014 01:36:54 +0000

No.

But to persuade people to work on anything, you need to persuade them that there is something there in terms of a market. I'd hardly regard this as something to be treated as an academic exercise.

But I would still indicate there is insufficient information around here on what is being attempted. Rather than having a draft with a set of use cases and requirements, we are having to try and get it elaborated on the mailing list.

Keith 

> Sent: 13 February 2014 16:27
> > Jumping in here, they are relevant in as much as there is 
> no point in IETF working on this if there is no known market for it.
> 
> Hi Keith,
> 
> are you suggesting that IETF processes shall only allow work 
> on technologies for which there is a known market?
> 
> I'm glad this was not the case in the past, otherwise I would 
> not be able to send a single email. At least I don't have 
> memory of IETF business case criteria for the SNMP protocol. 
> If that shall change in the future, I would like to know what 
> is the specific IETF criteria for market existence. Can you 
> elaborate what these are supposed to be?
> 
> -jiri
> 
> p.s. one more question here: I understand your point that I'm 
> eligible to read emails to this WG mailing list that carry 
> confidentiality notice on the grounds of group memership. 
> What I don't understand is whether I'm also permitted (in 
> departure from the notice) to forward such an email to some 
> other email address than that of the working group.
> 
> 
> > So all Ivo is asking is for you to justify that it is worth 
> other people working on this as well as yourselves.
> > Perhaps if you identified the spectrum you believe is 
> available for use in the the countries identified, that would 
> be useful.
> > regards
> > Keith Drage
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 15 Feb 2014 01:43:45 +0000

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:[email-masked]] On Behalf Of Kurtis Heimerl
Sent: 14 February 2014 16:54
To: Michael Hammer
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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>.

Not sure how that saves battery, but that is an implementation question we don't need to answer.

Just asking.

Michael Hammer
Principal Engineer

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

Dale

---

From: Michael Hammer <[email-masked]>
Date: Sat, 15 Feb 2014 03:00:00 +0000

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

Mobile: +1 408-202-9291

Milpitas, CA 95035 USA

From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 8:44 PM
To: Kurtis Heimerl; Michael Hammer
Cc: [email-masked]
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

  _____  

On Sat, Feb 15, 2014 at 1:08 AM, Michael Hammer
<[email-masked]> wrote:

****

Um layers[edit

Network Layer (L3)[edit

1.	Radio Resource

***

Just asking.

Michael Hammer

Principal Engineer

Mobile: +1 408-202-9291

Milpitas, CA 95035 USA

Cc: [email-masked]

Dale