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

Jim Forster <jim.forster@rangenetworks.com> Fri, 14 February 2014 16:57 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 8C18F1A02CF for <dispatch@ietfa.amsl.com>; Fri, 14 Feb 2014 08:57:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.831
X-Spam-Level:
X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 YfHM6jGUmTtZ for <dispatch@ietfa.amsl.com>; Fri, 14 Feb 2014 08:57:17 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 32CA51A0270 for <dispatch@ietf.org>; Fri, 14 Feb 2014 08:57:17 -0800 (PST)
Received: from BL2PR03MB404.namprd03.prod.outlook.com (10.141.91.149) by BL2PR03MB403.namprd03.prod.outlook.com (10.141.91.148) with Microsoft SMTP Server (TLS) id 15.0.873.15; Fri, 14 Feb 2014 16:57:12 +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; Fri, 14 Feb 2014 16:57:12 +0000
From: Jim Forster <jim.forster@rangenetworks.com>
To: Michael Hammer <michael.hammer@yaanatech.com>
Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS
Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIIAAT20AgAAEZwCAAAXeAIAAJYiAgAFsZwCAAWBU1IABLnGAgAAqBACAACCygIAADyCAgACIRrqAAGIlAIAAsyWAgAANgAA=
Date: Fri, 14 Feb 2014 16:57:12 +0000
Message-ID: <F75509E8-2615-4A6C-9DD9-9987446BAEFB@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> <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> <201402132328.s1DNS0U64926205@shell01.TheWorld.com> <CACyT-3=RKqvhGB-WLmWH0tGHCTEzH=Ej22sa+U-3vGN4AbTndg@mail.gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF2B24F@sc9-ex2k10mb1.corp.yaanatech.com>
In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF2B24F@sc9-ex2k10mb1.corp.yaanatech.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [202.129.185.171]
x-forefront-prvs: 01221E3973
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(189002)(199002)(63696002)(85306002)(79102001)(80022001)(80976001)(87936001)(69226001)(65816001)(54316002)(15202345003)(56776001)(74706001)(54356001)(74876001)(77982001)(33656001)(74366001)(66066001)(74502001)(59766001)(83716003)(19580395003)(83322001)(76786001)(36756003)(74662001)(90146001)(76796001)(31966008)(15188155005)(81342001)(85852003)(83072002)(47446002)(92726001)(56816005)(82746002)(15975445006)(92566001)(81816001)(16799955002)(81686001)(47736001)(95666001)(4396001)(49866001)(50986001)(87266001)(46102001)(81542001)(53806001)(76482001)(93136001)(2656002)(94946001)(94316002)(95416001)(51856001)(16236675002)(93516002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB403; H:BL2PR03MB404.namprd03.prod.outlook.com; CLIP:202.129.185.171; FPR:; MLV:sfv; InfoNoRecordsMX:1; A:1; LANG:en;
Content-Type: multipart/signed; boundary="Apple-Mail=_E5443062-12DF-433A-89DB-A6877328062A"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
X-OriginatorOrg: rangenetworks.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/x_Awecwo-mHUjo_Yrf_Fg8eNosM
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 16:57:30 -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.
> 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.
> 
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);
> ISDN/SIP interworking; Protocol specification

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