Femto-Femto HO Chalk Talk

Femto-Femto Handover Feature 75494
Chalk Talk
FemtoBSR SAE
V0.5, 5th September, 2008
Feature Overview
Only Intra-Cluster Handover supported

Only Intra-Brick Handover supported
Only intra-Frequency Handover supported
Handover will only occur between Femtos with the same Group
All Neighbour BSRs (Group and non-Group) must be on same
cluster
Handover must be transparent to the Core Networks
Core Network (MSC/SGSN)
Rerouting of signalling plane to target BSR in BSG

Rerouting of user plane to target BSR in BVG
Manual Provisioning should be minimal

Detection of Neighbour BSRs
Discovery of Neighbour BSRs Address
Manual Provisioning will be provided for fallback
Handover procedure needs to be fast

Delays to handover may result in call drops for fast moving UEs when
there is a limited overlap of FemtoCells
Handover will use UE Measurement based algorithm

Femto Cells will not overlay so DAHO is unsuitable, MAHO will allow
Handover to be directed to a target cell towards which the UE is moving.
BVG
Target FemtoBSR will support Pre-emption, dropping lower

priority calls to provide resources for incoming handover
BSR
CS User Plane
PS User Plane
Pre-emption at the target may introduce latency to the procedure but

without pre-emption handover will fail
2 | Femto-Femto Handover | August 2008
IpSec
Brick Router
Handover is for CS only (Sig only and Sig + RAB)

PS handover adds additional complexity in the target BSR. For sim.
bearer cases, PS RABs are released prior to handover.
BSG
All Rights Reserved Alcatel-Lucent 2006, #####
BPG
BSR
UE
Signalling Plane
Example Femto to Femto CS Handover

PSTN
Notes:
GW-MSC
3. BSRAP is used for the Relocation

4. BVG binding is updated
3G-MSC
IPC
5. STRMGR binding is switched,

source BSR removes UE context
BSG
BVG
Switch
STRMGR
binding
SeGW
IuUP
Setup
ADSL access
Network
UE originates
a CS voice call
Invoke
Relocation
Switch
DPAT
binding
Femto AP
Femto AP
Network Architecture Overview

Main Architecture Requirements/Constraints:
Neighbour BSR Discovery & Coverage
FemtoBSR must be able to determine potential neighbour cells for handover during configuration
and ensure that PSC selection considers group neighbours neighbour cells
Target BSR Address Discovery & Routing

FemtoBSR must be able to determine the Target Femto IP address for routing inter-Femto
signalling messages
Inter-BSR Signalling
New Femto-Femto Signalling protocol (BSRAP) is required for the transfer of handover
information between the source and target Femto.
Existing Protocol updates for support of Femto-Femto handover

BSR-BSG (BSGAP) for passing Neighbour BSR Discovery information
BSR-BSG (STRMGR) for redirection of CN control plane signalling to target Femto
BSR-BVG (DPAT) for redirection of user plane traffic to target Femto
BSR Network Topology Discovery

Requirement:
BSR must determine the BSR Network topology for use in
Coverage, PSC Allocation & Femto-Femto Handover
algorithms
Solution:
During Autoconfiguration/Self Optimisation:
1.
FemtoBSR performs Neighbour Cell Detection for Femto PSCs and

Cellid (SIB3)
2.
FemtoBSR passes own cell and neighbour cell information

{CellId, PSC, CPICH Ec/No, GroupId, Femto IP address)
FemtoBSR obtains neighbour neighbour cell information
{CellId, PSC, CPICH Ec/No, GroupId, Femto IP address}
Neighbour Cell Information

.
used for PSC-Allocation, Coverage and Femto-Femto Handover
Neighbour Neighbour Cell Information

.
2. BSR obtains group

information for NC
FemtoBSR obtains neighbour cell group information

{GroupId, Femto IP address, Groupsize)
FemtoBSR performs Neighbour Cell Information Transfer to each

Femto Neighbour Cell (Group and non-Group)
FemtoBSR determines neighbour cell list

{CellId{vRNC+BSRId}, PSC, CPICH Ec/no}
FemtoBSR performs Group Id Query procedure with BSG for

Detected Femto Neighbours
3.
BSG
used for PSC Allocation, Coverage Algorithm
3. BSRs exchange NC and NNC info
1. BSR Detects NC
PSC Allocation for Handover

A Femto BSR cannot have neighbours using the same PSC. General
problem in BSRs providing contiguous coverage (= multiple BSRs
deployed close together)
Issue for
Cell reselection: UE can receive signals from BSR 1 and 3. Interference might
not allow to syncronize and/or read SIBs to check if the cell for cell
reselection is suitable. Or interference adulterates the measurements.
Femto Handover: Neighbour list cannot have cells with the same PSC. It is
impossible to determine from the UE reported best PSC which is the target
BSR
BSR2:
BSR1:
1
PSCy
PSCx
BSR3:
PSCx
If BSR 2 has two neighbours with the

same PSCx, a UE at position 1 located
on BSR 2 would report best cell with
PSC x. BSR 2 is unable to determine
from PSC whether target is BSR1 or
BSR3
PSC issue is a group deployment issue and should be covered under

feature 80569 (Femto groups)
BSR
Network
Topology
Detection
Solution:
PSC Allocation will be modified to consider Neighbours - Neighbour
Cells
BSR must select a PSC that is not used by a neighbour cell and is
not used by any neighbouring cells of that neighbour cell
If no free PSC exists, select PSC based upon weakest neighbour
of weakest neighbour that is not a PSC used by the BSRs own
neighbour to minimise interference
Note:
-6 |Transfer
of Neighbour
Cell information between
BSRs
All Rightsneighbour
Reserved Alcatel-Lucent
2006, #####
Femto-Femto Handover
| August 2008
No
All PSCs
allocated to
NNCs
Select weakest
PSC from those not
allocated to a NNC
Yes
Select PSC
based upon
weakest NNC of
weakest NC
Group Femto Coverage

Issue:
FemtoBSRs must optimise cell coverage across group
Solution:
Periodic UE Measurements will be used to estimate the cell overlap based upon:
Number of UE Detected Femto Group Neighbour Cells
Large number of Detected Femto Group Neighbour Cells indicates:

Too much cell overlapdecrease cell size
Small number of Detected Femto Group Neighbour Cells indicates:

Insufficient cell overlap.increase cell size
Overlap thresholds algorithm will consider:

Group Size
Number of PSCs allocated to the group
Location of UE in Cell (Cell Edge, Cell Centre)
Hysteresis Time/Measurements based
Ongoing Femto Group Neighbour Cell (FGNC) Information for Handover

Each Femto maintains a list of its FGNCs with state:
Unknown
Detected
Unknown
Detected PSC & CellId, confirmed in Group by BSG
Informed
One Way visibility detected by a neighbour cell (you can
see me but I cannot see you)
TransferFGNC(psc)
Detected & Informed

Detected
FGNCs have Time to Live (TTL)

Refreshed every detection/inform event
On expiry detected/informed state is removed
TTL needs to consider interval between completed
SO events
Det_TTL Expiry
TransferFGNC(psc)
Detected
Inf_TTL Expiry
At each AC/SO event, TransferFGNC(psc) will be

performed with detected FGNCs
Will pass current PSC information (which may have
changed as a result of SO) and NNC info
Data Requirements
Detected Cells will be stored in MIM as a separate
informedCellNeighbour List
Inf_TTL Expiry
Detected
Detected
&
Informed
Det_TTL Expiry
Informed
Inter-BSR discovery and routing

Femto-Femto signalling will be performed through Brick
Femto Discovery will use a BSG lookup/registration mechanism
Both are generic solutions that avoid specification of additional requirements
(security and discovery) on the enterprise local network
Inter-BSR Signalling Requirements

New Protocol Stack Required for:
Exchange/Sharing of Handover Configuration Information between FemtoBSRs
Control Plane Signalling between the source and target BSR for performing handover
Proposed Solution:
BSRAP over SCTP
BSRAP will use X2AP Message set (concepts & timers) where possible, Information
Elements will be TLV based where possible upon micro BSRAP
BSR
BSR
Brick
BSRAP
BSRAP
SCTP
SCTP
IP
ESP
UDP
IP
IPV
IP Routing
UDP
encapsulated
IPSec tunnel
ESP
ESP
ESP
UDP
UDP
UDP
IP
IP
IPT
L2
L2
L2
L2
L1
L1
L1
L1
Inter-BSR signalling stack
Call Flow: Femto to Femto Handover of a CS connection

X:UE
Source:BSR
:BSG
Target:BSR
:BVG
Y:UE
Call Established
opt
[PS RAB established]

rrc_radioBearerRelease()
bsgap_bsrLookupRequest()
bsgap_bsrLookupResponse()
CanTm(Trelocprep)
bsrap_handoverRequest()
opt
[Target BSR has no free resources and lower priority exists]
Ref
Release RRC Connection - Success - NL
bsrap_handoverRequestAcknowledge()
CanTm(Treloc??)
rrc_radioBearerReconfiguration()
CanTm(TRelocOverall)
UE sync detected
bsgap_ueRegistrationRequest()
Informs the Source

BSR that it can
release context
info. for the UE
At some
point after
sync
Informs the BSG that the

UE context has been
handed over. The BSG
can use this to trigger
the update of streams
from the old BSR to the
new one
bsgap_ueRegistrationResponse()
bsrap_ueContextRelease()
dpat_BindingUpdateRequest()
dpat_BindingUpdateResponse()
rrc_radioBearerReconfigurationComplete()
Call Flow: Femto to Femto Handover Prep. fails

X:UE
Source:BSR
:BSG
Target:BSR
Call Established
bsgap_bsrLookupRequest()
bsgap_bsrLookupResponse()
alt
[Target BSR Failure]

CanTm(Trelocprep)
bsrap_handoverPreparationFailure()
[Source BSR Failure]

Tm(Trelocprep)
bsrap_handoverCancel()
Target BSR
cannot
allocate
resources to
support
incoming HO
Handover message IEs first stab

Handover Request
Message Type
Target BSR ID ? useful as a double check to prevent errorenous HOs ?
Source BSR UE Context id = (Iu Signalling Connection Id)
RAB context
Includes UL IuUp Endpoint and/or UL GTP Tunnel Endpoint etc
RRC Context
Includes IMSI, URNTI, Establishment Cause, Security info etc
Handover Request Acknowledge

Message Type
Source BSR UE Context Id
Target BSR to Source BSR Transparent container
List of RABs Setup and Failed
UE Context Release
Existing Protocol Updates Required for Femto Femto Handover

Existing Protocols
DPAT supports user plane handover with dpat_binding_update()
STRM-MGR supports control plane handover with STRMGR-REDIRECT control message
BSGAP
Will need to be extended for BSR lookup to BSG for determining IP Address of Neighbour/Target Femtos
UE Identifiers during Handover

IuSignallingConnectionRef
Currently implementation:
Allocated by source BSR containing:
BSRId + 7 bit context id
For CS, BSR uses all 128 context ids based on a round robin (no check
is made of currently used values)
For PS, BSR allocates only 4 contexts ids based upon UE context
Iu signalling connection identifier is transferred to target BSR during HO
7 bits are sufficient for each Source BSR to support 124 Handed out CS
calls, no change required
PS allocation scheme will need to be updated when PS HO supported
Mechanism for reallocation of Iu signalling connection identifier is
available (needs to be checked if implemented in the BSR/BSG).
Restriction on URNTI
Reassignment of U-RNTI is part of the hard handover procedure
Restriction on UL Scrambling Code

Reassignment of UL SC is part of the hard handover procedure
Femto-Femto Signalling Transport

Inter-Femto signalling will use SCTP associations
Permanent associations to all Neighbour Cells
Dynamic associations would increase latency
Long Keep alive/Heartbeating used to ensure Neighbour Cell still available

Increases in signalling traffic will be reduced by only keeping SCTP associations active for a limited time, if no
inter-BSR signalling occurs, association will be released and reestablished when required
Distribution of Neighbour Femto IP address information

Will be performed during AC/SO
Will need to be refreshed if an SCTP association fails (may indicate IP address of Neighbour Cell
has changed)
NOTE: Get icebreakers to prototype speed of setting up SCTP connection to determine if
permanent or dynamic associations should be used
Procedural Constraints
Source and Target Femto will use a common static radio configuration to minimise
the amount of data passed between source and target.
Note information on whether RAB is CS Voice and CS Data will need to be passed
DL Core Network Signalling will need to be buffered and forwarded during handover
Note some messages e.g. common id do not get acknowledged or repeated
UL Core Network Signalling messages will not need to be buffered (this was required
for the micro as the micro contained the SGSN, for the Femto UL NAS messages can
be sent directly to the CN.
When should BSGAP UE registration be performed?
If IMSI is known UE Registration from the BSR to the BSG will be performed following reception
of RRC complete message in target to reduce complexity in Failure scenarios
Manual Provisioning of Femto Neighbour Cell Information

Manual Provisioning will be provided in the FMS as a fallback to handle
unusual environments:
The FemtoBSR will be provisioned to use either the manually entered
neighbour cell information or provisioned to use the neighbour cell
information detected during autoconfiguration and self optimisation
Allocation of Areas to investigate

Configuration/BSR discovery/Coverage/Self Optimising Network All + Network Planning
PSC Allocation
Neighbour Cell Detection
Detailed Handover Algorithm (SRS) Clive

Detailed Handover Procedure (SRS) Graham/Nigel
Detailed New and Modified Protocols (SRS)- Graham
Simulation/Prototype Huiyu/Mark Freynet
FTS (Handover Algorithm & Procedures) Karl Ludwig
Interactions with Group Feature Richard Byatt
Impacted Requirement Documents

- FTS-75495:
KLW, Draft ready for review 5 Sept
- SRS-FBSR-HO:
New document with detailed F-F HO algorithms & procedures
- SRS-FBSR-MM:
No impact, if no change in SIB 11 needed (CWV)
- SRS-FBSR-Data:
Add new data for F-F HO, Neighbour Cell info etc
- SRS-FBSR-IPTS:
Add FBSR-FBSR transport requirements
- SRS-FBSR-RRM:
Add additional autoconfig., self opt., coverage, PSC allocation

algorithms and procedure and call admission control for handover
- SRS-FBSR-BSG-Interface:
Add additional BSGAP IE's/messages for support of BSR lookup

(check also if STRMGR can be used as is)
- SRS-FBSR-FBSR-Interface:
New document detailing BSRAP
- SRS-BSG-CP:
Add requirements for BSG passing additional information for HO
- SRS-FBSR-PMC:
Add PMs and KPIs for Handover
- SRS-FBSR-SEC:
Add requirements for ciphering/IP in the target during/after HO
Backup
Inter-BSR Routing for Femto-Femto Handover

Femto-Femto Handover appears as SRNS Relocation to
the FemtoBSR
Call based Information is passed between the source and target
FemtoBSR for preparation and during handover
Requires Discovery of IP Address for Target BSR
Requires Security for transport of Inter-FemtoBSR signalling
Core Network (MSC/SGSN)
Solution 1 Femto-Femto Signalling over Local Network

Only applicable to Femtos located on the same local area network
Advantage: Messaging will be faster due to local routing
Discovery of Target FemtoBSR IP Address
Dynamic DNS/DNS Lookup based upon BSRId
Or other Service based discovery: Multicast DNS,
Service Location Protocol (SLP), Simple Service
Discovery Protocol (SSDP), DNS Service Discovery
(DNS-SD)
Inter-BSR Security use IPSec in transport mode

May not be required for local network
May be possible to tunnel through an existing VPN for
handover through public network
BSG
BVG
Solution 2 Femto-Femto Signalling through Brick
IpSec
Brick Router
Applicable to both Enterprise and Residential Femto

Advantage: More Generic solution, avoids local routing
Discovery of Target FemtoBSR IP Address
BSR
BSR Lookup to BSG based upon BSRId at BSG

Or Dynamic DNS to MOP DNS Server
InterBSR Security will use existing IPSec tunnels to Brick

Requires Brick to support routing between
IPSec tunnels
Chosen Solution:
Femto-Femto signalling through Brick chosen as a more generic solution (avoids
requirements for local network routing)
Direct
Indirect
UE
BPG
BSR
BSR Address Discovery Determination of IP Address for Target BSR

Options:
Multicast DNS (mDNS)
Dynamic DNS
+ Extends on dynamic DNS

- Requires server (as Dynamic DNS)
Open source: Avahi, Howl
Simple Service Discovery Protocol (SSDP)
+ IETF Service Discovery protocol

+ Scalability
- Would require addition on SLP Directory Agent to avoid multicast issues
Open source: openSLP
DNS Service Discovery (DNS-SD)
+ Can be extended to DNS-SD in the future

- Cannot rely on Dynamic DNS server being supported in an Enterprise environment, may introduce security issues
- Would require additional of dynamic DNS Server in Femto cluster (BSG?)
Service Location Protocol (SLP)
- Not suited to large networks due to multicast
- More complex than DNS-SD

- Not Standardized
- Requires central directory to avoid multicast
Target BSR Address Lookup on BSG
+ Extends existing BSG registration functionality

+ Avoids adding dynamic DNS functionality
- Not standards based solution
Chosen Solution:
Types of Handover supported

The types of Handover to be considered are as follows:
CS+PS Handover
Adds additional Development and Test scenarios
Example: Target FemtoBSR has insufficient resources to support CS+PS RAB at current rate/transport
Not Requested by PLM

CS Only Handover
Sim. Bearer cases have commonality with Femto-Macro HO (PS is released prior to Handover)
KPIs need to be reduced to consider call drops caused by the additional time to release the PS Call prior to
HO
Signalling only
This may be required to avoid call drops during call setup and SMS failures
Proposed Solution:
Only CS (signalling only or CS + RAB) handover will be supported due to complexity of supporting
simultaneous CS+PS Handover
Inter-BSR Signalling: BSRAP

BSRAP
Format as BSGAP and Micro BSRAP, TLV message format
HO Messages derived from Micro BSRAP, BSRAP is a new protocol with new messages
and information elements; RANAP/X2AP is only used to identify the required
information to be transferred between BSRs.
RRC container is ASN.1 encoded according to TS 25.331
Single handover transaction for simultaneous CS and PS handover
BSRAP uses a transaction reference to support connection oriented

signaling and connectionless signaling.
Connectionless: Every message includes source BSR-Id (cluster-id?)
Connection oriented messages: Every message includes BSR-Id and U-RNTI or
another U-RNTI independent reference(?)
Point to point protocol between two BSRs.

No value in use of X2AP besides message names.
DPAT Protocol Changes (if needed)

DPAT security check prohibited the HO of the user plane, check was removed in BCR2.1
Proposal, if DPAT check is again needed in BCR2.2:

BVG DPAT change would be needed for BCR2.2, BPG would not be impacted in BCR2.2
Same change shall be applied both BVG and BPG DPAT now!
BCR2.1 DPAT Binding Update Request message:
MSC user plane IP address

MSC user plane port
BSR user plane IP address (Check: must be equal to Source IP address)
BSR user plane port
BCR2.2 DPAT Binding Update Request message:
MSC user plane IP address

MSC user plane port
BSR user plane IP address (no check anymore)
BSR user plane port
Verification IP address (Check: must be equal to Source IP address)
Brick checks always the Verification IP address
No HO: BSR user plane IP address and Verification IP address are identical
HO: Target BSR populates Verification IP address field with the source BSR address. Source BSR
provides the IP address in the handover request message.
The value of the DAT security check is questionable and should not be introduced again.
Call Flow: Femto to Femto Handover of a CS connection
UE
Source BSR
Target BSR
BSG
1. UE has established a call via Source BSR

CS Control Plane
2. HO Trigger
Release PS call if present
3. BSRAP: BSR Handover Request
4. BSRAP: BSR Request Handover Acknowledge
5. RRC: Radio Bearer
Reconfiguration
86. BSRAP: BSR Forward SRNS Context Acknowledge
7. Air interface synchronisation
8. RRC: Radio Bearer Reconfiguration Complete
9. STRMGR: Stream Redirect
10. BSRAP: BSR UE Context Release
Control Plane has been

switched to target BSR
BVG
MSC
Call Flow: Femto to Femto Handover of a CS calls

UE
Source BSR
Target BSR
BSG
BVG
1. UE has established a call via Source BSR

CS Control Plane
CS User Plane
2. HO Trigger
Release PS call if present
3. BSRAP: BSR Handover Request
4. BSRAP: BSR Request Handover Acknowledge
5. RRC: Radio Bearer
Reconfiguration
6. BSRAP: BSR Forward SRNS Context

7. DPAT User Plane Binding Update
8. BSRAP: BSR Forward SRNS Context Acknowledge

9. Air interface synchronisation
10. RRC: Radio Bearer Reconfiguration Complete
11. STRMGR: Stream Redirect
12. BSRAP: BSR UE Context Release
User Plane has been

Control Plane has been

MSC
Autoconfiguration information from Holger Claussen

(1) If the same sequence is transmitted repetitively (e.g. pilot) and a femtocell cannot decode the relevant
information by looking at one copy of the received sequence due to interference or noise, it is possible to combine
measurements over several copies of the same sequence and thereby averaging noise and interference and
improving the chances for the femtocell to decode the information. This could increase the sniffer range sufficiently
to pick up neighbouring femtocells that are further away. As a result it can be prevented that a femtocell selects
the same scrambling code as a neighbouring femto. In addition a femtocell could then detect if two neighbouring
femtos use the same scrambling code and notify them to change. For this it needs to be checked if the relevant
information is transmitted in a repetitive or predicable manner.
(2) If (1) is for some reason not feasible, measurements of connected mobiles can be used in addition to sniffer
measurements to detect the scrambling code of neighbouring cells. If a neighbouring cell uses the same scrambling
code the UE performance will probably be impacted measurably when moving towards the edge of the cell, which
can be detected and can trigger a change in the femto scrambling code.
If several femtocells that are registered for the location share the same scrambling code a femtocell needs to find
out the cellID of a neighbour cell that was identified by mobile measurements (which cannot report the cellID). This
can be solved by contacting each femtocell with the same scrambling code registered for the location, triggering a
wireless response (e.g. a short characteristic change in its pilot power) which can be measured and reported by a
connected mobile. If the wireless response could be detected the cellID of the neighbour is known, otherwise the
next potential femto is contacted in the same manner. This also allows to identify if two neighbours use the same
scrambling code.
In addition to the scrambling code allocation problems, you will need a solution for the joint coverage optimization
of multiple femtocells. We have started to look at this problem already in the context of trying self-evolving
algorithms. Please find attached a brief overview including a video that shows one example of a distributed
coverage optimization.
BSR Discovery (1)

Femto BSR requires knowledge of neighbour cells to setup
measurements in the UE.
Concern:
Neighbour Femto Cells may not be detected by sniffer (Cell x may
not be able to detect Cell y if cell edge y does not overlap cell
centre x, but mobile could handover between x and y).
Proposition: (needs to be verified by simulations)
In order to provide contiguous coverage the distance (d) between
two Femtos is limited (deployment rule, e.g. d <= 30m)
Due to the high sensitivity of the 3G sniffer at least one of the
BSRs can decode the SIB of the other BSR, if the deployment
rules have been applied.
Possible solution:
BSR x has detected BSR y. BSR x informs BSR y: You are my
neighbour.
BSR y checks, if BSR x is already in the BSR neighbour list:
Yes: no action.
No: add BSR x to the BSR neighbour list.
30 | Femto-Femto
The procedure
is performed regularly by all
by all BSRs in the
Handover | August 2008
group.
Femto Neighbour Cell Coordinated Sniffing

Issues
Femto Sniffing can take up to five minutes per Femto
Coordinated Sequential sniffing could take over 4 hours for a 50 Femto group
Coordinated non-group sniffing would be unmanagable
Femto Sniffing is restricted to the non busy hour

Coordinated Simultaneous sniffing would impact enterprise coverage
Non-busy hour for an Enterprise environment is more difficult to generalise, e.g.
Some Femtos will be used (meeting room) 9-5, others Femtos will be used (security office, lab, call
centre) over 24 hours.
Conclusion:
Advanced Coordinated Sniffing Algorithms will be considered in a later release
Inter-BSR Signalling Requirements - X2 interface protocol structure

SCTP transport layer for Control plane
single association per X2 interface 1 pair of streams for common procedures, few pairs for
dedicated procedures
GTP-U for User plane

Radio
Network
Layer
Control Plane
Transport
Network
Layer
Transport Network
User Plane
User Plane
User Plane
PDUs
X2-AP
Transport Network
User Plane
GTP-U
SCTP
UDP
IP
IP
Data link layer
Data link layer
Physical layer
Physical layer
Inter-BSR Signalling Requirements - X2AP overview

ASN.1-PER encoded
More similar to RANAP, RNSAP etc than GTP-C
Bare minimum of messages & procedures
Supports following functions
Mobility management
Load management
Reporting of General Error situations
Setting up and Resetting of the X2
Not all functions relevant to BSR

Relevant messages and IEs do not match BSRs requirements 100%
Inter-BSR Signalling Requirements - Options

1.
Use combination of X2AP & RANAP as high level basis for new BSRAP
Use X2AP message names and RANAP IEs where approriate
E.g. Handover Request, Request Acknowledge
Add new IEs and messages for BSR specifics where appropriate
Decide on whether to use single HO message for both CS & PS or separate ones
X2AP does not differentiate between CN nodes, only differentiates between which MME to use from the MME
pool
X2AP has Setup & Configuration Updates messages which could be used for exchanging Neighbour cell info.
etc
2.
Use cutdown RANAP as high level basis for new BSRAP
Base HO message on Relocation Request message
Decide on whether to use separate Relocation Requests for CS & PS or combine ?
How to perform tear down on Source BSR ?
Chosen solution:
.
For alignment with standards, X2AP message names will be used when available.
Femto-Femto handover Sequence Diagram Control Plane

:UE
source:BSR
:BSG
:BVG
:BPG
Target:BSR
Call Established
Based upon measurements source fBSR determines
that fBSR-fBSR Handover is required
Source BSR determines IP address of
target BSR from lookup in BSG. Target
Address will be inner tunnel IP address
bsgap_bsrLookupRequest(targetBsrId)
bsgap_bsrLookupResponse(targetBsrIpAddr)
Source BSR provides current BVG and

bsrap_relocationRequest(mscMgwUserPlaneIPAddress/Port, SGSNUserPlaneIPAddr/SGSNTEID)
BPG information to Target BSR.
Message will route through IPSec tunnels
bsrap_relocationCommand()
via Brick
rrc_RadioBearerReconfiguration()
bsrap_relocationSRNSForward()
Source BSR sends current user plane information

(GTP SN, DataVolReport, IuUP SN, RTP SN) to
Target.
Target BSR configures radio resources

and returns reconfiguration information
to source BSR
Target BSR will setup user plane based upon

received info to ensure handover is transparent
to CN (e.g. CN will not expect to perform IuUP
init)
Source BSR will buffer DL RANAP Traffic

Air Interface Synchronisation between UE and Target BSR
Source BSR will forward DL RANAP messages (or
send empty message to indicate no RANAP
messages)
bsrap_relocationDetect()
bsrap_forwardData(RANAPMessageSeq)
Target BSR updates binding at BVG/BPG
to route through target IPSec tunnel
dpat_bindingUpdateRequest(mscMgwUserPlaneIpAddress, bsrUserPlaneIpAddress, mscMgwPortNumber, bsrPortNumber)
dpat_bindingUpdateResponse(virtualMscIpAddress, virtualMscPortNumber)
dpat_gtpuBindingUpdateRequest(SGSNUserPlaneIPAddress, SGSNUserPlaneGTPUTEID, FBSRUserPlaneIPAddress)
dpat_gtpuBindingUpdateResponse(virtualSGSNUserPlaneIPAddress, VRNCUserPlaneGTPUTEID)
rrc_radioBearerReconfigurationComplete()
strmgr_controlPdu(flag, sequence, command{STRMGR-REDIRECT}, oldIpAddress, oldStreamId)
Target BSR redirects BSG stream from

source BSR
strmgr_dataPdu(flag{END}, sequence, length, body{Empty})

source BSR releases UE
context
bsgap_ueRegistration(hdr, imsi, sendUeDeleteIndFlag)
Target BSR Registers UE
Femto-Femto Handover Sequence diagram User Plane

:SGSN
:BPG
source:BSR
Target:BSR
No user plane
Setup Initial Call Setup to source BSR
ranap_rabAssignmentRequest(SGSNUserPlaneIPAddress, SGSNUserPlaneGTPTEID)
dpat_gtpuBindingUpdateRequest(SGSNUserPlaneIPAddress, SGSNUserPlaneGTPUTEID, sourceFBSRUserPlaneIPAddress)
dpat_gtpuBindingUpdateResponse(virtualRNCUserPlaneIPAddress, virtualRNCUserPlaneTEID, virtualSGSNUserPlaneIPAddress)
ranap_rabAssignmentResponse(virtualRNCUserPlaneIPAddress, virtualRNCUserPlaneTEID)
User Plane established to source BSR
sourceIP: SGSNUserPlaneIPAddress
destinationIP: virtualRNCUserPlaneIPaddress
GTPHeader: virtualRNCUserPlaneTEID
DLUserDate()
sourceIP: virtualRNCUserPlaneIPAddress
destinationIP: SGSNUserPlaneIPaddress
GTPHeader: SGSNUserPlaneTEID
sourceIP: virtualSGSNUserPlaneIPAddress
destinationIP: sourceFBSRUserPlaneIPaddress
DLUserData()
ULUserData()
ULUserData()
sourceIP: sourceFBSRUserPlaneIPAddress
destinationIP: virtualSGSNUserPlaneIPaddress
Relocation Request:
source passes: SGSNUserPlaneIPAddress,
SGSNUserPlaneGTPTEID
dpat_gtpuBindingUpdateRequest(SGSNUserPlaneIPAddress, SGSNUserPlaneGTPUTEID, targetFBSRUserPlaneIPAddress)
dpat_gtpuBindingUpdateResponse(virtualRNCUserPlaneIPAddress, virtualRNCUserPlaneTEID, virtualSGSNUserPlaneIPAddress)
User Plane established to target BSR
sourceIP: SGSNUserPlaneIPAddress
destinationIP: virtualRNCUserPlaneIPaddress
sourceIP: virtualRNCUserPlaneIPAddress
destinationIP: SGSNUserPlaneIPaddress
DLUserData()
sourceIP: virtualSGSNUserPlaneIPAddress
destinationIP: targetFBSRUserPlaneIPaddress
DLUserData()
ULUserData()
ULUserData()
sourceIP: targetFBSRUserPlaneIPAddress
destinationIP: virtualSGSNUserPlaneIPaddress
Ongoing Femto Group Neighbour Cell (FGNC) Information for Handover

Advanced Algorithms for a future release
Each Femto maintains a list of its FGNCs with state:
Unknown
Detected
Unknown
Detected PSC & CellId, confirmed in Group by BSG
Informed
One Way visibility detected by a neighbour cell (you can
see me but I cannot see you)
Detected & Informed

Suspect
Handover Success/Failure ratio indicates suspect FGNC
FGNCs have Time to Live (TTL)

Refreshed every detection/inform event
On expiry detected/informed state is removed
TTL needs to consider interval between completed
SO events
TransferFGNC(psc)
Detected
Det_TTL Expiry
TransferFGNC(psc)
Detected
Inf_TTL Expiry
Detected
Detected
&
Informed
Det_TTL Expiry
HOsuccfailcnt < Thresh

Suspect
Det_TTL Expiry && Inf_TTL Expiry
Handover events will be monitored using HOsuccfailcnt

Incremented for successful handovers
Decremented for unexpected UE failed handovers
E.g. HO Failure to closed access BSR is expected
If a low threshold is reached, FGNC is changed to

Suspect and Handover will not be performed
Detection/Inform of a Suspect Cell changes cell
stateHandover
and resets
HOsuccfailcnt (to a lower initial
37 | Femto-Femto
| August 2008
value).
Informed
TransferFGNC(psc)
Detected
At each SO event, TransferFGNC(psc) will be performed

to detected FGNCs
Will pass current PSC information (which may have
changed as a result of SO) and NNC info
Inf_TTL Expiry

Femto-Femto HO Chalk Talk

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Femto-Femto HO Chalk Talk

Caricato da

Copyright:

Formati disponibili

Femto-Femto Handover Feature 75494

Only Intra-Cluster Handover supported

Core Network (MSC/SGSN)

Rerouting of signalling plane to target BSR in BSG

Manual Provisioning should be minimal

Manual Provisioning will be provided for fallback

Handover procedure needs to be fast

Handover will use UE Measurement based algorithm

Target FemtoBSR will support Pre-emption, dropping lower

Pre-emption at the target may introduce latency to the procedure but

Handover is for CS only (Sig only and Sig + RAB)

All Rights Reserved Alcatel-Lucent 2006, #####

Example Femto to Femto CS Handover

3. BSRAP is used for the Relocation

5. STRMGR binding is switched,

All Rights Reserved Alcatel-Lucent 2006, #####

Network Architecture Overview

Target BSR Address Discovery & Routing

Existing Protocol updates for support of Femto-Femto handover

4 | Femto-Femto Handover | August 2008

All Rights Reserved Alcatel-Lucent 2006, #####

BSR Network Topology Discovery

FemtoBSR performs Neighbour Cell Detection for Femto PSCs and

FemtoBSR passes own cell and neighbour cell information

Neighbour Cell Information

used for PSC-Allocation, Coverage and Femto-Femto Handover

Neighbour Neighbour Cell Information

2. BSR obtains group

FemtoBSR obtains neighbour cell group information

FemtoBSR performs Neighbour Cell Information Transfer to each

FemtoBSR determines neighbour cell list

FemtoBSR performs Group Id Query procedure with BSG for

used for PSC Allocation, Coverage Algorithm

5 | Femto-Femto Handover | August 2008

All Rights Reserved Alcatel-Lucent 2006, #####

3. BSRs exchange NC and NNC info

PSC Allocation for Handover

If BSR 2 has two neighbours with the

PSC issue is a group deployment issue and should be covered under

Group Femto Coverage

Large number of Detected Femto Group Neighbour Cells indicates:

Small number of Detected Femto Group Neighbour Cells indicates:

Overlap thresholds algorithm will consider:

7 | Femto-Femto Handover | August 2008

All Rights Reserved Alcatel-Lucent 2006, #####

Ongoing Femto Group Neighbour Cell (FGNC) Information for Handover

Detected PSC & CellId, confirmed in Group by BSG

Detected & Informed

FGNCs have Time to Live (TTL)

At each AC/SO event, TransferFGNC(psc) will be

All Rights Reserved Alcatel-Lucent 2006, #####

Inter-BSR discovery and routing

9 | Femto-Femto Handover | August 2008

All Rights Reserved Alcatel-Lucent 2006, #####

Inter-BSR Signalling Requirements

Inter-BSR signalling stack

10 | Femto-Femto Handover | August 2008

All Rights Reserved Alcatel-Lucent 2006, #####

Call Flow: Femto to Femto Handover of a CS connection

[PS RAB established]

[Target BSR has no free resources and lower priority exists]

Informs the Source

Informs the BSG that the

11 | Femto-Femto Handover | August 2008