How can I access my mini-pc via ethernet/wifi without having Monitor?
Depends on how you define "access".
If you do not have a proven kernel & root filesystem (RFS) for booting, then you will absolutely need to have somekind of console attached to this miniPC. Otherwise you will not be able to view all of the startup messages that are generated. (Once a kernel is tested, the kernel is setup to boot in quiet mode for release. Although the Windows kernel is more verbose than normal when using "safe mode".)
PCs have traditionally used a video device (e.g. a monochrome/CGA/EGA/xVGA monitor) as the (text and/or GUI) console. Headless PCs and embedded systems typically use a (low-cost) serial (UART/USART) port as the (text-only) console. Linux can use a console via a USB-to-serial adapter, but some of the startup messages will be lost due to the late initialization of the USB stack.
Remote logins like telnet or ssh can only occur after the kernel has successfully booted. If you have no console and the kernel fails to boot, then you will have scant information to describe or debug the boot failure.
In other words, imagine that you obtain a new laptop with SSD whose screen does not turn on until Win7 or Linux asks for your username/password. The BIOS POST beep codes are disabled. There is no "disk" activity LED. When you first turn on the laptop, nothing appears on the screen at all. There is nothing to indicate boot progress. How are you going to describe the boot failure? How do you begin to solve this? How much time do you have to try out the myriad possible fixes? Or are you just going to use it as a doorstop?
BTW if your LAN is (relatively) secure, then all you need to access the (running) miniPC is telnet (rather than ssh). Startup the telnetd daemon (or configure inetd) on the miniPC, and use a telnet client on your host PC.
Booting from LAN does not solve or address this console issue at all. A LANboot simply means that the kernel image is obtained from a server, rather than local storage.
This does not make sense when there are gigabytes of local (and removeable) storage capacity. Admittedly testing kernels with LANbooting is convenient. U-Boot is capable of using the LAN and tftp, as well as local storage for loading the kernel image; the "U" in its name stands for "universal". Note that the LAN can also be used for accessing the root filesystem via NFS.
If your single-board computer has a UART or USART, then a serial-port console is the way to go. However the complication may be that there is no standard DB-9 serial-port connector or, more common, only logic-level signals are exposed rather than RS-232 signals. Some additional hardware would then be needed to use this interface as the console.
For the Raspberry Pi and the Mele A100/1000/2000, there is a UART but only logic-level signals are available. An external board or converter has to be connected, which will provide either a DB-9 or a USB connection to a host PC (which would need a terminal emulator program, such as Tera Term or Putty). A tutorial for setting up the serial port on a Raspberry Pi is here. U-Boot will probably require a recomplie to use the serial-port console. Support for the serial console will also have be be compiled into the kernel; the serial console for Linux is specified in the "kernel command line" originating from U-Boot. Linux allows specification of multiple consoles, and output messages will be displayed on all of them.
If a serial-port console is not available and/or net access is a must then there is the intermediate solution of booting the Linux kernel with a netconsole. But that usually requires a secure LAN and a known (e.g. static) IP address assigned to the host acting as the "console".
But for full visibility of the boot process, you would want to use a serial console, since almost all Linux-capable SBCs have a UART (with either logic or EIA/RS-232 levels) for a serial-port console.