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

RE: stds-80220-requirements: 4.5.6 call blocking





Current Section
4.5.6          Call Blocking (Open)
Editor’s note: This section is proposed for deletion because it is viewed as already being included in section 4.4.1. 
[When the bandwidth required for a call cannot be reserved, the system will provide signaling to support call blocking.]

Proposal:
Delete this requirement.


Rationale: 
We previously agreed  that "The sentence related to call blocking should be removed because
call blocking is an application layer specific issue. The Requirements
document should specify the classes of supported QoS, but
application-specific exception handling should not be included in the
document."
 
Furthermore, considering that call blocking in IP networks is related to QoS (see recent discussion on the reflector) as IP networks starve rather than bump lower priority traffic by higher priority traffic, there are multiple ways in which a call-blocking application can be implemented. 

One is as indicated by 4.4.1 “Service classes of service and QoS parameters of all services may be translated into a common set of parameters defined by 802.20. A QoS based IP network may employ the Resource Reservation Protocol (RSVP) to signal the allocation of resources along a routed IP path.”  This typically would be used in conjunction with SIP to allocate resources along a routed path.  If the resources are not available, the call can not be made.

Another one is also 4.4.1 which also gives the ability to configure and retrieve the configured QoS of the air interface through "802.20 shall also support configuration of the PHBs by a DS API that shall be based on a subset of the information model defined in RFC 3289".   That information model includes meters that a call blocking application can access to make a call blocking decision.

Branislav

-----Original Message-----
From: owner-stds-80220-requirements@majordomo.ieee.org [mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of Mcginniss, Dave S [GMG]
Sent: Thursday, October 30, 2003 3:48 PM
To: stds-80220-requirements@ieee.org
Subject: stds-80220-requirements: 4.5.6 call blocking


Current Section
4.5.6          Call Blocking (Open)
Editor’s note: This section is proposed for deletion because it is viewed as already being included in section 4.4.1. 
[When the bandwidth required for a call cannot be reserved, the system will provide signaling to support call blocking.]
[No sentence]

[When MAC/PHY resources cannot be allocated to support the QOS characteristics defined as “high priority bandwidth reserved” are not available the MAC/PHY API will provide messaging to the higher layer to support blocking. Example VOIP allowing the higher layer application to provide a busy signal blocking the call and providing feedback.  The QOS must allow the assignment of specific resources to the QOS class so that the MAC/PHY may make this determination.]
Proposed text
When bandwidth required for a call requiring “high priority bandwidth reserved” like (VOIP) is not available, the system shall provide signaling to the upper layers to support call blocking.
Rational
While blocking is a higher layer function it can not be accomplished with out real-time signaling form the MAC/PHY. It has been argued that this should be deleted because it is covered in section 4.4.1.  I do not believe it is covered in that section. The following text 

“Service classes of service and QoS parameters of all services may be translated into a common set of parameters defined by 802.20. A QoS based IP network may employ the Resource Reservation Protocol (RSVP) to signal the allocation of resources along a routed IP path.” 

This does not indicate that the system should pass resource availability information for reserved bandwidth but rather that it should provide information to reserve end to end bandwidth for a call already set up.  This function needs to be provided to layer 3+ and belongs in this section. 

My first 


David S. McGinniss
Sprint Broadband Wireless Group
Principal Engineer II 
(630) 926-3184
david.s.mcginniss@mail.sprint.com