Download 21-07-0102-00-0000-comments-to-lb1c

IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN: 21-07-xxxx-00-0000
Title: LB #1b Comment Summary
Date Submitted: March, 2007
Presented at IEEE 802.21 session #19, Orlando
Authors or Source(s):
Inma Carrion
Abstract: comments to commentary comments LB-1c
21-05-xxxx-00-0000
IEEE 802.21 presentation release statements
This document has been prepared to assist the IEEE 802.21 Working Group. It is
offered as a basis for discussion and is not binding on the contributing
individual(s) or organization(s). The material in this document is subject to
change in form and content after further study. The contributor(s) 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.21.
The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of
the IEEE-SA Standards Board Operations Manual
<http://standards.ieee.org/guides/opman/sect6.html#6.3> and in
Understanding Patent Issues During IEEE Standards Development
http://standards.ieee.org/board/pat/guide.html>
21-05-xxxx-00-0000
Proposal and comments
Comment #4043: Counter-proposal to the text proposed in ‘suggested remedy’
Note that the term MN is not appropriate when you are defining home/visited networks, the key issue is the
subscription not the MN. Also, the correct term for ‘provisioning service provider’ actually is ‘serving
network’, this term is widely used in 3GPP and 3GPP2 and we would be more compliant with them if we
aligned our terminology. See below for proposed text.
Add these definitions to section 3:
home network: network managed by the operator with whom the subscriber has a business relationship
(subscription)
visited network: network managed by an operator other than the subscriber’s home operator and in which the
subscriber is receiving service
serving network: network that provides IP based data services to the user. The serving network may be a
home network or a visited network
•
Then change the text in section 5.4.2 from ‘The terms Visited and Home are used to indicate the provisioning
service provider or enterprise. Any of the illustrated networks could be both a visited or home network
depending on the relation of the operator to the provisioner of the MN.’ to ‘The serving network for the
subscriber at a given point of time may be the home network or a visited network.’
•
Please, change also this text in line 47 section 5.4.2: ‘The model assumes that the provisioning service
provider either operates multiple access technologies or allows its user to roam into other networks when a
service level agreement (SLA) in support of inter-working has been established.’ to ‘The model assumes that
the serving network either operates multiple access technologies or allows its user to roam into other
networks when a service level agreement (SLA) in support of inter-working has been established.’
21-05-xxxx-00-0000
Proposal and comments
Comment #4045: Addition to the text proposed in ‘suggested remedy’
Again the term provisioner is confusing. The idea is to have a general statement saying that the network
serving the subscriber (MN) may use it’s own MIH server or others’. The text currently in the spec is
confusing and restricts all the possible use-cases.
•
Please, consider the change below to make the concept clearer:
MIIS could also be available from another overlapping or nearby visited network, using that network's MIIS
point of service. The serving network may utilize R3 and R4 interfaces to access other MIH entities. As an
example, in figure 3 the home network may access it’s own MIH information server or core operator 1
(visited network) MIH information server.
21-05-xxxx-00-0000
Proposal and comments
Comment #4417: Reserved values
Related to this comment are the questions of:
1) should an information element in a message be considered incorrect if it contains a ‘reserved’ value? If
yes, should the recipient ignore the IE and consider the rest of the message (it would be wise for
backward/future compatibility) (This is not explained in the doc);
2) can a ‘reserved’ value be used in the future? (it would be good to clarify it since in the past there have been
problems with different understanding of the use of reserved values, and therefore different implementations
and lots of IOT problems).
Note that it is not the same to specify an IE with some bits ‘reserved’ than as ‘reserved for future use’, when
we only specify it as ‘reserved’ there we have the question on whether we can use those values in the future
or not.
Proposal:
Add explanation of handling of ‘reserved’ values or refer to other IEEE specification where this is explained.
A proposal could be: An IE shall be considered syntactically incorrect in a message when it contains a
‘reserved’ value. Reserved values can be used in future revisions of the protocol.
21-05-xxxx-00-0000