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

Kurtis Heimerl <kheimerl@cs.berkeley.edu> Tue, 11 February 2014 21:31 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 A35841A076D for <dispatch@ietfa.amsl.com>; Tue, 11 Feb 2014 13:31:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.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, 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 6bTLGjLH86U9 for <dispatch@ietfa.amsl.com>; Tue, 11 Feb 2014 13:31:54 -0800 (PST)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 495811A075B for <dispatch@ietf.org>; Tue, 11 Feb 2014 13:31:54 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id c11so6409419lbj.17 for <dispatch@ietf.org>; Tue, 11 Feb 2014 13:31:53 -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=gNktLpo8FSMm13MkohDZ7A4eeGi5U8fJNCXS6QO5cyk=; b=AKctlzIsgfw3gDJNGmTccev9+GGKetOEdrOXjFddXeLkhUjDCH0+3PIr8QfWptCD5p xOqr5WL86v/M/KJ0IO6i/AnRhEgBDH2jSsNawqfbaTZqrdaTNLrJh0qWqdJ7oUR3YAXi m4PFWYfN7calGMSt6MPQN/ERQcH2gnjkHCw0XPG6JTvEKTUDfH1Tsd2llWft7Vdgha+/ 9PttLwNmopRB9W8OXEGHPEASrcXsAp7ZXcvYwnk3OzlCZ5jvYR7VmMdBD3icB8ogRC7t NXDVQc7YLISA49X81ugyksDbB6V77C7H+o/E+qZP98sVy773O4AOpaGPzTvEQnyLsPIj SKPQ==
X-Received: by 10.152.27.193 with SMTP id v1mr28470292lag.4.1392154313012; Tue, 11 Feb 2014 13:31:53 -0800 (PST)
MIME-Version: 1.0
Sender: munncha@gmail.com
Received: by 10.112.42.170 with HTTP; Tue, 11 Feb 2014 13:31:12 -0800 (PST)
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B12FA06@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> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <CACyT-3mAJX4uPDcXDz7j6xOAA+OSDoRguQ51EvZk9=LTG8KzJQ@mail.gmail.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com>
From: Kurtis Heimerl <kheimerl@cs.berkeley.edu>
Date: Wed, 12 Feb 2014 06:31:12 +0900
X-Google-Sender-Auth: 2kdUeUJNvO-yYipNBeGIQUyHdLU
Message-ID: <CACyT-3kopBbtwwf7Lopkwx+BCAw0wRvPd71kffgWn1w4JtpSvg@mail.gmail.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="089e0158c4864cbb7d04f2282fc8"
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: Tue, 11 Feb 2014 21:31:57 -0000

Comments in line:


On Tue, Feb 11, 2014 at 6:19 AM, DRAGE, Keith (Keith) <
keith.drage@alcatel-lucent.com> wrote:

>  I'd contend that there is not enough information in the diagram to
> identify either point of view.
>
>

This is not a "point of view". This is how the system is architected, as
shown in the diagram with the boxes under the OpenBTS box.


> What I am beginning to understand is that the SIP registrar is not
> colocated with the BTS, and therefore the subscriber records for the GERAN
> usage are physically seaparate and distinct from those of the SIP usage.
> Therefore to add a subscriber to the system, tou have to update the HLR
> records in the BTS (and every BTS that is serving that user) and the
> records at the SIP registrar / location server.
>
>

They can be physically separate, though they need not be. In most PBX
setups the subscriber records are read by the HLR (for authentication) and
PBX (for routing) from the same database. Again, this database and HLR
serves multiple BTSs, so each BTS does not need to be updated.


> Is there a requirement to correlate accounting records between the two
> usages?
>

For the PBX and HLR, probably. It's definitely good practice.


>
> Mobility management is not I assume converted to SIP. The original
> description said they would use REFER to do such functions. It has not been
> clear whether that is supported by a centralised function (at or distinct
> from the registrar / location server) or whether this is performed UE to
> UE. This needs to be clarified. I would very much suspect this is going to
> need the definition of some new protocol to indicate support of various
> capabilities (This is a special REFER because it comes from my other
> registration over a different proxy, and not any old REFER).
>


In OpenBTS, the BTS itself acts as the UE within the network, as it bridges
between Um and SIP. For Handover, the current solution has the UEs forward
packets between BTSs when a phone is roaming. I believe it's not possible
to do through the PBX, though I can't remember why.


>
> regards
>
> Keith
>
>  ------------------------------
> *From:* munncha@gmail.com [mailto:munncha@gmail.com] *On Behalf Of *Kurtis
> Heimerl
> *Sent:* 10 February 2014 19:05
> *To:* DRAGE, Keith (Keith)
> *Cc:* Tim Panton new; dispatch@ietf.org
>
> *Subject:* Re: [dispatch] SIP and GSM/UMTS with OpenBTS
>
>  You're misreading the diagram. As can be seen, multiple OpenBTS
> instances can talk to a single instance of the SAS. This allows for
> centralized charging and accounting for multiple BTS instances wherever the
> SAS is hosted.
>
>  As far as the 3GPP mobility management protocols (if I know which ones
> you are speaking of), those are converted to SIP (as is everything) and
> sent to the SAS. So I would say we are using these protocols between BTSs,
> especially for handover.
>
>
> On Tue, Feb 11, 2014 at 3:43 AM, DRAGE, Keith (Keith) <
> keith.drage@alcatel-lucent.com> wrote:
>
>> I am not assuming a specific solution - what we are all trying to find
>> out is how much of 3GPP GERAN is actually being used, and what identities
>> relate to what.
>>
>> So you will have a UICC - because it is a 3GPP GERAN access network, but
>> will not have any roaming that relates to the UICC, or the identities on
>> that UICC.
>>
>> But as far as I can see from the architecture given, the service is
>> limited to a single BTS. That means that (for the solution you identify
>> below) an operator with multiple BTSs will assign their users to a single
>> BTS and the collation of charging/accounting will have to be from each
>> individual BTS, back to some central entity (not shown).
>>
>> You will not be running the 3GPP mobility management protocols between
>> BTS.
>>
>> Keith Drage
>>
>>
>>
>> > -----Original Message-----
>> > From: Tim Panton new [mailto:thp@westhawk.co.uk]
>> > Sent: 10 February 2014 18:28
>> > To: DRAGE, Keith (Keith)
>>  > Cc: Jim Forster; Mary Barnes; dispatch@ietf.org
>> > Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS
>> >
>> >
>>  > On 10 Feb 2014, at 17:56, DRAGE, Keith (Keith)
>> > <keith.drage@alcatel-lucent.com> wrote:
>> >
>> > > If I follow this diagram correctly, you claim to have
>> > collapsed the HLR into your BTS. Your BTS apparently have no
>> > communication shown with each other. This means you each
>> > subscriber is limited to a single BTS with no roaming between them.
>> >
>> > I think you are assuming a specific solution to a specific problem.
>> > Many ITSPs allow SIP  registrations to a DID/account to come
>> > from dynamic IPs. So the necessary 'communication' can be
>> > implemented via the ITSP's normal functions. So when a user
>> > moves from the BTS in village A to the BTS  in village B
>> > their DID travels with them.
>> >
>> > Sure you wouldn't get the ability for an arbitrary GSM SIM to
>> > roam into the network and be billed to their home network.
>> >
>> > But realistically that sort of roaming isn't really a
>> > technical problem, it is predominantly a legal/commercial one.
>> >
>> > Tim.
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>
>