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

Ivo Sedlacek <ivo.sedlacek@ericsson.com> Thu, 13 February 2014 14:59 UTC

Return-Path: <ivo.sedlacek@ericsson.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 AC4F71A02A1 for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 06:59:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level:
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 08mLyfDFSLAL for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 06:59:42 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 353731A008E for <dispatch@ietf.org>; Thu, 13 Feb 2014 06:59:41 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-f9-52fcddda2f77
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E3.1A.10875.ADDDCF25; Thu, 13 Feb 2014 15:59:38 +0100 (CET)
Received: from ESESSMB301.ericsson.se ([169.254.1.164]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 15:59:37 +0100
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: Tim Panton new <thp@westhawk.co.uk>
Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS
Thread-Index: AQHPKAwVozdeAICzrkKy3baFOj5a05qy64bA
Date: Thu, 13 Feb 2014 14:59:38 +0000
Message-ID: <39B5E4D390E9BD4890E2B31079006101126623B2@ESESSMB301.ericsson.se>
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>
In-Reply-To: <201402121601.s1CG1q0W4835781@shell01.TheWorld.com>
Accept-Language: en-US, cs-CZ
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101126623B2ESESSMB301erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvje6tu3+CDBY1aVgsnbSA1WLd+2Ms DkweS5b8ZPK4OG0/UwBTFJdNSmpOZllqkb5dAlfGstOzmAr2JFQ8eWLXwPg5qIuRk0NCwESi r7uPBcIWk7hwbz1bFyMXh5DAIUaJjctvM0E4Sxglli2ZxgRSxSagJzFxyxFWEFtEQF1i5tKL YHFmAW2J/9fXMYLYwgKmEiuntkDVmElMmjaLuYuRA8g2ktj7wx4kzCKgKnG0/TlYCa+Ar8TF uetZIXY1c0l8v7yfDSTBKeAg8evHRbCZjAKyElf/9DJC7BKXuPVkPhPE1QISS/acZ4awRSVe Pv7HCmErSazYfgmqPl9i/8X7LBDLBCVOznzCMoFRdBaSUbOQlM1CUgYR15FYsPsT2yyoN5ct fM0MY5858JgJWXwBI/sqRvbcxMyc9HLDTYzAmDq45bfuDsZT50QOMUpzsCiJ83546xwkJJCe WJKanZpakFoUX1Sak1p8iJGJg1OqgTFd6bR+TnPFU42fn1g+y7m8WhWyeYKh394D6cuLj7yb ust+b1RcZFzck9yjO3Y6MRjaeW9+335A8qft2vTzby8uz9/5Snx2+BKDtNxJfyb0Z4S4HCte xSvwWScp1bdnm/jRn9Vba1RV7ut4Z1RcY95ctiY86J3Lr/a9d15p7dkTslbv6n/mHS1KLMUZ iYZazEXFiQDHvcDtdwIAAA==
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 14:59:45 -0000

(the mail below is resent without the final line)



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