IETF Logo Mail Archive

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

"Belling, Thomas (NSN - DE/Munich)" <thomas.belling@nsn.com> Mon, 10 February 2014 14:26 UTC

Return-Path: <thomas.belling@nsn.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 50A821A02FA for <dispatch@ietfa.amsl.com>; Mon, 10 Feb 2014 06:26:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.6
X-Spam-Level:
X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 9MbvCemelDkP for <dispatch@ietfa.amsl.com>; Mon, 10 Feb 2014 06:26:04 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1C41A07DF for <dispatch@ietf.org>; Mon, 10 Feb 2014 06:25:58 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1AEPrVS031664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2014 15:25:53 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1AEPqd0008557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 15:25:52 +0100
Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 10 Feb 2014 15:25:52 +0100
Received: from DEMUMBX001.nsn-intra.net ([169.254.1.157]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 15:25:52 +0100
From: "Belling, Thomas (NSN - DE/Munich)" <thomas.belling@nsn.com>
To: ext Jim Forster <jim.forster@rangenetworks.com>, Gullik Webjörn <gullik.webjorn@corevalue.se>
Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS
Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAAmPICAAALFAIAAAFCAgAAAZICAAAdQgIAALnMAgAAO2QCAAjuygIAAGAsAgABPfwCABHrqgA==
Date: Mon, 10 Feb 2014 14:25:51 +0000
Message-ID: <BDBE1A97E84675488F72A48C23811F3515E49D44@DEMUMBX001.nsn-intra.net>
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> <00C069FD01E0324C9FFCADF539701DB3BBF241C5@sc9-ex2k10mb1.corp.yaanatech.com> <AD3958C3-CAA4-44DD-BEEF-0B0F6895F447@westhawk.co.uk> <52F4E9A4.5000203@corevalue.se> <FF33B7D3-32BD-461E-B6E3-38109D87A5EF@rangenetworks.com>
In-Reply-To: <FF33B7D3-32BD-461E-B6E3-38109D87A5EF@rangenetworks.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.102]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2261
X-purgate-ID: 151667::1392042354-00001A6F-81F2BD2D/0-0/0-0
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: Mon, 10 Feb 2014 14:26:07 -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:dispatch-bounces@ietf.org] On Behalf Of ext Jim Forster
Sent: Friday, February 07, 2014 7:56 PM
To: Gullik Webjörn
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS


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

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

v2.23.0 | Report a Bug | By Email