5.6 Protocol termination
25.3013GPPRadio interface protocol architectureTS
This subclause specifies in which node of the UTRAN the radio interface protocols are terminated, i.e. where within UTRAN the respective protocol services are accessible. Dashed lines indicate those protocols whose presence is dependent on the service provided to upper layers.
5.6.1 Protocol termination for DCH
Figure 11 and Figure 12 show the protocol termination for DCH for the control and user planes, respectively. The part of physical layer terminating in the Serving RNC is the topmost macro-diversity combining and splitting function for the FDD mode. If no macrodiversity applies, the physical layer is terminated in Node B.
Figure 11: Protocol Termination for DCH, control plane
Figure 12: Protocol Termination for DCH, user plane
5.6.2 Protocol termination for RACH/FACH
Figure 13 and Figure 14 show the protocol termination for RACH/FACH for the control and user planes, respectively. Control plane termination refers to the case where RACH/FACH carry dedicated, common or shared control information (i.e. CCCH, DCCH or SHCCH, and in the downlink possibly also BCCH). User plane termination refers to the case where RACH/FACH carry dedicated user data (DTCH) or common user data (CTCH).
It is assumed that macrodiversity/soft handover is not applied for RACH/FACH. Therefore, the physical layer terminates in Node B. For RACH/FACH carrying DCCH, MAC is split between Controlling and Serving RNC. RLC, and in the C plane also RRC terminate in the Serving RNC. Since Iur can support common channel data streams, the users of that common channel can depend on different SRNCs. However, they depend on the same Controlling RNC. Therefore, for a given user, the Controlling RNC and the Serving RNC can be separate RNCs.
For FACH carrying BCCH, MAC, RLC and RRC are terminated in the CRNC.
For RACH/FACH carrying SHCCH, MAC, RLC and RRC are terminated in the Controlling RNC (TDD only).
For RACH/FACH carrying CCCH, MAC, RLC and RRC are terminated in the RNC.
Figure 13: Protocol Termination for RACH/FACH, control plane
Figure 14: Protocol Termination for RACH/FACH, user plane
5.6.3 Void
5.6.4 Void
5.6.5 Protocol termination for DSCH
5.6.5.1 DSCH definition
The DSCH is only supported for TDD. The DSCH is a resource that exists in downlink only. It has only impact on the physical and transport channel levels, so there is no definition of shared channel in the logical channels provided by MAC.
The DSCH is a transport channel shared dynamically between several UEs. The DSCH is mapped to one or several physical channels such that a specified part of the downlink resources is employed. For the DSCH no macrodiversity is applied, i.e. a specific DSCH is transmitted in a single cell only.
The DSCH is defined as a shared downlink channel for which resource allocation is performed by RRC in Controlling RNC. The allocation messages, including UE identification, are transmitted on SHCCH, which is mapped on RACH/FACH. Several DSCH can be multiplexed on a CCTrCH in the physical layer, the transport formats of the DSCHs have to be selected from the transport format combination set of this CCTrCH. Each CCTrCH is mapped on one or more PDSCHs. If the transport format combination subset of a CCTrCH contains more than one transport format combination, a TFCI can be transmitted inside the PDSCH, or blind detection can be applied in the UE.
Interleaving for the DSCH may be applied over a multiplicity of radio frames. Nevertheless, here the basic case is considered where the interleaving is rectangular for a given MAC PDU, and equal to one radio frame (10 ms). The framing is synchronised on the SCH.
In every radio frame, one or several PDSCHs can be used in the downlink. Therefore, the DSCH supports code multiplexing. MAC multiplexing of different UEs shall not be applied within a radio frame, i.e. within one radio frame a PDSCH is assigned to a single UE. However, MAC multiplexing is allowed on a frame by frame basis, i.e. one PDSCH may be allocated to different UEs at each frame.
Transport blocks on the DSCH may be of constant size, so that the Transport Block Set may be derived from the code allocated to each UE on the DSCH. For case B, the transport format combination set can change with each transmission time interval.
5.6.5.2 Resource allocation and UE identification on DSCH
The principles of capacity allocation and UE identification on the DSCH are described in more detail below.
5.6.5.2.1 Void
5.6.5.2.2 UE requires a downlink SHCCH
The information which physical downlink shared channels to listen to and when, is sent by RRC on the SHCCH logical channel, which is mapped on RACH and USCH/FACH and DSCH. The transmitted Layer 3 messages contain information about the used PDSCHs and the timing of the allocation.
5.6.5.3 Model of DSCH in UTRAN
Figure 15 captures the working assumption on the Downlink Shared Channel (DSCH). The two RLCs point to logical channel (DTCH) specific RLC-entities of specific users while MAC refers to the provision of MAC sublayer functions for all users.
The MAC sublayer of a DSCH is split between the Controlling RNC and SRNC. For a given user, the RLC sublayer is terminated in its SRNC. Since Iur can support DSCH data streams, the users on that DSCH can depend on different SRNCs. For a given user, the Controlling RNC and the Serving RNC can be separate RNCs. The MAC in the network takes care of mapping downlink data either to a common channel (FACH, not shown in this figure), or to a DCH and/or the DSCH.
Figure 15: Model of downlink shared channel (DSCH) in UTRAN (TDD only)
5.6.5.4 Protocol termination
The protocol termination points for DSCH in control and user planes are presented in Figure 16 and Figure 17, respectively. The DSCH is for TDD only.
Figure 16: Protocol termination points for DSCH, control plane (TDD only)
Figure 17: Protocol termination points for DSCH, user plane (TDD only)
5.6.6 Protocol termination for transport channel of type USCH
5.6.6.1 USCH definition
The USCH is only supported for TDD. It is a resource that exists in uplink only. It has only impact on the physical and transport channel levels, so there is no definition of shared channel in the logical channels provided by MAC.
The USCH is a transport channel shared dynamically between several UEs. The USCH is mapped to one or several physical channels such that a specified part of the uplink resources is employed.
The USCH is defined as a shared uplink channel for which resource allocation is performed by RRC in Controlling RNC. The allocation requests and allocation messages, including UE identification, are transmitted on SHCCH, which is mapped on RACH and USCH/FACH and DSCH. Several USCHs can be multiplexed on a CCTrCH in the physical layer, the transport formats of the USCHs have to be selected from the transport format combination set of this CCTrCH. Each CCTrCH is mapped on one or more PUSCHs. If the transport format combination subset of a CCTrCH contains more than one transport format combination, a TFCI can be transmitted inside the PUSCH, or blind detection can be applied in the Node B.
Interleaving for the USCH may be applied over a multiplicity of radio frames.
In every radio frame, one or several PUSCHs can be used in the uplink. Therefore, the USCH supports physical channel multiplexing. MAC multiplexing of different UEs shall not be applied within a radio frame, i.e. within one radio frame a PUSCH is assigned to a single UE. However, MAC multiplexing is allowed on a frame by frame basis, i.e. one PUSCH may be allocated to different UEs at each frame.
The transport format combination set on the USCH can change with each transmission time interval.
5.6.6.2 Resource allocation and UE identification on USCH
The information which physical uplink shared channels to transmit on and when is sent by RRC on the SHCCH logical channel, which is mapped on RACH and USCH/FACH and DSCH. The transmitted Layer 3 messages contain information about the assigned PUSCHs and the timing of the allocation.
5.6.6.3 Model of USCH in UTRAN
Figure 18 captures the working assumption on the Uplink Shared Channel (USCH). The two RLCs point to logical channel (DTCH) specific RLC-entities of specific users while MAC refers to the provision of MAC sublayer functions for all users.
The MAC sublayer of a USCH is split between the Controlling RNC and SRNC. For a given user, the RLC sublayer is terminated in its SRNC. Since Iur can support USCH data streams, the users on that USCH can depend on different SRNCs. For a given user, the Controlling RNC and the Serving RNC can be separate RNCs. The MAC in the network takes care of mapping uplink data either from a common channel (RACH, not shown in this figure), DCH or the USCH.
Allocations of uplink capacity are requested by the UEs and signalled to the UEs on the SHCCH (Shared channel control channel), which is mapped on RACH and USCH/FACH and DSCH.
Figure 18: Model of uplink shared channel (USCH) in UTRAN (TDD only)
5.6.6.4 Protocol termination
The protocol termination points for USCH in control and user planes are presented in Figure 19 and Figure 20, respectively. The USCH is for TDD only.
Figure 19: Protocol termination points for USCH, control plane (TDD only)
Figure 20: Protocol termination points for USCH, user plane (TDD only)
5.6.7 Protocol termination for transport channel of type BCH
System information on BCH can include information that is available only in Node B, and need to be updated very frequently (each 20-100 ms), such as uplink interference in the cell. Also, for the system information originating from the RNC, it is assumed that the updating of system information is at least one magnitude less (minutes) than the repetition frequency on the BCH (in the order of 1s). The system information originating from the CRNC should be sent transparently to Node B, which then handles the repetition. Protocol termination for the BCH shall therefore be distributed between the Node B and the CRNC, resulting in less signalling on Iub and lower processor load. Note that the RLC sublayer is transparent for this transport channel type.
Figure 21: Protocol termination for BCH
5.6.8 Protocol termination for transport channel of type PCH
In order to enable co-ordinated scheduling between PCH and FACH/DSCH the corresponding MAC scheduling functions shall be allocated in the same node. MAC-c/sh is terminated in CRNC. A natural implication is that RLC and RRC also are terminated in CRNC.
Note that the RLC sublayer is transparent for this channel.
Figure 22: Protocol termination for PCH
5.6.9 Protocol termination for HS-DSCH
5.6.9.1 HS-DSCH definition
The HS-DSCH is a resource that exists in downlink only. It has only impact on the physical and transport channel levels, so there is no definition of shared channel in the logical channels provided by MAC.
The HS-DSCH is a transport channel for which a common pool of radio resources is shared dynamically between several UEs. The HS-DSCH is mapped to one or several physical channels such that a specified part of the downlink resources is employed. For the HS-DSCH no macrodiversity is applied, i.e. a specific HS-DSCH is transmitted in a single cell only.
– In CELL_DCH state the HS-DSCH is defined as an extension to DCH transmission. Physical channel signalling is used for indicating to a UE when it has been scheduled and then the necessary signalling information for the UE to decode the HS-PDSCH.
– In FDD and 1.28 Mcps TDD mode, the HS-DSCH can be used to transmit both dedicated control plane and user plane data to the UE in CELL_FACH, CELL_PCH and URA_PCH state.
In every HS-DSCH TTI, one or several HS-PDSCHs can be used in the downlink. Therefore, the HS-DSCH supports code multiplexing. MAC multiplexing of different UEs shall not be applied within an HS-DSCH TTI, i.e. within one HS-DSCH TTI an HS-PDSCH is assigned to a single UE. However, MAC multiplexing is allowed on a TTI by TTI basis, i.e. one HS-PDSCH may be allocated to different UEs at each TTI.
5.6.9.2 Resource allocation and UE identification on HS-DSCH
For each HS-DSCH TTI, each HS-SCCH carries HS-DSCH related downlink signalling for one UE, along with a UE identity (via a UE specific CRC) that identifies the UE for which this information is necessary in order to decode the scheduled HS-PDSCH.
5.6.9.3 Protocol termination
The protocol termination points for HS-DSCH in the control (DCCH) and user planes (DTCH) are presented in figure 5.6.9.3-1 and figure 5.6.9.3-2, respectively. In FDD and 1.28 Mcps TDD, the protocol termination presented in figure 5.6.9.3-1 applies for BCCH and PCCH in CELL_FACH, CELL_PCH or URA_PCH state. Two configurations exist, a Configuration with MAC-c/sh and a Configuration without MAC-c/sh.
– Configuration with MAC-c/sh: In this case, the MAC-hs/MAC-ehs in Node B is located below MAC-c/sh in CRNC.
– Configuration without MAC-c/sh: In this case, the CRNC does not have any function for the HS-DSCH. MAC-d in SRNC is located directly above MAC-hs/MAC-ehs in Node B, i.e. in the HS-DSCH the SRNC is directly connected to the Node B, thus bypassing the DRNC.
Both configurations are transparent to both the UE and Node B. Figures 5.6.9.3-2 and 5.6.9.3-3 show the respective user plane protocol architecture with termination points for the above two configurations.
Figure 5.6.9.3-1: Protocol termination points for HS-DSCH, control plane
Figure 5.6.9.3-2: Protocol termination points for HS-DSCH, user plane
5.6.10 Protocol termination for E-DCH
5.6.10.1 E-DCH definition
The E-DCH is a resource that exists in uplink only. It has only impact on the physical and transport channel levels, it is not visible in the logical channels provided by MAC.
The E-DCH is a transport channel that is subject to Node-B scheduling. The E-DCH is defined as an extension to DCH transmission.
5.6.10.2 Resource allocation and UE identification related to E-DCH
Physical channel signalling from the Node-B is used for indicating to the UE what amount of uplink resources it is allowed to use. Also the UE sends scheduling requests to the Node-B about the resource needs.
Scheduling information is sent on a common physical channel and a UE identity is used to address the different UEs.
5.6.10.3 Protocol termination
The protocol termination points for E-DCH in the control and user planes are presented in figure 5.6.10.3-1 and figure 5.6.10.3-2, respectively.
Figure 5.6.10.3-1: Protocol termination points for E-DCH for DCCH, control plane
Figure 5.6.10.3-2: Protocol termination points for E-DCH, user plane
Figure 5.6.10.3-3: Protocol termination points for E-DCH for CCCH, control plane
5.6.11 Protocol termination for MBMS
5.6.11.1 MBMS definition
The MBMS feature is downlink unidirectional.
MBMS services can be provided in point-to-point and point-to-multipoint. For the point-to-multipoint there exist three logical channels specifically for MBMS: MCCH, MSCH and MTCH.
5.6.11.2 Resource allocation related to MBMS
The radio bearer allocation for the MCCH is indicated in system information on the BCCH. The radio bearer allocations for MSCH and MTCH are indicated on MCCH.
5.6.11.3 Protocol termination
The protocol termination points for MCCH and MSCH in the control plane and MTCH in the user plane are presented in figure 5.6.11.3-1 and figure 5.6.11.3-2, respectively.
Figure 5.6.11.3-1: Protocol termination points for MCCH and MSCH, control plane
Figure 5.6.11.3-2: Protocol termination points for MTCH, user plane
Figure 5.6.11.3-3 illustrates the protocol termination for MTCH in MBMS, which is used in p-t-m transmission in case of IP Multicast distribution.
Based on the configuration in BM-SC the PDCP sub-layer may perform header compression/decompression for the MBMS traffic.
The PDCP sub-layer may operate with the RFC 3095 header compression protocol. In that case, header compression should be performed under RFC 3095 U-mode.
Figure 5.6.11.3-3: Protocol Stack for MTCH (P-T-M) in case of IP multicast distribution
In case MRNC is used, figure 5.6.11.3-4 illustrates the protocol termination for MCCH in MBMS, which is MBMS p-t-m control channel.
MBSFN MCCH Information Control function is split between MRNC and CRNC. The MRNC controls the logical resources of the RNSs that are used for MBSFN operation within the MBSFN cluster(s). The MRNC informs the CRNC of the MCCH configuration (using transfer of MCCH Information Control messages) and schedule information to be used (included in RNSAP as defined in [20]) .The CRNC performs the MCCH configuration and sends the MCCH information accordingly.
Figure 5.6.11.3-4: Protocol Stack for MCCH