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

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

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.

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

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

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<mailto: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<mailto:thp@westhawk.co.uk>]
> Sent: 10 February 2014 18:28
> To: DRAGE, Keith (Keith)
> Cc: Jim Forster; Mary Barnes; dispatch@ietf.org<mailto: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<mailto: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<mailto:dispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/dispatch