Release 8
`
`89
`
`3C-SPF TS 36.300 VB.4.0 (2008-03}
`
`
`
`RRC: HANDOVER COMMAND
`
`S1-AP: HANDOVER COMMAND
`
`
`S1-AP: HANDOVER REQUIRED
`
`
`
`S1-AP: HANDOVER
`
`PREPARATION FAILURE
`
`
`Figure 19.2.2.5.1-1: Handover preparation procedure
`
`The handover preparation comprises the following steps:
`
`- The HANDOVER REQUIRED message is sent to the MME.
`
`- The handover preparation phase is finished upon the reception ofthe HANDOVER COMMAND in the source
`eN B. which includes at least radio interface related information (HO Command for the UE]. successfully
`established EPS Bearer(s) and EPS bearerls} which failed to setup.
`
`In case the handover resource allocation is not successful (e.g. no resources are available on the target side] the
`MME responds with the HANDOVER PREPARATION FAILURE message instead ofthe HANDOVER
`COMMAND message.
`
`19.2.2.5.2
`
`Handover Resource Allocation procedure
`
`The handover resource allocation comprises the following steps:
`
`
`
`
`
`Target eNB
`
`S1-AP: HANDOVER REQUEST
`
`S1-AP: HANDOVER REQUEST ACK
`
`
`
`
`
`S1-AP: HANDOVER FAILURE
`
`Figure ‘I9.2.2.5.2-‘Ii Handover resource allocation procedure
`
`- The MME sends the HAN DOVER REQUEST message including the EPS Bearerts) which needs to be setup by
`the target eNB.
`
`- The target eNB responds with the HANDOVER REQUEST ACK message after the required resources for all
`accepted EPS Bearers are allocated. The HANDOVER REQUEST ACK message contains successfully
`established EPS bearer{s). EPS Bearer(s) which failed to setup and radio interface related information (HO
`Command for the UE), which is later sent transparently via the EPCICN from the target RAT to the source RAT.
`
`If no resources are available on the target side. the target eNB responds with the HAN DOVER FAILURE
`message instead ofthe HANDOVER REQUEST ACK message.
`
`3GPP
`
`SAMSUNG 1017-0141
`
`SAMSUNG 1017-0141
`
`

`
`Release 8
`
`90
`
`3C-SPF TS 36.300 VB.4.0 (2008-03}
`
`19.2.2.5.3
`
`Handover Notification procedure
`
`The Handover Completion for SI initiated handovers comprises the following steps:
`
`- The HANDOVER NOTIFY message is sent by the target eNB to the MME when the UE has successfully been
`transferred to the target cell.
`
`RRC: HAN DOVER CONFIRM
`
`Target eNB
`
`S1—AP: HANDOVER NOTIFY
`
`Figure 19.2.2.5.3-1: Handover completion procedure
`
`19.2.2.5.4
`
`Handover Cancellation
`
`This functionality is located in the source eNB to allow a final decision regarding the outcome ofthe handover. i.e.
`either to proceed or to cancel the handover procedure.
`
`
`
`
`
`
`
`
`
`S1-AP: HANDOVER CANCEL. ACK
`
`S1-AP: HANDOVER CANCEL
`
`Figure 19.2.2.5.4-1: Handover cancellation procedure
`
`- The source eNB sends a HANDOVER CANCEL message to the MME indicating the reason for the handover
`cancellation.
`
`- The MME confirms the reception ofthe HANDOVER CANCEL message by returning the HAN DOVER
`CANCEL ACK message.
`
`19.2.2.5.5
`
`Path Switch procedure
`
`The handover completion phase for X2 initiated handovers comprises the following steps:
`
`- The PATH SWITCH message is sent by the target eNB to the MME when the UE has successfully been
`transferred to the target cell. The PATH SWITCH message includes the outcome ofthe resource allocation:
`successfully established EPS Bearerts).
`
`The MME responds with the PATH SWITCH ACK message which is sent to the eNB.
`
`The MME responds with the PATH SWITCH FAILURE message in case a failure occurs in the EPC.
`
`3GPP
`
`SAMSUNG 1017-0142
`
`SAMSUNG 1017-0142
`
`

`
`Release 8
`
`91
`
`3C-SPF TS 36.300 VB.4.0 (2008-03}
`
`Target eNB
`
`
`
`
`
`
`
`|
`s1_AP:PATHSWITCH
`RRC:HANDOVERCONFIRMI
`
`
`
`S1-AP: PATH SWITCH ACK
`
`S1-AP: PATCH SWITCH FAILURE
`
`
`
`Figure 19.2.2.5.5-1: Path Switch procedure
`
`19.2.2.6
`
`NAS transport procedures
`
`A NAS signalling message is transferred on the SI interface in both directions. The procedures providing this
`functionality are
`
`lnitial UE Message procedure (eNB initiated)
`
`Uplink NAS transport procedure (eNB initiated)
`
`Downlink NAS transport procedure (MME initiated)
`
`Downlink NAS non delivery indication procedure
`
`i} Initial UE Message procedure
`
`
`
`S1-AP: INITIAL UE MESSAGE
`
`
`
`
`
`
`
`Figure 19.2.2.6-1: Initial UE Message procedure
`
`- The INITIAL. UE MESSAGE procedure is initiated by the eNB by sending the INITIAL UE MESSAGE
`message to the MME. The INITIAL UE MESSAGE contains a NAS message [e.g. Service Request), the UE
`signalling reference [D and other Sl addressing information.
`
`ii) NAS Transport procedure (eNB initiated).
`
`
`
`3GPP
`
`Figure 19.2.2.6-2: Uptink NAS Transport procedure
`
`SAMSUNG 1017-0143
`
`

`
`Release 8
`
`92
`
`3C-SPF TS 36.300 VB.4.0 (2008-03}
`
`The Uplink NAS Transport procedure is initiated by the eNB by sending the UPLINK NAS TRANSPORT
`message to the MME. The UPLINK NAS TRANSPORT message contains a NAS message, UE identification
`and other SI related addressing information.
`
`iii} NAS Transport procedure [MME initiated)
`
`SI-AP: DOWNLINK NAS TRANSPORT
`
`Figure 19.2.2.6-3: Downlink NAS Transport procedure
`
`The Downlink NAS Transport procedure is initiated by the MME by sending the DOWNLINK NAS
`TRANSPORT message to the eNB. The DOWN LINK NAS TRANSPORT contains a NAS message. UE
`identification and other SI related addressing information.
`
`iv} Downlink NAS non delivery procedure
`
`S1-AP: DOWNLINK NAS NON DELIVERY
`
`INDICATION
`
`Figure 19.2.2.6-4: Downlink NAS Non Delivery Indication procedure
`
`When the eNB decides to not start the delivery ofa NAS message that has been received from MME, it shall
`report the non-delivery of this NAS message by sending a DOWNLINK NAS NON DELIVERY INDICATION
`message to the MME including the non-delivered NAS message and an appropriate cause value.
`
`19.2.2.7
`
`S1 interface Management procedures
`
`19.2.2.7.1
`
`Reset procedure
`
`The purpose ofthe Reset procedure is to initialize the peer entity after node setup and after a failure event occurred.
`This procedure is initiated by both the eNB and MME.
`
`19.2.2.?'.1a
`
`eNB initiated Reset procedure
`
`3GPP
`
`SAMSUNG 1017-0144
`
`SAMSUNG 1017-0144
`
`

`
`Release 8
`
`93
`
`3C-SPF TS 36.300 VB.4.0 (2008-03}
`
`
`
`
`S1-AP: RESET
`
`S1-AP: RESET ACK
`
`
`
`
`Figure 19.2.2.7.1a-1: eNB initiated Reset procedure
`
`The eNB triggers the RESET message to indicate that an initialisation in the MME is required. The MME
`releases the conespondin g references and resources.
`
`Afterwards the MME sends the RESET ACK message to confirm that the resources and references are cleared.
`
`19.2.2.7.1b
`
`MME initiated Reset procedure
`
` I S1-AP:RESET I
`
`
`
`
`
`S1-AP: RESET ASK
`
`Figure 19.2.2.7.1b-1: MME initiated Reset procedure
`
`The MME triggers the RESET message to indicate that an initialisation in the eNB is required. The eNB releases
`the corresponding references and resources.
`
`Afterwards the eNB sends the RESET ACK message to confirm that the resources and references are cleared.
`
`19.2.2.7.2
`
`Error Indication functions and procedures
`
`The Error Indication procedure is initiated by the eNB and the MME, to report detected errors in one incoming
`message. if an appropriate failure message cannot be reported to the sending entity.
`
`19.2.2.7.2a
`
`eNB initiated error indication
`
`
`
` S1 -AP: ERROR INDICATION
`3GPP
`
`Figure 19.2.2.7.2a-1: eNB initiated Error Indication procedure
`
`SAMSUNG 1017-0145
`
`

`
`Release 8
`
`94
`
`3GPP TS 36.300 V8.-4.0 (2008-03}
`
`- The eNB sends the ERROR INDICATION message to report the peer entity which kind oferror occurs.
`
`19.2.2.7.2b
`
`MME initiated error indication
`
`
`
`
`S1-AP: ERROR INDICATION
`
`
`
`Figure 19.2.2.7.2b-1: MME initiated Error Indication procedure
`
`- The MME sends the ERROR INDICATION message to report the peer entity which kind oferror occurs.
`
`20
`
`X2 Interface
`
`20.1
`
`User Plane
`
`The X2 user plane interface (X2-U) is defined between eNBs. The X2-U interface provides non guaranteed delivery of
`user plane PDUS. The user plane protocol stack on the X2 interface is shown in Figure 20.1-I. The transport network
`layer is built on IP transport and GTP-U is used on top of UDPKIP to carry the user plane PDUS.
`
`The X2-UP interface protocol stack is identical to the Si-UP protocol stack.
`
`User plane PDUS
`
`
`
`GTP-U
`
`Figure 20.1-1: X2 Interface User Plane (eNB-eNB}
`
`20.2
`
`Control Plane
`
`The X2 control plane interface (X2-CP) is defined between two neighbour eNBs. The control plane protocol stack of
`the X2 interface is shown on Figure 20.2-I below. The transport network layer is built on SCTP on top oflP. The
`application layer signalling protocol is referred to as X2-AP {X2 Application Protocol).
`
`3GPP
`
`SAMSUNG 1017-0146
`
`SAMSUNG 1017-0146
`
`

`
`Release 8
`
`95
`
`3C-SPF TS 36.300 VB.4.0 (2008-03}
`
`X2-AP
`
`Physical layer
`
`Data link layer
`
`P
`
`Figure 20.2-1: X2 Interface Control Plane
`
`A single SCTP association per X2-C interface instance shall be used with one pair of stream identifiers for X2-C
`common procedures. Only a few pairs of stream identifiers should be used for X2-C dedicated procedures. The upper
`limit for the number of stream identifiers for dedicated procedures is FFS and will be decided during the stage 3 work.
`
`Source-eNB communication context identifiers that are assigned by the source-eNB for X2-C dedicated procedures, and
`target-eNB communication context identifiers that are assigned by the target-eNB for X2-C dedicated procedures, shall
`be used to distinguish UE specific X2-C signalling transport bearers. The communication context identifiers are
`conveyed in the respective XZAP messages.
`
`20.2.1
`
`X2—CP Functions
`
`The XZAP protocol supports the following functions:
`
`-
`
`lntra LTE-Access-System Mobility Support for UE in ECM-CONNECTED:
`
`- Context transfer from source eNB to target eNB;
`
`- Control of user plane tunnels between source eNB and target eNB;
`
`- Handover cancellation.
`
`- Uplink Load Management;
`
`- General X2 management and error handling Functions:
`
`- Error indication.
`
`20.2.2
`
`X2—CP Procedures
`
`The elementary procedures supported by the X2/KP protocol are listed in Table 20.2.2-1 below:
`
`3GPP
`
`SAMSUNG 1017-0147
`
`

`
`Release 8
`
`96
`
`3C-SPF TS 36.300 VB.4.0 (2008-03}
`
`Table 20.2.2-1: X2-CP Procedures
`
`.
`.
`Response Message of
`Response Message of
`Successful Outcome Unsuccessful Outcome Descflpuon 8‘ comments
`
`Elementary
`Procedure
`
`Initiating
`Message
`
`Handover
`Preparation
`
`HANDOVER
`REQUEST
`
`Handover
`Cancellation
`
`HANDOVER
`CANCEL
`
`Release
`Resource
`
`RELEASE
`RESOURCE
`
`Error
`Indication
`
`ERROR
`INDICATION
`
`Load
`Management
`
`LOAD
`INDICATOR
`
`HANDOVER
`REQUEST
`ACKNOWLEDGE
`
`-
`
`-
`
`—
`
`
`
`HAN DOVER
`PREPARATION
`FAILURE
`
`Used by source eNB to request a
`handover to the target eNB
`
`Used by the source eNB to cancel a
`previousiv requested handover in a
`target eNB
`
`Used by the target eNB to signal to
`source eNB that control plane
`resources for the handed over UE
`context can be released.
`
`Used by the eNB to report errors in
`a received message provided they
`cannot be reported by an
`appropriate response message.
`
`Used by the eNB to report its load
`conditions to its neighbour eNBs.
`
`Note:
`
`this initial list might be extended.
`
`20.2.2.1
`
`Handover Preparation procedure
`
`The Handover preparation procedure is initiated by the source eNB ifit determines the necessity to initiate the handover
`via the X2 interface.
`
`
`
`Tas"=“‘B
`
`X2—.-XI’: I-IANDOVER REQUEST
`
`RRC: HAN DOVER COMMAND
`
`X2-AP: HANDOVER REQUEST ACKNOWLEDGE
`
`
`
`X2-AP: HANDOVER PREPARATION FAILURE
`
`Figure 20.2.2.1-1: Handover Preparation procedure
`
`The source eNB sends a HANDOVER REQUEST to the target eNB including the bearers to be setup by the target ENB.
`
`The handover preparation phase is finished upon the reception of the HANDOVER REQUEST ACKNOWLEDGE in
`the source eNB, which includes at least radio interface related infonnation (H0 Command for the UE}. successfully
`established EPS Bearer(s] and failed established EPS Bearer(s).
`
`In case the handover resource allocation is not successful (e.g. no resources are available on the target side) the target
`eNB responds with the HANDOVER PREPARATION FAILURE message instead ofthe HANDOVER REQUEST
`ACKNOWLEDGE message.
`
`lfeNB received NAS message from MME during X2 handover procedure. it shall be acted as specified in subclause
`l9.2.2.6.
`
`3GPP
`
`SAMSUNG 1017-0148
`
`SAMSUNG 1017-0148
`
`

`
`Release 8
`
`97
`
`3C-SPF TS 36.300 VB.4.0 (2008-03}
`
`20.2.2.2
`
`Handover Cancellation procedure
`
`This functionality is located in the source eNB to allow cancellation ofthe handover procedure.
`
`
`
`
`
`Target eNB
`
`X2—AP: HANDOVER CANCEL
`
`Figure 20.2.2.2-1: Handover Cancellation procedure
`
`The source eNB sends a HANDOVER CANCEL message to the target eNB indicating the reason for the handover
`cancellation.
`
`20.2.3
`
`Inter-cell Load Management
`
`Inter-cell load management in E-UTRAN is performed through the X2 interface. In case of variation in the load
`condition, the eNodeB signals the new load condition to its neighbour eNodeBs e.g. the neighbour eNodeBs for which
`an X2 interface is configured due to mobility reasons.
`
`The LOAD INDICATOR message is used to signal the load conditions between eNodeBs.
`
`3GPP
`
`SAMSUNG 1017-0149
`
`SAMSUNG 1017-0149
`
`

`
`Release 8
`
`98
`
`3G‘-PP TS 36.300 V8.-4.0 (2008-D3}
`
`
`
`lX2 A131 LOAD INDICATOR
`
`Figure 20.2.3-1: LOAD INDICATOR message over X2
`
`21
`
`System and Terminal complexity
`
`21.1
`
`Overall System complexity
`
`21.2
`
`Physical layer complexity
`
`21.3
`
`UE complexity
`
`22
`
`Support for self-configuration and self-optimisation
`
`22.1 Definitions
`
`This concept includes several different functions from eNB activation to radio parameter tuning. Figure 22.1-l is a basic
`framework for all self-configuration fself-optimization functions.
`
`Self-configu ration process is defined as the process where newly deployed nodes are configured by automatic
`installation procedures to get the necessary basic configuration for system operation.
`
`This process works in pre-operational state. Pre-operational state is understood as the state from when the eNB is
`powered up and has backbone connectivity until the RF transmitter is switched on.
`
`As described in Figure 2 I
`
`. l , functions handled in the pre-operational state like:
`
`- Basie Setup and
`
`-
`
`[nitial Radio Configuration
`
`are covered by the Self Configuration process.
`
`NOTE:
`
`depending on the final chosen functional distribution in RAN, the feasibility offollowing items should be
`studied e.g.:
`
`-
`
`To obtain the necessary interface configuration;
`
`- Automatic registration of nodes in the system can be provided by the network;
`
`- Alternative possibilities for nodes to obtain a valid configuration;
`
`-
`
`The required standardization scope.
`
`Self-optimization process is defined as the process where UE & eNB measurements and performance measurements
`are used to auto-tune the network.
`
`3GPP
`
`SAMSUNG 1017-0150
`
`SAMSUNG 1017-0150
`
`

`
`Release 8
`
`99
`
`3C-EPP TS 36.300 VB.4.0 (2008-03]
`
`This process works in operational state. Operational state is understood as the state where the RF interface is
`additionally switched on.
`
`As described in Figure 21.]. functions handled in the operational state like:
`
`- Optimization K Adaptation
`
`are covered by the Self Optimization process.
`
`NOTE:
`
`depending on the final chosen functional distribution in RAN the feasibility offollowing items should be
`studied e.g.:
`
`— The distribution of data and measurements over interfaces relevant to RAN3;
`
`—
`
`Functionsfentitiesfnodes in charge of data aggregation for optimization purpose;
`
`- Dependencies with O&M and O&M interfaces, in the self optimization process;
`
`— The required standardization scope.
`
`The architecture oflogical self-configurationloptimization functionality is FFS.
`
`.
`
`eNB power on
`{or cable connected]
`
`I
`
`
`
`----E—---- b-1 ' neighbour list configuration
`
`in-2:
`
`eoverageioapacity related
`para meter configuration
`
`E5
`
`5
`
`(B) Initial Radio
`Configuration
`
`-
`
`(operational state)
`
`§'=if-9i1liEi:a!0£_____ll _____ __‘:: __________ ___
`(0) Optimization I
`-----E-----l c~1 : neighbour llsloptimisalion
`Adaptation
`————
`i:-2 :
`coverage and capacity control
`
`5E
`
`Figure 22.1-1: Ramifications of Self-Configuration iSelf-Optimization functionality
`
`22.2 UE Support for self-configuration and self-optimisation
`
`UE shall support measurements and procedures which can be used for self-configuration and self-optimisation of the E-
`UTRAN system.
`
`- UE shall support measurements and measurement reporting to support self-optimisation ofthe E-UTRAN
`system. Measurements and reports used for the normal system operation. should be used as input for the self-
`optimisation process as far as possible.
`
`NOTE:
`
`the UE impact should be carefully investigated and taken into account.
`
`3GPP
`
`SAMSUNG 1017-0151
`
`(A) Basic Setup
`
`____ _____ a-1 _
`";
`
`configuration of IP address
`and detection of om
`
`'----- a-2'. authentication oteNEli'NW
`
`.----- a-3: association In aGW
`
`__ a-4: downloading oteNB software
`(and operational parameters}
`
`Sellicontiguration
`(prc-operational state)
`
`SAMSUNG 1017-0151
`
`

`
`Release 8
`
`100
`
`3C-SPF TS 36.300 VB.4.0 (2008-03}
`
`- The network is able to configure the measurements and the reporting for self-optimisation support by RRC
`signalling messages.
`
`-
`
`It shall be possible to associate measurements for self-optimisation purpose with location information depending
`on UE capability {details are [FFS]).
`
`22.3 Self-configuration
`
`22.3.1 Dynamic configuration of the S1-MME interface
`
`22.3.1.1
`
`Prerequisites
`
`The following prerequisites are assumed:
`
`-
`
`An initial remote IP end point to be used for SCTP initialisation is provided to the eNB for each MME in the pre
`operational state.
`
`How the eNB gets the remote IP end point{s} and its own IP address are FFS.
`
`-
`
`Other relevant information fromito eNB tolfrom MME to self-configure SI-MME are FFS
`
`22.3.1.2
`
`SCTP initialization
`
`-
`
`For each MME the eNodeB tries to initialize a SCTP association as described in RFC2960 [8], using a known
`initial remote [P Endpoint as the starting point. until SCTP connectivity is established.
`
`22.3.1.3 Application layer initialization
`
`Once SCTP connectivity has been established. the eNodeB and MME are in a position to exchange application level
`configuration data over the S l -MME application protocol needed for the two nodes to interwork correctly on the S]
`interface. The details of the infonnation exchange outlined below are F FS, and dependent on the further standardization
`ofthe SI interface.
`
`- The eNodeB provides the relevant information to the MME , which may include node ID. list ofsupported TA[s).
`etc. Details ofthe relevant information needed to setup the SI -M ME interface is subject to stage3 discussion and
`is left FFS.
`
`- The MME provides the relevant information to the eNodeB. which may include node ID, PLMN lD. etc. Details
`ofthe relevant information needed to setup the S1-MME interface is subject to stage3 discussion and is left FFS.
`
`- When the application layer initialization is successfully concluded, and has been mutually acknowledged by the
`two peer nodes, the dynamic configuration procedure is completed. and the S I -MME interface is operational.
`
`22.3.2 Dynamic Configuration of the X2 interface
`
`Editors Note: The Dynamic configuration ofthe X2 interface is expected to work in a similar manner as the
`Dynamic Configuration ofthe Sl-M ME interface {section 22.3.] }.
`
`22.3.2.1
`
`Prerequisites
`
`22.3.2.2
`
`SCTP initialization
`
`22.3.2.3
`
`Application layer initialization
`
`22.3.3 Automatic Neighbour Relation Function
`
`The ANR (Automatic Neighbor Relation} function relies on cells broadcasting their identity on global level, Cell
`Global-Cell-Identifier (Global-CID).
`
`3GPP
`
`SAMSUNG 1017-0152
`
`SAMSUNG 1017-0152
`
`

`
`Release 8
`
`101
`
`3C-SPF TS 36.300 VB.4.0 (2008-03}
`
`Cell B
`Phy-C|D=5
`Global-CID =19
`
`2b] Read ECHO
`
`3) Report
`G|oba1—C|D=‘19
`
`1) report(Phy—ClD=5.
`strong signal)
`
`2) Report Global-CID
`Request (Target Phy-
`C|D=5}
`E
`
`Figure 22.3.3-1: Automatic Neighbor Relation Function
`
`It is assumed that this function executes under the constraints ofthe O&M system which can manage:
`
`ANR Blacklist: List of cells to which the eNB shall neither establish nor keep a neighbour relation.
`
`ANR Whitelist: List ofcelis to which the eNB shall always establish and maintain a neighbour relation.
`
`it is also assumed that the O&M system is informed about changes in the eNB neighbour relation list.
`
`The function works as follows:
`
`The eNodeB serving cell A has an ANR function. As a part of the normal call procedure, the eNodeB instructs each
`UES to perform measurements on neighbor cells. The eNodeB may use different policies for instructing the UE to do
`measurements, and when to report them to the eNodeB.
`
`1. The UE sends a IneasuI'ement report regarding cell B. This report contains Cell B’s Phy-CID. but not its Global-
`CID.
`
`When the eNodeB receives a UE measurement report containing Phy-CID, the following sequence may be used.
`
`2. The eNodeB instructs the UE, using the newly discovered Phy-CID as parameter. to read the Global-CID ofthe
`related neighbor cell. It is FFS how this is achieved.
`
`3. When the UE has found out the new cel|’s Global-CID, the UE reports the detected Global-CID to the serving
`cell eNodeB.
`
`4. The eNodeB decides to add this neighbor relation, and can use Phy-CID and Global-CID to:
`
`a Lookup a transport layer address to the new eNodeB (FFS ifthis needs to be standardized by 3GPP).
`
`b Update its Neighbor Relation List.
`
`c
`
`If needed, setup a new X2 interface towards this eNodeB. The setup of the X2 interface is described in
`section 22.3.2.
`
`The exchange of further information for ANR optimisation purposes is FFS.
`
`3GPP
`
`SAMSUNG 1017-0153
`
`SAMSUNG 1017-0153
`
`

`
`Release 8
`
`102
`
`3C-SPF TS 36.300 VB.4.0 (2008-03}
`
`23
`
`Others
`
`23.1
`
`Support for real time IMS services
`
`23.2
`
`Subscriber and equipment trace
`
`Support for subscriber and equipment trace for LTE and SAE shall be as specified in 3GPP specifications 32.42] , 32.
`422. 32.423 and 3GPP Trace [RP 32.441, 32.442 and 32,443.
`
`All traces are initiated by the core network, even ifthe trace shall be carried out in the radio network.
`
`The following functionality is needed on the S] and X2 interface:
`
`-
`
`-
`
`Support for inclusion of subscriber and equipment trace information in INITIAL CONTEXT SETUP REQUEST
`and EPS BEARER SETUP REQUEST messages over the S] interface.
`
`Support for inclusion of subscriber and equipment trace infonnation in the HANDOVER REQUEST message
`over the X2 interface.
`
`A trace setup in the radio network will be propagated on the X2 interface at handover and on the S] interface if the
`handover is carried out between MMEs.
`
`3GPP
`
`SAMSUNG 1017-0154
`
`SAMSUNG 1017-0154
`
`

`
`Release 8
`
`103
`
`3GPP TS 36.300 VB.4.0 (2008-03}
`
`Annex A (informative):
`NAS Overview
`
`This subclause provides for information an overview on services and functions provided by the NAS control protocol..
`
`A.1
`
`Services and Functions
`
`The main services and functions ofthe NAS sublayer include:
`
`-
`
`-
`
`-
`
`EPS Bearer control (see 3GPP TR 23.40] [1 7]);
`
`ECM-IDLE mobility handling;
`
`Paging origination;
`
`- Configuration and control of Security.
`
`A.2
`
`NAS protocol states 8. state transitions
`
`The NAS state model is based on a two-dimensional model which consists of EPS Mobility Management (EMM) states
`describing the mobility management states that result from the mobility management procedures e.g. Attach and
`Tracking Area Update procedures. and of EPS Connection Management {ECM) states describing the signalling
`connectivity between the UE and the EPC (see 3GPP TS 23.401 [l7']}.
`
`NOTE:
`
`The ECM and EMM states are independent ofeach other and when the UE is in EMM-CONN ECTED
`state this does not imply that the user plane (radio and SI bearers) is established.
`
`The relation between NAS and AS states is characterised by the following principles:
`
`-
`
`EMM-DEREGISTERED & ECM-IDLE ::> RRC_lDLE:
`
`- Mobility: PLMN selection:
`
`- UE Position: not known by the network.
`
`-
`
`EMM-REGISTERED & ECM-IDLE :> RRC_lDLE:
`
`- Mobility: cell reseiection;
`
`- UE Position: known by the network at tracking area level.
`
`-
`
`EMM-REGISTERED & ECM-CONN ECTED with radio bearers established :> RRC_CONNECTED.
`
`- Mobility: handover;
`
`- UE Position: known by the network at cell level.
`
`
`
`3GPP
`
`SAMSUNG 1017-0155
`
`

`
`Release 8
`
`104
`
`3GPP TS 36.300 V8.-4.0 (2008-03}
`
`Annex B (informative):
`MAC and RRC Control
`
`The E-UTRA supports control signalling in terms of MAC control signalling (LUL2 control channel and MAC control
`PDU} and RRC control signalling (RRC message).
`
`B.1
`
`Difference between MAC and RRC control
`
`Tl1e different characteristics of MAC and RRC control are summarized in the table below.
`
`Table B.1-1: Summary of the difference between MAC and RRC control
`
`
`
` MAC control RRC control
`
`Control entity
`
`MAC
`
`RRC
`
`Signaliing
`
`L1lL2 control channel
`
`MAC control PDU
`
`RRC message
`
`Signalling reliability
`
`- 10'2 (no retransmission)
`
`- 10'3 (after HARQ)
`
`- 10‘5 (after ARQ)
`
`Control delay
`
`Very short
`
`Extensibility
`
`None or very limited
`
`Short
`
`Limited
`
`Longer
`
`High
`
`Security
`
`No integrity protection
`No ciphering
`
`No integrity protection
`No ciphering
`
`Integrity protected
`Ciphering (FFS)
`
`The Inain difference between MAC and RRC control lies in the signalling reliability. Due to the signalling reliability.
`signalling involving state transitions and radio bearer configurations should be perforrned by RRC. Basically, all
`signalling performed by RRC in UTRA should also be performed by RRC also for E-UTRA.
`
`B.2
`
`Classification of MAC and RRC control functions
`
`The table below illustrates the classification of MAC and RRC control functions for E-UTRAN.
`
`Table B.2-1: Classification of MAC and RRC control functions
`
`Controlled configurationlparameters
`
`MAC
`commi
`signalling
`
`L1l'L2
`controi
`channel
`
`Short-lived (PRB) and dynamic {MCS) allocation
`Long-lived (PRB) and fixed (MCS) allocation (FFS)
`T'""""9 Ad"3'”°e (FFS)
`
`MAC control
`ppu
`
`Timing Advance (FFS)
`RLC related control PDU (FFS)
`
`RRC control
`
`RRC
`
`Long—lived (PRB) and fixed (MCS) allocation (FFS)
`
`signauing
`
`message
`
`Activationideactivation of long-lived (PRB) andlor fixed (MCS) ailocation (FFS)
`Til configuration for variable Til length control (FFS)
`Static parameter configuration for UE inactivity control within RRC_ACTlVE (e_g.
`DRXIDTX periods)
`
`3GPP
`
`SAMSUNG ‘I017-0156
`
`SAMSUNG 1017-0156
`
`

`
`Release 8
`
`105
`
`3C-SPF TS 36.300 VB.4.0 (2008-03}
`
`Annex C (informative):
`System Information
`
`This annex provides an overview ofthe classification and division ofsystem infomtation between static and flexible
`parts. Considerations about dedicated distribution of system information are also included.
`
`C.1
`
`SI classification
`
`Five categories are identified for system information classification:
`
`I.
`
`information valid across multiple cells;
`
`2.
`
`Information needed at ce|l;’PLMN search;
`
`3.
`
`4.
`
`lnfonnation needed prior to cell camping;
`
`Information needed before cell access;
`
`5.
`
`lnfomtation needed while camping on a cell.
`
`From UEs’ point of view. the information that is needed at cell selection and prior to camping are very similar. Before a
`UE can camp on a cell, it needs to know ifthe access is allowed in that cell. Thus it would be very beneficial to know
`all access restrictions already at cell search phase.
`
`C.1.1
`
`Information valid across multiple cells
`
`The pieces ofinforntation that can be valid across multiple cells are:
`
`- A-GN SS assistance data;
`
`—
`
`PLMN identity(ies);
`
`- Tracking area identity;
`
`Note:
`
`the above text will be revised if it is agreed that a cell can be a member of more than one tracking area.
`
`-
`
`-
`
`-
`
`Predefined configuration information;
`
`System Frame Number ifit does not change from cell to cell (in case of synchronized network);
`
`Some measurement/mobility information (FFS}.
`
`C.1.2
`
`Information needed at cell/PLMN search
`
`In order to support full mobility within the serving frequency layer, the U Es need to perfonn cell search rather ofien and
`thus it is seen very important that the information needed in cell search phase is readily available, thereby improving
`cell search times and minimizing UE power consumption. If system information decoding is needed for identifying a
`cell, fast system infomtation reception is needed in order to avoid too long identification times. For optimising PLMN
`search and make PLMN search fast and non-complex. the information needed for PLMN search should be easily
`available. The pieces ofinformation that are needed at cell/PLMN search are:
`
`-
`
`PLMN identity(ies}: in order to acquire information to which PLMN the cell belongs, UEs need to receive
`PLMN identir}/(ies);
`
`NOTE:
`
`There may be multiple PLMN identities for one cell.
`
`- Measurement cell identity (FFS): there needs to be a cell identity in the system information, in order to allow
`UEs to identify the cell reliably for measurement purposes.
`
`3GPP
`
`SAMSUNG 1017-0157
`
`SAMSUNG 1017-0157
`
`

`
`Release 8
`
`106
`
`3C-SPF TS 36.300 VB.4.0 (2008-03}
`
`NOTE:
`
`UEs may identify the cell also based on the reference sequence detection;
`There is another cell identity that identifies the cell within e.g. PLMN.
`
`NOTE:
`
`UEs may have to check possible cell access restrictions before selecting celli’PLMN;
`For cell;’PLMN search UEs might need some Ll parameters.
`
`C.1.3
`
`Information needed prior to cell camping
`
`Before a UE can camp on a cell, it needs to know any access related parameters in order to avoid camping on cells
`where access is forbidden. Thus prior to camping on a cell, a UE needs to know the following information:
`
`- Any cell access restriction parameters, e.g.:
`
`- Tracking area identity: ifthe forbidden TA concept is adopted from legacy systems, then the UE needs to
`know whether the cell belongs to such forbidden TA.
`
`Note:
`
`the above text will be revised ifit is agreed that a cell can be a member of more than one tracking area.
`
`- Cell barring status and cell reservation status (FFS ifneeded per PLMN): the UE needs to know whether the
`cell is barred or reserved in order to avoid camping on a barred cell. Possibly also barring time might be
`needed in order to avoid UE to poll barring time frequently from the system information. Another option is
`that barring status is indicated also in the neighbour cell list.
`
`- Radio access limitation parameters:
`
`- Any radio condition parameters that limit the access to the cell e.g. similar to GSM C US criteria;
`
`-
`
`It is FFS if we need to have some hand information indication also, in order to allow UEs to check
`possible band support before camping on the cell.
`
`NOTE:
`
`UE may need some Ll parameters prior to camping.
`
`C.1.4
`
`Information needed prior to cell access
`
`Once a UE has camped on a cell, the information needed prior to cell access (transmission/reception) includes at least:
`
`-
`
`-
`
`System Frame Number (SFN) (FFS)
`
`-
`
`SFN is probably needed by the UE to understand the scheduling parameters (e. g. scheduling information for
`secondary SI, RACH, PCH, E-MBMS etc.)
`
`Ll information, example set of needed Ll parameters:
`
`Note:
`
`RAN] needs to define what parameters are needed at this phase.
`
`- Carrier Bandwidth: FFS if separate bandwidths for UL and DL are needed;
`
`- Carrier center frequency (FFS);
`
`- Cyclic Prefix parameters: in order to decode DL-SCH UE needs to know the CP length arrangements;
`
`- MIMO related parameters: in order to take advantage ofthe multi-antenna transmissions like MIMO, the UE
`needs to know parameters of number of TX antennas, DLIUL pre-coding matrices, etc...;
`
`- Band information: may be needed ifthe same DL carrier frequency has variable UL carrier frequency;
`
`- LHL2 signalling channel structure parameters: ifLlfL2 signalling channel has variable configurations, the
`UE may need to know its channel structure at least partly. LIIL2 signalling is crucial to receive any
`allocation infomtation. lf Random Access Response is transmitted without LUL2 signalling (e.g.
`synchronous transmission with Random Access Preamble), this information might not be required;
`
`- RACH parameters (needed by the UE to start usage of RACH):
`
`3GPP
`
`SAMSUNG 1017-0158
`
`SAMSUNG 1017-0158
`
`

`
`Release 8
`
`107
`
`3GPP TS 36.300 V8.4.0 (2008-D3}
`
`- RACH scheduling information: UE needs to know where in time (sub-frame) and frequency (Physical
`Resource Units) the RACH channel is located;
`
`- RACH sequences: UE needs to know the RACH set of sequences to choose from. The sequences may not be
`fully ofequal meaning [e.g. CQI can be classified for the sequences in a specific way);
`
`- Access class restrictions: access class restrictions might be needed to limit the number ofpossible UEs using
`RACH;
`
`-
`
`Persistence values: possible persistence value scheme parameters are needed for RACH usage;
`
`- Other parameters related to RAC H: UE needs to know the timers and parameters related to RAC H e.g. how
`often the UE rctransmits RACH and how many times the retransmission is allowed etc;
`
`- RACH power control parameters: UE needs to know parameters related to UL power control.
`
`C.1.5
`
`Information needed while camping on a cell
`
`When a UE has camped on a cell. it needs to continue measuring the n