WO2013040752A1

WO2013040752A1 - Enhanced mac padding for data transmissions

Info

Publication number: WO2013040752A1
Application number: PCT/CN2011/079864
Authority: WO
Inventors: Jing HAN; Haiming Wang; Wei Bai
Original assignee: Renesas Mobile Corporation
Priority date: 2011-09-20
Filing date: 2011-09-20
Publication date: 2013-03-28

Abstract

A network node determines that there is second data to be sent to a second radio device (e.g., MTC device) and disposes it into a second padding bit portion of a downlink message which has in a first portion first data for a different first radio device (e.g., conventional UE). By example, the message comprises a MAC PDU and the first data comprises a SDU; the second padding bit portion comprises at least a data section comprising the second data and a subheader. The first and second devices can share a same C-RNTI, which the network broadcasts in system information. Multiple MTC data can be sent in the padding bit portion, by multiplexing N subheaders and multiplexing N data segments each corresponding to one of the N subheaders, where the N data segments are for N radio devices other than the first radio device. MTC devices read their data from the second padding bit portion while the conventional UE ignores it.

Description

ENHANCED MAC PADDING FOR DATA TRANSMISSIONS

TECHNICAL FIELD:

[0001] The exemplary and non-limiting embodiments of this invention relate generally to wireless communication systems, methods, devices and computer programs, and more specifically relate to small data transmissions such as might be sent to M2M devices by a cellular network.

BACKGROUND:

[0002] The following abbreviations that may be found in the specification and/or the drawing figures are defined as follows:

3 GPP third generation partnership project

CCCH common control channel

C-R TI cell radio network temporary identifier

DL downlink

DRX discontinuous reception

eNB evolved Node B (base station of a LTE/LTE-A network)

E-UTRAN evolved universal terrestrial radio access network (LTE)

LA local area

LTE long term evolution

LTE-A long term evolution-advanced

M2M machine-to-machine

MAC medium access control

MCS modulation and coding scheme

MME mobile management entity

MTC machine type communications

PDCCH physical downlink control channel

PDU protocol data unit

PPvB physical resource block

PUCCH physical uplink control channel

PUSCH physical uplink shared channel

RAN radio access network

RRC radio resource control SDU service data unit

TA tracking area

UE user equipment

UL uplink

[0003] MTC, also termed M2M communications, is the networking of intelligent, communications-enabled remote assets which allows the exchange of information automatically without human intervention M2M covers a broad range of technologies and applications which connect the physical world - whether machines or monitored physical conditions - to a back-end information technology IT infrastructure. MTC/M2M systems are already in place and new systems are being standardized which are anticipated to greatly expand how prevalent MTC will become, the future target being the Internet of Things (IoT).

[0004] Wireless communications technologies used to enable this connectivity include GSM, GPRS, CDMA, 3G, LTE/LTE-A, WiFi and WiMAX. M2M communications can be over a relatively short range or a distance of many miles. Since there is a wide variety for M2M communications in both the types of data reported and the radio access technologies used, the traffic models are quite diverse and no single networking model is efficient for them all. In the 3GPP, MTC is studied from Jan 2010 in 3 GPP RAN. In the 3 GPP, MTC has been studied in the 3 GPP RAN group since January 2010. Currently there is an ongoing study item for MTC concerning RAN improvements, focusing on avoiding RAN overload to protect normal legacy UEs and to improve RAN efficiency when a very large number of MTC devices are accessed at once.

[0005] 3 GPP TS 22.368 vlO.5.0 (2011-06), entitled SERVICE REQUIREMENTS FOR MACHINE-TYPE COMMUNICATIONS (MTC), defines small data transmission as a feature of MTC. Document R2-111812 by 3 GPP TSG SA and entitled REPLY LS ON MTC PLANNING AND PRIORITIZATION (3 GPP TSG RAN WG2 meeting #73bis; Shanghai, China; 11-15 April 2011) requests that small data transmission become a prioritized feature/requirement for development of MTC procedures. Research directed toward MTC small data transmissions consider the expectation that there will be potentially a very large number of MTC devices, each of which sends or receives only a relatively small amount of data on each separate and distinct communication with other MTC devices or the central server. Thus the conventional RANs designed for human users who exchange relatively large data volumes per session need to support high numbers of M2M devices each sending small volumes of data, while still supporting the traditional human-oriented UEs such as mobile phone handsets. The challenge is to enable communication of these small amounts of data as to signaling overhead, network resources and reallocation delays with minimal impact to the conventional cellular networks and its conventional large data-volume users.

[0006] Document R2-112865 by ZTE and entitled DISCUSSION ON FAST METHOD FOR DYNAMIC ACCESS CONTROL (3GPP TSG RAN WG2 meeting #74; Barcelona, Spain; 9-13 May 2011) sets forth that there are expected to be a very large number of MTC device (for example 30,000 or so) which must be able to access the network within 10 seconds. Such a large number of MTC devices would result in a very large conventional signaling overhead in the physical (PHY) layer after the MTC devices gain access, which in the LTE/LTE-A system mean much control signaling to allocate via the PDCCH the various resource allocations. Small data transmissions to and from MTC devices are expected to be typically very small as compared with the resource that used for that PHY control signaling (the PDCCH in LTE/LTE-A), and should be much less than the minimum resource which could be allocated to each user/MTC device (one P B in LTE/LTE-A). To minimize the impact on conventional (legacy) UEs when the wireless network supports large numbers of MTC devices this signaling overhead burden must be addressed, and is a target of MTC devices for small packet transmission that is mentioned in document R2-111812 referenced above.

[0007] Further background relevant to MTC in the LTE/LTE-A system may be seen at 3 GPP TS 36.321 vlO.2.0 (2011-06) entitled MEDIUM ACCESS CONTROL (MAC) PROTOCOL SPECIFICATION (RELEASE 10); and also at document RP- 100330 by Huwai entitled Revised SID: RAN Improvements for Machine-type communications (3 GPP TSG RAN meeting #47; Vienna, Austria; 16-19 March 2010). Related subject matter is also detailed at co-owned application PCT/CN2011/0077849, filed on August 1 , 2011 and entitled SMALL DOWNLINK DATA TRANSMISSIONS.

[0008] These teachings are directed toward adapting conventional cellular network protocols, which were originally developed for human-oriented communications, to more efficiently support downlink MTC communications of small amounts of data. While the examples are directed to MTC in the LTE/LTE-A systems, these teachings are adaptable to non-MTC as well as to other radio access technologies beyond only LTE and LTE-A.

SUMMARY:

[0009] The foregoing and other problems are overcome, and other advantages are realized, by the use of the exemplary embodiments of this invention.

[0010] In a first exemplary embodiment of the invention there is an apparatus comprising at least one processor and at least one memory storing a computer program. In this embodiment the at least one memory with the computer program is configured with the at least one processor to cause the apparatus to at least: determine that there is second data to be sent to a second radio device; and dispose the second data into a second padding bit portion of a downlink message which comprises in a first portion first data for a different first radio device.

[001 1] In a second exemplary embodiment of the invention there is a method comprising: determining that there is second data to be sent to a second radio device; and disposing the second data into a second padding bit portion of a downlink message which comprises in a first portion first data for a different first radio device.

[0012] In a third exemplary embodiment of the invention there is a computer readable memory storing a computer program comprising: code for determining that there is second data to be sent to a second radio device; and code for disposing the second data into a second padding bit portion of a downlink message which comprises in a first portion first data for a different first radio device.

[0013] In a fourth exemplary embodiment of the invention there is an apparatus comprising at least one processor and at least one memory storing a computer program. In this embodiment the at least one memory with the computer program is configured with the at least one processor to cause the apparatus to at least: receive a downlink message which comprises in a first portion first data directed to a first radio device; and from a second padding bit portion of the received downlink message, read second data directed to a second radio device different from the first radio device. [0014] In a fifth exemplary embodiment of the invention there is a method comprising: receiving a downlink message which comprises in a first portion first data directed to a first radio device; and from a second padding bit portion of the received downlink message, reading second data directed to a second radio device different from the first radio device.

[0015] In a sixth exemplary embodiment of the invention there is a computer readable memory storing a computer program comprising: code for receiving a downlink message which comprises in a first portion first data directed to a first radio device; and code for reading, from a second padding bit portion of the received downlink message, second data directed to a second radio device different from the first radio device.

[0016] These and other embodiments and aspects are detailed below with particularity.

BRIEF DESCRIPTION OF THE DRAWINGS:

[0017] Figure 1 illustrates a downlink PDU addressed to a conventional UE in which small data for a different MTC device is inserted in what the conventional UE sees as padding bits, according to an exemplary embodiment of these teachings. [0018] Figure 2 is similar to Figure 1 but in which there is multiplexed small data for multiple different MTC devices inserted in what the conventional UE sees as padding bits, according to an exemplary embodiment of these teachings.

[0019] Figures 3-4 are logic flow diagrams that each illustrates from the respective perspective of the network and of the MTC device the operation of a method, and a result of execution of a set of computer program instructions embodied on a computer readable memory, in accordance with exemplary embodiments of this invention.

[0020] Figure 5 is a simplified block diagram of a radio device and two different network nodes which are exemplary electronic devices suitable for use in practicing the exemplary embodiments of this invention. DETAILED DESCRIPTION:

[0021] In the conventional LTE/LTE-A system, the eNB sends to a conventional UE a PDCCH which allocates to it one or more UL/DL resources. If UL, the UE tunes to that allocated resource and uses it to transmit its own data. If DL, the UE tunes to the allocated DL resource and receives data from the network. In LTE-LTE-A terminology, the allocated UL channel is a logical PUSCH and the allocated DL channel is a logical PDSCH. The eNB can allocate multiple UEs in a single PDCCH as follows. The various UEs in the eNB's cell are given a discontinuous reception (DRX) schedule; during the DRX period they are allowed to go into a power saving or sleep mode and otherwise they are expected to monitor for a PDCCH (or a page) addressed to them. Ideally the eNB staggers the DRXs of the various UEs in its cell to distribute in time when the eNB may schedule them.

[0022] When in an active mode the UEs tune to the PDCCH and decode the cyclic redundancy check C C field to see if their identifier is scrambled. If it is not they need not decode further and may either listen for the next PDCCH or go into sleep mode, according to their DRX schedule. A UE reading its identifier in the PDCCH will map from the location of that identifier to learn which PDSCH and/or PUSCH is allocated to it. The PDSCH and PUSCH also map to a physical hybrid automatic-repeat request channel (PHICH) on which the UE or eNB send their acknowledgement or negative acknowledgement of the respective DL or UL data they were expecting.

[0023] The examples below assume a conventional UE is allocated a PDSCH on the PDCCH. As noted in the background section, the minimum resource which can be allocated to a UE using the above conventional LTE/LTE-A practice is one PRB, and if the allocation is larger it must always be in terms of discrete PRBs. This discrete number of PRBs for a given allocation is also termed a transport block, and the reason it cannot extend some fraction of a PRB is to keep proper timing among all of the other allocated resources. Whether one or more PRBs, the transport block that the eNB sends DL with the data is termed a PDU, referring to how it is seen by a different protocol layer. The PDU includes a header and the data follows in what is termed the SDU (there may be one or more SDUs). If one considers the SDU as the substantive content, the PDU is the SDU with addressing and other non-data control elements. Since the combined header plus data do not in all cases exactly fill the transport block which aligns with one or more discrete PRBs, there are unused bit positions which are termed padding bits. These are not used for carrying any useful information, only for filling the transport block so as to align with the overall system timing. The eNB may fill the padding bits with a default value (for example, all zeros) but regardless the UE receiving the PDSCH ignores them since it knows from the control information in the header exactly how long is the SDU.

[0024] The number/volume of padding bits depends on how well the combined volume of the header and data fit into a discrete number of PRBs; if barely less there will be few padding bits and if slightly more there will be a larger number of padding bits to fill the next PRB into which the normal data overflowed. The eNB knows how much data it has DL for the UE at the time it schedules it on the PDCCH, and so in theory the eNB also know at that time just how much room there is for padding bits in the PDSCH it is currently allocating. Different size SDUs fit differently into different size transport blocks depending on the MCS, which the eNB may semi-statically configure for the UE. Typically this is done based on the data volume in the cell and the channel conditions for this UE rather than the number of padding bits, since meeting the guaranteed bit error rate is a more pressing priority for the eNB than minimizing the number of padding bits. [0025] Figure 1 illustrates one such transport block 100. The MAC header 111 or MAC control element (CE) carries the MAC SDU indicator and MAC control signaling, and the data intended for it is in the MAC SDU 112. Conveniently we term the combined header 111 and data 112 directed to the conventional UE as the first portion 110 of the transport block 100, which is followed by a second portion 120 that conventionally carries the padding bits. According to an exemplary embodiment of these teachings, that second portion 120 which the conventional UE continues to see as padding bits (and therefore ignore) are used to send DL small data to another device different from the one identified in the conventional PDU header 111. In the below examples this other device is a MTC device since the size of the padding bit portion 120 is well suited to small data transmissions, but this is a non-limiting implementation.

[0026] Figure 1 includes an expanded portion of the padding bit portion 120. There is a MAC subheader 121 which identifies the MTC device to which the data is directed, followed by the DL small data 125, and if necessary any remaining bit positions are filled with padding bits 129. To distinguish from the conventional header 111, these teachings coin the term MAC-MTC subheader 121 for that header disposed within the padding bit portion 120 of the transport block. [0027] The eNB uses this MAC-MTC subheader 121 to indicate the information about the MTC DL data 125. For example, the MAC-MTC subheader 121 may be of variable size and in an embodiment includes a length field L which indicates the size of the corresponding MTC DL data 125; a format field F (of size one bit) which indicates the size of the length field L; and an extension flag E (of size one bit) which indicates whether there are additional fields present in the MAC-MTC subheader 121. These fields L, F and E are in addition to the identifier of the MTC device to which the MTC data 125 is directed, since the system is designed to handle many MTC devices in any given cell. Specific identification of the MTC device in the subheader 121 is detailed further below. [0028] In an embodiment the length field L indicates the length of the MTC data only, from which the receiving MTC device can then know how many real padding bits 129 are present to reach the end of the transport block. The MTC device ignores the real padding bits 129 just as the conventional/legacy UE ignores the second portion 120 which it considers as being all padding bits.

[0029] As noted in the background section above, implementation of MTC in a conventional cellular system should have limited adverse impact on the conventional large data volume users/UEs. Placing MTC DL small data in the padding bits portion 120 of a transport block satisfies this goal in that the conventional/legacy UEs will regard the MTC subheader 121, the MTC DL data 125 itself, and any real padding 129 as MAC PDU padding and thereby ignore it. In this manner there is no adverse impact to conventional/legacy UEs; they simply decode the MAC PDU 100 as they have done in the prior art. Only the eNB and the identified MTC device(s) need to know there is DL data 125 for the MTC device in the padding bits portion 120. When the allocated transport block 100 size for the conventional/legacy UE is not used up by the MAC header 111 and the MAC SDU 112, the remaining bits as seen by the legacy UE are all padding bits which the eNB utilizes to the extent necessary for the small packet directed to an MTC device.

[0030] Above it was noted that at the time the eNB sends the PDCCH scheduling the PDSCH which carries the transport block 100, the eNB knows just how much room there is for padding 120 since it knows the size of the SDU 112 (and header 111). According to exemplary embodiments of these teachings, if the eNB determines that normal MAC PDU padding is not enough to accommodate the DL small data of the MTC devices which the eNB needs to send, the eNB can allocate more resource and/or a higher MCS, each of which will operate to create more padding (a larger size for the second portion 120 of the transport block 100) where the MTC data is to be disposed. [0031] Figure 2 illustrates an embodiment in which a single transport block 200 is used to carry data 212 to a conventional/legacy UE and also to carry multiple small data instances 225-227 to multiple MTC devices. Similar to Figure 1, the transport block 200 of Figure 2 has a first portion 210 with a header 211 and data 212 relevant for the conventional/legacy UE, and a second portion 220 which the conventional/legacy UE sees as padding bits but which are used for small DL MTC data. But in this case there are multiple data segments in the padding bit portion 220 each for a different MTC device.

[0032] Specifically, the padding bit portion 220 includes a multiplexed plurality of N MAC-MTC subheaders 221-223 each identifying a different MTC device, and each of the multiplexed N subsequent MTC data segments 225-227 correspond to one of the N MAC-MTC subheaders 221-223. This correspondence is in the Figure 2 embodiment implicit in that each n^th MAC-MTC subheader maps to a specific n^th one of the MTC data segments (n is an index through all of the N subheaders/data segments/MTC devices and N is an integer greater than one). In other embodiments there may be an explicit indication in the MAC-MTC subheader 221-223 of which MTC data segment 225-227 it maps. The multiplexed MAC-MTC subheaders 221-223 may each contain information about its corresponding MTC data segment 225-227 as detailed above for Figure 1. [0033] Additionally and as shown at Figure 2, there is a padding subheader 224 which simply separates the multiplexed MAC-MTC subheaders 221-223 from their corresponding MTC data segments 225-227, and following the data segments 225-227 there is if necessary real padding bits 229 to fill out the transport block. The Figure 2 embodiment is particularly useful where the eNB sees, when scheduling the conventional/legacy UE, that there is a reasonably large volume of headroom in the padding bits portion 120, 220 of the transport block 100, 200.

[0034] Now is detailed certain non-limiting embodiments of how the MTC devices might be addressed in the MAC-MTC subheaders 121, 221-223. In these embodiments the eNB assigns to the MTC devices a C-RNTI similar to the identifiers it assigns to the conventional/legacy UEs. To distinguish in this description over those conventional C-RNTIs, term the identifiers assigned by the eNB to the MTC devices as 'assistant C-RNTIs". Consider again Figure 1; in one embodiment the assistant C-RNTI for the MTC device to which the data 125 in the padding bit portion 120 is directed is also the same as the C-RNTI assigned to the conventional/legacy UE to which the MAC SDU data 112 is directed in the first portion 110 of the transport block 100. Both the MTC device and the conventional/legacy UE see that C-RNTI (scrambled) in the PDCCH which schedules that transport block 100. For the Figure 2 example the various MTC devices to which the various data segments 225-227 are directed may have different assistant C-RNTIs in which case the corresponding PDCCH will have them all scrambled. In one particular but non-limiting embodiment the MTC data 125 or the data segment fields 225-227 may also carry the assistant C-RNTI assigned to the specific MTC device to which the data in those fields 125, 225-227 is directed. . Since the system is designed for multiple MTC devices in any given cell, then each cell will have a set of these assistant C-RNTIs. The eNB can semi-statically configure this set depending on how many UEs and MTC devices are active in the cell at a given time, and depending on how many unique C-RNTIs are available to it.

[0035] In one particular embodiment the eNB will broadcast in system information all of the assistant C-RNTIs in its set and the MTC devices will, either by paging from the eNB or periodically of their own accord, read system information to assure they have the currently valid set. At any given time that set may include some subset of all the C-RNTIs in use in the cell, or all of the C-RNTIs. That is, the eNB may allocate some or all of its C-RNTIs to MTC devices and will indicate in system information which C-RNTIs are assistant C-RNTIs. The MTC devices are given a DRX cycle similar to the conventional UEs though possibly with a much longer DRX (inactive) period than is practical for conventional UEs, for at least some of the MTC devices for which a long DRX is practical.

[0036] For a given MTC device, during a predefined time slot which coincides with an active time of the DRX cycle, the given MTC device will attempt to decode the PDCCH using all of the assistant C-RNTIs indicated by the current system information broadcast. The different DRX cycles of the different MTC devices space out their active periods from one another, which the eNB tracks to know in advance which MTC device will be receiving which PDCCH. If the active MTC device reads an assistant C-RNTI in the PDCCH it will be able to decode it to see which PDSCH is allocated. This PDCCH will also address the conventional UE to which the first portion 110, 210 of the transport block 100, 200 will be addressed, but the MTC device will not be looking for any C-RNTI which is not an assistant C-RNTI. The MTC device will then tune to receive the PDSCH allocated by the PDCCH, and possibly read the conventional header 111, 211 to see exactly where the second portion 120, 220 of the transport block begins. As in the non-limiting embodiment noted above, if there are multiple data segments 225-227 for multiple MTC devices in the same transport block 200 then the MTC device will find its own assistant C-RNTI in the data segment 225-227 itself.

[0037] In a different embodiment, rather than update the system information whenever the set of assistant C-RNTIs changes, the eNB will simply allocate the C-RNTIs, including at least some of the assistant C-RNTIs, to a conventional UE. In this embodiment the MTC devices will be looking for an assistant C-RNTI that is also assigned conventionally to a legacy UE as was detailed above, and there will be a conventional/legacy UE and a MTC device assigned the same C-RNTI. The MTC device will know that its data will come only in the second padding bit portion 120, 220 of a transport block 100, 200 while the conventional/legacy UE will know its data will come only in the first portion 110, 210 portion (and that UE will ignore the second padding bit portion 120, 220) and so sharing a same C-RNTI between them will still get the correct data to the correct device.

[0038] For either of these distinct embodiments concerning the assistant C-RNTIs, it is advantageous that the eNB select a suitable legacy UE with which to piggyback MTC data for a given MTC device. For example, the eNB may decide that transmission efficiency is improved if it selects a legacy UE that is physically near to the MTC device for which the MTC data is intended, since in this case a similar MCS could be utilized in the same transport block 100, 200 to realize that transmission efficiency. The conventional/legacy UE would then have the same C-RNTI as an MTC device (and an overlapping active time of their respective DRX cycles) since the MTC device will get its data only in a same transport block which carries data for that related conventional/legacy UE. For the latter embodiment in which the eNB does not update the assistant C-RNTI set information, the eNB may then re-allocate one of the assistant C-RNTIs to a legacy UE near to the MTC device, and so the MTC devices do not need to re-acquire the corresponding system information which saves on power consumption and delay. This is particularly useful for those MTC devices which are stationary or fixed in location, though this itself is not a limit.

[0039] The above exemplary embodiments provide several technical effects and advantages. Specifically, as compared to treating the MTC devices as legacy UEs these embodiments significantly decrease the physical layer control signaling overhead for small data transmission, and additionally decrease the physical layer resource usage for MTC data transmission. Certain embodiments may impose a longer blind decoding detection on the part of the MTC devices, but the eNB can easily mitigate this by setting a suitably long DRX cycle for the MTC devices. [0040] Figures 3-4 detailed below are logic flow diagrams illustrating exemplary but non-limiting embodiments of the invention from the perspective of the network/eNB and of the recipient MTC device, respectively. The functional blocks shown at Figures 3-4 may represent method steps, actions taken by a network node or the radio device in response to stored software arranged according to these embodiments, or the actual network node or radio device themselves which are configured according to these teachings. In these figures more general terms are utilized than the specific examples above; the first radio device of Figures 3-4 is in the position of the conventional/legacy UE of the above examples and its data is first data; the second radio device is in the position of the MTC device and its data is second data; and the network access node is in the position of the eNB.

[0041] Consider first Figure 3 which describes from the perspective of the cellular network/network access node. According to these exemplary embodiments of the teachings herein, at block 302 the network access node (or one or more components thereof) determines that there is second data to be sent to a second radio device. The network access node at block 304 then disposes the second data into a (second) padding bit portion of a downlink message, where that downlink message comprises in a first portion first data for a first radio device different from the second radio device.

[0042] Further details at Figure 3 summarize various of the non-limiting embodiments detailed above with particularity. Specifically, block 306 specifies the LTE/LTE-A embodiments in the above examples: the downlink message comprises a medium access control MAC protocol data unit PDU, and the first data comprises a service data unit SDU.

[0043] Block 308 details that the second padding bit portion of the downlink message comprises at least a data section comprising the second data; and a subheader having at least a length field in which is indicated a size of the data section, and a format field in which is indicated a size of the length field. Block 310 further details block 308 in that the first and the second radio devices share (are assigned) a same cell radio network temporary identifier which is broadcast in system information.

[0044] Block 312 details the multiplexing explained above with reference to Figure 2. The second data comprises a plurality of N data segments to be sent to N radio devices other than the first radio device, and disposing the N data segments into the second padding bit portion of the downlink message comprises multiplexing N subheaders and multiplexing the N data segments each corresponding to one of the N subheaders. In this formulation, N is an integer greater than one.

[0045] And finally block 314 details the scheduling portion preceding the actual compiling and sending of the DL message, specific also for the LTE/LTE-A examples above. There, a downlink resource is scheduled by sending a PDCCH that allocates to the first radio device and to the second radio device a PDSCH; and then the network access node sends on the allocated PDSCH the downlink message which has the second data disposed into the second padding bit portion. In this case the first radio device comprises a UE and the second data is a machine to machine M2M transmission, which my implication means the second device is an MTC device. [0046] Now consider Figure 4 which describes from the perspective of the second radio device which receives the paging message. According to these exemplary embodiments of the teachings herein, at block 402 the radio device (or one or more components thereof) receives a downlink message which comprises in a first portion first data directed to a first radio device. At block 404, there is read from a second padding bit portion of the received downlink message second data directed to a second radio device different from the first radio device.

[0047] Further details at Figure 4 summarize various of the non-limiting embodiments detailed above with particularity. Specifically, block 406 details that the second padding bit portion of the downlink message comprises at least: a data section comprising the second data; and a subheader having at least a length field in which is indicated a size of the data section, and a format field in which is indicated a size of the length field. [0048] Block 408 details the multiplexing from the example at Figure 2 above. In this case the second padding bit portion comprises: N multiplexed subheaders; and N multiplexed data segments each corresponding to one of the N subheaders. Also in this case N is an integer greater than one, and each n^th data segment comprises data directed to an n^th one of N radio devices other than the first radio device.

[0049] And finally block 410 details how the second/MTC radio device finds that DL message it received at block 402. Specifically for the LTE/LTE-A systems, the second device learns from a physical downlink control channel PDCCH that a physical downlink shared channel PDSCH is allocated to a cell radio network temporary identifier that is shared by the first radio device and by the second radio device; and tunes to receive the DL message on the allocated PDSCH. In this case the second data is a machine to machine M2M transmission.

[0050] Reference is now made to Figure 5 for illustrating a simplified block diagram of various electronic devices and apparatus that are suitable for use in practicing the exemplary embodiments of this invention. Since the embodiments of the invention detailed above by example are transparent to the conventional/legacy UE, it is not shown specifically at Figure 5 though it is understood that the transport block having the padding bit portion is addressed in its first portion to such a conventional/legacy UE.

[0051] In Figure 5 a wireless radio access network is adapted for communication over a wireless link 21 with an apparatus, such as a MTC device 20 (termed above more generally as a radio device and which may be implemented as a mobile terminal/UE or otherwise) via a network access node, such as a base or relay station or more specifically an eNB 22. The radio access network may include a network control element embodied as a mobility management entity/serving gateway MME/SGW 23, which provides connectivity with further networks (e.g., a publicly switched telephone network PSTN and/or a data communications network/Internet) as well as other network elements. Shown at Figure 5 also is a core network CN server 24 which is connected to the eNB 22 via the MME/S-GS 23. The MTC device 20 may be any host device of a MTC-specific SIM card, or an ordinary SIM card, or even a radio device lacking a SIM card. [0052] The MTC radio device 20 includes processing means such as at least one data processor (DP) 20A, storing means such as at least one computer-readable memory (MEM) 20B storing at least one computer program (PROG) 20C executable by the MTC device 20 which cause the device 20 to perform actions as detailed above, communicating means such as a transmitter TX 20D and a receiver RX 20E for bidirectional wireless communications with the eNB 22 via one or more antennas 20F. Also shown for the MTC device 20 at reference number 20G is a program stored on the memory, with or without accompanying hardware separate from the DP 20A, for decoding/reading small data from a padding bit portion of a transport block as detailed by example above. A SIM card is not specifically shown but if present for implementing certain embodiments of these teachings in a MTC radio device 20 includes a processor and a memory storing a computer program which when executed by one or more processors operates as reference number 20G according to the teachings enabled by the examples above.

[0053] The eNB 22 also includes processing means such as at least one data processor (DP) 22A, storing means such as at least one computer-readable memory (MEM) 22B storing at least one computer program (PROG) 22C executable by the eNB 22 which cause the device 22 to perform actions as detailed above, and communicating means such as a transmitter TX 22D and a receiver RX 22E for bidirectional wireless communications with the UE 20 via one or more antennas 22F. There is a data and/or control path 25 coupling the eNB 22 with the MME/SGW 23, and another data and/or control path 23 coupling the eNB 22 to other eNBs/access nodes. The eNB 22 has at block 22G a functional compiler which is configured according to these teachings to dispose or otherwise insert small data packets into the padding bit portion of transport blocks addressed to UEs other than the one to whom the transport block is addressed. Such a compiler 22G may be implemented in hardware, tangibly stored software, or a combination of them both.

[0054] Similarly, for embodiments in which a node in the CN does the compiling which may be the typical protocol for other radio access technologies other than LTE/LTE-A, the CN server 24 includes processing means such as at least one data processor (DP) 24A, storing means such as at least one computer-readable memory (MEM) 24B storing at least one computer program (PROG) 24C of executable instructions, and communicating means such as a modem 24H for bidirectional communications with the eNB 22 via the MEME/S-GW 23 and its data/control path 25. While not particularly illustrated for the UE 20 or eNB 22, those devices are also assumed to include as part of their wireless communicating means a modem which may be inbuilt on an RF front end chip within those devices 20, 22 and which also carries the TX 20D/22D and the RX 20E/22E. Such a modem implementing embodiments of these teachings may include the functionality described for blocks 20G and 22G. For the CN server 24, it also is shown to include a compiler 24G which functions similar to that shown for the eNB 22.

[0055] At least one of the PROGs 20C in the MTC radio device 20 is assumed to include a set of program instructions that, when executed by the associated DP 20A, enable the device to operate in accordance with the exemplary embodiments of this invention, as detailed above. The eNB 22 and CN server 24 may also have software to implement certain aspects of these teachings for compiling paging messages as detailed above. In these regards the exemplary embodiments of this invention may be implemented at least in part by computer software stored on the MEM 20B, 22B which is executable by the DP 20A of the MTC radio device 20 and/or by the DP 22A of the eNB 22 and/or by the DP 24A of the CN server 24, or by hardware, or by a combination of tangibly stored software and hardware (and tangibly stored firmware). Electronic devices implementing these aspects of the invention need not be the entire MTC radio device 20 or eNB 22 or CN server 24, but exemplary embodiments may be implemented by one or more components of same such as the above described tangibly stored software, hardware, firmware and DP, an application specific integrated circuit ASIC or a system on a chip SOC, which for the MTC radio device may be a MTC-specific SIM card or a modem.

[0056] In general, the various embodiments of the MTC device 20 can include, but are not limited to portable or fixed sensing devices having wireless communication capabilities, and also personal/user operated portable digital devices having wireless communication capabilities including but not limited to cellular telephones, navigation devices, laptop/palmtop/tablet computers, digital cameras, music devices, and Internet appliances.

[0057] Various embodiments of the computer readable MEMs 20B, 22B and 24B include any data storage technology type which is suitable to the local technical environment, including but not limited to semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, removable memory, disc memory, flash memory, DRAM, SRAM, EEPROM and the like. Various embodiments of the DPs 20A, 22A and 24A include but are not limited to general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and multi-core processors.

[0058] Various modifications and adaptations to the foregoing exemplary embodiments of this invention may become apparent to those skilled in the relevant arts in view of the foregoing description. While the exemplary embodiments have been described above in the context of the E-UTRAN/LTE and LTE-A systems, it should be appreciated that the exemplary embodiments of this invention are not limited for use with only this one particular type of wireless communication system, and that they may be used to advantage in other wireless communication systems such as for example UTRAN, GERAN and GSM and others which may use transport blocks conventionally addressed to one device for carrying small data downlink to an MTC or other device.

[0059] Further, some of the various features of the above non-limiting embodiments may be used to advantage without the corresponding use of other described features. The foregoing description should therefore be considered as merely illustrative of the principles, teachings and exemplary embodiments of this invention, and not in limitation thereof.

Claims

WHAT IS CLAIMED IS:

1. An apparatus comprising:

at least one processor; and

at least one memory storing a computer program;

in which the at least one memory with the computer program is configured with the at least one processor to cause the apparatus to at least:

determine that there is second data to be sent to a second radio device; and dispose the second data into a second padding bit portion of a downlink message which comprises in a first portion first data for a different first radio device.

2. The apparatus according to claim 1, in which the downlink message comprises a medium access control MAC protocol data unit PDU, and the first data comprises a service data unit SDU.

3. The apparatus according to claims 1 or 2, in which the second padding bit portion of the downlink message comprises at least:

a data section comprising the second data; and

a subheader having at least a length field in which is indicated a size of the data section, and a format field in which is indicated a size of the length field.

4. The apparatus according to claim 3, in which the first device and the second device are assigned a same cell radio network temporary identifier which is broadcast in system information.

5. The apparatus according to claim 3, in which the second data comprises a plurality of N data segments to be sent to N radio devices other than the first radio device, and in which the N data segments are disposed into the second padding bit portion of the downlink message by multiplexing N subheaders and by multiplexing the N data segments each corresponding to one of the N subheaders, in which N is an integer greater than one.

6. The apparatus according to any of claims 1 through 5, in which the at least one memory with the computer program is configured with the at least one processor to cause the apparatus to at least further:

schedule a downlink resource by sending a physical downlink control channel

PDCCH that allocates to the first radio device and to the second radio device a physical downlink shared channel PDSCH; and

send on the allocated PDSCH the downlink message which has the second data disposed into the second padding bit portion;

in which the first radio device comprises a user equipment and the second data is a machine to machine M2M transmission.

A method, comprising:

determining that there is second data to be sent to a second radio device; and disposing the second data into a second padding bit portion of a downlink ge which comprises in a first portion first data for a different first radio device.

8. The method according to claim 7, in which the downlink message comprises a medium access control MAC protocol data unit PDU, and the first data comprises a service data unit SDU.

9. The method according to claims 7 or 8, in which the second padding bit portion of the downlink message comprises at least:

a data section comprising the second data; and

10. The method according to claim 9, in which first device and the second device are assigned a same cell radio network temporary identifier which is broadcast in system information.

11. The method according to claim 9, in which the second data comprises a plurality of N data segments to be sent to N radio devices other than the first radio device, and in which disposing the N data segments into the second padding bit portion of the downlink message comprises multiplexing N subheaders and multiplexing the N data segments each corresponding to one of the N subheaders, in which N is an integer greater than one. 12. The method according to any of claims 7 through 11, the method further comprising:

scheduling a downlink resource by sending a physical downlink control channel PDCCH that allocates to the first radio device and to the second radio device a physical downlink shared channel PDSCH; and

sending on the allocated PDSCH the downlink message which has the second data disposed into the second padding bit portion;

13. A computer readable memory storing a computer program comprising:

code for determining that there is second data to be sent to a second radio device; and

code for disposing the second data into a second padding bit portion of a downlink message which comprises in a first portion first data for a different first radio device.

14. The computer readable memory according to claim 13, in which the second padding bit portion of the downlink message comprises at least:

a data section comprising the second data; and

15. An apparatus comprising:

at least one processor; and

at least one memory storing a computer program;

receive a downlink message which comprises in a first portion first data directed to a first radio device; and

from a second padding bit portion of the received downlink message, read second data directed to a second radio device different from the first radio device.

16. The apparatus according to claim 15, in which the second padding bit portion of the downlink message comprises at least:

a data section comprising the second data; and

17. The apparatus according to claim 15, in which the second padding bit portion comprises:

N multiplexed subheaders; and

N multiplexed data segments each corresponding to one of the N subheaders; in which N is an integer greater than one and each n^th data segment comprises data directed to an n^th one of N radio devices other than the first radio device.

18. The apparatus according to any of claims 15 through 17, in which the at least one memory with the computer program is configured with the at least one processor to cause the apparatus to at least further:

learn from a physical downlink control channel PDCCH that a physical downlink shared channel PDSCH is allocated to a cell radio network temporary identifier that is shared by the first radio device and by the second radio device; and tune to receive the downlink message on the allocated PDSCH;

in which the second data is a machine to machine M2M transmission.

19. A method comprising:

receiving a downlink message which comprises in a first portion first data directed to a first radio device; and

from a second padding bit portion of the received downlink message, reading second data directed to a second radio device different from the first radio device.

20. The method according to claim 19, in which the second padding bit portion of the downlink message comprises at least:

a data section comprising the second data; and

21. The method according to claim 19, in which the second padding bit portion comprises:

N multiplexed subheaders; and

22. A computer readable memory storing a computer program comprising:

code for receiving a downlink message which comprises in a first portion first data directed to a first radio device; and

code for reading, from a second padding bit portion of the received downlink message, second data directed to a second radio device different from the first radio device.

23. The computer readable memory according to claim 22, in which the second padding bit portion of the downlink message comprises at least:

a data section comprising the second data; and

24. The computer readable memory according to claim 22, in which the second padding bit portion comprises:

N multiplexed subheaders; and