IEEE C802.16p-11/0337r2 Project Title

advertisement
IEEE C802.16p-11/0337r2
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
MGID Related Corrections
Date
Submitted
2011-11-10
Source(s)
Erik Colban
Huawei
Voice: +1-858-775-2494
E-mail: ecolban@huawei.com
erik.colban@drawmetry.com
anshun@samsung.com
Anshuman Nigam
*<http://standards.ieee.org/faqs/affiliationFAQ.html>
Re:
IEEE 802.16 Working Group Letter Ballot #33, as announced in document IEEE 802.1611/0027
Abstract
This contribution proposes some clarifications and correction related to the use of M2M Groups
and MGIDs
Purpose
Discuss and adopt
Notice
Copyright
Policy
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 is familiar with the IEEE-SA Copyright Policy
<http://standards.ieee.org/IPR/copyrightpolicy.html>.
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>.
MGID Corrections
Erik Colban
Huawei Technologies
Anshuman Nigam
Samsung
Abstract
This contribution addresses text in P802.16p/D1 related to M2M groups and MGIDs. It proposes some
additional specifications, clarifications and corrections related to this part of the draft.
1
IEEE C802.16p-11/0337r2
Introduction
The changes in this contribution reflect agreement from ad-hoc activities in M2M TG. The following was
agreed to by the ad-hoc:
i. Create new space for M2MCID from the CID space
1. Applies only to 16p upgraded BSs
ii. Use these M2MCID in Paging
iii. Have non overlapping Zone concept
1. Zone ID is 15 bits
iv. An M2M Device belongs to only one M2M Group Zone
v. Data via assignment MAP
vi. Update M2MCID on Zone change
Proposed Changes
Change 1
Change text on page 4 as follows:
6.3.1 Addressing and connections
Insert the following texts at the end of subclause 6.3.1
One or more BS in an area of the network may be grouped into an M2M zone and identified by an M2M
DEVICE GROUP ZONE ID. A BS may belong to at most one M2M group zone. A 15-bit M2M device group
ID (MGID) uniquely identifies an M2M device group in the domain of the net-work entity that assigns MGID
that one or more M2M devices belong to. The domain of the network entity is identified by M2M DEVICE
GROUP ZONE ID. The BS may broadcast the M2M DEVICE GROUP ZONE ID of the zone to which it
belongs may be broadcasted in the DCD message.
The M2M multicast connection ID (M2MCID) uniquely identifies a downlink multicast service flow shared by
a group of M2M devices within an M2M zone. Implicitly, it is also used to identify the group of M2M devices
that share the downlink multicast SF. An M2M device may share more than one downlink multicast SF each
identified by an M2MCID. All M2MCIDs that are assigned to an M2M device belong to the same M2M group
zone.
An The MGID M2MCID is assigned to a service flow of an M2M device by a network entity after initial
network entry
through during the DSA procedure and released during the DSD procedure or an explicit network exit (e.g.,
power down location update). The assigned MGID M2MCID shall be retained by an M2M device even in idle
mode unless the M2M device exits from the network or the network explicitly deletes the service flow
associated with the MGID M2MCID. The MGID M2MCID can be re-assigned during nNormal Operation mode
2
IEEE C802.16p-11/0337r2
and idle mode. During nNormal Operation mode, the MGID M2MCID may be changed, and deleted by DSC,
and DSD procedures respectively.
During the iIdle mMode, the MGID M2MCID may be changed by a location update procedure (i.e. BS-initiated
location update) or during network reentry through the RNG-RSP message. When the BS updates the MGID
through the BS-initiated location update, the BS can trigger the group location update as well as individual
location update. When the BS changes the MGID of all M2M devices within the multicast group, tThe BS can
trigger the group location update via a paging message. In Normal Operation, the BS can update the M2MCID
for a M2M device group using the MAC Group Management Control Message (MGMC).
When the M2M device performs the timer based location update, if the BS needs to
update the MGID M2MCID of M2M device, the BS may send a RNG-RSP message with a new MGID
M2MCID is sent by the BS in response to the RNG-REQ message.
A BS may use the MOB_PAG-ADV message to indicate the update of the MGID M2MCID and its new value
to all the M2M devices in a group. When an idle mode M2M device that belongs to the
M2M device group (indentified by its MGID M2MCID) receives a paging message directed to
containing its an MGID M2MCID TLV identifying one of its service flows and the an Action Code TLV with
value is set to 0b11, this M2M device shall update its the MGID M2MCID based on the value
indicated by MGID M2MCID Re-assignment TLV (see 11.17.5)
After receiving the updated MGID value, the M2M device shall send an acknowledgement (ACK) message to
the BS. This ACK message is carried in the RNG-REQ message.
If the BS does not receive the an acknowledgement message from any of the some of the M2M devices
belonging to that M2M device group which MGID has been updated, it assumes that those M2M devices missed
the MGID update information. Iit may repeat the procedure in the next paging cycle of those M2M devices or it
may send a RNG-RSP message containing the new MGID M2MCID to each of them. n the next paging cycle
BS may ask those M2M devices to perform location update and
may send them a unicast message with the new MGID value (RNG-RSP).
The BS may use the M2M Group MAC Control (MGMC) message with the MGID M2MCID to send the same
information to multiple M2M devices. The M2M device may respond to acknowledge this message with M2M
ACK MAC Control (MAMC) message.
Change 1.3
On page 5, line 10, change 111 | MGMC | M2M Group MAC Control Message| TBD Broadcast
Change 1.4
6.3.2.3.6 RNG-RSP (ranging response) message
Add the following text at the end of the subclause 6.3.2.3.6 as indicated
The following TLV parameter may be included in a RNG-RSP message to update MGID M2MCID in an M2M
device.
3
IEEE C802.16p-11/0337r2
MGID M2MCID Update
Bits 0-15: current MGID value
Bits 16-31: new MGID value
Change 1.5
Change MGID to M2MCID globally
Change 1.7
Add the following lines on page 9, line 54
The following TLV may be included when paging an M2M device:
M2M Paging Parameter (see 11.17.7)
The following TLV may be included when paging an M2M device:
Ranging backoff start (see 11.17.8)
Change 3
On page 14, line 29, make the following changes:
6.3.34 Support of multicast operation for machine to machine application
A BS may provide a multicast service for group of M2M devices that share a downlink multicast service flow.
The BS shall initiate the establishment of a service flow using the DSA procedures. During the establishment
of the SF, the SF is assigned an M2MCID, which uniquely identifies the SF. The M2M device shall retain these
identifiers in Idle Mode (see 6.3.1). The BS shall provide the mapping between the SF and the M2MCID during
the DSA signaling and may modify this mapping using the DSC procedures or by using M2MCID Update TLV
during network re-entry.
Add new subclause 6.3.34.1
6.3.34.1 M2M multicast operation in idle mode
A BS may provide a multicast service for M2M devices in idle mode with or without requiring network
reentry of the M2M devices. Before a BS sends DL multicast data, the BS may shall transmit the paging
message including the multicast traffic indication to the M2M devices during the paging listening intervals of
the M2M devices. If an M2M device receives the paging message indicating multicast traffic reception without
network reentry during its paging listening interval, the M2M device shall start receiving the DL multicast data
without the idle mode termination.
The Multicast transmission start time TLV may be included in the paging message in order to indicate when
4
IEEE C802.16p-11/0337r2
the DL multicast data is sent by the BS. The value of Multicast transmission start time TLV shall be less
than the start time of the next paging listening interval of the M2M devices receiving the MOB_PAG-ADV
message. The M2M device may power down until the frame indicated by the Multicast transmission start
time TLV in the MOB_PAG-ADV message.
When the multicast data transmission ends, the BS shall notify the end of multicast data transmission to the
group of M2M devices by sending the MOB_MTE-IND message. Upon receiving the
MOB_MTE-IND
message, the M2M devices may enter the paging unavailable interval as specified in 6.3.22.4.
In order to receive the M2M multicast data during idle mode M2M devices in idle mode shall use M2M
Multicast Traffic Reception timer if this timer is assigned during DSA procedure. If Multicast transmission
start time TLV is included in the MOB_PAG-ADV message indicating the multicast
traffic reception
(Action code = 0b10), M2M devices receiving the MOB_PAG-ADV message shall start the Multicast Traffic Reception timer at the frame indicated by the Multicast transmission start time TLV.
Otherwise, the
M2M device shall start the Multicast Traffic Reception timer when the M2M device
receives the
MOB_PAG-ADV. The M2M Multicast Traffic Reception timer shall be reset whenever the multicast data
are received. The M2M device shall stop the M2M Multicast Traffic Reception timer when the MOB_MTEIND message is received. If the M2M Multicast Traffic Reception timer expires, the M2M device shall enter
the paging unavailable interval as specified in 6.3.22.4.
Change 3.5
Insert the following change on pge 22, line 50:
Make the following changes to Table 658:
Transport, Secondary Management, Tunnel or Management Tunnel, Multicast
management CID
2m+1–– n0xFE9F
M2MCID
n+1 – 0xFE9F
5
For the secondary management
connection, the same value
is assigned to both the DL and UL
connection. Tunnel CID
is used for tunnel transport
connections. Management Tunnel CID is used for tunnel
management connections. Multicast management CID is used for
the downlink multicast
management services.
M2M multicast connection
identifiers
IEEE C802.16p-11/0337r2
Change 3.6
Add the following text to page page23, line 64:
Insert the following row at the end of Table 678:
M2M GROUP ZONE ID
ZZ
2
Bits 0-14: M2M group zone
identifier
Bit 15: Reserved
6
WirelessMAN
OFDMA
Download