Вы находитесь на странице: 1из 5

A Study of Throughput for Nb, Mc and Nc Interface in UMTS Core Network

Ye Ouyang
Howe School of Technology Management Stevens Institute of Technology Hoboken, NJ, USA youyang@stevens.edu

M. Hosein Fallah, Ph.D, P.E.


Howe School of Technology Management Stevens Institute of Technology Hoboken, NJ, USA hfallah@stevens.edu 2G MSC, Mc interface with MSC Server, A interface with BSC, and Ai interface with PSTN. In order to accurately plan, design, and dimension the UMTS CN, this paper will develop the algorithms of traffic and throughput for the UMTS CN network entities (NEs) described in Section 3. The analysis will be based on the live traffic and throughput generated or absorbed in the interfaces of CN NEs. A case study at last is provided finally to verify the algorithms created for UMTS CN. Our paper is aimed at helping UMTS network operators dimension an optimum network size and build an optimum network structure to deliver an optimum quality of service for users. II. THROUGHPUT ALGORITHMS OF UMTS CORE NETWORK

AbstractCurrently there are many practical tools or theoretical methods to plan and dimension GSM or UMTS radio networks but overlooks the algorithms for core networks because of its complexity. This paper introduces an algorithm for traffic and throughput dimensioning for Nb, Mc and Nc interfaces in UMTS core network. The analysis is based on the traffic and throughput generated or absorbed in the interfaces of network entities in UMTS network. This paper is targeted at helping wireless carriers plan and dimensioning their UMTS core networks. Keywords-UMTS; core network; circuit switch; Nb interface; throughpu; network plan, network dimension.

I.

ARCHITECTURE OF UMTS CORE NETWORK

Whether in 2G or in 3G phase, the CN plays an essential role in the whole mobile network system. In R99 version, the first version of 3G Universal Mobile Telecommunications System (UMTS), the CN portion still stays the same network entity (NE) type and network topology architecture as that in GSM phase. However, there is a change in R4, the second version of UMTS, which supports a networking mode where bearer is separated from control. Meanwhile multiple bearer modes such as ATM/IP/TDM are supported by CN. Consequently the Mobile Switching Center (MSC) in GSM/UMTS R99 is split into two NEs: MSC Server (MSS) and Media Gateway (MGW). Logically the CN in UMTS is classified into the packet switched domain (PS) and the circuit switched domain (CS), the latter of which includes such logical Network Entities (NE) as Mobile Switching Center Server (MSC Server or MSS), Media Gateway (MGW), Visitor Location Register (VLR) integrated in MSS physically, Home Location Register (HLR), Authentication Center (AUC), Equipment Identity Register (EIR). MSC Server provides Nc interface to connect with its peer MSC Server, Mc interface with MGW, C/D interface with HLR, A interface with 2G Base Station Controller (BSC), and the optional Gs interface with SGSN. MGW provides Iu-CS interface to connect with Radio Network Controller (RNC) in Radio Access Network (RAN), Nb interface with its peer MGW, E interface with

Since Nb, Mc and Nc interface are newly developed in UMTS CN, this section 2 is focused on the algorithms for the new interfaces. The calculation of TDM based traffic for the other interfaces such as A to E and Gb interface, since they have been existing in GSM CN, is still based on traditional algorithm: multiply total traffic (Erlang) and traffic proportion to obtain the traffic distribution for each NE and each link. A. Nb Interface As per Reference [1] and [2], the protocol stack of user plane and control plane of Nb interface are shown in Table I and II.
TABLE I. Transport over IP USER PLANE OF NB INTERFACE Transport over ATM Transport over TDM G.711

AMR/G.711 Nb-UP RTP/RTCP IP/UDP VLAN/MAC MPLS/PPP TABLE II. AAL2 SAR SSCS AAL2 ATM

PCM

CONTROL PLANE OF NB INTERFACE Transport over IP IPBCP (Q.1970) BCTP (Q.1990) BICC (Q.765.5)

Transport by ATM AAL2 Connection Signaling (Q.2630.2) AAL2 Signaling Transport Converter for

MTP 3b (Q.2150.1) MTP 3b SSCF-NNI SSCOP AAL5 ATM

TABLE V. M3UA SCTP IP MAC

CODEC PARAMETERS

Codec Type AMR. Type 7 AMR_SID. Type 8 G.711 Video Type, e.g. G.729

When an Nb UP layer protocol entity receives an initialization status request from the upper layer, it shall start the initialization procedure. Consider the throughput of initialization: (1) where TP denotes the throughput of an initialization per user, SInitial denotes the size of an initialization message, BHCACall represents the average call attempts in busy hour per subscriber. Take IP based fast forward bearer setup as an example, TP=531.28/3600=0.14bps which only counts for a very small value. Therefore it can be overlooked in calculating the throughput in Nb interface.
TABLE III. N bU P 4 RT P 12 OVERHEAD OF PROTOCOLS IN NB INTERFACE UD P 8 TC P 8 I P 2 0 MP LS 4 Po S 10 M A C 34 MAC /VLA N 38

Codec Speed (kbps) 12.2 Not a fixed value 64 64

Payload per Frame (Octets) 31 5 40 40

Speech Frame (ms) 20 160 5 5

TPInitial = SInitial BHCACall 8 / 3600

With

VAD technique, we BWVoicechannel = BWNonVADVocie(1 FVAD )

have

+ BWVADVoice FVAD (3) in which BWVAD is given by equation 4. FVAD is the VAD factor.
(4) where PSID is the payload of AMR SID can be found in Table V, OP denotes the overhead of protocol stacks in Table IV. Its value depends on which protocol stack group is chosen in transport. For video call service, we similarly obtain the bandwidth in both non-VAD and VAD scenario. (5) in which PVideo denotes the payload of video service. Its value can be obtained from Table V. With VAD available, we have BWVideochannel = BWNonVADVideo(1 FVAD )

BWVADVoice = (PSID + OP ) 8 / FSpeech

Size (Octet s)

BWNonVADVideo = (PVideo + OP ) 8 / FSpeech

TABLE IV.

OVERHEAD OF PROTOCOL STACKS Overhead (Octets) 78=4+12+8+20+34 82=4+12+8+20+38 54=4+12+8+20+10 58=4+12+8+20+4+10 74=12+8+20+34 78=12+8+20+38 50=12+8+20+10 54=12+8+20+4+10

Protocol Stack NbUP/RTP/UDP/IP/MAC NbUP/RTP/UDP/IP/VLAN/MAC NbUP/RTP/UDP/IP/POS NbUP/RTP/UDP/IP/MPLS/POS RTP/UDP/IP/MAC RTP/UDP/IP/VLAN/MAC RTP/UDP/IP/POS RTP/UDP/IP/MPLS/POS

As per Table I, the user data can be transported via three mediums: TDM, ATM or IP, last two of which provides different protocols stacks to achieve the transport. Table IV lists sample protocol stacks of user plane in Iu interface. Same with Iu-CS interface, Voice Activity Detection (VAD) or non-VAD technique should be considered individually for Nb interface. Without VAD, a single channel bandwidth in interface Nb is given by (2) where PAMR denotes the the AMR payload for voice service in Table V, FSpeech denotes the speech frame in Table V. OP denotes the overhead of protocol stacks in Table IV.

+ BWVADVideo FVAD (6) in which BWVADVideo is equivalent to BWVADVoice in equation 4. Equation 2, 3 and 4 are based on the application of Transcoder Free Operation (TrFO) technique which enables the voice transported at a speed of AMR 12.2kbps but not G.711 64kbps in CN. However Tandem Free Operation (TFO) technique, a previous technique used in GSM that transport voice at standard 64 kbps via PCM (Pulse Code Modulation) in CN, may still be applied in UMTS CN. If TFO is fully applied in the UMTS CN,
(7) where PTFO denotes the payload based on TFO. The value is different under TFO scenario. With VAD technique in TFO scenario, we have BWVoicechannelTFO = BWNonVADTFO(1 FVAD ) (8)

BWNonVAD _ TFO = (PTFO + OP )8 / FSpeech

BWNonVADVoice = (PAMR + OP ) 8 / FSpeech

+ BWVAD FVAD

A more possible scenario is that both TrFO and TFO are adopted by the wireless operator in UMTS CN with a ratio

of RTrFO and RTFO which RTrFO + RTFO=1, we have the total bandwidth of Nb interface is provided by BWVoCTrFO RTrFO RVO ErlVoU / BH BWNb = NS + BWVoCTFO (1 RTrFO ) + RVi ErlViU / BH BWViC

PK represents the payload of each message flow in Table VIII, NK denotes the number of H.248 message in each flow in Table VIII, OH.248 denotes the overhead of H.248 message in Table VIII.
TABLE VIII. Message Flow Type SUGGESTED MESSAGE FLOW IN MC INTERFACE Notes Direction No. of Message Suggested Message Flow Payload (Octets) 1697 1658 1969 1964 1915 1815 1959 1746 1217 881 1465 1505 1436 1330 1188 970 831 303 243

/ F Re dundancy (9) where the major throughput in Nb interface is also generated by voice and video call service. NS denotes the number of 3G subscribers in RNC. RVo denotes the ratio of subscribers using voice call to total subscribers. Normally its 100%. RVi denotes the video call service penetration rate. BWVoC_TrFO represents BWVoice Channel_TrFO obtained from equation 3. BWVoC_TFO represents BWVoice Channel_TFO from equation 8. BWViC is BWVideo Channel in equation 6. ErlVo User/BH denotes the average voice call traffic in Erlang per user per busy hour. ErlVi User/BH denotes the average video call traffic in Erlang per user per busy hour. Redundancy Factor prevents the network from traffic overflow. Normally set it as 0.7. B. Mc Interface The Mc reference point describes the interfaces between the MSS and MGW. It is full compliance with the H.248 standard [4]. The protocol stack in Mc interface is shown in Table VI. As per Table VI, we can infer the available protocol stack groups with its overhead in Table VII.
TABLE VI. PROTOCOL STACK IN MC INTERFACE H.248 M3UA SCTP SCTP MTP 3B SSCF SSCOP AAL5

1. Call between 3G (subscriber) and 3G (subscriber) 2. Call between 3G and 3G 3. Call between 3G and 3G 4. Call between 3G and PSTN 5. Call from 3G to PSTN 6. Call from PSTN to 3G 7. Inter-office handover 8. Inter-office handover 9. Internal handover 10. Call failure

Internal office (MSS) call

Inter-office call. Mobile Station (MS) originated. Inter-office call. MS terminated. MSS as visiting office. MSS as gateway office MSS as gateway office Handover into the MSS. Handover out of the MSS Handover in the same MSS. Tone in call fails

Downlink. MSS to MGW Uplink. MGW to MSS. Downlink Uplink Downlink Uplink Downlink Uplink Downlink Uplink Downlink Uplink Downlink Uplink Downlink Uplink Downlink Uplink Downlink Uplink

10 10 11 11 11 11 11 11 7 7 9 9 7 7 7 7 5 5 2 2

IP VLAN/MAC MPLS/PPP TABLE VII.


INTERFACE

OVERHEAD OF PROTOCOL STACK GROUPS IN MC Overhead (Octets) 126 86 102 62

Protocol stack type H.248/M3UA/SCTP/IP/VLAN/MAC H.248/SCTP/IP/VLAN/MAC H.248/M3UA/SCTP/IP/MPLS/PPP H.248/SCTP/IP/MPLS/PPP

H.248 message flow transported through Mc interfaces usually includes two message types which are mobile call service and handover service. The Table VIII summaries the H.248 message flow type and its payload for flow going through Mc interface. As per from the payload summarized from Table VIII, the size of each message flow is given by (10) in which SK denotes the size of each H.248 message flow, K denotes the flow type from 1 to 10 in Table VIII,

Its easy to find the payload at downlink is heavier than that in uplink direction, so the payload in downlink direction is adopted in further calculation. The next step is to obtain the total throughput in Mc interface via considering two scenarios: MSC Server functions as a visiting office or a gateway office. With a visiting function for MSS, the message flow going through Mc interface include both call message flow and handover message flow. So message type 1, 2, 3 and 4 shall be considered for call service. Meanwhile, message type 7, 8 and 9 shall be considered for handover service in Mc interface. At last type 10 in Table VIII shall be considered when a call fails to establish. As a result, the Throughput in Mc interface can be displayed below:
BWMc 4 K =1SK RCall / 4 + S 10 RFail BHCACall = NS 8 / 3600 9 + ( SK / 3) BHCAHandover K =7

SK = PK + NK OH .248

(11)

where NS denotes the number of 3G subscribers,

SK is obtained from equation 10, RCall denotes the ratio of established calls to total calls, RFail denotes the ratio of failed calls to total calls, BHCACall represents the average call attempts in busy hour per subscriber, BHCAHandover denotes the average handover times in busy hour per subscriber. With a sole gateway function for MSS connects with PSTN network, the message flow going through Mc interface include call service only. So message type 5 and 6 shall be considered for the bandwidth of Mc interface in a Gateway MSC Server. Handover function is not implemented in Mc interface Mc of a Gateway MSS, so the handover portion in equation 11 shall be removed for the interface Mc of a Gateway MSS. Besides H.248 message, other messages may also be transported via Mc interface if an internal Signaling Gateway (SG) is integrated with MGW. For example: the signaling gateway can transport the RANAP message over ATM between RNC and MGW and then over IP between MGW and MSS. C. Nc Interface Nc interface stands between MSC Servers to implement inter-office call service and handover service. The communication protocol in Nc interface is Bearer Independent Call Control (BICC), an advanced version evolved from ISUP protocol, which can be borne in TDM, ATM and IP due to its bearer independent feature. References [5] and [6] defines two modes to setup BICC bearer: forward bearer setup which is sub-divided into no tunnel case, fast tunnel case and delayed tunnel case; and backward bearer setup which includes no tunnel case only. Two modes have different size of message flow, so which mode is selected slightly impacts the throughput in interface Nc. As the preferable mode, IP based forward bearer setup with fast tunnel case is selected in our case. The protocol stack in Nc interface is shown in Table IX. The overhead size of protocol stacks in Nc interface is the same as that in Table VII.
TABLE IX. M3UA SCTP PROTOCOL STACK IN NC INTERFACE BICC SCTP MTP 3B SSCF-NNI SSCOP AAL5 MTP3 MTP2

and message size of the message flow in two directions. The formula is as below:
(PBICC + NBICCOBICC ) BWNc = NS 8 / 3600 /[2 (BHCAInterCall + BHCAInterHO )]

(12)

where NS denotes the number of 3G subscribers, PBICC denotes the total payload of BICC message which can be obtained from Table X, NBICC denotes the number of BICC messages, obtained from Table X, OBICC denotes the overhead of BICC message, same as it in Table VII, BHCAInter-Office Handover denotes the average inter-office handover times in busy hour per subscriber, BHCAInter-Office Call represents the average inter-office call attempts in busy hour per subscriber, its given by BHCA int ercall = Erlang VOU / BH (13) P int eroffice 3600 / Tcall where ErlangVoUser/BH denotes the average voice call traffic in Erlang per user per busy hour, Pinteroffice denotes the inter-office call rate (percentage), Tcall denotes the average call time.
TABLE X. Message 1.IAM 2.APM 3.APM 4.APM 5.COT 6.ACM 7.ANM 8.REL 9.RLC SUGGESTED PAYLOAD OF BICC MESSAGE Payload (Octets) 68 41 184 184 7 8 21 12 6 531 9 Direction Forward Backward Forward Backward Forward Backward Backward F or B Reversed to REL Total Number of messages

The values in Table X are based on TrFO fully applied in the network. However, the values based on TFO are very close to those in Table X. Therefore it may not need to differentiate TrFO and TFO scenario in dimensioning the bandwidth of interface Nc. If the bear is set up by other modes such as forward bearer setup with delayed tunneling or backward bearer setup with no tunnel case and so on, the equation 12 still universally applies for all cases. D. Summary of Section 2 Section 2 provides the algorithms of throughput for the Nc, Nb, and Mc interfaces existed in UMTS CN. The algorithms for the other interfaces such as A, C, E, Gb, Gs, Gi, Gs and Gc interface are still the same with those in GSM/GPRS stage. In the control plane of Mc interface, throughput of RANAP protocol may also be considered in dimensioning the CN topology. Section 2B for Mc interface only considers the main sources of throughput. Throughput generated by RANAP may be accumulated onto the result of equation 11.

IP VLAN/MAC MPLS/PPP

In the case of forward bearer setup with fast tunnel case, there are 9 messages going through Nc interface. All messages serve for inter-office call service and inter-office handover service between MSSs. The message type and suggested payload is summarized in Table X. Since the direction of step 8 and 9 in Table X are flexible, its impossible to confirm the payload or message size in each direction. The method to calculate throughput in Mc interface does not fit in throughput calculation for Nc interface. An alternative is to calculate the average payload

III.

CASE STUDY

A mobile operator intends to build a new 3G UMTS CN in the area with heavy traffic loading to replace the legacy GSM systems. The plan is to provision one MSC Server to control three MGWs in the three overloaded areas. Each MGW supports 100,000 3G subscribers in its local area. MSS supports 300,000 3G subscribers.

The obtained results show the throughput threshold of each interface for the wireless carriers to design and dimension the 3G core network. IV. SUMMARY AND CONCLUSION The paper first introduced the basic topology and architecture of UMTS core network and analyzed the major changes between GSM CN and UMTS CN. Based on the traffic and message flow, the algorithms to calculate the throughput for each interface and route are provided. Since some parts in the message packet are optional, the message size, header size and overhead size are suggested values in dimensioning the UMTS CN. The actual values vary from different vendors equipments. Radio access solutions are a primary concern of the UMTS deployment strategy, as it impacts the mobile operators most valued asset: spectrum. As an equally important part of this equation, the core network will play an essential role in enhancing mobility, service control, efficient use of network resources and a seamless migration from 2G/3G to 4G. While the deployment of UMTS radio access networks receives considerable attention, the UMTS core network has emerged as a critical element in the delivery of next generation mobile broadband services. As such, the algorithms provided in the paper are and will benefit mobile operators to address the issues in network dimension and plan while positioning them for future technologies. Hence the network evolution calls for a transition to a flat, all-IP core network with a simplified architecture and open interfaces. The evolution from TDM to IP is a lengthy process and requires a systematic and optimal approach. However, confirming the algorithms for UMTS CN is the foundation from which we can extend the researches in planning IMS and SAE. REFERENCES
[1]

Figure 1. CN topoloy TABLE XI. Parameter Network Volume Local 1,2,3 Volume Redundancy factor Voice traffic per Sub at BH Video traffic per Sub at BH VAD Factor TrFO rate Video Call penetration rate BHCACall per sub Inter-office call rate Call fail rate (Call fail tone played) BHCAHandover per sub BHCAInter-officeHOper sub Inter-office call rate Value 300,000 100,000 0.7 0.025 0.005 0.5 100% 10% 1.5 50% 1% 0.5 0.1 50% TRAFFIC MODEL Notes 3G subscribers 3G subscribers Range: 0.7-1 Decided by historical data, engineering experience or carriers request.

TABLE XI TRAFFIC MODEL

Based on the above equations and traffic model, we have 100% 0.025 24.775 10 3 / 0 .7 BWNb1 2 = 100,000 + 0.1 0.05 99.775 10 3 = 159.75Mbps = BWNb1 3 = BWNb 2 3

[2]

[3] [4]

(0.75 + 0.1) 8 / 3600 = 471.75Kbps

(3207.105 + 5.55) 1.5 BWMc1 = 100,000 8 / 3600 + 1033.16 = 1.3004Mbps = BWMc 2 = BWMc 3 BWNc = 30,000 [(531 + 9 126) / 2]

[5]

[6]

3GPP TS 29.414, Technical Specification Group Core Network and Terminals: Core Network Nb Data Transport and Transport Signaling. 3GPP TS 29.415, Technical Specification Group Core Network and Terminals: Core Network Nb Interface User Plane Protocols. 3GPP TS 23.002, Technical Specification Group Services and Systems Aspects; Network architecture. ITU-T, SERIES H: Audiovisual and multimedia systems, Infrastructure of audiovisual servicesCommunication procedures. H.248.1: Gateway control protocol. ITU-T Q1901 SERIES Q: switching and signalling, Specifications of signaling related to Bearer Independent Call Control (BICC), Bearer Independent Call Control protocol Corrigendum 1. ITU-T Q1902.1 series Q: switching and signalling, Specifications of signaling related to Bearer Independent Call Control (BICC), Bearer Independent Call Control protocol (Capability Set 2): Functional description.

Вам также может понравиться