-
Notifications
You must be signed in to change notification settings - Fork 4
/
Documentation.txt
186 lines (132 loc) · 8.06 KB
/
Documentation.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
Modules created:
1. UE/eNodeB -> Radio Access Network(RAN)
2. MME -> Mobility Management Entity
3. HSS -> Home Subscriber Server
4. SGW -> Serving Gateway
5. PGW -> PacketDataNetwork(PDN) Gateway
Mapping of programs to modules:
ran.cpp = UE/eNodeB
mme.cpp = MME
hss.cpp = HSS
sgw.cpp = SGW
pgw.cpp = PGW
User Equipment Registration Process:
1. Process of Authentication
Step-1:
RAN(UE) sends request to MME with its IMSI, MSISDN and type(1).
RAN to MME(Plain)
type = 1
UE IMSI
UE MSISDN
Step-2:
MME checks the type. If it is 1, it will forward the entire message to the HSS.
MME to HSS(Plain)
UE IMSI
UE MSISDN
Step-3:
HSS collects the data(autn, rand) for this UE(IMSI, MSISDN) based on the timestamp the request is received and calculates the RES based on the key value for this UE.
Step-4:
HSS sends the collection of data(autn, rand, res) to MME.
HSS to MME(Plain)
AUTN
RAND
RES
Step-5:
MME saves the res value and forwards the data(autn, rand) to RAN.
MME to RAN(Plain)
AUTN
RAND
Step-6:
RAN calculates the res value based on the same key that HSS has and sends this res value to MME.
RAN to MME(Plain)
RES
Step-7:
MME now verifies this res value with the res value obtained from the HSS. If they match. it sends OK reply. Otherwise, it does not reply anything.
MME to RAN(Plain)
"OK"
Step-8:
If UE gets OK reply, then the authentication of UE is successful, otherwise not.
2. Setup of Tunnels
Step-1:
When the authentication match was successful at the MME, the RAN is supposed to send the APN info indicating which PDN(PGW) to contact. But there might be situations where the RAN does not know about the PDN to which it has to get connected to. In such case, MME should acquire the APN info from the HSS for this particular UE and this APN is called the default APN. Once acquiring the APN, the MME should resolve it using DNS to find the IP address of the PGW. Now MME should choose one SGW for the purpose of tunneling data between eNodeB and PDN. MME creates a CREATE SESSION request and chooses a default bearer Identity for the UE Default Bearer and sends it to the SGW. In this request message, MME includes its own GTP-C TEID(chosen by the MME) and UE details(UE IMSI and UE Bearer ID). Typically MME should send this message on GTP-C tunnel, but since it does not know about SGW GTP-C TEID, it uses a '0' in GTP-C field.(But for convenience, MME sends this without any GTP headers and just as a plain message).
MME to SGW:(Plain)
MME GTP-C TEID
UE IMSI (UE NUM is made to send instead)
UE Bearer ID
Step-2:
On receiving this request, the SGW adds the UE related info to the bearer table it has and saves the GTP-C TEID of MME so that it can use it later for control communication with MME. It then chooses one TEID for GTP-C(for control plane data) and one TEID for GTP-U(for data plane data). It then forwards this request to PGW. In this request, it includes its own GTP-C TEID and GTP-U TEID along with UE details. It sends this message just like MME sent the request to SGW for the first time.
SGW to PGW(Plain)
SGW GTP-C TEID
SGW GTP-U TEID
UE IMSI
UE Bearer ID
Step-3:
PGW now saves the GTP-C TEID and GTP-U TEID of SGW so that it can use it for further control communication and data communication ans then it adds the UE related data to the bearer table it has and chooses an IP address(predefined for simplicity) for the UE. It also chooses its own GTP-C TEID and GTP-U TEID. Finally PGW passes these data(UE IP address, PGW GTP-C and GTP-U TEID). But this time, since it has the GTP-C TEID of SGW, it uses encapsulted GTP header for control data communication.
PGW to SGW:(GTP-C)
PGW GTP-C TEID
PGW GTP-U TEID
UE IP address
Step-4:
On receiving the GTP-C TEID and GTP-U TEID of PGW, SGW saves these data so that it can use later for control and data communication. SGW now replies to the MME with GTP protocol(GTP-C TEID of MME saved earlier). In this reply, it just sends the GTP-C TEID of SGW and indication of successful response of Create Session Request from MME.
SGW to MME(GTP-C)
Success(for Create Session Request)
GTP-C TEID of SGW
Step-5:
MME receives the GTP-C TEID of SGW and saves it so that it can communicate further with SGW through GTP-C protocol. This ends the series of messages in Create Session Request.
Till this point, Control tunnel is created between MME and SGW; SGW and PGW. Data tunnel is also created between SGW and PGW. Now, the only remaining tunnel to be created is data tunnel between eNodeB and SGW.
Step-Intermediate:
(Happens exactly after MME sends OK reply for authentication to RAN; this might happen while Create Session Request is being processed by GWs)
eNodeB now creates its own TEID for GTP-U between itself and SGW. It then sends this message to MME through NAS security procedure(encryption and integrity check protection).
eNodeB to MME(NAS security)
eNodeB GTP-U TEID
Step-6:
MME after receiving Create Session Response from SGW and GTP-U TEID from eNodeB, it sends the GTP-U TEID of eNodeB to SGW through Modify Session Request message via GTP protocol since it has saved the GTP-C TEID of SGW.
MME to SGW(GTP-C)
GTP-U TEID of eNodeB
Step-7:
SGW receives the GTP-U TEID of eNodeB and saves it. Now, SGW has GTP-C TEID of MME and PGW(for control communication) and GTP-U TEID of eNodeB and PGW(for data communication). Note that these TEIDs are for ONE PARTICULAR UE and this is how mobility is handled in LTE EPC, which would be dealt later.
Step-8:
SGW sends the Modify Bearer Response to MME including its own GTP-U TEID and UE IP address that it had saved earlier through GTP-C protocol. This also indicates the successful response of Modify Bearer request from MME.
SGW to MME(GTP-C)
Success(Modify Bearer Request)
GTP-U TEID of SGW
IP address of UE
Step-9:
MME, on receiving the Modify Bearer Response, sends a set of data to eNodeB. This includes IP address of UE, GTP-U TEID of SGW. This go via the NAS security procedure(encryption and integrity protection).
MME to eNodeB(NAS security)
IP address of UE
GTP-U TEID of SGW
Step-10
eNodeB on receiving the IP address of UE and GTP-U TEID of SGW, finishes this whole attach procedure. It assigns the UE the IP address that it has just received. It also saves the GTP-U TEID of SGW for all further data communication with SGW for this PARTICULAR UE.
After this whole process,
1. Control tunnel is formed between MME and SGW.
2. Control tunnel is formed between SGW and PGW.
3. Data tunnel is formed between SGW and PGW.
4. Data tunnel is formed between eNodeB and SGW.
User Equipment Uplink & Downlink Data transfer:
1. UE Data transfer happens via iperf with the tunnels formed above.
Detach Procedure:
Step - 1:
After sending iperf data traffic for a required amount of time, UE sends detach request to MME with type - 3.
RAN to MME(Plain)
type = 3
Step - 2:
On receiving type-3 detach request from UE, MME would forward the Delete Session Request message(through GTP-C) to the concerned SGW for this UE and it would then remove the corresponding entry(Client num it has obtained when this UE requested for attach) in the bearer table for this UE.
MME to SGW(GTP-C)
type = 3
Step - 3:
On receiving Delete session request from MME, SGW would forward the Delete Session Request message(through GTP-C) to the concerned PGW for this UE and it would then remove the corresponding entry(Client num it has obtained when this UE requested for attach) in the bearer table for this UE.
SGW to PGW(GTP-C)
type = 3
Step - 4:
On receiving Delete session request from SGW, PGW would send back Delete Session response to SGW and then remove the corresponding entry(Client num it has obtained when this UE requested for attach) in the bearer table for this UE. It also removes the TUN data such as TEID specific to this UE.
PGW to SGW(GTP-C)
OK
Step - 5:
On receiving Delete session response from PGW, SGW sends back the Delete Session response message to the MME and removes the TUN data such as TEID specific to this UE.
SGW to MME(GTP-C)
OK
Step - 6:
On receiving Delete session response from SGW, MME removes the TUN data such as TEID specific to this UE and then it sends back the detach accept message to the UE.
MME to RAN(Plain)
OK