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

Michael Hammer <michael.hammer@yaanatech.com> Fri, 14 February 2014 18:43 UTC

Return-Path: <michael.hammer@yaanatech.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 0337C1A0318 for <dispatch@ietfa.amsl.com>; Fri, 14 Feb 2014 10:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 dXxC2Xwm-G0r for <dispatch@ietfa.amsl.com>; Fri, 14 Feb 2014 10:43:24 -0800 (PST)
Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9761A0354 for <dispatch@ietf.org>; Fri, 14 Feb 2014 10:43:09 -0800 (PST)
Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 10:43:15 -0800
From: Michael Hammer <michael.hammer@yaanatech.com>
To: "mary.ietf.barnes@gmail.com" <mary.ietf.barnes@gmail.com>
Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS
Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAC9HICAAALFAIAAAFCA//96B5CAAI2tgIAALnMAgAZ4WICAAOAQAIAACMEAgAAEaACAAAXeAIAAJYeAgAFsZwCAANo2FIABtI+AgAAqBQCAACCxgIAABEMAgAAK7oCAAFDzgP//goyfgACWJ4CAAKAtAIAAt5uA//+ARwA=
Date: Fri, 14 Feb 2014 18:43:07 +0000
Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF2CCA2@sc9-ex2k10mb1.corp.yaanatech.com>
References: <00C069FD01E0324C9FFCADF539701DB3BBF2A4FF@sc9-ex2k10mb1.corp.yaanatech.com> <CAHBDyN6zoWSch2CTdYFN0nnYq0dnZvr76M5iXXFMQKioZTTjtw@mail.gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF2B047@sc9-ex2k10mb1.corp.yaanatech.com> <CAHBDyN651mynxUdLNDdhB00D9GT=RzZmjYmVnxV9vKU_vWzVvA@mail.gmail.com>
In-Reply-To: <CAHBDyN651mynxUdLNDdhB00D9GT=RzZmjYmVnxV9vKU_vWzVvA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.17.100.96]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_00FD_01CF298A.B098BFE0"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/LfVrc0jAD1hiEFooELizHsdZNo8
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 18:43:32 -0000

Mary,

 

I helped clarify for myself with my subsequent Um email.

 

However, the response to that did not say what interworking is needed beyond
what the existing ETSI Q.931-SIP spec already covers.

 

So, my current sense is that the protocol and interworking aspects are
already done.

 

Michael Hammer

Principal Engineer

 <mailto:michael.hammer@yaanatech.com> michael.hammer@yaanatech.com

Mobile: +1 408-202-9291

500 Yosemite Drive Suite 120

Milpitas, CA 95035 USA

 

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 
Sent: Friday, February 14, 2014 1:17 PM
To: Michael Hammer
Cc: keith.drage@alcatel-lucent.com; dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

 

On Fri, Feb 14, 2014 at 9:30 AM, Michael Hammer
<michael.hammer@yaanatech.com> wrote:

Mary,

 

The Base Transceiver Station (BTS) is not an LTE component, it is more
legacy base station technology.

The eNodeB is what LTE uses, which is what IMS would be transported by.

The radio access network just provides an IP path from the handset IMS
client to the IMS core elements.

There is no interworking at SIP layer for anything in the access network.

[MB] Right. But, it's my understanding that interworking at the SIP layer in
the access network is what OpenBTS is about and it's based on a GSM model. I
don't have my 6000 pages of GSM specs at hand (I left those on a shelf in my
cubicle when I left Nortel) and my book is two decades old, but it was my
understanding that the radio layer call control messages are the same ones
that are encapsulated into DTAP messages to be sent over the A interface in
GSM and they're used for Call Control in the MSC and it would be those that
are mapped to SIP (in the BTS) - i.e., these messages:

 

What I would find useful to know is how any of these multi-access IMS
systems (that also seem to support GSM access) are doing any mapping? Even
if it's done in the IMS core, I would think the model would be similar to
the mapping one would do in the BTS in the case of GSM access in an OpenBTS
model. [/MB]

 

So, 2 cases:  

Case 1:  the radio access network does not have connectivity to the core
network:  

solution may be to have a P2P SIP application that kicks in for local
connectivity.

This can be developed from current standard SIP protocol.  

No new SIP attributes have been proposed.

[MB] That may be a possibility. That approach would need more detail to see
if it's feasible for the deployments being considered. But, if this requires
anything new in the cellphone then I don't think it meets the basic
requirement of allowing people to use their existing cellphones to make
calls. [/MB] 

 

Case 2:  the radio access network does have connectivity to the core
network:

The IMS client should be able to connect to the core IMS components and
operate as normal in the LTE/IMS/VoLTE network.

Again, no new SIP attributes have been proposed.

[MB] My understanding is that OpenBTS is more focused on GSM than IMS.
Remember, not everyone in the world is running an IMS network.  So, I think
in this case, OpenBTS wouldn't be necessary.  [/MB] 

 

So, I ask again for the third time, what IETF protocol or extension thereto
is being proposed?

 

All the radio discussion as far as I can tell is just marketing, looking for
approval from IETF for deploying non-compliant 3GPP base stations.

[MB] IETF doesn't approve how anyone deploys any equipment.  The concern is
understood.  But, I think Jiri Kuthan stated this very well in terms of it
not at all being unusual for IETF to work on protocols that might have the
appearance of displacing existing protocols (and product deployments):
http://www.ietf.org/mail-archive/web/dispatch/current/msg05336.html

 

Again, we are dealing with equipment that is already being deployed and
appears to serve a useful function in providing connectivity in remote areas
that would otherwise not have a way for people to use their cellphones. 

 

I believe IETF should take the same stance we did when 3GPP was deciding to
use SIP and posit that any changes to IETF protocols must happen in IETF.  I
do not believe that OpenBTS is requiring any changes to 3GPP protocols.
We don't yet know the details of changes to IETF protocols.  My
understanding at this time is that at a minimum a documented way to
interwork the radio layer call control protocol with SIP is needed. Folks
are already doing something in this space.  I totally agree that the details
of what folks are doing now can help inform any decisions on what might be
needed in IETF documents.   

[/MB]

 

I think that may be dangerous and damaging of relationship between IETF and
3GPP.

[MB] I don't disagree that this could be a difficult situation and could
very likely require  some liaisons between the two organizations. But, we've
been there before in the early 2000s when 3GPP was working on R5 to define
the use of SIP in an IMS core network.  3GPP required some new SIP
extensions and there was a need to for education on both sides in terms of
why 3GPP needed these specific headers which weren't deemed generally
applicable to SIP on the open Internet.  [/MB] 

 

I admit maybe I have missed something, but someone needs to spell out more
clearly what they want to standardize.

[MB] That probably goes both ways in terms of understanding the concerns on
both sides.   The reason for these discussions is to help us tease out what
clearly needs to be standardized.  I totally agree that we are not there
yet. [/MB] 

If need be draw a picture.

[MB] I totally agree a picture would really help. [/MB] 

 

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com

Mobile: +1 408-202-9291

500 Yosemite Drive Suite 120

Milpitas, CA 95035 USA

 

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 
Sent: Thursday, February 13, 2014 4:47 PM
To: Michael Hammer
Cc: DRAGE, Keith (Keith); dispatch@ietf.org


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

 

I have stated specifics before as to the context for this and IETF: 

http://www.ietf.org/mail-archive/web/dispatch/current/msg05252.html

 

One of the things they are explicitly talking about the Radio layer Call
control protocol interworking with SIP.  Now, if folks are saying that this
interworking between these call control messages and SIP would be the same
in the BTS as it would be in the MSC, then a pointer to the exact IMS spec
that provides all these details would be most helpful.  My guess is that
this problem doesn't require the complete functionality defined by CT1.
It's certainly possible that there is a subset of those specifications which
could help meet their needs and I assume they would have dug through those
already). But, explicit pointers to those rather than a blanket statement
that IMS solves this specific problem would be really helpful.  

 

 I totally agree that the proponents have a lot more detail to provide so
that folks can understand the interworking and functionality that they are
wanting that is relevant to IETF and SIP. 

 

Mary

On Thu, Feb 13, 2014 at 2:49 PM, Michael Hammer
<michael.hammer@yaanatech.com> wrote:

Mary. Interworking sip with radio protocols is like saying inter working sip
with ip. Makes no sense.  So far I have not seen any case for work in IETF.
This is more analogous to ITU- T attempt to screw up MPLS as far as I can
tell. 
 
I asked the question before and still do not see a connection to any IETF
work.  Cut out the business case and nothing has been proposed. 
 
 
 
Sent with Good (www.good.com)

------ Original Message ------ 
From: Mary Barnes
Sent: Thursday, February 13, 2014 at 3:19 PM
To: DRAGE, Keith (Keith)
Cc: dispatch@ietf.org
Subject: [dispatch] SIP and GSM/UMTS with OpenBTS

 

 

On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith)
<keith.drage@alcatel-lucent.com> wrote:

Ericsson is not the only vendor that sees a market for small cells, but the
expectation is that the products are built to the completed 3GPP standards
will be deployed in licensed spectrum by owners of that spectrum, although
the boxes may well be owned by 3rd parties.

 

These deployments already exist.

 

I see Jim has now identified that this proposal is for licensed GSM
operators in licensed GSM space.

 

Personally, I would suggest if you believe the operators should be picking
this up, you take it to 3GPP where the operators are actually present. That
is the only way you will see it taken up by GSMA, which you will need to
obtain interoperator agreements to use this (e.g. roaming, shared networks).
3GPP them works with IETF on any SIP extensions needed.

[MB] One big problem with this proposal is that you must be a member of
3GPP/GSMA to make contributions and to participate in meetings.    

 

And, I think having to first do the work in 3GPP and then bring it to IETF
would introduce a tremendous delay for something that's already been
implemented/deployed.  While they are proposing to reuse elements and
protocols that are part of an IMS network, the core issue they have is with
interworking SIP with the radio layer protocols.  Certainly, one could
implement all the protocols that IMS uses and then use the 3GPP based specs
and proprietary headers to interwork with SIP in the Internet, but that
would be terribly inefficient. 

[/MB] 

 

I would only see IETF having any direct part in this if the proposal was
only to use unlicensed spectrum by enterprises rather than licensed
operators, which Jim has negated.

 

regards

 

Keith

 

  _____  

From: Tim Panton new [mailto:thp@westhawk.co.uk] 

Sent: 13 February 2014 14:50
To: DRAGE, Keith (Keith)
Cc: Harvind Samra; Ivo Sedlacek; dispatch@ietf.org


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

 

 

On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith)
<keith.drage@alcatel-lucent.com> wrote:

 

Jumping in here, they are relevant in as much as there is no point in IETF
working on this if there is no known market for it.

 

Usually those type of projects are published only on April 1st.

 

So all Ivo is asking is for you to justify that it is worth other people
working on this as well as yourselves.

 

Perhaps if you identified the spectrum you believe is available for use in
the the countries identified, that would be useful.

 

regards

 

Keith Drage

 

Ivo's employer seems to see a market for small cells, but looks to tie them
to existing operator IMS's through 

internet connections "owned by themselves or a partner".

http://www.telecomlead.com/enterprise-networking/mwc-2014-ericsson-announce-
small-cell-service-20233/

Perhaps that's an April fools joke too (I can't see any avian carriers
mentioned though)?

 

It isn't up to the IETF to crown specific solutions. That's the market's
job.

 

T.

 

 

 


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch