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

[Mary Barnes <[e-mail]>]

On Fri, Feb 14, 2014 at 9:30 AM, Michael Hammer <
[e-mail]> 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*
>
> *[e-mail] <[e-mail]>*
>
> *Mobile: *[phone]
>
> 500 Yosemite Drive Suite 120
>
> Milpitas, CA 95035 USA
>
>
>
> *From:* Mary Barnes [mailto:[e-mail]]
> *Sent:* Thursday, February 13, 2014 4:47 PM
> *To:* Michael Hammer
> *Cc:* DRAGE, Keith (Keith); [e-mail]
>
> *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 <
> [e-mail]> 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: *[e-mail]
> *Subject: *[dispatch] SIP and GSM/UMTS with OpenBTS
>
>
>
>
>
> On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith) <
> [e-mail]> 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:[e-mail]]
>
> *Sent:* 13 February 2014 14:50
> *To:* DRAGE, Keith (Keith)
> *Cc:* Harvind Samra; Ivo Sedlacek; [e-mail]
>
>
> *Subject:* Re: [dispatch] SIP and GSM/UMTS with OpenBTS
>
>
>
>
>
> On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) <
> [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
>
>