| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Here is the only current comment on the Em
Svc PAR Sott G. Scott Henderson Standards Manager Research In Motion Building 6, +14692356388 (Mobile) +19723731773 (Office) +19724091268 (FAX) From: Phillip Barber
[mailto:pbarber@broadbandmobiletech.com] This is a special case. You are proposing having 802.21 do the
work on behalf of the entire 802 community on this special topic. Not only
that, you are proposing that 802.21 Member participants re-write the PHY and
MAC layers of how each and every one of these 802 technologies will do this.
That presupposes that Members of 802.21 are better suited to developing and
writing such L1&L2 methods than the Member participants in each of the
individual technologies involved. That is more than a bit of a stretch. Maybe
true for a few technologies. But that is going to be a really hard sell for
many. So you had better know how each and every
one of those technologies supports, or at least purports to support, emergency
services. Because you are going to have to convince them ALL that you can write
their standards to support E911 service better than they can, because that is
what your PAR says you are going to do. They don’t have to prove that they can
support E911. You have to prove that they can’t, or that the method that
they use is inherently incompatible with the common method that you are likely
to develop. And some of those other Member participants are likely to disagree. 802.16 is an example. There are some
features and functions that 802.16 has developed to support E911, lawful
intercept, CALEA, etc…, all of the issues that you identify. And
WiMAX has developed specific solutions based on those 802.16 features and
functions. You are going to have to demonstrate that 802.16 and WiMAX need to
delay implementation of their solutions to await the development of the 802.21
solution, and the subsequent WiMAX development of supporting methods. As for validating topicality and need, you
definitely should reference US and European rulemaking that compels 802 based
technologies’ compliance. Thanks, Phil From: Scott Henderson
[mailto:shenderson@rim.com] The first email address bounced.
Hope this one goes through. Scott G. Standards Manager Research In Motion Building 6, +14692356388 (Mobile) +19723731773 (Office) +19724091268 (FAX) From: Hi Phil, Sorry the wording alarms you. It was
drafted by committee so it may not come across as intended. That phrase
is meant to convey that 802 will be providing L1&2 and that some other SDOs
(e.g. IETF, 3GPP etc.) will provide the complimentary upper layer development. As for the technical direction, it is of
course too soon to state that, but in preliminary discussions it is gravitating
toward creating a new ether type for emergency calling (911) and some behaviors
in the various points of attachment to provide location and forward the call to
the nearest PSAP. A new ether type would not seem to be a lot of
development and the handling at an AP or ether switch did not seem very different
from some current maintenance and management functions. The devil being
in the details, I would very much like to hear your thoughts on this idea, and
especially, how it might need modification for 802.16’s wide area
applications. Some of the complexity requirements for
emergency calls include: caller id, caller locations, call back, call
continuity (e.g. during handover), call integrity (anti-spoofing) and un
authenticated (non-subscriber) incoming calls. I have seen nothing in all
of the 802 standards which can handle all of these requirements, much less do
so uniformly across all of the affected 802 standards which might have to
support emergency calls. If 802.16 has addressed all or even a majority
of these, I would welcome knowing where and trying to inherit/reuse your
work. Your comment about Skype is a good one in
that it demonstrates both a big part of the problem being addressed by the FCC
and EC, and the crunch that regulatory requirements puts on providers of 802
services (like Muni WiFi, hotel WiFi or Ethernet). Skype can’t
handle the calls because it can’t route to the correct PSAP, but if the
call is identified at the outset as an emergency (by the handset or terminal)
and given specific L2 handling, Skype would not even need to be involved.
If a VoIP provider did get the call, they could direct the originator to
restart the call with the correct unique ether type and the L2 infrastructure
would automatically pass it off to the nearest PSAP. The 802 technologies that
would need to support this change are those which would set up or transport the
emergency calls: 802.3, 802.11, 802.16, 802.21 (for handovers), 802.20 and
802.22. There may also be implications with 802.1, and we will be
discussing that with them hopefully at the next meeting. There may be
some work needed in 802.15, and we are looking into that. As far as
transport over data networks, the FCC VoIP order covers those, and some of the
forward looking requirements for NG911 can be found at NENA Functional and Interface Standards
The Economic Feasibility is (as are all
such statements) a set of assumptions. In this case, the projected,
hopefully fairly simple, solution of using a new ether type and handling
procedure was seen as having a relatively low impact on the existing deployed
base (i.e. software/firmware update), but would allow external development
(ECRIT and 3GPP) to be simplified and made more uniform. It would also
potentially greatly simplify development and reduce cost for the PSAPs (one solution
vs. many). WiMAX is a more open issue in my mind because we didn’t
have anyone in the SG who currently attends, but I understand that they are
working along similar lines to 3GPP. If you have any advice how to
proceed in that direction, I would appreciate the input. Trying to put
all of that into the PAR/5C without preselecting the solutions is difficult at
best. That is what the task group is for, so to expect it to be specified
now seems to be putting the cart before the horse. Would it help to add references to the
various regulatory orders in either the PAR of 5C, or else attach one of the
tutorials? I’ve reviewed a number of PAR and 5C documents from
various WGs and they don’t go into that level of detail, nor do they
provide extensive research or background documentation as far as I have seen,
but it is not a big deal to add those references. Your thoughts? Thanks, Scott G. Standards Manager Research In Motion Building 6, +14692356388 (Mobile) +19723731773 (Office) +19724091268 (FAX) From: Gupta, Vivek G
[mailto:vivek.g.gupta@intel.com] fyi From: Phillip Barber
[mailto:pbarber@huawei.com] In the PAR form for submittal: This sentence in 5.5 Need for Project: 'This standard will provide the underlying transport
layer (PHY and MAC) functionality….' makes me very uncomfortable. Is it 802.21’s intention to directly write modifications
to other 802 technologies at the PHY and MAC layer? Language in the 5C, under Technical Feasibility would tend to indicate
this is not the intent: ‘This project would reuse and harmonize existing
802 functionality and utilize extensions to existing and proven 802
functionality to provide full implementation of emergency services
capabilities.’ But then why have the language in the PAR to support directly writing
PHY and MAC amendment to other 802 standards? Under the 5C: In the Distinct Identity: ‘3. Existing 802 standards do not
uniquely recognize an emergency services request and therefore do not address
all of the required functionality. This standard by its title will
identify it as the consistent and unique 802 definition of capabilities to
support emergency services.’ The answer implies that 802.21 will create a method to ’uniquely
recognize an emergency services request’ common across all 802
technologies. Seriously? The proponents of this solution actually believe that
the diverse wireline and wireless PHY & MAC solutions in 802 have enough
commonality that a single, common method will prove to be the most efficient
PHY & MAC solution across all of these diverse interfaces? I find such
assertion more than a little suspect. Also, the paragraph makes the assertion ‘Existing 802 standards
do not uniquely recognize an emergency services request and therefore do not
address all of the required functionality.’ Since the sentence omits any
clarifying/restricting adjective modifying ‘Existing’, like ‘Some
existing 802 standards…’, there is an implied ‘All’ to
the sentence as in ‘All existing 802 standards…’. I
believe that this statement is false; not true for every technology in 802.
Please provide documentation that demonstrates that every 802 technology fails
to ’uniquely recognize an emergency services request’. If even one
802 technology meets the requirement, then the assertion is false. In the Economic Feasibility, the 5C includes language: ‘Support for emergency services is a mandated
requirement for any commercial implementation of technology which can
potentially transport emergency calls.’ Is this true for all 802 technologies, in all implementations, in all
jurisdictions? So the law has been made to change the requirements for data
networks? Skype VoIP calls must now route to 911 regardless of jurisdiction?
Skype says no: ‘Can I call an emergency number (e.g. 112, 211,
999, and 911)? No, you cannot use Skype to call any emergency
services.’ Please clarify and demonstrate the requirement. Why is it necessary to
solve this problem in all 802 technologies? Are there no 802 technologies that
you can foresee excluding? Why is it necessary and useful to solve this problem using a unified
method? In your statement in Economic Feasibility: ‘Providing a consistent 802 solution to these
requirements can simplify and potentially greatly improve support of emergency
services functions.’ You contend that a unified method is less complex, and may improve
support of emergency services functions. Please justify that assertion. Under
what assumptions is this assertion true? Are those assumptions reasonable given
the diversity of technologies in 802? If the unified method for solving this
problem actually requires individual, differing changes to the differing 802
technologies, exactly how is this less complex? In what way is it more
valuable, more important to have 802.21 conduct these changes to the other 802
technologies rather than having the native, individual 802 steward working
groups do this work themselves? Is there a cost in having 802.21 do this work
instead of the current 802 owners of these standards? The blanket statement as
it exists is unsupported. Thanks, Phillip Barber -----Original Message----- Dear EC Members 802.21 WG approved a PAR for new standard on Support for Emergency
Services. The PAR and 5C can be found at: http://mentor.ieee.org/802.21/file/09/21-09-0027-00-00es-emergency-services-par-and-5c.doc Best regards, -Vivek ---------- This email is sent from the 802 Executive Committee email reflector.
This list is maintained by Listserv. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. |