APN stands for Access Point Name. This is a kind of Gateway (or Anchoring point) to which your UE (Mobile Phone) get attached to get access to the core network for most of the data service. The word names two things at once, and separating them early saves a lot of confusion later. The gateway is a real box in the core network, and in LTE it is the PGW. The APN is the short text string that points at it, something like
That indirection is the whole reason this page is long. One string has to mean the same thing in three places at once: the setting on the handset, the subscription record in the HSS, and the configuration of the test equipment or the live network. Get it wrong and nothing obvious breaks. The UE attaches, the bearer comes up, and no data flows.
Only part of this is written down. 3GPP defines the shape of the name, how the network resolves it, and what to do when the UE sends none, and the sections below quote all three. What no specification defines is which name your operator expects, or how a particular handset reacts when it receives a different one. That gap is where the practical problems come from, and most of this page is about it.
In this page, I will talk about APN with practical aspect and followings are the list of topics I will cover in this page.
- How APN is assinged ?
- What is the APN string made of ?
- How the network turns the APN into a PGW
- Protocol aspect of APN assignment
- Case 1 : Assignment of default APN
- Case 2 : Assignment of additional APN
- Case 3 : Network assigns a different APN from the one requested
- Case 4 : Network rejects the requested APN
- APN in S1AP
- APN-AMBR, and how to read it in the capture above
- UE Setting Aspect of APN Assignement
- Why sometimes UE does not specify APN name in PDN Connectivity Request ?
- Case 1 : UE does not want to send those information before Security is established
- Case 2 : Implying that UE doesn't care which APN the network assigns
- Case 3 : Possible UE bug
- Where the APN comes from when the UE sends none
- Common Issues and Challenges for APN related issues
- Check List
- Reference
How APN is assinged ?
How APN is assigned to UE ? Basically it gets assigned by network based on the request from the UE. So it is combination of UE setting(for request) and Network configuration. Since both parties get involved in APN assignment, frequently this APN assignment cause various issues espcially for testing the UE. (You would not see much of the problem with this for commericilized phone being used in real network since they are preconfigured to exactly match network requirement when you purchase it, but in many testing situation frequently you would see the case where the exact APN requirement on UE and network is not known. Some UE is pretty flexible/tolerant about the mismatched APN assignment from test equipment but some UE is very picky about the APN assignment from test equipment and shows various strange behavior when the assignment from network does not exactly match what it is expecting.
So when you are testing a UE (DUT) for most of the data service related test (e.g, IP throughput, Browsing, IMS etc), you have to consider both Protocol aspect of APN assingment and UE side APN setting.
It helps to be precise about how many times the name travels. The UE may put an APN in its request, and the network always puts one in its answer. Those are two separate fields in two separate messages, and nothing forces them to match. A test that checks only the second one will pass while the first one is empty.
Three places can supply the value. The UE side setting supplies what the handset asks for. The subscription in the HSS supplies what the network assigns when the handset asks for nothing. The ESM information exchange supplies it later still, when the UE would rather not send the name before security is running. The sections below take each of them in turn.
Two fields, not one : the requested APN and the assigned APN are separate, and they may differ.The UE may send nothing : an empty request is normal, and a section further down covers it.The network always answers with a name : Activate Default EPS Bearer Context Request carries an APN in every case.A mismatch is a configuration problem rather than a protocol error : which is why most of this page is about settings.
What is the APN string made of ?
So far the APN has been a name that somebody types into a settings screen. It is a structured string, and its structure is what decides which gateway the network picks for you. 3GPP TS 23.003 defines it in two parts, and only the first part is mandatory.
| APN Network Identifier | Which external network the PGW connects to, and optionally a service the UE is asking for. | Yes |
| APN Operator Identifier | Which PLMN backbone the PGW sits in. It is placed after the Network Identifier. | No, but stage 3 makes it mandatory on some interfaces |
The Network Identifier carries the rules that cause most of the trouble. It holds at least one label and, after encoding, at most 63 octets. It must not start with
The Operator Identifier is more regular. It is three labels, and the last one is always
The whole APN reaches 100 octets at most, and its syntax is the DNS name syntax of RFC 1035 and RFC 1123. Labels take letters, digits and the hyphen. A label begins and ends with a letter or a digit, and case does not matter. On the wire each label is one length octet followed by that many ASCII octets, and no zero octet closes the string. 23.003 notes that the MME adds that zero itself before it queries a DNS server.
You can check the encoding against the captures on this page. The Activate Default EPS Bearer Context Request for IMS reports
This also explains why
Two parts, one order : the Network Identifier first, the Operator Identifier after it.63 octets for the Network Identifier, 100 for the whole APN : both counted after encoding.The Operator Identifier is derived, not invented : it comes from the MCC and MNC of the IMSI, with the MNC padded to three digits.The length field counts the length octet : which is why a three character APN reports 4.
How the network turns the APN into a PGW
The string matters only because something has to resolve it. The MME does not hold a table of gateways. It builds a domain name out of the APN and asks DNS, which is the reason the label rules above are DNS rules rather than 3GPP inventions.
23.003 calls the result the APN-FQDN, and two edits build it. The labels
The MME queries that name and gets one or more PGW addresses back. 23.401 clause 4.3.8.1 governs which one it then picks. The subscription context from the HSS holds either the identity of a PGW together with an APN, or an APN with an indication that the gateway may be allocated dynamically. Where the DNS answer carries Weight Factors, the MME should use them when it needs to balance load, and the weight reflects a gateway's capacity relative to the others serving the same APN.
The APN-OI Replacement field exists for operators who need more than one gateway pool per PLMN. It has the same shape as the default Operator Identifier, except that one or more labels may sit in front of it. 23.003 gives
Roaming turns that off. When the visited network's PGW is the one to be selected, the Operator Identifier is built from the serving PLMN ID instead, and 23.003 says the APN-OI Replacement field shall be ignored if it was received.
The APN is the input to a DNS query : which is why a label may hold only letters, digits and hyphens.Two edits build the FQDN : insertapn.epc. , and swap.gprs for.3gppnetwork.org .The HSS decides before DNS does : the subscription either names a gateway or allows a dynamic one.APN-OI Replacement never leaves the MME : it steers the lookup, and the APN sent onward is unchanged.
Protocol aspect of APN assignment.
Two messages carry the APN, and everything else in this section is an example of one of them. The first is the request the UE sends. The second is the answer the network sends back. Both hold the same information element, and nothing requires them to hold the same value.
Typical process of APN assingment protocol is very simple. It happens in two steps as listed below.
i) UE -> NW : PDN Connectivity Request // Usually UE request PDN with a specific APN (or no specified APN)
ii) UE <- NW : Activate Default EPS Bearer Context Request // Network always specifies a specific APN
In reality, these two NAS message gets embedded in a little bit different RRC messages. Typically you may see following two types of RRC message carrying these NAS messages.
Case 1 : Assignment of default APN
The default APN arrives with the attach itself, so the UE has no connection yet when it asks for one. That constraint shapes the message pair below. Both NAS messages have to ride inside RRC messages that the attach procedure was going to send anyway.
In case of assignment of default APN, usually following two steps gets involved.
i) RRC : RRC Connection Setup Complete + NAS : Attach Request + ESM : PDN Connectivity Request
ii) RRC : RRC Connection Reconfiguration + NAS : Attach Accept + NAS : Activate Default EPS Bearer Context Req
< PDN Connectivity Request : Default APN > NAS capture. Field values are from a live capture, not from the specification.
NAS EPS session management messages: PDN connectivity request (0xd0)
0011 .... = PDN type: IPv4v6 (3)
.... 0001 = Request type: initial request (1)
ESM information transfer flag
1101 .... = Element ID: 0xd-
.... 000. = Spare bit(s): 0x00
.... ...1 = EIT (ESM information transfer): Security protected ESM information transfer required
Protocol Configuration Options
Element ID: 0x27
Length: 32
[Link direction: MS to network (0)]
1... .... = Extension: True
Configuration Protocol: PPP for use with IP PDP type or IP PDN type (0)
Protocol or Container ID: Internet Protocol Control Protocol (0x8021)
Length: 0x10 (16)
PPP IP Control Protocol
Code: Configuration Request (1)
Identifier: 0 (0x00)
Length: 16
Options: (12 bytes), Primary DNS Server IP Address, Secondary DNS Server IP Address
Primary DNS Server IP Address: 0.0.0.0
Type: Primary DNS Server IP Address (129)
Length: 6
Primary DNS Address: 0.0.0.0 (0.0.0.0)
Secondary DNS Server IP Address: 0.0.0.0
Type: Secondary DNS Server IP Address (131)
Length: 6
Secondary DNS Address: 0.0.0.0 (0.0.0.0)
Access Point Name // UE can specify a predefined name here.
// In case of default EPS bearer, it is common that the APN is not specified
Protocol or Container ID: DNS Server IPv4 Address Request (0x000d)
Length: 0x00 (0)
Protocol or Container ID: DNS Server IPv6 Address Request (0x0003)
Length: 0x00 (0)
Protocol or Container ID: IP address allocation via NAS signalling (0x000a)
Length: 0x00 (0)
Protocol or Container ID: IPv4 Link MTU Request (0x0010)
Length: 0x00 (0)
< Activate Default EPS Bearer Context Request : Default APN > NAS capture. Field values are from a live capture, not from the specification.
NAS EPS session management messages: Activate default EPS bearer context request (0xc1)
EPS quality of service
Length: 1
Quality of Service Class Identifier (QCI): QCI 9 (9)
Access Point Name
Length: 8
APN: internet // Network Assigns a specific APN Name
PDN address
Length: 13
0000 0... = Spare bit(s): 0x00
PDN type: IPv4v6 (3)
PDN IPv6 if id: 0000000000000001
PDN IPv4: 192.168.137.2 (192.168.137.2)
Protocol Configuration Options
Element ID: 0x27
Length: 8
[Link direction: Network to MS (1)]
1... .... = Extension: True
Configuration Protocol: PPP for use with IP PDP type or IP PDN type (0)
Protocol or Container ID: Internet Protocol Control Protocol (0x8021)
Length: 0x04 (4)
PPP IP Control Protocol
Code: Configuration Nak (3)
Identifier: 0 (0x00)
Length: 4
Case 2 : Assignment of additional APN
An additional APN is requested after the UE has attached and already holds a default bearer. The RRC leg therefore differs from the attach case, because no attach is running to carry the NAS message. Watch the first line of each pair below for that difference.
In case of assignment of additional APN after the default APN, usually following two steps gets involved.
i) RRC : ulinformationTransfer + ESM : PDN Connectivity Request
ii) RRC : RRC Connection Reconfiguration + NAS : Activate Default EPS Bearer Context Req
< PDN Connectivity Request : Additional APN > NAS capture. Field values are from a live capture, not from the specification.
NAS EPS session management messages: PDN connectivity request (0xd0)
0011 .... = PDN type: IPv4v6 (3)
.... 0001 = Request type: initial request (1)
Access Point Name
Element ID: 0x28
Length: 4
APN: ims // Usually UE request PDN with specific APN name
Protocol Configuration Options
Element ID: 0x27
Length: 41
[Link direction: MS to network (0)]
1... .... = Extension: True
Configuration Protocol: PPP for use with IP PDP type or IP PDN type (0)
Protocol or Container ID: Internet Protocol Control Protocol (0x8021)
Length: 0x10 (16)
PPP IP Control Protocol
Code: Configuration Request (1)
Identifier: 0 (0x00)
Length: 16
Options: (12 bytes), Primary DNS Server IP Address, Secondary DNS Server IP Address
Primary DNS Server IP Address: 0.0.0.0
Type: Primary DNS Server IP Address (129)
Length: 6
Primary DNS Address: 0.0.0.0 (0.0.0.0)
Secondary DNS Server IP Address: 0.0.0.0
Type: Secondary DNS Server IP Address (131)
Length: 6
Secondary DNS Address: 0.0.0.0 (0.0.0.0)
Protocol or Container ID: DNS Server IPv4 Address Request (0x000d)
Length: 0x00 (0)
Protocol or Container ID: DNS Server IPv6 Address Request (0x0003)
Length: 0x00 (0)
Protocol or Container ID: P-CSCF IPv6 Address Request (0x0001)
Length: 0x00 (0)
Protocol or Container ID: P-CSCF IPv4 Address Request (0x000c)
Length: 0x00 (0)
Protocol or Container ID: IP address allocation via NAS signalling (0x000a)
Length: 0x00 (0)
Protocol or Container ID: MS Support of Network Requested Bearer Control indicator (0x0005)
Length: 0x00 (0)
Protocol or Container ID: IPv4 Link MTU Request (0x0010)
Length: 0x00 (0)
< Activate Default EPS Bearer Context Req : Additional APN > NAS capture. Field values are from a live capture, not from the specification.
NAS EPS session management messages: Activate default EPS bearer context request (0xc1)
EPS quality of service
Length: 1
Quality of Service Class Identifier (QCI): QCI 9 (9)
Access Point Name
Length: 4
APN: ims // Network Allocate the specific APN Name. This may or may not be the same as UE requested
PDN address
Length: 13
0000 0... = Spare bit(s): 0x00
PDN type: IPv4v6 (3)
PDN IPv6 if id: 0000000000000011
PDN IPv4: 192.168.1.11 (192.168.1.11)
Linked TI - Transaction identifier
Element ID: 0x5d
Length: 1
0... .... = TI Flag: The message is sent from the side that originates the TI
TI value: 0x02 (2)
Quality Of Service - Negotiated QoS
Element ID: 0x30
Length: 14
00.. .... = Spare bit(s): 0
..10 0... = Quality of Service Delay class: Delay class 4 (best effort) (4)
.... .011 = Reliability class: Unacknowledged GTP/LLC, Ack RLC, Protected data (3)
1001 .... = Peak throughput: Up to 256 000 octet/s (9)
.... 0... = Spare bit(s): 0
.... .010 = Precedence class: Normal priority (2)
000. .... = Spare bit(s): 0
...0 1010 = Mean throughput: 100 000 octet/h (10)
100. .... = Traffic class: Background class (4)
...1 0... = Delivery order: Without delivery order ('no') (2)
.... .011 = Delivery of erroneous SDUs: Erroneous SDUs are not delivered('No') (3)
Maximum SDU size: 1500 octets (150)
Maximum bitrate for uplink: 64 kbps (64)
Maximum bitrate for downlink: 384 kbps (104)
0111 .... = Residual Bit Error Rate (BER): 1*10-5 (7)
.... 0100 = SDU error ratio: 1*10-4 (4)
0000 00.. = Transfer delay: Subscribed transfer delay/reserved (0)
.... ..00 = Traffic handling priority: Subscribed traffic handling priority/Reserved (0)
Guaranteed bitrate for uplink: 64 kbps (64)
Guaranteed bitrate for downlink: 568 kbps (127)
000. .... = Spare bit(s): 0
...0 .... = Signalling indication: Not optimised for signalling traffic
.... 0000 = Source statistics description: unknown (0)
Maximum bitrate for downlink (extended): Use the value indicated by the Maximum bit rate for downlink (0)
Guaranteed bitrate for downlink (extended): Use the value indicated by the Guaranteed bit rate for downlink (0)
LLC Service Access Point Identifier - Negotiated LLC SAPI
Element ID: 0x32
0000 .... = Spare bit(s): 0
.... 0011 = LLC SAPI: SAPI 3 (3)
Radio Priority
1000 .... = Element ID: 0x8-
Radio Priority (PDP or SMS): priority level 1 (highest) (1)
Protocol Configuration Options
Element ID: 0x27
Length: 72
[Link direction: Network to MS (1)]
1... .... = Extension: True
Configuration Protocol: PPP for use with IP PDP type or IP PDN type (0)
Protocol or Container ID: Internet Protocol Control Protocol (0x8021)
Length: 0x10 (16)
PPP IP Control Protocol
Code: Configuration Nak (3)
Identifier: 0 (0x00)
Length: 16
Options: (12 bytes), Primary DNS Server IP Address, Secondary DNS Server IP Address
Primary DNS Server IP Address: 10.211.64.87
Type: Primary DNS Server IP Address (129)
Length: 6
Primary DNS Address: 10.211.64.87 (10.211.64.87)
Secondary DNS Server IP Address: 10.211.64.87
Type: Secondary DNS Server IP Address (131)
Length: 6
Secondary DNS Address: 10.211.64.87 (10.211.64.87)
Protocol or Container ID: DNS Server IPv4 Address (0x000d)
Length: 0x04 (4)
IPv4: 10.211.64.87
Protocol or Container ID: DNS Server IPv6 Address (0x0003)
Length: 0x10 (16)
IPv6: 2001:0:0:1::2
Protocol or Container ID: P-CSCF IPv6 Address (0x0001)
Length: 0x10 (16)
IPv6: 2001:0:0:1::2
Protocol or Container ID: P-CSCF IPv4 Address (0x000c)
Length: 0x04 (4)
IPv4: 192.168.1.2
Case 3 : Network assigns a different APN from the one requested
This one appears in a log as a mismatch that is easy to read past. The UE asks for one name in PDN Connectivity Request, and Activate Default EPS Bearer Context Request comes back carrying another. The author's own note on the capture above says as much: the network allocated name may or may not be the one the UE asked for. The question that follows is whether the UE is supposed to accept it.
Start with what the network is meant to do. 23.401 clause 5.3.2.1 is brief and clear. If the UE provides an APN, that APN shall be employed for default bearer activation. A different name coming back is therefore the network departing from the rule, and it is worth finding out why before blaming the handset.
One case is not a departure at all. Where the subscription holds the wild card APN, 23.003 clause 9.2 lets the node choose either the Network Identifier the UE sent or a default one of its own. So a substitution against a wild card subscription is legal, and the same substitution against an ordinary subscription is not.
Now the part that decides the argument. 24.301 clause 6.4.1.3 describes what the UE does when the message arrives, and the APN is not in it. The UE stops timer T3396 for the APN it provided. It stores the WLAN offload values if they are present, and it checks the PTI. Then, in the specification's own words, for any case the UE shall send an ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message and enter the state BEARER CONTEXT ACTIVE. No step compares the name that came back against the name that went out.
Clause 6.4.1.4 settles the same point from the other side. It lists the ESM cause values a UE may put in an ACTIVATE DEFAULT EPS BEARER CONTEXT REJECT, and there are only three kinds: #26 insufficient resources, #31 request rejected unspecified, and the protocol errors #95 to #111. Not one of them means a wrong APN. So a UE has no conformant way to refuse a default bearer because it did not like the name, and the answer to the question is that it should accept.
A handset that refuses anyway is not following the specification, and the only cause available to it is #31, which tells you nothing at all. If you see #31 straight after an APN substitution, that is what you are looking at. Note also the T3396 detail above: the UE keys its back-off timer on the APN it provided, not on the one it received, so the name that came back plays no part even in the timer bookkeeping.
Accepting at NAS is not the end of it, though, and this is where the testing problems begin. The handset still routes application traffic by its own APN type settings, which is the third panel of Figure 1. A UE can accept the bearer, mark it active, and then send nothing over it, because nothing in its own configuration points at the name the network chose.
The network is supposed to use the APN the UE sent : 23.401 makes it a shall.A wild card subscription is the documented exception : there the node may substitute a default.The UE has no APN check on receipt : 24.301 clause 6.4.1.3 takes it straight to accept.No ESM cause exists for a wrong APN : so refusing is non-conformant, and #31 is all a UE can say.Accepting does not mean the service works : the handset still routes by its own APN type settings.
Case 4 : Network rejects the requested APN
The third outcome is an outright refusal. Instead of an Activate Default EPS Bearer Context Request, the MME sends PDN Connectivity Reject, and 24.301 clause 6.5.1.4.1 says what it must contain: the PTI, and an ESM cause value giving the reason. When the request rode inside an attach, the refusal comes back inside the attach result rather than on its own.
The cause value is the part to read. 24.301 lists more than twenty that can appear here, and these are the ones that point at the APN rather than at something else.
| #27 missing or unknown APN | The name does not exist as far as this network is concerned. | A typo, or an APN configured on the handset but never provisioned in the HSS. |
| #33 requested service option not subscribed | The name exists, but this subscriber is not entitled to it. | The subscription record, not the handset. |
| #66 requested APN not supported in current RAT and PLMN combination | The name is fine elsewhere, and not on this radio technology or in this PLMN. | NB-IoT and roaming setups, where a separate APN is often provisioned. |
| #55 multiple PDN connections for a given APN not allowed | The UE already holds a connection to this APN. | A leftover PDN connection from an earlier test that was never released. |
| #50, #51, #57 PDN type restrictions | The name is accepted and the requested IP version is not. | The UE asking for IPv4v6 where only one family is provisioned. |
| #53 ESM information not received | The network asked for the APN after security and never got an answer. | The ESM Information Request and Response exchange described further down this page. |
One more behaviour costs more lab time than anything else here. The network may add a Back-off timer value IE to the reject, and 24.301 clause 6.5.1.4.3 says what the UE must then do. For most causes, and with a timer value that is neither zero nor deactivated, the UE shall not send another PDN Connectivity Request in that PLMN for the same APN until the timer expires, the UE is switched off, or the USIM is removed. A value marked deactivated removes the expiry entirely, so only a power cycle or pulling the USIM will clear it.
Read that again with a test session in mind. You send one reject with a back-off timer, then fix the APN on the equipment, and the UE never asks again. Nothing is broken. The handset is doing exactly what the specification told it to do, and it will keep doing it until the timer expires. The rule also covers a request that carried no APN at all, so retrying with the APN field empty does not avoid it either.
A short list of causes is exempt from the back-off rule, including #26 insufficient resources, #28 unknown PDN type, the PDN type restrictions #50, #51, #57, #58 and #61, #54 PDN connection does not exist, #65 maximum number of EPS bearers reached, and #66. Cause #26 has a handling clause of its own, 6.5.1.4.2, because a shortage of resources is temporary in a way that an unknown name is not.
The cause value is the diagnosis : #27 points at the network's APN list, #33 at the subscription.An attach-time rejection arrives inside the attach result : not as a standalone reject.A back-off timer stops the UE retrying : same PLMN, same APN, until it expires or the UE restarts.Deactivated means until power off or USIM removal : and it is the usual reason a fixed setup still fails.An empty APN is covered too : so retrying without a name does not avoid the timer.
APN in S1AP
The messages above were read at the NAS layer. The same APN also crosses S1AP between the eNB and the MME, wrapped in a NAS-PDU that S1AP itself does not interpret. The two dumps below show where it sits, and what the MME wraps around it.
Followings are some of the message example going through S1AP that carries APN information.
< UplinkNASTransport > S1AP capture, carrying an ESM Information Response. Field values are from a live capture, not from the specification.
S1 Application Protocol
S1AP-PDU: initiatingMessage (0)
initiatingMessage
procedureCode: id-uplinkNASTransport (13)
criticality: ignore (1)
value
UplinkNASTransport
protocolIEs: 5 items
Item 0: id-MME-UE-S1AP-ID
ProtocolIE-Field
id: id-MME-UE-S1AP-ID (0)
criticality: reject (0)
value
MME-UE-S1AP-ID: ....
Item 1: id-eNB-UE-S1AP-ID
ProtocolIE-Field
id: id-eNB-UE-S1AP-ID (8)
criticality: reject (0)
value
ENB-UE-S1AP-ID: 3
Item 2: id-NAS-PDU
ProtocolIE-Field
id: id-NAS-PDU (26)
criticality: reject (0)
value
NAS-PDU: 27a8ccdcee7e024eda2808016e05697370736e
Non-Access-Stratum (NAS)PDU
0010 .... = Security header type: Integrity protected and ciphered (2)
.... 0111 = Protocol discriminator: EPS mobility management messages (0x07)
Message authentication code: 0xa8ccdcee
Sequence number: 126
0000 .... = EPS bearer identity: No EPS bearer identity assigned (0)
.... 0010 = Protocol discriminator: EPS session management messages (0x02)
Procedure transaction identity: 78
NAS EPS session management messages: ESM information response (0xda)
Access Point Name
Element ID: 0x28
Length: 8
APN: testapn
Item 3: id-EUTRAN-CGI
ProtocolIE-Field
id: id-EUTRAN-CGI (100)
criticality: ignore (1)
value
EUTRAN-CGI
...
Item 4: id-TAI
ProtocolIE-Field
id: id-TAI (67)
criticality: ignore (1)
value
TAI
...
< InitialContextSetupRequest > S1AP capture, carrying the Attach Accept. Field values are from a live capture, not from the specification.
S1 Application Protocol
S1AP-PDU: initiatingMessage (0)
initiatingMessage
procedureCode: id-InitialContextSetup (9)
criticality: reject (0)
value
InitialContextSetupRequest
protocolIEs: 8 items
Item 0: id-MME-UE-S1AP-ID
ProtocolIE-Field
id: id-MME-UE-S1AP-ID (0)
criticality: reject (0)
value
MME-UE-S1AP-ID: ...
Item 1: id-eNB-UE-S1AP-ID
ProtocolIE-Field
id: id-eNB-UE-S1AP-ID (8)
criticality: reject (0)
value
ENB-UE-S1AP-ID: 3
Item 2: id-uEaggregateMaximumBitrate
ProtocolIE-Field
id: id-uEaggregateMaximumBitrate (66)
criticality: reject (0)
value
UEAggregateMaximumBitrate
uEaggregateMaximumBitRateDL: 201943030
uEaggregateMaximumBitRateUL: 201943030
Item 3: id-E-RABToBeSetupListCtxtSUReq
ProtocolIE-Field
id: id-E-RABToBeSetupListCtxtSUReq (24)
criticality: reject (0)
value
E-RABToBeSetupListCtxtSUReq: 1 item
Item 0: id-E-RABToBeSetupItemCtxtSUReq
ProtocolIE-SingleContainer
id: id-E-RABToBeSetupItemCtxtSUReq (52)
criticality: reject (0)
value
E-RABToBeSetupItemCtxtSUReq
e-RAB-ID: 5
e-RABlevelQoSParameters
qCI: 9
allocationRetentionPriority
priorityLevel: Unknown (12)
pre-emptionCapability: shall-not-trigger-pre-emption (0)
pre-emptionVulnerability: pre-emptable (1)
0... .... Extension Present Bit: False
transportLayerAddress: 0a9bb99c
transportLayerAddress(IPv4): xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)
gTP-TEID: ...
nAS-PDU: ...
Non-Access-Stratum (NAS)PDU
0010 .... = Security header type:
Integrity protected and ciphered (2)
.... 0111 = Protocol discriminator:
EPS mobility management messages (0x07)
Message authentication code: 0x5e7a308b
Sequence number: 76
0000 .... = Security header type:
Plain NAS message, not security protected (0)
.... 0111 = Protocol discriminator:
EPS mobility management messages (0x07)
NAS EPS Mobility Management Message Type: Attach accept (0x42)
0000 .... = Spare half octet: 0
.... 0... = Spare bit(s): 0x00
.... .001 = Attach result: EPS only (1)
GPRS Timer - T3412 value
...
Tracking area identity list - TAI list
...
ESM message container
Length: 83
ESM message container contents: ...
0101 .... = EPS bearer identity:
EPS bearer identity value 5 (5)
.... 0010 = Protocol discriminator:
EPS session management messages (0x02)
Procedure transaction identity: 78
NAS EPS session management messages:
Activate default EPS bearer context request (0xc1)
EPS quality of service
Length: 1
Quality of Service Class Identifier (QCI): QCI 9 (9)
Access Point Name
Length: 8
APN: testapn
PDN address
Length: 5
0000 0... = Spare bit(s): 0x00
PDN type: IPv4 (1)
PDN IPv4: xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)
APN aggregate maximum bit rate
Element ID: 0x5e
Length: 6
APN-AMBR for downlink : 8640 kbps
APN-AMBR for uplink : 8640 kbps
APN-AMBR for downlink (extended) : 44 Mbps
APN-AMBR for uplink (extended) : 44 Mbps
APN-AMBR for downlink (extended-2) : 256 Mbps
Total APN-AMBR for downlink : 308.640 Mbps
APN-AMBR for uplink (extended-2) : 256 Mbps
Total APN-AMBR for uplink : 308.640 Mbps
Protocol Configuration Options
....
EPS mobile identity - GUTI
Element ID: 0x50
Length: 11
.... 0... = odd/even indic: 0
.... .110 = Type of identity: GUTI (6)
Mobile Country Code (MCC): 001
Mobile Network Code (MNC): 01
MME Group ID: 32774
MME Code: 33
M-TMSI: 0xc071bb09
EMM cause
Element ID: 0x53
Cause: CS domain not available (18)
GPRS Timer - T3402 value
...
GPRS Timer - T3423 value
...
PLMN List - Equivalent PLMNs - 2 PLMNs
Element ID: 0x4a
Length: 6
PLMN[1] Mobile Country Code (MCC): 001
PLMN[2] Mobile Country Code (MCC): 01
EPS network feature support
Element ID: 0x64
Length: 1
....
Additional update result
1111 .... = Element ID: 0xf-
.... 00.. = Spare bit(s): 0x00
.... ..01 = AURV: CS Fallback not preferred (1)
Item 4: id-UESecurityCapabilities
ProtocolIE-Field
id: id-UESecurityCapabilities (107)
criticality: reject (0)
value
UESecurityCapabilities
..0. .... Extension Present Bit: False
encryptionAlgorithms: c000
...0 .... Extension Present Bit: False
integrityProtectionAlgorithms: c000
Item 5: id-SecurityKey
ProtocolIE-Field
id: id-SecurityKey (73)
criticality: reject (0)
value
SecurityKey: ... [bit length 256]
Item 6: id-HandoverRestrictionList
ProtocolIE-Field
id: id-HandoverRestrictionList (41)
criticality: ignore (1)
value
HandoverRestrictionList
servingPLMN: 131002
Mobile Country Code (MCC): 001
Mobile Network Code (MNC): 02
equivalentPLMNs: 2 items
Item 0
PLMNidentity: 134109
Mobile Country Code (MCC): 001
Mobile Network Code (MNC): 02
Item 1
PLMNidentity: 138107
Mobile Country Code (MCC): 001
Mobile Network Code (MNC): 02
Item 7: id-SubscriberProfileIDforRFP
ProtocolIE-Field
id: id-SubscriberProfileIDforRFP (106)
criticality: ignore (1)
value
SubscriberProfileIDforRFP: 1
APN-AMBR, and how to read it in the capture above
The InitialContextSetupRequest above carries more than an APN name. It also carries the APN aggregate maximum bit rate, and the numbers in that block are easy to add up the wrong way. This section takes them apart, because the decoder and the specification do not agree on the total.
23.401 clause 4.7.3 says what the parameter is for. The subscribed APN-AMBR is stored per APN in the HSS, and it applies unless the MME or the PGW changes it. It limits the aggregate bit rate across all Non-GBR bearers and across all PDN connections of the same APN. Any one of those bearers may use the whole of it while the others are idle. GBR bearers sit outside it entirely.
Two nodes enforce it. The PGW enforces it in the downlink, and the UE enforces it in the uplink with the PGW enforcing it there as well. The MME then sets the UE-AMBR to the sum of the APN-AMBR of every active APN, capped at the subscribed UE-AMBR.
The coding is in 24.301 clause 9.9.4.2, and it runs three octets deep in each direction.
| APN-AMBR for downlink, octet 3 | Reserved. | A rate up to 8640 kbps. The network sets it to 8640 kbps as a marker when the real value is higher. |
| APN-AMBR for downlink (extended), octet 5 | Use the value in octet 3. | Ignore octet 3, and use this value. It reaches 256 Mbps. |
| APN-AMBR for downlink (extended-2), octet 7 | Use what octets 3 and 5 indicate. | This value multiplied by 256 Mbps, added to what octets 3 and 5 indicate. |
Now read the capture with that table beside it. It reports 8640 kbps in the base octet, 44 Mbps in the extended octet, and 256 Mbps in the extended-2 octet. The extended octet is not zero, so the base octet is a marker and does not count. What is left is 256 Mbps plus 44 Mbps, and the UE applies 300 Mbps.
The dump prints
APN-AMBR is per APN, not per bearer : it caps every Non-GBR bearer of that APN together.GBR bearers are outside it : their rate is governed by GBR and MBR instead.A non-zero extended octet replaces the base octet : it does not add to it.Only extended-2 adds : 256 Mbps per step, on top of what the first two octets indicate.
UE Setting Aspect of APN Assignement
There is special settings on UE in which you can add or delete (define) your own APN. How you define these APN on UE side would change UE behavior drastically. So when it comes to testing, it is very important to configure UE side APN setting to match the equipment APN setting. But the problem is .. depending on UE, some UE gives you full control over the APN setting but some UE does not give you any control at all or gives you the limitted controlability.
Following is one example of APN settings that I configured for testing purpose. (Don't try to blindly copy this setting onto your UE and expect it to work with your test environment or in live network).
The screenshot runs left to right through three panels of the Android APN editor. The first panel is the list of access points. The second is the top of one entry, and the third is the bottom of that same entry. A coloured underline marks each field that was changed from its default.
Figure 1. The Name field and the APN field are not the same thing. Only the second one is sent to the network.
Name is a local label : the entry is calleddeafult here, misspelling included, and the handset is perfectly happy with that. Nothing in this field reaches the network.APN is the string that travels : it readsphone , and that is what would appear as the Access Point Name in a PDN Connectivity Request. Comparing the Name field against a log instead is a common mistake.APN type decides which requests use this entry : it is set todefault,mms,supl,hipri,fota , so one entry serves all five. A network that expects a separate entry per service will not match this handset.MCC 001 and MNC 01 tie the entry to one PLMN : that pair is the usual test network, and it is the same MCC and MNC that appear in the captures earlier on this page.APN protocol is set to IPv4 : the PDN Connectivity Requests quoted above ask for IPv4v6, so this particular entry would not have produced them. The two were configured at different times.Almost everything else is left alone : Proxy, Port, Username, Password and Server are all unset and Authentication type is None, which is normal for a test APN. The MMSC field still holds a carrier default that has nothing to do with this network.
Why sometimes UE does not specify APN name in PDN Connectivity Request ?
A PDN Connectivity Request with no APN in it looks broken the first time you meet one in a log. It usually is not. Three situations produce it, and only the last of them is a fault. A later section says what the network does with a request like this.
Case 1 : UE does not want to send those information before Security is established
I think this is the most common case and happens most frequently for the default bearer setup. The PDN request is piggybacked in Attach Request which happens before 'Security Mode Command' procedure. That is, UE does not want to send this kind of information without any security protection. In this case, it is expected that UE send PDN Connectivity Request with ESM information transfer flat = 1. Then Network will send ESM Information Request afrer Security process is completed and then UE will notify APN name it wants to use in ESM Information Response message.
Message: Attach request - NAS capture, with the PDN Connectivity Request inside it. Field values are from a live capture, not from the specification.
Protocol discriminator = 0x7 (EPS Mobility Management) Security header = 0x1 (Integrity protected) Auth code = 0xab180dd6 Sequence number = 0x0a Protocol discriminator = 0x7 (EPS Mobility Management) Security header = 0x0 (Plain NAS message, not security protected) Message type = 0x41 (Attach request) EPS attach type = 2 (combined EPS/IMSI attach) NAS key set identifier: ... Old GUTI or IMSI: ... UE network capability: ... ESM message container: Protocol discriminator = 0x2 (EPS Session Management) EPS bearer identity = 0 Procedure transaction identity = 68 Message type = 0xd0 (PDN connectivity request) Request type = 1 (initial request) PDN type = 3 (IPv4v6) ESM information transfer flag = 1
NOTE : The meaning of ESM information transfer flag is specified in 3GPP 24.301-9.9.4.5 as follows :
The purpose of the ESM information transfer flag information element is to indicate whether ESM information, i.e. protocol configuration options or APN or both, is to be transferred security protected.
value 0 : security protected ESM information transfer not required
value 1 : security protected ESM information transfer required
Case 2 : Implying that UE doesn't care which APN the network assigns
I am not sure if this is explicitely allowed in terms of 3GPP, but I saw many cases where UE accept whatever APN the network assigns when UE does not specify APN name in PDN request.
Case 3 : Possible UE bug
I saw some cases where UE omit APN name in PDN request without setting ESM information transfer flag. In this case, some network may reject PDN request.
Where the APN comes from when the UE sends none
The three cases above leave one question open. If the UE sends no APN, where does the network find one ? The answer sits in the subscription rather than in the message, and 23.401 is explicit about it.
23.401 defines the term directly. A Default APN is the APN which is marked as default in the subscription data, and it is used during the Attach procedure and the UE requested PDN connectivity procedure when no APN is provided by the UE. So the default APN is a field in the HSS record, not a convention between vendors.
Clause 5.3.2.1 then states the rule the MME follows. For a Request Type of initial request, if the UE does not provide an APN, the MME shall use the PDN GW corresponding to the default APN. If the UE does provide one, that APN is used instead. The handover case is stricter. With no APN from the UE and no PGW identity for the default APN in the subscription, 23.401 calls the situation an error case.
That settles the network half of Case 2 above. A UE that sends no APN and then accepts whatever comes back is doing what the specification expects, and the MME that answers with the subscribed default is doing the same. What the specification does not settle is how the UE reacts to the name it receives, and that gap is what the rest of this page is about.
One more subscription value changes the answer, so it is worth knowing. The APN field in the HSS may hold a wild card APN, which the operator sets when the subscriber may reach any network of a given PDP type. 23.003 codes it as a single label
The default APN is a subscription field : marked as default in the HSS record.No APN from the UE means the default APN : for an initial request, 23.401 makes this a shall.Handover with no APN and no stored PGW is an error case : the specification names it as one.A wild card APN widens the choice : the node may use what the UE sent, or pick a default itself.
Common Issues and Challenges for APN related issues
One of the biggest issues about APN is that there is no strict rule, requirement clearly specified in 3GPP. A lot of detailed behavior is up to UE protocol stack implementation and requirement from Carriers. The most important factors is 'Matching between UE side expectation and NW side expectation'. The biggest problem is that it is very hard to find right person who has the clear information about this.
In my case, most of the issues that I come across with these problems are with UE maker/engineers who is working with application layer testing (e.g, IP throughput, IMS etc) and followings are the common situation that ends up with.
- Step i) I think we need to get clear understanding of UE side APN handling implementation and you need to talk to your radio protocol engineer about this.
- Step ii) (after a long time (at least several days) to get any feedback from radio protocol engineer). This protocol implmentation is implemented by chipset maker. We don't have much control over it. We need to talk to chipset maker for clear information.
- Step iii) (after even longer time to get any response from chipset vendor). Chipset maker says the APN configuration varies with each carrier (network operator). If you get clear problem description from Carrier, we may revise our stack to fix the problem.
- Step iv) (UE maker talks to Carriers and also takes a long time to get any feedback). Carrier says "We specified in our that we need this and this kind of APN and you have to make it work in any way. If you have any issues in the detailed protocol layer, it is your problem. We don't have any clear definition in terms of protocol sequence".
After the step iv), it goes back to step i) and after a couple of iteration with no productive progress, usually the verification engineer give up any further technical communication and try to rely on ad-hoc method as follows.
- Method 1) Keep changing UE side APN setup parameters until it work with a specific test equipment
- Method 2) Keep changing test equipment parameters until it work with a specific UE setting
Sometimes this kind of ad-hoc approach works but it can never be a perfect solution. Somebody use Method 1 and some other person use Method 2. So even for testing a same UE using the same equipment, if two different person performs the test final configuration on UE and equipment would be completely different. Also, in some UE you can use only method 1 due to equipment restriction and in some other cases you can use only method 2 due to UE side restriction. Therefore, none of them can be a generic solution.
To be honest, I don't think there would be any generic solution for this issue unless 3GPP put forward any clear requirement on it. For the time being, the most reasonable approach would be to create a clear requirement and check list of your own and coordinate everybody (chipset maker, UE maker and carrier) to follow the rules defined in the check list. Personally, I think Carrier (Network Operator) is at the best position to enforce this practice.
Check List
There is no right or wrong in many APN related issues (e.g, APN name). It is just a matter of a specific rule (set by developer or by network operator) and strictly following the rule. So the check list in this sections ask you about 'do you have this and this kind of rules of your own ?'
1. In what condition UE sets APN name in PDN Connectivity Request message ?
As I mentioned in Protocol aspect of APN assignment, in some case UE specifies APN name in some case and in some case UE does not specify it. The questions is 'in your UE, when it specify the APN name in PDN Connectivity Request ?'.
2. When UE does not specify APN name in its PDN Connectivity Request, what APN name the UE expects from Network in Activate Default EPS Bearer Context Req ?
Is any APN name OK ? or does it expect any specific APN name ?
3. If UE expect any specific APN name from the network in Activate Default EPS Bearer Context Req, where does the specific APN name come from ?
Is it from the requirement by network operator ? or is it from what you specified in UE APN setting ?
4. If UE send PDN Request with IP Type = IPv4v6 and Network allocates IPv4v6 in Activate Default EPS Bearer Context Req but RS(Router Solicitation)/RA(Router Advertisement) process failed, how UE should react ?
It would be desirable that UE gives up IPv6 setup process and just stick to IPv4, but I saw some UE retry the PDN request process until it gets RS/RA successful.
Note : Unlike APN name issues, there is relatively clear requirement specified in 3GPP. Refer to ESM Cause section for further information on this issue.
Reference
Three specifications carry the material added to this page. The practical sections stay as they were written, and these are the documents behind the structure of the name, the gateway selection and the rate limit.
- 23.003 - Numbering, addressing and identification, v20.0.0. Clause 9 is the structure of the APN and the wild card APN, and clause 19.4.2.2 is the APN-FQDN used for the DNS lookup.
- 23.401 - GPRS enhancements for E-UTRAN access, v20.0.0. Clause 4.3.8.1 is PDN GW selection, clause 4.7.3 is the APN-AMBR and its relation to the UE-AMBR, and clause 5.3.2.1 is the rule the MME follows when the UE sends no APN.
- 24.301 - Non-Access-Stratum (NAS) protocol for EPS, v20.0.0. Clause 9.9.4.2 is the coding of the APN aggregate maximum bit rate, and clause 9.9.4.5 is the ESM information transfer flag quoted earlier on this page.