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

Kurtis Heimerl <kheimerl@cs.berkeley.edu> Fri, 14 February 2014 05:24 UTC

Return-Path: <munncha@gmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2DB1A00EC for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 21:24:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.277
X-Spam-Level:
X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adu7kV4jDDtO for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 21:24:26 -0800 (PST)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 191411A00B9 for <dispatch@ietf.org>; Thu, 13 Feb 2014 21:24:25 -0800 (PST)
Received: by mail-lb0-f170.google.com with SMTP id u14so8976342lbd.15 for <dispatch@ietf.org>; Thu, 13 Feb 2014 21:24:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Pe5kMlu5R4QJcprILwNAc+UiycJ9do7ceHpZTiC/Kuk=; b=CHTYb+kuJ4UMVzIeCqcx6MQVf2cuXHGvP/IOeClYoVqokFOiGVIKByVZRDoZuAo0S9 Z4CCgOb+bFDRkES/VUURqyBDwktr+XuZpAwLCDOWonG+0Ji90blrg6+TSZ8zDcPmGiK2 Rdq/TNJfAHsKwyZ2puOEWP72+bcylRVFCALm5uzY/AQ5kEOuTQzXW44fVFTtM/wnRv0i NTBYUtfrTnRmmIeRWBQqs4RIFgWr23Ydi2KlxKdujOcH5WLY4Pw4djcx/AyAYm68AHkY wpmvFWitupGHfdgy5D9TJGmzoAQbWU0A0KoKrRd/hbV46wLmHm8lgdG7Zo/XzHsOQ5O/ nr7w==
X-Received: by 10.112.45.108 with SMTP id l12mr3505991lbm.21.1392355464001; Thu, 13 Feb 2014 21:24:24 -0800 (PST)
MIME-Version: 1.0
Sender: munncha@gmail.com
Received: by 10.112.42.170 with HTTP; Thu, 13 Feb 2014 21:23:43 -0800 (PST)
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B131C97@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <E1FE4C082A89A246A11D7F32A95A17826DFCD495@US70UWXCHMBA02.zam.alcatel-lucent.com> <F5DA260C-32C9-4D92-9169-2026983BFC47@gmail.com> <E1FE4C082A89A246A11D7F32A95A17826DFCD852@US70UWXCHMBA02.zam.alcatel-lucent.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <CAHBDyN5-O3pNury3RUNzstGHO8NCq6pV3ewHt_Yrxjd1k-if5Q@mail.gmail.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <DE4C1B56-0D67-4210-9FFA-EC0BC866E081@westhawk.co.uk> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> <949EF20990823C4C85C18D59AA11AD8B131C97@FR712WXCHMBA11.zeu.alcatel-lucent.com>
From: Kurtis Heimerl <kheimerl@cs.berkeley.edu>
Date: Fri, 14 Feb 2014 14:23:43 +0900
X-Google-Sender-Auth: hiw4TNBs5Zbc7hu-_foGyYijABY
Message-ID: <CACyT-3mj9=1E2747idRshhersPvN8o-6otg9A6zRQCXLXor89A@mail.gmail.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="001a1134bfc8d53e6904f257049d"
Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/jX8LSUYsPThqBW-yMcPsZ-pcDqs
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 05:24:31 -0000

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) <
keith.drage@alcatel-lucent.com> wrote:

>  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:ralph@schmid.xxx]
> *Sent:* 13 February 2014 15:28
> *To:* DRAGE, Keith (Keith); 'Harvind Samra'; 'Ivo Sedlacek'
> *Cc:* dispatch@ietf.org
> *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  :-)
>
>
>
> But I may be wrong...then just hit the DEL-button.
>
>
> Ralph.
>
>
>
>
>
>
>
>
>
> *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *DRAGE,
> Keith (Keith)
> *Sent:* Thursday, February 13, 2014 3:34 PM
> *To:* Harvind Samra; Ivo Sedlacek
> *Cc:* dispatch@ietf.org
> *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.
>
>
>
> 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:dispatch-bounces@ietf.org<dispatch-bounces@ietf.org>]
> *On Behalf Of *Harvind Samra
> *Sent:* 13 February 2014 12:37
> *To:* Ivo Sedlacek
> *Cc:* dispatch@ietf.org
> *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.
>
>
>
> On Feb 13, 2014, at 2:06 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com>
> wrote:
>
>
>
>   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
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> 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
>
> ____________________________________________
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>