RE: Action item For 01/05 Meeting
Alan et al,
It is interesting to look at the various handoff schemes mentioned on
slide 3 (Station Initiated Station Controlled (SISC), Station Initiated
Network Controlled (SINC), NISC, NINC, etc.) and examine the impact of
these on different work items proposed in CFP:
a] Information Service (IS):
It does NOT seem that the IS shall be impacted much by the type of
handover scheme chosen from above.
b] Event Service:
Same here.
c] MIH Function:
Believe the biggest impact is in this functionality and the type of
handover scheme chosen from above impacts the signaling between MIH
Functional entities on the station and network side.
If this is the case then this understanding should be captured in
Evaluation Guideline document as it might affect the way proposals are
grouped together. If NOT, then let's understand clearly what are the
other implications here.
Also slide 3 mentions/defines "Full Proposal" and it seems that it shall
be treated differently than other cases during down selection. This
needs to be clearly explained as well in Evaluation Criteria.
This now brings us to a further examination of [c] above. The different
schemes mentioned above (SISC, SINC, NISC, NINC) basically reflect on
the type of coupling between different networks and deployment
scenarios. Some of these schemes may not work well (or require extensive
changes) with certain types of networks. For example NINC may not work
well (or require extensive changes) for networks operating in ad hoc
manner in unlicensed bands.
Should 802.21 dictate, recommend or preclude a certain type of handover
scheme between two networks? Should/Can 802.21 change basic structure or
operating mode of certain networks to support a certain type of handover
scheme?
One other thought that was tossed around in the last teleconference was
that 802.21 should support all the above handover schemes. We can go
through that exercise and identify the possible media specific
amendments for different networks, due to these schemes. But then these
amendments are controlled by media specific groups and in certain cases
it's possible that they may not happen for certain handover schemes for
a certain media (group may resist drastic changes to basic structure and
operating mode of a network). What happens to 802.21 in such cases?
Comments, thoughts and any discussions welcome.
Best Regards,
-Vivek
|-----Original Message-----
|From: Carlton, Alan G [mailto:Alan.Carlton@InterDigital.com]
|Sent: Thursday, January 06, 2005 4:31 PM
|To: Gupta, Vivek G; stds-802-21@listserv.ieee.org
|Subject: RE: Action item For 01/05 Meeting
|Importance: High
|
|Thanks for the feedback Vivek
|
|Find my responses below.
|
|BR
|Alan.
|
|-----Original Message-----
|From: Gupta, Vivek G [mailto:vivek.g.gupta@intel.com]
|Sent: Wednesday, January 05, 2005 7:16 AM
|To: Carlton, Alan G; stds-802-21@listserv.ieee.org
|Subject: RE: Action item For 01/05 Meeting
|Importance: High
|
|
|
|Some comments on these slides:
|
|1] Slide 2:
|Instead of having 6 rows (xx to/from yy) maybe we should have only 4
|rows: 802.3, 802.x, 3GPP and 3GPP2.
|The core elements are probably better addressed on individual
technology
|basis rather than through handover scenario basis.
|
|AC: My intent here was to provide maximum flexibility to a proposal and
|also allow good visibility as to what the intended scope of a proposal
is.
|With the matrix as is, it is possible for partial proposal to address
802.x
|to 3GPP only. This would be indicated by the population of Row 5. If
said
|proposal scope covered a Reference Model, Event Service and Information
|Service
|for this scenario then this would be indicated by the inclusion of text
or
|not in the correspondng cells. We can talk about this at Tuesdays
|conference
|call.
|
|Also columns under "Other Elements" should either be removed or left at
|discretion of individual proposal, since those might differ across
|proposals.
|
|AC: I think it would be nice if we could agree some commom elements
|here. The items I have included are just suggestions we can modify
|change them. The intention in my mind of the "other" column was for the
|discretionary element that you have noted.
|
|
|2] Slide 3 and 5 can probably be combined.
|
|AC: Yes you are probably right, I'll make some mods.
|
|On slide 3 if we need 4
|separate columns we may need to explain them somewhat as well, in case
|people have questions.
|
|AC: Totally agree - This may be something that is missing from our TRD.
|We need to have a common agreement on this terminology
|
|Also just claiming support for different
|scenarios is probably not enough. Proposals probably need to back that
|up by identifying "amendments" to these technologies to achieve this
|support and that should probably be captured as well.
|
|AC: Something to this effect could be included in the ultimate
|evaluation guidelines document.
|
|3] Also on slide 5 I am not sure we need these many scenarios. This
|should probably be governed by architectural and other differences
|between different scenarios within a proposal, to make them meaningful.
|
|AC: The Note at the bottom provides for some flexibity. Of course if
|a call flow pertaining to a particular proposal is redundant because
the
|basic mechanisms have already being explained elsewhere in another
|call flow for example then a statement to that effect should be good
|enough.
|
|
|Best Regards,
|-Vivek
|
||-----Original Message-----
||From: owner-stds-802-21@ieee.org [mailto:owner-stds-802-21@ieee.org]
On
||Behalf Of Carlton, Alan G
||Sent: Tuesday, January 04, 2005 4:44 PM
||To: stds-802-21@listserv.ieee.org
||Subject: Action item For 01/05 Meeting
||
||Assuming tomorrows meeting is going ahead. Here is an update to the
|slides
||as requested at the last conference call.
||
||Best Regards
||Alan.
||
|| <<80221 Tuesday 0105 CC Input.ppt>>
||
||