**Note:** This guide assumes you've already installed Open5GS and it's running with it's default values. If you're new to Open5GS check out the [Quickstart Guide]({{ site.url }}{{ site.baseurl }}/docs/guide/01-quickstart)
You should see each of the services above, PGW, SGW, HSS, PCRF & MME all running.
If your instance doesn't show this make sure you're started each service:
```bash
$ systemctl start open5gs-*
```
#### Finding out why a Service isn't Starting
If a service isn't running check the log for that service - logs for each service live in */var/log/open5gs/* where each service logs to it's own file - MME logs in mme.log, PGW logs in pgw.log, and so on.
In the example above we can see the error - no SGW GTPC address is configured in the mme.yaml file, meaning Open5GS MME is failing to start.
The errors you experience may be different, but if a service is failing to start it's most often due to a misconfiguration issue in one or more of the Open5GS *.yaml* configuration files. The log should tell you which section of the yaml file is missing or invalid.
If you're not seeing any S1AP connection attempts check the eNB can contact the IP the MME is on (No firewall / ACLs etc blocking) and that SCTP Traffic is able to be carried across your transmission network.
**Note:** 3GPP defines SCTP as the transport protocol for S1-AP/S1-CP traffic (not TCP/UDP). Not all devices / routers support S1AP, particularly over the Internet.
If you're confident the service is running and connectivity is able to be established across your transmission network, you should see the *SCTP INIT* packets in Wireshark. If you're not seeing these packets go back and check your network.
If you are seeing the SCTP INIT messages and seeing an ABORT after each one, that suggests the SCTP connection is trying to be established. Check that the MME service is started and listening on the interface / IP you're sending traffic to.
If you're seeing S1AP Connection attempts but seeing them rejected by Open5GS, the S1AP message show in a packet capture will indicate the rejection reason, as well as in the mme log.
Typically S1AP connections are rejected due to one of these reasons:
* MNC / MCC in eNB does not match *gummei* and *tai* MCC/MNC pair in (mme.yaml*.
* Tracking Area Code does not match configured TACs in *mme.yaml*.
Each of these can be addressed by editing the relevant section in the MME config in */etc/open5gs/mme.yaml*
__Example of sucesful eNB connection to MME:__
```
$ tail -f /var/log/open5gs/mme.log
[mme] INFO: eNB-S1 accepted[10.0.1.14]:3223 in s1_path module (s1ap-lkpath.c:70)
[mme] INFO: eNB-S1 accepted[10.0.1.14] in master_sm module (mme-sm.c:126)
```
## UE Connection Issues
---
If your network is setup there are a variety of reasons your network may not perform correctly / at all when connecting a UE.
#### UE cannot See Network
If while scanning for the networks on your UE / Phone you're not seeing your network, there's a few things to check:
* Check your eNB is connected to the MME
* Check the eNB status
* Check the UE you are scanning with is capable of working on the frequencies / bands and duplex mode (TDD or FDD) used by the UE
* Check UE is within range of eNB
* Check PLMN is not forbidden on USIM (F-PLMN List)
#### UE Fails to Attach to the Network
Assuming while scanning for networks the UE can see the network, but not connect, the most common issues stem from Authentication.
LTE/E-UTRAN employs *Mutual Authentication* of both the network and the subscriber. This means the credentials in the HSS must match the credentials on the USIM and the credentials in the USIM must match those in the HSS. This means unlike GSM, you cannot use just any SIM and disable crypto, you have to know the details on the USIM or be able to program this yourself in order to authenticate.
If the issue is authentication, the mme and hss log will give you an indication as to which side is rejecting the authentication, the UE or the Network (Open5GS);