At its lowest level sit the 'base' components of Symbian OS. This includes the kernel (EKA1 or EKA2 - see the 'History' section), along with the user library which allows user-side applications to request things of the kernel. Symbian OS has a microkernel architecture, which means that the minimum necessary is within the kernel. It does contain a scheduler and memory management, but no networking or filesystem support. These things are provided by user-side servers. The base layer includes the file server, which provides a fairly DOS-like view of the filesystems on the device (each drive has a drive letter, and backslashes are used as the directory delimiter).
Immediately above base are a selection of 'system libraries'. These take all shapes and sizes, including for example character set conversion, a DBMS database, and resource file handling.
Further up, the software is not so readily arranged into a stack.
There is a large 'networking and communication' subsystem, which has three main servers - ETEL (EPOC telephony), ESOCK (EPOC sockets) and C32 (responsible for serial communication). Each of these has a plug-in scheme. For example ESOCK allows different ".PRT" protocol modules, implementing different types of networking protocol scheme. There's lots of stuff relating to short-range communication links too, such as Bluetooth, IrDA and USB.
There's also a large amount of 'user interface' code. Even though the user interfaces themselves are maintained by other parties, the base classes and substructure ("UIKON") for all UIs are present in Symbian OS.
There are also a selection of 'application engines' for popular smartphone applications such as calendars, address books, and task lists. A typical Symbian OS application is split up into an engine DLL and a graphical application - the application being a thin wrapper over the engine DLL. Symbian OS provides some of these engine DLLs.
There are, of course, many other things that don't fit into this model - for example, SyncML, J2ME providing another set of APIs on top of most of the OS and multimedia. Quite a few of these things are frameworks, and vendors are expected to supply plug-ins to these frameworks from third parties (for example, Helix player for multimedia codecs). This has the advantage that the APIs to such areas of functionality are the same on many phone models, and that vendors get a lot of flexibility, but means that phone vendors need to do a great deal of integration work to make a Symbian OS phone.