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