FW: [Fwd: FW: Monday August 9th 7AM Pacific ad hoc on requirements]
Since no comments sofar, I send this to the reflector so we can discuss this
in the teleconference.
BR, Reijo Salminen
-----Original Message-----
From: Reijo Salminen [mailto:reijo.salminen@seesta.com]
Sent: 24. elokuuta 2004 16:05
To: 'Peretz Feder'; 'yogeshbhatt@motorola.com'; 'stephen.mccann@roke.co.uk';
'vivek.g.gupta@intel.com'; 'Ajay Rajkumar'; 'Michael Williams';
'alan.carlton@interdigital.com'
Subject: RE: [Fwd: FW: Monday August 9th 7AM Pacific ad hoc on requirements]
Hello,
As agreed in the teleconference I try here to explain a bit more what I had
in mind on the chapter 6.2 on the req.spec.
I started the chapter by explaining the situation regarding 3GPP-WLAN
interworking standardization, and Peretz made some adjustments so I assume
we can agree upon the first chapter in the coming teleconference.
Then in the next chapter the aim from my side was to point out the
differences in the HSDPA and the rest of the bearers (in the example DCH)
what comes to the architecture where the protocol layers are terminated in
UTRAN. The reason for terminating MAC in the base station (Node B) at HSDPA
is to decrease the memory requirements at the terminal - the other bearers
have MAC terminated at the RNC. It might not be a trivial task to introduce
802 family network infrastructure into UTRAN and support scenarios 4 and 5
when the base product has such an internal architecture - this I tried to
pinpoint in the chapter in as polite way as I could so that 3GPP could also
possibly have similar opinions on what is written there.
Maybe it is also worth a discussion what do we expect 3GPP will most likely
be doing with the scenarios 4&5. Namely if the scenarios 1&2 are in place,
then the billing and authentication is controlled from 3G systems side, and
scenario 3 will introduce IMS services for the interworking systems. In such
a situation the 3G operator has quite a strong hold on the interworking from
business point of view, and the next question would then be how big impacts
is 3GPP willing to introduce in the UTRAN products due to interworking with
802 family systems. As we know, UTRAN is very crucial element in the success
of 3G, and any major changes in the UTRAN products at this stage of 3G
ramp-up are very likely considered as a big risk at the 3GPP.
In this situation it might be good to have respect from 802.21 side towards
3GPP and especially not to advice them what they should be doing and how -
that is what I ment by the sentence 'not introducing unnecessary constraints
on the liaison work between us and 3GPP'. We could refer to chapter 6.1 with
some polite words and leave all the doors open so that when 3GPP comes a bit
further on the scenarios 4&5, then the details could be specified in more
detail. In this way we can be prepared for whatever 3GPP decides to do with
the scenarios 4&5.
Any comments to this approach? This is more like a proposal of a political
character that technical, as you can see.
Best Regards, Reijo Salminen
-----Original Message-----
From: Peretz Feder [mailto:pfeder@lucent.com]
Sent: 12. elokuuta 2004 8:40
To: yogeshbhatt@motorola.com; reijo.salminen@seesta.com;
stephen.mccann@roke.co.uk; vivek.g.gupta@intel.com; Ajay Rajkumar; Michael
Williams; alan.carlton@interdigital.com
Subject: Re: [Fwd: FW: Monday August 9th 7AM Pacific ad hoc on requirements]
Vivek, Michael:
Per your request I have added my 6.2 contribution as a follow up to Reijo's.
I
covered UTRAN, EV-DO but not 3g1x as I ran out of time.
I also made a few changes throughout the document and removed the reference
to
scenarios 4 and 5 in section 5.2. as it is now properly mentioned in section
6.2.
Peretz Feder
Peretz Feder wrote:
>
>
----------------------------------------------------------------------------
----
>
> Subject: FW: Monday August 9th 7AM Pacific ad hoc on requirements
> Date: Mon, 9 Aug 2004 09:39:24 -0700
> From: <Michael.G.Williams@nokia.com>
> To: <yogeshbhatt@motorola.com>, <pfeder@lucent.com>
> CC: <reijo.salminen@seesta.com>, <ajayrajkumar@lucent.com>,
> <vivek.g.gupta@intel.com>, <stephen.mccann@roke.co.uk>
>
> Hi Reijo,
>
> I too am concerned with this section (and corresponding 6.2)
>
> While we can envisage handover scenarios, they may not all be fully
endorsed once 3GPP reaches that stage.
>
> I'm coming up to speed a bit on the work in the scenario 3 that is going
on right now. It seems to me they are tightly tying their requirements to
802.11 and are phrasing things so that they would probably need to redo a
great deal if they wanted a 802.16 coupling (or 802.3 for that matter)
>
> It seems that the interworking model of scenario 3 emerging is going to
affect the scenario 4&5 quite a bit.
>
> In any case, could those on this list consider drafting something for 6.2
and any revisions for 5.2 in advance of Thursday AM's call and either
circulate within this cc list or to the reflector? It would be good to have
some discussion already occurred before then.
>
> Best Regards,
> Michael
> -----Original Message-----
> From: ext Reijo Salminen [mailto:reijo.salminen@seesta.com]
> Sent: Monday, August 09, 2004 5:14 AM
> To: Williams Michael.G (Nokia-ES/MtView); STDS-802-21@listserv.ieee.org
> Subject: RE: Monday August 9th 7AM Pacific ad hoc on requirements
>
> Greetings,
>
> Once again the following comment: (I hope we can take this after Ajay's
> comments as agreed in previous meeting)
>
> Comment 1 on chapter 5.2 on rev 7 requirement document:
>
> The following text:
>
> "The 802.21 standard shall facilitate handover scenarios related to
> WLAN-cellular inter-working as specified by Scenarios 4 and 5 in 3GPP
> standard."
>
> Should be either removed, or rewritten in the following way:
>
> "The 802.21 standard shall facilitate service continuity and seamless
> operation in the handover process between the IEEE 802 and Non-IEEE
Cellular
> systems."
>
> This text would consider also other than WLAN systems (802.11?) from 802
and
> have the requirement in cleartext what the scenarios from 3GPP are aiming
> at. Then it is up to the proposals to come out with a solution how this
> could be achieved. As mentioned before there is very little information
> available about the details of the scenarios 4 and 5 from 3GPP side, so it
> is not possible to evaluate the proposals on this requirement as it is
> written now in the requirement spec.