This application claims priority to and the benefit of Korean Patent Application Nos. 10-2012-0075228 and 10-2013-0080591 filed in the Korean Intellectual Property Office on Jul. 10, 2012 and Jul. 9, 2013, respectively, the entire contents of which are incorporated herein by reference.
(a) Field of the Invention
The present invention relates to a signaling method for direct communication between terminals.
(b) Description of the Related Art
Direct communication refers to signal transmission and reception between terminals without mediation with a base station or control therebetween. As demand for direct communication between terminals is on the rise, a direct communication method within or outside an infrastructure communication region is required.
Standards for direct communication between terminals include IEEE Std. 802.16.1a. The IEEE Std. 802.16.1a is a standard that allows for direct communication between terminals as resources dedicated for direct communication are allocated in time and frequency domains in a frame structure of infrastructure communication between a base station and a terminal, and signals are exchanged between terminals through allocated radio resources.
To provide different QoS for each traffic stream in a radio resource region, flows are established at a MAC layer, and a MAC PDU (packet data unit) is constructed for each flow. In talk-around direct communication (TDC) according to IEEE Std. 802.16.1a, flow IDs (FIDs) are established in a unidirectional link establishment process, and the transmitting side configures the FIDs to not overlap. However, if the direction of unidirectional traffic is changed by a token handover procedure, the traffic source may be changed to a terminal with no FID. In this case, the transmitting terminal is not able to construct a MAC PDU for the terminal with no FID.
A multicast connection involves transmitting data to a plurality of user groups. A connection setup procedure is performed in the step of setting up an initial multicast connection, by which a multicast connection group is created. However, the existing IEEE Std. 802.16.1a does not provide for an operation scenario for a user (terminal) who leaves the multicast connection group. Also, this standard does not define a procedure of transmitting multicast connection setup information after the setup step, and therefore additional users who want to participate in the multicast connection group may not be able to participate in the multicast connection group.
The IEEE Std. 802.16.1a does not define a procedure of detecting the presence or absence of a receiving terminal within a communication distance when making a unidirectional unicast and multicast connection, or releasing a connection that fails to connect to a communication channel.
The present invention has been made in an effort to provide a signaling method which establishes an FID in order to support a token handover procedure in a unidirectional link.
In addition, the present invention has been made in an effort to provide a signaling method which dynamically maintains a multicast connection group.
Moreover, the present invention has been made in an effort to provide a signaling method which detects the presence or absence of a receiving terminal within a communication distance and releases a call connection if the receiving terminal is outside the communication distance.
The present invention has been made in a further effort to provide a signaling method which runs multiple dedicated channels in a link.
An exemplary embodiment of the present invention provides a signaling method for a first terminal to perform direct communication between terminals. The signaling method includes: transmitting a first link establishment request message for establishing a direct communication link to a second terminal; and receiving a link establishment response message for establishing a direct communication link from the second terminal, wherein the first link establishment response message includes a first field indicating a flow that the second terminal will use.
The first link establishment request message may further include a second field indicating “Flow Establishment Request for Token Handover”.
The first link establishment response message may further include a second field indicating “Flow Establishment Confirm for Token Handover”.
The first link establishment request message may be transmitted through an RTS (request to send) data part, and the first link establishment response message may be transmitted through a CTS (clear to send) data part.
The signaling method may further include: detecting the loss of the direct communication link; and upon detecting the loss of the direct communication link, releasing the direct communication link.
The detecting may include detecting that the loss of the direct communication link has occurred, if no signal is received on a subchannel, which is one of channels established between the first terminal and the second terminal, a predetermined number of times or more.
The releasing may include transmitting a link release command message for releasing the direct communication link to the second terminal.
The signaling method may further include, if the direct communication link is run on multiple dedicated channels, releasing at least one of the multiple dedicated channels.
The releasing of at least one dedicated channel may include: receiving a report on the states of the multiple dedicated channels from the second terminal, and selecting one to release from the multiple channels; and transmitting a resource change command message including a field for identifying the resources of the dedicated channel to release to the second terminal.
Another exemplary embodiment of the present invention provides a signaling method for a first terminal that performs direct communication between terminals. The signaling method may include: transmitting a token advertisement message for announcing a token to a plurality of second terminals; receiving a token request message from a third terminal wanting to have a token, among the plurality of second terminals; and transmitting a token response message responding to the token request message, wherein the token request message may include a first field indicating a flow that the third terminal will use.
The flow may be used when the third terminal makes a multicast connection.
The signaling method may further include transmitting a token handover message informing about a token handover to the plurality of second terminals.
Yet another exemplary embodiment of the present invention provides a signaling method for a first terminal to perform direct communication between terminals. The signaling method may include: transmitting a MAC header to the plurality of second terminals; transmitting a preamble to the plurality of second terminals; and repeatedly transmitting a link establishment command message for establishing a direct communication link to the plurality of second terminals through an RTS (request to send) data part.
The signaling method may further include: detecting the loss of the direct communication link; and upon detecting the loss of the direct communication link, releasing the direct communication link.
The detecting may include detecting that the loss of the direct communication link has occurred, if a signal transmitted on a subchannel, which is one of the channels established between the first terminal and the plurality of second terminals, has a lower value than a clear channel threshold.
A further exemplary embodiment of the present invention provides a signaling method for a relay terminal that relays direct communication between a first terminal and a second terminal. The signaling method may include: receiving a relay request message requesting relay information from the first terminal; and transmitting a relay response message responding to the relay request message to the first terminal, wherein the relay response message may include a field indicating a flow that the second terminal will use.
The signaling method may further include: transmitting the relay request message to the second terminal; and receiving the relay response message including the field from the second terminal.
The relay request message may include a field indicating “Flow Establishment Request for Token Handover”, and the relay response message may further include a field indicating “Flow Establishment Confirm for Token Handover”.
A further exemplary embodiment of the present invention provides a signaling method for a relay terminal that relays direct communication between a first terminal and a plurality of second terminals. The signaling method may include: receiving a token handover message for handing over a token from the first terminal; transmitting a token advertisement message for announcing a token to the plurality of second terminals; receiving a token request message from a third terminal wanting to have a token from the plurality of second terminals; and transmitting a token response message responding to the token request message to the third terminal, wherein the token request message may include a field indicating a flow that the third terminal will use.
The signaling method may further include transmitting a link establishment command message including the flow to the plurality of second terminals and the third terminal.
According to an exemplary embodiment of the present invention, a terminal having acquired a token can successfully generate a packet by establishing an additional FID in order to support a token handover procedure in a unidirectional link.
According to another exemplary embodiment of the present invention, it is possible to cope with dynamic changes in multicast by repeatedly setting up a multicast connection.
According to yet another exemplary embodiment of the present invention, a procedure for detecting the loss of a direct communication link and releasing the direct communication link can be provided.
According to a further exemplary embodiment of the present invention, a procedure for releasing a dedicated channel depending on the channel states if multiple dedicated channels are run for a direct communication link is provided.
In the following detailed description, only certain exemplary embodiments of the present invention have been shown and described, simply by way of illustration. As those skilled in the art would realize, the described embodiments may be modified in various different ways, all without departing from the spirit or scope of the present invention. Accordingly, the drawings and description are to be regarded as illustrative in nature and not restrictive. Like reference numerals designate like elements throughout the specification.
Throughout the specification, a mobile station (MS) may designate a terminal, a mobile terminal (MT), a mobile station (MS), an advanced mobile station (AMS), a high reliability mobile station (HR-MS), a subscriber station (SS), a portable subscriber station (PSS), an access terminal (AT), user equipment (UE), etc., and may include the entire or partial functions of the terminal, the MT, the MS, the AMS, the HR-MS, the SS, the PSS, the AT, the UE, etc.
A base station (BS) may designate an advanced base station (ABS), a high reliability base station (HR-BS), a nodeB, an evolved nodeB (eNodeB), an access point (AP), a radio access station (RAS), a base transceiver station (BTS), a mobile multihop relay (MMR)-BS, a relay station (RS) functioning as a base station, a high reliability relation station (HR-RS) functioning as a base station, etc., and may include the entire or partial functions of the ABS, the nodeB, the eNodeB, the AP, the RAS, the BTS, the MMR-BS, the RS, the HR-RS, etc.
Also, signaling for direct communication is a procedure for exchanging a MAC (medium access control) control message for direct communication, which may be used in combination with a signaling procedure or a MAC signaling procedure.
First of all, a frame structure for supporting a signaling method for direct communication according to an exemplary embodiment of the present invention will be described.
Referring to
In this specification, a portion of the uplink resource region is illustrated as a radio resource (direct mode zone) for direct communication, but the present invention is not limited thereto. A radio resource for direct communication may not be used in infrastructure communication between a base station and a terminal. Terminals participating in direct communication may perform direct communication by using a direct communication protocol and procedure through a radio resource for direct communication.
Meanwhile, a radio resource for direct communication may include a synchronization channel, a dedicated channel, and a supplementary channel. The synchronization channel may transfer a synchronization message including information for obtaining frequency or time synchronization between a transmission terminal and a reception terminal that want to perform direct communication therebetween. The dedicated channel may transfer a packet for direct communication between terminals. Here, the packet may include data and control information. The supplementary channel may transfer RTS (request to send) and CTS (clear to send) for reserving a dedicated channel, an ACK message indicating whether or not a packet has been successfully transferred, a control message with respect to a channel measurement value, a MAC control message for signaling, and the like. Radio resources for direct communication within a single superframe may be divided into a synchronization part and a data part. Here, the data part may include two slots, and the slots may be indicated as slot 1 and slot 2. Each slot may include a dedicated channel and a supplementary channel. Here, the dedicated channel and the supplementary channel are in a 1:1 relationship. For example, a supplementary channel of slot 1 may correspond to a dedicated channel of slot 2 of a previous superframe. A supplementary channel of slot 2 may correspond to a dedicated channel of slot 1 of the same superframe.
Hereinafter, a signaling method for establishing an FID (flow ID) to support a token handover procedure will be described. This signaling method will be explained with respect to unidirectional unicast connection, unidirectional multicast connection, unidirectional unicast connection and unicast relay connection, and unidirectional unicast connection and multicast relay connection, according to the configuration of a link.
First, a method for establishing an additional FID when making a unidirectional unicast connection will be described with reference to
Referring to
The receiving terminal negotiates about whether to use the function of supporting a token handover procedure or not, through the AAI-DC-LEST-REQ message. As shown in the underlined parts of the following Table 1, the transmitting terminal adds a “Flow Establishment Request for Token Handover” field to the AAI-DC-LEST-REQ message and transmits the message to the receiving terminal. If this field value is set to “Not Allowed”, the token handover procedure is not supported, whereas if this field value is set to “Request to establish flow for token handover”, the token handover procedure is supported.
Afterwards, the receiving terminal transmits an advanced air interface direct communication-link establishment-response (AAI-DC-LEST-RSP) message to the transmitting terminal (S320). In this case, as shown in the underlined parts of the following Table 2, the receiving terminal adds a “Flow Establishment Confirm for Token Handover” field to the AAI-DC-LEST-RSP message and transmits the message to the transmitting terminal. If this field value is set to “Not Allowed”, the token handover procedure is not supported, whereas, if this field value is set to “Confirm flow establishment for token handover”, the token handover procedure is supported. If the “Flow Establishment Request for Token Handover” field of the AAI-DC-LEST-REQ message transmitted by the transmitting terminal is set to “Request to establish flow for token handover”, and the “Confirm flow establishment for token handover” field of the AAI-DC-LEST-RSP message transmitted by the receiving terminal is set to “Flow Establishment Confirm for Token Handover”, the token handover procedure is finally determined.
Meanwhile, the receiving terminal establishes a flow that the receiving terminal will use, through the AAI-DC-LEST-RSP message. As shown in the underlined parts of the following Table 2, a field for establishing an additional flow (to be used by the receiving terminal) is added to the AAI-DC-LEST-RSP message transmitted by the receiving terminal. The additional flow is used to process traffic that the receiving terminal transmits later after acquiring a token.
Referring to
The transmitting terminal transmits a preamble to the receiving terminal (S410), and then transmits RTS and transmits an AAI-DC-LEST-REQ message through an RTS data part (S420).
Thereafter, the receiving terminal transmits a preamble (S430), transmits CTS, and then transmits an AAI-DC-LEST-RSP message through a CTS data part (S440).
Here, the AAI-DC-LEST-REQ message includes the “Flow Establishment Request for Token Handover” field, as explained in
Table 1 below describes the fields in the AAI-DC-LEST-REQ message, and Table 2 describes the fields in the AAI-DC-LEST-RSP message.
Flow
4
Indicates that the sending HR-MS
Shall always be
Establishment
requests the receiving HR-MS to
present
Request for Token
establish flows and send MAC PDUs
Handover
on the flows
0x0: Request to establish flow for
token handover
0x1: Not allowed
0x2 to 0xF: Reserved.
}
Flow
1
Zero indicates that the sending
Shall always be
Establishment
HR-MS of this message confirms
present
Confirm for Token
flow establishment.
Handover
0: Confirm flow establishment for
token handover
1: Not allowed
For (i=0;
N_Flow_Est is the number of flows
Present if
i<N_Flow_Est; i++)
on which the sender of this message
Confirmation
{
sends MAC PDUs.
Code == 0x0 and
Range [0 . . . 1]
Flow
Establishment
Confirm for
Token Handover ==
0x0
FID
4
Flow identifier assigned by the
Present if
source of packets on the flow
Confirmation
Code == 0x0 and
Flow
Establishment
Confirm for
Token Handover ==
0x0
Traffic Priority
3
0 to 7: Higher numbers indicate
Present if
higher priority
Confirmation
Default: 0
Code == 0x0 and
Flow
Establishment
Confirm for
Token Handover ==
0x0
CS Specification
8
0-15: Reserved
Present if
Parameters
16: Voice Codec G.729A
Confirmation
17: Voice Codec AMR
Code == 0x0 and
18-255: Reserved
Flow
Establishment
Confirm for
Token Handover ==
0x0
MAC Header Type
1
Indicates whether AGMH or SPMH
Present if
is presented at the start of MAC
Confirmation
PDUs of the service flow.
Code == 0x0 and
0: AGMH (Advanced Generic MAC
Flow
Header)
Establishment
1: SPMH (Short-Packet MAC
Confirm for
header)
Token Handover ==
default value is 0.
0x0
}
Next, a method for establishing an additional FID when making a unicast multicast connection will be described with reference to
The token handover procedure is a procedure for changing the direction of data transmission and reception while using an allocated radio resource as it is for unidirectional direct communication connection. A token refers to the authority to transmit a signal through the radio resource. A terminal having a token is eligible to transmit a signal. The token can be owned by a single terminal, and the remaining terminals receive a signal through a radio resource.
Referring to
A terminal wanting to have a token, among the plurality of receiving terminals, transmits an advanced air interface-direct communication-token-request (AAI-DC-TKN-REQ) message requesting a token to the transmission terminal (S520), and receives an advanced air interface-direct communication-token-response (AAI-DC-TKN-RSP) message from the transmitting terminal (S530). Here, the receiving terminal may use a different slot from the slot in which the AAI-DC-TKN-ADV message is transmitted. That is, the procedure for requesting a token may be performed as a unidirectional one-to-one procedure through a slot other than the slot 1 set for unidirectional one-to-many connection. To this end, the receiving terminal may transmit an AAI-DC-TKN-REQ message through an RTS data part and receive an AAI-DC-TKN-RSP message through a CTS data part.
Then, the transmitting terminal selects a receiving terminal to which the token is to be transferred, and announces token information to the plurality of receiving terminals through an advanced air interface-direct communication-token-handover (AAI-DC-TKN-HO) message informing about the token handover (S540), by which the token handover procedure is completed.
Afterwards, the terminal which has acquired the token (i.e., a terminal selected from among the plurality of receiving terminals) transmits an advanced air interface-direct communication-link establishment-command (AAI-DC-LEST-CMD) message to the plurality of receiving terminals through a dedicated channel, thereby performing the procedure of setting up a multicast connection. If this procedure is performed subsequent to a synchronization message, the terminal which has acquired the token transmits a Ded-CH preamble through the dedicated channel, and subsequently transmits the AAI-DC-LEST-CMD message to the plurality of receiving terminals. In this case, the AAI-DC-LEST-CMD message is an advertisement type, and transmitted together with an advanced air interface-direct communication-request to send (AAI-RTS) message (including DCGID) for performing channel occupancy. By this procedure of setting up a multicast connection, terminals having no multicast connection information (including terminals that have moved and have a new configuration) may participate in a multicast group. Meanwhile, a flow ID (FID) assigned by the terminal that has acquired the token is established in the AAI-DC-LEST-CMD message, and the terminal that has acquired the token makes a multicast connection to the receiving terminal by using the assigned FID.
Meanwhile, in the exemplary embodiment of the present invention, a receiving terminal wanting to acquire a token adds flow ID (FID) information to an AAI-DC-TKN-REQ message. That is, as shown in the underlined parts of Table 3, the AAI-DC-TKN-REQ message includes a field for establishing a flow that the receiving terminal wanting to acquire a token will add, and this added flow is used for the receiving terminal to process traffic after acquiring a token.
Table 3 below describes the fields in the AAI-DC-TKN-REQ message explained above, and the AAI-DC-TKN-RSP message includes fields indicating added flows, as shown in the underlined parts of Table 3.
For (i=0;
N_Flow_Est is the number of flows on which
i<N_Flow_Est; i++) {
the sender of this message sends MAC
PDUs.
Range [0 . . . 1]
FID
4
Flow identifier assigned by the source of
packets on the flow
Traffic Priority
3
0 to 7: Higher numbers indicate higher priority
Default: 0
CS Specification
8
0-15: Reserved
Parameters
16: Voice Codec G.729A
17: Voice Codec AMR
18-255: Reserved
MAC Header Type
1
Indicates whether AGMH or SPMH is
presented at the start of MAC PDUs of the
service flow.
0: AGMH (Advanced Generic MAC Header)
1: SPMH (Short-Packet MAC header)
default value is 0.
}
The receiving terminal that has acquired a new token (hereinafter referred to as “terminal having acquired a token”) sets up a unidirectional multicast connection to a new receiving terminal, which will be described in
Referring to
By doing so, the terminal having acquired the token can complete a new resource allocation procedure and a new link establishment procedure between the receiving terminals.
Next, a method for establishing an additional FID when making a unidirectional unicast connection and a unicast relay connection will be described with reference to
Referring to
Referring to
The receiving terminal transmits an advanced air interface-direct communication-relay-response (AAI-DC-RELAY-RSP) message to the relay terminal (S830), and the relay terminal transmits the AAI-DC-RELAY-RSP message to the transmitting terminal (S840).
By doing so, the relay information requesting and obtaining procedure is completed.
Referring to
Meanwhile, in the exemplary embodiment of the present invention, the AAI-DC-RELAY-REQ message explained in
Table 4 describes the fields in the AAI-DC-RELAY-REQ message, and Table 5 describes the fields in the AAI-DC-RELAY-RSP message.
Flow
4
Indicates that the sending HR-MS
Present if Target
Establishment
requests the receiving HR-MS to
DCTID exists
Request for Token
establish flows and send MAC PDUs
Handover
on the flows
0x0: Request to establish flow for
token handover
0x1: Not allowed
0x2 to 0xF: Reserved.
Flow
1
Zero indicates that the sending
Present if
Establishment
HR-MS of this message confirms
Confirmation
Confirm for Token
flow establishment.
Code == 0x0 and
Handover
0: Confirm flow establishment for
the sending
token handover
HR-MS of this
1: Not allowed
message
receives the
“Flow
Establishment
Confirm for
Token Handover”
field
For (i=0;
N_Flow_Est is the number of flows
Present if
i<N_Flow_Est; i++)
on which the sender of this message
Confirmation
{
sends MAC PDUs.
Code == 0x0 and
Range [0 . . . 1]
Flow
Establishment
Confirm for
Token Handover ==
0x0
FID
4
Flow identifier assigned by the
Present if
source of packets on the flow
Confirmation
Code == 0x0 and
Flow
Establishment
Confirm for
Token Handover ==
0x0
Traffic Priority
3
0 to 7: Higher numbers indicate
Present if
higher priority
Confirmation
Default: 0
Code == 0x0 and
Flow
Establishment
Confirm for
Token Handover ==
0x0
CS Specification
8
0-15: Reserved
Present if
Parameters
16: Voice Codec G.729A
Confirmation
17: Voice Codec AMR
Code == 0x0 and
18-255: Reserved
Flow
Establishment
Confirm for
Token Handover ==
0x0
MAC Header Type
1
Indicates whether AGMH or SPMH
Present if
is presented at the start of MAC
Confirmation
PDUs of the service flow.
Code == 0x0 and
0: AGMH (Advanced Generic MAC
Flow
Header)
Establishment
1: SPMH (Short-Packet MAC
Confirm for
header)
Token Handover ==
default value is 0.
0x0
}
Next, a method for establishing an additional FID when making a unidirectional unicast connection and a multicast relay connection will be described with reference to
Referring to
Referring to
Referring to
Thereafter, a receiving terminal wanting to have a token exchanges AAI-DC-TKN-REQ/RSP messages with the relay terminal (S1230 and S1240). That is, a receiving terminal wanting to have a token transmits an AAI-DC-TKN-REQ message to the relay terminal (S1230), and receives an AAI-DC-TKN-RSP message responding to this message from the relay terminal (S1240). Meanwhile, upon receiving the AAI-DC-TKN-REQ message from the receiving terminal (wanting to have the token), when the relay terminal determines to hand over the token, the relay terminal transmits a AAI-DC-TKN-HO message informing about the token handover to the plurality of receiving terminals (S1250), thus completing the token management procedure. Thereafter, a terminal which has received the token transmits data to the relay terminal, and the relay terminal transmits the data to the other terminals. In this case, the relay terminal multicasts an AAI-DC-LEST-CMD message to set up a new multicast connection (S1260).
Meanwhile, in the exemplary embodiment of the present invention, a receiving terminal wanting to acquire a token adds flow ID (FID) information to an AAI-DC-TKN-REQ message. That is, the AAI-DC-TKN-REQ message includes a field for establishing a flow that the receiving terminal wanting to acquire a token will add, and this added flow is used for the receiving terminal to process traffic after acquiring a token. The AAI-DC-TKN-REQ message as above is identical to that of Table 3.
As seen from the above token change, whenever objects change in a multicast relay connection, the relay terminal sets up a multicast relay connection. In this procedure, a multicast connection is set up without changing relay terminals.
Referring to
By doing so, the relay terminal can complete a new resource allocation procedure and a new link establishment procedure between the plurality of receiving terminals.
Next, a signaling method for dynamically maintaining a multicast connection group will be described. Although a communication group belonging to a multicast connection is dynamically variable, the dynamic characteristics of the communication group may not be supported because multicast connection information is transmitted only when setting up a multicast connection. To make up for it, in the exemplary embodiment of the present invention, the dynamic variability of a multicast communication group is supported by repeatedly performing a multicast connection procedure.
As shown in
Meanwhile, as shown in
Next, a signaling method for detecting the presence or absence of a receiving terminal within a communication distance and releasing a call connection if the receiving terminal is outside the communication distance will be described with reference to
During the transmission of traffic between a transmitting terminal and a receiving terminal, if there is no signal transmitted on a subchannel in a unidirectional unicast connection, the transmitting terminal detects that a link loss has occurred (S1510). In this case, the transmitting terminal detects that a link loss has occurred if no response is made on the subchannel a predetermined number of times or more. If no response is made on the subchannel, this may indicate that an unallocated subchannel code has been received, or a subchannel signal has a lower value than a clear channel threshold.
Upon detecting a link loss, the transmitting terminal transmits an advanced air interface-direct communication-link release-command (AAI-DC-LREL-CMD) message to the receiving terminal (S1520). Then, the transmitting terminal receives acknowledgement (ACK) from the receiving terminal, and releases the link. The Link Release Command Code field in the AAI-DC-LREL-CMD message may be set to link loss (0x01).
If no signal response is made on the subchannel in a unidirectional multicast connection, as well as in the unidirectional unicast connection of
Finally, a signaling method for running multiple dedicated channels in a link will be described with reference to
First of all, it is assumed that multiple dedicated channels are run for a unidirectional direction communication link between a transmitting terminal and a receiving terminal.
The transmitting terminal receives a report on the channel states transmitted from the receiving terminal (S1610), and selects a dedicated channel to release from the multiple dedicated channels (S1620). Upon selecting a dedicated channel to release from the multiple dedicated channels, the transmitting terminal transmits, to the receiving terminal, an advanced air interface-direct communication-resource change-command (AAI-DC-RCHG-CMD) message including a field for identifying the resources of the dedicated channel to release (S1630). As shown in the underlined parts of Table 6 below, the AAI-DC-RCHG-CMD message includes a field for identifying the resources of a dedicated channel to release.
Although
Table 6 below describes the fields in the AAI-DC-RCHG-CMD message.
For (i=0;
N_DCH_Rel is the number of DCHs
i<N_DCH_Rel; i++)
which are released from TDC
{
communication
Direct Mode Zone
2
Direct mode zone type for release
Type
0x0: Common direct mode zone
(CAAI-DCZ)
0x1: Common direct mode zone
extended (CAAI-DCZ-E)
0x2: Cell specific direct mode zone
(CSAAI-DCZ)
0x3: Reserved.
DCH Number
4
Indicates DCH number for release
}
First of all, it is assumed that multiple dedicated channels are run for a bidirectional direct communication link between a transmitting terminal and a receiving terminal.
The transmitting terminal receives a report on the channel states transmitted from the receiving terminal (S1710), and selects a dedicated channel to release from the multiple dedicated channels (S1720). Upon selecting a dedicated channel to release from the multiple dedicated channels, the transmitting terminal transmits, to the receiving terminal through slot 1, an advanced air interface-direct communication-resource change-request (AAI-DC-RCHG-REQ) message including a field for identifying the resources of the dedicated channel to release (S1730). As shown in the underlined parts of Table 7 below, the AAI-DC-RCHG-REQ message includes the field for identifying the resources of the dedicated channel to release.
Table 7 describes the fields in the AAI-DC-RCHG-REQ message.
For (i=0;
N_DCH_Rel is the number of DCHs
i<N_DCH_Rel; i++) {
which are released from TDC
communication
Direct Mode Zone
2
Direct mode zone type for release
Type
0x0: Common direct mode zone
(CAAI-DCZ)
0x1: Common direct mode zone extended
(CAAI-DCZ-E)
0x2: Cell specific direct mode zone
(CSAAI-DCZ)
0x3: Reserved.
DCH Number
4
Indicates DCH number for release
}
On the other hand, the receiving terminal, instead of the transmitting terminal, may select a dedicated channel to release, and may request the transmitting terminal to release the dedicated channel.
As shown in
Table 8 describes the fields in the AAI-DC-RCHG-RSP message.
For (i=0;
N_DCH_Rel is the number of DCHs
i<N_DCH_Rel;
which are released from TDC
i++) {
communication
Direct Mode Zone
2
Direct mode zone type for release
Type
0x0: Common direct mode zone
(CAAI-DCZ)
0x1: Common direct mode zone
extended (CAAI-DCZ-E)
0x2: Cell specific direct mode zone
(CSAAI-DCZ)
0x3: Reserved.
DCH Number
4
Indicates DCH number for release
}
While this invention has been described in connection with what is presently considered to be practical exemplary embodiments, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.
Number | Date | Country | Kind |
---|---|---|---|
10-2012-0075228 | Jul 2012 | KR | national |
10-2013-0080591 | Jul 2013 | KR | national |