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

Jim Forster <jim.forster@rangenetworks.com> Thu, 13 February 2014 11:46 UTC

Return-Path: <jim.forster@rangenetworks.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 C36B01A01B4 for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 03:46:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 PHGCsq9O3S5x for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 03:46:27 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) by ietfa.amsl.com (Postfix) with ESMTP id A38251A01E8 for <dispatch@ietf.org>; Thu, 13 Feb 2014 03:46:25 -0800 (PST)
Received: from BL2PR03MB404.namprd03.prod.outlook.com (10.141.91.149) by BL2PR03MB147.namprd03.prod.outlook.com (10.255.230.19) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 11:46:22 +0000
Received: from BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) by BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 11:46:22 +0000
From: Jim Forster <jim.forster@rangenetworks.com>
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS
Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIIAAT20AgAAEZwCAAAXeAIAAJYiAgAFsZwCAAWBU1IABLnGAgAAby4A=
Date: Thu, 13 Feb 2014 11:46:22 +0000
Message-ID: <676E4A52-E702-43BE-9245-5CD558D69497@rangenetworks.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> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <CACy T-3mAJX4uPDcXDz7j6xOAA+OSDoRguQ51EvZk9=LTG8KzJQ@mail.gmail.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <DE4C1B56-0D67-4210-9FFA-EC0BC866E081@westhawk.co.uk> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se>
In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [202.145.4.188]
x-forefront-prvs: 0121F24F22
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(71364002)(199002)(189002)(83716003)(85306002)(561944002)(79102001)(54316002)(77982001)(56776001)(19580395003)(59766001)(80976001)(93516002)(65816001)(80022001)(54356001)(53806001)(51856001)(66066001)(76482001)(63696002)(46102001)(94316002)(47446002)(86362001)(74502001)(83322001)(31966008)(74662001)(33656001)(47976001)(56816005)(94946001)(15975445006)(82746002)(50986001)(47736001)(95416001)(81816001)(81686001)(93136001)(49866001)(85852003)(92726001)(69226001)(4396001)(74366001)(90146001)(74876001)(2656002)(87266001)(16236675002)(81342001)(87936001)(81542001)(74706001)(92566001)(36756003)(95666001)(83072002)(76786001)(76796001)(15202345003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB147; H:BL2PR03MB404.namprd03.prod.outlook.com; CLIP:202.145.4.188; FPR:EFE8F16F.AFDA1FB5.F1D35DBB.4CF67178.20537; InfoNoRecordsA:1; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_676E4A52E70243BE92455CD558D69497rangenetworkscom_"
MIME-Version: 1.0
X-OriginatorOrg: rangenetworks.com
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: Thu, 13 Feb 2014 11:46:31 -0000

Ivan, all,

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

 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

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

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

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

 E.g. can you please clarify whether you indent to specify a solution for:
a) carriers with license to use the licensed GSM bands?

Yes.

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

No.

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.

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?

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>

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.