Re: [5gangip] New Version Notification for draft-xyx-5gip-ps-00.txt

[jouni korhonen <[e-mail]>]

The protocol choice will usually take place in “stage-3 groups". In this case it would be RAN3 afair. Their current working assumption for NG data transport (with a disclaimer) is already GTP - check TS38.414 & 38.424. Like it was with rel-8 the interesting & hectic part of the mobility takes place in RAN. Out of all efforts in rel-8 PMIP never made it into RAN par of the network. Too much legacy there. If there’s a desire to revert the TR38.801 decision on using GTP, the timeframe is getting tight. The good point is that RAN (S1, X2, etc) never used GTP-C as a control plane.

- Jouni

> On May 10, 2017, at 1:49 PM, [e-mail] wrote:
> 
> Samita
> 
>  
> 
> 3GPP 5G architecture is defined in http://www.3gpp.org/DynaReport/23501.htm
> 
>  
> 
> You’ll notice on page 90 that the protocols in the User Plane are not currently defined and that the concept of a central anchor is retained, at least for the PDU service.
> 
>  
> 
> David
> 
>  
> 
> From: 5gangip [mailto:[e-mail]] On Behalf Of Samita Chakrabarti
> Sent: 10 May 2017 21:34
> To: [e-mail]
> Cc: [e-mail]; Ca By <[e-mail]>; Mikael Abrahamsson <[e-mail]>
> Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt
> 
>  
> 
> Hi Dirk/Behcet:
> 
>  
> 
> Is there a short presentation or whitepaper talking about 3GPP 5G transport architecture ?
> 
> Would be very useful to have that side by side while 5gangip tries to come up with new protocols.
> 
> Perhaps it was already discussed, I am coming late in the game...
> 
>  
> 
> Thanks,
> 
> -Samita
> 
>  
> 
> On Fri, May 5, 2017 at 1:46 AM, <[e-mail]> wrote:
> 
> Dear Cameron and Mikael,
> 
> Thanks a lot for your comments. We definitely have and want to simplify our approach for 5G – the described situation is IMO exactly what demands for slicing, i.e. a modular approach with complex and costly functionalities only for dedicated application driven logical sub-networks … whereas for a great deal of traffic the functions to be executed must be as simple as possible – and these functions at control plane level will steer and decide on the separate User Plane paths … with other words what CUPS is all about, right?
> 
>  
> 
> Whether 3GPP is really going for such utmost flexibility currently – that is … let’s say: questionable (IMHO)
> 
> ;-/
> 
>  
> 
> Thanks and Best Regards
> Dirk
> 
>  
> 
>  
> 
> From: Ca By [mailto:[e-mail]] 
> Sent: Donnerstag, 4. Mai 2017 14:56
> To: von Hugo, Dirk; Mikael Abrahamsson
> Cc: [e-mail]
> Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt
> 
>  
> 
>  
> 
> On Thu, May 4, 2017 at 4:04 AM Mikael Abrahamsson <[e-mail]> wrote:
> 
> On Wed, 3 May 2017, [e-mail] wrote:
> 
> > Dear all,
> > As announced yesterday we have uploaded the problem statement draft you find below.
> > Thanks for reading, discussing, commenting …!
> >
> > Best Regards – also on behalf of all the authors
> 
> Thanks for writing this. My biggest goal with 5G has been simplification.
> I've been involved in running 3GPP networks for a long time, and they're
> hugely complicated and expensive.
> 
> >From my reading of this document, it seems that all traffic is still going
> to be tunneled, one way or another. It's good that the mobility functions
> is moved more towards the UE, because I imagine this will vastly simplify
> the network in between.
> 
> But why not take it one step further and only do access granting to the
> network resources, and then it's up to the UE to do whatever it
> wants/needs? Let's postulate that 90% of all traffic from devices is
> Internet traffic, and most of that is streaming video. If all network
> resources just is "IPv6 access to the Internet" as its primary service,
> then when the device connects (wifi, 5G, 4G, whatever), it gets IPv6
> Internet access. Access is granted based on a cryptographic signed token,
> where the token just is "my home network allowed me access to the network
> for X minutes". Then the base station, AP, whatever can just look at this
> token and grant access immediately without even talking to "core network".
> It just need to keep an updated list of cryptographic information to
> verify this token, or it needs to know where to verify it on demand.
> 
> Then you can (for instance) for streaming video, just start requesting
> video over this (new) connection. If it's MPTCP, just use that. When you
> need to hand over, just go to the new access method, attach, stop
> requesting data on the old one, start using the new address space. No
> handover is really needed. For traffic that needs handover, yes, you have
> to tunnel it using LISP, ILA, whatever (with the provision that Lorenzo
> pointed out, we need to have prefixes to be mobile, not individual
> addresses).
> 
> But my point here is, why tunnel most of the traffic, when most of the
> traffic actually doesn't need fast mobility? Most of the data on the
> Internet today is 1-2 seconds of streaming video, anyway. A lot of it can
> be pre-buffered, so having a few second outage during this "handover"
> (which isn't really a handover, just moving from one access to another) is
> no problem as far as I can see it.
> 
> If there is anything really broken with this idea, I'd like to understand
> why. Because I have pitched this idea in a few forums, and I've never
> heard why it wouldn't work and be a lot simpler than other proposals?
> 
>  
> 
> It will work with existing network and 3gpp proposed 5G core. The key concept is CUPS.  
> 
>  
> 
> For the internet access use case you described, the PPF (PGW user plane in 5G) can exist at the cell site or somewhere close to the base station for an internet access slice.  The 3GPP 5G generalizes these functions, and because they are virtual, they can be instantiated at any arbitrary location that make sense. Perhaps iot is a centralize public cloud for least cost signaling  and perhaps vehicle to vehicle is terminated at the base station for lowest latency. 
> 
>  
> 
> 3GPP already has this in the works afaik. 
> 
>  
> 
> Cameron
> 
>  
> 
>  
> 
> 
> --
> Mikael Abrahamsson    email: [e-mail]_______________________________________________
> 5gangip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/5gangip
> 
> 
> _______________________________________________
> 5gangip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/5gangip
> 
>  
> 
> _______________________________________________
> 5gangip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/5gangip