Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [802.21] Ad hoc telecon for Dec 13th



Mathieu,

Thanks for your comments. Please see new dialog below:

Regards,
Ulises

-----Original Message-----
From: zze-Seamless PERESSE M ext RD-RESA-REN [mailto:mperesse.ext@RD.FRANCETELECOM.COM] 
Sent: Wednesday, December 14, 2005 11:33 AM
To: STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] Ad hoc telecon for Dec 13th

Hi all,

Comments inline:

-----Message d'origine-----
De : Srinivas Sreemanthula [mailto:Srinivas.Sreemanthula@NOKIA.COM] 
Envoyé : mercredi 14 décembre 2005 01:49
À : STDS-802-21@listserv.ieee.org
Objet : Re: [802.21] Ad hoc telecon for Dec 13th

Hi Ulises,

On the first point, slide 3 shows the same. MIH discovery is agreed to be at the transport level and the MIH capability discovery is defined in MIH protocol. So, they indicated in two steps. I made one box to indicate that this a "setup" state before moving to "active".

The second point is interesting and I agree with you on this. Do you see that we do this negotiation as part of registration or after registration? I think we can do this during registration procedure because during registration the supported set of commands and events may change on either side based on their relationsip. We also have capability discovery to say what services and what events/commands are supported on the other end before registration. But we need to revisit that to improve some parts of it.

[MP] The negociation phase can be part of the registration process, and negociation messages are not Events, Commands, or Information message so it would make sense to say "MIH peers may not provide or accept MIH Events, MIH Commands, or MIH Information messages without an active registration session". 

[Ulises Olvera]> Another way of looking at it is to include negotiation parameter within existing Command and Event messages. In fact there is already similar behavior within the existing messages. E.g., Negotiation can be achieved using the the MIH_Event.Registration.Request/MIH_Event.Registration.Confirm pair. When the requesting peer solicits a service, it is up to the service provider to decide whether the requested service can be honor. However this behavior does not work in the same way for commands. This is where I think there might be some extra work to be done <[Ulises Olvera].


Regards,
Srini

>-----Original Message-----
>From: ext Olvera-Hernandez, Ulises
>[mailto:Ulises.Olvera-Hernandez@InterDigital.com]
>Sent: Tuesday, December 13, 2005 7:31 AM
>To: Sreemanthula Srinivas (Nokia-NRC/Dallas); 
>STDS-802-21@listserv.ieee.org
>Subject: RE: [802.21] Ad hoc telecon for Dec 13th
>
>Srini,
>
>Thanks for taking the lead on this area.
>I won't be able to attend the conference, but I have a couple of
>comments/questions:
>
>1) The slides indicate that the registration process occurs after the 
>discovery procedure. Do you include the Capability Discovery procedure 
>in this statement? Knowing the capability in prior to registration 
>might reduce unnecessary siganalling.
>
>2) The registration procedure also indicates that services might not be 
>provided without an active session. However both peers might need to 
>agree on what services can be acceptable.
>E.g., a UE might register for ES but in order to accept commands from 
>the remote peer in the network a negotiation process might need to take 
>place so that both peers agree on the level service that should be 
>provided (E.g., the UE might not accept all commands coming from the 
>network).
>
>Regards,
>Ulises
>
>-----Original Message-----
>From: Srinivas Sreemanthula [mailto:Srinivas.Sreemanthula@NOKIA.COM]
>Sent: Monday, December 12, 2005 11:24 PM
>To: STDS-802-21@listserv.ieee.org
>Subject: Re: [802.21] Ad hoc telecon for Dec 13th
>
>Hello all,
>Here is the slideset that is built on top of last meeting and some 
>email discussions. We can use these topics for open discussions and 
>draw some conclusions.
>
>Regards,
>Srini
>
>>-----Original Message-----
>>From: ext Srinivas Sreemanthula
>>[mailto:Srinivas.Sreemanthula@Nokia.com]
>>Sent: Monday, December 12, 2005 3:09 PM
>>To: STDS-802-21@LISTSERV.IEEE.ORG
>>Subject: Re: [802.21] Ad hoc telecon for Dec 13th
>>
>>Hello,
>>Here is telecon bridge info for  Dec 13th 9am-11am EST about
>>L3 ES/CS requirements.  An agenda will follow soon.
>> 
>>Regards,
>>Srini
>> 
>> US Phone Number: 972-894-6500
>> EU Phone Number: +358 7180 71870
>> Conference ID: 37494, PIN: 561988
>> Type of reservation: Single reservation: 13.12.2005
>> (GMT-06:00) Central Time (US & Canada)  Number of
>>participants: 20  Instructions language: English
>>
>>
>>________________________________
>>
>>		From: ext Ajay Rajkumar [mailto:ajayrajkumar@lucent.com]
>>
>>		Sent: Friday, November 25, 2005 7:22 AM
>>		To: STDS-802-21@listserv.ieee.org
>>		Subject: [802.21] Ad hoc telecons for the next
>two months
>>		
>>		
>>		*
>>		Hi everyone,
>>		
>>		The external meeting documents server has been
>updated and synced. At
>>the end of the just concluded Vancouver session the working group 
>>approved a set of telecon for the next two months.
>>		
>>		Here is the schedule of these telecons again. 
>>Please note that all times are from 9-11 am EST, which was acceptable 
>>to all and seems to be most suitable time for all time zones
>concerned.
>>		
>>		
>>		* 
>>		*IS Higher Layer Transport Requirements 
>>		   December 8, 2005 
>>		-    January 10, 2006 
>>
>>		*ES/CS Higher Layer Transport Discussion 
>>		-    November 29, 2005 
>>		-    December 13, 2005 
>>		-    January 12, 2006 
>>
>>		*802.11 Requirements 
>>		-    January 5, 2006 
>>		*
>>		802.16 Requirements 
>>		   -December 15, 2005
>>		
>>
>>		The telecon bridge number and codes would be
>announced closer to the
>>respective telecon dates.
>>		
>>		Best Regards,
>>		-ajay
>>		
>>		Ajay Rajkumar
>>		Chair, IEEE 802.21 WG
>>		
>>		
>>		
>>		
>>		
>>		
>>
>
>