U.S. patent application number 15/327808 was filed with the patent office on 2017-07-27 for user terminal and mobile communication system.
This patent application is currently assigned to KYOCERA CORPORATION. The applicant listed for this patent is KYOCERA CORPORATION. Invention is credited to Hiroyuki ADACHI, Kugo MORITA, Chiharu YAMAZAKI.
Application Number | 20170215218 15/327808 |
Document ID | / |
Family ID | 55163114 |
Filed Date | 2017-07-27 |
United States Patent
Application |
20170215218 |
Kind Code |
A1 |
ADACHI; Hiroyuki ; et
al. |
July 27, 2017 |
USER TERMINAL AND MOBILE COMMUNICATION SYSTEM
Abstract
A user terminal according to an embodiment comprises: a
controller configured to perform control to discard data of a
predetermined sequence number, under a predetermined condition
based on a window size used in a receiving RLC entity to define a
sequence number of data capable of being received without advancing
a window, in the receiving RLC entity established to receive data
by D2D communication that is direct device-to-device communication.
The controller sets the window size to zero.
Inventors: |
ADACHI; Hiroyuki;
(Kawasaki-shi, Kanagawa, JP) ; MORITA; Kugo;
(Yokohama-shi, Kanagawa, JP) ; YAMAZAKI; Chiharu;
(Ota-ku, Tokyo, JP) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
KYOCERA CORPORATION |
Kyoto |
|
JP |
|
|
Assignee: |
KYOCERA CORPORATION
Kyoto
JP
|
Family ID: |
55163114 |
Appl. No.: |
15/327808 |
Filed: |
July 22, 2015 |
PCT Filed: |
July 22, 2015 |
PCT NO: |
PCT/JP2015/070873 |
371 Date: |
January 20, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62035088 |
Aug 8, 2014 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 29/08 20130101;
H04W 80/02 20130101; H04L 1/08 20130101; H04W 28/0215 20130101;
H04L 47/32 20130101; H04L 47/27 20130101; H04L 47/34 20130101; H04L
1/1832 20130101; H04W 28/06 20130101; H04W 92/18 20130101; H04W
76/14 20180201; H04W 76/30 20180201; H04L 69/324 20130101 |
International
Class: |
H04W 76/02 20060101
H04W076/02; H04W 28/06 20060101 H04W028/06 |
Foreign Application Data
Date |
Code |
Application Number |
Jul 25, 2014 |
JP |
2014-152429 |
Claims
1. A user terminal, comprising: a controller configured to perform
control to discard data of a predetermined sequence number, under a
predetermined condition based on a window size used in a receiving
RLC entity to define a sequence number of data capable of being
received without advancing a window, in the receiving RLC entity
established to receive data by D2D communication that is direct
device-to-device communication, wherein the controller sets the
window size to zero.
2. The user terminal according to claim 1, wherein the controller
sets, in accordance with a type of information transmitted by the
D2D communication, the window size to zero.
3. The user terminal according to claim 1, wherein the controller
sets, in accordance with a destination of data transmitted by the
D2D communication, the window size to zero.
4. The user terminal according to claim 1, wherein the controller
sets, in accordance with a transmission method in the D2D
communication, the window size to zero.
5. A user terminal, comprising: a controller configured to
establish a receiving RLC entity for receiving data by D2D
communication that is direct device-to-device communication,
wherein the controller performs, in accordance with a type of
information transmitted by the D2D communication, a setting related
to a window in the receiving RLC entity.
6.-21. (canceled)
22. A user terminal, comprising: a controller configured to perform
data deciphering and data de-compression based on an unchanged
parameter in a PDCP entity used in D2D communication that is direct
device-to-device communication.
23. The user terminal according to claim 22, wherein the unchanged
parameter is a maximum value of a context identifier.
Description
TECHNICAL FIELD
[0001] The present application relates to a user terminal that is
used in a mobile communication system that supports D2D
communication being direct device-to-device communication and a
mobile communication system.
BACKGROUND ART
[0002] In the 3rd Generation Partnership Project (3GPP) that is a
mobile communication system standardization project, introduction
of a device-to-device proximity service (D2D ProSe) in Release 12
as a new function is under review.
[0003] The D2D proximity service is a service that enables direct
D2D communication to be performed in a synchronous cluster
including a plurality of user terminals which are synchronized with
one another. The D2D proximity service includes a D2D discovery
procedure of discovering a nearby terminal and D2D communication
that is direct D2D communication.
[0004] In the D2D communication, a transmitting user terminal
establishes a transmitting RLC entity in order to transmit data,
and a receiving user terminal establishes a receiving RLC entity in
order to receive data. Currently, the receiving RLC entity has been
agreed to be release depending on implementation of a user
terminal, but there is no agreement on the release of the
transmitting RLC entity (see Non Patent Document 1).
PRIOR ART DOCUMENT
Non-Patent Document
[0005] Non Patent Document 1: 3GPP Written Contribution
RP-140648
SUMMARY OF THE INVENTION
[0006] A user terminal according to an embodiment comprises a
controller configured to perform control to discard data of a
predetermined sequence number, under a predetermined condition
based on a window size used in a receiving RLC entity to define a
sequence number of data capable of being received without advancing
a window, in the receiving RLC entity established to receive data
by D2D communication that is direct device-to-device communication.
The controller sets the window size to zero.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] FIG. 1 is a configuration diagram illustrating an LTE system
according to an embodiment;
[0008] FIG. 2 is a block diagram illustrating a UE according to an
embodiment;
[0009] FIG. 3 is a block diagram illustrating an eNB according to
an embodiment;
[0010] FIG. 4 is a protocol stack diagram according to an
embodiment;
[0011] FIG. 5 is a configuration diagram illustrating a radio frame
according to an embodiment;
[0012] FIG. 6 is a diagram for describing a PDCP entity and an RLC
entity in D2D communication;
[0013] FIG. 7 is a diagram illustrating an example for describing
an arrangement of time and frequency resources used in D2D
communication according to an embodiment;
[0014] FIG. 8 is a diagram for describing an operation of a UE 100
in D2D communication; and
[0015] FIG. 9 is a diagram for describing an operation (a second
operation) of a UE 100 in D2D communication.
[0016] FIG. 10 is a diagram indicating examples of out-of-coverage
D2D communication and in-coverage D2D communication.
[0017] FIG. 11 is a diagram indicating example of in-activity timer
related actions.
DESCRIPTION OF THE EMBODIMENT
Overview of Embodiment
[0018] In an existing cellular communication, establishment and
release of a receiving entity and a transmitting entity between a
user terminal and a base station are simultaneously performed by
the base station and the user terminal, respectively, through an
RRC message. Thus, although a sequence number value (hereinafter,
referred to as an "SN value") of data is initialized each time an
RLC entity is established, no deviation in an SN value of data
occurs between a receiving entity and a transmitting RLC
entity.
[0019] On the other hand, in the D2D communication, when the
transmitting user terminal releases the transmitting RLC entity for
performing transmission to the receiving user terminal and then
transmits data to the receiving user terminal through a newly
established transmitting RLC entity, the receiving user terminal
may maintain the receiving RLC entity used to receive data from the
transmitting user terminal without releasing the receiving RLC
entity.
[0020] In this case, when the SN value of data is initialized in
the new transmitting RLC entity as in the existing cellular
communication, deviation in an SN value is likely to occur between
the receiving user terminal that is maintaining the receiving RLC
entity and the transmitting user terminal that has established the
new transmitting RLC entity.
[0021] Since the receiving user terminal determines whether or not
new data is identical to previously received data based on the SN
value of data received from the transmitting user terminal, when
deviation occurs in the SN value, the receiving user terminal is
likely to regard new data as previously received data and discard
the new data.
[0022] In this regard, one of objects of the present application is
to provide a technique in which it is possible to prevent the user
terminal from regarding new data as previously received data and
discarding the new data.
[0023] A user terminal (a receiving user terminal) according to an
embodiment comprises: a controller configured to perform control to
discard data of a predetermined sequence number, under a
predetermined condition based on a window size used in a receiving
RLC entity to define a sequence number of data capable of being
received without advancing a window, in the receiving RLC entity
established to receive data by D2D communication that is direct
device-to-device communication. The controller sets the window size
to zero.
[0024] In the embodiment, the controller sets, in accordance with a
type of information transmitted by the D2D communication, the
window size to zero.
[0025] In the embodiment, the controller sets, in accordance with a
destination of data transmitted by the D2D communication, the
window size to zero.
[0026] In the embodiment, the controller sets, in accordance with a
transmission method in the D2D communication, the window size to
zero.
[0027] A user terminal according to an embodiment comprises a
controller configured to establish a receiving RLC entity for
receiving data by D2D communication that is direct device-to-device
communication. The controller performs, in accordance with a type
of information transmitted by the D2D communication, a setting
related to a window in the receiving RLC entity.
[0028] A user terminal (a receiving user terminal) according to an
embodiment comprises a receiver configured to receive information
related to release of a transmitting RLC entity from another user
terminal that has established the transmitting RLC entity for
transmitting data to the user terminal through D2D communication
that is direct device-to-device communication.
[0029] In the embodiment, the user terminal further comprises a
controller configured to release a receiving RLC entity for
receiving data from the another user terminal through the D2D
communication, based on the information received by the
receiver.
[0030] In the embodiment, the controller releases the receiving RLC
entity on a basis of the information, at least before a period of
time in which the another user terminal releases the transmitting
RLC entity is exceeded.
[0031] In the embodiment, the information is information of a timer
used for the another user terminal to release the transmitting RLC
entity.
[0032] In the embodiment, a plurality of periods of time for
repetitive transmission of data are set in a time direction. The
user terminal further comprising a controller configured to release
the receiving RLC entity when no data is received from the another
user terminal although after data is received from the another user
terminal within a first period of time serving as the period of
time, a second period of time serving as the period of time
subsequent to the first period of time is exceeded.
[0033] A user terminal (a transmitting user terminal) according to
an embodiment comprises: a controller configured to establish a
transmitting RLC entity for transmitting data to another user
terminal through D2D communication that is direct device-to-device
communication; and a transmitter configured to transmit information
related to release of the transmitting RLC entity to the another
user terminal.
[0034] In the embodiment, the information is information of a timer
used for the user terminal to release the transmitting RLC
entity.
[0035] In the embodiment, a plurality of periods of time for
repetitive transmission of data are set in a time direction, and
the controller randomly sets a timing at which the same data is
transmitted when control of repeatedly transmitting the same data
within the period of time is performed.
[0036] A user terminal (a receiving user terminal) according to an
embodiment comprises: a controller configured to establish a
receiving RLC entity for receiving data from another user terminal
through D2D communication that is direct device-to-device
communication; and a receiver configured to receive information
indicating at least one of a start and an end of transmission of
data transmitted from the another user terminal through the D2D
communication. The controller releases the receiving RLC entity
based on the information.
[0037] In the embodiment, the information is flag information
identifying an interval from a start to an end of one block of the
data transmitted from the another user terminal.
[0038] In the embodiment, a plurality of periods of time for
repetitive transmission of data are set in a time direction, and
the controller releases the receiving RLC entity when no data is
received from the another user terminal although after data is
received from the another user terminal within a first period of
time serving as the period of time, a second period of time serving
as the period of time subsequent to the first period of time is
exceeded.
[0039] A user terminal (a transmitting user terminal) according to
an embodiment comprises: a controller configured to establish a
transmitting RLC entity for transmitting data to another user
terminal through the D2D communication that is direct
device-to-device communication; and a transmitter configured to
transmit information indicating at least one of a start and an end
of transmission of data transmitted from the another user terminal
through the D2D communication.
[0040] In the embodiment, the information is flag information
identifying an interval from a start to an end of one block of the
data.
[0041] Incidentally, in the D2D communication, a method for setting
a PDCP parameter and a RLC parameter is not yet defined. Therefore,
one of objects of the present application is to provide a technique
for setting a PDCP parameter and an RLC parameter used for D2D
communication.
[0042] A mobile communication system according to an embodiment
comprises: a first user terminal configured to transmit a
scheduling allocation indicating a position of time and frequency
resources for receiving data in the D2D communication, using time
and frequency resources within an SA resource pool; and a second
user terminal configured to receive the scheduling allocation from
the first user terminal using the time and frequency resources
within the SA resource pool. The first user terminal establishes a
transmitting RLC entity used in the D2D communication based on
setting information associated with the SA resource pool. The
second user terminal establishes a receiving RLC entity used in the
D2D communication based on the setting information associated with
the SA resource pool.
[0043] A mobile communication system according to an embodiment
comprises: a first user terminal configured to establish a
transmitting RLC entity for transmitting data through the D2D
communication; and a second user terminal configured to establish a
receiving RLC entity for receiving data through the D2D
communication. The first user terminal transmits data including
setting information of a receiving RLC entity. The second user
terminal establishes the receiving RLC entity based on the setting
information of the receiving RLC entity.
[0044] A mobile communication system according to an embodiment
comprises: a first user terminal configured to transmit a
scheduling allocation indicating a position of time and frequency
resources for receiving data in the D2D communication; and a second
user terminal configured to receive the scheduling allocation from
the first user terminal. The first user terminal transmits the
scheduling allocation including setting information of a receiving
RLC entity for receiving data in the D2D communication. The second
user terminal establishes the receiving RLC entity based on the
setting information of the receiving RLC entity.
[0045] In the D2D communication, a method of compressing data in a
PDCP entity is not yet defined. Therefore, one of objects of the
present application is to provide a technique for compressing data
in a PDCP entity in D2D communication.
[0046] A user terminal according to an embodiment comprises a
controller configured to perform data deciphering and data
de-compression based on an unchanged parameter in a PDCP entity
used in D2D communication that is direct device-to-device
communication.
[0047] In the embodiment, the unchanged parameter is a maximum
value of a context identifier.
[0048] It should be noted that the content that follows also is
included in the overview of the embodiment.
[0049] In an embodiment, a plurality of periods during which data
is transmitted repeatedly are arranged in a time direction, and the
controller (of the user terminal) randomly sets, if performing
control to repeatedly transmit the same data within the periods, a
timing at which the identical data is transmitted.
[0050] The user terminal according to an embodiment includes a
controller configured to compress, on the basis of the unchanged
parameter, data, in the PDCP entity used in the D2D communication
that is direct device-to-device communication.
[0051] In an embodiment, the unchanged parameter is a maximum value
of a context identifier.
Embodiment
[0052] Hereinafter, the embodiment in a case where a content of the
present application is applied to an LTE system will be
described.
[0053] (System Configuration)
[0054] FIG. 1 is a configuration diagram of an LTE system according
to an embodiment. As shown in FIG. 1, the LTE system according to
the embodiment includes UEs (User Equipments) 100, E-UTRAN (Evolved
Universal Terrestrial Radio Access Network) 10, and EPC (Evolved
Packet Core) 20.
[0055] The UE 100 corresponds to a user terminal. The UE 100 is a
mobile communication device and performs radio communication with a
connected cell (a serving cell). Configuration of the UE 100 will
be described later.
[0056] The E-UTRAN 10 corresponds to a radio access network. The
E-UTRAN 10 includes eNBs 200 (evolved Node-Bs). The eNB 200
corresponds to a base station. The eNBs 200 are connected mutually
via an X2 interface. Configuration of the eNB 200 will be described
later.
[0057] The eNB 200 manages a cell or a plurality of cells and
performs radio communication with the UE 100 that establishes a
connection with the cell of the eNB 200. The eNB 200, for example,
has a radio resource management (RRM) function, a function of
routing user data, and a measurement control function for mobility
control and scheduling. It is noted that the "cell" is used as a
term indicating a minimum unit of a radio communication area, and
is also used as a term indicating a function of performing radio
communication with the UE 100.
[0058] The EPC 20 corresponds to a core network. A network of the
LTE system (a LTE network) is configured by the E-UTRAN 10 and the
EPC 20. The EPC 20 includes MME (Mobility Management Entity)/S-GW
(Serving-Gateway) 300. The EPC 20 may include an OAM (Operation and
Maintenance).
[0059] The MME performs various mobility controls and the like, for
the UE 100. The S-GW performs control to transfer user data. The
MME/S-GW 300 is connected to the eNB 200 via an S1 interface.
[0060] The OAM is a server apparatus managed by an operator and
performs maintenance and monitoring of the E-UTRAN 10.
[0061] FIG. 2 is a block diagram of the UE 100. As shown in FIG. 2,
the UE 100 includes an antenna 101, a radio transceiver 110, a user
interface 120, GNSS (Global Navigation Satellite System) receiver
130, a battery 140, a memory 150, and a processor 160. The UE 100
may not have the GNSS receiver 130. Furthermore, the memory 150 may
be integrally formed with the processor 160, and this set (that is,
a chip set) may be a processor 160' constituting the
controller.
[0062] The antenna 101 and the radio transceiver 110 are used to
transmit and receive a radio signal. The radio transceiver 110
converts a baseband signal (a transmission signal) output from the
processor 160 into the radio signal, and transmits the radio signal
from the antenna 101. Furthermore, the radio transceiver 110
converts a radio signal (a reception signal) received by the
antenna 101 into the baseband signal, and outputs the baseband
signal to the processor 160.
[0063] The user interface 120 is an interface with a user carrying
the UE 100, and includes, for example, a display, a microphone, a
speaker, various buttons and the like. The user interface 120
receives an operation from a user and outputs a signal indicating
the content of the operation to the processor 160. The GNSS
receiver 130 receives a GNSS signal in order to obtain location
information indicating a geographical location of the UE 100, and
outputs the received signal to the processor 160. The battery 140
accumulates a power supplied to each block of the UE 100.
[0064] The memory 150 stores a program to be executed by the
processor 160 and information to be used for a process by the
processor 160. The processor 160 includes a baseband processor that
performs modulation and demodulation, encoding and decoding and the
like on the baseband signal, and a CPU (Central Processing Unit)
that performs various processes by executing the program stored in
the memory 150. The processor 160 may further include a codec that
performs encoding and decoding on sound and video signals. The
processor 160 corresponds to a controller and executes various
processes and various communication protocols described later.
[0065] FIG. 3 is a block diagram of the eNB 200. As shown in FIG.
3, the eNB 200 includes a plurality of antennas 201, a radio
transceiver 210, a network interface 220, a memory 230, and a
processor 240. It is note that the memory 230 may be integrated
with the processor 240, and this set (that is, a chipset) may be a
processor 240' constituting the controller.
[0066] The antenna 201 and the radio transceiver 210 are used to
transmit and receive a radio signal. The radio transceiver 210
converts a baseband signal (a transmission signal) output from the
processor 240 into the radio signal, and transmits the radio signal
from the antenna 201. Furthermore, the radio transceiver 210
converts a radio signal (a reception signal) received by the
antenna 201 into the baseband signal, and outputs the baseband
signal to the processor 240.
[0067] The network interface 220 is connected to the neighbor eNB
200 via the X2 interface and is connected to the MME/S-GW 300 via
the S1 interface. The network interface 220 is used in
communication performed on the X2 interface and communication
performed on the S1 interface.
[0068] The memory 230 stores a program to be executed by the
processor 240 and information to be used for a process by the
processor 240. The processor 240 includes the baseband processor
that performs modulation and demodulation, encoding and decoding
and the like on the baseband signal and a CPU that performs various
processes by executing the program stored in the memory 230. The
processor 240 corresponds to a controller and executes various
processes and various communication protocols described later.
[0069] FIG. 4 is a protocol stack diagram of a radio interface in
the LTE system. As shown in FIG. 4, the radio interface protocol is
classified into a layer 1 to a layer 3 of an OSI reference model,
wherein the layer 1 is a physical (PHY) layer. The layer 2 includes
MAC (Medium Access Control) layer, RLC (Radio Link Control) layer,
and PDCP (Packet Data Convergence Protocol) layer. The layer 3
includes RRC (Radio Resource Control) layer.
[0070] The PHY layer performs encoding and decoding, modulation and
demodulation, antenna mapping and demapping, and resource mapping
and demapping. Between the PHY layer of the UE 100 and the PHY
layer of the eNB 200, user data and a control signal are
transmitted through the physical channel.
[0071] The MAC layer performs priority control of data, and a
retransmission process and the like by hybrid ARQ (HARQ). Between
the MAC layer of the UE 100 and the MAC layer of the eNB 200, user
data and a control signal are transmitted via a transport channel.
The MAC layer of the eNB 200 includes a scheduler to decide
(schedule) a transport format of an uplink and a downlink (a
transport block size, a modulation and coding scheme) and an
allocated resource block to the UE 100.
[0072] The RLC layer transmits data to an RLC layer of a reception
side by using the functions of the MAC layer and the PHY layer.
Between the RLC layer of the UE 100 and the RLC layer of the eNB
200, user data and a control signal are transmitted via a logical
channel.
[0073] The PDCP layer performs header compression and
decompression, and cipher and decipher.
[0074] The RRC layer is defined only in a control plane handling a
control signal. Between the RRC layer of the UE 100 and the RRC
layer of the eNB 200, a control signal (an RRC message) for various
types of setting is transmitted. The RRC layer controls the logical
channel, the transport channel, and the physical channel in
response to establishment, re-establishment, and release of a radio
bearer. When a connection (an RRC connection) is established
between the RRC of the UE 100 and the RRC of the eNB 200, the UE
100 is in an RRC connected state, and when the connection is not
established, the UE 100 is in an RRC idle state.
[0075] NAS (Non-Access Stratum) layer positioned above the RRC
layer performs session management, mobility management and the
like.
[0076] FIG. 5 is a configuration diagram of a radio frame used in
the LTE system. In the LTE system, OFDMA (Orthogonal Frequency
Division Multiple Access) is employed in a downlink (DL), and
SC-FDMA (Single Carrier Frequency Division Multiple Access) is
employed in an uplink (UL), respectively.
[0077] As shown in FIG. 5, the radio frame is configured by 10
subframes arranged in a time direction. Each subframe is configured
by two slots arranged in the time direction. Each subframe has a
length of 1 ms and each slot has a length of 0.5 ms. Each subframe
includes a plurality of resource blocks (RBs) in a frequency
direction, and a plurality of symbols in the time direction. Each
resource block includes a plurality of subcarriers in the frequency
direction. A resource element is configured by one subcarrier and
one symbol. Among radio resources allocated to the UE 100, a
frequency resource is configured by a resource block and a time
resource is configured by a subframe (or slot).
[0078] (D2D Proximity Service)
[0079] The D2D proximity service will be described below. An LTE
system according to an embodiment supports the D2D proximity
service. The D2D proximity service is described in the Non Patent
Document 1, but an overview thereof is herein described.
[0080] The D2D proximity service is a service that enables direct
communication to be performed between UEs in a synchronous cluster
including a plurality of UEs 100. The D2D proximity service
includes a D2D discovery procedure of discovering a nearby UE and
D2D communication that is direct communication between UEs. The D2D
communication is also referred to as "direct communication."
[0081] A scenario in which all the UEs 100 configuring the
synchronous cluster are positioned within a cell coverage is
referred to as "in coverage." A scenario in which all the UEs 100
configuring the synchronous cluster are positioned out of the cell
coverage is referred to as "out of coverage." A scenario in which
some UEs 100 configuring the synchronous cluster are positioned
within the cell coverage, and the remaining UEs 100 are positioned
out of the cell coverage is referred to as "partial coverage."
[0082] Within the coverage, for example, the eNB200 serves as a D2D
synchronization source. A D2D asynchronization source is
synchronized with the D2D synchronization source without
transmitting a D2D synchronous signal. The eNB200 serving as the
D2D synchronization source transmits D2D resource information
indicating radio resources available for the D2D proximity service
through a broadcast signal. The D2D resource information includes,
for example, information (discovery resource information)
indicating radio resources available for the D2D discovery
procedure and information (communication resource information)
indicating radio resources available for the D2D communication. The
UE 100 serving as the D2D asynchronization source performs the D2D
discovery procedure and the D2D communication based on the D2D
resource information received from the eNB200.
[0083] In the out of coverage or the partial coverage, for example,
the UE 100 serves as the D2D synchronization source. In the out of
coverage, the UE 100 serving as the D2D synchronization source
transmits the D2D resource information indicating radio resources
available for the D2D proximity service, for example, through the
D2D synchronous signal. The D2D synchronous signal is a signal
transmitted in a D2D synchronization procedure of establishing
synchronization between terminals. The D2D synchronous signal
includes a D2DSS and a physical D2D synchronization channel
(PD2DSCH). The D2DSS is a signal that provides a synchronization
reference of a time and a frequency. The PD2DSCH is a physical
channel that carries more information than the D2DSS. The PD2DSCH
carries the D2D resource information (the discovery resource
information and the communication resource information).
Alternatively, when the D2D resource information is associated with
the D2DSS, the PD2DSCH may be unnecessary.
[0084] The D2D discovery procedure is used mainly when the D2D
communication is performed in a unicast manner. One UE 100 that
desires to start the D2D communication with the other UE 100
transmits a discovery signal (a D2D discovery signal) using any one
of radio resources available for the D2D discovery procedure. The
other UE 100 that desires to start the D2D communication with one
UE 100 scans the discovery signal within the radio resources
available for the D2D discovery procedure and receives the
discovery signal. The discovery signal may include information
indicating radio resources which one UE 100 uses for the D2D
communication.
[0085] (PDCP Entity and RLC Entity)
[0086] A PDCP entity and an RLC entity which are established for
the D2D communication will be described below with reference to
FIG. 6. FIG. 6 is a diagram for describing the PDCP entity and the
RLC entity in the D2D communication.
[0087] The UE 100 that performs the D2D communication establishes
the PDCP entity and the RLC entity. The PDCP entity performs the
same operation as the PDCP layer in the D2D communication, and the
RLC entity performs the same operation as the RLC layer in the D2D
communication. In the present embodiment, the RLC entity operates
in an unacknowledged mode (the UM). In the UM, data division and
combination are performed, but ARQ retransmission is not
performed.
[0088] The UE 100 that transmits data through the D2D communication
establishes a transmitting PDCP entity and a transmitting RLC
entity (hereinafter, referred to as a "transmitting entity"). On
the other hand, the UE 100 that receives data through the D2D
communication establishes a receiving PDCP entity and a receiving
RLC entity (hereinafter, referred to as a "receiving entity").
[0089] In order to specify the transmitting entity and the
receiving entity, an ID (a transmission source ID: a source Layer 2
ID) identifying a transmission source, an ID (a transmission
destination ID: a destination Layer 2 ID) identifying a
transmission destination, and an ID (LCID) identifying a logical
channel are used.
[0090] The transmitting entity is established when data that is to
be transmitted (that should be transmitted) through the D2D
communication is generated. On the other hand, the receiving entity
is established when first data is received through the D2D
communication but a corresponding receiving RLC entity is not
established. Thus, when the respective IDs (the transmission source
ID, the transmission destination ID, and the LCID) of the first
data are not identical to the respective IDs of the existing
receiving entity, the receiving entity is established.
[0091] Specifically, in order to transmit data to the UE 100B, the
UE 100A establishes the transmitting PDCP entity and the
transmitting RLC entity (hereinafter, referred to as a "first
transmitting entity") as illustrated in FIG. 6. In the first
transmitting entity, the transmission source ID is "A (the UE
100A)," the transmission destination ID is "B (the UE 100B)," and
the LCID is "1."
[0092] Further, in order to receive data from the UE 100B, the UE
100A establishes the receiving PDCP entity and the receiving RLC
entity (hereinafter, referred to as a "second receiving entity").
The UE 100A establishes the second receiving entity in which the
transmission source ID is "B," the transmission destination ID is
"A," and the LCID is "2" based on the first data (and the IDs)
received from the UE 100B.
[0093] Similarly, the UE 100A establishes a third receiving entity
in which the transmission source ID is "C (the UE 100C)," the
transmission destination ID is "A," and the LCID is "1" based on
the first data (and the IDs) received from the UE 100C.
[0094] The UE 100A transmits data to the UE 100B through the first
transmitting entity, receives data from the UE 100B through the
second receiving entity, and receives data from the UE 100C through
the third receiving entity.
Operation According to Embodiment
[0095] An operation according to an embodiment will be described
below with reference to FIGS. 7 to 9. FIG. 7 is a diagram
illustrating an example for describing an arrangement of time and
frequency resources used in the D2D communication according to the
present embodiment. FIG. 8 is a diagram for describing an operation
of the UE 100 in the D2D communication. FIG. 9 is a diagram for
describing an operation (a second operation which will be described
later) of the UE 100 in the D2D communication.
[0096] In the present embodiment, the UE 100 that transmits data
through the D2D communication repeatedly transmits the same data
within a period of time for repetitive transmission of data. As the
period of time (hereinafter, the repetitive transmission period of
time), a plurality of periods of time are set in a time
direction.
[0097] The UE 100 selects radio resources used for transmission of
data from among time and frequency resources in a data region (a
data resource pool) periodically arranged in the time direction.
For example, when timings to transmit the same data are randomly
set in the time direction, the UE 100 randomly selects four
subframes from among time and frequency resources in the first half
of the data region, and randomly selects four subframes from among
time and frequency resources in the second half of the data region
as illustrated in FIG. 7. The UE 100 repeatedly transmits certain
data using the four subframes selected from among the time and
frequency resources in the first half of the data region, and
repeatedly transmits another data using the four subframes selected
from among the time and frequency resources in the first half of
the data region. In this case, the durations of the first half and
the second half of the data region correspond to the repetitive
transmission period of time. Alternatively, the UE 100 repeatedly
transmits certain data using eight subframes selected from among
the time and frequency resources of the data region. In this case,
the duration of the data region corresponds to the repetitive
transmission period of time.
[0098] Since the UE 100 randomly timings to transmit the same data
in the time direction, it is possible to prevent data transmitted
from the UE 100 from continuously colliding with data transmitted
from another UE. As a result, the receiving UE can receive at least
one piece of data among a plurality of pieces of data (same data)
that are repeatedly transmitted from the UE 100.
[0099] The UE 100 selects radio resources for transmitting a
scheduling assignment (SA) indicating a position of (radio
resources for) data transmitted through the D2D communication from
among time and frequency resources in an SA region (an SA resource
pool) which are periodically arranged in the time direction. In the
example of FIG. 7, since the frequency position of the SA is
identical to the frequency position of the radio resource for data,
the receiving UE can recognize the frequency position of data based
on the frequency position of the SA.
[0100] An example in which the UE 100A that has transmitted data to
the UE 100B through the D2D communication releases the transmitting
RLC entity, then newly establishes the transmitting RLC entity, and
transmits data to the UE 100B will be described below (see FIG.
8).
[0101] First, the UE 100A that is performing the D2D communication
transmits data (specifically, a packet (a UMD PDU)) in which the SN
number is N at a certain timing. As a result, a VT (US) in the UE
100A becomes N+1. Here, the VT (US) is a state variable holding an
SN value allocated to a newly generated UMD PDU. An initial value
of the VT (US) is set to, for example, 0 (zero), and the VT (US) is
updated each time the transmitting RLC entity in the UM transmits
the UMD PDU in which the SN is the VT (US).
[0102] Meanwhile, the UE 100B receives the data (the UMD PDU) in
which the SN value is N from the UE 100A. As a result, a VR (UH) of
the UE 100B becomes N+1. The VR (UR) of the UE 100B becomes M
(.ltoreq.N+1). Here, the VR (UR) is a UM reception state variable,
and holds the earliest SN value of the UMD PDU for which reordering
is considered. The UE 100B may set an SN value of data (first data
received from the UE 100A) serving as a trigger for establishing
the receiving RLC entity as an initial value of the VR (UR). In the
present embodiment, the SN value of the first data (the UMD PDU)
received from the UE 100A is set as the initial value of the VR
(UR). The VR (UH) is a highest UM reception state variable, and
holds an SN value next to an SN value of a UMD PDU having the
highest SN among the received UMD PDUs. The VR (UH) undertakes a
high order end of a reordering window. The UE 100B may set an SN
value of data (first data received from the UE 100A) serving as a
trigger for establishing the receiving RLC entity as an initial
value of the VR (UH). In the present embodiment, the SN value of
the first data (the UMD PDU) received from the UE 100A is set as
the initial value of the VR (UH).
[0103] The UE 100B discards the data (the UMD PDU) having a
sequence number (an SN value) positioned within the range of the
reordering window in the receiving RLC entity under a certain
condition. Specifically, the UE 100B (the receiving RLC entity)
that has received from a UMD PDU in which the SN is x from a lower
layer discards the received data (the UMD PDU) when "VR
(UR)<x<VR (UH)" is satisfied, when the UMD PDU in which the
SN is x has been previously received, or when "(VR
(UH)-UM_Window_Size)<=x<VR (UR)" is satisfied.
[0104] Further, when an SN value of data satisfies "(VR
(UH)-UM_Window_Size)<=SN<VR (UH)," the SN value is positioned
within the range of the reordering window (that is, falls within
the reordering window). Thus, UM_Window_Size indicates the range of
the reordering window. Further, UM_Window_Size is a constant that
is used by the receiving RLC entity in order to define an SN of a
UMD PDU that can be received without moving the reordering window
forward.
[0105] On the other hand, data that has a sequence number
positioned within the range of the reordering window and does not
satisfy the certain condition is input to a receiving buffer. The
data in the receiving buffer is sorted in an SN order,
reconstructed as an RLC SDU, and then transferred to an upper
layer.
[0106] Then, when transmission of data to be transmitted to the UE
100B is completed, the UE 100A releases the transmitting RLC entity
(and the transmitting PDCP entity). Thereafter, when new data to be
transmitted to the UE 100B is generated, the UE 100A establishes a
new transmitting RLC entity. Meanwhile, since the release of the
receiving RLC entity (and the receiving PDCP entity) depends on an
implementation of the UE 100B, the UE 100B may maintain the
receiving RLC entity. In this case, similarly to the existing
cellular communication, the UE 100A is considered to set the SN
value to the initial value (that is, "0") in the new transmitting
RLC entity and start transmission of data.
[0107] Specifically, the UE 100A transmits new data (UMD PDU) in
which the SN value is 0 as illustrated in FIG. 8. As a result, the
VT (US) of the UE 100A becomes 1 (one). Meanwhile, the UE 100B
receives the new data (UMD PDU) in which the SN value is 0 from the
UE 100A. Here, when the UE 100A uses the same LCID in the released
transmitting RLC entity and the newly established transmitting RLC
entity, the UE 100B performs a process of receiving new data from
the UE 100A through the receiving RLC entity being maintained
thereby. Since the UE 100B (the receiving RLC entity) has the VR
(UH) of N+1 and the VR (UR) of M (.ltoreq.N+1), the deviation in
the SN value occurs between the UE 100A and the UE 100B. Thus, as
illustrated in FIG. 8, "(VR (UH)-UM_Window_Size)<=0 (=x)<VR
(UR)" is satisfied, and the UE 100B is likely to discard the
received new data in the receiving RLC entity.
[0108] In this regard, in the present embodiment, it is possible to
prevent the UE 100B from regarding the new data as previously
received data and discarding the new data through any one of the
following operations (first to third operations).
[0109] (A) First Operation
[0110] First, a first operation will be described. In the first
operation, the UE 100A transmits information (hereinafter, referred
to as "release information") related to release of the transmitting
RLC entity to the UE 100B. The UE 100B receives the release
information from the UE 100A.
[0111] The release information is, for example, information of a
timer (an in-activity timer) used for the UE 100A to release the
transmitting RLC entity. When a plurality of timers having
different lengths are specified in order to release the
transmitting RLC entity, the UE 100A transmits information (for
example, flag information) indicating a timer to be used among a
plurality of timers as the release information.
[0112] A notification of the release information may be given from
the UE 100A to the UE 100B through a MAC CE. A notification of
information of a plurality of specified timers may be given to each
UE through a SIB, or information of a plurality of specified timers
may be set to each UE in advance.
[0113] The UE 100B may release the receiving RLC entity for
receiving data from the UE 100B based on the release information.
Specifically, the UE 100B releases the receiving RLC entity at
least before a time at which the UE 100A releases the transmitting
RLC entity is exceeded. The UE 100B may release the receiving RLC
entity at the same time at which the transmitting RLC entity is
released depending on the implementation of the UE 100B, or may
release the receiving RLC entity before a time at which the
transmitting RLC entity is released.
[0114] As a result, the transmitting RLC entity can be prevented
from being released before the receiving RLC entity is released. As
a result, the UE 100B can be prevented from regarding the new data
as the previously received data and discarding the new data.
[0115] Further, even when the UE 100B releases the receiving RLC
entity before the transmitting RLC entity is released, the UE 100B
establishes the receiving RLC entity using the SN value of data
transmitted from the UE 100A as the initial value, and thus the
deviation in the SN value does not occur between the UE 100A and
the UE 100B. Thus, although data is transmitted by the transmitting
RLC entity being maintained thereby after the receiving RLC entity
is released, there is no problem.
[0116] Alternatively, when data is received from the UE 100A after
the transmitting RLC entity is released based on the release
information, the UE 100B may regard the received data as new data
and perform a process without discarding the received data. For
example, when the UE 100B is maintaining the receiving RLC entity,
a process of adding a correction value to an SN value of new data
may be performed.
[0117] Alternatively, when the timer (the in-activity timer) of the
UE 100A is determined to have expired based on the release
information, the UE 100B may transfer all data held in the
receiving RLC entity to the upper layer and then process
subsequently received data as new data. For example, when a timer
set based on the release information expires, the UE 100B may
transfer all data in the receiving buffer to the upper layer and
then perform a process of initializing at least the SN value of the
receiving RLC entity.
[0118] (B) Second Operation
[0119] Next, a second operation will be described with reference to
FIG. 9. In the second operation, the UE 100B sets UM_Window_Size to
0.
[0120] As described above, when UM_Window_Size is larger than 0,
the UE 100B (the receiving RLC entity) is likely to discard
received new data. Thus, the UM 100B sets UM_Window_Size to 0 in
the receiving RLC entity. Thus, since the sequence number of the
received data is not positioned within the range of the reordering
window, the UE 100B transfers the received data to the upper layer
(specifically, the receiving PDCP entity) in the receiving RLC
entity without discarding the received data. As a result, it is
possible to prevent the new data from being regarded as the
previously received data and discarded.
[0121] Further, when UM_Window_Size is set to 0, data reordering is
not performed in the receiving RLC entity, and received data is
transferred to the upper layer. Thus, when reordering is
unnecessary in the receiving RLC entity, the UE 100 may set
UM_Window_Size to 0.
[0122] For example, the UE 100B may set UM_Window_Size to 0
according to a type of data transmitted through the D2D
communication. Specifically, the UE 100B may set UM_Window_Size to
0 when data is data that needs to be processed in real time such as
audio data or video data (for example, when an allowable delay of
data is equal to or larger than a certain value) and may set
UM_Window_Size to a normal size when data is document data.
[0123] Alternatively, the UE 100B may set UM_Window_Size to 0
according to the destination (the transmission destination ID) of
data transmitted through the D2D communication. Specifically, the
UE 100B may set UM_Window_Size to 0 when the transmission
destination ID is an ID indicating groupcast or broadcast, and may
set UM_Window_Size to a normal size when the transmission
destination ID is an ID indicating unicast (the UE 100B).
[0124] Alternatively, the UE 100B may set UM_Window_Size to 0
according to an application used in the D2D communication.
Specifically, the UE 100B may set UM_Window_Size to 0 when the
application is an application intended for voice communication or
video communication, and may set UM_Window_Size to a normal size
when the application is an application intended for transfer of
document data.
[0125] (C) Third Operation
[0126] Next, a third operation will be described. In the third
operation, the UE 100A transmits information indicating at least
one of a start and an end of transmission of data. The UE 100B
releases the receiving RLC entity based on the information.
[0127] For example, the UE 100A starts transmission of data after
transmitting a code indicating a start of transmission of data as
the information. Alternatively, the UE 100A transmits the
information together with first data. As the information is
received, the UE 100B can recognize that transmission of data has
been started by the UE 100A. Thus, the UE 100B can determine that
data received after the information is received is new data.
Accordingly, it is possible to prevent the new data from being
regarded as the previously received data and discarded.
[0128] The UE 100A may transmit the information through the MAC CE
or may add the information to a MAC subheader of first data and
transmit the resulting data.
[0129] Alternatively, the UE 100A transmits a code indicating an
end of transmission of data as the information after finishing
transmission of data. Alternatively, the UE 100B transmits the
information together with last data. As the information is
received, the UE 100B can recognize that the UE 100A has finished
transmission of data. Thus, the UE 100B can determine that data
received after the information is received is new data transmitted
through the new transmitting RLC entity. Accordingly, it is
possible to prevent the new data from being regarded as the
previously received data and discarded.
[0130] The UE 100A may transmit the information through the MAC CE
or may add the information to a MAC subheader of last data and
transmit the resulting data.
[0131] Alternatively, the UE 100A transmits flag information (an
identifier) identifying an interval from a start to an end of one
block of data as the information. Specifically, the UE 100A
increases a variable indicating the flag information each time a
block of data is changed. For example, when the flag information is
configured with one bit, the flag information is changed like 0, 1,
0, 1, . . . each time a block of data is changed. When the flag
information is configured with two bits, the flag information is
changed like 0, 1, 2, 3, 0, 1, . . . each time a block of data is
changed.
[0132] Accordingly, the UE 100B can determine that received data is
a block of new data according to the change in the flag
information. Thus, although received data is discarded, the UE 100B
can establish a new receiving entity and process the data in the
new receiving entity when the data is identified to be a block of
new data based on the flag information. Alternatively, the UE 100B
may correct the SN value without discarding the data in the new
receiving entity and then process the data.
[0133] The flag information may be necessarily transmitted together
with data when data is transmitted. In this case, for example, the
flag information can be necessarily transmitted together with data
such that the flag information is included in a MAC subheader of
data together with the transmission source ID, the transmission
destination ID, and the LCID. Alternatively, the flag information
may be transmitted when transmission of data starts and when
transmission of data ends or may be appropriately transmitted when
transmission of data is performed. In this case, the flag
information may be transmitted through the MAC CE or may be
transmitted through a dedicated MAC subheader.
[0134] In the third operation, for example, when data is audio
data, a start and an end of transmission of data may be decided by
detection of an unvoiced interval and a voiced interval. Further,
when data is document data, one piece of document data may be dealt
as one block, or each of a plurality of pieces of data generated by
dividing one piece of document data may be dealt as one block. In a
push to talk (PTT), switching from OFF to ON may be regarded as a
start of transmission of data, and switching from ON to OFF may be
regarded as an end of transmission of data.
Other Embodiments
[0135] In the above embodiment, the UE 100A repeatedly transmits
the same data within the repetitive transmission period of time. In
this case, the UE 100B may release the receiving RLC entity when no
data is received from the UE 100A although after receiving data
from the UE 100A within a first repetitive transmission period of
time a second repetitive transmission period of time subsequent to
the first repetitive transmission period of time is exceeded. It is
because when no data is received within the second repetitive
transmission period of time in which data is subsequently
transmitted from the UE 100A, the UE 100B can determine that
transmission of data from the UE 100A has ended. As a result, it is
possible to suppress the deviation in the SN value occurring as the
receiving RLC entity is continuously maintained.
[0136] The repetitive transmission period of time may be a value
set according to an application used in the D2D communication. For
example, the repetitive transmission period of time set for an
operation intended for voice communication or video communication
may be smaller than that set for an application intended for
transfer of document data. Alternatively, the repetitive
transmission period of time may be set only when an application is
intended for voice communication or video communication.
[0137] Further, setting information for repeatedly transmitting the
same data within the repetitive transmission period of time in the
D2D communication may be set to each of the respective UEs 100
(each of the UE 100A and the UE 100B) in advance or may be
transmitted to each of the respective UEs 100 through the SIB.
Thus, the UE 100A and the UE 100B can share the repetitive
transmission period of time.
[0138] Further, in the above embodiment, when the same data is
repeatedly transmitted to the UE 100B (in the unicast manner)
rather than the broadcast manner and the groupcast manner, the UE
100A may change a transmission antenna weight each time
transmission is performed. In this case, when the transmission
antenna weight is constant, all a plurality of transmissions may
have a bad reception quality, but when the transmission antenna
weight is changed each time transmission is performed, at least one
of a plurality of transmissions can have an improved reception
quality.
[0139] Further, in the above embodiment, the frequency position of
the SA is the same as the frequency position of the radio resource
for data, but embodiments are not limited thereto. For example, the
frequency position of the radio resource for data may be randomly
decided. In this case, information indicating the frequency
position of the radio resource for data may be included in the SA,
and, for example, the frequency position of the radio resource for
data may be associated with the frequency position of the SA so
that the frequency position of the radio resource for data is
randomly decided according to the frequency position of the SA.
[0140] Further, in the above embodiment, the UE 100A repeatedly
transmits the same data within the repetitive transmission period
of time, but embodiments are not limited thereto. Even when the UE
100 does not repeatedly transmit the same data (or, when the
repetitive transmission period of time is not set), the receiving
UE can prevent the new data from being regarded as the previously
received data and discarded through at least one of the first to
third operations.
[0141] Further, in the above embodiment, when the UE 100A transmits
audio data (an audio packet) through the D2D communication, the UE
100A may divide one packet into a plurality of subframes and
transmit one packet through one subframe instead of transmitting a
plurality of divided packets. In this case, since the packet is not
divided, the UE 100B can transfer the packet to the upper layer
without performing a process of combining the packets (the RLC
PDUs) in the receiving RLC entity. Thus, since reordering in the
upper layer when UM_Window_Size is set to 0 is unnecessary, it is
effective particularly in the second operation.
[0142] Further, in the above embodiment, when the UE 100A releases
the transmitting RLC entity according to an instruction (signaling)
given from the upper layer, the UE 100A may hold the transmission
destination ID and the LCID used by the transmitting RLC entity and
the SN value of data transmitted last until a certain period of
time elapses after the instruction is received.
[0143] When new data to be transmitted to UE 100B through the
transmitting RLC entity that is instructed to be released is
generated before a certain period of time elapses, the UE 100A
transmits the new data through any one of the following
methods.
[0144] Firstly, when the UE 100A transmits data to the UE 100B
using the same LCID as the held LCID, the UE 100A starts
transmission of new data using an SN value next to an SN value of
data that is transmitted last in the transmitting RLC entity. Thus,
when the UE 100B does not release the receiving RLC entity, since
an SN value of new data is an SN value subsequent to that of
previous data, the UE 100B can process the new data without
discarding the new data in the receiving RLC entity.
[0145] Secondly, the UE 100A transmits new data to the UE 100B
using a different LCID from the held LCID. Thus, even when the UE
100B does not release the receiving RLC entity, a new receiving RLC
entity is established since new data having the different LCID is
received. Accordingly, the UE 100B processes the new data in the
new receiving RLC entity and thus does not discard the new
data.
[0146] Here, a certain period of time is set to, for example, a
period of time longer than a timer until the receiving RLC entity
is released after the receiving RLC entity is not used.
[0147] Further, in the second operation, UM_Window_Size is set to
0, but embodiments are not limited thereto. UM_Window_Size may be
set to a value smaller than a prescribed value. In the LTE system,
since the prescribed value of UM_Window_Size is 2SN Length/2 (the
(SN bit length/2)-th power of 2), for example, UM_Window_Size may
be set to 2SN Length/x (X>2). Specifically, the UE 100B may set
UM_Window_Size to 2SN Length/2. As a result, since the range of the
reordering window is reduced, a sequence number of received data
becomes difficult to be positioned within the range of the
reordering window, and thus it is possible to perform the
reordering process while preventing the received data from being
discarded.
[0148] Further, when an SN value of data is out of the range of the
reordering window in the receiving RLC entity due to the occurrence
of deviation in an SN value between the UE 100A and the UE 100B,
the reordering window is moved based on an SN value of new data. In
this case, in the D2D communication, data in the receiving buffer
may be not processed (or discarded) before the reordering window is
moved. However, in the first operation and the third operation, the
movement of the reordering window can be prevented, and thus this
problem can be solved.
[0149] Further, in the above embodiment, the UE 100B sets an SN
value of data (first data) serving as a trigger for establishing
the receiving RLC entity as the initial value of the VR (UR), but
embodiments are not limited thereto. The UE 100B may set the
initial value of the VR (UR) to a value smaller than an SN value of
data serving as a trigger for establishing the receiving RLC
entity. For example, when an SN value of first data received from
the UE 100A is N+1, the UE 100B may set the initial value of the VR
(UR) to "(N+1)-(UM_Window_Size/x)" (x is an arbitrary number).
Thus, in the following case, it is possible to prevent the new data
from being regarded as the previously received data and
discarded.
[0150] First, the UE 100B that performs the D2D communication with
the UE 100A releases the receiving RLC entity and then receives
data in which the SN value is N+1 from the UE 100A that is
maintaining the transmitting RLC entity without releasing the
transmitting RLC entity. Thus, the UE 100B establishes the new
receiving RLC entity, and receives data from the UE 100A. The UE
100B sets N+1 serving as the SN value of the data serving as the
trigger for establishing the receiving RLC entity as the initial
value of the VR (UR). Then, the UE 100A is assumed to have
transmitted data having an SN value (for example, N) before data is
received by the new receiving RLC entity to the UE 100B without
transmitting data according to the SN value order. For example,
when data is repeatedly transmitted or retransmitted at a PHY
level, the UE 100B hardly transmit data according to the SN value
order. In this case, "(VR (UH)-UM_Window_Size)<N<VR (UR)
(=N+1)" is satisfied, and even when the UE 100B can normally
receive data that is repeatedly transmitted or retransmitted at the
PHY level, the UE 100B is likely to discard the data. However, as
the UE 100B sets the initial value of the VR (UR) to the value
smaller than the SN value of the data serving as the trigger for
establishing the receiving RLC entity, a data discarding target
range is reduced, and thus it is possible to prevent the new data
from being regarded as the previously received data and
discarded.
[0151] The UE 100B may set the initial value of the VR (UR) to the
value smaller than the SN value of the first data according to a
type of data transmitted through the D2D communication or may set
the initial value of the VR (UR) to the value smaller than the SN
value of the first data according to the destination of data
transmitted through the D2D communication. For example, when a type
of data is data that need not be processed in real time (for
example, an allowable delay of data is equal to or larger than a
certain value), the UE 100B may set the initial value of the VR
(UR) to the value smaller than the SN value of the first data.
Alternatively, when the transmission destination ID is an ID
indicating the groupcast or the broadcast, the UE 100B may set the
initial value of the VR (UR) to the value smaller than the SN value
of the first data. Thus, it is possible to prevent the new data
from being regarded as the previously received data and discarded
without lowering the communication quality.
[0152] Further, in the above embodiment, the RLC entity operates in
the UM, and embodiments are not limited thereto. The RLC entity may
operate in an acknowledged mode (AM). In the AM, not only data
division and assembly but also ARQ retransmission when transmission
of the RLC PDU fails are performed. As retransmission is performed
doubly through an HARQ in the MAC layer and an ARQ in the RLC
entity, high reliability can be obtained.
[0153] In the above embodiment, the LTE system has been described
as an exemplary mobile communication system, but embodiments are
not limited to the LTE system, and the present application may be
applied to a system rather than the LTE system.
[0154] [Additional Statement 1]
[0155] A supplementary matter of the embodiment is provided
below.
[0156] (1) Introduction
[0157] The release timing of the transmitting PDCP/RLC entity was
not agreed yet. In this additional statement, the need to align the
transmitting and receiving PDCP/RLC configurations as well as the
proper release procedure to prevent unnecessary UMD PDU discarding
is considered.
[0158] (2) Discussion
[0159] The procedure for D2D communication can be described as
follows. (See FIG. 10.) FIG. 10 is a diagram indicating examples of
out-of-coverage D2D communication and in-coverage D2D
communication.
[0160] The out-of-coverage D2D communication (A) will be briefly
described. As shown in FIG. 10, in the out-of-coverage D2D
communication (A), the UE 100A and UE 100B are located outside of
the coverage.
[0161] Firstly, the UE 100A and UE 100B synchronize. After that,
Data is generated in the UE 100A. The data is data to be
transmitted to the UE 100B. The UE 100A establishes a transmitting
PDCP/RLC entity (step 1). This operation is the operation of UE
implementation. Next, the UE 100A selects a transmission resource.
The UE 100 A transmits control information (SA) for notifying the
selected transmission resource. UE 100B receives the control
information from UE 100A. The UE 100B decodes the received SA. The
UE 100B grasps transmission resources used for data transmission
based on the decoded SA. Next, the UE 100A transmits data. The UE
100B receives the data based on the grasped transmission resource.
The UE 100B acquires the L2 ID and LCID. The UE 100B establishes a
receiving PDCP/RLC entity (step 2). Next, the UE 100A transmits
data. The UE 100B receives the data. The UE 100 B releases the
receiving PDCP/RLC entity. This operation is the operation of UE
implementation. The UE 100A releases the transmitting PDCP/RLC
entity (step 3).
[0162] Next, the in-coverage D2D communication (B) will be briefly
described. It should be noted that the description of the same
parts as in the out-of-coverage D2D communication (A) is omitted as
appropriate. As shown in FIG. 10, in in-coverage D2D communication
(B), the UE 100 A and the UE 100 B are located within the coverage
of the cell of the eNB 200.
[0163] Firstly, the eNB 200 transmits system information block (SIB
18) by broadcasting. The UE 100A and the UE 100B receive the system
information block.
[0164] Data is generated in the UE 100A. The UE 100A establishes a
transmitting PDCP/RLC entity (step 1). UE 100A transmits a random
access preamble (RA) or a scheduling request (SR) and sends buffer
status report (BSR) in D2D communication. The eNB 200 transmits SA
resource allocation and data transmission resource allocation to
the UE 100A based on the BSR. The UE 100A transmits the SA to the
UE 100 B based on the SA resource allocation. Note that the SA
indicates data transmission resource allocation received from the
eNB 200. The UE 100 B decodes the SA. Based on the decoded SA, the
UE 100B grasps a transmission resource (data transmission resource
allocation) used for data transmission. The subsequent operation is
the same as the out-of-coverage D2D communication (A).
[0165] As indicated in the PDCP and RLC related procedures in FIG.
10, a few open issues still need to be resolved, especially for
steps 1, 2 and 3. These issues are discussed in detail below.
[0166] (2.1) PDCP/RLC Configuration Mismatches
[0167] Regarding steps 1 and 2, when PDCP and RLC entities are
established, the configuration of PDCP/RLC related parameters has
not been decided yet. The parameters to be configured are described
in Table 1. Table 1 is parameters for PDCP and RLC
configurations.
TABLE-US-00001 TABLE 1 Parameters for PDCP Parameters for RLC
discardTimer (only for transmitting t-Reordering (only for
reception PDCP entity) RLC entity) maxCID SN-FieldLength
pdcp-SN-Size profiles
[0168] Since the discardTimer (for PDCP) is only meant to be used
by the transmitting entity and t-Reordering (for RLC) is only meant
to be used by the receiving entity, these values do not need to be
shared between transmitting and receiving entities (Tx and Rx
entities). However, the other parameters listed in Table 1 do need
to be shared between transmitting and receiving entities in order
for the PDUs to be processed correctly. According to the current
specification for cellular, these parameters are configured to UEs
100 via the RRC signalling, so the UEs 100 and eNB 200 share common
values. However, for D2D, it already agreed not to establish
receiving PDCP/RLC entity via RRC signalling. Instead receiving
PDCP/RLC is established according to the first received UMD PDU. In
particular, for the out-of-coverage scenario (FIG. 10 (A)), UEs 100
(D2D UEs) cannot receive the RRC signalling, so both transmitting
and receiving PDCP/RLC entities need to coordinate the values
through other means.
[0169] For the out-of-coverage scenario, the simplest way to
coordinate the values for PDCP/RLC configuration is to depend on
pre-configuration. If every parameter in Table 1 has only one
possible value then pre-configuration may be a viable solution. But
if more than one values for each parameter need to be supported, an
alternative solution may be needed as suggested below.
[0170] For the in-coverage scenario, especially for intra-cell
deployment scenario (FIG. 10(B)), both transmitting D2D UE (UE
100A) and receiving D2D UE (UE 100B) can receive the signal from
the serving cell. Therefore, UEs 100 (D2D UEs) can use SIB in order
to obtain the values for PDCP/RLC configuration. As for the
inter-cell deployment scenario, UE 100 (D2D UE) can also use SIB,
if serving cell's SIB includes neighbouring cell's PDCP/RLC
configuration as neighbouring cell's information. For the
out-of-coverage scenario, the solution will depend on whether every
parameter in Table 1 has more than one value.
[0171] For the partial coverage scenario, in order to align the
PDCP/RLC configuration of the in-coverage UE 100 and the
out-of-coverage UE 100, a transmitting UE 100 (Tx D2D UE) will need
to provide the values for PDCP/RLC configuration to the receiving
UE 100 (Rx D2D UE). [0172] Proposal 1: It should discuss whether
the transmitting UE 100 (the transmitting D2D UE) is allowed to
autonomously select the desired values for PDCP/RLC
configuration.
[0173] If the transmitting UE 100 is not allowed to select PDCP/RLC
configuration autonomously, one PDCP/RLC configuration needs to be
specified between transmitting and receiving PDCP/RLC entities. For
D2D Communication, both transmitting and receiving UEs can share
the receiving SA resource pool, therefore, one possibility is for
the same PDCP/RLC configuration to be shared per a SA reception
resource pool. This has the potential to be applicable for all D2D
scenarios, including Out-of-coverage, In-coverage and
Partial-coverage scenarios. [0174] Proposal 2: If transmitting UE
is not allowed to select PDCP/RLC configuration autonomously, one
PDCP/RLC configuration may be specified per SA reception resource
pool.
[0175] However, if the transmitting UE 100 (transmitting D2D UE) is
allowed to select the PDCP/RLC configuration autonomously, the
following alternatives should be considered as a means for the
transmitting UE 100 to share the configured values with the
receiving UE. [0176] ALT.1: Delivering via MAC sub-header [0177]
ALT.2: Delivering via SA [0178] ALT.3: Delivering via PD2DSCH
[0179] ALT.1 and ALT.2 can be applied to all scenarios; however,
ALT 3 can't be applied to UEs 100 unless the transmitting UE 100
(transmitting D2D UE) is also the synchronization source. In
particular, for in-coverage scenario, it is assumed that majority
of UEs 100 (D2D UEs) are not synchronization source, so ALT 3
should be precluded. [0180] Proposal 3: If transmitting UE 100
(transmitting D2D UE) could select PDCP/RLC configuration
autonomously, it should discuss which of the two alternatives
(ALT.1 or ALT.2) should be adopted for the delivery of the selected
PDCP/RLC configuration to the receiving UE 100.
[0181] (2.2) Release Timing of PDCP and RLC Entities
[0182] With respect to the issue of PDCP/RLC release timing (step 3
in FIG. 3), it currently assumes the PDCP entity and the RLC entity
must be established and released together; however, there is no
agreement on whether the transmitting and receiving entities should
be coordinated. The release timing of transmitting PDCP/RCL entity
has impact on successful reception of UMD PDU at the receiving RLC
entity. The impact on the release timing of the PDCP/RLC entities
is further discussed in detail below.
[0183] As shown in FIG. 8 above, if a transmitting RLC entity (ex.
source ID: A, destination ID: B, LCID: 0) is released earlier than
a receiving RLC entity (ex. source ID: A, destination ID: B, LCID:
0) and the transmitting RLC entity with the same configuration
(source ID: A, destination ID: B, LCID: 0) is established again
before the receiving RLC entity is released, the receiving RLC
entity will discard UMD PDUs for D2D Communication due to the
inconsistency between the transmitting RLC entity's SN (ex. SN=0)
and the receiving RLC entity's SN. (ex. VR(UH) &
VR(UR)=N+1)
[0184] The above issue will occur if the release timing of the
receiving RLC entity is up to UE implementation. In order to solve
the above issue, the following alternatives may be considered.
[0185] ALT. 1: Introduce a common timer between the transmitting
RLC entity and the receiving RLC entity
[0186] In order to prevent the receiving RLC entity from staying
active for a prolonged duration, unnecessarily, it is useful to
introduce an "in-activity timer" which indicates the maximum time
the RLC entity may stay active after receiving the last UMD
PDU.
[0187] If this timer is introduced, the release timing of the
transmitting RLC entity and the receiving RLC entity can be
properly coordinated and the discarding of the UMD PDUs at the
receiving RLC entity may be avoided.
[0188] For example, the transmitting RLC entity will not be
released while the in-activity timer is running. Alternatively, the
transmitting RLC entity may refrain from using the same LCID which
is previously used while the in-activity timer is running. The
detailed procedure is depicted in FIG. 11. FIG. 11 is a diagram
indicating example of in-activity timer related actions.
Explanation of portions similar to those in FIG. 10 will be
omitted.
[0189] In FIG. 11, the UE 100A starts a valid timer after sending
the data. Each time the UE 100A transmits data, the UE 100A
restarts the valid timer. On the other hand, the UE 100B
establishes the PDCP/RLC entity and starts a valid timer. Each time
the UE 100 B receives data, the UE 100 B restarts the active
timer.
[0190] The UE 100A releases the transmitting PDCP/RLC entity after
a duration A longer than the duration (activation time) of the
valid timer expires (step S3). That is, the UE 100A releases the
transmitting PDCP/RLC entity after expiration of the valid timer.
On the other hand, the UE 100B releases the reception PDCP/RLC
entity after a duration B longer than the duration of the valid
timer expires (step S2). That is, the UE 100B releases the
receiving PDCP/RLC entity before expiration of the valid timer.
[0191] ALT. 2: Setting the reordering window size to "zero"
[0192] This approach is the same for MBMS transmission. With D2D
Communication, re-transmission scheme is yet to be agreed,
therefore, "zero-size" re-ordering window might be useful based on
the current agreements for D2D Communication. However, the
repetition scheme for D2D Communication transmission is still under
discussing in RAN1, and such repetition scheme might cause
out-of-order delivery of UMD PDU from lower layer. The need for
this solution will largely depend on whether RAN1 can reach an
agreement for a repetition scheme at the next meeting.
[0193] Taking into account of the pros and cons of the above
alternatives, it is assumed the D2D UE should release the
transmitting RLC entity after the in-activity timer expiry (Alt 1).
Additionally, the receiving RLC entity should share such
in-activity timer with the corresponding transmitting RLC entity
and use it as the reference to prevent the occurrence of the UMD
PDU discarding. [0194] Proposal 4: transmitting RLC entity should
be released after the in-activity timer expiry to prevent the
occurrence of the UMD PDU discarding. [0195] Proposal 5: The
receiving RLC entity should share the in-activity timer with the
corresponding transmitting RLC entity and use it as the reference
to prevent the occurrence of the UMD PDU discarding.
[0196] (3) Conclusion
[0197] The potential mismatches of the transmitting and receiving
PDCP/RLC entities are addressed. The benefit of specifying an
inactivity timer used by both the transmitting and receiving RLC
entities to prevent unnecessary UMD PDU discarding is discussed. We
have the following proposals.
[0198] [Additional Statement 2]
[0199] A supplementary matter of the embodiment is provided
below.
[0200] (1) Set PDCP/RLC Parameter
[0201] (1.1) Problem
[0202] In cellular communication, PDCP and RLC entities used in a
data bearer are produced (established) when the UE 100 receives an
RRC signaling transmitted from a cell. The PDCP parameter and the
RLC parameter used when the PDCP and RLC entities are produced are
set by the RRC signaling.
[0203] On the other hand, in D2D communication, a method for
setting the PDCP parameter and the RLC parameter is not yet
defined. As described in the [Appendant 1] above, between a
receiving UE 100 (receiving D2D UE) and a transmitting UE 100
(transmitting D2D UE), it is necessary to use an identical
parameter value.
[0204] Therefore, an object is to provide a technique for setting a
PDCP parameter and an RLC parameter used for D2D communication,
below. It is noted that in order to set one of the parameters, that
is, the PDCP parameter and the RLC parameter, it may be naturally
possible to use the following method. The other of the parameters
may be set by using a method different from that used for the one
of the parameters.
[0205] (1.2) Solution
[0206] In a first method, RLC and PDCP setting for a D2D bearer is
defined for each SA (reception) resource pool.
[0207] The RLC and PDCP setting for a D2D bearer may be previously
stored by the UE 100 (D2D UE) (Pre-configured). The RLC and PDCP
setting for a D2D bearer may be notified, by broadcast, from the
eNB200 to the UE 100.
[0208] The transmitting UE 100 uses a setting corresponding to the
SA resource pool used for transmitting the SA (RLC and PDCP setting
for a D2D bearer) so as to establish the RLC and PDCP entities.
[0209] The receiving UE 100 uses a setting corresponding to the SA
resource pool used for reception of the SA transmitted from the
transmitting UE 100 so as to establish the RLC and PDCP
entities.
[0210] In the partial coverage, a UE 100 in a coverage and a UE 100
out of a coverage need to utilize the identical PDCP parameter and
RLC parameter. For this reason, the SA resource pool used in the
coverage and the SA resource pool used out of the coverage match at
least partially. (At least in the matching portion) the PDCP
parameter and the RLC parameter (that is, the RLC and PDCP setting
for a D2D bearer) are identical.
[0211] The serving cell may notify the UE 100 (D2D UE) located at a
cell edge to perform transmission in the SA resource pool (the
matching portion of the SA resource pool).
[0212] In a second method, the transmitting UE 100 includes the
PDCP and RLC setting into a MAC sub-header of the data, and
transmits the resultant data. The receiving UE 100 uses the setting
included in the received data (MAC PDU) so as to establish the PDCP
and RLC entities.
[0213] In a third method, the transmitting UE includes the PDCP and
RLC setting into the SA, and transmits the resultant SA. The
receiving UE 100 uses the setting included in the received SA so as
to establish the PDCP and RLC entities.
[0214] (2) Set PDCP Parameter
[0215] (2.1) [Problem]
[0216] If encryption (ciphering) and header compression (RoHC,
Header compression/de-compression) in a PDCP entity used in
cellular communication are utilized in D2D communication, then the
parameters in the PDCP entity between the transmitting UE 100 and
the receiving UE 100 do not match, and as a result, the receiving
UE 100 may fail to decrypt and/or decompress the PDCP PDC and
discard the PDCP PDU. A reason for this is that the parameter (HFN
(Hyper Frame Number), CID (Context Identifier)) are employed on the
assumption that the timings of generating a transmitting PDCP
entity and a receiving PDCP entity are identical.
[0217] (2.2) Solution
[0218] In the first method, the receiving UE 100 uses a fixed value
(that is, unchanged) value as a parameter to as to perform at least
one of the data decryption and the data decompression.
[0219] For example, a value fixed as an HFN (for example, 0) is
used. Accordingly, when the transmitting UE 100 has already
performed the D2D communication, even if the receiving UE 100
participates (starts reception) in the D2D communication at some
midpoint, deviation in the HFN does not occur. Accordingly, in the
processing of the PDCP PDU, the receiving UE 100 is capable of
restraining discarding of the PDU caused due to the deviation in
the HFN.
[0220] It is noted that the transmitting UE 100 is capable of
fixing a parameter used in at least one processing of the data
encryption and the data compression.
[0221] In the second method, in the D2D communication, RoHC using
the CID is not implemented. If the transmitting UE 100 omits the
unchanged header but applies the CID to the data instead thereof so
as to transmit the data (PDCP PDUs), then the receiving UE 100 that
participated in the D2D communication (started reception) at some
midpoint is not capable of knowing the CID. Therefore, as a result
of not performing the RoHC using the CID by (that is, the unchanged
header is not omitted), the receiving UE 100, which participated in
the D2D communication at some midpoint, is capable of decompressing
the data.
[0222] Therefore, in the second method, when header information
indicating a data follow is not changed in the transmitting PDCP
entity, under the assumption that a compression process is
performed in which the CID to designate the data flow, instead of
the header information, is applied to the data, if the transmitting
PDCP entity is an entity used for the D2D communication, then the
transmitting UE 100 cancels (does not execute) the compression
process.
[0223] It is noted that the transmitting UE 100 may designate the
data flow instead of the header information and execute a
compression process of applying, to the date, a predetermined
identifier associated with the SA resource pool used for the D2D
communication.
[0224] In the third method, in order to implement the first method
described above, a parameter (e.g., maxCID) having a smaller bit
number than the cellular communication is used for D2D
communication.
[0225] It is noted that the entire content of Japanese Patent
Application No. 2014-152429 (filed on Jul. 25, 2014) and U.S.
Provisional Application No. 62/035,088 (filed on Aug. 8, 2014) is
incorporated in the specification of the present application by
reference.
INDUSTRIAL APPLICABILITY
[0226] As described above, the user terminal and the mobile
communication system according to the embodiment, with which it is
possible to appropriately control D2D communication, are useful in
the mobile communication field.
* * * * *