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

RE: [802.21] Providing QoS through current link layer primitives



Hi Nada,

Thanks for your answers, 

-----Message d'origine-----
De : Nada Golmie [mailto:nada.golmie@nist.gov] 
Envoyé : lundi 27 février 2006 23:09
À : zze-Seamless PERESSE M ext RD-RESA-REN
Cc : Reijo Salminen; STDS-802-21@LISTSERV.IEEE.ORG; Olvera-Hernandez, Ulises; nada.golmie@nist.gov
Objet : Re: [802.21] Providing QoS through current link layer primitives

Hello Mathieu,

The MIH QOS framework for 802.21 described in 21-06-0493-02 can be easily extended in order to communicate the application QOS (static) requirements to the MIH function and/or decision engine.
I guess we need simply add the "MIH_Configure_QOS" command and event as you suggest. No other additions are required as far as I can tell.

Multiple parameters can be specified as you suggest in step A. Observe that these parameters should refer to the MIH QOS pre-defined (or
proposed) list, i.e. IPTD, IPDV, IPLR, and IPER. We can certainly keep some "reserved for future use".

Some comments/ clarifications on the terminology you use:
1) What you refer to as  type 1 QOS are commonly known as application QOS requirements. These are expected requirements in order for the application to operate adequately. There are several ITU-T publications that make recommendations for different class of service/applications. 
Thus, these requirements can be known a priori to the MIH or may not be exchanged on a session by session basis.

[MP] You mean that if an application use "MIH_Configure_QoS" to express its App QoS requirements, there is no need to specify any values, but rather a type of service/application ?

2) What you refer to as type 2 QOS are known as network performance objectives and those are real-time measurements obtained from the network and made available to the MIH/ decision engine or even the application in order to perform some action, for example a handover, or no handover.

[MP] OK, here is what I would propose for a start:
- define the 2 types of QoS parameters in the definition section (application QoS requirements and network performance objectives (perhaps with ITU-T references)). -
- modify Paragraph 5.1.3 so that it roughly describe what we want to achieve (not specifically how).
- add MIH_Configure_QoS so that the proposal keeps its consistency.

-Nada


Reijo Salminen wrote:

>Hi, Mat
>
>Thank you for your very fruitful answer.
>
>I agree it would be good to spend some time on the scenarios, it is 
>very good input to the group and will help in achieving a good 
>understanding of the problematics and thus improve the possibilities to 
>come up with a high quality standard in IEEE 802.21.
>
>I warmly welcome to cooperate on this issue further, we could work on 
>this during next week so that we would have an updated version of the 
>submission to present and discuss further in the group during Denver 
>meeting.
>
>Any comments, Nada, Ulises, rest of the group?
>
>BR, Reijo
>
>
>  
>
>>HI Reijo,
>>
>>Thanks for your answer.
>>
>>Even if the use cases and scenarios are out of scope, i think it is 
>>essential to share them among the group, so that we all  grasp the 
>>reason why a particular feature needs to be added.
>>
>>I will now present what I have in mind, a particular use case 
>>(obviously with some out of scope material..) and then the features 
>>needed to make this use case possible through .21:
>>
>>
>>To function properly, certain applications need a minimum level of QoS 
>>(for example VoIP or VideoConf). They also need to  adapt to condition 
>>changes due to the wireless environment. In other words, for an 
>>application to operate properly, the  currently available QoS level 
>>must somehow match the minimum QoS level that the application needs. 
>>Thus, as far as an application is  concerned, we can distinguish two 
>>types of QoS
>>info:
>>
>>Type 1- The application's QoS needs (static information) (ex: 
>>VideoConf Throughput:100kbps-Low Delay..) Type 2- The currently 
>>available QoS (values are provided by the links, at L2, IP or TCP 
>>level - dynamic information) that can be provided to the application.
>>
>>If I understood correctly, you provide a means for "type 2" QoS info 
>>to be obtained by MIH users from the MIH, via MIH_Link_Parameter_Report.
>>
>>But if you don't have any input from your applications ("type 1" QoS 
>>info), you won't be able to make them work optimally (you can just 
>>maintain a pre-defined QoS level in your terminal, which can be 
>>sub_optimal depending on the apps your run) I think it should be also 
>>good to standardise the way applications communicate their QoS needs 
>>("type 1" QoS info). One may argue that this can  be directly 
>>interfaced with a decision engine but in this case applications will 
>>have to be compatible with each networks/terminal's decision engines. 
>>So I think we should provide this feature into the MIH in the form of 
>>two primitives:
>>
>>- One command (MIH_Configure_QoS.req/resp): for application to inform 
>>the MIH of their QoS needs.
>>- One event (MIH_Configure_QoS.ind): for MIH users (such as decision
>>engines) to be notified of a new application's QoS need
>>
>>Here is a scenario that uses these primitives and yours:
>>(Note: MIH Users/MIH exchanges can be local or remote - MIH/Link Layer 
>>exchanges are local - some required MIH messages exchanges are not shown):
>>
>>A- First step: QoS needs configuration
>>
>>APP		       				Decision Engine
>>|								^
>>|								|
>>|1/3)MIH_Configure_QoS.request/response		|2)MIH_Configure_QoS.indication
>>|								|
>>v								|
>>MIH --------------------------------------------
>>
>>
>>
>>In this step, the application configures the QoS level, according what 
>>it is needed to function properly.
>>Multiple QoS parameters can be specified and there can be multiple 
>>values for one QoS parameter, such as (Minimum, Average,  Maximum). 
>>Two new primitives are required: MIH_Configure_QoS in the form of a 
>>command (1 and
>>3) and in the form of an event (2)
>>-> The MIH user ID (or application ID) must be embeded in the
>>MIH_Configure_QoS primitive.
>>
>>
>>B- Second Step: Threshold configuration
>>
>>
>>Decision Engine
>>|
>>|
>>|4/7)MIH_COnfigure_Threshold.request/response
>>|
>>v
>>MIH
>>|
>>|
>>|5/6)Link_Configure_THreshold.request/response
>>|
>>v
>>LLs
>>
>>If needed the Decision Engine can (re)configure thresholds for 
>>different QoS parameters.
>>
>>
>>C- Third step: QoS parameter reports
>>
>>APP		       		Decision Engine
>>^						^
>>|						|
>>|9)MIH_Link_PArameter_Report		|9')MIH_Link_PArameter_Report
>>|						|
>>MIH --------------------------------
>>^
>>|
>>|8)Link_Parameter_Report
>>|
>>LLs !!!Threshold crossed!!!
>>
>>In this step, a threshold is crossed for a particular parameter.4) The 
>>Link_Parameter_Report is sent to the MIH which generates a 
>>MIH_Link_Parameter report towards the Decision Engine (and possibly 
>>the application itself).
>>
>>
>>D - Fourth Step: Handover
>>
>>
>>APP		       		    Decision Engine !!!!HO Required for terminal A
>>^
>>|							|
>>|13')MIH_Link_HAndover_Complete.ind		|10/13) MIH_Switch.request/response
>>|							|
>>MIH <-------------------------------------
>>|
>>|11/12)Link_Switch.request/response
>>|
>>v
>>LLs
>>
>>In this step, if the Decision Engine decides an HO is needed for 
>>terminal A, it sends a MIH_Switch.request to the MIH which trigger the 
>>actual HO. Upon success, the Decision Engine (and possibly the 
>>application) is notified.
>>The application can keep on operating at an optimal QoS level.
>>
>>--
>>
>>This could apply both to terminal based and network based framework. 
>>New parameters may have to be specified for the primitives used in 
>>this scenario.
>>
>>I hope this is clear enough!
>>
>>My wish is to be able to come up with an optimal QoS framework 
>>together, if you like the ideas I presented above and if it somehow 
>>shares your representation of the problem.
>>
>>Comments are welcome.
>>
>>
>>Regards,
>>
>>Mathieu
>>
>>
>>-----Message d'origine-----
>>De : Reijo Salminen [mailto:reijo.salminen@seesta.com]
>>Envoyé : jeudi 23 février 2006 09:40
>>À : zze-Seamless PERESSE M ext RD-RESA-REN; 'Olvera-Hernandez, 
>>Ulises'; STDS-802-21@LISTSERV.IEEE.ORG Objet : RE: [802.21] Providing 
>>QoS through current link layer primitives
>>
>>Hi, Mat
>>
>>It seems that the reflector has been down, so I send once more my 2 
>>cents on this, maybe also Nada has some comments since she has been 
>>the author of most of the slides in the submission.
>>
>>The main point is to make the QoS information available for the MIH 
>>users, and then use the same lexicon that is used in ITU-T 1540/1541 
>>and IETF NSIS, with lexicon I mean the parameters and their 
>>interpretation. If the group has a possibility to get acquainted with 
>>the referred documents/WG material (NSIS under URL 
>>http://www.ietf.org/html.charters/nsis-charter.html), it would help in 
>>understanding why the number of parameters should be kept as low as 
>>possible, but still covering most of the predictable user application 
>>requirements.
>>
>>Then another thing is what the users will be doing with the information.
>>This is outside the scope of 802.21, but since we anyway need to have 
>>some visions what the possible scenarios could be, and what you have 
>>asked, we could do some brainstorming on that.
>>
>>One probable user of the information is the functionality that is 
>>involved with the interworking towards the core network, say for 
>>example using NSIS signaling. In that case the 802.21 could maybe seen 
>>as a network segment that is at least partially beyond the UNI 
>>interface, where the scope of
>>ITU-T1540/41 and NSIS ends, if you look at the Figure1/1541 in the 
>>submission. In this example then the NSIS QoS signaling, with the 
>>desired/available/reserved/minimum QoS levels could be extended 
>>towards the access, thus we could have the possibility to introduce 
>>end-to-end QoS in the system, if we want.
>>
>>Another probable user is the decision making engine, which you mentioned.
>>But as we have in several occasions in 802.21 concluded, this is 
>>outside the scope, as is the policies involved.
>>
>>Engineers working with the Admission Control functionality, might be 
>>interested in using the possibilities of the proposed approach.
>>
>>By collecting statistics of the experienced QoS in the access 
>>networks, could give a simple but reliable measure how mature the 
>>access network is, I mean how well the network planning engineers have 
>>done their challenging task on putting the AP:s/BS:es on correct 
>>places and densely enough, as well as how well the admission control 
>>is doing it's part. This information could be useful when making 
>>decisions on the target access networks in the vertical handover - 
>>this of course with cooperation of the information services functionality.
>>
>>There could be several other possible users of the information, the 
>>application adaptation to the situation is one possible scenario, and 
>>several others may emerge once the mechanism is available.
>>
>>I hope this helps in starting this interesting discussion, I hope we 
>>can continue on this in the reflector and in the Denver meeting.
>>
>>BR, Reijo
>>
>>
>>
>>-----Original Message-----
>>From: stds-802-21@LISTSERV.IEEE.ORG 
>>[mailto:stds-802-21@LISTSERV.IEEE.ORG]
>>On Behalf Of zze-Seamless PERESSE M ext RD-RESA-REN
>>Sent: 22. helmikuuta 2006 15:42
>>To: Olvera-Hernandez, Ulises; STDS-802-21@LISTSERV.IEEE.ORG
>>Subject: RE: [802.21] Providing QoS through current link layer 
>>primitives
>>
>>Hi Ulises,
>>
>>I have read your document and I think this is a really good initiative.
>>
>>I have some questions:
>>
>>- do you have a scenario about how an application could use the "QoS 
>>services" provided by the MIH ?
>>
>>If I understood correctly, the application can be informed about the 
>>QoS parameters provided by the lower layers.
>>But what is the application going to do after getting this information ?
>>
>>What I can think of is:
>>
>>- Adapt itself to the new available QoS (for example, for a videoconf 
>>app, if higher throughput is available the video resolution can be raised).
>>- Ask for a handover when the available QoS level is not sufficient 
>>anymore (using an existing MIH primitive ? Or a new one ? Or by 
>>communicating with a decision engine which will then communicate with 
>>the MIH ?)
>>
>>-> The QoS reports will pertain to the serving link or to other 
>>-> available
>>links as well ?
>>
>>
>>Thanks,
>>
>>Mathieu.
>>
>>-----Message d'origine-----
>>De : Olvera-Hernandez, Ulises
>>[mailto:Ulises.Olvera-Hernandez@INTERDIGITAL.COM]
>>Envoyé : mercredi 22 février 2006 13:27 À : 
>>STDS-802-21@listserv.ieee.org Objet : Re: [802.21] Providing QoS 
>>through current link layer primitives
>>
>>Albert,
>>
>>There are new efforts within the 802.21 group to define a set of QoS 
>>parameters that could be used by Mobility Management application and 
>>Higher Layer entities to determine the QoS characteristics of the 
>>underlying link.
>>Although this work has not yet been agreed or sanctioned by the group 
>>there is already a contribution for the coming IEEE 802.21 March 
>>meeting that provides a recommendation as to how this can be done. 
>>This is publicly available at:
>>
>>http://grouper.ieee.org/groups/802/21/
>>
>>The contribution is stored onto the March 2006 folder, under the 
>>following
>>name: 21-06-0493-02-0000-Threshold_Parameters_Survey.ppt
>>
>>Comments are appreciated.
>>
>>Ulises
>>
>>
>>-----Original Message-----
>>From: Soohong Daniel Park [mailto:soohong.park@SAMSUNG.COM]
>>Sent: Wednesday, February 22, 2006 4:52 AM
>>To: STDS-802-21@listserv.ieee.org
>>Subject: Re: [802.21] Providing QoS through current link layer 
>>primitives
>>
>>QoS seems interesting and important issue in terms of link selectio 
>>and change of 21 mobile node. Perhaps, you are saying more parameters 
>>should be newly defined into this spec. than this. Right ? If yes, 
>>which parameters are in your mind ?
>>
>>Daniel (Soohong Daniel Park)
>>Mobile Convergence Laboratory, SAMSUNG Electronics.
>>
>>----- Original Message -----
>>From: "Albert Vidal" <Albert.Vidal@NETLAB.NEC.DE>
>>To: <STDS-802-21@LISTSERV.IEEE.ORG>
>>Sent: Tuesday, February 21, 2006 1:55 AM
>>Subject: [802.21] Providing QoS through current link layer primitives
>>
>>
>>    
>>
>>>Hi all,
>>>
>>>The current version of the draft specifies two primitives to report 
>>>current link quality parameters:
>>>
>>>- Link_Parameters_Change
>>>- MIH_Link_Parameters_Report
>>>
>>>These two primitives could be valuable in order to maintain a certain 
>>>QoS with the current PoA (Point of Attachment), as well as to
>>>      
>>>
>>guarantee
>>    
>>
>>>that the next potential PoA after a handover will be able offer the 
>>>minimum QoS required.
>>>
>>>The text offers four example parameters to indicate the link quality:
>>>Link Speed, Link Bit Error Rate, Link Frame Loss Rate before 
>>>retransmission and Link Received Signal Strength. Nevertheless, more 
>>>parameters will be needed to guarantee the QoS, for instance to
>>>      
>>>
>>address
>>    
>>
>>>load balancing issues among different PoAs of the same network or to 
>>>avoid a handover decision towards a congested PoA. (As an example, 
>>>see some work in progress related to network initiated handovers in 
>>>the framework of the European project Daidalos:
>>>
>>>      
>>>
>>http://www.ietf.org/internet-drafts/draft-melia-mobopts-niho-ps-00.txt).
>>    
>>
>>>How is this aspect of the text expected to be solved? Will the list 
>>>of link layer parameters be left open, or on the contrary, will it be 
>>>closed to a certain number of parameters?
>>>
>>>
>>>Best regards,
>>>Albert
>>>
>>>
>>>      
>>>
>>
>>    
>>
>
>  
>


--
Nada Golmie, Ph.D. 
Manager, High Speed Network Technologies Group National Institute of Standards and Technology 100 Bureau Dr. Stop 8920 Gaithersburg, MD 20899
Email: nada@nist.gov
Phone: (301) 975-4190
Fax:   (301) 590-0932
Web: http://w3.antd.nist.gov