Title:	Follow up S2-99093  (Work Item Proposal for the support of IP communication using PPP for MS（ADP） access)　
Date:	99-04/19-21
Source:	NTT DoCoMo
Related to:	Evolution point for Architecture and related Protocols
1.	Abstract
This contribution follows up the previous contribution, S2-99093 “Work Item Proposal for the support of IP communication using PPP for MS(ADP) access”, which gives a proposal for the improvements of the SM and GTP in order to support IP communication with PPP terminating at ADP(MS). This contribution clarify other important merits  of terminating PPP at ADP(MS) when using PPP for IP communication than those described in S2-99093.

2.	 Discussing point: the Clarification of the other merits from the terminating PPP at ADP(MS) 
This section clarifies some important merits of the terminating PPP at ADP(MS)  when IP communication uses PPP as access interface. Before go into the clarification, the following clarification is done for the convenience to the discussion. 
When IP communications are carried out, possible and necessary to be supported, user interfaces are as follows.
(a)	LAN interface (e.g. Eathernet)
(b)	PPP interface
Each operator is possibly necessary to support both interfaces. According to the current GPRS/UMTS specification, LAN interface will be terminated at ADP(MS). This means that at SGSN and especially at GGSN system recognize user data stream as PDP type IP and GGSN will handle user IP packet. On the other hand, in the case of using PPP interface there are following three alternatives with respect to the terminating point.
<1>	Terminating at ADP(MS) : included in the PDP type IP
<2>	Terminating at GGSN : included in the PDP type PPP
<3>	Terminating at ISP : included in the PDP type PPP
It is understood that both PDP type IP and PPP are supported in the Release98 GPRS specification and should be supported in UMTS/GPRS Release99 specification. The following subsections clarifies the merits by comparing among three alternatives.
2.1	Reducing the implemented functionality of GGSN for user plane considering of supporting various interface for IP communications
In case <1> UMTS networks can recognize and handle IP communications as one single type of PDP type IP for both user LAN interface and user PPP interface. This means that UMTS networks are required to implement only single functionality both for LAN interface and PPP interface in user plane. This thing gives a good influence on network(GGSN) implement cost.
In case <2> user IP communications with PPP interface are recognized as PDP type PPP in the UMTS networks. On the contrary to the case <1>, in case <2> UMTS networks have to handle IP communications with LAN interface and IP communication with PPP in the different way for user plane. It is also recognized that GGSNs handle user IP layer (as main purpose) adding to PPP handle. Consequently in case <2> GGSNs need to implement both IP layer functionality and PPP layer functionality and GGSNs and necessary functionality between LAN interface and PPP interface are different. 
In case <3> user PPP flames are necessary to be encapsulated and transferred to ISP by each user logical connection base. This means that specific  functionality for PPP is necessary to GGSNs in user plane (than for LAN interface).
In the conclusion, the case <1> can achieve single implementation between LAN interface and PPP interface. On the  other hand case <2> and <3> need to implement plural(not single) functionality. So the case <1> is the best choice from GGSN functionality implementation point of view. 

2.2	Reducing the processing burden of GGSN for user plane 
According to the PPP specification described in RFC1662, PPP termination requires functionality for user flame handling to GGSNs. Actually, there are three “modes” (Bit stuffing, Octet synchronous and asynchronous) for transmission of flame data on layer1 and necessary functionality are different in each “mode”. But any “mode” will requires handling of every octet of every user PPP flame. So case <2> brings a heavy burden to GGSNs of UMTS  networks. It is obvious that IP handling requires much lighter burden to GGSNs since IP handling only requires header handling. We can say the same thing in case that the same operator share both a UMTS network and a ISP facility. Consequently from burden of user flame handling point of view, it is obvious that case <2> is the best choice for the UMTS networks. 
From processing burden point of view, case <3> is in a degree heavier than case <2> since case <3> require GGSNs to mapping every PPP flame between GTP and e.g L2TP.
In the conclusion, case <2> is the best choice from processing burden point of view.
2.3	Interworking with user IP layer point of view
One of the main target of S2 QOS adhoc work is End to End QOS which interwork with user level IP QOS. In case <3> user IP communications with PPP interface are recognized as PDP type PPP in the UMTS networks. And UMTS network only relay PPP frames to ISP. This means GGSNs in the UMTS networks don’t terminate PPP layer and user IP layer. So GGSNs can see neither RSVP messages (carried as ones of user IP messages) or traffic class  field in the user IP packet for differenciated service. Consequently case <3> can not achieve End to End QOS. (It is noted that ADP/MS also can not interwork with user IP layer since PPP is terminated at user TE.) 
In the conclusion, case <3> can not be selected from interworking with end to end QOS point of view.
2.4	Inefficiency at header compression in case <2> and  <3>
In the current discussion, it is assumed that LLC is removed from UMTS protocol stacks and no flow control mechanism is introduced on Iu reference point. If the UMTS specification follows the assumption, a certain volume of packets are lost at radio congestion (and Iu transmission loss) by discarding packets in RNC. If lower link is in erroneous situation, header compression functionality can not send out well compressed packets.  
In the conclusion, case <2> and <3> can not be selected from header compression point of view. 
2.5	From ISP point of view
It is not always that ISP allows to implement L2TP or PPTP to their facility. If ISP does not allow it, case <3> can not be selected. So case <3> is very risky.
In the conclusion, case <3> is too risky to be selected.
3.	Conclusion
According to the above discussion, it is obvious that case <1> is the best choice for UMTS networks.
Consequently, PDP activation procedure should be improved in UMTS phase1 specification for the efficient support of IP communication with PPP termination at MS(ADP) side. 

4.	PROPOSAL
It is proposed that the following text should be included in the chapter 7(Working assumption) or at least in the chapter 9 (Key issues)
<Proposed text>
7.4 or 9.19 The improvement of PDP activation procedure for efficient support of IP communication with PPP termination at ADP(MS)
In order to support IP communication with PPP termination at ADP(MS), PDP activation procedure and related protocols (SM and GTP) are necessarily to be improved. The impact of improvement should be minimized and done in a general way such as not targeting only PPP but e.g DHCP.

APPENDIX
Title:	Work Item Proposal for the support of IP communication using PPP for MS(ADP) access
Date:	99-03-15
Source:	NTT DoCoMo
Related to:	Work Item for Architecture and related Protocols
5.	Abstract
This contribution shows one proposal for the work item for the support of IP communication using PPP for MS ADP  access.The background for this proposal is shown in the section 2.Then the discussion about PPP timer issue and ISP level parameters transfer issue are described in the section 3. Finally this contribution proposes evolution points for the PDP activation in order to solve the problem.

6.	Background of the evolution point
6.1	 The Target Service Cases considered in this contribution
The target service cases considered in this contribution are described as followed for the help of understanding of this contribution’s idea.
Situation: One IMT-2000 user is roaming from Japan to Europe and communicating to its Home network side PDN (packet data network) with IP application. One remarkable characteristic is that its “Socket” (or driver) in the laptop computer uses PPP for the support of its application. The other remarkable characteristic is that user uses Best effort service of IMT-2000 service (or traffic) category.
Case1  The IMT-2000 user is communicating via its Internet which has not ISP level roaming agreement with  either visiting network operator or visiting network side ISP.
Case2  The IMT-2000 user is communicating to its INTRANET Internet which has not ISP level registration with  either visiting network operator or visiting network side ISP.
Case3  The IMT-2000 user is communicating to the application server in the home network and home network has not ISP level roaming agreement with  either visiting network operator or visiting network side ISP.
Note: GRPS specification allows mobile operators to be ISPs.

6.2	 Rough History of GPRS specification relating to this issue 
(1) Release97
Release97 GPRS specification supports IP protocol as one “PDP type”. In the 07.60, the mapping example between PPP and SNDCP at the MS side for the upper IP communication is described.
(2) Release98
One proposal was made and accepted for the support of PPP as one “PDP type” which means that networks receive (IP over) PPP packets and send out IP packets on the interworking point to ISP (i.e. Gi reference point).
The PDP type of IP remain since the support of e.g. IP over LAN interface is necessary for the GPRS.

The reason described in the proposal are 2 points as follows.
(a)	PPP Request-Acknowledge Timer is 3 seconds.
(b) Parameters for authentication and other service features for the ISP can not be communicated between ISP and MS in the current GPRS information flows (i.e. PDP activation) 

7.	Discussion
7.1	 The Timer can wait for the communicating between user application and GGSN for the PPP request and  acknowledge sequence?
The target cases of this contribution may causes “the timeover delay” of 3seconds which means unable to connect  to the PDN in a considerable possibility. The following causes can be considered as the “contributors” to the delay.

(1)	Traffic jam at air interface for best effort traffic 
Traffic jam will cause delay for the channel allocation for the traffic.
(2)	Retransmission of RLC for error correction of air interface.
(3)	Traffic jam on Iub, Iur, Iu and the range between SGSN and BG (boarder gateway) in the visiting network for Best Effort traffic.
(4)	Traffic jam on intermediate network (between Japan and Europe) for Best Effort traffic.
(5)	Traffic jam on the range between BG and GGSN for Best Effort traffic.
Especially in the long path, the possibility of “over time” will increase. So NTT DoCoMo concerns about the target cases in the condition that PPP is terminated in the GGSN as user protocol (PDP). But it should be noted that since the other cases than roaming or Best effort services may not cause “time over” NTT DoCoMo does not intend to deny the support of the termination of PPP at GGSN itself.

7.2	 The possible solution for the trouble
The possible solution for the concern described in the above is the termination of PPP at MS side. But this solution still has the trouble described in the (b) of section 1.2 . The reason for the trouble of (b) is mismatching the sequence of PPP and PDP activation (PDP activation has only one upwards message and only one downwards message). So for the true solution, PDP activation should have some additional massages for the support of ISP related parameters transfer as the evolution point. 

7.3	 Does the C-plane satisfy the delay condition?
According to the current GPRS specification, the system distinguishes the Control planes traffics from user traffics. And the system gives the best priority for the control plane traffics. We believe that IMT-2000 system can control the delay values for the control plane traffics. The assumed possible techniques for the solution for the implementation is described as follows. (ffs)
(a)  The radio code and Iub path for RRC connection (control plane traffic) can be distinguished from dedicated channels and common channel for the user traffics.
(b)	The signaling path can be separated from user traffic path for Iu.
(c)	The signaling path can be separated from user traffic path for Gp by allocating different IP addresses to between signaling traffic and user traffic. (this means that individual leased line can be allocated for signaling traffics ,which can be assumed as not considerable traffic volume.)

The above method may be used simultaneously or separately for operators. How  much do they want to improve the delay is up to operators. And it is important for operators that such improvement should be allowed.

7.4	 The basic condition for the solution from design point of view
(1)	The impact on the current GPRS specification and the coming GPRS network shall be minimized.
(2)	The new messages to be added to PDP activation will exchanged between MS and GGSN. The parameters in the messages are transferred by SGSN transparently. This way of solution will cause the minimal impact on the SGSN.

8.	Conclusion
PDP activation should be improved for the support of PPP termination at MS side as well as PPP termination at GGSN side. Operators should be allowed to choose either one solution.

9.	PROPOSAL
The new work item for the PDP activation should be created. The content of the work item will be proposed by NTT DoCoMo later.