|Version 9 (modified by dburgess, 2 years ago)|
Note: This page contains developer notes from contributors in the public release. The OpenBTS commercial release already has handover in testing with a release scheduled for April 2012. Commercial customers should Range Networks for more information.
This page is built from two parts. First one reflects my understanding of OpenBTS software internals, and the second one describes the proposed handover procedure
1.OpenBTS software for newbies
When contributing to the project, is reasonable to spent some time reading the code. This is same to all the newbies, and that is the reason for typing it here. My goal is implementing handover procedure, that influences the content.
As an example, when discussing MT call establishing, the following key points could be interesting:
-- how SIP messages are processed
-- how SIP INVITE message triggers paging
-- how time advance and power are measured on uplink
-- where is an entry point for Um-originated events
-- in what way processing is done
-- how call is handled
-- where call related data is stored
What goes on inside the PC
-- SIP/SIPInterface: driveLoop() is responsible for checking SIP UDP socket; new MT events (calls and SM) are detected inside checkInvite(); paging to corresponding mobile identity is ordered
-- Control/RadioResource?: pager class serves a loop to maintain paging
-- Somewhere outside openBTS world:
In Transceiver (*Transceiver::pullRadioVector(.. int &timingOffset) Transceiver::driveReceiveFIFO() ), access bursts are processed. Time of advance (TOA) value is computed and packed to burstString at offsets 6(Hi) and 7(Lo), which is sent via UDP (mDataSocket.write(burstString,..)).
-- TRXManager/TRXManager: ReceiveLoopAdaptor?() permanently calls driveRx() function to fetch radio bursts from UDP socket. These bursts are fed to ARFCNManager::receiveBurst(). Inside the function, proper decoder is chosen (depending on frame and timeslot number), and is called as “proc->writeLowSide(inBurst);” From now on, call setup and processing are followed in different ways
-- Control/DCCHDispatch: DCCHDispatchRR() detects 2 events: Paging Response and Assignment Complete, discussed in 2 paragraphs below..
-- Control/RadioResource?: PagingResponseHandler?() removes mobile identity from being paged; in the case of MTC, Control::MTCController() from Control/CallControl? processes call setup logic. Each successful call is associated with own thread callManagementLoop(), which checks both radio and signalling and handles voice traffic (see Control/CallControl?)
-- When assignment procedure takes place:
Control/RadioResource?: Control::AssignmentCompleteHandler?() calls ether Control::MOCController() or Control::MTCController(), both from Control/CallControl?. As mentioned above, a dedicated thread callManagementLoop() serves a call -- let us take a look at SIP/SIPInterface: driveLoop() again. All SIP messages are distributed between different FIFO queues, each one belongs to a call and is identified by SIP call id. On the other end of the pipe, corresponding function reads a message..
In other words, once upon a time, there appeared a call loop. Someone provides it with SIP messages (addressed to it) and events from radio side, that could cause it's interest..
For the curious:
Following 04.08... Pls correct me, I was just trying to fix it in my head.. Abbreviated description can be found at http://en.wikipedia.org/wiki/Um_interface, detailed – 7.3.3 of GSM 04.08; Early assignment example:
1. ← (PCH) ← PAGING REQUEST
2. CHANNEL REQUEST → (RACH) →
3. ← (AGCH) ← IMMEDIATE ASSIGNMENT
4. PAGING RESPONSE → (SDCCH) →
is packed into L2 SABM ! (it differs from Q.921, where “No information field is permitted with the SABME command. ”)
5. ← (SDCCH) ← AUTHENTICATION REQUEST (? packed inside L2 UA)
6. AUTH RESPONSE → (SDCCH) →
7. ← (SDCCH) ← CIPH MODE CMD
8. CIPH MODE COMPLETE → (SDCCH) →
9. ← (SDCCH) ← SETUP
10. CALL CONFIRMED → (SDCCH) →
11. ← (?) ← ASSIGNMENT CMD /*traffic chan is assigned*/
12. ASSIGNMENT COMPLETE → (?) →
13. ALERTING → (?) →
14. CONN → (?) →
15. ← (?) ← CONN ACK
2 Handover-related aspects
Non-synchronized cell case (GSM 04.08 126.96.36.199.2) only.
HO procedure should be triggered via SIP-like message, cause:
-- this saves software structure
-- makes the architecture flexible, allows to migrate HO control procedure to a dedicated node
Measurement results are sent by a mobile ether with MEASUREMENT REPORT (GSM 04.08 9.1.21) or EXTENDED MEASUREMENT REPORT each layer 2 frame (GSM 04.08 188.8.131.52).
Each measurement causes SIP INFO message with extended structure that contains LV HEX-coded measurement results (04.08 10.5.2.20)
HO initiation is done via extended INVITE message, which carries HEX-coded destination Cell Description (10.5.2.2) and Channel Description (10.5.2.5a), which is sent to the serving BTS.
2.3 Resource Allocation
Serving BTS reserves resources sending extended INVITE message to the target BTS, that contains Handover Reference (10.5.2.15)
Target BTS acknowledges resource allocation sending Trying
2.4 Handover Procedure
Serving BTS issues HANDOVER COMMAND, with corresponding destination cell and reference value.
When the mobile is detected (got HANDOVER ACCESS), target BTS sends PHYSICAL INFORMATION (downlink) and SIP Ringing.
When HANDOVER COMPLETE is received, target BTS sends 200 OK
Detailed description can be found here
(102.2 KB) - added by guest
2 years ago.
handover message flow
- proposal-ho.pdf (67.8 KB) - added by guest 2 years ago.
- handover-old1.jpg (11.5 KB) - added by dmisol 20 months ago.
- handover-old2.jpg (11.3 KB) - added by dmisol 20 months ago.
- handover-target.jpg (15.4 KB) - added by dmisol 20 months ago.