Left: | ||
Right: |
OLD | NEW |
---|---|
1 .. include:: replace.txt | 1 .. include:: replace.txt |
2 .. highlight:: cpp | 2 .. highlight:: cpp |
3 | 3 |
4 ++++++++++++++++++++ | 4 ++++++++++++++++++++ |
5 Design Documentation | 5 Design Documentation |
6 ++++++++++++++++++++ | 6 ++++++++++++++++++++ |
7 | 7 |
8 | 8 |
9 | 9 |
10 -------- | 10 -------- |
11 Overview | 11 Overview |
12 -------- | 12 -------- |
13 | 13 |
14 An overview of the LTE-EPC simulation model is depicted in | 14 An overview of the LTE-EPC simulation model is depicted in |
15 the figure :ref:`fig-epc-topology`. There are two main components: | 15 the figure :ref:`fig-epc-topology`. There are two main components: |
16 | 16 |
17 * the LTE Model. This model includes the LTE Radio Protocol | 17 * the LTE Model. This model includes the LTE Radio Protocol |
18 stack (RRC, PDCP, RLC, MAC, PHY). These entities reside entirely within the | 18 stack (RRC, PDCP, RLC, MAC, PHY). These entities reside entirely within the |
19 UE and the eNB nodes. | 19 UE and the eNB nodes. |
20 | 20 |
21 * the EPC Model. This models includes core network | 21 * the EPC Model. This model includes core network |
22 interfaces, protocols and entities. These entities and protocols | 22 interfaces, protocols and entities. These entities and protocols |
23 reside within the SGW, PGW and MME nodes, and partially within the | 23 reside within the SGW, PGW and MME nodes, and partially within the |
24 eNB nodes. | 24 eNB nodes. |
25 | 25 |
26 | 26 |
27 .. _fig-epc-topology: | 27 .. _fig-epc-topology: |
28 ··· | 28 ··· |
29 .. figure:: figures/epc-topology.* | 29 .. figure:: figures/epc-topology-with-split.* |
30 :align: center | 30 :align: center |
31 | 31 |
32 Overview of the LTE-EPC simulation model | 32 Overview of the LTE-EPC simulation model |
33 | 33 |
34 | 34 |
35 .. _sec-design-criteria: | 35 .. _sec-design-criteria: |
36 | 36 |
37 --------------- | 37 --------------- |
38 Design Criteria | 38 Design Criteria |
39 --------------- | 39 --------------- |
(...skipping 68 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
108 | 108 |
109 | 109 |
110 EPC Model | 110 EPC Model |
111 +++++++++ | 111 +++++++++ |
112 | 112 |
113 | 113 |
114 The main objective of the EPC model is to provides means for the | 114 The main objective of the EPC model is to provides means for the |
115 simulation of end-to-end IP connectivity over the LTE model.· | 115 simulation of end-to-end IP connectivity over the LTE model.· |
116 To this aim, it supports for the | 116 To this aim, it supports for the |
117 interconnection of multiple UEs to the Internet, via a radio access | 117 interconnection of multiple UEs to the Internet, via a radio access |
118 network of multiple eNBs connected to a single SGW/PGW node, as shown | 118 network of multiple eNBs connected to the core network, as shown |
119 in Figure :ref:`fig-epc-topology`. | 119 in Figure :ref:`fig-epc-topology`. |
120 | 120 |
121 The following design choices have been made for the EPC model: | 121 The following design choices have been made for the EPC model: |
122 | 122 |
123 #. The Packet Data Network (PDN) type supported is both IPv4 and IPv6. | 123 #. The Packet Data Network (PDN) type supported is both IPv4 and IPv6. |
124 #. The SGW and PGW functional entities are implemented within a single | 124 #. The SGW and PGW functional entities are implemented in different |
125 node, which is hence referred to as the SGW/PGW node. | 125 nodes, which are hence referred to as the SGW node and PGW node, |
126 #. The scenarios with inter-SGW mobility are not of interests. Hence, a | 126 respectively. |
127 single SGW/PGW node will be present in all simulations scenarios | 127 #. The MME functional entities is implemented as a network node, |
128 which is hence referred to as the MME node. | |
129 #. The scenarios with inter-SGW mobility are not of interest. But | |
130 several SGW nodes may be present in simulations scenarios. | |
128 #. A requirement for the EPC model is that it can be used to simulate the | 131 #. A requirement for the EPC model is that it can be used to simulate the |
129 end-to-end performance of realistic applications. Hence, it should | 132 end-to-end performance of realistic applications. Hence, it should |
130 be possible to use with the EPC model any regular ns-3 application | 133 be possible to use with the EPC model any regular ns-3 application |
131 working on top of TCP or UDP. | 134 working on top of TCP or UDP. |
132 #. Another requirement is the possibility of simulating network topologies | 135 #. Another requirement is the possibility of simulating network topologies |
133 with the presence of multiple eNBs, some of which might be | 136 with the presence of multiple eNBs, some of which might be |
134 equipped with a backhaul connection with limited capabilities. In | 137 equipped with a backhaul connection with limited capabilities. In |
135 order to simulate such scenarios, the user data plane | 138 order to simulate such scenarios, the user data plane |
136 protocols being used between the eNBs and the SGW/PGW should be | 139 protocols being used between the eNBs and the SGW should be |
137 modeled accurately. | 140 modeled accurately. |
138 #. It should be possible for a single UE to use different applications | 141 #. It should be possible for a single UE to use different applications |
139 with different QoS profiles. Hence, multiple EPS bearers should be | 142 with different QoS profiles. Hence, multiple EPS bearers should be |
140 supported for each UE. This includes the necessary classification | 143 supported for each UE. This includes the necessary classification |
141 of TCP/UDP traffic over IP done at the UE in the uplink and at the | 144 of TCP/UDP traffic over IP done at the UE in the uplink and at the |
142 PGW in the downlink. | 145 PGW in the downlink. |
143 #. The focus of the EPC model is mainly on the EPC data plane. The | 146 #. The initial focus of the EPC model is mainly on the EPC data plane. |
144 accurate modeling of the EPC control plane is,· | 147 The accurate modeling of the EPC control plane is,· |
145 for the time being, not a requirement; hence, the necessary control plane | 148 for the time being, not a requirement; however, the necessary control |
146 interactions can be modeled in a simplified way by leveraging on direct | 149 plane interactions among the different network nodes of the core network |
147 interaction among the different simulation objects via the | 150 are realized by implementing control protocols/messages among them. |
148 provided helper objects. | 151 Direct interaction among the different simulation objects via the |
152 provided helper objects should be avoided as much as possible. | |
149 #. The focus of the EPC model is on simulations of active users in ECM | 153 #. The focus of the EPC model is on simulations of active users in ECM |
150 connected mode. Hence, all the functionality that is only relevant | 154 connected mode. Hence, all the functionality that is only relevant |
151 for ECM idle mode (in particular, tracking area update and paging) | 155 for ECM idle mode (in particular, tracking area update and paging) |
152 are not modeled at all. | 156 are not modeled at all. |
153 #. The model should allow the possibility to perform an X2-based | 157 #. The model should allow the possibility to perform an X2-based |
154 handover between two eNBs. | 158 handover between two eNBs. |
155 | 159 |
156 | 160 |
157 | 161 |
158 | 162 |
(...skipping 89 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
248 | 252 |
249 | 253 |
250 EPC Model | 254 EPC Model |
251 +++++++++ | 255 +++++++++ |
252 | 256 |
253 | 257 |
254 | 258 |
255 EPC data plane | 259 EPC data plane |
256 -------------- | 260 -------------- |
257 | 261 |
258 In Figure :ref:`fig-lte-epc-e2e-data-protocol-stack`, we represent the | 262 In Figure :ref:`fig-lte-epc-e2e-data-protocol-stack-with-split`, we represent th e |
259 end-to-end LTE-EPC data plane protocol stack as it is modeled in the | 263 end-to-end LTE-EPC data plane protocol stack as it is modeled in the |
260 simulator. From the figure, it is evident that the· | 264 simulator. The figure shows all nodes in the data path, i.e. UE, eNB, |
261 biggest simplification introduced in the data plane model | 265 SGW, PGW and a remote host in the Internet. All protocol stacks |
262 is the inclusion of the SGW and PGW functionality within a single | 266 (S5 protocol stack, S1-U protocol stack and the LTE radio protocol stack) |
263 SGW/PGW node, which removes the need for the S5 or S8 interfaces· | 267 specified by 3GPP are present. |
264 specified by 3GPP. On the other hand, for both the S1-U protocol stack and | |
265 the LTE radio protocol stack all the protocol layers specified by 3GPP | |
266 are present.· | |
267 | 268 |
268 | 269 |
269 .. _fig-lte-epc-e2e-data-protocol-stack: | 270 .. _fig-lte-epc-e2e-data-protocol-stack-with-split: |
270 ··· | 271 ··· |
271 .. figure:: figures/lte-epc-e2e-data-protocol-stack.* | 272 .. figure:: figures/lte-epc-e2e-data-protocol-stack-with-split.* |
272 :align: center | 273 :align: center |
273 | 274 |
274 LTE-EPC data plane protocol stack | 275 LTE-EPC data plane protocol stack |
275 | 276 |
276 | 277 |
277 | 278 |
278 | |
279 EPC control plane | 279 EPC control plane |
280 ----------------- | 280 ----------------- |
281 | 281 |
282 The architecture of the implementation of the control plane model is | 282 The architecture of the implementation of the control plane model is |
283 shown in figure :ref:`fig-epc-ctrl-arch`. The control interfaces that are | 283 shown in figure :ref:`fig-lte-epc-e2e-control-protocol-stack-with-split`. |
284 modeled explicitly are the S1-AP, the X2-AP and the S11 interfaces.· | 284 The control interfaces that are modeled explicitly are the S1-MME, the S11, and the S5 |
285 interfaces. The X2 interface is also modeled explicitly and it is described in m ore | |
286 detail in section :ref:`sec-x2` | |
285 | 287 |
286 We note that the S1-AP and the S11 interfaces are modeled in a simplified | 288 The S1-MME, the S11 and the S5 interfaces are modeled using procotol data units sent |
287 fashion, by using just one pair of interface classes to model the | 289 over its respective links. These interfaces use the SCTP protocol as transport p rotocol |
288 interaction between entities that reside on different nodes (the eNB | 290 but currently, the SCTP protocol is not modeled in the ns-3 simulator, so the |
289 and the MME for the S1-AP interface, and the MME and the SGW for the | 291 UDP protocol is used instead of the SCTP protocol. |
290 S11 interface). In practice, this means that the primitives of these | 292 |
291 interfaces are mapped to a direct function call between the two | 293 |
292 objects. On the other hand, the X2-AP interface is being modeled using | 294 .. _fig-lte-epc-e2e-control-protocol-stack-with-split: |
293 protocol data units sent over an X2 link (modeled as a point-to-point | 295 |
294 link); for this reason, the X2-AP interface model is more realistic. | 296 .. figure:: figures/lte-epc-e2e-control-protocol-stack-with-split.* |
297 :align: center | |
298 | |
299 LTE-EPC control plane protocol stack | |
295 | 300 |
296 | 301 |
297 | 302 |
298 | |
299 .. _fig-epc-ctrl-arch: | |
300 ··· | |
301 .. figure:: figures/epc-ctrl-arch.* | |
302 :align: center | |
303 | |
304 EPC control model | |
305 | |
306 | |
307 | |
308 | |
309 .. only:: latex | 303 .. only:: latex |
310 | 304 |
311 .. raw:: latex | 305 .. raw:: latex |
312 ······ | 306 ······ |
313 \clearpage | 307 \clearpage |
314 | 308 |
315 | 309 |
316 | 310 |
317 ----------------------- | 311 ----------------------- |
318 Channel and Propagation | 312 Channel and Propagation |
(...skipping 2710 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
3029 | 3023 |
3030 | 3024 |
3031 | 3025 |
3032 .. only:: latex | 3026 .. only:: latex |
3033 | 3027 |
3034 .. raw:: latex | 3028 .. raw:: latex |
3035 ······ | 3029 ······ |
3036 \clearpage | 3030 \clearpage |
3037 | 3031 |
3038 | 3032 |
3033 .. _sec-nas: | |
3039 | 3034 |
3040 --- | 3035 --- |
3041 NAS | 3036 NAS |
3042 --- | 3037 --- |
3043 | 3038 |
3044 | 3039 |
3045 The focus of the LTE-EPC model is on the NAS Active state, which corresponds to EMM Registered, ECM connected, and RRC connected. Because of this, the following simplifications are made: | 3040 The focus of the LTE-EPC model is on the NAS Active state, which corresponds to EMM Registered, ECM connected, and RRC connected. Because of this, the following simplifications are made: |
3046 | 3041 |
3047 - EMM and ECM are not modeled explicitly; instead, the NAS entity at the UE wil l interact directly with the MME to perform actions that are equivalent (with gr oss simplifications) to taking the UE to the states EMM Connected and ECM Connec ted;· | 3042 - EMM and ECM are not modeled explicitly; instead, the NAS entity at the UE will interact directly with the MME to perform actions that are equivalent (with gro ss simplifications) to taking the UE to the states EMM Connected and ECM Connect ed;· |
3048 | 3043 |
3049 - the NAS also takes care of multiplexing uplink data packets coming from the u pper layers into the appropriate EPS bearer by using the Traffic Flow Template c lassifier (TftClassifier).· | 3044 - the NAS also takes care of multiplexing uplink data packets coming from the up per layers into the appropriate EPS bearer by using the Traffic Flow Template cl assifier (TftClassifier).· |
3050 | 3045 |
3051 - the NAS does not support PLMN and CSG selection· | 3046 - the NAS does not support PLMN and CSG selection· |
3052 | 3047 |
3053 - the NAS does not support any location update/paging procedure in idle mode | 3048 - the NAS does not support any location update/paging procedure in idle mode |
3054 | 3049 |
3055 | 3050 |
3056 | 3051 |
3057 Figure :ref:`fig-nas-attach` shows how the simplified NAS model | 3052 Figure :ref:`fig-nas-attach` shows how the simplified NAS model |
3058 implements the attach procedure. Note that both the default and | 3053 implements the attach procedure. Note that both the default and |
3059 eventual dedicated EPS bearers are activated as part of this | 3054 eventual dedicated EPS bearers are activated as part of this |
(...skipping 13 matching lines...) Expand all Loading... | |
3073 | 3068 |
3074 | 3069 |
3075 .. only:: latex | 3070 .. only:: latex |
3076 | 3071 |
3077 .. raw:: latex | 3072 .. raw:: latex |
3078 ······ | 3073 ······ |
3079 \clearpage | 3074 \clearpage |
3080 | 3075 |
3081 | 3076 |
3082 | 3077 |
3083 ----------------- | 3078 ---------------- |
3084 S1 | 3079 S1, S5 and S11 |
3085 ----------------- | 3080 ---------------- |
3086 | 3081 |
3087 S1-U· | 3082 S1-U and S5 (user plane) |
3088 +++++++++ | 3083 +++++++++++++++++++++++++ |
3089 | 3084 |
3090 The S1-U interface is modeled in a realistic way by encapsulating | 3085 The S1-U and S5 interfaces are modeled in a realistic way by encapsulating |
3091 data packets over GTP/UDP/IP, as done in real LTE-EPC systems. The | 3086 data packets over GTP/UDP/IP, as done in real LTE-EPC systems. The |
3092 corresponding protocol stack is shown in Figure | 3087 corresponding protocol stack is shown in Figure |
3093 :ref:`fig-lte-epc-e2e-data-protocol-stack`. As shown in the figure, | 3088 :ref:`fig-lte-epc-e2e-data-protocol-stack-with-split`. As shown in the figure, |
3094 there are two different layers of· | 3089 there are two different layers of· |
3095 IP networking. The first one is the end-to-end layer, which provides end-to-end· | 3090 IP networking. The first one is the end-to-end layer, which provides end-to-end· |
3096 connectivity to the users; this layers involves the UEs, the PGW and | 3091 connectivity to the users; this layer involves the UEs, the PGW and |
3097 the remote host (including eventual internet routers and hosts in | 3092 the remote host (including eventual internet routers and hosts in |
3098 between), but does not involve the eNB. In this version of LTE, the EPC | 3093 between), but does not involve the eNB and the SGW. In this version of LTE, the EPC |
3099 supports both IPv4 and IPv6 type users. The 3GPP unique 64 bit IPv6 prefix | 3094 supports both IPv4 and IPv6 type users. The 3GPP unique 64 bit IPv6 prefix |
3100 allocation process for each UE and PGW is followed here. Each EPC is assigned | 3095 allocation process for each UE and PGW is followed here. Each EPC is assigned |
3101 an unique 16 bit IPv4 and a 48 bit IPv6 network address from the pool of | 3096 a unique 16 bit IPv4 and a 48 bit IPv6 network address from the pool of |
3102 7.0.0.0/8 and 7777:f00d::/32 respectively. In the end-to-end IP connection | 3097 7.0.0.0/8 and 7777:f00d::/32 respectively. In the end-to-end IP connection |
3103 between UE and PGW, all addresses are configured using these prefixes. | 3098 between UE and PGW, all addresses are configured using these prefixes. |
3104 The PGW's address is used by all UEs as the gateway to reach the internet.· | 3099 The PGW's address is used by all UEs as the gateway to reach the internet.· |
3105 | 3100 |
3106 The second layer of IP networking is the EPC local area network. This | 3101 The second layer of IP networking is the EPC local area network. This |
3107 involves all eNB nodes and the SGW/PGW node. This network is | 3102 involves all eNB nodes, SGW nodes and PGW nodes. This network is |
3108 implemented as a set of point-to-point links which connect each eNB | 3103 implemented as a set of point-to-point links which connect each eNB |
3109 with the SGW/PGW node; thus, the SGW/PGW has a set of point-to-point | 3104 with its corresponding SGW node and a point-to-point link which connect |
3110 devices, each providing connectivity to a different eNB. By default, a | 3105 each SGW node with its corresponding PGW node; |
3111 10.x.y.z/30 subnet is assigned to each point-to-point link (a /30 | 3106 thus, each SGW has a set of point-to-point devices, each providing |
3112 subnet is the smallest subnet that allows for two distinct host | 3107 connectivity to a different eNB. By default, a 10.x.y.z/30 subnet |
3113 addresses).· | 3108 is assigned to each point-to-point link (a /30 subnet is the smallest |
3109 subnet that allows for two distinct host addresses).· | |
3114 | 3110 |
3115 As specified by 3GPP, the end-to-end IP | 3111 As specified by 3GPP, the end-to-end IP |
3116 communications is tunneled over the local EPC IP network using | 3112 communications is tunneled over the local EPC IP network using |
3117 GTP/UDP/IP. In the following, we explain how this tunneling is | 3113 GTP/UDP/IP. In the following, we explain how this tunneling is |
3118 implemented in the EPC model. The explanation is done by discussing the | 3114 implemented in the EPC model. The explanation is done by discussing the |
3119 end-to-end flow of data packets. | 3115 end-to-end flow of data packets. |
3120 | 3116 |
3121 .. _fig-epc-data-flow-dl: | 3117 .. _fig-epc-data-flow-dl-with-split: |
3122 ··· | 3118 ··· |
3123 .. figure:: figures/epc-data-flow-dl.* | 3119 .. figure:: figures/epc-data-flow-dl-with-split.* |
3124 :align: center | 3120 :align: center |
3125 | 3121 |
3126 Data flow in the downlink between the internet and the UE | 3122 Data flow in the downlink between the internet and the UE |
3127 | 3123 |
3128 To begin with, we consider the case of the downlink, which is depicted | 3124 To begin with, we consider the case of the downlink, which is depicted |
3129 in Figure :ref:`fig-epc-data-flow-dl`.··· | 3125 in Figure :ref:`fig-epc-data-flow-dl-with-split`.··· |
3130 Downlink IPv4/IPv6 packets are generated from a generic remote host, and | 3126 Downlink IPv4/IPv6 packets are generated from a generic remote host, and |
3131 addressed to one of the UE device. Internet routing will take care of | 3127 addressed to one of the UE device. Internet routing will take care of |
3132 forwarding the packet to the generic NetDevice of the SGW/PGW node | 3128 forwarding the packet to the generic NetDevice of the PGW node |
3133 which is connected to the internet (this is the Gi interface according | 3129 which is connected to the internet (this is the Gi interface according |
3134 to 3GPP terminology). The SGW/PGW has a VirtualNetDevice which is | 3130 to 3GPP terminology). The PGW has a VirtualNetDevice which is |
3135 assigned the base IPv4 address of the EPC network; hence, static | 3131 assigned the base IPv4 address of the EPC network; hence, static |
3136 routing rules will cause the incoming packet from the internet to be | 3132 routing rules will cause the incoming packet from the internet to be |
3137 routed through this VirtualNetDevice. In case of IPv6 address as destination, | 3133 routed through this VirtualNetDevice. In case of IPv6 address as destination, |
3138 a manual route towards the VirtualNetDevice is inserted in the routing table, | 3134 a manual route towards the VirtualNetDevice is inserted in the routing table, |
3139 containing the 48 bit IPv6 prefix from which all the IPv6 addresses of the UEs | 3135 containing the 48 bit IPv6 prefix from which all the IPv6 addresses of the UEs |
3140 and PGW are configured. Such device starts the GTP/UDP/IP tunneling procedure, | 3136 and PGW are configured. Such device starts the GTP/UDP/IP tunneling procedure, |
3141 by forwarding the packet to a dedicated application in the SGW/PGW node which | 3137 by forwarding the packet to a dedicated application in the PGW node which |
3142 is called EpcSgwPgwApplication. This application does the following operations: | 3138 is called EpcPgwApplication. This application does the following operations: |
3143 | 3139 |
3144 #. it determines the eNB node to which the UE is attached, by looking | 3140 #. it determines the SGW node to which it must route the traffic |
3145 at the IP destination address (which is the address of the UE); | 3141 for this UE, by looking at the IP destination address |
3142 (which is the address of the UE); | |
3146 #. it classifies the packet using Traffic Flow Templates (TFTs) to | 3143 #. it classifies the packet using Traffic Flow Templates (TFTs) to |
3147 identify to which EPS Bearer it belongs. EPS bearers have a | 3144 identify to which EPS Bearer it belongs. EPS bearers have a |
3148 one-to-one mapping to S1-U Bearers, so this operation returns the | 3145 one-to-one mapping to S5 Bearers, so this operation returns the |
3149 GTP-U Tunnel Endpoint Identifier (TEID) to which the packet | 3146 GTP-U Tunnel Endpoint Identifier (TEID) to which the packet |
3150 belongs; | 3147 belongs; |
3151 #. it adds the corresponding GTP-U protocol header to the packet; | 3148 #. it adds the corresponding GTP-U protocol header to the packet; |
3152 #. finally, it sends the packet over an UDP socket to the S1-U | 3149 #. finally, it sends the packet over a UDP socket to the S5 |
3150 point-to-point NetDevice, addressed to the appropiate SGW. | |
Tom Henderson
2018/11/26 04:55:06
s/appropiate/appropriate
Manuel Requena
2018/12/14 12:07:43
Done.
| |
3151 | |
3152 As a consequence, the end-to-end IP packet with newly added IP, UDP | |
3153 and GTP headers is sent through one of the S5 links to the SGW, where | |
3154 it is received and delivered locally (as the destination address of | |
3155 the outmost IP header matches the SGW IP address). The local delivery | |
Tom Henderson
2018/11/26 04:55:06
s/outmost/outermost
Manuel Requena
2018/12/14 12:07:43
Done.
| |
3156 process will forward the packet, via an UDP socket, to a dedicated | |
3157 application called EpcSgwApplication. This application then performs | |
3158 the following operations: | |
3159 | |
3160 #. it determines the eNB node to which the UE is attached, by looking | |
3161 at the S5 TEID; | |
3162 #. it maps the S5 TEID to get the S1 TEID. EPS bearers have a | |
3163 one-to-one mapping to S1-U Bearers, so this operation returns the | |
3164 S1 GTP-U Tunnel Endpoint Identifier (TEID) to which the packet | |
3165 belongs; | |
3166 #. it adds a new GTP-U protocol header to the packet; | |
3167 #. finally, it sends the packet over a UDP socket to the S1-U | |
3153 point-to-point NetDevice, addressed to the eNB to which the UE is | 3168 point-to-point NetDevice, addressed to the eNB to which the UE is |
3154 attached. | 3169 attached. |
3155 | 3170 |
3156 As a consequence, the end-to-end IP packet with newly added IP, UDP | 3171 Finally, the end-to-end IP packet with newly added IP, UDP |
3157 and GTP headers is sent through one of the S1 links to the eNB, where | 3172 and GTP headers is sent through one of the S1 links to the eNB, where |
3158 it is received and delivered locally (as the destination address of | 3173 it is received and delivered locally (as the destination address of |
3159 the outmost IP header matches the eNB IP address). The local delivery | 3174 the outmost IP header matches the eNB IP address). The local delivery |
3160 process will forward the packet, via an UDP socket, to a dedicated | 3175 process will forward the packet, via an UDP socket, to a dedicated |
3161 application called EpcEnbApplication. This application then performs | 3176 application called EpcEnbApplication. This application then performs |
3162 the following operations: | 3177 the following operations: |
3163 | 3178 |
3164 #. it removes the GTP header and retrieves the TEID which is | 3179 #. it removes the GTP header and retrieves the S1 TEID which is |
3165 contained in it; | 3180 contained in it; |
3166 #. leveraging on the one-to-one mapping between S1-U bearers and | 3181 #. leveraging on the one-to-one mapping between S1-U bearers and |
3167 Radio Bearers (which is a 3GPP requirement), it determines the· | 3182 Radio Bearers (which is a 3GPP requirement), it determines the· |
3168 Bearer ID (BID) to which the packet belongs; | 3183 Bearer ID (BID) to which the packet belongs; |
3169 #. it records the BID in a dedicated tag called EpsBearerTag, | 3184 #. it records the BID in a dedicated tag called EpsBearerTag, |
3170 which is added to the packet;· | 3185 which is added to the packet;· |
3171 #. it forwards the packet to the LteEnbNetDevice of the eNB node via | 3186 #. it forwards the packet to the LteEnbNetDevice of the eNB node via |
3172 a raw packet socket | 3187 a raw packet socket |
3173 | 3188 |
3174 Note that, at this point, the outmost header of the packet is the | 3189 Note that, at this point, the outmost header of the packet is the |
3175 end-to-end IP header, since the IP/UDP/GTP headers of the S1 protocol | 3190 end-to-end IP header, since the IP/UDP/GTP headers of the S1 protocol |
3176 stack have already been stripped. Upon reception of | 3191 stack have already been stripped. Upon reception of |
3177 the packet from the EpcEnbApplication, the LteEnbNetDevice will | 3192 the packet from the EpcEnbApplication, the LteEnbNetDevice will |
3178 retrieve the BID from the EpsBearerTag, and based on the BID | 3193 retrieve the BID from the EpsBearerTag, and based on the BID |
3179 will determine the Radio Bearer instance (and the corresponding PDCP | 3194 will determine the Radio Bearer instance (and the corresponding PDCP |
3180 and RLC protocol instances) which are then used to forward the packet | 3195 and RLC protocol instances) which are then used to forward the packet |
3181 to the UE over the LTE radio interface. Finally, the LteUeNetDevice of | 3196 to the UE over the LTE radio interface. Finally, the LteUeNetDevice of |
3182 the UE will receive the packet, and delivery it locally to the IP | 3197 the UE will receive the packet, and delivery it locally to the IP |
3183 protocol stack, which will in turn delivery it to the application of | 3198 protocol stack, which will in turn delivery it to the application of |
3184 the UE, which is the end point of the downlink communication. | 3199 the UE, which is the end point of the downlink communication. |
3185 | 3200 |
3186 | 3201 |
3187 | 3202 |
3188 .. _fig-epc-data-flow-ul: | 3203 .. _fig-epc-data-flow-ul-with-split: |
3189 ··· | 3204 ··· |
3190 .. figure:: figures/epc-data-flow-ul.* | 3205 .. figure:: figures/epc-data-flow-ul-with-split.* |
3191 :align: center | 3206 :align: center |
3192 | 3207 |
3193 Data flow in the uplink between the UE and the internet | 3208 Data flow in the uplink between the UE and the internet |
3194 | 3209 |
3195 | 3210 |
3196 The case of the uplink is depicted in Figure :ref:`fig-epc-data-flow-ul`. | 3211 The case of the uplink is depicted in Figure :ref:`fig-epc-data-flow-ul-with-spl it`. |
3197 Uplink IP packets are generated by a generic application inside the UE, | 3212 Uplink IP packets are generated by a generic application inside the UE, |
3198 and forwarded by the local TCP/IP stack to the LteUeNetDevice of the | 3213 and forwarded by the local TCP/IP stack to the LteUeNetDevice of the |
3199 UE. The LteUeNetDevice then performs the following operations: | 3214 UE. The LteUeNetDevice then performs the following operations: |
3200 | 3215 |
3201 #. it classifies the packet using TFTs and determines the | 3216 #. it classifies the packet using TFTs and determines the |
3202 Radio Bearer to which the packet belongs (and the corresponding | 3217 Radio Bearer to which the packet belongs (and the corresponding |
3203 RBID); | 3218 RBID); |
3204 #. it identifies the corresponding PDCP protocol instance, which is | 3219 #. it identifies the corresponding PDCP protocol instance, which is |
3205 the entry point of the LTE Radio Protocol stack for this packet; | 3220 the entry point of the LTE Radio Protocol stack for this packet; |
3206 #. it sends the packet to the eNB over the LTE Radio Protocol stack. | 3221 #. it sends the packet to the eNB over the LTE Radio Protocol stack. |
3207 | 3222 |
3208 The eNB receives the packet via its LteEnbNetDevice. Since there is a | 3223 The eNB receives the packet via its LteEnbNetDevice. Since there is a |
3209 single PDCP and RLC protocol instance for each Radio Bearer, the | 3224 single PDCP and RLC protocol instance for each Radio Bearer, the |
3210 LteEnbNetDevice is able to determine the BID of the packet. This BID | 3225 LteEnbNetDevice is able to determine the BID of the packet. This BID |
3211 is then recorded onto an EpsBearerTag, which is added to the | 3226 is then recorded onto an EpsBearerTag, which is added to the |
3212 packet. The LteEnbNetDevice then forwards the packet to the | 3227 packet. The LteEnbNetDevice then forwards the packet to the |
3213 EpcEnbApplication via a raw packet socket. | 3228 EpcEnbApplication via a raw packet socket. |
3214 | 3229 |
3215 Upon receiving the packet, the EpcEnbApplication performs the | 3230 Upon receiving the packet, the EpcEnbApplication performs the |
3216 following operations: | 3231 following operations: |
3217 | 3232 |
3218 #. it retrieves the BID from the EpsBearerTag in the packet; | 3233 #. it retrieves the BID from the EpsBearerTag in the packet; |
3219 #. it determines the corresponding EPS Bearer instance and GTP-U TEID by | 3234 #. it determines the corresponding EPS Bearer instance and GTP-U TEID by |
3220 leveraging on the one-to-one mapping between S1-U bearers and Radio | 3235 leveraging on the one-to-one mapping between S1-U bearers and Radio |
3221 Bearers; | 3236 Bearers; |
3222 #. it adds a GTP-U header on the packet, including the TEID | 3237 #. it adds a GTP-U header on the packet, including the TEID |
3223 determined previously; | 3238 determined previously; |
3224 #. it sends the packet to the SGW/PGW node via the UDP socket | 3239 #. it sends the packet to the SGW node via the UDP socket |
3225 connected to the S1-U point-to-point net device. | 3240 connected to the S1-U point-to-point net device. |
3226 | 3241 |
3227 At this point, the packet contains the S1-U IP, UDP and GTP headers in | 3242 At this point, the packet contains the S1-U IP, UDP and GTP headers in |
3228 addition to the original end-to-end IP header. When the packet is | 3243 addition to the original end-to-end IP header. When the packet is |
3229 received by the corresponding S1-U point-to-point NetDevice of the | 3244 received by the corresponding S1-U point-to-point NetDevice of the |
3230 SGW/PGW node, it is delivered locally (as the destination address of | 3245 SGW node, it is delivered locally (as the destination address of |
3231 the outmost IP header matches the address of the point-to-point net | 3246 the outmost IP header matches the address of the point-to-point net |
3232 device). The local delivery process will forward the packet to the | 3247 device). The local delivery process will forward the packet to the |
3233 EpcSgwPgwApplication via the corresponding UDP socket. The | 3248 EpcSgwApplication via the corresponding UDP socket. The |
3234 EpcSgwPgwApplication then removes the GTP header and forwards the | 3249 EpcSgwApplication then perfoms the following operations: |
3250 | |
3251 #. it removes the GTP header and retrieves the S1-U TEID; | |
3252 #. it maps the S1-U TEID to get the S5 TEID to which the packet | |
3253 belongs; | |
3254 #. it determines the PGW to which it must send the packet from | |
3255 the TEID mapping; | |
3256 #. it add a new GTP-U protocol header to the packet; | |
3257 #. finally, it sends the packet over a UDP socket to the S5 | |
3258 point-to-point NetDevice, addressed to the corresponding PGW. | |
3259 | |
3260 At this point, the packet contains the S5 IP, UDP and GTP headers in | |
3261 addition to the original end-to-end IP header. When the packet is | |
3262 received by the corresponding S5 point-to-point NetDevice of the | |
3263 PGW node, it is delivered locally (as the destination address of | |
3264 the outmost IP header matches the address of the point-to-point net | |
3265 device). The local delivery process will forward the packet to the | |
3266 EpcPgwApplication via the corresponding UDP socket. The | |
3267 EpcPgwApplication then removes the GTP header and forwards the | |
3235 packet to the VirtualNetDevice. At this point, the outmost header | 3268 packet to the VirtualNetDevice. At this point, the outmost header |
3236 of the packet is the end-to-end IP header. Hence, if the destination | 3269 of the packet is the end-to-end IP header. Hence, if the destination |
3237 address within this header is a remote host on the internet, the | 3270 address within this header is a remote host on the internet, the |
3238 packet is sent to the internet via the corresponding NetDevice of the | 3271 packet is sent to the internet via the corresponding NetDevice of the |
3239 SGW/PGW. In the event that the packet is addressed to another UE, the | 3272 PGW. In the event that the packet is addressed to another UE, the |
3240 IP stack of the SGW/PGW will redirect the packet again to the | 3273 IP stack of the PGW will redirect the packet again to the |
3241 VirtualNetDevice, and the packet will go through the dowlink delivery | 3274 VirtualNetDevice, and the packet will go through the downlink delivery |
3242 process in order to reach its destination UE. | 3275 process in order to reach its destination UE. |
3243 | 3276 |
3244 Note that the EPS Bearer QoS is not enforced on the S1-U | 3277 Note that the EPS Bearer QoS is not enforced on the S1-U and S5 |
3245 links, it is assumed that the overprovisioning of the link bandwidth | 3278 links, it is assumed that the overprovisioning of the link bandwidth |
3246 is sufficient to meet the QoS requirements of all bearers. | 3279 is sufficient to meet the QoS requirements of all bearers. |
3247 | 3280 |
3248 | 3281 |
3249 S1AP | 3282 S1AP |
3250 +++++ | 3283 +++++ |
3251 | 3284 |
3252 The S1-AP interface provides control plane interaction between the eNB | 3285 The S1-AP interface provides control plane interaction between the eNB |
3253 and the MME. In the simulator, this interface is modeled in an ideal | 3286 and the MME. In the simulator, this interface is modeled in a realistic |
3254 fashion, with direct interaction between the eNB and the MME objects, | 3287 fashion transmitting the encoded S1AP messages and information elements |
3255 without actually implementing the encoding of S1AP messages and | 3288 specified in [TS36413]_ on the S1-MME link. |
3256 information elements specified in [TS36413]_ and without actually | |
3257 transmitting any PDU on any link. | |
3258 | 3289 |
3259 The S1-AP primitives that are modeled are: | 3290 The S1-AP primitives that are modeled are: |
3260 | 3291 |
3261 * INITIAL UE MESSAGE | 3292 * INITIAL UE MESSAGE |
3262 * INITIAL CONTEXT SETUP REQUEST | 3293 * INITIAL CONTEXT SETUP REQUEST |
3263 * INITIAL CONTEXT SETUP RESPONSE· | 3294 * INITIAL CONTEXT SETUP RESPONSE· |
3264 * PATH SWITCH REQUEST | 3295 * PATH SWITCH REQUEST |
3265 * PATH SWITCH REQUEST ACKNOWLEDGE· | 3296 * PATH SWITCH REQUEST ACKNOWLEDGE· |
3266 | 3297 |
3298 | |
3299 S5 and S11 | |
3300 +++++++++++ | |
3301 | |
3302 The S5 interface provides control plane interaction between the SGW | |
3303 and the PGW. The S11 interface provides control plane interaction between | |
3304 the SGw and the MME. Both interfaces use the GPRS Tunneling Protocol (GTPv2-C) | |
3305 to tunnel signalling messages [TS29274]_ and use UDP as transport protocol. | |
3306 In the simulator, these interfaces and protocol are modeled in a realistic | |
3307 fashion transmitting the encoded GTP-C messages. | |
3308 | |
3309 The GTPv2-C primitives that are modeled are: | |
3310 | |
3311 * CREATE SESSION REQUEST | |
3312 * CREATE SESSION RESPONSE | |
3313 * MODIFY BEARER REQUEST | |
3314 * MODIFY BEARER RESPONSE | |
3315 * DELETE SESSION REQUEST | |
3316 * DELETE SESSION RESPONSE | |
3317 * DELETE BEARER COMMAND | |
3318 * DELETE BEARER REQUEST | |
3319 * DELETE BEARER RESPONSE | |
3320 | |
3321 Of these primitives, the first two are used upon initial UE attachment for the e stablishment | |
3322 of the S1-U and S5 bearers. Section :ref:`sec-nas` shows the implementation of t he attach | |
3323 procedure. The other primitives are used during the handover to switch the S1-U bearers from | |
3324 the source eNB to the target eNB as a consequence of the reception by the MME of a | |
3325 PATH SWITCH REQUEST S1-AP message. | |
3326 | |
3327 | |
3328 | |
3267 .. only:: latex | 3329 .. only:: latex |
3268 | 3330 |
3269 .. raw:: latex | 3331 .. raw:: latex |
3270 | 3332 |
3271 \clearpage | 3333 \clearpage |
3272 | 3334 |
3273 | 3335 |
3274 | 3336 |
3275 .. _sec-x2: | 3337 .. _sec-x2: |
3276 | 3338 |
(...skipping 1262 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
4539 and the ``EpcHelper`` working "under the hood" to configure the EPC upon explici t methods· | 4601 and the ``EpcHelper`` working "under the hood" to configure the EPC upon explici t methods· |
4540 called by the ``LteHelper``. The exact interactions are displayed in the Figure :ref:`fig-helpers`. | 4602 called by the ``LteHelper``. The exact interactions are displayed in the Figure :ref:`fig-helpers`. |
4541 | 4603 |
4542 .. _fig-helpers: | 4604 .. _fig-helpers: |
4543 ··· | 4605 ··· |
4544 .. figure:: figures/helpers.* | 4606 .. figure:: figures/helpers.* |
4545 :align: center | 4607 :align: center |
4546 | 4608 |
4547 Sequence diagram of the interaction between ``LteHelper`` and ``EpcHelper``. | 4609 Sequence diagram of the interaction between ``LteHelper`` and ``EpcHelper``. |
4548 | 4610 |
OLD | NEW |