Project

General

Profile

Roadmap » History » Version 6

msuraev, 11/17/2016 12:55 PM
fix typo

1 1 laforge
h1. Overall Roadmap
2
3 3 laforge
This is the general direction in which we would like the Osmocom
4
Cellular Infrastructure projects to move.  None of this will of course
5
happen
6 1 laforge
without significant contribution and/or funding:
7
8
h2. BTS
9
10 3 laforge
* more systematic generation + reporting of alarms over Abis OML #1615
11 4 laforge
* communication of BTS specific capabilities/features towards BSC (via Abis extension) to avoid BTS/BSC config mismatches #1614
12 1 laforge
13
h2. BSC
14
15
* BSC/MSC split: Real A interface with BSSAP/BSSMAP between MSC and BSC
16 3 laforge
* Support of 3GPP A-over-IP in addition to current non-standard IPA
17
* multiplex / SCCPlite
18 1 laforge
* Alarm handling
19
** generation of Alarms inside the BSC
20
** aggregation/forwarding of Alarms received from Abis
21
** reporting of alarms via control interface·
22 3 laforge
** control interface / SNMP proxy for alarm -> trap conversion #1590
23 4 laforge
* Move all media processing (TRAU frames, RTP) to separate MGW daemon, controlled via MGCP #61
24 1 laforge
* late assignment instead of very early assignment #1778
25 5 laforge
* A5/3 support #75 (BTS supports it, we just need to enable it based on MS capability)
26 1 laforge
27
h2. Core Network
28 3 laforge
29 4 laforge
* BSC/MSC split: Real A interface with BSSAP/BSSMAP between MSC and BSC #1594
30
* externalize the HLR+AUC from the NITB (osmo-gsup-hlr) #1711, #1591, #1592, #30,
31 3 laforge
* support for UMTS AKA over GERAN #1711
32
* support of SMS delivery via GPRS #1587
33
* support of combined CS/PS attach (2G and 3G) #1599 #1583
34
* support of inter-BSC hand-over (after BSC/MSC split) #1609
35 1 laforge
* support of inter-MSC hand-over (after HLR+AUC externalization)
36
* Real A interface (MTP2/MTP3/SCCP)
37 6 msuraev
* Move all media processing (TRAU frames, RTP) to separate MGW daemon, controlled via MGCP
38 3 laforge
* Local Call, Local Switching #1602
39
* External interface to HLR #1643
40
* External interface for USSD #1597
41 5 laforge
* Generation of accounting/billing data #1596
42 1 laforge
43 3 laforge
h2. SIP Interface (osmo-sip-connector
44
45
* better VTY #1680
46
* create user manual #1684
47
* DTMF support
48
* call hold #1686
49
* codec selection #1683
50
51 1 laforge
h2. 3G/3.5G related
52
53 3 laforge
* Iu-CS and Iu-PS interface over M3UA (as specified in 3GPP), not just
54
* SUA (current implementation) #1595, #1589·
55 1 laforge
* test/validate mobility between multiple hNodeB/smallcells
56
* hand-over between multiple hNodeB/smallcells
57
* Iu-CS/Iu-PS validation against RNCs
58
* Iuh validation against more hNodeB/smallcell vendors
59 3 laforge
* inter-RAT mobility (2G <-> 3G) #1588
60 1 laforge
* network with simultaneous 2G and 3G/3.5G cells
61
62
h2. PCU
63
64
* more complete EGPRS implementation for uplink and downlink
65
* multi-slot uplink support
66 3 laforge
* PTCCH support (TA loop for fast moving MS) #1526, #1545
67
* closed loop power control #1546
68
* EC-GSM-IoT support #1780
69 1 laforge
70
h2. Build and Test infrastructure
71
72
* more mature osmo-gsm-tester setup
73 3 laforge
** have osmo-gsm-tester do full end-to-end regression testing on every
74
commit or every night
75
** develop test cases for MO-Call, MT-Call, Hold/Retrieve, USSD,
76
SMS-in-Call, hand-over, etc.
77
** not only functional testing, but performance testing (time to deliver
78
N SMS)
79 1 laforge
** GPRS/EGPRS testing
80 3 laforge
*** (single-MS ul/dl throughput, multi-MS ul/dl throughput) #1544
81 1 laforge
*** mobility between different BTS/PCUs
82 3 laforge
** testing against different modems (different baseband processr,
83
protocol stack)
84 1 laforge
85
h2. Libraries/Infrastructure
86
87 5 laforge
* VTYv2: Externalize VTY + config management #1601 #1613 #1600
88 3 laforge
** shared daemon that manages a MIB and offers VTY + control interface
89
to access that MIB
90
** individual programs just access that config daemon via well-defined
91
API
92 1 laforge
** preferably with transactions, roll-back
93
** avoid hand-written code for parsing individual VTY commands
94
** avoid duplicate code for VTY + Control interface
95 3 laforge
96
h2. Documentation
97
98
* provide one conscise set of tutorials/howto's as opposed to fragmented
99
* and duplicated, outdated information in wiki #1719
100
* regularly update user manuals and reference manuals
Add picture from clipboard (Maximum size: 48.8 MB)