Radio Resource Management Strategy in SATIN - Semantic Scholar

Radio Resource Management Strategy in SATIN M. Karaliopoulos1, E. Angelou2, I. Andrikopoulos2, P. Henrio3, B.G. Evans1 Centre for Communication Systems Research1, University of Surrey, UK [email protected]

ABSTRACT This paper proposes a Radio Resource Management strategy for unidirectional satellite systems delivering multicast and broadcast services to mobile users. Both the radio interface and the targeted services impose particular requirements on the RRM task. We present the individual RRM entities, describe their exact role and suggest algorithms for their functions.

Space Hellas S.A.2 Athens, Greece [email protected]

Alcatel Space3 Nanterre, France [email protected]

RNC), feedback/loop mechanisms (power control, ARQ); whereas it necessitates the use of common channels to configure lower layers based on unidirectional signalling from S-RNC to UEs. Logical Channels

DTCH

DCCH

CTCH

CCCH

PCCH

BCCH

MAC Transport Channels

DCH

DSCH

FACH

PCH

BCH

PHY

I. INTRODUCTION The provision of multimedia broadcast and multicast services to mobile users via satellite has attracted a lot of interest in the recent years. The inherent broadcast capabilities of satellites and the limited success of the stand-alone system model providing a similar set of services with the terrestrial mobile networks have been the main motivation for the re-consideration of the satellite role in service provision [1]. In this context the close integration of the S-UMTS component with the terrestrial 3G architecture is regarded as a key factor for the success of the system. Within the SATIN1 framework the use of stand-alone UTRA FDD downlink carriers is investigated in order to deliver unidirectional point to multi-point services. Such services are currently under investigation within the 3GPP MBMS (Multimedia Broadcast/Multicast Services) framework [2]. The stand-alone carriers convey several MBMS services in either broadcast or multicast mode. The MBMS data are mapped onto appropriate radio bearers and transmitted from the Node B in parallel to the UTRA FDD carriers. Intermediate module repeaters (IMR) co-located physically with Node Bs boost the signal and ensure coverage indoors and in densely built-up areas [3]. The main feature of the SATIN access scheme is the lack of a return path via satellite2. As a result the real time interaction between UEs and Satellite-RNC is not possible implying the absence of the following features: connection over the air as regards the satellite radio interface, Packet Data Protocol (PDP) messaging between User Equipment (UE) and Satellite Radio Network Controller (Satellite1

IST-2000-25030 SATIN is partly funded by the European Commission. A return link via T-UMTS is available but may be used for specific functions (access to content decoding keys, retrieval of multimedia content blocks corrupted on the satellite forward link, fetching of content “advertised” in the broadcast/multicast channel but not stored in the local cache) 2

Physical Channels

DPDCH DPCCH PDSCH

Primary relevance to SATIN

S-CCPCH

P-CCPCH xICH CPICH AICH AP-AICH PICH CSICH CD/CA-ICH

SCH

Figure 1: SATIN common channel mapping Figure 1 shows the common channels and their mapping

foreseen in SATIN, in accordance with the FDD mode of UTRA. The proposed access scheme combines regular features of Broadcast and Packet Switched domains. For the multimedia data transport, there is one-to-one correspondence between services and logical channels (common traffic channel - CTCH). The logical channels are then mapped, again one-to-one, to transport channels; the forward access channel (FACH) was selected within SATIN, since it necessitates the least changes in the standard UTRA FDD interface. At the physical level, secondary common control channels (S-CCPCHs) carry (multiplex) one or more FACHs. Most of the signalling is carried by the broadcast control channel (BCCH thereafter BCH): first System Information Broadcast allows reception of in-band service signalling (passed by BMC messages) onto a “system master CTCH/FACH” (to remain available to all UEs in the cell). The latter then provides service-to-channel mapping, hence allows protocol stack configuration for reception of any other CTCH of interest. Discontinuous reception functionality is combined with BMC resource allocation and scheduling. This paper addresses a basic set of this interface functions, embraced within the radio resource management (RRM) term. First the requirements for the SATIN RRM functions are outlined. These requirements stem from the services point of view but also from the particular features of the access scheme that differentiate it from the conventional TUMTS radio interface. Then the main functional entities of RRM are discussed in detail. Alternatives for their mode of operation are presented and systematic algorithms for the

individual entities are proposed, facilitating a full topdown RRM design –from traffic mix to individual RRM component configuration. II. RRM REQUIREMENTS

lies functionally within RRC and is in close connection with the other RRM functional blocks, namely AC, LC, PS (Figure 2). Within SATIN it is possible to identify two modes of operation, each one implying different functionality for the aforementioned blocks. Subscription info

The basic function of radio resource management (RRM) is to allocate physical radio resources when requested by the Radio Resource Control (RRC) layer. RRM aims at maximizing spectral efficiency and at satisfying the QoS requirements, while also trying to prevent network congestion. It has already been noted that the lack of real-time interaction between the user and the network renders (downlink) power control irrelevant. There are two more significant consequences of the return-path absence: § the satellite RNC has to do without the assistance of user-side measurements regarding the quality of the downlink § the resource allocation procedure and radio bearer (re)configuration rely on unidirectional messages, i.e. no possibility for reception confirmation, hence less reliability. The first point imposes some hard limitations to the shorter-term functions of RRM; it respectively increases the weight of the longer-term functions, like dimensioning and the design of broadcast schedules. The second point implies that frequent reconfiguration of the radio bearers is not desirable, or at least it should not happen as frequently as in the T-UMTS case. Additional requirements for RRM rise from the supported services and more generally from the overall service delivery paradigm. At high-level, one of the fundamental requirements is compliance with the current core requirements of MBMS as specified within the ongoing 3GPP Release 6 [2]. The SATIN system can be envisaged as a Content Delivery Network (CDN), primarily oriented towards data streaming (e.g. audio, video broadcasting, alert and emergency announcements) and push & store applications (e.g. infotainment, entertainment, software delivery, webcasting). In the first case the multimedia content can be played directly upon reception at the user terminal, while in the second the multimedia contents are stored in a local cache for later processing (pre-stored). The RRM procedures envisaged within SATIN for the treatment of these two types of services are different. III. RRM STRATEGY A. Data Streaming Services The main blocks of RRM relevant to data streaming services (mainly real-time services) are the AC, PS, LC and the radio bearer allocation and mapping (RBAM) block. The latter is responsible for the Radio Bearer (RB) configuration, i.e. the estimation number of the required transport/physical channels and their mapping together with the actual TFCS for each physical channel. This block

QoS handling

(2) Admission Control

MAC

Scheduling/priority handling

Traffic volume measurements

(1)

TimePower- scheduling Rate-

(7)

(4) (5)

TF(C) selection CMAC-MEASUREMENT-Ind CMAC-MEASUREMENT-Req

Radio bearer allocation/ mapping

(6) (3)

Load estimation

Load Control

CPHY-MEASUREMENT-Req

RRC

CPHY-MEASUREMENT-Ind

L1 measurements module

L1

Figure 2: Model of the RRM entities in SATIN Mode A: there is a fixed RB configuration over some interval of time, over which the traffic mix remains the same (for example in the order of 1h). This mode relies on some form of prediction of the traffic that is expected over subsequent time intervals, which may be based on historical data drawn from measurements. This corresponds to the traditional dimensioning task, practised for years in telecommunication networks (e.g. telephone networks). In this case the AC block functions within the constraints imposed from this mapping, which is the responsibility of the RBAM block. Mode B: the RB mapping is drawn in an ad-hoc manner by the AC without any prior configuration. In this case the AC decides on the acceptance of the service request and then (re)-configures the bearer appropriately. The AC decision upon the acceptance or rejection of a service request is made on the basis of power or load constraints, without taking account of the per physical channel rate constraints. In effect, AC assumes that there is an infinite flexibility regarding the radio bearer mapping and allocation, i.e. the RBAM will re-map FACHs upon S-CCPCHs and reconfigure them, as far as a service request is accepted in terms of the extra load and power constraints it introduces. The second option allows higher flexibility in the resource utilization at the expense of extra interlayer- and over the air- signaling (reconfiguration messages towards the group users). Given the absence of positive acknowledgement on behalf of the group users, the latter option is at disadvantage. The RBAM function becomes more relevant in mode A and is described in the following.

A.1 RBAM Strategy The aim of the RBAM block in mode A is to perform some dimensioning of the system, on the basis of the traffic mix; the assumption is that there is some adequate description of

the traffic mix in terms of –at least– arrival rate λi , duration µi and requested rate for each type of service Ri . This is equivalent to providing an appropriate configuration of the bearers (number of FACHs, rates and mapping to S-CCPCHs). The task may be split into more than one step and their actual context depends on the assumptions on the service characterization. The steps relevant to the RBAM task are: Step 1: Estimation of required FACHs Let S be the set of different services. A service is characterized by the 3-tuple {λi , µi , Ri } , i.e., in this

context, audio broadcast at 32 kbps is considered a different service than audio broadcast at 64kbps. The cardinality of the service set is N, i.e. |S|=N. No assumption is made for the flow burstiness; it might be CBR or VBR, but in the latter case the Ri value is set to the mean/guaranteed rate attribute. Each element s i corresponds to a member of the service set, i.e. a service. Let Pbl a vector of size N corresponding to blocking probabilities targeted for each service, i.e. there is one-toi

one correspondence between s i and Pbl . Then the required FACHs for each s i can be derived use of well-known results of classical queueing theory: • From the m-server loss queueing system (see, example, [4]), for each service type s i separately, invocation of the M/M/c/c formula N times. • From the extension of the Erlangian formula to multiple services scenario over all types of flows

via for i.e. the

si

requesting the same rate Ri , irrespective of the arrival rates or service durations of the respective services. The respective formula (see e.g. [5]) is applicable under the complete-sharing (CS) assumption, i.e. FACHs can be fully shared among services requesting the same rates (i.e. as long as the TFCS provided can cope with possible discrepancies at the packet level). In both cases the required number of FACHs is that number of servers (of rate equal to Ri ) that will guarantee i

the target blocking probabilities Pbl . Step 2: Mapping of the FACHs on S-CCPCHs The objective of this function is to map the derived FACHs onto the available S-CCPCHs. The number of available SCCPCHs M and their maximum capacity c, or a rough estimation of theirs, is assumed to be known a priori (i.e. from link budget exercises and Layer 1 simulation input). There are two alternatives for this mapping: One is to not take the power requirements (Eb/No) of individual services into consideration. Then a mathematical formulation of the problem could be: N

minimize

z = ∑ yj j =1

N

subject to

∑R x

≤ cy j , j ∈ {1..N }

i

ij

ij

= 1 , i ∈ {1..N }

(1)

i=` N

∑x j =1

where yi = 1 if S-CCPCH is used or 0 otherwise and

xij = 1 , if service (FACH) i is assigned to S-CCPCH j, 0 otherwise. This is the bin-packing problem, i.e. given the FACHs (items) pack them into the minimum possible number of S-CCPCHs (bins). A feasible solution of the problem corresponds to cost values z less than or equal to M. Both approximate and exact algorithms are available for the solution of this problem; given the rather small number of S-CCPCHs3, computation efficiency does not pose constraints. The second option is to take into consideration the power requirements (Eb/No) of the individual services. In that case we can apply a variation of this algorithm to derive a mapping that minimizes the power waste (e.g. allocates services of similar power requirements to each S-CCPCH). The Eb/No requirement is a function of the TB size most frequently used. In comparison with eq. (1), only the objective function changes: N

minimize

z = ∑ y j ⋅ (Eb No ) j , j ∈ {1..N } j =1

{

}

where (Eb No ) j = max (Eb No )k , k : xkj = 1 k

Although the objective function in this case is non-linear and less well-known than in eq. (1), adaptations of the approximate algorithms for the classical bin-packing problem give considerable improvement over the solution of eq. (1). Step 3: Derivation of TCFS for each S-CCPCH Strict rules or algorithms for performing this task are difficult to find. In any case, deriving the TFCS a priori, on the basis of traffic predictions is not too efficient. The TFCS should be broad enough to capture the packet-level dynamics of the services expected over some future time interval. The wider the range of services, the broader the TFCS should be with direct impact on the terminal processing requirements. Some rules might be: The chosen TB sizes should be in line with the packet sizes expected from the applications, so that overheads (headers and padding) are minimum. The same reasons (i.e. minimisation of the overheads and resource utilisation efficiency) dictate TFs for each FACH that can cover the full range of short-term rate variations. A.2 Admission and Preventive Load Control The admission control is the set of actions taken by the satellite network during the phase of service establishment or service re-negotiation to decide whether to accept or to 3

For SF=8, allowing for the P-CCPCH and the master S-CCPCH, there are 6 S-CCPCHs for data transfer

reject a user group service request. A new user group service request can be accepted only when there are adequate network resources available to guarantee the Quality of Service (Q S) of all existing and the requested services. The AC algorithm considers QoS-related, power, code and rate constraints. Load control, on the other hand, monitors, detects and handles situations when the system reaches near overload or an overload situation while RABs remain active. Therefore, when somewhere in the network limited resources degrade service quality, load control brings the system back and restores stability seamlessly. ο

new user group service request , possible TFSs for the new user service request from RBAM mapping of the FACHs on S-CCPCHs

step 1

TFSs for the new user service request checked by AC QoS, power, rate, code accepted

rejected

step 2

Admitted TFCs checked by Preventive LC accepted

rejected

Reduced TFCS to PS via RBAM

Figure 3: AC strategy coupled with preventive LC

SATIN proposes an admission control strategy coupled with a preventive load control mechanism. It is an admission control strategy that implements a preventive load control algorithm aiming at determining the admissible set of TBSs that can be supported by the system, ensuring the required QoS. This combined strategy can be applied to cases where more than one FACH are multiplexed on a single S-CCPCH. The particular procedure is depicted in Figure 3. In step 1, AC4 first checks the allowable TFCs selected from RBAM by applying eq. (2) (derived from the QoS and power constraints). In the case of the fixed mapping it then checks whether there are available FACHs with allowable information rate greater than the requested rate for the incoming service request. AC provides the allowable combinations to RBAM, which in turn provides the corresponding TFCS to the PS (it is possible that the resulting TFCS is a reduced set following the application of additional constraints). M

∑

k =1

γk SFk

Eb No required to satisfy the most demanding of the services (in terms of BER) on S-CCPCH k, Fk is the maximum number of FACHs for S-CCPHCH k, SFk the spreading factor of physical channel k, α is the average orthogonality of the beam, λ is the average antenna leakage, Rj is the rate of service j on S-CCPCH k, β is a fraction of the total power 4

γ k is

1 is the channel gain Ln i

Lni is the total path losses, no is the noise spectral density of the users’ mobile front-end, W is the chip rate, Ptott is the total transmitted power from each S-CCPCH. If the AC criteria are satisfied then preventive LC takes over (step 2) and checks what would be the total load for each TFC if the new session had been accepted (eq.2).

γk

M

∑

k =1, ≠ w

SFk

⋅ (1 − a + λ ) +

γw SFw

⋅ (1 − a + λ ) ≤ nDL _ threshold (3)

where nDL _ threshold is the load factor threshold set by the Radio Network Planning process, and w is the S-CCPCH where the new RAB will be accepted. If this load criterion is also satisfied then the session is accepted and the selected TFCS is available to PS via RBAM. The above process would ideally ensure that the system would not enter a congested state (depending on how conservative or optimistic the selection of the load threshold value is).

A.3 Packet Scheduling Given the fixed Spreading Factor (SF) of the S-CCPCHs, the major task of the scheduler becomes the time scheduling of the different FACHs that have been mapped to a single S-CCPCH. The power transmitted per code channel is set to a specific level that can guarantee some QoS measure (usually of statistical nature) for all services (i.e. FACHs) carried from the code-channel. It may vary over intervals equal to the duration of a flow, but not at the level of Transmission Time Interval. In fact, the power scheduling check may only be made once, when the service is admitted or may even be taken into consideration once in the dimensioning of the system (number of code channels supported per beam) and not be repeated again in the more dynamic stages of RRM. Check the capacity requests from each service (CTCH/FACH). Determine the respective requests for each S-CCPCH as defined by interlayer mappings of CTCH(s) / FACH(s) / S-CCPCH

Order these requests on the basis of some priority criterion

⋅ ( Ptott ⋅ (1 − a + λ ) + noW / hni ) ≤ β Ptott (2)

where M is the number of S-CCPCHs,

allocated to data channels, hni =

the

In mode A (fixed RB configuration), AC indicates to RBAM to which (pre-configured) RB the accepted RAB should be mapped. In mode B (ad hoc RB configuration), AC determines the ad hoc RB configuration for the accepted RAB, and instructs RBAM accordingly.

Determine the resource allocation over the respective interval, given service rate, transmit power and code availability constraints

Scheduling discipline

Figure 4: Packet scheduling procedure

Generic formulation of the scheduling problem Let kij denote the kth TF of the jth FACH, 1 ≤ j ≤ N i , mapped to the ith S-CCPCH, 1 ≤ i ≤ M . N i is the number of FACHs mapped to the ith S-CCPCH, while K ij is the number of TFs of the jth FACH mapped to the ith SCCPCH. We assume that the TBSet sizes

the TBSet Sizes corresponding to the TFs of each FACH are sorted in increasing order, namely: TBsetsizeij kij ≤ TBsetsizeij kij + 1 , 1 ≤ kij ≤ K ij

( )

(

)

The scheduler is assigned with L Transport Format Combinations (TFCs) per S-CCPCH, obeying the limitations of 3GPP standards5. The task of the scheduler is to select every TTI and for each S-CCPCH i some “appropriate” TFCl, 1 ≤ l ≤ L , featuring a certain TBSet Size for each one of the N i FACH channels mapped to it TBS (l,m), 1 ≤ m ≤ N i . The actual context of the term “appropriate” is dictated by the service QoS requirements and differentiates the one scheduler from the other. This differentiation is summarized in the term scheduling discipline (Figure 4), i.e. the way the semi-statically fixed capacity of each physical channel is time-shared among the different FACHs. Within SATIN we investigate adaptations of two scheduling disciplines, known from fixed networks: the multilevel priority with exhaustive service and the Weighted Fair Queuing (WFQ) schemes. B. Push & Store Applications Capacity that remains available after the dimensioning performed by the RBAM block for the data streaming services can be used for the push and store services. This capacity can be organised into channels (CTCHs / FACHs) carrying broadcast schedules. The transport channels may be mapped one-to-one or multiplexed onto S-CCPCHs. The network broadcasts a fixed, given number of items (various forms of content) towards the end users relying on information regarding the demand for these items. The requirement for these services is the design of efficient broadcast schedules (cycles) that, in combination of with cache management algorithms at the terminal side, minimize the average response time. This time is defined as the time elapsing from the moment a user expresses his will to receive a service till the moment the service is stored at is terminal, averaged over all items. The user expresses his will for example via selecting a choice at the terminal. The terminal then –knowing from the announcement channel (‘master CTCH/FACH’) when the requested item is next transmitted and the respective configuration info- turns to the appropriate S-CCPCH, receives the item and returns to the master-FACH reception state. The design of the broadcast schedules has been the object of research from the times of teletext [7]. A lower bound for the optimal mean access time for items of different size was derived in [8] along with an on-line algorithm allowing the scheduling of items on the fly. Apparently the response time may be regarded as a way to differentiate the QoS provided to different groups. Via scheduling one group’s items one a slower or faster server it is possible to achieve higher (resp. lower) response times. This is a way

5

3GPP TS 25.302, 25.133/ 25.306

to implement priorities corresponding to different usergroup classes (e.g. high, normal, low). Moreover this estimation of response time can be used for a form of “admission/load control”. A new item will be incorporated in the schedule as far as it does not push the response time beyond a predefined target value. V. CONCLUSIONS

In this paper the RRM strategy adopted within SATIN was presented. The strategy allows a top-down design of the RRM function: from the expected traffic mix to the configuration of individual RRM entities. The combination of features from both the Broadcast and the Packet Switched Domain into the access scheme is naturally reflected into the RRM functions. A different approach is followed for the two main type of services envisaged. For data streaming services two modes of operation are possible. Dimensioning is crucial task in Mode A; Mode B allows higher flexibility at the expense of additional interlayer and over-the-air signaling. The admission control is coupled with a preventive load control mechanism, while, given the transport channel choice (FACH), the time scheduling of the different FACHs that have been mapped to a single S-CCPCH is the major task of the packet scheduler. Push and store services, on the other hand are organized into broadcast schedules. These services are transmitted cyclically on FACH channels, the main objective in this case being the minimization of the mean response time. In a follow-up paper, detailed results from the ongoing performance evaluation of the SATIN RRM will be provided. REFERENCES

[1] ASMS-TF, “The Vision of the Advanced satellite Mobile Systems Task Force”, September 2001 [2] 3GPP TR 23.846, “Multimedia Broadcast/Multicast Service; Architecture and Functional Description”. [3] T. Severijns, et al “The intermediate module concept within the SATIN proposal for the S-UMTS air interface”, IST Mobile Summit 2002 [4] D. Gross and R. Harris, “Fundamentals of queueing theory”, 2nd edition, John Wiley and Sons, 1985. [5] J. Kaufman, “Blocking in a shared resource environment”, IEEE Transactions on Communications, Vol. COM-29, October 1981.. [6] Z. Liu, M. Zarki, “SIR-Based call admission control for DS-CDMA cellular systems,” IEEE JSAC, vol. 12, No. 4, pp. 638-644, May 1994. [7] M.H. Ammar, J.W. Wong, ‘The design of teletext broadcast cycles’, Perfromance Evaluation, 5(4): 235-242, December 1985 [8] N. Vaidya, S. Hameed, “Scheduling Data Broadcast in Asymmetric Communication Environments”, Wir. Networks, vol. 5, no. 3, p.171-182, May 1999