IEEE C802.16j-08/085
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
Comment on service flow management for admission control
Date
Submitted
2008-03-15
Source(s)
Hyunjeong Kang, Jungje Son,
E-mail:
hyunjeong.kang@samsung.com
Youngbin Chang
Samsung Electronics, Suwon, Korea
Rakesh Taori
Samsung Advanced Institutes of
Technology (SAIT)
Re:
IEEE802.16-08/007”IEEE 802.16 Working Group Letter Ballot Recirc #28b: Announcement”
Abstract
This contribution proposes a clarification on service flow management for admission control.
Purpose
Discuss and adopt the proposed text in the TG16j draft.
Notice
Release
Patent
Policy
This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups. It
represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for
discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material
contained herein.
The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name
any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole
discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The
contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.16.
The contributor is familiar with the IEEE-SA Patent Policy and Procedures:
<http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and
<http://standards.ieee.org/guides/opman/sect6.html#6.3>.
Further information is located at <http://standards.ieee.org/board/pat/pat-material.html> and
<http://standards.ieee.org/board/pat>.
Comment on service flow management for admission control
Hyunjeong Kang, Jungje Son, Youngbin Chang, Rakesh Taori*
Samsung Electronics, Samsung Advanced Institutes of Technology (SAIT)*
1
IEEE C802.16j-08/085
1. Introduction
To support SS-initiated or BS-initiated DSA or DSC procedure for service flow addition or service flow change,
IEEE 802.16j draft [1] describes admission control between MR-BS and the RSs along the path connecting the
MR-BS and the MS. If the RS cannot meet the values of the service flow parameters requested in the DSx-REQ
message, the RS may choose to respond in one of the following two ways; 1) the RS changes the requested
values of the service flow parameters with those that it can support and forwards the modified DSx-REQ
message with the modified service flow parameters to its subordinate RS or 2) the RS indicates to the MR-BS
that it cannot support the requested values of service flow parameters and stops forwarding DSx-REQ message
to its subordinate RS.
While method #1 may appear attractive, it is not. In practice, even the MR-BS is required to confirm with a
policy module prior to the actual admission decision. This means that if DSx-RSP message with the last
modification according to method #1 is sent up to the MR-BS, it may incur even more overhead if the policy
module rejects the proposed modifications. Method #2 above, which can be seen as a failure report, may need a
frequent admission control transaction among the RS, the MR-BS and the policy module.
To complement method #1 and method #2, the MR-BS may allow the RS to modify the required service flow
parameters within the minimum requirement and the RS may provide information about the alternative values
for the service flow parameters that it can support, if it cannot support the minimum requirement as well as the
required service flow parameters. Based on this information the MR-BS and the policy module can make a
decision on the associated service flow.
2. Proposed solution
Based on the principle that only network entity such as policy module handles the service flow parameters of a
service flow, it is proposed to disallow one of the ways currently permitted in the specification (i.e. method #1)
which allows the RS to directly update the requested service flow parameters and pass it downstream. Instead,
we can allow an alternative method whereby the RS (at which the requested SF parameters are not supported)
can modify the requested SF parameters within the range of the minimum SF parameter sets, and the RS (at
which the requested SF parameters as well as the minimum SF parameters are not supported) can provide
information concerning values that it can support to MR-BS.
The figure 1 shows an example of proposed admission control during SS initiated DSA procedure.
Here, the procedures are described of admission control transaction along the path.
The MR-BS sends DSA-REQ to check the availability of RS of the requested SF parameters along the path. The
DSA-REQ may include both the requested SF parameters and the minimum SF parameters indicating the
minimum requirement of the requested service flow. Upon receiving the DSA-REQ, if the intermediate RS can
support the requested SF parameters, it forwards the DSA-REQ to the downstream. If the intermediate RS
cannot support the requested SF parameters but it can support the minimum SF parameters, it changes the
requested SF parameters with one it can support and forwards the DSA-REQ to the downstream. When the
access RS receives DSA-REQ, it does the same operations. If the access RS cannot support the minimum SF
parameters as well as the requested SF parameters, the access RS adds the acceptable SF parameters for
indicating the alternative values for the service flow parameters that it can support into DSA-RSP and sends the
message to MR-BS. The acceptable SF parameters are used for indicating QoS parameters RS along the path
2
IEEE C802.16j-08/085
can support.
MR-BS
Int-RS
Access RS
SS
DSA-REQ
DSA-REQ
(minimum SF parameter)
DSA-REQ
(minimum SF parameter)
DSA-RSP
(acceptable SF parameter)
DSA-RSP
DSA-RSP and DSA-ACK
DSA-ACK
DSA-ACK
Admission control
Figure 1 Example of service flow management during SS-initiated DSA
If an intermediate RS cannot support both the required SF parameters and the minimum SF parameters, it
includes the acceptable SF parameters that it can support in the DSA-REQ and forwards the message to the
downstream. If the access RS cannot support both parameters either, it updates the acceptable SF parameters and
sends DSA-RSP with the acceptable SF parameters to MR-BS.
The figure 2 shows an example of updating the acceptable SF parameters at RSs along the path.
3
IEEE C802.16j-08/085
MR-BS
Int-RS
Access RS
SS
DSA-REQ
DSA-REQ
(minimum SF parameter)
DSA-REQ
(minimum SF parameter,
acceptable SF parameter)
DSA-RSP
DSA-RSP
(updated acceptable SF
parameter)
DSA-RSP and DSA-ACK
DSA-ACK
DSA-ACK
Admission control
Figure 2 Example of service flow management during SS-initiated DSA
3. Proposed text change
[Change line 45 in page 126 through line 18 in page 127 of subclause 6.3.14.9.3.1 as follows:]
In an MR network with RSs operating in distributed scheduling mode, before admitting the service flow and
sending DSA-RSP to the requesting SS, the MR-BS requests for admission control decision from the
intermediate RSs in the following way:
— If the service flow maps to an existing tunnel and the service flow parameter for the tunnel is changed,
the MR-BS shall send a DSC-REQ to all the RS on the path to obtain admission control decision. The
MR-BS may include the minimum SF parameter in the DSC-REQ. The minimum SF parameter
represents the minimum requirement that the service flow parameter for the tunnel shall meet. The CID
in the service flow parameter should be the tunnel CID. If the tunnel is for the uplink direction, the
individual SS CIDs to be added into the tunnel shall be included in the CID added into tunnel TLV in
the DSC-REQ. Only the access RS processes the CID added into tunnel TLV and uses such information
to map the individual uplink SS CID into the tunnel. Other intermediate RSs ignore it and just simply
forward.
— If the service flow is not mapped to a tunnel, the MR-BS shall send a DSA-REQ using the requested
service flow parameter to all the RS on the path to obtain admission control decision. The MR-BS may
include the minimum SF parameter in the DSA-REQ in addition to the requested SF parameter. The
minimum SF parameter represents the minimum requirement that the service flow shall meet. The CID
in the service flow parameter should be the CID of the individual service flow.
— The MR-BS may include Per-RS QoS TLV in DSA-REQ to RS. If RS receives Per-RS QoS TLV, RS
4
IEEE C802.16j-08/085
shall use values in Per-RS QoS TLV instead of the ones in the service flow parameters.
The DSA/DSC-REQ is first sent from MR-BS to its subordinate RS using its primary management CID.
— Upon receiving the DSA/DSC-REQ, if the RS’ resource condition can support the requested SF
parameter, the RS simply forwards the message to its subordinate RS using the primary management
CID of the subordinate RS.; otherwise, the RS processes the request in the following ways:
— The RS may update the SF parameter with the one it can support. It then sends the DSA/DSC-REQ to
its subordinate neighboring RS using the primary management CID of the subordinate RS. This
procedure is repeated by each RS, until the DSA/DSC-REQ reaches the access RS. After processing the
DSA/DSC-REQ, the access RS replies with a DSA/DSC-RSP using its own primary management CID
directly to the MR-BS.
— If the RS cannot support the requested SF parameter but can support the minimum SF parameter in the
DSA/DSC-REQ, the RS updates the requested SF parameter with the one it can support and forwards
the message to its subordinate RS using the primary management CID of the subordinate RS.
— Otherwise, the RS includes or updates the acceptable SF parameters with the one RS can support and
sends the DSA/DSC-REQ to its subordinate RS using the primary management CID of the subordinate
RS.
— This procedure is repeated until the DSA/DSC-REQ reaches the access RS. After processing the
DSA/DSC-REQ, if the acceptable SF parameters are included in the message, the access RS transmits
DSA/DSC-RSP to the MR-BS with the confirmation code set to reject-RS-not-supported-parametervalue and the acceptable SF parameters.
— The RS may directly send a DSA/DSC-RSP back to MR-BS indicating that it cannot support the
requested SF without forwarding the DSA/DSC-REQ further to its subordinate RS.
[Change line 8 in page 128 through line 49 in page 128 of subclause 6.3.14.9.4.1 as follows:]
In an MR network with RSs operating in distributed scheduling mode, before admitting the changes of the
service flow and sending DSC-RSP to the requesting SS, the MR-BS sends DSC-REQ to all the RSs on the path
to requests for admission control decisions from the intermediate RSs in the following way:
— If the service flow is mapped maps to an existing tunnel and the service flow parameters for the tunnel
are changed, the MR-BS shall send a DSC-REQ to all the RS on the path to obtain admission control
decision. The MR-BS may include the minimum SF parameter in the DSC-REQ. The minimum SF
parameter represents the minimum requirement that the service flow parameter for the tunnel shall meet.
The CID in the service flow parameter should be the tunnel CID. If the tunnel is for the uplink direction,
the individual SS CIDs to be added into or removed from the tunnel shall be included in the CID added
into tunnel TLV or CID removed from tunnel TLV in the DSC-REQ. Only the access RS processes the
CID added into tunnel TLV and CID removed from tunnel TLV and uses such information to map or
remove the individual uplink SS CID into or from the tunnel. Other intermediate RSs ignore it and just
simply forward.
— If the service flow is not mapped to a tunnel, the MR-BS shall send a DSC-REQ using the requested
service flow parameter to all the RS on the path to obtain admission control decision. The MR-BS may
include the minimum SF parameter in the DSC-REQ in addition to the requested SF parameter. The
minimum SF parameter represents the minimum requirement that the service flow shall meet. The CID
in the service flow parameter should be the CID of the individual service flow. The CID for the service
flow is included.
— The MR-BS may include Per-RS QoS TLV in DSC-REQ to RS. If RS receives Per-RS QoS TLV, RS
5
IEEE C802.16j-08/085
shall use values in Per-RS QoS TLV instead of the ones in the service flow parametersfor the service
flow.
Such DSC-REQ is first sent from MR-BS to its subordinate RS using its primary management CID.
— Upon receiving the DSC-REQ, if the RS’ resource condition can support the requested modified SF
parameter, the RS simplyforwards the message to its subordinate RS using the primary management
CID of the subordinate RS; otherwise, the RS processes the request in the following ways.
— The RS may update the SF parameter with the one it can support. It then forwards the DSC-REQ to its
subordinated neighboring RS. This procedure is repeated by each RS, until the DSC-REQ reaches the
access RS. After processing the DSC-REQ, the access RS replies with a DSC-RSP using its own
primary management CID directly to the MR-BS.
— If the RS cannot support the requested SF parameter but can support the minimum SF parameter in the
DSC-REQ, the RS updates the requested SF parameter with the one it can support and forwards the
message to its subordinate RS using the primary management CID of the subordinate RS.
— Otherwise, the RS includes or updates the acceptable SF parameters with the one it can support and
sends the DSC-REQ to its subordinate RS using the primary management CID of the subordinate RS.
— This procedure is repeated until the DSC-REQ reaches the access RS. After processing the DSC-REQ, if
the acceptable SF parameters are included in the message, the access RS transmits DSC-RSP to the MRBS with the confirmation code set to reject-RS-not-supported-parameter-value and the acceptable SF
parameters.
— The RS may directly send a DSC-RSP back to MR-BS indicating that it cannot support the requested
modified SF, without further forwarding it to the next hop.
In order to ensure that the DSC-REQ messages from MR-BS to the RSs follow the same path as the packet
associated with the tunnel or individual SS transport connection, the same procedure as defined for SS initiated
DSA in section 6.3.14.9.3.1 is applied.
If MR-BS receives DSC-RSP from the access RS within T50, it shall send DSC-RSP to the requesting station.
Meanwhile MR-BS may also send a DSC-ACK with the admitted service flow parameter to all the RSs on the
path.The processing procedures of DSC-ACK message to the RSs are the same as those for the DSC-REQ as
described above. The path used to route the DSC-ACK should be the same as the path used to route the
corresponding DSC-REQ.
[Modify the table in 11.13.4 (QoS parameter set type) as indicated.]
Bit 0: Provisioned Set
Bit 1: Admitted Set
Bit 2: Active Set
Bit 3: Acceptable Set
Bit 4: Minimum Set
Bits 35–7: Reserved
[Add the text in the paragraph after the table in 11.13.4 (QoS parameter set type) as indicated.]
The minimum QoS parameter sets are used for indicating the minimum requirement of the requested service
6
IEEE C802.16j-08/085
flow. The acceptable QoS parameter sets are used for indicating QoS parameters RS can support. If RS cannot
support both the requested service flow parameters and the minimum service flow parameters, the acceptable
QoS parameter sets are included in DSA/DSC message.
[Add a new row at the end of the table 574 (Rev2) in 11.13 (Service flow management encodings) as indicated.]
CC
(skip)
18
Table 574 – CC values
Status
(skip)
reject-RS-not-supported-parameter-value
Reference:
[1] IEEE P802.16j/D3 February 2008
7