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.
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.
-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