RE: [802.21] Providing QoS through current link layer primitives
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
>>
>>
>
>
>