local switching for packet abis

Slide 1* © Nokia Siemens Networks Local Switching for Packet Abis / A. Macioek / April 2010
For internal use only
Logo is aligned right to reflect the corporate stationery.
* © Nokia Siemens Networks Local Switching for Packet Abis / A. Macioek / April 2010
NWS LTE RA E2E Mgmt SA NE GSM&LTE Migration
February 2011
BSS21327
Please always use the latest version of the materials which can be found under the link:
1.unknown
BSS21327
Feature Dependencies
Database Parameters
Performance Measurements
Table of Contents
BSS21327
1.1
18.02.2010
Dimensioning aspects considered in details with the packet Abis calculator. Some open issues resolved.
1.2
12.04.2010
Review comments considered (NWS EP RP TAS NT Transp Solutions – Rolf Siekmeyer, GS MS NPO CaDe – Raimo Ahosola, Pal Szabadszallasi). Open issues resolved.
1.3
26.04.2010
Clarification on max number of E1/T1 lines supported by a hub-BTS (max changed from 16 to 8)
2.0
29.04.2010
2.1
16.06.2010
2.2
08.10.2010
Updated KPI names according to the approved S15 KPI list
BSS21327
-
Background Information
Normally, MS-to-MS calls are always transferred through all network elements of the GERAN network, i.e. BTSs, BSCs, trans-coders and a core network
This is also the case for calls established between terminals served by the same cell, co-sited cells or cells served by a common BSC
Local Switching for Packet Abis
Calls and related signalling are transferred through all network entities
According to statistics, in ‘isolated areas’, e.g. in remote towns and villages, even up to 95% of calls is established locally
As a result, it can be imagined that such calls would not be transferred to the network elements beyond the BTS thus saving Abis resources
Such the concept, known as local switching, is valid for speech data only => signalling data would be transferred ’traditionally’ to allow using existing features => otherwise, a completely new control plane concept had to be invented
Local switching does not apply to PS calls as well because normally a PS call is established ’non-locally’ between MS and a server (GGSN) and not between two MSs
BSC1
BTS1
MSC1
TRAU1
MSC2
TRAU2
BSC2
BTS2
MS1
MS2
Speech
Signalling
E1/T1
Abis
No solutions supporting local switching
Solutions operating with the legacy E1/T1 Abis interface => new dedicated HW (RGW, CGW) must be installed to support local switching:
BSS21436/BSS30370 Local Switching for Satellite Abis/Terrestrial Abis
Up to 8 E1/T1 links (16 E1/T1 links) or up to 60 TRXs (16 RGW) supported by RGW (CGW)
Up to BSS13 ED
Aggregating and switching local traffic
E1/T1
E1/T1
E1/T1
Abis
Abis
For locally switched calls only signalling is conveyed to BSC
A completely new implementation fully relying on the packet Abis is introduced without involving equipment of external vendors:
BSS21327 ”Local Switching for Packet Abis”
RG25 (BSS)
Feature Details
Feature Details
In RG25 local switching means a possibility to transfer MS-to-MS voice calls originated and terminated by the same BSC directly between involved BTSs without going through the controlling BSC:
Speech data is directly switched between the involved BTSs
Signalling/PS data is transmitted through all network entities => there is no impact of the local switching on conveying signalling/PS data
Packet Abis is a must => legacy E1/T1 between BTS and BSC is not allowed with the RG25 local switching
There are two main configurations of the local switching:
Intra-BCF local switching => two terminals are served by the same BTS (BCF) => the call can be switched internally by the BTS (BCF)
Inter-BCF local switching => two terminals are served by different BCFs belonging to the same BSS and to the same local switching area => the voice call is directly transferred from one BTS (BCF) to another BTS (BCF) without involving the BSC
Feature Details
Speech and signalling
Switching local traffic
Feature Details
Packet Abis over TDM
hub-BTS
IP network
Feature Details
A locally switched voice call can be established in a so-called local switching area
The local switching area is built up of up to 16 sites including a hub-BTS (packet Abis over TDM) and is identified by the packet Abis BCF group ID (PABGID)
Any two local switching areas must not overlap with each other, i.e. a site cannot belong to any two local switching areas
Speech data of locally switched calls is transported between the involved sites without engaging a BSC
Signalling/PS data is managed in a ‘traditional way’ irrespectively of the local switching functionality
Local Switching Area (1/2)
Feature Details
In case of the intra-BCF local switching the area consists of a single BCF only
In case of the inter-BCF local switching the area consists of few BCFs, out of which one must operate as a hub-BTS (packet Abis over TDM)
PABGID = 2
Up to 16 BTSs in the LS area including hub-BTS
Local switching area with inter-BCF locally switched calls
Local switching area with intra-BCF locally switched calls only
Each BCF creates a LS area
PABGID = 1
PABGID = 3
PABGID = 0
PABGID = 0
PABGID = 0
PABGID = 0
Local switching areas with inter-BCF local switching
PABGID = 0
Feature Details
Hub-BTS is a mandatory network element of the local switching with the inter-BTS local switching and packet Abis over TDM
The hub-BTS is a fully equipped BTS acting also as a site of the local switching area with the IP forwarding functionalities
The following IP forwarding functionalities are supported by the hub-BTS:
Aggregating IP packets arriving from BTSs of the local switching area and forwarding them outside to a BSC (non-locally switched calls) or inside to other BTSs of the local switching area (locally switched calls)
Receiving IP packets from the BSC and forwarding them to the BTSs of the local switching area (non-locally switched calls)
Handling IP packets from the BSC if they are dedicated for the hub-BTS
The hub-BTS is not required in a configuration for the intra-BTS local switching or with the packet Abis over Ethernet
Hub-BTS (1/3)
Feature Details
A hub-BTS is connected to a BSC with the packet Abis over TDM
The same interface type, i.e. TDM, must be used between BTSs of a given local switching area and the hub-BTS => mixture of the Ethernet/TDM links is not allowed
The hub-BTS connected to the BSC/BTSs stores a routing table, i.e. a list of IP addresses assigned to BCFs of the local switching area and their corresponding ML-PPP bundles => the routing table is created according to the content of the SCF (Site Commissioning File) file sent by a BSC to the hub-BTS
Hub-BTS (2/3)
No longer valid for BSS15 according to the latest SFS approved (version 1.2.0). Points below removed from the slide.
All the BTSs must be connected to the hub-BTS using the same interface type, i.e. either packet Abis over Ethernet or packet Abis over TDM => mixed configuration of the interface types is not allowed
The hub-BTS is able to convert the TDM traffic to Ethernet traffic (and vice-versa) if different interface types are applied to connect a BSC with a hub-BTS and the hub-BTS with BTSs of the local switching area
The hub-BTS must recover synchronisation from the Ethernet backhaul to the TDM backhaul in case the packet Abis over TDM interface is configured to connect the hub-BTS with the BTSs of the local switching area
hub-BTS
BTS1
BSC
Few HDLC links are bundled in a single ML-PPP bundle
HDLC(3)
HDLC(1)
Feature Details
Hub-BTS (3/3)
Up to 8 HDLC links can be configured in a single ML-PPP bundle
Up to 68 HDLC links (due to memory limitations) can be configured in total for all ML-PPP bundles (in a hub-BTS)
Up to 16 ML-PPP bundles can be served by the hub-BTS
Up to 8 E1/T1 lines terminated at a hub-BTS
ML-PPP (4)
ML-PPP bundle
Grooming @ BTS2 => BTS2 and BTS3 connected to the hub-BTS on a single E1/T1 interface, but with direct ML-PPP bundles
192.168.0.103
ML-PPP(4)
192.168.0.101
ML-PPP(3)
192.168.0.100
ML-PPP(2)
BTS3
192.168.0.103
Feature Details
In case of the packet Abis over Ethernet each BTS (BCF) of the local switching area has a list of other BCFs located in the same local switching area and IP addresses associated with the particular BCFs
The hub-BTS is not needed as each local BCF is aware of other local BCFs belonging to the same local switching area according to the list
Local Switching with Packet Abis over Ethernet
White-list of BCF IDs and IP addresses exchanged inside LSA
IP network
Local switching area configuration with the packet Abis over Ethernet
* - CS U-plane IP addresses
Feature Details
BTS2
192.168.0.100*
BTS1
192.168.0.101*
Feature Details
Lawful Interception
The operator may request to intercept also locally switched calls
A BSC contains a database with up to 150 000 records with MSISDN numbers of subscribers to be intercepted
During the local call detection procedure the BSC sniffs the MSISDN of the MS originating or terminating the call from the DTAP signalling messages
If the match is found in the database the locally switched call is to be intercepted:
The local switching is disabled for the call being established or…
… the call is locally switched (to maintain the same user perception in terms of the end-to-end speech delay), but copies of the locally switched speech frames are sent to MSC via BSC and TCSM/MGW
=> the behaviour depends on the BSS database parameter settings (see slide 55)
Feature Details
In general, TrFO (Trans-coder Free Operation) is a functionality allowing for transmission of speech frames between MSs without trans-coding at MGW when the same codec type is used by MSs at both connection ends
The differences between the TrFO and TFO* (Tandem Free Operation) are:
TrFO employs an out-of-band signalling whereas the TFO operates with an in-band signalling (some bits in speech frames are stolen to convey signalling)
TrFO is executed with the A over IP and trans-coding done at MGW (core side) whereas TFO runs when trans-coding is done at TCSM (BSS side)
A call setup is completed after the codec negotiation by TrFO is finished => extra delay (to be measured in tests) in a call setup procedure is expected; the codec negotiation by TFO is started just after the call setup is completed => no extra delays
With TrFO only radio codec + header bits are transmitted => bandwidth savings; with TFO also G.711 bits are transmitted on the MSB (Most Significant Bits) bits => no bandwidth savings
For more details please refer to NEI BSS21341 ”A over IP”
TrFO with Local Switching (1/4)
* - see BSS14 NEI slides ”AMR Wideband & TFO” (BSS20960, BSS21118) https://sharenet-ims.inside.nokiasiemensnetworks.com/Download/409226619
Feature Details
Due to the fact that local switching calls are established directly between the BTSs without involving trans-coders the TrFO operation is the only option for the locally switched calls, i.e. there is no room for trans-coding functionalities in the local switching transmission chain
TrFO negotiation is done between the involved BCSUs (not in MGW)
Therefore, the same speech codec type and the same active codec set (in case of AMR) must be applied to both connection ends to successfully establish a locally switched call
The following speech codec types are supported with the local switching: EFR, FR, HR, AMR-NB FR, AMR-NB HR and AMR-WB
The same codec type must be used in DL and UL directions
Link adaptation (in case of AMR) is done considering radio conditions at both connection ends => the worse radio conditions forces the use of more robust codec mode
Feature Details
The only supported AMR-NB codec modes are 4.75, 5.9, 7.4 and 12.2 kbps (the ”Config-NB-Code-1” codec modes configuration):
If other codec modes are configured at the connection ends the TrFO is not possible => the establishment of the locally switched call is not possible
TrFO is possible on a locally switched call with AMR-NB codec modes operating in FR at one connection end and in HR mode at another connection end as long as 4.75, 5.9 and 7.4 kbps codec modes are on-air => AMR packing/unpacking can work with the locally switched calls
Before a locally switched call is established between two MSs served by BTS(s) of the local switching area, BCSUs serving the involved BTSs exchange information on supported speech codec types based on MS preference and BTS capability:
If a common codec type is found, then the local switching is possible
If a common codec type is not found, then the call is established without local switching
Feature Details
BSC
BTS1
BTS2
encoding
decoding
* - AMR-WB source bit rate of the least robust codec mode
MS1
MS2
ACS: 4.75, 5.9, 7.4
MS1BTS1 (EFR)
MS1MS2
EFR
Codec type optimisation with the channel mode modify procedure, i.e. AMR changed to EFR
FR-HR matching
local switching nok
An operator must configure the same AMR codec mode sets in all BTSs of the local switching area
IP network
MS2BTS2 (AMR HR)
MS1 does not support AMR
Feature Details
In principle, the congestion control mechanisms for the local switching act in the same way as in a ‘classical’ packet Abis network as described in the NEI for Packet Abis
The BTSBSC connections are monitored for the congestion => locally switched calls are not taken into account in BU (Bandwidth Utilisation)/PL (Packet Loss) evaluation
PL evaluation is done based on PS/CS traffic exchanged with the BSC
Local switching with the packet Abis over TDM: a hub-BTS can indicate a congestion situation to a BSC on the hub-BTSBSC interface:
The BSC replies to all local BTSs => the congestion control mechanisms affect all the local BTSs even if some of them do not really experience a congestion situation => voice quality is compromised in the whole local switching area
Local switching with the packet Abis over Ethernet: any local BTS can indicate a congestion situation
The TX queues handling is done as described in the NEI for Packet Abis with the only difference:
C- and M-plane packets forwarded to the local BTSs are never dropped
Congestion Control
Feature Details
Intra-cell HO => 3 cases are distinguished:
Between TRXs belonging to the same cell represented by the BTS object => local switching is supported after the HO
Between TRXs represented by different BTS objects, but belonging to the same cell represented by the SEG and BCF object => local switching is supported after the HO
Between TRXs represented by different BTS and BCF objects, but belonging to the same cell represented by the SEG object (multi-BCF) => local switching is supported after the HO if the BCFs belong to the same local switching area
Handovers (1/3)
intra-cell HO inside BCF
local switching NOT released
intra-cell HO between BCFs
local switching NOT released if BCFs are in the same LS area
BSS21327-302 Hub BTS configuration
BSS21327-204 IP-forwarding for a hub BTS with Ethernet backhaul
Feature Details
Inter-cell internal BSC HO:
Local switching is supported after the HO if the cells belong to the same local switching area
Inter-cell external HO:
Handovers (2/3)
inter-cell HO between BCFs
local switching NOT released if BCFs are in the same LS area
BCF-1
BCF-1
Feature Details
When selecting a target channel, if possible, a BSC selects a channel of the same type and codec (in case of AMR) as used in a source channel
Local switching is signalled to the target cell by sending the new local switching IE in the CHANNEL ACTIVATION message
Also the new IP address and the UDP port number of the target cell are signalled in the CHANNEL ACTIVATION message
Handovers (3/3)
Feature Details
Local switching is released in the following cases:
External inter-cell HO (inter-cell HO between cells belonging to different BCSs)
Internal inter-cell HO to a cell configured in a different local switching area
Intra-cell HO to a BCF configured in a different local switching area (multi-BCF)
Supplementary services are activated during an on-going call (call holding, multi-party connection, explicit call transfer and cellular text telephone modem) even if the services refer to subscribers from the same local switching area
Codec mismatch after any handover was completed
=> the call continues with speech frames transferred to MSC via BSC and TCSM/MGW
=> the call never becomes locally switched again if local switching once released
Local Switching Release
Local switching release may cause audible effects on voice quality due to an additional delay, especially in the case with the satellite backhaul
Feature Details
Connection of small/medium and isolated towns/villages to a GSM network, which are not reachable with landline transmission (microwave link difficult or not possible at all) and the only alternative is a satellite Abis
Voice traffic is a dominant service and majority of calls is established locally
Application Scenarios (1/3)
BTS
BTS
BTS
BTS
BTS
Packet Abis over Ethernet
Isolated area – small/medium town
Feature Details
Serving large traffic generated mostly among subscribers located, e.g. in the same office, campus or area
Local switching areas typically consisting of a single site
BTS
Traffic switched locally in a site
Traffic switched locally in a site
The case is justified if it leads to a reduction of PCM lines!
Lower load on TDM link towards BSC
Feature Details
Increasing PS capacity on the Abis interface serving an isolated area, especially over satellite, without the need to extend Abis capacity => locally switched traffic does not require Abis resources => the released Abis resources can be utilised in a different way, e.g. to increase bandwidth for PS services
The majority of calls is established locally
PS traffic generated by subscribers increases
Locally switched calls are not put to Abis => more room for PS calls
Feature Details
BSC: BSC3i (1000/2000), FlexiBSC
Hardware Requirements
Feature Details
Reduction of Abis transmission costs (OPEX) in an operator’s network:
Potential savings particularly significant in case of satellite links, which are very expensive
Possibility of deploying coverage for remote communities with low ARPU at a reasonable price where the only option is to use the Abis satellite links
Option to introduce new features or expand capacity of base stations without expanding the backhaul
Improved speech quality by:
Shorter transmission delays, especially in case of a satellite backhaul
No trans-coding due to removal of trans-coders from the transmission path => trans-coder free operation (TrFO) is applied
Bandwidth savings on A interface, but only with the A over IP with trans-coder (TC) in media gateway (MGW)
Benefits
Transmission is the main priority for operators in emerging markets. Transmission costs from a BTS to a BSC, either over satellite or terrestrial leased line, makes up a large percentage of the Total Cost of Ownership (TCO) of a GSM site.
Reduction of transmission costs is the key benefit for the operator. Potential savings can be particularly significant in cases where the Abis connection is using Satellite links. For operators who consider deploying additional coverage for remote communities where traditional backhaul is not an option, the Local Switching feature often makes the otherwise too expensive Satellite connectivity economically viable. Thus with Local Switching the operator may deploy coverage cost effectively where it was previously not possible.
Substantial OPEX savings can also be achieved by reducing the bandwidth requirements for BTS clusters that are connected via terrestrial Abis. The bandwidth savings with terrestrial Abis can lead to reduction of MWR license fees or leased line fees. It potentially allows the operator to introduce new features or expand base station capacity without needing to expand backhaul.
In fact the A interface connections will remain unaffected, even if a mobile to mobile call is internally switched in the BSS. In other words, two (for the two legs of the call) TDM circuits (in case of legacy TDM A interface) or two bi-directional IP flows (in case of A over IP) will be needed anyway between the TCSM and the MSC (or MGW). Only in case of A over IP with TC in MGW (i.e. without a TCSM) it shall be possible to save bandwidth of the A interface as well: in this case the A interface PGW shall only generate SID frames (instead of continuously sending speech data frames) towards the MGW for the locally switched calls, to keep the connection with the MGW alive.
Impact on Planning and Dimensioning
Impact on Planning and Dimensioning (1/11)
Summary
Local switching aims at bandwidth savings on Abis! The savings on other interfaces should be considered as a nice side-effect, but not as a reason for the feature introduction!
Interface
Realisation
Connection
Savings
Abis
Ater
TDM
BSCTCSM
”Empty” speech frames are transmitted to keep the connection alive => no savings
BSCMGW
over IP
BSCMGW
Only SID frames are sent to MGW every 160 ms for AMR-NB and AMR-WB and every 480 ms for remaining codec types to keep the connection alive => there are savings – see slide 49
TCSMMGW
IP flows are transmitted to keep the connection alive => no savings: SID frames are sent to MGW every 160 ms for AMR-NB and AMR-WB and every 480 ms for remaining codec types NoData frames for AMR-NB and AMR-WB and speech frames with the BFI (Bad Frame Indicator) set are sent for the remaining codec types
TDM
TCSMMGW
”Empty” speech frames are transmitted to keep the connection alive => no savings
In fact the A interface connections will remain unaffected, even if a mobile to mobile call is internally switched in the BSS. In other words, two (for the two legs of the call) TDM circuits (in case of legacy TDM A interface) or two bi-directional IP flows (in case of A over IP) will be needed anyway between the TCSM and the MSC (or MGW). Only in case of A over IP with TC in MGW (i.e. without a TCSM) it shall be possible to save bandwidth of the A interface as well: in this case the A interface PGW shall only generate SID frames (instead of continuously sending speech data frames) towards the MGW for the locally switched calls, to keep the connection with the MGW alive.
The Packet Abis Calculator (the Local Switching sheet) can be used to evaluate the local switching in terms of:
the Abis bandwidth utilisation
the required number of E1 lines (packet Abis over TDM variant) between a hub-BTS and BSC (inter-site local switching)..
…or between BTS and BSC (intra-site local switching) for different percentages of locally switched calls
The next slides contain work instructions, i.e. step-by-step description how to use the tool, and examples of calculation results for different modes of local switching and packet Abis realisations (over Ethernet or TDM)
Packet Abis Calculator for Local Switching
1) Select the LS mode: inter-site with packet Abis over Eth (LS over Eth), over TDM (LS over TDM), intra-site with packet Abis over Eth (ISS over Eth), over TDM (ISS over TDM)
2) Decide on the number of site configurations that are foreseen for the LS area – they are created immediately for providing further input
3) Select the configuration representing the hub-BTS (only in case of inter-site LS over TDM)
4) Specify the percentage of locally switched calls
5) Specify the number of sites for each configuration; for the configuration representing the hub-BTS only a single site can be specified (the value is hard-coded); the number of sites over all configurations cannot exceed 16
6) Specify the number of TRXs for each site configuration
7) Specify other parameters for each site configuration, in the load mode a user can type in directly the amount of traffic in Erlangs irrespective the voice distribution input
8) Specify the voice and codec distribution
9) Press Calculate
Inputs
1) Total amount of traffic served per site and by all sites of the given site configuration
2) Required bandwidth per site of a local switching area towards BSC and the required number of E1s (in case of packet Abis over TDM) towards the hub-BTS (inter-site local switching)
3) Total bandwidth required towards BSC from all sites without inter-site local switching
4) The required number of E1 lines towards BSC for all sites without inter-site local switching (in case of packet Abis over TDM)
4) Total bandwidth required towards BSC from all sites with inter-site local switching
5) The required number of E1 lines towards BSC for all sites with inter-site local switching (in case of packet Abis over TDM)
6) If the required number of E1 lines in the hub-BTS (packet Abis over TDM) exceeds 8 a warning is issued – such the configuration of the inter-site local switching is not feasible
Outputs – Inter-Site Local Switching
1) Required bandwidth per site towards a BSC and the required number of E1s (in case of packet Abis over TDM) towards the BSC without intra-site local switching
2) Required bandwidth per site towards a BSC and the required number of E1s (in case of packet Abis over TDM) towards the BSC with intra-site local switching
3) Application of intra-site local switching is recommended if the number of E1 lines towards BSC is reduced (in case of packet Abis over TDM)
4) With a single E1 line towards BSC (in case of packet Abis over TDM) application of the intra-site local switching makes no sense
Outputs – Intra-Site Local Switching
Inter-Site Local Switching with Packet Abis over Ethernet
- without local switching
- with local switching
Assumptions:
Estimated bandwidth refers to required bandwidth between BTSs and a BSC
For 2/2/2 and 4/4/4 16 BTSs in a local switching area, for 8/8/8 8 BTSs in a local switching area (to save computation time)
Up to 30% HR, no PS data
Inter-Site Local Switching with Packet Abis over Ethernet
Edge node
Edge node
IP network
L2 switch
L2 switch
L2 switch
L2 switch
L2 switch
BSC
Locally switched calls are switched outside the IP network managed by an ISP => bandwidth savings seen in the IP network provided by the ISP => savings in €
Only non-locally switched calls are transferred by the IP network provided by the ISP
To achieve bandwidth and OPEX savings in Ethernet network provided by an ISP locally switched calls must be switched outside the network managed by the ISP
IP network
1GB Ethernet switch supporting fibre optic
Locally switched calls are switched between ports of the switch without affecting the IP network provided by the ISP
Examples of network architecture for local switching
SFP* link in FIYA/FIQA
SFP link in FIYA/FIQA
* - the small form-factor pluggable (SFP) is a hot-pluggable transceiver; it can be used in L2/L3 equipment to support fibre optic links
Inter-Site Local Switching with Packet Abis over TDM
With the increasing penetration of LS calls the size of the local switching area can be increased to the upper limit of 8 E1 lines served by the hub-BTS
- max number of sites in a LS area
Intra-Site Local Switching with Packet Abis over Ethernet
Assumptions:
Estimated bandwidth refers to required bandwidth between a BTS and a BSC
Intra-Site Local Switching with Packet Abis over TDM
With the increasing penetration of LS calls the number of E1 lines between a BTS and a BSC can be reduced from, e.g. 2 to 1. For the taken assumptions this is possible starting with the 7/7/7 TRX configuration in a site.
intra-site local switching not applicable – there is no room for E1 lines reduction
intra-site local switching not applicable – there is no room for E1 lines reduction
Application of intra-site local switching (TDM) makes sense for certain LS calls penetrations and site configurations
The maximum bandwidth saving on the A interface over IP (BSCMGW) is a sum of bandwidth savings of local switching areas connected to a MGW:
lsa – local switching area => BW(lsa) – bandwidth saving of the local switching area lsa connected to the MGW
A – A interface => BW(A) – bandwidth saving on the A interface
A Interface
The maximum bandwidth savings on the A interface are reached when traffic distributions in local switching areas are identical. In practice, this assumption may not be satisfied, so the actual savings may be lower.
Packet Abis over Ethernet or Packet Abis over TDM is a prerequisite for the local switching feature
If an MS with an on-going locally switched call requests a DTM connection, an intra-cell HO is done to a packet territory (both CS and PS parts), but the local switching is maintained on the CS part after the handover
The same holds for the DTM connection requested by SGSN to the MS with the on-going locally switched call => the local switching is maintained
The local switching is also maintained in case of BSC or PCU initiated intra-cell and internal inter-cell HOs causing the DTM reallocation
The local switching is also maintained when the DTM is released => an intra-cell HO is done to the CS territory
DTM
For the capability of the local call detection the User-User Signalling (UUS) core feature (TS 22.087) must be activated
Other Dependencies
Database Parameters
Database Parameters
packetAbisBcfGroupId
New parameters
The parameter defines the identifier of the BCF group. The BCF group delimits a group of BTSs (BCFs) among which local switching is possible, i.e. among all BTSs (BCFs) having the same value of the identifier assigned. The maximum number of BTSs (BCFs) in the BCF group is 16. There are two special settings: PABGID = 65535 to indicate that local switching is not in use for the BCF and PABGID = 0 to indicate that only intra-BCF local switching is possible for the BCF, i.e. the LS area contains that specific BCF only. The first valid BCF group value indicating a real LS area, i.e. a group of BCFs among which local switching is possible, is 1.
Note: If more BCFs are configured with the PABGID set to the special values 0 or 65535, this does not mean that they belong to the same LS area. The parameter is valid only if the Abis interface connection type (AICT) is other than Legacy Abis.
object: BCF
unit: none
range: 0..3000
step: 1
default: 65535
MML abbreviated name: PABGID
MML commands (examples):
New parameters (1/2)
A list containing MSISDN numbers of subscribers to be intercepted in a core network is provided to a BSC by an operator. Up to 150000 numbers can be saved to the BSC.
object: N/A
unit: none
range: N/A
step: N/A
default: N/A
N/A
Database Parameters
lsEnabledInterceptedCalls
The parameter defines whether the local switching should be disabled or enabled for calls under the lawful interception. If the parameter is set to false, the calls to be intercepted are not locally switched even if possible, i.e. they go through the whole transmission path via BSC, TRAU/MGW and MSC. If the parameter is set true, the calls to be intercepted are locally switched (if possible), but copies of locally switched speech frames are sent to the MSC via BSC and TRAU/MGW.
object: BSC
unit: none
abisInterfaceConnectionType
The new setting is used for a BTS (BCF) connected through the packet Abis over TDM to a BSC. The BTS acts in this case as a hub-BTS for the inter-BTS local switching for the packet Abis over TDM. The new setting is applicable to the hub-BTSBSC connection only.
If the local switching area is defined for a group of BTSs (BCFs) connected through the packet Abis over TDM, the Abis interface connection type parameter should be set to “Packet Abis over TDM (Hub BTS)” for the BTS acting as the hub-BTS. In this case the PABGID parameter must be specified for the hub-BTS.
If only the intra-BTS (intra-BCF) local switching is enabled for a BTS connected through the packet Abis over TDM, there is no need to configure a hub-BTS and the Abis interface connection type parameter should be set to “Packet Abis over TDM”.
If the Abis Interface Connection Type parameter is set either to Packet Abis over TDM or to Packet Abis over TDM (Hub BTS) the HDLC parameters must be specified
object: BCF
unit: none
range: [Packet Abis Over TDM, Packet Abis Over Ethernet, Legacy Abis, Packet Abis over TDM (Hub BTS)]
step: none
MML abbreviated name: AICT
Number of successful mobile originated speech calls, which have established a locally switched speech path.
Trigger event:
When local switching establishment is successful for mobile originated calls.
001274:
MO_LS_CALL_SUCC
New counters (1/9)
Number of successful mobile terminated speech calls, which have established a locally switched speech path.
Trigger event:
When local switching establishment is successful for mobile terminated calls.
Use case:
To observe ratio of calls established locally – aggregated over the local switching area (trf_1002)
…or per BTS (with the distinction of MOC (moc_1000) and MTC (mtc_1000) calls established locally):
001275:
MT_LS_CALL_SUCC
RTP = timeslot
New counters (2/9)
Number of unsuccessful establishments of locally switched calls due to different speech codec types on local call peers
Trigger event:
Updated after a TCH allocation, when local switching cannot be established because of mismatch between chosen codec and codec used by peer.
Use case:
To observe ratio of calls not established locally due to codec mismatch between the involved terminals localised in the local switching area – aggregated over the local switching area:
…or per BTS (csf_1000):
RTP = timeslot
Number of releases of local switching due to an inter-cell handover outside a LS Area
Trigger event:
When the inter-cell handover is triggered outside the LS area for a locally switched call. This is updated before a handover command is sent to mobile.
Use case:
To observe ratio of local switching releases due to inter-cell HO outside the local switching area – aggregated over the local switching area (dcr_1000):
…or per BTS
New counters (3/9)
New counters (4/9)
Number of releases of local switching due to an external handover
Trigger event:
When an inter-BSC handover is triggered for a locally switched call. This is updated before a handover command is sent to mobile.
Use case:
To observe ratio of local switching releases due to external HO (to another BSC) – aggregated over the local switching area (dcr_1001)
…or per BTS
New counters (5/9)
Number of releases of local switching due to establishment of supplementary services, which require speech path control of an MSC
Trigger event:
When local-switching is released due to the start of supplementary services.
Use case:
To observe ratio of local switching releases due to establishment of supplementary services – aggregated over the local switching area (dcr_1002):
Number of DL RTP packets containing TRAU frames of the CS U-plane, which have been successfully received from a LS peer BCF, including packets received on time, too late and too early.
Trigger event:
Each time the DL RTP packet containing the TRAU frame of the CS U-plane from the LS peer BCF is received at a base station regardless it is received on time, too early or too late.
Description
New counters (6/9)
Number of DL RTP packets containing TRAU frames of the CS U-plane, which are missing or lost.
Trigger event:
Each time the next sequence number is missing from the RTP packet received from a peer BTS. If the gap in the RTP sequence numbers is smaller than a threshold value (100), then the counter is incremented by the amount of missing RTP packets. If the gap in the RTP sequence numbers is greater than or equal to the threshold value (100), then it is interpreted as a jump in the RTP sequence number.
Use case:
To measure packet loss rate of locally switched calls in DL from a peer BTS
132001:
CS_U_PLN_RTP_PACKT_LOST_LSBTS
(132 Local Switching Traffic)
The new measurement ‘132 Local Switching Traffic’ monitors CS U-plane RTP and UDP packets for each BTS configured in a LS area. The object level is a LS peer BCF.
Number of DL RTP packets containing TRAU frames of the CS U-plane received from a LS peer BCF too early according to the timestamp of the RTP packet.
Trigger event:
Updated when the RTP packet arrives but there is no room in the de-jitter buffer to process the packet.
Use case:
To measure packet loss rate for locally switched calls from a peer BTS due to improper configuration a de-jitter buffer in DL
132003:
CS_U_PLN_RTP_TOO_EARLY_LSBTS
New counters (7/9)
Number of DL RTP packets containing TRAU frames of the CS U-plane received from a LS peer BCF too late according to the timestamp of the RTP packet.
Trigger event:
Updated when the RTP packet arrives but a processing window of the packet already elapsed.
132002:
CS_U_PLN_RTP_TOO_LATE_LSBTS
Number of DL octets received at a BCF from a LS peer BCF within UDP packets containing NSN multiplexed RTP packets (p-RTP) of the CS U-plane. Framing characters are included. Unit is kB.
Trigger event:
Each time the DL octet of the CS U-plane from the LS peer BCF is received at a base station.
Use case:
To measure the average UDP packet size in DL of locally switched calls in kB
132007:
CS_U_PLN_UDP_OCTET_REC_LSBTS
Number of UL RTP packets containing TRAU frames of the CS U-plane sent to a LS peer BCF
Trigger event:
Each time the UL RTP packet containing the TRAU frame of the CS U-plane is sent to another LS peer BCF.
132004:
CS_U_PLN_RTP_PACKT_SENT_LSBTS
New counters (8/9)
Number of DL UDP packets containing NSN (a proprietary format) multiplexed RTP packets (p-RTP) of the CS U-plane successfully received at a BCF from a LS peer BCF.
Trigger event:
Each time the DL p-RTP packet of the CS U-plane from the LS peer BCF is received at a base station.
132005:
CS_U_PLN_UDP_PACKT_REC_LSBTS
New counters (9/9)
Number of UL UDP packets containing NSN (a proprietary format) multiplexed RTP packets (p-RTP) of CS U-plane sent from a BCF to a LS peer BCF.
Trigger event:
Each time the UL p-RTP packet of the CS U-plane is sent to another LS peer BCF.
132006:
CS_U_PLN_UDP_PACKT_SENT_LSBTS
Number of UL octets sent from a BCF to a LS peer BCF within UDP packets containing NSN multiplexed RTP packets (p-RTP) of the CS U-plane. Framing characters are included. Unit is kB
Trigger event:
Each time the UL octet of the CS U-plane is sent from a BCF to another LS peer BCF.
Use case:
To measure the average UDP packet size in UL of locally switched calls in kB
132008:
CS_U_PLN_UDP_OCTET_SENT_LSBTS
Feature Impact Analysis & Verification
Counters:
001275 (MT_LS_CALL_SUCC)
Both counters should have non-zero values after a sufficiently long observation period, e.g. one day. These are absolute values not giving information on rate of calls established locally. This disadvantage is reconciled by the KPI shown below.
KPIs:
Percentage of calls established locally (aggregated over the local switching area):
Percentage of incoming (MTC) and outgoing (MOC) calls established locally (measured on the level of the BTS belonging to the local switching area)
The low percentage of locally switched calls may indicate that the local switching area is incorrectly designed, i.e. it may not include cells between which locally switched calls are frequently established.
Feature works on a configured local switching area.
Local switching area includes cells, among which the locally switched calls are frequently established.
In each cell a significant portion of calls (incoming and outgoing) should be established locally.
How to measure?
Feature impact
Counters:
001276 (LS_ESTAB_UNSUCC_DUE_CODEC)
If codec types are aligned among cells of the local switching area, the counter should have a small value. This is an absolute value not giving information on rate of calls not established locally due to codec type mismatch. This disadvantage is reconciled by the KPI shown below.
KPIs:
Percentage of calls not established locally due to codec mismatch (aggregated over the local switching area):
Percentage of calls not established locally due to codec mismatch (measured on the level of the BTS belonging to the local switching area):
The high percentage may indicate that codec types in cells of the local switching area are not aligned and, as a result, TrFO works inefficiently. In an ideal case the percentage should be low (near zero). This KPI may also indicate the need for corrections in ACSs of BTSs belonging to the local switching area if AMR codec type is in use and the percentage is high.
Codec types/modes are aligned in cells of a local switching area, so TrFO can work efficiently, i.e. a common codec type can be found between to MSs establishing a locally switched call.
If the common codec type is not found the call is established normally without local switching.
Also the KPIs presented on the previous slide demonstrates a lower rate of calls established locally, although the local switching area is correctly designed.
How to measure?
Feature impact
Counters:
001277 (LS_REL_DUE_INTER_HO_OUT_LS)
001278 (LS_REL_DUE_EXTERNAL_HO)
If internal HOs are mostly done between cells of the same local switching area, the counter should have a small value. This is an absolute value not giving information on rate of local switching releases due to an internal HO to a cell outside the local switching area. This disadvantage is reconciled by the KPI shown below.
KPIs:
Percentage of local switching releases during internal/external HOs (measured on the level of the local switching area):
The high percentage indicates that the local switching area is not properly designed, i.e. it does not contain cells between which HOs are frequently performed. These KPIs are inputs for re-planning of the local switching area. If a local switching area is correctly designed the percentages should be low.
During internal HOs within a local switching area a locally switched call is maintained.
If a local switching area is incorrectly designed, i.e. it does not contain cells between which handovers are frequently done, a local switching is released
The local switching can also be released during the internal HO if TrFO cannot be established, i.e. supported codec types in cells of a local switching area mismatch
How to measure?
Feature impact
Counters:
KPIs:
Percentage of local switching releases due to a supplementary service setup (measured on the level of the local switching area):
If during a locally switched call a supplementary service is established the local switching is released.
The local switching feature is designated for basic peer-to-peer voice calls without supplementary services.
How to measure?
Feature impact
Counters:
Quality of locally switched calls should be monitored.
The high packet loss rate may indicate network congestion in its part serving a local switching area.
However, the network congestion may not necessarily take place on a route to a BSC at the same time.
How to measure?
Feature impact
Length of a de-jitter buffer impacts PDV (Packet Delay Variation). If the buffer is too short, the PDV goes down, but the incoming packets may be rejected, because there is no room in the buffer. If it is too long, then all incoming packets can be served, but the PDV increases. Both cases lead to quality degradation.
Counters:
KPIs:
Packet loss rate in DL for locally switched calls due to de-jitter buffer
The KPI may be useful to optimise the length of the de-jitter buffer to minimise the PDV.
KPIs:
Average UDP packet size in DL of locally switched calls in kB
Average UDP packet size in UL in the local switching area in kB
Locally switched calls are multiplexed (if originated and terminated by the same local BTSs) in a part of a network serving a local switching area. The higher is the multiplexing factor (the larger is a packet size), the greater are bandwidth savings.
How to measure?
Feature impact
Local Switching for Packet Abis, BSS21327, BSC S15, Requirements Specification, v.1.0.1, Timo Olkkonen, Outi Rissanen, Jarno Filipoff, Hannu Makkonen
Local Switching for Packet Abis, BSS21327, System Feature Specification, v.1.2.1, Sergio Parolari
Local Switching for Packet Abis, BSS21327, BSC S15, Implementation Specification, v.0.0.1, Manoj R Nair, Sharath K
Feature Description: BSS21436 Local Switching for Satellite Abis, BSS30370 Local Switching for Terrestrial Abis
3GPP TS 48.008 version 8.7.0 Release 8 – Digital cellular telecommunications system (Phase 2+); Mobile Switching Centre - Base Station system (MSC-BSS) interface; Layer 3 specification
References
Backup
Feature Details
ML-PPP (Multi-Link Point-to-Point) layer 2 protocol is used to transport speech data in the packet Abis over TDM variant:
Inside a local switching area between two BTSs of a local switching area through a hub-BTS for locally switched calls (inter-site local switching) => BTS1hub-BTSBTS2
Between a BTS and a BSC through a hub-BTS for non-locally switched calls (intra-site local switching) => BTS1hub-BTSBSC
Between a BTS and a BSC for non-locally switched calls (intra-site local switching) => BTS1BSC
Signalling data and PS traffic is always transmitted by the ML-PPP protocol to/from the BSC irrespective of the local switching functionality
As the maximum number of BTSs connected to the hub-BTS is 15 the maximum number of ML-PPP bundles going through the hub-BTS is 16:
Maximum 15 ML-PPP bundles to connect the hub-BTS with the local BTSs
… + 1 ML-PPP bundle to connect the hub-BTS to the BSC
There is a constant mapping between destination IP addresses contained in the IP packets arriving at the hub-BTS and the ML-PPP bundles connecting the hub-BTS with BTSs
ML-PPP in Local Switching with Packet Abis over TDM
Feature Details
Detection of a local call is based on sniffing/manipulation of the DTAP (Direct Transfer Application Part) messages by a BSC:
DTAP is used to transfer call control and mobility management messages between the MSC and the MS at call setup
Normally, the DTAP information in these messages is not interpreted by the BSS
To check whether a call being established is a candidate for the local switching the following steps are performed:
BSC inserts a call identifier of an MS originating a call to the User-User IE (part of the DTAP signalling)
The call identifier is saved to the BSC lookup table
The manipulated DTAP signalling is forwarded to MSC
If the MS originating the call tries to establish the call with an MS served by the same BSC the manipulated DTAP signalling containing the call identifier arrives back from the MSC at the BSC
BSC sniffs the call identifier from the manipulated DTAP signalling and compares it with call identifiers saved to the BSC lookup table to check the connection being established was started through the same BSC => if so, the local switching is possible
At this point the call is not yet established => the local switching is to be tried out
Local Call Detection & Setup – Phase 1
Feature Details
The MSs may be served by the same or different BCSUs
The BCSUs serving the MSs make an exchange of lists of codec types they support (FR, EFR, HR, AMR HR, AMR FR, AMR WB):
RRM tries to allocate a common codec type to both connection ends, e.g. AMR HRAMR HR, AMR HRAMR FR with the same source bit rate => the local switching is possible
Common codec type not found by the RRM => the local switching is not possible and both connection ends operate with their preferred codec types
The TrFO (Transcoder Free Operation) mechanism is responsible for the selection of the common codec type (see the next slides)
The BCSUs serving the MSs make an exchange of IP addresses of BTSs and radio channel UDP ports, on which the TCH channel should be established:
At this moment it is checked if the BTSs belong to the same local switching area => if this is a case, then the call is finally established with the local switching, otherwise the call is connected without the local switching
Local Call Detection & Setup – Phase 2
Feature Details
BSC
BCSU1
BCSU2
TRAU
MSC
BTS2
MS2
BTS1
MS1
* - counter is incremented each time a new call is established to distinguish the calls established in the same BSC
BSC id
BCSU index
forward the manipulated DTAP to MSC
if the terminating MS is to be served by the same BSC as the originating MS the MSC sends the manipulated DTAP back to the same BSC
sniff the call identifier from DTAP and, if present, compare it with the call identifiers stored in the BSC lookup table
remove the call identifier from User-User IE (DTAP)
call setup
call setup
if the match is found it means MS1 tries to connect with the MS2 served by the same BSC
BCSU1 and BCSU2 start establishment of local switching…
insert MS1 call identifier to User-User IE of DTAP protocol and save the call identifier to BSC lookup table
call identifier
Feature Details
BSC
BCSU1
BCSU2
TRAU
MSC
BTS1
BTS2
MS1
MS2
BSC lookup table
BCSUs exchange information on the supported codec types and try to find a common codec type
the BCSUs exchange the IP addresses and radio channel UDP port numbers
if the common codec type is found and both BTSs belong to the same local switching area the call is finally switched locally
Feature Details
In case of the packet Abis over Ethernet all BTSs of the local switching area must belong to the same VLAN (Virtual LAN) network (apart from belonging to the same local switching area)
C/U-plane and M-plane can be handled by the same VLAN ID (no separation between C/U- and M-planes) or separate VLAN IDs (general restriction of the packet Abis feature)
Local Switching Area (3/3)
penetration of LS calls
TRX configuration 4/4/4

local switching for packet abis

Documents