WO2012081849A2 - Procédé destiné à la réception de données à diffusion multiple dans un système de communication sans fil et dispositif m2m conçu dans ce but - Google Patents
Procédé destiné à la réception de données à diffusion multiple dans un système de communication sans fil et dispositif m2m conçu dans ce but Download PDFInfo
- Publication number
- WO2012081849A2 WO2012081849A2 PCT/KR2011/009199 KR2011009199W WO2012081849A2 WO 2012081849 A2 WO2012081849 A2 WO 2012081849A2 KR 2011009199 W KR2011009199 W KR 2011009199W WO 2012081849 A2 WO2012081849 A2 WO 2012081849A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- message
- idle mode
- service flow
- base station
- multicast
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B7/00—Radio transmission systems, i.e. using radiation field
- H04B7/24—Radio transmission systems, i.e. using radiation field for communication between two or more posts
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/30—Resource management for broadcast services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
Definitions
- the present invention relates to wireless communication, and more particularly, to an M2M device for receiving multicast data and an M2M device for receiving multicast data.
- Machine-to-machine communication refers to communication between the electronic device and the electronic device as it is. Broadly, it means wired or wireless communication between electronic devices or communication between a device controlled by a person and a machine. Recently, however, it is generally referring to wireless communication between an electronic device and an electronic device, that is, device-to-device performed without human involvement.
- M2M communication In the early 1990s, when the concept of M2M communication was first introduced, it was recognized as a concept of remote control or telematics, and the market itself was very limited. However, in the past few years, M2M communication has been rapidly gaining worldwide attention. Grew. In particular, intelligent metering that measures flow management, remote monitoring of machinery and equipment, operating hours on construction machinery and automatic measurement of heat or electricity usage in point-of-sales and security-related applications. It showed great influence in the field of (Smart Meter). M2M communication in the future will be utilized for more various purposes in connection with existing mobile communication and wireless high-speed Internet, or low-power communication solutions such as Wi-Fi and Zigbee, and will no longer be limited to the business-to-business market. It will be the foundation to expand into the market.
- M2M communication technology can be used in numerous devices and equipment such as automobiles, trucks, trains, containers, vending machines, gas tanks, and the like.
- An object of the present invention is to provide a method for M2M device to receive multicast data in a wireless communication system.
- Another object of the present invention is to provide an M2M device for receiving multicast data in a wireless communication system.
- a method of receiving multicast data by a machine to machine (M2M) device in a wireless communication system includes at least one service flow allocated in association with a multicast service flow from a base station.
- the method may further include receiving a second message from the base station, the second message including a second indicator indicating that the multicast data is to be transmitted, wherein the method includes receiving control information for the multicast data from the base station.
- the first message may be any one of AAI-DSA-REQ, AAI-DSA-RSP, AAI-DREG-REQ, or AAI-DREG-RSP message type
- the second message is a paging message.
- the first indicator is an idle mode retaining indicator, a multicast service flow retaining indicator, or an idle mode retaining information element type, and the first message. May further include a field indicating information on the number of service flows maintained in the idle mode.
- the first message may further include a field indicating a service flow parameter maintained in the idle mode among at least one service flow parameter allocated in connection with the multicast service flow.
- the assigned at least one service flow parameter may be assigned via the first message.
- the first message further includes an M2M group identifier and a flow identifier corresponding to the M2M device, and receives control information for the multicast data based on the M2M group identifier, and based on the flow identifier. Data can be received.
- a machine to machine (M2M) device that receives multicast data in a wireless communication system according to the present invention includes at least one service flow parameter allocated in association with a multicast service flow from a base station.
- a receiver for receiving a first message comprising a first indicator indicating whether to maintain a message in an idle mode;
- a processor for controlling the at least one service flow parameter to be maintained even if the M2M device enters the idle mode when the indicator instructs to maintain the at least one service flow parameter in the idle mode.
- the receiver may further receive a second message including a second indicator indicating that the multicast data is transmitted from the base station.
- the receiver may receive control information for the multicast data from the base station, and receive the multicast data based on the control information.
- the first indicator may be of an idle mode retaining indicator, a multicast service flow retaining indicator, or an idle mode retaining information element type.
- the first message may further include a field indicating a service flow parameter maintained in the idle mode among at least one service flow parameter allocated in connection with the multicast service flow.
- the first message further includes an M2M group identifier and a flow identifier corresponding to the M2M device, wherein the processor receives control information for the multicast data based on the M2M group identifier, and the flow identifier Control to receive the multicast data based on.
- the present invention relates to a method for a base station to transmit multicast data for M2M devices and a method for receiving M2M data from multicast data, and various embodiments of the present invention transmit multicast traffic (data) to M2M devices.
- it provides a method for eliminating unnecessary signaling overhead between the M2M device and the base station, minimizing power consumption of the M2M devices, and preventing unnecessary resource waste.
- FIG. 1 is a diagram for schematically explaining a device configuration such as an M2M device and a base station according to an embodiment of the present invention.
- FIG. 2 is a diagram illustrating an example of a process for a UE to receive downlink traffic from a base station in an idle mode in an IEEE 802.16 system, which is an example of a wireless communication system.
- FIG 3 is a diagram illustrating an example of multicast data transmission between an M2M device and a base station according to an embodiment of the present invention.
- FIG. 4 illustrates an example of allocating a service flow parameter through an AAI-DSA-REQ message when a base station initiates a DSA.
- FIG. 5 is a diagram illustrating an example of allocating a service flow parameter through an AAI-DSA-REQ message when an M2M device initiates a DSA.
- FIG. 6 shows an example of a hierarchical M2M group structure.
- FIG. 7 shows an example of a method of allocating a group ID and a subgroup ID.
- FIG. 8 is a diagram illustrating an example of allocating a group ID, a user ID, and a subscriber ID to an M2M device.
- FIG. 9 is a diagram illustrating another example of allocating a group ID, a user ID, and a subscriber ID to an M2M device.
- a terminal collectively refers to a mobile or fixed user terminal device such as a user equipment (UE), a mobile station (MS), an advanced mobile station (AMS), and the like.
- the base station collectively refers to any node of the network side that communicates with the terminal such as a Node B, an eNode B, a Base Station, and an Access Point (AP).
- UE user equipment
- MS mobile station
- AMS advanced mobile station
- AP Access Point
- a user equipment may receive information from a base station through downlink, and the terminal may also transmit information through uplink.
- Information transmitted or received by the terminal includes data and various control information, and various physical channels exist according to the type and purpose of information transmitted or received by the terminal.
- M2M device refers to a terminal capable of supporting communication of the M2M device as described above.
- An access service network for an M2M service is defined as an M2M ASN (M2M Access Service Network), and a network entity communicating with M2M devices is called an M2M server.
- the M2M server executes an M2M application and provides an M2M specific service for one or more M2M devices.
- An M2M feature is a feature of an M2M application, and one or more features may be needed to provide the application.
- An M2M device group refers to a group of M2M devices that share one or more features in common.
- M2M devices M2M communication devices, machine type communication (MTC) devices, etc.
- MTC machine type communication
- the types of device applications under discussion include (1) security, (2) public safety, (3) tracking and tracing, (4) payment, and (5) healthcare.
- M2M devices Another characteristic of M2M devices is low mobility or no mobility. Significantly less or no mobility means that M2M devices are stationary for a long time.
- An M2M communication system is a specific M2M with a fixed location, such as secured access and surveillance, public safety, payment, remote maintenance and control, metering, and so on. Mobility-related operations for the application can be simplified or optimized.
- the number of M2M communication devices may increase dramatically compared to the number of general mobile communication devices. Therefore, if they all communicate with the base station individually, it can put a serious load on the air interface and the network.
- M2M communication is applied to a wireless communication system (for example, IEEE 802.16e / m).
- a wireless communication system for example, IEEE 802.16e / m.
- the present invention is not limited thereto, and the embodiment of the present invention may be applied to other systems such as 3GPP LTE system in the same manner.
- FIG. 1 is a diagram for schematically explaining a device configuration such as an M2M device and a base station according to an embodiment of the present invention.
- the M2M device 100 (or may be referred to as an M2M communication device, hereinafter referred to as an M2M device) and the base station 150 are RF units 110 and 160, processors 120 and 170, and optionally, respectively. Memory 130 and 180.
- each of the RF units 110 and 160 may include transmitters 111 and 161 and receivers 112 and 162.
- the transmitter 111 and the receiver 112 are configured to transmit and receive signals with the base station 150 and other M2M devices
- the processor 120 is the transmitter 111 and the receiver.
- the transmitter 111 and the receiver 112 may be configured to control a process of transmitting and receiving signals with other devices.
- the processor 120 may perform various types of processing on the signal to be transmitted and then transmit the signal to the transmitter 111, and may perform processing on the signal received by the receiver 112. If necessary, the processor 120 may store information included in the exchanged message in the memory 130. With such a structure, the M2M device 100 may perform the methods of the various embodiments described below. Although not shown in FIG. 1, the M2M device 100 may include various additional configurations according to the device application type. When the M2M device 100 is for intelligent metering, the M2M device 100 may include an additional configuration for power measurement, and the like. The power measurement operation may be performed by the processor 120 illustrated in FIG. 1. May be controlled, or may be controlled by a separately configured processor (not shown).
- FIG. 1 illustrates an example in which communication is performed between the M2M device 100 and the base station 150, the M2M communication method according to the present invention may occur between M2M devices, and each of the devices is shown in FIG. 1.
- the method according to various embodiments described below may be performed in the same form as each device configuration shown in FIG.
- Transmitter 161 and receiver 162 of base station 150 are configured to transmit and receive signals with other base stations, M2M servers, and M2M devices, and processor 170 is functional with transmitter 161 and receiver 162. Connected to, the transmitter 161 and the receiver 162 may be configured to control the process of transmitting and receiving signals with other devices. In addition, the processor 170 may perform various processing on the signal to be transmitted and then transmit the signal to the transmitter 161, and may perform the processing on the signal received by the receiver 162. If necessary, the processor 170 may store information included in the exchanged message in the memory 130. With this structure, the base station 150 may perform the methods of the various embodiments described above.
- Processors 120 and 170 of each of the M2M device 110 and the base station 150 instruct (eg, control, coordinate, manage, etc.) operation at the M2M device 110 and the base station 150, respectively.
- Each of the processors 120 and 170 may be connected to memories 130 and 180 that store program codes and data.
- the memories 130 and 180 are coupled to the processors 120 and 170 to store operating systems, applications, and general files.
- the processors 120 and 170 may also be referred to as a controller, a microcontroller, a microprocessor, a microcomputer, or the like.
- the processors 120 and 170 may be implemented by hardware or firmware, software, or a combination thereof.
- ASICs application specific integrated circuits
- DSPs digital signal processors
- DSPDs digital signal processing devices
- PLDs programmable logic devices
- FPGAs Field programmable gate arrays
- firmware or software when implementing embodiments of the present invention using firmware or software, the firmware or software may be configured to include a module, a procedure, or a function for performing the functions or operations of the present invention, and to perform the present invention.
- Firmware or software configured to be may be included in the processors 120 and 170 or may be stored in the memories 130 and 180 to be driven by the processors 120 and 170.
- the idle mode refers to a paging group, a paging cycle, and a paging offset that are approved by the base station through signaling between the terminal and the base station in order to save power of the terminal.
- Offset mode. That is, even if the terminal roams a radio link environment having a plurality of base stations over a wide area, it is a mechanism that can periodically receive a downlink broadcast message without registering with a specific base station.
- the Idle mode stops all normal operations as well as handovers (HOs) and tailors only downlink synchronization to receive paging messages, which are broadcast messages only over a period of time. It is set.
- the paging message is a message instructing the paging action (paging action) to the terminal.
- paging operations include ranging, network reentry, and the like.
- the idle mode may be initiated by the terminal or initiated by the base station. That is, the terminal may enter the idle mode by transmitting a deregistration request (DREG-REQ) message to the base station and receiving a deregistration response (DREG-RSP) message from the base station in response thereto. In addition, the base station may enter the idle mode by transmitting a non-registration deregistration response (DREG-RSP) message or a deregistration command (DREG-CMD) message to the terminal.
- DREG-REQ deregistration request
- DREG-RSP deregistration response
- DREG-RSP non-registration deregistration response
- DREG-CMD deregistration command
- the terminal When the terminal receives a paging message corresponding to itself during the Available Interval (AI) in the idle mode, the terminal switches to the connected mode through a network entry process and transmits and receives data. .
- AI Available Interval
- Idle State or Idle Mode operation generally supports downlink broadcast traffic transmission even when the UE moves in a radio link environment composed of multiple base stations, even if the UE does not register with a specific base station. It refers to the action that makes.
- the terminal may transition to the idle state to save power.
- the terminal transitioning to the idle mode receives a broadcast message (eg, paging message) broadcasted by the base station during an available interval (AI) and transitions to the normal mode or remains idle. You can judge.
- a broadcast message eg, paging message
- the idle state can benefit the terminal by eliminating active requests and general operational requirements associated with handover.
- the idle state may limit the terminal activity to be scanned in discrete cycles, thereby saving power and operational resources used by the terminal.
- the idle state provides a simple and appropriate way to inform the terminal of downlink traffic pending, and removes the network interface and network handover (HO) traffic from the inactive terminal.
- the base station can benefit.
- Paging refers to a function of identifying a location (eg, any base station or a switching center) of a corresponding terminal when an incoming call occurs in mobile communication.
- a plurality of base stations supporting the idle state or the idle mode may belong to a specific paging group to configure a paging area.
- the paging group represents a logical group.
- the purpose of a paging group is to provide an adjacent coverage area that can be paged in downlink if there is traffic targeting the terminal.
- the paging group is preferably configured to meet the condition that a particular terminal is large enough to exist for most of the time in the same paging group, and that the paging load should be small enough to maintain an appropriate level.
- the paging group may include one or more base stations, and one base station may be included in one or more paging groups.
- Paging groups are defined in the management system. Paging groups can use paging group-action backbone network messages.
- the paging controller may manage a list of idle terminals and manage initial paging of all base stations belonging to a paging group by using a paging-announce message, which is one of backbone network messages.
- the terminal transmits a deregistration request (DREG-REQ) message to the base station to request deregistration with the base station to enter the idle mode. Thereafter, the base station transmits a deregistration response (DREG-RSP) message to the terminal in response to the DREG-REQ message. At this time, the DREG-RSP message includes paging information.
- entry into the idle mode of the terminal may be initiated by a request of the base station. In this case, the base station transmits a DREG-RSP message to the terminal.
- the paging information may include a paging cycle, a paging offset, a paging group identifier (PGID), a paging listening interval (Paging Listening Interval) value, and the like.
- PID paging group identifier
- Paging Listening Interval paging listening interval
- the terminal receiving the DREG-RSP message from the base station enters the idle mode with reference to the paging information.
- the idle mode has a paging cycle, and one paging cycle may consist of an available interval and an unavailable interval.
- the usable interval is the same concept as the paging listening interval or the paging interval.
- the paging offset indicates a time point (eg, a frame or subframe) at which a paging segment starts within a paging period.
- the paging group identifier indicates the identifier of the paging group assigned to the terminal.
- the paging information may include paging message offset information.
- the paging message offset information indicates a time point at which the paging message is transmitted from the base station.
- the terminal may receive a paging message delivered to the user in an available period, that is, a paging listening interval using the paging information.
- the paging message may be transmitted through the base station or the paging controller. That is, the terminal monitors the radio channel according to a paging period in order to receive a paging message.
- the terminal in the idle mode receives a paging message in its paging listening interval and checks whether there is downlink (DL) data transmitted to the terminal. If there is downlink data (ie, a positive indication), the terminal performs a network reentry process including a ranging process. Thereafter, a process of establishing a connection for a related downlink service flow is performed through a dynamic service addition (DSA) process. After the connection for the service flow is established, the base station transmits downlink data for the service to the terminal.
- DSA dynamic service addition
- FIG. 2 is a diagram illustrating an example of a process for a UE to receive downlink traffic from a base station in an idle mode in an IEEE 802.16 system, which is an example of a wireless communication system.
- the base station may transmit a paging message (S210).
- the idle mode terminal receives a paging message in its paging listening interval and checks whether there is downlink data (DL data) delivered to it (S210). If there is downlink data (ie, a positive indication), the terminal may perform a network reentry procedure including a ranging process (S220). Thereafter, the terminal may perform a process of establishing a connection for a related downlink (DL) service flow through a dynamic service addition (DSA) process (S230). When the connection for the service flow is established, the base station may transmit downlink control information (DL A-MAP / DL MAP) and downlink data for the corresponding service to the terminal (S240).
- DL data downlink data
- S240 dynamic service addition
- the automatic application or firmware update process for M2M devices is an M2M service scenario. It can be a major application in.
- the M2M server may transmit updated information to M2M devices having a corresponding application.
- the base station In order to transmit such multicast data that needs to be transmitted to multiple terminals in common to M2M devices in idle mode, the base station according to the embodiment of FIG. 2 will page the corresponding M2M devices.
- the terminal receiving the paging starts the transmission of a random access code, performs a network reentry process, accesses the network, and receives DL traffic transmitted from the base station. These processes increase the use of unnecessary resources of the network and also increase the power consumption of the terminal.
- an idle mode M2M device can efficiently receive multicast data.
- FIG 3 is a diagram illustrating an example of multicast data transmission between an M2M device and a base station according to an embodiment of the present invention.
- the base station when the base station receives downlink multicast data from the network, the base station idles before transmitting downlink multicast data to the M2M devices in the cell.
- M2M devices in the first may be informed that the downlink multicast data (DL multicast data) through a paging (paging) message (S310).
- AAI-PAG-ADV message in IEEE 802.16m
- MOB_PAG-ADV message in IEEE 802.16e
- the idle mode M2M device When the idle mode M2M device receives a paging message, if the multicast indicator is checked after checking whether there is a multicast traffic indication, the group belonging to itself (or multicast data allocated to the terminal) Verify that the M2M group ID for) is included. If the M2M device has an M2M group ID corresponding to the M2M device, the M2M device maintains idle mode (ie, does not perform network reentry) and transmits DL multicast data. The receiving operation may be performed (S320).
- Table 1 below shows an example of the paging message (eg, AAI-PAG-ADV message) format.
- an MGID field indicating the M2M group ID.
- the M2M device receives multicast data after paging as well as a multicast group ID (MGID) for receiving paging messages.
- Multicast service flow parameters to be maintained also need to be maintained in idle mode.
- the operation of receiving multicast data without network reentry in idle mode may have an overhead in which the M2M device must maintain all multicast service flow parameters associated with the MGID as well as the MGID. For example, if the idle mode M2M device performs a network entry procedure for a specific multicast service, and wants to use a method of transmitting data, the M2M device has all the multicast service flow parameters except the MGID. You won't have to keep it.
- the present invention proposes a method in which M2M devices can determine whether to maintain service flow parameters for a specific multicast service in an idle mode.
- the base station may inform the M2M device through the DSA process an indicator (eg, idle mode retaining indicator) indicating whether parameters for service flows allocated through the DSA should be maintained in the idle mode.
- an indicator eg, idle mode retaining indicator
- Table 2 shows the AAI-DSA-REQ / RSP message format.
- the processor 120 of the M2M device may receive the specific value Ob1.
- the message controls the service flow parameters allocated in connection with the multicast service flow to be maintained in the idle mode.
- FIG. 4 illustrates an example of allocating a service flow parameter through an AAI-DSA-REQ message when a base station initiates a DSA.
- the M2M device may perform an initial network entry procedure with a base station (S410).
- the M2M device and the base station register a ranging message (eg, AAI-RNG-REQ / RSP), a basic negotiation request / response message (eg, AAI-SBC-REQ / RSP message), A message (eg, AAI-REG-REQ / RSP) related to the message may be exchanged between the M2M device and the base station (S410).
- a ranging message eg, AAI-RNG-REQ / RSP
- a basic negotiation request / response message eg, AAI-SBC-REQ / RSP message
- a message eg, AAI-REG-REQ / RSP
- the processor 120 of the M2M device controls to maintain the parameters for the corresponding service flow in the idle mode. If the M2M device receives a paging message to receive multicast traffic in idle mode, the M2M device may receive multicast data in idle mode. In response to the AAI-DSA-REQ message, the M2M device may transmit an AAI-DSA-RSP message to the base station (S440). Then, the base station may transmit a message confirming this to the network entity (for example, the M2M server) (S450), and then confirm the reception by sending an AAI-DSA-ACK message to the M2M device (S460).
- the network entity for example, the M2M server
- the M2M device and the base station use the deregistration request / response message (for example, an AAI-DREG-REQ / RSP message) to inform the user of the paging cycle and paging offset.
- the M2M device and the base station may enter idle mode (S470).
- FIG. 5 is a diagram illustrating an example of allocating a service flow parameter through an AAI-DSA-REQ message when an M2M device initiates a DSA.
- the M2M device may perform an initial network entry procedure with a base station (S510).
- the M2M device and the base station exchange AAI-RNG-REQ / RSP message, AAI-SBC-REQ / RSP message, and AAI-REG-REQ / RSP message between the M2M device and the base station. It may be (S510).
- M2M device may initiate the AAI-DSA-REQ message transmission (S520).
- the base station may request the network entity (eg, M2M server) to allocate the group ID of the corresponding M2M device (S530), and in response to the request, the network entity (eg, the M2M server) sends the corresponding M2M device.
- the M2M device may transmit an AAI-DSA-ACK message to the base station (S560), and the base station receiving the acknowledgment response sends a message confirming this to the network entity (for example, the M2M server). Can be transmitted (S570).
- the M2M device and the base station share information such as a paging cycle and paging offset through an AAI-DREG-REQ / RSP message to enter the idle mode ( S580).
- an idle mode maintenance indicator indicating whether to maintain an idle mode for a specific service flow is included in the AAI-DSA-REQ / RSP message format and transmitted.
- the idle mode maintenance indicator for a specific service flow parameter may be transmitted in addition to the AAI-DSA-REQ / RSP message format in the AAI-DREG-REQ / RSP message format, which is a deregistration request / response message.
- Table 3 shows an example of an AAI-DSA-REQ / RSP message format including an idle mode retaining indicator (eg, Idle mode retaining indicator) for a specific service flow parameter.
- an idle mode retaining indicator eg, Idle mode retaining indicator
- the base station determines all service flow parameters (M2M group ID (or multicast) assigned to the M2M device in relation to the multicast service flow when the M2M device enters idle mode (de-registration).
- M2M group ID or multicast
- An indicator indicating whether the group ID), the flow ID (FID), and the associated QoS parameter) is maintained in the idle mode may be transmitted to inform the M2M device whether to maintain it.
- Tables 4 and 5 below show examples of an AAI-DSA-REQ / RSP message format including idle mode maintaining indicators (eg, Multicast service flow retaining indicators) for multicast service flow parameters.
- idle mode maintaining indicators eg, Multicast service flow retaining indicators
- Table 4 Fields Size (bit) Value Condition Multicast service flow retaining indicator One Indicates whether all multicast service flow parameters (M2M group ID (or Multicast Group ID), FIDs, related QoS parameters) assigned to the M2M device (or AMS) are maintained in Idle mode. 0: Not maintained in Idle mode 1: Maintained in Idle mode.
- the processor 120 of the M2M device determines that the multicast service flow indicator has been assigned. If it is instructed not to maintain the cast service flow parameters (0b0), the processor 120 of the M2M device controls not to maintain the multicast service flow parameters in the idle mode.
- Table 5 Fields Size (bit) Value Condition Multicast service flow retaining indicator One For one or more service flows of all multicast service flows assigned to the M2M device (or AMS), indicate that the relevant parameters (Multicast Group ID, FID, related QoS parameters) are maintained in Idle mode.
- 0 Service maintained in Idle mode
- the AAI-DSA-REQ / RSP message format instructs to maintain the multicast service flow parameters in idle mode (Ob1)
- the AAI-DSA-REQ / RSP message format may further include a "Num_of_service flows" field indicating the number of service flows maintained in the idle mode.
- the processor 120 of the M2M device may determine the number of service flows maintained in the idle mode through the "Num_of_service flows" field.
- AAI-DREG-REQ / RSP message between the M2M device and the base station (e.g., M2M Group ID and flow ID (FID)).
- FID flow ID
- QoS parameters related to the FID are also maintained.
- the above multicast ID information may be indicated to the M2M device in the form of a bitmap based on the number of multicast connections that the M2M device has. Table 6 below shows an example of the AAI-DREG-REQ / RSP message format.
- Table 6 Fields Size (bit) Value Condition Multicast service flow retaining indicator One Indicates that related parameters (Multicast Group ID, FID, related QoS parameters) are maintained in Idle mode for one or more service flows among all multicast service flows assigned to the M2M device (or terminal).
- the related parameters indicate that the idle mode is maintained. If so, a service flow mapping bitmap field including bitmap information for indicating maintained multicast service flows may be included.
- an M2M device may have a total of four multicast service flows (1: MGID (1) -FID (1), 2: MGID (2) -FID (1), 3: MGID (3) -FID (1)).
- the first bit of the service flows mapping bitmap is MGID (1) -FID (1)
- the second bit is the MGID ( 2) -FID (1)
- the third bit may indicate MGID (3) -FID (1)
- the fourth bit may indicate MGID (4) -FID (1). Only parameters for multicast service flows set to 1 will be retained.
- the AAI-DREG-REQ / RSP message format in IEEE 802.16m may be modified and defined as shown in Table 7 below.
- Bit 1 Retain MS service and operational information associated with AAI-PKMREQ / RSP messages.
- Bit 2 Retain MS service and operational information associated with AAI-REGREQ / RSP messages.
- Bit 3 Retain MS service and operational information associated with network address.
- Bit 4 Retain MS state information. The information retained by setting bit 4 includes configuration of all Service Flows in the AMS as set by successful AAI-DSA and AAI-DSC transactions. In particular it includes FIDs and related description (QoS descriptors and CS classifier information)
- Bit 5 Retain MS state information only for multicast connections.
- the information retained by setting bit 5 includes configuration of all Service Flows only for multicast connections in the AMS as set by successful AAI-DSA and AAI-DSC transactions. In particular it includes M2M group IDs, multicast FIDs and related description (QoS descriptors and CS classifier information). If Bit 4 is set to 1, this bit will be ignored.
- the M2M device maintains information (eg, multicast group IDs, multicast FIDs, related QoS parameters) for all multicast connections assigned to it.
- Table 8 below shows another AAI-DREG-REQ / RSP message format example different from Table 7 above.
- Bit 1 Retain MS service and operational information associated with AAI-PKMREQ / RSP messages.
- Bit 2 Retain MS service and operational information associated with AAI-REGREQ / RSP messages.
- Bit 3 Retain MS service and operational information associated with network address.
- Bit 4 Retain MS state information. The information retained by setting bit 4 includes configuration of all Service Flows in the AMS as set by successful AAI-DSA and AAI-DSC transactions. In particular it includes FIDs and related description (QoS descriptors and CS classifier information)
- Bit 5 Retain MS state information only for multicast connections.
- the AAI-DREG-REQ / RSP message format may further include a "Num_of_service flows" field indicating the number of service flows maintained in idle mode. have.
- the processor 120 of the M2M device may determine the number of multicast service flow parameters maintained in the idle mode through the "Num_of_service flows" field.
- the AAI-DREG-REQ / RSP message format may include ID information (multicast group ID, multicast FID) for one or more multicast connections. In order to reduce the overhead of ID information, it may be represented in a bitmap form.
- Table 9 below shows another AAI-DREG-REQ / RSP message format example different from Table 7.
- Table 9 Fields Size (Bit) Value Condition Idle Mode Retain Information element 6 Provided as part of this message indicative only. Network reentry from idle mode process requirements may change at time of actual reentry. For each bit location, a value of 0 indicates the information for the associated reentry control messages shall not be retained and managed; a value of 1 indicates the information for the associated reentry control message shall be retained and managed. Bit 0: Retain MS service and operational information associated with AAI-SBCREQ / RSP messages.
- Bit 1 Retain MS service and operational information associated with AAI-PKMREQ / RSP messages.
- Bit 2 Retain MS service and operational information associated with AAI-REGREQ / RSP messages.
- Bit 3 Retain MS service and operational information associated with network address.
- Bit 4 Retain MS state information. The information retained by setting bit 4 includes configuration of all Service Flows in the AMS as set by successful AAI-DSA and AAI-DSC transactions. In particular it includes FIDs and related description (QoS descriptors and CS classifier information)
- Bit 5 Retain MS state information only for multicast connections.
- the service flow mapping bitmap field “Service flows mapping bitmap” may be further included in the AAI-DREG-REQ / RSP message format.
- Service flows mapping bitmap is an example of a name and may be called in another form.
- the service flow mapping field indicates which of the multicast connections of the M2M device (or terminal) is maintained in the idle mode.
- the service flow mapping field size is determined based on the number of multicast connections. For example, if the number of connections is three, the size of the bitmap is three, with each bit representing respective multicast connections.
- the M2M device For multicast connections with the bit set, the M2M device maintains the associated ID (eg, M2M group ID or multicast group ID, FID) and QoS parameters in idle mode.
- M2M devices having the same attributes (or characteristics and characteristics) are grouped to manage M2M devices (or terminals) belonging to the same group.
- the criteria for grouping terminals may be various as follows.
- Application type-based grouping Grouping by type of applications such as electronics metering, gas metering, healthcare, etc., grouping the gas metering application type devices.
- M2M subscriber based grouping For example, it may be grouped for each M2M subscribers such as KEPCO, Samchully Gas, Seoul Gas, etc.
- Location-based grouping M2M devices can group based on location.
- the M2M system forms a group and assigns a group ID to each group.
- One group may have a subgroup according to a situation, and the base station may assign an ID for the group and the subgroup to the M2M device.
- FIG. 6 shows an example of a hierarchical M2M group structure.
- An example of subgrouping is as follows. When the application type of gas measurement as described above is made into one group, Samchully gas and Seoul gas may be sub-groups. If Samchully gas, which is an M2M subscriber, is used as a group, when there are many M2M devices in a group, it may be divided into several subgroups with n M2M devices in one subgroup.
- the ID assigned to the M2M group is assigned a group or network common ID of a specific cell, not a cell specific ID. That is, the group ID is maintained even if the cell is changed.
- the sub-group ID is grouped by the number of M2M devices in the cell, it may change from cell to cell, and if the cell changes, the ID of the subgroup needs to be updated. This can be summarized as follows:
- Group ID A network common ID, which is the same in a network or a specific cell group.
- Subgroup ID The cell specific ID, that is, even if the group ID is the same for each cell, the subgroup ID mapped to the group ID may be different. If the cell changes due to mobility, the subgroup ID may change. In this case, the subgroup ID needs to be updated.
- FIG. 7 shows an example of a method of allocating a group ID and a subgroup ID.
- A may be used as an ID for an existing terminal.
- a group ID set for M2M devices from A + 1 to A + n (B) is used as a group ID that is common to a network (or a common cell group).
- the subgroup ID set is from B + 1 to B + n (C) and may have a different range for each cell.
- the ID may be configured as shown in Table 10 below.
- IDs of subgroups of each group may not be consecutive.
- the subgroup IDs for group A + 1 are B + 1, B + 7, B + 15,... Can be
- the base station may allocate resources to the M2M device using the group ID and the subgroup ID.
- resources For example, an individual MAP IE (used when allocating resources to only a specific M2M device) or a group allocation MAP IE (resource resources to terminals belonging to a group or subgroup) to M2M devices in a connected mode.
- the subgroup ID When allocating resources individually by using a subframe ID, the subgroup ID may be used (for example, the subgroup ID may be masked to the CRC so that M2M devices may detect a MAP for a group to which they belong). To make it happen).
- a group ID may be used to transmit multicast traffic that must be transmitted to all M2M devices belonging to a specific M2M subscriber such as software / firmware update. This group ID may also be used (group ID masked with CRC) when decoding downlink control information (eg, A-MAP IE) for the paging message.
- A-MAP IE downlink control information
- the ID assigned by the network is a static ID.
- Subscriber ID (or Multicast Group ID): ID assigned by the network
- Group indication at group paging (masked in the CRC of the MAP for the paging message, or included as a group ID field (or bitmap) in the paging message)
- DSA procedure service creation process
- Bitmap or ID itself can be inserted into the MAP
- FIG. 8 is a diagram illustrating an example of allocating a group ID, a user ID, and a subscriber ID to an M2M device.
- the M2M device may perform an initial network entry procedure with a base station (S810).
- the M2M device sends an initial ranging code to the base station, receives a response message (AAI-RNG-ACK) and a CDMA-Allocation A-MAP IE for it from the base station, and then requests a ranging.
- the AAI-SBC-REQ / RSP message may be exchanged, authentication and key exchange processes may be performed, a registration request message may be transmitted to the base station, and a response message to the registration request may be received.
- the network entity eg, M2M server
- may transmit a message including group ID information (eg, group ID ⁇ A, B ⁇ ) corresponding to the corresponding M2M device to the base station (S820).
- the base station may transmit a pre-provisioned DSA-REQ message to the M2M device (S830).
- the M2M device may transmit a pre-provisioned DSA-RSP message to the base station (S840), and the base station may transmit a message confirming this to a network entity (for example, the M2M server) (S850). Thereafter, the base station may transmit an AAI-DSA-ACK message in response to the M2M device (S860).
- a network entity for example, the M2M server
- the base station transmits a paging message to the corresponding M2M device (S870).
- FIG. 9 is a diagram illustrating another example of allocating a group ID, a user ID, and a subscriber ID to an M2M device.
- the M2M device may perform an initial network entry procedure with a base station (S910).
- the M2M device sends an initial ranging code to the base station, receives a response message (AAI-RNG-ACK) and a CDMA-Allocation A-MAP IE for it from the base station, and then requests a ranging.
- the AAI-SBC-REQ / RSP message may be exchanged, authentication and key exchange processes may be performed, a registration request message may be transmitted to the base station, and a response message to the registration request may be received.
- the network entity eg, M2M server
- may transmit a message including group ID information (eg, group ID ⁇ A, B ⁇ ) corresponding to the corresponding M2M device to the base station (S920).
- the base station may transmit a pre-provisioned DSA-REQ message to the M2M device (S930).
- the M2M device may transmit a pre-provisioned DSA-RSP message to the base station (S940), and the base station may transmit a message confirming this to a network entity (for example, an M2M server) (S950). Thereafter, the base station may transmit an AAI-DSA-ACK message to the corresponding M2M device in acknowledgment (S960).
- a network entity for example, an M2M server
- the base station transmits a paging message to the corresponding M2M device (S970).
- multicast group ID information for example, indicating that multicast traffic is sent.
- the base station may transmit control information for multicast data to the corresponding M2M device by
- the method of receiving multicast data from the base station by the M2M device is industrially available in various communication systems such as 3GPP LTE, LTE-A, IEEE 802.16.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
L'invention concerne un procédé destiné à la réception de données à diffusion multiple dans un système de communication sans fil, et un dispositif M2M conçu dans ce but. Selon la présente invention, ledit dispositif de communication entre machines (M2M) destiné à la réception de données à diffusion multiple comprend : un récepteur permettant la réception d'un premier message comprenant un premier indicateur qui indique si au moins un paramètre d'utilisation de service, dont l'affectation est réalisée à partir d'une station de base en fonction de l'utilisation d'un service de diffusion multiple, est maintenu en mode inactif ; et un processeur conçu pour la commande servant à maintenir au moins un paramètre d'utilisation de service même lorsque ledit dispositif M2M passe en mode inactif si l'indicateur indique qu'au moins un paramètre d'utilisation de service est maintenu en mode inactif.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020137018455A KR20130132917A (ko) | 2010-12-13 | 2011-11-30 | 무선통신 시스템에서 멀티캐스트 데이터를 수신하는 방법 및 이를 위한 m2m 기기 |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US42222110P | 2010-12-13 | 2010-12-13 | |
| US61/422,221 | 2010-12-13 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| WO2012081849A2 true WO2012081849A2 (fr) | 2012-06-21 |
| WO2012081849A3 WO2012081849A3 (fr) | 2012-08-23 |
Family
ID=46245187
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/KR2011/009199 Ceased WO2012081849A2 (fr) | 2010-12-13 | 2011-11-30 | Procédé destiné à la réception de données à diffusion multiple dans un système de communication sans fil et dispositif m2m conçu dans ce but |
Country Status (2)
| Country | Link |
|---|---|
| KR (1) | KR20130132917A (fr) |
| WO (1) | WO2012081849A2 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017010589A1 (fr) * | 2015-07-15 | 2017-01-19 | 엘지전자(주) | Procédé et appareil de transmission et de réception de données, par un terminal, dans un système de communication sans fil |
-
2011
- 2011-11-30 WO PCT/KR2011/009199 patent/WO2012081849A2/fr not_active Ceased
- 2011-11-30 KR KR1020137018455A patent/KR20130132917A/ko not_active Withdrawn
Non-Patent Citations (4)
| Title |
|---|
| 'DRAFT Amendment to IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems' IEEE P802.16M/D4 February 2010, * |
| JIA LIN ET AL.: 'Carrier for paging and Network re-entry in idle mode of Multi-carrier' IEEE 802.16 BROADBAND WIRELESS ACCESS WORKING GROUP, IEEE C802.16M-09/0115 05 January 2009, * |
| KANG, HYUN JEONG ET AL.: 'Suggested Table Format for Idle mode MAC control message (16.2.3)' IEEE 802.16 BROADBAND WIRELESS ACCESS WORKING GROUP, IEEE C802.16M-10/1073R1 14 August 2010, * |
| KERSTIN JOHNSSON ET AL.: 'Suggested Updates on Requirements for Low Power Consumption' IEEE 802.16 BROADBAND WIRELESS ACCESS WORKING GROUP, IEEE C802.16P-10/0009R3 10 November 2010, * |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017010589A1 (fr) * | 2015-07-15 | 2017-01-19 | 엘지전자(주) | Procédé et appareil de transmission et de réception de données, par un terminal, dans un système de communication sans fil |
| KR20180034482A (ko) * | 2015-07-15 | 2018-04-04 | 엘지전자 주식회사 | 무선 통신 시스템에서 단말의 데이터 송수신 방법 및 장치 |
| KR101999809B1 (ko) | 2015-07-15 | 2019-10-01 | 엘지전자 주식회사 | 무선 통신 시스템에서 단말의 데이터 송수신 방법 및 장치 |
| US10681637B2 (en) | 2015-07-15 | 2020-06-09 | Lg Electronics Inc. | Method and apparatus for transmitting and receiving data, by terminal, in wireless communication system |
Also Published As
| Publication number | Publication date |
|---|---|
| KR20130132917A (ko) | 2013-12-05 |
| WO2012081849A3 (fr) | 2012-08-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2012091441A2 (fr) | Procédé de transmission et de réception d'informations de mise à jour de paramètre de mode veille, et appareil correspondant | |
| WO2012138148A2 (fr) | Procédé permettant de transmettre et de recevoir des informations de mise à jour de paramètres, et appareil correspondant | |
| WO2012074257A2 (fr) | Dispositif de communication entre machines (m2m) et station de base et procédé d'envoi et de réception de trafic de diffusion groupée | |
| WO2012111952A2 (fr) | Procédé de transmission et de réception d'informations de mise à jour de paramètre dans un système de communication sans fil, et dispositif l'utilisant | |
| WO2012102547A2 (fr) | Procédé de transmission et de réception d'un rapport de coupure de courant et dispositif correspondant | |
| WO2012108647A2 (fr) | Procédé de réception de données de diffusion groupée dans un système de communication sans fil et dispositif m2m associé | |
| WO2011129575A2 (fr) | Appareil et procédé de réalisation d'une communication machine-machine (m2m) basée sur un groupe | |
| US20140302874A1 (en) | System and method for paging off-line state terminals | |
| KR101863929B1 (ko) | 무선통신 시스템에서 m2m(machine to machine) 기기가 멀티캐스트 데이터 관련 정보를 송신 및 수신하는 방법과 이를 위한 장치 | |
| WO2013022307A2 (fr) | Appareil permettant de transmettre/recevoir des données de multidiffusion dans un système de communication sans fil et procédé associé | |
| WO2012053857A2 (fr) | Procédé et appareil pour exécuter une entrée/rentrée sur le réseau dans un système de communication sans fil | |
| WO2011149200A2 (fr) | Dispositif m2m fonctionnant en mode veille et procédé de réalisation de communication entre un dispositif de station de base et le dispositif m2m | |
| KR100957355B1 (ko) | Ⅰp 기반의 무선 이동 통신 시스템에서 고속 페이징시스템 및 방법 | |
| WO2013035970A1 (fr) | Procédé pour déterminer la validité d'un identificateur de groupe de terminaux en communication de machine à machine | |
| WO2012121566A2 (fr) | Procédé et dispositif destinés à l'attribution de ressources de groupe à un dispositif m2m dans un système de communication sans fil | |
| WO2012177038A2 (fr) | Procédé et appareil pour la communication d'une coupure de courant anormale dans un système d'accès sans fil prenant en charge les environnements m2m | |
| WO2012153971A2 (fr) | Procédé et appareil d'envoi de données de multidiffusion à des dispositifs m2m dans un système d'accès sans fil | |
| WO2013032093A1 (fr) | Procédé pour transmettre un identifiant de zone de groupe de terminaux dans une communication de type de machine à machine | |
| WO2012011776A2 (fr) | Procédé et dispositif de transmission/réception d'un identifiant pour station mobile fixe en état de repos dans un système de communication sans fil | |
| KR20120090855A (ko) | 기계간 통신에서의 송신 방법 | |
| WO2013036068A1 (fr) | Procédé pour fournir un service m2m, et procédé et appareil pour une communication m2m | |
| WO2012121552A2 (fr) | Procédé de transmission/réception d'informations de commande pour un dispositif m2m, et dispositif associé | |
| WO2012141441A2 (fr) | Procédé et appareil permettant d'exécuter une mesure de distance au niveau d'un dispositif m2m dans un système de communication sans fil | |
| EP3949574A1 (fr) | Dispositifs de communication sans fil à module de radiomessagerie et à identités multiples | |
| WO2013035954A1 (fr) | Procédé de mise à jour d'identificateur de groupe de terminaux en communication de machine-à-machine |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 11849666 Country of ref document: EP Kind code of ref document: A2 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| ENP | Entry into the national phase |
Ref document number: 20137018455 Country of ref document: KR Kind code of ref document: A |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 11849666 Country of ref document: EP Kind code of ref document: A2 |