Exhibit 1006.07
`
`ZTE Corporation and ZTE (USA) Inc.
`
`

`
`TS
`
`v3.0.0 (1999-04)
`
`Technical Specification
`
`3"’ Generation Partnership Project (3GPP);
`Technical Specification Group (TSG) RAN;
`Working Group 2 (WG2);
`
`Radio Interface Protocol Architecture
`
`-fi@
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1006.07—00001
`
`

`
`TS 25.301 V3.0.0 (1999-04)
`
`Reference
`
`<Workitem> (<ShortfI|ename>.PDF)
`
`Keywords
`Digital cellular telecommunications system,
`Universal Mobile Telecommunication System
`(UMTS), UTRA, IMT—2000
`
`3GPP
`
`Postal address
`
`Office address
`
`Internet
`
`secretariat@3gpp.org
`Individual copies ofthis deliverable
`can be downloaded from
`http://www.3gpp.org
`
`Copyright Notification
`
`No part may be reproduced except as authorized by written permission.
`The copyright and the foregoing restriction extend to reproduction in all media.
`
`r’ “)
`
`All rights reserved.
`
`

`
`Contents
`
`Intellectual Property Rights
`
`Foreword
`
`1. Scope
`
`2. References
`
`3. Definitions and Abbreviations
`
`3.1 Definitions
`
`3.2 Abbreviations
`
`4. Assumed UMTS Architecture
`
`5. Radio interface protocol architecture
`
`5.1 Overall protocol structure
`5.1.1 Service access points and service primitives
`
`5.2 Layer 1 Services and Functions
`5.2.1 Ll Services
`
`5.2.1.1 Transport channels
`522 L1 Functions
`
`5.3 Layer 2 Services and Functions
`5.3.1 MAC Services and Functions
`
`5311 MAC Services to upper layers
`5.3.1. 1.1 Logical channels
`5.3.l.l.l.l Control Channels
`5.3.1 .1 .1 .2 Traffic Channels
`
`5.3.1. 1.2 Mapping between logical channels and transport channels
`5.3.1.2 MAC functions
`5.3.2 RLC Services and Functions
`
`5321 Services provided to the upper layer
`5.3.2.2 RLC Functions
`
`5.3.3 Data flows through Layer 2
`5.3.3.1 Data flow for BCCH mapped to BCH (ffs)
`5.3.3.2 Data flow for PCCH mapped to PCH (ffs.)
`5.3 3.3 Data flow for SCCH mapped to SCH (ffs.)
`5.334 Data flow for CCCH mapped to FACH/RACH (ffs)
`5.3.3.5 Data flow for DCCH mapped to FACH/RACH
`5.3.3.6 Data flow for DCCH mapped to DSCH
`5.337 Data flow for DTCH (non-transparent RLC) mapped to FACH/RACH
`5.3.3.8 Data flow for DTCH (non-transparent RLC) mapped to DSCH
`5.3.3.9 Data flow for DTCH (transparent RLC) mapped to DCH
`53310 Data flow for DTCH (non-transparent RLC) mapped to DCH
`53311 Data flow for DCCH mapped to DCH
`
`5.4 Layer 3 — RRC Services and Functions
`54.] RRC services
`5411 General Control
`5.4.1.2 Notification
`5413 Dedicated Control
`5.4.2 RRC functions
`
`5.5 Interactions between RRC and lower layers in the C plane
`
`5.6 Protocol termination
`5.6.1 Protocol termination for DCH
`
`TS 25.301 V3.0.0 (1999-04)
`
`'JI
`
`:xo\o\o\I\I\lc\c\Un
`
`_.,_._.—i
`
`[\;,_,_.—i
`
`[\)_‘_-—-__«—-—_._-—-HO\oooooC:\UrU1.J>.u.>L..zuJUJ
`
`NN
`l\-)U.)
`[QU.)
`l\-)L»)
`l\3Lad
`
`l\3l\)l\JQJUJUJ
`l\)l\JUJUJ
`l\-)L»)
`
`[NJ13
`[\J-l>
`I043
`[Q-J>
`l\)-J3
`I\J U!
`
`I9 \I
`
`Nb-I\l\l
`
`

`
`56.2 Protocol termination for RACI-I/FACH
`5.6.3 Protocol termination for FAUSCH
`5.6.4 Protocol termination for DSCH
`5.6.4.1 DSCH definition
`5.6.4.2 Resource allocation and UE identification on DSCH
`
`56.4.2.1 Case A (UE requires a downlink TFCI on a DPCCH)
`5.6.4.2.2 Case B (UE requires a downlink DSCH Control Channel)
`5643 Model of DSCH in UTRAN
`5644 Protocol termination
`
`5.6.5 Protocol termination for transport channel of type BCH
`5.6.6 Protocol termination for transport channel of type PCH
`5.6.7 Protocol termination for transport channel of type SCH
`5.6.8 Protocol termination for ODCH
`5.6.9 Protocol termination for ORACH
`
`6. User Identification and RRC Connection Mobility
`
`6.1 UE identification within UTRAN
`
`6.2 UE connection to UTRAN
`
`7. UE modes
`
`8. Ciphering
`
`Appendices
`
`History
`
`TS 25.301 V3.0.0 (1999-04)
`
`28
`29
`30
`30
`30
`
`30
`30
`31
`31
`
`32
`32
`33
`33
`34
`
`35
`
`35
`
`36
`
`36
`
`37
`
`38
`
`41
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1006.07-00004
`
`

`
`TS 25.301 V3.0.0 (1999-04)
`
`Intellectual Property Rights
`
`lPRs essential or potentially essential to the present deliverable may have been declared to 3GPP and/or its
`organizational partners. The information pertaining to these essential IPRs, if any, is publicly available for 3GPP
`members and non-members, free of charge. This can be found in the latest version of the 3GPP Technical Report:
`
`Pursuant to the 3GPP Interim IPR Policy, no investigation, including IPR searches, has been carried out by 3GPP. No
`guarantee can be given as to the existence of other IPRS not referenced in the [tbd.], which are, or may be, or may
`become, essential to the present document.
`
`Foreword
`
`This Technical Specification has been produced by the 3GPP.
`The contents of the present document are subject to continuing work within the TSG and may change following formal
`TSG approval. Should the TSG modify the contents ofthis TS, it will be re-released by the TSG with an identifying
`change of release date and an increase in version number as follows:
`Version 3.y.z
`where:
`
`x the first digit:
`1
`presented to TSG for information;
`2 presented to TSG for approval;
`3
`Indicates TSG approved document under change control.
`the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
`updates, etc.
`the third digit is incremented when editorial only changes have been incorporated in the specification;
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1006.07-00005
`
`

`
`TS 25.301 V3.0.0 (1999-04)
`
`1. Scope
`The present document shall provide an overview and overall description of the UE-UTRAN radio interface protocol
`architecture as agreed within the 3GPP TSG RAN working group 2 Details of the radio protocols will be specified in
`companion documents.
`
`2. References
`
`The following documents contain provisions which, through reference in this text, constitute provisions of the present
`document.
`
`References are either specific (identified by date of publication, edition number, version number, etc.) or
`non-specific.
`For a specific reference, subsequent revisions do not apply.
`For a non-specific reference, the latest version applies.
`A non-specific reference to a TS shall also be taken to refer to later versions published as an EN with the same
`number.
`
`1] ETSI UMTS 23.10: “UMTS Access Stratum Services and Functions”
`2] 3GPP RAN S301 RAN Overall Description”
`3] ETSI UMTS 25.XX: “Vocabulary for the UTRAN”
`4] 3GPP RAN S202: “Services Provided by the Physical Layer”
`] 3GPP RAN S203: “UE Functions and Inter-Layer Procedures in Connected Mode”
`] 3GPP RAN S204: “UE Procedures in ldle Mode”
`] 3GPP RAN S2.21: “MAC Protocol Specification”
`] 3GPP RAN S222: “RLC Protocol Specification”
`9] 3GPP RAN S231: “RRC Protocol Specification”
`
`5 6 7 8
`
`[ [ [ [ [ [ [ [ [
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1006.07-00006
`
`

`
`TS 25.301 V3.0.0 (1999-04)
`
`3. Definitions and Abbreviations
`
`3.1 Definitions
`
`See [3] for a definition of fundamental concepts and vocabulary.
`
`3.2 Abbreviations
`
`ARQ
`BCCH
`BCH
`C-
`CC?
`CCCH
`CCHT
`CCTrCH
`CN
`(HC
`CTCH
`I)C
`DCA
`DCCH
`DCH
`DL
`DRNC
`DSCH
`DTCH
`FACH
`FAU SCH
`FCS
`FDD
`(}C
`llO
`ITU
`
`kbps
`L1
`L2
`L3
`LACI
`LAl
`DA/KC
`MM
`Nt
`
`Automatic Repeat Request
`Broadcast Control Channel
`Broadcast Channel
`Control-
`Call Control
`Common Control Channel
`Control Channel
`
`Coded Composite Transport Channel
`Core Network
`
`Cyclic Redundancy Check
`Common Traffic Channel
`
`Dedicated Control (SAP)
`Dynamic Channel Allocation
`Dedicated Control Channel
`Dedicated Channel
`Downlink
`Drift Radio Network Controller
`Downlink Shared Channel
`Dedicated Traffic Channel
`Forward Link Access Channel
`
`Fast Uplink Signalling Channel
`Frame Check Sequence
`Frequency Division Duplex
`General Control (SAP)
`Handover
`International Telecommunication Union
`
`kilo-bits per second
`Layer 1 (physical layer)
`Layer 2 (data link layer)
`Layer 3 (network layer)
`Link Access Control
`
`Location Area ldentity
`Medium Access Control
`
`Mobility Management
`Notification (SAP)
`ODMA Common Control Channel
`ODMA Dedicated Control Channel
`ODMA Dedicated Channel
`
`Opportunity Driven Multiple Access
`ODMA Random Access Channel
`ODMA Dedicated Traffic Channel
`
`Paging Control Channel
`Paging Channel
`Protocol Data Unit
`
`Payload Unit
`Physical layer
`Physical Channels
`Radio Access Bearer
`Random Access Channel
`Radio Link Control
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1006.07-00007
`
`

`
`TS 25.301 V3.0.0 (1999-04)
`
`Radio Network Controller
`
`Radio Network Subsystem
`Radio Network Temporaiy Identity
`Radio Resource Control
`Service Access Point
`
`Synchronization Control Channel
`Synchronization Channel
`Service Data Unit
`
`Serving Radio Network Controller
`Serving Radio Network Subsystem
`Traffic Channel
`
`Time Division Duplex
`Transport Format Combination Indicator
`Transport Format Indicator
`Temporary Mobile Subscriber Identity
`Transmit Power Control
`User-
`
`User Equipment
`User Equipment with ODMA relay operation enabled
`Uplink
`Universal Mobile Telecommunications System
`UTRAN Registration Area
`Uplink Shared Channel
`LIMTS Terrestrial Radio Access
`UMTS Terrestrial Radio Access Network
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1006.07-00008
`
`

`
`TS 25.301 V3.0.0 (1999-04)
`
`4. Assumed UMTS Architecture
`
`Figure l shows the assumed UMTS architecture as outlined in UMTS 23.10 . The figure shows the UMTS architecture
`in terms of its entities User Equipment (UE), UTRAN and Core Network. The respective reference points Uu
`(Radio Interface) and Iu (CN-UTRAN interface) are shown. The figure illustrates furthermore the high-level functional
`grouping into the Access Stratum and the Non-Access Stratum.
`
`The Access Stratum offers services through the following Service Access Points (SAP) to the Non-Access Stratum:
`
`I
`
`General Control (GC) SAPs,
`
`I Notification (Nt) SAPs and
`
`I
`
`Dedicated Control (DC) SAPs
`
`The SAPS are marked with circles in Figure l. The services provided to the non-access stratum by the GC, Nt, and DC
`SAPs, from a radio interface protocol perspective, are assumed to be provided by the Radio Resource Control (RRC) to
`the higher protocol layer. It is however assumed that at the network side, the RRC layer terminates in the UTRAN (cf.
`
`‘_0"-AccessStratum I
`
`-1
`Dc -
`-
`11
`
`_
`
`Core Network
`
`Figure 1: Assumed UMTS Architecture
`
`5. Radio interface protocol architecture
`
`5.1 Overall protocol structure
`The radio interface is layered into three protocol layers:
`
`I
`
`I
`
`I
`
`the physical layer (L1),
`
`the data link layer (L2),
`
`network layer (L3).
`
`Layer 2 is split into two sublayers, Radio Link Control (RLC) and Medium Access Control (MAC).
`
`Layer 3 and RLC are divided into Control (C-) and User (U-) planes.
`
`In the C-plane, Layer 3 is partitioned into sublayers where the lowest sublayer, denoted as Radio Resource Control
`(RRC), interfaces with layer 2. The higher layer signalling such as Mobility Management (MM) and Call Control (CC)
`are assumed to belong to the non-access stratum, and therefore not in the scope of 3GPP TSG RAN. On the general
`level, the protocol architecture is similar to the current ITU-R protocol architecture, ITU-R M. 1035.
`
`Figure 2 shows the radio interface protocol architecture. Each block in Figure 2 represents an instance of the respective
`protocol. Service Access Points (SAP) for peer-to-peer communication are marked with circles at the interface between
`sublayers. The SAP between MAC and the physical layer provides the transport channels (cf. Sec. 5.2.1.1). The SAPs
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1006.07-00009
`
`

`
`10
`
`TS 25.301 V3.0.0 (1999-04)
`
`between RLC and the MAC sublayer provide the logical channels (cf. Sec. 5.3.1.1. 1). In the C-plane, the interface
`between RRC and higher L3 sublayers (CC, MM) is defined by the General Control (GC), Notification (Nt) and
`Dedicated Control (DC) SAPs.
`
`inter-layer
`Also shown in the figure are connections between RRC and MAC as well as RRC and L1 providing local
`control services. An equivalent control interface exists between RRC and the RLC sublayer. These interfaces allow the
`RRC to control the configuration of the lower layers. For this purpose separate Control SAPS are defined between RRC
`and each lower layer (RLC, MAC, and L1). It is assumed that for RLC and MAC one Control SAP each is provided
`per UE.
`
`[Editor's note.‘ Control ofRLC entities in C and Uplanes needs to be clarifiedfiirther. Also, the multiplicity 0fControl
`SA PS (necessity ofone SAP per UE) at the UTRAN side may need to be reconsidered]
`
`The RLC sublayer provides ARQ functionality closely coupled with the radio transmission technique used. There is no
`difference between RLC instances in C and U planes.
`
`The UTRAN can be requested by the CN to prevent all loss of data (i.e. independently of the handovers on the radio
`interface), as long as the Iu connection point is not modified. This is a basic requirement to be fulfilled by the UTRAN
`retransmission functionality as provided by the RLC sublayer.
`
`However, in case of the lu connection point is changed (e.g. SRNS relocation, streamlining), the prevention of the loss
`of data may not be guaranteed autonomously by the UTRAN but would rely on some functions in the CN. In this case,
`a mechanism to achieve the requested QoS may require support from the CN. Such mechanisms to protect from data
`loss due to SRNS relocation or streamlining are for further study.
`
`[Editor's note: Such mechanisms need to be specifiedjointly with 3GPP TSGS CNanal SA. The impliedfiinctionality
`would be applied in the U plane. Applicability in the C plane isforfurlher study. /
`
`C-p]ane Signalling
`
`U-plane information
`
`............
`
`control
`
`
`
`LflRLC
`
`.......... Logical
`Channels
`
`..............................................Tmmmm
`Channels
`
`IJNWAC
`
`L1
`
`Figure 2: Radio Interface protocol architecture (Service Access Points marked by circles)
`
`3GPP
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1006.07—00010
`
`

`
`TS 25.301 V3.0.0 (1999-04)
`
`5.1.1 Service access points and service primitives
`Each layer provides services at Service Access Points (SAPs). A service is defined by a set of service primitives
`(operations) that a layer provides to upper layer(s).
`Control services, allowing the RRC layer to control lower layers locally (ie. not requiring peer-to-peer communication)
`are provided at Control SAPS (C-SAP). Note that C-SAP primitives can bypass one or more sublayers, see Figure 2.
`
`In the radio interface protocol specifications, the following naming conventions for primitives shall be applicable:
`
`I
`
`Primitives provided by SAPS between adjacent layers shall be prefixed with the name of the service-providing
`layer, i.e. PHY, MAC or RLC.
`
`Primitives provided by Control SAPs, in addition to the name ofthe service-providing layer, shall be prefixed with
`a “C”, i.e. CPHY, CMAC or CRLC.
`
`This principle leads to the following notations, where <Type> corresponds to request, indication, response or confirm
`type of primitives:
`
`Primitives between PHY and MAC:
`
`PHY- <Generic nam>e — <Type>
`
`Primitives between PHY and RRC (over C-SAP):
`CPHY- <Generic name> - <Type>
`
`Primitives between MAC and RLC:
`
`MAC- <Generic name> - <Type>
`
`Primitives between MAC and RRC (over C-SAP):
`CMAC- <Generic name> - <Type>
`
`Primitives between RLC and non-access stratum, and between RLC and RRC for data transfer:
`RLC- <Generic name> - <Type>
`
`Primitives between RLC and RRC for control of RLC (over C-SAP):
`CRLC- <Generic name> — <Type>
`
`5.2 Layer1 Services and Functions
`This section shall provide an overview on services and functions provided by the physical layer. A detailed description
`of Layer 1 general requirements can be found in 3GPP RAN S2.02 [4].
`
`5.2.1
`
`L1 Services
`
`The physical layer offers information transfer services to MAC and higher layers. The physical layer transport services
`are described by how and with what characteristics data are transferred over the radio interface. An adequate term for
`this is ‘Transport Channel’1.
`
`5.2.1.1 Transport channels
`A general classification of transport channels is into two groups:
`
`0
`
`0
`
`common transport channels (where there is a need for inband identification ofthe UEs when particular UEs are
`addressed) and
`
`dedicated transport channels (where the UEs are identified by the physical channel, i.e. code and frequency for FDD
`and code, time slot and frequency for TDD).
`
`Common transport channel types are (a more detailed description can be found in [4]):
`
`I Random Access Channel (RACH)
`A contention based uplink channel used for transmission of relatively small amount of data, eg. for initial access or
`non-realtime dedicated control or traffic data.
`
`1 This should be clearly separated from the classification of whatis transported, which relates to the concept of logical channels. Thus DCl-l is used to
`denote that the physical layer offers the same type of service for both control and traffic.
`
`3GPP
`
`

`
`TS 25.301 V3.0.0 (1999-04)
`
`I ODMA Random Access Channel (ORACH)
`A contention based channel used in relaylink.
`
`0 Forward Access Channel (FACH)
`Common downlink channel without closed-loop power control used for transmission of relatively small amount of
`data.
`
`Downlink Shared Channel (DSCH)
`A downlink channel shared by several UEs carrying dedicated control or traffic data.
`
`DSCH Control Channel
`
`A downlink channel associated with a DSCH used for signalling of DSCH resource allocation.
`
`/Ed/‘tor’ s note: It isforfurther study whether or not the DSCH Control Channel needs to be regarded as separate
`transport channel type from FACH. Seen from the upper layers, the current requirements are identical to a FA(
`but some extra Ll
`information (e. g. TPC bits) may lead to a different physical channel. See Sec. 5. 6.4 for a
`description of the DSCH concepts currently considered in I SG-RAN WG2. This section also includesfurlher notes
`on fls. items related to the DSCI-1.]
`
`I Uplink Shared Channel (USCH)
`An uplink channel shared by several UEs carrying dedicated control or traffic data, used in TDD mode only.
`
`I Broadcast Channel (BCH)
`A downlink channel used for broadcast of system information into an entire cell.
`
`0 Synchronization Channel (SCH)
`A downlink channel used for broadcast of synchronization information into an entire cell in TDD mode.
`
`Note that the SCH transport channel is defined for the TDD mode only. ln the FDD mode, a synchronization
`channel is defined as a physical channel. This channel however should not be confused with the SCH transport
`channel defined above.
`
`I Paging Channel (PCH)
`A downlink channel used for broadcast of control information into an entire cell allowing efficient UE sleep mode
`procedures. Currently identified information types are paging and notification. Another use could be UTRAN
`notification of change ofBCCH information.
`
`Dedicated transport channel types are:
`
`0 Dedicated Channel (DCH)
`A channel dedicated to one UE used in uplink or downlink.
`
`0 Fast Uplink Signalling Channel (FAUSCH)
`An uplink channel used to allocate dedicated channels in conjunction with FACH.
`
`I ODMA Dedicated Channel (ODCH)
`A channel dedicated to one UE used in relaylink.
`
`To each transport channel (except for the FAUSCH, since it only conveys a reservation request), there is an associated
`Transport Format (for transport channels with a fixed or slow changing rate) or an associated Transport Format Set (for
`transport channels with fast changing rate). A Transport Format is defined as a combination of encodings, interleaving,
`bit rate and mapping onto physical channels (see 3Gl’P RAN S202 [4] for details). A Transport Format Set is a set of
`Transport Formats. E. g., a variable rate DCH has a Transport Format Set (one Transport Format for each rate), whereas
`a fixed rate DCH has a single Transport Format.
`
`5.2.2 L1 Functions
`
`The physical layer performs the following main functions:
`
`I Macrodiversity distribution/combining and soft handover execution
`
`0
`
`0
`
`Error detection on transport channels and indication to higher layers
`
`FEC encoding/decoding and interleaving/deinterleaving of transport channels
`
`

`
`13
`
`TS 25.301 V3.0.0 (1999-04)
`
`Multiplexing of transport channels and demultiplexing of coded composite transport channels
`
`Rate matching
`
`Mapping of coded composite transport channels on physical channels
`
`Power weighting and combining ofphysical channels
`
`Modulation and spreading/demodulation and despreading of physical channels
`
`Frequency and time (chip, bit, slot, frame) synchronization
`
`Measurements and indication to higher layers (e. g. FER, SIR, interference power, transmit power, etc.)
`
`Closed-loop power control
`
`RF processing
`
`5.3 Layer 2 Services and Functions
`
`5.3.1 MAC Services and Functions
`
`This sections provides an overview on services and functions provided by the MAC sublayer. A detailed description of
`the MAC protocol is given in 3GI’P RAN S2,2l [7].
`
`5.3.1.1 MAC Services to upper layers
`0
`Data transfer. This service provides unacknowledged transfer of MAC SDUS between peer MAC entities. This
`service does not provide any data segmentation. Therefore, segmentation/reassembly function should be achieved
`by upper layer.
`Acknowledged data transfer service by MAC for transmission on RACH/FACH is ffs.
`
`0
`
`Re-allocation of radio resources and MAC parameters. This service performs on request of RRC execution of
`radio resource reallocation and change of MAC parameters, i.e. reconfiguration of MAC functions such as
`change of identity of UE, change of transport format (combination) sets, change of transport channel type. In TDD
`mode, in addition, resource allocation can be handled by the MAC autonomously.
`
`0 Reporting of measurements. Local measurements such as traffic volume, quality indication, MAC status
`indication, [other MAC measurements tbd.], are reported to RRC.
`
`The following potential services are regarded as further study items:
`
`I Allocation/deallocation of radio resources. Indication to RRC that allocation/deallocation of a MAC bearer is
`
`required. In TDD mode, resource allocation can alternatively be performed by the MAC autonomously.
`
`5.3.1.1.1 Logical channels
`The MAC layer provides data transfer services on logical channels. A set of logical channel types is defined for
`different kinds of data transfer services as offered by MAC. Each logical channel type is defined by what type of
`information is transferred.
`
`A general classification of logical channels is into two groups:
`
`0
`
`0
`
`Control Channels (for the transfer of control plane information)
`
`Traffic Channels (for the transfer of user plane information)
`
`The configuration of logical channel types is depicted in Figure 3.
`
`

`
`Control Channel (CCH) C Synchronisation Control Channel (SCCH)
`
`14
`
`TS 25.301 V3.0.0 (1999-04)
`
`Broadcast Control Channel (BCCH)
`
`Paging Control Channel (PCCH)
`
`T Dedicated Control Channel (DCCH)
`
`Common Control Channel (CCCH)
`
`T ODMA Dedicated Control Channel (ODCCH)
`
`T ODMA Common Control Channel (OCCCH)
`
`Traffic Channel (TCH)
`
`Dedicated Traffic Channel (DTCH)
`
`ODMA Dedicated Traffic Channel (ODTCH)
`
`mCommon Traffic Channel (CTCH)
`
`Figure 3: Logical channel structure
`
`5.3.1.1.1.1 Control Channels
`
`Control channels are used for transfer of control plane information only.
`
`Synchronisation Control Channel (SCCH)
`
`A downlink channel for broadcasting synchronisation information (information about the location and structure of the
`BCCH) in case of TDD operation.
`
`Broadcast Control Channel (BCCH)
`
`A downlink channel for broadcasting system control information. The BCCH may be further devided into two types,
`BCCH-Constant (BCCH-C) and BCCH-Variable (BCCH-V). BCCH-C would then transmit relatively many layer 3
`information elements, which do not change, exept for change of system information. BCCH-V would transmit layer 3
`information elements which change frequently and which a UE has to receive in short time (eg. downlink power level,
`uplink interference level, etc). The split of BCCH is ffs.
`
`Paging Control Channel (PCCH)
`
`A downlink channel that transfers paging information. This channel is used when the network does not know the
`location cell of the UE, or, the UE is in the cell connected state (utilizing UE sleep mode procedures).
`
`Common Control Channel (CCCH)
`
`Bi-directional channel for transmitting control information between network and UEs. This channel is commonly used
`by the UEs having no RRC connection with the network.
`
`Dedicated Control Channel (DCCH)
`
`A point-to-point bi-directional channel that transmits dedicated control information between a UE and the network.
`This channel is established through RRC connection setup procedure.
`
`ODMA Common Control Channel (OCCCH)
`
`Bi-directional channel for transmitting control information between UEs.
`
`ODMA Dedicated Control Channel (ODCCH)
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1006.07-00014
`
`

`
`15
`
`TS 25.301 V3.0.0 (1999-04)
`
`A point-to-point bi-directional channel that transmits dedicated control information between UEs. This channel is
`established through RRC connecti on setup procedure.
`
`5.3.1.1.1.2 Traffic Channels
`
`Traffic channels are used for the transfer ofuser plane information only.
`
`Dedicated Traffic Channel (DTCH)
`
`A Dedicated Traffic Channel (DTCH) is a point-to-point channel, dedicated to one UE, for the transfer ofuser
`information. A DTCH can exist in both uplink and downlink.
`
`ODMA Dedicated Traffic Channel (ODTCH)
`
`A ODMA Dedicated Traffic Channel (ODTCH) is a point-to-point channel, dedicated to one UE, for the transfer of
`user information between UE’s. A ODTCH exists in relaylink.
`
`Common Traffic Channel (CTCH)
`
`A point-to-multipoint unidirectional channel for transfer ofdedicated user information for all or a group of specified
`UEs.
`
`[Editor's note: This channel type is agreedfor Support ofShort ll/lessage Service-Cell Broadcast. Whether or not this
`logical channel shall also be employedfor support ofhigh-rate mulricast services is_fi’s.]
`
`5.3.1.1.2 Mapping between logical channels and transport channels
`The following connections between logical channels and transport channels exist:
`
`SCCH is connected to SCH
`
`BCCH is connected to BCH
`
`PCCH is connected to PCH
`
`CCCH is connected to RACH and FACH
`
`DTCH can be connected to either RACH and FACH, to RACH and DSCH, to DCH and DSCH,
`USCH (TDD only)
`
`to a DCH, or to
`
`CTCH can be connected to DSCH, FACH or BCH (ffs.)
`
`/Ed/‘lo/"s note: Above poieniial mappings are proposed by the editor. Yhis channel type will be included into (lie
`Figures below when the mappings have been agreed]
`
`DCCH can be connected to either RACH and FACH, to RACH and DSCH, to DCH and DSCH, to a DCH,
`FAUSCH, or to USCH (TDD only).
`
`to
`
`The mappings as seen from the UE and UTRAN sides are shown in Figure 4 and Figure 5 respectively. Figure 6
`illustrates the mapping from the UE in relay operation. Note that ODMA logical channels and transport channels are
`employed only in relaylink transmissions (ie. not used for uplink or downlink transmissions on the UE-UTRAN radio
`interface).
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1006.07-00015
`
`

`
`SCCH-
`SAP
`
`BCCH-
`SAP
`
`PCCH-
`SAP
`
` MAC SAPS
`
`TS 25.301 V3.0.0 (1999-04)
`
`SCH
`(TDD only)
`
`BCH
`
`PCH FAUSCH RACH FACH USCH DSCH DCH (Tjliffef
`(TDD only)
`
`Figure 4: Logical channels mapped onto transport channels, seen from the UE side
`
`SCCH-
`SAP
`
`BCCH-
`SAP
`
`PCCH-
`SAP
`
` E— MAC SAPs
`
`SCH
`(TDD Only)
`
`BCH
`
`PCH FAUSCH RACH
`
`T
`11
`FACH USCH DSCH DCH Cffiffgs
`(TDD only)
`
`Figure 5: Logical channels mapped onto transport channels, seen from the UTRAN side
`
`ODCCH-
`SAP
`
`OCCCH-
`SAP
`
`ODTCH-
`SAP
`
`:l MAC SAPs
`
`ORACH
`
`ODCH
`
`Ef]:}ff§’s‘
`
`Figure 6: Logical channels mapped onto transport channels, seen from the UE side (relay only)
`
`5.3.1.2 MAC functions
`The functions of MAC include:
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1006.07-00016
`
`

`
`17
`
`TS 25.301 V3.0.0 (1999-04)
`
`Mapping between logical channels and transport channels. The MAC is responsible for mapping of logical
`channel(s) onto the appropriate transport channel(s).
`
`Selection of appropriate Transport Format for each Transport Channel depending on instantaneous source
`rate. Given the Transport Format Combination Set assigned by RRC, MAC selects the appropriate transport
`format within an assigned transport format set for each active transport channel depending on source rate. The
`control of transport formats ensures efficient use oftransport channels.
`
`Priority handling between data flows of one UE. When selecting between the Transport Format Combinations in
`the given Transport Format Combination Set, priorities of the data flows to be mapped onto the corresponding
`Transport Channels can be taken into account. Priorities are e. g. given by attributes of radio access bearer services
`and RLC buffer status. The priority handling is achieved by selecting a Transport Format Combination for which
`high priority data is mapped onto Ll with a “high bit rate” Transport Format, at the same time letting lower priority
`data be mapped with a “low bit rate” (could be zero bit rate) Transpoit Format. Transpoit format selection may
`also take into account transmit power indication from Layer 1.
`
`Priority handling between UEs by means of dynamic scheduling. In order to utilize the spectrum resources
`efficiently for bursty transfer, a dynamic scheduling function may be applied. Priority handling on common and
`shared transport channels is realized by MAC. Note that for dedicated transport channels, the equivalent of the
`dynamic scheduling function is implicitly included as part of the reconfiguration function of the RRC sublayer.
`For TDD it is regarded as further study item.
`
`Note that in the TDD mode the data to be transported are represented in terms of sets of resource units.
`
`0
`
`Scheduling of broadcast, paging and notification messages. This function provides mechanisms for efficient
`transfer of broadcast, paging and notification messages by means of appropriate scheduling and repetition of the
`messages.
`
`Identification of UEs on common transport channels. When a particular UE is addressed on a common
`downlink channel, or when a UE is using the RACH, there is a need for inband identification of the UE. Since the
`MAC layer handles the access to, and multiplexing onto, the transport channels, the identification functionality is
`naturally also placed in MAC.
`
`Multiplexing/demultiplexing of higher layer PDUs into/from transport blocks delivered to/from the physical
`layer on common transport channels. MAC should support service multiplexing for common transport channels,
`since the physical layer does not support multiplexing ofthese channels.
`
`Multiplexing/demultiplexing of higher layer PDUs into/from transport block sets delivered to/from the
`physical layer on dedicated transport channels. The MAC allows service multiplexing for dedicated transport
`channels. This function can be utilized when several upper layer services (eg. RLC instances) can be mapped
`efficiently on the same transport channel. In this case the identification of multiplexing is contained in the MAC
`protocol control information.
`
`Traffic volume monitoring. Measurement oftraffic volume on logical channels and reporting to RRC. Based on
`the reported traffic volume information, RRC performs transport channel switching decisions.
`
`Routing of higher layer signalling. This function performs the mapping ofhigher layer signalling messages to the
`appropriate transport channel. This function is required in TDD mode, where resource allocation is performed by
`the MAC autonomously.
`
`Maintenance of a MAC signalling connection between peer MAC entities. This function supports
`unacknowledged transfer of MAC-internal messages between peer MAC entities. A MAC signalling connection is
`required in the TDD mode.
`
`Monitoring the links of the assigned resources. This function provides means for monitoring link quality in
`TDD mode (used by MAC for fast DCA).
`
`Dynamic Transport Channel type switching. Execution of the switching between common and dedicated
`transport channels based on a switching decision derived by RRC.
`
`The following potential functions are regarded as further study items:
`
`I
`
`Constrained execution of open loop power control algorithms. This function establishes layer 1 power levels
`within the constraints of open loop power control set by RRC.
`
`[Editor’s note: Details Qfthis_functi0n need to be c/ari'fied.]
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1006.07-00017
`
`

`
`18
`
`TS 25.301 V3.0.0 (1999-04)
`
`Processing of messages received at common control channels. This function is applied in TDD mode to support
`a data transfer on common control channels to support MAC operation (needed for fast DCA details are ffs.).
`
`Successive Transmission on RACH. When the mobile station continues to transmit the succeeding (second or
`more) radio frames because the message length is longer than a radio frame, the transmission timing offset, the
`RACH spreading code and signature shall be determined as follows: The transmission timing offset (frame and/or
`slot) shall be determined pseudo-randomly. The RACH spreading code and the signature of the succeeding radio
`frame can be determined pseudo-randomly. The same RNTI shall be used